ISO 27001 條文與文件清單：四階文件怎麼對照

你手上如果已經有一份「一階手冊、二階程序書、三階作業指導書、四階表單紀錄」的清單，先記住一句：四階文件不是 ISO 27001 的規定，它是顧問與教材談「文件要分幾層」時的溝通用語。國際標準化組織與國際電工委員會共同發布的 ISO/IEC 27001:2022，從頭到尾只用一個詞在管文件——文件化資訊（documented information）。標準要求的是「哪些文件化資訊必須存在、必須被管制」，至於分幾階、叫什麼名字、總共幾份，條文沒有規定。

這篇寫給正在準備導入、手邊已經拿到顧問清單的企業主與管理代表。你的三個疑問，文中逐條回答：這四階是標準規定還是顧問習慣、不照四階會不會被開缺失、條文真正要求「一定要留下」的有哪幾份。做法是把條文翻成一張 18 列的對照表，每列標「必要」或「建議」，判斷依據是條文的動詞，不是文件名稱。資訊安全管理系統（Information Security Management System，ISMS）在你的公司裡要用幾份文件、什麼形式呈現，由你決定；但適用性聲明（Statement of Applicability，SoA）與風險評鑑結果這兩份是條文明列的必要產出，缺了就不是「精簡」，是「沒做」。風險評鑑講的風險，看的是機密性、完整性、可用性（Confidentiality、Integrity、Availability，CIA）三個面向，後面的表格會用到這個詞。

看完你會拿到三樣東西：一份可以勾選的最小必要文件集（14 項，依條文推出）、一套把「四階」對回條文的對照方式、以及七種最常見的做錯方式與改法。條文 4–10 章的完整教學、SoA 怎麼逐項填、風險評鑑怎麼做、27001 與 9001 怎麼整合，站上其他頁面各有專篇，文中不重複，需要時在文末導過去。

文中提到條文時一律寫「ISO 27001 ＋條號」，例如 ISO 27001 6.1.3；提到品質標準時寫「ISO 9001 4.2.2」。這個寫法有實際作用：兩份標準有大量同號條文，只寫「6.1.3」，三個月後你自己都分不出是哪一份。標準文中是付費內容，文中不做逐字引用，只寫條號與要求重點。

先分清「條文要求」與「顧問習慣」：兩種清單不要混著用

一句話切開：條文清單回答「標準要求什麼」，文件清單回答「我要準備什麼、準備到什麼程度」。前者看的是 shall 出現在哪裡、後面接的是什麼；後者是把前者翻譯成你公司做得出來的文件與紀錄。兩張清單各有用途，混著用就會出事：拿顧問的文件清單去推論標準要求，會把「慣例」當「義務」；拿條文清單直接當交付清單，會漏掉「內容要寫到什麼程度」，於是有文件、沒內容。

先確認版本。ISO/IEC 27001:2022 是第 3 版，2022 年 10 月發布，之後另有一個修訂案 Amd 1:2024。iso.org 標準頁對它的定位只有一句：「ISO/IEC 27001 is the world’s best-known standard for information security management systems (ISMS).」這句話不含任何文件層級的要求，它只是告訴你這是什麼標準。

真正管文件的地方只有一個詞。條款 4–10 與 Annex A 的標題裡，沒有「品質手冊」「文件化程序」「作業指導書」這三個名詞被當成要求項目；整份標準用的是 documented information，中文一般譯「文件化資訊」。你在顧問清單上看到的「一階、二階、三階」，在標準裡找不到對應的層級用語。

那個詞的範圍怎麼劃？ISO 27001 7.5.1 只要求兩類：(a) 標準明列要求的文件化資訊、(b) 組織自行判定為 ISMS 有效性所必要的文件化資訊。第二類的份數與形式由組織決定。這句話是整篇的關鍵：它把「要不要多做」的裁量權交給你，同時也代表你不能用「標準沒要求」當藉口，把第一類一起省掉。

這裡只建立判讀框架，不給清單，清單在後面「條文→必要文件對照表」一節。先有一個觀念就夠：條文要求什麼，跟你的顧問習慣用幾階來交付，是兩件事；分清楚之後，你才有辦法判斷手上的清單哪一項是「非做不可」、哪一項是「這樣做比較好溝通」。

「四階文件」是誰規定的？分三層講清楚

「誰規定的」要拆成三層問，因為三層的答案不一樣，混在一起講就變成各說各話。三層是：標準文中、驗證機構、國際指引與教材。

可能的來源	成立嗎	依據
ISO 27001 標準文中的用語	不成立	條款 4–10 與 7.5 子條款只有 documented information；目錄中沒有「四階」「階層」「手冊」這類層級用語
驗證機構的要求	查無官方依據	查過 iso.org、BSI、Intertek、ANAB 的公開資料與國內認證機構的公開文件索引，沒有找到任何驗證機構把「四階文件」寫成 27001 的驗證要求
國際指引的「典型階層」	成立，但已被取代	ISO/TR 10013:2001 的 Annex A 標題為「Typical hierarchy of QMS documentation」（品質管理系統 Quality Management System，QMS；依官方預覽目錄），列品質手冊、文件化程序、工作指導書、表單、外部文件、紀錄
台灣顧問與教材的慣用語	成立（華語圈命名）	「一階手冊、二階程序書、三階作業指導書、四階表單紀錄」這套中文命名與分階邏輯，見衛福部食藥署公開簡報《ISO 9001與四階文件架構》

表格第二列要補一句說明：「查無」不等於「一定沒有」。查無的意思是，在公開可取得的資料裡找不到把四階文件寫成驗證要求的文件；個別驗證機構有沒有內部的習慣做法，誰都不能替你斷言。真要確認只有兩條路：把你的合約、該機構的公開要求拿出來對，或直接問你的稽核員。

接下來三個事實要一起看，只看其中一個就會寫錯。

第一，源頭是品質管理的指引，不是資訊安全標準。ISO/TR 10013:2001 的適用對象是 ISO 9000 族，也就是品質管理系統；它的前言寫得清楚：這份技術報告的指引「不是要用來作為契約、法規或驗證目的的要求」（依 ISO/TR 10013:2001 前言法文版原文自譯）。這份文件自己就聲明了它不是驗證要求——而它正是「四階」這個說法的出處。

第二，ISO 自己在 2021 年把「階層」拿掉了。ISO 10013:2021 取代 ISO/TR 10013:2001，ISO 技術委員會的新聞稿第一句就是「This document replaces ISO/TR 10013:2001.」，並接著說明「ISO 10013 no longer prescribes a particular hierarchy but reflects the ability of electronic media to organize itself in a multitude of ways.」）

第三，同一份新聞稿也說手冊非必須、但可以有用。原文是「While a quality manual is not required, it can still be useful, and many sector-specific standards still require “quality manuals and documented procedures”.」（同上）這句話同時解釋了為什麼業界還在講四階：部分產業別方案仍然要求手冊與程序書，那是方案的要求，不是 ISO 27001 的要求。

三個事實合起來，答案是這樣：「四階文件」不是 ISO 27001 的規定；它是一套已經被取消的品質管理指引架構，被華語圈的顧問與教材沿用下來，成為一種好用的溝通座標。寫作紀律也要一起講清楚：不能寫成「四階是標準要求」，也不能反過來寫成「四階已經不能用了」。ISO 的新聞稿自己說手冊「can still be useful」——標準不要求，不等於禁止你用。

ISO 10013 在 2021 年為什麼把「階層」拿掉

版本關係先確認：ISO 10013:2021《品質管理系統—文件化資訊指引》取代 ISO/TR 10013:2001。官方新聞稿寫的是「This document replaces ISO/TR 10013:2001.」（ISO 技術委員會新聞稿（2021））

為什麼拿掉階層？官方原話是「ISO 10013 no longer prescribes a particular hierarchy but reflects the ability of electronic media to organize itself in a multitude of ways.」——也就是說，ISO 10013:2021 不再規定階層，改為反映電子媒體可以用很多種方式組織自己。

這句話的實務含意不難懂。2001 年的時候，文件多半是紙本，紙本必須分層，因為你要決定「這張紙放進哪一個資料夾」；一個資料夾裝不下跨部門的流程，所以要有手冊、程序書、作業指導書的分工。現在你的文件可能是一頁 Wiki、一個系統模組、一個雲端文件庫裡的資料夾；同一段內容可以同時被三個地方引用，搜尋取代了翻資料夾。層級不再是判準，內容與可追溯性才是。

但界線要寫清楚：這是品質管理的指引，屬於 ISO 9000 族，不是 ISO 27001 的條文。文中引用它，是為了解釋「四階」這個說法的來源與它現在的地位，不是說 ISO 27001 採用它、也不是說 27001 因為它改變了什麼。ISO 27001 的立場是自己那句話：只用 documented information 一個詞，只分兩類來源。所以不要寫「ISO 10013 是 ISO 27001 的規定」——那句話把兩份不同家族文件的關係講反了，也是文中最容易被退稿的一句。

ISO 9001 的歷史：2008 有手冊、2015 移除、2026 沒恢復

你會拿到四階清單，跟年份有關。多數「四階文件」教材成形於 ISO 9001:2008 的年代，那時候手冊是明文要求。版本變化是這樣：

版本	是否明文要求品質手冊	依據
ISO 9001:2008（含更早版本）	是。4.2.2 要求組織建立並維持品質手冊；同期條文另有多份「文件化程序」的要求	驗證機構 DQS 知識頁（2022-03-08）指出 2008 版仍在 4.2.2 明文要求建立與維持手冊；二手轉述，標準文中未取得
ISO 9001:2015	否。改為文件化資訊，手冊要求移除	同上；ISO 技術委員會 2021 年新聞稿已用現在式寫「a quality manual is not required」
ISO 9001:2026（現行版）	仍未要求	2015 版已被 2026 版取代（官方頁面引句見下）；「2015 移除、2026 未恢復」屬多來源一致的二手說法，2026 版全文本輪未取得

版本現況用官方頁面確認最快：iso.org 對 2015 版的說明是「This current edition has now been withdrawn and replaced by ISO 9001:2026.」所以現在沒有「等 9001 改版再說」這件事，2015 版已經是撤銷狀態。

為什麼要花一段講 9001？因為你手上那份清單的年份來源就是這裡。2008 年版把品質手冊寫成必要文件，教材於是把「手冊」當成第一階的固定成員；2015 年改成文件化資訊之後，手冊在條文裡消失，但教材沒有跟著改，於是這套說法一路留到今天。知道這段歷史，你就能理解為什麼顧問給的清單長那樣，而不必把整份清單當成義務。

兩條禁令要守住：不要把 9001 的現況寫成「手冊還是必要文件」；也不要寫 2026 版的條文文字，因為本輪沒有取得 2026 版全文，只能確認版本狀態與多方一致的二手說法。

還有一件事先講清楚：只寫版本與手冊要求的歷史，不寫 ISO 9001 的文件清單本身。9001 的清單與精簡判準，站上另有專頁，文中在講最小必要集時會把連結放過去。

條文 → 必要文件對照表（18 列）

這張表是文中主體。左邊是條文，右邊是「你要準備什麼、內容至少寫到哪裡」，中間那一欄是判定。之所以要標判定，是因為兩種誤判都很常見：把「建議」當「必要」，力氣花在錯的地方；把「必要」當「建議」，結果 SoA 沒做、風險評鑑結果沒留日期與範圍。

表格拆成兩張：先列必要，再列建議。第 3 列之後會出現 CIA，指的是前面說過的機密性、完整性、可用性三面。

#	條文	要求主題	必要或建議	文件或紀錄名稱	內容至少要寫什麼	依據（shall 關鍵詞）
1	ISO 27001 4.3	ISMS 範圍	必要	ISMS 範圍說明書	邊界與適用性；ISO 27001 4.1 內外部議題與 4.2 利害關係人需求的取捨；組織活動、服務、委外、地點；排除項與排除理由	shall be available as documented information（4.3）
2	ISO 27001 5.2	資訊安全政策	必要	資訊安全政策	三項承諾（滿足要求、持續改善、融入流程）、目標框架、適用範圍、核准與日期	shall be available as documented information（5.2）
3	ISO 27001 6.1.2	風險評鑑流程	必要	風險評鑑方法與準則（可獨立成程序，也可寫在風險管理辦法內）	風險準則與接受準則；CIA 三面；風險擁有者指派規則；分析與評估方法；可重現、可比較	shall retain documented information about the process（6.1.2）
4	ISO 27001 6.1.2	風險評鑑結果（規劃面）	必要	風險清單／評鑑結果表	風險描述、影響、可能性、等級、擁有者、對應的資產或流程	同上（流程含結果），並與 ISO 27001 8.2 的結果對應
5	ISO 27001 6.1.3	適用性聲明	必要	SoA（獨立於手冊之外）	Annex A 93 項逐項：是否納入、納入理由、是否已實施、排除理由	produce a Statement of Applicability（6.1.3）
6	ISO 27001 6.1.3	風險處理計畫	必要	風險處理計畫	選定處理選項、對應控制措施、負責人、期程、殘餘風險與風險擁有者核准	shall retain documented information（6.1.3）
7	ISO 27001 6.2	資訊安全目標	必要	目標與達成計畫	目標值、量測方式、負責人、完成時點、資源、如何評估結果；與政策一致	be available as documented information ＋ shall retain documented information（6.2）
8	ISO 27001 7.2	能力	必要	訓練與能力紀錄	能力需求、學經歷與訓練、成效評估、職務對應	retain appropriate documented information as evidence of competence（7.2）
9	ISO 27001 7.5.1–7.5.3	文件化資訊的管制機制	必要	文件與紀錄管制規則＋文件總清單	識別（名稱、日期、作者、編號）、格式與媒體、審查與核准；分發、存取、取用、儲存與保存（含可讀性）、版本變更、保存與處置、作廢管制、外部來源文件	shall be controlled／shall address the following activities（7.5.3）
10	ISO 27001 8.1	運作規劃與控制	必要	作業流程文件與營運紀錄（例如備份、權限異動、機房進出）	流程準則、控制方式、委外或外部提供流程的控制、變更的控制	Documented information shall be available to the extent necessary（8.1）
11	ISO 27001 8.2	風險評鑑（執行）	必要	風險評鑑報告（含日期與範圍）	評鑑期間、重大變更觸發、結果與等級、參與人員	shall retain documented information of the results（8.2）
12	ISO 27001 8.3	風險處理（執行）	必要	風險處理執行結果紀錄	已實施控制、實施證據、有效性檢視、更新後的殘餘風險	shall retain documented information of the results（8.3）
13	ISO 27001 9.1	監控與量測	必要	監控與量測結果	指標定義、方法、時機、負責人、結果與分析結論	Documented information shall be available as evidence of the results（9.1）
14	ISO 27001 9.2.1–9.2.2	內部稽核	必要	稽核方案＋稽核紀錄（計畫、查檢表、報告、不符合單）	頻率、範圍、準則、稽核員客觀性、結果與報告對象	retain documented information as evidence of the audit programme and the audit results（9.2.2）
15	ISO 27001 9.3.1–9.3.3	管理審查	必要	管理審查會議紀錄	ISO 27001 9.3.2 的全部輸入（前次決議、內外部變化、績效趨勢、利害關係人回饋、風險評鑑結果與處理進度、改善機會）＋決議與變更需求	Documented information shall be available as evidence of the results（9.3）
16	ISO 27001 10.2	不符合與矯正	必要	不符合與矯正措施紀錄	不符合性質、後續行動、原因分析、相似不符合的確認、有效性檢視	Documented information shall be available as evidence of the results（10.2）

再來是建議的兩列。它們不是「不用做」，而是「條文要求你做到，但留不留文件、留成什麼形式，由你判斷」：

#	條文	要求主題	必要或建議	文件或紀錄名稱	內容至少要寫什麼	依據（shall 關鍵詞）
17	ISO 27001 5.3	角色、職責與職權	建議	職責矩陣／組織圖／ISMS 角色說明	誰確保 ISMS 符合標準、誰向高層報告績效	條文只要求 assigned and communicated，沒有文件化字樣（5.3）
18	ISO 27001 4.1／4.2／6.3／7.3／7.4	脈絡、利害關係人、變更規劃、意識、溝通	建議	脈絡分析表、利害關係人清單、變更評估單、宣導紀錄、溝通矩陣	依組織需要；這些多半是 ISO 27001 4.3 與 6.1 的輸入	各條有 shall，但沒有文件化字樣

地圖指定的五項，在這裡全數覆蓋：範圍是第 1 列（ISO 27001 4.3）、政策是第 2 列（ISO 27001 5.2）、SoA 是第 5 列（ISO 27001 6.1.3）、風險評鑑報告在第 3、4、11 列（ISO 27001 6.1.2 與 8.2）、紀錄在第 9、13、14、15、16 列（ISO 27001 7.5.3、9.1、9.2、9.3、10.2）。

第 1 列的依據是全篇唯一可以逐字呈現的條文，因為這一句可以公開核對：「The scope shall be available as documented information.」（依標準條文，經驗證機構公開對照文件轉載）其餘條文一律以條號與重點自述，理由有兩個：標準文中是付費內容，逐字轉貼會踩著作權；而且抄錯一個字，整段的意思就變了。

第 5 列的 SoA 要特別強調一句：它獨立於手冊之外。SoA 不是手冊的附件，也不是風險評鑑報告的一章，它是 ISO 27001 6.1.3 的必要產出，要能逐項對到 Annex A。至於 SoA 的欄位怎麼設計、每一項的理由怎麼寫，屬於另一篇的範圍，文中不展開。

第 10 列的「範圍依風險」也值得一句：ISO 27001 8.1 要求的文件化資訊是「在足以確信流程依規劃執行的範圍內」可取得，不是「所有作業都要寫成文件」。備份、權限異動這種高風險流程，值得有一份寫清楚準則的文件；打掃廁所不需要。

怎麼判斷「必要」還是「建議」：看動詞不看名詞

規則可以寫成表格，三行就講完：

判定	條文長什麼樣	你要做什麼	例子（條號）
必要	shall ＋ documented information／retain documented information／available as documented information／produce（例如 SoA）／Documented information shall be available as evidence of	文件必須存在，內容要被管制，稽核會要	ISO 27001 4.3、5.2、6.1.2、6.1.3、6.2、7.2、7.5、8.1、8.2、8.3、9.1、9.2、9.3、10.2
建議	有 shall，但沒有文件化字樣（要求的是「做」，不是「留文件」）；或屬 ISO 27001 7.5.1 (b) 由組織自行判定必要性	事情必須做到，但留不留文件、留成什麼形式，由你判斷	ISO 27001 4.1、4.2、5.3、6.1.1、6.3、7.1、7.3、7.4、10.1
Annex A 衍生（條件式必要）	該控制項經 SoA 納入，且控制項陳述本身要求文件或紀錄	納入才要；未納入不強制	A.5.9、A.5.26、A.8.9 等（見「Annex A 會拉出哪些文件」一節）

一句話版：看動詞不看名詞——retain、available as documented information、as evidence of 是必須留下；只有 shall ensure、shall determine 的是必須做到，但留不留文件由你判斷。

為什麼要特別點名「沒有文件化強制語」的條文？因為它們最容易被兩邊誤判：一邊把它們當成必要，於是把每一條都做成一份文件；另一邊把它們當成不用做，於是連職責都沒有人負責。清單是這幾條：ISO 27001 4.1、4.2、4.4、5.1、5.3、6.1.1、6.3、7.1、7.3、7.4、10.1。這些條文要求你「決定」「確保」「指派並溝通」「建立 ISMS」，但沒有要求留下一份叫什麼名字的文件。實務上你通常還是會留（例如職責矩陣、宣導紀錄），因為它們是範圍說明書或風險評鑑的輸入；但那是你的判斷，不是條文的強制。

其中一條要單獨說明：ISO 27001 6.3 是 2022 版新增的變更規劃，要求變更以規劃方式執行，但這條沒有文件化字樣，所以列在建議（二手轉述，多來源一致，標準文中未取得）。

最後一個提醒：這張規則表是依條文用語做的分類，不是驗證機構的判定表。個別稽核員怎麼看你的證據、要不要開觀察或缺失，屬機構裁量；標準不會替你保證結果。

總共要幾份？為什麼標準裡找不到數字

直接回答：沒有答案。條文沒有規定份數，也沒有規定層級。

為什麼找不到？因為 ISO 27001 7.5.1 給的是「來源」不是「數量」：標準明列要求的（第一類）加上組織自己判定為必要的（第二類）。第一類可以用一份文件涵蓋很多條，也可以一條一份；第二類完全由你決定。其餘各條只說「要保留什麼內容」，沒有一條寫「幾份」「幾階」「幾頁」。

所以任何「ISO 27001 要 N 份文件」的說法都沒有條文依據。包含你可能聽過的「要寫幾份程序書」——那是 ISO 9001:2008 時代的舊記憶，當年條文確實列了一串「文件化程序」的要求，後來的版本改成文件化資訊。用 2008 年的份數回答 2022 年的問題，答案一定不對。（這段是依條文用語的推論，不是條文原文）

可操作的做法是這樣：先用上一節的 18 列建立你自己的「必要清單」，每一列填上「我們公司對應哪一份、放在哪裡、誰維護」；填完再看組織規模決定合併方式。人少的公司可以把風險評鑑方法與風險清單放同一份，把文件管制規則與文件總清單放同一份；分工細的公司會拆成多份。兩種都合規，差別在維護成本。

文中不給份數建議，連「大約十到十五份」都不給。給了它就變成另一個沒有依據的數字，而你三個月後會拿它去跟稽核員爭論。

7.5 文件化資訊：建立更新（7.5.2）與管制（7.5.3）差在哪

ISO 27001 7.5 是整份標準裡唯一專門管文件化資訊的條款，裡面有三個子條款：7.5.1 講範圍、7.5.2 講建立與更新、7.5.3 講管制。多數企業只做到 7.5.2，然後在 7.5.3 失分，原因通常是沒分清這兩件事在管什麼。

動作	條號	要求什麼	原文關鍵詞
建立與更新	ISO 27001 7.5.2	三項：識別與描述（標題、日期、作者、文件編號）、格式與媒體（語言、軟體版本、紙本或電子）、審查與核准	shall ensure appropriate
管制（前段）	ISO 27001 7.5.3	兩項：需要時地可用且適合使用；受到適當保護（免於機密性喪失、不當使用、完整性喪失）	shall be controlled
管制（活動）	ISO 27001 7.5.3	五項活動：分發、存取、取用與使用；儲存與保存（含維持可讀性）；變更管制（版本）；保存與處置；外部來源文件	shall address the following activities

一句話區分：7.5.2 管「生出來的時候長什麼樣、誰核准」；7.5.3 管「生出來之後在誰手上、怎麼找、會不會被改、什麼時候銷」。

有一個很常見的錯誤值得單獨講：只做 7.5.2，沒做 7.5.3 的取用與作廢管制。症狀是文件都有版本、都有核准簽核，但現場拿到的是上一版；或是離職同仁的雲端資料夾還開著，存取權沒收。稽核現場「拿到舊版」這件事，對應的是 7.5.3 的取用與版本管制，不是 7.5.2 的核准欄位。反過來說，你的文件如果沒有核准紀錄，那是 7.5.2 的問題。兩種缺失的改法完全不同，先分清才不會改錯地方。

五項活動裡最常被漏掉的是「保存與處置」和「外部來源文件」。前者是「什麼時候銷毀、誰核准銷毀」；後者是法規、客戶提供、雲端服務商的文件——很多公司把它們放在個人的信箱或桌面，沒有進文件總清單，這一項就等於沒做。外部來源文件在後面另有一節。

紀錄要保存多久？標準沒有年限，那要怎麼訂

誠實回答：查無。ISO 27001 沒有規定任何保存年限。條文只要求「保存與處置」這兩件事要被處理（ISO 27001 7.5.3），沒有給年數，也沒有「至少 N 年」這種寫法。

因此如果有人告訴你「依規定要保存幾年」，而那個「規定」指的是 ISO 27001，那就是錯的。查過的來源包括標準目錄、驗證機構公開的條文整理、以及 7.5 條文的公開說明頁，都沒有找到年限規定。這裡的「查無」只代表公開資料裡找不到，不代表你所在行業的其他法規沒有規定——那要看你適用哪一部法規，跟 27001 無關。

那要怎麼訂？這屬於顧問實務，不是條文要求。年限的來源通常是三種：其他法規（公司治理、個人資料、稅務、特定行業管理規則）、客戶合約、組織自己的風險判斷。做法是「組織自訂＋註明依據」：在文件管制規則裡對每一類紀錄寫明起算點（例如事件結案日、稽核報告核准日）、保存期間、期滿的處置方式（銷毀或封存），並附上依據來源。這樣稽核員問「為什麼是這個數字」時，你答得出理由，而不是答「顧問說的」。

文中不出現任何年數當成標準要求，也不建議你抄別家的數字。抄來的數字沒有依據，等到被追問就變成另一個缺失。

「文件」與「紀錄」差在哪？現在只有一個詞

在 2022 版裡，名詞上不是兩個，只有一個：documented information。7.5 的三個子條款一體適用，沒有「文件用一套規則、紀錄用另一套規則」這種設計。

差別在動詞與目的。這張表可以直接放進你的內部教育訓練：

條文動詞	意思	出現的條文	你要做的事
retain … as evidence of	留下來當證據	ISO 27001 9.1、9.2、9.3、10.2（另 7.2 是能力證據）	不能事後改寫；要有日期、範圍、結果
available as documented information	要能取得、要能使用	ISO 27001 4.3、5.2、6.2、8.1	找得到、拿得到、版本對；內容隨現況更新

實務含意是這樣：「紀錄」不是另一套制度，而是「被要求留下當證據的那部分文件化資訊」。所以紀錄「不可事後修改」這個規矩，是從 as evidence of 這個目的推出來的，不是從名詞分類推出來的——你要留下的是「當時發生什麼」，事後覆寫就消滅了這個目的。這一段是依條文用語的推論，條文本身沒有寫「紀錄不能改」這幾個字。

順帶處理一個常見的混淆：不要寫「ISO 27001 把文件與紀錄分成四階」。這句話同時錯在兩件事——標準沒有「四階」，也沒有把文件與紀錄當成兩個分開管制的事物。可以講的是：四階說法裡的第 4 階（表單與紀錄），剛好對到條文裡最硬的那組證據要求（retain、as evidence of）。這是對照，不是標準用語。

外部來源文件（法規、客戶提供、雲端服務商）怎麼納管

條文依據在 7.5.3 的末段：組織判定為 ISMS 規劃與運作所必要的外部來源文件化資訊，必須適當識別並管制。（此段為驗證機構公開條文整理的轉述，標準文中未取得）

關鍵在「組織判定為必要」這幾個字。條文的範圍不是你收到的所有外部文件，而是你判斷為必要的那一些。所以第一步不是「全部收進來」，是「決定哪些必要」。判斷依據通常是三件事：它會影響你的法規遵循、會影響你的控制措施怎麼做、或客戶合約要求你遵守。收到但用不到的行銷型錄，不必進管制。

落地做法（顧問實務，非條文要求）：在你的文件總清單裡給外部文件一組欄位——來源單位、版本或日期、取得方式、內部保管人、更新檢查頻率。這五欄的作用，是讓「這份文件現在是不是最新的」變成一個可以查的問題，而不是靠某個人的記憶。更新檢查頻率特別重要：法規會改、雲端服務商的條款會改，沒有檢查頻率就等於沒有管制。

跟風險的連結：法規類的外部文件通常會連到 ISO 27001 6.1.2 的風險評鑑（法規要求沒跟到，本身就是一種風險），並對到 Annex A 的 A.5.31（法令、法規、契約要求）。這個連法還有一個好處：稽核員問「你怎麼知道法規有沒有變」，你指得出清單與檢查紀錄。

雲端服務商的文件要分兩種看。對方給你的合約、服務水準協議、資安白皮書，屬於你的外部來源文件，因為你要靠它判斷自己承擔了哪些責任；對方自己內部的作業程序，不是你的文件，不必納管。分不清這條線，文件總清單會愈長愈沒人維護。

本節不談供應商管理怎麼做，那是 Annex A 的範圍，跟文件管制是兩件事。

Annex A 會拉出哪些文件？（13 項，不逐條解說 93 項）

先講界線，這段不寫清楚，後面就會被讀成「每一項控制都要有文件」。Annex A 是 normative 的控制措施參考清單，93 項分成四大主題：A.5 組織 37 項、A.6 人員 8 項、A.7 實體 14 項、A.8 技術 34 項。Annex A 本身不會讓任何一項控制變成「一定要做」——必要與否由 ISO 27001 6.1.3 的風險處理決定，並寫進 SoA。

所以下面這張表的讀法是：這些控制項一旦納入，就會要求某種文件或紀錄；沒納入的，不強制。表列 13 項，每項一句話；逐條解說 93 項屬於另一頁的範圍。

#	控制項	名稱	它要求什麼文件或紀錄	依據
1	A.5.1	資訊安全政策與各主題子政策	高層核准、發布、傳達並定期審查的政策文件（含存取控制、密碼、事件、供應者等子政策）	驗證機構公開的強制文件清單（A.5.1 由 5.2 涵蓋）；二手
2	A.5.9	資訊與關聯資產清冊	資產清冊，含擁有者	同上；二手
3	A.5.10	可接受使用規則	員工使用資訊與資產的規範	同上；二手
4	A.5.24	事件管理規劃與準備	事件管理程序與角色分工（通報、分級、處理流程）	驗證機構與顧問公開清單彙整；二手
5	A.5.26	事件回應	事件回應程序與事件處理紀錄	驗證機構公開清單；二手
6	A.5.31	法令與契約要求	法規與契約要求清單（法規登錄表），含更新機制	同上；二手
7	A.5.37	文件化作業程序	給需要者使用的作業程序文件（IT 與營運操作）	同上；二手
8	A.6.2	聘僱條件與角色職責	角色與資安職責定義（職務說明書或聘僱文件中的資安條款）	同上；二手
9	A.6.6	保密協議	保密協議（Non-Disclosure Agreement，NDA）的簽署紀錄	同上；二手
10	A.8.9	組態管理	組態基準與安全設定定義（含基線文件）	同上；二手
11	A.8.15	日誌	使用者活動、例外與安全事件之日誌（保留可查）	同上；二手
12	A.8.27	安全系統架構與工程原則	安全工程原則文件（開發與架構遵循）	同上；二手
13	A.8.32	變更管理	變更管理程序與變更紀錄	驗證機構與顧問公開清單彙整；二手

必寫的那句在這裡：「Annex A 衍生的文件只有在風險或利害關係人要求導致必須實施該控制時，才成為強制。」（驗證機構公開文件的說明，二手）

實務上這句話的意思是：你的風險評鑑如果沒有把「資產沒有清冊」評成風險，客戶也沒有要求你提供資產清冊，那麼 A.5.9 沒納入 SoA，你不會單因為「Annex A 有這一項」而被開缺失。反過來說，一旦納入，資產清冊就是必要文件，內容要能對到擁有者。

93 項的逐條內容、四大主題的分類邏輯、每一項控制措施在問什麼，請看 ISO 27001 Annex A：93 項控制措施與 4 大主題。文中只處理「哪 13 項會拉出文件」。

最小必要文件集 14 項：先合規，再對照四階

把前面的條文對照表收斂成一份可以勾的清單，就是這 14 項。它們是「依條文推出的最小集合」，不是「標準要求 14 份」——同一份文件可以同時滿足好幾項，也可以一項拆成兩份，重點是每一項都有人負責、內容對得上條文。

#	文件或紀錄	條號	為什麼是最小必要（含 shall 關鍵詞）
1	ISMS 範圍說明書	ISO 27001 4.3	shall be available as documented information
2	資訊安全政策	ISO 27001 5.2	shall be available as documented information
3	風險評鑑流程（方法與準則）	ISO 27001 6.1.2	shall retain documented information about the process
4	風險評鑑結果	ISO 27001 6.1.2、8.2	8.2 要求保留結果的文件化資訊
5	SoA	ISO 27001 6.1.3	produce a Statement of Applicability
6	風險處理計畫（含殘餘風險核准）	ISO 27001 6.1.3	6.1.3 流程的產出，並須保留文件化資訊
7	風險處理執行結果	ISO 27001 8.3	shall retain documented information of the results
8	資訊安全目標與達成計畫	ISO 27001 6.2	be available as documented information，並須保留
9	能力與訓練紀錄	ISO 27001 7.2	as evidence of competence
10	文件與紀錄管制規則（含文件清單）	ISO 27001 7.5.1–7.5.3	7.5.3 要求管制並處理各項活動
11	監控與量測結果	ISO 27001 9.1	as evidence of the results
12	內部稽核方案與稽核結果	ISO 27001 9.2.2	as evidence of the audit programme and the audit results
13	管理審查紀錄	ISO 27001 9.3	as evidence of the results
14	不符合與矯正紀錄	ISO 27001 10.2	as evidence of the results

接著把四階對回來。這張表只是溝通用的座標，不是標準要求：

四階說法	對到最小必要集的哪幾項
一階（手冊）	無強制對應；若你保留手冊，通常放第 1、2 項的摘要
二階（程序書）	第 3、10 項（＋依風險納入的事件、存取、供應者等程序）
三階（作業指導書）	無強制對應；A.5.37 納入時才有
四階（表單與紀錄）	第 4、6、7、8、9、11、12、13、14 項（證據層，最不能省）

順序很重要：先建必要清單，再用四階當溝通座標。反過來做（先畫四階架構、再把內容塞進去）的結果，通常是手冊寫得很完整、SoA 卻沒做——因為架構圖裡沒有「SoA 放哪一階」這種問題，它就被漏掉了。

至於哪幾項可以合成一份，判斷標準不是「條號接近」，是維護條件：同一個維護人、同一個更新頻率、同一群讀者，就可以合。風險評鑑方法與風險清單同一個人維護、同一季更新，合成一份合理；政策與文件管制規則的讀者與更新節奏不同，硬合只會讓其中一邊永遠是舊的。

如果你想要一個具體的排法，可以參考下面這個示例架構（示例架構、非客戶案例）：範圍與政策層（範圍說明書、資訊安全政策、可選的 ISMS 手冊或制度總覽）／風險層（風險評鑑方法、風險清單、風險處理計畫、SoA）／運作層（文件與紀錄管制規則、事件管理程序、存取控制規則、供應者管理、備份與維運、變更管理）／證據層（訓練紀錄、監控與量測結果、稽核方案與報告、管理審查紀錄、不符合與矯正紀錄、事件紀錄、日誌）／外部文件層（法規與契約要求清單、供應商與雲端服務文件）。組織可以合併、拆開，或改用 Wiki 與系統模組；層數不是重點。

ISO 9001 的文件清單與精簡判準，站上另有一篇專門處理：ISO 9001 程序書要寫幾份？文件清單、必備紀錄與精簡判準。兩邊的判斷邏輯不同（品質 vs 資訊安全），不要直接把 9001 的清單改名拿來用。

最常見的 7 種做錯方式

這七項是實務上最常看到的，每一項都附「怎麼改」，因為只列錯沒有用。

#	錯在哪	後果	怎麼改	依據
1	把四階文件當成 ISO 27001 的規定，照抄別家公司的架構	力氣花在分層與封面，SoA 與風險評鑑結果反而缺	先用 18 列建立必要清單，再用四階當溝通座標；分層可以簡化	ISO 10013:2021 不再規定階層
2	只做手冊與程序書，沒有風險評鑑報告與 SoA	兩個核心產出不存在，稽核無法追溯「風險→控制」的鏈條	SoA 獨立成一份；風險評鑑結果要有日期與範圍	ISO 27001 6.1.2、6.1.3、8.2
3	有文件但沒有版本或核准紀錄，或拿舊版去稽核	7.5.2 的核准與 7.5.3 的版本管制同時失分；現場與文件不一致	文件總清單加「版本、核准日、失效日」三欄；作廢版下架	ISO 27001 7.5.2、7.5.3
4	文件寫得比實際做法漂亮（照抄範本），現場做法與文件不一致	稽核訪談一問就破，被判定文件化資訊未反映實際運作	先寫「現在怎麼做」，再補「依條文還缺什麼」；寧可短而真	ISO 27001 7.5.1 (b)、8.1
5	把紀錄當文件一起改，導致紀錄失去可追溯性	改了歷史紀錄等於證據鏈斷，as evidence of 的目的消失	紀錄只能新增版本或附加說明，不得覆寫；權限上鎖	ISO 27001 9.1、9.2、9.3、10.2
6	保存期限自己訂一個數字，卻說不出依據	稽核問「為什麼是這個數字」答不出來，對外也變成不實承諾	寫「組織自訂＋依據（法規、合約、風險）」；標準本身無年限	ISO 27001 7.5.3（僅要求處理保存與處置）
7	稽核前才補文件（事後補簽），無法證明執行	日期與其他紀錄互相矛盾，比沒有更糟	用既有系統紀錄（簽核、郵件、工單）當證據；補的是整理，不是補簽	ISO 27001 8.2、9.1

另外補一項不列在主表的（顧問實務）：把 ISO 9001 的文件清單直接改名成 27001 用。兩份標準的對象不同——一個管品質、一個管資訊安全，風險邏輯也不同。改名最快，但改完會發現風險評鑑與 SoA 完全沒有對應，等於重做。

ISO 27001 文件 常見問題 FAQ

結語：先勾 14 項，再決定要不要分階

回到你手上那份清單。它最大的問題不是錯，是沒有標「必要」與「建議」，所以你分不出哪一項不做會被開缺失、哪一項只是顧問交付比較順手。把清單改造成兩欄——左邊條號、右邊「我們公司對應哪一份」——你會發現真正卡住你的不是文件數量，而是幾份核心文件沒有內容：範圍說明書沒寫排除理由、風險評鑑結果沒有日期、SoA 沒有逐項對到 Annex A。

順序建議這樣走：先勾完 14 項最小必要集，缺的補內容；再處理 ISO 27001 7.5 的管制機制（版本、取用、作廢）；最後才決定要不要分階、要不要手冊。四階是溝通座標，不是起跑線；先合規、再對照，你就不會把時間花在封面與編號上。

文中由驪鑫整理。驪鑫是 ISO 輔導顧問公司，輔導為主、可協助企業走完驗證流程，本身不做驗證發證，也不保證任何驗證結果。

如果你不確定手上的清單夠不夠、或想知道顧問與驗證機構怎麼搭配，可以看 ISO 27001 顧問與驗證機構怎麼選？12 個企業最常問的問題，裡面有選商與合作方式的問答。

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

聯絡方式

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

延伸閱讀

• ISO 27001 認證怎麼申請？流程、時程與 6 大好處一次看
• ISO 9001 是什麼？2026 認證流程、費用與導入重點
• ISO 9001 14001 整合轉版｜多系統整合轉版排程與整合稽核安排

參考資料

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

• ISO，〈ISO/IEC 27001:2022 標準頁〉：標準頁
• ISO，〈ISO 9001:2026 標準頁〉：標準頁
• ISO，〈ISO 9001:2015 標準頁〉：標準頁
• ISO，〈ISO 10013:2021 文件化管理系統指引〉：ISO 標準查詢
• ISO，〈ISO 標準查詢入口〉：ISO 標準查詢