The prime is accountable for its subcontractors' handling of controlled data. Not partially, not in a supervisory sense: if a subcontractor mishandles controlled unclassified information on a program, it is the prime that has the conversation with the contracting officer and the prime whose past performance record carries it. That accountability is why a modeling task, which by its nature wants to move a lot of data into a lot of places, is the flow-down question that most often stalls between a program security lead and a specialist subcontractor.
It stalls for a reason that is fixable. The flow-downs are written for the general case of a subcontractor performing work, and a modeling task raises specific questions the standard language does not answer: where the training extract lives, whether the data is used to improve anything the government did not buy, what happens to intermediate artifacts, and what a trained model itself is with respect to the data it learned from. A subcontractor who has thought about those questions before being asked is a different proposition from one who has not, and this article is about what the good answer looks like from the prime's side of the table.
What the prime is actually accountable for
Three things, and separating them clarifies most of what follows.
Flow-down. The data protection obligations in the prime's contract have to reach the subcontractor in the subcontract, in substance, without dilution. This is a contracting act and it is normally handled well.
Assurance. The prime has to be able to say what the subcontractor's posture actually is, not merely that a clause was included. When a customer asks whether the entity building the model can protect the data it holds, "we flowed the requirement down" is a weak answer. The strong answer describes the environment, the access model and the evidence.
Incident handling. If something happens at the subcontractor, the prime's own reporting obligations run on a clock, and the prime cannot meet them unless the subcontractor's obligation to notify is faster than the prime's obligation to report, and unless somebody has thought about who calls whom at what hour.
The second and third are where programs are usually thin, and both are addressable with artifacts a prepared subcontractor can produce in the first two weeks.
What gives a prime real assurance about a sub's data handling
Editorial weighting, illustrative rather than measured. The last row is deliberately low: a flowed-down clause is necessary and is not assurance.
The design that removes most of the problem
The cleanest arrangement for a modeling task on controlled data is that the data never moves. The subcontractor's engineers work inside the prime's environment, on prime- or government-issued identities, against data that stays where it already is, and the subcontractor's own corporate systems hold nothing but the ordinary business record of the engagement. Code lives in the program's repository. Model training runs on program infrastructure. Artifacts are produced and stay inside.
Where this is workable it should be the default, because it converts a long conversation about the subcontractor's security posture into a short one about access provisioning. It also makes the answer to the customer's question trivially strong: the subcontractor holds no controlled data, and here is how access is granted, logged and revoked.
What makes it unworkable, when it is unworkable, is usually the development experience. If the program's environment cannot support the tooling, the compute or the iteration speed a modeling task needs, the honest answer is that the team will work around it. Better to design the alternative than to have it happen quietly.
The enclave, when the data has to move
When some controlled data has to reach the subcontractor's environment, the design that works is a scoped enclave rather than a whole-company posture. The enclave is a bounded environment, separate from the subcontractor's general corporate systems, that exists to hold this program's data and nothing else. Six properties make it real rather than nominal.
It is separate at the identity layer, not just the network layer. Access is a distinct set of accounts, granted per person by name for this program, with the grant recorded and the revocation on the same list. A network segment reachable by anyone with a corporate login is not an enclave.
Its membership is a short, named list the prime can see. Every person with access, when they were granted it, why, and when it ends. This list is one of the two most valuable artifacts in the whole arrangement, because it is what turns an assurance statement into something checkable.
Data enters and leaves through a defined path with a record. Not by email, not by an ad hoc file share, not through a personal cloud drive. One mechanism, recorded, so the answer to what data exists outside the government's systems is a query rather than an investigation.
Endpoints are managed. Engineers reach the enclave from managed devices with disk encryption, current patching and endpoint protection, and controlled data is not stored on those endpoints. Where possible the work happens on infrastructure inside the enclave and the endpoint is a window rather than a container.
Logging exists and is retained. Authentication, access to data, administrative changes and data movement, retained long enough to be useful and reviewable by the prime on request.
It has an end. A defined disposition at the end of the task: what is returned, what is destroyed, when, and what evidence of destruction is provided. Written at the start, executed at the end, because the residual copy of program data on a subcontractor's storage two years after a task ended is a real and entirely avoidable risk.
The questions specific to a modeling task
Standard flow-down language does not reach these, and each of them should be answered in writing before the first extract is made.
What data is actually needed, and in what form. The first question a competent subcontractor asks is whether the full record is required or whether a subset, a redaction or a derived representation would do. Modeling tasks often need the structure of the data more than its content, and a task scoped to de-identified or synthetic data for development, with validation on real data inside the program's environment, removes most of the handling problem at modest engineering cost. This decision has to be made deliberately at the start; it cannot be retrofitted.
Where the training extract lives and how long. An extract is a copy, with its own location, its own access list, its own retention and its own destruction. Naming it in the plan, with a date, prevents the most common finding on this class of work: a copy of program data sitting in a development environment long after the reason for it ended.
Whether anything trains on the data other than the delivered model. The commitment the prime needs is explicit and broad: customer data is not used to train, tune or improve any model, product or service other than the deliverable itself; it is not sent to any external service that retains inputs; and no derived artifact leaves with the subcontractor at the end. That commitment should be in writing, from the subcontractor, and it should cover both hosted services the subcontractor might call and the subcontractor's own internal work.
What intermediate artifacts exist and how they are treated. A modeling pipeline produces feature stores, cached embeddings, evaluation outputs, error analyses and experiment logs, and some of these contain or reconstruct source content. They are program data and belong under the same handling and the same disposition as the extract itself. This is the item most often missed, because these artifacts feel like working notes rather than data.
What the trained model itself is. Treat the model artifact as derived from the data it was trained on and handle it accordingly, inside the enclave, delivered to the prime, not retained afterward. Where the task involves fine-tuning on sensitive content, assume the artifact carries something of the data and place it under the same controls rather than reasoning about whether it does.
| Artifact | Where it lives | Disposition at task end |
|---|---|---|
| Source extract from the program | Enclave storage, named location, access list | Destroyed, with written evidence to the prime |
| Derived features, caches and embeddings | Enclave only; never on endpoints | Destroyed with the extract |
| Evaluation sets and error analyses | Enclave, versioned with the code | Delivered to the prime, then destroyed locally |
| Trained model artifacts | Enclave, produced by the pipeline | Delivered to the prime; no copy retained |
| Code and infrastructure definitions | Program repository wherever possible | Delivered; assigned to the prime in writing |
| Experiment logs and notebooks | Enclave; treated as program data | Delivered or destroyed, decided in advance |
Handling questions a modeling task raises that standard flow-downs miss
Editorial weighting, illustrative rather than measured. The last row is deliberately low: tooling choice has almost no bearing on a data handling review.
The attestation the prime can put in front of the customer
The artifact that makes this whole arrangement easy is a short document, produced by the subcontractor, that a program security lead can hand to a customer or attach to a security package without rewriting it. Two or three pages, in the program's own vocabulary, covering seven things.
- What data the subcontractor receives, in what form, and why that form is the minimum needed.
- Where it is stored, by named system, and the boundary that separates it from everything else.
- Who has access, by name, with the grant and revocation process and the current list attached.
- How the data moves in and out, by named mechanism, with the record that is kept.
- What is logged, how long it is retained, and how the prime obtains it on request.
- The explicit statement that customer data trains nothing but the deliverable and reaches no external service that retains it.
- The disposition schedule and the evidence of destruction that will be provided.
Alongside it, a security posture summary describing the controls in place against whatever framework the program's requirement invokes, with the assessment or self-assessment status stated plainly, and the incident notification commitment with its timeline and named contacts.
A subcontractor who arrives with these documents drafted has removed weeks from the program's schedule and a category of risk from the prime's position. A subcontractor who responds to the request by asking what format the prime would like is telling the prime something useful about how this engagement will go.
Incident notification, arranged to actually work
Two details decide whether an incident is handled well, and both are cheap to arrange in advance.
The first is that the subcontractor's notification obligation is meaningfully faster than the prime's reporting obligation. If the prime must report within a fixed window from discovery, a subcontract that gives the subcontractor the same window guarantees the prime is late. The subcontractor's clock should be a small fraction of the prime's, and the obligation should trigger on suspicion rather than on confirmation, because confirmation takes longer than the reporting window allows.
The second is that notification goes to a named person with a phone number, not to a contracts mailbox. Programs discover on a Saturday that the notification path they wrote runs through an inbox nobody reads on weekends. Name two people on each side, exchange numbers at kickoff, and write the escalation into the operating documents rather than only into the subcontract.
Add one practice that costs almost nothing: the subcontractor preserves evidence rather than remediating first. The instinct on discovering a problem is to fix it, and fixing it can destroy the record the prime needs to characterize what happened and what data was involved. Agreeing this in advance is far easier than agreeing it during.
How we handle controlled data on a modeling task
Precision Federal builds AI and data systems and delivers them into production inside federal agencies, working as a specialist subcontractor under the prime's contract. Our default on any task involving controlled data is that the data does not move: our engineers work inside the prime's or the government's environment, on issued identities, and we hold no copy. Where the work genuinely requires an extract, we work in a scoped enclave with the properties above, and we bring the documents rather than waiting to be asked for them.
What the first weeks produce. Inside two weeks, a written data handling plan for this task: the minimum data needed and in what form, the named storage location and its boundary, the named access list with grant and revocation, the transfer mechanism and its record, the logging and retention, the explicit no-training commitment, the intermediate artifact inventory, and the disposition schedule with destruction evidence. Alongside it, our security posture summary and the incident notification commitment with named contacts. All of it drafted so the prime can hand it to the customer without editing it.
What continues through delivery. The access list stays current and is available to the prime on request. Data movement stays on the defined path. Intermediate artifacts stay inside the enclave and are inventoried. At task end, delivery and destruction happen on the schedule, with written evidence.
What the prime keeps. The code, the models, the pipelines, the evaluation sets, the infrastructure definitions and the documentation, under the prime's data rights posture as the government contract requires, transferred by a present written assignment rather than a work-for-hire recital. No copy of program data or derived artifacts stays with us. The customer relationship stays entirely with the prime, and our engineers speak to the government through the channel the prime designates. We are comfortable named as a subcontractor with a defined scope or working behind the prime's brand.
How it is priced in shape. Fixed-price milestones tied to written acceptance criteria, with the data handling plan as a first-milestone deliverable in its own right, or a committed team at agreed labor categories that maps into the prime's cost structure and the contract's rate schedule.
How to start. One email with a one-page brief: the program, the modeling task, what data it involves and its marking, the environment and who grants access, the flow-down requirements in the prime contract, the contract instrument and the date that matters. We return a scoped, priced statement of work and a draft data handling plan for the task.
Five ways this goes wrong
The extract is made before the plan is written. Everything after that is retroactive, and the question of what exists where becomes an investigation instead of a lookup.
Intermediate artifacts are treated as working notes. Feature stores, caches, embeddings and experiment logs are program data. Leaving them out of the inventory and the disposition is the most common gap on modeling tasks specifically.
The enclave is a network segment with corporate logins. Separation at the network layer without separation at the identity layer gives the appearance of an enclave and none of the assurance.
Notification runs through a mailbox. A path that depends on somebody reading an inbox will fail on the one occasion it matters. Named people, phone numbers, exchanged at kickoff.
Disposition is never executed. The plan says the data is destroyed at task end and nobody does it, because the task ended informally and the person who owned the enclave moved on. Put the destruction and its evidence on the closeout checklist as a condition of final payment.
Bottom line
The prime's exposure on a modeling task is manageable and mostly decided before any data moves. Prefer the arrangement where nothing moves at all: the subcontractor's engineers work inside the program's environment and hold no copy. Where an extract is genuinely needed, require a scoped enclave separated at the identity layer, with a named access list, one recorded path in and out, managed endpoints, retained logs and a written disposition. Require the modeling-specific answers the standard clauses miss: the minimum data form, the extract's location and lifetime, the intermediate artifact inventory, the treatment of the model itself, and an explicit no-training commitment. Then require the attestation in a form the customer can read, and a notification clock faster than the prime's own.
Frequently asked questions
The prime, in practice. Flow-down puts the obligation on the subcontractor, but the conversation with the contracting officer and the effect on the performance record land on the prime. That is why flow-down alone is weak assurance. The prime needs a description of the subcontractor's actual posture, a named access list it can inspect, logging it can request, and a notification obligation on a clock faster than its own reporting window, triggered on suspicion rather than on confirmation.
Preferably not. The cleanest arrangement is that the data never moves: the subcontractor's engineers work inside the program's environment on issued identities, code lives in the program repository, training runs on program infrastructure, and the subcontractor holds no copy. Where the environment cannot support the work, design a scoped enclave deliberately rather than letting the team improvise one, and scope the extract to the minimum form the task actually needs.
Separation at the identity layer, not only the network. Distinct accounts granted per person by name for this program, with grants and revocations recorded; a short named membership list the prime can see; one defined and recorded path for data in and out; managed endpoints where controlled data is not stored locally; authentication, access and administrative logging retained and reviewable on request; and a written disposition schedule with evidence of destruction at task end.
They are program data and belong under the same handling and disposition as the source extract. Derived features, cached embeddings, evaluation outputs, error analyses and experiment logs can contain or reconstruct source content, and they are the most commonly missed item on modeling tasks because they feel like working notes. Inventory them at the start, keep them inside the enclave and off endpoints, and name their disposition alongside the extract's.
An explicit and broad one: customer data is not used to train, tune or improve any model, product or service other than the deliverable itself; it is not sent to any external service that retains inputs; and no derived artifact leaves with the subcontractor at the end of the task. The commitment should cover both hosted services the subcontractor might call and its own internal work, and it belongs in the data handling plan the prime can hand to the customer.