When a Cloud Backend Becomes Part of a CRA Product

Start With the Local or User-Facing Product

A backend scope analysis should start by identifying the product users receive or interact with. That can be a hardware device, installed software, mobile application or another product with digital elements. Document its intended functions before considering the backend. Without a clear function list, teams can easily classify every connected service as essential merely because the product communicates with it.

• Identify the supplied product.
• List intended product functions.
• Identify reasonably foreseeable connected use.
• Then map each function to remote services.

Map Every Product Function to Its Remote Dependencies

For each function, determine whether execution depends on a remote API, database, computation service, identity service, messaging service or another backend. The objective is not simply to create a network diagram. The map should show what the user loses when each dependency disappears. This directly supports the Article 3(2) requirement that absence of remote data processing prevent the product from performing one of its functions.

• Map functions to APIs.
• Map functions to databases.
• Map functions to remote computation.
• Record behaviour during service loss.
• Distinguish product features from internal business workflows.

A Backend Can Be In Scope Even When the Product Still Works Offline

A common scope mistake is to ask whether the device or application works at all when disconnected. Article 3(2) uses a narrower function test. A smart device can keep local controls but lose remote control. An application can continue to display cached content but lose synchronisation. If a genuine product function disappears when the manufacturer-controlled backend is unavailable, the fact that other functionality survives does not automatically take the backend outside the remote data processing definition.

• Offline operation is not an automatic exclusion.
• Partial product operation can remain.
• Identify each function lost during backend outage.
• Record whether the lost capability is part of the product.

Manufacturer Responsibility for the Backend Software Is Essential

Functional dependency alone is not the whole test. The remote software also needs to be designed and developed by the manufacturer or under its responsibility. A manufacturer-operated product API is a different case from a fully independent external cloud service designed outside the manufacturer's responsibility. Architecture documents should identify who specifies the software, controls development, approves releases and bears responsibility for the product-facing backend layer.

• Identify who designs the backend.
• Identify who controls development.
• Identify who approves product-facing changes.
• Separate manufacturer responsibility from independent provider responsibility.

Recital 11 Makes Manufacturer APIs a Clear Example

Recital 11 describes a mobile application that requires access to an API or database supplied through a service developed by the manufacturer. It states that the service falls within the CRA as remote data processing. A manufacturer-developed API that provides product data, commands, synchronisation or another required capability should therefore be examined as part of the product boundary rather than treated automatically as a separate web service.

• Manufacturer API services can be product components.
• Database-backed services can be included.
• Mobile application backends are expressly contemplated.
• Apply the full Article 3(2) test.

Remote-Control Backends Are Another Express Example

Recital 12 gives cloud-enabled functionality supplied by a smart-home device manufacturer that allows users to control the device remotely. This is a straightforward example of a remote service delivering a product function. Similar architectures should still be assessed on their own facts, but the recital demonstrates that a backend does not sit outside the CRA merely because its code executes in the cloud instead of inside the physical device.

Ancillary Analytics Need a Different Functional Test

A manufacturer can collect telemetry for internal analytics, business intelligence or product improvement without that processing necessarily constituting a product function. If removing the analytics pipeline leaves all product functionality intact, the Article 3(2) dependency element may not be satisfied for that service. This conclusion should not be assumed from the word analytics, because analytics can sometimes directly power user-facing recommendations or other functionality. The relevant question is what function the remote processing actually delivers.

• Internal analytics may be outside the product function boundary.
• User-facing analytics functionality can require different treatment.
• Test what the user-facing product loses.
• Document the purpose of the data processing.

A Corporate Website Is Not Automatically Part of the Backend

Recital 12 states that websites that do not support the functionality of a product with digital elements do not fall within scope as remote data processing solutions. A manufacturer's marketing site or corporate information site therefore should not be inserted into the product architecture merely because it shares a domain, identity platform or hosting provider. If a web application actually controls or configures the product, however, the functional analysis changes.

• Marketing websites are not automatically in the product boundary.
• Shared branding is not the legal test.
• Shared hosting is not the legal test.
• Product-control web applications require functional analysis.

Third-Party Cloud Infrastructure Does Not Automatically Decide the Application Layer

A manufacturer can run its own product backend on infrastructure supplied by an independent cloud provider. Recital 12 distinguishes cloud services designed and developed outside the manufacturer's responsibility, but the manufacturer's own application software can still be designed and developed under its responsibility. The product-scope record should therefore distinguish the independent infrastructure service from the application, API, database schema or business logic that the manufacturer controls.

• Separate infrastructure from application software.
• Identify responsibility at each layer.
• Do not classify the full cloud stack as one undifferentiated service.
• Assess manufacturer-controlled backend software independently.

Authentication Dependency Can Affect the Scope Analysis

Where a manufacturer-controlled backend performs authentication that is necessary before the product can perform a function, the dependency can be relevant to Article 3(2). At the same time, the use of a completely independent identity service does not automatically make that entire external service part of the manufacturer's product. The correct boundary depends on which software is under manufacturer responsibility and what product function depends on it. Authentication architecture should therefore be included explicitly in the dependency map.

• Map authentication to product functions.
• Identify manufacturer-controlled authentication software.
• Identify independent identity-service layers.
• Avoid automatically importing an entire external service into the product.

Backend Changes Can Change the Product Boundary

A remote service that begins as optional can become essential after new product functionality is added. Conversely, functionality can move from the cloud into local software. The remote data processing conclusion should therefore be reviewed when the manufacturer adds APIs, introduces account requirements, changes offline behaviour, replaces providers or moves significant processing between local and remote environments. Scope classification should follow the current product architecture rather than the architecture that existed at first market launch.

• Review new cloud-dependent features.
• Review changes in offline behaviour.
• Review provider changes.
• Review movement between local and remote processing.
• Update the product-boundary record.

Use a Backend Scope Matrix

A practical backend scope matrix can contain one row per remote service. Record the service name, product functions supported, whether the processing occurs at a distance, who is responsible for the software, what happens if the service is unavailable, underlying cloud provider, interfaces with the product and final Article 3(2) conclusion. This makes the legal reasoning reproducible and gives engineering, security and compliance teams a shared architecture model.

• One row per remote service.
• Map the supported product function.
• Record manufacturer responsibility.
• Record outage consequences.
• Identify infrastructure provider separately.
• Record the CRA scope conclusion.