The Regulation → Capability Mapping view enables security leaders to start from a regulatory or assurance obligation and systematically understand which security capabilities must exist to make that obligation operational and defensible.
Purpose of This Mapping View
Translate Regulatory Language
Convert abstract regulatory requirements into concrete operational capabilities that teams can build and maintain
Avoid Legal-Only Interpretations
Move beyond compliance theater by grounding obligations in actual security capabilities rather than documentation exercises
Reveal Shared Dependencies
Discover how multiple frameworks rely on the same underlying capabilities, enabling efficient multi-framework compliance
Enable Defensible Answers
Provide clear, evidence-based responses to auditors and supervisors by connecting obligations to actual operational reality
This view answers the critical question: "If I am asked about this obligation, what must actually be in place?" It transforms abstract compliance requirements into tangible security architecture and operational practices that can be implemented, measured, and defended.
How This Mapping Works
This mapping methodology starts from regulatory lenses and domains and systematically navigates back to the foundational elements that make compliance real:
Security Capability Clusters (SCCs)
Supporting governance and operational practices
Evidence expectations and failure exposure
Control implementation patterns
Critical Principle
Regulatory requirements are not implemented directly. They are realized through capabilities. Without this distinction, organizations build compliance programs that satisfy auditors on paper but fail under real-world pressure.
This approach ensures that every regulatory obligation maps to concrete, testable capabilities that exist in your operational environment. The result is compliance that reflects actual security posture rather than aspirational documentation.
ISO/IEC 27001, the international standard for information security management systems, establishes comprehensive requirements for establishing, implementing, maintaining, and continually improving security controls across an organization.
Change control processes, configuration baselines, asset management, and technical vulnerability management
6
SCC-11 - Backup, Restoration & Continuity
Business continuity planning, backup procedures, disaster recovery capabilities, and resilience testing
ISO controls are only effective when governance and operation intersect. The standard requires both strategic oversight and tactical execution, making it essential that capabilities span from boardroom to server room.
The NIS2 Directive (Network and Information Security Directive) represents the EU's updated approach to cybersecurity resilience, emphasizing organizational preparedness, supply chain security, and the ability to maintain operations under cyber pressure.
SCC-01 - Governance, Risk & Compliance
Executive accountability, cyber risk management frameworks, and board-level oversight of security posture
Crisis management procedures, backup verification, recovery time objectives, and resilience testing
SCC-12 - Data Protection & Privacy
Encryption capabilities, data classification, secure disposal, and cross-border data handling controls
NIS2 emphasizes organizational readiness and systemic resilience rather than checkbox compliance. It requires demonstrable capability to prevent, detect, respond to, and recover from cybersecurity incidents that could impact essential services.
The Digital Operational Resilience Act (DORA) establishes a comprehensive framework for ICT risk management in the financial sector, with particular emphasis on operational continuity under disruption and third-party technology dependencies.
1
SCC-01 - Governance, Risk & Compliance
ICT risk management framework, governance structures, and management body accountability
2
SCC-05 - Logging, Monitoring & Detection
ICT-related incident detection, classification, and regulatory reporting capabilities
3
SCC-07 - Secure Development & DevOps
Secure development practices for critical ICT systems and deployment safeguards
1
SCC-11 - Backup, Restoration & Continuity
Digital operational resilience testing, recovery plans, and continuity capabilities
2
SCC-09 - Third-Party & Supplier Security
ICT third-party risk management, critical provider oversight, and contractual arrangements
DORA evaluates operational survivability under disruption. The regulation tests whether financial entities can maintain critical operations when technology fails, vendors become unavailable, or cyber incidents occur. This requires capabilities that go beyond prevention to encompass detection, response, recovery, and learning.
The General Data Protection Regulation (GDPR) establishes comprehensive requirements for processing personal data, emphasizing individual rights, accountability, and demonstrable compliance through technical and organizational measures.
SCC-12 - Data Protection & Privacy
Data minimization, purpose limitation, storage limitation, encryption at rest and in transit, pseudonymization, and data subject rights fulfillment mechanisms
SCC-01 - Governance, Risk & Compliance
Data protection impact assessments (DPIAs), records of processing activities, privacy governance frameworks, and accountability documentation
SCC-02 - Identity & Access Management
Role-based access to personal data, need-to-know enforcement, access logging, and authentication for data access
SCC-05 - Logging, Monitoring & Detection
Data breach detection, processing activity monitoring, unauthorized access detection, and 72-hour breach notification capability
SCC-09 - Third-Party & Supplier Security
Processor agreements (Article 28), sub-processor management, international transfer mechanisms, and vendor audit rights
GDPR compliance exists only where accountability meets enforcement. The regulation requires organizations to demonstrate not just that they have policies, but that those policies are embedded in operational systems and enforced through technical controls. Capability-based implementation ensures that data protection is baked into architecture rather than bolted on through documentation.
SOC 2 (Service Organization Control 2) reports provide assurance about the controls at service organizations relevant to security, availability, processing integrity, confidentiality, and privacy. Unlike regulatory frameworks, SOC 2 evaluates control effectiveness over a sustained period.
1
SCC-01 - Governance, Risk & Compliance
Common Criteria foundation: risk assessment, policies, communication, monitoring of controls, and management oversight
2
SCC-02 - Identity & Access Management
Security and Confidentiality criteria: user access provisioning, authentication mechanisms, privilege management, access reviews
3
SCC-05 - Logging, Monitoring & Detection
Security monitoring, system activity logging, intrusion detection, security event analysis, and incident response
4
SCC-07 / SCC-08 - Development & Change Control
System development lifecycle, change management procedures, testing protocols, and deployment authorization
5
SCC-11 - Backup, Restoration & Continuity
Availability criteria: backup procedures, disaster recovery plans, system redundancy, and recovery testing
SOC 2 tests control reliability over time. Type II reports examine whether controls operated effectively throughout the examination period, not just whether they existed at a point in time. This makes capability maturity and operational consistency critical to successful attestation.
Each regulation addressed in isolation, creating siloed compliance programs that don't communicate
Framework-Specific Controls
Different control implementations for each framework, multiplying technical debt and operational overhead
Multiplied Effort
Redundant evidence collection, duplicate audits, and parallel documentation efforts that scale linearly with frameworks
ECIL Regulation → Capability Mapping
Shared Dependencies Revealed
Identify common capability requirements across multiple frameworks, enabling unified implementation
Multi-Framework Assurance
One well-designed capability architecture satisfies multiple regulatory requirements simultaneously
Architectural Compliance
Compliance becomes embedded in system design rather than maintained through separate documentation layers
This view prevents regulatory tunnel vision - the dangerous tendency to optimize for individual framework compliance while missing the structural patterns that enable efficient, defensible, multi-framework assurance.
How to Use This Page
Answer Audit Questions Without Panic
When auditors ask about specific regulatory requirements, immediately understand which capabilities must be demonstrated and where evidence exists. Transform reactive scrambling into confident, structured responses grounded in operational reality.
Translate Regulatory Language into Engineering Action
Convert abstract compliance obligations into concrete technical requirements that engineering teams can build, test, and maintain. Bridge the gap between legal interpretation and operational implementation.
Explain Compliance Posture to Executives
Communicate security and compliance status to leadership in terms of capability maturity rather than control counts. Show how investments in capabilities deliver multi-framework compliance value.
Identify Capability Gaps with Regulatory Impact
Discover which missing or immature capabilities create exposure across multiple regulatory frameworks. Prioritize remediation based on cumulative regulatory risk rather than individual framework requirements.
Regulation → Capability Mapping answers the fundamental question that determines whether compliance is real or theatrical: "What must exist operationally to satisfy this obligation?"
Explore related mapping views and strategic perspectives within the Enterprise Security Lens framework to build a complete understanding of how capabilities, regulations, evidence, and business outcomes connect.