Introduction
CC6.1 is the first criterion in the logical and physical access group of the SOC 2 Trust Services Criteria. In plain terms, it asks whether the entity uses logical access security software, infrastructure, and architectures to protect its information assets from security events.
This guide explains what CC6.1 is about and what evidence teams commonly keep for it. It is a general explanation, not a statement of what your auditor will require. Your control descriptions and your auditor's test attributes decide what must be shown. See the AICPA's published Trust Services Criteria for the authoritative wording.
Related reading: Role-Based Access Control Evidence for SOC 2 and How to Run a SOC 2 User Access Review.
What CC6.1 Is Getting At
CC6.1 is about the mechanisms that restrict who can reach systems and data. Typical themes include:
- Identifying and authenticating users before they get access
- Restricting access based on role and least privilege
- Protecting access paths with controls such as multi-factor authentication
- Keeping an inventory of the systems and information assets in scope
Provisioning, review, and removal of access are usually covered by neighboring criteria, so teams often present them together. See Onboarding and Offboarding Evidence for SOC 2.
Evidence Examples
| Control area | Example evidence | Point-in-time or period |
|---|---|---|
| Authentication | Identity provider settings showing MFA enforcement | Both: setting now, logs or checks over the period |
| Role design | Role catalog and the permissions each role grants | Point in time, with change history |
| Access lists | Exported user and role lists for in-scope systems | Dated exports across the period |
| Privileged access | List of administrators and approval records | Period, see Privileged Access Management Evidence for SOC 2 |
| Asset scope | Inventory of in-scope systems | Dated snapshots |
See also point-in-time vs period-of-time evidence.
How Auditors Typically Test It
For a Type 2, auditors often inspect configuration and then request a population of access changes for the audit period and pick an audit sample. Each sampled item should trace to an approval and the resulting access. The exact approach depends on your auditor.
Common Gaps
- Screenshots of settings with no history behind them
- Role catalogs that do not match what systems actually grant
- Shared or generic accounts with no owner
- Access exports taken once and never refreshed
- Missing approvals for sampled access grants
Pre-Audit Checklist
- Every in-scope system has an owner and a known authentication method
- MFA enforcement is documented with dated evidence
- Role definitions match actual permissions
- Administrator accounts are listed and justified
- Access lists are exported on a regular schedule and retained for the full period
- Open gaps are tracked as possible control deviations
How AuditFlo.co Helps
AuditFlo.co helps teams retain continuous evidence collection and audit-period history from connected systems, which can make dated access records easier to assemble. AuditFlo.co does not issue SOC 2 reports, does not certify compliance, and does not replace your auditor.
To see the workflow for your stack, request a demo.
Key Takeaway
CC6.1 comes down to showing that access to your systems is restricted and that the restrictions held across the whole period. Keep dated records, match roles to real permissions, and confirm retention before fieldwork.