Select Two (Multi-Select) Questions

System logs for performance analysis

Why it fails: Performance logs support operational monitoring and capacity planning rather than privacy risk reduction, so aggressive minimisation removes diagnostic value. It is tempting because logs are voluminous and retention is costly, and minimisation would be correct for logs holding personal data beyond their lawful retention period.

Publicly available documentation

Why it fails: Publicly available documentation carries no personal or sensitive data, so minimisation yields no privacy or compliance benefit. It is tempting because large document repositories look like easy reduction targets, and minimisation would be correct for internal documents containing personal data that is no longer needed.

Database server IP

Why it fails: A server IP identifies infrastructure, not personal data, so it cannot support automated classification, consent tracking or retention enforcement. It tempts because asset inventories are legitimate governance metadata, but privacy schemas need attributes describing the data itself, such as category, purpose and lawful basis.

System uptime monitor

Why it fails: Uptime monitoring measures service availability, carrying no information about personal data, its purpose, retention or lawful basis, so it cannot drive governance automation. It tempts because monitoring metadata is genuinely useful in operations, yet privacy schemas require data-centric attributes such as classification and consent.

Storing all data in a single centralized repository.

Why it fails: Centralization can simplify management but is not essential and may introduce risks such as a single point of failure. It also does not inherently ensure data quality or compliance. Many organizations use distributed architectures successfully. Thus, it is not a required practice for life cycle governance.

Applying the same retention period to all data types.

Why it fails: A uniform retention period is inappropriate because different data types have different legal and business retention requirements. Applying one period could lead to premature deletion or excessive retention, both of which are compliance risks. Retention must be tailored to data type and jurisdiction, so this is not an essential practice.

Encrypting all data at rest and in transit.

Why it fails: Encryption is a security control that protects confidentiality but does not ensure data quality or governance. It does not address classification, retention, or accuracy. While important, it is not one of the two essential practices for maintaining data quality and compliance across the entire life cycle in this scenario.

Disabling all audit logging

Why it fails: Disabling audit logging removes accountability records rather than reducing personal data collection, so it fails minimisation and harms compliance. It is tempting because logs can contain personal data, and trimming them appears privacy-friendly, but audit trails are required for security and regulatory obligations.

Increasing the retention period for backups

Why it fails: Extending backup retention keeps personal data longer than necessary, directly contradicting minimisation, which limits collection and storage duration. It is tempting because backups support resilience and recovery, and longer retention genuinely helps availability scenarios, but privacy principles require defined, short retention with secure deletion.

Storing all raw data in a data lake for future use

Why it fails: Hoarding all raw data in a data lake retains everything indefinitely, the opposite of minimisation, which restricts collection to what is necessary. It is tempting because raw data enables future analytics and reprocessing, a legitimate goal, but minimisation demands purpose limitation and deletion rather than speculative retention.

Automatically delete all data upon receiving a DSAR to simplify the process.

Why it fails: Deleting data upon a DSAR is incorrect; the right to access is distinct from the right to erasure. Automatically deleting data could destroy evidence needed for the response and violate other legal obligations. It also fails to provide the requested information. This action would be non-compliant and harmful.

Require the requester to specify the exact database where their data is stored.

Why it fails: Data subjects are not required to know internal system details. The organization must search all relevant systems. Requiring such specificity places an unreasonable burden on the requester and violates GDPR principles. The responsibility to locate data lies with the organization, not the data subject.

Charge a fee for each DSAR to cover administrative costs.

Why it fails: Under GDPR, DSARs must generally be fulfilled free of charge. A fee can only be charged if the request is manifestly unfounded or excessive, and it must be reasonable. Charging a standard fee is non-compliant and could deter data subjects from exercising their rights, leading to penalties.

Store all patient data indefinitely to ensure it is available for future medical research or legal claims.

Why it fails: Indefinite storage violates the data minimization and storage limitation principles. Privacy regulations require that personal data be kept only as long as necessary for the purposes for which it was collected. While medical research may justify longer retention, it must be based on a specific legal basis and often requires anonymization or consent. Storing all data indefinitely increases risk and is not a defensible practice. This option contradicts the core requirement to limit retention.

Document the retention schedule in a policy but allow individual departments to deviate as needed without central oversight.

Why it fails: Allowing departments to deviate without central oversight undermines the consistency and enforceability of the retention schedule. Privacy regulations require a unified approach to ensure all personal data is handled according to legal requirements. Decentralized exceptions can lead to over-retention in some areas and premature deletion in others, both of which are non-compliant. A documented policy must be centrally governed and audited to be effective. This option introduces unacceptable risk.

Rely on the cloud provider's default retention settings for the EHR system to manage data lifecycle.

Why it fails: Cloud providers typically offer configurable retention settings, but relying on defaults is insufficient because the organization remains the data controller and is accountable for compliance. Defaults may not align with legal requirements, which vary by data type and jurisdiction. The CDPSE must ensure that retention settings are customized and documented. Delegating this responsibility to the provider without oversight is a governance failure and could lead to non-compliance.

The technical capabilities of the SaaS application to automatically enforce retention and deletion, such as built-in retention labels or policies.

Why it fails: Technical capabilities are an implementation detail, not a retention period consideration. While automation is valuable, the retention period itself must be determined by legal and business factors first. The tool's capabilities may influence how the schedule is enforced, but they do not define the appropriate duration for each data category.

The storage cost associated with retaining data in the SaaS application's cloud infrastructure, to optimize the IT budget.

Why it fails: While storage cost is a business consideration, it is not an essential privacy consideration for retention periods. Retention should be driven by legal and purpose limitations, not cost. Using cost as a primary factor could lead to premature deletion of data that must be retained for legal reasons, or retention of data beyond necessity to avoid migration costs.

The preferences of the employees whose data is being processed, as expressed through consent forms or surveys.

Why it fails: Employee preferences are not a primary determinant of retention periods. Retention is governed by legal requirements and business needs, not individual preferences. Consent may be a legal basis for processing, but it does not override statutory retention obligations. Relying on preferences could result in inconsistent and non-compliant retention practices.

Server uptime percentage

Why it fails: Server uptime is infrastructure availability telemetry and carries no personal data linkage, so it cannot locate or retrieve records for a data subject. It is tempting because uptime is a common operational metric, but it would be correct in an availability or SLA report, not a DSR-actionable inventory.

Network bandwidth usage

Why it fails: Network bandwidth usage measures traffic volume, not where personal data resides or how to retrieve it, so it cannot satisfy access or erasure requests. It is tempting because bandwidth appears in asset and capacity registers, but it would be correct for network capacity planning, not DSR fulfilment.

Retain all source records indefinitely to preserve historical accuracy.

Why it fails: Indefinite retention contradicts data minimization and retention limitation. Keeping every source record forever increases the attack surface and the risk of unauthorized reuse. Retention should be defined per purpose and per data category, with automated deletion or anonymization once the analytics need ends. Historical accuracy can be preserved through aggregated or de-identified snapshots rather than indefinite raw retention.

Grant all analytics engineers read access to the raw ingestion zone.

Why it fails: Broad read access to raw data undermines both minimization and purpose limitation. Engineers could view fields that were not approved for analytics and could copy data into ungoverned environments. Access should be scoped to the curated, purpose-bound data set, with raw access limited to a small operational group and governed by additional controls such as just-in-time elevation.

Store all ingested records in a single unpartitioned table for maximum flexibility.

Why it fails: A single unpartitioned table encourages broad access and makes it difficult to apply field-level or row-level restrictions. It increases the risk that data collected for one purpose is reused for another, which violates purpose limitation. Flexibility in storage should not come at the cost of losing the ability to segregate data by purpose, source, or retention class.

Encrypt consent records using a symmetric key stored in the application code to prevent tampering.

Why it fails: Storing a symmetric key in application code is a security anti-pattern because it can be extracted from the binary or repository. While protecting consent records from tampering is important, this method introduces a vulnerability that could compromise the integrity of the records. A hardware security module or key management service would be more appropriate, and encryption alone does not ensure enforcement across services.

Rely on the mobile operating system's permission prompts as the sole mechanism for capturing consent for all data processing purposes.

Why it fails: Operating system permission prompts typically cover device capabilities like camera or location, not the full range of data processing purposes such as analytics or marketing. Using them as the sole mechanism would fail to capture purpose-specific consent and would not provide an auditable record. The scenario requires a dedicated consent management platform, so this approach is insufficient.

Allow users to change their consent preferences only through a customer support ticket to maintain a controlled audit trail.

Why it fails: Requiring a support ticket to change consent creates friction and may not meet regulatory expectations for easy withdrawal of consent. It also introduces delays and potential errors in updating preferences across microservices. A consent management platform should provide a self-service mechanism that updates records in real time, so this approach is not appropriate for enforceable consent.

Encrypt all personal data at rest using AES-256.

Why it fails: Encryption protects confidentiality but does not limit retention or provide evidence of disposal. Data can remain encrypted indefinitely, still violating storage limitation. While encryption is a valuable security control, it does not address the requirement to dispose of data when no longer needed or to verify that disposal occurred. Therefore it is not essential for meeting the stated retention and verifiability objectives.

Conduct annual privacy training for all employees.

Why it fails: Training raises awareness but does not enforce retention periods or produce verifiable disposal records. It is a supportive measure, not a direct control for ensuring data is not over-retained. The scenario requires operational mechanisms that define and enforce retention and that can prove deletion, so training alone is insufficient and not one of the two essential controls.

Store all personal data in a single centralized database to simplify management.

Why it fails: Centralization may simplify some aspects, but it does not inherently enforce retention limits or provide verifiable disposal. In fact, a single large repository can increase risk if compromise occurs. The objective is to ensure timely and provable deletion, which requires retention policies and automated disposal with logging, not merely consolidating storage. Thus this option does not meet the requirement.

Disable point-in-time recovery on the relational database so that deleted rows cannot be restored.

Why it fails: Disabling point-in-time recovery removes a valuable operational safeguard and does not by itself guarantee that deleted rows are purged from existing backups and snapshots. The correct approach is to manage backup retention and expiry, not to disable recovery, which would increase risk without fully addressing residual copies.

Rely on the database's automatic vacuum process to remove deleted rows from all storage layers.

Why it fails: Vacuum reclaims space from deleted rows in the live database but does not remove data from backups, snapshots, or point-in-time recovery logs. It also does not touch the object storage bucket. Relying on vacuum alone leaves residual copies in backup and recovery layers, so deletion requests would not be fully honored.

Enable object lock in governance mode on the bucket to prevent any deletion of personal data.

Why it fails: Object lock in governance mode prevents deletion and would directly conflict with the requirement to honor deletion requests. Governance mode can be bypassed by privileged users, but the intent of the control is immutability, which is the opposite of what a deletion capability needs. It does not help purge non-current versions or backups.

Implementing access controls to restrict who can view the data during its active use.

Why it fails: Access controls are part of the data storage and use phases, not disposal. They are used to protect data while it is being retained and processed. While important for overall security, they do not relate to the secure destruction of data after its retention period ends. Therefore, this activity is not part of the disposal phase.

Collecting consent from data subjects for processing their personal data.

Why it fails: Consent collection occurs during the data collection phase, before any processing. It is a legal basis for processing and is not related to disposal. Once data is being disposed of, consent is no longer relevant, as the data should no longer be processed. Thus, this is not a disposal activity.

Encrypting data at rest to protect it from unauthorized access.

Why it fails: Encryption at rest is a security control used during the storage phase to protect data confidentiality. It does not destroy data and is not a disposal activity. While encryption can facilitate cryptographic erasure when keys are destroyed, the act of encrypting data is not part of the disposal process itself.

Allow the vendor to use the data for its own product improvement purposes to reduce costs.

Why it fails: Permitting the vendor to use the data for its own purposes would constitute a separate processing activity that is likely incompatible with the original purpose and may violate data protection laws. It also increases privacy risk because the firm loses control over the data. Vendor risk management should restrict the vendor to processing only on documented instructions, not for its own benefit.

Rely on the vendor's standard terms of service without customization to expedite the contract.

Why it fails: Standard terms of service are typically designed to protect the vendor, not the customer's privacy obligations. They often lack the specific data protection, breach notification and audit provisions required by privacy regulations. Relying on them without customization can leave the firm unable to demonstrate compliance and may limit its ability to manage vendor-related privacy risks.

Transfer all accountability for data protection compliance to the vendor through a liability waiver.

Why it fails: Accountability for compliance cannot be fully transferred to a vendor. The firm remains responsible for ensuring that processing complies with applicable laws, even when using a processor. A liability waiver may shift financial risk but does not absolve the firm of regulatory obligations. This approach would weaken oversight and could be seen as an attempt to circumvent accountability.

Increase the number of privacy impact assessments conducted annually.

Why it fails: While PIAs are valuable, simply increasing their number without addressing the root causes of employee access issues may not improve governance. The incidents involved unauthorized access, suggesting a need for training and oversight rather than more assessments. PIAs are typically project-focused and may not directly mitigate employee behavior.

Publish a revised privacy notice on the organization's website.

Why it fails: Updating a privacy notice improves transparency but does not directly strengthen internal governance or prevent unauthorized employee access. It is a communication tool, not a control. The incidents described require structural and educational remedies, not just external disclosures.

Delegate all privacy decision-making to the IT security department.

Why it fails: Delegating privacy decisions solely to IT security can lead to a technology-centric approach that overlooks legal, ethical, and operational privacy considerations. Privacy governance requires cross-functional input and should not be siloed. This action could weaken accountability and fail to address the cultural and process issues behind the incidents.

Conducting daily monitoring of privacy compliance activities

Why it fails: Daily monitoring is an operational task typically performed by the privacy office or compliance staff, not by a steering committee. The committee's role is strategic oversight, not hands-on execution. Assigning daily monitoring to the committee would be inefficient and detract from its governance responsibilities, which focus on direction, resource allocation, and risk oversight.

Developing detailed privacy training materials for employees

Why it fails: Developing training materials is an operational task usually handled by the privacy office or learning and development teams. The steering committee may approve the training strategy, but creating content is not its core responsibility. The committee's focus should remain on strategic oversight, resource allocation, and resolving high-level issues, not on tactical content development.

Performing technical vulnerability assessments on privacy systems

Why it fails: Technical vulnerability assessments are typically conducted by IT security or privacy engineering teams. The steering committee does not perform technical work; it provides governance and oversight. While the committee may review assessment results and prioritize remediation, conducting the assessments themselves falls outside its scope and would distract from its strategic role.

An annual privacy training session for all employees.

Why it fails: Annual training is a valuable awareness tool, but it is not a governance mechanism for ongoing oversight and accountability. It does not provide a structure for decision-making, performance review, or enforcement. While training supports a privacy culture, it lacks the continuous monitoring and executive engagement that a steering committee or defined roles provide, so it is not an essential governance component for the CPO's objective.

A one-time privacy risk assessment conducted at the start of the program.

Why it fails: A one-time risk assessment provides a snapshot but does not support ongoing oversight. Privacy risks evolve with business changes and regulatory updates, so continuous or periodic assessments are needed. A single assessment cannot ensure accountability over time and may become outdated quickly. It is a tactical activity, not a governance component that provides sustained oversight.

A privacy policy that is published on the company website.

Why it fails: Publishing a privacy policy is a transparency requirement and informs external stakeholders, but it does not constitute a governance mechanism for internal oversight and accountability. A policy document alone does not ensure that roles are defined, performance is monitored, or decisions are made. It is an output of governance, not a component that drives ongoing accountability.

Automatic increase in quarterly revenue.

Why it fails: Revenue growth stems from commercial performance, not privacy governance; a mature programme reduces regulatory and reputational risk and evidences accountability to regulators. The option is tempting because executives often demand demonstrable return on compliance investment, yet privacy benefits are expressed as avoided fines and preserved trust, never guaranteed income.

Elimination of the need for an IT department.

Why it fails: Privacy governance defines policy, accountability and data-handling controls; it cannot remove the infrastructure, application support and operations an IT department delivers. The option tempts because governance centralises data oversight and automates some manual tasks, but that consolidation supplements IT rather than replacing the technical function entirely.

Guarantee that no data breaches will ever occur.

Why it fails: Governance reduces risk through accountability, transparency and controls, but no programme can eliminate breaches; attackers and human error persist. It is tempting because breach prevention is the headline goal of privacy work, and it would be correct if the stem asked for an aspirational outcome rather than a realistic benefit.

The privacy office is responsible for negotiating all contracts with third-party data processors.

Why it fails: Contract negotiation is typically handled by legal or procurement, not the privacy office. While the privacy office should review contracts for privacy clauses, making it responsible for all negotiations dilutes its focus and may exceed its expertise. The charter should specify privacy review and approval rights, not full contract ownership.

The privacy office reports directly to the Chief Financial Officer to ensure budget alignment.

Why it fails: Reporting to the CFO may secure funding, but it does not necessarily provide the independence or authority needed to enforce privacy. Privacy governance requires a reporting line that allows objective decision-making, often to the CEO, board, or a dedicated risk committee. CFO reporting can create conflicts of interest, especially when privacy investments compete with financial targets.

The privacy office must obtain approval from the marketing department before updating privacy policies.

Why it fails: Requiring marketing approval for privacy policy updates undermines the privacy office's independence and could delay necessary changes. Privacy policies must reflect legal and regulatory requirements, not marketing preferences. The privacy office should have the authority to update policies with input from stakeholders, but not be subject to their veto.

A mandate to block all internet access.

Why it fails: Blocking all internet access is a network-security control that prevents legitimate business processing and does nothing to govern lawful personal data handling. It tempts as an extreme protective measure, but it would be correct only in isolated high-security enclaves; privacy governance instead needs retention limits, consent management and oversight.

The office floor plan.

Why it fails: An office floor plan is physical facilities documentation and addresses no privacy principle such as lawfulness, retention or data-subject rights. It tempts because physical layout can relate to security zoning, but it would be correct only for facilities or safety planning, not as a governance framework component.

A list of employee social media passwords.

Why it fails: Collecting employee social media passwords is itself a privacy and security violation, creating credential-handling risk rather than governing personal data processing. It tempts as an apparent access-control measure, but it would be correct only in no legitimate scenario; governance instead requires documented policies, accountability and data-subject rights.