The RDPS three-part test, and why most APAC SaaS still fails one of them. 你的雲端到底算不算 RDPS？三個問題就能判斷。

There’s a question that decides whether a Taiwan smart-home brand’s conformity assessment costs €30,000 or €200,000. The question doesn’t live in the CRA itself. It lives in eleven paragraphs at the back of a 70-page draft guidance from Brussels — section 8, on remote data processing. Read those eleven paragraphs and the rest of your CRA project changes shape. 有一個問題，決定一家台灣智慧家庭品牌的 conformity assessment 成本是 €30,000 還是 €200,000。這個問題不在 CRA 條文裡。它躲在布魯塞爾發出來的一份 70 頁指引草案後半的 11 個段落——第 8 章，談 remote data processing。把這 11 段讀完，你整個 CRA 專案會變成另一個樣子。

The question: is the cloud thing your product talks to part of the product, in the CRA’s eyes? Or just something nearby? 問題是這樣：你產品連的那個雲，在 CRA 眼裡到底算不算產品的一部分？還是只是擺旁邊的東西？

If it’s part of the product, it goes into the conformity assessment. The Notified Body looks at it. The risk assessment must cover it. Vulnerability reporting under Article 14 covers it. The support period covers it. If it’s just nearby, it’s a third-party component — you do due diligence under Article 13(5) and you mitigate at the product layer, but the cloud itself isn’t in scope. The work is on a different scale. 如果算，它就得進 conformity assessment，Notified Body 會看它、risk assessment 要涵蓋它、第 14 條的弱點通報要涵蓋它、support period 也要涵蓋它。如果只算旁邊的東西，它就是第三方元件——你依第 13 條第 5 項做盡職調查、在產品層做緩解就好，雲端本身不在範圍。兩種狀況的工作量差好幾個級距。

The Commission gives a name to the “part of the product” case: remote data processing solution, RDPS. And it gives three questions to decide. 執委會給「算是產品一部分」的這種情況一個名字：remote data processing solution，RDPS。然後給了三個問題來判斷。

Three elements, in plain language: (1) is it at a distance, (2) does the product lose a function without it, and (3) is the software designed and developed by you or under your responsibility. All three have to be yes for it to be RDPS. Drop any one of them, and the cloud component falls out of scope — with very different consequences. 三個要素，白話講：(1) 是不是 at a distance？(2) 沒有它，產品會不會少一個功能？(3) 那個軟體是不是你做的、或在你責任之下做的？三題都要 yes，才算 RDPS。少一題，這個雲端元件就掉出範圍——但落地的後果完全不同。

Test 1第一道‘At a distance’ — the easy one.它「遠不遠」？這題基本送分。

The Commission says “at a distance” means data processing happening outside the user’s environment or, for a professional user, outside the organisation’s operational environment. Cloud computing, including edge computing, qualifies. Wired or wireless transmission doesn’t matter; ethernet and Wi-Fi both count. The boundary is environmental, not technical. 執委會說，「at a distance」指的是 data processing 發生在使用者環境之外；對企業使用者來說，是發生在組織的運作環境之外。Cloud computing 算（包括 edge computing）。有線無線都不影響——乙太網路、Wi-Fi 都算。這條線是環境上的，不是技術上的。

Almost everything you’re worried about will pass this test. A smart thermostat’s mobile app talking to AWS — yes. A POS terminal talking to a payment gateway — yes. An industrial robot streaming camera frames to a vision API — yes. The Commission’s intention with this test is to mark out things that aren’t at a distance — like data the product processes locally on the user’s device. The first test is mostly there to draw a line, not to fail anyone. 幾乎所有你會擔心的東西，都會通過這一道。智慧恆溫器的 app 連 AWS——通過。POS 終端連支付閘道——通過。工業機器人把相機畫面送到 vision API——通過。執委會這一道的目的，是把不算 at a distance 的東西排除掉——比如產品在使用者裝置上本機處理的資料。所以這一道主要是在畫線，不是在刷掉誰。

There’s one nuance worth catching. Recital 11 distinguishes “remotely by the manufacturer” from “locally on the user’s device” — the Commission anchors the boundary at where the processing happens, not at who runs it. So a server you operate yourself in the same data centre as the user (an edge server in a factory, say) still qualifies as “at a distance” if it’s outside the user’s device. 有個小細節值得抓住。Recital 11 區分「remotely by the manufacturer」和「locally on the user’s device」——執委會把界線畫在處理發生在哪裡，而不是誰在跑。所以你自己跟使用者放在同一個資料中心的伺服器（比如工廠裡的 edge server），只要它在使用者裝置之外，還是算「at a distance」。

Test 2第二道Without the cloud, does the product lose a function?少了那個雲，產品會不會掉一個功能？

This is the test that traps APAC manufacturers. The CRA says “one of its functions” — not “its core functionality”, not “its intended purpose”. The Commission underlines this point explicitly. The bar is low. The bar is too low. APAC 製造商最常在這道掉進陷阱。CRA 的措辭是「one of its functions」——不是「core functionality」、不是「intended purpose」。執委會在這點上講得特別清楚。門檻很低。低到容易讓人忽略。

The Commission lists six function categories that almost any modern connected product has: sending commands to a device, syncing files, user onboarding, configuration, receiving updates including security patches, identity and access management. If your cloud handles any of these — and most clouds for IoT do — the answer to test 2 is yes. 執委會列了六種幾乎所有現代聯網產品都有的功能：對裝置下指令、檔案同步、使用者 onboarding、設定（個人化）、接收更新（包括安全修補）、身份與存取管理。如果你的雲端做的是這六件事的任何一件——而多數 IoT 雲端都會——第二道答案就是 yes。

There’s a finer distinction worth knowing. If a function can be performed both remotely and locally — switching a smart bulb from the app or from the wall switch — the Commission says the remote path still counts as a function. You don’t escape the test by having a manual fallback. 還有一個細節值得知道。如果一個功能可以遠端做、也可以本機做——比如智慧燈泡可以用 app 開關、也可以用實體開關——執委會說，遠端那條路徑還是算一個功能。「我有手動 fallback」這個理由，逃不掉這一道。

What does fall out at this test? Telemetry collected purely for statistics or for future product development — the Commission gives this as the canonical example. Analytics dashboards your team uses internally, that the product itself doesn’t depend on. Update channels for marketing communications. Anything where switching off the cloud doesn’t change what the user can do. 什麼東西會在這道被刷下來？純粹做統計、或為了未來產品開發收集的 telemetry——執委會把這個當標準例子。你內部團隊用的分析儀表板、產品本身不依賴的那種。行銷溝通用的更新頻道。任何「把雲端關掉，使用者能做的事都不變」的東西，就會被刷下來。

There’s a curious case for websites. The guidance says websites are not RDPS if they only contain information about the product, even if the product redirects users to them. But an authentication portal that issues credentials the product needs in order to operate — that’s RDPS. The test isn’t whether there’s a URL involved. The test is whether the product loses a function when the URL goes away. 網站有一個有趣的情況。執委會說，如果網站只是放關於產品的資訊——即使產品會把使用者導過去——它不是 RDPS。但如果是個發 credential 給產品讓它能運作的認證入口——那是 RDPS。判斷不是看「有沒有 URL」，而是看「URL 不見了，產品會不會少一個功能」。

Most APAC manufacturers fail test 2 by passing it — they assume the cloud is in scope, and never check whether the function it supports could be downgraded. 多數 APAC 製造商在第二道是「以通過的方式失敗」——他們直接假設雲端在範圍內，從來沒檢查過那個功能是不是可以降級掉。

Test 3第三道Was the software designed and developed by you, or under your responsibility?那個軟體是你做的、或在你責任之下做的嗎？

This is the test where APAC manufacturers either over-protect themselves or under-protect themselves. There is no middle ground because the Commission’s definition of “under your responsibility” is sharper than most product teams expect. 這一道是 APAC 製造商不是過度保護自己、就是保護不足的地方。沒有中間值——因為執委會對「under your responsibility」的定義，比多數產品團隊以為的還精準。

In-house development — you wrote the cloud code — is unambiguously RDPS-qualifying. Easy. In-house 開發——雲端程式碼是你寫的——毫無疑問就是 RDPS。沒問題。

External development that’s “under your responsibility”: the Commission spells out what this means. The technology has to be tailor-made for you. Built solely on your behalf. Based on your designs and specifications. Owned by you, not licensed. If you commission a custom backend from a Taipei software house, signed off by your engineers, with you holding the IP — that’s under your responsibility. 外部開發但「在你責任之下」：執委會把界線講清楚了。技術必須為你量身訂做、單獨為你開發、按你的設計與規格做、由你擁有，不是 licensed。如果你委託台北一家軟體公司做一套客製化後端，你的工程師簽核，IP 在你手上——那就是「在你責任之下」。

Not under your responsibility: you license an existing product or service from a vendor who offers it to other customers as well, even if you got slight customisations. Salesforce, Auth0, Twilio, MongoDB Atlas, Stripe, Shopify, Zendesk — the standard SaaS stack — sits here. The provider built the product. You configured it. You’re a tenant. 不在你責任之下：你從一家也賣給其他客戶的廠商那裡 license 既有產品或服務，就算做了一些客製化也算。Salesforce、Auth0、Twilio、MongoDB Atlas、Stripe、Shopify、Zendesk——標準的 SaaS 組合——都在這邊。產品是供應商做的，你做設定。你是租戶。

The Commission walks through the three big cloud service models to make this concrete: 執委會用三種主流雲端服務模式把這件事講具體：

There’s a piece of the IaaS and PaaS rows that’s easy to miss. The hypervisor underneath your IaaS, the runtime underneath your PaaS, the operating system if you didn’t write it — those are not RDPS, even when the application running on them is. The Commission’s sentence on this is precise: certain elements within the same stack qualify, others don’t. Your conformity assessment scope follows the layer you actually built and own. IaaS 跟 PaaS 那兩列有個容易漏的地方。你 IaaS 底下的 hypervisor、PaaS 底下的 runtime、不是你寫的作業系統——那些都不是 RDPS，就算上面跑的應用是 RDPS 也一樣。執委會這句話寫得很精準：同一個堆疊裡有些元素算、有些不算。你的 conformity assessment 範圍，跟著「你真正打造、真正擁有的那一層」走。

There’s another distinction the Commission makes that matters. Who operates the solution is not a deciding factor. The CRA cares about who designed and developed it. So if you write the backend and contract a managed service provider in Singapore to run it for you, you’re still on the hook for the CRA essential requirements on that backend. Outsourcing operations doesn’t outsource compliance. 執委會還有另一個重要區分。誰在運作這個解決方案不是判斷因素。CRA 在乎的是「誰設計、誰開發」。所以如果你寫了後端、發包給新加坡的 managed service provider 幫你跑——後端的 CRA essential requirements 還是你要負責。外包運作不等於外包合規。

Practical — the “not RDPS” trap實作 — 「不是 RDPS」的陷阱Falling out of RDPS does not fall out of compliance.掉出 RDPS 不等於掉出合規責任。

If your third-party SaaS fails test 3 — and it usually does — the Commission is explicit: it should be treated as a third-party component. The cybersecurity risk it carries doesn’t go away. Article 13(5) requires due diligence on integrated components. The product as a whole still has to meet the essential requirements in Annex I. 如果你的第三方 SaaS 在第三道沒過——通常會——執委會講得很白：它要當第三方元件處理。它帶來的 cybersecurity risk 不會消失。第 13 條第 5 項要求對整合的元件做盡職調查。產品作為一個整體，還是要符合附件一的 essential requirements。

What changes is where the work happens. Inside RDPS, you’re responsible for the cloud’s own security posture, its risk assessment, its vulnerability handling under Article 14. Outside RDPS but as a third-party component, you mitigate at the product layer — strong authentication, encryption of communications, integrity verification of responses, isolation of the chat function from sensitive data, due diligence on the vendor. 變的是工作發生在哪。在 RDPS 範圍內，你要對雲端本身的 security posture、它的 risk assessment、它在第 14 條下的弱點處理負責。在 RDPS 範圍外、但作為第三方元件——你在產品層做緩解：強驗證、通訊加密、回應完整性驗證、把 chat 功能跟敏感資料隔離、對供應商做盡職調查。

The Commission’s banking app use case in § 8.3.1 is the cleanest illustration of this split: the bank’s own self-hosted API is RDPS; the third-party SaaS chat for customer support is not RDPS but is a component; the cloud provider’s PaaS underneath the bank’s notification code is not RDPS but is a component; the bank’s own notification code on top of that PaaS is RDPS. Same product, four different scopes, three different sets of obligations. 執委會在 §8.3.1 的銀行 app 用例，是這個切分最乾淨的圖示：銀行自己架的 API 是 RDPS；用作客服的第三方 SaaS chat 不是 RDPS、但是元件；雲端供應商的 PaaS 在銀行通知程式碼底下，不是 RDPS、是元件；銀行自己跑在那個 PaaS 之上的通知程式碼，是 RDPS。同一個產品，四種不同範圍，三套不同義務。

APAC implicationsAPAC 落地Where Taiwan and Japan manufacturers actually trip.台灣和日本製造商真正踩坑的地方。

There are three patterns that come up repeatedly in scoping conversations. 在 scoping 對話裡反覆出現的三個模式：

Pattern 1: Over-claiming RDPS to play it safe. A Taipei IoT vendor uses Auth0 for authentication, Twilio for OTP delivery, Stripe for payments, Mixpanel for analytics. They include all four in their CRA scope “to be conservative”. The result: a Notified Body engagement that contractually requires the vendor to give them access to four other companies’ security architectures — access those companies will not give. The project stalls. The right answer was that none of those four are RDPS — all four are licensed SaaS, all four fail test 3 — and the manufacturer should be applying due diligence at the integration layer instead. 模式一：保守起見過度宣告 RDPS。一家台北 IoT 廠用 Auth0 做驗證、Twilio 送 OTP、Stripe 收款、Mixpanel 做分析。他們「為了保守」把這四個都納入 CRA 範圍。結果：跟 Notified Body 簽的合約要求供應商提供其他四家公司的安全架構存取——那四家公司不會給。專案卡住。正確答案是這四個都不是 RDPS——全部是 licensed SaaS，第三道全部沒過——製造商該做的是在整合層做盡職調查。

Pattern 2: Building custom “to be safe” and locking the cloud into scope. A Tokyo robotics OEM commissions a Japanese cloud integrator to build a custom vision API for their industrial robots. They own the IP. The product can’t pick up parts without it (test 2: yes), it’s in the cloud (test 1: yes), it was designed and developed under their responsibility (test 3: yes). All three tests pass. The vision API is RDPS. It must be in the conformity assessment, in the risk assessment, in the support period, in the vulnerability reporting. They didn’t plan for that. They thought commissioning custom development would isolate them from CRA exposure on the cloud side. It does the opposite. 模式二：「為了保險」做客製化、結果把雲鎖進範圍。東京一家機器人 OEM 委託日本雲端整合商，為他們的工業機器人做客製 vision API。IP 在他們手上。產品沒有它就不能撿件（第二道：通過）、它在雲端（第一道：通過）、它在他們責任之下被設計開發（第三道：通過）。三道都過。Vision API 是 RDPS。它必須進 conformity assessment、進 risk assessment、進 support period、進弱點通報。他們沒規劃這件事。他們以為「委託客製化開發」可以把雲端方面的 CRA 暴露隔開。結果完全相反。

Pattern 3: The cellular network confusion. The Commission deals with this directly in § 8.3.5. A smartphone using a 5G network — the network is not RDPS. It’s a connectivity enabler, not data processing whose absence would prevent a function. The phone’s function is to connect to a network correctly; it doesn’t fail that function when the network is down, it just has nothing to talk to. APAC OEMs sometimes drag carriers and infrastructure providers into their compliance discussions when the regulation simply doesn’t reach there. 模式三：行動網路的混淆。執委會在 §8.3.5 直接處理這個。智慧手機用 5G 網路——網路不是 RDPS。它是連線的 enabler，不是「沒有它就少一個功能」的 data processing。手機的功能是正確連上網路；網路斷的時候它沒有失敗那個功能，它只是沒東西可連。APAC OEM 有時會把電信業者跟基礎設施供應商也拖進合規討論——但法規根本沒管到那裡。

What to do tomorrow明天就做的事Run the test on every cloud dependency. Document the answers.對每個雲端依賴跑一次測試。把答案寫下來。

For every cloud component the product talks to, write down three answers. Yes/No on test 1. Yes/No on test 2 — and if yes, name the function it supports. Yes/No on test 3 — and if yes, point to the contract or the IP record that supports the claim. Three Yes’s means RDPS. Anything less means third-party component. 對產品連的每一個雲端元件，寫下三個答案。第一道 Yes/No。第二道 Yes/No——如果 Yes，寫出它支援的是哪個功能。第三道 Yes/No——如果 Yes，指出哪份合約或哪份 IP 紀錄支持這個主張。三個 Yes 才是 RDPS。少一個就是第三方元件。

Then for each item, write what it implies. RDPS implies cloud-side risk assessment, cloud-side vulnerability handling, cloud-side support period commitment. Third-party component implies due diligence under Article 13(5), product-layer mitigation, vendor selection criteria. The act of writing this down — per cloud component, with names and signatures — is half the conformity assessment. The other half is doing what your own document says. 然後對每一項，寫出它的含義。RDPS 意味著：雲端側的 risk assessment、雲端側的弱點處理、雲端側的 support period 承諾。第三方元件意味著：第 13 條第 5 項的盡職調查、產品層緩解、供應商選擇準則。把這件事寫下來——一個雲端元件一欄、附上人名跟簽核——已經做了 conformity assessment 的一半。另一半，是把你自己寫的東西做出來。

The three-part test is the cheapest piece of CRA work you can do this quarter. It costs three columns in a spreadsheet. It saves a few hundred thousand euros downstream — in either direction. 三部測試是這一季你能做的最便宜的 CRA 工作。它花你一份試算表的三個欄位。它在下游省掉幾十萬歐元——不管你站在哪一邊。