Compliance Framework Crosswalk

---

name: compliance-crosswalk description: Compliance framework crosswalk mapping SOC 2, ISO 27001, NIST CSF, and PCI-DSS for unified control management tags: [compliance, security]

Compliance Framework Crosswalk

Overview

Organizations operating in regulated industries or pursuing enterprise customers frequently face overlapping compliance requirements. A compliance crosswalk maps equivalent controls across multiple frameworks, enabling a "implement once, satisfy many" approach.

This skill covers the four most common frameworks for SaaS platforms:

Framework	Scope	Governed By	Controls
SOC 2 Type II	Trust Service Criteria	AICPA	~60 CC
ISO 27001:2022	ISMS Annex A Controls	ISO/IEC	93
NIST CSF 2.0	Cybersecurity Functions	NIST	106 subcat
PCI-DSS v4.0	Payment Card Data	PCI SSC	~250 req

By building a unified control library with crosswalk mappings, you can:

• Reduce duplicate implementation effort by 40-60%
• Streamline evidence collection for multi-framework audits
• Identify control gaps visible only through cross-framework analysis
• Accelerate certification timelines by leveraging existing compliance evidence

When to Use This Skill

• Your organization needs to comply with multiple security frameworks simultaneously
• You are building a GRC (Governance, Risk, Compliance) program from scratch
• An audit is approaching and you need to map existing controls to a new framework
• You want to identify shared controls that satisfy multiple framework requirements
• You are designing an automated evidence collection system
• You are evaluating which framework to pursue first for maximum cross-coverage

How It Works

Step 1: Identify Your Primary Framework

Choose the framework with the broadest control coverage or the one required by your most important customer/regulator. Common starting points:

Starting Framework	Best When
SOC 2	US SaaS company, enterprise sales, no payment data
ISO 27001	International customers, EU market, broad ISMS
NIST CSF	US government contracts, federal requirements
PCI-DSS	Processing, storing, or transmitting cardholder data

For FAOS, the recommended starting point is SOC 2 (primary customer requirement) with ISO 27001 as the secondary framework for international expansion.

Step 2: Map Controls to Secondary Frameworks

For each control in your primary framework, identify equivalent controls in secondary frameworks. Use the mapping tables in the Examples section as a starting reference.

Key mapping principles:

• One-to-many: A single SOC 2 criterion may map to multiple ISO 27001 controls
• Many-to-one: Multiple PCI-DSS requirements may be satisfied by one NIST CSF subcategory
• Partial overlap: Some mappings are partial -- the control covers 80% of the requirement but needs supplementation
• No equivalent: Some controls are framework-specific (e.g., PCI-DSS requirement for PAN masking)

Step 3: Identify Shared Controls

Group mapped controls by implementation domain to find shared controls:

Domain	Shared Control Description	Frameworks Satisfied
Access Control	Role-based access with MFA and access reviews	All 4
Encryption	TLS 1.2+ in transit, AES-256 at rest	All 4
Logging & Monitoring	Centralized logging with 90-day retention	All 4
Incident Response	Documented IR plan with annual testing	All 4
Change Management	Peer-reviewed changes with rollback capability	All 4
Vulnerability Mgmt	Regular scanning with risk-based remediation	All 4
Vendor Management	Third-party risk assessments	SOC 2, ISO, NIST
Data Classification	Asset inventory with sensitivity labels	ISO, NIST, PCI-DSS

Step 4: Build a Unified Control Library

Create a structured control library that maps each implementation to all satisfied framework requirements:

# unified-control-library.yaml
controls:
  - id: UCL-AC-001
    title: "Multi-Factor Authentication"
    description: "MFA is required for all user accounts accessing production systems"
    owner: "Security Engineering"
    implementation:
      status: implemented
      evidence_type: configuration_screenshot
      automation: "Quarterly MFA compliance scan via IdP API"
    mappings:
      soc2:
        - CC6.1  # Logical and physical access controls
        - CC6.2  # Access credentials management
      iso27001:
        - A.8.5  # Secure authentication
      nist_csf:
        - PR.AA-01  # Identities and credentials managed
        - PR.AA-03  # Users, services, and hardware authenticated
      pci_dss:
        - "8.4.2"   # MFA for all access to CDE
        - "8.4.3"   # MFA for remote network access

Step 5: Automate Evidence Collection

For each unified control, define evidence collection procedures that produce artifacts satisfying all mapped frameworks:

1. Automated evidence: API queries to IdP, cloud provider, SIEM (preferred)
2. Semi-automated evidence: Scripts that generate reports from system configurations
3. Manual evidence: Screenshots, attestations, meeting minutes (minimize these)

Map evidence artifacts to control IDs for audit retrieval:

evidence:
  - id: EVD-AC-001-Q1-2026
    control_id: UCL-AC-001
    type: automated_report
    source: "Okta MFA compliance report"
    collected_at: "2026-01-15T00:00:00Z"
    satisfies:
      - soc2: CC6.1
      - iso27001: A.8.5
      - nist_csf: PR.AA-03
      - pci_dss: "8.4.2"

Examples

Example 1: Crosswalk Table for Access Control Domain

+-------------------+------------------+------------------+------------------+
| SOC 2             | ISO 27001:2022   | NIST CSF 2.0     | PCI-DSS v4.0     |
+-------------------+------------------+------------------+------------------+
| CC6.1 Logical &   | A.5.15 Access    | PR.AA-01 Identity| 7.1 Restrict     |
| physical access   | control          | & credentials    | access by need   |
|                   |                  | managed          | to know          |
+-------------------+------------------+------------------+------------------+
| CC6.2 Credentials | A.8.5 Secure     | PR.AA-03 Users   | 8.2 User ID      |
| management        | authentication   | authenticated    | management       |
+-------------------+------------------+------------------+------------------+
| CC6.3 Access      | A.5.18 Access    | PR.AA-05 Access  | 7.2 Appropriate  |
| authorization     | rights           | permissions      | access control   |
+-------------------+------------------+------------------+------------------+
| CC6.6 System      | A.8.20 Network   | PR.DS-01 Data at | 1.3 Network      |
| boundaries        | security         | rest protected   | access controls  |
+-------------------+------------------+------------------+------------------+
| CC6.7 Data        | A.8.24 Use of    | PR.DS-02 Data in | 4.1 Strong       |
| transmission      | cryptography     | transit protected| cryptography     |
+-------------------+------------------+------------------+------------------+
| CC6.8 Unauthorized| A.8.16 Monitoring| DE.CM-01 Networks| 10.6 Review logs |
| access prevention | activities       | monitored        | and events       |
+-------------------+------------------+------------------+------------------+

Example 2: Unified Control Library YAML Format

# Full unified control library structure
metadata:
  version: "1.0.0"
  last_updated: "2026-02-24"
  frameworks:
    - name: soc2
      version: "2022"
      source: "AICPA Trust Services Criteria"
    - name: iso27001
      version: "2022"
      source: "ISO/IEC 27001:2022 Annex A"
    - name: nist_csf
      version: "2.0"
      source: "NIST Cybersecurity Framework 2.0"
    - name: pci_dss
      version: "4.0"
      source: "PCI-DSS v4.0"

domains:
  - name: "Access Control"
    controls:
      - id: UCL-AC-001
        title: "Multi-Factor Authentication"
        description: >
          MFA is required for all interactive user accounts accessing
          production systems, administrative consoles, and cloud provider
          management planes.
        owner: "Security Engineering"
        review_frequency: quarterly
        implementation:
          status: implemented
          tool: "Okta Verify"
          automation: true
          evidence_artifacts:
            - "Okta MFA enforcement policy export"
            - "Quarterly MFA compliance scan results"
        mappings:
          soc2: [CC6.1, CC6.2]
          iso27001: [A.8.5]
          nist_csf: [PR.AA-01, PR.AA-03]
          pci_dss: ["8.4.2", "8.4.3"]

      - id: UCL-AC-002
        title: "Role-Based Access Control"
        description: >
          Access to systems and data is granted based on job function
          using predefined roles. Least privilege is enforced. Access
          reviews are conducted quarterly.
        owner: "IT Operations"
        review_frequency: quarterly
        implementation:
          status: implemented
          tool: "Okta + GCP IAM"
          automation: partial
          evidence_artifacts:
            - "GCP IAM policy export"
            - "Quarterly access review spreadsheet"
            - "Role definition document"
        mappings:
          soc2: [CC6.1, CC6.3]
          iso27001: [A.5.15, A.5.18]
          nist_csf: [PR.AA-05]
          pci_dss: ["7.1", "7.2"]

      - id: UCL-AC-003
        title: "Privileged Access Management"
        description: >
          Privileged accounts (admin, root, service accounts) are
          inventoried, subject to enhanced monitoring, and require
          additional approval for access.
        owner: "Security Engineering"
        review_frequency: monthly
        implementation:
          status: implemented
          tool: "GCP IAM + Breakglass procedure"
          automation: partial
          evidence_artifacts:
            - "Privileged account inventory"
            - "Break-glass access logs"
            - "Monthly privileged access review"
        mappings:
          soc2: [CC6.1, CC6.2, CC6.3]
          iso27001: [A.8.2, A.8.5, A.8.18]
          nist_csf: [PR.AA-01, PR.AA-05]
          pci_dss: ["7.2", "8.6"]

  - name: "Data Protection"
    controls:
      - id: UCL-DP-001
        title: "Encryption at Rest"
        description: >
          All data at rest is encrypted using AES-256 or equivalent.
          Cloud-managed encryption keys are used by default;
          customer-managed keys (CMEK) available for enterprise tier.
        owner: "Platform Engineering"
        review_frequency: annual
        implementation:
          status: implemented
          tool: "GCP Cloud KMS"
          automation: true
          evidence_artifacts:
            - "GCP encryption configuration scan"
            - "KMS key rotation policy"
        mappings:
          soc2: [CC6.7]
          iso27001: [A.8.24]
          nist_csf: [PR.DS-01]
          pci_dss: ["3.5", "3.6"]

Best Practices

Do This

• Start with the framework that covers the most controls shared across your target frameworks
• Maintain a single unified control library as the source of truth for all frameworks
• Automate evidence collection wherever possible to reduce audit preparation burden
• Review crosswalk mappings annually or when framework versions are updated
• Track partial mappings explicitly -- note when a control satisfies 80% but needs supplementation
• Use control IDs consistently across your ticketing system, wiki, and audit reports
• Involve auditors early to validate your crosswalk interpretations
• Version control your unified control library alongside your codebase

Don't Do This

• Do not maintain separate control implementations per framework -- this defeats the purpose of crosswalks
• Do not assume a 1:1 mapping between frameworks -- always verify the actual control text
• Do not ignore framework-specific requirements that have no crosswalk equivalent
• Do not copy crosswalk tables blindly -- validate them against your specific environment
• Do not skip evidence linking -- every control must have traceable evidence artifacts
• Do not treat compliance as a point-in-time activity -- continuous monitoring is essential
• Do not forget to update crosswalks when frameworks release new versions

Security Checklist

• Primary compliance framework is selected and gap assessment completed
• Crosswalk mapping covers all target frameworks (SOC 2, ISO 27001, NIST CSF, PCI-DSS as applicable)
• Unified control library is documented in a structured format (YAML, spreadsheet, or GRC tool)
• Each control has an assigned owner and review frequency
• Shared controls are identified and implementation avoids duplication
• Framework-specific controls (no crosswalk equivalent) are listed separately
• Evidence artifacts are defined for every control
• Automated evidence collection is implemented for high-frequency controls
• Crosswalk mappings are validated by an auditor or compliance advisor
• Control library is version-controlled with change history
• Quarterly reviews are scheduled to update mappings and evidence
• Gap remediation plan exists for controls not yet implemented
• Executive dashboard reports compliance posture across all frameworks

Related Skills

• @soc2-controls -- detailed SOC 2 Trust Service Criteria implementation guide
• @iso27001-annexa -- ISO 27001:2022 Annex A control implementation guidance
• @nist-csf -- NIST Cybersecurity Framework 2.0 subcategory details
• @pci-dss-v4 -- PCI-DSS v4.0 requirement implementation guide
• @gdpr-reference -- GDPR data protection requirements and crosswalk to ISO 27001

Additional Resources

• NIST CSF 2.0 Reference Tool -- interactive framework explorer
• AICPA SOC 2 Trust Services Criteria -- official criteria definitions
• ISO 27001:2022 Annex A Controls -- control catalog
• PCI-DSS v4.0 Requirements -- full requirements and guidance
• Unified Compliance Framework (UCF) -- commercial crosswalk database
• NIST SP 800-53 to CSF Mapping -- official NIST control mappings
• CSA Cloud Controls Matrix -- cloud-specific crosswalk