(三) 不同的範圍
範圍界定是規劃資訊安全管理系統（ISMS）的導入及實施的關鍵點，組織通常會細分為較小的ISMS範圍（例如：與特定專案、服務或政策等相關的ISMS）。在任何一種情況下，範圍都決定了資訊安全管理的控制措施、界限及適用性。範圍將由以下因素決定：

1. 組織的業務
2. 相關利害關係者的需求和期望
3. 目前的組織結構
   重要的是在一開始就正確定義並與相關等級最高的利害關係者達成一致(例如行政院資通安全處或者是重要客戶的要求)，確認相關系統的執行適用資訊安全要求。組織通常具有與資訊安全相關的多個範疇，資訊安全的整體範圍雖然可能被定義為全組織，但是在大多數情況下，整個組織要通過認證(如ISO/IEC 27001或PCI DSS標準)的難度很高。根據本人的稽核經驗，驗證過的組織僅有一家是全組織導入及驗證。因此，組織應考慮具有多個較小的範圍，每個範圍都適合其所包含的資訊所需的保護。例如，PCI DSS稽核的範圍是透過僅保護信用卡持卡人資料來確定的。從縮小範圍開始進行導入，也可以增加成功的機會，並在合理的時間內實現ISMS的目標。

(四) 如何定義ISMS的範圍

1. 識別需要保護的內容
   組織到底需要保護什麼？很可能需要保護眾多的資訊資產，以支持組織實現其營運目標。重要的是要了解組織認為哪些是最重要的，因此建議採用基於風險的優先順序的方法來確定範圍。為了確定資產實際上值得保護，組織應列出每項資產需要保護的理由。初始的時候可以將ISMS的範圍定義為僅包括特定流程、服務、系統或特定部門，再來逐步擴展ISMS範圍，或者創建另一個具有不同要求和保護的獨立範圍。為了使範圍完全清楚，特別是對第三方而言，識別不在範圍內的內容（例如人力資源、會計部門的活動）是一項基本的工作。無論哪種方式，範圍都應根據要保護的業務目標和資訊資產明確定義所包含的內容，並且應該明確指出超出範圍的其他任何內容。
2. 監督和審查
   ISMS、政策、審查或專案的範圍不是一成不變的，可能隨著環境、威脅、技術和要求的發展而需要逐漸調整。因此，範圍界定不應該於專案開始時進行一次然後不再檢討修正；相反地，應定期監測和審查範圍和/或根據重大變化進行審查。當進行稽核（無論是內部稽核或是第三方驗證）時，稽核員應該做的第一件事就是審查和評估範圍的適當性。可能影響/改變ISMS範圍的因素包括：
   • 時間依存性：特定ISMS和/或安全專案的範圍可能僅適用於特定時間段，例如合約期限
   • 監管環境的變化
   • 更改/更新標準和/或第三方要求
   • 組織變更：例如組織改組或遷址
   • 識別不符合和/或指示不正確範圍的事件
   • ISMS的整體成熟度（範圍可能會隨著時間的推移而增加，逐步擴大）
   • 流程和做法的變化（例如停止某些不再需要的活動）
   • 外包服務
3. 委外和第三方
   委外可以定義為「將組織中部分或全部資訊系統功能，轉交給外部服務供應商去完成，如應用系統開發與維護、系統操作、網路管理、系統規畫及應用系統軟體採購等」，雲端服務可以定義為「IaaS：雲端服務提供者爲使用者提供雲端環境的基礎架構(如伺服器、儲存及網路等)，使用者在雲端服務提供者的基礎架構中建構自己的平台和應用程式，以便能夠開發、管理與交付應用程式；PaaS：除了基礎架構以外，使用者可以選用雲端服務提供者預先建置的工具套件來開發、自訂與測試自己的應用程式；SaaS：使用者不必於他們的本地端裝置上安裝應用程式，應用程式位在雲端環境上，透過 Web 或 API 存取，使用者可透過應用程式儲存、分析資料，或協同進行」，幾乎所有組織都會將某些活動外包給第三方，某些第三方活動被認為是理所當然的，經常被人們所習慣及忽視，例如清潔團隊、廢物清除承包商以及會計師，他們的活動可能沒有受到詳細審查，但他們可能擁有最高級別的存取權限。
   組織希望或需要將其部分（或全部）IT委外的原因有很多，隨著資訊技術的變化和發展非常迅速，將組織的某些IT解決方案委外或使用雲端儲存/服務可能更具成本效益。外部託管服務還可以提供組織內無法提供的專業IT知識和支持。如果管理得當，委外IT或雲端技術不會比管理內部IT環境帶來更大的風險，並且可以說風險更小。但本人曾經稽核過一個組織，業務承辦人員在辦理活動時使用GOOGLE表單蒐集參加客戶的個人資料(未使用組織本身資訊系統)，當問及為何如此做的原因，承辦人員回覆，組織的系統或資訊安全風險較高，使用GOOGLE安全性較高，但是在活動結束時，承辦人員從GOOGLE將個人資料刪除，它真的代表已經確實刪除了嗎？再者，如果發生個人資料外洩事件時，GOOGLE會負責嗎？這一段作業是否在我們ISMS範圍內，如何對這種作業執行管控，這都是在訂定範圍的時候需要考量的，所以採購或管理不善的委外或不適當的雲服務提供可能極具風險。使用雲端服務時，可能會有多方參與整個服務的提供，例如：基礎設施和軟體服務可以由不同的組織提供。在此背景下確定範圍將清楚地了解所涉及的系統組件以及每個服務提供商的安全責任。這些安全要求應包含在任何合約協議中。實施安全的責任可能是由委外的人負責的，但問責制度很難建立(如同前面的案例)，因此在這種情況下理解ISMS的範圍非常重要。簡而言之，在滿足某些安全要求時，委外功能或流程將屬於ISMS的範圍。