Akira ISO 42001 互動式地圖

ISO/IEC 27001 vs 42001 對照總表

ISO/IEC 27001 管的是資訊安全，重點是保護資訊的機密性、完整性與可用性；ISO/IEC 42001 管的是 AI 系統怎麼被負責任地開發、提供與使用，關心的還有公平、透明、安全與對人的影響。兩者都採用 ISO 管理系統共同結構（Harmonized Structure），第 4～10 條的骨架幾乎一樣，所以政策、文件管制、內部稽核、管理審查與矯正措施等流程可以共用一套。42001 多出來的，主要是第 4.1 條要判定組織的 AI 角色、第 6.1.4 與 8.4 條的 AI 系統影響評估，以及一份完全不同的附錄 A（38 項控制，著重 AI 生命週期、資料、透明與第三方）。ISO 沒有發布兩個標準附錄 A 之間的官方對照表，下表的控制對應是依主題整理的參考，實際導入仍要依組織的風險評鑑與適用性聲明決定。

9327001:2022 附錄 A 控制數

3842001:2023 附錄 A 控制數

427001 附錄 A 主題（組織、人員、實體、技術）

942001 附錄 A 控制群組（A.2～A.10）

7兩者共用結構的主條文（第 4～10 條）

242001 獨有的條文（6.1.4、8.4 影響評估）

一、條文 4–10 對照

兩個標準採用相同的管理系統共同結構，條號幾乎一一對應。「相同」表示做法可以直接共用；「擴充」表示骨架相同，但 42001 要多考慮 AI 的內容；「42001 獨有」是 27001 沒有的要求。

條號	27001 要做的事	42001 要做的事	類型	整合時怎麼做
4.1了解組織及其全景	找出會影響 ISMS 成果的內外部議題；依 2024 年 Amd 1 還要判斷氣候變遷是否為相關議題。	同樣找出內外部議題，另外要說明組織開發、提供或使用的 AI 系統打算拿來做什麼，並判定組織扮演哪些 AI 角色。 42001 多了 AI 系統用途與 AI 角色（例如提供者、生產者、客戶）的判定；氣候變遷考量兩者都有，公開資料指出 42001:2023 出版時已內含，不在 2024 年修訂清單內。	擴充	沿用 ISMS 的全景分析表，加一欄 AI 系統清單與每個系統對應的角色，角色判定會直接影響後面要選哪些控制。
4.2利害關係者	列出與 ISMS 有關的利害關係者、他們的要求，以及哪些要求要透過 ISMS 處理。	做法相同，對象換成與 AIMS 有關的人，常會多出 AI 系統的使用者、受 AI 決策影響的人與 AI 相關主管機關。結構相同；利害關係者名單通常要補上受 AI 影響的個人或群體。	相同	用同一張利害關係者表，加一欄標示該要求屬於 ISMS、AIMS 或兩者。
4.3決定管理系統範圍	依全景與利害關係者要求，界定 ISMS 涵蓋的組織、地點、資訊與系統，並留下文件。	同樣界定範圍並留下文件，範圍要能看出涵蓋哪些 AI 系統、哪些 AI 活動與角色。結構相同；範圍的描述單位從資訊與系統變成 AI 系統與 AI 活動。	相同	兩個範圍不必一樣大，可以分開寫，再註明重疊的單位與共用的流程。
4.4管理系統	建立、實施、維持並持續改善 ISMS，包括所需的過程與彼此的互動。	對 AIMS 做同樣的事。相同。	相同	整合管理系統手冊可以共用一份，用章節或附件區分兩邊各自的過程。
5.1領導與承諾	最高管理階層要讓資安政策與目標和策略一致、提供資源、把 ISMS 融入業務流程。	最高管理階層對 AIMS 負同樣的責任，政策與目標換成 AI 政策與 AI 目標。相同。	相同	高階主管的承諾可以在同一場會議、同一份文件中一起展現，但要看得出有涵蓋 AI。
5.2政策	訂定資訊安全政策，提供設定資安目標的框架，並承諾符合要求與持續改善。	訂定 AI 政策，結構要求和 27001 相同；附錄 A.2 再補充 AI 政策該涵蓋的內容與和其他政策的銜接。條文相同；AI 政策的實質內容由附錄 A.2 補強。	相同	AI 政策可以獨立成一份，也可以併入整合政策，但 AI 的原則與承諾要能單獨辨識出來。
5.3角色、責任與權限	指派並溝通與資安相關角色的責任與權限，包括誰負責回報 ISMS 績效。	對 AIMS 做同樣的指派；附錄 A.3 再要求釐清 AI 相關角色。相同；細部角色由附錄 A.3 補充。	相同	沿用既有的權責矩陣，加入 AI 系統負責人、模型或資料負責人等角色。
6.1.1處理風險與機會的行動：一般	規劃時考慮全景與利害關係者要求，決定要處理的風險與機會，並規劃行動。	同樣規劃風險與機會，另外要建立 AI 風險準則，用來區分可接受與不可接受的風險，並支撐風險評鑑、風險處理與影響評估。 42001 多了 AI 風險準則的要求，也要考慮 AI 系統的應用領域與預期用途。	擴充	共用同一套風險方法文件，在風險準則一節加上 AI 專屬的可接受門檻與判斷依據。
6.1.2風險評鑑	依既定準則找出喪失機密性、完整性、可用性的風險，指定風險擁有者，分析並評估風險。	同樣要有可重複的風險評鑑過程，但後果要評估對組織、對個人與對社會的影響，必要時納入影響評估的結果。 42001 的後果範圍更廣，不只看組織損失，也看對個人與社會的影響。	擴充	沿用相同的評分架構，擴充後果類型（例如歧視、人身安全、權益受損），並可在同一份風險登錄表用標籤區分 AI 風險。
6.1.3風險處理與適用性聲明	選擇處理選項與必要控制，和附錄 A 比對，產出適用性聲明（SoA）與風險處理計畫。	流程相同，比對的是 42001 自己的附錄 A，附錄 B 提供實作指引，同樣要產出 SoA 與處理計畫。流程相同；比對清單與 SoA 內容完全不同。	相同	兩份附錄 A 不同，SoA 通常分開兩份，或在同一文件分兩章；每項都要寫納入或排除的理由。
6.1.4AI 系統影響評估	沒有對應條文；27001 的風險評鑑以組織的資訊安全為主，不要求評估系統對外部個人或社會的影響。	建立過程，評估 AI 系統的開發、提供或使用可能對個人、群體與社會造成的後果，並把結果用在風險評鑑。 42001 獨有，是兩個標準最大的差異之一。	42001 獨有	另建影響評估程序，可參考 ISO/IEC 42005；已有個資衝擊評估的組織可把它當作輸入之一，但不能取代。
6.2目標及達成規劃	設定可量測的資訊安全目標，規劃由誰、何時、用什麼資源達成。	對 AI 目標做同樣的事；附錄 C 列出可參考的 AI 目標，例如公平、透明、穩健性。相同；目標內容換成 AI 相關。	相同	目標清單可以放在同一張表，但 AI 目標要有自己的指標，不要只寫資安指標。
6.3變更的規劃	需要變更 ISMS 時，要有計畫地進行。	需要變更 AIMS 時，同樣要有計畫地進行。相同。	相同	共用一套管理系統變更流程即可。
7.1資源	決定並提供 ISMS 所需的資源。	決定並提供 AIMS 所需的資源；附錄 A.4 再要求把 AI 系統用到的資源盤點清楚。相同；資源盤點的細節由附錄 A.4 補充。	相同	預算與人力規劃可一起編列，但 AI 的運算資源、資料與工具要另外列出。
7.2能力	確認影響資安績效的人員具備所需能力，並保留能力證據。	對影響 AI 績效的人員做同樣的事。相同；能力需求會多出資料科學、模型評估、AI 倫理等領域。	相同	沿用職能矩陣與訓練紀錄，加上 AI 相關職能項目。
7.3認知	讓人員知道資安政策、自己的貢獻與不遵守的後果。	讓人員知道 AI 政策、自己對 AIMS 的貢獻與不遵守的後果。相同。	相同	年度認知課程可以合併，另加一節 AI 使用規範與通報管道。
7.4溝通	決定要對內對外溝通什麼、何時、對誰、怎麼溝通。	對 AIMS 做同樣的規劃；附錄 A.8 再補充要提供給使用者與利害關係者的資訊。相同；對外資訊的細節由附錄 A.8 補充。	相同	沿用溝通計畫表，加上 AI 系統的對外說明與事故通知對象。
7.5文件化資訊	保存標準要求與組織認為必要的文件，並管制建立、更新與保存方式。	要求相同，適用於 AIMS 的文件。相同。	相同	共用同一套文件管制程序與文件系統，只需補上 AI 相關文件類別。
8.1運作規劃與管制	規劃並管制達成 ISMS 要求所需的過程，包括外部提供的過程。	對 AIMS 做同樣的規劃與管制，包括實施風險處理所選定的控制。相同。	相同	運作管制可以共用流程，例如變更管理與委外管理，再補上 AI 系統上線前的檢查點。
8.2執行風險評鑑	依計畫的期間或發生重大變更時執行資安風險評鑑，並保留結果。	依計畫的期間或發生重大變更時執行 AI 風險評鑑，並保留結果。結構相同；評鑑對象是 AI 風險。	相同	可排在同一個年度風險評鑑週期，但模型更新、換資料來源等 AI 變更要能觸發重新評鑑。
8.3執行風險處理	實施資安風險處理計畫，並保留結果。	實施 AI 風險處理計畫，並保留結果；處理後要確認是否產生新的風險。結構相同。	相同	處理計畫的追蹤可以用同一套工單或專案工具，用標籤區分。
8.4執行 AI 系統影響評估	沒有對應條文。	依計畫的期間或發生重大變更時執行影響評估，並保留結果。 42001 獨有，是 6.1.4 的執行面。	42001 獨有	把影響評估掛進 AI 系統上線與重大變更的審查流程，避免只做一次就放著。
9.1監督、量測、分析與評估	決定要監督量測什麼、怎麼做、何時做、由誰分析評估。	對 AIMS 做同樣的事。相同；指標多半會加上模型表現、偏差、事故等 AI 指標。	相同	績效儀表板可以合併，但 AI 指標要能單獨呈現給管理審查。
9.2內部稽核	依計畫的期間執行內部稽核，建立稽核方案，確保稽核員客觀公正。	要求相同，適用於 AIMS。相同。	相同	可以合併成一個稽核方案，但查 AI 控制的稽核員要具備 AI 生命週期與資料的基本知識。
9.3管理審查	最高管理階層依計畫的期間審查 ISMS，並決定改善與變更。	要求相同，適用於 AIMS。相同。	相同	管理審查會議可以合併，議程要分別涵蓋兩邊的輸入項目並留下各自的決議。
10.1持續改善	持續改善 ISMS 的適切性、充分性與有效性。	對 AIMS 做同樣的事。相同。	相同	改善提案與追蹤共用同一套機制。
10.2不符合事項與矯正措施	發生不符合時要處理、找出原因、採取矯正措施並確認有效。	要求相同，適用於 AIMS。相同。	相同	共用矯正措施程序與表單，原因分析時記得把資料與模型因素納入考量。

二、42001 附錄 A 38 項控制與 27001 的參考對應

ISO 沒有發布 27001 與 42001 的官方對照表，下表是依主題整理的參考對應：類似表示 27001 的做法大致可以沿用；部分重疊表示可以借用 27001 的流程，但要補上 AI 特有的內容；42001 獨有表示 27001 沒有相近的控制，要另外建立。點 42001 控制名稱會打開該節點的白話說明；27001 的條號會在新分頁開啟 ISO 27001 地圖的節點。

42001 條號	控制名稱	關係	27001 參考	說明
A.2.2	AI policy	類似	5.1	和 27001 的資安政策同一個思路，政策框架、核准與公告流程可以共用，但內容要談 AI 的原則與承諾。
A.2.3	Alignment with other organizational policies	部分重疊	5.1	27001 也有主題別政策，但這項更強調 AI 會牽動資安、隱私、品質等既有政策，要找出交集並避免互相衝突。
A.2.4	Review of the AI policy	類似	5.1	定期審查政策的機制可以直接沿用資安政策的審查週期與紀錄方式。
A.3.2	AI roles and responsibilities	類似	5.2 5.3	沿用資安角色與職務分隔的做法，再補上 AI 系統負責人、資料負責人、人類監督者等角色。
A.3.3	Reporting of concerns	部分重疊	6.8	27001 的事件通報管道可以借用，但這項要能讓人員對 AI 系統提出疑慮，並考量保密與保護通報者。
A.4.2	Resource documentation	部分重疊	5.9	資產清冊的格式可以擴充，針對每個 AI 系統記下它用到的資料、工具、運算與人力資源。
A.4.3	Data resources	部分重疊	5.9 5.12	資產清冊與資訊分級可以涵蓋資料集，但 AI 還要記錄資料的用途、來源、品質與代表性等資訊。
A.4.4	Tooling resources	部分重疊	5.9	軟體資產清冊可以沿用，再補上訓練框架、標註工具、模型評估工具等 AI 專用工具。
A.4.5	System and computing resources	部分重疊	5.9 8.6 5.23	容量管理與雲端服務管理可以共用，但要另外記錄訓練與推論所需的運算資源與部署環境。
A.4.6	Human resources	42001 獨有	無相近控制	附錄 A 沒有直接對應；最接近的是 27001 條文 7.2 能力，可沿用職能紀錄，再列出 AI 生命週期各階段需要的人員與專長。
A.5.2	AI system impact assessment process	42001 獨有	無相近控制	27001 沒有這類要求；要另建評估程序，說明何時做、誰來做、怎麼判斷影響大小。
A.5.3	Documentation of AI system impact assessments	42001 獨有	無相近控制	文件管制流程可以共用，但影響評估的結果與保存期限要另外規定。
A.5.4	Assessing AI system impact on individuals or groups of individuals	部分重疊	5.34	只有個資與隱私這一塊可以沿用既有的個資衝擊評估；公平、安全、權益等面向是新的工作。
A.5.5	Assessing societal impacts of AI systems	42001 獨有	無相近控制	27001 完全沒有對應；要評估 AI 系統對社會層面的影響，例如環境、就業或公共資訊。
A.6.1.2	Objectives for responsible development of AI system	部分重疊	8.25	安全開發生命週期的規則可以當基礎，但這項要把公平、透明等負責任 AI 目標放進開發要求。
A.6.1.3	Processes for responsible AI system design and development	部分重疊	5.8 8.25 8.27	專案管理與安全開發流程可以沿用，再補上 AI 特有的關卡，例如資料審查、模型評估與上線核准。
A.6.2.2	AI system requirements and specification	部分重疊	8.26	應用程式安全需求的做法可以參考，但 AI 需求還要寫清楚預期用途、效能門檻與限制條件。
A.6.2.3	Documentation of AI system design and development	部分重疊	8.25 8.27	架構設計文件的管理方式可以共用，內容要加上模型選擇、訓練方式與資料處理的設計決定。
A.6.2.4	AI system verification and validation	部分重疊	8.29	27001 的測試著重資安，這項還要驗證模型準確度、穩健性、偏差等，測試範圍明顯更大。
A.6.2.5	AI system deployment	部分重疊	8.31 8.32	環境分離與變更管理可以直接沿用，再加上部署前確認需求是否達成的核准步驟。
A.6.2.6	AI system operation and monitoring	部分重疊	8.16 8.6	監控平台可以共用，但要加上模型效能、資料漂移與錯誤輸出等 AI 指標。
A.6.2.7	AI system technical documentation	部分重疊	5.37	文件化作業程序的管理方式可以共用，但內容要讓使用者或主管機關看得懂系統的能力與限制。
A.6.2.8	AI system recording of event logs	類似	8.15 8.17	日誌收集與保護機制可以直接沿用，再決定 AI 系統在哪些階段要記錄哪些事件。
A.7.2	Data for development and enhancement of AI system	部分重疊	5.12 5.33	資訊分級與紀錄保護可以涵蓋資料集，但要另外訂定訓練與改善模型時資料的管理過程。
A.7.3	Acquisition of data	部分重疊	5.31 5.32 5.34	法規、智慧財產權與個資的檢查可以沿用，這項還要記錄資料怎麼來、取得條件與適用範圍。
A.7.4	Quality of data for AI systems	42001 獨有	無相近控制	27001 的完整性只管資料沒被竄改，不管資料準不準、夠不夠代表性；品質要求要另外訂定。
A.7.5	Data provenance	42001 獨有	無相近控制	27001 沒有對應；要記錄資料從哪裡來、經過哪些處理，讓結果出問題時能追回源頭。
A.7.6	Data preparation	部分重疊	8.11	只有去識別化與遮罩這部分能沿用 8.11，清理、標註、轉換等準備步驟要另外訂出方法與紀錄。
A.8.2	System documentation and information for users	42001 獨有	無相近控制	27001 沒有要求向使用者揭露系統資訊；要另外決定使用者需要知道哪些用途、限制與注意事項。
A.8.3	External reporting	42001 獨有	無相近控制	27001 的通報管道主要給內部人員；這項要讓外部的人能回報 AI 系統的不良影響，常見做法是沿用客服或弱點回報窗口再擴充。
A.8.4	Communication of incidents	部分重疊	5.24 5.26 5.5	資安事件管理與主管機關聯繫流程可以共用，再加上 AI 事故該通知哪些使用者與利害關係者。
A.8.5	Information for interested parties	部分重疊	5.5 5.31	法規與合約義務的盤點可以共用，這項聚焦在對利害關係者提供 AI 系統相關資訊的義務。
A.9.2	Processes for responsible use of AI systems	部分重疊	5.10	資產可接受使用規範可以當基礎，再補上使用 AI 系統時的核准、限制與人類監督要求。
A.9.3	Objectives for responsible use of AI system	42001 獨有	無相近控制	27001 沒有對應；要訂出使用 AI 時想達成的負責任目標，並用來指引使用過程。
A.9.4	Intended use of the AI system	部分重疊	5.10	可接受使用規範只管不能怎麼用；這項要確保 AI 系統照預期用途使用，並保留相關紀錄。
A.10.2	Allocating responsibilities	部分重疊	5.19 5.20	供應商協議的資安條款可以沿用，但要釐清組織、供應商、客戶在 AI 生命週期各段誰負責什麼。
A.10.3	Suppliers	類似	5.19 5.21 5.22 5.23	供應商評估與監督流程可以直接沿用，再加上模型、資料與 API 供應商是否符合組織負責任 AI 做法的檢查。
A.10.4	Customers	42001 獨有	無相近控制	27001 多從採購方角度看供應鏈；這項要組織把客戶的期望與需求納入提供 AI 產品或服務的方式。

三、依主題看兩邊的控制

同一個管理主題，在兩個標準裡各由哪些控制負責。整合導入時，同一主題的程序可以合併成一份，再分別標出對應的條號。

主題	27001:2022	42001:2023	說明
政策	5.1 5.36	A.2.2A.2.3A.2.4	政策的核准、公告與定期審查流程可以共用；AI 政策可以獨立一份，也可以併入整合政策，但要說清楚它和資安、隱私政策的關係。
角色與通報	5.2 5.3 5.4 6.8	A.3.2A.3.3	沿用權責矩陣與通報管道，補上 AI 系統負責人與人類監督者，並讓人員能對 AI 系統提出疑慮。
資產與資源	5.9 5.12 8.6 5.23	A.4.2A.4.3A.4.4A.4.5A.4.6	資產清冊可以擴充成 AI 系統資源清冊，一次記錄每個系統用到的資料、工具、運算與人力。
影響評估	5.34	A.5.2A.5.3A.5.4A.5.5	27001 幾乎沒有對應，只有個資衝擊評估能當作輸入之一；對個人、群體與社會的影響評估要另建流程。
開發生命週期與技術文件	5.8 5.37 8.25 8.26 8.27 8.29 8.31 8.32	A.6.1.2A.6.1.3A.6.2.2A.6.2.3A.6.2.4A.6.2.5A.6.2.7	安全開發、測試、變更管理是現成的骨架；42001 要在上面加上負責任 AI 目標、模型驗證與給外部看的技術文件。
資料	5.12 5.31 5.32 5.33 5.34 8.11	A.7.2A.7.3A.7.4A.7.5A.7.6	27001 管資料的保密與完整，42001 還管資料的品質、代表性與來源追溯，這部分多半要新建。
紀錄與監控	8.15 8.16 8.17	A.6.2.6A.6.2.8	日誌與監控平台可以共用，再加上模型效能、漂移與異常輸出的監控指標。
事件與對外資訊	5.5 5.24 5.25 5.26 5.27	A.8.2A.8.3A.8.4A.8.5	事件管理流程可以共用；42001 另外要求對使用者揭露系統資訊、提供外部回報管道，以及把 AI 事故告知相關的人。
負責任使用	5.10	A.9.2A.9.3A.9.4	可接受使用規範是起點，但 42001 要的是照預期用途使用 AI 系統，並有使用目標與監督。
供應商與第三方	5.19 5.20 5.21 5.22 5.23	A.10.2A.10.3A.10.4	供應商評估、合約與監督流程可以沿用；42001 還要分清楚 AI 生命週期中各方的責任，並照顧客戶的需求。

四、整合導入建議

共用管理系統骨架：第 4～10 條結構相同，常見做法是用一套整合管理系統手冊、文件管制、矯正措施程序同時涵蓋 ISMS 與 AIMS；標準沒有要求一定要整合，也可以各自獨立。
風險方法共用但要擴充：可以沿用 27001 的風險評分架構與登錄表格式，但後果類型要加上對個人、群體與社會的影響，並另訂 AI 風險的可接受門檻；AI 風險要放同一張表還是另開清冊，由組織自行決定。
影響評估另建流程：6.1.4 與 8.4 的 AI 系統影響評估是 27001 沒有的工作，不要硬塞進資安風險評鑑；可參考 ISO/IEC 42005 設計程序，結果再回饋到 AI 風險評鑑，既有的個資衝擊評估只能當作輸入之一。
SoA 分開或分章：兩份附錄 A 是不同清單，適用性聲明比對的對象不同，常見做法是分開兩份，或同一份文件分兩章；不論哪種，每項控制都要寫出納入或排除的理由與實施狀態。
先盤點 AI 系統與角色：從 4.1 開始，列出組織開發、提供或使用的 AI 系統與各自的 AI 角色，再決定 AIMS 範圍；範圍不必和 ISMS 一樣大，但要寫清楚兩邊重疊與共用的部分。
內稽與管審合併：稽核方案與管理審查會議可以合併辦理，但稽核員要具備 AI 相關知識，管審議程要分別涵蓋兩邊的輸入並留下各自的決議；驗證機構能否合併稽核與如何計算人天，以驗證機構規定為準。
證據沿用要看清界線：日誌、變更管理、供應商評估、事件管理等 27001 證據可以擴充沿用；資料品質、資料來源、對使用者的說明與預期用途等控制，多半要新建流程與紀錄。

想動手練習哪些可以共用、怎麼排導入順序，可以看互動教學頁：

▶互動教學與 ISO 27001 整合導入

對照依公開資料與兩個標準的條文架構整理，屬於參考對應，不是 ISO 官方對照；標準原文請參閱 ISO 正式出版品。

ISO/IEC 27001 vs 42001 對照總表

一、條文 4–10 對照

二、42001 附錄 A 38 項控制與 27001 的參考對應

三、依主題看兩邊的控制

四、整合導入建議

我是 AKIRA

🎯 擅長

📜 證照

💻 專業技能