Scope is the lever, and it is a design decision
Most firms approach this backwards. They start with the control list, price out the tools, get a number that alarms them, and then look for discounts. The number was set two steps earlier, when somebody decided — usually by default, usually without noticing — how much of the company the controlled information would be allowed to reach. Every laptop, mailbox, backup set, file server and contractor phone that can hold that information is inside the boundary. Every one that cannot is outside it. Nothing else in this subject moves the bill as far.
The government expects you to use this lever. The rule is written around a defined assessment scope with an asset inventory and a documented boundary, which only makes sense if the boundary is something you draw rather than something you inherit. What the rule will not do is let you draw it on paper and leave the systems unchanged. A boundary is a claim about how information moves through your company, and an assessment is somebody checking the claim.
You are probably here because
- Somebody quoted you a number based on your total headcount and it made no sense
- You have a small defense line inside a mostly commercial business
- Your engineers use the same CAD and ERP systems for every customer
- You already built an enclave and are not confident it holds
The section on what follows the boundary is the one people wish they had read first. The section on leaks is where most enclaves actually fail.
How the rule divides your assets
At Level 2 the program rule sorts everything you own into categories with different consequences. The names matter because assessors use them, and the categories are where the argument happens.
Assets that handle the controlled information. Anything that processes, stores or transmits it. These are assessed against the requirements without qualification. This is the core, and it is the smallest list you can honestly draw.
Assets that provide security functions. Your identity provider, endpoint management, logging and monitoring, the firewall, and whoever administers any of them. These are in scope because they protect the core, whether or not the information ever passes through them. This category is where outsourced administration lands, and it is the one small firms most often miss.
Assets you manage by risk instead. Things capable of handling the information but not intended to, which you document in your inventory and your system security plan and manage under your own risk-based policies. This category looks like a discount and is really a trade: less control work, more documentation work, and an assessor who can look at any of it if your documentation does not convince them.
Specialized assets. Operational technology, test equipment, government-furnished equipment, and similar things that cannot reasonably be made to meet general-purpose requirements. These are documented rather than assessed the same way, which is a genuine and deliberate accommodation for manufacturers. The precise treatment has been adjusted before — read the current rule and the assessment guide rather than assuming what a vendor told you two years ago is still true.
Out of scope. Assets that cannot handle the information, separated physically or logically. “Cannot” is doing real work in that sentence. An asset that merely does not happen to hold any today is not out of scope; it is unmanaged.
| Category | What lands here | What it costs you |
|---|---|---|
| Handles the information | The enclave itself: workstations, file storage, the collaboration space, the transfer mechanism | Full control implementation and full evidence. Keep this list short. |
| Provides security functions | Identity, endpoint management, logging, monitoring, backup, the administrator — internal or outsourced | Assessed as part of your environment. This is where an outside IT firm enters your scope. |
| Managed by risk | Capable but not intended — a general file server, an engineering workstation on the same network | Documentation and policy, plus exposure to a closer look if the documentation is thin. |
| Specialized | Machine controllers, test rigs, government-furnished equipment, embedded devices | Inventory and plan entries. A real accommodation, not a loophole. |
| Out of scope | Separated systems that cannot receive the information | Nothing — if the separation is enforced rather than asserted. |
Level 1 works differently and more simply. Anything that handles federal contract information is in scope, there is no asset categorisation to reason about, and the whole exercise is a self-assessment against fifteen requirements. If you are at Level 1, this article is more machinery than your situation needs.
What follows the boundary wherever you put it
The most common enclave failure is not a leak of data. It is a diagram that shows a small box while the systems underneath reach everywhere. Five things follow the boundary whether or not the design acknowledges them.
Identity. If your enclave authenticates against the same directory as the rest of the company, the directory is a security function for the enclave and it is in scope. That is not automatically bad — a well-run directory with conditional access can serve both — but it has to be in the plan and the evidence rather than treated as background infrastructure.
Whoever administers it. Anyone holding administrative credentials is inside your security boundary, and for most firms under fifty people that is an outside IT provider. Their practices become part of your evidence. Find this out early, because a provider who has never been asked for control evidence will need months to produce it.
Backup. The classic quiet failure: a carefully separated environment with a backup job replicating to a general-purpose account outside it. Backups are copies. Copies are in scope.
Logging. Logs carry file names, user names, paths and sometimes content. A monitoring platform that ingests from the enclave is a security protection asset and it holds enclave-derived material.
The physical space and the people. Requirements cover physical access and the humans who have it. Training, screening where applicable, and the ordinary discipline of who is allowed in the room. That does not shrink because your enclave is virtual.
Where enclaves actually leak
Assume the architecture is sound. The leaks are almost never architectural; they are what people do to get their work done, and they are entirely predictable.
Email. Somebody forwards a drawing to a colleague, or a prime sends a package to a general mailbox because that is the address on the purchase order. Email is the single most common path by which controlled information arrives somewhere unscoped, and it usually arrives from outside, unannounced.
File transfer to and from the customer. The prime's portal, a shared drive, a link in a message. If receipt happens outside the enclave and gets moved in afterwards, the outside step is part of your scope.
Local copies. An engineer downloads a file to work on the train. A printout goes to the shop floor. A photograph of a screen ends up in a message thread. Controls exist for all three and they only work if somebody chose them deliberately.
The business systems everyone shares. Enterprise resource planning, quality management, product lifecycle management, the ticketing system, the estimating spreadsheet. These are shared by design, and the controlled attributes leak in as part numbers, specifications, drawing revisions and customer names. This is the hardest category and the one that most often decides against an enclave in a manufacturing business.
The helpdesk trail. Nobody attaches a controlled document to a ticket. They paste an error message, a file path, a screenshot. Across a year of tickets that is a searchable partial copy of the environment, sitting in a platform nobody scoped.
How well does an enclave hold in practice? — our read
Our judgment from designing these environments, not a survey. The bottom three rows are the situations where whole-company scoping is often cheaper than a boundary nobody can hold.
The four questions that draw the line
Before any tooling decision, walk the actual workflow with the people who do it. Not the process document — the work.
Where does the information enter? Portal, email, physical media, a customer system your people log into. Every entry point either becomes a controlled intake path or becomes a leak. There should be exactly one, and it should be boring.
Who touches it, by name? Not roles. Names. The list is almost always shorter than management expects and almost always includes two people nobody thought of, usually in quality and in purchasing.
Where does it come to rest? Every copy. The working directory, the archive, the backup, the email attachment, the printout, the analysis someone did in a spreadsheet last spring.
How does it leave? Delivery to the customer, disposal at end of contract, and the awkward middle case of a subcontractor of your own who needs part of it.
Do that honestly and the boundary draws itself. Skip it and you will get a boundary drawn around an org chart, which is the version that fails.
When whole-company is the cheaper answer
Enclaves have an ongoing tax: two environments to run, two sets of habits to maintain, and a constant enforcement burden on people who are trying to do their jobs. There are four situations where paying that tax costs more than not having it.
The firm is small and homogeneous. Below roughly fifteen people where everybody works on everything, the separation overhead can exceed the savings. One well-run environment with good identity, good encryption and honest logging is often simpler and more defensible.
Defense work is most of the revenue. If eighty percent of the business is inside the enclave, you have built a fence around your whole company and then paid to maintain the fence.
The core business systems cannot be split. If the ERP or the quality system has to carry the controlled attributes, that system is in scope and it touches everything. Fighting this usually produces an enclave that is technically real and practically ignored.
Enforcement is not credible. An enclave depends on people respecting a line every day under deadline pressure. If leadership will not back that up, whole-company scoping is the more honest choice, because the alternative is a documented claim your own staff disprove weekly.
Where this goes wrong
- A boundary drawn around an org chart instead of around where the data actually travels
- Forgetting the administrator, particularly an outsourced one, who is inside every boundary they can reach
- Backups replicating outside the enclave while the diagram shows one box
- Using the risk-managed category as a discount, without the documentation it actually requires
- An intake path through a shared mailbox, which is a leak that recurs on its own
- Assuming specialized-asset treatment from what a vendor said, rather than from the current rule
- Building the enclave before walking the workflow, and discovering purchasing needs access in month four
- Two environments and no enforcement, which is worse than one environment and honesty
Before you commit to a boundary
- Walk the real workflow with the people who do it, not the process document
- Name every person who touches the information, then check purchasing and quality
- List every place a copy comes to rest, including printouts and spreadsheets
- Trace identity, backup, logging, endpoint management and the administrator into or out of scope explicitly
- Choose one intake path and make every other one impossible, not discouraged
- Check whether your ERP or quality system carries controlled attributes
- Price the recurring cost of two environments against one, honestly
- Write the boundary down in the system security plan the way it actually is
- Verify the current asset categories in 32 CFR 170.19 rather than a vendor summary
Bottom line
Draw the boundary first, buy tools second, and let the workflow rather than the org chart decide where the line runs. An enclave is the right answer when defense work is a minority of the business, when a small named team does it, and when leadership will actually enforce the separation. Whole-company scoping is the right answer when the company is small and uniform, when defense is most of the revenue, or when the core business systems cannot be split without breaking the business. The wrong answer, and the common one, is an enclave on a diagram with a mailbox as its front door.
Frequently asked questions
A defined scope is expected. The rule is built around a documented assessment scope with an asset inventory and a described boundary, which is the structure an enclave uses. The condition is that the separation is real in the systems rather than only in the document, and that everything providing security functions for the enclave is included.
If they hold administrative credentials over the scoped environment, plan on yes. Anything providing security functions for that environment is in scope even when it never touches the information itself. Ask them early for their access list and their control evidence, because a provider who has not been asked before will take months to assemble it.
The rule has a specialized-asset category precisely because general-purpose requirements do not fit machine controllers, test rigs and government-furnished equipment. The treatment is generally documentation in the inventory and the plan rather than full control implementation, and it has been adjusted between rule versions. Read the current text of 32 CFR 170.19 and the assessment guide rather than relying on a vendor's memory.
Probably, and this is the question that most often decides the whole design. If controlled attributes live in a system that touches every department, the enclave concept starts to break down and whole-company scoping may genuinely be cheaper. Work this out before you build anything, because retrofitting a boundary around an enterprise system is the most expensive version of this project.
Often yes, and it is the part we most encourage firms to do themselves, because it depends on knowledge of your own workflow that no outsider has. Walk the four questions with your own people and write down the honest answer. Outside help is worth it when the boundary has to cross a production network, when several tenants or acquired companies are involved, or when a previous attempt already failed and nobody agrees on why.