Who should own a person (employee), and which ISO/IEC 27001, SOC 2 and PCI DSS clauses apply?
The clauses the checker cites on a person (employee): ISO/IEC 27001 A.5.16, ISO/IEC 27001 A.5.18, SOC 2 CC6.2 and PCI DSS 8.2.1. Every clause it cites, across the seven regimes, is in the table below.
How the checker reads it
- It is a user account people sign in with: PCI DSS reads it under the user-account periods (8.2.6, 7.2.4, 8.3.9), never under 8.6.
- Its owner is its holder: the owner column, or the display name, or the account name itself, matched against the staff list.
- The type comes from your type column; when that is blank the checker reads the account name and labels the type assumed from the name, and any finding resting on it is read as a question by the reviewer.
Findings that can apply
7 of 14- 1. A leaver's own account is still enabled: Was this account disabled on the day the person left, and if not, what has it done since?
- 4. Dormant for more than the threshold: Is this account still needed, and if so by whom?
- 5. Privileged, and orphaned or dormant: Who holds these rights today, and do they still need them?
- 6. Password or key not changed within the period, or never: When was this credential last changed, and who knows it?
- 8. Credential stored in code, a config file or a script: Can this credential move into a vault, and who has read the file it sits in?
- 10. Not reviewed within the interval: Who reviews this account, and when is the next review due?
- 12. Created with no approval recorded: Where is the request and the approval for this account?
Clauses
10 cited| Regime | Clause |
|---|---|
| ISO/IEC 27001 | ISO/IEC 27001 A.5.16 Identity management |
| ISO/IEC 27001 | ISO/IEC 27001 A.5.18 Access rights |
| SOC 2 | SOC 2 CC6.2 Registering and authorising users before issuing credentials |
| PCI DSS | PCI DSS 8.2.1 Unique ID assigned to every user |
| NIST SP 800-53 | NIST SP 800-53 AC-2 Account Management |
| NIST SP 800-53 | NIST SP 800-53 PS-4 Personnel Termination |
| CIS Controls | CIS Controls 5.1 Establish and Maintain an Inventory of Accounts |
| CIS Controls | CIS Controls 6.1 Establish an Access Granting Process |
| CIS Controls | CIS Controls 6.2 Establish an Access Revoking Process |
| NIS2 | NIS2 Art. 21(2)(i) Human resources security, access control policies and asset management |
The first clause, set out
ISO/IEC 27001 A.5.16Identity managementIdentities 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
A line that reads as this type
the type column left blank, invented valuese1042 | | directory | | yes