Which EU regulation applies to a software or SaaS vendor first
The answer depends on what you ship and who you sell to. If you ship a product with digital elements, the Cyber Resilience Act reaches you. If you run a cloud backend, NIS2 may reach you through your customers' contracts. If you sell to banks or other EU financial entities, DORA reaches you mainly through the contracts those entities must sign. If you build AI systems, the AI Act applies, and if you process personal data for customers, the GDPR processor duties usually come first. Most vendors meet those GDPR processor obligations first, because a written contract under Article 28(3) is needed for almost every customer relationship that involves personal data. The CRA reporting duties under Article 14 started on 11 September 2026, while the rest of the regulation applies from 11 December 2027. Confirm with counsel whether your products fall within the scope set out in the Commission's guidance and whether any remote backend counts as remote data processing for a product's functions.
NIS2 and DORA usually reach a vendor through customer contracts rather than directly. Your customers in scope must manage security with their direct suppliers, so expect security schedules, incident notice clauses and audit rights in procurement questionnaires. Check which of your customers are essential or important entities under NIS2 and which are financial entities under DORA, because the clauses they will ask for differ. Ask each customer's compliance team which clauses they require and whether they need evidence on a specific timetable. None of these regimes issues a certificate, so a vendor cannot hand over a 'NIS2 certificate' or 'DORA certificate'. Offer evidence instead: risk assessments, vulnerability handling records, incident procedures, and independent test reports.
Pursuing both tracks in parallel is usually the efficient choice when you have EU customers, because the same evidence serves several regimes. A single vulnerability handling process, SBOM, incident runbook and penetration test program can support CRA Annex I obligations, NIS2 risk management measures and customer security reviews. Map each artifact to the requirement it supports and keep one evidence register. Start with the GDPR processor contract and the CRA reporting process if you have products on the market, then build the rest on shared records. Keep a short written decision for each regulation so a reviewer can see why it does or does not apply to you.
How the CRA, NIS2, DORA, the AI Act and GDPR differ for vendors
This table compares five EU regimes by who they regulate, how a vendor comes into scope, legal form, key dates, obligations, fines and certificates. Read each row across to see whether a regime binds your product, your service or only your customers' contracts.
| Factor | Regime and what it asks of vendors | How it reaches a vendor that is not itself in scope |
|---|---|---|
| Who it regulates | CRA: manufacturers of products with digital elements, including remote data processing designed as part of the product (Article 3(2)). NIS2: essential and important entities in 18 sectors, including cloud, managed and managed security service providers. DORA: 20 types of financial entity and ICT third-party providers. AI Act: AI system and general-purpose model providers and deployers. GDPR: controllers and processors of personal data. | CRA: Article 21(2)(d) of NIS2 pushes security duties down to suppliers. DORA: Article 30 contracts require ICT providers to meet financial entity terms. GDPR: Article 28(3) processor contracts flow obligations to sub-processors. AI Act: applies to non-EU providers whose output is used in the EU (Article 2). |
| How a vendor becomes in scope | CRA: the product is placed on the EU market, and standalone browser-only web applications are not products on that basis (Commission guidance C(2026) 5252, section 2.2). NIS2: the entity is classified as essential or important under Article 3 and national law. DORA: the vendor is designated a critical ICT third-party provider or signs as a provider to a financial entity. AI Act: the vendor provides or deploys an AI system in the EU. GDPR: the vendor processes personal data for a controller. | Confirm early whether your service is a product with digital elements, a managed service, a financial sector ICT service or an AI system, because each trigger uses different wording. |
| Legal form | CRA: regulation, directly applicable across the EU. NIS2: directive, applied through national transposition laws (Article 5 allows stricter national rules). DORA: regulation, directly applicable without national transposition. AI Act: regulation (Regulation (EU) 2024/1689). GDPR: regulation (Regulation (EU) 2016/679). | A directive can differ by Member State, so check the national law where your customers sit. Regulations apply the same text across the EU. |
| Key dates from the supplied facts | CRA: entered into force 10 December 2024 (Article 71(1)). Article 14 reporting applies from 11 September 2026 and the main regulation from 11 December 2027 (Article 71(2)). NIS2: national measures applied from 18 October 2024 (Article 41). DORA: applies from 17 January 2025 (Article 64). AI Act: consolidated text as amended by Regulation (EU) 2026/1744 dated 27 July 2026. GDPR: applies under its own text (Article 99). | The CRA dates are the ones most likely to change a launch plan. Confirm each date against the current Official Journal text before setting milestones. |
| What the vendor must do | CRA: meet Annex I essential requirements, run vulnerability handling under Annex I Part II and report under Article 14. NIS2: apply Article 21 risk management and Article 23 reporting measures, using Implementing Regulation (EU) 2024/2690 for cloud and managed services. DORA: manage ICT third-party risk, keep contract terms required by Article 30 and support testing under Chapter IV. AI Act: follow obligations that depend on system risk class. GDPR: process only under a binding written contract and support the controller's obligations. | Ask each customer which obligations it expects you to meet by contract and which it will verify itself. The contract is often the first point of enforcement for you. |
| Maximum fines where the facts give them | CRA: Article 64 sets EUR 15 million or 2.5% of total worldwide annual turnover for Annex I and Articles 13 and 14 breaches, EUR 10 million or 2% for other listed obligations, and EUR 5 million or 1% for misleading information, whichever is higher. NIS2, DORA, AI Act and GDPR fines are set by Articles 34, 50 and 83 as applicable; confirm figures in the text before quoting them. | Fines fall on the entity that breaches the obligation, so a customer's fine does not transfer to you, but its contract remedies may. |
| Certificate or proof available | CRA: conformity assessment through self-assessment under module A for most products, with a notified body for class II and critical products (Article 32). No certificate of compliance is created for the whole company. NIS2: no certificate; authorities use inspections, audits and scans (Articles 32 to 34). DORA: no certification scheme; the only authority-issued attestation is for a threat-led penetration test (Article 26(7)). AI Act: conformity assessment depends on risk class. GDPR: voluntary certification under Article 42, valid up to three years, which does not reduce responsibility. | Customers may ask for SOC 2 or ISO 27001 reports as evidence, but no EU regime above issues a company-wide certificate. Verify any certificate claim with the issuing body. |
Which obligations a SaaS vendor meets directly and which arrive through contracts
Each EU regime reaches a software or SaaS vendor by a different test, and some arrive only as clauses in customer contracts. Read each card to decide which duties apply to your product directly and which you must accept, evidence and price because a customer requires it.
Cyber Resilience Act for products
The CRA binds manufacturers of products with digital elements placed on the EU market. Article 3(2) brings a cloud backend into scope when the manufacturer designs it, or has it designed, and the product could not perform one of its functions without it. A browser-only web application used exclusively by the user is not, on that basis, a product, so check whether your app ships a client or relies on a remote backend for product functions. Confirm scope against the Commission guidance and with counsel before you classify the product.
NIS2 for cloud and managed providers
NIS2 binds essential and important entities in its sectors, and cloud computing, managed service and managed security service providers are named among them. Whether you are in scope depends on the national transposition law in each Member State and on the size and classification rules that apply to you. If you are not in scope, your EU customers still must manage security in their relationships with suppliers and service providers under Article 21(2)(d), so expect that duty to reach you as a contract clause. Ask your customers which obligations they are passing down.
DORA through financial customer contracts
DORA does not regulate most SaaS vendors directly. It binds financial entities, and it reaches ICT third-party service providers under Article 2(1)(u) mainly through the contractual terms those banks, insurers and payment firms must sign under Article 30. A vendor serving regulated financial customers should expect audit, incident, exit and data location clauses in its agreements. Confirm with each customer which of its entities are in scope and whether your service supports a critical or important function, since that changes what they will ask for.
AI Act for AI system providers
The AI Act applies under Article 2 to providers that place AI systems or general-purpose AI models on the EU market, wherever they are established. It also reaches non-EU providers and deployers whose AI output is used in the EU. If your SaaS product includes an AI feature offered to EU users, you may be a provider with direct duties, so classify the feature by its risk category first. Confirm the classification with counsel, because the duties depend on that answer and on the consolidated text as amended in 2026.
GDPR processor contracts under Article 28
A SaaS vendor that processes personal data on behalf of an EU customer is a processor, and Article 28 requires a binding written contract or other legal act that sets out how that processing is governed, including electronic form. The duty is direct for processors, but its terms are negotiated through the data processing agreement your customer signs. Check the subprocessor, breach notification and deletion terms against what you can actually deliver. GDPR certification under Article 42 is voluntary and does not replace these contract terms.
When a cloud backend brings a SaaS product into CRA scope
The first question for a SaaS vendor is whether its cloud backend is part of the product the Cyber Resilience Act covers. Under Article 3(2), remote data processing counts as part of a product when the manufacturer designed it, or had it designed under its responsibility, and the product could not perform one of its functions without it. Both limbs matter. A backend that only stores data for a web portal may not meet the second limb, while a backend that the device or desktop app cannot run without may. Document each function the client performs, which backend service it calls, and whether the function fails without that call.
Commission guidance C(2026) 5252, section 2.2, points the other way for one category: software that runs remotely and is only accessed by the user, such as web applications used exclusively through a browser, is not on that basis a product with digital elements, unless it is remote data processing supporting a product's functions. A vendor that ships both a browser application and a desktop or device client on the same cloud service therefore has to split the analysis. The browser experience may fall outside the product test, while the installed client and any backend calls it needs for its own functions may fall inside. Record that split in a scope memo, with the function-by-function reasoning behind it.
The guidance is non-binding and was published on 27 July 2026, so it shapes how regulators and notified bodies are likely to read the Article, but it does not settle a specific product's position. Confirm the reasoning against the guidance text and the regulation with your legal counsel, and revisit the memo when the product's architecture changes. This paragraph does not reach a legal conclusion for any product. Readers should also check the Commission's CRA implementation pages for later updates before relying on any scope decision.
Which regimes to plan for by vendor type
A company that ships software, devices or apps that depend on its own cloud service is most likely to meet the Cyber Resilience Act first. Under Article 3(2), remote data processing designed by or under the responsibility of the manufacturer can be part of an in-scope product when the product could not perform one of its functions without it. A web application used only through a browser is not, on that basis alone, a product with digital elements, so the answer depends on how the backend supports the product's functions.
- Scope of the backend: Map which cloud services the product cannot function without. Those services can fall inside the CRA's essential requirements in Annex I.
- Reporting clock: Article 14 reporting applies to in-scope products placed on the market before 11 December 2027, from 11 September 2026. Confirm whether your products are affected.
- Conformity route: Most products use self-assessment under module A, but class I important products and class II or critical products may need a notified body. Check the Annex III and Annex IV categories.
- NIS2 if you are a cloud provider: If your backend makes you a cloud computing service provider, NIS2 may apply to you directly, subject to national transposition.
Expect customer clauses on vulnerability handling, security update support periods, and incident notification timelines. Confirm the product category, the support period and the reporting route with counsel before drafting contract language.
A SaaS vendor whose customers are EU banks or other financial entities is most affected by DORA, even though DORA applies to the financial entity rather than the vendor. Article 2(1)(u) lists ICT third-party service providers, and their obligations arise mainly through the contracts that financial entities must sign under Article 30. Critical providers can also face direct oversight by the European Supervisory Authorities under Articles 31 to 44.
- Contract terms first: Expect Article 30 requirements to appear as contract clauses on service descriptions, data location, access, audit rights and exit arrangements.
- Incident cooperation: Banks will need your input for their ICT incident classification and reporting under Chapter III of DORA. Agree timelines and channels in the contract.
- Testing participation: Expect requests to take part in digital operational resilience testing under Chapter IV. Article 26(7) is the only authority-issued attestation the Regulation provides for, covering threat-led penetration testing.
- NIS2 pass-down: Where a customer is also an essential or important entity under NIS2, expect supply chain security clauses. DORA is a sector-specific Union act for financial entities under Article 1(2).
Ask each customer which Article 2 category it falls under and whether it has been designated for threat-led testing. Confirm with the customer's compliance team which contract annexes they require, because the ICT clauses vary by institution.
A vendor that builds or resells AI systems falls under the EU AI Act as a provider, deployer or both. Under Article 2, the Act applies to providers placing AI systems or general-purpose AI models on the EU market wherever they are established, to deployers in the EU, and to non-EU providers and deployers whose output is used in the EU. The consolidated text as amended by Regulation (EU) 2026/1744 is the version to check.
- Provider or deployer role: Determine whether you place the system on the market under your name or deploy a third-party model inside your product. The obligations differ.
- Data processing terms: If you process personal data for a customer, the GDPR processor contract rules apply. Article 28(3) requires a binding written contract, including in electronic form.
- Cyber requirements for AI products: If the AI system also contains software in scope of the CRA, the product rules apply in parallel.
- Breach notice: Article 33 of the GDPR sets the processor's duty to inform the controller, and customers will expect it written into the contract.
Expect clauses on model documentation, data use restrictions, human oversight, and cooperation with the customer's own AI compliance assessment. Confirm your role and the risk category of each system with counsel, because the high-risk obligations depend on the use case.
A managed service or managed security provider is itself in scope under NIS2 when it meets the size-cap rule, and the Commission's implementing regulation 2024/2690 sets the technical requirements for managed and managed security service providers. Annex I of NIS2 covers ICT service management, and recital 86 calls for increased diligence in selecting managed security service providers. Confirm the size thresholds and the sector classification in the regulation text, because the cap determines whether you are in scope at all.
- Direct NIS2 obligations: If in scope, you carry the Article 21 risk management and Article 23 reporting duties yourself, supervised by the national authority.
- Customer flow-down: Even outside scope, in-scope customers must manage security with their suppliers under Article 21(2)(d), so expect supply chain questionnaires.
- Evidence requests: Ask for ENISA's technical implementation guidance of June 2025 to see the examples of evidence and framework mappings the regulators are using.
- DORA if you serve banks: Financial customers will flow ICT provider duties to you through their contracts.
Expect clauses on security incident notice, subcontracting, audit access and continuity commitments. Confirm your size and sector status against the regulation text before deciding which evidence to build first.
What each regime asks the vendor to prove and who checks it
This table compares who assesses each regime, what proof the vendor produces and how supervision runs over time for the CRA, NIS2, DORA, the GDPR and the AI Act. Read it to separate regimes that issue a certificate from those that rely on self-assessment, authority inspections or contract flow-down.
| Regime | Who assesses or supervises | Proof the vendor produces | Cycle and what to confirm |
|---|---|---|---|
| Cyber Resilience Act (products) | Manufacturer self-assesses under module A for most products; a notified body is needed for class I important products where standards are not applied in full, and for class II and critical products | EU declaration of conformity and technical documentation for the product; for notified-body routes, the body's conformity assessment output | Applies from 11 December 2027 for most products; confirm which conformity module applies to your product class in the Commission guidance and Implementing Regulation 2025/2392 |
| CRA reporting (Article 14) | CSIRT designated as coordinator, with ENISA receiving notifications at the same time | Vulnerability and incident notifications through the CRA Single Reporting Platform | Applies from 11 September 2026 to in-scope manufacturers whenever their products were placed on the market; confirm your reporting workflow before that date |
| NIS2 (entities and supply chain) | National competent authority through inspections, security audits, security scans and information requests; essential entities face ex ante supervision, important entities ex post | No certificate of compliance exists; evidence is what the entity can show an inspector, and customers' flow-down clauses request it | Depends on national transposition law; confirm the authority and supervision regime in each Member State where your customers sit |
| DORA (ICT third-party providers) | Financial entities' competent authorities supervise through Article 50 powers; ESAs oversee critical ICT third-party providers directly | No certification scheme; the only authority-issued attestation is that a threat-led penetration test met requirements (Article 26(7)), and the contract with the financial entity under Article 30 | Applies to financial entities since 17 January 2025; your obligations arrive mainly through bank contracts, so confirm each client's Article 30 clause set |
| GDPR (processors) | Supervisory authorities enforce; no audit or attestation is required by the Regulation | Processor contract under Article 28(3) in writing or electronic form; Article 42 certification is voluntary | Article 42 certification is voluntary, issued by accredited bodies or supervisory authorities for at most three years, and does not reduce responsibility for compliance |
| EU AI Act (AI system providers) | Market surveillance and conformity routes set in the Regulation; the route depends on the system's risk class and whether a notified body is involved | Conformity documentation and registration as the consolidated text requires for the provider's risk class | Applies to providers placing AI systems on the EU market wherever established; confirm the conformity route and dates in the consolidated text of Regulation (EU) 2024/1689 as amended in 2026 |
| Customer security questionnaires and audits | The customer's own third-party risk team, often using contract rights granted under the regimes above | Evidence packs, pen test summaries and control descriptions requested per contract | Set by each contract; ask each client which regime its supervisor expects it to pass down to you |
The order to take these regulations on as a SaaS vendor
This sequence sorts out which EU rules reach your products and services, then builds the evidence that answers customer and regulator questions in the order those obligations start to bite. Shared records such as SBOMs, vulnerability handling, incident runbooks and access controls serve several steps at once.
Map scope by product, service and customer
List every product, hosted service and backend your company offers, then mark which ones are placed on the EU market, which are only accessed through a browser, and which include remote data processing that a product needs to run. Commission guidance C(2026) 5252 treats cloud backends as in scope where the manufacturer designed them and the product could not perform a function without them, so check each backend against that test. Also record which of your customers are NIS2 or DORA entities, because their supplier questions will reach you regardless of your own status. The output is a scope register signed off by product, legal and security owners, with a note on each borderline case.
Put GDPR processor terms in writing
Where you process personal data for customers as a processor, confirm that a contract or other binding legal act governs that processing, in writing or in electronic form, as Article 28(3) and (9) of the GDPR require. Legal counsel usually drafts or updates the data processing terms, and your security team supplies the technical and organizational measures described in the annex. Check that subprocessor, breach notification and deletion terms match what your operations team actually does. The output is a signed processing agreement template and a register of executed agreements by customer.
Check CRA reporting duties for products already on the market
Reporting obligations under Article 14 of the Cyber Resilience Act applied from 11 September 2026, and they reach in-scope products whenever they were placed on the market. Confirm which products fall under the regulation and assign a contact who can receive actively exploited vulnerability and severe incident reports, since notifications go to the CSIRT designated as coordinator and reach ENISA at the same time. Products placed on the market before 11 December 2027 come under the full regulation only if they are substantially modified after that date, so plan the remaining Annex I work against that date. The output is a documented reporting procedure and a list of products with their current status.
Build the shared evidence base
Assemble the records that several obligations depend on: a software bill of materials for each product, a documented vulnerability handling process that covers Annex I Part II, an incident response runbook with a named reporting path, and an access control and authentication baseline for your hosted services. Engineering leads own the technical records, and the security lead checks that each one reflects current releases. These records answer CRA, NIS2 and DORA questions at once, so keep one maintained source rather than separate documents per regulation. The output is a versioned evidence set that a customer or auditor can read without a briefing.
Build a customer security pack for NIS2 and DORA questions
Prepare a pack that answers the supply chain questions your in-scope customers must address under NIS2 Article 21(2)(d) and the contract terms financial entities must sign under DORA Article 30. Include your security policies, the evidence set from the previous step, subprocessor and hosting locations, incident notification commitments, and your audit or testing summary. Be precise about what you can share, because DORA sets no certification scheme and NIS2 creates no certificate of compliance, so customers cannot accept a certificate as proof. The output is a maintained pack with a version date and a named owner who answers follow-up questions.
Decide whether a notified body or certification route applies
Under Article 32 of the Cyber Resilience Act, most products follow self-assessment under module A, while a notified body is needed for class I important products where harmonized standards are not applied in full, and for class II and critical products. Check the Annex III and Annex IV categories against each product, and review the Implementing Regulation (EU) 2025/2392 descriptions. Ask any notified body for its scope, timeline and fees in writing before you commit, because those depend on the product and cannot be estimated from this page. The output is a written conformity route decision for each product, with its supporting rationale.
Track the NIS2 amendment and Digital Omnibus proposals
Record the Commission proposal COM(2026) 13 that would amend NIS2 with a new small mid-cap category, and the Digital Omnibus proposal COM(2025) 837 followed through procedure 2025/0360(COD). Both are proposals that still need approval from the European Parliament and the Council, so do not treat their content as law. Assign an owner to check the legislative status each quarter and to update the scope register and customer pack if either text changes. The output is a dated tracking note that states which provisions are in force and which are proposed.
What EU compliance work costs a SaaS vendor and what it needs from the team
What drives the cost of Cyber Resilience Act readiness for a software vendor?
The main drivers are how many products you ship, the class each product falls into under Annex III or Annex IV, how large and complex the backend is, and how much of the work you already have documented. Products in class I, class II or the critical category carry more conformity work than products that follow self-assessment under module A, and a notified body is needed for class II and critical products. Your cost is mostly internal engineering time plus any outside help for the risk assessment, the Annex I evidence and the vulnerability handling process. Ask any provider to price each product separately and to state which of these items are included in the fixed scope.
Can a SaaS vendor handle GDPR processor obligations without outside help?
Often yes, if a team owns privacy, legal review and engineering together, because the core work is contractual and procedural. Article 28 requires a binding written contract or other legal act with each controller, and your team must also maintain the processing records, sub-processor controls and breach notification steps that Article 33 and Article 28 expect. The GDPR requires no audit or certificate, and Article 42 certification is voluntary, so the work is about evidence you can show a customer or supervisory authority. Outside help is most useful when you have many customer contracts to standardize or when the data flows are complex. Confirm with counsel which obligations apply to your specific role as processor.
What does a notified body route change for a CRA project?
A notified body route adds a third-party conformity assessment step, which changes both the schedule and the budget. Under Article 32 and the Commission's FAQ, a notified body is needed for class I important products where harmonized standards, common specifications or certification schemes are not applied in full, and for class II and critical products. Most other products follow self-assessment under module A. Before you commit, check which harmonized standards apply to your product category, because the standardization request M/606 still has deliverables due through 2026 and 2027. Ask the notified body and your advisor to confirm the assessment scope in writing before you plan the release.
How long does EU compliance work take for a SaaS vendor?
Duration depends on scope, so treat any single number with caution. The dates that matter are fixed by law: the CRA Article 14 reporting obligations apply from 11 September 2026, Chapter IV on notified bodies applies from 11 June 2026, and the rest of the regulation applies from 11 December 2027. NIS2 member state rules applied from 18 October 2024, and DORA has applied since 17 January 2025 for financial entities. Products on the market before 11 December 2027 fall under the CRA only if substantially modified, but Article 14 reporting applies to all in-scope products. Build your plan backward from these dates and ask each provider to state its own duration assumptions in the written scope.
What should a fixed-scope quote for EU compliance work include?
A fixed-scope quote should name each product or service in scope, each regulation and article set it addresses, and each deliverable with its acceptance criteria. Ask whether the quote covers the CRA risk assessment, Annex I evidence, vulnerability handling process, GDPR processor contract review, sub-processor register and any NIS2 or DORA supplier clauses you must pass down. Also ask what is excluded, such as notified body fees, legal opinions, penetration testing or post-launch support, and how change requests are priced. DeployOpen plans and delivers fixed-scope engagements with scope, deliverables and timelines agreed in writing before work starts, and quotes follow from that written scope. Compare any provider on the same written basis.
What must the vendor's own team supply before outside help starts?
Your team must supply the facts that only you hold. That includes a product inventory with versions and intended use, an architecture diagram that shows the cloud backend and any remote data processing, a record of past security incidents and how they were handled, and the customer and supplier contracts that set your obligations. You will also need your current vulnerability handling process, your sub-processor list and your support period for each product. Gaps in these inputs usually become the largest source of extra cost and delay, so ask any provider to send an intake checklist before quoting.
Do customers require a certificate for EU compliance?
Usually not, because none of the main EU regulations creates a certificate of compliance for the vendor. NIS2 creates no certificate and relies on national authority oversee, the GDPR certificate under Article 42 is voluntary, and DORA's only authority-issued attestation covers a threat-led penetration test. The CRA uses conformity assessment and a declaration of conformity for products, so a notified body certificate may apply in some cases. Customers often ask for independent reports or certifications instead, which is a commercial decision. Confirm with each customer which evidence their contract requires, and remember that a certification body or auditor, not DeployOpen, issues any audit report or certificate.
How DeployOpen scopes and prepares EU vendor readiness work
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and prepares systems, controls and evidence for compliance assessments. For software and SaaS vendors working through the EU regulations compared on this page, that means turning obligations into a written scope before any work starts.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope states which products, cloud backends and supplier relationships fall under each regulation you select.
- Scope notes separate what the regulation requires from what your customers or contracts ask for, so you can confirm each with counsel.
How we build
- We implement and harden the open-source platforms and controls in your own cloud accounts, data centers or air-gapped networks.
- Security testing of applications, APIs and infrastructure can be scoped alongside the build to check the controls work as documented.
- Vulnerability handling, logging and supplier-contract evidence are mapped to the requirements you agreed to address in the scope.
How we hand over
- Deliverables include configuration, control documentation and evidence packs that your auditors, notified bodies or regulators can review.
- Documentation explains what the evidence shows and what it does not show, since DeployOpen does not issue audit reports or certifications.
- Handover covers runbooks and backup procedures so your own team can operate the systems after the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing like the original engagement.
- Retainers can cover updates to evidence when a regulation's technical standards, guidance or reporting process changes.
- Confirm with your legal and conformity assessment advisers which obligations apply to your products before you rely on any scope.
