Skip to main content

Introduction - Normative cross-check

Software security does not happen in a technical vacuum.
Organisations in different sectors are subject to regulations, standards and frameworks that set explicit requirements to ensure adequate protection of systems, data and operations.
In this context, Security by Design - Theory of Everything (SbD-ToE) is not only a prescriptive manual of good practice: it is also an instrument of normative convergence, making it possible to align secure development and operation practices with multiple external demands.

Chapter 002 - Normative cross-check plays precisely this role:

  • Demonstrate, in a clear and verifiable way, how SbD-ToE responds to regulatory and normative requirements.
  • Identify where the model covers requirements, where there are declared gaps and what is out of scope, with the reason; the gaps and what is left out call for complementary legal, organisational or contractual processes.
  • Support GRC teams, auditors, technical teams and management teams in the task of articulating operational security with formal compliance.
  • For organisations that own or contract software development, offer practical playbooks to implement normative requirements consistently with the discipline of application security.

Context and Rationale​

Historically, the normative security landscape has evolved in a fragmented way:

  • Two decades ago, few standards existed, often limited to generic risk management requirements.
  • With digitalisation, an explosion of sectoral and regulatory normative instruments followed: HIPAA for healthcare, PCI-DSS for payments, GDPR for personal data protection, NIS2 and DORA for European cyber resilience, among many others.
  • Today, the challenge is not a lack of normative instruments but the excess of overlap and the resulting difficulty of coherent practical application.

SbD-ToE was conceived as a response to this problem.
Being built top-down, on the basis of multiple normative references, technical frameworks and maturity models (ISO, ENISA, NIST, OWASP SAMM, BSIMM, SSDF, DSOMM, SLSA, etc.), the manual ensures that:

  • Normative requirements are incorporated from the root, not treated as external or additive layers.
  • Compliance is not an isolated goal: applying secure practices throughout the lifecycle produces the technical evidence that regulations ask for, and the Manual declares what remains to be done.
  • Each knowledge area (requirements, architecture, CI/CD, containers, governance, etc.) contributes requirements and evidence to that answer.

Objectives of this chapter​

  1. Show the correspondence between SbD-ToE practices and the requirements of international and European normative instruments.
  2. Show the areas covered, where adopting the Manual provides the technical evidence the regulation asks for.
  3. Declare the gaps and what is out of scope, with no grey areas, helping organisations understand where they need additional measures (legal, procedural or technical).
  4. Provide a comparative repository that can be reused in audits, certifications or compliance reports.
  5. Offer implementation playbooks for organisations that contract or develop software, ensuring that acquisition/development is consistent with specific normative requirements.

Methodology adopted​

The analysis follows a systematic structure, common to all normative instruments:

  • Framing → brief description of the normative instrument, its scope and objectives.
  • Coverage matrix → each obligation of the regulation, checked against the consolidated text, has one of three answers, and none is left unanswered:
    • Covers, stating how: catalogue requirement, policy, floor or requirement added by the regime, or engineering evidence for a duty that sits on another plane (the latter never counts as coverage of the duty itself).
    • Declared gap, stating what is missing; when the gap depends on a future round of the AppSec Core, the round is indicated.
    • Out of scope, with the reason.
      The “Applicable requirements” pages (and, for the CSA, “Coverage”) are generated from this matrix and take precedence over hand-written text.
  • Regulatory contexts → the core of the Manual is regulation-agnostic. When an application is subject to a regime, it declares the corresponding context (CTX-<regime>), which raises catalogue requirements to mandatory (floor) and adds requirements that only make sense under the regime. A context never removes or lowers a Manual minimum. Levels L1–L3 measure the application's risk and are not equivalent to any regulation's risk classes.
  • Critical Notes → observations on interpretation, overlap or complementarity.
  • Conclusion → what the SbD-ToE covers in that normative framework, what remains a declared gap and what is out of scope.
  • Practical Playbook (where applicable) → implementation roadmap for organisations with a development/AppSec discipline, guiding how to integrate normative requirements into software acquisition or development.

The Manual is centred on the application: requirements, architecture, code, dependencies, pipeline, deployment and operation of the software. AI comes in like any other topic of the Manual; there is no separate AI manual. The obligation-by-obligation answer for each regulation is in:

Philosophy of Integrated Compliance​

SbD-ToE is not a standard, but it was designed to engage in dialogue with all standards.
This is because:

  • Standards and regulations focus on specific dimensions (governance, risk, reporting, data protection, etc.), and SbD-ToE prescribes comprehensive and integrated practices on the application side.
  • The relation between the two is not presumed from scope: it is shown obligation by obligation, and it can be overlap, contribution, partial coverage, conditional satisfaction, gap or out of scope. The coverage matrices record it in three categories (covers, declared gap, out of scope).
  • Compliance remains the organisation's judgement. The Manual provides the technical evidence and states clearly what remains to be done and what does not fall to it, without a parallel or bureaucratic effort for each regulation.

This view mitigates regulatory fragmentation and offers organisations a unified model of practical application, where security, risk and compliance converge.

Important Note: Normative Instruments and Application Development​

Many normative instruments (e.g. DORA, NIS2, ISO 27001) are not specific to software development, but cover the comprehensive management of ICT risk in organisations.

However, when an organisation owns or contracts software development, the discipline of application security (AppSec) becomes a critical component for demonstrating compliance with those normative instruments.

Practical consequence:

  • The normative instrument requires "ICT risk management" (broad scope)
  • The organisation implements this through multiple controls (architecture, operations, contracts, etc.)
  • If there is software development/acquisition, the playbooks in this chapter guide how to integrate AppSec practices in a consistent and proportionate way with the regulation

The Manual's perimeter. The Manual is centred on the application. The following are out of scope, with the reason recorded in each regulation's matrix: the security of the entity as a whole (corporate network and administration channels, EDR, patching of operating systems and equipment, inventory and classification of all assets), business continuity, crisis management and the entity's BIA, conformity assessment, CE marking and declarations of conformity, and the legal side of the GDPR (legal bases, formal response to the data subject and deadlines). AI is treated like any other topic of the Manual, with no separate manual.

Example: DORA is financial regulation, but if a financial entity develops software in-house, it must apply the principles of SbD-ToE to demonstrate that its cyber-resilience posture (DORA Art. 5) includes development security practices.

Chapter Structure​

This chapter is organised by framework/normative instrument, each in a dedicated folder with an introduction, an implementation playbook and the coverage page generated from the matrix:

Frameworks Currently Covered​

DORA (Digital Operational Resilience Act)​

NIS2 (Network and Information Security Directive)​

CRA (Cyber Resilience Act)​

GDPR (General Data Protection Regulation)​

AI Act (Artificial Intelligence Regulation)​

ENISA / CSA (Cybersecurity Act — European cybersecurity certification)​

Supporting Examples and Templates​

Example Playbook​

Frameworks to Include (Roadmap)​

The following frameworks are on the roadmap for future addition:

  • ISO 27001 → Information Security Management Standard
  • HIPAA → Health Insurance Portability and Accountability Act
  • PCI-DSS → Payment Card Industry Data Security Standard
  • SOC2 → Service Organization Control 2
  • FedRAMP → Federal Risk and Authorization Management Program
  • CSA STAR → Cloud Security Alliance Security Trust Assurance and Risk

Common Structure of Each Framework​

Each framework folder follows this consistent structure:

  1. Introduction

    • Legal/regulatory framing
    • Scope of application
    • Main objectives

  2. Implementation Playbook

    • Cross-check: Requirements vs. SbD-ToE
    • Implementation roadmap
    • Phases and milestones
    • Practical checklists

  3. Convergence Analyses (where applicable)

    • Overlap between frameworks
    • Lex specialis principle
    • Harmonised implementation strategies

  4. Applicable requirements / Coverage (generated from the matrix)

    • Obligation by obligation: covered, declared gap or out of scope
    • Floor and requirements added by the regulatory context, where one exists

Recommended reading​

  • This chapter should be read in conjunction with Chapter 00 - Theory of Everything, which explains the overall philosophy of the manual.
  • For organisations with software development/acquisition, it is recommended to start with the playbooks (e.g. DORA, NIS2), which guide coherent implementation.
  • It may also be used as a stand-alone document, serving as a quick reference guide for anyone seeking to verify the alignment of SbD-ToE with specific requirements.