SOC 2: what it asks of an account list

The SOC 2 common criteria CC6.1 to CC6.3 cover logical access: every kind of account in scope, including system and service accounts (CC6.1), registration and authorisation before credentials are issued and removal once access is no longer authorised (CC6.2), and access by role with least privilege and periodic review (CC6.3). The criteria set no number of days; the periods here are the ones you set.

When to tick it: tick it when the company is audited against the SOC 2 criteria.

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

Finding	Clause
1. A leaver's own account is still enabled	SOC 2 CC6.3 (every account type) SOC 2 CC6.2 (every account type)
2. Owner has left, or owner not recognised	SOC 2 CC6.2 (every account type)
3. No owner named, or a team named with no accountable person	SOC 2 CC6.1 (every account type)
5. Privileged, and orphaned or dormant	SOC 2 CC6.3 (every account type)
10. Not reviewed within the interval	SOC 2 CC6.2 (every account type) SOC 2 CC6.3 (every account type)
11. AI agent credential with no owner or no review	SOC 2 CC6.1 (every account type)
12. Created with no approval recorded	SOC 2 CC6.2 (every account type)

SOC 2: every clause cited

3 of the 61 held

The requirement text is our statement of each clause, read against the copy we hold and cited to it; it is not the instrument verbatim.

SOC 2 CC6.1Logical access security over protected information assets

Access security software, infrastructure and architecture are in place over protected information assets to guard them against security events. Points of focus: information assets are inventoried, classified and managed; logical access to hardware, data at rest, in processing and in transit, software, admin rights, mobile devices, output and offline components is limited through access control software and rules; users, devices and software prove who they are before they get in, locally or remotely; networks are segmented so unrelated parts are isolated; external points of access and the data and users passing through them are inventoried and managed; access rules combine classification, data separation, port and protocol limits, identity and certificates; identification and authentication requirements are defined and managed; new infrastructure and software are registered and authorised before receiving credentials, which are removed when no longer needed; encryption protects data at rest where risk warrants; and keys are protected from generation to destruction. The 2022 revision stresses covering the whole architecture, all relevant infrastructure and tooling, and every kind of access including employees, contractors, vendors, partners, and system and service accounts.

What an auditor asks to see: Asset inventory with classification for in-scope systems; Identity provider configuration showing MFA and password policy; Network diagrams showing segmentation of production; Encryption-at-rest configuration and key management procedure; Inventory of service and system accounts with owners

Where account lists usually fall short: Service accounts and API keys outside the access management process; Production network flat with no segmentation; Encryption keys stored alongside the data they protect

Source: SOC 2 (Trust Services Criteria, common criteria)

SOC 2 CC6.2Registering and authorising users before issuing credentials

Before system credentials are issued and access is granted, internal and external users whose access the organisation administers are registered and authorised; their credentials are removed once their access is no longer authorised. Points of focus: credentials to protected assets are created only on authorisation from the asset owner or an authorised custodian; access is removed when a person no longer needs it; and credentials are reviewed periodically for people who should not hold them.

What an auditor asks to see: Access request tickets with owner approval for a sample of new users; Termination records reconciled to account disablement dates; Periodic user access review sign-offs with remediation of findings

Where account lists usually fall short: Accounts created without a recorded approval; Leavers retaining active accounts days or weeks after departure; Access reviews performed but inappropriate access not removed

Source: SOC 2 (Trust Services Criteria, common criteria)

SOC 2 CC6.3Role-based access, least privilege and segregation of duties

Rights over data, programs, functions and other protected assets is granted, changed or removed according to roles, responsibilities or system design and changes, applying least privilege and segregation of duties. Points of focus: access is created or modified on the asset owner's authorisation; it is removed when no longer needed; role-based access control separates incompatible functions; and roles and access rules are reviewed periodically and adjusted.

What an auditor asks to see: Role definitions and role-to-permission matrix; Change-of-role tickets showing old access removed; Privileged access list and review evidence; Segregation of duties rules, for example developers cannot deploy to production unaided

Where account lists usually fall short: Role changes add access without removing the old; Broad administrator rights assigned by default; Role definitions never reviewed

Source: SOC 2 (Trust Services Criteria, common criteria)