Data Governance & Compliance

Context

Security Engineering Overview

Data governance only works in conjunction with security, SRE and data platform processes.

Data Governance & Compliance in architecture, these are not only legal documents, but specific technical solutions: data classification, access control, data lineage, PII handling, retention/deletion and a provable audit trail. The goal: a system that is both product friendly and regulatory compliant.

Governance principles

Data classification first

Separate data by sensitivity level: PII/financial/medical/public. Controls are built on a data class, not just a service.

Least privilege by design

Access to data should be the minimum required: role-based/attribute-based access, short-lived credentials, audited elevation.

Traceability

Each critical transformation of data must be observable: who changed it, when, from what source, and where the data went next.

Retention and deletion

Data storage periods and deletion should be automated at the storage and pipeline level, including backups and replicas.

Multi-region / Global Systems

Compliance always affects data placement and cross-region routing.

Open chapter

Regulatory framework: GDPR, Federal Law-152 and others

GDPR (EU)

Focus: Lawful basis, data subject rights, breach notification, data minimization, privacy by design.

We need DSAR processes (access/erase), data mapping, audit trail, regional restrictions and transparent consent flows.

FZ-152 (Russia)

Focus: Legal grounds for processing personal data, requirements for protection and organizational measures, local requirements for storage/processing.

PD inventory, cross-border transmission control, circuit segmentation and access logging are required.

CCPA/CPRA, PCI DSS, HIPAA (etc.)

Focus: Data subject rights, industry requirements for payment/health information security.

We need domain-specific controls: tokenization, field-level encryption, strict retention, evidence-ready audit logs.

PII handling lifecycle

Collection: collect only the required fields, enter purpose tags for each PII class.
Storage: at-rest encryption, separate keys/policies for particularly sensitive attributes.
Processing: masking/tokenization in analytical and non-prod environments.
Transfer: mTLS, data contracts, geo-aware routing and explicit control of interregional movements.
Access: JIT access, MFA for admin operations, regular recertification of rights.
Deletion: cascade deletion with checking downstream copies and backups.

Data lineage as architecture control

Metadata catalog

A unified register of datasets, owners, data contracts and data criticality.

End-to-end lineage graph

Connections source -> transform -> serving layer for impact analysis before changes.

Automated policy checks

Checks at the CI/CD and data platform level: PII cannot be output to an unauthorized circuit.

Incident-ready evidence

Logs of lineage and access events should allow you to quickly answer: what data is affected and where it is located.

Compliance-ready architecture checklist

Each critical dataset has an owner, sensitivity-tag and retention policy.

PII in logs and traces is edited/masked by default.

There is an automated pipeline for DSAR requests (access/correction/delete).

Data lineage is available not only to the platform team, but also to security/legal owners.

Regular compliance reviews are built into release governance and are not conducted ad-hoc.

Typical antipatterns

Collect excess PII “for the future” without a clear lawful purpose.

Store sensitive data in telemetry/logging without redaction.

Ignore backups and archives in your data deletion strategy.

Do data lineage manually in tables instead of an automated graph.

Consider regulatory compliance to be the task of the legal team only, without architectural restrictions in the code and platform.

References

This chapter is not legal advice: check the requirements in your jurisdiction with the legal/compliance function.