Your auditor will ask for your privileged access inventory. If you can't produce one that covers both human administrators and service accounts, you're starting the engagement behind schedule.
This checklist guides you in building a complete privileged access inventory that satisfies ISO/IEC 27001 Clause 9.2 (internal audit) and SOC 2 CC6.1 (logical and physical access controls). It addresses what most organizations miss: the nonhuman identities that now outnumber your employees and the fragmented access grants scattered across cloud platforms, SaaS applications, and on-premise systems.
What This Checklist Covers
You'll inventory every identity with elevated permissions across your environment. This includes traditional admin accounts, API keys, service principals, OAuth tokens, CI/CD pipeline credentials, and machine identities. Security gaps exist across endpoints, cloud environments, SaaS applications, and third-party access, so your inventory must span all of these.
The checklist produces a documented register of privileged access for surveillance audits or readiness assessments. More importantly, it gives you visibility into paths to privilege that attackers actively target.
Prerequisites
Before you start, confirm you have:
- Administrative access to your identity provider (Okta, Azure AD, Google Workspace)
- Read access to your cloud tenants (AWS IAM, Azure subscriptions, GCP projects)
- API credentials for SaaS platforms where you manage user roles
- A stakeholder from each business unit who can confirm which service accounts their teams created
- Your ISMS scope statement (ISO/IEC 27001 Clause 4.3) or system description (SOC 2) to define boundaries
If you're working toward ISO/IEC 27001 certification, your Lead Auditor will expect this inventory to align with your asset register (Annex A 5.9) and access control policy (Annex A 5.15).
Privileged Access Inventory Checklist
1. Identify All Human Accounts with Administrative Rights
List every user account with elevated permissions in your directory services, operating systems, databases, and applications.
Done when: You have a spreadsheet with columns for username, system, permission level, business justification, and last review date. Aim for fewer than 5% of total users holding admin rights, with each entry including a named approver.
2. Document Service Accounts and Application Identities
Enumerate every service principal, managed identity, service account, and application registration across your environment.
Done when: Each nonhuman identity has a documented owner, purpose, credential rotation schedule, and scope of access. Ensure no shared service account passwords and store every credential in a secrets management system (reference Annex A 8.3 for ISO/IEC 27001).
3. Catalog API Keys and Access Tokens
Pull all API keys, personal access tokens, OAuth client secrets, and long-lived credentials from your platforms.
Done when: You know where each key is used, who created it, when it expires, and what permissions it grants. Set expiration dates on every token and avoid keys older than 90 days without documented business justification.
4. Map Cloud IAM Roles and Policies
Review IAM policies in AWS, Azure role assignments, and GCP IAM bindings to identify overly permissive grants.
Done when: You've flagged every identity with wildcard permissions, cross-account access, or the ability to modify security configurations. Ensure least-privilege assignments and no standing admin access without MFA enforcement (SOC 2 CC6.1).
5. Audit SaaS Application Admin Roles
Check admin and owner roles in your SaaS platforms: GitHub, Salesforce, Slack, Jira, your SIEM, your backup solution.
Done when: You have a list of who holds "Organization Owner," "Workspace Admin," or equivalent roles in each platform. Implement two-person integrity for critical platforms and document approval for each admin grant.
6. Review Third-Party and Vendor Access
Document every external identity with access to your systems: MSP accounts, support portal logins, vendor API integrations.
Done when: Each third-party account has a named sponsor, defined access period, and documented business need. Ensure time-bound access grants that expire automatically and separate credentials for each vendor (Annex A 5.19 for supplier relationships).
7. Verify Segregation of Duties Controls
Cross-check your privileged accounts against your Segregation of Duties policy to confirm no single identity can both initiate and approve critical transactions.
Done when: You've tested a sample of high-risk business processes and confirmed no user holds conflicting roles. Implement Technological Controls enforcing separation, not just policy documentation (SOC 2 CC6.3).
8. Test Credential Rotation and Expiration
Confirm that privileged credentials rotate on schedule and that unused accounts disable automatically.
Done when: You've validated that your password policy applies to admin accounts, service account credentials rotate per your policy, and dormant accounts deactivate after your defined threshold. Automate rotation for service accounts and ensure the process runs without manual intervention.
9. Document Access Review Procedures
Establish who reviews this inventory, how often, and what they're checking for.
Done when: You have a procedure that names the reviewer, specifies quarterly or semi-annual frequency, and defines the approval workflow. Provide evidence of completed reviews with documented decisions for each access grant (ISO/IEC 27001 Annex A 5.18).
10. Prepare Audit Evidence
Package your inventory with supporting evidence: access request tickets, approval emails, policy attestations, review sign-offs.
Done when: An external auditor can trace any privileged account back to its approval, understand its purpose, and verify it was reviewed. Organize a single folder containing the inventory, the access control policy, review logs, and approval records.
Common Mistakes
Stopping at human accounts. Nonhuman identities now represent the majority of privileged access in cloud-native environments. If you're only inventorying people, you're missing the attack surface.
Treating "service account" as a sufficient business justification. Your auditor will ask why the account exists, which application uses it, and who approved the access level. "For automation" doesn't answer those questions.
Forgetting SaaS platforms. Your GitHub organization admins can modify code that deploys to production. Your SIEM admins can delete security logs. These are privileged identities, even if they're not in Active Directory.
Skipping the review cadence. An inventory without a review procedure is a point-in-time snapshot. Your control operates when you review and recertify access on schedule (ISO/IEC 27001 Clause 9.2 requires you to audit this).
Ignoring paths to privilege. An account with permission to modify IAM policies can grant itself admin rights. An identity with access to your secrets manager can retrieve admin credentials. Map the indirect paths, not just the direct grants.
Next Steps
Run this checklist quarterly. After your first pass, you'll identify orphaned accounts, overprivileged service identities, and access grants with no documented owner. Remediate those, then establish the review cadence.
For ISO/IEC 27001, tie this inventory to your risk register. Privileged access represents a high-impact threat vector; your Risk Treatment Plan should address how you're reducing exposure.
For SOC 2, connect this work to your user access review control. Your auditor will sample privileged accounts and trace them through your approval and review process.
If you're managing access across fragmented environments, prioritize integration. A unified view of privileged identities across cloud, SaaS, and on-premise systems closes the security gaps that exist when you're defending with siloed tools. Paths to privilege remain valuable targets for attackers, which means your inventory must be comprehensive, current, and tied to active review controls.
