CC6.1 Logical 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 adds: new system architectures are security-assessed before they go live; restricted components expressly include servers, storage, network elements, APIs and endpoints, with standard hardening applied; stronger authentication such as multifactor is used where the risk strategy calls for it; isolation may use zero trust designs and other techniques beyond network segmentation; cryptographic modules, algorithms, key lengths and designs suit the risk strategy; and, where confidentiality or privacy is in scope, access to confidential or personal information is limited to the purposes identified and to personnel who need it.
Source: SOC 2 (2017 Trust Services Criteria), CC6.1. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open SOC 2 (2017 Trust Services Criteria) in the compliance library.
These are criteria, not controls: you design controls that meet them, and which criteria are in scope follows the categories your report covers (Security always; Availability, Confidentiality, Processing Integrity and Privacy only if chosen). A Type 2 report tests that the controls operated across the period, so the evidence asked for is samples across that period, not one copy.
These are the artefacts auditors commonly ask for on this requirement, our guidance rather than text from the standard. Your assessor decides what is sufficient in your context, and asks for samples across the period when a report covers one.
system holds itEvidence a system already holds
- Identity provider configuration showing MFA and password policy · Identity provider / directory
- Inventory of service and system accounts with owners · Identity provider / directory
- Hardening baselines applied to servers, network devices, APIs and endpoints · Endpoint management (MDM / EDR)
periodic reviewEvidence produced at each review
- Security architecture review records for new systems before go-live · Identity provider / directory
governing documentDocuments that govern the control
- Asset inventory with classification for in-scope systems · Policy repository / GRC workspace
- Network diagrams showing segmentation or zero trust access policies for production · Policy repository / GRC workspace
- Encryption-at-rest configuration, approved algorithms and key lengths, and key management procedure · Policy repository / GRC workspace
First move
Common gaps auditors find
- Service accounts and API keys outside the access management process
- Production network flat with no segmentation
- Encryption keys stored alongside the data they protect
- New platforms deployed with no prior security architecture review
- Access to confidential or personal data broader than the stated purpose
Do this for your whole sheet
Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.
Build my evidence sheetCC5.3 Deploying controls through policies and procedures (COSO principle 12) · CC6.2 Registering and authorising users before issuing credentials