An ISO 27001 compliant password policy must take a risk-based, documented approach to authentication rather than impose a fixed list of rules. It needs to cover secure creation, hashing and storage, blocklist checks, rotation only after compromise, and guidance toward multi-factor authentication, with clear evidence for auditors. The sections below give copy-ready templates and a checklist for each of these requirements.
TL;DR:
- Risk assessments must justify password length, hashing schemes, and MFA requirements based on system sensitivity and data value.
- Technical controls should include usage of bcrypt, scrypt, or Argon2 with explicit metadata for migration and compliance.
- NIST standards recommend minimum length of 15 characters for single-factor secrets and forbids arbitrary complexity rules, aligning with ISO 27001 risk-based approach.
- Passwords must be stored as salted hashes and checked against blocklists of breached passwords, with usability considerations like paste support.
- Documented exceptions should be temporary, justified, and reviewed within a year, to maintain a security posture aligned with audit expectations.
Table of Contents
- ISO 27001 requirements and Annex A mapping for passwords
- Building a password policy template you can reuse
- Technical controls that make the policy enforceable
- Reconciling ISO 27001 with NIST and CISA guidance
- Keeping password rules usable without weakening security
- An implementation checklist for your next audit
- What implementers consistently get wrong
- Get an estimate before you build your policy set
- FAQ
- Sources
ISO 27001 requirements and Annex A mapping for passwords
ISO 27001 does not dictate a minimum password length or a rotation schedule. That means your policy needs to show how you decided on your rules, not just what the rules are.
Auditors expect to see a risk assessment that ties authentication strength to the sensitivity of the systems it protects. A customer-facing portal with low-value data might justify different controls than an admin account with access to production infrastructure. Document the acceptance criteria you used: why a given password length, hashing scheme, or MFA requirement was judged sufficient for that risk tier. This record, not the policy text alone, is what demonstrates compliance under a risk-based framework.
Common audit checks include whether the policy references a specific Annex A control, whether a risk assessment exists for authentication decisions, and whether technical implementation matches what the policy claims. Keep your Annex A mapping current. Recommended artifact names include a “Password and Authentication Policy” document, an “Authentication Risk Assessment” record, and a “Technical Control Evidence” folder holding configuration exports from your identity provider. Store these in your ISMS document register alongside related access control policy ISO 27001 artifacts so an auditor can trace the decision from risk assessment to technical control to evidence.
Building a password policy template you can reuse
A password policy document works best when it follows a predictable shape that auditors already recognize. Use these sections as your skeleton.
- Purpose and scope: state which systems, accounts, and personnel the policy covers.
- Roles and responsibilities: name who owns the policy, who approves exceptions, and who monitors enforcement.
- Password creation requirements: minimum length, allowed characters, and blocklist checks.
- Storage and verification: hashing scheme, salting, and metadata retention.
- Lifecycle rules: when a password must change and when it must not.
- Enforcement and monitoring: how violations are detected and logged.
- Exceptions and review: how deviations are approved and how often the policy is reviewed.
Sample clauses you can adapt:
- “Passphrases of sufficient length are permitted as single-factor credentials; shorter secrets may be acceptable when combined with an approved second factor, according to risk assessment and best practice guidance.”
- “Proposed passwords are checked against a blocklist of commonly breached and context-specific terms before acceptance.”
- “Passwords are stored as salted hashes with algorithm and cost factor metadata retained to support future migration.”
Operational notes matter as much as the clauses themselves. Log every password reset and failed authentication attempt, enforce the blocklist at the application layer rather than relying on user judgment, and include password policy awareness in your annual security training. A policy that exists only on paper will not survive a technical audit.
Technical controls that make the policy enforceable
The policy document sets expectations, but the technical configuration is what an auditor will actually test. Specify a modern hashing scheme such as bcrypt, scrypt, or Argon2, along with a defined cost factor, and store that metadata per record so you can migrate users to stronger parameters over time without a forced reset. NIST SP 800-63B requires verifiers to store salt and hash together and to record the hashing scheme so migration paths stay auditable.
Key technical specifications to document:
- Minimum salt length and generation method, using a cryptographically secure random source.
- Unicode normalization (NFC) applied before hashing, so the same password typed on different devices produces the same verifier.
- Maximum length support of at least 64 characters, with no truncation that silently weakens long passphrases.
- Blocklist checks run against the entire submitted string, not substrings, to avoid false positives on legitimate long passphrases.
Password managers depend on your login forms supporting paste and autofill. Blocking paste into password fields is a common usability mistake that pushes people toward weaker, memorable passwords. Rate-limit failed login attempts and log verification events over protected channels so you have evidence of enforcement when an auditor asks.
Pro Tip: Never hash with unsalted SHA-256 or SHA-1 alone. These algorithms are fast by design, which makes them easy to brute-force at scale once a database leaks; use a dedicated password hashing algorithm instead.
Reconciling ISO 27001 with NIST and CISA guidance
ISO 27001 tells you to be risk-based; it does not tell you which number to pick. NIST SP 800-63B fills that gap with concrete operational guidance that auditors increasingly expect to see referenced.
- NIST sets a minimum of 15 characters for single-factor secrets and 8 characters when the password is one factor in MFA.
- NIST forbids arbitrary composition rules (mandatory symbols, forced capitals) and periodic rotation except after evidence of compromise.
- NIST requires blocklist screening against commonly used and previously breached passwords.
- CISA guidance on phishing-resistant MFA ranks FIDO/WebAuthn and PKI-based authenticators as the strongest defense, with SMS codes as the weakest form.
The practical reconciliation is straightforward: use your ISO 27001 risk assessment to justify adopting NIST’s specific thresholds as your organization’s chosen controls, and record CISA’s MFA guidance as the basis for prioritizing phishing-resistant methods on your highest-risk systems. Reference both documents by name in your policy’s supporting rationale so the audit trail connects your risk decision to a recognized external standard.
Keeping password rules usable without weakening security
A policy that frustrates people invites workarounds like sticky notes and reused passwords. Encourage password managers explicitly in the policy text rather than treating them as a workaround, and make sure your login forms allow paste and autofill so the tools work as intended.
For situations where a system genuinely cannot meet the standard policy, build a short exception process:
- The system owner documents why the control cannot be applied and what compensating measure exists.
- A designated approver, typically the information security manager, reviews and signs off on the risk acceptance.
- The exception is logged with a review date, no longer than twelve months out, to confirm it is still necessary.
Train staff on why the rules exist, not just what they are, and monitor for circumvention such as shared accounts or disabled MFA. Escalate repeated violations through your existing incident process rather than handling them informally.
Pro Tip: Treat every approved exception as a temporary risk acceptance, not a permanent carve-out. Review it on a fixed schedule or it will quietly become the default.
An implementation checklist for your next audit
Auditors respond well to evidence that is organized before they ask for it. Work through this order:
- Finalize the password and authentication policy document, referencing Annex A 5.17.
- Complete and file the authentication risk assessment.
- Export hashing configuration (algorithm, cost factor, salt handling) from your identity provider.
- Capture proof that blocklist checks are active, such as a rejected-password log sample.
- Build an MFA coverage matrix showing which systems use phishing-resistant methods versus weaker options.
- Collect training completion records tied to the password policy rollout.
Checklist artifacts worth keeping in your ISMS folder:
- Policy document with version history and approval date.
- Technical implementation notes for developers, including hashing library and parameters used.
- A sample rejected-password log entry showing the blocklist in action.
Pro Tip: Keep a single-page summary mapping each policy clause to its evidence file. This saves significant time when an auditor asks you to demonstrate a specific control.
For broader context on where this policy fits, see how password requirements connect to identity and access management in technology environments, and review the full ISO 27001 policy set to confirm your password policy references the related access control and backup policies correctly.
What implementers consistently get wrong
The most common audit finding I see is a policy that states a rule with no documented reason behind it, a fixed 90-day rotation with nothing tying it to risk. The fix is simple: write down why each control exists and what it protects against, not just the control itself. Reviewers respond well to that trail.
A ready template speeds this up considerably, and a readiness check can flag gaps in your authentication controls before an auditor does. Document your risk-based decisions as you make them, not after the fact.
— Martin
Get an estimate before you build your policy set
Writing a compliant password policy is one piece of a larger ISO 27001 project, and most teams underestimate how long the full policy set and technical rollout take.
You can find tools online that provide real-time, organization-specific estimates of the cost and effort involved in ISO 27001 implementation, factoring in company size, industry, and security maturity, with editable assumptions and benchmarking data. Start with the free 2-minute readiness check to see where your authentication controls stand, or go straight to the ISO 27001 cost calculator for a full project estimate with traceable, versioned assumptions. Initial calculations can often be run without requiring signup.
FAQ
What are the NIST 800-63B password policy requirements?
NIST SP 800-63B requires a minimum of 15 characters for single-factor passwords and 8 characters when combined with another authentication factor, found in the full guidelines. It also forbids mandatory composition rules and periodic rotation unless there is evidence of compromise, and it requires blocklist screening against commonly breached passwords.
What are the NIST password guidelines for 2026?
The current guidance remains NIST SP 800-63B, which continues to favor length over complexity, blocklist checks over composition rules, and rotation only after a suspected compromise. Organizations should reference this version directly in their ISMS documentation rather than older composition-based standards.
What are the guidelines for password policy?
A sound policy sets a minimum length, screens new passwords against a blocklist, stores credentials as salted hashes, and avoids forced periodic changes except after compromise. It should also point users toward password managers and define when multi-factor authentication is required, following the structure in NIST SP 800-63B.
Why is SHA-256 not good for passwords?
SHA-256 is a general-purpose hashing algorithm designed to run fast, which makes it easier for an attacker with leaked hashes to try billions of guesses per second. Dedicated password hashing algorithms like bcrypt, scrypt, or Argon2 are intentionally slow and configurable, which raises the cost of a brute-force attack even if the database is stolen.
How does MFA affect password policy requirements?
Multi-factor authentication lowers the burden on the password itself, which is why NIST SP 800-63B allows shorter minimum lengths when a password is paired with another factor. CISA recommends prioritizing phishing-resistant methods like FIDO or WebAuthn over SMS codes, which should shape which systems get the strictest password rules versus relying more heavily on the second factor.
Sources
- Digital Identity Guidelines: Authentication and Authenticator Management (NIST SP 800-63B)
- NIST Special Publication 800-63-4: Digital Identity Guidelines
- Implementing phishing-resistant MFA (CISA fact sheet)