SOC 2 Control Mapping: How to Map Controls to TSC Criteria

What Is SOC 2 Control Mapping?

SOC 2 control mapping is the process of documenting which specific controls your organisation has implemented to satisfy each Trust Services Criterion. The output is a control matrix: a structured document (or compliance tool records) that shows the relationship between criteria and controls.

Control mapping serves two purposes: (1) for you — it clarifies what controls you need and identifies gaps. (2) for your auditor — it provides the basis for their testing procedures. Auditors design their test plans based on the controls you describe.

Building a Control Matrix

Control matrix columns: Criterion ID (e.g. CC6.1), Criterion Description (brief), Control ID (your internal numbering), Control Description (what the control does), Control Owner (person responsible), Control Frequency (continuous, daily, weekly, quarterly, annual, event-driven), Evidence Type (automated export, screenshot, document), Evidence Location (AuditPath control, S3 path, Google Drive folder).

One control can satisfy multiple criteria. For example, your quarterly access review satisfies CC6.2 (access restricted to authorised users) and CC6.3 (access modified when circumstances change). Map it to both criteria — it counts as evidence for both.

For each control, the description should be specific enough that an auditor can design a test. "We enforce MFA" is too vague. "All IAM users with console access are required to have MFA enabled, enforced by an IAM policy. Evidence: weekly IAM credential report export showing MFA enrolled = True for all users."

CC1–CC2 Sample Controls

CC1.1 (Integrity and Ethics): Control — Board of Directors and management demonstrate commitment to security through an approved Information Security Policy and security training programme. Evidence — ISP approval record, annual training completion report.

CC1.2 (Security Policies): Control — The company maintains an approved Information Security Policy hierarchy covering all major control domains. Evidence — policy documents with approval signatures and dates.

CC2.2 (Communication to Personnel): Control — All employees receive and acknowledge the Information Security Policy and key supporting policies annually. Evidence — employee acknowledgement records (DocuSign, LMS completion).

CC6 Access Control Mapping

CC6.1 (Logical Access Controls): Control 1 — MFA is required for all users with console access to AWS, GitHub, and Okta. Evidence: weekly IAM credential report export. Control 2 — SSO via Okta is required for all applications with access to production systems. Evidence: Okta application inventory and sign-on policy screenshot.

CC6.2 (Access Restriction): Control — Access is provisioned using least-privilege principles. New user access requires manager approval via IT ticketing system. Evidence: access provisioning tickets for sampled users.

CC6.3 (Access Removal): Control — Quarterly access reviews are conducted for all production systems. Access for terminated employees is removed within 24 hours via the offboarding checklist. Evidence: quarterly access review spreadsheets, offboarding checklist completions.

CC7, CC8, CC9 Mapping

CC7.1 (Vulnerability Management): Control — AWS Security Hub with CIS Benchmark is enabled and reviewed weekly. Vulnerabilities at CVSS 7.0+ are remediated within 30 days. Annual penetration test is conducted by a third-party firm. Evidence: weekly Security Hub exports, vulnerability tracking spreadsheet, penetration test report.

CC8.1 (Change Management): Control — All changes to production code require pull request with at least one reviewer before merge. Infrastructure changes require Terraform PR with plan output reviewed. Evidence: GitHub PR history, Terraform PR records.

CC9.2 (Vendor Risk Management): Control — Tier 1 vendors are reviewed annually using their current SOC 2 reports. All Tier 1 vendors have executed DPAs. Evidence: vendor risk register, vendor SOC 2 reports with review dates.

Multi-Framework Control Mapping

If you are pursuing SOC 2 and ISO 27001 simultaneously, map controls to both frameworks in your control matrix. Add columns for ISO 27001 Annex A control references alongside SOC 2 criteria.

SOC 2 CC6.1 (access control) maps to ISO 27001 Annex A 9.1.1, 9.2.1, 9.2.2. SOC 2 CC7.1 (vulnerability management) maps to A.12.6.1 and A.18.2.3. Building these mappings explicitly shows auditors (and your team) which controls serve multiple frameworks.

AuditPath maintains these cross-framework mappings automatically — when you mark evidence as satisfying SOC 2 CC6.1, it also marks the corresponding ISO 27001 controls. This is the efficiency gain of a unified compliance programme.