Compliance Crosswalk

<!-- AUTO-GENERATED by export-plugins.py — DO NOT EDIT -->
---
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:

```yaml
# 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:

```yaml
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

```yaml
# 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](https://csrc.nist.gov/projects/cybersecurity-framework) -- interactive framework explorer
- [AICPA SOC 2 Trust Services Criteria](https://www.aicpa.org/resources/landing/system-and-organization-controls-soc-suite-of-services) -- official criteria definitions
- [ISO 27001:2022 Annex A Controls](https://www.iso.org/standard/27001) -- control catalog
- [PCI-DSS v4.0 Requirements](https://www.pcisecuritystandards.org/document_library/) -- full requirements and guidance
- [Unified Compliance Framework (UCF)](https://www.unifiedcompliance.com/) -- commercial crosswalk database
- [NIST SP 800-53 to CSF Mapping](https://csrc.nist.gov/projects/olir) -- official NIST control mappings
- [CSA Cloud Controls Matrix](https://cloudsecurityalliance.org/research/cloud-controls-matrix/) -- cloud-specific crosswalk

<!-- Source: .faos/custom/skills/security/compliance-crosswalk/SKILL.md -->