Does a third-party cloud service inside a CRA product become your responsibility?
Software you deploy on a third-party IaaS or PaaS can be your remote data processing (RDPS), while a third-party SaaS application offered to all customers is treated like an integrated component that needs due diligence. That is the position of the Commission's non-binding guidance annexed to Communication C(2026) 5252, which a customer or contract reviewer will likely cite when asking how your cloud dependencies are covered. The answer depends on three questions: who designs the service, whether your product relies on it for remote processing, and what you can verify about it. If you build and operate the back end on rented infrastructure, the design is yours and the service sits inside your product's obligations. If you consume a SaaS product that the provider designs for every customer, you cannot change its architecture, so your duty shifts toward selecting it carefully and checking its security evidence.
The guidance also says the risk assessment must cover failures outside the product, such as a back-end or external service becoming unavailable. You address that with product-level measures, for example cryptographic authentication of remote commands, rather than by regulating how the provider runs its data centers. Start by listing every remote service the product uses and marking which ones are designed under your responsibility. Then record in the technical documentation that the product has RDPS or relies on third-party remote solutions, and describe them. Where a provider's evidence is available, the guidance accepts reuse of artefacts such as a certificate under a Cybersecurity Act scheme, evidence of ISO/IEC 27001:2022 conformity, or evidence of meeting Implementing Regulation (EU) 2024/2690 or DORA. Confirm with each provider which of these it actually holds and for which service scope, because a certificate covering a different region or product line does not help you.
Your organization owns its controls and the conformity decisions that follow from them. An implementation partner can help map the service inventory, collect provider evidence and draft the documentation, but only an independent auditor or certification body issues reports or certificates. Build the contract to match these duties. The guidance suggests embedding security guarantees in service level agreements with remote service providers, so ask for notice of material security incidents, access to current assurance reports, audit or evidence rights, and a commitment to keep the service available for the period you need to support the product. Note that NIS2 Article 21(2)(d) pushes similar security expectations down to suppliers through contracts, so a provider that refuses these terms may also be a poor fit for your customers in regulated sectors.
How the guidance sorts cloud services by who runs them
When your own software runs on a provider's infrastructure or platform, the guidance can classify that software as remote data processing solution (RDPS) under your responsibility. The provider runs the hardware and platform, but the code, configuration and data flows that your product relies on were designed by you, so the product must meet the essential requirements for that remote part.
- Classification: Software you deploy on third-party IaaS or PaaS can be RDPS, so it sits within your design responsibility.
- What you remain responsible for: Your application logic, access controls, configuration, secure defaults and the data flows you define on the platform.
- What the product must guard against: Misconfiguration of the platform services you choose, unauthenticated remote commands and loss of the remote service.
- Evidence to keep: Your technical documentation should state that the product has RDPS and describe the platform it runs on.
- Provider assurance: Collect provider evidence, such as a certificate or report covering the platform, to reuse for the infrastructure layer.
Confirm with your architects which of your cloud-hosted components are RDPS before you draw the boundary in your risk assessment.
A third-party SaaS application offered to all of its customers is not designed under your responsibility. The guidance says you should treat it like an integrated component and apply due diligence, rather than treating its internal design as your own design work.
- Classification: A third-party SaaS application offered to all customers is treated like an integrated component.
- What you remain responsible for: Choosing the provider, assessing it before integration, and documenting the dependency in your technical documentation.
- What the product must guard against: Changes or outages in the service that affect how your product behaves, and data sent to the service beyond what you intended.
- Evidence to keep: Due diligence records, the provider's assurance evidence and the contract terms that govern security and change notification.
- Contract terms: The guidance suggests embedding security guarantees in service level agreements with providers.
Ask the provider which certifications and assurance reports cover the service you actually use, not only the company as a whole.
Remote data processing does not need to run on a public cloud. The guidance states that processing on your own servers or in a private cloud can qualify as RDPS just as a public cloud solution can, so the cloud provider is not the deciding factor. What matters is that the processing supports the product and is under your design control.
- Classification: Remote processing on your own servers or private cloud can qualify as RDPS.
- What you remain responsible for: The full design, hardening and operation of those systems to the level the product requires.
- What the product must guard against: Unauthorized remote access to the back end and manipulation of commands sent from it.
- Evidence to keep: The same technical documentation as any RDPS, which can be reused across products that share the same RDPS.
- Scope note: Owning the infrastructure does not remove the obligation to describe it and assess its risks.
Confirm internally whether your own hosting counts as RDPS under the guidance before assuming it falls outside the regulation.
The risk assessment must cover risks that come from outside the product, including back-end systems or external services becoming unavailable. The guidance does not tell you how that infrastructure must be run. Instead, it expects product-level measures that keep the product safe and functional when those services fail or are compromised.
- Classification: External back-end and remote services are assessed as risks from outside the product.
- What you remain responsible for: Identifying these dependencies in your risk assessment and deciding how the product reacts to their loss.
- What the product must guard against: Unavailability of the service and forged or replayed remote commands.
- Product-level measures: Cryptographic authentication of remote commands is one example the guidance gives.
- Verification: Check the provider's own security measures, and keep records of that check.
Review each external dependency and write down the product behavior if that dependency stops responding.
Which assurance evidence a remote service provider can supply
The guidance lets a manufacturer reuse assurance artefacts that a remote service provider already holds, instead of auditing that provider from scratch. Each of the four artefacts below proves something about the provider's controls, and none of them proves that the product is compliant on its own.
NIS2 or DORA compliance evidence
Evidence that a provider meets Implementing Regulation (EU) 2024/2690 for cloud and managed service providers, or the DORA requirements for ICT third-party services, shows that its risk management is assessed against a defined EU standard. It does not show that the service runs the controls your product depends on, such as authentication of commands or availability of the back end. Confirm that the evidence covers the specific region, service tier and hosting location your product uses, and ask which version of the requirements it was assessed against.
Cybersecurity Act certificate
A certificate issued under a scheme adopted under the EU Cybersecurity Act is an independent attestation that a defined set of security requirements was tested by an accredited body. It proves the scope named on the certificate, at the assurance level stated. Check that the certificate names the exact service, product version and assurance level you rely on, that it is still valid, and that its scope excludes nothing your product calls.
ISO/IEC 27017 or 27001 conformity
Evidence of conformity with ISO/IEC 27017:2015, the cloud-specific control guidance, or ISO/IEC 27001:2022, the management system standard, shows that the provider runs a documented information security management system that an accredited certification body has audited. Certificates are issued to a defined scope, so the question is whether that scope includes the cloud service and the data centers your product uses. Ask for the statement of applicability and the most recent audit report summary.
Security guarantees in the SLA
The guidance suggests writing security guarantees into service level agreements with remote service providers, alongside product-level controls and checks on the provider's own measures. A contract clause makes the provider's obligations enforceable, covering incident notification, vulnerability fixes, availability targets and audit rights. It does not transfer your CRA responsibility to the provider. Negotiate the clauses before go-live, name the security metrics measured, and confirm how long the provider keeps evidence after termination.
Why NIS2 supplier duties reach your contracts with cloud providers
The guidance recalls that cloud computing services fall under the NIS2 Directive, and the risk-management requirements for cloud providers are set out in Implementing Regulation (EU) 2024/2690. That matters for a CRA manufacturer because many of your customers are essential or important entities under NIS2, and they will ask how the products they buy fit into their own supply chain controls. The link runs through Article 21(2)(d) of the *NIS2 Directive*, which requires essential and important entities to address security in their relationships with direct suppliers and service providers. A cloud provider you rely on may sit outside NIS2 scope itself, yet the obligation still reaches it through the contract the customer signs with you, and you then pass it on to your own providers.
In practice, an NIS2 customer may write expectations into its purchase terms, such as asking how your remote services are hosted, which providers hold its data, how incidents at those providers are notified to you, and what assurance evidence you hold. Those expectations are the same ones the CRA guidance asks you to collect for third-party remote services, so one set of contract clauses can serve both purposes. Check what your provider contracts already allow: audit or evidence access, incident notification timelines, subprocessor disclosure, and the right to terminate or migrate if a provider falls short.
Your own NIS2 status is not something this page can settle. Whether you or your customers are essential or important entities depends on sector, size and national transposition, so confirm your status and the scope of any flow-down obligations with counsel or your national competent authority before you draft clauses.
Which route fits each cloud dependency
This table compares the four routes a manufacturer can take for a cloud or external service its product depends on, showing how the Commission guidance classifies each one, what documentation it triggers and what the manufacturer must verify. Read each row against the service's actual role in the product, because the same vendor can sit on different routes depending on whether it hosts software the manufacturer deploys or a service offered to every customer.
| Dependency | How the guidance classifies it | Documentation it triggers | What the manufacturer must verify |
|---|---|---|---|
| Manufacturer software deployed on third-party IaaS or PaaS | Can be remote data processing (RDPS) because the manufacturer designs and deploys the software | Technical documentation states the product has RDPS and describes the third-party remote solution | Product-level controls such as cryptographic authentication of remote commands, plus the provider's own security measures |
| Manufacturer's own servers or private cloud | Can qualify as RDPS in the same way a public cloud solution can; hosting location does not decide the question | Technical documentation describes the RDPS and its operation under the manufacturer's control | Security of the manufacturer's own hosting, including access control, patching and monitoring of the back end |
| Third-party SaaS application offered to all customers | Not designed under the manufacturer's responsibility; treat as an integrated component subject to due diligence | Component entry in the technical documentation and SBOM where the service is part of the product | Provider assurance evidence such as ISO/IEC 27001:2022 or ISO/IEC 27017:2015 conformity, plus contractual security terms |
| External back-end or remote service the product relies on | Risk to assess from outside the product, such as the service becoming unavailable | Risk assessment entry and a note in the technical documentation describing the dependency | How the product keeps working or fails safely if the service is down, and whether it can be verified without the service |
| Shared RDPS used by several products | RDPS under the manufacturer's responsibility, operated once for multiple products | Documentation for the shared RDPS can be reused across each product's conformity assessment | That each product's documentation references the same, current description of the shared service |
| Provider evidence under Implementing Regulation (EU) 2024/2690 or DORA | Reusable assurance artefact for a third-party remote service | Cite the evidence in the technical documentation and record the scope it covers | That the evidence covers the service the product actually uses, and its validity period |
| Security guarantees in the service level agreement | Suggested by the guidance to back up product-level controls | Contract terms recorded in supplier and risk files | Incident notice, vulnerability information and security obligations written into the contract with the provider |
How to record a third-party remote service in the CRA technical file
This sequence takes each cloud or SaaS service your product relies on from discovery to a documented entry in the technical file, with evidence and contract terms that support the classification. It also sets the trigger for keeping the record current.
Inventory every remote service the product uses
Engineering and product owners list each cloud, hosted or SaaS service that the product calls, stores data in, or cannot function without, including back-end APIs, update servers, licensing services, telemetry pipelines and identity providers. Include services the product uses in production builds and those used for updates. The output is a single register with one row per service, the product feature it supports, and the named internal owner. The step is done when someone outside the build team can read the register and identify every remote dependency without asking questions.
Classify each service as RDPS or third-party component
For each register row, decide whether the software runs on third-party infrastructure that you deploy and control, which points to remote data processing (RDPS), or whether it is a third-party SaaS application offered to all customers that you did not design, which the guidance treats like an integrated component subject to due diligence. Record the reasoning next to each decision, because an assessor will ask why a service sits on one side of the line. The output is a classification column in the register with a short rationale per row. Confirm borderline cases against the Commission guidance before you finalize them.
Collect and review assurance evidence
For each service, request the assurance artefacts the provider can supply. Depending on the service, these can include evidence of meeting Implementing Regulation (EU) 2024/2690 or DORA, a certificate under a Cybersecurity Act scheme, or evidence of conformity with ISO/IEC 27017:2015 or ISO/IEC 27001:2022. Check scope, validity dates and whether the audited service matches the one you use. Note gaps and the compensating product-level controls you will rely on. The output is an evidence file per service with a dated review note and a list of open questions for the provider. Some providers will not share full reports, so confirm what they will provide under confidentiality.
Confirm security terms in the service agreement
Legal and procurement review the contract or service level agreement and check that it contains security guarantees matching the service's role in the product. Typical items to verify include security incident notification, availability commitments, vulnerability handling responsibilities, the right to receive evidence, and what happens when the provider changes its infrastructure. Where the agreement is silent, record the gap and decide whether to negotiate, accept the risk with a documented rationale, or replace the service. The output is a signed-off contract summary per service that lists the clauses relied on and any open gaps.
Document the remote dependencies in the technical file
The technical documentation states that the product has RDPS, relies on third-party remote solutions, or both, and describes each one. For every entry, record the service name, provider, function in the product, classification, the evidence reviewed, the contract clauses relied on, and the product-level measures that protect against the service becoming unavailable or compromised, such as cryptographic authentication of remote commands. If a remote processing service is shared by several products, document it once and reference it from each product file. The output is a dedicated section of the technical file that an assessor can follow without interviewing the team.
Re-review when the provider or product changes
Set triggers that reopen the record: a provider change, a material change to the service's hosting or scope, a new assurance report, a new contract term, a new product release that adds or removes a remote call, or a substantial modification of the product. Each trigger sends the affected register row back through classification, evidence and contract review. The output is an updated register with change history and a re-review log that links each change to the technical file version it affected. Assign a named owner for monitoring provider notices so that changes are not missed between releases.
What usually goes wrong with cloud dependencies in a CRA file
Most gaps in a CRA file around cloud dependencies come from one assumption: that a service the manufacturer did not build sits outside the product's obligations. The cards below cover the recurring mistakes, and each one names the check that closes it before an assessor or market surveillance authority asks.
Treating SaaS as out of scope
Teams often reason that because they did not build a third-party SaaS application, it does not belong in the CRA file. The guidance treats a SaaS application offered to all customers as something not designed under the manufacturer's responsibility, so it is handled like an integrated component with due diligence. Inventory every external service the product calls at runtime, then record for each one why it is in scope and what due diligence you performed.
Certificates that do not cover the service
A provider's certificate often covers a different scope than the service the product actually uses, such as a regional data center, a single product line or a subset of features. Reusable artefacts include evidence of meeting Implementing Regulation (EU) 2024/2690 or DORA, a Cybersecurity Act scheme certificate, or conformity with ISO/IEC 27017:2015 or ISO/IEC 27001:2022. Ask the provider to confirm in writing which services, locations and periods the evidence covers, and file that scope statement with the technical documentation.
Missing the back-end availability risk
A product can keep working in the field while its remote back end is down, and the CRA risk assessment must cover risks from outside the product, including external services becoming unavailable. The guidance does not regulate how the provider runs its infrastructure, but it expects product-level mitigations such as cryptographic authentication of remote commands. Document what the product does when the external service fails, and test that fallback behavior before release.
No contract clause for evidence on request
Many cloud contracts give the customer little more than a general security statement, so the manufacturer cannot obtain current evidence when a vulnerability or assessment arises. The guidance suggests embedding security guarantees in service level agreements with remote service providers, alongside verification of their own measures. Add clauses that require evidence on request, vulnerability notification within a defined period, and cooperation during incidents, and confirm the exact timelines with the provider.
Documenting each product separately
When several products rely on the same remote processing service, teams often write a separate description for each one, which then drifts out of step. The guidance states that documentation for a remote data processing service shared by several products can be reused across their conformity assessments. Maintain one controlled description of the shared service, reference it from each product's technical documentation, and update it whenever the service changes.
Who owns each part of cloud due diligence
The manufacturer owns the product, its risk assessment and its conformity under the Cyber Resilience Act. Responsibility for deciding whether a cloud service is remote data processing (RDPS) or a third-party SaaS component sits with the manufacturer, and that decision has to be recorded and defended. Three internal groups usually share the work, each with a distinct part of the due diligence.
- Product security: Owns the risk assessment, decides which remote services the product depends on, and sets the product-level controls that protect against a back-end or external service becoming unavailable or being abused.
- Legal and procurement: Negotiates the contract terms with each provider, including security commitments in service level agreements, audit or evidence rights, incident notice and data location, and keeps the register of providers.
- Engineering: Documents the architecture, implements controls such as cryptographic authentication of remote commands, and maintains the technical documentation as the service design changes.
Before signing off, confirm that each provider has a named owner inside the manufacturer and that the record of each remote service is kept with the technical documentation.
An implementation partner such as DeployOpen can prepare the systems and evidence the manufacturer uses. Its work is operational: it documents how the architecture uses remote services, collects the assurance material providers supply, configures product-level controls, and assembles the technical documentation for the manufacturer to review. The partner does not decide the classification, accept the risk on the manufacturer's behalf, or sign the declaration of conformity.
- Architecture documentation: Maps data flows, remote services and failure paths so the manufacturer can state which services are RDPS and which are third-party components.
- Provider evidence: Gathers the assurance artefacts providers offer, such as certificates or reports, and records their scope and dates.
- Product-level controls: Configures measures such as cryptographic authentication of remote commands and the handling of unavailable back-end services.
- Technical documentation: Assembles the material the manufacturer must keep, including the description of any RDPS or remote solution, for review and sign-off.
Ask the partner in writing which items it prepares and which the manufacturer approves, and confirm that its fixed-scope deliverables are listed in the agreed scope.
Most products follow self-assessment under module A, so the manufacturer carries the conformity assessment itself. A notified body is required 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 (Article 32). Where a notified body is involved, it performs the independent assessment and issues the outcome, not the implementation partner.
- Self-assessment: Under module A the manufacturer prepares the technical documentation and the EU declaration itself.
- Notified body route: Class I products without full application of standards, and class II and critical products, require a notified body listed in the Commission's NANDO system.
- Independence boundary: Assessors and notified bodies issue reports and certificates. Implementation partners prepare evidence but do not issue them.
- Market surveillance: National authorities can check the products and the documentation at any time after placing on the market.
- Engagement terms: Agree with the assessor in advance which documents, tests and interviews it will review.
Confirm the product's class under Annex III or Annex IV before choosing a route, since that choice determines whether an external body is needed.
Questions buyers ask about cloud and SaaS services under the CRA
Is a SaaS tool my product calls my responsibility under the CRA?
Usually it is not designed under your responsibility, so you treat it as an integrated component and exercise due diligence rather than owning its security. The Commission's guidance draws the line here: a third-party SaaS application offered to all customers sits outside your design control. The exception is software you deploy yourself on a provider's infrastructure, which can be remote data processing (RDPS) that you must cover in your risk assessment. Your job is to decide how your product depends on that tool, document it in the technical documentation, and check the provider's security posture before and during use. Ask your legal and product teams to confirm which of your integrations are SaaS and which are your own deployments on IaaS or PaaS.
Does my product have to run on a public cloud to meet the CRA?
No. The guidance states that remote data processing does not need to run on a third-party cloud, and processing on your own servers or a private cloud can qualify just as a public cloud solution can. What the regulation looks at is the function the remote service performs for the product, not the hosting model. Choosing a self-hosted or private deployment does not remove the need for a risk assessment, product-level controls such as cryptographic authentication of remote commands, or evidence that the back end stays available and secure. If you run the service yourself, the same obligations apply to you directly, with no provider evidence to lean on, so plan the internal controls accordingly.
What assurance evidence can a cloud provider give me for the CRA?
Providers can supply artefacts the guidance lists for reuse, including evidence of meeting Implementing Regulation (EU) 2024/2690 or DORA, a certificate under a Cybersecurity Act scheme, or evidence of conformity with ISO/IEC 27017:2015 or ISO/IEC 27001:2022. This evidence shows the provider runs its own security program in the scope the certificate or report covers. It does not prove that your product is secure, that your configuration of the provider is correct, or that the service meets the availability your product needs. Check the scope statement, the date, the systems and locations included, and any exclusions. Ask which controls the provider owns and which you must configure, and record that split in your technical documentation.
What should the contract and SLA with a cloud or SaaS provider say?
The guidance suggests embedding security guarantees in service level agreements with third-party remote service providers, alongside product-level controls and checks on the provider's own measures. Practical clauses to request include:
- Security obligations that map to the risks in your product risk assessment, such as access control and encryption
- Incident notification timelines that let you meet your own reporting duties under Article 14
- Availability commitments and the remedies if the service fails, since outside services becoming unavailable is a named risk
- Audit or assurance rights, and delivery of current reports or certificates on a set cadence
- Sub-processor disclosure, data location, and exit and data return terms
Have counsel confirm the wording. Numeric SLA targets should come from your own availability analysis, not from a generic template.
How much effort does CRA due diligence on cloud services take?
The effort depends on how many external services your product depends on, how critical each one is to remote functions, and how much assurance evidence each provider already holds. A single SaaS tool used for non-essential features needs a short review. A back end that a safety or security function relies on needs a full risk assessment, documented controls on both sides, and a process for re-checking evidence each year. We cannot give you a reliable duration or cost without the list of services and their roles, so ask any provider or partner for a quote built from that written scope. Expect the work to recur, because evidence expires and providers change their services.
Can our team handle CRA cloud due diligence internally?
Often yes for the inventory, contract review and evidence collection, provided someone owns the process and the product risk assessment. Internal teams usually struggle with the technical part: configuring the provider securely, testing whether a back-end failure leaves the product in a safe state, and writing technical documentation that a market surveillance authority can follow. Outside help is most useful for scoping, for building the controls and tests, and for independent verification of your own deployments. DeployOpen plans, implements and hardens self-hosted open-source platforms in your own infrastructure and prepares the evidence, but it does not issue reports or conformity outcomes. Only an independent assessor or notified body does that.
Is the Commission's CRA guidance on cloud services binding?
No. The guidance is non-binding and explains how the Commission reads the regulation, so it helps you interpret the text but does not replace it. Binding obligations come from Regulation (EU) 2024/2847 itself, and market surveillance authorities and courts will apply the regulation. Several references in the guidance point to other instruments, such as NIS2 and Implementing Regulation (EU) 2024/2690, which carry their own legal status. Follow the guidance as a practical reading, track how national authorities apply it, and get legal advice for your specific product. Conformity outcomes are decided by an independent assessor or notified body, never by the guidance or by your implementation partner.
How DeployOpen works on this
DeployOpen plans, implements and documents the self-hosted open-source platforms inside your own infrastructure, including the cloud accounts and services your product relies on. We prepare the systems, configuration and evidence that show how each remote dependency is set up and governed, while your organization keeps ownership of its controls and the independent assessor issues any report.
How we scope
- Written scope lists each cloud or SaaS dependency, where it runs and what data it touches.
- We map which dependencies process remote data for your product and which act as integrated components.
- Scope names the assurance documents we will collect and the owner for each provider relationship.
How we build
- We configure self-hosted platforms in your cloud accounts or data centers, with product-side controls for remote commands and service outages.
- We test authentication, failure handling and access paths for each dependency inside the agreed scope.
- We keep configuration and architecture records current so each dependency can be described in technical documentation.
How we hand over
- Deliverables include a dependency register, architecture description and the configuration records agreed in scope.
- Evidence packs collect provider certificates, reports and SLA clauses, with dates and gaps marked for your review.
- Handover covers how to update the register when a provider changes, so records stay accurate after the engagement ends.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask us to confirm which parts of provider assurance your own legal and procurement teams must obtain directly.
