Choose a system boundary that matches how work actually happens

A boundary is a description of the environment you intend to assess and operate. It is not merely the name of a software product. Management needs to understand what moves through the environment, which people support it, and what normal work would force outside it. A smaller boundary can reduce complexity only when the business can actually keep the promised separation.

32 CFR 170.19 requires the assessment scope to be specified before assessment and sets different scoping rules by level. This guide offers a management comparison method. It does not determine an asset category or promise that a proposed design will satisfy the rule.

Compare two operating models

Consider fictional Ridgeway Components. It can keep a new controlled engineering workstream in a separate environment, or expand controls across the existing workspace. The separate environment looks simpler on a diagram. During a trial, however, supervisors routinely print job sheets, a legacy machine needs a file transfer, and outside IT uses an existing administration tool. Those dependencies belong in the decision.

Neither column is a recommendation for every supplier. Ridgeway’s decision depends on the actual information, technology, staff and contract. The useful comparison is the cost and reliability of operating each option, including the steps needed to prevent ordinary workarounds.

Walk a complete job through the design

Choose a fictional or approved nonsensitive job and trace it from receipt to final retention or disposal. Include customer transfer, email notifications, editing, collaboration, local cache, backup, printing, external support and offboarding. Ask what happens during an outage. A boundary that works only on an ideal day needs another design review.

For each step, name the system, the person responsible and the policy or technical control that keeps the flow inside the intended route. Distinguish “this route is technically prevented” from “we told employees not to do that.” Both may be relevant, but they are different claims and need different evidence.

Make assumptions visible before purchasing

A vendor demonstration often shows a clean workflow with no legacy constraints. Bring the awkward cases to the demonstration: the production machine that cannot run the proposed client, a subcontractor on a different platform, a remote supervisor, or a printer shared with another team. Ask the provider to describe its responsibilities and the customer’s responsibilities for each case.

NIST SP 800-171 Revision 2 is an information protection requirements publication, not a shopping list of approved products. A purchased license does not establish implementation. Avoid turning a vendor’s marketing statement into an organization-wide compliance assertion.

Record the decision and the conditions attached to it

• Describe the workstream and the information basis.
• List entry, exit, support and recovery routes.
• Identify the applicable scoping source and qualified reviewer.
• State assumptions that must remain true for the design to work.
• Assign implementation owners and a controlled trial.
• Define changes that require a new scope review.

For Ridgeway, a sensible trial might test one job, one external transfer and one recovery exercise before broader rollout. Trial success is an operational finding, not an assessment result. Capture defects and revise the architecture before making commitments in a proposal.

The decision record can hold a high-level explanation and links to your internal approved documentation. Keep actual network diagrams, configurations and controlled files in your authorized systems. The public tool needs only nonsensitive references to support the next management conversation.