Data Governance: Classify, Catalog, and Control Your Information Assets

In 2023, a mid-tier defense subcontractor discovered during incident response that their development team had been loading production CUI into a test environment for eighteen months. The test database ran on an unencrypted instance with no access controls, exposed to a third-party CI/CD vendor. Nobody had classified the data flowing into that pipeline. Nobody had cataloged the test environment as a CUI-processing system. The DFARS 252.204-7012 reporting obligation surprised them.

This is not an edge case. It is the predictable outcome of building security programs without first answering the foundational question: what data do we have, where does it live, and what protection does it require?

Every security control in every compliance framework makes an implicit assumption --- that you know what you are protecting. Access controls assume you know which stores require restriction. Encryption policies assume you know which data demands it. Incident response plans assume you know what was compromised and what notification obligations follow. Skip data governance, and you are layering controls onto a foundation of guesswork.

Why Classification Is the Precondition, Not an Afterthought

Here is the hard-won opinion most data governance consultants bury in caveats: if you cannot produce a classified data inventory within 24 hours of an incident, your entire security program is built on sand. Every downstream control --- access management, encryption, DLP, retention, breach notification --- depends on classification decisions. Get classification wrong, and every control that references it inherits the error silently.

The timing pressure is real. CMMC Level 2 assessors now explicitly ask contractors to demonstrate how they identify and mark CUI across their environment. GDPR enforcement actions increasingly cite failures in data mapping (Article 30) as the root cause of inadequate breach response. And the proliferation of AI/ML pipelines means data is moving faster and further than governance programs designed for static databases ever anticipated.

Classification is not a labeling exercise you do once during an audit cycle. It is the continuous operational discipline that makes everything else work.

Classification Levels --- What They Mean Operationally

Classification assigns sensitivity labels that cascade into specific protection requirements. A practical taxonomy spans six levels:

Level	Impact of Disclosure	Examples
Public	None. Intended for external consumption.	Marketing materials, published policies
Internal	Minor inconvenience, no material harm.	Org charts, meeting notes, internal memos
Confidential	Competitive or financial harm.	Financial projections, contract terms, source code
Restricted	Significant harm to individuals or organization.	PII, PHI, payment card data, credentials
CUI	Harm to national security per 32 CFR Part 2002.	Export-controlled data, law enforcement sensitive, tax returns
Classified	National security damage requiring clearance.	Confidential, Secret, Top Secret per EO 13526

Each level drives specific, measurable control decisions:

Encryption: Restricted and CUI require AES-256 at rest and TLS 1.2+ in transit. Public data does not.
Access control: Confidential gets RBAC with quarterly reviews. Classified gets need-to-know with continuous monitoring.
Retention: Classification determines both minimum retention and maximum retention --- keeping data longer than required increases breach exposure.
Incident notification: A breach involving Restricted PII triggers state notification laws (24 hours in some jurisdictions). Internal data may require no external notification.
DLP policy: Classification labels determine which rules fire, preventing both over-blocking (alert fatigue) and under-blocking (actual exfiltration).

The CUI Challenge

CUI deserves special attention because it is the classification level most organizations mishandle. The National Archives CUI Registry defines 20 category groupings and over 125 specific categories, each with distinct marking, safeguarding, and dissemination requirements.

The challenge: CUI is not one classification --- it is a family. CUI marked "CUI//SP-EXPT" (export-controlled) has different handling requirements than "CUI//SP-PRVCY" (privacy). Organizations working under DFARS 252.204-7012 or pursuing CMMC Level 2 must identify which CUI categories they handle and apply corresponding controls from NIST SP 800-171. Misidentifying the category means misapplying controls --- and an assessor will catch it.

Data Catalog --- Inventory Before You Protect

A data catalog inventories every data store in your environment --- databases, file shares, cloud buckets, SaaS repositories, email archives, backup tapes, removable media --- annotated with classification, ownership, and access patterns.

Without a catalog, you are guessing. Most breaches involve data stores that nobody realized contained sensitive information: a development database loaded with production PII, a file share with export-controlled documents that migrated during a reorg, a decommissioned server with plaintext credentials in configuration files.

An effective catalog captures:

Data store identification: Every database, file share, object store, SaaS repository, and physical media location.
Classification mapping: What levels are present in each store. A single database often contains Public, Confidential, and Restricted data across different tables.
Data owner assignment: A named individual (not a team, not a role) responsible for classification decisions and access approvals.
System interconnections: Which applications read from or write to each store --- the attack surface is the union of all connected systems.
Regulatory applicability: Which frameworks apply to the data in each store (HIPAA, PCI DSS, ITAR, GDPR, CCPA, FISMA).

Building the initial catalog is labor-intensive. Every subsequent audit, risk assessment, and incident investigation becomes dramatically cheaper because you can answer the assessor's first question --- "what data does this system process?" --- definitively rather than speculatively.

Data Lineage --- Following Data Through the Pipeline

Classification tells you what data is sensitive. The catalog tells you where it lives. Lineage tells you how it got there and where it goes next.

Data lineage tracks the origin, movement, and transformation of data across systems. This matters for three operational reasons:

Compliance traceability. When a regulator asks where a specific customer's PII resides across your environment, lineage answers definitively. GDPR Article 30 requires records of processing activities --- lineage is how you produce them without a multi-week manual investigation.

Breach scoping. When an incident occurs, lineage determines blast radius. If a database was compromised, lineage shows which downstream systems received data from it and which upstream systems fed data into it. Without lineage, breach scoping becomes the exhaustive manual investigation that delays notification and extends exposure.

Export control compliance. For organizations subject to ITAR or EAR, lineage must capture geographic location at each processing stage. Data that transits through a non-approved jurisdiction --- even temporarily, even in a CDN cache --- may constitute an export violation. You cannot enforce geographic restrictions on data you cannot trace.

Lineage should capture: source system, ingestion method, transformation steps, destination systems, retention disposition, and for controlled data, geographic location at each stage.

DLP Integration --- Classification Labels Drive Enforcement

Data Loss Prevention is the enforcement mechanism for classification decisions. DLP monitors data in motion (network traffic, email, file transfers), at rest (file shares, databases, endpoints), and in use (clipboard, print, screen capture) --- applying rules based on classification labels.

The integration between classification and DLP is where governance becomes operational:

Public: No restrictions. Free to share externally.
Internal: Logged when shared externally. No block, but audit trail.
Confidential: Blocked from personal email, personal cloud storage, unmanaged devices. Security team alerted on attempted exfiltration.
Restricted: All Confidential rules plus endpoint controls --- print disabled, USB write disabled, screenshot blocked. Manager notification on any external sharing attempt.
CUI: All Restricted rules plus geographic restrictions. Data cannot leave approved enclaves. Incident ticket auto-generated on any policy violation.

Without classification, DLP rules are either too broad (blocking legitimate activity, generating alert fatigue) or too narrow (missing actual exfiltration). Classification makes DLP precise rather than noisy.

NIST SP 800-88 --- Media Sanitization Done Right

When data reaches the end of its retention period --- or when hardware is decommissioned, returned from lease, or transferred between classification levels --- destruction must be proportional to sensitivity. NIST SP 800-88 Rev. 1 defines three methods:

Clear. Logical overwrite of user-addressable storage. Appropriate for media reused within the same security domain. Standard overwrite with zeros or random data.

Purge. Physical or logical techniques rendering recovery infeasible using state-of-the-art laboratory methods. Cryptographic erase (destroying the key on self-encrypting drives), degaussing magnetic media, block erase on flash. Appropriate for media leaving organizational control.

Destroy. Physical destruction rendering media unusable. Shredding, disintegration, pulverization, incineration. Required for media that contained Classified or highest-sensitivity CUI categories.

Sanitization method maps directly to classification:

Classification	Minimum Sanitization
Public / Internal	Clear
Confidential	Purge
Restricted / CUI	Purge (Destroy for highest-sensitivity categories)
Classified	Destroy

Organizations must maintain sanitization records --- what media, by whom, what method, what date, verified by whom. These records satisfy the MP-6 (Media Sanitization) control in the Media Protection family and become auditor packet evidence.

Retention --- Keep What You Must, Destroy What You Should

Retention is the intersection of legal obligation and risk management. Keep data longer than required --- increased breach exposure. Destroy before the retention period expires --- regulatory violation.

Key regulatory retention requirements:

HIPAA: 6 years for policies, procedures, and documentation of required activities.
SOX: 7 years for audit work papers and financial records.
DoD contract records: 6 years and 3 months after final payment (varies by record type).
PCI DSS: 1 year audit log retention, 3 months immediately available.
GDPR: No fixed period --- delete when purpose for processing is fulfilled. "We might need it later" is not a valid purpose.
Federal Records Act: NARA-approved schedules. Unauthorized destruction is a criminal offense.

A defensible retention program requires: defined periods per classification and regulatory applicability, automated enforcement where possible, documented exceptions with business justification, and --- critically --- verified destruction when periods expire. Retention without destruction is just hoarding with extra paperwork.

Data Sovereignty --- Where Data Lives Is a Legal Decision

Data sovereignty means data is subject to the laws where it is stored or processed. This creates concrete technical requirements that classification informs:

GDPR: EU personal data transfers outside the EU require adequacy decisions, Standard Contractual Clauses, or Binding Corporate Rules.
ITAR: Technical data related to defense articles cannot be stored on servers accessible to non-US persons, including cloud infrastructure with multinational operations teams.
Federal contract residency: Some contracts require CONUS-only storage. Others specify FedRAMP-authorized environments with US-only operations staff.
Emerging regimes: China PIPL, Russia data localization, India DPDPA --- each jurisdiction adds localization requirements for multinational organizations.

Your data catalog must include geographic location. Your lineage tracking must verify data does not transit non-approved jurisdictions. Classification determines which sovereignty rules apply --- Public data has no geographic constraints, while CUI and ITAR data may have absolute ones.

The Compliance Connection

Data governance feeds directly into multiple NIST SP 800-53 control families:

Access Control (AC): Classification determines who accesses what. AC-3 (Access Enforcement) and AC-4 (Information Flow Enforcement) depend on knowing what classification each data flow carries.
Media Protection (MP): MP-6 requires sanitization methods mapped to classification levels.
System and Information Integrity (SI): SI-12 requires retention and destruction aligned to regulatory and operational requirements.
Audit and Accountability (AU): AU-11 specifies retention periods for audit logs that may vary based on the classification of systems generating them.

When your governance program is mature, these controls self-document. Classification labels prove access decisions are appropriate. Catalog entries prove you know where sensitive data resides. Lineage proves data flow enforcement works. Sanitization records prove media protection is real. Without governance, each control requires manual, point-in-time evidence that goes stale immediately.

Data Quality --- Governance on Bad Data Is Governance of Nothing

Data governance built on inaccurate data is worse than no governance --- it provides false assurance. Four quality dimensions must be measured continuously:

Completeness: Are required fields populated? A vulnerability scan record missing the asset identifier is useless for remediation tracking.
Accuracy: Does data reflect reality? An asset inventory showing 500 devices when the network has 2,000 provides dangerous false assurance.
Consistency: Same entity, same representation across systems? HR says "Department 4100," IT says "Engineering-West" --- reconciliation fails, controls gap.
Timeliness: Is data current? A compliance dashboard showing six-month-old scan results shows nothing useful.

Quality scoring is not optional polish --- it is how you know whether your governance program is producing reliable outputs or expensive fiction.

Key Takeaways

Classification is the precondition for every downstream security control --- get it wrong and errors cascade silently

CUI is not one classification but 125+ categories with distinct handling requirements

A data catalog answers the question every auditor asks first: "what data does this system process?"

Data lineage determines breach blast radius --- without it, scoping takes weeks instead of hours

NIST 800-88 sanitization method maps directly to classification level --- match destruction to sensitivity

Retention without verified destruction is hoarding, not compliance

Frequently Asked Questions

How do we classify data that spans multiple sensitivity levels?

Apply the highest classification present. A database containing both Public marketing copy and Restricted PII gets classified as Restricted for access control and encryption purposes. If operationally feasible, segregate data by classification so that controls can be applied proportionally --- but when in doubt, protect to the highest level present.

Do we need to classify every piece of data individually?

No. Classify at the data store and data type level, not the record level. Define classification rules by data type (all SSNs are Restricted, all CUI markings are CUI, all financial projections are Confidential) and apply them to stores. Individual record classification is only practical for document-centric environments with manual marking workflows.

How often should the data catalog be updated?

Continuously, through automation where possible. Discovery scans should run at least quarterly to identify new data stores. Classification reviews should trigger on system changes (new integrations, new data flows, infrastructure migrations). The catalog that is "updated annually" is the catalog that is wrong 11 months out of 12.

What is the relationship between data governance and CMMC?

CMMC Level 2 requires organizations to identify, mark, and protect CUI per NIST 800-171. This is impossible without a functioning data governance program. You cannot mark what you have not classified. You cannot protect what you have not cataloged. Assessors will ask how you identify CUI across your environment --- "we label documents when we create them" is not a sufficient answer for data that flows through automated pipelines.

How does data lineage differ from a network diagram?

A network diagram shows connectivity between systems. Lineage shows how specific data categories move between systems, including transformation, aggregation, and derivation. A network diagram tells you two systems can communicate. Lineage tells you that PII from System A flows through ETL Pipeline B, is aggregated in Data Warehouse C, and feeds Dashboard D --- each point being a classification enforcement boundary.

How Advisedly Helps

Advisedly integrates data governance directly into the compliance lifecycle --- classification decisions cascade into access controls, DLP policies, encryption requirements, and retention enforcement across 500+ frameworks simultaneously. The platform catalogs data stores, tracks lineage across system boundaries, maps sanitization requirements to NIST 800-88 levels, and generates the evidence that proves governance controls are operating --- not just documented. If your data governance exists only as a policy document that nobody follows in practice, reach out at begin@advisedly.ai