Auditing ISO 27001 Annex A 5.17 Authentication Information involves verifying the secure allocation, management, and revocation of secret authentication data. This process validates the Primary Implementation Requirement of protecting passwords, tokens, and biometrics through a formalised lifecycle. The Business Benefit mitigates the risk of credential theft and unauthorized access by ensuring robust secrets management.
This technical verification tool is designed for lead auditors to confirm the integrity of secrets management across the organisational estate. Use this checklist to validate compliance with ISO 27001 Annex A 5.17 (Authentication information) by ensuring that passwords, tokens, and biometric data are handled through a secure and formalised lifecycle.
1. Authentication Information Management Policy Verified
Verification Criteria: A formalised policy exists that defines the requirements for the allocation, management, and revocation of authentication secrets, including specific rules for complex passwords and multi-factor authentication.
Required Evidence: Approved Access Control Policy or dedicated Authentication Management Standard with version history and management sign-off.
Pass/Fail Test: If the policy does not explicitly define requirements for temporary authentication information (e.g. initial setup passwords), mark as Non-Compliant.
2. Secure Initial Allocation of Secrets Confirmed
Verification Criteria: The process for issuing temporary authentication information (initial passwords) ensures that the information is sent via a secure, out-of-band channel and is forced to change upon first use.
Required Evidence: System configuration screenshots showing “User must change password at next logon” is enabled for new accounts and logs of secret delivery (e.g. encrypted SMS or secure portal).
Pass/Fail Test: If temporary passwords are sent in clear-text via email or are not forced to change immediately, mark as Non-Compliant.
3. Personnel Guidance on Secure Handling Validated
Verification Criteria: Users are formally advised on their responsibilities for keeping authentication information confidential and are prohibited from sharing secrets.
Required Evidence: Staff training records, signed Acceptable Use Policy (AUP), or periodic security awareness newsletters covering secret protection.
Pass/Fail Test: If an interviewee cannot identify the organisation’s official policy regarding password sharing or “post-it note” storage, mark as Non-Compliant.
4. Technical Password Complexity Enforcement Verified
Verification Criteria: Technical controls are in place to enforce minimum password length, complexity (special characters/numbers), and the blocking of commonly used or breached passwords.
Required Evidence: Password Policy configuration reports from Active Directory, Entra ID, or relevant LDAP services.
Pass/Fail Test: If the system allows the setting of passwords shorter than 8 characters or lacks a “breached password” blacklist, mark as Non-Compliant.
5. Secure Storage of Authentication Information Confirmed
Verification Criteria: Authentication secrets are never stored in clear-text; they must be protected using modern cryptographic hashing and salting techniques.
Required Evidence: Database schema documentation or technical specification from the software vendor confirming the use of salted hashes (e.g. Argon2, bcrypt, or PBKDF2).
Pass/Fail Test: If authentication secrets are found stored in unencrypted spreadsheets, text files, or clear-text database columns, mark as Non-Compliant.
6. Multi-Factor Authentication (MFA) Implementation Validated
Verification Criteria: MFA is enforced for all remote access, privileged accounts, and access to sensitive systems to provide an additional layer of verification beyond passwords.
Required Evidence: Conditional Access Policy logs or system settings showing MFA is “Enforced” or “Required” for the ISMS scope.
Pass/Fail Test: If administrative access to cloud consoles or VPNs is possible using only a single-factor password, mark as Non-Compliant.
7. Default Manufacturer Password Remediation Verified
Verification Criteria: All default passwords provided by manufacturers for hardware and software (e.g. routers, databases, IoT devices) are changed before the systems are moved to production.
Required Evidence: Asset hardening checklists or configuration audit logs for new infrastructure showing non-default credentials.
Pass/Fail Test: If any network device is found with a default credential (e.g. admin/admin) still active, mark as Non-Compliant.
8. Management of Privileged Authentication Secrets Confirmed
Verification Criteria: Privileged secrets (e.g. Root or Domain Admin passwords) are managed through a secure vaulting system with restricted access and audit logging.
Required Evidence: Access logs from a Privileged Access Management (PAM) tool showing check-in/check-out of administrative credentials.
Pass/Fail Test: If privileged secrets are known by multiple people and are not rotated or vaulted, mark as Non-Compliant.
9. Authentication Revocation for Terminated Personnel Verified
Verification Criteria: Authentication information is immediately revoked or disabled upon the termination of a contract or employment to prevent unauthorised access.
Required Evidence: Cross-reference of HR leaver logs against account “Disabled” timestamps in the primary identity provider.
Pass/Fail Test: If a leaver’s authentication credentials remain active more than 24 hours post-termination, mark as Non-Compliant.
10. Biometric Data Privacy and Protection Validated
Verification Criteria: If biometric authentication is used, the raw biometric data is not stored; instead, a secure mathematical template must be used and stored locally/encrypted.
Required Evidence: Data Privacy Impact Assessment (DPIA) or technical architecture diagram confirming that raw biometrics (e.g. fingerprints) are not transmitted or stored centrally.
Pass/Fail Test: If raw biometric images are stored on a central server or lack a corresponding DPIA, mark as Non-Compliant.
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Initial Allocation | GRC tool identifies that a “New Joiner” ticket was closed. | The auditor must verify *how* the secret was sent. If the password was put in the Jira ticket description, the control has failed. |
| Password Complexity | Tool records “M365 Default Policy” is active. | Check the *exceptions*. GRC tools often miss accounts added to “exclusion groups” where MFA and complexity are disabled. |
| Secure Storage | Tool confirms that the database uses encryption at rest. | Encryption at rest is not enough for secrets. You must verify that the application layer hashes the password *before* it reaches the DB. |
| Staff Awareness | SaaS platform shows 100% completion on a generic “Cyber Awareness” course. | Ask a staff member how they store passwords. If they mention a browser’s “save password” feature on an unmanaged device, the training is ineffective. |
| Default Credentials | GRC tool assumes all SaaS apps are managed by the vendor. | Manually audit physical hardware (printers/routers). GRC tools rarely “see” local administrative passwords on office hardware. |
| Privileged Access | Tool identifies that an “Admin” role exists. | Check the rotation. A real auditor demands evidence that the Domain Admin password has been rotated in the last 90 days. |
| Revocation | Tool checks if an account is “Disabled”. | Verify “Active Sessions”. Disabling an account often doesn’t kill an existing OAuth token, allowing the user to stay logged in. |
About the author
