ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
Writing an ISO 27001 password policy is the one task where almost every implementation team starts in the wrong place: they open the standard looking for a number, find none, and quietly copy a 90-day rotation rule from a template written in 2011. ISO/IEC 27001:2022 does not contain a password length. It does not contain a complexity rule. It does not contain an expiry interval. What it contains is a requirement to manage authentication information properly and to log people in securely — and the numbers have to come from somewhere else, chosen by you, justified by your risk assessment, and defensible in front of an auditor.
This guide covers exactly what Annex A asks for, which external baseline to adopt and why the common ones contradict each other, what has to be inside an ISO 27001 password policy, and what evidence a certification body will sample at stage 2.
Free gap assessment
Where do you actually stand against ISO 27001?
Score every management system clause and all 93 Annex A controls, free, and get a prioritised gap list back.
Run the free ISO 27001 gap assessment → or View premium report sample
Two Annex A controls govern an ISO 27001 password policy in the 2022 edition: A.5.17 Authentication information (an organizational control) and A.8.5 Secure authentication (a technological control). A.5.17 covers the full lifecycle of the secret — how it is created, issued, handled by the person holding it, and revoked. A.8.5 covers the log-in mechanism itself: the technology that checks the secret and decides whether to let someone in.
Neither control states a minimum length, a character-composition rule or an expiry interval. That is deliberate. ISO/IEC 27001 is a management system standard, and Annex A is a reference set of control objectives, not a hardening guide. The standard’s position is that you determine the parameters from your risk assessment and then apply them consistently. For the full set of 93 controls across four themes, see our guide to the ISO 27001 Annex A controls.
Free ISO 27001 risk assessment
Which of your risks sit above your appetite line?
Set your own risk criteria, pick from 61 information security risk scenarios, rate likelihood and impact, and decide how to treat each one. You get a heat map, a process score and the findings an auditor would raise, free.
Run the free risk assessment → or View premium report sample
Two consequences follow, and both catch people out. First, an auditor cannot fail your ISO 27001 password policy for choosing 10 characters instead of 12 — but they can and will fail you for choosing a number you cannot explain, or for enforcing something different from what your policy says. Second, an ISO 27001 password policy is not one of the mandatory documents the standard names. You still need one in practice, because A.5.17 and A.8.5 will almost never be excluded in the Statement of Applicability, and clause 6.1.3 requires you to justify every exclusion.
The single most useful thing to understand about an ISO 27001 password policy in the 2022 edition is that A.5.17 is a three-into-one merge. The 2013 standard spread password handling across three separate Annex A controls, each of which could be audited, evidenced and failed on its own. The 2022 edition collapses all three into one SoA line.
| ISO 27001:2013 control | What it covered | ISO 27001:2022 control |
|---|---|---|
| A.9.2.4 Management of secret authentication information of users | How credentials are issued and allocated | A.5.17 Authentication information |
| A.9.3.1 Use of secret authentication information | What the user is obliged to do with them | A.5.17 Authentication information |
| A.9.4.3 Password management system | What the system must enforce technically | A.5.17 Authentication information |
| A.9.4.2 Secure log-on procedures | The log-in mechanism itself | A.8.5 Secure authentication |
| A.9.2.1 User registration and de-registration | Identity lifecycle | A.5.16 Identity management |
| A.9.2.3 Management of privileged access rights | Admin and root accounts | A.8.2 Privileged access rights |
Why does the merge matter? Because most password policies written since the transition only answer the third row. They describe what Active Directory or Okta enforces — length, lockout, history — and say nothing about how a new starter receives their first credential, or what an employee is obliged to do with it. Under the 2013 edition those were separate findings. Under the 2022 edition they are the same finding, which means a single nonconformity can be raised against a document that looks complete.
Build the ISO 27001 password policy to answer all three questions in order: how is authentication information issued and replaced, what is the person holding it required to do, and what does the system enforce. The transition from the 2013 edition closed on 31 October 2025, so there is no longer a legacy certificate to hide behind.
If the standard supplies no number, you have to adopt one. Three external baselines dominate, and the awkward truth is that they disagree with each other. Writing an ISO 27001 password policy for an organization that is also in scope for card payments or a UK government contract means reconciling rules that were written to different threat models.
| Baseline | Minimum length | Composition | Expiry | Status |
|---|---|---|---|---|
| NIST SP 800-63B-4 (July 2025) | 15 characters for single-factor; 8 characters where the password is one factor in MFA | Composition rules prohibited | Periodic change prohibited; forced only on evidence of compromise | Final; supersedes SP 800-63B (2020) |
| PCI DSS v4.0.1 req. 8.3.6 | 12 characters, or 8 where the system cannot support 12 | Must contain both numeric and alphabetic characters | Every 90 days for password-only accounts (req. 8.3.9), unless posture is analysed dynamically | Mandatory since 31 March 2025 |
| Cyber Essentials v3.3 (April 2026) | 8 with MFA, or 12 without MFA, or 8 plus an automatic deny list | Not prescribed | Not prescribed | Current requirements for IT infrastructure |
Of the three, NIST’s SP 800-63B-4 is the most detailed and the most restrictive on what you are not allowed to do. Section 3.1.1.2 prohibits composition rules outright, prohibits periodic expiry, prohibits password hints that an unauthenticated visitor can reach, and prohibits prompting users for knowledge-based answers such as a first pet’s name. It also requires verifiers to compare the whole proposed password against a blocklist of commonly used, expected and breached passwords — not substrings — and to tell the user why it was rejected.
Two further SP 800-63B-4 requirements are worth lifting straight into your document because they fail more real systems than length ever does. Verifiers must accept the entire submitted password and must not truncate it, and verifiers must allow password managers and autofill. A legacy application that silently cuts a passphrase off at 16 characters, or an online banking portal that blocks paste, breaks both. Neither is an ISO 27001 requirement in itself, but once you have named NIST as the baseline inside your ISO 27001 password policy, your own document has made it one.
PCI DSS pulls the opposite way. It keeps complexity and it keeps rotation, because the standard is written for environments where single-factor service accounts are still common. If your cardholder data environment is a carved-out subset of your ISMS scope — which it usually is — do not force the stricter PCI rule across the whole estate. Write a tiered baseline: a general rule for the ISMS, and a named exception for the CDE. An auditor will accept a documented, scoped difference far more readily than an averaged-out rule that satisfies neither standard.
The most common defect in an ISO 27001 password policy is a mandatory expiry interval that nobody can trace to a requirement. It is not in ISO/IEC 27001:2022. It is not in NIST’s current guidance, which prohibits it. The UK’s National Cyber Security Centre is blunter still: its guidance on updating your approach to passwords states that regular password changing harms rather than improves security, on the grounds that users make small predictable variations, stolen credentials are used immediately rather than months later, and a reset tells you nothing about whether a compromise happened.
Rotation survives in an ISO 27001 password policy for exactly one defensible reason: a contractual or regulatory obligation that still demands it, PCI DSS requirement 8.3.9 being the obvious one. If that applies to part of your estate, say so in the policy and name the scope. If it does not apply to you, deleting the rule is a genuine security improvement, not a relaxation — and it is one of the few places where tightening your ISMS means removing a control parameter rather than adding one.
What replaces rotation is event-driven change. Force a reset on evidence of compromise, on appearance in a breach corpus, on a shared or temporary credential at first use, and on role change or termination. That last trigger connects the policy to your joiners-movers-leavers process and to the user access review cycle, which is where certification bodies tend to sample.
Below is the section set that satisfies both controls in full. Map each section to the control it evidences; this mapping is what turns a generic IT document into an ISO 27001 password policy an auditor can trace.
| Policy section | What it has to settle | Control evidenced |
|---|---|---|
| Scope and systems in coverage | Which directories, applications and devices the rules apply to, and any named exceptions | A.5.17 / A.8.5 |
| Baseline parameters | Minimum length, maximum length, blocklist, lockout threshold, and the external baseline you adopted | A.5.17 |
| Issuance and initial credentials | How a first or replacement secret is delivered, and that it must be changed at first use | A.5.17 (from A.9.2.4) |
| User obligations | No reuse across services, no sharing, approved password manager, reporting suspected compromise | A.5.17 (from A.9.3.1) |
| System enforcement | What the identity provider enforces technically, and how exceptions are approved | A.5.17 (from A.9.4.3) |
| Log-in controls | Rate limiting, generic failure messages, no credential display, session handling, MFA triggers | A.8.5 |
| Multi-factor authentication | Which accounts and services require it, and which factor types are accepted | A.8.5 |
| Privileged and service accounts | Separate, stronger parameters; vaulting; no interactive shared logins | A.8.2 |
| Storage and transmission | Salted hashing with an approved algorithm; never in plaintext, tickets or scripts | A.5.17 / A.8.24 |
| Change triggers and revocation | Compromise, breach-list match, role change, termination | A.5.17 / A.5.18 |
| Records | What is logged about allocation and reset events, and how those records are protected | A.5.17 / A.8.15 |
| Review and ownership | Named owner, review frequency, approval route | Clause 7.5 |
Keep the document separate from, but cross-referenced to, your ISO 27001 access control policy. Access control (A.5.15) decides who may reach what; authentication decides whether the person at the keyboard is who the account says they are. Auditors sample them separately, and merging them tends to produce a document where neither control is fully evidenced.
A.8.5 is where MFA lives, and it is the half of an ISO 27001 password policy that carries the most risk reduction per hour of work. The control does not mandate it by name, but in practice no certification body will accept an internet-facing administrative interface protected by a password alone, because the risk assessment behind it cannot be made to stand up. Treat MFA coverage as a scoped commitment in the policy: all remote access, all cloud administration, all privileged accounts, and anything handling the data classifications you have marked as sensitive.
Factor choice matters more than coverage percentages. SMS and push notifications are phishable; FIDO2 security keys and passkeys are not. If you are setting a direction of travel, our guide to phishing-resistant MFA covers the difference and the migration order. For administrator accounts specifically, read it alongside ISO 27001 privileged access, since A.8.2 imposes requirements that your general baseline will not satisfy.
One drafting note: where MFA is enforced, NIST permits the password component to drop to eight characters. That is a real, defensible relaxation, and it is the strongest internal argument for funding an MFA rollout — it buys back user goodwill at the same time as it reduces risk. Write it into the ISO 27001 password policy as an explicit conditional rather than applying the lower figure quietly.
A stage 2 audit tests implementation of your ISO 27001 password policy, not its drafting. Expect the auditor to ask for the document, then immediately ask you to prove the configuration matches it.
| Evidence | What it proves | Common failure |
|---|---|---|
| Screenshot of the enforced policy in the identity provider | Configuration matches the document | Policy says 12 characters, tenant enforces 8 |
| Blocklist or breached-password protection setting | Weak passwords are actually rejected | Feature licensed but never enabled |
| MFA coverage report by account type | The scoped commitment is real | Break-glass and service accounts excluded without approval |
| A sample of new-starter credential issuance | A.5.17 issuance half is implemented | Initial passwords emailed in plaintext |
| Signed acceptable use or policy acknowledgement | User obligations were communicated | Acknowledgements collected once in 2023, never since |
| Legacy systems register with approved exceptions | Deviations are governed, not accidental | Undocumented systems that cap length at 16 |
| Reset and lockout event logs | Records of allocation events exist and are protected | Helpdesk resets with no identity verification step |
The exception register is the item most teams forget. Every estate has an application that cannot meet the baseline. That is not a nonconformity in itself — an undocumented, unapproved, unreviewed exception is. Record the system, the gap, the compensating control, the owner and the review date, and the finding disappears.
Five defects account for most of the findings raised against an ISO 27001 password policy at certification:
An ISO 27001 password policy is not a named mandatory document. ISO/IEC 27001:2022 lists a specific set of documented information that must exist, and a password policy is not on it. In practice you will need one, because A.5.17 and A.8.5 are almost never excluded from the Statement of Applicability, and the practical way to evidence both is a written policy plus matching configuration.
None. An ISO 27001 password policy supplies the number, not the standard. ISO/IEC 27001:2022 states no minimum length anywhere in Annex A. You choose the figure, document the basis, and enforce it consistently. Most organizations adopt 12 to 15 characters for single-factor access and permit 8 where MFA is enforced, following NIST SP 800-63B-4.
No. The 90-day figure comes from PCI DSS requirement 8.3.9 and from legacy practice, not from ISO 27001. Current NIST and NCSC guidance both advise against periodic expiry. Keep it in your ISO 27001 password policy only where a contract or another standard in your scope requires it, and name that scope.
The standard does not name MFA as a requirement. A.8.5 requires secure authentication proportionate to the access being granted, and for remote, administrative and cloud access a password-only risk treatment is very difficult to defend. Treat MFA as effectively mandatory for those populations.
Yes, if it is written as a tiered baseline. Set the general ISMS rule, then define a named exception block for the cardholder data environment carrying PCI DSS’s 12-character minimum, alphanumeric composition and 90-day rotation. Averaging the two into a single rule usually satisfies neither assessor.
The two controls behind an ISO 27001 password policy sit apart: A.5.17 is an organizational control and A.8.5 is a technological control, so they appear in different themes of the SoA with separate justifications. Both should normally be marked applicable; exclusion requires a justification under clause 6.1.3 that an auditor will test hard.
Get the sequence right and an ISO 27001 password policy is an afternoon’s work. Decide the baseline first and write down why. Configure the identity provider to match it, enable breached-password protection, and confirm MFA coverage by account type. Then write the document so that issuance, user obligations and system enforcement each get their own section, because that is the shape of A.5.17. Finally, record the systems that cannot comply and approve them as exceptions. A policy built in that order takes an afternoon and survives a stage 2 audit; one written first and configured afterwards almost never matches the tenant.
If you would rather start from a document that already carries the control mapping, the ISO 27001 Toolkit includes 165 editable templates covering the access control and authentication set alongside the full ISMS documentation suite, for $149. It is the fastest way to get an ISO 27001 password policy, an access control policy and a Statement of Applicability that reference each other correctly rather than three documents written in isolation.
You can confirm the current edition of the standard itself — edition 3, published October 2022, with the free Amendment 1:2024 climate action change — on the ISO catalogue page for ISO/IEC 27001:2022.
October 20, 2026
October 20, 2026
October 19, 2026
October 19, 2026
October 18, 2026