Chapter 56 Quiz: Privacy Engineering & Data Protection¶

B — MINIMIZE

MINIMIZE is the foundational privacy design strategy. It requires that personal data is not collected unless strictly necessary, is deleted as soon as it is no longer needed, and is reduced in detail where possible (e.g., collecting only zip code instead of full address). This directly implements GDPR's data minimization principle (Article 5(1)(c)). Refer to Chapter 56 Section 56.1 for the full strategy taxonomy.

B — Implement appropriate technical and organizational measures at design time and by default limit processing to what is necessary

Article 25 codifies privacy engineering into law. "By design" means privacy controls are built into the system architecture from the start — not bolted on after launch. "By default" means the most privacy-protective settings are the default (e.g., profile visibility set to private, optional data fields left blank). This is not just about encryption — it encompasses the full spectrum of Hoepman's strategies. Refer to Chapter 56 Section 56.2.

C — Right to Opt-Out of Sale/Sharing

CCPA grants consumers the right to opt out of the sale of their personal information. CPRA expanded this to include "sharing" for cross-context behavioral advertising. Businesses must provide a "Do Not Sell or Share My Personal Information" link on their homepage. Once a consumer opts out, the business cannot sell or share their data unless the consumer later opts back in. Refer to Chapter 56 Section 56.3.

B — When processing is likely to result in a high risk to rights and freedoms, including profiling, large-scale special category data, and systematic public monitoring

Article 35(3) lists three specific cases where a DPIA is mandatory, but this is not exhaustive — any processing that is "likely to result in a high risk" requires one. The Article 29 Working Party (now EDPB) identified nine criteria; meeting two or more generally triggers a DPIA requirement: evaluation/scoring, automated decision-making with legal effects, systematic monitoring, sensitive data, large scale, combining datasets, vulnerable data subjects, innovative use of technology, and cross-border transfer. Refer to Chapter 56 Section 56.4.

B — The ability to determine that two or more items of interest are related, enabling profiling and inference

Linkability is a privacy-specific threat that STRIDE does not cover. Even if data is pseudonymized, an adversary who can link records across datasets (e.g., linking anonymized medical records to anonymized fitness tracker data via timestamp correlation) can re-identify individuals. This is why Hoepman's SEPARATE strategy exists — distributing data across distinct processing environments prevents linkability. Refer to Chapter 56 Section 56.5.

C — Differential privacy

Differential privacy provides a formal, mathematical guarantee (parameterized by epsilon) that the output of a query or algorithm does not significantly change whether or not any single individual's data is included. Noise is calibrated to the sensitivity of the query. A lower epsilon provides stronger privacy but reduces utility. Apple uses local differential privacy for keyboard and emoji analytics; the U.S. Census Bureau used it for the 2020 Census. Refer to Chapter 56 Section 56.6.

B — Vulnerable to homogeneity and background knowledge attacks

k-anonymity ensures each record is indistinguishable from at least k-1 other records on quasi-identifiers (e.g., age, zip code, gender). However, if all k records share the same sensitive value (e.g., all have "cancer" as diagnosis), the attacker learns the diagnosis regardless. l-diversity addresses homogeneity by requiring diverse sensitive values, and t-closeness further requires the distribution of sensitive values in each group to be close to the overall distribution. Refer to Chapter 56 Section 56.6.

B — Classify, restrict, remediate, assess notification obligations, and update the inventory

Unclassified sensitive data in unexpected locations is a common finding during data discovery. The response must be systematic: (1) classify the data based on its sensitivity (SSNs = highest classification), (2) immediately restrict access (need-to-know only), (3) remediate the root cause (stop logging SSNs, mask existing entries), (4) assess whether unauthorized access occurred (if so, breach notification may be required under state laws and GDPR), (5) update the data inventory to ensure this data store is monitored going forward. Refer to Chapter 56 Section 56.7.

B — A standardized framework for communicating consent preferences in machine-readable format across the ad tech supply chain

Before TCF, a user's consent on a publisher's website had no standardized way to propagate to the dozens of ad tech vendors in the supply chain. TCF v2.2 defines a TC String (Transparency and Consent string) that encodes the user's choices for each purpose and vendor, which propagates through bid requests. CMPs generate the TC String based on user interaction, and vendors check it before processing data. This doesn't solve all consent problems — enforcement still depends on vendors actually respecting the signal. Refer to Chapter 56 Section 56.8.

B — One month (extendable by two months for complex requests), and automation addresses identity verification, cross-system search, redaction, and volume

GDPR Article 12(3) sets the one-month deadline. For complex or numerous requests, this can be extended by two months, but the controller must inform the data subject within the first month and explain the reasons for delay. DSAR automation platforms handle: (1) identity verification (preventing fraudulent requests), (2) automated data discovery across all systems where the subject's data resides, (3) redaction of third-party personal data from the response, (4) consistent formatting of the response package, and (5) audit trail for compliance evidence. Refer to Chapter 56 Section 56.9.

B — Standard Contractual Clauses (SCCs) with Transfer Impact Assessments, and Binding Corporate Rules (BCRs)

Schrems II (Case C-311/18) invalidated Privacy Shield because US surveillance laws (FISA Section 702, EO 12333) did not provide adequate protection. The CJEU ruled that SCCs remain valid but exporters must verify that the recipient country's laws ensure an essentially equivalent level of protection. If they don't, supplementary measures (encryption where the key is not accessible to the importer, pseudonymization, split processing) must be implemented. BCRs are more comprehensive but require supervisory authority approval, making them practical only for large multinationals. Note: the EU-US Data Privacy Framework (2023) provides a new adequacy decision, but its durability remains uncertain. Refer to Chapter 56 Section 56.10.

B — 72 hours, with details on nature, DPO contact, consequences, and mitigation measures

The 72-hour clock starts when the controller "becomes aware" — meaning has a reasonable degree of certainty that a breach has occurred (not when the investigation is complete). If notification is not made within 72 hours, the controller must provide reasons for the delay. SOC teams must have pre-built breach notification templates and escalation procedures to meet this timeline. The notification to the supervisory authority (Article 33) has a lower threshold than notification to data subjects (Article 34), which is only required when the breach is "likely to result in a high risk." Refer to Chapter 56 Section 56.11.

B — Computational overhead makes FHE impractical for real-time SOC operations

FHE enables powerful privacy-preserving analytics (e.g., searching encrypted logs without exposing content, running threat detection on encrypted network flows), but the performance penalty is prohibitive for real-time use. Practical adoption focuses on partially homomorphic encryption (PHE) supporting either addition OR multiplication (not both), and leveled/somewhat homomorphic encryption (SHE) supporting a limited number of both operations. Use cases where latency is acceptable — batch analytics on encrypted medical records, privacy-preserving machine learning training — are more viable. Libraries like Microsoft SEAL, IBM HELib, and Google's FHE transpiler are advancing the field. Refer to Chapter 56 Section 56.6.

B — Article 5(2) accountability principle and Article 30 records of processing activities

DEMONSTRATE is the strategy that closes the accountability loop. It requires organizations to provide verifiable evidence that their processing operations comply with privacy principles. This maps directly to GDPR's accountability principle (Article 5(2): "The controller shall be responsible for, and be able to demonstrate compliance with" the data protection principles) and Article 30 (maintaining records of processing activities including purposes, categories, recipients, transfers, retention periods, and security measures). Without DEMONSTRATE, the other seven strategies lack provability. Refer to Chapter 56 Section 56.1.

B — Prior consultation with the supervisory authority under Article 36

Article 36 creates a mandatory checkpoint: if a DPIA indicates that processing would result in high risk in the absence of measures taken by the controller to mitigate the risk, and the controller cannot sufficiently reduce that risk, the supervisory authority must be consulted before processing begins. The authority has up to eight weeks (extendable by six weeks for complex cases) to provide written advice. This mechanism prevents organizations from proceeding with high-risk processing without regulatory review. The SOC must document why standard mitigations (pseudonymization, access controls, retention limits) are insufficient and what additional measures were considered. Refer to Chapter 56 Section 56.4.