The most common GDPR exam trap is the "we are not an EU company" defense. It does not work:
GDPR applies to any organization, anywhere in the world, that processes personal data of EU/EEA residents.
- US company with EU customers: GDPR applies to EU customers' data
- Australian company with EU employees: GDPR applies to EU employees' HR data
- Chinese company selling products to EU consumers: GDPR applies to EU buyer data
What qualifies as personal data under GDPR: name, address, email, phone, photo, bank info, IP address (yes!), location data, cookie identifiers, health data, genetic data, biometric data. The definition is intentionally broad. If a piece of information can identify a person, it is personal data.
GDPR penalties for serious violations: up to 4% of annual global turnover OR €20 million, whichever is higher. For a company with $1 billion in global revenue, 4% = $40 million potential fine — larger than the €20M fixed alternative.
Exam trap: "The company processes EU customer IP addresses and cookie data. Does GDPR apply?" Yes — IP addresses and cookie identifiers are personal data under GDPR.
Data role questions require distinguishing four roles. Three quick classifiers:
- Data Owner: described as a SENIOR BUSINESS EXECUTIVE (VP, director, department head). Makes classification and access DECISIONS. NOT a technical role. "The VP of Marketing is responsible for deciding who can access customer data" = Data Owner.
- Data Controller: GDPR term. The ORGANIZATION (or person) that DECIDES WHY data is processed and HOW it will be used. Primary GDPR accountability. "The hospital decides what patient data to collect and for what medical purposes" = Controller.
- Data Processor: GDPR term. Third party that PROCESSES data per the controller's INSTRUCTIONS. Does not independently decide purpose. "The cloud provider stores patient records as directed by the hospital" = Processor.
- Data Custodian / Steward: TECHNICAL role implementing controls. Sets labels, configures access controls, applies encryption, monitors access. "The DBA encrypts the database and configures role-based access" = Custodian.
Critical exam trap: "Who is the data owner of the customer database?" If the choices include the DBA, the CISO, and the VP of Sales, the answer is the VP of Sales. Data ownership is a business accountability role; technical roles are custodians regardless of how much control they have over the data technically.
The right to erasure (right to be forgotten) is the most commonly tested GDPR individual right. One principle governs its implementation:
Deletion must reach every copy of the data, including backups.
Common incomplete erasure scenarios that still violate GDPR:
- Deleting from the production database but retaining in monthly backup archives
- Removing from the customer-facing system but keeping in an analytics data warehouse
- Deleting active records but leaving in transaction logs or audit trails
- Anonymizing in production but keeping identifiable data in replicas or staging environments
When the right does NOT apply (exceptions where erasure can be refused): data must be retained to comply with a legal obligation, data is needed for the exercise of legal claims, data serves legitimate public interest (health, scientific research), or freedom of expression and information applies.
Practical requirement: organizations must maintain a data inventory (knowing where all copies of personal data exist) BEFORE they can respond to erasure requests. Without a data inventory, finding and deleting all copies is impossible.
Exam questions sometimes conflate privacy and security. They are different concepts that overlap:
- Security = protecting data from unauthorized ACCESS (attackers, thieves, unauthorized insiders). Addresses the CIA triad. "Did an unauthorized person get the data?"
- Privacy = governing how data is USED with individuals' knowledge and consent. "Are we using data in ways that respect individuals' rights, even if the access is authorized?"
Privacy violations without security breaches: sharing customer data with marketing partners without consent (authorized access, privacy violation). Retaining customer data indefinitely after the purpose is served (no breach, GDPR violation). Using employee health data for performance reviews without consent (authorized internal use, privacy violation).
Security breach without privacy violation: encrypted data is stolen; since the data is properly encrypted and keys were not compromised, the data is unreadable. Security event but potential HIPAA safe harbor applies (may not be reportable).
Exam trap: "The company implemented strong encryption and access controls. Is their privacy program complete?" No — privacy also requires: purpose limitation (only use data for stated purposes), data minimization (collect only what is needed), retention limits (delete when no longer needed), and individual rights (right to access, correct, delete, and port their data).
Practice Scenarios
A European customer submits a formal GDPR erasure request to an e-commerce company. The customer's account shows: purchase history from 2018-2022, email marketing preferences, saved payment method tokens (not actual card numbers), a product review posted publicly in 2021, and shipping address history. The company's legal team has confirmed there is no ongoing legal obligation requiring retention of this customer's data. Map out the complete erasure response: what must be deleted, from which systems, and whether any elements can be retained.
Answer: Complete erasure analysis for each data element: (1) Purchase history (2018-2022): Must be deleted from the production order management database. Must be deleted from backup archives (all backup generations that contain this customer's order records). Must be deleted from the analytics data warehouse if identifiable (aggregate reports that cannot be linked back to this individual may be retained if truly anonymized). Must be deleted from email marketing history if order history informed targeting. (2) Email marketing preferences: Must be deleted. However, a minimal suppression record (email address + "erasure request completed, do not contact") may be retained to comply with the right to erasure itself — without it, the organization cannot ensure it does not accidentally re-add the individual to marketing lists. This is a recognized exception in GDPR guidance. (3) Payment method tokens: Must be deleted from the customer's account. The payment processor (as a separate data controller or processor) has independent retention obligations for fraud prevention and dispute resolution under PCI DSS. The e-commerce company should delete its reference to the token; the payment processor may have separate legal grounds to retain transactional records. (4) Product review (public, 2021): This is a complex case. The review is content the customer created and posted publicly. GDPR erasure rights generally apply, but content published in the public interest, for research, or for freedom of expression may have exceptions. Standard practice: the company should anonymize the review (remove the name/username/account link) rather than delete the review content itself, if the review does not contain personal identifiers. If the customer insists on full deletion of the content, legal counsel should assess whether this falls under freedom of expression exceptions. (5) Shipping address history: Must be deleted from the account profile and all associated systems (CRM, customer service platform, fulfillment history, backup archives). After completing deletion: document the erasure request receipt and completion date (retain this record as a compliance record of fulfilling the right, not as the customer's personal data). Notify the customer in writing within 30 days of receiving the request that erasure has been completed. If full erasure is not technically possible within 30 days (e.g., backup rotation schedules), notify the customer of the timeline and the specific limitations.
A hospital (Hospital A) uses three external parties: (1) a cloud provider to host its electronic health records system; (2) a billing company to process insurance claims on its behalf; (3) an analytics firm that the hospital has authorized to use de-identified patient data to improve healthcare outcomes research. Inside Hospital A: the VP of Clinical Operations oversees which patient data categories are maintained and who may access them; the DBA team manages encryption, access controls, and backup verification; the hospital board bears ultimate accountability for HIPAA compliance. Identify the data role for each entity and individual.
Answer: Role classifications with reasoning: (1) Hospital A (overall): Data Controller under GDPR/primary entity under HIPAA. Hospital A decides WHY patient data is collected (for treatment) and HOW it is processed (clinical, billing, and research purposes). Hospital A bears primary HIPAA compliance accountability as a covered entity. All three external parties are engaged by Hospital A under Hospital A's direction. (2) Cloud provider: Data Processor under GDPR; Business Associate under HIPAA. The cloud provider stores and manages EHR data per Hospital A's instructions without making independent decisions about the data's purpose or use. The cloud provider processes data on the controller's (Hospital A's) behalf. Must have a HIPAA Business Associate Agreement in place. (3) Billing company: Data Processor / Business Associate. Processes insurance claim data on Hospital A's behalf under Hospital A's direction (using data provided by Hospital A for the specific purpose of billing). Does not independently determine what claims to submit or what patient data to retain. Must have BAA with Hospital A. (4) Analytics firm: This is more complex. If the analytics firm is using truly de-identified data per HIPAA safe harbor standards (18 specific identifiers removed; no reasonable way to re-identify), the firm is NOT a business associate and the data is not PHI — HIPAA does not apply to properly de-identified data. If the data is not truly de-identified or if the firm could re-identify it, the firm is a business associate and a Data Processor. Under GDPR, even de-identified data may still be personal data if re-identification is reasonably possible. The analytics firm's role depends on the quality of de-identification. (5) VP of Clinical Operations: Data Owner. Senior business executive accountable for a data category (patient clinical data). Makes decisions about which data is maintained, who may access it, and retention policy. Accepts residual risk on behalf of the clinical operations business unit. NOT a technical role. (6) DBA team: Data Custodians. Technical staff implementing day-to-day controls: encryption, access controls, backup verification. Implement the policies set by the data owner. (7) Hospital board: Ultimate governance accountability, but this maps to the organizational data controller role rather than the individual "data owner" role in Security+ terminology. The board has fiduciary and compliance accountability for the organization as a whole.
A retail company operating in the US and EU is building its first formal data inventory (GDPR records of processing activities). The company collects: customer purchase history, customer loyalty program data (names, emails, purchase patterns), employee HR records, payment card data processed through a third-party payment processor, website analytics (cookies, IP addresses, page views), and supplier contact information. Design the data inventory structure and identify which data categories require GDPR-specific treatment.
Answer: Data inventory structure: the inventory should be maintained as a structured record with the following fields for each data category: (a) Data category name, (b) Description and examples, (c) Data owner (accountable executive), (d) Processing purpose(s), (e) Legal basis for processing (GDPR Article 6 basis: consent, contract, legal obligation, legitimate interest, etc.), (f) Data subject categories (EU/US customers, employees, EU visitors), (g) Storage location(s) including all copies, (h) Sensitivity classification, (i) Retention period, (j) Third parties with access (processors), (k) International transfer mechanisms if data leaves EU. Inventory entries for each category: (1) Customer purchase history: Owner = VP of Marketing. Purpose: order fulfillment, customer service, personalization. Legal basis: contract performance (EU customers). Locations: order management database, backup archives, analytics warehouse. Retention: 7 years (financial records requirement). GDPR treatment: required — EU customers are data subjects. Erasure requests and access requests must be handled for EU customers. (2) Loyalty program data: Owner = VP of Marketing. Purpose: personalized offers, loyalty rewards. Legal basis: consent (EU customers must have opted in with clear consent). Locations: CRM system, email marketing platform, backup archives. Retention: duration of membership + 2 years. GDPR treatment: required; consent must be documented and revocable; includes names and emails = personal data. (3) Employee HR records: Owner = VP of Human Resources. Purpose: employment management, payroll, compliance. Legal basis: contract (employment contract) and legal obligation. Locations: HR system, payroll processor, backup archives. Retention: during employment + 7 years post-employment. GDPR treatment: required for EU-based employees; employee records are personal data; employees have access and correction rights. (4) Payment card data: Owner = CFO/Finance. Purpose: payment processing. IMPORTANT: data is processed by third-party payment processor (separate data controller for processing); the retailer's PCI DSS scope depends on whether card data passes through retailer systems or is tokenized directly. If tokenized at point of entry, minimal PCI scope. GDPR treatment: account numbers are personal data; processor relationship requires Data Processing Agreement. (5) Website analytics (cookies, IP addresses): Owner = VP of Marketing/IT. Purpose: website performance, user behavior analysis. Legal basis: consent (GDPR cookie consent required for EU visitors). Locations: analytics platform, backup. Retention: typically 13 months maximum. GDPR treatment: required; IP addresses are personal data under GDPR; cookie consent banner mandatory for EU visitors; must honor cookie opt-outs. (6) Supplier contact information: Owner = VP of Procurement. Purpose: supplier relationship management. Legal basis: legitimate interest. Locations: procurement system. GDPR treatment: if supplier contacts are EU residents (e.g., individual freelancers), GDPR applies. If contacts are corporate entities, GDPR may not apply (GDPR protects natural persons, not companies). Individual names at supplier companies are still personal data if they identify a person. Prioritization: loyalty program data (consent-based = most complex), website analytics (cookie law compliance), and employee records (EU employees) should be addressed first given GDPR requirements.