Add compliance positioning to security page

Architecture-Security-and-Access-Boundaries.md

@@ -24,6 +24,87 @@ flowchart TD
 - Site and edge layers receive bounded requests, advice, or setpoints.
 - Edge remains protected behind intermediate layers.
 
+## Purdue-Aligned Segmentation
+
+EVOLV is designed to fit a Purdue-style industrial segmentation model:
+
+- field and PLC assets remain at the lower operational layers
+- edge runtimes sit close to the process and are not exposed as public integration surfaces
+- site systems mediate plant-local services and isolate OT from broader enterprise traffic
+- central services host APIs, identity, analytics, and engineering functions above the plant boundary
+
+This matters because it gives a clear answer to external reviewers:
+
+- EVOLV does not require direct enterprise-to-field access
+- EVOLV can preserve layered trust boundaries between PLCs, edge runtimes, site services, and central platforms
+- EVOLV can support zone/conduit style security designs instead of flattening OT and IT into one network
+
+## European Regulatory Positioning
+
+EVOLV should be described as an architecture that can support compliance with strict European requirements, not as a system that is automatically compliant by default.
+
+### NIS2
+
+Directive (EU) 2022/2555 (NIS2) requires cybersecurity risk-management measures and incident handling for important and essential entities.
+
+This architecture supports that direction by:
+
+- separating edge, site, and central responsibilities
+- reducing direct exposure of operational assets
+- allowing central policy, identity, logging, and oversight
+- preserving local operation during upstream disruption
+
+### CER
+
+Directive (EU) 2022/2557 (Critical Entities Resilience Directive) focuses on resilience of essential services.
+
+This architecture supports CER-style resilience expectations by:
+
+- keeping local and site operation viable during central outages
+- enabling business-continuity and degraded-mode operation
+- supporting multiple operational layers instead of one central dependency
+
+### Cyber Resilience Act
+
+Regulation (EU) 2024/2847 (Cyber Resilience Act) sets horizontal cybersecurity requirements for products with digital elements.
+
+Where EVOLV components are packaged, distributed, and maintained as digital products, the platform direction supports CRA-aligned engineering by:
+
+- avoiding hard-coded secrets in tracked manifests
+- treating updates, identity, security boundaries, and lifecycle management as platform concerns
+- supporting traceable releases through central source control and CI/CD
+
+### GDPR
+
+Regulation (EU) 2016/679 (GDPR) applies where EVOLV processes personal data.
+
+The architecture helps support GDPR obligations by:
+
+- centralizing external API ingress
+- limiting unnecessary spread of sensitive data toward field layers
+- enabling clearer control over access, logging, and retention boundaries
+
+## What We Can Defensibly Claim
+
+The safe and accurate claim is:
+
+- EVOLV can be deployed in a way that aligns with strict European cybersecurity and resilience expectations
+- EVOLV can support Purdue-style layered OT/IT segmentation
+- EVOLV can be engineered to satisfy strong governance, audit, and access-control requirements
+
+The claim that should be avoided is:
+
+- "EVOLV is automatically compliant"
+
+Actual compliance still depends on:
+
+- configuration
+- site implementation
+- monitoring and incident response
+- supplier and patch management
+- data-classification and retention policy
+- documented operational controls
+
 ## Why This Matters
 
 - lower exposure of OT assets