A DPO who does everything alone is a single point of failure
You've mapped the data (S3), fixed consent (S4), drilled the breach (S5), and cleaned the lifecycle (S6). But if all of it lives in your head and your inbox, Himalaya's governance dies the day you take leave. Today we build the machine: the policies that set the rules, the decision rights that say who decides, the roles that spread the work across the business, and a maturity score that tells you - and the board - exactly where Himalaya stands and what to invest in next.
The governance operating model 7 min live
Governance is a team sport played by the whole business, not a solo act by the DPO. The operating model answers three questions: what are the rules (policies and standards), who gets to decide (decision rights), and who holds each seat (the roles). Get these named and the DPO stops being the bottleneck.
LivePolicies vs standards vs decision rights2 min▶
Three words people use interchangeably and shouldn't. They stack:
- Policy - the what and why. A short, board-endorsed statement of intent: "we retain personal data only as long as needed." Rarely changes.
- Standard - the how. The specific, testable rule that implements a policy: "consumer records are purged 90 days after client offboarding." Changes as systems change.
- Decision right - the who decides. The named authority to approve an exception, sign off a new dataset, or resolve a cross-domain dispute. This is the heart of governance.
Tools don't govern; decision rights do. A catalog can flag a policy violation, but only a named person with a decision right can say "approved" or "stop."
At Himalaya, "keep data safe" was a vibe, not a policy - so no one could say who approved the US-vendor transfer. You write a one-line transfer policy, a standard ("no overseas transfer without a signed comparable-protection clause"), and give the decision right to approve exceptions to the governance council - not to whoever set up the pipeline.
LiveThe roles - owner, steward, council, DPO office3 min▶
Four seats, four different jobs. Confusing them is why governance stalls.
| Role | What they're on the hook for |
|---|---|
| Data owner | Accountable for a data domain - a senior business person who answers for its correct, lawful use. Sets direction, approves access. |
| Data steward | Day-to-day quality and curation - definitions, fixing issues, keeping the domain healthy. Hands-on, closest to the data. |
| Governance council | Cross-domain decisions and priorities - resolves disputes between domains, sets shared policy, allocates investment. |
| DPO office | Privacy oversight - advises, monitors, and is the regulator/data-subject contact across every domain. Independent; does not own the data. |
Key distinction to hold onto: the owner is accountable (answers for it); the steward is responsible (does the work). The DPO advises them both and judges the privacy risk - but never becomes the owner, or independence collapses (Session 1).
Who owns Himalaya's consumer database? Not you - the DPO can't own the very data whose lawfulness you judge. It should be Deven (CPO), whose modules collect it: he's the accountable owner. A senior data engineer on Raj's team stewards it day to day. The council settles it when marketing and product disagree on how the consumer list is used.
Self-studyStewardship workflows - how issues get routed2 min read▶
Roles only matter if there's a path an issue actually travels. A stewardship workflow is that path:
- Detect - a quality check, a user report, or an access request surfaces a problem (e.g. duplicate consumer addresses).
- Route - it goes to the steward for that domain, not into a shared inbox nobody owns.
- Resolve or escalate - the steward fixes routine issues; anything needing a decision (an exception, a cross-domain conflict) escalates to the owner, then the council.
- Record - the fix and the decision are logged, so the next occurrence has a precedent and the DPO can evidence it.
Without a workflow, every issue lands on the DPO - the single point of failure we opened with. With one, most issues resolve at the steward tier and only genuine decisions reach the top. That's the machine working as designed.
Maturity: knowing where you stand 7 min live
You can't ask a board to invest without telling them where you are. A maturity model turns "governance feels weak" into a defensible score per capability, on a ladder everyone can read. Himalaya, honestly scored, sits near the bottom - and that low score is exactly what unlocks the Session 8 roadmap.
LiveWhat a capability maturity assessment is3 min▶
A maturity assessment scores each governance capability (say, data quality, metadata, protection, retention) on a ladder from "nothing in place" up to "optimised." The point isn't the number - it's the shared, evidence-based picture of where you are and where the gaps are.
The scoring idea is consistent across models:
- Score each capability on evidence - is there a documented, operating practice, or just intention? A policy that exists but nobody follows scores low.
- Score on engagement - is the business actually doing it, or is it a shelf document? Adoption matters as much as existence.
- Compare current score to a target - the gap between them is your investment case, capability by capability.
Score Himalaya's retention capability: there's no schedule, ex-client data lingers, "keep everything" is the norm. Evidence = none, engagement = none → it scores at the bottom rung. Do that across six capabilities and you have a one-page picture the board can't argue with - and a ranked list of what to fix first.
LiveHonesty flag - DCAM is the model, but member-gated2 min▶
Teach this straight. The leading data-management maturity model is DCAM (the Data Capability Assessment Model, from the EDM Council). It's the one large enterprises and regulators most often reference. But its exact component names and the full model are member-gated - you need EDM Council membership to use the official framework.
- So we teach the maturity / scoring concept - ladder, evidence, engagement, gap-to-target - which is public and transferable.
- We do not invent DCAM's official component names or pass off a made-up list as "the DCAM components." A DPO who fakes a framework loses trust the moment they meet someone who has the real one.
- If Himalaya needs a formal DCAM assessment, that's an EDM Council engagement - name it as such to the board rather than improvising.
Self-studyUsing a maturity score to get board investment2 min read▶
A maturity score is a fundraising tool disguised as an assessment. The move:
- Show the picture - current score per capability, most in the red. Boards respond to a heat map far better than to prose.
- Anchor to risk - tie the lowest scores to the concrete exposure: the near-miss breach, the unlawful transfer, the missing DNC check. Low maturity = the fine waiting to happen.
- Set a target and a cost - "move retention and transfer from rung 1 to rung 4 in 12 months, here's the headcount and tooling." Specific asks get funded; "we need to do better" doesn't.
- Re-score to prove ROI - come back next year with the same ladder and show movement. That's how you keep the budget.
Himalaya scores low/conceptual on most capabilities today. That's not a failure to hide - it's the baseline that makes next year's improvement visible, and it becomes the backbone of the Session 8 first-90-days roadmap and board report.
Data quality as a governed capability 6 min live
Quality isn't a nice-to-have that lives on the data-engineering team - it's a governed capability the operating model owns, and it's what makes the Accuracy Obligation (Session 6) real. If users can't trust the data, no amount of policy will save you.
LiveQuality dimensions feed trust2 min▶
DAMA frames data quality as a set of measurable dimensions: accuracy, completeness, consistency, timeliness, validity, and uniqueness. A governed program doesn't just hope for quality - it measures each dimension, sets thresholds, and surfaces the result where users will see it.
- Quality signals feed the catalog (Session 3): a dataset carries a visible trust indicator, so an analyst knows before they build on it whether it's reliable.
- Quality ties directly to the Accuracy Obligation (Session 6): the controls that keep data accurate are your quality capability, now owned and measured, not left to chance.
- The steward runs the day-to-day quality checks; the owner is accountable for the domain hitting its thresholds; the DPO cares because inaccurate personal data used for decisions is a legal risk, not just an analytics one.
Himalaya's three-conflicting-addresses problem from Session 6 is a consistency and uniqueness failure. As a governed capability, the steward sets a source-of-truth rule and a dedupe check, the catalog shows a trust score, and the wellness client stops routing a health notice to the wrong address. Quality control and the Accuracy Obligation are the same fix wearing two hats.
Design Himalaya's stewardship org and score its maturity ★ 19 min · on Himalaya
Two artifacts that turn you from single-point-of-failure into a program: a stewardship org (who owns and stewards what) and a maturity scorecard (where Himalaya stands). We build both for Himalaya together, then you repeat on your own org for homework.
Himalaya - one overloaded new DPO (you), no named data owners or stewards, no council, "keep data safe" as a vibe not a policy, and governance capabilities that mostly score at the bottom rung. Today you assign the seats and put a number on the gap.
Assign owners and stewards for the top 3 datasets. Consumer database (owner: Deven/CPO), warehouse pipelines (owner: Raj), marketing contact list (owner: Ilsa/CRO). Name a steward for each. You (DPO) advise all three, own none.
Draft one data policy. Pick retention or access. Write it as three lines: the policy (what/why), one standard (the testable rule), and the decision right (who approves exceptions - the council).
Build a maturity scorecard. List ~6 capabilities (consent, retention, transfer, protection, quality, metadata/catalog). Score Himalaya 1-5 on each, with one line of evidence per score. Most will land low - that's honest.
Identify the biggest gap. Rank the capabilities by risk-weighted gap. For Himalaya the transfer and retention gaps tie to concrete legal exposure - those lead the Session 8 roadmap.
Keep the honesty flag. Label the scorecard "DCAM-style maturity concept" - not "the DCAM assessment." Note that the certified version is an EDM Council membership engagement.
Try it yourself - this week ◐ 30-45 min total
- Draw your own organisation's governance operating model - who's the council, who are the owners and stewards for your top 3 datasets, and where does the DPO office sit? Mark any seat that's currently empty.
- Write one real policy as three lines: policy (what/why), standard (the testable rule), decision right (who approves exceptions). Pick a topic you actually need - retention, access, or transfer.
- Score your org on a 6-capability maturity scorecard, 1-5 with evidence. Be honest - most first scorecards are mostly red, and that's the point.
- Identify the single biggest risk-weighted gap and draft the one-sentence investment ask you'd put to a board.
- Look up the EDM Council DCAM page so you know exactly what's member-gated - then you can reference it honestly without over-claiming.
What this session covers
This session teaches the working content of the frameworks below. Member-gated frameworks and certification exams stay with their official sources - this page makes you fluent in the body of knowledge, honestly flagged where the official model is gated.
Three questions before you go 🎯 ◐ 90 seconds
1 · Your board asks for "the official DCAM component names and full assessment." What's the honest DPO answer?
DCAM's exact component names and full model are member-gated. Teach the maturity/scoring concept honestly; name the official route rather than inventing component names.
2 · Deven owns the consumer database; a senior engineer curates it day to day. Which is right?
The owner is accountable (answers for the domain); the steward is responsible (does the day-to-day work). The DPO advises and oversees but must not own the data - that would break independence.
3 · Marketing wants a policy exception to reuse the consumer list for a new purpose. What decides whether it's allowed?
Governance is decision rights, not tooling. A tool can flag a violation, but only a named authority (here, the governance council) can approve or refuse an exception.