安全與私隱要求

安全與私隱要求是產品常設要求的一部分，讓已核准的產品義務在不同交付作業中持續適用。本文說明承擔產品負責人或產品經理職責的人，如何結合專業意見與產品脈絡，把要求寫得足夠清楚，供人員與 AI 使用，並在政策、風險及相關要求改變時持續維護。這些經過維護的要求，讓後續作業有依據推導合規的功能規格，再驗證依規格交付的軟體。

這套做法以要求重用的研究為基礎。Christian 與 Mead 指出，有些安全要求過於含糊，無法指導交付；另一些則過於具體，直接指定特定機制。他們的《Security Requirements Reusability and the SQUARE Methodology》探討如何透過通用要求，以及對安全概念的共同理解來支援重用，並提出以重用為重點的 R-SQUARE，作為安全品質要求工程方法 SQUARE 的變體。¹ 在 AI 輔助交付中，後續工作還必須正確理解要求的適用條件、假設、例外及彼此關係，因此這些內容也要寫清楚。規格優先交付把維護和協調這些知識納入知識系統，讓其他交付作業、人員或 AI 工作階段接手時，仍能使用已確認的解讀。

安全要求說明產品必須如何保護資訊、資產與服務。私隱要求則關注資訊處理及其對人的影響，包括系統按預期運作時仍可能產生的影響。美國國家標準暨技術研究院（NIST）的《Privacy Framework》說明了這種較廣泛的私隱風險觀點。² 兩類要求都會參考適用法律、監管指引、合約、既有組織政策，以及專業風險判斷。產品常設要求與限制條件已定義這些判斷如何形成長期適用的產品義務；本文進一步說明安全與私隱要求的內容、使用方式與審查工作。

本文會以 Cookies 範例貫穿各節，透過網頁應用程式的 cookie 同意管理，說明高層次的私隱義務如何形成反覆適用的產品要求。網頁應用程式可以透過 cookies，也就是由使用者瀏覽器保留的小量資料，記住使用者的偏好，供下次造訪時使用。團隊需要判斷哪些用途必須取得同意，以及使用者同意、拒絕或撤回同意時，應用程式應如何回應。落實這些決定，涉及產品行為、專業判斷、技術控制措施，以及證明使用者選擇已生效的證據。本例假設具備相關專業能力的私隱決策負責人已確認，某一組非必要的偏好 cookies 必須取得同意；用於身分驗證的 cookies 和同意紀錄，則各有已核准的處理方式。團隊透過共用的 cookie 管理元件，在新增功能時持續落實這些決定。

返回頁頂

1. 專業權限與產品責任

在這個交付模型中，承擔產品負責人（Product Owner）或產品經理（Product Manager）角色的人，對產品合規負最終責任。大型組織通常設有專職角色；小型團隊則可能由工程師或創辦人兼任。因此，本文所述職責可以由同一人承擔，但仍須明確列出決策權限，以及任何必要的獨立審查安排。無論由誰承擔產品角色，都必須理解適用義務、提供解讀所需的產品脈絡、取得適當的專業意見，並確保已議定的要求反映在規格與驗收決策中。

產品脈絡包括產品提供什麼功能、處理誰的資料、處理目的，以及哪些服務會接收資料。法務或合規專業人員可能熟悉義務，卻不了解這些事實。因此，承擔產品責任的人也要提供這些資訊，並在產品改變時更正。

安全與私隱專業人員評估威脅、私隱影響，以及擬採用的控制措施是否足夠。如有法務與合規專業人員參與，他們會協助判斷哪些義務適用及如何解讀；團隊也可以從外部取得所需專業意見。組織須指定誰有權核准專業判斷、處理解讀爭議，以及接受剩餘風險或規則允許的例外。這樣的分工保留了專業決策權，而產品負責人或產品經理仍須負責把判斷落實到產品。

責任分工也要說明決策如何傳達及接受審查。NIST《Cybersecurity Framework 2.0》可作為相關治理參考：它把網路安全成果分為不同職能，其中 GOVERN 涵蓋風險策略、政策、角色、責任與監督。³ 實際準備時，團隊要為每項重大義務找出來源與決策負責人，記錄其權限範圍，並建立把未決問題交由他們處理的途徑。後續交付工作才能取得所需專業意見。

產品責任與適用法律訂明的責任並行。例如，歐盟《一般資料保護規則》（GDPR）把相關義務賦予資料控制者。歐洲資料保護委員會（EDPB）的指引說明了控制者對有效資料保護措施與保障機制的責任。⁴ 適用這套法規的產品團隊，須把相關控制者及其義務納入產品脈絡；其他法律制度可能採用不同的責任分配。框架中的產品負責人或產品經理角色確立交付責任，適用法律則決定產品須處理的法律責任。

專業意見要結合預期行為與實際資料流加以檢視，才能成為可用的產品知識。產品負責人或產品經理把意見與產品脈絡帶入結構化討論，讓相關參與者釐清適用條件、假設、例外，以及彼此有衝突的義務。AI 可以在討論中整理來源、提出待釐清的問題；專業結論則由具備相應能力的人員審查，並在其權限內確認決策。如果把未經審查的 AI 解讀當成定論，同一錯誤便可能一路傳入規格、實作與測試。

參與者執行业務分析、架構、工程或品質工作時，會運用已核准的判斷來定義行為、設計、實作及證據。在這些活動中，他們是專業判斷的下游使用者，即使同一人也兼任產品管理角色，仍是如此。他們要提供可能需要重新專業評估的事實，也有責任理解與自身工作相關的政策；即使已有控制措施執行日常規則，這項責任仍然存在。

在 Cookies 範例中，產品管理人員說明功能要記住哪些偏好，以及原因。私隱專業人員，以及有需要時參與的法務或合規專業人員，為同意與保留安排的決策提供依據；安全專業人員則評估存取與資料暴露風險。產品管理人員隨後確保已核准的 cookie 行為反映在功能規格與驗收條件中。

返回頁頂

2. 產品特定要求的形成與重用

返回頁頂

2.1. 組織脈絡與產品解讀

產品團隊根據與自身義務相關的來源，建立適用於產品的權威要求。如果組織維護了政策、標準、控制措施目錄或已核准的模式，組織脈絡層便能提供可重用的輸入，供團隊選取相關來源，再按產品情況調整其應用。若沒有這一層知識，產品負責人或產品經理便直接整理適用來源與專業判斷。共享知識系統說明了廣泛知識如何與產品特定解讀連接；獨立維護的組織脈絡層，是其中一種可用來源。

解讀的工作，是把義務連到產品為履行義務而必須作出的決策。例如，資料最少化原則仍需要團隊判斷：為達成所述目的，產品究竟需要哪些資料。ENISA 的《Privacy and Data Protection by Design》探討了從原則走向設計的過程，把法律原則連到設計策略與技術措施。⁵ 產品紀錄應保留已核准的解讀、來源與可取得的版本資訊、決策負責人，以及說明如何適用的理由。

組織可以透過 Model Context Protocol（MCP）提供政策儲存庫的存取途徑，讓 AI 工具讀取所連接的資源。在這種安排下，服務提供持續維護的來源，產品特定知識則記錄來源如何適用於軟體。按產品調整過的解讀可以直接用於工作，團隊同時要安排來源檢查與審查，使解讀保持有效。

管治指示列明參與者進行相關工作時必須查閱的知識。在 Cookies 範例中，只要變更涉及同意或 cookie 行為，已核准的要求與實作指引便應納入工作範圍。Skill 可以提供應用這些知識的程序。如果工具會選擇性載入 Skills，必要的閱讀要求與操作規則就應放在適用的管治指示中。團隊也要透過 AI 實際使用的存取途徑，確認它能取得相關來源。

人員同樣需要按工作選取脈絡。產品經理需要了解義務及其對產品的影響；工程師還需要已核准的設計與目前實作。〈共享知識系統〉所述的「按需分層載入上下文」，讓 AI 從較廣泛的脈絡逐步取得當前工作所需的知識。人員也會依專業責任與手上的工作，選取相關知識。

返回頁頂

2.2. 清晰程度與重用條件

下一位參與者要能重用要求，就必須理解其含義與適用條件。R-SQUARE 著重建立共同的安全概念，把通用要求定義清楚，讓面對相似威脅的系統能夠採用。¹ 產品特定的常設要求還要說明，原有推論在什麼情況下成立。在 Cookies 範例中，這包括已分類的偏好 cookies、用途，以及必須取得同意的條件。

以下資訊讓後續人員與 AI 能取得已核准的判斷。它們進一步展開產品常設要求與限制條件的參考結構，可以集中記錄，也可以透過持續維護的連結查閱。

可用的 cookie 要求會說明：哪些偏好 cookies 可以設定或讀取、用途是什麼、需要符合哪些同意條件，以及條件不再成立時必須如何處理。共用 cookie API 實作了其中部分決定。把義務明確寫出來，團隊日後就能依同一組預期結果評估替代元件。

返回頁頂

2.3. 形成要求時的依賴關係

產品意圖提供起始目的。其他產品常設要求可隨產品需要逐漸明確而形成，並在已有相關知識時互相參考。特定決策之前必須確立什麼要求，取決於適用條件，因此準備工作應依重大依賴關係安排；即使產品特定紀錄仍在形成，適用義務也持續有效。

產品管理人員與相關專業人員要找出知識缺口，以及哪些工作必須待缺口解決後才能推進。既有的可靠性、資料、架構或整合知識，可能揭露遺漏的私隱假設；新的私隱要求也可能指出這些領域的相應缺口。依照知識系統就緒度所述方法，每項重大缺口都需要負責人，以及必須解決的時點。

在 Cookies 範例中，團隊記錄的要求是：只有在所需同意仍有效時，才能為所述用途設定與使用已分類的偏好 cookies；使用者撤回同意時，相關使用必須停止，cookies 也必須移除。相關決策紀錄則列出涵蓋的資料、已核准的解讀，以及同意證據的獨立處理方式，供後續交付作業套用與檢視。

返回頁頂

3. 威脅、私隱影響與假設

要求需要保留足夠的分析脈絡，讓具備相應能力的參與者理解其成立原因，並辨識重大變更。安全分析檢視受保護資產與服務面對的威脅；私隱分析則檢視資料在收集、使用、披露、保留及處置過程中，可能對個人造成的影響。

進行這些評估，必須先知道資料流向，以及資料可能如何被處理。LINDDUN 是其中一種私隱分析方法，它把私隱威脅類別連到系統的資料流模型，協助識別要求。⁶ 至於較廣泛的風險評估，NIST《Guide for Conducting Risk Assessments》則整理了威脅、弱點、可能性與影響的評估方式，供決策使用。⁷ 專業人員選擇合適的方法，保留用來說明產品要求的結論，以及結論成立所依賴的條件。分析紀錄必須讓人能檢視這些條件；以下欄位可作為安全或私隱常設要求之決策依據的參考結構。

在 Cookies 範例中，安全分析會考慮偏好資料遭未經授權存取的風險；私隱分析還要檢視超出核准用途所需的保留，以及撤回同意後繼續使用的情況。最初判斷的假設是：偏好 cookies 用於所述的便利功能、只由預定的產品元件使用，並經由已核准的 cookie 管理途徑處理。

若某項交付作業把這些偏好分享給分析服務供應商，就改變了用途或接收者的假設。發現變更的參與者應記錄擬議資料流，並在依賴該判斷的規格獲核准之前，交由產品管理及相關專業人員處理。他們會對照既有要求評估新情況，判斷需要新增或修訂哪些義務。

返回頁頂

4. 控制措施的決策與常設要求之間的協調

返回頁頂

4.1. 控制目的與剩餘風險

控制措施是為達成安全或私隱結果而選用的措施。其決策紀錄說明預期效果、選擇理由、適用條件、預期證據及限制。剩餘風險則是在考慮所選措施後，評估仍然存在的風險。組織須指定誰有權在適用義務與例外規則允許的範圍內接受該風險。

選擇控制措施，首先要決定產品必須達成什麼保護效果。在選定具體機制之前，私隱設計策略提供了一組有助討論的概念。Hoepman 提出八項涵蓋資料處理與組織流程的策略：最少化、隱藏、分離、彙總、告知、控制、落實及證明。這些策略把早期私隱決策連到設計模式與技術。⁸ 在 Cookies 範例中，減少保留的偏好資料，以及讓使用者能行使選擇權，是兩種不同的控制目的，都需要能達成各自目的的實作。

產品常設要求表達義務與可驗證的結果；相關決策紀錄說明所選措施為何足夠；架構知識、管治指示與技術規格則記載具體設計與操作規則。產品常設要求規格與決策紀錄說明了現行要求與決策依據之間的這種分工。

Cookies 範例採用共用的 cookie 管理元件，讓應用程式碼透過它讀取、設定與移除 cookies。工程指引要求參與者使用該元件，並定義如何新增 cookie 行為。其決策紀錄說明控制措施的涵蓋範圍與限制，包括既有 cookies、第三方程式碼，以及未受涵蓋的執行環境。指定的決策負責人須處理重大的剩餘風險，或在權限內接受該風險。

只要要求、適用條件與成立假設仍有效，元件便可重用。新的資料、用途、接收者或信任關係，都需要重新檢查適用條件。使用元件的經驗有助於判斷其預期運作方式，而本次評估則要確認，它是否仍足以支援擬議用途。

返回頁頂

4.2. 要求之間的相互影響

安全與私隱要求和其他產品義務同屬一套產品常設要求系統。紀錄應指出重大依賴關係，以及對同一行為提出的相互衝突要求。相關決策負責人須判斷如何一併滿足適用義務，並記錄議定條件或已獲授權的例外。以下角度列出常見的相互影響，供團隊檢視。

在 Cookies 範例中，偏好資料與同意決策的證據各有用途。決策負責人分別指定處理方式，確保撤回同意會終止相關使用，並移除已分類的偏好 cookies；另有正當理由保留的證據，則依其各自獲核准的規則處理。功能規格就能為各類資料寫出議定結果。

團隊應記錄要求之間的關係，以及協調其相互影響後作出的決策。任一要求改變時，便能循這些關係找到另一位決策負責人與受影響規格。因此，重用工作也包括維護多項要求共同依賴的議定內容。

返回頁頂

5. 推導交付作業的功能規格

交付作業的功能規格定義可觀察的行為、情境、例外與驗收條件。準備規格的人員應找出適用的產品常設要求，確認其假設與相互影響，並在開始依賴這些知識的實作前處理重大缺口。

Cookies 範例說明這項工作如何從特定法律與產品脈絡出發。對適用英國相關規則的產品而言，英國資訊專員公署（ICO）的指引說明了 cookies 及相關瀏覽器技術的同意要求與例外。⁹ 產品負責人或產品經理與相關專業人員，應依適用指引確認擬議 cookie 用途的分類與義務。本例沿用前文已確立的同意要求，對偏好 cookies 的處理方式屬於已核准的情境假設。

產品常設要求確立撤回同意後必須達成的結果，以及停止相關處理的義務；交付作業規格則定義各種狀態及轉換如何達成該結果。政策或管治指示可以要求規格涵蓋相關狀態，精確行為則寫在功能規格中。以下紀錄說明：在已核准的分類範圍內，交付作業新增另一項非必要偏好時，需要確立什麼內容。

實際規格還要釐清可能影響結果的時機、進行中工作階段的行為、多分頁影響與失敗處理。分析人員及產品參與者會與相關專業人員共同確立行為；架構師與工程師決定設計及實作責任；品質專業人員則為每項重大條件安排相應驗證。如果實作發現某條 cookie 存取途徑不受已核准的控制措施涵蓋，或遇到相互衝突的保留規則，參與者須把發現交回決策負責人，再依既定權限修訂規格。

返回頁頂

6. 驗證與知識系統維護

返回頁頂

6.1. 符合要求與驗收

驗證要檢視規格是否涵蓋適用要求，以及軟體是否符合規格。在 Cookies 範例中，程式碼檢查可以確認應用程式碼是否使用共用 cookie 管理元件；行為證據還要確認，使用者的選擇是否在同意紀錄、受影響的 cookies，以及後續功能行為中產生議定結果。

使用者選擇與實際執行之間的關係，已有實證研究檢視。Matte、Bielova 與 Santos 研究了採用 IAB Europe「透明度與同意框架」的 cookie 橫幅；該框架會向參與服務傳達使用者的同意選擇。研究發現，有些實作在使用者作出選擇前，或已明確拒絕後，仍記錄為同意。¹⁰ 如果只檢查是否有橫幅或共用元件，就會漏掉這種失效情況。因此，驗收本例功能時，需要取得使用者同意、拒絕或撤回同意後相關行為的證據。

承擔驗收責任的角色審查這些證據、偏離項目，以及必要的專業判斷。產品負責人或產品經理仍對產品合規負責，包括要求是否足以處理產品的實際情況。可信賴交付作業與驗收證據進一步說明，如何把要求、責任、驗證與證據連到驗收決策。

返回頁頂

6.2. 定期審查與來源變更

安全與私隱要求沿用產品常設要求與限制條件所述的定期審查流程。每項要求，或按既定程序一併管理的一組要求，都須記錄最後實質修改時間、最近一次完成審查的時間與結果、下次預期審查日期，以及審查責任。負責人依義務及其後果選定合適週期；兩次定期審查之間若出現重大變更，則由事件觸發審查。

審查要確認產品脈絡、專業解讀、威脅評估、控制措施與剩餘風險判斷是否仍然成立，也要檢視它們與其他要求的相互影響。例如，對適用 GDPR 的產品而言，EDPB 關於第 25 條的指引要求在整個處理期間，定期審查資料保護措施是否有效。⁴ 團隊應找出自身產品適用的審查義務，並透過共通的產品常設要求流程記錄結果。

產品若依賴持續維護的上游來源，就可以用巡查工作檢查來源，找出可能影響已核准解讀的變更。紀錄須列明查過的來源與版本、時間及結果；專業審查再判斷要求對產品是否仍然有效。來源檢查與專業審查各自保留結果，即使審查確認既有要求仍有效、無須修改內容，也應留下審查紀錄。

若以程式碼儲存庫管理這些知識，每項由政策或法律衍生的產品特定要求，都可以在文件或所連結的要求索引中附上審查中繼資料。reviewOwner、lastReviewedAt、nextReviewAt、source 與 sourceVersion 等欄位，讓參與者能找到負責人、審查安排與所依據的來源。決策負責人在確認要求時選定週期，並記錄下次審查日期。按既定程序管理文件的平台，也可以維護同等資訊。

排程執行的 AI 工作可以依下列程序準備審查：

1. 讀取要求索引，找出已到期或逾期的審查，並一併查看相關來源變更通知與已記錄的產品變更。若缺少審查日期或無法存取來源，向指定負責人回報。

2. 比較權威來源與現行要求所依據的版本，整理審查摘要，列出來源連結、觀察到的變更、可能受影響的假設或控制措施、相關要求及未決問題。即使沒有發現變更，也要記錄來源檢查結果。

3. 把摘要交給承擔產品責任的人，以及負責相關專業決策的人員。他們評估目前產品脈絡、確認或修訂要求，並記錄已完成的審查、結果、下次審查日期，以及任何後續工作。

這項 AI 工作的權限涵蓋資料查找、比較與修訂建議的準備。排程工作完成，表示審查準備已完成；要求是否仍然有效，則由專業決策確認。在 Cookies 範例中，即使已發表的指引沒有改變，仍可能需要按期審查，因為新功能或第三方整合可能已改變偏好 cookies 的使用方式。

返回頁頂

6.3. 變更影響與知識保留

審查發現重大變更時，決策負責人須評估它對要求及相依知識的影響。如果共同假設、控制措施或先前已解決的衝突有所改變，就要檢視相關產品常設要求；如果交付作業規格與既有軟體的行為仍依賴已被取代的解讀，也需要審查。

在 Cookies 範例中，加入分析功能可能需要重新評估私隱、修改產品常設要求與控制措施的涵蓋範圍，以及定義新的功能行為。審查應找出這些後果與負責人，包括先前已驗收軟體所需的修正。要求目前是否有效，以及軟體目前是否符合要求，應分別清楚呈現。

若重大影響仍未釐清，必須先處理，才能據此核准相依工作。審查期間，既有生效日期與例外到期條件仍然適用。實作、驗證與營運中的發現，則透過交付作業生命週期中的知識收斂回到知識系統。

返回頁頂

7. 結語

安全與私隱要求把產品義務、適用條件、假設與預期證據寫得足夠清楚，後續交付工作才能重用其中的專業判斷。規格優先交付讓這些知識貫穿整個過程：承擔產品責任的人結合專業意見與產品脈絡，相關決策負責人確認產品常設要求，各項適用的交付作業再推導履行要求所需的行為與驗證。Cookies 範例展示了這個過程如何把同意義務連到可觀察的行為，涵蓋使用者的不同選擇，以及之後的產品變更。

要持續重用要求，就必須同時維護專業判斷與實作。來源檢查、定期審查，以及已記錄的要求關係，讓團隊能重新評估改變的假設、協調義務，並找出受影響的規格與軟體。AI 可以協助這些工作，相關決策仍由具備相應能力的人員作出。這樣建立的知識系統，既提供未來參與者可採用的已核准解讀，也清楚指出哪些問題需要重新判斷，以及應交由誰處理。

產品常設要求與限制條件對比例原則的說明，可用來決定準備與審查的深度；知識系統就緒度中的「不熟悉產品的參與者測試」，則檢視另一位具備相應能力的參與者，能否運用這些知識繼續負責任地交付。