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:

- :doc:`/solutions/index`
- :doc:`/evidence-library/index`
- :doc:`/whitepapers/index`

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**.