# Compliance Crosswalk > - Skill: `frank-luongt/compliance-crosswalk` (Agent Skill) - Install (CLI): `npx skillmds@latest add frank-luongt/compliance-crosswalk` - Raw SKILL.md: https://api.skillmd.com/api/skills/frank-luongt/compliance-crosswalk/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: frank-luongt (https://skillmd.com/u/frank-luongt) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/frank-luongt/compliance-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: ```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