A NIS2 audit verifies how well your organisation complies with the 10 areas of article 21 of the Directive. The methodology we apply in real projects is structured in 5 phases: applicability analysis, gap analysis against article 21, technical testing (pentesting, architecture, supply chain, threat modeling), 24h/72h notification procedure and remediation plan with roadmap. An initial audit lasts 6-10 weeks and produces defensible evidence in front of an inspection by the competent authority. If you already have ISO 27001:2022 in place, you start with 65-75% of the way done: typical gaps are 24h/72h notification, supply chain and specific board training.
Before auditing: does NIS2 apply to me?
The first question isn't how do I audit, but whether the audit is mandatory. NIS2 applies to entities in Annexes I and II of the Directive with 50+ employees or > €10M turnover, plus specific exceptions (DNS, TLDs, qualified trust services, etc.). If in doubt, review the complete NIS2 in Spain guide before continuing.
If the answer is "doesn't apply directly but we supply a regulated entity", the audit is still recommended: the regulated entity will contractually require equivalent measures from you (supply chain management, article 21 letter d).
The 5 phases of a NIS2 audit
| Phase | Content | Duration |
|---|---|---|
| 1. Applicability and scope | Determine whether NIS2 applies, in which category and to which group entities | Week 1 |
| 2. Article 21 gap analysis | Mapping the 10 mandatory areas against existing controls | Weeks 2-4 |
| 3. Technical testing | Pentesting, architecture, supply chain, threat modeling | Weeks 4-8 |
| 4. Notification procedure | Designing 24h / 72h / 1 month with drill | Weeks 6-8 |
| 5. Remediation plan | 12-month roadmap with prioritisation | Weeks 8-10 |
Phase 1: Applicability analysis and scope
What gets done
Determine whether NIS2 applies, in which category (essential / important) and to which group entities, identifying the services whose interruption could be considered a "significant incident".
Concrete steps
- Mapping CNAE/NACE activities of each group entity against Annexes I and II.
- Counting employees and consolidated turnover (medium/large enterprise criterion from Recommendation 2003/361/EC).
- Identifying subsidiaries that provide covered services.
- Determining critical services: applications, infrastructure and processes whose interruption would affect operational continuity.
- Map of actors: regulated B2B clients, critical ICT providers, competent authority, competent CSIRT.
Deliverables
- Formal applicability and scope document, signed by the management body.
- Prioritised inventory of critical services.
- List of authorities and CSIRTs with operational contact details.
Common mistakes
- Excluding European subsidiaries because "they bill little" without consolidating at group level.
- Not considering that a service shared between regulated and non-regulated entities usually has to be treated as regulated.
- Assuming that a later Royal Decree-law or transposition will reduce scope. The directive sets a floor, not a ceiling.
Phase 2: Article 21 gap analysis
The 10 mandatory areas of article 21
Article 21.2 lists the minimum areas every regulated entity must cover:
| # | Article 21 area | Key question being audited |
|---|---|---|
| a | Risk analysis and information system security policies | Is there a live risk analysis, approved by management and reviewed at least annually? |
| b | Incident handling | Is there a documented procedure for detection, classification, response and communication? |
| c | Business continuity: backups, disaster recovery, crisis management | Are there RTO/RPO per critical service, tested BCP/DRP and crisis management plan? |
| d | Supply chain security | Is there an inventory of critical ICT providers, periodic evaluation and contractual clauses? |
| e | Security in acquisition, development and maintenance, vulnerability management and disclosure | Is there secure SDLC, vulnerability management, responsible disclosure policy? |
| f | Policies and procedures to assess effectiveness of measures | Are there internal audits, pentesting, security metrics and management review? |
| g | Basic cyber hygiene practices and training | Mandatory training plan, specific training for the board and anti-phishing campaigns? |
| h | Policies and procedures on cryptography use and, where applicable, encryption | Are there cryptography standards, key management and data encryption at rest and in transit? |
| i | Human resources security, access control and asset management | Background checks, segregation of duties, IAM, asset inventory? |
| j | Multifactor authentication, secure communication solutions and emergency communication | MFA on privileged and remote access, encrypted communications, out-of-band channels? |
How the gap analysis runs
- Collection of evidence for each control: policies, records, configurations, logs, contracts, minutes.
- Structured interviews with control owners (CISO, IT Manager, HR, Legal, Procurement, product teams).
- Mapping to reference frameworks already implemented: ISO 27001:2022 (Annex A), ENS (Royal Decree 311/2022), NIST CSF 2.0.
- Gap classification by:
- Criticality: high / medium / low
- Remediation effort: low / medium / high
- Estimated time and dependencies
If you already have ISO 27001:2022
You start with 65-75% of the way done. The typical gaps we detect:
- 24h/72h/1 month notification: the ISO incident procedure doesn't contemplate NIS2 deadlines.
- Supply chain: ISO requires clauses; NIS2 requires active verification, periodic evaluation and consideration of aggregate risk.
- Specific board training: ISO doesn't formally require it; NIS2 does.
- Personal liability of directors: requires documenting the board's due diligence.
- Effectiveness testing: NIS2 implies regular pentesting and technical evaluations beyond the ISO internal audit.
Full coverage in ISO 27001 + NIS2.
If you have ENS Royal Decree 311/2022
Coverage similar to ISO 27001, with a plus on governance and categorisation. Gaps are the same plus some specific ones around private supply chain (ENS is designed for the public sector).
Phase 3: Technical testing
NIS2 doesn't demand a formal "NIS2 certification", but article 21 letter f requires assessing the effectiveness of the measures. In a real audit, that means concrete technical testing, not just documentary review.
NIS2-aligned pentesting
- Critical web/API applications: OWASP-aligned pentesting focused on applications supporting services whose interruption would be a significant incident.
- External infrastructure: pentesting of the internet-exposed surface.
- Internal infrastructure: assumed-breach scenario, privilege escalation, lateral movement.
- Active Directory: review of critical configurations, ACLs, policies, Kerberos, exploitation paths.
Recommended frequency: annual minimum for critical systems, semi-annual for the most critical.
Architecture and segmentation audit
- Review of network design: security zones, segmentation, microsegmentation where applicable.
- Verification of data flows between zones and applications.
- Review of identities and accesses (especially privileged, service and maintenance accounts).
- Analysis of jump hosts and remote access mechanisms.
- Evaluation of cloud architecture where applicable.
Supply chain review
More than a technical test, it's documentary + technical verification:
- Inventory of ICT providers classified by criticality
- Review of contractual clauses aligned with article 21 letter d
- Security questionnaires and associated evidence (SOC 2, ISO 27001, attestations)
- Technical tests of the integration with provider systems
- Analysis of concentration risk and exit plan if the provider is critical
Threat modeling of critical services
For each service whose interruption would be a significant incident:
- Architecture diagram and data flows
- Identification of actors (legitimate and malicious)
- Threat modeling with STRIDE / PASTA / LINDDUN methodology
- Mapping to MITRE ATT&CK for realistic scenarios
- Prioritisation of mitigations aligned with the risk of a significant incident
Technical phase deliverables
- Pentesting report with CVSS prioritisation + business impact
- Architecture and segmentation report with findings and recommendations
- Supply chain map with criticality and gaps
- Threat models per critical service with mitigation backlog
Phase 4: Incident notification plan
NIS2 requires a documented and tested notification procedure.
24h / 72h / 1 month procedure
| Deadline | Mandatory content |
|---|---|
| 24 h from awareness | Early alert to the competent CSIRT: indication of whether the incident may be caused by unlawful or malicious acts, and cross-border impact if any. |
| 72 h | Incident notification: initial assessment, severity, impact, indicators of compromise (IoC) if available, mitigation measures taken. |
| 1 month | Final report: detailed description of the incident, severity and impact, type of threat/root cause, measures taken and ongoing, cross-border impact. |
Note: if the incident affects personal data, the GDPR art. 33 notification to the AEPD (72h) gets activated in parallel. They're independent procedures.
How the procedure gets tested
- Tabletop exercise at least annually with the crisis committee
- Technical drill of the detection → escalation → notification flow
- Post-incident review of any real incident with continuous improvement criteria
- Incident register traceable and reviewed by management
Roles that must be designated before auditing
- Incident Response Manager (technical)
- Crisis Manager (business)
- Spokesperson (communication)
- Legal counsel (internal or external, with 24×7 availability)
- Point of contact with the competent CSIRT
Phase 5: Remediation plan and roadmap
Recommended plan structure
- Consolidated findings from phases 2-4, with criticality and effort
- 12-month roadmap with quarterly waves
- Assignment of owners and budget per initiative
- Progress metrics (KPIs) and monthly steering committee
- Partial re-audits quarterly to validate gap closure
Example prioritisation (real project, mid-sized industrial sector company)
| Priority | Initiative | Effort | Deadline |
|---|---|---|---|
| P0 | 24h/72h notification procedure with drill | Medium | 4 weeks |
| P0 | NIS2 contractual clauses with critical providers | Low | 6 weeks |
| P0 | Specific board training | Low | 2 weeks |
| P1 | MFA on all privileged and remote access | Medium | 8 weeks |
| P1 | Threat modeling of the 5 critical services | High | 12 weeks |
| P1 | Annual pentesting programme | Low | 2 weeks (planning); continuous execution |
| P2 | Microsegmentation of operational network | High | 6-9 months |
| P2 | SIEM improvement with NIS2 use cases | Medium | 4 months |
| P3 | PAM rollout | High | 6+ months |
Evidence and documentation an inspection will request
A competent authority can require, without prior notice or with little advance notice, evidence such as:
- Information security policy signed by management and current
- Risk analysis updated within the last year
- Asset and critical ICT provider inventory
- Procedures for incident management, continuity, change management, access control, cryptography
- Incident records and notifications made
- Continuity and recovery plan, with test results
- Recent pentesting and vulnerability analysis results
- Training plan and attendance record, including board training
- Approval minutes for measures by the management body
- Contractual clauses for critical ICT providers and evidence of evaluation
- MFA and access control policies: technical evidence (configuration screenshots, logs)
Documenting this evidence at the pace of the work, not after the fact, is the difference between passing an inspection well or not.
Common mistakes we detect
- Treating the audit as a paper exercise. European authorities increasingly look at real effectiveness measured by technical tests, not just the existence of policies.
- Leaving the 24h procedure untested. Over 60% of the organisations we audit have a written procedure but have never run a full drill.
- Not training the board. Training the management body is mandatory in NIS2.
- Underestimating the supply chain. Having signed clauses isn't enough; evaluation and verification must happen periodically.
- Confusing NIS2 notification with AEPD notification. They're independent procedures that can be activated at the same time.
- Not preserving traceability of board decisions. Personal director liability requires minutes and due diligence evidence.
- Assuming a cloud provider complies for you. Even if AWS/Azure/GCP meet their own obligations, responsibility for the critical service lies with the regulated entity.
- Not reviewing clauses with regulated clients. When you're a provider to a regulated entity, the clauses you sign can impose de facto NIS2 obligations on you.
Frequently asked questions
Who audits NIS2 in Spain?
NIS2 doesn't require mandatory external audits like ENS does for the public sector. But sectoral competent authorities (in coordination with INCIBE-CERT) can inspect at any time, require independent audits and request technical evidence. The recommendation is to run an annual external audit to have defensible evidence.
Does NIS2 require an ISO-style certification?
No. NIS2 doesn't require formal certification, but it does require assessing the effectiveness of measures (article 21 letter f). An ISO 27001:2022 certification is the most standardised way to demonstrate part of the controls, but it doesn't replace full NIS2 compliance.
How often do you need to audit NIS2?
Minimum annually for the gap analysis and framework review. Technical tests (pentesting of critical applications) should be annual or semi-annual depending on criticality. After a significant incident, an extraordinary audit is performed.
Does one audit work for NIS2 and DORA?
For financial entities subject to DORA, DORA is lex specialis and prevails. The audit should be structured from DORA and map to NIS2 the few gaps not covered. For non-financial entities, NIS2 is the reference. See DORA vs NIS2.
How do I prove staff training?
With an approved training plan, versioned contents, attendance register signed or digitally traceable, comprehension assessments and simulated phishing campaigns with response metrics. The board needs specific training with signed minutes.
How much does an initial NIS2 audit cost?
It depends on the scope (number of critical services and group entities under analysis), the technical component included (pentesting, threat modeling, architecture review), the prior maturity (if you already have ISO 27001:2022 or ENS, part of the work is done) and the state of documentation. The subsequent adequacy is a separate 6-12 month project.
For an assessment tailored to your organisation, request an initial conversation; in 45 minutes we can give you a realistic order of magnitude.
Can I do the audit with internal staff?
Partially. The gap analysis and documentation can be done in-house. Technical tests (pentesting, threat modeling) should be outsourced to guarantee independence and specialisation, two criteria authorities look at when evaluating the robustness of measures.
Audit your organisation against NIS2 with Secra
At Secra we run the full cycle: applicability analysis, gap analysis against article 21, NIS2-aligned pentesting, architecture audit, threat modeling of critical services, design of the 24h/72h notification procedure and remediation plan with 12-month roadmap.
→ Learn about our NIS2 compliance service
→ Request an initial conversation, no commitment
Related reading
About the author
Secra Solutions team
Ethical hackers with OSCP, OSEP, OSWE, CRTO, CRTL and CARTE certifications, 7+ years of experience in offensive cybersecurity, and authors of CVE-2025-40652 and CVE-2023-3512.