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:

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