SOC 2's CC6 criteria cover logical and physical access. Practical controls include a central identity provider with MFA, approved joiner and leaver processes, role based access, network boundary rules, encryption and data transfer limits, and controls against unauthorized software. This guide goes through CC6.1 to CC6.8 with ideas for each.
How should you read the criteria?
We read the AICPA 2017 Trust Services Criteria with the 2022 points of focus. The criteria state outcomes, not tools, and auditors accept different designs if you can explain why they meet the intent. Below we paraphrase the intent and offer ideas that tend to be easy to evidence.
CC6.1: logical access security
The intent is software, infrastructure and architecture that protect information assets, and the points of focus include an inventory of assets. Ideas: an asset and system list with owners and classification, SSO through one identity provider, MFA, strong authentication for admin consoles, encryption at rest, network segmentation between production and corporate, and secrets stored in a vault.
CC6.2: registration and authorization of users
The intent is to authorize new users before credentials are issued, and to remove credentials when access is no longer authorized. Ideas: ticketed access requests with owner approval, groups tied to roles, automated provisioning from HR data where you can, and a leaver process with a same day target that covers service accounts and API keys.
CC6.3: role based access, least privilege, segregation of duties
The intent is to authorize, change and remove access based on role, considering least privilege and segregation of duties. Ideas: a role matrix, separate admin and daily accounts, just in time elevation, a rule that the author of a change cannot approve it, and quarterly access reviews with recorded removals.
CC6.4: physical access
The intent covers restricting physical access to facilities and assets. For a cloud hosted company, most of this is inherited from your hosting provider, so collect their latest assurance report and document the carve out. For offices, keep a visitor log, badge or key control, and secure device storage.
CC6.5: disposal
The intent is to discontinue protections on physical assets only after data cannot be recovered. Ideas: a device wipe and return process, certificates of destruction from a vendor, and checks that departing staff return laptops.
CC6.6: threats from outside the boundary
The intent is protection against threats from sources outside the system boundary. Ideas: default deny firewalls and security groups, a web application firewall where relevant, VPN or zero trust access for admin paths, rate limiting, DDoS protection from your provider, and regular external scans.
CC6.7: transmission and movement of data
The intent is to restrict who can transmit, move or remove information and to protect it in transit. Ideas: TLS everywhere with enforced minimum versions, encrypted backups, restrictions on bulk export and removable media, data loss prevention rules for key data, and logged approvals for customer data exports.
CC6.8: unauthorized or malicious software
The intent is to prevent or detect unauthorized or malicious software. Ideas: endpoint protection, restrictions on installing software, protected branches and reviewed changes, dependency and container scanning, signed artifacts, and alerts on unexpected changes in production.
What evidence should you keep?
Asset list, identity provider settings, role matrix, sample joiner and leaver tickets, access review records, firewall exports, hosting provider reports, encryption settings, endpoint console coverage, scan results and change approvals, all dated.
Mistakes to avoid
- Counting SSO as done while a few admin consoles use local passwords.
- Reviews that confirm everything without a single change.
- Forgetting service accounts.
- Assuming the hosting provider covers CC6.4 without collecting its report.
What to do
- Build the asset list and name owners.
- Enforce SSO and MFA, and list exceptions.
- Publish the role matrix and run ticketed joiner and leaver processes.
- Complete an access review each quarter.
- Export boundary rules and encryption settings.
- Collect provider reports for physical controls.
- Cover software controls in endpoints, repositories and pipelines.
Quick check
Does CC6 require SSO?
No criterion names SSO or MFA. They are common designs that make CC6.1 to CC6.3 easy to evidence.
How do cloud companies handle CC6.4?
Usually by relying on the hosting provider's physical controls, collecting its assurance report and documenting the carve out, while covering your own offices and devices.
How Safeguard helps automate this
Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously between audits. For CC6, that covers access lists, settings and review records that otherwise get captured by hand.
Technical evidence comes from your real code and dependencies, through scans, SBOMs and reachability, which supports CC6.8 on unauthorized or malicious software. Safeguard's agent can open tested fix pull requests for vulnerable dependencies and other findings. It is off by default, every category starts on Manual, and you choose which categories run automatically and set the approval level. The examination is done by an independent CPA firm. Safeguard helps prepare and keep evidence ready, and does not guarantee a result.
See it at /demos/framework-mapping.
Want to see it on your own stack? Book a call.
Sources
Last reviewed: 18 October 2026.
