CTI under DFARS 7012: what counts and who it covers

Does controlled technical information under DFARS 7012 bring our systems into scope?

Controlled technical information is technical information with military or space application that is subject to controls on access, use, reproduction, release or dissemination, and that meets the criteria for distribution statements B through F. If your organization holds CTI in support of a contract, the systems that process, store or transmit it are covered contractor information systems under DFARS 252.204-7012, and NIST SP 800-171 applies to them. The question for a contractor holding drawings or technical data marked for restricted distribution is therefore not whether NIST SP 800-171 is a good idea, but whether the marked material falls within the clause at all.

Scope depends on two facts that your organization must establish and document: what the contract marks or identifies, and where the data actually goes. Review the distribution statement on each item, the contract's specifications and the data deliverables, then trace every copy through email, shared drives, engineering tools, backups and subcontractor exchanges. Information that is lawfully publicly available without restrictions is excluded, so the determination must rest on the access and dissemination controls that apply, not on how sensitive the material feels. Ask the contracting officer to confirm any marking you cannot resolve.

The organization owns this determination and the controls that follow from it. DeployOpen does not decide scope, issue a determination or perform the assessment. The adequacy review is carried out by the contracting agency, and a DCMA DIBCAC assessment, where one applies, is performed by the Defense Contract Management Agency. DeployOpen can help map where CTI moves through your environment and prepare the systems and evidence those reviewers will ask for. Read the DFARS 252.204-7012 clause text before you decide, and record the reasoning in writing.

How distribution statements B to F identify CTI

Distribution statement B limits release to U.S. government agencies. The controlled audience is government personnel, so the statement signals that the document is meant for government use and is not generally available to contractors. Under the DoD instruction, a statement is paired with a reason, a date or event, and a controlling office, and those details tell you who can authorize further release.

Audience: U.S. government agencies and their personnel.
Contractor access: Contractors generally receive the document only through written authorization from the controlling office.
Marking block: Read the reason, date and controlling office printed with the statement.
CTI status: A B statement on technical data with military or space application points toward CTI, even when no export marking appears.
Records: Keep the authorization letter or contract line that allowed the copy into your environment.

Before storing any B-marked document, confirm in writing that the statement and your authorization match the contract.

Which drawings, specifications and source code fall under CTI

Controlled technical information is defined by its subject matter and its access restrictions, not by its file type. The categories below cover the technical information most often found in defense work, along with how each is usually identified in a contract and what to check before treating an item as CTI.

Engineering drawings and lists

Engineering drawings and associated lists describe parts, assemblies and tolerances for military or space hardware. Drawings often carry a distribution statement in the title block or footer, which is the most direct marker of CTI. Check the statement against DoD Instruction 5230.24 criteria, then confirm that the associated parts lists and CAD files inherit the same restriction.

Specifications and process sheets

Specifications set performance, material and test requirements, while process sheets describe how a part is made. Both are frequently marked with a distribution statement from B to F on the cover page or header. Check whether the restriction applies to the whole document or only to certain annexes, because a mixed document may be partly CTI.

Technical reports and manuals

Technical reports, test results and operating manuals can reveal design or performance details even when no drawing is involved. These items are often identified by a restriction notice or by the contract's data item description rather than by a stamp. Check the contract's list of deliverables and the originating program office's marking guidance before deciding.

Research, engineering and test data sets

Data sets from research, engineering analysis or testing are technical data even when stored as spreadsheets or databases. A data set can be CTI when its content reveals military or space capability, even if individual values look ordinary. Check the source program, the originating contract's data rights clause and whether the set was generated in performance of the contract.

Executable code and source code

Computer software, including executable code and source code, is technical information under the clause's definition. Software for military systems often lacks a visible marking, so the restriction usually comes from the contract, the program's licensing terms or the release record. Confirm with the program office whether the code, its build scripts and its documentation are restricted before storing them in a shared repository.

Information that is already public

Information that is lawfully and publicly available without restriction is excluded from CTI, even if it describes a defense system. Before treating an item as public, check whether it was released through an official channel with no access controls, and whether the release was authorized. A public press release or a document found on the internet does not by itself make the underlying technical data public.

Why CTI makes a system a covered contractor information system

Controlled technical information is one of the two routes by which a contractor system becomes a *covered contractor information system* under DFARS 252.204-7012. The clause defines that term as an unclassified information system owned or operated by or for a contractor that processes, stores or transmits covered defense information. Covered defense information includes CTI that is marked or otherwise identified in the contract and provided by or for DoD, or CTI the contractor collects, develops, receives, transmits, uses or stores in performing the contract. The practical test for a contractor is therefore whether any engineering drawing, specification, technical report or source code subject to distribution statements B through F ever sits on, moves through or is written in a system the contractor runs, including a system a cloud provider or other third party operates for it.

The clause then sorts covered systems into two groups. Systems operated on behalf of the Government follow the cloud clause 252.239-7010 or other terms in the contract. All other covered contractor systems must implement NIST SP 800-171, and the clause set 31 December 2017 as the deadline for that implementation. Contractors should confirm in each contract which group a given system falls into, because a development environment that holds CTI for a DoD program usually falls in the second group even when the contractor never delivers it to the Government. DFARS 204.7304(c) directs contracting officers to include the clause in DoD solicitations and contracts, including those for commercial products and services, except those solely for commercially available off-the-shelf items. A contractor that receives CTI under a noncommercial contract should expect the clause and its system requirements to apply.

The 2026 contract vehicles add a version question. DoW Class Deviation 2026-O0025, Revision 3 has contracting officers use a revised DFARS 252.204-7012 that names SP 800-171 Revision 2 explicitly. A proposed FAR overhaul published on 23 June 2026 would instead require contractors handling CUI to comply with Revision 3. That rule was not final as of October 2026. The version your system must meet is therefore set by the contract text in front of you, not by the NIST publication you find first. Confirm the clause date and deviation language with the contracting officer, record the version in the system security plan, and plan for the possibility that a Revision 3 assessment will be required later.

How to confirm CTI is present before you scope a system

Whether a system is a covered contractor information system depends on whether it holds covered defense information, and CTI is one of its two main sources. The checks below work through where technical data came from, how it is marked, where copies have spread, and who created new material during performance. Record each finding so the scoping decision can be defended later.

Inventory technical data from DoD customers

Start with a list of every technical data package, drawing, specification, report, dataset and code repository received from a DoD customer or prime. Note the contract, the sender and the date received. Under DFARS 252.204-7012, technical information with military or space application can be CTI even when no one has labeled it, so the inventory should cover material you have not yet reviewed. Keep the list current as new deliveries arrive.

Review distribution statements and contract markings

Check each document for a distribution statement. Statements B through F under DoD Instruction 5230.24 mark information subject to access or release controls, which is the core test for CTI. Also read the contract for CUI identifiers and any list of information the government expects you to protect. A document with no statement may still qualify, so treat a missing marking as a question for the contracting officer, not as proof of absence.

Trace every copy of the data

CTI rarely stays in the system where it arrived. Trace copies into email, file shares, collaboration tools, engineering repositories, build servers and test environments. Each location that stores or transmits the data may be part of the covered system. Illustrative example: a drawing package attached to an engineering ticket and cloned into a build server creates three locations to assess, not one.

Identify who creates CTI during performance

Information your staff creates while performing the contract can also be covered defense information when it is technical in nature and falls within the contract's scope. Identify the engineers, analysts and subcontractors who produce designs, test results, code and reports for the program. Their working files, notes and drafts belong in the inventory, because new CTI can appear in systems that were never meant to hold controlled data.

Check whether the system touches CTI at all

Once the copies are traced, decide whether each system processes, stores or transmits CTI. Any single system that does is a covered contractor information system and must meet the NIST SP 800-171 requirements, while systems that never touch the data may fall outside that scope. Document the reasoning for each system, since the boundary decision drives the enclave design and the assessment that follows.

Record the decision and ask when unclear

Where distribution statements are missing, the marking is ambiguous or a prime's guidance conflicts with the data, put the question in writing to the contracting officer or the prime. Record the question, the answer, the date and the people involved in your scoping file. A written determination is the evidence an assessor will ask for when they test how you decided what to protect.

What the Raytheon and Nightwing settlement shows about DFARS 7012

The May 2025 settlement shows that a DFARS 252.204-7012 obligation does not stop at the systems a contractor sells or delivers to the Government. In that matter, Raytheon, RTX and Nightwing agreed to pay $8.4 million to resolve False Claims Act allegations that Raytheon failed to develop and implement a system security plan for an internal development system used for unclassified DoD work. The government also alleged failures to meet other DFARS 252.204-7012 and FAR 52.204-21 requirements between 2015 and 2021. The whistleblower received $1,512,000 under the settlement, according to the Department of Justice release.

For a holder of controlled technical information, the lesson is about where the data lives. Engineering drawings, specifications and source code that carry distribution statements B through F are covered defense information wherever they are developed, not only in the production enclave or the deliverable package. An internal development environment that builds, stores or transmits that technical data is a covered contractor information system, so it needs a system security plan and the NIST SP 800-171 controls that the plan describes. Teams often treat engineering tools as outside the boundary because they are not the system delivered to the customer, and that assumption is what the allegations targeted.

Before the next contract award, confirm which internal systems touch CTI. Map source code repositories, CAD and PLM systems, test data stores, build servers and engineer laptops against the data they hold, not against the org chart. Ask whether each system has a current system security plan, whether its controls are documented and whether the security posture reported for it is accurate. Illustrative example: a team that stores drawings in a shared engineering server and never added that server to its plan has the same exposure pattern the settlement describes, even if the production network is well managed.

Common questions about CTI and DFARS 7012

Can a contractor decide on its own that information is not CTI?

Not on its own. A contractor can reason about whether data is CTI, but the scope call belongs to the contracting officer and the organization together, and the contract's markings and identifications carry heavy weight. CTI is technical information with military or space application that is subject to controls on access, use, reproduction, release or dissemination, meeting the criteria for distribution statements B through F. Information that is lawfully publicly available without restrictions is excluded. Document the reasoning, ask the contracting officer in writing when the answer is unclear, and keep that record with the system security plan so an assessor can see how the decision was made.

Does source code count as controlled technical information?

It can. DFARS 252.204-7012 defines technical information as technical data or computer software, and its examples include computer software executable code and source code. Whether a particular repository is CTI depends on whether the code meets the CTI criteria, including military or space application and access or dissemination controls tied to a distribution statement. Engineering teams should not assume that code is out of scope because it is software. Ask the program office which repositories, build systems and artifacts carry distribution statements, and check whether development environments, CI runners and code review tools hold that material.

Is unmarked engineering data still CTI?

Marking is evidence, not the only test. Distribution statements B through F identify CTI, so a missing statement is a strong signal that the data may not be CTI, but the definition also asks whether the information is subject to access, use or dissemination controls. Unmarked engineering data received from a DoD customer or generated under a contract may still be covered as covered defense information if it is identified in the contract or collected in performance. Treat unmarked material as unresolved until someone with contract authority has reviewed it, and do not release it on the assumption that it is public.

Is a commercial product supplier in scope for DFARS 7012?

Often yes. DFARS 204.7304(c) prescribes clause 252.204-7012 for all DoD solicitations and contracts, including those for commercial products and services, except those solely for commercially available off-the-shelf items. A supplier of commercial products can therefore be bound by the clause if its contract is not solely for COTS items and if it handles covered defense information. Suppliers should read the solicitation and contract line by line, check whether technical data is delivered or generated, and confirm with the contracting officer whether the clause applies to their deliverables.

What must an organization do first when CTI is involved?

Start by identifying where CTI lives. Inventory the contract documents, drawings, specifications, source repositories, test data and reports that may carry distribution statements, and record which systems create, store, process or transmit them. Those systems become covered contractor information systems and fall under the adequate security requirement, which follows NIST SP 800-171 for systems not operated on the Government's behalf. Next, write down the scope decision, get the contracting officer's position in writing where it is unclear, and only then plan the enclave, system security plan and assessment. Organizations usually find this inventory takes longer than the technical work it triggers.

What can an outside partner do about CTI scoping, and what can it not do?

An implementation partner can map where CTI and related CUI sit in your environment, help build the boundary and evidence for NIST SP 800-171 controls, and prepare the documentation an assessor will review. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure and runs security testing. It does not decide what is CTI for your contracts, and it does not issue assessment reports or certifications. The organization owns its controls and the scope call, the contracting officer makes the contractual determination, and only an independent assessor or the DoD assessment process produces the formal result. Ask any partner to state these roles in the written scope before work begins.

What does the enforcement example teach about CTI?

It shows that the consequences fall on the contractor's system documentation and controls, not only on the data. The May 2025 settlement by Raytheon, RTX and Nightwing involved allegations that a system security plan was not developed and implemented for an internal development system used for unclassified DoD work, along with other DFARS 252.204-7012 and FAR 52.204-21 gaps between 2015 and 2021. The settlement totaled $8.4 million, and the whistleblower received $1,512,000, according to the Department of Justice. Development environments that touch technical data deserve the same scrutiny as production systems.

How DeployOpen helps scope CTI systems

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For controlled technical information, the work starts with deciding which systems actually hold, process or transmit it, so the covered contractor information system is defined before any build begins.

How we scope

Map where drawings, specifications and source code marked with distribution statements B to F are created, stored, shared and transmitted.
Identify every system, account and contractor-operated service that touches that technical information, including backups and collaboration tools.
Agree the boundary, deliverables and timelines in a written, fixed-scope agreement before work starts; ongoing support is available as a retainer.

How we build

Stand up or harden the covered environment with access control, encryption and audit logging mapped to the NIST SP 800-171 requirements in scope.
Configure self-hosted open-source platforms for document management, source control and ticketing so CTI is separated from unrelated data.
Test the configured controls against the SP 800-171A determination statements and record gaps for remediation before handover.

How we hand over

Deliver the system security plan draft, network and data-flow diagrams, and a configuration baseline for the scoped systems.
Provide evidence packages that show how each control is implemented, so your assessor can examine and interview against them.
Document operating procedures, administrator runbooks and training materials, and confirm ownership of every control with your team.

How we support

Support upgrades, backups and patching of the scoped platforms under a retainer where your contract calls for continued operation.
Re-test controls after material changes to the boundary, such as new subcontractors, new tools or new CTI repositories.
Your organization owns its controls and its assessment outcome; DeployOpen prepares systems and evidence, and only an independent assessor issues results.

Controlled technical information (CTI) under DFARS 7012