Data Governance, Security, and Privacy

Data Governance, Security, and Privacy

Quick Answer: Domain 6 expects awareness of data governance, security (6.3.3), privacy rule application (6.5.2), roles (owners, stewards, custodians), policies (access, retention, quality, ethical use), and metric/KPI validation (6.3.4) so enterprise analytics is trusted. Domain weight is ~9%, but scenarios pairing strong analysis with weak governance remain highly testable.

Strategy and solution evaluation fail without trustworthy data and responsible use. Governance is how organizations decide who may use which data for what purpose under what controls—and how they keep enterprise numbers consistent. Domain 5 ethics (minimization, fairness, honesty) continues here as operating policy, not only personal conduct.

Why Governance Belongs in Domain 6

Project teams can ship insights that are locally clever and enterprise-dangerous:

• Customer PII exported to personal laptops “to finish the model.”
• Conflicting revenue definitions in three executive decks.
• Models trained on data retained longer than policy allows.
• Access granted broadly because “analysts need everything.”

Domain 6 governance questions ask you to restore control and trust without pretending governance means “never use data.” Good governance enables analytics by making approved use clear, safe, and reusable.

Data Security Basics (6.3.3)

Data security protects information assets against unauthorized access, use, disclosure, alteration, or destruction. Classic pillars:

Practical security controls CBDA candidates should recognize

• Classification: Public, internal, confidential, restricted—drives handling rules.
• Least privilege / need-to-know: Access limited to what the role requires for the purpose.
• Authentication & authorization: Identity verified; permissions enforced (including service accounts).
• Encryption: In transit (TLS) and at rest for sensitive stores—conceptually expected.
• Masking, tokenization, aggregation: Reduce exposure in lower environments and shared reports.
• Audit logging: Who accessed or exported what, when.
• Secure SDLC / pipeline controls: Protect notebooks, jobs, and production feature pipelines.
• Incident response awareness: Escalation path when leakage or misuse is suspected.

Analytics-specific security pitfalls

• Copying production extracts to unsecured collaboration tools.
• Embedding secrets in notebooks or BI connection strings.
• Over-sharing dashboards with row-level data that should be role-filtered.
• Training models on restricted data then publishing parameters that leak personal details.
• “Temporary” open access that never expires.

Exam framing: If a stem shows a powerful analysis path that requires unrestricted PII dump, prefer purpose-limited, least-privilege access with masking where possible—not “security blocks analytics so skip security.”

Privacy Rules: Identify and Apply (6.5.2)

Privacy concerns the rights of individuals regarding personal information and the organization’s duties when processing that information. Security is necessary but not sufficient: data can be secure and still used for an unapproved purpose.

Concepts to apply (not jurisdiction-specific legal advice)

CBDA expects practitioner application, not bar-exam memorization of every regulation. Recognize principles common to modern privacy regimes (e.g., GDPR-like ideas, sector rules, organizational policy):

1. Lawful / authorized basis — Is there a legitimate, documented basis for the processing?
2. Purpose limitation — Use data for the stated analytics purpose; re-purpose requires re-check.
3. Data minimization — Collect and use only what is needed for the research question/solution.
4. Transparency — Individuals and stakeholders understand material uses where required.
5. Retention limitation — Keep personal data only as long as needed; then delete or anonymize.
6. Integrity and confidentiality — Align privacy with security controls.
7. Accountability — Document decisions, DPIA-like assessments when high risk, and owners.
8. Individual rights awareness — Access, correction, deletion, or restriction requests may affect datasets and models.

Sensitive categories (heightened care)

Health, biometrics, precise location, children’s data, financial account details, government IDs, and special-category attributes often require stricter controls, fewer secondary uses, and stronger access barriers.

Analytics application checklist

• Map personal data elements in sources and features.
• Confirm purpose matches acquisition/notice/policy.
• Prefer aggregated or de-identified outputs for broad distribution.
• Assess re-identification risk in “anonymized” small cells.
• Align model monitoring data stores with retention policy.
• Involve privacy/legal for high-risk profiling or automated decisions affecting people.

Domain 5 ethics and Domain 6 privacy converge: a high-ROI targeting model that uses unnecessary sensitive attributes fails privacy application even if security encryption is perfect.

Governance Roles: Owners, Stewards, Custodians

Role names vary by organization; CBDA cares about responsibility clusters:

Why roles matter on the exam

• Conflicting KPI? Escalate to owner/steward for definition—not each analyst invents a version.
• Access request? Owner approves purpose; custodian implements technical access.
• Quality incident? Steward coordinates remediation; custodian may fix pipelines; owner accepts residual risk.

Anti-pattern: “Everyone owns the data” → nobody owns definitions. Anti-pattern: IT alone “owns” business meaning of “active customer.”

Policies: Access, Retention, Quality, Ethical Use

Policies translate principles into enforceable expectations.

Access policy

• Role-based or attribute-based access; time-bound elevated access.
• Approval workflow for sensitive domains.
• Restrictions on export, screenshot, and third-party sharing.
• Separation of duties for production model changes where needed.

Retention policy

• Retention schedules by data class and purpose.
• Archive vs delete vs anonymize rules.
• Alignment of training datasets and feature stores with schedules.
• Legal hold exceptions documented.

Quality policy

• Critical data elements with quality rules and thresholds.
• Monitoring, issue logging, and SLA for remediation.
• Standards for documentation and lineage for decision-critical data.

Ethical use policy

• Prohibited uses (e.g., unfair discrimination, dark patterns).
• Required bias/impact reviews for models affecting people.
• Honest reporting standards (no selective charts that mislead).
• Escalation path for ethical concerns (ties to professional conduct).

Policies without awareness and enforcement are shelfware. Domain 6 strategy often includes building the operating model that makes policies real (training, tooling, audits).

Validation of Metrics and KPIs (6.3.4)

Enterprise reporting collapses when every team calculates “conversion,” “churn,” or “margin” differently. Competency 6.3.4 emphasizes validating metrics/KPIs so decision makers trust numbers.

What “validated metric” means

A metric is validated when:

1. Business definition is clear (numerator, denominator, population, time window).
2. Calculation logic is documented and versioned.
3. Source fields and transformations are known (lineage).
4. Quality checks confirm inputs meet fitness thresholds.
5. Reconciliation against systems of record or independent methods succeeds within tolerance.
6. Owner/steward signs off for enterprise use.
7. Change control exists when definitions evolve.

Practitioner validation steps

• Start from the decision: which KPI must be trusted for which choice?
• Inventory competing definitions currently in use.
• Facilitate steward/owner agreement; publish a certified metric.
• Implement in a governed semantic layer or metric store when available.
• Test edge cases (returns, cancellations, time zones, late-arriving events).
• Monitor drift between certified metric and shadow calculations.
• Communicate version and caveats in dashboards and executive packs.

Trust failures to spot in scenarios

Validated metrics are a strategic asset: they reduce argument time and increase decision speed—exactly Domain 6 value.

Putting Governance into Strategy and Solutions

Connect this section to the previous Domain 6 sections:

• Maturity: Moving from ad hoc to managed almost always requires basic governance (owners, critical metrics, access).
• 6.1 policies/procedures: Include data handling and metric use rules when operationalizing insights.
• 6.2 solution evaluation: Security, privacy, and metric trust are go/no-go criteria, not afterthoughts.
• Portfolio: Fund foundational governance and certified metrics when they unblock multiple initiatives.

Mini decision table for exam stems

Mini Checklist: Governance, Security, Privacy

• Data classified; access least-privilege and audited?
• Purpose, minimization, and retention applied to personal data?
• Owners, stewards, custodians identified for critical domains?
• Access, retention, quality, ethical-use policies known and followed?
• Decision-critical KPIs validated, owned, and change-controlled?
• Solution evaluation includes security/privacy/metric trust gates?

Governance is not the enemy of analytics speed; untrusted analytics is slow forever because every meeting re-litigates the numbers and every incident freezes programs. Domain 6 professionals guide organizations to secure, private, owned, and validated data practices so strategy, solutions, and day-to-day decisions can move with confidence.