When the median time between initial compromise and operator access is just 22 seconds, your identity controls can't wait for the next audit cycle. This checklist helps you verify that your identity governance program meets both SOC 2 Trust Services Criteria CC6.1-CC6.3 and ISO/IEC 27001:2022 controls in Annex A 5.15-5.18 (access control), while addressing the attack paths that auditors increasingly scrutinize.
Use this to prepare for your next assurance engagement or to close gaps your lead auditor flagged in the last cycle.
Prerequisites
Before working through this checklist, confirm you have:
- Defined system boundaries: Your scope statement clearly identifies which systems, applications, and infrastructure components are in scope for access control requirements.
- Assigned control ownership: Someone owns identity governance as a documented responsibility (ISO/IEC 27001:2022 clause 5.3 requires assigned roles and authorities).
- Baseline policy documentation: You've documented an access control policy that addresses user lifecycle management, privilege assignment, and review requirements.
If you're missing these, stop here. The checklist items below assume these foundations exist.
Identity Inventory and Visibility
☐ 1. Maintain a complete identity inventory across all identity types
Your inventory must include human users, service accounts, machine identities, API keys, and any AI-agent identities with system access. Document the authoritative source for each identity type.
Good looks like: A single source of truth (CMDB, identity governance platform, or maintained registry) that an auditor can query to see every identity with access to in-scope systems. No "we think there are some service accounts in that environment" responses.
☐ 2. Map identity ownership to business or technical owners
Every identity in your inventory links to a responsible party who can justify its existence and privilege level.
Good looks like: When your auditor samples 25 identities, you produce the owner's name and role within two business days. No orphaned accounts with "former employee" or "unknown" as the owner.
☐ 3. Document privilege levels and entitlements for each identity
Record what each identity can access, what actions it can perform, and whether those privileges are standing or time-bound.
Good looks like: For any sampled identity, you can show a current entitlement report that lists systems accessed, permission levels, and business justification. This satisfies SOC 2 CC6.2 (logical access controls are designed to prevent unauthorized access).
Access Control Implementation
☐ 4. Implement least privilege assignment with documented justification
New access requests require business justification. Default access is read-only or no access until a specific need is documented.
Good looks like: Your access request tickets show who requested access, who approved it, what business function requires it, and when it was granted. Auditors testing CC6.1 (access authorization) will sample these tickets.
☐ 5. Enforce segregation of duties for sensitive functions
Conflicting privileges (such as code commit rights plus production deployment rights, or payment initiation plus payment approval) cannot coexist in a single identity without compensating controls.
Good looks like: A documented Segregation of Duties Policy with a matrix showing incompatible roles, plus evidence that your identity system flags or blocks conflicting assignments. This directly addresses ISO/IEC 27001:2022 Annex A 8.2 (privileged access rights).
☐ 6. Configure multi-factor authentication for privileged and remote access
MFA is active and enforced (not optional) for administrative access, remote access, and access to systems processing sensitive data.
Good looks like: Authentication logs showing MFA challenges and successful validations. Configuration screenshots proving MFA cannot be bypassed. This supports both CC6.1 and ISO/IEC 27001:2022 Annex A 5.17 (authentication information).
Access Review and Monitoring
☐ 7. Conduct periodic access reviews at defined intervals
Reviews occur quarterly for privileged access, at least annually for standard access. Reviews cover entitlements, not just account existence.
Good looks like: Completed review reports showing which identities were reviewed, who performed the review, what changes resulted, and sign-off from business owners. ISO/IEC 27001:2022 clause 9.2 (internal audit) and SOC 2 CC6.3 both require evidence of periodic review.
☐ 8. Revoke access promptly when employment or business need ends
Termination workflows trigger immediate access revocation. Role changes trigger access recertification within your defined timeline (commonly 24-48 hours for terminations, 7 days for role changes).
Good looks like: HR system integration logs showing termination dates, corresponding IAM system logs showing access revocation, and no gap exceeding your policy threshold. Auditors will correlate HR termination dates with access revocation timestamps.
☐ 9. Monitor for excessive privileges and dormant accounts
You run regular reports identifying accounts with privileges beyond their role requirements, plus accounts with no activity in the past 90 days.
Good looks like: Monthly or quarterly reports showing accounts flagged for excessive privilege or inactivity, with documented remediation actions. This is where identity security posture management tools provide audit value.
Identity Threat Detection
☐ 10. Implement logging for authentication and authorization events
All authentication attempts, authorization decisions, and privilege escalations generate logs retained per your policy (commonly 90 days minimum for SOC 2, one year for ISO/IEC 27001:2022 Annex A 8.15).
Good looks like: Log samples showing successful and failed authentication, timestamp, source IP, and identity involved. Your SIEM or log aggregation tool can produce these on demand.
☐ 11. Define and monitor for suspicious identity activity
You've documented what constitutes suspicious activity (such as impossible travel, unusual access patterns, after-hours privileged access) and configured alerts.
Good looks like: Alert rules in your SIEM or identity threat detection and response platform, plus evidence that alerts generate tickets in your incident response queue. When auditors ask "how would you detect credential compromise?", you show them the alert rule and a sample ticket.
Common Mistakes
Treating service accounts as an afterthought: Auditors increasingly focus on machine identities because attackers do. If you can't produce a complete service account inventory with ownership and privilege documentation, expect a finding.
Confusing access review with account existence verification: Confirming an account still exists isn't a review. Reviews must verify that current entitlements still match business need.
No documented risk prioritization for remediation: When your access review identifies 200 excessive privilege assignments, auditors want to see how you prioritized remediation. "We're working on it" without a risk-based Risk Treatment Plan suggests weak governance.
Missing the connection between identity controls and attack path analysis: Your auditor may not ask "how do attackers exploit identity blind spots?", but your incident response plan should show you've considered it. Document how you identify and connect identity weaknesses that could create exploitable paths.
Next Steps
After completing this checklist:
- Document gaps as nonconformities if you're maintaining ISO/IEC 27001:2022, or as control deficiencies if you're in a SOC 2 cycle.
- Build a Risk Treatment Plan for any gaps that could enable unauthorized access or privilege escalation.
- Schedule remediation based on risk severity, not convenience.
- Update your internal audit program to verify these items quarterly, not just before external assessments.
Your identity governance program isn't audit-ready when you can answer auditor questions. It's ready when you can demonstrate continuous visibility, control, and remediation of identity risk.
