資料存取申請流程圖（由申請到收回）
資料存取申請流程圖：寫明用途、查閱資料集的分級、由資料負責人決定、完成個人資料檢查、授予有期限的權限，再重新認證或收回。
運作方式
把泳道改成你們自己的組織
把申請人、資料管理員、資料負責人、私隱團隊和資料平台團隊，換成你們真正擁有的角色。即使今日兩份工作由同一個人兼任，也要令資料負責人與平台團隊保持分開，因為把兩者合併，正是「授出權限的人同時就是批核人」這種流程的成因。如果你們沒有私隱團隊，請寫上實際承擔這項責任的那個人，而不是把整條泳道刪走；如果資料管理是非正式安排，就把該領域的負責人放上去，並且白紙黑字寫明。
把你們的資料分級制度寫進圖裡
「查閱資料分級與處理規則」在等級不存在之前是空的一步。把它們一一命名——公開、內部、機密、受限制，或者你們自己那一套——並在每一級旁邊寫明它容許甚麼：只准在原處查詢、可以匯出、必須遮蔽、須簽署協議。然後說明哪一級會觸發使用協議那條分支，哪一級永遠不得離開分析環境。沒有這張對照表，每一份申請都要從頭辯論一次，而答案會隨著批核人而漂移。
令用途說明真正發揮作用
界定一份申請最少要說到甚麼程度：要回答的問題、需要的資料表與欄位、涉及誰的紀錄、想用多久，以及匯出的資料會存放在哪裡。「用作分析」應該被退回，而不是被批准。這是本頁成本最低的一項控制措施，因為一段寫得好的用途，會令最低權限的評估、遮蔽與否的判斷和到期日的訂定幾乎變成機械操作；而一段含糊的用途，會令這三件事全部變成任意決定。
按資料分級訂出預設有效期
為「授予權限並設定到期日」按每一級掛上一個預設值：破例存取用該宗事故的處理窗口，受限制資料大約九十日，內部資料六個月或十二個月，如有相關專案則用專案的結束日期。容許申請人要求更短的期限，並令任何長過預設值的要求，成為負責人的一項明示決定。到期機制是唯一一項能夠捱過重組、工具遷移和所有人忘記這條流程存在的控制措施。
在需要用到之前先議定緊急通道
決定誰可以啟動緊急破例存取、它會授出甚麼、由哪個帳戶執行、整段連線如何記錄日誌，以及在授出權限的那一刻要通知誰。然後訂出追認的限期——幾個工作天就夠——更重要的是，決定沒有人追認時會怎樣。到限期自動收回是唯一站得住的做法，因為一個沒有後果的事後審批隊列，一個季度之內就會變成永久積壓。
先走一次，然後發佈一個版本
把定稿的圖拿去給一位資料負責人、一位經常提出申請的分析人員、負責執行授權的平台工程師，以及處理私隱事務的同事，並用上一季三份真實申請來檢驗，其中要包括一份被拒絕的和一份走了破例通道的。按實際發生過的情況去修正這張圖，而不是按政策上寫的。然後發佈該版本、保留此前的版本，並在資料管治政策中連結過去，令讀者知道自己看的是哪一版。
常見問題
資料存取申請流程有哪些步驟？
提出一份寫明用途而不是寫明系統的申請；在資料目錄中找到該資料集，查閱它的分級與處理規則；確認它有具名負責人，沒有的話先為它分級；由該位負責人按最低權限原則評估用途並作出決定；如涉及個人資料，記錄合法處理基礎、精簡欄位，並經過私隱審查或 DPIA；在原始存取之前先提出遮蔽或匯總的方案；受限制資料另加一份已簽署的使用協議；授予權限並設定到期日；啟用查詢日誌；把該權限記入存取權限登記冊；然後在到期之前重新認證，或者收回它——如果當事人的職務或用途有變，就即時收回。實務中最常缺席的三步，是遮蔽這個替代方案、到期日，以及職務變動觸發的收回。
資料集的存取應該由 IT 還是資料負責人批准？
應該由資料負責人，即是這批資料所描述的那個業務範疇中負責的人，而不是營運底下平台的那個團隊。要作的判斷是「這個用途是否值得這批資料」，而只有明白這些紀錄代表甚麼的人才作得到。平台團隊負責執行授權、設定到期日、開啟日誌；它不應該同時決定誰有資格讀薪資、病人或客戶紀錄。加上直屬主管的批准作為第一道關卡是值得的，因為那確認了這份申請屬於當事人的職務範圍，但它不能取代負責人的決定。如果某個資料集真的沒有負責人，那件事本身就是一項發現——所以本圖把「是否已編目並有具名負責人？」放在評估之前，而不是之後。
資料存取權限應該多久到期？
夠用來完成寫明的用途就好，不要再長；預設值由資料分級決定，而不是逐份申請去談。一套行得通的做法是：破例存取用該宗事故的處理時間，受限制或個人資料大約九十日，一般內部資料六至十二個月，如果申請掛在某個專案上，就用專案的結束日期。機制比數字更重要：有了到期日，收回才是預設，續期才是刻意的動作，於是即使流程無人打理，權限也會自己衰減；沒有到期日的權限只會不斷累積。當你們請負責人重新認證時，把查詢次數一併附上——一項半年來無人查詢過的權限，收回時不會有人爭辯；而一份沒有附任何使用數據的名單，幾乎一定會被整批批准。
資料存取申請在甚麼情況下需要做 DPIA？
在歐盟與英國 GDPR 之下，當處理很可能對個人造成高風險時，就必須進行資料保障影響評估（DPIA），尤其是大規模處理特殊類別資料、系統性監察，以及會產生法律效果或類似重大影響的自動化決定；各地監管機構亦會自行公佈一份必須做 DPIA 的處理清單。香港與台灣的個人資料法例並沒有把 DPIA 定為法定要求，但同一套判斷在這裡照樣好用：涉及的人數規模、資料是否屬於敏感或涉及刑事紀錄的類別、當事人是否合理預期得到這種用途，以及輸出結果會不會用來作出關於他們的決定。實務上有兩件事最見效：每一份涉及個人資料的申請都先做篩查，而不是等有人提出疑慮；以及把結論當成授出權限時的條件——遮蔽哪些欄位、保留多久、不得重新識別身分——而不是當成一份歸檔之後就沒有人再看的文件。
本頁與一般存取申請流程有甚麼不同？
/yue/templates/存取申請流程 上的一般存取申請流程處理的是系統與應用程式：有人需要某個業務系統中的一個角色，由直屬主管與系統負責人批准，跑一次職責分隔檢查，然後由 IT 開通。本頁處理的是資料集，因此有三件事不同。批核人是資料負責人而不是系統負責人，因為問題關乎這些紀錄的意思，而不是某個應用程式的功能。流程中間多了一個資料分級的步驟，因為答案取決於那張資料表裡有甚麼。而且存在遮蔽或匯總這個替代方案，這在應用系統的權限裡並無對應物——你沒辦法批給某人財務模組的六成，但你可以批給他一個已經抽走識別欄位的檢視表。如果你們要設計的是應用系統權限的服務台表單，請由一般流程開始；如果你們要管治的是誰可以查詢資料倉庫，請由這一份開始。