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