High School AdvancedA16.7Privacy Engineering and Data Governance

Lesson A16.7

Data Governance Roles

Data governance succeeds when people know which decisions they own, which controls they operate, which evidence they produce, who they consult, and when they must escalate. This lesson turns vague “everyone owns privacy” statements into concrete decision rights and responsibility.

All organizations, roles, decisions, risks, and evidence in this lesson are fictional or synthetic.

Lesson Progress

Data Governance Roles

High School AdvancedA16: Privacy Engineering and Data Governance • Lesson 7 of 10

70% complete

Readiness Check

A16.7 Entry Readiness

0/4 ready

Professional Hook

A Good Decision Can Still Fail When Nobody Owns It

Privacy programs often fail at handoffs rather than at principles. A team may agree that data should be minimized, access reduced, or a supplier reviewed—but the decision stalls because nobody is accountable for approving the change, operating the control, producing evidence, or confirming closure.

Governance is the structure that turns privacy decisions into owned, reviewable action.

Learning Objectives

Five Capabilities for This Lesson

1

Explain the responsibilities of data owners, system or product owners, data stewards, privacy teams, security teams, records teams, compliance teams, control owners, evidence owners, remediation owners, and business leaders.

2

Distinguish accountability, approval, advisory support, control operation, evidence custody, remediation execution, and escalation so governance roles do not become interchangeable labels.

3

Evaluate fictional governance gaps such as unclear ownership, duplicate approval, advisory teams treated as risk owners, orphaned controls, missing evidence owners, and unresolved cross-functional handoffs.

4

Design decision-rights and responsibility mappings that connect privacy purpose, data classification, access, sharing, retention, privacy risk, exceptions, evidence, and change triggers to named roles.

5

Build a Data Governance Responsibility Matrix that becomes the seventh artifact in the A16 Privacy Engineering Review.

Governance Roles

Eleven Roles That Often Participate in Data Decisions

Data Owner

Core responsibility

Accountable for important decisions about how a data domain is used, classified, shared, retained, and governed.

Typical decisions

Business purpose, acceptable data use, ownership of major data risks, sharing approval, retention rationale, and escalation.

Does not automatically mean

The person who administers the database or personally operates every control.

Evidence

Data ownership register, approved purpose, classification decisions, risk acceptance, sharing approval.

System / Product Owner

Core responsibility

Accountable for the service or product lifecycle and for implementing approved privacy and governance requirements in the system.

Typical decisions

Feature design, implementation priorities, product change, system architecture decisions within delegated authority.

Does not automatically mean

The automatic owner of every business data risk.

Evidence

Product requirement, architecture review, release record, change approval, remediation plan.

Data Steward

Core responsibility

Supports day-to-day data quality, metadata, inventory accuracy, lineage, classification hygiene, and governance operations.

Typical decisions

Operational stewardship actions within the framework set by owners.

Does not automatically mean

Final authority for business-purpose or risk-acceptance decisions.

Evidence

Inventory updates, metadata review, lineage record, stewardship issue log.

Privacy Team

Core responsibility

Advises on privacy engineering, user expectations, minimization, risk, governance, and review standards.

Typical decisions

Privacy review conclusions and recommendations within the organization's governance model.

Does not automatically mean

Owner of every privacy risk or business consequence.

Evidence

Privacy assessment, review memo, design recommendation, governance standard.

Security Team

Core responsibility

Designs and operates safeguards that protect necessary data and services.

Typical decisions

Security architecture, control design, security requirements, monitoring, and security risk recommendations.

Does not automatically mean

Authority to decide whether every data use is necessary or appropriate.

Evidence

Security architecture, access review, logging evidence, control test, threat model.

Records / Information Governance

Core responsibility

Defines and supports record classes, retention schedules, archival rules, lifecycle, and approved holds.

Typical decisions

Records classification and retention guidance within the governance model.

Does not automatically mean

The sole owner of all deletion operations.

Evidence

Retention schedule, archive rule, hold record, disposition standard.

Compliance / Governance Analyst

Core responsibility

Maps requirements, controls, policies, evidence, reviews, and governance obligations.

Typical decisions

Assessment conclusions and mapping recommendations within assigned authority.

Does not automatically mean

A substitute for business ownership or technical control operation.

Evidence

Control mapping, policy register, assessment record, review finding.

Control Owner

Core responsibility

Accountable for the design and ongoing effectiveness of a specific control.

Typical decisions

How the control should operate, how gaps are remediated, and what evidence demonstrates effectiveness.

Does not automatically mean

Owner of the underlying business risk unless separately assigned.

Evidence

Control definition, test result, operating evidence, remediation record.

Evidence Owner

Core responsibility

Ensures required evidence is produced, retained, attributable, current, and available for review.

Typical decisions

Operational evidence-handling steps within assigned scope.

Does not automatically mean

Authority to approve the business decision the evidence supports.

Evidence

Evidence register, source mapping, retention metadata, review history.

Remediation Owner

Core responsibility

Executes the work required to fix a gap or reduce a risk.

Typical decisions

Implementation sequencing within the approved remediation plan.

Does not automatically mean

The risk owner or final approver unless separately assigned.

Evidence

Remediation ticket, milestone record, implementation proof, closure package.

Business Leader / Risk Owner

Core responsibility

Owns the business consequence and approves treatment or residual-risk decisions within authority.

Typical decisions

Priorities, funding, acceptance, escalation, and tradeoffs for material business risks.

Does not automatically mean

The person who performs every technical or privacy-control task.

Evidence

Risk decision, funding approval, acceptance record, leadership recommendation.

Decision Rights

Who Owns Which Decision?

A useful governance model maps roles to specific decisions rather than saying one team “owns privacy.” The accountable owner should be able to explain the decision, the authority, the evidence, and who was consulted.

Approve a new business purpose for data

Accountable: Data Owner / Business Owner

Consulted: Privacy, Product, Security, Compliance

Evidence: Purpose record + impact review + owner approval

Change data classification

Accountable: Data Owner

Consulted: Data Steward, Privacy, Security

Evidence: Classification rationale + context review + owner approval

Add a new supplier recipient

Accountable: Business or Product Owner

Consulted: Privacy, Security, Third-Party Risk, Legal/Procurement where applicable

Evidence: Supplier review + data-scope mapping + purpose + approval

Change retention period

Accountable: Data Owner

Consulted: Records, Privacy, Product, Compliance

Evidence: Updated retention rationale + schedule + lifecycle impact

Accept residual privacy risk

Accountable: Authorized Risk Owner

Consulted: Privacy, Security, Product, Compliance

Evidence: Risk record + residual risk + rationale + expiry/review trigger

Operate a privacy or security control

Accountable: Control Owner

Consulted: System Owner, Privacy/Security as appropriate

Evidence: Control procedure + operating evidence + test result

Close a privacy remediation

Accountable: Risk or Control Owner depending on governance model

Consulted: Remediation Owner, Evidence Owner, Privacy

Evidence: Closure criteria + current evidence + review conclusion

Accountability

Seven Principles for Clear Governance

One accountable owner

Important decisions should have one clearly accountable owner even when many teams are consulted.

Failure mode: Everyone is responsible, so nobody is actually accountable.

Advisory is not ownership

Privacy, security, legal, or compliance teams may advise strongly without owning the business consequence.

Failure mode: The business sends every decision to privacy and assumes privacy owns the risk.

Control ownership is specific

The person accountable for a control may differ from the data owner, risk owner, and remediation owner.

Failure mode: A vague “IT owns it” label hides who is accountable for effectiveness.

Evidence has an owner

Important governance conclusions need someone responsible for producing current, reviewable evidence.

Failure mode: A control is supposed to work, but no one owns the evidence needed to prove it.

Decision authority has limits

Owners should act within defined authority and escalate decisions beyond their scope.

Failure mode: A low-level owner accepts a major residual risk without the required authority.

Handoffs are explicit

When responsibility moves between teams, the handoff should define what is complete and what remains open.

Failure mode: Product thinks Security owns the gap; Security thinks Product owns it.

Ownership survives organizational change

Role changes, team moves, and vendor transitions should not orphan risks, controls, or data.

Failure mode: A departed employee remains listed as owner for a critical privacy decision.

Cross-Functional Handoffs

Governance Breaks When Responsibility Falls Between Teams

Data Owner → Product Owner

Sends

Approved purpose, classification, retention, sharing constraints, decision requirements.

Receives

Implemented product behavior, change evidence, unresolved design tradeoffs.

Handoff risk

Requirements are approved but never translated into product behavior.

Product Owner → Privacy Team

Sends

Feature design, data flow, user experience, planned purpose, supplier or analytics changes.

Receives

Privacy recommendations, risk findings, minimization and expectation requirements.

Handoff risk

Privacy is engaged after the architecture is already fixed.

Privacy Team → Risk Owner

Sends

Residual risk, uncertainty, treatment options, evidence confidence, recommendation.

Receives

Treatment decision, acceptance, escalation, or funding direction.

Handoff risk

Privacy recommendation is mistaken for final business approval.

Control Owner → Evidence Owner

Sends

Control requirements, evidence definition, test frequency, review criteria.

Receives

Current operating evidence and evidence-quality status.

Handoff risk

The control exists but evidence is stale or incomplete.

Remediation Owner → Risk Owner

Sends

Implementation status, milestone evidence, unresolved blockers.

Receives

Priority, scope change, escalation, or closure decision.

Handoff risk

A completed ticket is treated as equivalent to reduced residual risk.

Records Team → System Owner

Sends

Retention schedule, lifecycle trigger, archival and deletion expectations.

Receives

Implemented lifecycle behavior and deletion evidence.

Handoff risk

Retention policy exists on paper but system behavior never changes.

Responsibility Matrix

What a Reviewable Governance Record Should Contain

GOV ID

Stable identifier for the governance decision.

Example: GOV-701

Decision / responsibility

Names the specific decision being governed.

Example: Approve partner scheduling data scope

Accountable owner

Names the role ultimately accountable for the outcome.

Example: Integration Product Owner

Approver / authority

Shows who has authority when formal approval is required.

Example: Business Service Owner

Consulted roles

Shows which specialist teams advise the decision.

Example: Privacy, Security, Third-Party Risk

Control owner

Shows who owns the control that supports the decision.

Example: Integration Engineering Lead

Evidence owner

Shows who ensures reviewable proof exists.

Example: Integration Governance Analyst

Remediation owner

Shows who performs corrective work when a gap exists.

Example: Integration Engineering Team

Linked records

Connects the governance decision to A16 evidence.

Example: PRA-605 / MIN-305 / RET-505

Escalation trigger

Defines when the decision must move to higher authority.

Example: New sensitive fields, unresolved supplier evidence, residual risk above tolerance

Review cadence

Defines when ownership and authority should be revalidated.

Example: Quarterly and after material change

Current state

Shows whether the governance assignment is Current, Gap, Conditional, Blocked, or Closed.

Example: Conditional

Fictional Governance Matrix

Seven Northbridge Governance Decisions

GOV-701TreatPRA-601 / DATA-201 / MIN-301

Approve the support-profile field set

Accountable owner

Student Services Data Owner

Approver / authority

Student Services Director

Consulted roles

Product Owner, Privacy Team, Security Team

Control owner

Support Product Owner

Evidence owner

Data Steward

Remediation owner

Support Product Team

Current issue

Three unused fields remain in the base profile.

Escalation trigger

New sensitive fields or unresolved minimization gap

GOV-702MonitorPRA-602 / DATA-202 / RET-502

Maintain restricted access to support case notes

Accountable owner

Student Services Data Owner

Approver / authority

Student Services Director

Consulted roles

Privacy, Security, Records

Control owner

Support Access Control Owner

Evidence owner

Security Governance Analyst

Remediation owner

Identity and Support Engineering

Current issue

No current material governance gap; ownership is clear.

Escalation trigger

New support role, new supplier, new analytics use

GOV-703TreatPRA-603 / RET-503

Set retention for individual learning analytics events

Accountable owner

Learning Analytics Data Owner

Approver / authority

Analytics Program Director

Consulted roles

Privacy, Records, Security, Product

Control owner

Analytics Platform Owner

Evidence owner

Analytics Data Steward

Remediation owner

Analytics Engineering

Current issue

Different workspaces use inconsistent expiry dates.

Escalation trigger

Retention extension or failure to standardize lifecycle

GOV-704BlockedPRA-604 / MIN-304

Approve creation of individual engagement indicators

Accountable owner

Learning Analytics Data Owner

Approver / authority

Analytics Program Director

Consulted roles

Privacy, Product, Research Governance

Control owner

Analytics Model Owner

Evidence owner

Analytics Governance Analyst

Remediation owner

Analytics Engineering

Current issue

No current approved operational purpose supports persistent individual inference.

Escalation trigger

Any proposal to use the indicator for individual decisions

GOV-705ConditionalPRA-605 / MIN-305 / RET-505

Approve partner scheduling data scope and lifecycle

Accountable owner

Integration Product Owner

Approver / authority

Student Services Business Owner

Consulted roles

Privacy, Security, Third-Party Risk, Procurement

Control owner

Integration Engineering Lead

Evidence owner

Integration Governance Analyst

Remediation owner

Integration Engineering

Current issue

Partner payload exceeds current purpose and supplier lifecycle evidence is incomplete.

Escalation trigger

Residual risk above tolerance or unresolved supplier evidence

GOV-706ConditionalPRA-606 / RET-506

Close temporary research workspace

Accountable owner

Research Program Owner

Approver / authority

Research Governance Lead

Consulted roles

Privacy, Security, Data Steward

Control owner

Research Workspace Owner

Evidence owner

Research Governance Analyst

Remediation owner

Research Operations

Current issue

Closure evidence becomes due at the project end.

Escalation trigger

Project extension or failed deletion reconciliation

GOV-707MonitorPRA-607 / DATA-207

Maintain aggregate-only support quality reporting

Accountable owner

Operations Analytics Data Owner

Approver / authority

Operations Director

Consulted roles

Privacy, Product, Security

Control owner

Dashboard Product Owner

Evidence owner

Operations Data Steward

Remediation owner

Dashboard Engineering

Current issue

Current design is strong; individual drill-down would require re-review.

Escalation trigger

New individual-level drill-down or source export

Fake Dashboard

Northbridge Data Governance Dashboard

Fictional accountability, approval, control ownership, evidence ownership, remediation, and escalation summary

Governance decisions

7

Profile, support, analytics, partner, research, and dashboard decisions

Clear accountability

6

Most major decisions have named accountable owners and approvers

Treat / Conditional

4

Profile, analytics retention, partner scope, and research closeout need active governance

Blocked

1

Persistent individual engagement inference lacks an approved operational purpose

Fake SOC Alert

Partner Decision Has Multiple Specialists but One Accountable Owner

Source: Fictional Governance Review • Time: 09:40

High Severity
GOV-705 requires Privacy, Security, Third-Party Risk, Procurement, Engineering, and business input. The Integration Product Owner remains accountable for the product decision, while the Business Owner holds approval authority for material residual risk.
Defensive recommendation: Keep specialist consultation broad but preserve one accountable owner, distinct control/evidence/remediation owners, and a clear escalation trigger.

Fake Log Panel

Fictional Data Governance Review Log

training-log-viewer.log
[08:12] GOV-701 decision=PROFILE_FIELDS accountable=DATA_OWNER state=TREAT
[08:34] GOV-702 decision=CASE_NOTE_ACCESS control_owner=ASSIGNED state=MONITOR
[08:56] GOV-703 decision=ANALYTICS_RETENTION expiry=INCONSISTENT state=TREAT
[09:18] GOV-704 decision=INDIVIDUAL_INFERENCE purpose=UNAPPROVED state=BLOCKED
[09:40] GOV-705 decision=PARTNER_SCOPE evidence=PARTIAL state=CONDITIONAL
[10:02] GOV-706 decision=RESEARCH_CLOSEOUT evidence=FUTURE state=CONDITIONAL
[10:24] GOV-707 decision=AGGREGATE_REPORTING ownership=CLEAR state=MONITOR

Training note: this is fake data for defensive analysis practice only.

Analyze the Evidence

Evidence Analysis: Who Owns the Partner Privacy Risk?

The partner issue affects business service design, data sharing, supplier lifecycle, privacy, and security.
Privacy and Security provide specialist assessment.
Integration Engineering operates the technical controls.
The Integration Product Owner controls the product and integration roadmap.
The Business Owner holds authority for material residual-risk approval.

Which governance model is strongest for GOV-705?

Common Governance Mistakes

Eight Ways Role Design Becomes Unclear

1

Privacy owns every privacy risk

Why it fails: The organization treats the advisory privacy team as the owner of business decisions it does not control.

Better approach: Assign business or data ownership while privacy advises, challenges, and governs.

2

IT owns the data

Why it fails: Technical administration is confused with business accountability.

Better approach: Separate system administration from data ownership and purpose authority.

3

Everyone approves

Why it fails: Too many approvers create delay while no one is clearly accountable.

Better approach: Define one accountable owner and only the approvals truly required.

4

No evidence owner

Why it fails: Controls are expected to work, but no role owns production of current reviewable evidence.

Better approach: Assign evidence ownership explicitly.

5

Remediation owner treated as risk owner

Why it fails: The team performing the fix is assumed to own the business consequence.

Better approach: Keep remediation execution separate from risk accountability.

6

Departed owner remains assigned

Why it fails: Risks, controls, and data decisions become orphaned after organizational change.

Better approach: Revalidate ownership during role changes and scheduled governance review.

7

Advisory recommendation treated as approval

Why it fails: A specialist recommendation is mistaken for final business authority.

Better approach: Document who advises, who approves, and who owns the outcome.

8

RACI without decision detail

Why it fails: A generic matrix lists teams but does not say which exact decisions they own.

Better approach: Map responsibilities to concrete decisions, evidence, escalation, and review triggers.

Scenario Decision Lab

Scenario Decision Lab 1 — Partner Data Accountability

A partner data issue requires input from Privacy, Security, Third-Party Risk, Procurement, Engineering, and business leadership. The team proposes making Privacy the owner because the concern is privacy-related.

Scenario Decision Lab

Scenario Decision Lab 2 — Research Deletion Evidence

A temporary research project ends. The Research Program Owner is accountable for lifecycle completion, the workspace team runs deletion, but no one has been assigned to own the deletion evidence.

Safe Fictional Lab

Build a Data Governance Responsibility Matrix

Use your fictional A16 privacy risks, retention decisions, and data inventory to assign responsibility for concrete governance decisions. Focus on who is accountable, who approves, who operates controls, who owns evidence, who remediates, and when escalation is required.

1

Create at least twenty-five fictional governance records.

2

Give every record a stable GOV ID.

3

Link each record to relevant PRA, DATA, MIN, EXP, or RET IDs.

4

Name the specific decision or responsibility.

5

Assign one accountable owner.

6

Name formal approval authority where required.

7

List consulted roles.

8

List informed roles where useful.

9

Assign the control owner.

10

Assign the evidence owner.

11

Assign the remediation owner.

12

Assign the data steward where relevant.

13

Assign the system or product owner.

14

Record the current governance issue.

15

Record decision authority limits.

16

Define escalation triggers.

17

Define review cadence.

18

Define organizational-change triggers.

19

Define closure authority.

20

Define required closure evidence.

21

Include at least five data-purpose decisions.

22

Include at least five retention or lifecycle decisions.

23

Include at least five privacy-risk decisions.

24

Include at least three supplier-sharing decisions.

25

Include at least three control-ownership decisions.

26

Include at least three evidence-ownership gaps.

27

Include at least three remediation handoffs.

28

Include at least three decisions that require leadership escalation.

29

Include at least three cases where Privacy advises but does not own the business risk.

30

Include at least three cases where system ownership differs from data ownership.

Lab boundary

Use fictional teams, roles, data, risks, systems, and evidence only. Do not identify real employees, internal ownership gaps, private organizational structures, or confidential governance records.

Analyze the Evidence

Evidence Analysis: Research Closeout Ownership

The Research Program Owner is accountable for the project lifecycle outcome.
Research Operations performs workspace cleanup.
The privacy review requires current deletion and reconciliation evidence.
No role is currently assigned to own evidence production and custody.

What is the strongest governance decision for GOV-706?

Advanced Challenge

Design a Data Governance Operating Model

Create a fictional operating model that explains how data, privacy, security, product, records, compliance, control, evidence, remediation, and business roles work together without duplicating authority.

1

Data owner definition

2

System owner definition

3

Data steward definition

4

Privacy-team mandate

5

Security-team mandate

6

Records-team mandate

7

Compliance-team mandate

8

Control-owner definition

9

Evidence-owner definition

10

Remediation-owner definition

11

Risk-owner definition

12

Approval authority

13

Consultation rules

14

Escalation thresholds

15

Decision-rights catalog

16

Handoff standard

17

Ownership review cadence

18

Organizational-change reassignment

19

Closure authority

20

Governance evidence

The strongest operating model should make decision ownership clear without forcing every team into the same role for every decision.

Defender Habits

A16.7 Defender Checklist

Skill Check

Seven Questions

Check Your Understanding

A16.7 Mini Quiz: Data Governance Roles

Choose your answers first. Explanations appear only after submission.

1. What is the strongest description of a Data Owner?

2. What is the strongest description of a Control Owner?

3. Why should evidence ownership be explicit?

4. Which statement about privacy teams is strongest?

5. What is strongest when a decision exceeds an owner's authority?

6. What is strongest when a remediation ticket is marked complete?

7. Why should governance ownership be reviewed after organizational change?

Portfolio Prompt

Portfolio Build — Data Governance Responsibility Matrix

Create the seventh artifact for your A16 Privacy Engineering Review: a fictional Data Governance Responsibility Matrix with at least twenty-five records. Include GOV ID, linked PRA/DATA/MIN/EXP/RET IDs, decision/responsibility, accountable owner, approval authority, consulted roles, informed roles where useful, control owner, evidence owner, remediation owner, data steward, system/product owner, current governance issue, authority limit, escalation trigger, review cadence, organizational-change trigger, closure authority, and closure evidence.

Assign one accountable owner for each major decision.
Separate business ownership from technical administration.
Keep advisory roles distinct from approval authority.
Assign evidence ownership explicitly.
Define escalation before a difficult decision occurs.
Use fictional or synthetic roles only.

Confidence / Readiness Reflection

Are You Ready for A16.8?

A16.8 focuses on Privacy by Design in Systems. Before continuing, make sure you can identify who has authority to turn privacy requirements into architecture, product, control, and lifecycle decisions.

1

I can distinguish data owner, system owner, control owner, evidence owner, remediation owner, and risk owner.

2

I can explain why advisory teams do not automatically own business risk.

3

I can assign one accountable owner while keeping consultation broad.

4

I can identify when a decision should be escalated.

5

I can explain how governance handoffs affect privacy-control effectiveness.

Portfolio Build Guide

How to Make the Data Governance Responsibility Matrix Look Professional

Map decisions, not departments

A strong matrix says who owns a specific decision such as partner scope, retention, or risk acceptance.

Separate role types

Keep accountable owner, approver, control owner, evidence owner, and remediation owner distinct.

Show authority limits

An owner should know when a decision must be escalated.

Show handoffs

Important cross-functional work should define what one team sends and what another must return.

Show evidence ownership

Reviewable governance depends on current evidence with a named custodian.

Show change triggers

Ownership should be revisited after reorganizations, supplier changes, or major product changes.

Show closure authority

The person performing remediation should not automatically decide that the risk is closed.

Connect forward

A16.8 will use these governance roles to assign privacy-by-design responsibilities across system architecture.

Key Takeaways

What You Should Remember

1.Governance works best when accountability, advice, control operation, evidence, remediation, and approval are distinguished.
2.Data owners are accountable for important business data decisions; system owners implement those decisions in products and services.
3.Privacy and security teams may strongly influence a decision without owning the underlying business consequence.
4.Control owners, evidence owners, remediation owners, and risk owners can be different roles.
5.One accountable owner is usually clearer than broad shared accountability.
6.Decision authority should include escalation when a risk exceeds the owner's scope.
7.Handoffs need explicit inputs, outputs, evidence, and remaining responsibilities.
8.Organizational change can orphan risks, controls, and data if ownership is not revalidated.
9.A responsibility matrix should map concrete decisions, not merely list teams.
10.The Data Governance Responsibility Matrix prepares you for A16.8 Privacy by Design in Systems.

Lesson Safety Boundary

Governance exercises use fictional organizations and roles only

Do not identify real employees, expose private organizational structures, investigate internal ownership gaps, or use confidential governance documents. All responsibilities, roles, systems, and evidence in this lesson are fictional and educational.

Lesson Complete

A16.7 Data Governance Roles Complete

You now have a structured model for data ownership, product ownership, privacy and security advice, control ownership, evidence ownership, remediation ownership, risk ownership, decision rights, handoffs, escalation, and closure authority. Next, A16.8 focuses on Privacy by Design in Systems.