Methodology
Stated plainly enough to argue with.
A scope that cannot be inspected cannot be defended. This page documents how a boundary is produced: what evidence makes an obligation binding rather than suspected, how information types and impact levels are assigned, what happens to an asset the evidence cannot decide, and what the output explicitly does not determine.
The workflow
Seven modules, in the order the work actually happens.
This is not a feature list. Each module consumes the previous one's output, and the engine's own code is organized the same way — one module per stage.
- 01
Ingest
Collect contracts, task orders, flow-downs, DD 254s, and security addenda into a controlled source set. Every document is digested so any later finding can be traced to the exact language that produced it.
- 02
Analyze
Detect clauses in the document text, normalize the obligations they create, and keep the quoted source span. A clause citation found in your document supports a confirmed obligation — not an inference.
- 03
Discover
Take in the data estate that actually exists: repositories, systems, endpoints, users, and external providers, each with the provenance of who declared it and how confidently.
- 04
Classify
Apply the NIST SP 800-60 categorization process. Assign information types and CUI Registry categories, set provisional FIPS 199 impact levels, and record the written rationale.
- 05
Map
Relate every obligation to the locations, systems, people, and providers it actually touches. This comparison is where under-scoping and over-scoping both surface.
- 06
Scope
Determine the boundary. State what is inside, what is excluded and on what basis, and what cannot yet be decided — along with the dependencies and assumptions the boundary rests on.
- 07
Evidence
Preserve decision records carrying source materials, rationale, authority, owner, and review cadence. Records are produced pending review; the engine never marks a decision approved.
The decision model
Every safeguard traces back to the language that requires it.
The chain is the product's central claim. Each link names what produced it, so a reviewer can walk backward from a control requirement to the clause in your contract — or forward from a clause to the systems it reaches.
- 01Contract clause
- 02Obligation
- 03Information type
- 04Classification rationale
- 05Data location
- 06System / user boundary
- 07Required safeguards
Obligation status
A citation in your document is not the same as language about the subject.
This distinction is the difference between reading a contract and guessing at one. Subject-matter language never produces a confirmed obligation, however suggestive it is.
| Status | What it requires |
|---|---|
| confirmed | The clause citation appears in an ingested document. The engine can quote the language and name the document and line. |
| strongly indicated | Subject-matter language appears in the source set but no clause citation was located. Not incorporation. |
| possible | Reserved for inference from outside the source set. |
Clauses the engine detects: FAR 52.204-21 · FAR 52.204-25 · DFARS 252.204-7012 · DFARS 252.204-7019 · DFARS 252.204-7020 · DFARS 252.204-7021 · DFARS 252.204-7008 · DFARS 252.239-7010 · 32 CFR 2002 · 22 CFR 120-130 (ITAR) · 15 CFR 730-774 (EAR) · DD Form 254 / 32 CFR 117 · FAR 52.224-1 / 52.224-2 / 52.224-3.
Classification
Information types, impact levels, and where they come from.
The engine applies the NIST SP 800-60 Volume I categorization process: identify the information types the obligations reach, assign provisional FIPS 199 impact levels, record the rationale, then derive the system security category as the high-water mark.
| Information type | CUI category | Provisional impact | Derivation |
|---|---|---|---|
| Controlled Technical Information CTI | Controlled Technical Information | C Moderate · I Moderate · A Low | Organization-defined type derived from the CUI Registry Defense grouping. The Volume II catalog has no contractor-held CTI entry; Volume I's method is applied to the category authority instead. |
| ITAR-Controlled Technical Data ITAR-TD | Export Controlled | C High · I Moderate · A Low person-based access restriction | Organization-defined type derived from the CUI Registry Export Control grouping and 22 CFR 120.10 technical data. |
| EAR-Controlled Technology EAR-TD | Export Controlled | C Moderate · I Moderate · A Low person-based access restriction | Organization-defined type derived from the Export Control grouping. |
| Covered Defense Information CDI | Controlled Technical Information | C Moderate · I Moderate · A Low | Contract-defined type from DFARS 252.204-7012, which reaches controlled technical information and other CUI marked or otherwise identified in the contract. |
| Controlled Unclassified Information (category not yet determined) CUI | — | C Moderate · I Moderate · A Low | Placeholder type used when a contract establishes CUI obligations but the specific Registry category has not yet been determined. It is a finding, not a classification. |
| Federal Contract Information FCI | — | C Low · I Low · A Low | Contract-defined type from FAR 52.204-21. FCI is not CUI; it carries the fifteen basic safeguarding requirements rather than 800-171. |
| Personally Identifiable Information PII | Privacy Information | C Moderate · I Moderate · A Low | Organization-defined type derived from the CUI Privacy grouping and the Privacy Act. Volume II contains agency personnel-management information types whose applicability depends on whether the contractor operates a system of records on the agency's behalf — verify before citing a catalog reference. |
| Proprietary Business Information PROPIN | Proprietary Business Information | C Moderate · I Low · A Low | Organization-defined type from the CUI Registry. |
| Classified National Security Information CLASSIFIED | — | Not categorized | Recorded for boundary purposes only. Classified information is categorized and protected under the NISPOM and applicable security classification guidance, not under FIPS 199 or this engine. |
On citing NIST SP 800-60 Volume II
Volume II is a catalog of information types written for federal agency mission and support functions. Most information a contractor holds does not map cleanly onto a catalog entry. Rather than assert a section number the engine cannot substantiate, types derived from a CUI Registry category or a contract obligation record that derivation and leave the catalog reference empty. An invented citation is worse than an honest derivation, and this audience checks.
Provisional impact levels below follow the NIST SP 800-60 Volume I method and the reasoning recorded in each entry's provisional_rationale. Entries whose catalog_ref is null are organization-defined types derived from a CUI category or contract obligation rather than lifted from the Volume II catalog; this is the expected case for contractor-held information and is not a gap. Where catalog_ref is present it is marked with its verification state and must be confirmed against the published volume before citation in an assessment package.
The boundary
Three dispositions, because two would force a guess.
Most scoping exercises produce a binary: in or out. That forces every ambiguous asset into one of two wrong answers. An asset the evidence cannot decide comes back undetermined and stays visible.
- in scope
Holds, processes, or transmits an information type that an obligation in the source set reaches.
- out of scope
Holds no such information type. The exclusion is recorded with its basis — a documented exclusion is what makes a narrower boundary defensible.
- undetermined
Cannot be decided from the current evidence. Never silently excluded: quiet exclusion is how a scope collapses under review.
Required safeguards
Baselines attach to information types, not to organizations.
| Baseline | Requirements | Families |
|---|---|---|
| FAR 52.204-21 basic safeguarding (fifteen requirements) | 15 | 6 |
| NIST SP 800-171 Rev. 2 (110 requirements) | 110 | 14 |
| CMMC (800-171 based at Level 2) | — | 14 |
| NISPOM (32 CFR 117) | — | out of scope |
Boundary-defining families
Some control families determine whether the boundary holds at all. Segmentation and access decisions made in these families are what make a narrower scope supportable, which is the whole cost argument.
Constraints beyond the control families
| Constraint | Source | Requirement |
|---|---|---|
| FedRAMP Moderate equivalent for external cloud services | 252.204-7012 | An external cloud service provider that processes, stores, or transmits covered defense information must meet security requirements equivalent to the FedRAMP Moderate baseline. |
| 72-hour cyber incident reporting | 252.204-7012 | Rapidly report cyber incidents affecting covered defense information or affected systems to DoD within 72 hours of discovery. |
| 90-day media preservation | 252.204-7012 | Preserve and protect images of known affected information systems for at least 90 days from incident submission. |
| Foreign-person access control (deemed export) | 22-120 | Release of controlled technical data to a foreign person, including within the United States, is an export requiring authorization. Applies to access by employees, contractors, and service providers. |
| United States data residency | 252.239-7010 | Government data and Government-related data must remain within the United States or outlying areas unless otherwise authorized. |
| CUI marking and dissemination controls | 32-2002 | Apply CUI banner and portion markings, limited dissemination controls where directed by the category authority, and decontrol procedures. |
Evidence
The engine produces the basis for a decision. A person makes it.
Every decision record is created in state pending_review with the owner role that should approve it. Nothing is self-approving.
| Record kind | Owner | Review cadence | Re-review trigger |
|---|---|---|---|
| classification | Information owner (with security concurrence) | 12 months | New award, modification, or CUI category change |
| boundary | CISO or system owner | 6 months | System change, new provider, or personnel change |
| obligation | Contracts manager | 12 months | Contract modification or new task order |
| open item | Assigned per item | monthly | Weekly until closed |
Boundaries
What this does not determine.
- Scoping decisions, not a compliance determination or assessment result.
- No CUI marking, export classification, CMMC, or FOCI determination is rendered.
- Decision records are produced pending review by an authorized owner.
- Not a verified inventory. The data estate is your declaration. Completeness is asserted, not proven by the engine — an asset absent from the inventory cannot be scoped, and the output says so.
- Not a substitute for the clause. A clause absent from the ingested source set is not evidence of its absence from the contract. Obligation summaries omit exceptions and alternates; anything turning on precise wording needs the clause as incorporated.