Extend architecture review with security positioning

architecture/stack-architecture-review.md

@@ -364,7 +364,77 @@ Questions still open:
 - telemetry transport or only synchronization/eventing?
 - durability expectations and replay behavior?
 
-## 7. Recommended Ideal Stack
+## 7. Security And Regulatory Positioning
+
+### 7.1 Purdue-style layering is a good fit
+
+EVOLV's preferred structure aligns well with a Purdue-style OT/IT layering approach:
+
+- PLCs and field assets stay at the operational edge
+- edge runtimes stay close to the process
+- site systems mediate between OT and broader enterprise concerns
+- central services host APIs, identity, analytics, and engineering workflows
+
+That is important because it supports segmented trust boundaries instead of direct enterprise-to-field reach-through.
+
+### 7.2 NIS2 alignment
+
+Directive (EU) 2022/2555 (NIS2) requires cybersecurity risk-management measures, incident handling, and stronger governance for covered entities.
+
+This architecture supports that by:
+
+- limiting direct exposure of field systems
+- separating operational layers
+- enabling central policy and oversight
+- preserving local operation during upstream failure
+
+### 7.3 CER alignment
+
+Directive (EU) 2022/2557 (Critical Entities Resilience Directive) focuses on resilience of essential services.
+
+The edge-plus-site approach supports that direction because:
+
+- local/site layers can continue during central disruption
+- essential service continuity does not depend on one central runtime
+- degraded-mode behavior can be explicitly designed per layer
+
+### 7.4 Cyber Resilience Act alignment
+
+Regulation (EU) 2024/2847 (Cyber Resilience Act) creates cybersecurity requirements for products with digital elements.
+
+For EVOLV, that means the platform should keep strengthening:
+
+- secure configuration handling
+- vulnerability and update management
+- release traceability
+- lifecycle ownership of components and dependencies
+
+### 7.5 GDPR alignment where personal data is present
+
+Regulation (EU) 2016/679 (GDPR) applies whenever EVOLV processes personal data.
+
+The architecture helps by:
+
+- centralizing ingress
+- reducing unnecessary propagation of data to field layers
+- making access, retention, and audit boundaries easier to define
+
+### 7.6 What can and cannot be claimed
+
+The defensible claim is that EVOLV can be deployed in a way that supports compliance with strict European cybersecurity and resilience expectations.
+
+The non-defensible claim is that EVOLV is automatically compliant purely because of the architecture diagram.
+
+Actual compliance still depends on implementation and operations, including:
+
+- access control
+- patch and vulnerability management
+- incident response
+- logging and audit evidence
+- retention policy
+- data classification
+
+## 8. Recommended Ideal Stack
 
 The ideal EVOLV stack should be layered around operational boundaries, not around tools.
 
@@ -446,7 +516,7 @@ These should be explicit architecture elements:
 - versioned configuration and schema management
 - rollout/rollback strategy
 
-## 8. Recommended Opinionated Choices
+## 9. Recommended Opinionated Choices
 
 ### 8.1 Keep Node-RED as the orchestration layer, not the whole platform
 
@@ -501,7 +571,7 @@ The architecture should be designed so that `tagcodering` can mature into:
 - site/central configuration exchange point
 - API-served configuration source for runtime layers
 
-## 9. Suggested Phasing
+## 10. Suggested Phasing
 
 ### Phase 1: Stabilize contracts
 
@@ -533,13 +603,13 @@ The architecture should be designed so that `tagcodering` can mature into:
 - advisory services from central
 - auditability of downward recommendations and configuration changes
 
-## 10. Immediate Open Questions Before Wiki Finalization
+## 11. Immediate Open Questions Before Wiki Finalization
 
 1. Which signals are allowed to use reconstruction-aware smart storage, and which must remain raw or near-raw for audit/compliance reasons?
 2. How should `tagcodering` be exposed to runtime layers: direct database access, a dedicated API, or both?
 3. What exact responsibility split should EVOLV use between API synchronization and broker-based eventing?
 
-## 11. Recommended Wiki Structure
+## 12. Recommended Wiki Structure
 
 The wiki should not be one long page. It should be split into:
 
@@ -549,6 +619,6 @@ The wiki should not be one long page. It should be split into:
 4. security and access-boundary model
 5. configuration architecture centered on `tagcodering`
 
-## 12. Next Step
+## 13. Next Step
 
 Use this document as the architecture baseline. The companion markdown page in `architecture/` can then be shaped into a wiki-ready visual overview page with Mermaid diagrams and shorter human-readable sections.