SOC 2 CC6.1 — Logical access security architecture

What SOC 2 CC6.1 requires

Logical access security architecture is one of 8 criteria in the Logical and Physical Access Controls (CC6) series of the Security (Common Criteria) category. Logical access security software, infrastructure, and architectures are implemented over protected information assets to restrict access to authorized users. CC6 is the heaviest-tested series in most SOC 2 reports and the one where exceptions most often appear — expect user access reviews, provisioning and deprovisioning tickets, and configuration exports to be sampled across the full period.

Audit evidence assessors look for

When preparing for a SOC 2 audit against CC6.1, gather artefacts such as:

Access control policy and RBAC design
Identity provider / SSO configuration
Network segmentation and firewall configuration
Inventory of protected information assets with classification

Points of focus for CC6.1

The Trust Services Criteria set out points of focus that describe what an auditor considers when assessing CC6.1. They are not themselves requirements, but they shape the testing:

Information assets are identified and classified so protection can be proportionate.
Access to those assets is restricted through authentication and authorisation infrastructure.
Points of access, including network segments and external connections, are identified and managed.
Encryption is used to protect information where appropriate.

How to implement CC6.1

Start from an asset inventory with classificationCC6.1 is written around protected information assets. If you cannot list them and say which are sensitive, nothing downstream is assessable. This inventory is also what scopes the rest of the CC6 series, so getting it wrong propagates.
Centralise authentication before refining authorisationAn identity provider with SSO gives you one place to enforce and one place to evidence. Organisations that try to demonstrate access control across twenty separately administered systems generate twenty times the evidence and twenty times the exceptions.
Document the RBAC design, then show the system matches itThe design document and the actual configuration export are two different pieces of evidence and auditors want both. Divergence between them is a finding even when the live configuration is more restrictive than documented.
Evidence network segmentation as architecture, not intentA diagram showing intended segments is not evidence. Firewall or security-group configuration exports demonstrating the boundaries actually exist is.
Cover non-human identitiesService accounts, API keys and machine identities are in scope and are routinely omitted. They typically have broad privilege, no owner, and no rotation — which makes them the highest-value thing to fix before an audit.

Common audit findings for CC6.1

What actually gets raised against CC6.1, in rough order of how often it comes up:

An asset inventory that omits SaaS applications holding customer data.
Service accounts with standing administrative privilege, no named owner and no rotation schedule.
Documented RBAC design that no longer matches the live configuration.
Systems outside SSO that were not disclosed during scoping and surface during testing.

Scoping CC6.1

CC6.1 is Common Criteria and applies to every SOC 2. It is the anchor of the most heavily tested series in the report — CC6 typically accounts for a large share of the total test procedures and the majority of exceptions. Evidence here also substantially satisfies ISO 27001 A.5.15 and A.8.3.

ISO 27001 mapping

CC6.1 corresponds to the following ISO 27001:2022 Annex A control(s): A.5.9, A.5.12, A.5.15, A.5.16, A.5.17, A.8.2, A.8.3, A.8.4, A.8.5, A.8.18, A.8.24. If you already run an ISO 27001 ISMS, map your existing evidence for these controls to CC6.1 rather than duplicating work.

Map CC6.1 to ISO 27001 & NIST CSF →

Crosswalk this criterion in the Control Mapper & Gap Assessment.

Document the risk →

Record treatment for gaps against CC6.1 in the Risk Register.

Other Logical and Physical Access Controls criteria

CC6.2 Provisioning and deprovisioning CC6.3 Role-based access and least privilege CC6.4 Physical access restriction CC6.5 Secure disposal CC6.6 Protection against external threats CC6.7 Protection of data in transmission and movement CC6.8 Prevention and detection of malicious software

All CC6 Logical and Physical Access Controls criteria →

Frequently asked questions

Is CC6.1 required for a SOC 2 report?

Yes. CC6.1 sits in the Common Criteria, which apply to every SOC 2 engagement regardless of which additional categories you scope in — there is no SOC 2 report that omits them.

How does an auditor test CC6.1?

In a Type 1 report the auditor assesses design only — does a control exist at a point in time that would meet CC6.1 if it operated. In a Type 2 report they also test operating effectiveness by sampling evidence from across the review period, typically 3 to 12 months. That difference is why Type 2 evidence has to be continuous rather than assembled the week before fieldwork.

What happens if CC6.1 fails testing?

A control that fails becomes an exception, which the auditor describes in the report along with management's response. Exceptions do not automatically make a report "failed" — a SOC 2 report is an opinion, not a pass/fail certificate — but a qualified opinion is what customers notice, so remediate and re-test before fieldwork closes where you can.

Does SOC 2 CC6.1 map to ISO 27001?

Yes — CC6.1 aligns with ISO 27001:2022 Annex A control(s) A.5.9, A.5.12, A.5.15, A.5.16, A.5.17, A.8.2, A.8.3, A.8.4, A.8.5, A.8.18, A.8.24. If you already run a certified ISMS, re-point that evidence rather than building a parallel set; the underlying control is the same and only the reporting format differs.

What are the most common audit findings for CC6.1?

An asset inventory that omits SaaS applications holding customer data. Service accounts with standing administrative privilege, no named owner and no rotation schedule.