What is a system boundary in this model, and why does it have to be organisational as well as technical?
It is the delimitation of the cyber system under consideration, and it only works if it is unambiguous in both senses: technically you must be able to say where the system ends, and organisationally someone must own everything inside it.
* A system can be one service or a hybrid of five providers — what matters is that the border is unambiguous. *
The examples of what a "system" can be are deliberately varied:
- one piece — a single service;
- many parts — several services interconnected;
- a cloud service — a boundary that runs through a provider;
- a multi-cloud service — several providers together;
- fully hybrid, mixed — on-premises services and cloud services in one system.
Why the organisational half is non-negotiable: a boundary that is technically drawn but organisationally unowned is a boundary nobody maintains. Rules get added by whoever needs them, nobody prunes them, and after two years the line on the diagram has no relationship to reality. Conversely, a boundary that is organisationally clear but technically vague ("everything in the production department") cannot be implemented — you cannot write a rule against a sentiment.
The consequences run through everything that follows:
- It determines what you are defending, and therefore what "inside" means for every perimeter-style approach.
- It determines who decides: whose approval is needed to let something in, and whose risk is affected.
- It is where hybrid and multi-cloud designs go wrong: the boundary crosses a contract, so a piece of it is enforced by somebody else's configuration screen.
Tip: if a design cannot say, in one sentence each, where the system ends and who owns everything inside it, that is the first finding — before any technology discussion.
Go deeper:
NIST glossary — authorization boundary — the formal version: what is inside, what is explicitly excluded, and who signs it off.