Compliance & Privacy
Data classification, GDPR, Russian 152-ФЗ, PCI DSS scope reduction, privacy-by-design, retention/deletion policy and controller-vs-processor duties.
8 questions
MiddleTheoryVery commonWhat does EU data-protection regulation GDPR require of an engineer in practice?
What does EU data-protection regulation GDPR require of an engineer in practice?
Every processing operation rests on one documented lawful basis — consent is one of six, not the default. Systems must serve subject rights: access, rectification, erasure, portability. A breach reaches the supervisory authority within 72 hours of awareness; subjects only if their risk is high.
Common mistakes
- ✗Treating consent as the only lawful basis when six exist
- ✗Reading the 72-hour clock as a duty to notify every data subject
- ✗Assuming a passed audit proves the processing is lawful and the system secure
Follow-up questions
- →When must the data subjects themselves be notified of a breach, and why then?
- →Why is the legitimate-interest basis harder to rely on than it first appears?
JuniorTheoryCommonWhat is data classification, and why does it drive every downstream control?
What is data classification, and why does it drive every downstream control?
Classification assigns each dataset a sensitivity tier — public, internal, confidential, regulated — by the harm its disclosure would cause. That tier then dictates encryption, access, retention and residency, so controls follow risk instead of habit.
Common mistakes
- ✗Treating classification as a labelling exercise rather than the input that selects controls
- ✗Classifying only the primary database, leaving logs, backups and exports untiered
- ✗Assuming one blanket control set is adequate for every sensitivity tier
Follow-up questions
- →How does a classification tier map to concrete evidence an auditor can inspect?
- →How would special-category data under health-privacy law
HIPAAchange your tiers?
JuniorTheoryCommonWhat do privacy by design and by default require when you build a feature?
What do privacy by design and by default require when you build a feature?
Privacy is designed in, not bolted on: collect only the fields a stated purpose genuinely needs, keep them only while that purpose lasts, and pseudonymise wherever identity is not required. By default the least-sharing setting is already active, without the user changing anything.
Common mistakes
- ✗Equating privacy by design with a consent banner added just before launch
- ✗Shipping the most permissive defaults and expecting users to tighten them
- ✗Believing encryption removes the duty to minimise what is collected and kept
Follow-up questions
- →When does a change need a formal impact assessment — a
DPIA— before it ships? - →How does pseudonymisation differ from anonymisation for regulatory purposes?
JuniorTheoryCommonWhat does a retention policy do, and how does erasure interact with a legal hold?
What does a retention policy do, and how does erasure interact with a legal hold?
A retention policy sets, per data class, how long a record lives and what deletes it — logs, backups and exports included. Erasure requests are honoured inside that frame, but a legal hold freezes deletion for the disputed records only; every other schedule keeps running.
Common mistakes
- ✗Exempting logs, backups and exports from the retention schedule
- ✗Treating a legal hold as an estate-wide freeze rather than a scoped one
- ✗Counting a soft delete or a cold archive as genuine erasure
Follow-up questions
- →How do you satisfy an erasure request against immutable backups?
- →Why does an instinct to keep every log forever conflict with retention duties?
MiddleTheoryCommonHow do controller and processor differ, and what does a data processing agreement fix?
How do controller and processor differ, and what does a data processing agreement fix?
The controller decides why and how data is processed and holds primary accountability; the processor acts only on the controller's documented instructions. The contract fixes scope, security measures, sub-processor approval, breach reporting and end-of-contract deletion.
Common mistakes
- ✗Assuming a processor may reuse the data for its own purposes
- ✗Thinking that outsourcing the processing also outsources the accountability
- ✗Leaving sub-processor approval and end-of-contract deletion out of the contract
Follow-up questions
- →What assurance does a processor's
SOC 2Type II report add over a Type I? - →Who notifies the supervisory authority when it is the processor that is breached?
MiddleTheoryOccasionalWhy is scope reduction the primary strategy under card standard PCI DSS?
Why is scope reduction the primary strategy under card standard PCI DSS?
Every system that stores, processes or transmits cardholder data — plus anything that can reach it — sits in the cardholder data environment and inherits the whole control set. Tokenisation and hosted payment fields keep the raw number out, and segmentation walls off the rest.
Common mistakes
- ✗Believing a passed assessment proves the environment is actually secure
- ✗Forgetting that systems merely able to reach the card environment are in scope
- ✗Treating encryption of stored card numbers as equivalent to tokenisation
Follow-up questions
- →How does tokenisation differ from encrypting the stored card number for scope?
- →How can a control be satisfied on paper while the underlying risk remains?
MiddleTheoryOccasionalWhat does Russian personal-data law 152-ФЗ require of a service serving RU citizens?
What does Russian personal-data law 152-ФЗ require of a service serving RU citizens?
Personal data of Russian citizens must be recorded, systematised and updated in databases located in Russia; a foreign copy is permitted only downstream of that primary. Processing needs a documented ground, usually purpose-scoped consent, and the operator notifies Roskomnadzor.
Common mistakes
- ✗Reading localisation as a total ban on any copy held outside Russia
- ✗Treating a single blanket consent as covering unrelated new purposes
- ✗Forgetting the operator's own notification duties to the regulator
Follow-up questions
- →How do localisation duties interact with a cross-border transfer to a processor?
- →Why does adding a new processing purpose usually require fresh consent?
SeniorDesignRareYour SaaS serves EU and Russian customers from one platform. Product wants a single global user store; legal has flagged EU regulation GDPR and Russian personal-data law 152-ФЗ. Three sub-processors sit in the flow — a US analytics vendor, an EU email provider and a global CDN. An enterprise buyer is demanding your SOC 2 Type II report plus a data-flow map, and your management system under ISO 27001 carries an open risk you cannot close this quarter. Constraints — one product codebase, no per-region forks; the analytics vendor cannot be replaced before next year; audit evidence must be producible without manual screenshots. Design the data-flow map, the residency split, the processor contracts and the way you carry the unclosable risk. What do you record, where does each data class live, and what evidence do you produce?
Your SaaS serves EU and Russian customers from one platform. Product wants a single global user store; legal has flagged EU regulation GDPR and Russian personal-data law 152-ФЗ. Three sub-processors sit in the flow — a US analytics vendor, an EU email provider and a global CDN. An enterprise buyer is demanding your SOC 2 Type II report plus a data-flow map, and your management system under ISO 27001 carries an open risk you cannot close this quarter. Constraints — one product codebase, no per-region forks; the analytics vendor cannot be replaced before next year; audit evidence must be producible without manual screenshots. Design the data-flow map, the residency split, the processor contracts and the way you carry the unclosable risk. What do you record, where does each data class live, and what evidence do you produce?
Map each data class to its store, purpose, lawful ground and destination first. Russian primary records stay in Russia; EU data stays in the EU, with a transfer mechanism for the US vendor. Contract every sub-processor, accept the open risk with an owner and expiry date, and let controls emit their evidence.
Common mistakes
- ✗Designing one global store first and treating residency as a later migration
- ✗Carrying an unclosable risk informally instead of as a dated, owned acceptance
- ✗Collecting audit evidence by hand when the controls themselves could emit it
Follow-up questions
- →Why do manual screenshots fail as audit evidence once the control count grows?
- →What makes a risk acceptance legitimate rather than an open-ended excuse?
