ISO/IEC 27001: what it asks of an account list
Annex A of ISO/IEC 27001:2022 sets the access controls an auditor reads an account list against: access control (A.5.15), identity management across the whole life cycle (A.5.16), authentication information (A.5.17), access rights granted, reviewed and withdrawn (A.5.18), privileged access rights (A.8.2), secure authentication (A.8.5) and logging (A.8.15). The Annex sets no number of days; the periods here are the ones you set.
When to tick it: tick it when the company runs an information security management system to ISO/IEC 27001.
Named, not quoted, beside it: Sarbanes-Oxley section 404 and the IT general controls over access to programs and data; the PCAOB auditing standard for an audit of internal control over financial reporting (AS 2201); ISO/IEC 27002:2022, the guidance behind each Annex A control.
Findings that cite it
ISO/IEC 27001: every clause cited
7 of the 93 heldThe requirement text is our statement of each clause, read against the copy we hold and cited to it; it is not the instrument verbatim.
ISO/IEC 27001 A.5.15Access control
Rules that govern both physical entry and logical access to information and associated assets are to be set and applied on the basis of business and information security requirements. Purpose (stated in ISO/IEC 27002:2022): ensures access to information and associated assets is authorized and unauthorized access is prevented. As an Annex A reference control, it is compared with the controls determined in risk treatment (6.1.3 c) and recorded in the Statement of Applicability as included or excluded, with the justification and implementation status (6.1.3 d); implementation guidance is ISO/IEC 27002:2022 5.15.
What an auditor asks to see: Statement of Applicability entry for control A.5.15, showing inclusion or justified exclusion, implementation status and the risks it treats; The topic-specific access control policy, approved and communicated, reflecting owner-defined business and security requirements; Access control rules or role models mapping entities (users, services, devices) to rights, consistent with classification; Evidence of a default-deny design in firewall rules, application roles and cloud IAM policies; Separation of request, approval and administration functions in the access management workflow
Where account lists usually fall short: The access control policy exists but is not reflected in actual system configurations; Default-allow rules persist in network or cloud environments; Non-human entities such as service accounts are left outside the access rules; Access rights are not aligned with classification, so sensitive data is broadly accessible
ISO/IEC 27001 A.5.16Identity management
Identities are to be managed throughout their whole life cycle. Purpose (stated in ISO/IEC 27002:2022): enables unique identification of people and systems accessing organizational assets and appropriate assignment of access rights. As an Annex A reference control, it is compared with the controls determined in risk treatment (6.1.3 c) and recorded in the Statement of Applicability as included or excluded, with the justification and implementation status (6.1.3 d); implementation guidance is ISO/IEC 27002:2022 5.16.
What an auditor asks to see: Statement of Applicability entry for control A.5.16, showing inclusion or justified exclusion, implementation status and the risks it treats; Identity management procedure covering creation, verification, activation, change, disablement and removal; Evidence that identities are verified against trusted documents before issue; A register of shared identities with the business justification and approval for each; A register of non-human identities (service accounts, machine identities) with segregated approval and an independent oversight record
Where account lists usually fall short: Generic shared accounts exist without documented justification or approval; Service accounts have no owner and no periodic oversight; Identities of leavers remain enabled for weeks because HR notifications are not integrated; The same person holds several identities in one directory, undermining accountability
ISO/IEC 27001 A.5.17Authentication information
A management process is to control how authentication information is allocated and managed, and it includes telling personnel how to handle such information properly. Purpose (stated in ISO/IEC 27002:2022): ensures proper entity authentication and prevents authentication process failures. As an Annex A reference control, it is compared with the controls determined in risk treatment (6.1.3 c) and recorded in the Statement of Applicability as included or excluded, with the justification and implementation status (6.1.3 d); implementation guidance is ISO/IEC 27002:2022 5.17.
What an auditor asks to see: Statement of Applicability entry for control A.5.17, showing inclusion or justified exclusion, implementation status and the risks it treats; Credential issuance procedure requiring identity verification before new, replacement or temporary credentials are provided; Evidence that initial credentials are unique, delivered over protected channels and changed at first use; Password policy and technical configuration showing length, complexity, reuse prevention, breached-password blocking and masked entry; Records of vendor default credentials being changed at installation
Where account lists usually fall short: Initial passwords are sent in clear text email or use a predictable pattern; Default vendor credentials remain on network devices or appliances; Shared account passwords are not changed when someone who knew them leaves; No check against known breached passwords is performed
ISO/IEC 27001 A.5.18Access rights
Access rights to information and associated assets are to be granted, reviewed, changed and withdrawn in line with the access control rules and policy the organization has set. Purpose (stated in ISO/IEC 27002:2022): keeps access to information and assets defined and approved against what the business needs. As an Annex A reference control, it is compared with the controls determined in risk treatment (6.1.3 c) and recorded in the Statement of Applicability as included or excluded, with the justification and implementation status (6.1.3 d); implementation guidance is ISO/IEC 27002:2022 5.18.
What an auditor asks to see: Statement of Applicability entry for control A.5.18, showing inclusion or justified exclusion, implementation status and the risks it treats; Access request records showing owner authorization, and management approval where required, before rights were activated; A central record of access rights per user identifier across logical and physical access; Periodic access review records including privileged access, with evidence that removals identified in the review were actioned; Leaver and mover reports showing timely removal or adjustment of rights, including keys, cards and subscriptions
Where account lists usually fall short: Access is cloned from a colleague's profile, carrying over excessive rights; Access reviews are rubber-stamped by managers without owner involvement; Physical access badges are not revoked on the same timeline as logical accounts; Temporary access granted for projects is never removed
ISO/IEC 27001 A.8.2Privileged access rights
The granting and use of privileged access rights are to be limited and managed. Purpose (stated in ISO/IEC 27002:2022): limits privileged access to authorized people, software components and services. As an Annex A reference control, it is compared with the controls determined in risk treatment (6.1.3 c) and recorded in the Statement of Applicability as included or excluded, with the justification and implementation status (6.1.3 d); implementation guidance is ISO/IEC 27002:2022 8.2.
What an auditor asks to see: Statement of Applicability entry for control A.8.2, showing inclusion or justified exclusion, implementation status and the risks it treats; An inventory of privileged accounts per system (operating systems, databases, applications, cloud consoles) mapped to named individuals; Authorization records for each privileged grant with approver, justification and expiry; Privileged access management configuration showing time-limited elevation, step-up authentication and session recording; Privileged access review records performed periodically and after organizational changes
Where account lists usually fall short: Administrators use their privileged account for email and web browsing; Shared generic administrator accounts are used with no individual accountability; Privileged rights are standing and never expire; Service accounts with administrative rights are excluded from reviews
ISO/IEC 27001 A.8.5Secure authentication
Secure authentication technologies and procedures are to be put in place, driven by the information access restrictions and the access control policy. Purpose (stated in ISO/IEC 27002:2022): ensures users and entities are securely authenticated when granted access to systems, applications and services. As an Annex A reference control, it is compared with the controls determined in risk treatment (6.1.3 c) and recorded in the Statement of Applicability as included or excluded, with the justification and implementation status (6.1.3 d); implementation guidance is ISO/IEC 27002:2022 8.5.
What an auditor asks to see: Statement of Applicability entry for control A.8.5, showing inclusion or justified exclusion, implementation status and the risks it treats; An authentication standard linking required authentication strength to information classification and system criticality; MFA configuration and coverage reports for critical systems, remote access and privileged access, including conditional or risk-based rules; Log-on configuration showing warning banners, generic error messages, lockout or throttling after failed attempts and masked password entry; Authentication logs recording successful and failed attempts, with alerting on suspected brute force
Where account lists usually fall short: MFA is enabled for some critical systems but legacy protocols allow bypass; Error messages reveal whether the username or the password was wrong; No lockout or rate limiting exists on internet-facing log-on pages; Biometric authentication has no fallback method
ISO/IEC 27001 A.8.15Logging
Logs recording activity, exceptions, faults and other events of interest are to be generated, kept, protected and analysed. Purpose (stated in ISO/IEC 27002:2022): records events, generates evidence, protects log integrity, identifies security events and supports investigations. As an Annex A reference control, it is compared with the controls determined in risk treatment (6.1.3 c) and recorded in the Statement of Applicability as included or excluded, with the justification and implementation status (6.1.3 d); implementation guidance is ISO/IEC 27002:2022 8.15.
What an auditor asks to see: Statement of Applicability entry for control A.8.15, showing inclusion or justified exclusion, implementation status and the risks it treats; The topic-specific logging policy defining purposes, events to be logged, fields captured, retention and protection; Log source inventory showing which systems send which event types to central logging or SIEM; Configuration evidence that logs are tamper-protected (append-only storage, hashing, restricted deletion) and that administrators cannot erase their own activity; SIEM correlation rules, use cases and alert tuning records, and evidence of regular log review
Where account lists usually fall short: Critical systems or cloud services are not sending logs to central collection; Administrators can delete or disable logging on systems they manage; Logs overwrite themselves when storage fills, losing evidence; Logs are collected but nobody analyses them until after an incident