Privacy Risk Management And Compliance practice questions

Proceed with the project and monitor for data breaches.

Why it fails: The risk must be mitigated or accepted formally before proceeding.

Inform the public about the risk to maintain transparency.

Why it fails: Informing the public is not the immediate remediation step for a high-risk internal assessment.

Switch to a less intrusive profiling algorithm without re-evaluating the DPIA.

Why it fails: A re-evaluation is necessary to ensure the new algorithm is actually less risky.

Disable the data transfer feature until a local data center is provisioned.

Why it fails: This is a business decision, not a regulatory compliance requirement if legal mechanisms are in place.

Perform a Data Protection Impact Assessment (DPIA) specifically for the transfer.

Why it fails: A DPIA is a risk assessment tool, not a legal mechanism to authorize international data transfers.

Update the Privacy Policy to inform users about the international transfer.

Why it fails: Transparency is required, but it does not fulfill the legal requirements for a transfer mechanism.

The specific hardware models used for storage.

Why it fails: Hardware models are not personal data and GDPR Article 13 does not require them; the Right to be Informed concerns purposes, lawful basis, recipients and retention. It is tempting because infrastructure transparency appears diligent, but that belongs in security documentation, not the Privacy Notice.

The name of the Chief Privacy Officer.

Why it fails: Naming the Chief Privacy Officer is not an Article 13 mandatory element; the Right to be Informed requires purposes, lawful basis, recipients, retention periods and data subject rights. It is tempting because it offers a contact route, but the notice must instead identify the controller and, where applicable, the Data Protection Officer.

The company's annual revenue.

Why it fails: Annual revenue is corporate financial data, not information about processing, so it cannot satisfy Article 13. It is tempting because revenue indicates organisational scale and accountability, but that figure belongs in financial disclosures; the notice must state purposes, lawful basis and retention instead.

The name of the supervisory authority that will handle complaints.

Why it fails: While data subjects have the right to lodge a complaint with a supervisory authority, the privacy notice must inform them of this right, but it does not require naming a specific authority. The notice should state that they can complain to a supervisory authority, but listing one particular authority is not mandatory.

A list of all third parties with whom data is shared.

Why it fails: The GDPR requires informing data subjects of recipients or categories of recipients, not an exhaustive list of all third parties. Providing categories is sufficient. Listing every third party could be impractical and is not required by law. This option overstates the requirement.

The retention period for each data category.

Why it fails: The GDPR requires informing data subjects of the retention period or, if not possible, the criteria used to determine it. However, specifying a precise retention period for each data category is not mandatory; the criteria suffice. This is a common misconception, but the regulation allows flexibility.

Ensure that the cloud provider is certified under the EU-U.S. Privacy Shield framework.

Why it fails: The EU-U.S. Privacy Shield was invalidated by the Court of Justice of the European Union in 2020 (Schrems II). It is no longer a valid transfer mechanism. Organizations must use other frameworks like the EU-U.S. Data Privacy Framework (if applicable) or SCCs with supplementary measures. Relying on Privacy Shield would be non-compliant and ineffective.

Implement end-to-end encryption for all data transfers to render the data unintelligible to unauthorized parties.

Why it fails: End-to-end encryption is a strong security control but does not by itself make a cross-border transfer lawful. Legal transfer mechanisms such as SCCs or adequacy decisions are still required. Encryption can be a supplementary measure to protect data, but it does not replace the need for a valid transfer framework. Therefore, it is not one of the essential actions for lawful transfers.

Obtain explicit consent from all customers for each cross-border transfer of their personal data.

Why it fails: While consent can be a legal basis for transfers, it is not always feasible or appropriate, especially for routine financial processing. GDPR allows other mechanisms like SCCs or Binding Corporate Rules. Relying solely on consent for all transfers would be impractical and may not satisfy banking regulations that require robust safeguards. Consent is just one option, not an essential action for all transfers.

The right to lodge a complaint with a supervisory authority

Why it fails: This right is specific to GDPR and is not required under CCPA/CPRA. GDPR Article 13(2)(d) mandates informing data subjects of their right to lodge a complaint with a supervisory authority. CCPA/CPRA does not have a supervisory authority complaint mechanism; instead, it provides a private right of action for certain breaches. Thus, this element alone does not satisfy both.

The legal basis for processing

Why it fails: GDPR requires disclosure of the legal basis for processing, but CCPA/CPRA does not have an equivalent requirement. CCPA/CPRA focuses on notice at collection and disclosure of categories, not legal bases. Therefore, including the legal basis is not necessary for CCPA/CPRA compliance, though it is for GDPR. This element alone does not satisfy both.

The right to opt out of the sale or sharing of personal information

Why it fails: This right is specific to CCPA/CPRA and is not required under GDPR. GDPR does not have a concept of 'sale' of personal data, though it provides the right to object to processing. While GDPR requires information about the right to object, it is not the same as the opt-out of sale. Therefore, this element does not satisfy both regulations simultaneously.

A self-certification by the data exporter that its security controls are sufficient.

Why it fails: Self-certification is not a recognized transfer mechanism under GDPR Chapter V. The controller cannot unilaterally declare adequacy. Valid mechanisms include adequacy decisions, SCCs, Binding Corporate Rules, and specific derogations. A self-certification would not satisfy the legal requirements for a cross-border transfer.

Verbal consent from the data subjects obtained during a phone call.

Why it fails: Consent can be a derogation under Article 49 for occasional transfers, but it must be explicit, informed, and documented. Verbal consent is difficult to prove and does not meet the written documentation standards. It is also not a sustainable mechanism for systematic transfers, and the question asks for valid mechanisms, not derogations.

A Binding Corporate Rules (BCR) framework approved by the competent supervisory authority.

Why it fails: BCRs are a valid transfer mechanism for intra-group transfers, but they require approval by the competent supervisory authority and are not applicable to transfers to independent third parties. The scenario does not specify an intra-group transfer, so BCRs are not a general solution. They are also complex and time-consuming to implement.

Automated archival of location history after one week.

Why it fails: Archiving after one week is a retention control applied after collection, so it does not determine whether geolocation should be gathered at all. Retention limits are tempting as a privacy measure, but the first principle is purpose limitation and lawful basis, which precede any storage schedule.

Publicly disclosing the use of geolocation in the privacy policy.

Why it fails: Disclosure in a privacy policy is a transparency control, not a lawful basis; it cannot authorise collection. Geolocation is personal data requiring a lawful basis and consent (or another Article 6 ground) before any processing begins. Publicising the use is a later accountability step, appropriate once the lawful basis and notice content are settled.

Full encryption of geolocation data in transit.

Why it fails: Encryption protects data in transit but does not address whether collection itself is lawful, necessary or consented to, which must be established before any technical safeguard. Encryption is tempting because it is a visible control, yet purpose limitation and consent govern the initial collection decision.

Perform a Data Protection Impact Assessment (DPIA) to document the risk.

Why it fails: A DPIA documents and assesses risk but does not remove plain text passwords, leaving the exposure intact. It would be the correct choice when the requirement is to evaluate privacy impact and compliance before processing, not to remediate storage.

Conduct a data breach simulation to see if the vulnerability is exploitable.

Why it fails: A breach simulation tests exploitability but leaves the plaintext passwords exposed throughout, so the vulnerability persists. Simulations suit validating detection and response readiness once exposure is contained. The immediate requirement is removing plaintext storage itself — hashing and salting stored credentials — which simulation cannot achieve.

Implement an access control list (ACL) to restrict who can see the plain text passwords.

Why it fails: An ACL restricts who can read the stored passwords but leaves them in plain text, so any bypass, backup or insider exposure still reveals them. ACLs would be correct for limiting network or file access, not for removing plain text storage.

Perform a penetration test on the CSP's multi-tenant environment.

Why it fails: Penetration testing a multi-tenant environment without authorisation is contractually prohibited and targets technical vulnerabilities, not GDPR accountability. It tempts because testing validates controls, and it would be the right step for assessing your own systems or a single-tenant deployment you control.

Verify the CSP's physical data center location to ensure it is within the EU.

Why it fails: EU data residency alone does not satisfy GDPR Article 28, which requires a data processing agreement and verified processor obligations. Location checks are tempting because transfers outside the EEA need safeguards, but residency is only one element of third-party privacy risk.

Review the CSP's SOC 2 Type II report for general system reliability.

Why it fails: SOC 2 Type II addresses security, availability and processing integrity, not GDPR lawful basis, data subject rights or cross-border transfer safeguards. It is tempting because it is a recognised assurance report, and it would suit vendor security due diligence rather than privacy risk management.

Request the third party to delete the data until a contract is signed.

Why it fails: Deletion is not the immediate requirement; processing may continue under an existing lawful basis while a contract is negotiated. Requesting deletion suits terminating an unnecessary transfer, not regularising an ongoing one that must be governed by a data processing agreement.

Disable the API endpoint connecting to the third party to prevent further data exposure.

Why it fails: Disabling the endpoint halts a transfer that may already be lawful, and the requirement is to establish a governing contract, not to sever connectivity. Disabling suits containing an active breach or unauthorised exfiltration, where continued transmission itself causes harm.

Immediately notify the supervisory authority of the data transfer.

Why it fails: Notifying the supervisory authority is triggered by a reportable personal data breach, not by discovering an undocumented transfer. Notification would be the immediate requirement once the transfer is confirmed to constitute a breach meeting the reporting threshold.

A manual email ticketing system for data subject access requests.

Why it fails: A manual email ticketing system requires staff to read, route and action each request, which does not automate the opt-out process and cannot scale to web visitor volume. Ticketing suits low-volume, complex data subject access requests; opt-out automation requires a self-service web mechanism recording preferences directly.

An automated script that permanently deletes user accounts after 30 days of inactivity.

Why it fails: Deleting inactive accounts after 30 days addresses data retention and minimisation, not opt-out, and would destroy records needed to honour a visitor's opt-out preference. Automated retention scripts suit lifecycle and storage-limitation requirements; opt-out automation requires capturing and enforcing a consumer's sale-sharing preference.

An internal dashboard for employees to view customer purchase histories.

Why it fails: An internal dashboard showing purchase histories gives staff visibility into consumer data but provides no mechanism for a web visitor to signal opt-out, so it cannot automate that request. Employee-facing analytics dashboards suit internal reporting; opt-out automation requires a consumer-facing preference or consent control.

Restricting all data transfers to only encrypted tunnels.

Why it fails: Encrypted tunnels protect data in transit but do not by themselves satisfy cross-border transfer rules, which require a lawful transfer mechanism such as Standard Contractual Clauses or an adequacy decision. Encryption is the correct control for confidentiality of data in motion, not for transfer legality.

Relying on the internal 'Group Privacy Policy' as an adequacy decision.

Why it fails: A private group policy is a contractual arrangement between affiliates, not a legal adequacy decision granted by the European Commission, so it cannot authorise transfers to the US. It is tempting because binding corporate rules genuinely legitimise intra-group transfers, but they require supervisory authority approval rather than self-declaration.

Self-certification under the U.S. Commerce Department's privacy program.

Why it fails: The Commerce Department self-certification framework was invalidated by the Schrems II ruling, so it no longer provides a valid transfer mechanism to the US. It is tempting because it once offered a streamlined compliance route, and a replacement framework now exists, but the stem specifies the period after the earlier framework's invalidation.

Enable automated data deletion scripts after the application deployment phase.

Why it fails: Scheduling deletion only after deployment leaves retention periods undefined during development and testing, where behavioural data is already processed. Automated deletion is a valid storage-limitation control, but it must be designed alongside collection, not bolted on post-deployment.

Configure the database to encrypt all fields regardless of sensitivity to ensure maximum protection.

Why it fails: Blanket field-level encryption ignores data sensitivity classification, so the PIA cannot demonstrate purpose limitation or data minimisation. Encryption is a security control for protecting data at rest, appropriate once collection scope is justified — not a substitute for privacy-by-design decisions about what to collect.

Conduct a post-implementation audit to identify potential data leakage points.

Why it fails: A post-implementation audit detects leakage after data has already been processed, which is detective, not privacy-by-design. It is tempting because audits are genuine assurance activities, but the prioritised action should be a data protection impact assessment and minimisation embedded before collection begins.

To calculate the budget required for security hardware.

Why it fails: A DPIA produces risk findings and mitigation actions, not costings for hardware. Budgeting follows from those findings but is a finance activity. A DPIA is the right choice when the question concerns identifying and reducing privacy risks of a processing activity.

To train employees on the company's privacy policies.

Why it fails: A DPIA assesses privacy risks and mitigations for a specific processing activity before it begins; awareness training is delivered through separate privacy programmes. Training is the right answer when the requirement is demonstrable workforce competence rather than analysis of a processing operation's risks.

To verify the system uptime requirements of the application.

Why it fails: A DPIA examines privacy risks to data subjects, not availability targets. Uptime requirements belong to business impact analysis or service-level design. A DPIA would be the correct instrument when assessing necessity and proportionality of processing, or risks arising from new technologies.

The vendor management list.

Why it fails: A vendor management list records third-party suppliers and their risk ratings, not the lawful basis for processing employee data. It is tempting because vendors may process personal data, but it would be the correct artefact when assessing processor contracts or supply-chain risk, not when establishing a legal basis.

The firewall configuration log.

Why it fails: A firewall configuration log records permitted and denied network traffic, revealing nothing about lawful grounds for processing employee data. It is tempting because it evidences technical security controls around personal data, but it would be the correct document when demonstrating network segmentation or access enforcement, not legal basis.

The employee handbook.

Why it fails: An employee handbook communicates workplace policies and conduct rules to staff; it does not document the lawful basis for each processing activity. It is tempting because it addresses employees and may mention data protection, but it would be the correct source for internal policy obligations, not the record of legal grounds.

Review the vendor's insurance policy coverage.

Why it fails: Insurance coverage concerns cost recovery, not breach response; reviewing it first delays containment and notification duties owed to regulators and affected individuals. Policy review is genuinely relevant later, when quantifying financial exposure, but the immediate priority is determining what data was compromised and containing the incident.

Demand the vendor perform an independent audit of their systems.

Why it fails: An independent audit is a later containment and assurance activity; the first step is to assess the breach's scope and impact on the organisation's own data and customers, then activate the incident response and vendor notification obligations. Audits are appropriate once immediate exposure is understood and evidence preserved.

Suspend all services provided by the vendor immediately.

Why it fails: Immediate blanket suspension can disrupt critical business services and destroy forensic evidence before scope is established; the first step is assessing impact and initiating the incident response process. Suspension is appropriate only once the breach's extent and the vendor's containment posture are understood and continuity plans allow it.

Marketing brochures describing the product features.

Why it fails: Marketing brochures describe product features and carry no record of consumer data-access requests or disclosures. They tempt because they are readily available compliance-adjacent documents, yet the Right to Know requires demonstrable processes for receiving, verifying and fulfilling consumer requests for their personal information.

The latest penetration test report for the customer portal.

Why it fails: A penetration test report evidences security testing of the portal, not the consumer request and disclosure workflow the Right to Know requires. It tempts because audits commonly request penetration tests, but CCPA Right to Know demands verifiable processes for receiving, verifying and responding to consumer data-access requests.

A list of all employees with database access.

Why it fails: A list of employees with database access addresses access control, not consumer data-access requests. It tempts because auditors do examine access lists, but the Right to Know requires evidence of processes for receiving, verifying and responding to consumer requests for their personal information, which this list does not show.

Implementing strict multi-factor authentication for developers.

Why it fails: Multi-factor authentication governs who may access systems, not how personal data is masked or substituted during test execution. It is tempting because MFA genuinely hardens developer access to production-like environments, and it would be the right control when the risk is unauthorised access to test infrastructure rather than exposure of live personal data within test datasets.

Full encryption of the test database.

Why it fails: Encrypting the whole test database leaves production-like personal data readable to anyone with database credentials or application access, so exposure during testing persists. It is tempting because encryption satisfies storage-level controls, but masking or synthetic data generation removes the personal data itself, which is what testing privacy demands.

Restricting the test environment access to only senior engineers.

Why it fails: Restricting access to senior engineers still lets those individuals view and copy live personal data, and least-privilege by role does not reduce the data's sensitivity. It is tempting because it limits the audience, but de-identification through masking, pseudonymisation or synthetic data is the control that actually protects personal data in testing.

The system is too slow for real-time credit processing.

Why it fails: Processing latency is a performance matter, not a privacy one; the Right to Explanation concerns a data subject's ability to obtain meaningful reasons for an automated credit decision. Slow throughput does not impede that entitlement. Latency would be the correct concern when assessing whether an automated system meets real-time operational service levels.

The cost of maintaining the automated system infrastructure.

Why it fails: Infrastructure cost is a commercial consideration, not a privacy issue. The Right to Explanation obliges the controller to give data subjects meaningful information about the logic behind an automated credit decision. Cost would be the correct focus when evaluating budget or total cost of ownership for maintaining the automated system.

The inability of the system to process non-numeric data types.

Why it fails: Data-type handling is an engineering limitation, not the privacy concern: the Right to Explanation requires meaningful insight into how a decision was reached. Opaque machine-learning models can resist such explanation. Processing non-numeric data is a routine capability question, unrelated to a data subject's entitlement to understand an automated credit refusal.