The Boundary That Left Out the Keys
Meridian Health Cloud runs a patient-scheduling SaaS for 60 clinics and stores ePHI for roughly 1.2 million patients. An authorization package is being assembled for a customer security review. The engineer who drafted the boundary statement included only the production application and its database. Left outside were: (a) a third-party analytics vendor that receives de-identified encounter extracts nightly over an API; (b) an internal bastion host holding SSH keys to production; (c) the corporate email tenant used to send appointment reminders; and (d) the marketing website, hosted in the same cloud account with the same IAM roles. The engineer's note reads: 'Vendors and internal tooling are out of scope; they have their own controls.' The review is in three weeks.
1. Decide where each of the four excluded elements belongs relative to the authorization boundary, and state the principle you applied.
Read the worked answer
The principle is not ownership or who operates the component. The boundary encloses the people, processes, technology, and data flows that support the system's mission or can affect the protection of its data. Test each element with two questions: does it process, store, transmit, or protect the data, and can compromise of it degrade the system's security posture?
- Bastion host - inside. It carries credentials to production. It is a supporting component and a control point, not 'internal tooling.'
- Analytics vendor - outside the boundary, inside the package. It is an external service reached by an interconnection. Document the data flow, the agreement, the actual content of the extracts (verify 'de-identified' rather than accepting the label), and the provider controls Meridian relies on.
- Email tenant - determined by content, not by tool. Inspect reminder templates and the provider's handling. Patient name plus clinic plus appointment time is ePHI. If any ePHI transits, treat it as an interconnection or bring it in; if truly none does, exclude it with evidence.
- Marketing site - inside as drawn, unless separated. Sharing a cloud account and IAM roles creates a path to production regardless of the site's own data. Either move it to its own account, or include the shared identity layer as a common control.
The draft note is the actual defect: 'they have their own controls' is an assertion, not an inherited-control description.
2. Two components legitimately stay outside the boundary. The system owner asks what still has to appear in the package for them. Explain, and say what happens if it is omitted.
Read the worked answer
Out of boundary is not out of documentation. For each external element the package must contain:
- A data-flow diagram showing what crosses the boundary, in which direction, by what mechanism, and how often.
- The governing agreement (interconnection agreement, contract, or terms) and who on each side is accountable.
- A statement of which controls are inherited or shared, and how Meridian obtains assurance that they operate - the provider's independent report, attestation, or its own assessment, with a date.
- The residual risk if the provider fails or is breached, and its treatment.
The SSP must distinguish controls the system implements from those it inherits. Omitting this produces a package that claims protection it cannot evidence, and the reviewer's first question - 'what happens to my ePHI at that vendor?' - becomes unanswerable. It also removes the item from continuous monitoring, so no one notices when the vendor changes subprocessors.
3. The CISO proposes simply widening the boundary to everything in the cloud account, arguing it is cleaner. Evaluate that option.
Read the worked answer
Widening is a real option but the reasoning behind it is usually wrong, and here it is.
Widening does not make the work smaller - it makes the assessment surface larger, pulls unrelated workloads into scope, raises cost, and dilutes the authorization statement until it no longer tells a reader what is protected. It also invites scope creep during every future review.
The better sequence is architectural: separate accounts and identity roles so the marketing site and similar workloads genuinely do not share a path to ePHI, then keep a narrow, well-documented boundary. Widen only where separation is technically impossible - for example, where a single IAM layer or shared network segment serves both - and in that case bring the shared component in as a common control rather than pretending it away. The test is the data path, not administrative convenience.