拿到 ISO 27001 證書之後，我們還需要問什麼？

在 COSCUP 和朋友聊到 ISO 27001 時，我想到一個很基本的問題：如果公司規定密碼每 90 天換一次，為什麼是 90 天？為什麼不是 92 天、180 天，或 3 天？

我關心的是，制定規則的人能不能說明它要處理什麼風險，以及為什麼這個做法適合自己的系統。工程師應該有能力提出這個問題，組織也應該容許它被提出。

證書之外，還有範圍與深度

ISO 對 ISO/IEC 27001:2022 的說明，重點是建立、維持及持續改善資訊安全管理系統，透過風險管理保護資訊的機密性、完整性和可用性。

讀到一家公司的驗證資訊時，我會想進一步知道：涵蓋哪些服務與作業？相關風險如何被辨識？選擇了哪些控制措施？如何知道這些措施有效？

這些問題不會只靠一個標誌就全部得到答案。很多實際安排寫在組織內部的程序、作業文件與紀錄裡，外部讀者未必看得到。因此，能從公開證書確認的事情，和我們希望從它推論的事情，需要分開。

密碼政策不能只剩下背誦一個天數。以目前的 NIST SP 800-63B-4 密碼要求為例，在其數位身分驗證適用脈絡中，不要求使用者定期更換密碼；有證據顯示驗證資訊遭到入侵時，則應強制更換。

這是另一份指引的具體要求，不是 ISO 27001 所有情境的替代答案，更不能直接套用到 API 金鑰或所有機器憑證。它提醒我們：安全措施必須連同威脅模型、使用方式及其他控制一起討論。

如果改掉一項舊規則，組織需要能說明依據，確認適用的法規和契約要求，並評估剩餘風險。只把「90」換成另一個數字，並沒有完成這件事。

我原來的貼文對「顧問說不這樣做就過不了」這種溝通方式很不滿。當這句話成為討論的終點，提出問題的人就容易被看成阻礙驗證，真正的風險和業務需求反而沒有人處理。

這不是說所有顧問都如此。好的外部協助，可以讓組織看見盲點、建立方法、減少摸索成本。但組織仍需要知道自己為什麼採取某個措施，誰有權接受剩餘風險，以及什麼情況下要重新檢討。

利害關係人也不能被簡化成「誰付錢就只聽誰的」。客戶、員工、契約相對人和其他相關方的要求，需要依實際情境辨識。被管理的風險會影響誰，應該是這場討論的一部分。

與其只問今年有沒有拿到證書，我更想知道：團隊能否解釋重要措施的理由？發現措施失效時，能否修正？事件發生後，是否知道誰負責調查、改善與對外說明？

能把這些問題回答清楚，證書背後的管理系統才比較容易被看見。