How to prepare IT support for ISO 27001, NIS2 and DORA audits

When a company tells me they have an audit coming up, the first place I look is the service desk. Not the policy binder, not the firewall config, the support queue. That surprises people, but it should not. Support is where incidents are first detected, logged and classified, and where access and changes flow every day. When an auditor wants evidence that you actually operate the way your policies say you do, that evidence lives in your tickets.

The good news is that support run the ITIL way already covers most of what ISO 27001, NIS2 and DORA ask for. The gap is usually not capability, it is evidence and consistency. This guide walks through what to have in place, and what to be ready to show.

The single most important thing to get right: NIS2 and DORA put incident reporting on a clock. Under NIS2 you owe an early warning within 24 hours, a notification within 72 hours, and a final report within one month. If your service desk cannot classify and escalate an incident fast enough, you miss a regulatory deadline. Support has to be wired into the reporting process, not cut off from it.

The three frameworks in one table

Framework	What it is	What it wants from support
ISO 27001	Information security management system (ISMS), a voluntary certification often driven by client and tender pressure	Managed incidents, access, changes, logs, suppliers, continuity, and evidence for all of it
NIS2	EU cybersecurity directive, transposed into national law across the EU	Risk management measures plus incident reporting on strict deadlines, with management accountability
DORA	EU digital operational resilience regulation for the financial sector, in force since January 2025	Classification and reporting of major ICT incidents, resilience, testing, and third party risk management

The three overlap far more than they differ. Build support well once, and you satisfy most of all three.

Why the service desk is the front line

Auditors are trained to trace a claim to its evidence. You say you manage incidents? Show me the last major one, start to finish. You say only authorised people get privileged access? Show me the approval and the last review. Almost every one of those trails runs through support. That is why a tidy, well run service desk is worth more at audit time than a beautiful policy nobody follows.

Nine things audit-ready support has in place

1. Incident management wired to reporting. A classification and severity matrix with a clear threshold for “this is reportable to a regulator”, an escalation path, and templates ready for the 24 hour and 72 hour notifications. Every incident fully recorded.
2. Logging and evidence. Every ticket and action timestamped and retained according to a retention policy. When the auditor says “show me”, you can.
3. Access management. Joiner, mover and leaver handled through the service desk with approvals. A list of privileged accounts. A regular review of who has access to what.
4. Change and configuration management. Changes logged, risk assessed, approved, tested, with a back-out plan. An asset inventory or CMDB so you know what you actually support.
5. Continuity and operational resilience. Runbooks for outages, a disaster recovery plan, a communication plan. For DORA, evidence that you have tested resilience, not just documented it.
6. Third party risk. A register of the suppliers behind your support (the ITSM tool, any outsourced L1, remote access vendors) with contracts, SLAs and exit plans.
7. Documented processes and knowledge. SOPs, runbooks, an escalation matrix and policies, all versioned and reviewed on a schedule. Auditors want “documented and actually followed”.
8. Measurement and reporting. Defined SLAs, MTTR, incident trends, and a monthly report to management. This is how you demonstrate control and management accountability.
9. Roles and training. A clear RACI, defined ownership, and security awareness training for support staff, because the service desk is a favourite target for social engineering.

Your audit-readiness checklist

Here is the short version to pin above your desk. If any of these is missing, it is a priority before the auditor arrives.

• Incident register with classification, timestamps and a “reportable” flag
• Severity matrix mapped to NIS2 and DORA reporting thresholds, plus 24h and 72h templates
• Escalation matrix that names who notifies the regulator
• Access approval records, a privileged account list, and the date of the last review
• Change log with approvals and back-out plans, and a current asset list or CMDB
• Versioned SOPs and runbooks with last-review dates
• SLA definitions and the last 6 to 12 months of SLA and MTTR reports
• Supplier list with contracts, SLAs and exit plans
• A business continuity or disaster recovery plan with a recent test on record
• Security training records for the support team
• A retention policy for support records and logs
• An evidence pack: a few sample tickets that show the whole process end to end

We packaged this into two documents you can use straight away: a full guide and a printable one-page checklist.

• Download the guide: Audit-ready support for ISO 27001, NIS2 and DORA (PDF)
• Download the one-page readiness checklist (PDF)

How we help

This maps cleanly onto how we work. Consult runs a gap analysis of your support against the framework, so you know exactly where the missing processes and evidence are, with a prioritised action plan. Transform puts them in place: the ITSM tool, SLAs, escalations, runbooks, and the change and access trails. Operate keeps the evidence trail alive month after month, so the next audit is a formality rather than a fire drill.

If you have an audit on the horizon, the cheapest time to fix support is now, not the week before. Book a free 30-minute call and we will look at where you stand and tell you honestly what to tighten. If you would rather start on your own, our free maturity check takes two minutes and gives you a first read.