NIS2 audits do not happen only in response to incidents. Under the directive, supervisory authorities have the right to proactively request information, conduct document-based inspections, and in some cases carry out on-site inspections of essential and important entities.
The distinction matters: NIS2 supervisory oversight is not triggered only by incidents. Authorities can conduct proactive inspections — and what they examine is whether risk is managed systematically, as an ongoing practice, not whether the organisation can respond well to a crisis.
Here is what you need to have ready.
Asset inventory — certificates and systems
Supervisory authorities will expect documented evidence that your organisation knows its information assets. For certificates, that means:
- A list of all certificates in use, with associated domains, issuance date, expiry date, and named owner
- Which systems each certificate protects — and the classification of those systems (critical, important, standard)
- Third-party certificates on your organisation's domains (supply chain)
- Evidence that the list is kept current — not assembled for the occasion
That last point matters: a list generated in preparation for an audit looks very different from a report produced by a system that has been running continuous scanning for six months. Supervisory authorities know the difference.
Risk assessment for the certificate lifecycle
Article 21(2)(a) requires risk analysis. For certificates, your documentation should include:
- Risk identification: certificate expiry, weak TLS configuration, compromised keys, shadow IT certificates
- Likelihood and impact assessment for each risk area
- The controls implemented to mitigate each risk — and what the residual risk is
- Date of the most recent assessment and the person responsible
A risk assessment that is two years old and has not been updated is difficult to defend. The risk assessment should be a living document with dated revisions.
Certificate incident procedures
What happens in your organisation, concretely, if a certificate expires unexpectedly? Supervisory authorities will expect an answer that points to documented procedures:
- Who detects it — and how? (Monitoring, alerting, a customer report?)
- Who is notified, and in what order?
- Who has authority to initiate emergency renewal?
- What is the escalation path if the primary responsible person is unavailable?
- When is an incident assessed as reportable under NIS2?
These procedures do not need to be lengthy — but they must exist, be dated, and ideally show evidence of having been tested or exercised.
Incident log and history
Has your organisation experienced certificate-related incidents? Expired certificates, emergency renewals, configuration errors that were caught? Supervisory authorities may ask — and your ability to document what happened, when, and what was done is a sign of operational maturity.
There is a counterintuitive point here worth making explicitly: a completely clean incident record is not reassuring to a supervisory authority — it raises the question of whether monitoring is actually working at all. A history that shows incidents detected, documented, and resolved is far more credible than one that shows nothing.
Supply chain documentation
Article 21(2)(d) and Article 22 on supply chain security are among the requirements many organisations are least prepared for. For certificates, this means:
- A list of critical suppliers delivering services over TLS
- Evidence that supplier certificates are monitored — or contractual requirements on the supplier to do so
- What happens if a critical supplier's certificate expires and disrupts your service
Why NIS2 audit readiness cannot be assembled at the last minute
Any documentation that requires historical data is difficult to reconstruct for an audit. Specifically, these evidence types cannot be credibly produced retroactively:
- An audit log showing when each certificate was scanned and what changed
- A time series of expiry status demonstrating continuous monitoring over months
- Alert trigger history showing that alerting actually functioned
- Reports stamped with the date they were generated — not the date of the inspection
- Scan timestamps that show ongoing, systematic coverage — not a one-off scan run before the audit
That is the concrete reason to invest in automated certificate management now, not two weeks before an audit: the system continuously builds the documentation you need. See the NIS2 compliance checklist for a full list of what supervisory authorities examine.
What CertControl produces for NIS2 documentation
The five document types described above are what CertControl delivers as part of ongoing operations — not as a preparation exercise before an audit:
- Certificate register with expiry dates, owners, and associated systems. CertControl discovers certificates automatically via CT logs and active scanning. The register is always current — every certificate has a named owner in the system, and associated systems are visible through scanning.
- Monitoring status with a continuous time series. CertControl logs when each endpoint was last scanned, which findings exist, and whether they have changed. When supervisory authorities ask "when did you last run a scan?" you have a precise, timestamped answer.
- Alert configuration and alert log. Warning intervals, recipients, and alert history are all accessible in the platform. When asked for evidence that alerting actually works, you provide the log — not a verbal assurance.
- Incident procedure supported by system data. CertControl provides the background information needed for rapid assessment: which systems are affected, what the certificate's history is, when it expires. That is the foundation for a procedure that holds up under NIS2's 24-hour reporting requirement.
- Supply chain documentation via supplier monitoring. CertControl can monitor TLS certificates on critical suppliers' endpoints directly. The list of monitored supplier certificates and the alert history constitute the documentation for Article 21(2)(f) compliance.