ISO 27001 Operations: Password Rotation Procedures

Annex A.12 (Operations Security) is the operational backbone of ISO 27001:2022. While Annex A.9 tells you who should have access and Annex A.10 tells you how to encrypt, A.12 governs the day-to-day procedures — password rotation schedules, change management for credential systems, and capacity planning for authentication infrastructure.

In our work helping UK enterprises achieve and maintain ISO 27001 certification, Annex A.12 generates the most non-conformities during surveillance audits — not because requirements are unclear, but because organisations treat them as a one-time implementation rather than an ongoing operational discipline.

Control 8.6: Password Change Management

The ISO 27001:2022 revision introduced Control 8.6 under Annex A.8 (Asset Management), but its operational implications for password management fall squarely within A.12's domain. The key requirements are:

• Documented change management procedure: Any modification to password storage infrastructure — switching hashing algorithms, rotating master encryption keys, updating identity provider configurations — must follow a formal change management process.
• Change approval: No change to password-related systems can be implemented without documented authorisation. This includes emergency changes (e.g., rotating a compromised admin credential).
• Rollback procedure: Every password system change must have a tested rollback plan. If a key rotation fails, you must be able to revert within defined RTOs.

The 2022 revision of ISO 27001 places particular emphasis on operational procedures for cloud-based identity providers. If you use Azure AD, Okta, or AWS IAM for enterprise credential management, each platform's password rotation and change management capabilities must be documented in your Statement of Applicability (SoA).

Password Rotation Schedules Under ISO 27001

The 2022 revision removed the old requirement for mandatory periodic password changes (the 90-day rotation rule that NIST also abandoned in SP 800-63B). However, this does not mean ISO 27001 ignores password rotation entirely. Here is what A.12 actually requires:

• Rotation on suspicion of compromise: Passwords must be rotated immediately upon any indication of compromise. The operational procedure for emergency credential rotation must be documented and tested. This is a mandatory control under A.12.6.1 (Management of Technical Vulnerabilities).
• Service account rotation: Service accounts, API keys, and system-level credentials must have defined rotation intervals (typically 90-180 days). These are high-risk credentials because they often have elevated privileges and are rarely monitored.
• Privileged account rotation: Administrator passwords must be rotated after each use (check-in/check-out model) or at minimum every 30 days. This aligns with the NCSC's privileged access guidance for UK public sector organisations.
• User password rotation: Optional — only required when there is evidence of compromise or when a user leaves the organisation. The ISO 27001 auditor will accept a policy of "rotate on suspicion only" as long as it is documented.

The Ponemon Institute's 2026 Cost of a Breach study found that organisations with automated service account rotation reduced the average breach lifecycle by 67 days compared to those with manual rotation processes. This data point is worth citing during your ISO 27001 audit to justify automated rotation investment.

A.12.4: Logging and Monitoring for Password Events

Annex A.12.4 requires event logging for all operational security activities. For password management, this translates to:

• Successful and failed password changes — every password reset or change must be logged with timestamp, user ID, source IP, and outcome
• Administrative credential usage — every use of a privileged account must be logged and reviewed at least weekly
• Anomalous authentication patterns — logs must be monitored for mass password reset events, off-hours credential changes, and geolocation anomalies
• Log retention — password-related logs must be retained for a minimum of 12 months (or longer if required by sector regulation like GDPR or PCI DSS)

From our audit experience, the most common A.12.4 finding is not a failure to log — it is a failure to review logs. An auditor will ask to see evidence of regular log reviews, not just that logs exist. Automated SIEM alerts with documented response procedures satisfy this requirement.

A.12.6: Technical Vulnerability Management for Credential Systems

Control A.12.6.1 requires organisations to actively manage technical vulnerabilities in all systems that handle credentials. This includes:

• Identity provider patching — your Okta, Azure AD, or LDAP infrastructure must be patched within the organisation's defined SLAs (typically 14 days for critical CVEs)
• Password database scanning — regular vulnerability scans of systems that store password hashes (Active Directory, SQL databases, password managers)
• Third-party dependency monitoring — if your authentication code uses libraries like bcrypt, Argon2, or OpenSSL, you must monitor for CVE disclosures and patch promptly
• Penetration testing — annual penetration tests must specifically test password storage and authentication systems. The tester should attempt to extract password hashes and verify that encryption controls are effective

Capacity Management for Authentication Infrastructure

Control A.12.1.3 (Capacity Management) is often overlooked in password system audits, but it is increasingly important. Password infrastructure must handle peak loads without degradation:

• Password reset requests during business hours (especially Monday mornings)
• Bulk password changes after a breach notification
• Authentication spikes during product launches
• Growth projections for user base over the next 12-24 months

Your auditor will ask for evidence of capacity monitoring — CPU, memory, and request throughput trends for your identity provider over the preceding 12 months. If you use a cloud-native identity solution (Azure AD, Auth0, Okta), the auditor will accept documented SLA evidence from the provider covering uptime and request throughput.

Separation of Development, Test, and Production

Control A.12.1.4 requires separation of development, testing, and production environments. For credential management, this means:

• No production passwords in test environments — test databases must use synthetic credentials, never real user passwords
• Separate AD/LDAP instances — development and production must use different directory services
• Different API keys — API credentials for dev, staging, and prod must be entirely separate

See our Enterprise Password Policy Audit Guide for the full checklist on separating credential environments.