Audit Preparation: What Examiners Really Want to See

When a DORA or NIS2 audit is approaching, many companies reflexively reach for documents: policies are written, organisation charts are created, process descriptions are formatted. That is understandable. But it misses the point.

Auditors do not examine whether you have documents. They examine whether your measures are effective.

The five levels of an audit examination #

An experienced auditor works through five levels. If substance is missing at any level, the levels below do not help.

1. Scope — What have you defined as relevant? #

The auditor wants to understand what scope you have established for your risk management. For open source components, this means: Do you know your SBOM? Do you know which projects are in your supply chain? Have you consciously decided what is in scope — and documented why something is out of scope?

2. Risk logic — How do you assess risks? #

Not every vulnerability is equally critical. The auditor examines whether you have a traceable methodology: How do you assess the criticality of a component? Which factors are considered — reachability, exploit probability, business relevance? Is this logic documented and consistently applied?

3. Remediation catalogue — What do you concretely do? #

This is where it becomes operational. The auditor does not want to read that you "manage vulnerabilities". They want to see: which concrete measures were taken for which vulnerability? Was a patch applied, a workaround implemented, a risk accepted? And why?

4. Governance interface — Who decides? #

A central examination point: Is there a clear interface between operational work and the decision-making level? Who assesses a risk? Who decides on the measure? Who approves a risk acceptance? The auditor looks for evidence that the management body is involved — not just formally but substantively.

5. Evidence package — Can you prove it? #

Everything you claim must be provable. The evidence package comprises: SBOM with timestamp, vulnerability assessments, remediation protocols, decision logs, final reports. An auditor must be able to trace the cycle: problem identified, assessed, decided, measure taken, outcome documented.

The cycle auditors want to see #

At its core, every auditor examines whether the following cycle works:

Problem — A vulnerability is identified
Assessment — The criticality is evaluated
Decision — The management body or an authorised responsible person decides on the measure
Measure — The decision is implemented
Outcome — The effectiveness is documented

If you can demonstrate this cycle for your open source components, you have cleared the essential hurdle.

Template narrative for the audit report #

A formulation that auditors expect and accept:

*"For the management of risks from open source components in the software supply chain, OTTRIA was engaged as a specialised service provider. OTTRIA continuously monitors all components of the SBOM, assesses identified vulnerabilities, and delivers remediation protocols with documented outcomes. The decision on implementing recommended measures remains with the management body. The cycle of detection, assessment, decision, measure, and outcome documentation is demonstrable throughout."*

What OTTRIA delivers — and what you add #

OTTRIA delivers:

SBOM evaluation and ongoing analysis
Vulnerability detection including Silent Fixes
Risk assessment per component and vulnerability
Remediation protocols with documented outcomes
Decision briefs with options for action
Compliance documentation with legal references (Art. 8/25/28 DORA, Art. 21 NIS2, Annex I CRA)

You add:

Your decision per risk — accept, mitigate, or escalate
The implementation status in your internal system
The sign-off by the management body
The integration into your overarching risk management

Together, this produces an evidence package that shows an auditor: the organisation has not merely described processes — it lives them.