Know your data

A RoPA is a structured inventory: one row per processing activity, each row answering the same eight questions. It is the artifact every other governance activity depends on - you can't build a retention schedule, a transfer register, or a breach assessment without first knowing what activities exist and what data they touch.

• It's the DPO's single source of truth for "what do we do with personal data." When Mara (CEO) or the PDPC asks, you read from the RoPA, not from memory.
• It's activity-centric, not system-centric. One system (Redshift) hosts many activities; one activity (marketing) can span several systems. You inventory the activities.
• It directly satisfies part of the Accountability Obligation - being able to demonstrate, on paper, what you're doing and why.

New DPOs freeze trying to build the perfect complete RoPA on day one. Don't. A RoPA is a living record you grow and correct over time - a wrong-but-written row beats a perfect-but-imagined one.

• Start with the highest-risk activities - the ones from your Session 2 top-3 (marketing, the US analytics feed, keep-everything retention).
• Interview the activity owners: Deven (CPO) for product data, Ilsa (CRO) for marketing, Raj (Head of Data) for the warehouse and pipelines.
• Mark unknowns as open questions in the row rather than leaving it blank - a documented gap is itself governance progress.
• Set a review cadence. The RoPA drifts the moment engineering ships a new source; a quarterly refresh keeps it honest.

The controller/processor roles from Session 1 shape your RoPA. The duties and the record differ depending on which hat Himalaya wears for a given activity - and in a B2B2C platform, it wears both.

Keep separate RoPA entries for controller activities and processor activities. When the PDPC or a client asks "on what basis do you hold this?", the answer for processor data is "on our client's instructions, under our contract" - a very different answer from your controller data, and one you must be able to point to.

Reuse the ladder from Session 1, now as an operational label you stamp on every dataset. Classification is what lets you apply proportionate controls - you don't guard a public metrics table the way you guard health notes.

A data-flow map follows a category of personal data from where it enters to everywhere it ends up. It's the map that makes transfer and retention risks visible - a field you never drew is a field you can't govern.

• Pick a data category (say, consumer contact details) and trace it end to end: collected in the product module → landed in Redshift → copied to the marketing SaaS → sent to the US analytics vendor.
• Mark every cross-border hop and every third-party recipient - these are your Transfer Limitation and disclosure points.
• Note where data duplicates. Copies multiply risk: each place the data rests is another place it can leak or must be deleted.

Classification is not paperwork for its own sake - the tier a dataset carries decides the controls it earns. This is the bridge between today's mapping and the protection work in Sessions 5 and 6.

So classification isn't an academic label - it's the input that tells your engineers which masking, which access rule, and how long to retain. A dataset with no tier is a dataset with no defined controls, which is exactly how the near-miss happened.

A data catalog is a searchable index of your data assets - tables, columns, dashboards, files - with descriptions, owners, and classification tags attached. Think of it as a library catalogue for the warehouse: it answers "where does consumer email live?" in seconds, across all 40+ schemas.

• It discovers and indexes assets automatically, so it stays closer to current than a hand-kept spreadsheet.
• It's where your classification tags from Part 2 live at scale - tag once, and every downstream copy inherits the sensitivity label.
• It carries ownership - the named data owner/steward for each asset (formalised in Session 7).

A business glossary is the agreed definition of the terms your organisation uses, linked to the physical data that implements them. It closes the gap between what the business says and what the columns actually hold.

• It defines terms like "active consumer," "wellness client," or "prescribed data" once, so everyone means the same thing.
• Each glossary term links to the physical assets in the catalog - so "health note" as a concept points to the exact columns that store one.
• For a DPO it's how you make "sensitive/prescribed data" a precise, enforceable label rather than a fuzzy idea people interpret differently.

Data lineage traces data at the column and table level - where each field came from, what transformed it, and everywhere it flows downstream. It's the machine-generated version of the flow map you drew by hand in Part 2.

• Impact analysis: before you delete or change a field, lineage shows every downstream table, dashboard, and export that depends on it - so a retention deletion doesn't silently break a report.
• Audit trail: when the PDPC asks "how did this consumer's data reach the US vendor?", lineage is the documented answer, hop by hop.
• Breach scoping: lineage lets you trace exactly which downstream copies of an exposed table exist - the difference between "we think" and "we know" during a breach (Session 5).

Note the honesty rail: Collibra and Alation are the well-known platforms that provide catalog, glossary, and lineage together, but their hands-on configuration and vendor academies stay official. This course teaches the tool-agnostic capabilities so you can evaluate and direct any of them as the DPO - not operate one specific product.