diff --git a/Architecture-Security-and-Access-Boundaries.md b/Architecture-Security-and-Access-Boundaries.md
index 93cc67c..85ff5c4 100644
--- a/Architecture-Security-and-Access-Boundaries.md
+++ b/Architecture-Security-and-Access-Boundaries.md
@@ -115,3 +115,7 @@ Actual compliance still depends on:
 ## Operational Constraint
 
 Central guidance should remain advisory-first. Local site and edge layers must still behave safely when central is degraded or unavailable.
+
+## Related Page
+
+- [Security and Regulatory Mapping](Architecture-Security-and-Regulatory-Mapping)
diff --git a/Architecture-Security-and-Regulatory-Mapping.md b/Architecture-Security-and-Regulatory-Mapping.md
new file mode 100644
index 0000000..2b9bc6c
--- /dev/null
+++ b/Architecture-Security-and-Regulatory-Mapping.md
@@ -0,0 +1,56 @@
+# EVOLV Security and Regulatory Mapping
+
+This page maps major security and resilience requirement areas to the EVOLV architecture direction.
+
+It is intended to help explain to reviewers how EVOLV can be deployed to satisfy strict requirements, while staying explicit that compliance depends on implementation and operations as well as architecture.
+
+## Primary Sources
+
+- NIS2: Directive (EU) 2022/2555
+- CER: Directive (EU) 2022/2557
+- Cyber Resilience Act: Regulation (EU) 2024/2847
+- GDPR: Regulation (EU) 2016/679
+
+Official texts:
+
+- https://eur-lex.europa.eu/eli/dir/2022/2555/oj
+- https://eur-lex.europa.eu/eli/dir/2022/2557/oj
+- https://eur-lex.europa.eu/eli/reg/2024/2847/oj
+- https://eur-lex.europa.eu/eli/reg/2016/679/oj
+
+## Mapping Table
+
+| Requirement Area | Regulatory Context | EVOLV Architecture Response | Current Position |
+|---|---|---|---|
+| OT/IT segmentation | NIS2, CER, Purdue-aligned industry practice | External integrations terminate centrally; field edge is not the public integration surface; site and edge remain behind mediated layers. | Architecture defined, deployment enforcement depends on implementation. |
+| Resilience during central outage | CER, NIS2 | Local and site layers retain Node-RED execution and local InfluxDB access so operation and monitoring can continue during central disruption. | Architecture defined, per-site operating procedures still required. |
+| Controlled external access | NIS2, GDPR | Central API gateway acts as the entry point; central auth and policy checks mediate requests downward. | Architecture defined, gateway and IAM rollout maturity may vary by deployment. |
+| Identity and authorization | NIS2, GDPR, CRA | Central IAM and policy enforcement are treated as platform services rather than ad hoc runtime behavior at the edge. | Target-state architecture; implementation maturity not yet uniform. |
+| Secure configuration handling | NIS2, CRA | `tagcodering` is the intended configuration backbone; tracked manifests should use environment variables or secret injection rather than hard-coded credentials. | Direction established; config backbone and secret-handling rollout still in progress. |
+| Vulnerability and update management | CRA, NIS2 | Central source control, CI/CD, and release traceability support controlled updates and evidence of change. | Core tooling exists in architecture direction; operating process must be maintained. |
+| Logging and auditability | NIS2, GDPR, CER | Central ingress and layered mediation make it easier to define logging and audit boundaries; local/site layers can retain operational evidence. | Partly architectural, partly operational; needs explicit logging policy per deployment. |
+| Data minimization and boundary control | GDPR | Centralized ingress and layered architecture reduce unnecessary spread of sensitive data into lower operational layers. | Architecture supports this; actual data classification and retention rules remain deployment-specific. |
+| Product cybersecurity lifecycle | CRA | EVOLV treats release, patching, security boundaries, and configuration ownership as platform concerns rather than one-off flow edits. | Direction established; lifecycle evidence depends on maintained process. |
+| Business continuity / degraded mode | CER, NIS2 | Edge-first and site-mediated runtime design avoids full dependency on one central runtime for essential service continuity. | Strong architecture fit; continuity plans and tests still required. |
+
+## What Reviewers Can Be Told
+
+The safe statement is:
+
+- EVOLV is architected so it can be deployed in alignment with strict European cybersecurity and resilience expectations.
+
+The unsafe statement is:
+
+- EVOLV is automatically compliant by architecture alone.
+
+## Evidence Expectations
+
+To move from architecture alignment to demonstrable compliance, deployments should be able to show:
+
+- network segmentation and access-control design
+- IAM and authorization configuration
+- patch and vulnerability-management process
+- logging and incident-response process
+- backup and recovery approach
+- data-classification and retention policy
+- evidence of how local, site, and central layers behave during outages
diff --git a/Home.md b/Home.md
index cbdb336..38cbb85 100644
--- a/Home.md
+++ b/Home.md
@@ -56,6 +56,7 @@ Architecture pages:
 - [Platform Overview](Architecture-Platform-Overview)
 - [Telemetry and Smart Storage](Architecture-Telemetry-and-Smart-Storage)
 - [Security and Access Boundaries](Architecture-Security-and-Access-Boundaries)
+- [Security and Regulatory Mapping](Architecture-Security-and-Regulatory-Mapping)
 - [Configuration Model and Tagcodering](Architecture-Configuration-Model-and-Tagcodering)
 
 ```mermaid