Feishu Hong Kong

香港企業採購協作平台:資料私隱、跨境協作與供應商治理 FAQ

最後核實:2026-10-02

English version

客戶資料可以放進協作平台嗎?採購前先看甚麼?

要看資料內容、用途、誰可以查閱,以及你向客戶作過甚麼承諾。即使同樣是一份聯絡名單,交給內部同事跟進,跟分享給外部合作方,需要考慮的事情也不同。平台名稱本身不能替公司回答這些問題。

你可以先拿一個實際工作流程,列出會用到哪些資料、由誰上載、哪些同事和供應商要看,以及完成後怎樣保存或交接。討論時用空白表格或虛構資料便可以,不必為了展示流程先把真實客戶資料上載。

IT 可以核對存取設定,業務同事說明用途,HR 處理人員變動的交接;涉及私隱或合約判斷,再交給相應的專責人士。本文以香港採購問題為主;澳門辦公室或跨境項目的安排,需要另按當地及適用要求評估。

合作方需要看一份文件,要開放多少權限?

權限設計應從工作需要出發,而不是從方便一次開到最大出發。為成員、管理員、訪客和供應商分開定義可查看、可編輯、可邀請與可匯出的範圍;角色改變或項目結束時,安排移除不再需要的權限。

外部協作者尤其需要清楚的進出場規則:誰提出邀請、誰批准、有效期如何管理、交付完成後誰確認關閉。這些簡單的責任點,會比日後追查一個不明連結更容易管理。

把供應商與交接放進同一張清單

採用任何雲端服務或讓第三方參與流程前,團隊應把供應商聯絡人、支援升級方式、資料處理問題的內部負責人,以及退出或交接時需要取回的內容列入項目檔案。這不是要求每位使用者理解所有條款,而是避免關鍵決策只留在採購電郵或個人對話。

若項目包含客戶資料、個人資料或受規管資料,應由公司依其所在地、業務與合約情況尋求合適的法務、合規或資料保護意見。

每季用實際情景覆核

治理不應只在上線那天完成。可定期抽取一個已結束項目,檢查外部協作者是否仍有存取權、關鍵文件是否由團隊帳號擁有、交接紀錄能否找到,以及異常事件知道向誰升級。這類覆核不需要把每一項工作變成審計,但能及早發現流程與實際使用之間的落差。

本文提供的是營運管理框架,不構成法律、稅務、私隱或監管意見。任何合規決定應以公司的專業意見和適用要求為準。

私隱問題,不要留到合約最後一頁才問

香港企業在採購協作平台時,最容易出現的誤會是:只要供應商有一份安全頁面,資料私隱就已經處理好。事實上,是否合適取決於公司放入甚麼資料、誰可看、作甚麼用途、由誰管理,以及出現問題時能否追溯。香港《個人資料(私隱)條例》以原則為本,涵蓋收集、使用、保留、安全、公開透明及查閱更正等問題。這不代表每個項目都要由員工自行解讀法律,而是提醒管理層:先把資料流向和責任人說清楚,才能讓專業人士判斷下一步。

一個實用起點是把資料分成三類:日常工作資料、可識別個人的資料,以及需要額外審閱的客戶/受規管資料。分類不是為了把所有工作卡住,而是讓團隊知道哪些內容可以在一般協作流程處理,哪些內容應先問資料保護、法務或合規負責人。

CIO 與供應商的盡職調查,應有書面答案

當 CIO 問供應商問題時,重點不只是「有沒有保安」。更好的問法包括:哪些資料由公司控制、哪些由服務提供者代表公司處理;管理員如何設計角色與外部訪客;支援人員何時可能存取資料;項目結束後怎樣交接、匯出或刪除;發生事件時由誰通知誰;以及是否有其他處理方參與。要求書面回答,不是要為難供應商,而是讓內部採購、資訊安全和法務在看同一套事實。

同時,別把「已合規」當作任何平台可公開承諾的標籤。合規取決於資料、目的、設定、合約、所在地與公司自身做法。若涉及跨境資料、個人資料、金融或其他受規管內容,應由有權負責的人在具體情況下作判斷。

HR 其實是第一道日常防線

很多私隱問題不是由惡意造成,而是新同事不知道外部協作者看得到甚麼,或者離職交接時忘了撤銷一個連結。HR 的工作不是把法規背給同事聽,而是把簡單的行為規則放進入職、轉組和離職流程:哪些資料不要貼進公開群組;對外分享前應找誰;發現誤發或帳號異常時怎樣上報;離職後由誰確認文件和待辦已交回團隊。

這類指引應以真實情境寫成,而不是一大段禁止事項。舉例說,供應商需要看附件時,員工應知道先確認範圍與到期安排;客戶名單需要交接時,員工應知道由流程負責人確認,而不是私下轉寄。規則越貼近工作,越容易被執行。

每季一次的「小覆核」,比一次大承諾可靠

正式上線後,可定期抽一個已完成項目,請流程負責人、IT 和 HR 一起看四件事:外部帳號是否仍有不需要的存取;關鍵檔案是否仍由個人持有;角色變動後交接是否完成;若資料被誤發,大家是否知道要找誰。這種覆核不是法律審計,也不是為了追究同事,而是把制度與真實使用重新對齊。

本文的資料私隱段落根據香港私隱專員公署公開的條例概覽整理,目的在於協助採購提問,不構成法律、監管、稅務或安全意見。閱讀時可以把未答清楚的問題記下來,連同供應商的回覆交給公司負責私隱與合約的同事,一起確認。

不要把資料治理變成只剩 IT 的孤島

資料私隱與跨境協作最容易在部門交界失手:業務為了回覆客戶而分享附件、HR 為了安排人手而交接名單、IT 以為項目結束後流程負責人會移除外部權限。每個人都做了看似合理的事,卻沒有人看見整條資料路徑。因此,採購前應指定一位流程負責人,讓他把資料類型、外部角色、保留或交接方式和上報路徑寫下來,再由相關專責人士覆核。

供應商評估也不該只問一次就結束。合約、設定、使用情境或外部合作方改變時,原本的答案可能需要更新。管理層可以要求每季用一個已完成項目做短覆核,而不是等到出現事件才翻查誰曾經批准。覆核時請保留事實:誰仍有存取、哪些資料仍存在、誰負責下一步;不要急著用模糊的「已合規」安撫自己。

對員工而言,最有用的私隱指引往往很短:不確定能否分享時先問誰;發錯了怎樣報告;離職或轉組時交接甚麼;外部人員完成工作後誰關閉權限。把這些答案寫進日常流程,才讓條例、合約和採購盡調真的落在工作上。本文的價值是幫讀者問到正確問題,不是替任何公司下法律結論。

資料私隱 FAQ 的最後提醒

有供應商文件是否就可以放心? 文件是盡職調查的開始,不是公司責任的終點。誰應該看這份清單? 至少包括流程負責人、IT/安全、採購及涉及資料的人員;必要時加入法務或資料保護負責人。員工發現疑似誤發怎麼辦? 不要先猜測嚴重程度,先按既定路徑報告、保留事實並由指定人員處理。清楚的上報安排,比要求員工自行判斷法律問題更實際。

上線前的責任對照

流程負責人負責資料使用目的和交接;IT/安全負責帳號與存取控制;HR 負責人員變動觸發的通知;採購與法務按需要審閱供應商資料與合約。把這四個角色寫在同一頁,能避免每次出現問題都先問「這應該是誰的事」。

把「不知道」也記錄下來

在盡職調查中,最危險的不是一個尚未回答的問題,而是把它假定為已經沒問題。若採購團隊仍不清楚某項資料會由誰處理、某個外部帳號由誰批准,請把它標為待確認並指定負責人和期限。這種透明做法讓管理層能按風險作決定,也讓法務、合規或資料保護人員有足夠事實提出意見。把後續回覆與日期留在採購紀錄內,也能避免人員轉換後重新猜測原來的決定,讓交接更穩。

「資料放在哪裏?」供應商怎樣回答才算有用?

請對方按你準備購買的服務及方案書面回覆,並說明答案是否涵蓋主要資料、備份、支援存取,以及涉及的其他處理方。若只收到一頁概括的保安介紹,可以再請對方指出哪些內容適用於你的安排。

這裏沒有替飛書或 Lark 指定儲存地點;相關資料需要向供應商核實。香港、澳門與內地的適用要求也不能混為一談。拿到具體回覆後,再交給公司負責私隱和合約的人評估,較容易形成有根據的決定。

HR 想放員工資料,是否全部都適合放在同一個空間?

先按工作需要分開考慮。一般入職指引與薪酬、身份證明或病假文件,涉及的查閱需要並不相同。可以先列出每類文件由誰收取、誰確實需要看、何時覆核保留安排,再評估系統及設定能否配合。

示範或培訓時使用虛構資料,避免順手把真實員工文件當作測試材料。若不確定現有通知、用途或保留安排是否足夠,請公司的私隱負責人覆核。讓同事知道資料交給誰、有問題找誰,也是入職時一份很實在的安心。

企業採購 FAQ:按決策角色閱讀

CEO:資料私隱為何是商業決策,不只是 IT 問題?

我需要批准甚麼風險取捨?
批准清楚的資料分類、項目範圍、外部協作者邊界和升級責任;不要以『已加密』或『雲端供應商會處理』替代公司自己的決策。
何時應要求專業意見?
當涉及個人資料、客戶資料、受規管資料、跨境資料安排或合約義務時,應由公司按自身情況讓法務、合規或資料保護負責人參與。
董事/管理層要看甚麼摘要?
看資料流向、資料擁有者、外部成員、供應商責任、事件升級與退出安排;不是只看一份抽象的『合規證明』。

CIO:採購盡職調查要問供應商甚麼?

資料處理與存取要問到甚麼程度?
請供應商以書面回答資料類型、處理地點或安排、角色和權限控制、日誌、支援存取、資料保留/匯出/刪除、分包商與安全事件通報流程;並由內部相關人員判斷是否足夠。
跨境協作最小檢查清單是甚麼?
畫出資料由誰上載、誰可查看、是否有外部帳號、何時撤回權限、怎樣完成項目交接,以及出現異常時由誰暫停或升級。
可否宣稱某平台『已合規』?
不應作泛化宣稱。合規取決於資料、目的、設定、合約、所在地與公司自身控制;本頁只提供採購問題框架。

HR:員工使用與私隱責任怎樣落地?

培訓應講甚麼?
講清楚哪些資料可放入哪一類工作空間、何時不可對外分享、如何辨識外部協作者、遇到誤發或存取疑問向誰報告。
離職和轉組要做甚麼?
由人員流程觸發帳號停用或角色變更,並由流程負責人覆核文件、任務和外部存取是否已交接。
員工要背法律條文嗎?
不需要。給他們與工作相關、可執行的規則和升級路徑;法律與合規判斷留給指定負責人。
編輯核實來源(發佈前再次複核)