Privacy Governance practice questions

Creating data erasure requests.

Why it fails: This is part of the 'Protect' function.

Detecting privacy breaches.

Why it fails: This is under the 'Detect' function.

Implementing technical access controls.

Why it fails: This is a Control/Protect function activity.

Archiving personal data.

Why it fails: This is part of the 'Data Lifecycle' management.

The software vendor.

Why it fails: The vendor may report to the controller, not the regulator.

The office administrator.

Why it fails: They lack the regulatory knowledge.

The social media manager.

Why it fails: They manage the public message, not the legal report.

The color of the office walls.

Why it fails: Wall colour is a cosmetic attribute with no measurable link to privacy outcomes such as data-subject request handling or retention compliance. It is tempting because it is trivially observable, and such a metric would belong in an office-design review, but it cannot evidence privacy programme success.

The number of coffee machines in the breakroom.

Why it fails: Counting coffee machines measures office facilities, not privacy outcomes such as subject-request turnaround or breach rates. It is tempting because physical assets are easy to tally, and such metrics would suit a facilities-management report, but they evidence nothing about data-protection effectiveness.

How many office chairs are purchased.

Why it fails: Office-chair purchases track procurement activity, not privacy performance indicators like consent rates or incident volumes. Tallying furniture is tempting because it is quantifiable and simple to collect, and it would be valid for a workplace-resources audit, yet it cannot demonstrate that a privacy programme is working.

A privacy budget allocated to the marketing department.

Why it fails: Allocating a privacy budget to marketing does not ensure accountability or enforcement. Marketing may not have the expertise or authority to enforce privacy policies. This could create conflicts of interest and dilute privacy governance. Budget allocation should be centralized under privacy leadership to support program objectives.

Annual privacy training for all employees.

Why it fails: Annual training is important for awareness but does not by itself establish accountability or enforcement. It is a preventive control that educates employees, but without defined responsibilities or consequences, it may not lead to compliance. It is a supporting element, not an essential component for accountability and enforcement.

Regular privacy awareness campaigns for customers.

Why it fails: Customer awareness campaigns inform individuals about privacy practices but do not establish internal accountability or enforcement mechanisms. They are outward-facing and do not ensure that employees comply with privacy policies. While valuable for transparency, they are not essential for internal governance enforcement.

A Data Steward responsible for the day-to-day management of data quality and metadata

Why it fails: Data stewards focus on data quality, metadata management, and data lifecycle within specific domains. While they may support privacy efforts by ensuring data accuracy, their role is not primarily about privacy compliance or governance. Privacy governance requires roles specifically accountable for privacy outcomes, such as a DPO or privacy steering committee. Data stewardship is a complementary but not essential role for privacy governance.

A Privacy Program Manager responsible for implementing privacy policies and managing privacy operations

Why it fails: A Privacy Program Manager is important for executing privacy initiatives, but the question asks for essential roles that should be defined within the governance program. The DPO and Privacy Steering Committee are foundational governance roles that establish accountability and strategic oversight. The Privacy Program Manager is an operational role that supports the program but is not a governance role per se. Thus, it is not one of the two most essential roles.

A Chief Information Security Officer (CISO) responsible for implementing technical security controls to protect personal data

Why it fails: While the CISO plays a critical role in protecting personal data through security controls, the CISO is not a privacy-specific role. Privacy governance focuses on legal compliance, data subject rights, and policy oversight, which are distinct from information security. The CISO's responsibilities are important but do not replace the need for dedicated privacy roles. Therefore, the CISO is not one of the essential roles defined within the privacy governance program.

Ad-hoc committee based on project needs.

Why it fails: An ad-hoc committee convenes only when projects demand it, so it provides no standing oversight, defined accountability or consistent policy across decentralised business units. It is tempting for its low overhead, but it would suit a one-off initiative rather than ongoing enterprise privacy governance.

Outsourcing all privacy functions.

Why it fails: Outsourcing transfers processing to a vendor but leaves the organisation accountable for privacy outcomes, so it cannot supply the internal governance structure a decentralised organisation needs. It is tempting where specialist capability is scarce, yet accountability for privacy risk cannot be delegated away.

Centralized command-and-control structure.

Why it fails: A centralised command-and-control structure concentrates decisions at the centre, which conflicts with a decentralised organisation where units hold their own autonomy and accountability. It is tempting because it delivers consistency, but it would fit a centralised organisation, not a federated one needing embedded local ownership.

The list of current vendors.

Why it fails: A vendor list records existing third parties but says nothing about what personal data is collected, why, where it flows, or which laws apply, so it cannot scope the programme. It is tempting because vendor risk is a privacy concern, yet the foundational artefact is the data inventory or record of processing activities.

The software inventory.

Why it fails: A software inventory lists applications and versions, not the personal data flows, processing purposes or lawful bases a governance programme must map first. It is tempting because it supports asset-level privacy reviews, and would be the right starting point when scoping which applications require data protection impact assessments.

The technical architecture diagram.

Why it fails: A technical architecture diagram shows system and data-flow topology but omits lawful basis, retention periods, data-subject rights and cross-border transfer details that governance must address. It is tempting because it maps where data resides, but the programme should start from the data inventory and processing register.

The individual data subjects.

Why it fails: Data subjects hold rights enforceable against the controller, but they never assume governance responsibility for a SaaS deployment. This distractor tempts candidates who conflate data-subject rights with accountability, yet the stem asks who retains primary responsibility, which stays with the organisation determining purposes and means of processing.

The Lead Supervisory Authority.

Why it fails: A Lead Supervisory Authority is a GDPR supervisory body that regulates controllers, not a party that assumes governance duties when a company outsources processing. It is tempting because supervisory authorities do oversee cross-border processing, but they would only be relevant as an external regulator, never as the entity retaining primary accountability.

The Network Infrastructure team.

Why it fails: The network infrastructure team operates connectivity and firewalls, holding no accountability for lawful data processing, consent or privacy notices. It would be relevant to questions about network segmentation or traffic controls, not governance of personal data in a SaaS arrangement.

The Cloud Service Provider (CSP).

Why it fails: The CSP processes customer data under the customer's instructions, so it does not hold primary privacy governance responsibility. It is tempting because the CSP operates the SaaS platform and its infrastructure, and would be correct for securing the underlying cloud services rather than governing how personal data is collected and used.

Count of privacy training sessions completed.

Why it fails: Training completion counts attendance, not reduced privacy risk or business value. It is tempting because completion data is easily pulled from a learning management system and satisfies audit evidence for awareness requirements, which would be the correct metric when demonstrating training compliance specifically.

Total spend on privacy software tools.

Why it fails: Spend on tools is an input cost, not evidence of privacy value delivered against business objectives. It is tempting because budgeting figures are readily available and simple to present, and would be the right measure when justifying a finance or procurement request rather than demonstrating programme outcomes.

Number of privacy patches applied.

Why it fails: Patch counts measure operational activity, not privacy's contribution to business objectives such as trust, reduced breach exposure or compliance enablement. It is tempting because patch volume is easy to report from vulnerability tooling, and would be a valid metric for a patch-management or vulnerability-remediation programme.

Conducting periodic penetration tests.

Why it fails: Penetration tests assess technical vulnerabilities in systems; they do not demonstrate accountability for how personal data flows are mapped and governed. GDPR accountability demands documented records such as data-flow maps, ROPA, and DPIAs. Testing is tempting as a security control, but it evidences resilience, not Article 5(2) demonstrability.

Updating the external privacy policy annually.

Why it fails: An annually updated external privacy policy is a transparency notice to data subjects, not evidence of internal accountability for mapped data flows. Article 5(2) requires demonstrable records such as data-flow maps, ROPA, and DPIAs. Updating the policy is tempting because it is a visible GDPR artefact, but it documents notices, not processing governance.

Signing NDAs with all employees.

Why it fails: NDAs bind employees to confidentiality but do not evidence how personal data flows are mapped, recorded, or governed across the enterprise. GDPR accountability requires demonstrable records such as data-flow mapping, ROPA, and DPIA documentation. NDAs are tempting as a contractual safeguard, yet they address confidentiality, not Article 5(2) demonstrability.

Lack of translation services.

Why it fails: Translation is a logistical task solved by vendors or localisation teams, and it does not alter the underlying governance problem. Translation services are relevant when publishing multilingual notices or consent text, yet divergent statutory requirements across jurisdictions remain the substantive barrier to a single enforceable global policy.

Difficulty in choosing a document management system.

Why it fails: Document management is an operational tooling decision, not a governance obstacle; a policy's effectiveness does not hinge on which repository stores it. Selecting a system matters when records retention or version control is the stated objective, but conflicting legal regimes, not storage, defeat global governance.

Inability to find a privacy officer for every region.

Why it fails: Regional privacy officers can be appointed, shared across territories, or outsourced, so staffing gaps are surmountable. Appointing officers matters when local accountability or supervisory-authority contact points are required, but reconciling conflicting national privacy laws into one governable framework is the actual challenge.

Resistance from the Marketing department.

Why it fails: Marketing resistance is departmental politics, not a governance obstacle: a Global Privacy Policy's core difficulty is reconciling conflicting national legal regimes (GDPR, PIPL, LGPD) into one enforceable framework. Marketing buy-in matters when rolling out consent and preference management, but it is a stakeholder-adoption task, not the greatest governance challenge.

Installing a firewall after code completion.

Why it fails: A firewall is a network boundary control installed after coding, addressing traffic filtering rather than embedding privacy requirements into system design. It would be correct for perimeter security hardening. Privacy by design instead requires data protection requirements to be elicited and documented during the requirements gathering phase.

Reviewing audit logs after the system launch.

Why it fails: Audit logs record activity after processing begins, so they cannot shape requirements or embed data minimisation and consent into the design. Log review suits post-deployment monitoring and incident investigation. Privacy by design demands controls specified during requirements gathering, before any code or data flows exist.

Performing a DPIA after production deployment.

Why it fails: A DPIA after production deployment assesses risks already built into the system, when redesign is costly and personal data is already processed. Post-launch assessment suits validating an existing processing operation. Privacy by design requires the DPIA during requirements gathering, so findings shape the design before development starts.

Approving all business marketing budgets.

Why it fails: A DPO advises on and monitors compliance with data protection regulations; marketing budget approval is a finance and executive function. It is tempting because marketing campaigns process personal data and require DPO guidance on lawful basis and consent, but approving budgets is not part of the DPO's statutory duties.

Managing the IT server infrastructure.

Why it fails: A DPO's remit covers data protection compliance, records of processing and breach notification, not server operations, which sit with IT operations teams. It is tempting because privacy depends on secure infrastructure, so the DPO coordinates with infrastructure staff, yet managing servers is not the role.

Developing all corporate software applications.

Why it fails: A DPO monitors compliance with data protection laws, advises on data protection impact assessments and liaises with supervisory authorities; software development belongs to engineering teams. It is tempting because privacy-by-design requires DPO input into development, but the DPO advises and monitors rather than building applications.

Only the Human Resources team.

Why it fails: Organisational support for privacy requires representation beyond HR, since legal, compliance, security and business functions own different data processing risks; an HR-only committee cannot mandate enterprise-wide privacy policy. HR representation would be correct for a committee scoped to employee data handling.

External consultants only.

Why it fails: External consultants provide advice but hold no internal authority to commit resources or enforce privacy decisions, so they cannot secure organisational support alone. Consultants would be the right choice for an independent assessment or gap analysis, not for governance membership.

Only the IT staff.

Why it fails: A privacy steering committee needs cross-functional representation — legal, compliance, business, security and privacy — to secure organisational backing; restricting membership to IT staff excludes the business owners who approve privacy policy. IT-only membership would suit a technical working group implementing controls.

Checking for the presence of a Privacy Impact Assessment template.

Why it fails: A template's mere existence evidences documentation, not operational maturity; it says nothing about whether assessments are performed, reviewed or acted upon. Templates are artefacts used when establishing a programme, whereas maturity requires evidence of consistent execution and measurement across assessed domains.

Reviewing the number of cookies on the public website.

Why it fails: Cookie counts describe website tracking implementation, not governance maturity across policy, accountability and oversight. Counting cookies is tempting because cookie banners and consent management are visible privacy artefacts, so the metric suits a narrow technical audit of web tracking rather than programme maturity evaluation.

Asking employees if they like the privacy policy.

Why it fails: Employee sentiment measures satisfaction, not governance maturity; it captures opinion rather than evidence of controls, accountability or oversight. It is tempting because surveys are a recognised privacy tool, but they belong in awareness or culture assessments, where gauging staff attitudes toward notices is genuinely the right instrument.

An email thread.

Why it fails: Email threads are informal correspondence, not governance artifacts; they lack version control, approval trails and defined ownership, so accountability cannot be evidenced. They are tempting because they document discussions and decisions in writing, which suits routine operational communication rather than formal privacy governance records.

A standard operating procedure (SOP).

Why it fails: An SOP documents the steps for executing a defined operational task, not the assignment of decision rights and accountability across roles. It is tempting because SOPs are governance artefacts, and writing one is correct when the requirement is to standardise how a repeatable privacy process is performed.

The company's mission statement.

Why it fails: A mission statement expresses organisational purpose and values; it assigns no roles, decision rights or escalation paths, so it cannot evidence who is accountable for privacy decisions. It is tempting because it is a formal governance document, and it is the right artefact when the goal is communicating the company's ethical stance.

Total replacement of the IT department.

Why it fails: Privacy governance integration changes oversight and accountability structures; it does not replace the IT department that operates systems. It is tempting because governance shifts responsibilities and can centralise privacy decision-making, but the correct benefit is embedding privacy accountability within existing IT processes, not removing IT functions.

Elimination of IT costs.

Why it fails: Integrating privacy governance into IT governance cannot eliminate IT costs; privacy controls typically add assessment, tooling and monitoring expenditure. It is tempting because governance alignment does reduce duplicated compliance effort and rework, which yields cost avoidance, but never outright cost elimination.

Simplification of external legal audits.

Why it fails: External legal audits still occur regardless of internal governance alignment; integration does not simplify them directly. It is tempting because consistent privacy documentation and controls can make audit evidence gathering smoother, but the significant benefit is embedding privacy requirements into IT decision-making, not audit reduction.

Requiring a full DPIA before every sprint.

Why it fails: A full DPIA per sprint imposes a heavyweight, document-driven assessment on every short iteration, throttling delivery and producing stale artefacts rather than continuous risk visibility. It is tempting because a DPIA is the correct instrument for a single high-risk processing change, such as a new profiling system assessed once before launch.

Waiting for the security sign-off at the end of the project.

Why it fails: Deferring privacy review to a single end-of-project sign-off leaves risks unexamined across iterations, so issues surface only after code and design are entrenched, making remediation costly. It is tempting because stage-gate sign-off suits waterfall delivery, where requirements are frozen and one approval point genuinely covers the whole release.

Hard-coding privacy requirements in the source code.

Why it fails: Embedding privacy requirements as fixed code values removes them from governance: they cannot be reviewed, versioned or adapted as processing purposes change, and developers may not recognise regulatory obligations. It is tempting because codifying validated rules enforces them automatically, which suits stable, well-understood constraints like retention periods in a batch job.

Ignore the privacy principle.

Why it fails: Ignoring the privacy principle abandons the governance obligation to evaluate the conflict and record a justified decision. It is tempting when business pressure favours speed, but disregarding a principle is only defensible after a formal assessment shows it is not legally binding in that jurisdiction.

Ask the CEO to override the privacy policy.

Why it fails: Escalating to the CEO for an override bypasses the governance body that must first assess the conflict against privacy principles and applicable law. It is tempting when executive authority appears to settle disputes quickly, yet CEO sign-off is appropriate only after that documented assessment, not as the opening step.

Immediately terminate the project.

Why it fails: Terminating the project removes any chance of reconciling the business requirement with the privacy principle, which governance expects to be assessed and documented first. It is tempting as an absolute safeguard when processing is unlawful, but that scenario calls for halting the specific data activity, not the entire project.

To satisfy customer requests for free gifts.

Why it fails: Retention policy governs how long personal data is kept and when it is deleted, supporting storage limitation and erasure obligations. Free gifts are a marketing incentive with no lawful basis, so this does not address privacy governance at all.

To save costs on hardware maintenance.

Why it fails: Cost saving is a business benefit of deleting stale data, not the governance driver. A retention policy exists to enforce storage limitation and lawful erasure under privacy regulation; hardware maintenance budgets are unrelated to data subject rights.

To increase storage space.

Why it fails: Increasing storage space is an infrastructure outcome, not a privacy objective. Retention policy limits how long personal data persists and mandates deletion once the purpose ends; capacity planning does not satisfy storage limitation or erasure requirements.