CRA Remote Data Processing Solutions Explained

Remote Data Processing Is Defined in Article 3(2)

Article 3(2) provides the operative definition of remote data processing. The concept covers data processing at a distance where the relevant software is designed and developed by the manufacturer, or under the responsibility of the manufacturer, and where absence of that processing would prevent the product with digital elements from performing one of its functions. The definition is narrower than a general concept of cloud computing. It connects the remote service directly to manufacturer responsibility and product functionality.

• Use Article 3(2) as the primary test.
• Do not classify by hosting model alone.
• Establish manufacturer responsibility.
• Identify the product function dependent on the service.

The Processing Must Occur at a Distance

The first element is remote processing rather than processing entirely within the local product environment. Examples can include server-side computation, remote data storage, cloud-hosted logic, a manufacturer-operated API or a remote database. The fact that communication occurs over a network is relevant to the architecture, but network connectivity alone is not enough. The remaining Article 3(2) elements still need to be satisfied.

• Identify what computation or storage occurs remotely.
• Identify the communication path.
• Separate local and remote functions.
• Continue to the responsibility and dependency tests.

The Software Must Sit Under Manufacturer Responsibility

Article 3(2) requires the relevant remote software to be designed and developed by the manufacturer or under the manufacturer's responsibility. A manufacturer can therefore be responsible for remote software even where development tasks are performed by contractors or service providers under its responsibility. Conversely, Recital 12 distinguishes cloud services designed and developed outside the responsibility of the product manufacturer. The analysis should focus on responsibility for the remote software rather than simply who owns the physical servers.

• Manufacturer-developed software can qualify.
• Software developed under manufacturer responsibility can qualify.
• Server ownership is not the complete test.
• Independent third-party cloud services require separate analysis.

The Product Must Depend on the Remote Processing for a Function

The second central requirement is functional dependency. The absence of the remote processing must prevent the product with digital elements from performing one of its functions. This wording calls for an architecture-and-function test rather than a general business-impact test. If removal of the backend removes a product capability, that supports classification as remote data processing. If removal affects only analytics, internal administration or another activity that is not a function of the product, the Article 3(2) result can be different.

• Identify the exact affected product function.
• Test what happens when the backend is unavailable.
• Distinguish product functionality from manufacturer business operations.
• Record the conclusion.

One Lost Function Can Be Enough

Article 3(2) refers to one of the product's functions rather than complete product operation. A connected device might continue to perform local control while losing remote monitoring when its cloud service is absent. A mobile application might open successfully while losing synchronisation or account-dependent functionality. Those surviving functions do not automatically place the remote solution outside the definition if another genuine product function depends on the remote processing.

• The entire product does not need to stop.
• Partial functionality can remain.
• Analyse each product function separately.
• Do not use simple power-on testing as the scope test.

Recital 11 Specifically Identifies APIs and Databases

Recital 11 gives a concrete architecture example: a mobile application requires access to an API or database supplied by means of a service developed by the manufacturer. In that case, the service is within the CRA as a remote data processing solution. This confirms that remote processing can consist of application services and data services rather than only large cloud platforms. Product teams should therefore include backend APIs and remote databases in their scope assessment where the statutory conditions are met.

Remote Storage Can Be Relevant When Product Functionality Depends on It

Recital 11 discusses processing or storage at a distance and limits CRA coverage to the extent that the remote element is necessary for the product to perform its functions. Cloud storage should therefore not be classified merely because product data happens to be backed up remotely. The question is whether the remote storage is part of delivering a product function. Synchronisation, remote retrieval or shared state can create a stronger functional relationship than an independent manufacturer backup system that users never rely on as part of the product.

• Remote storage can be within the product boundary.
• Functional necessity still controls.
• User-facing synchronisation can be relevant.
• Internal backup systems require a different analysis.

Recital 12 Prevents Automatic Inclusion of Every Cloud Service

Recital 12 states that cloud solutions are remote data processing solutions only if they satisfy the Regulation's definition. A general cloud provider, independent productivity service or unrelated hosted business system does not become part of the CRA product merely because the manufacturer uses it. The manufacturer should define the software layer under its responsibility and identify whether that software provides a required product function.

• Cloud is not automatically in scope.
• General-purpose provider services need separate analysis.
• Identify the manufacturer-controlled software layer.
• Map the service to actual product functions.

Third-Party Infrastructure and Manufacturer Software Should Be Separated

Modern products frequently run manufacturer-developed software on infrastructure supplied by a separate cloud provider. Recital 12's reference to cloud services outside manufacturer responsibility means the legal assessment should not simply treat every layer as one service. The underlying infrastructure provider may supply an independent cloud service, while the manufacturer's own application, API or database layer can still require Article 3(2) analysis. Architecture records should distinguish infrastructure, platform and product-facing application responsibilities.

• Separate infrastructure from manufacturer application software.
• Record which party controls each layer.
• Do not assume third-party hosting removes manufacturer responsibility for its own software.
• Do not automatically pull an entire cloud provider into the product boundary.

The Manufacturer's Whole Network Is Not the Remote Processing Solution

Recital 11 clarifies that CRA requirements concerning remote data processing solutions do not amount to requirements for managing cybersecurity risks to the manufacturer's network and information systems as a whole. Product-facing remote services can be in scope without every internal identity system, office network, employee device or enterprise application becoming part of the CRA product. The product boundary should therefore be specific and technically defensible.

• Identify product-facing systems.
• Separate enterprise systems that do not deliver product functionality.
• Avoid an unlimited product boundary.
• Document interface points between product services and enterprise systems.

Create an Article 3(2) Scope Record for Each Remote Service

For every significant remote dependency, maintain a short Article 3(2) record. Identify the service, processing performed, responsible entity, software-development responsibility, product functions depending on the service, behaviour when the service is absent, interfaces with the local product and relevant third-party infrastructure. Conclude whether the service is part of the remote data processing solution and state why. This record provides a stable basis for the cybersecurity risk assessment and technical documentation.

• Name the remote service.
• Describe its processing.
• Identify manufacturer responsibility.
• Identify dependent product functions.
• Document outage behaviour.
• Record the legal-scope conclusion.