Which policies NIS2 requires, and what each must cover

Which policies does NIS2 require for an essential or important entity?

The core requirement is Article 21(2)(a) of NIS2, which requires policies on risk analysis and information system security. Implementing Regulation (EU) 2024/2690 sets the content of that foundation in its Annex: the security policy must set security objectives, commit to continual improvement and resources, list the topic-specific policies the entity maintains, state documentation retention periods, and be reviewed by the management body at least annually. The management body's annual review is the point where the policy becomes binding on the organization, so the first decision is to name who reviews it, when, and how the review is recorded.

The exact set of policies depends on the entity's sector, its services and whether the implementing regulation applies to it directly. Entities covered by Regulation 2024/2690 (such as DNS, cloud, data center, managed service and trust service providers) work to its full Annex, while other essential and important entities use the same Article 21 measures as the baseline for their own policy set. ENISA's June 2025 guidance lists ten topic-specific policies the implementing regulation requires to be documented, and the sibling sections cover each. Confirm with your national competent authority and your sector rules which of these apply to you, and record that decision in writing, because it is the first thing a supervisor will ask about.

The organization owns and approves every policy. Its management body adopts the security policy, and named policy owners are accountable for each topic policy. An implementation partner can draft, harmonize and maintain the documents, map them to the measures they support, and set up the review cycle, but the partner cannot approve them or make the risk decisions they contain. A national competent authority, or an independent assessor where one is engaged, checks the policies and whether staff follow them. No certifier issues a NIS2 certificate, so a policy set that looks complete on paper still has to match how the organization actually operates.

Which topic-specific policies ENISA's June 2025 guidance identifies

ENISA's June 2025 guidance identifies ten topic-specific policies that the implementing regulation expects to be documented. The guidance is non-binding, so treat this list as a reading aid for Implementing Regulation (EU) 2024/2690, not as a legal checklist. The cards below cover six of these policy areas, with what each policy should contain and the evidence a supervisor would expect to see.

Risk analysis and security policy

The information system security policy sets security objectives, commits management to continual improvement and resources, lists the topic-specific policies and states how long documentation is kept. Management bodies must review it at least annually. Check that the policy names who accepts residual risk and links to the current risk treatment plan. A supervisor will ask for the signed policy, the review minutes and the risk treatment plan that the policy governs.

Incident handling

The incident handling policy must set an incident categorization system, communication plans for escalation and reporting, and named response roles. Supporting documents include a response manual, an escalation chart, contact lists and reporting templates. Check that the categories match the criteria your team uses to decide whether an incident is significant, and that contact details are current. A supervisor will ask for the current manual, the contact list with its last update date and records of past exercises.

Supply chain security

The supply chain policy must define supplier selection criteria. These cover cybersecurity practices, the ability to meet security specifications, product quality and resilience, and the ability to diversify supply and limit vendor lock-in. Check that the criteria apply at renewal and change, not only at onboarding. A supervisor will ask for the criteria, completed assessments for critical suppliers and the plan for replacing a supplier that fails them.

Cryptography

The cryptography policy sets the type, strength and quality of cryptographic measures for data at rest and in transit, scaled to asset classification. Check that the chosen standards are written into the policy, that key management and rotation duties have named owners, and that exceptions are recorded with an approver. A supervisor will ask for the asset classification the policy relies on, an inventory of where cryptography is used and the exception register.

Security testing and effectiveness

The policy and procedures for assessing whether measures are effectively implemented and maintained must take into account the risk assessment and past significant incidents. Check that testing covers the measures the risk assessment ranks highest, and that findings feed back into the risk register with owners and deadlines. A supervisor will ask for the testing schedule, recent test reports, remediation tracking and evidence that past incidents changed the test scope.

Access control

The access control policy must define who may use which systems, how access is granted, reviewed and removed, and how privileged accounts are handled. Check that it covers joiners, movers and leavers, and that administrators use separate accounts for privileged work. A supervisor will ask for the policy, the most recent access review with sign-off and logs showing privileged sessions.

What the incident handling, supply chain and cryptography policies must include

The incident handling policy under point 3.1.2 of the Annex to Implementing Regulation (EU) 2024/2690 must do more than state that incidents will be handled. It needs an incident categorization system that lets responders sort events by severity and type, so the right people are pulled in and the Article 23 clock decisions can be made consistently. Alongside it, the policy must set communication plans for escalation and for reporting, name the roles that act during a response, and point to the supporting documents: a response manual, an escalation chart, a contact list and reporting templates. Ask your team to show, for one tabletop scenario, who is paged first, who decides whether an incident is significant, and where the draft early warning is written. If the answer depends on one person's memory, the policy is not finished.

The supply chain security policy under point 5.1.2 requires supplier selection criteria, and the regulation names four areas to cover. The first is the supplier's cybersecurity practices. The second is its ability to meet the security specifications you set for the product or service. The third is product quality and resilience. The fourth is the ability to diversify supply and limit vendor lock-in. Each criterion should be written down as a question the buyer must answer before contract signature, with the evidence accepted for the answer. A practical starting point is to record which critical services depend on a single provider and what exit path exists if that provider fails. The policy is the rule; the supplier file is where the decision is recorded, so keep both current.

The cryptography policy under point 9.2(a) must set the type, strength and quality of cryptographic measures for data at rest and for data in transit, and the level of protection must follow the asset classification. This means the classification scheme and the cryptography rules have to agree. Highly sensitive assets need stronger and more tightly controlled measures than low-impact ones, and the policy should say who approves exceptions. Confirm with your security architects which algorithms, key lengths and protocol versions are approved, and how key lifecycle is managed, since the regulation's wording sets the requirement but the technical settings are yours to define and justify. For self-hosted platforms, check that backups and replicas are covered by the same rules as primary storage, because a weaker copy is a common gap in audits.

How to write, approve and maintain the policy set

This sequence turns the policy requirements into a controlled document set that management has approved, staff know, and each measure can be traced to. Each step produces a named artifact, so the set can be shown to a competent authority as a working system rather than a folder of templates.

Inventory policies against the implementing regulation
Start by listing every policy the Annex to Implementing Regulation (EU) 2024/2690 expects to see documented, including the information system security policy and the topic-specific policies ENISA identifies in its June 2025 guidance. Map each policy to the Annex section that requires it, and note any existing documents that already cover part of it. The output is a policy register with one row per required policy, its Annex reference, and the status of any existing document. The step is complete when no required topic is left without a row.
Assign a named owner to each policy
Give every policy one accountable owner from the business or technical function that runs the activity, such as the head of IT operations for the access control policy or the supplier risk lead for the supply chain security policy. The management body remains accountable for the overall security policy, so record that separately. The output is the policy register extended with an owner, a deputy, and a review date field. The step is complete when each owner has confirmed in writing that they accept the role.
Draft policies from the risk assessment
Write each policy from the current risk assessment and asset classification rather than from generic templates, so that the stated objectives, roles and rules address the risks you actually recorded. Set out the cryptography policy by asset class, the incident handling policy with its categorization system and escalation roles, and the supply chain policy with its supplier selection criteria. The output is a draft for each policy, each citing the risk entries it addresses. The step is complete when every risk treatment decision that requires a rule has a policy clause behind it.
Obtain management body approval
Present the security policy and the topic-specific policy set to the management body, which must approve the Article 21 measures and oversee their implementation. The security policy should state its objectives, the commitment to continual improvement and resources, the list of topic-specific policies, and the document retention periods. The output is a dated approval record, with the minutes or written resolution naming the version approved. The step is complete when the approved version number is recorded in the policy register.
Publish policies and train staff
Publish approved policies in a controlled location that staff can reach, and remove superseded copies so that only one version is in circulation. Brief each group of staff on the policies that apply to their role, and provide the incident handling contacts and procedures to those who must act during an incident. The output is a publication record with version numbers and distribution scope, plus attendance or acknowledgment records for the training. The step is complete when each policy owner has confirmed that the affected staff have received the version in force.
Link each policy to measures and evidence
Build a traceability table that connects each policy to the measures it supports, the procedures that implement those measures, and the evidence that shows they operate, such as logs, backup reports, access reviews, or test results. Confirm the evidence source against ENISA's examples of evidence for the relevant requirement. The output is a traceability matrix that a supervisor can follow from policy to proof. The step is complete when every policy row has at least one evidence source and an owner for that evidence.
Review policies at least annually
Review the security policy at least once a year, as the implementing regulation requires for management body review, and review topic-specific policies when risks, incidents, systems or suppliers change. Each review checks the register, the risk assessment, the lessons from significant incidents, and the evidence gathered in the period. The output is a review record showing what was checked, what changed, and who approved the new version. The step is complete when the review record is approved by the management body and the register shows the next review date.

Who writes, approves and checks each policy

The management body is accountable for the Article 21 measures under NIS2, and the policies are the written form of that accountability. Management approves the information system security policy, sets the security objectives and commits the resources the policy describes. Named policy owners, usually the CISO or the head of IT security, hold the day-to-day responsibility for each topic-specific policy and for keeping it current.

Approval: the management body formally approves the information system security policy and records the approval date and version.
Annual review: management reviews the policy set at least once a year, as the implementing regulation requires, and records decisions and changes.
Risk acceptance: the body decides who accepts residual risk, and that decision is written down with the risk treatment plan.
Ownership: each topic-specific policy names an owner with defined roles, responsibilities and authorities.
Training: members of the management body complete the cybersecurity training NIS2 requires for them.

Confirm with your national competent authority how it expects approval and review records to look, and check who signs for your entity under your own governance rules.

How long to keep policy documents and the evidence behind them

The information system security policy must state documentation retention periods, and the organization sets those periods itself. Implementing Regulation (EU) 2024/2690 asks for the periods to be written down as part of the policy, but it does not give a number that applies to every entity. The right period depends on the entity's national transposition law, any sector-specific rules that apply to it, limitation periods for claims, and its own contracts with customers and suppliers. Confirm retention rules with your national transposition law and qualified counsel before you fix any figure in the policy. Record the rule you adopt, the legal basis for it, and the date it was approved, so an assessor can see why the period was chosen.

A retention period only helps if you can show which version of a policy was in force on a given date. Keep each policy as a versioned record with an owner, an approval date from the management body, the date of the last annual review, and a log of changes with the reason for each. Store superseded versions instead of overwriting them, and keep the review minutes that show management read and approved the document. When a competent authority asks what the access control policy said during a past incident, you can then answer from records rather than reconstruct them from memory. Ask your GRC or document system vendor whether it keeps immutable version history and export logs, and test a retrieval of an older version before you rely on it.

Why policy projects stall and how to avoid it

Most NIS2 policy projects fail after the documents are written, not while they are drafted. The pitfalls below share one cause: the policy describes an intent that no system, owner or record backs up. Each fix ties the policy to a check a supervisor would run.

Templates without matching systems

A policy copied from a template often names tools, roles or networks the organization does not run. A supervisor who asks for the policy and then for the configuration will see the gap at once. Before approval, walk each policy statement against the real system, owner and ticket queue. Where a statement cannot be matched, either change the policy or fix the system and record the change. For example, a logging policy that promises 12 months of retention but has no log store configured is a finding on day one.

No management sign-off

The security policy must be approved and overseen by the management body, and a policy approved only by the security team is hard to defend. Record the approval with the approver's name, role, date and version number, and keep the minutes or written approval in the same repository. Confirm with counsel which body counts as the management body in your national law, since the transposition text varies by Member State.

Policies that are not followed

A policy that exists but is not applied is the most common finding in an inspection. The supervisor will sample a few events, such as an access grant, a supplier onboarding or a patch decision, and compare them with what the policy requires. Pick one operational check per policy, run it on a sample, and keep the results. Where practice differs from the text, record a documented exception with an owner and an expiry date rather than leaving the gap silent.

Missing supplier criteria

The supply chain security policy must set supplier selection criteria covering cybersecurity practices, ability to meet security specifications, product quality and resilience, and the ability to diversify supply and limit vendor lock-in. Teams often write the policy but never apply the criteria to actual suppliers. Keep a supplier register that records each supplier's assessment against these criteria, with the assessment date and the person who signed it off.

Undated reviews

The security policy must be reviewed by management at least annually, and a review without a date cannot be shown to have happened. Put the version number, review date, reviewer and changes made on the policy's first page, and keep the prior versions. Where a review concluded that no change was needed, record that conclusion too. Undated reviews make an otherwise compliant program look unmanaged.

Retention periods never set

The security policy must list documentation retention periods, yet many programs leave them blank or assume a default. Decide a period for each record type, such as risk assessments, incident records, access reviews and supplier assessments, and set the same period in the storage system so it is enforced rather than remembered. Confirm the periods against national record-keeping rules and any sector-specific law that applies to your entity.

Questions buyers ask about NIS2 policies

Is one information system security policy enough for NIS2?

A single top-level policy is the starting point, but it is not enough on its own. Article 21(2)(a) requires policies on risk analysis and information system security, and Implementing Regulation (EU) 2024/2690 expects the security policy to set security objectives, commit to continual improvement and resources, list the topic-specific policies, state documentation retention periods, and be reviewed by management at least annually. The top-level policy then points to the topic-specific policies that carry the detail, such as incident handling, supply chain security, cryptography and access control. Supervisors will look for both layers and for proof that management actually reviewed them.

Is ENISA's list of required policies legally binding?

ENISA's list is not binding in itself. ENISA's June 2025 technical implementation guidance is non-binding, but the policies it identifies correspond to what Implementing Regulation (EU) 2024/2690 requires to be documented for the covered entity types. The binding text is the regulation and the national law that transposes NIS2 in your Member State. Read the guidance as a practical map of expected evidence, and confirm with your national competent authority or a qualified legal adviser which obligations apply to your entity type. Following the guidance does not by itself prove compliance.

How much effort does drafting NIS2 policies take?

No supplied fact gives a duration for drafting, so the effort is best estimated from your own environment. The main drivers are the number of in-scope systems and suppliers, how much of your existing ISO/IEC 27001 or other policy set can be reused, how many approval rounds your management body requires, and whether incident handling and supply chain material already exist. Costs have two parts: internal time from security, IT, legal and operations staff, and any external advisory fees. Ask any provider for a written scope listing the policies included, the review cycles, and who signs off each document.

Can our own team write the NIS2 policies without outside help?

Often yes, if the team has security governance experience and time to draft and maintain the documents. The harder part is not writing but making the policies match what the systems actually do. Your team must own the policies and approve them, because management bodies carry responsibility under NIS2. Teams that lack a security lead, or that have never run a formal risk assessment, usually benefit from outside drafting support or a review of a draft. Whatever you choose, confirm that someone internal can answer for each policy during a supervisory inspection.

Can an outside partner own and maintain our NIS2 policies?

An outside partner can prepare, draft and update policies, but it cannot own them. Under NIS2 the organization owns its controls and management approves the policies. DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and can prepare systems and evidence for assessments. It does not issue audit reports or certifications, and only the competent authority or an independent assessor can verify compliance. Ask any partner which policy sections it drafts, which remain with your staff, and how changes are handed over.

How do NIS2 policies connect to the risk assessment?

The policies are the written rules, and the risk assessment decides which rules are needed and how strict they must be. Implementing Regulation (EU) 2024/2690 requires a policy and procedures to check whether measures are effectively implemented and maintained, taking into account the risk assessment and past significant incidents. In practice, each policy should trace back to identified risks, the treatment plan, and named owners for residual risk. When the risk assessment changes, the affected policies must be reviewed. Keep the link visible, so a supervisor can follow a risk from the assessment to the policy and then to the control evidence.

How do incident handling policies support NIS2 reporting deadlines?

The incident handling policy is where reporting deadlines become operational steps. Implementing Regulation (EU) 2024/2690 requires it to include an incident categorization system, communication plans for escalation and reporting, assigned response roles, and supporting documents such as response manuals, escalation charts, contact lists and templates. Article 23 sets the reporting timeline for significant incidents, including the 24-hour early warning, the 72-hour notification and the one-month final report. The policy should name who decides that an incident is significant and who submits each report, and it should be tested through exercises. Confirm the current reporting rules with your national authority.

How often must NIS2 policies be reviewed?

The security policy must be reviewed by management bodies at least annually, according to Implementing Regulation (EU) 2024/2690. Topic-specific policies should also be reviewed on a schedule you define, and earlier after a significant incident, a major change in systems or suppliers, or a new risk assessment result. Record each review with its date, the reviewers, the decisions taken and the version approved. Supervisors look for this review history as evidence that policies are maintained, not written once and filed.

How DeployOpen prepares policies and the evidence behind them

DeployOpen works with your team to turn the NIS2 policy set into documents that match how your systems actually run, then hands the library over for your management body to own. The organization decides its policies and accepts its risks, while DeployOpen prepares the drafts, the supporting systems and the evidence that show the policies are followed.

How we scope

Agree in writing which entities, systems, sites and suppliers the policy set covers before any drafting starts.
List the ten topic-specific policies ENISA identifies and confirm which ones your organization already holds.
Confirm the document retention periods, review cycle and approval roles your management body will sign off.
Engagements are fixed-scope, so deliverables and timelines are agreed in a written scope before work begins.

How we build

Draft the information system security policy with security objectives, resource commitments and a list of topic-specific policies.
Write incident handling, supply chain and cryptography policies tied to your real categorization, supplier and asset records.
Map each policy statement to the system configuration, logs and tooling that should show it is operating.
Test the controls behind each policy so the documents describe settings that can be checked, not intentions.

How we hand over

Deliver the policy library with version history, owners, approval fields and a documented annual management review step.
Provide an evidence index that links each policy requirement to the artifacts a competent authority could request.
Walk your security, legal and management teams through the documents so they can explain and defend each decision.
Confirm with your independent assessor or competent authority which format and level of detail they expect.

How we support

Update policies after material changes to systems, suppliers, significant incidents or national transposition rules.
Support the annual management review with refreshed evidence, gap notes and suggested policy revisions.
Continue testing and upgrades through an ongoing retainer if your organization wants that support after handover.
Your organization keeps ownership of every policy decision, and DeployOpen does not issue any compliance report or certificate.

Which policies NIS2 requires