A compliance officer stares at a spreadsheet listing over 200 legacy applications, trying to determine which fall under the new NIS2 directive. The enforcement date looms, and the pressure mounts to shift from high-level policies to concrete, auditable proof. This isn’t just about ticking boxes-it’s about building a defensible cybersecurity posture that stands up to regulator scrutiny.
Critical Access Controls Auditors Prioritize for NIS2
When auditors arrive, they no longer accept vague assurances. They demand documented, technical evidence. One of the first things they examine? Identity governance. Specifically, whether Multi-Factor Authentication (MFA) is enforced across all sensitive accounts-not just for employees, but for contractors, admins, and service accounts alike. Coverage gaps in legacy systems or non-web applications are red flags.
Many organizations find that centralizing their identity logs and automating user lifecycle management is a vital first step when preparing for nis2 compliance. This ensures that access provisioning, modification, and deactivation are traceable and aligned with employment status. Without automation, manual processes create blind spots-and auditors know it.
The Shift Toward Rigorous Identity Governance
Modern compliance hinges on accountability. Identity Governance Administration (IGA) isn’t optional; it’s foundational. Systems must log every access request, approval, and change. The goal? To answer, at any time, who has access to what, and why. This level of visibility supports Zero Trust principles and satisfies auditors looking for proactive risk management.
Comparing Audit Requirements: Evidence vs. Policy
There’s a critical difference between having a policy and proving its enforcement. NIS2 shifts the burden to technical validation. What was once a checklist item now requires real-time, auditable data. Below is a comparison of common pitfalls versus what auditors expect.
| 🔍 Control Category | ❌ Weak Approach (Legacy) | ✅ Audit-Ready Approach (NIS2 Compliant) |
|---|---|---|
| MFA Coverage | Enabled only on primary user accounts; legacy systems excluded | Enforced across all privileged and user accounts, including service and admin accounts |
| Access Review | Annual sign-offs based on memory or incomplete lists | Quarterly automated reviews with logs showing reviewer actions and remediation |
| Incident Response | Policy exists but untested; no integration with monitoring tools | Validated playbooks with automated alerts and a 24-hour notification capability |
Moving Beyond the Paperwork
Article 20 of the directive mandates that management ensure appropriate technical and organizational measures. This means auditors won’t accept a binder of policies-they want to see system-generated logs, access review reports, and proof of testing. A manual sign-off sheet is no longer enough.
Technical Proofs and Documentation
For incident response, the directive requires notification within 24 hours of a qualifying event. This isn’t a suggestion-it’s a legal obligation. Organizations must have tools that detect, escalate, and trigger alerts automatically. The ability to generate a timeline of actions during an incident is now a core compliance requirement.
Managing Third-Party Risks and Supply Chain Security
Outsourcing doesn’t outsource risk. Many assume that using a compliant cloud provider absolves them of responsibility. That’s a dangerous misconception. The shared responsibility model means the provider secures the infrastructure, but the customer remains accountable for secure configuration-especially access controls and log management.
The Shared Responsibility Reality
You can’t delegate your compliance. Even if your data lives in a certified cloud environment, misconfigured access policies or unmonitored logs can lead to breaches-and penalties. It’s on your organization to ensure that IAM settings, MFA enforcement, and audit trails are properly maintained.
Supplier Risk Registries
Third-party vendors with network access must be inventoried and monitored. This includes tracking what systems they can reach and reviewing their access rights regularly. A supplier risk registry isn’t just good practice-it’s a requirement under NIS2. Without it, you’re blind to potential backdoor threats.
The NIS2 Compliance Roadmap: Key Milestones
Compliance isn’t a one-time project. It’s a cycle of preparation, validation, and continuous improvement. The most successful organizations treat it as a governance process, not just a technical fix. Leadership involvement is non-negotiable.
Executive Responsibility and Validation
Under Article 20, senior management must formally approve and validate the organization’s risk management strategy. If the board refuses to sign off, it’s not just a governance issue-it’s a compliance failure. Auditors see this as a red flag indicating lack of accountability.
Inventory and Shadow IT Detection
You can’t protect what you don’t know exists. A complete inventory of all applications-authorized and unauthorized-is the foundation of visibility. Shadow IT, like unsanctioned SaaS tools, creates hidden attack paths. Discovery tools and network monitoring are essential to map the full digital footprint.
Continuous Cybersecurity Training
Human error remains a top attack vector. NIS2 mandates documented proof of regular cybersecurity awareness training. This isn’t a checkbox exercise. Training must be role-specific, repeated, and verifiable. Phishing simulations and completion reports serve as evidence during audits.
Practical Steps for Immediate Readiness
Where do you start? Focus on actions that generate immediate, auditable evidence. Here’s a practical 7-point checklist to build momentum:
- ✅ Full application inventory - Identify all systems, including cloud and shadow IT
- ✅ MFA coverage report - Verify enforcement across all user and service accounts
- ✅ Automated access review logs - Replace manual spreadsheets with system-generated trails
- ✅ Incident response plan - Test and document the ability to notify within 24 hours
- ✅ Supplier risk registry - Catalog all third parties with access and review permissions
- ✅ Training evidence - Maintain records of completed cybersecurity sessions
- ✅ Board-signed validation - Secure formal approval of security measures under Article 20
Conducting a Gap Analysis
Begin with a scoping exercise based on ENISA’s guidance. Determine your entity classification-essential, important, or otherwise. This defines your obligations. A gap analysis then highlights where policies, controls, or evidence fall short.
Strengthening the Incident Response Loop
It’s not enough to have a plan. You must prove it works. Conduct tabletop exercises, simulate breaches, and test notification workflows. The technical ability to generate a timeline of events post-incident is now a baseline expectation.
Full FAQ
What is the most frequent mistake when mapping MFA coverage for an audit?
Organizations often assume MFA is fully deployed because it’s enabled on primary systems. The oversight? Legacy applications, service accounts, and non-interactive logins are frequently excluded. Auditors look for 100% coverage across all privileged accounts, and gaps in older systems are a common finding.
How does NIS2 differ from ISO 27001 regarding management liability?
While ISO 27001 is a voluntary standard, NIS2 is a legal directive with enforceable penalties. Under NIS2, executives can be held personally liable for non-compliance, with fines up to 10 million euros or 2% of global turnover. This shifts cybersecurity from a technical concern to a board-level responsibility.
Does a subsidiary need its own audit if the parent company is compliant?
Not necessarily. Compliance is based on operational autonomy and size. If a subsidiary operates independently and meets size thresholds, it may be in scope. However, if it’s fully integrated into the parent’s infrastructure and governance, a single audit may suffice-provided the parent can demonstrate oversight.