NIS2 Supplier Risk Assessment: How to Assess Third-Party Risk
NIS2 Article 21 requires essential and important entities to put appropriate and proportionate technical, operational, and organizational cybersecurity measures in place across ten minimum areas. Those areas cover risk analysis, incident handling, continuity, supply chain security, secure development and vulnerability handling, control effectiveness, cyber hygiene and training, cryptography, people and access, and secure authentication and communications. Article 21 of Directive (EU) 2022/2555 is the legal baseline.
One point causes needless confusion: Article 21 does not contain 21 security controls. The number is the article number. Paragraph 2 lists ten minimum categories, and the implementation is risk-based rather than a single control checklist that every organization copies.
That distinction matters. A hospital, managed service provider, manufacturer, and DNS provider can all fall under NIS2, but the measures that are proportional to their systems and risks will not look identical. National law and sector-specific rules can add detail, so the EU-level requirements are the starting point rather than the entire local compliance file.
Free tool
Find the Article 21 gaps before turning them into a project plan
Use Q-Sec's NIS2 Compliance Self-Assessment Toolkit to identify where controls, ownership, or evidence are incomplete before you start assigning remediation work.
Open the NIS2 self-assessment toolkitWhat is NIS2 Article 21 about?
Article 21 has two layers. First, it sets the standard: measures must be appropriate to the risk and proportionate to the organization. Second, it names ten areas that the security program must cover. The table below turns the legal categories into an operating view without pretending that every company needs the same tools.
| Article 21 area | What it means operationally | Typical evidence |
| Risk analysis and information system security | Know the risks to systems and services, decide how they are treated, and maintain security policies that reflect those decisions. | Risk methodology, risk register, security policies, approvals |
| Incident handling | Detect, analyze, contain, respond to, and recover from security incidents through defined roles and procedures. | IR plan, incident records, escalation paths, exercise results |
| Business continuity and crisis management | Keep critical services recoverable through backup, disaster recovery, continuity planning, and crisis decisions. | Backup records, restore tests, BCP/DR plans, exercise records |
| Supply chain security | Address security risk in relationships with direct suppliers and service providers. | Supplier assessments, contract clauses, review records, exceptions |
| Secure acquisition, development, and maintenance | Build security into system procurement, development, change, maintenance, vulnerability handling, and disclosure. | Secure development rules, patch/vulnerability records, procurement criteria |
| Assessment of measure effectiveness | Check whether controls actually work and correct weaknesses found. | Audit results, testing records, control reviews, remediation tracking |
| Cyber hygiene and training | Maintain basic security practices and train people according to their responsibilities. | Training records, awareness program, hygiene procedures |
| Cryptography and encryption | Set policies for cryptography and use encryption where appropriate to the risk. | Crypto policy, key-management records, approved standards |
| HR security, access control, asset management | Control who and what can access systems and keep track of assets, ownership, and lifecycle changes. | Asset inventory, access reviews, joiner/mover/leaver records |
| MFA, continuous authentication, secure communications | Use stronger authentication and secure internal communications where appropriate. | MFA coverage, authentication policy, secure communication controls |
The evidence examples are practical illustrations, not a universal statutory document list. What a competent authority expects will depend on the entity, risk, national implementation, and any more specific rules that apply.
What does "appropriate and proportionate" mean under Article 21?
NIS2 does not ask every entity to build the same security program. Article 21 ties the level of security to the risk. The Directive points to the entity's exposure, size, the likelihood and severity of incidents, and their societal and economic impact. It also says to consider the state of the art, relevant European and international standards where applicable, and implementation cost.
That gives teams room to design controls around the environment, but it also creates a documentation job. If two in-scope organizations make different choices, each should be able to explain why its choice fits its risks. "We did what our vendor recommended" is a thin rationale if the control is later questioned.
The same logic applies to exceptions. A control can be inappropriate in one environment and necessary in another. Record the risk, the decision, the owner, any compensating measure, and when the decision will be reviewed.
Why does Article 21 use an all-hazards approach?
Article 21 says the measures must follow an all-hazards approach. Cybersecurity risk is therefore wider than malware and account compromise. The security of the physical environment around network and information systems also matters when a physical event can disrupt the service.
For a data center, that can pull power, cooling, physical access, and emergency procedures into the same risk discussion as network segmentation or privileged access. For a manufacturer, a cyber event and an operational disruption can share the same recovery dependency. The point is continuity of secure service, not a tidy separation between "cyber" and everything around it.
How do the 10 NIS2 Article 21 measures work in practice?
Article 21 groups the required measures into ten areas, each covering a different part of how an organization manages cyber risk in practice.
1. Policies on risk analysis and information system security
The first measure gives the rest of Article 21 somewhere to stand. An organization needs a repeatable way to identify risks, assess them, decide how to treat them, and connect those decisions to security policies. A risk register that never changes after the annual audit is paperwork, not risk management.
The useful questions are concrete: which services are critical, which systems support them, what could interrupt or compromise them, who owns the risk, what controls reduce it, and what risk remains after those controls are applied? Policies should then reflect the actual operating model instead of describing controls the company does not run.
2. Incident handling
Article 21 requires an incident-handling capability. That means more than having an incident response document. Teams need a path from detection to triage, investigation, containment, recovery, and post-incident work, with clear authority at each handoff.
Keep the legal boundary clear: Article 21 covers the security capability; Article 23 covers regulatory notification of significant incidents. The processes must connect, because a team cannot meet a reporting deadline if it cannot classify the incident quickly enough, but they are not the same obligation.
Free guide
Build the reporting clock into the response process
Use the Q-Sec NIS2 Incident Response Plan Template to structure escalation, notification preparation, actions, and evidence around the NIS2 reporting workflow.
Get the NIS2 incident response plan template3. Business continuity, backup, disaster recovery, and crisis management
A control can stop an attack and still create a business problem if recovery has not been planned. Article 21 therefore places backup management, disaster recovery, business continuity, and crisis management in the same risk-management set.
The practical test is whether the organization can recover the service it depends on, not whether a backup job reports "successful." Recovery priorities, restoration procedures, dependencies, decision rights, alternate communication routes, and exercises matter because a plan becomes useful only when people can execute it under pressure.
4. Supply chain security
Article 21 makes direct suppliers and service providers part of the cybersecurity risk picture. Paragraph 3 goes further and says entities should consider supplier-specific vulnerabilities and the overall quality of products and cybersecurity practices, including secure development procedures.
That creates work before and after signing a contract. Security teams need to know which suppliers can affect critical services, what access or data they receive, which security expectations belong in the contract, how exceptions are handled, and what evidence is reviewed over time. The full supplier assessment method belongs on the dedicated supplier-risk page rather than being duplicated here.
5. Security in acquisition, development, and maintenance
Security needs to enter the system lifecycle before an incident exposes the gap. Article 21 explicitly covers acquisition, development, maintenance, vulnerability handling, and vulnerability disclosure.
For an organization that develops software, this can affect secure design, code review, dependency management, change control, testing, and vulnerability intake. For a company buying technology, the same requirement reaches procurement criteria, configuration, maintenance responsibility, end-of-life decisions, and how supplier vulnerabilities are handled.
6. Assessing whether cybersecurity measures are effective
Article 21 does not stop at "control implemented." Organizations need policies and procedures for assessing whether the measures work. The right test depends on the control and risk: configuration review, restore test, access review, tabletop exercise, vulnerability assessment, penetration test, audit, or another method can all have a place.
NIS2 does not prescribe one universal penetration-testing schedule for every entity. The requirement is broader: assess effectiveness and correct weaknesses. A test report is useful only when findings have owners, remediation decisions, and evidence that the fix was checked.
Read the Penetration Testing for NIS2 Compliance post. When penetration testing is a sensible way to test technical controls and where the Directive stops short of making it universal.
7. Basic cyber hygiene and cybersecurity training
Cyber hygiene covers the routine practices that prevent ordinary weaknesses from becoming incident paths. Training sits beside it because controls fail quickly when people do not understand their responsibilities.
The training should match the role. A general awareness session, privileged administrator training, secure-development training, and management-body training solve different problems. Keep records of what was delivered, to whom, and when, but do not confuse attendance with proof that the wider control set works.
8. Cryptography and, where appropriate, encryption
Article 21 asks for policies and procedures on cryptography and, where appropriate, encryption. The wording matters. It does not say that every piece of data must be encrypted in the same way; the organization needs a defensible policy tied to risk and system use.
That usually means decisions about approved cryptographic methods, where encryption is required, how keys and certificates are managed, who can administer them, and what happens when algorithms, certificates, or systems reach the end of their acceptable life.
9. Human resources security, access control, and asset management
These three areas sit together because access decisions are hard to defend when the organization does not know which assets exist, who owns them, or who still needs access. An accurate inventory and clear ownership give access reviews something real to check against.
Joiner, mover, and leaver processes, privileged access, service accounts, periodic reviews, asset classification, and ownership records are common parts of the implementation. The exact controls should follow the risk. A forgotten administrator account on a critical system deserves different treatment from access to a low-risk internal tool.
10. MFA, continuous authentication, and secure communications
The final category includes multi-factor authentication or continuous authentication solutions, secure voice, video, and text communications, and secure emergency communication systems where appropriate. Simplified Article 21 lists often shrink this item to "use MFA," which loses part of the requirement.
The implementation question is coverage. Which users, systems, privileged actions, remote-access paths, and emergency channels need stronger authentication or protected communication? A company can have MFA somewhere and still leave the access paths that matter most exposed.
When does the Commission Implementing Regulation (EU) 2024/2690 change the Article 21 picture?
For certain NIS2 entities, Article 21 has more detailed EU-level technical and methodological requirements. Commission Implementing Regulation (EU) 2024/2690 applies to specified categories, including DNS service providers, TLD name registries, cloud computing providers, data center providers, content delivery network providers, managed service providers, managed security service providers, online marketplaces, online search engines, social networking platforms, and trust service providers.
For those relevant entities, the Annex to the Regulation adds much more detail to the Article 21 categories. It also requires a documented rationale where a requirement marked "where appropriate," "where applicable," or "to the extent feasible" is not applied.
ENISA published technical implementation guidance in June 2025 with practical advice, examples of evidence, and mappings for the entities covered by the Regulation.
Do not copy that detailed control set into every NIS2 program without checking scope. Other essential and important entities still have the Article 21 obligations, but their technical detail comes from the Directive, national transposition, applicable guidance, and any sector-specific rules.
How should an organization implement Article 21?
A useful Article 21 program is a chain of decisions that can be traced from risk to evidence. The sequence below keeps the work operational instead of producing ten policy documents that never meet each other.
- Confirm scope and applicable rule set. Establish which legal entity and services are in scope, which national law applies, and whether Regulation 2024/2690 or another sector-specific rule adds detail.
- Map critical services, systems, dependencies, and risks. Article 21 measures should be tied to what the organization needs to protect and recover.
- Map the ten categories to current controls. Mark each area as effective, partial, missing, or not applicable with a documented rationale where that concept is legally available.
- Assign owners and decision rights. Name who maintains the control, who accepts exceptions, who can authorize disruptive response actions, and who reports status to management.
- Collect operating evidence. Keep policies together with records that show the control runs: logs, reviews, test results, approvals, tickets, incident records, training records, and supplier evidence as relevant.
- Test, correct, and review. Article 21(4) requires corrective action without undue delay when the entity finds it does not comply. Treat findings as work with owners and deadlines, not as an audit appendix.
What evidence can support NIS2 Article 21 compliance?
There is no single EU document pack that proves Article 21 compliance for every organization. Evidence should answer a more practical set of questions: what was required, which control addresses it, who owns the control, how do we know it operated, what exceptions exist, and what happened when testing found a weakness?
| Evidence type | What it can show |
| Policy evidence | Approved risk, security, access, cryptography, supplier, development, continuity, and incident-handling policies as relevant |
| Operating evidence | Access reviews, alerts, incident records, backup jobs, restore results, vulnerability tickets, supplier reviews, training records |
| Testing evidence | Control assessments, tabletop exercises, penetration tests where appropriate, audit findings, restore drills, remediation verification |
| Decision evidence | Risk acceptance, exception rationale, ownership, management approval, corrective action decisions |
| Change evidence | Updated controls after incidents, system changes, supplier changes, findings, or shifts in risk |
The strongest evidence usually connects documents to actual operation. A policy can show intent. A dated access review, restore test, incident record, or remediation check can show that the control was used and reviewed.
What Article 21 does not prescribe
Article 21 is specific about the areas organizations must cover, but it leaves room in how they do it. It does not name a mandatory SIEM product, require every organization to run an internal SOC, prescribe one penetration-testing cadence for all entities, or make ISO 27001 certification a universal condition of NIS2 compliance.
That freedom should not be read as a lower bar. The organization still needs measures that fit the risk and can withstand supervisory scrutiny. A tool can support the requirement. The tool alone is rarely the requirement.
Quick Article 21 implementation check
Use this short review to find gaps before you turn Article 21 into a larger remediation plan:
- The organization has a current risk method and knows which systems and services the Article 21 controls protect.
- All ten Article 21 categories have named controls and owners.
- Incident handling connects to the Article 23 reporting process without confusing the two obligations.
- Business continuity includes tested recovery, not only backup creation.
- Direct suppliers and service providers are assessed according to their access, dependency, and security risk.
- Security requirements appear in acquisition, development, maintenance, and vulnerability processes.
- Control effectiveness is tested with methods that fit the control and risk.
- Training, cryptography, access, asset management, MFA, and secure communications are scoped to real roles and systems.
- Evidence exists for operation, testing, decisions, exceptions, and remediation.
- Any gap found against Article 21 has an owner and corrective action path.
Final thoughts: Turn Article 21 into an operating control set
The useful way to read Article 21 is as a minimum security map with a risk test attached. Cover all ten areas, decide what proportionality means for your environment, name owners, keep evidence close to the work, and correct gaps when testing or incidents expose them. That gives management and supervisors something more useful than a folder of policies: a control set they can trace from requirement to operation.
Move from Article 21 gaps to a defensible remediation plan
Q-Sec's NIS2 Compliance service covers applicability, control assessment, gap identification, remediation priorities, documentation, and audit preparation.
Frequently asked questions about NIS2 Article 21
How many measures are in NIS2 Article 21?
Article 21(2) lists ten minimum cybersecurity risk-management categories. "Article 21" is the article number, not a count of 21 security controls.
Does Article 21 apply to both essential and important entities?
Yes. Article 21 requires both essential and important entities to implement appropriate and proportionate cybersecurity risk-management measures. Supervision differs between the two categories, but the Article 21 duty applies to both.
Does NIS2 Article 21 require a SIEM?
No. Article 21 does not name SIEM as a mandatory product. Monitoring, detection, incident handling, evidence, and control testing still need to be addressed through measures appropriate to the organization's risks.
Does Article 21 require penetration testing?
It requires procedures for assessing the effectiveness of cybersecurity measures, but it does not set one universal penetration-testing requirement or cadence for every NIS2 entity. Testing should match the control, risk, and applicable national or sector rules.
Is Commission Implementing Regulation 2024/2690 mandatory for every NIS2 entity?
No. It applies to the specific categories of relevant entities named in the Regulation. Other NIS2 entities must still meet Article 21 but should check national and sector-specific implementation requirements.
Does ISO 27001 prove Article 21 compliance?
No certification automatically proves Article 21 compliance. ISO 27001 can support many related security-management practices, but the organization still needs to map its controls to NIS2, national law, and any rules that apply to its sector.
What happens if an organization finds an Article 21 gap?
Article 21(4) requires necessary, appropriate, and proportionate corrective measures without undue delay when the entity finds that it does not comply with the measures in paragraph 2.
