Part 7 — Data protection and privacy engineering

G1 taught you to hash passwords and encrypt channels. This Part is the layer almost every guide skips: knowing what data you hold, protecting it at rest with a real key hierarchy, proving you can delete it across a distributed system on request, keeping it in the right jurisdiction, hardening the database it lives in, and governing who can access it. This is where security engineering meets privacy law and turns into architecture.

Chapter 41 — Data classification, inventory, and data-flow mapping

In one sentence

You cannot protect, delete, or report on data you haven't found and labelled, so classification and a living data-flow map are the prerequisite for every other chapter in this Part.

Where we are

Every control from here — encryption, erasure, residency, access governance — answers the question "for THIS data, given its sensitivity". Without an inventory, that question has no answer, and "we think we know where the PII is" is how breaches turn into surprises.

How it works

Classification tiers (a workable default):

   PUBLIC          marketing pages, published docs. No control needed.
   INTERNAL        internal wikis, non-sensitive metrics. Basic access
                   control.
   CONFIDENTIAL    business data, non-regulated customer data, source
                   code. Access control + encryption in transit +
                   logging.
   RESTRICTED      regulated categories: PII, PHI, PCI cardholder data,
                   auth secrets, biometrics, precise location, children's
                   data. Every control in this Part: encryption at rest
                   with a real key hierarchy, strict least-privilege
                   access, DLP, erasure support, residency awareness.

   Map REGULATORY CATEGORIES onto tiers, don't invent new taxonomy:
     PII (GDPR/CCPA "personal data" -- broader than people expect: an IP
       address, a device ID, a cookie ID, an email, precise location are
       ALL personal data under GDPR), PHI (HIPAA), PCI cardholder data
       (PAN, expiry, CVV -- CVV must NEVER be stored, G1 Ch 50),
       "special category" / sensitive data (health, biometric, racial/
       ethnic origin, religious belief, sexual orientation, political
       opinion -- GDPR Art. 9, extra restrictions), children's data
       (COPPA, GDPR Art. 8), secrets (keys, credentials -- G1 Ch 49).

Records of Processing Activities (RoPA) — GDPR Art. 30, and worth doing even if GDPR doesn't apply to you:

   For each processing activity, record:
     purpose            why you process this data
     categories of data subjects   customers, employees, prospects...
     categories of data           the classification tiers above, itemised
     recipients                    who you share it with (processors,
                                   sub-processors, other controllers)
     transfers                     to which countries (Ch 47)
     retention period              how long, and the deletion trigger
     security measures             a pointer to the controls in this Part

   This single document (kept current, not written once for an audit) is
   what makes a DSAR (Ch 46), a breach scoping exercise (G1 Ch 51), and a
   DPIA (Part 1 Ch 4's LINDDUN, and below) all tractable instead of
   archaeology.

Data-flow mapping (the technical companion to RoPA):

   A diagram (kept as code, alongside the threat model, Part 1 Ch 4) of:
     - every SOURCE of restricted data (signup form, webhook, import,
       third-party API, support ticket).
     - every STORE it lands in (primary DB, cache, search index, object
       storage, warehouse, logs, backups, a vendor's system).
     - every FLOW between them, and whether it crosses a trust or
       jurisdictional boundary.
     - every CONSUMER (a service, a human role, a third party, an
       analytics pipeline, an LLM feature).
   This is what lets you answer, in minutes rather than weeks: "if this
   customer asks us to delete their data, where do we have to go?"
   (Ch 46), "does this feature move EU data to a US region?" (Ch 47),
   "who can currently read this column?" (Ch 49).

Doing it in practice — automated discovery, because manual inventories rot:

   [ ] TAG at creation, not after the fact: every new table/column,
       bucket, topic, and log stream gets a classification tag in code
       review / IaC (Part 3), enforced by policy (a Kyverno/OPA/Terraform
       policy that requires a `data-classification` label).
   [ ] SCAN for what tagging misses: AWS Macie (PII in S3), GCP Sensitive
       Data Protection / DLP API, Azure Purview, or a self-hosted scanner
       (Presidio, an open-source PII detector) run continuously across
       storage, databases, and logs.
   [ ] REVIEW quarterly: reconcile the automated findings against the
       RoPA and the data-flow map; anything unclassified is a finding,
       not a shrug.
   [ ] CONNECT to every downstream control: your encryption policy
       (Ch 42), your erasure orchestrator (Ch 46), your access-review tool
       (Ch 49), and your DLP rules (Ch 49) should all key off these tags,
       not a separate parallel list.

Worked example

Discovering an unmapped PII flow before it becomes an incident.

   SecureShop's data-flow map lists: signup -> `users` table (RESTRICTED:
   email, name) -> `orders`/`invoices` (RESTRICTED: address, partial
   card) -> analytics warehouse (should be DE-IDENTIFIED, Ch 45) ->
   BI dashboards.

   A quarterly Macie scan flags: `s3://ss-support-exports/*.csv` contains
   email addresses and order totals -- a bucket NOT in the data-flow map.

   Investigation: a support tool integration exports a daily CSV of
   "recent tickets with order context" to that bucket for a third-party
   analytics vendor, set up eight months ago, never added to the RoPA or
   the data-flow map, no DPA on file, no encryption-at-rest key policy
   review, no entry in the erasure orchestrator's system list.

   Remediation: add the flow to the map and RoPA; get a DPA with the
   vendor (Ch 47); apply the SSE-KMS + bucket-policy controls from Part 2
   Ch 9; add the export to the erasure orchestrator (Ch 46); add the
   bucket to the quarterly access review (Ch 49). This is exactly the
   kind of gap classification-by-tagging-alone misses and continuous
   scanning catches -- BEFORE a regulator or a breach finds it for you.

Practice (60 min)

Pick a real system (or SecureShop). Draft a one-page RoPA for its three biggest processing activities.
Draw the data-flow diagram as code (Mermaid, alongside your Part 1 threat model) for one restricted-data type (e.g. customer PII) from source to every store and consumer.
Run an open-source PII scanner (Microsoft Presidio, or your cloud's native DLP) against a sample dataset / a storage bucket you own. Compare its findings to your map — what did it find that you didn't have mapped?
Add a policy-as-code check (Part 3) requiring a data-classification tag on every new S3 bucket / BigQuery dataset / RDS instance; test that an untagged resource fails the gate.
Set a quarterly calendar reminder (and a ticket template) for the scan-vs-map reconciliation.

Common mistakes

A classification policy that exists only as a document. If it doesn't drive tags, gates, and scans, it doesn't reflect reality within a quarter.
Classifying once at launch. New features add new flows constantly (the worked example). Continuous scanning is not optional.
Treating "no special category data" as "no PII." IP addresses, device IDs, and cookie IDs are personal data under GDPR even though they don't feel sensitive.
RoPA maintained only for an audit. It should be the single source of truth your erasure, residency, and access-review tooling reads from.
No connection between the map and the controls. A data-flow diagram that doesn't inform encryption policy, erasure scope, or access reviews is documentation, not a control.

Check yourself

What does a RoPA record for each processing activity?
Name four categories of data that count as personal data under GDPR even though people don't always think of them that way.
Why must classification be automated/continuous rather than a one-time exercise?
What three downstream controls should key off your classification tags?
In the worked example, what let the unmapped flow be found before an incident?

(Answers: Appendix G.)