[{"data":1,"prerenderedAt":197},["ShallowReactive",2],{"seo-verification":3,"blog-nis2-compliance-evidence-from-your-vps-provider-en":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-nis2-compliance-evidence-from-your-vps-provider-en",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":27,"featuredImage":29,"bgImage":30,"posterImage":31,"relatedSolution":29,"intro":32,"sections":33,"ctaTitle":145,"ctaBody":146,"ctaButton":147,"ctaUrl":148,"relatedPosts":149},462,"nis2-compliance-evidence-from-your-vps-provider",{"fr":12,"en":10,"ar":13,"es":14},"nis2-preuve-conformite-hebergeur-vps","nis2-أدلة-الامتثال-من-مزود-استضافة-vps","nis2-evidencias-de-cumplimiento-de-tu-proveedor-vps","NIS2 compliance evidence to request from your VPS provider","Which documentary evidence to request from your VPS provider for a NIS2 audit? Access logs, patch management, security SLA, BCP, incident reports: practical guide.",13,0,false,"2026-10-17T00:00:00+00:00","2026-10-18T21:57:56+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},10,"Compliance & Regulation","conformite","bg-amber-500\u002F10 text-amber-400",[28],{"id":23,"name":24,"slug":25,"color":26,"icon":25},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fnis2-preuve-conformite-hebergeur-vps-poster.svg","Entities notified in 2025 had an 18-month compliance window now expired — the evidence file is no longer optional. Facing an auditor, one question always comes up: what can your hosting provider prove, and what must you document yourself? Directive (EU) 2022\u002F2555 (NIS2) establishes shared responsibility — the provider covers the infrastructure, you cover your processes and your assets. This article describes precisely which documents to request, which contractual clauses to verify, and which evidence you must produce on your own ServOrbit VPS.",[34,38,49,52,88,91,99,102,133,136,139,142],{"type":35,"title":36,"body":37},"h2","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.\n\nA 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.",{"type":39,"title":40,"items":41,"body":5},"ul","What this article covers",[42,43,44,45,46,47,48],"**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",{"type":35,"title":50,"body":51},"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.\n\nArticle 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.",{"type":53,"title":54,"headers":55,"rows":59,"body":5},"comparison","Documentary responsibilities",[56,57,58],"Domain","What the provider documents","What you document",[60,64,68,72,76,80,84],[61,62,63],"Physical infrastructure","Datacenter certification (ISO 27001, SOC 2), physical access control, redundant power","Choice of datacenter and justification of geographical data location",[65,66,67],"Network and hypervisor","Network flow logs, VM isolation, hypervisor patching","Application firewall configuration, network rules on the guest OS side",[69,70,71],"Patch management","Patch bulletins applied to the infrastructure, CVEs addressed","OS updates, application dependencies, runtime",[73,74,75],"Access logs","Access to management panel, administrative actions on the infrastructure","Application logs, SSH authentication logs, database access",[77,78,79],"Security incidents","Notification within NIS2 article 23 deadlines, incident report on the infrastructure","Your own incident report, impact on your data and services",[81,82,83],"Business continuity","Availability SLA, infrastructure recovery plan, VM snapshot backups","Defined RPO\u002FRTO, tested application restore, documented crisis plan",[85,86,87],"Security policy","Provider's internal security policy (provided on contractual request)","Your IS security policy, asset map, team training",{"type":35,"title":89,"body":90},"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).\n\nFrom 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.\n\nOn 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\u002FApache 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.",{"type":39,"title":92,"items":93,"body":5},"Documents to request from your provider regarding logs",[94,95,96,97,98],"**Management panel access log** — export of connections with source IP, date\u002Ftime, action performed, covering minimum 12 months","**Infrastructure operations log** — VM creation\u002Fdeletion\u002Fresize, 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",{"type":35,"title":100,"body":101},"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.\n\nFrom 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.\n\nOn 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.",{"type":103,"title":104,"steps":105,"body":5},"steps","Building your NIS2 evidence file: practical steps",[106,109,112,115,118,121,124,127,130],{"title":107,"body":108},"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.",{"title":110,"body":111},"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 `logrotate` configuration for `auth.log` and your application logs: the `rotate` directive must allow a minimum 90-day retention. Configure export to external storage with `rsyslog` or a Loki agent if not already in place — this is the only way to prove log integrity in the event of server compromise.",{"title":113,"body":114},"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).",{"title":116,"body":117},"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.",{"title":119,"body":120},"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.",{"title":122,"body":123},"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).",{"title":125,"body":126},"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.",{"title":128,"body":129},"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.",{"title":131,"body":132},"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.",{"type":35,"title":134,"body":135},"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.\n\nEssential 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).\n\nOn 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.",{"type":137,"body":138,"title":5},"tip","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.",{"type":35,"title":140,"body":141},"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.\n\nThe 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.\n\nTo 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.",{"type":35,"title":143,"body":144},"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).\n\nOn 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.\n\nFor further reading: general obligations for hosting providers and their clients under NIS2 are detailed in [nis2-hebergement-obligations-clients-2026](\u002Fblog\u002Fnis2-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](\u002Fblog\u002Fcra-cyber-resilience-act-hebergement-2027). Data localisation and transfer obligations under CNDP are addressed in [conformite-cndp-hebergement-hors-maroc](\u002Fblog\u002Fconformite-cndp-hebergement-hors-maroc).","Documentable infrastructure for your NIS2 audit","ServOrbit provides the access logs, timestamped snapshots and contractual commitments needed for your NIS2 compliance file — from 99 DH\u002Fmonth.","View our security commitment","\u002Fpourquoi\u002Fsecurite",[150,166,182],{"id":151,"slug":152,"slugs":153,"title":157,"excerpt":158,"readTime":159,"views":18,"isPinned":19,"publishedAt":160,"updatedAt":161,"category":162,"categories":163,"featuredImage":29,"bgImage":30,"posterImage":165,"relatedSolution":29},211,"nis2-what-the-directive-requires-from-your-hosted-clients",{"fr":154,"en":152,"ar":155,"es":156},"nis2-hebergement-obligations-clients-2026","nis2-ما-تفرضه-التوجيهات-على-عملائكم-المستضافين","nis2-obligaciones-hosting-clientes-2026","NIS2: what the directive requires from your hosted clients","NIS2 applies from October 2026 across the EU. Clients in essential sectors must choose providers that meet the same security standards.",4,"2026-08-02T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[164],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Fnis2-hebergement-obligations-clients-2026-poster.svg",{"id":167,"slug":168,"slugs":169,"title":173,"excerpt":174,"readTime":175,"views":176,"isPinned":19,"publishedAt":177,"updatedAt":161,"category":178,"categories":179,"featuredImage":29,"bgImage":30,"posterImage":181,"relatedSolution":29},267,"cra-2027-what-the-cyber-resilience-act-changes-for-your-agency",{"fr":170,"en":168,"ar":171,"es":172},"cra-cyber-resilience-act-hebergement-2027","cra-2027-ما-يغيره-قانون-المرونة-الإلكترونية-لوكالتك","cra-2027-cyber-resilience-act-agencias","CRA 2027: What the Cyber Resilience Act Changes for Your Agency","The Cyber Resilience Act (CRA) takes full effect in December 2027. What it requires, how it penalizes, and how to prepare your agency starting now.",11,3,"2026-08-15T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[180],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Fcra-cyber-resilience-act-hebergement-2027-poster.svg",{"id":183,"slug":184,"slugs":185,"title":189,"excerpt":190,"readTime":23,"views":191,"isPinned":19,"publishedAt":192,"updatedAt":161,"category":193,"categories":194,"featuredImage":29,"bgImage":30,"posterImage":196,"relatedSolution":29},276,"hosting-outside-morocco-cndp-prior-authorization",{"fr":186,"en":184,"ar":187,"es":188},"conformite-cndp-hebergement-hors-maroc","cndp-والاستضافة-خارج-المغرب-الترخيص-المسبق-إلزامي","alojamiento-fuera-de-marruecos-autorizacion-cndp","Hosting Outside Morocco: CNDP Prior Authorization","Moroccan Law 09-08 governs every transfer of data out of Morocco, from the first email a form collects. Authorization or simple mention: it depends on the destination.",7,"2026-08-17T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[195],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Fconformite-cndp-hebergement-hors-maroc-poster.svg",1792361096208]