- The asset inventory, or the honest admission that one does not exist yet
- A list of active contracts with data-handling clauses and markings
- Knowledge of where email, files, backups, and collaboration actually happen — including the unofficial paths
ATL-001WORKSHEETEDITORIAL REVIEW COMPLETE
System Boundary Definition Worksheet
A structured worksheet for drawing the line that every security decision depends on: which systems, people, locations, and services are inside the environment that stores, processes, or transmits sensitive contract information — and what is deliberately outside it, and why.
Using this artifact
Purpose, inputs, and completion
Purpose. Every safeguard, every requirement, and every assessment applies within a defined system boundary — yet most small contractors have never written theirs down. This worksheet produces the first defensible draft: what is in, what is out, why, and what enforces the difference. It feeds the system security plan; it is not one.
When to use it. Work through the sections in order with the people who actually handle contract data in the room. Expect the first pass to surface systems nobody mentioned in the kickoff meeting — that is the worksheet doing its job. Where a fact is uncertain, write UNKNOWN and log it in the final section rather than papering over it. Revisit at every significant system, provider, or contract change.
- Start from data, not from network segments: list where sensitive contract information enters, lives, moves, and leaves.
- For every system that touches that data, decide in or out — and for every 'out', write the reason and the mechanism that keeps it out.
- Interview the people who do the work, not just the people who run the systems; the boundary usually breaks at an unofficial workflow.
- Mark every cell you are unsure about UNKNOWN rather than guessing; the unknowns are the work plan.
Keeping it honest
Evidence, validation, and failure modes
- A dated, owned boundary statement a reviewer can be walked through
- An exclusion register with the enforcing mechanism for each exclusion
- A boundary-crossing list that seeds flow-control and interconnection decisions
- Pick three recent files or emails containing sensitive contract information and trace where each actually went; every location reached must appear on this worksheet.
- Ask the person who most recently onboarded: which systems did they get access to on day one, and are all of them classified here?
What looks done but is not
- The boundary is drawn around the network diagram instead of the data — then backups, personal devices, and SaaS tools turn out to be inside all along.
- Exclusions with no enforcing mechanism: 'the shop floor is out of scope' means nothing if the shop-floor PC can open the file share.
- The worksheet is completed once for a proposal and never touched again; an eighteen-month-old boundary is a work of fiction.
Mapped relationships
Practices and requirements this artifact relates to
Brilliant at the Basics practices
NIST SP 800-171 Rev. 2
NIST SP 800-171 Rev. 3
Relationships are mapped support, not equivalence: completing this artifact documents work relevant to these requirements and does not by itself address any of them. Retention: Retain every superseded version; the history of how the boundary moved is itself evidence a reviewer will ask about.
Full document
Preview — exactly what prints
WORKSHEET · GOVERNANCE & PROGRAM MANAGEMENTv1.0 · REVIEWED 2026-08-06
System Boundary Definition Worksheet
Brilliant at the Basics Resource Center · brilliantatthebasics.us · published by inDirectIT, Inc.
Independent educational material. Not affiliated with, sponsored by, approved by, or endorsed by the U.S. Department of War. Does not establish compliance, certification, or contractual standing.
Purpose
Every safeguard, every requirement, and every assessment applies within a defined system boundary — yet most small contractors have never written theirs down. This worksheet produces the first defensible draft: what is in, what is out, why, and what enforces the difference. It feeds the system security plan; it is not one.
How to use it
Work through the sections in order with the people who actually handle contract data in the room. Expect the first pass to surface systems nobody mentioned in the kickoff meeting — that is the worksheet doing its job. Where a fact is uncertain, write UNKNOWN and log it in the final section rather than papering over it. Revisit at every significant system, provider, or contract change.
Scope declaration
One paragraph, written last, summarizing the boundary the rest of the worksheet defends. If it cannot be written plainly, the boundary is not yet understood.
Declaration
| Environment name | One-sentence boundary summary | Effective date |
|---|---|---|
Write the summary for a stranger
A useful declaration reads like: 'Sensitive contract information is handled only in our business cloud tenant and on company-managed laptops; production machines, personal devices, and the guest network are excluded and blocked by policy X and network control Y.' If your draft needs three paragraphs of exceptions, the exceptions are the real boundary — document them below.
Information types handled
The boundary exists to protect information. Name what you actually handle — by category and marking, never by copying the content itself into this document.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| Information category | How it arrives | Where it is authorized to live | Contract or marking basis |
|---|---|---|---|
| EXAMPLE: Federal contract information (FCI) | Prime's procurement portal; email | Business cloud tenant only | FAR 52.204-21 clause in PO 4501 |
| EXAMPLE: Controlled unclassified information (CUI) | Marked drawings from prime | Segregated project library | DFARS 252.204-7012 flowdown; CUI markings |
In-scope systems and services
Everything that stores, processes, or transmits the information named above — including services a provider runs for you, and including backups.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| System or service | Type | Who operates it | Touches which information | Why it is in scope |
|---|---|---|---|---|
| EXAMPLE: Business cloud tenant (email, files) | SaaS | Internal + MSP | FCI, CUI | Primary storage and collaboration |
| EXAMPLE: Engineering workstations (12) | Endpoint | Internal | CUI | CAD work on marked drawings |
| EXAMPLE: Backup service | SaaS | MSP | FCI, CUI | Holds copies of everything above |
Deliberate exclusions
An exclusion is only real if something enforces it. Every row needs a mechanism, or it moves to the in-scope table.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| Excluded system or area | Why excluded | What enforces the exclusion | Verified how / when |
|---|---|---|---|
| EXAMPLE: Production CNC network | No contract data authorized there | Firewall rule blocks file-share and email reach; no browser on HMIs | Rule review + spot walk, 2026-07 |
| EXAMPLE: Personal phones | Policy prohibits contract data | No company accounts on unmanaged devices (conditional access) | Policy export, 2026-07 |
Exclusions meet reality on the shop floor
For OT environments, verify exclusions with the process owner during a maintenance window walkdown, not from a desk. A boundary claim about production equipment that was never physically verified is a finding waiting to be written — and changes to enforce an exclusion on live equipment need change control and a rollback, like any other OT change.
People and locations
| Group or role | Approx. count | Access to which information | Works from |
|---|---|---|---|
| EXAMPLE: Engineering | 8 | CUI project library | Main site + home offices |
Boundary crossings
Where information deliberately enters or leaves: portals, customer transfers, supplier exchanges, remote access. These rows seed your flow-control and agreement work.
| Crossing | Direction | Mechanism | Who authorized it | Agreement or control in place |
|---|---|---|---|---|
| EXAMPLE: Drawing exchange with prime | Inbound / outbound | Prime's transfer portal | Program manager | Contract data-handling clause |
Unknowns and next steps
The most valuable output of a first pass. Every UNKNOWN written above lands here with an owner and a date.
Open questions
| Unknown | Why it matters | Owner | Resolve by |
|---|---|---|---|
Document control, version history, and approval
An artifact without an owner, a review date, and an approval trail is a snapshot, not a record. Complete this section before the document is used, and update it at every review.
| Field | Entry |
|---|---|
| Document owner (named person) | |
| Suggested owner role | IT leader or compliance lead |
| Approval authority | Executive sponsor |
| Review frequency | Semiannual, and at every significant system or contract change |
| Next scheduled review | |
| Storage location of the completed document | |
| Retention | Retain every superseded version; the history of how the boundary moved is itself evidence a reviewer will ask about. |
Version history
| Version | Date | Author | Summary of change | Approved by |
|---|---|---|---|---|
Review and approval
| Reviewed by | Role | Date | Signature / initials |
|---|---|---|---|
Complete this offline — and mind what you write down
Fill this in inside your own environment, not on any public website or unapproved cloud tool. A completed copy may reveal your security posture: never include CUI, export-controlled data, credentials or keys, unremediated vulnerability details, network diagrams, or customer-sensitive information beyond what the artifact strictly needs, and store the completed document with the same care as the systems it describes.
What completing this artifact does and does not do
This is independent educational material. Completing it documents your work and produces records a reviewer can examine — it does not, by itself, implement a safeguard, satisfy any NIST SP 800-171 requirement, establish compliance with DFARS or CMMC, or replace your own analysis within your defined system boundary. Requirement references are mapped relationships, not equivalence claims. Tailor every section to your technical, operational, contractual, regulatory, and safety requirements.