Data Classification Policy Template (FIPS 199, ISO/IEC 27002 5.12)

Data Classification Policy: [Organisation name]

Organisation-wide policy that defines the data classification levels, the criteria and examples used to assign them, the labels that carry them, and the handling rules for each level across storage, sharing, export, printing, AI use, retention and deletion. It adds flags for personal data and for the special categories and criminal offence data of GDPR (Regulation (EU) 2016/679) Articles 9 and 10, owner duties, automated discovery and tagging, reclassification and exceptions. Impact levels follow the low, moderate and high model of FIPS 199 (February 2004), and the policy implements ISO/IEC 27002:2022 controls 5.12 (classification of information) and 5.13 (labelling of information), cited by number and short name only. Replace every [bracketed] value and every row marked Example. This is a documentation format, not legal advice.

Document control

Approvals

Revision history

Contents

• 1. Purpose, scope and basis
• 2. Roles and owner duties
• 3. Classification levels and criteria
• 4. Impact assessment method
• 5. Personal data and special-category flags
• 6. Labelling
• 7. Handling matrix
• 8. Derived, aggregated and AI data
• 9. Automated discovery and tagging
• 10. Reclassification and declassification
• 11. Exceptions
• 12. Compliance, monitoring and metrics
• 13. Traceability matrix
• 14. Glossary and references
• Standard and licence note

1. Purpose, scope and basis

1.1 Purpose

This policy makes sure that every data asset at [Organisation name] carries a classification that reflects the harm its loss, alteration or unavailability would cause, and that people and systems handle it with controls proportionate to that harm. It gives one shared vocabulary to security, privacy, data engineering, legal and business teams, so that a label applied in a source system means the same thing in the warehouse, a dashboard, a support ticket or an AI prompt.

1.2 Scope

The policy applies to:

• structured data in operational databases, data warehouses, lakehouse tables, streams, caches and search indexes;
• unstructured data in documents, email, chat, tickets, object storage and file shares;
• derived data: extracts, aggregates, features, embeddings, model training sets, model outputs, logs and backups;
• data held or processed by suppliers on behalf of [Organisation name];
• printed and other physical copies.

Out of scope: authentication secrets and cryptographic keys (see security/secrets-management-standard), and records retention periods (see data/data-retention-deletion-standard and compliance/iso-15489-records-schedule).

1.3 Basis

2. Roles and owner duties

Owner duties in detail:

1. Classify every dataset in the domain within [30] days of creation or of acquiring ownership, and record the decision in the data catalogue.
2. Record the reason for the level, using the criteria in section 3 and the impact assessment in section 4.
3. Review classifications at least annually and on any trigger listed in section 10.
4. Approve each access grant, share or export that the handling matrix marks "owner approval".
5. Respond to discovery findings (section 9) within the agreed time.
6. Keep classification consistent across copies: the source decides the minimum level for every derived dataset.

3. Classification levels and criteria

3.1 Levels

Rules:

• When in doubt, choose the higher level and ask the data owner.
• Unlabelled data is treated as Internal (C1) until classified, except when discovery detects personal data, which raises it to Confidential (C2) automatically.
• A collection of data takes the highest level of any element in it.
• Aggregation can raise the level (section 8.1).

3.2 Criteria

Apply the criteria in order. The first criterion that matches sets the minimum level. An owner may set a higher level with a recorded reason (for example security-critical records); never a lower one. Other documents that state a level (the record of processing activities, the records schedule, DPIAs and data sharing agreements) quote the level and the criterion ID, for example "Confidential (CR-05)", so that a reviewer can check the decision against this table.

3.3 Examples

4. Impact assessment method

FIPS 199 categorises information by the potential impact on the organisation, its assets or individuals if confidentiality, integrity or availability were lost. It uses three levels: low (limited adverse effect), moderate (serious adverse effect) and high (severe or catastrophic adverse effect). This policy uses those levels as the evidence behind a classification decision.

Steps:

1. List the information types in the dataset (for example customer contact data, order history, payment references).
2. For each type, rate the potential impact of loss of confidentiality, integrity and availability as low, moderate or high, with a one-line reason.
3. Take the highest rating for each objective across all types (the high-water mark).
4. Map the confidentiality rating to a level: low to Internal, moderate to Confidential, high to Restricted. Public needs an explicit publication approval, not only a low rating.
5. Record integrity and availability ratings in the catalogue; they set change-control, backup and recovery requirements in other standards.

5. Personal data and special-category flags

Every dataset and, where the catalogue supports it, every column carries the applicable flags below in addition to its level.

Rules:

• Free-text fields (notes, tickets, transcripts, prompts) get PD by default and are scanned for PD-SC content.
• The ANON flag needs a completed assessment in compliance/de-identification-assessment; removing names alone is not anonymisation.
• The DPO decides disputed flags.

6. Labelling

Labelling rules:

• Public data may be left unlabelled once approved; all other levels are labelled.
• Labels are applied by the producer at creation and inherited by every copy.
• Nobody removes or lowers a label without the procedure in section 10.
• Tag names and allowed values are maintained in a controlled vocabulary owned by the data governance lead.

Example dbt column metadata (from dbt 1.10, meta sits under config for columns as well as models; the older placement directly under the column raises a deprecation warning):

models:
  - name: dim_customer
    config:
      meta:
        classification: C2
        flags: [PD]
        owner: "@orders-data-owner"
    columns:
      - name: email
        config:
          meta:
            classification: C2
            flags: [PD]
            pii_type: email
      - name: support_note
        config:
          meta:
            classification: C3
            flags: [PD, PD-SC]

7. Handling matrix

7.1 Storage, access and transfer

7.2 AI use, retention and deletion

The AI rules apply to the AI Usage Policy (ai-data/ai-usage-policy) and to retrieval designs in ai-data/rag-system-design. Model outputs inherit the highest level of the inputs and retrieved context unless the owner reclassifies them.

8. Derived, aggregated and AI data

8.1 Inheritance and aggregation

• Inheritance: a derived dataset (view, model, extract, feature, embedding) inherits the highest level and all flags of its inputs. The platform propagates tags along lineage where the catalogue supports it.
• Lowering by transformation: a derived dataset may carry a lower level only when the transformation removes the reason for the higher level (for example aggregation to a minimum group size of [10], or removal of all personal columns), and the owner approves it under section 10.
• Aggregation raising: a combination of Internal datasets that reveals Confidential information (for example joining order lines, delivery postcodes and timestamps that together identify households) takes the higher level.

8.2 Machine learning and generative AI artefacts

9. Automated discovery and tagging

9.1 Discovery coverage

9.2 Workflow

Rules:

• A provisional tag from a scanner can raise a level but never lower it.
• Stewards review provisional tags within [10] working days; Restricted findings within [2] working days.
• Track precision and recall of each detection rule and tune rules with more than [20] percent false positives.
• Policy enforcement (masking, row filters, access denial) keys off the tags, so a missing tag is a control failure and is reported.

10. Reclassification and declassification

Triggers for review:

• new data elements or a new source joined into the dataset;
• a change of purpose or new consumers outside the original audience;
• an event that changes sensitivity (results published, product launched, contract ended);
• a de-identification assessment concluding the data is anonymised;
• an incident involving the dataset;
• the annual review date.

Declassification procedure:

1. The requester records the asset, current level, proposed level and the reason.
2. The data steward checks lineage: all upstream sources and downstream copies affected.
3. For PD flagged data, the DPO confirms the flag change.
4. The data owner approves or rejects.
5. The steward updates tags; the custodian confirms policies follow.
6. The decision is logged with date and approver.

11. Exceptions

Rules:

• Exceptions last at most [12] months and are re-approved to continue.
• Restricted-level exceptions need the policy owner and the DPO.
• The exception register is reviewed [quarterly] and reported to the risk committee; expired exceptions are closed or escalated.

12. Compliance, monitoring and metrics

Non-compliance is handled under the Information Security Policy (compliance/information-security-policy). Mishandling of personal data may also be a personal data breach and follows the incident response plan (compliance/incident-response-plan).

13. Traceability matrix

14. Glossary and references

14.1 Glossary

14.2 References

Standard and licence note

Based on NIST FIPS 199 (February 2004) and Regulation (EU) 2016/679 (GDPR), with structure aligned with ISO/IEC 27002:2022 controls 5.12 and 5.13, which are cited by number and short name only; no ISO text, tables or definitions are reproduced. NIST publications are US government works and EU legislation is free to reuse. NIST IR 8496 is listed as a draft whose development has ceased and is not used as current guidance. All policy text, levels, criteria and examples are original and use a fictional organisation. Check the current official versions and the consolidated GDPR text before use. This is a documentation format, not legal advice. Template licence: MIT.