Clause 4.3 is where the ISMS gets a boundary. The scope determines what you are accountable for controlling, what an auditor will test, and where your liability ends. A scope that is too narrow leaves risk unaddressed. A scope that is too broad creates obligations you cannot meet.
What 4.3 Requires
When determining scope, the standard requires the organization to consider three things:
a) External and internal issues from 4.1
Your scope must reflect the context you documented in 4.1. If your organization operates under HIPAA, the systems that handle PHI cannot be excluded. If you operate with a small team and limited infrastructure, that shapes what a realistic scope looks like. The scope has to be consistent with what the organization actually is.
b) Requirements from 4.2
The interested party requirements you documented in 4.2 directly shape what must be in scope. You cannot list a regulatory requirement in 4.2 and then exclude the system that creates it from 4.3. The two documents have to be consistent — if HIPAA breach notification is a requirement, the systems that handle PHI must be in scope.
c) Interfaces and dependencies with other organizations
Anywhere your operations touch another organization’s systems, there is a boundary and that boundary has security implications. You don’t control what happens inside your EHR vendor’s infrastructure. But the data crossing that boundary is your responsibility to account for. The scope must acknowledge where those interfaces exist and where your responsibility ends.
An auditor will verify that the scope is documented and that it is consistent with 4.1 and 4.2. They will look for unjustified exclusions — systems that clearly handle sensitive data but are left out without explanation. They will also check that interfaces with third parties are acknowledged. Leaving out the EHR vendor or a cloud platform while listing regulatory requirements that apply to that data is a finding.
Common gap: Organizations scope to “the IT department” or “our internal systems” and exclude cloud platforms and third-party dependencies entirely. If PHI or sensitive data flows through it, it belongs in scope or the exclusion must be explicitly justified.
Scoping for a Healthcare Practice
For a SaaS company, scope typically follows the product — the platform, its infrastructure, and the people who build and maintain it. For a healthcare practice, scope follows the data. Specifically: anywhere PHI is created, stored, transmitted, or accessed.
That boundary is wider than most small practices assume. PHI doesn’t just live in the EHR. It moves through email. It sits on staff laptops. It crosses into the hands of external contractors with system access. A scope limited to “the EHR system” would miss all of that.
For Meridian Health Partners, the scope covers every system and process through which PHI flows and explicitly acknowledges the third-party dependencies that create interfaces outside the practice’s direct control.
What the Document Looks Like
Below is the ISMS Scope document for Meridian Health Partners, built from the context established in 4.1 and the interested party requirements documented in 4.2.
Purpose
This document defines the scope of the Information Security Management System (ISMS) implemented by Meridian Health Partners LLC in alignment with ISO/IEC 27001:2022. It establishes the boundaries of the ISMS, identifies what is included and excluded, and documents the interfaces with external organizations that affect information security.
Scope Statement
The ISMS covers all systems, processes, personnel, and third-party dependencies involved in the creation, storage, transmission, and access of protected health information (PHI) at Meridian Health Partners LLC. This includes clinical operations, administrative functions that handle patient data, and the technology infrastructure that supports them.
Internal Issues Considered (4.1)
Meridian operates as a 22-person healthcare practice with no dedicated IT or security function. Security responsibilities are distributed across clinical and administrative staff. This constraint shapes the scope — controls must be practical for a small team — but does not justify excluding systems that handle PHI.
External Issues Considered (4.1)
Meridian operates under HIPAA and processes data from EU patients, creating obligations under GDPR. Both regulatory frameworks require administrative, physical, and technical safeguards applied to PHI wherever it exists within the defined environment. These obligations are non-negotiable and directly inform the scope boundary.
In Scope
| System / Area | Reason for Inclusion |
|---|---|
| EHR System | Primary system of record for all patient PHI. Core to clinical operations. |
| Microsoft 365 (Email & Teams) | PHI is transmitted via email — referrals, test results, patient communications. Must be in scope. |
| Staff Devices | All devices used to access the EHR or M365 are potential PHI endpoints. |
| Practice Network Infrastructure | PHI transits the local network. Network security controls are required under HIPAA technical safeguards. |
| External IT Contractor Access | Contractor has privileged access to practice systems. Access controls and agreements are required. |
| Breach Notification & Incident Response Processes | Required under HIPAA (60-day notification) and GDPR (72-hour notification). Must be formally documented and tested. |
Out of Scope
| System / Area | Reason for Exclusion |
|---|---|
| Personal Devices (Staff-Owned) | Not used to access practice systems. No PHI exposure. If this changes, the scope must be updated. |
| Appointment Scheduling System (if PHI-free) | If the scheduling system contains appointment times only — no clinical data, no patient identifiers beyond name — it falls outside the PHI boundary. Requires confirmation. |
| Third-Party Billing Company | Billing is handled externally under a Business Associate Agreement (BAA). The billing company maintains its own controls. Meridian’s obligation is the BAA, not direct ISMS coverage of their systems. |
Interfaces and Dependencies (4.3c)
| External Organization | Nature of Interface | Responsibility Boundary |
|---|---|---|
| EHR Cloud Provider | Hosts all patient records. PHI resides on their infrastructure. | Provider secures infrastructure. Meridian secures configuration, access, and data handling. Shared responsibility model applies. |
| Microsoft (M365) | Platform for email, document storage, and team communication. PHI transits and rests here. | Microsoft secures the platform. Meridian secures configuration, user access, and conditional access policies. |
| External IT Contractor | Privileged access to practice systems for maintenance and support. | Contractor operates under NDA and data handling agreement. Access is logged, reviewed, and revoked on contract end. |
| Third-Party Billing Company | Receives PHI for billing and claims processing. | Governed by BAA. Meridian’s responsibility is ensuring the BAA is current and that PHI transfer is encrypted. |
| Cyber Liability Insurer | Requires evidence of reasonable security practices and incident notification. | Meridian maintains ISMS documentation as evidence. Incident response procedure includes insurer notification step. |
Scope Availability
This document is maintained as documented information per Clause 4.3. It is reviewed annually or following any significant change to the organization’s operations, technology, or regulatory environment. The scope owner is the practice owner / leadership.
Next in this series: Clause 4.4 — The ISMS. The shortest clause in the standard and the one that ties everything together.
