Your phone app talks to a server you built. Under the Cyber Resilience Act that server is not a separate thing you can wave away. It is part of the product. The regulation's own headline example of remote data processing is a mobile app reaching an API or a database that runs on a service you developed. So the backend behind your app is not a neighbour to the product. It is inside it.
This page gives you the test, then sorts every backend a typical app talks to into three categories: remote data processing solution, component, and out of scope. We summarised the test in the March 2026 Commission guidance breakdown. This is the worked-through version for anyone shipping a phone app, an API, or a cloud backend.
Summary
- Remote data processing is part of the product. The CRA treats a connected product as the device or app plus the backend you built that it needs to work. People shorten remote data processing solution to RDPS, and this page uses that.
- One test, three things to be true. A backend is remote data processing when it runs at a distance, your product needs it to perform a function, and you built it or had it built for you. Miss any one of the three and it is not.
- The textbook example is an app and its API. The regulation's own headline case is a mobile app that reaches an API or a database run by a service you built.
- Three categories, nothing else. Every backend your app touches is either a remote data processing solution, a component, or out of scope.
- Off-the-shelf SaaS is not RDPS, but it is still your problem. A service you only license is a component. You still assess the integration risk and run supplier due diligence on it.
- The 5G network is out entirely. A cellular network is a connectivity enabler, like a router or a Wi-Fi signal. You owe the operator no due diligence at all.
- Your CI/CD and CRM are out. The CRA does not regulate your company network as a whole. Internal pipelines, payroll and red-team infrastructure stay outside.
Remote data processing in four numbers: the things you check, the two questions that decide it, the categories a dependency can land in, and the example the regulation leads with.
What remote data processing actually means
The regulation boils it down to one idea, and three things have to be true at the same time. The data has to be handled somewhere other than the user's own device. Your product has to need that handling to do one of its jobs. And you have to have built the service, or had it built under your responsibility. Get all three and you have a remote data processing solution. Miss one and you do not.
Read the three apart, because each one trips up a different team.
- Handled at a distance. The processing happens outside the user's device or environment. It can sit at the edge, on a wired link or a wireless one. A mobile app reaching a cloud function is part of the processing that happens on the cloud.
- Needed for a function. Without the service, the product cannot do one of its jobs. The word the regulation uses is functions, not core features, and that matters. The next section unpacks how broad it is.
- Built by or for you. You designed and developed the service, or a provider built it under your responsibility. Renting space to run it does not change the answer.
Two points catch people out before they even start sorting:
- It is your software, not the hardware it runs on. The remote data processing solution is the code you built and run at a distance. The provider's hypervisor or runtime underneath is a component, and the physical hardware it all sits on is the product environment. Neither is your remote data processing solution, and you assess the risk from both.
- It does not have to be public cloud. A remote data processing solution can run on your own on-premise servers or a private cloud on your own premises. The test is design, development and necessity, not where the box physically sits.
The three questions
Run every backend your app depends on through three questions in order. Each path lands in one of the three categories.
The first question filters out anything that never leaves the device. The next two are the decisive pair, and both have to be yes. Three things are worth pinning down before you start:
- Functions is broader than core features. It covers anything that supports how the product performs, not just the headline feature. Sending commands to a device, synchronising files, onboarding a user, configuration and personalisation, receiving updates including security patches, and signing users in all count as functions. If a backend is needed for any one of them, the second question is yes.
- A manual fallback does not exempt you. A light bulb you can switch on through an app or by a physical switch is still a remote data processing solution for the remote path. The manual option does not take the function out of scope.
- Built by or for you is not who runs it. You can hand operation to a third party and stay responsible. Under your responsibility means tailor-made, built on your behalf to your specification, and owned rather than licensed. Licensing an existing product, or a lightly modified version of one, is not built by or for you.
The textbook case: your app, your API, your database
Start with the case the regulation itself uses as its example. A mobile app needs an API or a database, and that API or database runs on a service you built. In that case the service is a remote data processing solution, full stop. This is the picture the rest of the page builds on.
Walk a notes app through the three questions. The app syncs files through your REST API and your database. Handled at a distance, yes. Needed for a function, yes, because file synchronisation is a function. Built by or for you, yes, because you designed the API and the database schema. Three yeses. Your API and your database are a remote data processing solution. They sit inside the product's conformity scope.
The cloud platform underneath is a different question. If you rent infrastructure and deploy your own code on it, the platform you rent is not the remote data processing solution. Your code is. The IaaS underneath is a component. You document the reliance, assess the integration risk, and can ask the provider for security evidence.
The three categories at a glance
Every dependency lands in exactly one category. Both decisive questions yes is a remote data processing solution. Needed for a function but not your responsibility is a component. Not needed for a function is out of scope, and you check the risk it still introduces.
| Category | When it applies | Meaning | What you must do |
|---|---|---|---|
| Remote data processing solution | at a distance, needed for a function, and built by or for you | Part of the product itself | Meet the Annex I essential requirements. Fold it into the product risk assessment. Cover it in the EU Declaration of Conformity and the technical documentation. Handle and report vulnerabilities across the support period |
| Component | at a distance and needed for a function, but not built by or for you | A third-party piece your product leans on | Assess the integration risk. Mitigate at product level, through authentication, integrity checks, isolation and response validation. Run supplier due diligence and put security guarantees in the SLA. Reuse the evidence the provider already holds, such as a CE marking, an ISO/IEC 27001 or 27017 certificate, an EU cybersecurity certificate, evidence of the provider's NIS2 obligations, or its DORA obligations where they apply |
| Out of scope | not needed for a function, or pure connectivity | Neither a remote data processing solution nor a component | No conformity or component duty. You still assess any risk the communication introduces. Pure connectivity, like the cellular network, Wi-Fi or a router, is the one case where you owe the provider nothing at all |
Our take: In practice the test rarely fails on the first two questions. Almost everything an app talks to runs at a distance and is needed for something. The answer turns on the third question, ownership, and that is where we see teams slip. If a service was built for you and you own it, treat it as in scope and move on. The expensive mistake we keep seeing is filing a tailor-made backend under component because a vendor happens to operate it.
Worked examples
The draft guidance reasons through a set of fictional, archetypal products, and the gallery below mirrors that. Where it names a real technology category, it classifies the typical pattern. The answer turns on how you use the thing, own-built against licensed off-the-shelf, never a legal verdict on a named vendor.
A. Your own sync backend
Product: a notes or productivity app. The app connects to your REST API and your database on rented infrastructure. Handled at a distance, yes. Needed for a function, yes, file synchronisation. Built by or for you, yes. This is a remote data processing solution. The rented infrastructure underneath is a component. It is the textbook case from the section above.
B. Smart-home companion app
Product: a thermostat or a bulb and its companion app. The app talks to your cloud backend, which you built and run on third-party infrastructure. The device also works by a manual switch. Handled at a distance, yes. Needed for a function, yes, sending commands to a device, and the manual fallback does not change that. Built by or for you, yes. This is a remote data processing solution. The infrastructure underneath is a component. The regulation confirms that a smart-home manufacturer's cloud control falls inside scope.
C. Banking app, the all-three-categories case
Product: the banking app. One app, four dependencies, three categories.
- Your self-hosted API layer is a remote data processing solution. You built it, the app needs it, it runs at a distance.
- The account and ledger systems the app never touches directly are out of scope, an external dependency. They are still risk-assessed. You apply strong authentication of the backend interfaces, integrity protection, and verification of responses.
- A third-party support-chat SaaS is a component. You isolate it from the core banking flow, validate the content it returns, and run due diligence.
- Your push-notification code on a third-party PaaS is a remote data processing solution. The PaaS platform itself is a component. Your code is the software you designed. The platform is the rented layer underneath.
D. Identity and login
Product: any app. Signing users in is a function, so identity is in play.
- Your own token-issuing auth service is a remote data processing solution. You built it, the app needs it to sign users in.
- A third-party identity provider you only license off the shelf is a component, not a remote data processing solution. You assess the integration risk and run due diligence.
- A provider building a tailor-made identity service solely for you, owned by you, flips back to a remote data processing solution. Same vendor, different contract, different answer.
E. Off-the-shelf SaaS storage
Product: a media or e-reader app storing purchased content in a generic third-party storage SaaS. Handled at a distance, yes. Needed for a function, yes. Built by or for you, no, because you licensed an existing product off the shelf. This is a component, not a remote data processing solution. You secure the authentication, encryption and integrity of the communication, and run due diligence. Contrast it with example A. The same job, file storage, lands in a different category because of who built the service.
F. AI and LLM feature
Product: an app with an AI feature.
- Your own model or inference service that you built and run on third-party infrastructure is a remote data processing solution.
- A third-party model API you only license off the shelf is a component, not a remote data processing solution. You assess the integration risk and run due diligence.
- Data sent purely for model training or statistics, not needed for a product function, is likely out of scope. You still assess any risk that communication adds.
G. The out-of-scope set
Out of scope is not one thing. It has two sub-zones, and they carry different work.
- Nothing owed to the provider. The 5G or cellular network, the user's Wi-Fi and the router are connectivity enablers. They are not a remote data processing solution and not a component. You owe the operator no due diligence at all.
- Not a remote data processing solution, still a risk check. Crash or usage telemetry collected purely for statistics or future product development is not a remote data processing solution, but you assess any communication risk it adds. A marketing site or help centre the app merely links to is not a remote data processing solution either.
- Your own network. Internal CRM, HR, payroll, CI/CD pipelines, the internal distribution of updates to edge locations, and pen-test or red-team infrastructure are not a remote data processing solution. The CRA does not regulate your company network as a whole.
What each category obligates you to do
The category is not a label. It sets the work.
The line moves with the cloud model. On rented infrastructure, the software you deploy can be a remote data processing solution, the provider's hypervisor underneath is a component, and the physical hardware is the product environment. On a rented platform, your app code can be a remote data processing solution and the runtime platform is a component. An off-the-shelf SaaS application is a component, not a remote data processing solution.
Remote data processing solution. It is inside the product. You meet the Annex I essential requirements, fold it into the product risk assessment, cover it in the EU Declaration of Conformity and the technical documentation, and handle and report vulnerabilities across the support period.
Component. It is a third-party piece your product leans on. You assess the integration risk and mitigate at product level, through authentication, integrity checks, isolation and response validation. You run supplier due diligence and put security guarantees in the SLA. You can reuse evidence the provider already holds, such as a CE marking, an ISO/IEC 27001 or 27017 certificate, an EU cybersecurity certificate, evidence of the provider's NIS2 obligations, or its DORA obligations where they apply. A third-party provider changing its own service is not a substantial modification of your product.
Out of scope. No conformity or component duty. You still assess any risk the communication introduces, except for the connectivity case where you owe the provider nothing.
Write the remote data processing solutions and the third-party reliance into your technical documentation. The risk assessment covers the remote data processing solutions, the third-party reliance, and the product environment.
You do not have to put your whole backend through conformity. The CRA reaches only the parts of your systems that store or process the data a product function needs. Segregating those parts from the rest, the way the banking app keeps its ledger separate from its API, narrows what falls inside the assessment. And if one backend serves several products, declare it in each product's technical documentation. You can reuse that documentation from one product's assessment to the next.
Common mistakes
- Treating all your cloud as in scope. The CRA does not reach your company network as a whole. Your CI/CD, CRM, HR and payroll are out.
- Assuming who runs it decides it. Operation is not the test. Design, development and ownership are.
- Forgetting that components still need work. Out of the conformity scope is not out of obligation. A component needs an integration-risk assessment, product-level mitigations and supplier due diligence.
- Thinking telemetry pulls you in. Statistics-only telemetry is not a remote data processing solution. It still gets a comms risk check, but it is not part of the product.
- Confusing product updates with internal update distribution. A product receiving updates, including security patches, is a function, so the update-delivery service you build can be a remote data processing solution. The internal distribution of those updates across your own edge locations is internal infrastructure and out of scope.
Frequently Asked Questions
Is my app's own REST API in scope of the CRA?
Yes, if you built it and your app needs it to perform a function. The regulation's own example is a mobile app reaching an API or database run by a service the manufacturer built, and that puts your API inside the product's conformity scope. The cloud platform you run it on is a separate question, and it is treated as a component.
If I host my backend on a third-party cloud, does the cloud make my whole stack a remote data processing solution?
No. The remote data processing solution is the software you designed and developed, not the platform underneath it. That platform is the provider's, not yours, so the rented infrastructure is a component. You assess the integration risk and run supplier due diligence on it.
Is a third-party login provider a remote data processing solution?
It depends on how you use it. A third-party identity provider you license off the shelf is a component, not a remote data processing solution, even though signing users in is a function. If instead a provider builds a tailor-made identity service solely for you and you own it, that flips back to a remote data processing solution. Same vendor, different contract, different answer.
Does the CRA cover my internal CI/CD pipeline and CRM?
No. The CRA does not regulate your company network and information systems as a whole. Internal CRM, payroll, CI/CD pipelines, the internal distribution of updates to edge locations, and pen-testing or red-teaming all sit outside. These are your own network, not a remote data processing solution your product depends on.
Is the mobile network my app runs over in scope?
No. A 5G or cellular network is a connectivity enabler, like a router, an Ethernet cable or a Wi-Fi signal. It is neither a remote data processing solution nor a component, and you owe the network operator no due diligence at all. This is the one out-of-scope case that carries no obligation toward the provider.
What is the difference between a remote data processing solution and a component?
Both can run at a distance and both can be needed for a function. The difference is who built the service. A remote data processing solution is designed and developed by you, or under your responsibility, so it sits inside the product's conformity scope. A component is a third-party piece you license, so it stays outside conformity but still needs an integration-risk assessment, product-level mitigations and due diligence. See What is a product with digital elements for where remote data processing sits in the wider scope test.
This article is for informational purposes only and does not constitute legal advice. The worked examples follow the European Commission's draft guidance, Communication Ares(2026)2319816 of 3 March 2026, whose consultation closed on 13 April 2026 and which is not yet formally adopted. For specific compliance guidance, consult with qualified legal counsel.