Determining the Scope of the Information Security Management System

Clause 4.3 requires organizations to determine the boundaries and applicability of their ISMS. You must consider internal and external issues (Clause 4.1), requirements of interested parties (Clause 4.2), and interfaces/dependencies with other organizations to establish a documented scope.

You determine the scope by analyzing your business operations to decide what needs protection. Identify key assets, physical locations, and teams. Crucially, you must also identify where your systems connect with third parties (interfaces) and ensure those points are covered. For example, WatchDog Security’s Asset Inventory can help you maintain a current list of cloud resources and SaaS systems that belong inside the defined scope.

A scope statement should include a description of the products, services, and locations covered. It must also list any exclusions with justifications and clearly define the interfaces between your organization and external parties.

For startups, a broad scope (whole company) is often easier to manage than creating artificial boundaries. For large enterprises, narrowing the scope to specific sensitive product lines allows for focused control application without slowing down non-critical business units.

Common mistakes include failing to document interfaces with third parties, excluding 'Shadow IT' that processes real data, and creating a scope so narrow that it excludes the actual business value (e.g., certifying only the HR department but not the SaaS product).

Clause 4.3 explicitly requires considering 'interfaces and dependencies' with other organizations. While you cannot control a third party (like AWS or Google Cloud), your scope must include the management of that relationship and the security of the interface (e.g., API keys, contracts). For example, WatchDog Security’s Vendor Risk Management can help you catalog in-scope vendors, capture due diligence outputs, and document how each dependency is governed as part of the ISMS scope.

The ISMS Scope defines what is being protected (boundaries, departments, assets). The Statement of Applicability (SoA) defines how it is protected by listing which of the Annex A controls are applied to that scope.

The scope should be reviewed at planned intervals (typically annually during Management Review) or whenever significant changes occur, such as mergers, acquisitions, new product launches, or changes in physical office locations. WatchDog Security can help track these triggers. For example, WatchDog Security’s Compliance Center can log scope-review decisions, assign follow-ups, and keep the scope document and related evidence packaged for audits.

ISMS scope often becomes hard to maintain as systems, vendors, and teams change, which can create mismatches between what’s actually in use and what’s documented for audit. A GRC platform helps by centralizing the scope statement, mapping it to assets, processes, and evidence, and making updates traceable as the organization evolves. For example, WatchDog Security’s Compliance Center can link the scope statement to Clause 4.3 requirements, track scope-related gaps, and keep supporting evidence organized for audit readiness.

Interfaces change frequently (new SaaS tools, new data flows, new integrations), so relying on a one-time diagram or spreadsheet can quickly become outdated. A practical approach is to maintain a living inventory of vendors and integrations, then periodically review which ones handle in-scope data and how they connect to your systems. For example, WatchDog Security’s Vendor Risk Management can maintain a vendor catalog with risk-tiering and assessments, while helping you consistently document which third-party interfaces are considered in-scope for the ISMS.