Where Does the Boundary End?
A grants management system serves 400,000 applicants and holds PII plus banking data. The front end is a vendor-hosted multi-tenant SaaS; the vendor holds a Moderate authorization from another agency. The agency's eligibility engine calls the SaaS API, and nightly extracts land in an internal SQL Server that produces reports for the finance office. The vendor replicates backups to a cloud region the agency never approved. The system owner proposes excluding the reporting SQL Server ('it is just a copy, the SaaS is the system of record') and treating the vendor as fully out of scope because 'they are already authorized.' The boundary diagram shows one box labeled SaaS.
1. Should the reporting SQL Server be inside the authorization boundary? State the criteria you would apply and the decision.
Read the worked answer
Apply three criteria: does the component process, store, or transmit the system's data; does it have its own access paths and users; and will the AO be accepting risk for it?
The reporting server fails all three tests for exclusion. It stores the same PII, it has its own accounts, patching, backup, and database administrators, and a compromise there exposes the same population. 'It is just a copy' describes function, not risk - risk follows the data, not the label 'system of record.'
So there are two defensible outcomes, and the system owner must pick one explicitly:
- Include it in the boundary, add its controls to the SSP and assessment scope; or
- Register it as a separate system with its own authorization and document the interconnection (data flow, direction, agreement, responsibilities).
What is not defensible is leaving it off the diagram while it holds 400,000 applicants' banking data.
2. How should the vendor SaaS and the unapproved backup region be treated in the authorization package?
Read the worked answer
The vendor's authorization from another agency is a leveraged authorization, not a free pass. The agency must still:
- confirm the vendor's package covers the services actually used, the data types involved, and the environments in play;
- obtain and review the vendor's SSP summary, assessment results, and open POA&M items;
- document the shared responsibility split - which controls the vendor owns, which the agency owns, and which are hybrid;
- accept the residual risk for the agency's own use.
The backup region is the sharper problem. A region outside the vendor's assessed boundary may mean the replication is not covered by the authorization, and it certainly raises data-location questions the agency's privacy and records requirements govern. The correct step is to ask the vendor whether the region is in scope and, if not, either require replication to an in-scope location or treat it as a change requiring assessment. The agency cannot inherit assurance the vendor never obtained.
3. What is the practical risk created by the single-box boundary diagram, and what would you require instead?
Read the worked answer
A single box hides every decision the AO is being asked to accept: the API interconnection, the extract and its destination, the backup replication, and the shared responsibility line between agency and vendor. It makes the package look simple by making it unauditable - an assessor cannot scope testing against a picture with no interfaces, and a reviewer cannot spot an omission that is not drawn.
What is needed is a data-flow view showing each component, each connection with direction and protocol, the data elements on each path, and who operates each node, plus the supporting interconnection agreement or memorandum of understanding for the API. Scoping is a risk decision, and it should be visible enough that someone can disagree with it.