SOC 2 CC6.1: logical access, explained for startups

What usually proves it

An auditor wants records from the period being examined, pulled from the systems that hold them rather than written up afterwards. Dates matter. A record with a date and a named owner carries more weight than a screenshot with neither. For CC6.1, the usual records are these.

• Multi-factor authentication enforcement settings
• A system and asset inventory
• Encryption at rest settings for databases and storage
• Identity provider configuration exports

What Polara asks about it

The free readiness assessment asks 19 questions that bear on CC6.1. A yes becomes a task to show the proof. A no becomes a task to fix the gap, with the steps written out.

• Do you maintain an inventory of devices that access production data? If yes, show it: MDM device list export, spreadsheet with serial numbers, asset inventory report, or device ownership roster. If no, the fix: build a device inventory from a device management tool or a maintained register and assign an owner to each device.
• Are all company laptops configured with full disk encryption? If yes, show it: MDM dashboard showing encryption compliance, FileVault/BitLocker compliance report, or disk encryption policy screenshot. If no, the fix: enforce full disk encryption on every company laptop and export the compliance report.
• Do you use a device management tool (MDM/EDR) for company laptops? If yes, show it: MDM dashboard screenshot, device compliance report, Jamf/Intune export, or endpoint compliance summary. If no, the fix: deploy a device management tool to every company laptop and enforce the baseline configuration through it.
• Are users required to lock their devices when unattended? If no, the fix: enforce an automatic screen lock on company devices and state the requirement in the acceptable use policy.
• Do you maintain an inventory of production systems, data stores, and SaaS applications with an owner for each? If yes, show it: spreadsheet listing each production system, data store and SaaS application with an owner, a configuration management database export, or a cloud resource inventory with owner tags. If no, the fix: build one inventory of production systems, data stores and SaaS applications, assign an owner to each entry, and export it.
• MFA required for cloud console access? If yes, show it: Okta multi-factor authentication (MFA) policy screenshot, AWS identity and access management (IAM) policy requiring MFA, Google Workspace 2-step verification settings, or Azure Active Directory MFA policy. If no, the fix: enforce multi-factor authentication (MFA) for every cloud console identity and export the enforcement setting as evidence.
• Password policy minimum length. If yes, show it: Okta or Google Workspace password policy settings, Azure Active Directory password policy screenshot, or IdP policy export. If no, the fix: set a minimum password length of 12 characters wherever passwords are enforced and export the policy.
• Role-based access for production systems? If yes, show it: AWS identity and access management (IAM) groups and roles screenshot, Okta groups list, Azure Active Directory group assignments, or role-based access control (RBAC) matrix export. If no, the fix: define production roles, assign access through those roles only, and export the role configuration.
• Account sharing prohibited? If yes, show it: access Control Policy section on individual accountability, employee handbook excerpt, onboarding security acknowledgment, or login banner. If no, the fix: prohibit shared accounts in the access control policy and replace any shared credential with named accounts.
• Highest data classification level you apply. If yes, show it: data Classification Policy, data inventory with classifications, data handling guidelines, or labeling or tagging screenshot. If no, the fix: define classification levels that cover customer and confidential data and apply them in the data management policy.
• Encryption at rest for databases and backups? If yes, show it: AWS Relational Database Service (RDS) encryption settings, S3 bucket encryption settings, key management service (KMS) key policy screenshot, or database encryption status report. If no, the fix: enable encryption at rest on databases and backups and export the configuration.
• Key rotation frequency. If no, the fix: define a key rotation schedule in the cryptography policy and enable automatic rotation where the key service supports it.
• Direct SSH/console access limited to named admins? If yes, show it: AWS SSM Session Manager config, bastion host access logs, VPN access policy, or jump host audit logs. If no, the fix: limit SSH and console access to named administrators and export the access list.
• Backups encrypted? If yes, show it: relational Database Service (RDS) backup encryption settings, S3 bucket encryption, key management service (KMS) key policy, or encrypted backup report. If no, the fix: enable encryption on backup storage and export the configuration.

It also asks, for context:

• Cloud provider used for production.
• Where is your password and authentication policy actually enforced?
• SSO used for SaaS apps?
• Encryption standard for data at rest.
• Secrets or key management system used for encryption keys.

Policies, templates and connected evidence

A policy states the rule, a template gives you the record to keep, and a connected system pulls the proof from the source. An auditor checks that the three agree: the cadence in the policy, the dates in the record and what the system shows.

In the policy pack, the Access Control Policy, Cryptography Policy, Data Management Policy and Asset Management Policy cover CC6.1.

Free templates that help, printed in full with Word, PDF or Excel downloads:

• Access control policy template
• Data classification and retention policy template
• Encryption policy template
• User access review template
• Access control matrix template
• Separation of duties matrix template
• Data classification standard template
• Asset inventory template

Connected systems that pull evidence for it:

• Amazon Web Services, IAM users: who has access, with each user's multi-factor authentication status and last login.
• Amazon Web Services, IAM password policy: the account-wide password requirements, or that none is set.
• Amazon Web Services, IAM roles: privileged roles and the trust policies that grant them.
• Amazon Web Services, IAM account summary: account-wide counts, including users and whether root multi-factor authentication is on.
• GitHub, Organization members: all members of the organization with their access type.
• GitHub, Organization two-factor enforcement: whether two-factor authentication is required for every organization member.
• Google Cloud, IAM members: project-level IAM policy bindings, showing which roles are granted to which members.
• Google Cloud, Organization policies: organization policy constraints in effect on each project.
• Google Workspace, Directory users: all users in the Workspace domain with admin, suspended and 2-Step Verification enrollment status.
• Google Workspace, 2-Step Verification status: per-user 2-Step Verification enrollment, summarized for the domain.
• Okta, Multi-factor enrollment: how many active users have at least one active multi-factor authentication factor.
• Okta, Sign-on policies: sign-on and authentication policies, and whether their rules require multi-factor authentication.
• Microsoft Entra ID, Multi-factor registration: how many users have registered a multi-factor authentication method.
• Microsoft Entra ID, Conditional access policies: enabled conditional access policies that require multi-factor authentication.
• Microsoft Entra ID, Intune managed devices: devices managed in Intune, with their encryption and compliance state.

If you also run ISO 27001, the Annex A controls A.5.9, asset inventory, A.5.12, classifying information, A.5.13, labeling information, A.5.15, access control rules, A.5.17, passwords and secrets, A.6.7, remote work, A.7.7, clear desk and screen, A.8.1, laptops and phones, A.8.2, privileged access, A.8.3, restricting access to data, A.8.4, source code access, A.8.5, secure sign in, A.8.11, data masking, A.8.18, powerful admin utilities, A.8.22, network segregation, A.8.24, encryption and A.8.31, separate environments ask for overlapping evidence. One record can serve both when it names what it proves.

Where it goes wrong

One gap a remediation playbook covers here is MFA Enforcement. The fix: enable and enforce MFA for all users across identity provider and critical systems. The proof: screenshot of IdP settings showing MFA is enforced for all users.

An auditor asks two things about it. Is there a documented requirement for multi-factor authentication? Is MFA enforced for all users in the identity provider?

Is it in your scope?

Yes, always. CC6.1 is one of the 33 common criteria, and the common criteria are in every SOC 2 report, Type 1 or Type 2. The common criteria. Every SOC 2 report covers them, whatever else you add: governance, risk, access, operations, change and vendors. Most of the work in any SOC 2 sits here.

Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.

Logical and physical access: the criteria around it

CC6.1 is one of 8 criteria in logical and physical access, CC6.1 to CC6.8. Reading a group together shows how its outcomes fit, and one record often serves more than one of them.

• CC6.1, this page
• CC6.2, user provisioning
• CC6.3, least privilege
• CC6.4, physical access
• CC6.5, data and device disposal
• CC6.6, network boundaries
• CC6.7, data in transit
• CC6.8, malware prevention

Before it: CC5.3, policies and procedures. After it: CC6.2, user provisioning. All the criteria are on the Trust Services Criteria page, grouped by category.