CC6 Decoded: Access Controls That Actually Pass the Audit

Why CC6 Is Where Audits Are Won or Lost

If you only read one post in this series carefully, make it this one.

The CC6 logical access controls represent the largest concentration of audit testing in any SOC 2 engagement. In my experience across dozens of audits, the majority of exceptions — the findings that show up in reports — come from CC6. Access provisioning without proper approval. Terminated employees still active in systems. Admin accounts without MFA. Access reviews that were planned but never completed.

Orion had all of these. Let's walk through every CC6 control systematically.

CC6.1 — Infrastructure Security

This control covers how your infrastructure is architected to prevent unauthorized access.

What auditors test:

• Network segmentation — is production traffic separated from development?
• Encryption in transit — is all traffic over HTTPS/TLS?
• Encryption at rest — is customer data encrypted at rest?
• Firewall and security group configuration

What good evidence looks like for Orion:

• AWS VPC architecture diagram showing production/dev separation
• Screenshot of AWS Certificate Manager showing TLS certificates
• AWS RDS encryption enabled (screenshot from console)
• AWS Security Groups review showing only necessary ports open (443, 22 with IP restrictions)

The gap Orion fixed: Their staging environment shared the same AWS account as production. An engineer with staging access technically had the ability to see production security group rules. They split these into separate accounts during remediation.

CC6.2 — Provisioning Access

This control covers how access is granted to new users — both employees and external users.

What auditors test:

• Is there a documented approval workflow before access is granted?
• Are access requests tied to a defined business need?
• Is the principle of least privilege applied?

The key question the auditor will ask: "Show me the last 5 people who were granted production access. What was the approval process?"

What good evidence looks like:

• A ticketing system (Jira, Linear, ServiceNow) with access request tickets showing requester, justification, and manager approval
• An access request form or template
• Evidence that access granted matches what was approved (no extra permissions)

Orion's implementation: They created a simple access request template in Linear. Any request for production access required a ticket with: (1) what access is needed, (2) why it's needed, (3) manager approval comment. The ticket was then actioned by a senior engineer. Simple, auditable, effective.

CC6.3 — Removing Access

This is one of the most commonly failed controls. It covers whether access is removed when it's no longer needed — particularly when employees leave.

What auditors test:

• Sample 10-15 employee terminations during the observation period
• Check: Was access removed within your stated SLA? (Typically same day or within 24 hours)
• Check: Were all systems covered? (Okta, AWS, GitHub, databases, SaaS tools)

The failure mode: Most companies have an HR offboarding process but it doesn't systematically cover all technical systems. IT disables the Okta account (which stops email and SSO apps), but the engineer's personal GitHub account still has org membership. Or their AWS IAM user was never deleted.

What good evidence looks like:

• Offboarding checklist that explicitly covers each in-scope system
• Completion record for each termination (signed or timestamped by the person who completed it)
• Identity provider logs showing account deactivation timestamps
• GitHub organization member list export showing departed employees are removed

Orion's implementation: They built a comprehensive offboarding checklist in Notion with checkboxes for each system. Each completed offboarding was saved as a timestamped Notion page. During the audit, they could pull up any termination and show the complete checklist — deactivated in Okta, removed from GitHub org, AWS IAM user deleted, database access revoked.

CC6.4 — Physical Access

For cloud-native companies, physical access controls are simpler — you don't own the datacenter. But you still need controls for your office.

What auditors test:

• Are your office premises secured? (Keycard access, locks)
• Are visitors logged?
• Is sensitive equipment (laptops with production access) secured when unattended?

Evidence needed: Office access control system documentation, visitor log policy, clean desk/screen lock policy.

CC6.6 — Remote Access

This covers how employees access systems remotely — and increasingly, this means the entire company since remote work is now normal.

What auditors test:

• Is remote access to production systems controlled? (VPN, bastion host, or equivalent)
• Is MFA required for remote access?
• Are mobile devices that access company data managed? (MDM)

Orion's implementation: All production database access goes through an AWS Systems Manager Session Manager connection (no SSH keys, fully logged). All engineers use company-issued MacBooks enrolled in Kandji (MDM). MFA required for Okta (which gates all production access).

CC6.7 — Privileged Access

This control focuses on administrator and privileged accounts — the accounts that can do the most damage if compromised.

What auditors test:

• Who has admin/privileged access? Is the list minimal?
• Is MFA enforced for all admin accounts?
• Is privileged access reviewed at least quarterly?
• Are admin activities logged?

Common failures:

• Old admin accounts from departed employees that weren't removed
• Shared admin passwords (no individual accountability)
• MFA not enforced on cloud provider root accounts

What good evidence looks like:

• Admin account list showing current employees only
• MFA enforcement policy evidence (Okta or AWS IAM screenshot showing MFA required)
• Quarterly privileged access review sign-off documents
• AWS CloudTrail enabled for admin actions

CC6.8 — Malware Protection

This control covers protection against unauthorized or malicious software on endpoints.

What auditors test:

• Is endpoint protection (EDR/AV) deployed on all in-scope endpoints?
• What is the coverage percentage?
• Are alerts reviewed?

Evidence needed: EDR deployment report showing device list and coverage %, recent scan reports, evidence of alert review.

Orion's setup: CrowdStrike deployed on all MacBooks. Monthly deployment report from Kandji showing 100% enrollment. CrowdStrike detections reviewed weekly in security standup (15-minute agenda item, minutes kept).

The CC6 Evidence Checklist

Print this and use it:

• [ ] Network architecture diagram showing production/dev separation
• [ ] Encryption at rest — evidence for all production databases and storage
• [ ] Encryption in transit — TLS certificates or equivalent
• [ ] Access provisioning process — documented with approval workflow
• [ ] 3-5 sample access request tickets showing approval workflow
• [ ] Offboarding checklist with evidence of completions
• [ ] Quarterly access review reports (last 2 cycles)
• [ ] MFA enforcement evidence for all production systems
• [ ] Admin account list (dated, showing only current employees)
• [ ] Privileged access review sign-offs (at least 2 from observation period)
• [ ] EDR deployment report showing coverage %
• [ ] MDM enrollment report

What Comes Next

Access controls are the foundation. But even the best controls are worthless if you can't show the auditor the evidence. Next post: the evidence collection playbook — how to gather, organise, and present audit evidence without losing your mind.