Is there a NIS2 certification, and what do authorities accept?
NIS2 creates no certificate of compliance. If a customer or regulator asks for a NIS2 certificate, the honest answer is that none exists under the Directive. National competent authorities oversee compliance through inspections, security audits, security scans and information requests, and they can impose administrative fines when an entity falls short. Your organization owns its controls and is responsible for showing they work. An independent auditor, assessor or certification body issues any report or certificate you present, and DeployOpen prepares systems, controls and evidence for that work but never issues those documents itself.
What counts as acceptable proof depends on the Member State. ENISA's June 2025 technical implementation guidance notes that, depending on the national framework, compliance may be demonstrated through assessment or certification by accredited conformity assessment bodies, or by auditors authorized by national authorities. Before you buy an assessment, confirm with your competent authority which route it recognizes, which bodies it accepts, and whether it expects a particular format. The ENISA technical implementation guidance is the natural starting point for the evidence examples it gives, but it is non-binding and does not replace national rules.
Plan for the fact that an ISO/IEC 27001:2022 certificate is not, by itself, proof of NIS2 compliance. ENISA's mapping to that standard does not measure equivalence, so an ISO certificate can support your evidence but leaves gaps against Implementing Regulation (EU) 2024/2690 and the national law. Ask your auditor to state in writing which requirements its work covers and which it does not, and ask the authority whether it will accept that scope. Budget for the independent assessment as a recurring cost, and treat any vendor claim of a NIS2 certificate as a question to verify before you rely on it.
Which audit route applies to your organization
NIS2 lets the national competent authority carry out security audits itself. Essential entities can face regular, targeted and ad hoc audits, while important entities face targeted audits, following the Article 32 and 33 supervision model. The authority sets the scope and timing, and it decides what it needs to see, so the entity cannot choose its auditor or limit the review to a pre-agreed sample.
- Who pays: The entity usually bears its own internal staff time and any remediation work. Confirm with your authority whether it recovers any costs of its own audit activity under your national law.
- Output: The authority issues its findings, orders or required corrective actions. No NIS2 certificate is issued.
- What to hold ready: Current risk assessment, asset inventory, policies, access records, logs and evidence of the Article 21 measures, presented in a form an inspector can follow.
- Information requests: Expect requests for documents and evidence on short notice, so assign a single contact and keep an indexed evidence library.
- Confirm: Ask the authority which audit types it runs for your sector, how it selects entities and what response times it expects.
Ask your authority in writing how it intends to audit your entity and which evidence it will request first.
Here the authority does not audit the entity itself. It has a security audit carried out by an independent body it appoints, and the results are reported back to the authority. The entity is the party being audited, but the appointed body sets the testing approach within the authority's mandate. This route is common where authorities want technical depth without building their own audit teams.
- Who pays: Depending on national rules, the entity may be invoiced directly for the audit or the cost may be recovered through supervisory fees. Confirm the billing arrangement before the audit starts.
- Output: The independent body prepares an audit report for the authority. The entity usually receives a copy or a summary, and the authority decides what follows.
- What to hold ready: System architecture, network diagrams, configuration baselines, vulnerability management records and results of any previous security testing.
- Access: Plan for technical access to systems, test accounts and staff availability, and agree rules of engagement in writing.
- Confirm: Ask the authority which bodies it has appointed, whether you may object to a selection and how the report is shared with you.
Request the audit scope and rules of engagement before any testing begins, and keep records of every access granted.
An entity may choose to commission an assessment from an accredited conformity assessment body. ENISA's June 2025 guidance notes that, depending on the national framework, compliance may be demonstrated through assessment or certification by such bodies. The entity pays for this work directly, and the assessment does not replace the authority's supervision unless your national law says so. Use this route to build evidence, prepare for an authority review or meet a customer requirement.
- Who pays: The entity contracts and pays the body directly. Costs depend on scope, sites and the depth of testing. Ask for a fixed-scope quote with named deliverables.
- Output: The body issues a report, and where its accreditation and scheme allow, a certificate. Check that the scheme is recognized by your authority before relying on it.
- What to hold ready: A defined scope, a current Article 21 measures register, and documented exceptions with owners and dates.
- Accreditation: Verify the body's accreditation status and the scope of its accreditation before signing.
- Confirm: Ask your authority whether it recognizes assessments from this body as evidence and how that affects the enforcement factors that apply to your entity.
A certificate or report from a body only shows what its scope covered, so compare that scope with your full in-scope environment.
Some Member States may authorize individual auditors or firms under national rules to assess NIS2 compliance. ENISA's guidance refers to auditors authorized by national authorities as one of the routes through which compliance may be demonstrated. The authorization regime, the qualifications required and the reporting format are set nationally, so the rules differ from one country to another and may change as transposition matures.
- Who pays: The entity pays the authorized auditor under a commercial contract. Some national regimes may also set fee caps or disclosure rules, which you should confirm.
- Output: The auditor issues a written report on the scope tested. Whether this report is accepted by the authority depends on the national framework.
- What to hold ready: The same evidence set the authority would request, including the results of any prior security audits and the underlying records.
- Independence: Check that the auditor is independent of the team that operates or implemented the controls being assessed.
- Confirm: Ask the competent authority for the current list of authorized auditors, the authorization criteria and whether a report from them satisfies a supervisory request.
Verify the auditor's authorization in writing before signing, because a report from an unauthorized firm may carry no weight with your authority.
Where ISO 27001, schemes and codes of conduct fit
NIS2 does not issue a certificate, so entities choose among several routes to show their risk-management measures work. Each route below carries different weight with authorities, and none of them replaces the others. Read each card as a question to put to your supervisor, your auditor and your own evidence.
ISO/IEC 27001:2022 certification
An ISO/IEC 27001:2022 certificate shows that an accredited certification body found an information security management system operating against that standard's requirements and Annex A controls. It is useful evidence for many Article 21 measures, but ENISA's mapping to Implementing Regulation 2024/2690 does not measure equivalence. A certificate alone does not prove NIS2 compliance. Check which scope the certificate covers, whether it includes the in-scope services, and which Implementing Regulation 2024/2690 sections the gap analysis still leaves open.
European cybersecurity certification schemes
Schemes adopted under the Cybersecurity Act certify ICT products, services and processes against defined assurance requirements. Under Article 24(1), Member States may require essential and important entities to use certified ICT products, services and processes. Under Article 24(2), the Commission may adopt delegated acts requiring certain entity categories to use certified products or obtain a certificate, after an impact assessment and with an implementation period. Confirm with your national authority whether your Member State has used this power and which scheme, if any, applies to your products.
Approved codes of conduct and certification mechanisms
Approved codes of conduct and approved certification mechanisms are tools that a competent body or scheme owner has formally endorsed for a sector or service. Articles 32(7)(g) and 34(3) require authorities to consider adherence when deciding enforcement measures and fines. Adherence is a factor, not a shield, so it does not excuse a failed measure. Ask whether a code or mechanism exists for your sector, who approved it, and whether your assessment covers the version the authority recognizes.
Nationally recognized standards and schemes
Recital 80 says that, without appropriate European certification schemes, Member States should promote relevant European and international standards for demonstrating compliance with risk-management measures. Depending on the national framework, ENISA's June 2025 guidance notes that compliance may be shown through assessment by accredited conformity assessment bodies or by auditors authorized by national authorities. Confirm which standards and assessor types your national authority accepts before buying an assessment, because acceptance varies by Member State.
Proposed Cybersecurity Act changes (proposal)
The Commission's 20 January 2026 revised Cybersecurity Act proposal would let companies certify their cyber posture under voluntary ENISA-managed schemes. It is a proposal, not law, and it needs approval by the European Parliament and the Council before it applies. Do not plan a procurement or a supervisor response around it yet. Track the status of the proposal and check whether any resulting scheme would be recognized under your national NIS2 law.
How an audit runs from request to findings
The sequence moves from the authority's notice through evidence collection, testing and findings to remediation and follow-up, and each stage leaves a written record that the next stage depends on. NIS2 creates no certificate, so the outcome of this sequence is an authority's assessment of the entity's own evidence, not a pass mark.
Receive the authority notice and agree scope
The national competent authority, or an independent body acting for it, notifies the entity that an audit or inspection will take place and states its type, such as a regular, targeted or ad hoc audit for essential entities or a targeted audit for important entities. Management and the compliance lead confirm which systems, sites, suppliers and Article 21 measures fall within the review and who is the named contact. The output is a written scope note that the entity keeps on file. Confirm with the authority which legal basis applies under the national transposition law and what timelines it will follow, because these vary by Member State.
Assemble the evidence pack
The entity gathers the evidence that shows its risk-management measures are in place and operating, such as the risk assessment, approved policies, asset inventory, access reviews, patch records, backup restore tests, incident logs and supplier assessments. Each item is mapped to the Article 21 measure or Implementing Regulation 2024/2690 requirement it supports, using ENISA's June 2025 examples of evidence as a reference. The output is an indexed evidence pack with owners and dates, and it is checked for gaps before anything is sent. Where the entity has commissioned an implementation partner, that partner prepares the pack, but the entity remains responsible for its accuracy.
Submit evidence and answer information requests
The entity provides the evidence pack and responds to follow-up information requests within the period the authority sets. Authorities may ask for the results of security audits carried out by a qualified auditor and the underlying evidence, so prior audit reports and their working papers should be retrievable without delay. Each submission and response is logged with a version reference. The output is a complete submission record showing what was provided, when and by whom, which later protects the entity if a question about a previous answer arises.
Testing by the auditor or authority
The authority, or an independent body it appoints, tests the evidence and, where scoped, the systems themselves through interviews, configuration review, sample checks, security scans and walkthroughs of processes such as incident handling. Testers compare what the entity says it does with what the systems and records show. The output is the testers' working notes and preliminary observations, which the entity may ask to discuss before the report is finalized. Ask the auditor how it will handle live testing, access windows and the handling of personal data found during sampling, and confirm this in writing before testing begins.
Issue findings and classify them
The auditor or authority issues findings that describe each gap, the requirement it relates to and the evidence that supports the finding. Findings are typically graded by severity so that the entity can see which items need urgent attention and which are documentation issues. The output is a findings report that the entity reviews for factual accuracy and can answer through a formal response. Note that a finding is not a certificate outcome, and the authority decides on any enforcement measures in line with its powers under the national law and NIS2.
Build the remediation plan
Management approves a remediation plan that assigns each finding to a named owner, states the corrective action, sets a target date agreed with the authority where required, and identifies the evidence that will close the item. Where a finding reflects a control that was never designed, the plan includes the design work and not only a documentation update. The output is a signed remediation plan tracked in a register that management reviews. Plans should be realistic about resourcing, and any dependency on suppliers should be captured so the supplier obligations are visible.
Close findings and confirm follow-up
The entity implements the corrective actions, collects closure evidence for each finding and submits it to the authority or auditor for verification. The authority may conduct a follow-up review to confirm that the actions were effective, and the entity should expect questions about recurrence rather than only about the fix. The output is a closure record for every finding, including the evidence reference, the verifier and the date, plus an updated risk assessment. Confirm with the authority or auditor what form of follow-up applies and how long the records must be retained.
What a NIS2 audit costs and who pays for each part
This table compares each cost component of a NIS2-related audit by who pays for it and whether it is one-time or recurring. Use it to build a quote request, because no supplied fact gives a price for any component. The main takeaway is that the entity bears every component, even when an outside party performs the work.
| Cost component | Who is paid or who bears it | One-time or recurring, and main cost driver |
|---|---|---|
| Internal staff time | The entity's own employees, including security, IT, legal and management body members who approve and oversee the measures | Recurs with each audit cycle. Driven by how many systems, sites and policies are in scope and how ready the evidence is |
| Implementation partner work | An outside firm such as DeployOpen, paid under a written, fixed-scope agreement to prepare systems, controls and evidence | Mostly one-time for preparation, with optional recurring retainers for upkeep. Driven by scope, number of systems and gaps found |
| Independent auditor or certification body fees | The independent auditor, assessor or certification body that tests the controls and issues any report or certificate | Recurs at each assessment. Driven by scope, sampling, number of sites and whether the assessor is accredited or authorized under national rules |
| Authority-run audits | The national competent authority, with the entity bearing its own cost of cooperating, producing evidence and remediating findings | Triggered by supervision. Essential entities face regular, targeted and ad hoc audits. Important entities face targeted audits. Driven by findings and the readiness of evidence |
| Independent body audits ordered by an authority | The entity pays for an independent body when the authority has it carry out a security audit | Occurs when ordered rather than on a fixed schedule. Driven by the audit scope the authority sets |
| Tooling and evidence systems | Software vendors, hosting providers, or internal teams for open-source and self-hosted tools that produce logs, asset inventories and records | Licenses or hosting recur. Build and configuration are one-time. Driven by log volume, retention needs and integration work |
| Remediation of audit findings | The entity, through internal staff or contractors | Often one-time per finding, but findings can recur if controls drift. Driven by the number and severity of findings |
What makes a NIS2 audit larger or slower
Authority-led audits of NIS2 entities expand or contract with a small set of variables. The cards below cover what drives effort in each one and the steps that keep an audit focused on what the authority actually asks to see.
Number of in-scope services and sites
Every service, system and site that falls within the entity's NIS2 scope is something an auditor may sample, trace and ask about. A broad scope multiplies the systems to document, the owners to interview and the configurations to test. Define the in-scope services in writing, map each to its supporting systems and locations, and remove what is out of scope with a documented rationale. Ask the auditor early which boundary they will accept.
Essential versus important classification
Essential entities can face regular, targeted and ad hoc audits, while important entities are generally subject to targeted audits (Articles 32 and 33). The classification therefore sets how often evidence is requested and how quickly it must be produced. Confirm the classification with the national competent authority and the applicable national law, since transposition details vary, and plan audit readiness around the stricter regime if there is any doubt.
Number of Member States
An entity operating in several Member States may fall under more than one national authority, each with its own registration, reporting and inspection practices. Each authority can request evidence separately, which means the same control may be examined more than once in different formats. Identify the competent authority for each jurisdiction, agree a single evidence library that all of them can draw from, and confirm with each authority what format it expects.
Third-party and cloud dependencies
Controls that depend on a managed provider, a cloud platform or an outsourced SOC are harder to evidence because the entity must obtain proof from a party it does not operate. Contracts, service reports and incident notices from each supplier may be needed during an audit. Inventory each critical dependency, confirm which audit reports and contractual rights are available, and record how supplier evidence reaches your own evidence library before an authority asks for it.
Evidence maturity
Auditors test whether controls operate over time, not only whether a policy exists. Evidence that is scattered across tickets, chat logs and personal folders takes longer to assemble and invites further sampling. Map each Article 21 measure to a named owner, a recurring artifact and a storage location, such as exported access reviews, patch records or test results. ENISA's June 2025 guidance gives examples of evidence that can serve as a starting point.
Incident history
A recent significant incident, or a pattern of late or incomplete reports, typically leads an authority to look more closely at detection, response and the reporting timeline. Records of past incidents, lessons learned and corrective actions are therefore likely to be requested. Keep incident registers current, document how each corrective action was closed and confirm that the 24-hour, 72-hour and one-month reporting steps can be evidenced for each event.
Who owns controls, who prepares evidence and who certifies
Your organization remains accountable for NIS2 compliance. Under the Directive, the management body approves and oversees the Article 21 risk-management measures, and the entity answers to its national competent authority for how those measures work in practice. No outside party can take that accountability over, and a supervisor will ask management, not a vendor, to explain decisions.
- Ownership of controls: Management sets the risk appetite, approves policies and assigns an owner to each Article 21 measure.
- Operation of controls: Your staff run access reviews, patching, backups, incident handling and supplier reviews every day, whatever tooling sits underneath.
- Decisions and sign-off: Accepted risks, scope decisions and any deviation from a measure are recorded as management decisions.
- Evidence retention: Your organization keeps the logs, tickets, approvals and test results that show controls operated over time.
- Regulator contact: Registration, incident notifications and information requests go from your organization, even when a partner drafted the material.
Before engaging anyone, confirm internally who holds each control owner role and who signs off evidence for the authority.
An implementation partner such as DeployOpen plans, builds, hardens and documents the systems that produce NIS2 evidence, and helps assemble that evidence for review. In DeployOpen's case this covers self-hosted open-source platforms inside the client's own infrastructure. The partner does not decide whether the organization is compliant and does not issue any audit report, attestation or certificate.
- Systems preparation: Deploying, configuring and hardening self-hosted platforms in the client's cloud accounts, data centers or air-gapped networks.
- Evidence preparation: Setting up logging, configuration baselines, backup records and ticket workflows so that evidence can be exported in a usable form.
- Documentation: Drafting runbooks, architecture records and control descriptions that the client's staff review and adopt.
- Testing support: Running security testing that feeds findings into the client's own risk register.
- Handover and support: Training internal staff, and offering ongoing support or retainers if the client wants them.
In a fixed-scope engagement, check the written scope for which items are delivered as documents, which as configured systems, and which remain your responsibility after handover.
An independent auditor, assessor or certification body is the only party that issues an assessment result. Depending on the national framework, ENISA's June 2025 guidance notes that compliance may be shown through assessment or certification by accredited conformity assessment bodies or by auditors authorized by national authorities. NIS2 itself creates no certificate, so the authority decides which assessment routes it accepts. Article 32(2) allows authorities to have security audits carried out by an independent body, and they may request the results of audits carried out by a qualified auditor.
- Independence: The auditor must not design or implement the controls it tests, which is why the partner and the auditor should be separate firms.
- Testing: The auditor samples evidence, interviews staff and checks that controls operated across the audit period.
- Reporting: Findings and any formal conclusion come from the auditor, in its own report format.
- Recognition: Confirm with your national authority whether it accepts a given assessor or certification route.
- Fees: The auditor is paid directly by the organization under its own engagement letter.
Before signing, confirm with the authority or the auditor which assessment routes count in your Member State and in what form they will be accepted.
How to choose an auditor, certification body or consultant
NIS2 has no certificate, so the question is less which body certifies you and more which party can credibly produce evidence your national authority will accept. The cards below cover the checks that separate a qualified assessor from a vendor selling a badge, and the questions to settle before any written scope is signed.
Confirm accreditation or national authorization
Where your national framework relies on accredited conformity assessment bodies or auditors authorized by the national authority, that status is the first gate. ENISA's June 2025 guidance says compliance may be demonstrated this way, depending on the Member State. Ask the body for its accreditation or authorization details, then confirm them directly with the competent authority, because a claim on a website or in a sales deck is not enough.
Check independence from implementation work
An assessor that designed or built the controls it then tests cannot give an independent opinion. Ask whether the firm has prepared your policies, configured your systems or run your remediation, and whether that work sits in the same engagement. Implementation partners prepare systems and evidence, while only an independent auditor, assessor or certification body issues reports or certificates. Keep those roles in separate contracts where your authority expects it.
Verify sector and entity experience
NIS2 covers 18 sectors, and the expectations for a cloud provider, a hospital and a water utility differ in their operational detail. Ask for named examples of assessments in your sector and entity type, described without client names. Confirm that the assessors understand the Annex I or Annex II rules that apply to you, and how they handle groups that operate in several Member States.
Review sample reports and methodology
Ask for a redacted sample of the report or assessment output, along with the method used to reach each finding. A useful method names the ENISA evidence examples it follows, states how it samples systems and records, and separates observed evidence from management statements. Vague output such as a single pass or fail score for the Article 21 measures tells you little about what your supervisor will later ask to see.
Ask how evidence is handled
Supervisors can request the results of security audits and the underlying evidence. Ask who retains the working papers, how long they are kept, in which jurisdiction they are stored, and whether you receive copies you can hand to an authority. Clarify the confidentiality terms and whether the body will discuss its findings with a regulator directly during an inspection.
Settle the written scope first
Before signing, agree in writing on the entity and systems in scope, the Article 21 measures and Implementing Regulation 2024/2690 sections assessed, the sampling approach, the deliverables and the timeline. Ask for the fees to be separated into one-time assessment work and any recurring surveillance or retainer work, and confirm what happens if the authority requests additional evidence. A fixed scope makes the quote comparable across bidders.
NIS2 certification and audit questions buyers ask
Is there a NIS2 certificate I can buy?
No. NIS2 creates no certificate of compliance. National competent authorities supervise compliance through inspections, security audits, security scans and information requests, and they can impose administrative fines. Some national frameworks let authorities or the entity rely on assessment or certification by accredited conformity assessment bodies or by auditors authorized by the national authority, so the reader should confirm with their competent authority which routes count in their Member State. Any vendor offering a NIS2 certificate should be asked which authority recognizes it and on what legal basis. A certificate from a body that is not recognized in the entity's jurisdiction does not discharge the entity's own obligations.
Can an ISO 27001 certificate satisfy NIS2?
Not by itself. ENISA's mapping of Implementing Regulation (EU) 2024/2690 to ISO/IEC 27001:2022 does not measure equivalence, so an ISO 27001 certificate does not demonstrate NIS2 compliance on its own. ISO 27001 overlaps with many of the Article 21 measures, and recital 80 of NIS2 points Member States toward relevant European and international standards where no European certification scheme exists. The gaps usually sit in the governance duties of the management body, the staged incident reporting deadlines and the sector-specific requirements of the implementing regulation. Ask the authority whether it accepts ISO 27001 evidence and which parts it expects to see in addition. The ENISA technical implementation guidance lists examples of evidence.
Who issues the NIS2 audit report?
An independent auditor, assessor or conformity assessment body issues the report, and the authority decides how to use it. NIS2 lets authorities carry out security audits themselves or have an independent body carry them out. Essential entities face regular, targeted and ad hoc audits, while important entities face targeted audits. Authorities may ask for the results of security audits carried out by a qualified auditor together with the underlying evidence. An implementation partner, including DeployOpen, prepares systems, controls and evidence but does not issue audit reports or attestations. Confirm with your authority which auditor types it recognizes, whether they must be authorized, and how the report must be delivered.
Can we run the NIS2 audit ourselves?
You can prepare and run internal reviews yourselves, but an internal review does not replace the audit an authority may require. Internal audit, control testing and gap reviews help the organization find weaknesses before an authority does. Whether a particular audit must come from an external party depends on the national law and on the authority's choice to carry out the audit itself or to appoint an independent body. The management body remains accountable for the Article 21 measures either way. Confirm with your authority whether self-assessment is accepted for any part of your obligations, and document who in your organization owns each control and each test.
How long does a NIS2 audit take and what does it cost?
The supplied sources do not give a duration or fee for a NIS2 audit, so ask your auditor or authority for both in writing. The cost usually depends on the number of entities and sites in scope, the number of systems and suppliers that the assessment covers, the depth of evidence that must be reviewed, and whether the authority requires an accredited or authorized assessor. The Commission's official cost estimates and the audit cost discussion are covered on the NIS2 compliance cost page. Ask each auditor for a written scope, a list of deliverables, the evidence they expect from you and a separate quote for any re-test or follow-up. Preparation work, such as building an evidence pack, is a different cost from the audit fee.
What evidence do we need to provide to the authority?
Authorities can ask for evidence of implementation, including the results of security audits by a qualified auditor and the underlying evidence behind them. In practice, the evidence pack usually covers:
- A current risk assessment and the approval of the Article 21 measures by the management body
- Policies, procedures and asset inventories that match the systems in scope
- Records of access reviews, change management, backups and patching with dates and owners
- Incident response plans, exercise records and logs that show the staged reporting process
- Supplier assessments, contract clauses and records of security audits or attestations received from suppliers
Ask your authority for its evidence expectations and compare them with the ENISA examples, which are non-binding.
Does DeployOpen certify us for NIS2?
No. DeployOpen does not issue audit reports, attestations or certifications. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and it can prepare systems, controls and evidence for an assessment. Your organization owns its controls and the decisions about scope, and an independent auditor, assessor or certification body issues any report. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask DeployOpen for the written scope that lists which evidence it will prepare and which parts remain with your auditor and your management body.
Which NIS2 requirements can a self-hosted platform evidence?
Self-hosted open-source platforms can generate logs, configuration records, access reviews, backup reports and change histories that support several Article 21 measures, provided they are configured, retained and reviewed correctly. The useful question for an engineer is whether each platform produces evidence in a form an auditor can sample, such as timestamped logs, exported configurations and documented approvals. Confirm for each component whether it supports the logging, retention and access controls your auditor will test, and document any gap that needs a compensating control. The implementation partner can set these up, but the authority will assess your organization's controls, not the tool.
How DeployOpen prepares your NIS2 evidence before an audit
NIS2 creates no certificate, so the work is preparing systems, controls and evidence that a national authority or independent auditor can test. DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, then documents the evidence, while your organization keeps ownership of its controls and the independent auditor issues any report.
How we scope
- Engagements are fixed-scope, with the systems, controls and evidence set agreed in writing before work starts.
- The written scope names which in-scope entity, sites and systems the NIS2 evidence covers and which authority or audit body it targets.
- Scope confirms who owns each Article 21 control, so management keeps decisions and ownership while we prepare the technical work.
How we build
- We implement and harden self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks.
- We configure logging, access control, backup and patch records so they produce the evidence an assessor will request.
- We run security testing against applications, APIs and infrastructure, and document the findings and remediation for audit files.
How we hand over
- Deliverables include configuration baselines, control descriptions, runbooks and an evidence index mapped to the agreed scope.
- Documentation is written so your own staff can reproduce the evidence without DeployOpen involved.
- Handover covers what the independent auditor or authority will need to see, and which items remain your responsibility to confirm.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer keeps evidence current as platforms are upgraded and as the national transposition and audit expectations change.
- Ask any provider to confirm in writing which report or certificate, if any, they issue. DeployOpen prepares evidence but does not issue audit reports or certifications.
