Compliance Mapping

From Regulatory Requirements to Executable Controls

Purpose

This section explains how regulatory and standards-based requirements are translated into technical controls, operating models, and evidence within modern cloud and software environments.

It provides a practical mapping layer between:

  • legal and regulatory expectations

  • engineering implementation

  • operational proof

This is not legal advice. It is an engineering and assurance interpretation of compliance obligations.

—

What Compliance Means in Practice

In regulated environments, compliance is often misunderstood as:

  • policy documentation

  • periodic audits

  • checkbox validation

In practice, regulators, auditors, and customers expect:

  • controls to be implemented

  • responsibilities to be clear

  • risks to be managed

  • evidence to be defensible

Compliance therefore becomes an operating model, not a document set.

—

The Mapping Model

Thinkwerke approaches compliance using a consistent mapping structure:

  1. Requirement - What the regulation or standard requires

  2. Control Objective - What must be achieved to satisfy the requirement

  3. Technical Control - How the objective is implemented in systems and workflows

  4. Operational Process - How the control is operated, monitored, and maintained

  5. Evidence - How effectiveness is demonstrated

This model supports reuse across frameworks and reduces duplication.

—

Frameworks Covered

This documentation covers the following major frameworks and regulations:

  • ISO 27001

  • NIS2 Directive

  • Cyber Resilience Act (CRA)

  • GDPR

  • Cross-framework mappings and overlaps

Each framework is documented individually, with references to shared controls and common evidence sources.

—

Cloud & Vendor-Hosted Context

Most regulated organisations operate in:

  • public cloud environments

  • managed platforms

  • vendor-hosted services

Compliance mapping must therefore account for:

  • shared responsibility

  • inherited controls

  • validation of vendor assurances

  • organisation-owned implementation

All mappings in this section assume real-world cloud architectures.

—

Evidence-Centric Compliance

Across all frameworks, a common requirement emerges:

> If a control cannot be proven, it does not exist.

This documentation emphasises:

  • evidence generated by execution

  • traceability from requirement to artefact

  • repeatability across audits and customers

  • minimal manual intervention

Evidence sources are referenced consistently across frameworks.

—

How to Use This Section

You can use this section to:

  • understand regulatory expectations in engineering terms

  • map controls to cloud and CI/CD environments

  • prepare for audits and assessments

  • align internal teams around shared control language

  • build reusable assurance material

Each framework page links to:

  • relevant solution architectures

  • evidence library examples

  • whitepapers for deeper context

—

Relationship to Other Sections

This section is supported by:

Together, these form a complete execution-to-evidence documentation set.

—

Key Takeaway

Compliance is not achieved through documentation alone.

It is achieved when regulatory intent is translated into controls, controls into execution, and execution into evidence.