某一數據流是否會觸發本地化或跨境傳輸義務，取決於大多數主體並沒有真正梳理過的分類問題：數據屬於哪一類、適用什麼數量門檻，以及主體自身的處理活動是否屬於這些規則所針對的那類活動。這些問題都無法抽象地回答——每一項都取決於主體自己的系統實際做了什麼，而不是對這一監管領域的概括性描述。
分類先於合規，而不是與合規並行
本地化或跨境傳輸義務，是由特定數據的性質和數量觸發的，而不是因為主體是外資所有，或者在國際範圍內經營。兩家員工規模和收入相近的主體，可能因為實際持有的數據類別、以及在一定期間內有多少數據跨境流動，而處在義務的兩側。把“我們是外資主體，所以這大概適用於我們”當作起點來分析，就跳過了真正決定答案的那一步——那是數據層面的分類工作，而不是主體層面的。
主體通常在哪裏發現缺口
在實踐中，缺口很少是在正式審計中出現的。它出現在一項例行的供應商關係中——一款雲分析工具、一個總部設在境外的客户支持平台、一家服務器所在法域與所有人想象的不同的薪酬處理商——結果發現它以沒有人梳理過的方式傳輸數據，因為這層關係早於任何有意識的合規審查。選擇供應商看中的是它的產品，而不是對它的數據架構做過審查，數據究竟流向哪裏的問題在接入時從未被問起，因為沒有人想到要問。
問題從來不在於數據是否跨越了邊界，而在於目前是否有人能拿出一張圖，標明它所有跨越邊界的地方。
建立清單：實際涉及什麼
數據流清單在開始階段，與其説是一項法律工作，不如説是一項運營工作——它先從系統地列出觸及主體數據的每一個系統、供應商和集成接口開始，並針對每一項，查明數據實際在哪裏處理和存儲，而不是供應商的宣傳材料説它在哪裏。在實踐中，這意味着把信息技術、人力資源、財務和一切面向客户的系統彙集到同一場對話中，因為數據本地化問題很少遵守部門邊界——一個團隊選定的客户支持平台和另一個團隊選定的薪酬系統，各自都可能獨立產生一項沒有人放在一起看過的義務。
決定義務的是數量和類別，而不是意圖
一家主體即使從未打算把敏感數據傳輸出境，仍然可能僅僅因為它持有的數據類別和處理的數據量恰好越過了有關門檻，而觸發一項義務——意圖不是抗辯理由，“我們沒有意識到”描述的是缺口本身，而不是缺口的例外。這就是為什麼上述清單步驟必須真正全面，而不是只關注主體自認為敏感的數據流；真正重要的類別由監管框架界定，而不是由主體自己對什麼感覺敏感的直覺來界定。
清單建成之後，應當由誰負責
一份建成之後就束之高閣的清單，在一年之內就會失去大部分價值，因為新的供應商和系統在不斷增加，每一個都可能是新的數據流。能真正保持清單更新的主體，是那些明確指定了責任人的主體——某位職責包括在每次簽訂新供應商合同時詢問數據流問題的人，而不是交給碰巧記得的那個團隊。這一職責落在誰身上，因主體規模而異，但失敗的模式是一致的：沒有責任人的清單，過時的速度恰好與主體供應商關係變化的速度一樣快。
搶在問題之前的一套實用順序
- 把觸及主體數據的每一個系統和供應商都列入清單，包括合規或信息技術部門之外的團隊所選定的那些。
- 針對每一項，查明數據實際在哪裏處理和存儲，而不是供應商的宣傳所描述的位置。
- 依據主體實際面臨的監管風險，對所涉及的數據類別進行分類，而不是假定僅憑外資所有就能決定。
- 標出任何答案不明確的供應商關係，並把這種不確定性當作需要優先解決的事項，而不是日後再回頭處理的細節。
- 每當引入新的供應商或系統時，重新審視清單，而不是把它當作一次性工作。
一個實用的起點，是在某項具體傳輸變得緊迫之前、而不是之後，開展一次數據流清單工作。本文是對一個正在發展中的監管領域的一般性評論，不構成法律建議；具體的分類問題，應當交由熟悉主體實際系統的律師處理。