Your application passed the hardened baseline. The containers run non-root with hardened images. The authorization artifacts are written. The AO signed. You're fielded.
Then someone asks: whose data is in this database?
The application stores government operational data. It also stores contractor-generated analytics, configuration data your engineering team maintains, user metadata, system logs, and cached intermediate results. Some of that data belongs to the government. Some belongs to you. Some of it is derived from government data and the ownership is contractually ambiguous. All of it lives in the same PostgreSQL instance, the same object storage bucket, the same Redis cache.
This is the data co-mingling problem, and it is invisible until the first time someone needs to answer one of these questions:
- A security incident occurs. Which notification obligations are triggered — government reporting timelines, or commercial breach notification, or both?
- The contract ends. Which data gets returned to the government, which gets deleted, and which do you retain as your own IP?
- A FOIA request arrives. Which data in the system is subject to it?
- A new program wants access to the system. Which data can they see, and which is restricted to the original program?
- Your database administrator runs a query for troubleshooting. Did they just access government data they're not authorized to see?
If you can't answer these questions from the system's architecture and operational procedures — if the answer requires someone to manually inspect records and make judgment calls — you have a data governance gap.
Why data co-mingling happens in DoW environments
Commercial applications aren't designed to separate data by owner. They're designed to serve users. A project management platform stores projects, tasks, documents, and comments in a shared schema. A data analytics platform stores ingested datasets, derived results, and user configurations in shared storage. The application doesn't distinguish between "government data" and "contractor data" because in commercial use, that distinction doesn't exist.
The distinction becomes critical the moment the application operates inside an authorized environment with government data. The data categories multiply:
Government operational data. Mission data, operational records, intelligence products — owned by the USG, subject to classification controls, retention schedules, and disposition requirements defined by the program.
Contractor IP. Your algorithms, your models, your application code, your configuration templates. Owned by you, governed by your contract's IP clauses, potentially subject to export controls.
Derived data. Analytics produced by running your algorithms against government inputs. Ownership depends on the contract — some contracts grant the government rights to derived products, others don't. If the contract is silent, the answer is litigation.
User metadata. Login records, access logs, activity trails. May contain PII. Subject to different retention and privacy requirements than operational data.
System data. Logs, metrics, cached intermediate results, temporary files. May inadvertently capture fragments of operational data. Often overlooked in data governance plans because it's "just infrastructure."
Multi-program data. If the system serves multiple programs, data from Program A must be invisible to users from Program B — even if both programs are USG. Need-to-know doesn't disappear because the data is in the same system.
All of these categories land in the same database, the same storage, the same cache. The application schema doesn't distinguish between them. The backup system captures all of them together. The incident response plan doesn't scope which notification obligations trigger based on which data was exposed.
What goes wrong
Incident response without data boundaries
A breach in a co-mingled environment triggers every notification obligation simultaneously — because you can't prove which data was affected. Government reporting timelines (often 1 hour for critical incidents) apply to the entire dataset because you can't scope the exposure to specific data categories. Your commercial breach notification obligations also trigger. The incident response becomes a worst-case exercise because the data boundaries don't exist in the architecture.
At GSA Schedule rates (~$175/hr for cleared cybersecurity staff), an incident response engagement that should have been scoped to one data category but instead consumes the entire dataset costs 2–5x more in forensic analysis alone. At commercial cleared rates ($200–$325/hr), that multiplier hits harder. An incident that could have been a 40-hour investigation becomes a 200-hour investigation — the difference between $7,000 and $65,000 at the low end.
Contract termination without data separation
The contract ends. The government wants its data returned and your copies deleted. Your IP — the models, the configurations, the proprietary analytics — stays with you. But the data lives in a shared PostgreSQL instance with no schema-level separation between government records and your records. The backup tapes contain both. The object storage bucket contains both. The Redis cache contained both until it was flushed.
Selectively deleting government data without affecting your own data is an engineering project that nobody scoped, nobody budgeted, and nobody planned for. Proving that the deletion was complete — as the contract typically requires — is harder still.
Privileged access without data-aware controls
Your database administrator troubleshoots a production issue. They run a query that returns government operational data they're not authorized to access. They didn't intend to access it — the data was in the same table as the system metadata they needed. But the access was logged, and if the system processes CUI or classified data, that access may constitute a spillage event with its own reporting and remediation requirements.
The DBA isn't at fault. The architecture is. The system doesn't distinguish between "contractor needs to see this to operate the system" and "this is government data the contractor can only access under specific authorization."
What multi-tenant data governance looks like
Solving this is not a technology problem — it's a design problem that touches architecture, operations, and contracts:
Data classification at ingest. Every record entering the system is tagged with its data category, owner, and handling requirements. The tags propagate through processing. Derived data inherits the most restrictive classification of its inputs.
Access control by data category. Roles map to data categories, not just to application features. A contractor operator can access system data and contractor IP but not government operational data. A government analyst can access operational data but not contractor IP. A DBA can access database metadata but not the contents of government data tables without explicit authorization.
Separate retention and disposition. Each data category has its own retention period, defined by its owner and the applicable regulatory framework. At contract end or retention expiry, each category is handled independently — government data returned and deleted, contractor data retained, derived data handled per contract terms.
Scoped incident response. The incident response plan distinguishes between data categories. A breach affecting system logs triggers different obligations than a breach affecting government operational data. The forensic scope is bounded by data boundaries, not by the entire dataset.
Contractual alignment. The data governance controls trace back to specific contractual clauses, regulatory requirements (CUI marking per 32 CFR 2002, ITAR/EAR, FISMA, program-specific data handling agreements), and data ownership terms. Every control exists because a specific obligation requires it.
When this surfaces
Data co-mingling risk surfaces during the authorization study — specifically in Tier 3 (Multi-Domain / Systems Authorization) engagements, where the system operates across security domains, serves multiple programs, or handles data from multiple classification levels.
A Tier 1 or Tier 2 fit study focuses on getting the application to run on the hardened baseline. Data governance concerns don't appear because the study uses synthetic data in an unaccredited lab. The co-mingling problem only becomes visible when the study scopes the system's operational data environment — who owns the data, where it goes, and what happens when things go wrong.
When the Tier 3 study identifies co-mingling risk, Millabs offers a follow-on Data Governance Implementation engagement ($25,000–$45,000, fixed fee, 3–4 weeks) that produces the Data Governance Plan, access control architecture, and gap register. The plan is operational — tied to the system's actual architecture and the specific data categories it will handle, not a generic policy template.
The cost of not doing it
Data governance gaps don't produce findings at the authorization gate. They produce findings during the first incident, the first contract transition, the first FOIA request, or the first multi-program access decision. By then, the cost of remediation is an order of magnitude higher than the cost of designing it correctly before the system handles production data.
The cleared cybersecurity staff who perform incident response, forensic analysis, and contractual data separation bill at the same GSA Schedule rates ($145–$200/hr) and commercial rates ($200–$325/hr) as the engineers who could have designed the controls upfront. The difference is that incident response is urgent, unplanned, and scoped by the worst case — while design work is planned, bounded, and scoped by the actual data categories.
A $25,000–$45,000 data governance engagement before production is cheaper than one incident response engagement after.
Robert Burckner is the founder of Millabs Corporation, a Service-Disabled Veteran-Owned Small Business. He has operated on both sides of the data boundary — as Division Chief at the Space Warfighting Analysis Center (USSF/NRO) managing compartmented programs, and as a contractor deploying commercial systems into those same environments.
If your system will handle government data alongside contractor data and nobody has designed the separation, contact Millabs.