Reading NIS2 as an engineering specification

The Network and Information Security Directive (NIS2) is most often discussed as a compliance obligation — a set of boxes to check, a risk-assessment template to fill, an incident-reporting timeline to meet. This reading misses the more interesting question: what does NIS2 imply about how systems should be engineered?

Read as an engineering spec, NIS2 makes several implicit architectural demands that are worth surfacing explicitly.

Supply-chain provenance is not optional

Article 21(2)(d) requires measures for "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." In engineering terms: you need a documented, auditable supply-chain provenance model. Not a vendor questionnaire — a model that connects component identity to supply-chain node identity, with cryptographic attestation where possible.

Incident reporting implies instrumentation

The 24-hour initial notification requirement (Article 23) is not just a process requirement — it is an instrumentation requirement. You cannot report what you cannot detect. Systems that will be subject to NIS2 need detection pipelines that can surface anomalies within hours, not days.

Risk assessment requires evidence

Article 21(1) requires "appropriate and proportionate technical, operational, and organisational measures to manage the risks." The word "proportionate" implies a risk assessment that is evidence-based, not checkbox-based. A proportionate response to risk requires understanding the risk quantitatively — which in turn requires the kind of source-tier evidence framework we use at Zhianrui.