Most information governance programs can tell you exactly what data they hold, where it lives, and who is responsible for it.
What they can't tell you is what happens to that data after it moves.
A technical drawing shared with a subcontractor. A financial model emailed to outside counsel. A CAD file downloaded to a field engineer's laptop for an off-site review. Each of those is a file that left the governed environment. The governance framework logged the departure. It had nothing to say about what happened next.
That's the gap that creates real exposure — for defense contractors managing CUI, for healthcare organizations managing PHI, for financial institutions managing NPI. The data is classified, the policies are written, and the files are unprotected.
What is Information Governance?
Information governance is the framework through which an organization defines, manages, and controls its information assets. At its core, it answers three questions:
What data do we have? Inventory and classification — identifying the types of data the organization creates, stores, and processes, and assigning sensitivity levels.
Who is responsible for it? Ownership and stewardship — defining which teams and individuals are accountable for specific categories of data and the policies governing its use.
What are the rules? Policy and compliance — establishing how data can be used, shared, retained, and disposed of, typically in alignment with regulatory requirements.
A mature information governance program covers all three. It gives compliance officers an auditable record of what data exists and under what policy it's governed. It gives IT teams the structure to implement access controls and retention schedules. It gives regulators the documentation they expect when they audit.
What governance frameworks are not designed to do is protect data at the file level once it crosses an organizational boundary. That's a different problem, and it requires a different layer.
Stop Writing Policies You Can’t Enforce
Knowing where your data lives (Governance) doesn’t stop it from being exploited after it moves. If your program doesn’t include file-level technical controls, you have a policy, not a security posture.
The Classification-to-Protection Gap
Data classification is the entry point for every information governance program. You categorize data by sensitivity — controlled unclassified information, proprietary, confidential, personally identifiable information — and attach policies to each category.
Classification is necessary. It's the foundation without which you can't make consistent decisions about access, sharing, or retention.
But classification is a label. It tells the file what it is. It doesn't protect the file from being opened, copied, forwarded, or accessed without authorization once it leaves the system where the classification policy was enforced.
Consider the most common scenario in a defense manufacturing environment. An engineer downloads a classified CAD file to work on a design during a supplier visit. The governance framework has classified that file correctly — it's CUI, governed by CMMC Level 2 requirements, access restricted to cleared personnel. The file is now on a laptop outside the facility, outside the secure network, outside the enforcement perimeter of every governance control the organization put in place.
The governance program documented what that file is, but nothing in it prevents unauthorized access to the file on that laptop.
This is the classification-to-protection gap: the distance between knowing what your data is and ensuring it's actually protected wherever it travels.
Why Information Governance Matters More Than It Used To
Three things have made the gap harder to ignore in 2026.
Data doesn't stay put. The average organization handles files across dozens of applications, storage platforms, and communication channels. Defense contractors share technical data with Tier 3 suppliers across the supply chain. Healthcare organizations send PHI to billing vendors, labs, and specialists. Financial institutions share NPI with processors, attorneys, and accountants. Governance policies cover what data can move. They don't control what happens to it after it does.
Regulations are enforced at the file level. CMMC Level 2 requires FIPS-validated encryption at the point of CUI protection, not just at the network perimeter, but on the data itself. HIPAA's Technical Safeguards standard requires access controls and encryption for ePHI regardless of where it exists. The FTC Safeguards Rule extends encryption obligations to NPI shared with third parties. Regulators are no longer satisfied with governance frameworks that classify data but don't protect it.
Attackers go for the files. Breach actors don't compromise governance frameworks. They exfiltrate files. And 100% of breached data in analyzed healthcare incidents was unencrypted — not because organizations didn't have governance policies, but because the files weren't protected at the file level. Governance documented what was stolen. It didn't prevent the theft from having consequences.
The Layer That Governance Needs
An information governance framework without file-level enforcement is a policy document. It describes what should happen, but it cannot ensure that it does.
The enforcement layer — what makes governance operational rather than theoretical — is protection that's embedded in the file itself, independent of the platform, network, or device it ends up on.
Per-file FIPS 140-3 validated encryption means every file carries its own cryptographic key. The classification policy becomes a technical control: a file classified as CUI can only be opened by users who satisfy the access conditions, on authorized devices, from authorized locations. If the file ends up somewhere it shouldn't — on an unmanaged laptop, forwarded to an unauthorized recipient, exfiltrated by an attacker — access is denied. The classification label on the file was never enough. The encryption makes the classification enforceable.
Context-aware access controls extend the governance model beyond the perimeter. Identity, device trust, location, and time all factor into whether access is granted. These aren't controls enforced by the network the file happens to be on; they're controls enforced by the file itself. They travel with the data.
For organizations building or maturing an information governance program, this is the layer that closes the gap between classification and protection.
Information Governance and CMMC: What Defense Contractors Need to Know
For defense contractors under CMMC Level 2 requirements, information governance isn't optional. The System Security Plan (SSP) — the document that forms the foundation of any CMMC assessment — is essentially an information governance artifact: it maps CUI, defines access controls, documents protection mechanisms, and traces accountability.
But the SSP describes the governance framework. The C3PAO assessor will want to verify that the framework is operational. Specifically:
SC.3.177 requires FIPS 140-3 validated cryptographic modules protecting CUI. Having a policy that says CUI should be encrypted isn't sufficient — the assessor asks for the CMVP validation certificate number for the specific module in use.
SC.3.187 requires that your organization manage its cryptographic keys. A governance framework that says "encryption is managed by our cloud provider" fails this control.
MP.2.121 requires media protection on contractor-controlled devices — specifically including the laptops and portable devices your engineers use when they download and work with CUI outside the facility.
Information governance provides the framework for knowing what CUI you have. File-level protection provides the enforcement mechanism that makes the governance real in the eyes of an assessor.
Building an Information Governance Program That Actually Works
The most effective governance programs treat classification and protection as two phases of the same process, not two separate workstreams. Classification without protection leaves the data exposed. Protection without classification is applied inconsistently.
The practical sequence:
Inventory and classify first. Know what data you have, where it lives, and what regulatory category it falls under — CUI, PHI, NPI, or proprietary. This is the governance foundation. Without it, you can't make consistent protection decisions.
Identify where data crosses boundaries. Map every path a sensitive file can take out of your governed environment: shared drives, email, file transfer, removable media, and cloud sync. These are the enforcement points where classification needs to translate into protection.
Apply protection at the file level. Encryption and access controls that travel with the file — not just at the storage layer or the network perimeter — ensure the classification policy remains enforceable after data moves. This is what turns governance documentation into operational security.
Generate the audit evidence. Per-file access logs, key management records, and access control documentation are what compliance assessors and regulators look for. The governance framework tells you what should be protected. The audit trail proves it is.
Close the Governance-to-Protection Gap
Information governance only works if the classification policy can travel with the data. Theodosian closes this gap by embedding FIPS 140-3 validated encryption and context-aware controls directly into every file, ensuring your data is self-defending, wherever it goes.
FAQs: Information Governance
What is the difference between information governance and data governance?
The terms are often used interchangeably. Data governance tends to focus on structured data — databases, data warehouses, analytics platforms — and is associated with data quality, lineage, and access control in IT systems. Information governance is broader, covering all information assets, including unstructured data such as documents, files, emails, and media. For most organizations, particularly those handling sensitive files such as technical drawings, clinical records, or financial documents, information governance is the more relevant term.
What does a basic information governance framework include?
At minimum: a data inventory that identifies what sensitive data the organization holds and where; a classification scheme that assigns sensitivity levels and corresponding policies; ownership and stewardship assignments that make specific teams accountable for specific data categories; and access and retention policies that define how data can be used, shared, and disposed of. Most compliance frameworks (CMMC, HIPAA, SOC 2) require some version of these elements as part of their technical and administrative controls.
Why isn't data classification enough on its own?
Classification identifies sensitive data and attaches a policy label to it. It doesn't technically enforce the policy once a file leaves the system where the classification was applied. A file classified as CUI that's downloaded to a laptop, forwarded by email, or synced to a personal cloud account is still classified — but the access controls that enforced the classification don't travel with it. File-level encryption extends classification into enforceable protection, wherever the file goes.
How does information governance support CMMC compliance?
The System Security Plan (SSP) required for CMMC Level 2 is a governance document — it maps CUI, defines access controls, and documents protection mechanisms. A strong governance program gives you the foundation for the SSP. The technical controls that the SSP describes — FIPS-validated encryption (SC.3.177), key management (SC.3.187), media protection on contractor devices (MP.2.121) — are what C3PAO assessors verify are actually in place. Governance tells you what should be protected; the technical controls prove it is.
What is the CMMC encryption requirement for CUI?
CMMC Level 2 practice SC.3.177 requires FIPS 140-3 validated cryptographic modules for protecting CUI. This is not satisfied by using AES-256 as an algorithm alone — the specific cryptographic module must hold a current CMVP validation certificate, and assessors ask for that certificate number. CMMC Level 2 also requires that FIPS-validated encryption cannot be deferred to a Plan of Action and Milestones (POA&M) — it must be fully implemented before a certification can be granted.
How long does it take to implement file-level governance controls?
For most organizations, deployment of per-file encryption alongside existing systems takes days rather than weeks. Theodosian is designed to work alongside existing storage platforms, collaboration tools, and Microsoft 365 environments, not replace them. The 14-day pilot demonstrates file-level protection active on your CUI, generating assessor-ready audit evidence automatically at every access event.