Data Classification, Retention, Export and Deletion

Bounded lesson outcome

Data handling becomes unsafe when classification, retention, export, and deletion are treated as four independent checklists. The bounded outcome of this lesson is to build a local, inspectable lifecycle model that connects each synthetic record to a data class, purpose, owner, retention trigger/condition, export scope, deletion scope, hold state, and evidence of disposition. The evidence destination is Data Lifecycle Policy Evidence Record v1, and the executable fixture is SEC011-LAB1.

This lesson does not produce jurisdiction-specific legal advice, one universal retention period, or compliance certification. NIST Privacy Framework material is used only for risk-based privacy and data-processing lifecycle concepts. Every duration in the fixture is explicitly labeled SYNTHETIC_INTERNAL_POLICY; none is represented as law. Positive Evidence and Negative Evidence must come from local execution rather than from a prefilled conclusion.

1. Classification comes before lifecycle policy

A common failure is to treat all information as one generic “data” category and then apply one retention or export rule everywhere. A record is not defined only by its field names. Purpose and ownership are part of the decision boundary. The fixture contains three bounded classes: operational_profile, audit_event, and attachment_metadata. This is an instructional taxonomy, not a universal classification scheme.

In SEC011-LAB1, if an operational record is mutated into an audit class, the lifecycle decision must change. If classification can change without changing any policy outcome, classification has become decorative metadata instead of an enforcement input.

2. Purpose and owner are part of the boundary

Two records may look similar but exist for different processing purposes. A defensible lifecycle record states who owns the decision and which purpose is declared. Possessing a copy does not create export authority, and visibility does not create retention authority.

The local policy binds every class to an expected purpose and owner. A mismatch returns DENY_CLASS_PURPOSE_OWNER_MISMATCH. That denial does not prove law or compliance; it only prevents the shortcut “the system has the data, therefore any lifecycle action is permitted.”

3. Retention needs a trigger and an exit condition

A statement such as “keep this for 30 days” is weak without a trigger, owner, authority, and exit condition. Thirty days from what event? Which exception can suspend the transition? What evidence shows the retention state ended? In this lesson, a retention rule has trigger, condition, policy_authority, and exit_condition.

The fixture uses synthetic windows such as synthetic_30d_after_case_close and synthetic_180d_after_event. These are not legal requirements. Negative Evidence appears when the record class, purpose, or owner does not match a declared rule, or when no bounded retention rule exists. Every accepted decision says that it is valid only within this instructional policy.

4. Export requires authorization, minimization, and provenance

The ability to read data is not permission to export it. An export request identifies the requester, purpose, data class, and requested fields. The policy checks whether the requester is authorized for that class and whether the requested fields are a subset of an explicit allowlist.

In the baseline, role:support-exporter may export a narrow set of synthetic fields from operational_profile. A request for internal_trace exceeds the permitted field scope and must return DENY_EXPORT_FIELD_SCOPE. This is a defensive local probe; there is no real personal data or external destination.

5. Data possession is not export authority

Another common shortcut is to assume that a component holding data may automatically export it. SEC011-LAB1 tests the opposite. A reader can be a legitimate consumer without being an exporter. Export authority is a separate policy row.

Evidence therefore records requester, requested fields, observed decision, and policy basis. A generated file without the authorization decision is incomplete provenance. Data Lifecycle Policy Evidence Record v1 separates the observable output from the later policy inference.

6. Deletion is more than UI invisibility

Removing a row from a screen, or even from a primary table, does not by itself prove disposition. A lifecycle can include a primary copy, derivative copy, and backup boundary. This lesson does not claim that backups must or can be rewritten instantly. It requires the deletion scope and available evidence to remain explicit.

If primary_disposed=true while derived_disposed=false or no backup boundary is documented, the fixture returns DENY_DELETION_EVIDENCE_INCOMPLETE. A bounded completion requires owned primary and derivative copies to be disposed and a backup state such as DOCUMENTED_EXPIRY_BOUNDARY to be recorded. That result is not global-erasure proof.

7. A hold is a governed state, not a deleted policy

Normal lifecycle transitions sometimes need to pause. A hold should not erase the underlying policy or silently become unlimited retention. It has an owner, reason, and explicit state. While a hold is active, deletion returns DELETE_SUSPENDED_HOLD and preserves the reason in evidence.

The fixture uses SYNTHETIC_POLICY_HOLD, which is not a legal claim. The important Negative Evidence is that deletion remains blocked even if the rest of the disposition evidence looks complete.

8. Evidence of disposition must be traceable

Every lifecycle decision should connect to record ID, class, purpose, owner, and observed decision. “Deleted” or “export was safe” without traceable evidence is weak. The evidence artifact has ten required columns: Data Class / Purpose / Owner / Retention Trigger / Retention Condition / Export Scope / Deletion Scope / Hold State / Observed Evidence / Residual Boundary.

evidence_row_complete() requires all ten fields to exist and be nonblank. That check does not replace human review. It prevents an incomplete row from masquerading as a finished proof artifact.

9. Positive Evidence

The baseline produces several positive observations. A record with matching class, purpose, and owner receives a bounded retention decision. A correctly scoped export returns ALLOW_EXPORT_MINIMIZED. A deletion case with owned-copy disposition and a documented backup boundary returns DELETE_BOUNDED_DISPOSITION_RECORDED.

These observations prove only fixture behavior. They do not prove production privacy, security, or legal compliance. The policy explicitly carries production_proof=false to preserve that boundary.

10. Negative Evidence

Negative evidence is mandatory. Required probes include a class mutation, an over-broad export, a hold-active deletion, incomplete disposition, and a missing evidence field. Each probe should have a prediction before execution and preserve the raw observable afterward.

The goal is not exploitation. It is to see a control boundary in a harmless local model. No credentials, real personal data, production system, or network target is used. A learner who keeps only happy-path output has not completed the evidence standard.

11. Classification mutation

The first mutation changes a record from operational_profile to audit_event. If the old purpose and owner remain, the evaluator must deny the mismatch. If the record is fully rebuilt for the audit context, the retention rule must change from the operational rule to the audit rule.

This shows that policy is driven by declared semantics, not by record identity alone. It also prevents copy-and-paste lifecycle decisions.

12. Over-broad export mutation

The second mutation asks for a field outside the class allowlist. The request must be denied even if the requester is otherwise authorized for the data class. This separates action authorization from field minimization.

Preserving the denied export matters because it shows what shortcut was attempted and why it failed. Removing the negative row leaves the owner with a success-only narrative.

13. Hold mutation

The third mutation activates a synthetic hold with an explicit reason and owner. Deletion must pause. After the hold is released, the normal lifecycle rule can be evaluated again. This demonstrates that a hold suspends a transition without deleting the policy.

A hold without an owner or reason returns DENY_HOLD_METADATA_INCOMPLETE. Again, this is instructional metadata, not jurisdiction-specific legal authority.

14. Deletion scope and backup boundary

Deletion evidence distinguishes owned copies. Primary and derivative copies can be marked DISPOSED, while a backup can remain under a documented expiry boundary. The lesson deliberately avoids claiming instant backup erasure.

The residual boundary must say that infrastructure outside the fixture, actual backup implementation, legal retention requirements, downstream recipients, and third-party copies are not proven by this lab.

15. Changed-context transfer

The transfer task introduces a synthetic analytics dataset with different owners and purposes. The learner may not copy the first retention window or export scope. The lifecycle record must be rebuilt from the new context.

The transfer template deliberately leaves final_decision blank. AI may suggest defensive probes or organize observed local output, but it may not fill the decisive conclusion, residual boundary, or owner acceptance. Transfer independence is a completion requirement.

16. Assessment and blocking boundaries

Assessment covers retrieval, application, diagnosis, decision, and transfer. Application, diagnosis, and transfer are blocking. Answers must point to local evidence and must not invent jurisdiction-specific law.

A response fails the boundary if it declares one retention period universal, treats possession as export authority, treats UI invisibility as deletion proof, or promotes an NIST draft statement into a final mandatory requirement.

17. Source boundary and freshness

This lesson has exactly two frozen authorities: NIST-PF10 and NIST-PF11-STATUS. NIST-PF10 supports risk-based privacy/data-processing lifecycle concepts and is not used as jurisdiction-specific law. NIST-PF11-STATUS is used only to record the status of the update project.

A current-source recheck on 2026-09-16 found Version 1.0 still published as the final voluntary, risk-based Privacy Framework, while the official Version 1.1 page still describes 1.1 as an Initial Public Draft/update project and says final 1.1 is coming soon. No draft requirement is imported into the lab policy.

18. Residual Risk

Even when every local gate passes, production privacy/security, legal compliance, jurisdiction-specific retention, real infrastructure deletion, downstream recipients, and third-party copies have not been proven. Residual Risk must keep those limits explicit.

Summary

The compact rule is: classify before applying lifecycle policy; bind purpose and owner; define retention with a trigger and exit condition; authorize and minimize export independently of possession; prove deletion with scoped disposition evidence; model holds as governed states; and never invent legal requirements. Data Lifecycle Policy Evidence Record v1 must preserve Positive Evidence, Negative Evidence, transfer, and residual boundaries together.