SOC 2 CC6.1: Logical Access Security Software, Infrastructure, and Architectures

SOC 2 CC6.1 is the foundational access control criterion in the Trust Services Criteria: it requires an organization to implement logical access security software, infrastructure, and architectures over protected information assets. It anchors the CC6 series (Logical and Physical Access Controls), carries the largest set of points of focus in the series, and is where auditors evaluate identity, authentication, network segmentation, and encryption as one connected system.

What does SOC 2 CC6.1 require?

In plain terms, CC6.1 asks whether access to systems and data is deliberately designed and technically enforced. The criterion covers the full technical stack of access control: the software that authenticates users, the infrastructure that hosts identities and credentials, and the architecture decisions (segmentation, access paths, encryption) that limit what an authenticated identity can reach.

CC6.1 is intentionally technology-neutral. It does not mandate a specific identity provider, MFA on every system, or a particular encryption algorithm. What it requires is that the controls in place are appropriate to the organization's risk, documented, and demonstrable. A two-person IT team with a maintained access spreadsheet and enforced MFA can satisfy CC6.1; a 500-person company with an unmanaged identity sprawl cannot.

Scope matters as much as controls. CC6.1 applies to the systems and data relevant to the audited service, and auditors focus on who has access to production and product-related systems rather than blanket organizational coverage. The SOC 2 scoping guide covers how the system boundary is drawn.

What are the CC6.1 points of focus?

The AICPA defines 11 points of focus for CC6.1 that apply to all engagements, plus one additional point each for engagements that include the Confidentiality and Privacy categories. Because the Trust Services Criteria are AICPA copyrighted material, the points of focus below are paraphrased and grouped by theme rather than reproduced verbatim; consult the official TSC document for exact wording.

• Asset inventory and architecture. Information assets (infrastructure, software, data) are identified, classified, and managed, and new system architectures are assessed for security before they enter the environment.
• Access restriction. Logical access to infrastructure, software, and data is restricted through access control software, rule sets, and hardened standard configurations, with access rules built from data classification, port and protocol restrictions, and user identification.
• Identity and authentication. People, infrastructure, and software are identified and authenticated before accessing assets, with stronger techniques such as multifactor authentication applied where the risk warrants it, and identification requirements documented and managed.
• Points of access. External entry points, the data flowing through them, and the users and systems behind them are inventoried and managed.
• Network segmentation. Unrelated portions of the environment are isolated from each other using segmentation or zero trust approaches, in line with the risk mitigation strategy.
• Credentials for infrastructure and software. New infrastructure and software are registered and authorized before receiving credentials, and credentials are removed when no longer needed.
• Encryption and key protection. Data is encrypted at rest, in processing, or in transit where the risk warrants it, and cryptographic keys are protected across generation, storage, use, and destruction.

Confidentiality engagements add a point of focus restricting access to confidential information to identified purposes; Privacy engagements add the equivalent for personal information.

How do you meet CC6.1 in cloud environments?

Cloud environments satisfy CC6.1 through the provider's identity and network primitives, configured deliberately and evidenced through exports. The building blocks are consistent across AWS, Azure, and GCP:

• Centralized identity through an IdP. SSO through an identity provider (Okta, Entra ID, Google Workspace) gives every user one attributable identity across the cloud console and SaaS tools. Federated roles replace long-lived IAM users.
• MFA enforced at the IdP. One enforcement point covers every downstream application. Conditional access policies (device posture, location) strengthen the story.
• Password policy aligned to NIST SP 800-63B. Current guidance drops composition rules: 8-character minimum with MFA, 15 without, with checks against compromised-password lists. Citing 800-63B in the policy is a stronger audit position than legacy complexity rules.
• Segmentation through VPCs and security groups. Separate production from non-production at the account or project level, restrict east-west traffic with security groups, and treat the account boundary as the primary blast-radius control.
• Managed encryption and keys. Provider KMS services handle encryption at rest by default; TLS termination covers transit. Key rotation and access to key policies are the configuration items auditors check.
• Asset inventory from the platform. Config services (AWS Config, Azure Resource Graph) generate the asset inventory CC6.1 expects, with tagging supplying ownership and classification.

How do you meet CC6.1 on-prem?

On-prem environments satisfy CC6.1 by stitching heterogeneous systems into one coherent access model: a central directory, a defined access path, and documented exceptions. The on-prem access control guide covers the full implementation; the shape is:

• Active Directory as the identity source of truth. Domain-joined systems inherit password, timeout, and access policy through GPOs; the AD user export (name, status, last logon) becomes a primary audit artifact. Systems that support LDAP should bind over LDAPS so authentication traffic is encrypted.
• A defined access path: VPN, then bastion. The VPN gateway with per-user certificates and MFA is the sole entry point; a bastion host is the only system permitted to reach production over SSH or RDP, with session logging and idle timeouts. Firewall rules enforce the path.
• Local accounts as documented exceptions. Network appliances and legacy systems that cannot join the domain get unique named local accounts, locally enforced password policy, and an inventory explaining why directory integration is unavailable.
• Break-glass instead of shared accounts. Where shared credentials are unavoidable, restrict them to emergencies: store them in a password manager or PAM tool with access logging, alert on every use, investigate each alert, and rotate the credential afterward.
• Hardening baselines with justified exceptions. A CIS benchmark scan against a custom, documented baseline (remediate, accept with justification, or mark not applicable) demonstrates standard configuration hardening better than a perfect score with no rationale.

Cloud vs on-prem at a glance

What evidence do auditors expect for CC6.1?

A second recurring gap is the undocumented exception. A database that cannot support MFA is not automatically a finding; an undocumented one is. A risk register entry naming the gap, the compensating controls (strong passwords plus IP allowlisting, for example), and the acceptance decision converts a hidden weakness into evidence of a functioning risk process.

How does CC6.1 map to ISO 27001:2022?

Organizations pursuing both frameworks can reuse CC6.1 evidence almost wholesale for these Annex A controls. The SOC 2 to ISO 27001 control mapping covers the full crosswalk across all five Trust Services Categories.

Related criteria

CC6.1 establishes the access control architecture; the rest of the CC6 series operates it. CC6.2 covers registering and provisioning users, CC6.3 covers role-based access and least privilege, and CC6.6 covers protection against threats from outside the system boundary. The Trust Services Criteria guide summarizes every series, and the monitoring side of the access story (detecting anomalous use of the access CC6.1 grants) lives in CC7.2.

Frequently Asked Questions

What does SOC 2 CC6.1 mean?

SOC 2 CC6.1 requires an organization to implement logical access security software, infrastructure, and architectures over protected information assets. It is the foundational criterion of the CC6 series and covers identity, authentication, access restriction, network segmentation, and encryption as one connected control set.

What evidence satisfies CC6.1?

Typical CC6.1 evidence includes an asset inventory with owners, an RBAC matrix, identity provider or Active Directory user exports, MFA configuration screenshots, firewall or security group rules, encryption and key management configuration, and a hardening baseline with documented exceptions.

Does SOC 2 CC6.1 require multifactor authentication?

No. CC6.1 expects stronger authentication techniques such as MFA where the organization's risk assessment warrants them. Systems that cannot support MFA can pass with a documented risk acceptance and compensating controls, such as strong password requirements and IP allowlisting.

Does CC6.1 require encryption?

CC6.1 includes points of focus on encrypting data at rest, in processing, and in transit, and on protecting cryptographic keys, applied where appropriate to the risk. Auditors look for encryption decisions that trace to the risk assessment rather than blanket encryption everywhere.

How is CC6.1 different from CC6.2 and CC6.3?

CC6.1 covers the technical architecture of access control: the software, infrastructure, and design that restrict access. CC6.2 covers the lifecycle of user registration, authorization, and deprovisioning. CC6.3 covers role-based access, least privilege, and segregation of duties within that architecture.