The password policy is one of the most practically important documents in your ISMS — and one of the most commonly done poorly. Either it sets unrealistic requirements that no one follows, or it’s so vague it provides no real guidance.
This guide explains what ISO 27001 requires for password management, how to write a policy that works in practice, and what auditors actually look for.
Which ISO 27001 Control Covers Passwords?
Password management falls primarily under Control 5.17 (Authentication information) in ISO 27001:2022. This control covers the management of secret authentication information — including passwords, PINs, and cryptographic keys.
It’s also supported by:
- Control 5.15 (Access control) — the broader policy for who can access what
- Control 5.16 (Identity management) — how identities are created and managed
- Control 8.5 (Secure authentication) — the technical controls for implementing authentication securely
Between these four controls, ISO 27001 gives you a comprehensive framework for securing access. The password policy is the key document that brings the people and process side together.
What Must a Password Policy Cover?
ISO 27001 doesn’t dictate specific password lengths or complexity rules — it takes a risk-based approach. But Control 5.17 makes clear that the organisation must have rules in place for the selection, use, and management of authentication information.
Password Policy: Old Thinking vs Modern Guidance
How NCSC and NIST guidance has changed — and what your ISO 27001 policy should reflect
A complete password policy should address:
1. Password creation requirements
What makes an acceptable password? Modern guidance (NCSC, NIST, and most certification bodies) has moved away from complex-but-short passwords (e.g. “P@ssw0rd!”) towards long-but-memorable ones (e.g. three random words). Your policy should reflect current best practice:
- Minimum length — the NCSC recommends a minimum of 12 characters; many policies now specify 16+ for privileged accounts
- Avoid common passwords — your systems should check new passwords against a list of commonly used/compromised passwords where possible
- No mandatory complexity requirements for length-based passwords — this was dropped from NIST guidance because it makes passwords less memorable and encourages poor choices
2. Multi-factor authentication (MFA)
Any modern password policy should address MFA requirements. As a minimum, specify:
- MFA is required for all remote access
- MFA is required for all privileged accounts (admin, system accounts)
- MFA is required for access to sensitive systems (HR, finance, customer data)
Increasingly, auditors expect to see MFA applied broadly — not just to remote access. If your organisation uses M365 or Google Workspace, enabling MFA organisation-wide is typically straightforward and provides strong evidence.
3. Password change and expiry
Again, guidance has evolved. NIST and NCSC no longer recommend mandatory regular password changes — forcing frequent changes leads to predictable patterns (“Password1!” → “Password2!”) and often weakens security. Instead:
- Passwords should be changed when there’s reason to believe they’ve been compromised
- Passwords must be changed when an account is first set up or reset
- Privileged account passwords may have shorter mandated review cycles (e.g. every 90 days) where MFA isn’t available
Your policy should reflect this nuance rather than blanket-mandating monthly changes that your team will work around.
4. Password storage and sharing
- Passwords must never be written down in an unsecured location (sticky notes, unencrypted spreadsheets)
- A password manager should be used — either an organisation-provided enterprise solution or a recommended personal tool
- Passwords must never be shared between individuals — each user must have their own credentials
- System and service account credentials must be stored in a secure vault, not in code or scripts
5. Default and temporary passwords
- Default passwords on all systems must be changed on first use
- Temporary passwords must be changed on first login
- System-generated passwords must be unique per user
6. Responsibilities
Who is responsible for enforcing password policy? Typically:
- IT/system administrators are responsible for enforcing technical controls (minimum length, lockout policies)
- Individual users are responsible for choosing strong passwords and protecting them
- Line managers are responsible for ensuring offboarding procedures revoke credentials promptly
What Do Auditors Look For?
Auditors approach the password policy in two ways: reviewing the document itself, and looking for evidence it’s being followed.
Document review: Is the policy present, current, and consistent with good practice? Does it cover the areas above? Is it signed off and accessible to staff?
Operational evidence: This is where many organisations fall short. Auditors may ask to see:
- A system configuration showing the minimum password length enforced
- MFA enabled in your M365, Google Workspace, or other platform admin console
- The lockout policy configured on your systems (how many failed attempts before lockout?)
- Evidence from your password manager that it’s in use
- A record from your access review process showing that credentials are deactivated when staff leave
The most common finding is a policy that says one thing and practice that does another. If your policy says “minimum 12 characters” but your systems allow 6, the auditor will raise a nonconformity.
What ISO 27001 Auditors Look for on Password Policy
Auditors check two things: the document, and whether it’s actually being followed
A Note on Passphrases
The industry shift towards passphrases (three or more random words) rather than complex short passwords is worth reflecting in your policy. The NCSC’s guidance at ncsc.gov.uk explicitly recommends this approach for most passwords.
A 16-character passphrase like “correct-horse-battery-staple” is far harder to crack than “P@55w0rd” and far easier to remember. If your policy mandates complexity that effectively forces the latter, you’re working against your users rather than with them.
Suggested Policy Structure
1. Purpose and scope — what this policy covers and who it applies to
2. Authentication standards — minimum password length and passphrase approach; prohibition on common/compromised passwords; multi-factor authentication requirements (where mandatory, where recommended)
3. Password management — rules on storage (password manager required), no sharing, no writing down, changing on compromise
4. System and privileged accounts — specific rules for admin accounts, service accounts, shared credentials
5. Default and temporary passwords — must be changed on first use
6. Technical enforcement — reference to system configurations (lockout policy, length minimums) that enforce the policy technically
7. Responsibilities — IT, individual users, line managers
8. Review — how often the policy is reviewed and by whom
Getting the Policy You Need
The ISO 27001 toolkit includes a ready-to-edit password policy template aligned to ISO 27001:2022 and current NCSC guidance. It’s one of a full suite of supporting policies in the toolkit.
You can also read the guide to Control 5.17 (Authentication Information) for a deeper look at what the standard specifically requires from this control.
Get Started
Free Templates
Free
The 14 mandatory documents. The starting point for any ISO 27001 project.
A great way to get started without the commitment.
Templates
Full Toolkit
£85
130+ documents; policies, risk register, audit pack, staff communications and everything else you need to build a working ISMS.
Buy now →Do-It-Yourself
DIY Course
£285
The Do-It-Yourself course introduces the standard, its requirements, and then shows you how to implement it, stage by stage.
Includes the full toolkit & email consultancy.
More support?
Coaching
~£3,500
I can guide you through the standard and help you tailor it to your business through a series of coaching workshops.
Includes the full toolkit, personal consultancy, and first-pass guarantee.