Defining Your System Boundary: Why Most Are Wrong
Key Takeaways
- Most system boundary decisions get made for documentation convenience, not architectural accuracy — and that gap doesn't show up until an assessor tests it.
- A defensible boundary is built from actual data flows and connections, not from what's easy to leave out.
- Boundary creep runs both directions — scope can shrink (excluding messy systems) or balloon (over-including out of fear) — both are symptoms of the same root problem.
Your system's authorization boundary determines what's actually in scope for controls, documentation, and assessment — which means an inaccurate boundary doesn't just create a paperwork problem, it creates a false sense of what's actually being protected. The organizations that struggle here almost never do so out of dishonesty; they do it because nobody sat down and mapped real data flows before drawing the line. If your boundary has never been tested by the question "what actually connects to this system, and why isn't that included?" — that's worth doing before an assessor does it for you.
Busy executives can stop here. The full guide below is for the team doing the boundary-mapping work.
The Full Guide
A system boundary defines everything within an information system's authorization — the components, the data flows, the connections — that fall under a single security plan and a single authorization decision. Everything inside the boundary is what you're accountable for. Everything outside it is, on paper, someone else's problem. That last part is exactly where boundaries get quietly manipulated — not maliciously, but out of a very human instinct to keep scope manageable.
How Boundary Creep Actually Happens
It rarely happens as one decision. It happens as a series of small, individually reasonable-sounding calls:
- A legacy system that's hard to document gets left out because "we're planning to decommission it eventually."
- A shared service gets excluded because it's "managed by a different team," even though your system depends on it daily.
- An integration gets left unmentioned because including it would mean documenting a messier data flow than anyone wants to deal with.
Every boundary eventually gets tested with one question: "what actually connects to this system?" A boundary drawn for documentation convenience instead of architectural accuracy falls apart the moment that question gets asked. This guide exists so you answer it yourself, first.
How to Actually Draw a Defensible Boundary
- Map real data flows first, before drawing anything. What actually sends data into this system, and what does this system send data to?
- Include shared services and dependencies, even ones "owned" by another team — if your system depends on it to function, it's part of your operational picture.
- Document exclusions explicitly, with reasoning. The same discipline FIPS 199 categorization requires for impact levels applies here too.
- Ask the assessor's question before they do. Answer it yourself, in writing, before anyone else asks.
That third step is where most of the real damage happens later. A boundary without documented exclusion reasoning is a boundary nobody can defend when an assessor asks "what's this, and why isn't it included?"
Boundaries Drawn Too Wide
Defensible Boundary
Built from mapped data flows. Every connection accounted for, every exclusion justified in writing.
Over-Inclusive Boundary
Adjacent systems pulled in "just in case," without a real determination — creating unmanageable scope in the opposite direction.
Boundary creep isn't only about excluding things — sometimes systems over-include out of fear. The fix is the same either way: map what's actually true, and let the boundary follow the mapping, not the other way around.
Where Teams Get This Wrong
- Excluding "someone else's system" without documenting why — organizational ownership isn't the same as technical connection.
- Drawing the line right before the messy integration, because including it means more work.
- Treating the boundary as fixed forever, never revisited as systems change.
- Confusing who owns something administratively with whether it actually connects technically.
Why This Ripples Forward
Your boundary isn't just a diagram — it's the foundation for your control baseline, your SSP, and ultimately your assessment. If the boundary is wrong, everything built on top of it inherits that error.
Where to Go From Here
The honest test: can you name everything that connects to this system, and explain — in writing — why anything adjacent isn't included? If that answer doesn't exist yet, that's the actual next step.
System Boundary Worksheet
A fillable PDF that walks you through mapping every real connection your system has — direction, data type, and a written justification for anything excluded — plus a Boundary Defensibility Check before you call it done.
Choose Your Next Step
Download the Worksheet
Self-serve boundary mapping, guided step by step, with NIST SP 800-37 referenced throughout.
Get the TemplateTalk to MS Capital
Have someone who's carried the accountability for this call before get it right the first time.
Book a Discovery Call