NIS2 Article 21 requires in-scope entities to take appropriate and proportionate technical, operational and organisational measures. A CTO can treat its list as a backlog: each measure becomes an owned work item with evidence. Start with incident reporting, supply chain security, vulnerability handling and access control.
What does Article 21 actually list?
The directive names these areas: risk analysis and system security policies; incident handling; business continuity such as backup and crisis management; supply chain security, including relationships with direct suppliers; security in acquiring, developing and maintaining systems, including vulnerability handling and disclosure; policies to assess the effectiveness of measures; basic cyber hygiene and training; cryptography and encryption; human resources security, access control and asset management; and multi-factor or continuous authentication where appropriate.
Measures must be proportionate to risk, size and the cost of implementation, and they take an all-hazards approach. There is no fixed control list beyond this, which is why the mapping work matters.
How do I map it to engineering work?
Write one row per measure, with an owner, the artefact that proves it and the review date. A constructed slice:
- Supply chain security: dependency inventory per service, a review step for new third party components, supplier contacts for incidents.
- Secure development and vulnerability handling: triage rules with target fix times by severity, a disclosure contact and a published security.txt style address.
- Access control and MFA: SSO for all admin tools, quarterly access reviews, break-glass accounts that alert.
- Business continuity: restore tests with recorded results, not just backup jobs.
- Effectiveness: a recurring exercise, such as a tabletop on a supplier compromise, with actions tracked.
Evidence wins audits and customer reviews. A policy without a record of use is weak.
How do I handle the reporting clock?
Article 23 sets an early warning within 24 hours of awareness of a significant incident, an incident notification within 72 hours and a final report within one month of that notification. Awareness is the hard part for engineering: the clock depends on you recognising an incident as significant. Define what significant means in your context, who decides, and how fast. Rehearse the decision with a realistic scenario.
Where does the board come in?
The directive makes management bodies approve the risk measures and oversee implementation, and it allows them to be held liable. Give them a short quarterly view: open risks, incidents, supplier concerns and progress on the backlog. Keep the minutes.
What about suppliers?
Your obligations extend to supply chain risk, so your own vendors and open source dependencies are part of the scope. Ask critical suppliers for incident notice terms and security evidence. For open source, keep a current SBOM per release so you can answer "are we affected" within hours when a component is disclosed as vulnerable. Safeguard's SBOM and dependency scanning, plus reachability analysis, can help with that question.
What to do
- Confirm scope and the national law that applies.
- Build the Article 21 matrix with owners and evidence.
- Define significant incident, the decider and the 24 hour, 72 hour and one month steps.
- Set vulnerability fix targets and publish a disclosure contact.
- Generate an SBOM for each release and store it.
- Run a supplier incident exercise and record the lessons.
- Report to management on a fixed schedule.
Quick check
Does Article 21 prescribe specific tools?
No. It lists areas that measures must cover and requires them to be appropriate and proportionate. You choose the controls and keep evidence that they work.
When does the 24 hour clock start?
At the point the entity becomes aware of a significant incident, according to Article 23. Your process should define how awareness and significance are decided.
Sources
Last reviewed: 18 October 2026.
