Chapter 16 · Security, Reliability, and Governance

Retention, Privacy, Lineage, and Data Quality

Governance becomes real only when ownership, retention, lineage, and quality expectations are represented by executable processes and evidence. Keeping data forever is not neutral: it increases cost, legal exposure, and the impact of security failures.

Intermediate160–195 minutesLifecycle governance + capstoneLast reviewed: August 2026

Learning outcomes

Turn governance expectations into repeatable controls

01

Design retention schedules from purpose, legal need, and operational value.

02

Distinguish deletion, anonymization, pseudonymization, archival, and legal hold.

03

Record lightweight lineage between sources, transformations, and outputs.

04

Define measurable data-quality dimensions and executable checks.

05

Assemble ownership, evidence, remediation, and review into a governance operating model.

Data has a lifecycle

Collect minimum necessary data
Validate + classify
Use for declared purpose
Share through controlled interfaces
Archive or restrict
Delete or irreversibly anonymize
Retain evidence

Lifecycle controls should be triggered by events and reviewed against documented purpose, not by indefinite storage defaults.

Retention policy as data

sqlite · retention policy catalog
CREATE TABLE retention_policy (    policy_code       TEXT PRIMARY KEY,    object_name       TEXT NOT NULL,    trigger_event     TEXT NOT NULL,    active_days       INTEGER NOT NULL CHECK (active_days >= 0),    archive_days      INTEGER NOT NULL CHECK (archive_days >= 0),    terminal_action   TEXT NOT NULL CHECK (        terminal_action IN ('delete','anonymize','review')    ),    owner             TEXT NOT NULL,    legal_basis       TEXT NOT NULL,    reviewed_at       TEXT NOT NULL) STRICT;INSERT INTO retention_policy VALUES('customer_profile','customer','account_closed',30,0,'anonymize','privacy','service + legal review','2026-08-01'),('sales_order','sales_order','order_completed',2555,365,'review','finance','financial recordkeeping','2026-08-01'),('security_audit','security_audit','event_created',365,730,'delete','security','security monitoring','2026-08-01');SELECT * FROM retention_policy ORDER BY object_name;

Deletion, anonymization, and pseudonymization

ActionMeaningCan the original identity return?
DeletionRemove the record and dependent copies according to policyNot from the deleted system; backups need separate expiry handling
Irreversible anonymizationTransform data so the person is no longer reasonably identifiableDesigned not to be reversible
PseudonymizationReplace direct identifiers with a token while retaining a re-identification pathYes, by an authorized holder of the mapping or key
Archival restrictionMove data to a less accessible tier for required retentionYes; access is limited, not eliminated
Legal holdTemporarily suspend normal deletion for specified recordsYes, until the hold is released

Privacy-aware erasure workflow

Do not delete blindly from the parent table. Discover obligations, active orders, legal holds, downstream copies, analytical exports, search indexes, and backups. Then execute an approved workflow with evidence.

sqlite · anonymize an eligible closed customer
BEGIN IMMEDIATE;-- Example eligibility: already deleted and no non-cancelled orders.UPDATE customerSET email = 'deleted+' || customer_id || '@invalid.example',    full_name = 'Deleted Customer',    date_of_birth = NULL,    marketing_consent = 0WHERE customer_id = :customer_id  AND deleted_at IS NOT NULL  AND NOT EXISTS (      SELECT 1      FROM sales_order AS o      WHERE o.customer_id = customer.customer_id        AND o.status <> 'cancelled'  );-- Remove a token that is not needed for financial recordkeeping.UPDATE sales_orderSET payment_token = NULL,    customer_id = NULLWHERE customer_id = :customer_id  AND status = 'cancelled'  AND changes() = 1;COMMIT;

Production code should verify affected-row counts explicitly and record the policy, approval, request ID, and outcome. Avoid relying on a long implicit chain of changes() calls.

Lineage as a graph

Lineage records which data products depend on which sources and transformations. It supports impact analysis, incident response, reproducibility, and ownership.

sqlite · lightweight lineage graph
CREATE TABLE lineage_edge (    upstream_object   TEXT NOT NULL,    downstream_object TEXT NOT NULL,    transformation    TEXT NOT NULL,    owner             TEXT NOT NULL,    code_version      TEXT NOT NULL,    observed_at       TEXT NOT NULL,    PRIMARY KEY (upstream_object, downstream_object, transformation)) STRICT;INSERT INTO lineage_edge VALUES('commerce.customer','reporting.customer_order_summary','join + aggregate','analytics','git:4ab7c2e','2026-08-05'),('commerce.sales_order','reporting.customer_order_summary','join + aggregate','analytics','git:4ab7c2e','2026-08-05'),('reporting.customer_order_summary','dashboard.executive_sales','semantic projection','bi-team','dashboard:v12','2026-08-05');SELECT upstream_object, downstream_object, owner, code_versionFROM lineage_edgeORDER BY upstream_object, downstream_object;

Quality dimensions and contracts

DimensionQuestionExample metric
CompletenessAre required values present?Non-null email rate
ValidityDo values satisfy format, domain, and range rules?Percentage of recognized status codes
UniquenessAre business identifiers duplicated?Duplicate active email count
Referential integrityDo references resolve?Orphan order count
TimelinessIs the data recent enough for its purpose?Minutes since latest successful load
ConsistencyDo related representations agree?Order total versus line-item sum
AccuracyDoes the value reflect the real-world fact?Sampled reconciliation against authoritative source

Executable quality checks

sqlite · quality result registry
CREATE TABLE data_quality_result (    check_name       TEXT NOT NULL,    measured_at      TEXT NOT NULL,    observed_value   REAL NOT NULL,    threshold_value  REAL NOT NULL,    comparison       TEXT NOT NULL CHECK (comparison IN ('<=','>=','=')),    passed           INTEGER NOT NULL CHECK (passed IN (0,1)),    details          TEXT,    PRIMARY KEY (check_name, measured_at)) STRICT;INSERT INTO data_quality_resultSELECT    'active_customer_email_completeness',    datetime('now'),    AVG(CASE WHEN email IS NOT NULL AND trim(email) <> '' THEN 1.0 ELSE 0.0 END),    1.0,    '>=',    AVG(CASE WHEN email IS NOT NULL AND trim(email) <> '' THEN 1.0 ELSE 0.0 END) >= 1.0,    'Expected 100% for active customer records'FROM customerWHERE deleted_at IS NULL;INSERT INTO data_quality_resultSELECT    'orphan_order_count',    datetime('now'),    COUNT(*),    0,    '=',    COUNT(*) = 0,    'Orders whose non-null customer_id does not resolve'FROM sales_order AS oLEFT JOIN customer AS c ON c.customer_id = o.customer_idWHERE o.customer_id IS NOT NULL  AND c.customer_id IS NULL;SELECT * FROM data_quality_result ORDER BY check_name;

Governance operating loop

Owner defines contract
Steward classifies + documents
Engineering implements controls
Automated checks produce evidence
Failures create accountable work
Review changes policy + thresholds

Governance is a feedback system with owners and remediation, not a static spreadsheet.

Governance review

  1. Why is indefinite retention a security decision?
  2. Why does pseudonymized data often remain sensitive?
  3. How does lineage help during a breaking schema change?
  4. What must happen when a quality check fails?
Review the answers

More retained data increases breach impact and operational exposure. Pseudonymization preserves a re-identification path and may remain linkable. Lineage identifies downstream consumers and owners before deployment. The failure needs severity, owner, evidence, remediation, and a decision on whether to block publication or continue under an explicit exception.

Chapter capstone checklist

Control familyRequired artifactVerification
Identity and accessRole matrix, owners, grants, exception approvalsAutomated success and denial tests
Injection preventionParameterized data-access layer and identifier allow-listsSecurity unit tests and code review
RecoveryBackup inventory, keys, restore runbook, dependency mapScheduled isolated restore with measured RPO/RTO
Protection and auditClassification catalog, encryption boundaries, audit schemaTLS verification, log review, key-recovery test
Lifecycle and qualityRetention schedule, holds, lineage, quality contractsDeletion/anonymization drill and quality evidence

Chapter summary

  • Authenticate every identity and authorize through role-based least privilege.
  • Keep untrusted values separate from SQL syntax with parameterized queries.
  • Measure recoverability through recurring restore tests, not backup-job success alone.
  • Layer encryption, masking, auditing, and classification according to explicit threats.
  • Govern data through purpose, retention, privacy workflows, lineage, quality checks, owners, and evidence.

Chapter 17 moves from governance to practical database access: SQL dialects, command-line and graphical tools, drivers, connection pools, prepared statements, ORMs, query builders, raw SQL, migrations, seed data, and database changes in Git.

References

Keep knowledge open

Help the academy stay free and grow.

If these tutorials save you time, a small donation supports new lessons, technical review, diagrams, examples, and long-term maintenance.

ETHEthereum / ERC-20 only
0x716c4Ab160C4B66F31a28AE2448BfF68fc3a2ef0

Send only assets compatible with the Ethereum/ERC-20 network. Do not send TRC-20/TRON assets.