DATA GOVERNANCE AND CLASSIFICATION STANDARD

Classification Scheme · Labeling · Handling · Retention · Data Loss Prevention · Data Lifecycle

Table of Contents

1. Purpose and Scope
2. Principles
3. The Classification Scheme
4. Classifying Data
5. Labeling
6. Handling Requirements by Classification
7. The Data Lifecycle
8. Retention and Disposal
9. Data Loss Prevention
10. Roles and Responsibilities
11. Regulatory and Framework Alignment Summary
12. Document Control

1. Purpose and Scope

CERG protects data. Every other standard is, in the end, in service of keeping the right data confidential, intact, and available. Yet the program has had no general scheme for saying how sensitive a given piece of data is. The CUI Handling Standard governs one specific regulated category exhaustively; nothing governed the rest. The Asset Management Standard requires every asset to carry a data classification but pointed at a scheme that did not yet exist. This standard is that scheme.

This standard establishes the general data governance framework for CERG: the classification scheme, how data is classified and labeled, the handling requirements each classification carries, the data lifecycle, retention and disposal, and data loss prevention.

It applies to all data CERG-managed systems store, process, or transmit, in every environment. It does not replace CERG-STD-CUI-001; CUI is a regulated category with its own exhaustive handling rules, and where data is CUI, the CUI standard governs. This standard provides the general scheme into which CUI fits as the most restrictive category.

Classification Is Not About Labels. It Is About Treatment.

A classification scheme that produces labels and nothing else is a filing exercise. The point of classifying data is that the classification decides how the data is treated: who may access it, whether it is encrypted, how it is backed up, how long it is kept, and what happens if someone tries to send it outside. Section 6 is the part of this standard that matters. The scheme in Section 3 exists to drive it.

2. Principles

1. All data has a classification. Data is classified, explicitly or by a sensible default. Unclassified data is not a category; it is an unfinished task.
2. Classify by impact. Data’s classification reflects the harm that would result from its unauthorized disclosure, alteration, or loss, not who created it or where it lives.
3. The highest element sets the classification. A collection of data carries the classification of the most sensitive element it contains. A report that mixes public figures with one Confidential number is Confidential.
4. Classification drives treatment. The classification is the input to access, encryption, backup, retention, and monitoring decisions in the other standards. This standard produces the classification once.
5. Classification travels with the data. When data is copied, exported, or moved, its classification and its handling requirements move with it. A copy is not a way to launder a classification away.
6. Least data. Data that is not collected cannot be breached. The program collects and retains the data it needs and disposes of data it no longer needs.

3. The Classification Scheme

CERG uses four classification levels. An organization adopting CERG may rename the levels to fit its own conventions through CERG-GOV-VAR-001, but the four-level structure and its meaning are fixed.

Four Levels, Not Fourteen

The temptation in a classification scheme is to add levels until every shade of sensitivity has its own. A scheme with too many levels is one nobody can apply consistently, and an inconsistently applied scheme is worse than a coarse one. Four levels is enough to drive genuinely different treatment and few enough that every employee can learn them. Regulated categories like CUI are not new levels; they are Restricted data with additional handling rules layered on by their own standard.

4. Classifying Data

1. The data owner classifies. Every data asset has an owner, per CERG-STD-AM-001. The owner assigns the classification and is accountable for it being correct.
2. Classify at creation. Data is classified when it is created or acquired, not when someone later notices it is sensitive.
3. The default is Internal. Data created without an explicit classification is treated as Internal. The default is deliberately not Public; data is not exposed by omission. Data is not defaulted to Confidential either, because a default that over-classifies trains people to ignore the scheme.
4. Regulated data is classified by its regime. Data subject to a regulatory category, CUI, BES Cyber System Information, financial data in SOX scope, is classified at the level that regime requires, which is Confidential or Restricted, and handled additionally per the relevant standard or operational package.
5. Reclassification is deliberate. A classification changes only by a recorded decision of the data owner. Data is commonly declassified when it is approved for release, for example a financial figure once it is published. Lowering a classification is a decision, not a drift.

5. Labeling

1. Confidential and Restricted data is labeled. Data at the Confidential and Restricted levels carries a visible classification label wherever the format allows: document headers or footers, email subject or banner, dataset metadata.
2. Internal and Public labeling is recommended, not required. Labeling Internal and Public data is encouraged for clarity but not mandatory, so the labeling effort concentrates where it matters.
3. Labels are machine-readable where possible. Where the platform supports classification metadata, the label is applied as metadata, not only as visible text, so that data loss prevention (Section 9) and access controls can act on it.
4. An unlabeled Confidential or Restricted item is a finding. Discovering sensitive data with no label is a handling failure and is corrected.

6. Handling Requirements by Classification

This table is the operative core of the standard. It states the minimum handling for each classification. The other standards implement these requirements; this table is the single place they are stated together.

Encryption requirements are met using the algorithms and key management of CERG-STD-CR-001. Where a regulated category imposes a stricter requirement than this table, the stricter requirement governs.

7. The Data Lifecycle

Data moves through a lifecycle, and a handling requirement applies at each stage.

8. Retention and Disposal

1. Data has a retention period. Each category of data has a defined retention period, set by business need and by legal and regulatory obligation. The retention schedule is maintained by Governance.
2. Retention is enforced. Data is kept for its retention period and is disposed of at the end of it. Keeping data indefinitely “in case” is not a retention decision; it is the absence of one, and it grows the breach surface every year.
3. Legal hold overrides retention. Data subject to a legal hold is preserved regardless of its retention period until the hold is lifted. Legal hold is the one authorized reason to retain data past its schedule.
4. Disposal is secure and evidenced. Disposal of Confidential and Restricted data is secure, sanitization appropriate to the medium and classification, and produces a retained disposal record. Disposal of data assets is coordinated with asset disposal per CERG-STD-AM-001 §9.
5. Backups respect retention conceptually but follow their own cycle. Backup copies follow the backup retention cycle in CERG-STD-RES-001. Where a regulation requires data to be provably destroyed everywhere, including backups, that requirement is handled through the relevant operational package.

Data You No Longer Need Is Pure Liability

Old data has all of the breach exposure and almost none of the value. The customer records from a system retired six years ago cannot help the business, but they can absolutely be stolen. Retention discipline is one of the few security controls that reduces risk and reduces cost at the same time, because storing less data costs less and exposes less. CERG treats indefinite retention as a finding, not a safe default.

9. Data Loss Prevention

1. DLP monitors Confidential and Restricted data. Data loss prevention monitors for Confidential and Restricted data moving in ways its classification does not permit: leaving the organization by email, upload, or removable media.
2. DLP enforces, it does not only observe. For Confidential and Restricted data, DLP blocks or quarantines unauthorized movement, not merely logs it after the fact.
3. DLP uses the classification labels. DLP acts on the machine-readable labels from Section 5 and on content inspection. This is why labeling sensitive data is required, not optional.
4. DLP events are detection signals. A DLP block or alert is a signal delivered to the detection platform per CERG-STD-LM-001. A pattern of DLP events involving one user or one dataset is investigated.
5. DLP coverage spans the data paths. DLP covers the realistic exfiltration paths for the estate: email, web upload, cloud storage sync, and removable media. Coverage gaps are recorded as accepted risk until closed.

10. Roles and Responsibilities

Roles below are the canonical role names from CERG-GOV-OM-001 §6.1.

11. Regulatory and Framework Alignment Summary

12. Document Control

Revision History

Review Triggers

• New or changed regulatory data-handling obligation
• Revision of relevant NIST or ISO data-protection guidance
• A significant data-loss or data-exposure incident
• Internal audit or regulatory finding affecting data governance
• Direction from the CISO

Cyber Governance owns this document. The Governance Pillar Leader (Policy & Standards) is responsible for initiating reviews, managing the revision cycle, and obtaining CISO endorsement for all changes.

Related Documents

Source: standards/CERG-STD-DG-001_Data_Governance_and_Classification_Standard.md · Download .md · View on GitHub