適用性聲明（SoA）怎麼寫：範圍、控制項取捨與常見錯誤

適用性聲明（Statement of Applicability，SoA）是 ISO/IEC 27001 風險處理流程要產出的一份文件。這裡的 ISO/IEC 27001 指國際標準化組織與國際電工委員會共同發布的資訊安全管理系統要求事項標準。SoA 列出組織為了把資訊安全風險降到可接受水準，決定採用哪些控制措施、為什麼採用、目前做到哪裡，以及附錄 A 裡哪些控制措施被排除、為什麼排除。它不描述風險長什麼樣子，只交代「決定了什麼」。

企業真正卡住的很少是「要不要做 SoA」，多半是「做到什麼程度才算寫完」。內容只有四件事，但這四件事要能跟風險評鑑互相對得起來。以下依序講欄位、93 項怎麼取捨、排除理由怎麼寫、順序與範圍，最後是八個常見的退件寫法與台灣本地的規定。

文中由驪鑫整理。驪鑫是 ISO 輔導顧問公司，輔導為主、可協助企業走完驗證流程；服務範圍為全台，北中南皆有據點，可就近安排或到廠。我們不發證，發證的是驗證機構。

適用性聲明（SoA）是什麼，跟風險評鑑、風險處理計畫差在哪

ISO/IEC JTC 1/SC 27 工作組的公開文件寫得很清楚：自 ISO/IEC 27001:2013 起，SoA 一詞指的是文件化資訊，內容包含組織必要的資訊安全控制措施、這些措施納入 SoA 的理由、是否已實作，以及被排除的附錄 A 控制措施的理由。原文：the term SOA refers to the documented information that contains an organization’s necessary information security controls

翻成中文就是四件事。查「ISO 27001 適用性聲明」找到的就是這份文件，它不叫控制措施清單，也不是風險評鑑報告。

• 哪些控制措施是這個組織非做不可的。附錄 A 有 93 項，真正要列進來的是「為了把風險降到可接受水準，我們確實需要」的那一些。
• 每一項納入的理由：它對應哪個風險，為什麼這個風險需要這項控制措施。
• 每一項目前是否已實作。這是狀態欄，寫「已實作」或「未實作」；「適用」「不適用」不是這裡的用語。
• 附錄 A 中被排除的控制措施，以及排除的理由。理由是依組織的業務情境判定為不需要，而且要把那個業務事實說出來。

控制措施編號怎麼編、要不要標擁有者、要不要放證據連結，這些是你家自己的規格，標準沒管。下一節談欄位時會再拆一次。

SoA 的位置在 ISO/IEC 27001:2022 第 6.1.3 條 d) 款，是「資訊安全風險處理」這個流程的第 4 個動作。整條流程是：a) 依風險評鑑結果選處理選項；b) 決定所有必要的控制措施；c) 與附錄 A 對照，確認沒有漏掉必要控制措施；d) 產出適用性聲明；e) 制定風險處理計畫；f) 取得風險所有者對風險處理計畫的核准與對殘餘風險的接受。（條號與順序經驗證人員指引，以及財團法人全國認證基金會（Taiwan Accreditation Foundation，TAF）公告的 TAF-MS-IC01 轉引；標準文中為付費出版品，文中未取得全文，因此不以引號引用標準原文。）

很多人花時間找「官方格式」，其實找不到。ISO/IEC 27001 只規定 SoA 必須包含什麼，沒有規定它要長成什麼樣子。同一份文件接著說，組織可以用附錄 A 的結構，做成表格再加上實作狀態與理由欄；也可以用自己的控制措施名稱與描述，甚至用「我們的做法是……」這種事實句來寫，而不是「組織應……」這種要求句。翻成白話：內容標準要管，格式你自己選。原文：It does not specify how it should be structured.（出處同上，ISO/IEC JTC 1/SC 27 工作組公開文件，未經 ISO 背書）

它跟另外兩份文件常被混成一件，但三份要交代的事情不同。

	風險評鑑紀錄	適用性聲明（SoA）	風險處理計畫
條號	6.1.2（執行期另於 8.2 再做一次）	6.1.3 d)	6.1.3 e) 制定、f) 核准；8.3 實作
要交代什麼	風險準則與接受準則、辨識流程（含風險所有者）、分析流程（後果、可能性、風險等級）、與準則比較後排出的處理優先序	必要控制措施、納入理由、是否已實作、排除附錄 A 控制措施的理由	哪一項風險用哪個控制措施處理、處理後能否達到接受準則、誰核准、殘餘風險由誰接受、實作結果的文件化資訊
什麼時候產出	風險評鑑做完時	必要控制措施與附錄 A 對照完成之後，風險處理計畫之前	SoA 之後；實作階段的結果另外留下紀錄
回答誰的問題	我們有哪些風險、哪些要先處理	我們決定用哪些控制措施、不用哪些、為什麼	誰在什麼時候把哪一件事做到什麼程度、做完的殘餘風險誰簽
稽核時怎麼被看	抽一項風險，看它有沒有被評、有沒有分級	抽一項控制措施，看它能不能追回風險，反向也抽一次	抽一項處理工作，看有沒有做、做完的證據在不在

三份文件是一條線：風險評鑑決定「有哪些風險」，SoA 決定「為了這些風險，我們用哪些控制措施、哪些不用」，風險處理計畫決定「誰、什麼時候、做到什麼程度，殘餘風險誰簽」。SoA 的每一列往上要能追到風險評鑑的某一項，往下要能追到風險處理計畫的某一項工作。追不到的那一列，稽核員就會問「這項控制措施是為了什麼」。

能不能合成一份？標準沒有禁止同一份文件同時承載這三種內容，前面那份委員會文件也明說組織可以加入任何額外資訊。但有個條件要先滿足：驗證機構的稽核報告要「引述適合性聲明之版本」，SoA 本身也要納入驗證文件之中（驗證機構認證規範 ISO/IEC 27006-1:2024 中文版 9.4.3.1 b) 與 8.2.2）。合併時就得能在同一份文件裡單獨指出 SoA 的版本與範圍，例如獨立一頁封面、獨立一個版本區塊，或一份文件三個清楚分開的章節。做不到這一點，第一次改版版本追蹤就會斷。（此段為推論：標準未就合併形式表態，這是從「版本必須可被引述」反推的條件。）

ISO 27001 一定要有適用性聲明嗎？沒有 SoA 能不能驗證

答案要看兩層，兩層的證據強度不一樣。

條文用的是「應」：第 6.1.3 條 d) 款要求組織產出適用性聲明，內容即前述四項，同條末句還要求組織保留風險處理過程的文件化資訊。從要求事項的角度看，SoA 是這個流程本來就該留下的產出，沒有「有更好」這種選項。（條文經驗證人員指引轉引；標準文中付費未取得，文中不以引號引用標準原文。）

另一層是驗證制度，多數企業的壓力來自這裡。我國的驗證機構認證規範，也就是 ISO/IEC 27006-1:2024 的中文版，由 TAF 以 TAF-MS-IC01 公告，2024-09-11 實施，寫得很直接：「驗證機構應查證驗證範圍至少具有 1 份適用性聲明。」（9.1.3.6）以及「適用性聲明應納入驗證文件之中。」（8.2.2）

還有一個主體要先分清：ISO 本身不發證，官方寫「ISO does not perform certification or issue certificates」。判定能不能發證的是驗證機構（Certification Body，CB），它依 ISO/IEC 27006-1 執行；國內則由 TAF 依 TAF-MS-IC01 對驗證機構做認證。標準給你要求，驗證機構給你判定，兩個角色不要混。

要講就講這一句：「依驗證機構規範（ISO/IEC 27006-1，國內由 TAF 以 TAF-MS-IC01 公告），驗證範圍內至少要有一份 SoA，且 SoA 要納入驗證文件。」「ISO 27001 規定沒有 SoA 就一定拿不到證書」這種說法，把驗證機構的規範講成標準條文，遇到追問就答不下去；對方一旦拿出驗證機構的實際要求，你的說法會顯得比事實更絕對。

SoA 是必要文件，沒有它不行。但它得是流程的產出。先寫 SoA、再回頭補風險評鑑，文件上看不出來，稽核時一抽就看得出來。

至於認證申請、兩階段稽核與矯正流程本身，屬另一篇的範圍，這裡只留一句導向：〈ISO 27001 認證怎麼申請？流程、導入與輔導重點〉。

SoA 表格要有哪些欄位？哪些是標準要求、哪些是業界慣例

網路上流傳的 SoA 表格動輒十幾欄，很容易讓人以為欄位越多越完整。實際相反：標準要求的是四項內容，其餘都是呈現方式或業界慣例。下面這張表把常見的十欄逐一標明性質。

欄位	性質	說明與依據
必要控制措施清單（編號或名稱）	標準要求	6.1.3 d) 第 1 項要求列出必要控制措施（含 6.1.3 b) 與 c) 的結果）。名稱與編號格式標準未規定。
納入理由	標準要求	6.1.3 d) 第 2 項；理由須反映組織情境與風險管理安排（見下一節引文）。
是否已實作	標準要求	6.1.3 d) 第 3 項。這是狀態欄，不是適用性欄。
排除理由（僅限附錄 A 的控制措施）	標準要求	6.1.3 d) 第 4 項；驗證機構規範也這樣描述 SoA 的用途（TAF-MS-IC01 8.2.3 b)）。
「適用／不適用」判定	由四項內容推得的呈現方式	有納入才有納入理由、有排除才有排除理由，所以「適用性」是結果的呈現，不是另一項獨立要求。
對應的風險或風險處理措施	業界慣例（稽核實務的核心檢查點）	讓 SoA 能與風險評鑑雙向抽樣核對；沒有這一欄，就得靠編號或另表對照。
證據或文件指涉（政策、程序書、紀錄）	業界慣例	讓「已實作」這句話有去處；稽核員通常直接照這一欄抽件。
控制措施擁有者	業界慣例	標準未要求；但出事時要有人認這一行。
版本、日期、核准紀錄	半要求	標準未規定這些欄位，但稽核報告要引述 SoA 版本（TAF-MS-IC01 9.4.3.1 b)），沒有版本就無法被引述。
額外資訊（例如控制措施屬性、對應條文）	組織自選	委員會文件明說組織可以加入任何額外資訊。

最容易被寫錯的是第五列。「適用／不適用」那一欄是台灣與業界長年下來的呈現習慣，條文裡沒有這一項要求，它背後對應的其實是「有納入理由」與「有排除理由」。表格只做適用性勾選、理由欄留白，形式上很像我國常見的表格，實質上少了標準真正要的兩項。反過來說，理由寫得夠具體，即使表格上沒有「適用」這一欄，也不會少東西。

還有一種說法要避免：「法規規定的格式是……」「ISO 官方範本長這樣」。標準只管內容不管結構（前節引文），ISO 也沒有發布 SoA 範本，這項查無公開資料。各驗證機構有自己的建議格式，那屬機構文件，不是標準。

小型組織最少要留幾欄？以下是顧問實務建議，不是標準要求。單一廠址、系統不多、風險項目在數十項以內，六欄就夠用：必要控制措施、納入理由、是否已實作、對應風險編號、證據或文件指涉、版本與核准。被排除的附錄 A 控制措施另立一段清單，逐項寫排除理由。這樣每一列都能被追問三次而不空：為什麼用這項、這是哪一項風險、做到哪裡看什麼。規模變大、廠區變多，再補擁有者與處理措施欄。一開始就開十幾欄，最後通常只有前三欄填得滿。

93 項控制措施可以全部納入嗎？取捨的判斷方式

取捨的討論常常從一個錯的數字開始。附錄 A 的控制措施分四個主題，合計 93 項：

主題	編號範圍	項數
組織控制措施	A.5.1–A.5.37	37
人力控制措施	A.6.1–A.6.8	8
實體控制措施	A.7.1–A.7.14	14
技術控制措施	A.8.1–A.8.34	34
合計	—	93

（主題與項數依 TAF-MS-IC01 附錄 E 表 E.1，ISO/IEC 27006-1:2024 中文版。TAF 中文版把 people 譯作「人力控制措施」，本站其他頁面若寫「人員控制措施」屬業界通行譯法。文中不逐條解說 93 項內容，需要逐條看法的請見〈ISO 27001 Annex A 的 93 項控制措施怎麼看〉。）

「93 項全部納入可以嗎？」這個問題沒有單層的答案，得拆成四層看，任何一層單獨拿出來用都會得到錯的結論。

全部納入本身不違反條文。 6.1.3 b) 要求組織決定所有必要的控制措施，而附錄 A 的控制措施可以全部都是你的必要控制措施，條文沒有要求你必須排除一部分。「我們決定 93 項都要」在形式上站得住。

但全部納入、每一項說不出理由，就不合格。委員會文件寫得很直白：納入的理由必須反映組織的情境與風險管理安排，「因為它在附錄 A」是明示不合格的寫法。實務上還有一種變形：理由欄全部貼同一句話，例如「依風險評鑑結果納入」，93 列一模一樣。這在稽核員眼中等於沒寫，因為它回答不了「這一項對應哪個風險」。原文：the justification for inclusion of a control must reflect the context and risk management arrangements of the organization, not simply because it is in Annex A.（ISO/IEC JTC 1/SC 27 工作組公開文件，未經 ISO 背書）

全部納入卻沒做，會落到「未實作」加「風險處理計畫沒被實作」。 同一份委員會文件提醒：把附錄 A 的控制措施文字直接當成自己的必要控制措施、卻沒照著做，就會留下大量被判定不符合的空間。8.3 要求組織實作風險處理計畫並保留實作結果的文件化資訊；未實作的控制措施所對應的殘餘風險，仍要由風險所有者接受（6.1.3 f)）。93 項全寫「已實作」，等於對外宣告 93 個可以被要求拿出證據的承諾。原文：If the organization adopts the Annex A control text as its necessary control specifications but does not do what the Annex A control specifies（ISO/IEC JTC 1/SC 27 工作組公開文件，未經 ISO 背書）

93 項全寫「已實作」，是最容易被反向抽樣打穿的寫法。 稽核抽樣不看你的目錄有多整齊，而是隨手挑一列問「這個做到哪裡、紀錄在哪」。只要有一列答不出來，那一列就從「已實作」變成「未實作」，連帶影響風險處理計畫的完成度。誠實寫「未實作」並不是災難，它只是把工作推進風險處理計畫，讓殘餘風險進入核准流程。真正難處理的是寫了「已實作」卻沒有證據。（以上為顧問實務）

還有一個方向要放進來：必要控制措施不必來自附錄 A。 驗證機構規範寫得很清楚：「組織可自行設計必要的控制措施，或是從任何來源選用，因此，即使組織的必要控制措施皆非 ISO/IEC 27001:2022 附錄 A 規定的項目，也可能通過 ISO/IEC 27001 驗證。」（TAF-MS-IC01 9.1.1.2 註）委員會文件也說：「Annex A … is, by design, neither complete nor recommended.」（同上，未經 ISO 背書）「附錄 A 沒寫的我們就不必做」與「附錄 A 有的我們都要做」，是同一種誤解的兩面。

那用 ISO/IEC 27002 佐證取捨可以嗎？可以，但角色要分清楚。ISO 官方對 27002 的定位是實作指引，官方常見問答直接回答：27002 提供的是最佳實務建議，不能用來驗證。所以 27002 可以拿來說明「這項控制措施通常怎麼做才做得到」，理由本身要回到你的風險與業務情境。寫成「因為 27002 建議」，跟「因為它在目錄裡」是同一種寫法。原文：No, ISO/IEC 27002 provides best practice recommendations and cannot be certified to.

取捨的依據是風險，不是附錄 A 的目錄。 三種常見組合的風險不同。全部納入並逐項寫出對應風險，工作量大但一致；納入大部分、少數排除，要確保每個排除都有業務事實；只納入一部分並大量使用自訂控制措施，彈性最大，但每一項自訂控制措施都要在 SoA 裡出現（見下一節第六個錯誤）。

排除控制項的理由怎麼寫才算合理（可接受寫法與錯誤對照）

排除理由是 SoA 最常被挑剔的一欄，因為它最容易寫成一句沒有內容的話。可接受的寫法可以整理成三類，來源是稽核實務指引（ISO/IEC 27007:2017 附錄 A 表 A2，經驗證人員指引轉引，屬二手·驗證人員指引；以下為內容整理，不加引號）：

• 該控制措施所對應的活動，組織並沒有從事。 例如組織沒有自己的機房、沒有承作專案、沒有遠端連線作業。
• 組織用自訂控制措施取代，使原控制措施不再需要。 原本要靠附錄 A 那一項達成的事，已經由另一個做法完整承接。
• 組織用目的相同的自訂控制措施。 目的相同、做法不同，屬於替代而非消失。

還有第四類，來自委員會文件對「排除」的定義：依組織業務情境判定為不必要。被排除的附錄 A 控制措施，理由欄要寫出是哪一個業務事實讓它不必要。這一類最容易寫壞，因為「業務情境」四個字可以裝任何東西，所以唯一的檢驗點是：你必須說出是哪一個業務事實。原文：the justification for any Annex A controls that are excluded, i.e., are determined as being unnecessary according to the organization’s business context.（ISO/IEC JTC 1/SC 27 工作組公開文件，未經 ISO 背書）

放進實際句子裡，差異就很明顯：

#	錯誤寫法	為什麼不行	可用的寫法
1	「本公司無此風險」	沒有指出是哪一項風險被處理掉、用什麼處理，等於沒有理由	「本公司無自建機房，全部系統位於供應商雲端機房，故實體環境控制由供應商執行；本公司以供應商管理相關控制措施承接，殘餘風險列於風險登錄表第 X 項並由風險所有者接受」
2	「不需要」「不適用」「與本公司無關」	這三個詞都是結論，不是理由；稽核員無法從中查證任何事實	「本公司未承作專案型業務，無專案活動可對應，故此項排除；此一事實見組織業務說明第 X 段」
3	把「還沒做」寫成「排除」	「排除」與「未實作」在條文裡是兩個不同要素，混用會讓實作進度消失	保留在 SoA 並在「是否已實作」欄寫未實作，同時在風險處理計畫排出完成時間
4	理由欄空白，或 93 列全部貼同一句	納入理由要反映組織情境與風險管理安排，同一句話無法反映任何個別風險	每一列寫出對應的風險項目或風險類別；同性質的可以共用寫法，但要指得出是哪些風險
5	排除後沒有交代由誰承接	風險不會因為你排除一項控制措施就消失	寫明由哪一項控制措施（自訂或其他附錄 A 項目）承接，並指向風險登錄表的對應項目

第一列那個雲端機房的寫法，是顧問實務示範，不是條文。它同時交代三件事：事實（沒有自建機房）、替代（由供應商管理控制措施承接）、殘餘風險歸屬（列在風險登錄表並被接受）。三件事湊齊，一句話就能通過追問；缺任何一件，就會被追問第二次。

還有兩件事要提醒。第一，「還沒做」不是排除理由，它是實作狀態，寫在「是否已實作」欄，並在風險處理計畫裡排工作。這一欄被誤用的頻率很高，因為寫「未實作」在心理上像自曝其短，但把它寫成「排除」的後果更大：那等於宣稱風險不存在。第二，排除理由要能指到風險登錄表的具體項目（顧問實務）。只寫「經風險評鑑後判定無需」，指不出是哪一項風險、哪一次評鑑，等於把理由推給一份沒有被引用的文件。

八個最常被退回的 SoA 寫法，與對應的改法

下面八條不是統計排名。驗證稽核時 SoA 缺失的公開統計，查無。 IAF 的公開文件區與大會決議、TAF 的公開文件與驗證機構名錄、ISO Survey 年報，以及 ISO/IEC 27006-1 附錄 E 的控制措施審查指引，都沒有資訊安全管理系統（Information Security Management System，ISMS）不符合事項的分類統計。文中不提供統計數字、也不給排名，只給八種實務上會直接被退回的寫法，以及依條文與驗證規範推得的檢查點。

#	錯誤	為什麼錯	依據等級	怎麼改
1	只抄附錄 A 目錄，理由欄空白或全寫「依附錄 A」	納入理由必須反映組織情境與風險管理安排，不能只因為它在附錄 A	標準要求（6.1.3 d) 第 2 項）＋委員會文件	每一列補上對應風險；同性質可分組，但要指得出是哪些風險
2	排除只寫「不需要」「不適用」「與本公司無關」	沒有業務事實，等於沒有理由	標準要求（6.1.3 d) 第 4 項）＋二手·驗證人員指引	改成「事實＋替代＋殘餘風險歸屬」三件式
3	把「尚未實作」寫成「排除」	排除與實作狀態是兩個不同要素，混用會讓進度消失	標準要求＋推論	保留該列、狀態寫未實作、工作排入風險處理計畫
4	SoA 與風險評鑑對不上，從風險抽樣追不到控制措施	SoA 應由風險處理導出、可被雙向抽樣核對	二手·驗證人員指引	加「對應風險」欄，或在風險登錄表回填控制措施編號，兩邊互相指得過去
5	先做落差分析就直接產出 SoA（順序反了）	SoA 是風險處理的產出，不是現況勾表；落差分析只回答「現在有什麼」	二手·驗證人員指引＋推論	回到 6.1.2 完成風險評鑑，再走 a) 到 d) 的順序重做一次
6	自訂控制措施沒寫進 SoA	必要控制措施不限附錄 A，用了就要列；不列就不在 SoA 的範圍裡	委員會文件＋官方（TAF-MS-IC01 9.1.1.2 註）	把自訂控制措施獨立編號（例如 C-01 起）並寫納入理由
7	沒有版本，或範圍改了 SoA 沒改	稽核報告要引述 SoA 版本；控制措施範疇變動時驗證文件要更新	官方（TAF-MS-IC01 9.4.3.1 b)、9.6.2.3）	建立版本號、日期、核准人與變更紀錄，範圍變更時同步改 SoA
8	範圍寫整家公司（含關係企業、海外廠），實際只做一個機房與辦公室	風險評鑑與處理要反映驗證範圍所定義的活動邊界，並反映在 SoA	官方（TAF-MS-IC01 9.1.3.6）＋推論	先把範圍縮到實際管得到的活動，再據此寫風險評鑑與 SoA

第 4 與第 5 條要一起看，它們是同一個觀念的兩面。驗證人員指引有一句話把這件事講得很清楚（二手·驗證人員指引，以下為內容轉述，不加引號）：SoA 只是風險登錄表的萃取；SoA 不該在風險登錄表完成前產出，也不該是初步落差分析的結果。落差分析回答的是「附錄 A 的 93 項我們現在有幾項」，這個問題本身沒有錯，但它是一份現況清單，不是風險處理的決定。把它當 SoA 交出去，等於用「現在有什麼」代替「為了風險決定做什麼」。

沒有統計，檢查點就只能從條文與驗證規範推。以下六個必檢點都是推論，來源是要求事項與驗證機構規範，不是觀察到的統計數字：

1. SoA 是否含齊四項內容（6.1.3 d)）：隨手抽三列，能不能同時回答「為什麼納入、是否已實作、對應哪個風險」。
2. 是否留有「與附錄 A 比較、確認未遺漏」的證據（6.1.3 c)；TAF-MS-IC01 8.2.3 a)）。這一步常常做了但沒留紀錄。
3. 每一筆排除是否有可查證的業務事實（6.1.3 d)；稽核實務指引的三類範例）。
4. 是否取得風險所有者對風險處理計畫的核准與對殘餘風險的接受（6.1.3 f)）。
5. SoA 版本是否可被引述、是否隨控制措施變更而更新（TAF-MS-IC01 9.4.3.1 b)、9.6.2.3）。
6. SoA 是否與驗證範圍一致（TAF-MS-IC01 9.1.3.6）。

另外，網路上常被引用的量化研究是東吳大學 2014 年的一篇碩士論文，以發現事項統計政府機關與金融機構的缺失類別。它只能當背景，不能當 2022 版的統計引用，因為它用的是 ISO 27001:2005 的控制領域分類，與 2022 版附錄 A 的四個主題無法對應。看到有人拿 2005 年版的分類講現在的缺失排名，先問一句「這是哪一版的分類」。

如果你正在挑驗證機構或輔導顧問，這八條也可以反過來當面試題：問對方「你們看過最常見的 SoA 問題是什麼、怎麼改」。答得出具體寫法的，通常真的審過件。挑選時該問的問題，〈ISO 27001 顧問與驗證機構怎麼選？12 個企業最常問的問題〉有整理。

先做 SoA 還是先做風險評鑑

順序不只是行政流程問題，它決定 SoA 能不能被追問。完整的順序是：

順序	動作	條號	這一步留下什麼
1	界定資訊安全管理系統（ISMS）範圍	4.3	範圍文件：哪些活動、系統、地點、介面在範圍內
2	資訊安全風險評鑑	6.1.2	風險評鑑紀錄：準則、辨識、分析、評估與優先序
3	選定風險處理選項	6.1.3 a)	每一項風險打算採哪一種處理方式
4	決定必要控制措施（可自設計或任何來源）	6.1.3 b)	必要控制措施清單，不限附錄 A
5	與附錄 A 對照，確認沒有漏掉必要控制措施	6.1.3 c)	對照的證據（誰比、比了什麼、結論）
6	產出適用性聲明	6.1.3 d)	SoA 本體（四項內容）
7	制定風險處理計畫	6.1.3 e)	工作項目、負責人、完成時間、如何達成接受準則
8	風險所有者核准風險處理計畫、接受殘餘風險	6.1.3 f)	核准與接受的紀錄
9	實作風險處理計畫	8.3	實作結果的文件化資訊
10	監控、內部稽核、管理審查；有變更時回頭更新	9.1、9.2、9.3	監控紀錄、稽核報告、審查紀錄

第 2 與第 9 步在執行期會再走一次：驗證人員指引把 8.2 與 8.3 描述為 6.1.2 與 6.1.3 在執行期的再次執行（二手·驗證人員指引）。這件事對 SoA 的直接後果是：每次週期性重評，SoA 都可能被改寫，版本欄因此不是裝飾。

反過來做，最常見的有兩種。第一種是先有 SoA、後補風險評鑑：納入理由只能寫成「依附錄 A」或「業界慣例」，因為還沒有風險可以對應；等風險評鑑補上，兩邊的項目對不起來，於是出現「SoA 有這一列、風險登錄表沒有這項風險」。第二種是用落差分析代替風險處理：把現況有什麼列一列，缺的標紅，SoA 就成了待辦清單，而不是決定書。兩者的共同症狀都一樣：從風險抽樣追不到控制措施。

順序之外還有三條回饋關係要留住，它們決定 SoA 什麼時候該改：

• 週期性重評：8.2 與 8.3 在執行期再走一次，風險變了、處理方式變了，SoA 跟著改。
• 殘餘風險被否決：風險所有者不接受殘餘風險時，要回頭改處理選項或加控制措施（6.1.3 a) 到 d)），SoA 也要改（此為推論）。
• 範圍或活動邊界變更：範圍一改，風險評鑑與 SoA 都要改；驗證機構規範要求風險評鑑與處理要反映驗證範圍所定義的活動邊界，並確認反映在 ISMS 與適用性聲明中（TAF-MS-IC01 9.1.3.6）。

最後畫一條界線：風險評鑑的方法、情境怎麼設計、可能性與後果怎麼分級、風險準則怎麼定、殘餘風險的完整做法，屬另一篇的範圍。 文中只處理 SoA 與風險評鑑的介面，也就是 SoA 從風險評鑑的哪裡接過來、接到哪一欄、什麼時候要跟著改。把方法論塞進這一篇，反而會讓讀者找不到 SoA 該怎麼寫。

ISMS 範圍寫太寬或太窄，SoA 要付什麼代價

範圍是 SoA 的上游，也是最容易被當成「填一格就好」的那一格。這一格寫錯，SoA 的問題不在文筆，在方向。

情況	對 SoA 的具體後果	依據
範圍寫太寬（把關係企業、海外廠、未實際管理的雲端環境都寫進驗證範圍）	這些活動的風險都要進風險評鑑，控制措施都要進 SoA，而且每一項都要有實作證據。只要有一塊實際上沒做，那一列就從「已實作」變成「必要控制措施未實作」，或讓排除理由站不住，直接被開不符合。	推論（由驗證範圍與 8.3 實作要求推得）
範圍寫太窄（只寫一個機房或一個系統，實際上有其他系統在處理同一批資料）	範圍外的系統不會出現在 SoA，但驗證機構仍會要求「不完全在範圍內的服務或活動介面」納入驗證事項與風險評鑑；介面漏寫就會被打回，因為風險從介面進來，SoA 裡卻沒有任何一列在管它。	官方（TAF-MS-IC01 9.1.3.6）
範圍寫得剛好	SoA 的控制措施集合＝範圍內活動的風險處理結果；跨界的介面另外用控制措施或說明處理，必要時在 SoA 的範圍說明裡點出來。	推論

第二列引的那段要求，逐字是：「驗證機構應確保不完全在 ISMS 範圍內的服務或活動介面，均已納入 ISMS 驗證事項中，且納入客戶之資訊安全風險評鑑。例：與其他組織共用的設施(例如，IT 系統、資料庫及電信系統，或營運功能委外)。」（TAF-MS-IC01 9.1.3.6）

這段話解釋了為什麼「範圍縮小」解決不了問題。很多企業第一次寫範圍，直覺是把範圍縮到「我們真的做得到的地方」，以為這樣 SoA 就變薄、稽核就變輕鬆。但介面條款要求把「不完全在範圍內」的服務與活動介面也納進來評，共用機房、共用資料庫、委外營運都是典型例子。範圍可以窄，介面不能漏。漏了介面，等於把最大的風險來源留在門外。

範圍寫太寬的代價是另一種：SoA 變成一本誰都無法維護的目錄。最常見的觸發點是「反正都寫進去比較安全」，把關係企業、海外據點、集團共用系統全部寫進驗證範圍。當下感覺是加分，實際上每一個寫進去的活動都變成一列要拿出證據的控制措施。三個月後，要嘛補文件補到癱，要嘛在稽核現場承認某一塊還沒做。

可操作的動作只有一句：先定範圍，再寫風險評鑑，再由風險導出 SoA。 順序顛倒過來（先寫 SoA、再回頭定範圍），你會發現範圍一改，SoA 要重做一半。定範圍時把它當成一個要對外解釋的句子來寫：「我們把哪些活動、哪些系統、哪些地點納入，哪些不納入，理由是」。寫得出來，SoA 的邊界就寫得出來。

SoA 的版本、核准，與改版後要不要通知驗證機構

版本控制是必要的，理由不是「文件管理習慣」，是驗證制度直接要求。驗證機構規範把「引述適合性聲明之版本」列為稽核報告應包含的事項（TAF-MS-IC01 9.4.3.1 b)）。沒有版本，就無法被引述；無法被引述，稽核報告就寫不出你當天交的是哪一版。

核准鏈的部分，條文明文指定的是風險處理計畫與殘餘風險：由風險所有者核准風險處理計畫、接受殘餘風險（6.1.3 f)，條文轉引）。SoA 本身的簽核人，實務上多由管理代表或資訊安全負責人簽核（顧問實務），文件上建議同時留下核准人與日期。不是為了好看，是為了被問「這一版是誰決定的」時答得出來。

至於「改了要不要通知驗證機構」，沒有單一答案，要分兩種情況。只改文字、沒有涉及驗證範圍內控制措施範疇的更動：驗證機構規範的註寫得很清楚，「更改適用性聲明時，若沒有涉及驗證範圍內控制措施之範疇的更動，則無須更新驗證文件。」（TAF-MS-IC01 8.2.2 註）版本仍要更新、變更紀錄仍要留，驗證文件不必跟著換。控制措施範疇有變動（新增或刪除控制措施、範圍調整導致控制措施集合改變）：驗證文件需要更新（TAF-MS-IC01 9.6.2.3 就控制措施範疇變動時的驗證文件更新有要求），實務上應主動與驗證機構確認後續安排（此段為推論加上官方依據，具體程序依各機構規定）。

把這件事做成日常，只需要四個欄位（顧問實務）：版本號、日期、核准人、變更紀錄。變更紀錄不必寫成公文，一行一句就夠：「2026-03-15 v1.2：新增 A.8.16 監控活動，對應風險 R-07；範圍未變」。這一行同時回答了三個問題：改了什麼、為什麼改、有沒有動到範圍。

還有一個實務上的小陷阱：很多人把 SoA 的版本與 ISMS 文件的版本混在一起。SoA 的版本要能獨立被引述（前面說的合併條件），所以即使它放在一份大文件裡，也要有自己的版本標記，不能只靠整份文件的版次。

台灣這一邊：CNS 27001、資通安全管理法、政府標案

CNS 27001 是我國依同一套要求事項轉訂的國家標準。國家標準查詢系統上的官方欄位，標準名稱逐字是「資訊安全、網宇安全及隱私保護－資訊安全管理系統－要求事項」，適用範圍逐字含「當組織宣稱符合本標準時，不得排除本標準第4節至第10節所規定之任何要求事項。」

可以寫的是這一句：CNS 27001 的英文名稱與適用範圍敘述與 ISO/IEC 27001 一致，SoA 的要求隨這套要求事項適用。不能寫的是「CNS 27001 的條文與 ISO/IEC 27001 一字不差」，或「CNS 也有 6.1.3 d) 這一條」。CNS 全文為計費下載，本次未取得條文，CNS 條文內是否也有這一段，查無。 要確認請向發證機構或標準主管機關查證，不要用推測填空。

資通安全管理法的現行條文修正日期為民國 114 年 9 月 24 日，全文 35 條；以全文檢索「適用性聲明」的結果是 0 次。本法未使用「適用性聲明」這個詞。 它要求被納管機關訂定、修正及實施的是「資通安全維護計畫」，並由主管機關稽核實施情形。

維護計畫的必要事項包括：核心業務及其重要性、資通安全政策及目標、資通安全推動組織、專職人力及經費之配置、資通安全長之配置、資通系統之盤點（含核心資通系統與資產）、資通安全風險管理、資通安全防護及控制措施、事件通報應變及演練、情資評估及因應、委外管理措施、人員考核機制、持續精進及績效管理機制（依第 22 條授權訂定之辦法所列）。

這份清單要小心讀：它是「資通安全維護計畫」的內容，不是 SoA 的要求。 兩者的產出主體、依據、格式都不同。把維護計畫的必要事項寫成「法規要求 SoA 要有的內容」，是把兩套制度疊在一起。「法規要求 SoA」「SoA 是法定文件」這兩句都不成立；本法既沒使用這個詞，也沒有要求組織取得 ISO 27001 證書。

政府採購這裡有兩個公開實例，都是單一案件，不是通案規定。第一件是工研院的採購規範書（案號 A522001790），把審閱文件寫成「審閱資通安全法規遵循情形、計畫負責單位之資訊安全規範及現有 ISMS 文件化資訊，包括資安政策、程序書、SOP、範圍書、適用性聲明（SoA）、資產清單、風險評鑑報告等」。第二件是政府電子採購網的招標公告（案號 AH130200，公告日 2024-10-09），要求「依據法令法規及本院需求，完成ISMS文件及適用性聲明之研訂作業」。（兩件均為公開採購文件）

這兩個例子能支撐的結論只有一個：政府機關的採購文件確實會把 SoA 列為要交付或要審閱的文件，SoA 從「驗證用文件」變成「契約交付項目」，有具體例證。它不能支撐「多數標案都要求 SoA」或「沒有 SoA 就不能投標」，查無通案規定，也不能用兩個案子推算。要確認自己手上的案子，最實際的做法是到政府電子採購網以「適用性聲明」「ISMS 文件」檢索招標文件，看文件裡怎麼寫，而不是聽轉述。

適用性聲明 常見問題 FAQ

寫到多細，取決於對方要的是哪一份文件

回到最初的問題：SoA 沒有「標準格式」，只有「標準內容」。四項內容寫得出來、每一列追得回風險、排除理由指得出業務事實，這份 SoA 就站得住。表格再漂亮、欄位再多，只要從風險抽樣追不到控制措施，就會在稽核現場被追問到底。

動筆之前的順序是：先把範圍定成一句能對外解釋的話，完成風險評鑑，決定必要控制措施，與附錄 A 對照，再產出 SoA，最後才是風險處理計畫與核准。把這個順序反過來，你會花更多時間改文件。實務上還有一個更前面的問題值得先問清楚：對方要的是 SoA 本身，還是包含 SoA 在內的一整套 ISMS 文件？〈ISO 輔導顧問怎麼選？6 項判斷依據與 3 個常見誤判〉整理了該問的問題。

驪鑫做的是 ISO 輔導：輔導為主、可協助企業走完驗證流程，服務範圍為全台，北中南皆有據點，可就近安排或到廠；我們不發證，判定與發證由驗證機構為之。

下一步｜與我們聯絡

不確定企業是否需要導入 ISO，或想了解輔導範圍、費用與時程？

歡迎先與我們聯繫，先了解您的需求與現況，再依實際情況安排電話討論、線上會議或到廠訪談。

全台皆可洽詢，北、中、南均提供 ISO 輔導服務。

聯絡方式

• 免付費專線：0800-695-996
• 各區電話：台北 02-6604-4178｜台中 04-2327-0352｜高雄 07-334-2260
• LINE 官方帳號：@zgs9595e
• 線上表單：與我們聯絡

延伸閱讀

• 多系統整合轉版與整合稽核安排
• ISO 證書可以用買的嗎？4 個風險與實際後果
• ISO 顧問輔導費用怎麼算？5 個影響因素

參考資料

本篇引用的官方文件與查詢入口（查閱日 2026-11-04）：

• ISO/IEC 27001:2022：標準頁
• ISO/IEC 27007:2017（稽核指引）：標準頁
• ISO/IEC 27006-1:2024（驗證機構要求）：ISO 標準查詢入口
• ISO 官方驗證說明：iso.org/certification
• 資通安全管理法：全國法規資料庫
• CNS 27001（CNS 線上服務）：cnsonline.com.tw