What NIS2 Article 20(1) asks boards to approve and oversee
Article 20(1) requires Member States to ensure that the management bodies of essential and important entities approve the cybersecurity risk-management measures taken to comply with Article 21 and oversee how those measures are implemented. The duty puts cybersecurity into the category of management decisions rather than IT tasks. The risk it addresses is familiar to most boards: security programs drift when the people who fund them never formally decide what the organization is committing to, which risks are accepted, and who answers when a measure fails. Because NIS2 is a directive, this obligation reaches your entity through the national transposition law of the Member State where you are established, so the wording, the supervisor and the enforcement detail may differ by country. Confirm the local text with your national competent authority or counsel before you set your governance calendar. Approval and oversight are different acts, and the difference is where most programs struggle. Approval is a recorded decision on a specific set of measures and policies. Oversight is the ongoing duty to receive information, question it and act on it. A board can approve a policy in one meeting and never see another security report, which satisfies the first half of the duty and fails the second. The sector-specific rules in Implementing Regulation (EU) 2024/2690 make this concrete for the entities it covers: the network and information system security policy must show the date of formal approval by the management bodies and be reviewed by them at least annually. Ask your advisers to confirm whether your entity falls under that regulation, and if it does, put the annual review on the board calendar now. For a practical start, ask three questions of your current governance record. Can you show the minutes where the board approved the Article 21 measures, with the policy version and approval date? Can you name the person who reports directly to the board on network and information system security? Does the board minute show that it reviewed residual risks and accepted them, or delegated acceptance to a named accountable person with authority to manage those risks? If any answer is no, you have a gap to close before the first supervisory request. Evidence of real board engagement is what a supervisor will test, so the records need to show questions asked and decisions taken, not only that a document was circulated.
Which entities, bodies and records fall under Article 20(1)
Before the management body can approve anything under Article 20(1), the organization has to settle who is in scope, which people count as the management body, and which records prove it. The cards below cover the decisions that change who signs, how often they review, and which evidence they must hold.
Essential or important classification
Article 3 places an in-scope entity in one of two categories, and the category sets how supervision works, not whether Article 20(1) applies. Both essential and important entities must have their management bodies approve the Article 21 measures and oversee them. Check your classification against the sector annexes and size rules, and record the reasoning in the board pack so the approval rests on a settled scope.
Who counts as the management body
NIS2 leaves the definition of the management body to the entity and national law, so the answer may be a board of directors, a supervisory board, or another body with decision-making authority. Confirm the body with your national transposition law and your articles of association. Approval given by a committee or executive that the law does not recognize may not satisfy the duty.
Group structures and parent undertakings
In a group, the decision to approve measures can sit with a parent company, a subsidiary board, or both, depending on how the group is organized and what each national law requires. Map which legal entity is in scope, which board holds the approval, and whether group-wide policies count as the entity's own approved measures. Document the mapping so an authority can trace each approval to the right body.
Entities operating in several Member States
An entity may be subject to NIS2 in more than one Member State, and the jurisdiction rules determine which national authority supervises it. Confirm the lead jurisdiction and whether each national law requires its own approval record or accepts one group-level decision. Keep a register that lists each jurisdiction, the authority, and the body that approved the measures.
Digital infrastructure and digital provider entities
For DNS, TLD, cloud, data center, CDN, managed service and other covered digital entities, Implementing Regulation 2024/2690 requires the network and information system security policy to show the date of formal approval by the management bodies and to be reviewed by them at least annually. Other entities should still record approval dates, but this group must meet the policy-date and annual review duties. Confirm whether your service type falls within the regulation's scope.
Approval and review records
The approval duty is only as strong as the records that show it happened. Keep signed minutes, the approved version of each policy with its approval date, and the dates of each annual review. Confirm with counsel how long your national law expects these records to be retained and who can produce them on request from an authority.
How Implementing Regulation 2024/2690 turns approval into records
For the entity types that Implementing Regulation (EU) 2024/2690 covers, approval by the management body has to be visible in the documents themselves. The network and information system security policy must show the date of formal approval by the management bodies, and the management bodies must review it at least once a year. A policy with no approval date, or one last reviewed two years ago, fails this expectation even if the board discussed security in a meeting. Practically, that means the board minutes or resolution should reference the policy version, the policy header or document control table should carry the approval date, and the review cycle should sit in the calendar with an owner. Ask whether your policy versioning tool or document repository can show who approved each version and when.
The regulation also expects named accountability. At least one person must report directly to the management bodies on network and information system security, so the reporting line should appear in the organization chart and in the board's terms of reference, not only in a job title. Risk assessment results and residual risks must be accepted either by the management body or by accountable persons who have authority to manage those risks, and the entity must ensure adequate reporting reaches the board. The decision to delegate acceptance is therefore a governance choice to record in writing: who may accept which residual risk, up to what threshold, and what the board receives in return. Each acceptance should be traceable to a risk register entry.
These points apply to the entity types listed in the regulation, namely DNS, TLD, cloud, data center, CDN, managed and managed security service providers, online platforms and trust service providers. Other essential and important entities are not bound by these specific annex points, but Article 20(1) still applies to them through national law, and national authorities may set their own documentation expectations. Confirm with your competent authority or national transposition law how approval dates, reviews, reporting lines and risk acceptance must be evidenced for your sector. The ENISA technical implementation guidance offers examples of evidence that can help you design records, though it is non-binding.
How an assessor tests board approval and oversight
This table sets out, row by row, how an assessor tests the management body's approval and oversight duties, what evidence they ask for, and where organizations usually fall short. Read each row as a question the assessor will put to the board secretary, the CISO and the minutes. The main takeaway is that a signature alone rarely proves oversight, and the record must show that the board understood and challenged what it approved.
| Test area | Test approach and evidence requested | Common findings |
|---|---|---|
| Approval of risk measures and policy | Assessor checks that the network and information system security policy and the Article 21 measures carry a dated formal approval by the management body, and that the minutes show the item was tabled and discussed. | Approval recorded only by a sign-off sheet or email from a delegate, with no minutes showing the board reviewed the content. |
| Annual review | Assessor requests the review date history and minutes from each review cycle, confirming the policy was reviewed at least annually where the implementing regulation applies. | Policy shows an approval date from several years ago, or reviews happened but were not recorded in board minutes. |
| Direct reporting line | Assessor confirms that at least one named person reports directly to the management body on network and information system security, through a reporting line in the terms of reference or org chart and dated briefings. | The security lead reports only to a delegate such as a CIO or operations head, so the board never hears from security directly. |
| Risk acceptance records | Assessor reviews the risk register, residual risk decisions and the acceptance record, checking who accepted each residual risk and whether that person held authority to manage it. | Residual risks accepted by a mid-level manager with no delegated authority, or accepted with no record of the reporting that informed the decision. |
| Regular status reporting to the board | Assessor requests the periodic compliance and security status reports presented to the board, looking for trends, open actions and decisions taken in response. | Reports are presented as a slide deck with green indicators, with no minutes showing questions asked, challenge raised or follow-up requested. |
| Receipt of independent review results | Assessor asks for independent audit, penetration test or assessment reports and evidence that the board received them and tracked remediation. | Independent findings are filed with the security team but never tabled at board level, or no evidence of challenge to the remediation plan exists. |
Steps to get board approval and oversight working
This sequence turns the Article 20(1) duty into a working cycle: the management body knows what it approves, who reports to it, how risk is accepted, and when it reviews the program. Each step closes with a record the board or an assessor can inspect.
Map the management body and its decision rights
Start by identifying who sits on the management body in your entity, how it is constituted under your national transposition law, and which decisions it reserves for itself versus delegates to executives or committees. Legal counsel and the company secretary should confirm the list against the articles of association or equivalent governing documents. The output is a short decision-rights register that names each board decision on cybersecurity, its approver and its delegate. You know this step is done when every Article 21 measure has a named approver.
Define the Article 21 measures the board must approve
Work with the security function to list the cybersecurity risk-management measures the entity has adopted under Article 21, including the policies, technical controls and processes that support them. Separate the items that require formal board approval, such as the network and information system security policy, from operational procedures that management can approve internally. The output is an approval inventory showing each item, its version, its owner and whether board approval is required. Confirm the boundary with your national authority or sector guidance where the transposition law is unclear.
Set the reporting cadence and content
Agree with the board how often it receives compliance reporting on network and information system security and what each report must contain. Typical content includes the status of Article 21 measures, open risks, significant incidents, audit findings and supplier concerns, though the exact set should come from your own risk profile. Draft a one-page report template and a standing agenda item. The output is an approved reporting calendar and template that the board has accepted in a minute. You know this step is done when the first scheduled report is in the calendar with a named author.
Assign the direct-reporting role
Designate at least one person who reports directly to the management body on network and information system security, as the implementing regulation requires for in-scope digital entities. This is usually a CISO, a security officer or a designated executive, and the role should carry the authority and access needed to brief the board without filtering through intermediate layers. Record the appointment in board minutes and update the role description. The output is a signed appointment and a documented reporting line from the role holder to the board. Confirm with your counsel whether the role must also be notified to the national authority.
Establish risk acceptance rules
Define who may accept residual cybersecurity risk and up to what level. The board can accept risk directly, or it can delegate acceptance to accountable persons with the authority to manage risk, provided the entity ensures adequate reporting back to the board. Write the acceptance thresholds, the approval path for each tier, the expiry rules for accepted risks and the escalation trigger for anything outside appetite. The output is a risk acceptance procedure and a register of currently accepted risks, each with an approver and a review date. An assessor will check that accepted risks match the authority granted in this procedure.
Schedule annual policy review and independent review intake
Put the annual review of the network and information system security policy on the board calendar, with the board's formal approval recorded and the approval date shown on the document. Also schedule the intake of independent review results, such as internal audit reports, external assessments and penetration test summaries, so the board receives them and can direct remediation. The output is a multi-year governance calendar and a documented intake path for review findings. Confirm the exact review scope with your sector's supervisor, since the implementing regulation sets the minimums for certain entity types.
Run the first approval cycle and record the decisions
Present the policy set, the approval inventory, the reporting template, the risk acceptance procedure and the review calendar to the management body in a single session. Record each decision with the version approved, the date and any conditions attached. Confirm that minutes show board members engaged with the material rather than noting it as received. The output is signed board minutes and approved documents with visible version and approval dates. These records become the primary evidence a supervisor will ask to see when testing Article 20(1).
Which evidence satisfies Article 20(1) and how to keep it current
Article 20(1) is tested by what the management body has actually approved, reviewed and accepted, and by whether that record is current. The six artifacts below form one chain: approval, policy, reporting line, risk decisions, periodic reporting and independent review. Each needs an owner and a recurring trigger so the record still holds between audits.
Dated management body approval minutes
Minutes or written resolutions showing the management body approved the Article 21 cybersecurity risk-management measures, with the date, attendees and the measures named. Assessors look for a decision, not attendance alone. Check that the minutes name the measures or the policy version approved, so the approval can be tied to a specific document. Keep the minutes in the governance record and reference them from the policy itself. Ask counsel to confirm the approval form your national transposition law requires.
Signed policy with approval history
The network and information system security policy, with a version history showing each formal approval date by the management bodies and each review. For digital infrastructure and digital provider entities, Implementing Regulation 2024/2690 requires the policy to show that approval date and to be reviewed by the management bodies at least annually. Keep a change log that records what changed and why. A policy with no approval date fails this test even if the content is sound.
Defined reporting line to the board
A written statement naming at least one person who reports directly to the management bodies on network and information system security, with the reporting frequency and escalation path. Implementing Regulation 2024/2690 requires this direct line. Check that the named person has the authority and time to act, and that the role appears in the organization chart and job description. Update the record whenever the role changes hands, since a vacant or unnamed role is an immediate finding.
Risk acceptance records with rationale
Records showing that the management body, or an accountable person with authority to manage risks, accepted each assessed risk result and residual risk. Each record should state the risk, the treatment chosen, the residual risk level, the rationale and the expiry or review date. Under the implementing regulation, acceptance is valid only when the entity ensures adequate reporting to the management bodies. Schedule re-acceptance when a residual risk changes or when a risk reaches its review date.
Periodic compliance reports to the board
Regular reports giving the management body the status of network and information system security, such as open risks, incident trends, overdue remediation and control gaps. The implementing regulation requires management bodies to be informed through regular compliance reporting. Set a fixed cadence and a standard template so reports can be compared over time. Keep each issued report with its date and the minutes showing it was discussed. A report that is written but never tabled leaves no proof of oversight.
Independent review summaries for the board
Summaries of independent reviews, such as internal audit findings, external assessments or penetration test results, delivered to the management body with the actions decided. The implementing regulation requires management bodies to receive the results of independent reviews. Record who reviewed, the scope, the findings, the decision taken on each finding and the closure evidence. An independent assessor or certification body issues its own reports; the summary here shows how the board used them.
Who owns the board decisions, the partner work and the auditor role
The management body of an essential or important entity owns the decisions that Article 20(1) describes. Its members approve the cybersecurity risk-management measures taken to meet Article 21, oversee how they are implemented, and, under Implementing Regulation 2024/2690, accept residual risk or delegate that acceptance only to accountable persons who hold the authority to manage risk and who report back adequately. Accountability stays with the board even when work is delegated, so the board cannot treat a partner's report as its own decision.
- Policy approval: The board approves the network and information system security policy and records the date of formal approval. For digital infrastructure and digital provider entities, the policy must also be reviewed at least annually.
- Reporting line: At least one person must report directly to the management body on network and information system security, so the board hears from someone it can question.
- Risk acceptance: Board minutes should show which residual risks were accepted, by whom, and on what basis.
- Oversight of status: The board should receive regular compliance reporting and the results of independent reviews.
- Documented decisions: Keep minutes and briefing packs that show the board actually deliberated, since these are the first records a supervisor asks for.
Before relying on any of this, confirm with counsel which national transposition law applies and what it requires of the board in your Member State.
An implementation partner such as DeployOpen works on the systems and paperwork that the entity's own people then review and decide. In practice this means drafting the policy set, building reporting templates, maintaining risk registers, assembling evidence packs and preparing material for board briefings. The partner can facilitate those briefings and explain technical findings in plain language. It does not approve policies, accept risk, or sign off on compliance on the entity's behalf.
- Policy drafts: The partner prepares draft policies for the board to review and approve, with the approval date field left for the board to complete.
- Reporting templates: Standard formats for the direct report to the board and for periodic compliance status updates.
- Risk registers: Current records of risks, treatments and residual risk, owned by the named accountable persons.
- Evidence packs: Organized outputs from self-hosted tools, such as configuration exports, review records and test results, mapped to the requirement they support.
- Briefing support: Preparation and facilitation of board sessions, with the decisions and any risk acceptance recorded by the entity.
When scoping a partner, ask which of these items will be delivered, who will sign each one, and which decisions remain with named people in the entity.
Testing and reporting belong to parties independent of the entity and of its implementation partner. Depending on the entity and the Member State, that may be a national competent authority that inspects, requests information and runs security audits or scans, or an independent auditor or assessor engaged by the entity for an assurance exercise. NIS2 creates no certificate of compliance, so no single document settles conformity. An independent party is the one that issues any audit report or attestation, and DeployOpen does not issue audit reports, attestations or certifications.
- Testing: The auditor or authority examines whether the board's approval, oversight and reporting are real, not only documented.
- Reporting: Findings go to the entity and, where relevant, to the authority. The board must receive the results of independent reviews.
- Independence: A partner that helped build the evidence should not also be the party that tests it for assurance, and the entity should check the auditor's own independence rules.
- Scope of outsourcing: Drafting, tooling and evidence collection are commonly outsourced. Approval, risk acceptance and accountability are not.
- Authority requests: Expect supervisors to ask for approval records, reporting lines and risk acceptance evidence.
Before engaging an auditor, confirm which supervisor applies to your entity and what assurance format it accepts.
What meeting Article 20(1) costs in money and effort
The main cost of Article 20(1) is management time, and it is mostly one-time setup followed by a recurring review cycle. Article 20(1) requires the management body to approve the Article 21 measures and oversee them, so the board or its delegated committee pays in meeting hours to read the network and information system security policy, question the risk assessment and accept residual risk. Implementing Regulation (EU) 2024/2690 adds recurring obligations: the policy must show the date of formal approval and be reviewed at least annually for digital infrastructure and digital provider entities (Annex, points 1.1.1(k) and 1.1.2). Expect the first cycle to be the heaviest, because the board must be briefed on the full scope, and later cycles to be shorter if reporting is stable.
Staff time is the second cost, and it is usually larger than the board's. The entity's security lead, or whoever is named as the person reporting directly to the management body under point 1.2.3, must draft the status reports, collect evidence from owners of each control and keep the risk register current. These are recurring costs that grow with the number of systems, sites and suppliers. External preparation work, such as mapping the policy set to the Article 21 measures or building the reporting pack, is typically a one-time fixed-scope engagement. Tooling is the third component. Much of the evidence can come from self-hosted open-source platforms running in the entity's own infrastructure, but licence terms differ between projects, so confirm them before relying on a tool for a supervisor-facing record.
Independent review is the cost most often underestimated. Point 2.3.3 requires that the management body receives the results of independent reviews, so an external assessor's fee is a recurring line item if the entity commissions periodic reviews. Ask every provider for a quote that separates one-time items (initial mapping, policy set, reporting template) from recurring items (annual policy review, quarterly reporting support, review fees). Ask who is paid for each deliverable, what is excluded from scope, how many board cycles are included, and how changes to scope are priced. No quote figure appears here because prices follow from the written scope, and the reader should treat any number without a written scope as a placeholder.
Where boards and entities usually fall short
Why is informal board approval of cybersecurity measures a problem under NIS2?
Informal approval is hard to defend because Article 20(1) expects management bodies to approve the Article 21 measures, and a supervisor will ask for proof of that approval. A verbal agreement in a meeting or an email thread without a clear decision leaves no dated record of what was approved and when. The fix is to table the cybersecurity risk-management measures and the network and information system security policy as agenda items, record the decision in the minutes with the approval date and the version approved, and store the signed or minuted version with the policy itself. For digital infrastructure and digital provider entities, Implementing Regulation 2024/2690 requires the policy to show the date of its formal approval, so the date must be in the document, not only in the minutes.
What happens when no named person reports directly to the board on security?
Without a named person, the board has no clear channel for security information, and no one is accountable for telling it when something goes wrong. Implementing Regulation 2024/2690 requires at least one person to report directly to the management bodies on network and information system security for the entities it covers. The fix is to appoint that person in writing, define their reporting line and access to the board, and give them a standing agenda slot. Organizations often assign this role to a CISO, a security officer, or a vCISO, but the appointment must match the entity's actual structure and the person needs enough authority to be heard.
Can a department manager accept a cybersecurity risk on behalf of the company?
Only if that manager has the authority to manage the risk, and only when the board or an accountable person with that authority is informed. Under Implementing Regulation 2024/2690, risk assessment results and residual risks are accepted by the management bodies or by accountable persons with authority to manage risks, provided the entity ensures adequate reporting to the management bodies. The fix is a written risk acceptance matrix that names who may accept which risk levels, sets a review date for each accepted risk, and routes higher residual risks to the board. Any acceptance made outside that matrix should be treated as an open finding until it is re-approved.
How do you make cybersecurity reports useful for board decisions?
Board reports work when they show business impact, risk trends and decisions needed, not raw technical output. A report that lists thousands of alerts or scanner findings gives directors no basis for a decision, so they approve nothing or defer everything. The fix is a short, recurring report that covers the status of the measures against the Article 21 areas, the top residual risks with owners and dates, incidents and near misses, open remediation items with budget implications, and the specific decisions requested. Technical detail belongs in an appendix that the security lead can explain when asked. Ask the board which questions it needs answered each quarter and build the report around those questions.
What is the consequence of missing the annual review of the security policy?
A missed annual review means the policy is out of date, and the entity cannot show that the board reviewed it as the implementing regulation requires. For digital infrastructure and digital provider entities, Implementing Regulation 2024/2690 requires the network and information system security policy to be reviewed by the management bodies at least annually. The fix is a governance calendar that puts the policy review on the board's agenda each year, assigns an owner to prepare the review, and records the outcome, including changes made or a decision that no change was needed. Trigger an earlier review after a significant incident, a major change in systems or suppliers, or a change in the regulatory baseline.
Why do independent review results often never reach the board?
Independent reviews often stop at the audit team or the security manager because no one is assigned to escalate them, and the board never sees the findings. Implementing Regulation 2024/2690 requires management bodies to be informed of the status of network and information security through regular compliance reporting and to receive the results of independent reviews. The fix is to make receipt of review results a fixed step in the reporting process: the reviewer's summary goes to the board, the board records what it received, and the remediation plan for each significant finding is tracked to closure. Penetration tests, internal audits and external assessments all belong in this flow, and the board minutes should show the review was presented.
How DeployOpen prepares board governance evidence
DeployOpen works on Article 20(1) by preparing the systems, policy records and reporting lines that show a management body approving and overseeing the Article 21 measures. The organization keeps ownership of its controls and decisions, and only an independent assessor or the competent authority can judge whether the evidence is sufficient.
How we scope
- Written scope names the entities, systems and policy set the management body must approve.
- Scope records which reports, reviews and risk acceptances the board will receive and how often.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We prepare the network and information system security policy with a field for formal approval date and annual review.
- We design a direct reporting line to the management body for the accountable security person.
- We set up a risk acceptance record that captures residual risk, the accepting role and the reporting trail.
How we hand over
- We deliver the approved policy set, reporting templates, risk acceptance records and meeting minutes format.
- We document how board reports are produced from the platforms, so the organization can repeat them without DeployOpen.
- We walk management through the evidence pack and record which items the organization still needs to confirm.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can keep board reporting current as systems change, policies come up for annual review and new risks arise.
- Confirm with your own counsel and the relevant national authority which Article 20 duties apply to your entity.
