Why the evidence file is urgent
The NIS2 directive entered into force in January 2023, and the transposition deadline for EU member states was set at 17 October 2024. Entities notified after that date were generally given an 18-month period to achieve compliance — a deadline that expires now due for most affected organisations. First enforcement actions are under way in several member states, and competent authorities are now issuing formal documentation requests.
A NIS2 audit does not merely verify that technical measures are in place: it requires dated, traceable and opposable evidence. A correctly configured system that is not documented will not pass an audit — neither will an incident report without a reliable timestamp. Building the evidence file is therefore a task distinct from technical compliance itself, and it involves your hosting provider as much as your own teams.
What this article covers
- Provider scope — what the provider is responsible for proving and what it cannot certify on your behalf
- Access and security logs — which logs to request, in what format and for what retention period
- Patch management — vulnerability and patch reports applicable to the underlying infrastructure
- Security SLA — contractual clauses that carry evidential weight during an audit
- Business continuity plan (BCP) — what the provider documents and what you must produce yourself
- Incident report — the NIS2 article 23 notification timeline and the evidence chain to reconstruct
- What the provider cannot certify — the clear boundary between infrastructure and the client's security policy
The boundary between what the provider proves and what falls on you
The most common audit objection: 'our hosting provider is ISO 27001 certified — does that cover our NIS2 compliance?' The answer is no, and the distinction matters. The provider proves the security of its infrastructure — datacenter, hypervisor, network, its staff's internal procedures. You prove the security of what you deploy on top of it: your applications, your data, your access controls, your procedures.
Article 21 of the NIS2 directive imposes measures on the entity subject to the directive, not on its hosting provider. The provider is an element of your supply chain (Art. 21.d): you must document how you assessed its security practices, what contractual clauses protect you, and what incident notification mechanisms it offers. What the provider can never produce in your place: your asset map, your formalised security policy, your team training, your own incident management procedure, and proof that your application data is encrypted according to your own choices.
Documentary responsibilities
Scroll the table
| Domain | What the provider documents | What you document |
|---|---|---|
| Physical infrastructure | Datacenter certification (ISO 27001, SOC 2), physical access control, redundant power | Choice of datacenter and justification of geographical data location |
| Network and hypervisor | Network flow logs, VM isolation, hypervisor patching | Application firewall configuration, network rules on the guest OS side |
| Patch management | Patch bulletins applied to the infrastructure, CVEs addressed | OS updates, application dependencies, runtime |
| Access logs | Access to management panel, administrative actions on the infrastructure | Application logs, SSH authentication logs, database access |
| Security incidents | Notification within NIS2 article 23 deadlines, incident report on the infrastructure | Your own incident report, impact on your data and services |
| Business continuity | Availability SLA, infrastructure recovery plan, VM snapshot backups | Defined RPO/RTO, tested application restore, documented crisis plan |
| Security policy | Provider's internal security policy (provided on contractual request) | Your IS security policy, asset map, team training |
Access and security logs: what to request
Logs are the first thing a NIS2 auditor requests, as they allow reconstruction of an incident's timeline (Art. 21.b) and prove that access controls are actually enforced. On a VPS, the log chain involves two layers: the provider's (access to the management panel, operations on the infrastructure) and yours (guest operating system, applications).
From the provider side, logs to request explicitly are: management panel login events (with source IP address and timestamp), VM resize, snapshot or reinstall operations, and security alerts detected at the infrastructure level. These logs must be exportable in a structured format (JSON, CSV) and cover at minimum the last 90 days. For authentication and administration logs, a 12-month retention period is recommended by most national CSIRTs.
On your VPS side, the minimum configuration to document includes: centralising auth.log (or secure on Red Hat distributions) to storage the application account cannot modify, retaining Nginx/Apache logs with rotation configured to keep at least 90 days, and exporting to an external solution (remote syslog, Loki, Elasticsearch) to preserve integrity in the event of server compromise.
Documents to request from your provider regarding logs
- Management panel access log — export of connections with source IP, date/time, action performed, covering minimum 12 months
- Infrastructure operations log — VM creation/deletion/resize, snapshots, network configuration changes
- Documented retention policy — official log retention duration, format and export procedure
- Network security alerts — reports of anomalies detected at the infrastructure level (scans, perimeter intrusion attempts)
- Log access procedure during an incident — channel, response time and delivery format for urgent requests from an auditor or authority
Patch management: evidence on the provider and client sides
Article 21 NIS2 requires measures to ensure security in the acquisition, development and maintenance of systems. For a VPS, this covers two distinct perimeters that an auditor will examine separately.
From the provider side, elements to request are: the vulnerability management policy applied to the hypervisor and network infrastructure, security bulletins published or transmitted to customers for critical CVEs affecting the underlying infrastructure, and contractually guaranteed deployment timeframes for critical patches. On ServOrbit, the infrastructure patch management policy is documented and communicated during incidents affecting the hypervisor; you can request a formalised copy for your audit file.
On the client side, you must document: OS update frequency (weekly or monthly according to your policy), application dependency management (scanning tool, register of CVEs addressed), and tests carried out before deploying a patch to production. A simple dated and signed update log — even a spreadsheet — constitutes valid evidence if maintained consistently.
Building your NIS2 evidence file: practical steps
Request the infrastructure compliance file from your provider
Submit a written request to your provider specifying the NIS2 framework and required elements: current ISO 27001 or SOC 2 certificate, datacenter locations, vulnerability management policy, incident notification procedure. On ServOrbit, this file can be requested via support by mentioning your NIS2 audit process — specify that you need a formalised, dated document.
Audit and export VPS access logs
Log in to your ServOrbit management panel and export the history of connections and operations. On the VPS itself, check the
logrotateconfiguration forauth.logand your application logs: therotatedirective must allow a minimum 90-day retention. Configure export to external storage withrsyslogor a Loki agent if not already in place — this is the only way to prove log integrity in the event of server compromise.Verify and document contractual clauses with evidential value
Re-read your hosting contract looking explicitly for: availability SLA with measurable penalties, obligations to notify in the event of a security incident affecting the infrastructure (deadline and channel), log retention duration and access procedure during investigation, conditions for audit or inspection by the client or their representative, and business continuity commitments with measurable metrics (RTO, RPO).
Produce your own documented security policy
The provider cannot produce this document in your place. It must cover at minimum: the map of hosted critical assets, access management rules (mandatory MFA, SSH keys, secret rotation policy), the backup policy (frequency, location, restoration test), and the people authorised to access the infrastructure. A one-to-two-page document, dated and approved by management, constitutes valid evidence.
Put in place and test the business continuity plan
The NIS2 BCP covers two levels: the provider's (infrastructure availability, failover procedure) and yours (application restoration procedure, escalation contacts, failover decision). On ServOrbit, document the available automated snapshots, their frequency and retention. Add your own restoration procedure, tested and dated — an undocumented restoration test does not exist in an auditor's eyes.
Prepare the NIS2 incident notification procedure
Article 23 of the directive requires: an early warning to the competent national authority within 24 hours of detecting a significant incident, a formal notification within 72 hours including initial impact assessment and probable cause, and a final report within one month. Define in writing: who is responsible for notification, what significance threshold is retained, and which channel is used (national authority platform, secure email).
Configure backups with proof of restoration testing
On ServOrbit, automated snapshots cover the VM layer. For the application layer, configure a separate backup exported to external object storage (S3 compatible). Document each restoration test: date, version restored, duration, result. A table in a versioned file (git) constitutes a valid trace. The minimum recommended frequency for a full restoration test is quarterly.
Verify the supply chain (Art. 21.d)
Inventory all suppliers with access to your infrastructure: provider, managed services, external developers, integrators, critical library vendors. For each, document: the access level granted, security clauses in the contract, and the procedure if the supplier itself suffers an incident. Your hosting provider must appear in this inventory with its certifications and contractual commitments.
Archive and version the entire file
A NIS2 compliance file must be dateable and opposable. Store all documents in an access-controlled, versioned space (a private git repository works well), with a change history. Each document must carry a date, a version and the identity of its approver. Plan a minimum annual review, also documented.
Security SLA: clauses with evidential value
An availability SLA (contractual uptime) is not a security SLA. For a NIS2 audit, contractual clauses with evidential value are different and more specific. Here is what distinguishes an acceptable hosting contract from an insufficient one under the directive.
Essential clauses for NIS2 cover: the security incident notification deadline for infrastructure incidents (must be 24 hours or less to be compatible with article 23), the type of information transmitted during an incident (at minimum: nature of the incident, affected systems, measures taken), log retention duration and access procedure during investigation, conditions for audit or inspection by the client or their representative, and business continuity commitments with measurable metrics (RTO, RPO).
On ServOrbit, the general terms document availability commitments and notification obligations. For NIS2 entities, we recommend supplementing this with a written exchange specifying incident notification deadlines and log access procedures — this exchange itself constitutes a piece of the evidence file.
Hardening: do not rely on your provider's ISO 27001 certification as sole evidence. ISO 27001 covers the provider's internal processes, not your specific environment. Explicitly request the certification scope (is your datacenter included?) and its issue date. Supplement with recent security bulletins and incident reports for the past 12 months where available. For your own perimeter, an annual penetration test by a third party and its report constitute the strongest evidence of your security posture maturity — far more than a self-declared checklist.
NIS2 incident report: the evidence chain to reconstruct
Article 23 of the NIS2 directive is one of the most concrete and demanding obligations: it imposes a precise notification sequence, and the absence of dated evidence at each step is itself a violation. Understanding this sequence before an incident occurs is essential.
The required timeline is as follows: within 24 hours of detecting a significant incident, the entity must transmit an early warning to the competent national authority (ANSSI in France, BSI in Germany, according to your member state). This warning must indicate that the incident is suspected to be of malicious origin or to have cross-border impact. Within 72 hours of detection, a formal notification must be transmitted with: an initial severity assessment, the affected systems, and the probable cause. Within one month of incident resolution, a final report must document the full timeline, corrective measures taken and lessons learned.
To be able to produce these documents, your infrastructure must provide evidence at each step: the precise detection timestamp (log with server timestamp), the list of affected systems (up-to-date inventory), the nature of data exposed (asset map), and actions taken (operations log). Your provider must supply its own timeline if the incident touches its infrastructure — this obligation must be written into your contract.
Conclusion and further reading
Building a NIS2 evidence file is not a bureaucratic exercise: it is the documentary translation of security practices that, if genuinely in place, only need to be formalised. The fundamental distinction to keep in mind is between what your hosting provider proves (its infrastructure, its processes, its certifications) and what you must produce yourself (your policy, your assets, your procedures, your tests).
On a ServOrbit VPS, the technical building blocks are available: automated snapshots, exportable access logs, contractual incident notification, and certified infrastructure. What you must add is the documentary layer that makes these elements opposable to an auditor: formalised requests, verified contractual clauses, written and tested procedures.
For further reading: general obligations for hosting providers and their clients under NIS2 are detailed in [nis2-hebergement-obligations-clients-2026](/blog/nis2-hebergement-obligations-clients-2026). The impact of the Cyber Resilience Act on software components in your infrastructure is covered in [cra-cyber-resilience-act-hebergement-2027](/blog/cra-cyber-resilience-act-hebergement-2027). Data localisation and transfer obligations under CNDP are addressed in [conformite-cndp-hebergement-hors-maroc](/blog/conformite-cndp-hebergement-hors-maroc).
