Why Your NIS2 Compliance Spreadsheet Will Fail Your Auditor

The spreadsheet looks fine. The reality does not.

Here is a scenario from a real engagement (details anonymized):

A mid-sized financial services company in Germany prepared for their NIS2 readiness assessment. They had a comprehensive compliance spreadsheet - 47 controls, status columns, evidence links, owner names, last-review dates. Everything green. Management signed off. The CISO presented it to the board.

During the assessment, we checked three items against operational reality:

1. Access control matrix: The spreadsheet said “reviewed quarterly.” The actual access review had not happened in 14 months. Three former employees still had active VPN credentials.

2. Incident response plan: The spreadsheet said “tested annually.” The last tabletop exercise was 22 months ago. The on-call rotation listed in the plan included two people who had left the company.

3. Backup recovery testing: The spreadsheet said “tested monthly.” The last successful restore test was eight months ago. The most recent test had failed, and the failure was noted in an internal ticket but never reflected in the compliance tracking.

None of this was intentional. The CISO was competent. The team was busy. The spreadsheet was updated when someone remembered to update it. That is the problem.

What mapping drift actually is

Mapping drift is the gap between what your compliance documentation says and what your organization actually does. It is not fraud. It is not negligence. It is the natural entropy that occurs when compliance tracking is static and operational reality is dynamic.

Every organization experiences mapping drift. The question is whether you detect it before your auditor does.

Mapping drift happens for predictable reasons:

• People leave. The person responsible for quarterly access reviews takes a new job. The task is not formally reassigned. Months pass.
• Processes change. The IT team migrates to a new backup system. The new system works differently. The compliance documentation still describes the old system.
• Priorities shift. A product launch pushes the incident response tabletop exercise to “next month.” Next month becomes next quarter.
• Evidence decays. A policy document is approved in January. By November, three of its referenced procedures have been updated, but the policy itself has not been re-approved.

The result is a compliance posture that looks solid on paper but has quietly degraded in practice.

Why NIS2 makes this worse than before

NIS2 Article 21(1) requires that cybersecurity risk management measures be “appropriate and proportionate” and that entities “regularly review” these measures. The word “regularly” is doing heavy lifting here.

Under the original NIS Directive, enforcement was inconsistent and penalties were modest. Many organizations could maintain compliance as a periodic exercise - update the documentation before the audit, fix the obvious gaps, pass the review, and go back to normal operations.

NIS2 changes this in three ways:

1. Higher penalties. Up to EUR 10 million or 2% of global turnover. Fines of this magnitude mean that compliance failures have board-level consequences.

2. Management accountability. NIS2 Article 20 holds the management body personally accountable for approving and overseeing cybersecurity risk management measures. If the board signs off on a compliance status that does not reflect reality, that is now a governance failure.

3. Supervisory powers. National competent authorities can conduct on-site inspections, request evidence, and issue binding instructions. This is not a paper review. Inspectors will check whether your documented controls match operational reality.

A static spreadsheet reviewed once a year cannot meet these requirements. By the time you update it for the annual review, the gap between documentation and reality may be months wide.

What auditors actually check

Experienced auditors do not just read your compliance documentation. They triangulate. For any given control, an auditor will typically:

1. Read the policy. What does your documentation say should happen?
2. Check the evidence. Does evidence exist that it happened? Is the evidence current?
3. Interview the operator. Does the person responsible know the procedure? When did they last execute it?
4. Test the control. Can you demonstrate it working right now?

Mapping drift shows up in step 2, 3, or 4. The policy says one thing. The evidence says another. The operator describes a different process than the one documented. The live test reveals a gap.

Common findings caused by mapping drift:

• Access reviews documented as quarterly but last performed 6+ months ago
• Incident response plans listing team members who left the organization
• Backup recovery procedures that describe a system replaced during a migration
• Security training records showing 100% completion but the training content is two years old
• Vulnerability scanning reports generated monthly but findings not remediated within the documented SLA

How to prevent it

The fix is not more discipline. People do not fail at compliance because they lack willpower. They fail because static tracking tools cannot keep up with organizational change.

Three approaches that work:

1. Make assessments continuous, not periodic

Instead of reviewing all 47 NIS2 controls once a year, review a rotating subset each month. This distributes the workload and catches drift early. A control reviewed last month that has drifted is much easier to fix than one reviewed last year.

2. Tie evidence to operational systems

Wherever possible, evidence should be generated from the system itself, not manually entered into a spreadsheet. If your access review happens in your identity provider, the evidence is the review log from that system. If your backups run automatically, the evidence is the backup job report. Manual transcription from operations into a compliance spreadsheet is where drift enters.

3. Use tool-assisted assessment

This is where platforms like AuditFront fit. Instead of maintaining a spreadsheet, you run structured assessments that prompt you to verify each control against current reality. The assessment itself becomes the review - you cannot mark a control as compliant without answering specific questions about its current state.

AuditFront’s assessment approach forces recency. When you assess a control, you are answering “is this true right now?” not “was this true when we last checked.” The assessment date is the evidence date. If your last assessment of backup recovery testing was three months ago and the current state has changed, the next assessment will catch it.

The bottom line

NIS2 does not require perfection. It requires that your cybersecurity measures are appropriate, proportionate, and regularly reviewed. A spreadsheet that says “all green” is not evidence of compliance. Evidence is demonstrated, current, and verifiable.

If your compliance tracking depends on someone remembering to update a document, mapping drift is already happening. The question is whether you find it before your regulator does.

Start a free NIS2 assessment to see where your current controls actually stand - not where your spreadsheet says they stand.