GDPR · Domain 6
Data Protection by Design & Default
About 15% of the exam
Article 25 in two halves
By design
- Measures chosen when the means are decided
- Principles built into the processing itself
- Pseudonymization and minimization named as examples
- State of the art and cost weighed
By default
- Only data necessary for each purpose
- Least amount, shortest time, fewest people
- Nothing published without human intervention
- Settings start private, not open
Article 25 binds the controller rather than the software vendor, so procurement questions and configuration choices are where the duty actually lands
Article 33, telling the authority
- Deadline
- seventy two hours from awareness
- Awareness
- reasonable certainty data was compromised
- Late notice
- must carry reasons for delay
- Threshold
- unless risk to rights is unlikely
- Content
- nature, numbers, consequences and measures
- Phased reporting
- send more as you learn it
- Processor duty
- tell the controller without undue delay
The processor never notifies the authority itself, and no fixed hour count applies to the processor's own report to the controller
Article 34, telling people
- Triggered by high risk to individuals
- Without undue delay, no fixed hours
- Clear plain language, not legal wording
- Describe likely consequences and your measures
- Give the officer contact details
- Suggest steps people can take
The three exemptions
- Data was unintelligible, typically strong encryption
- Later measures removed the high risk
- Individual contact needs disproportionate effort
- Public communication then replaces individual notice
- The authority can still order you
Breach types
- Confidentiality
- unauthorized access or disclosure
- Integrity
- data altered without authorization
- Availability
- data lost, destroyed or locked
- Combined
- many incidents hit several at once
- Not every incident
- only where personal data is involved
Documenting every breach
- Record facts, effects and remedial action
- Record the decision not to notify
- Keep the reasoning, not just the outcome
- The authority can ask to see it
- Register covers notified and unnotified alike
Article 32 security measures
- Pseudonymization and encryption where appropriate
- Confidentiality, integrity, availability and resilience
- Restore availability after a physical incident
- Test and evaluate the measures regularly
- Risk based, not a fixed checklist
- State of the art and cost weighed
- Processors owe this duty directly
Article 32 is why weak security turns one breach into two findings, the incident itself and the failure that allowed it to happen
Responding to a breach, step by step
- Contain and preserve evidence
- Confirm personal data is involved
- Start the seventy two hour clock
- Assess risk to rights and freedoms
- Notify the authority or record why not
- Tell people where the risk is high
- Review and improve the controls
- Awareness cannot be deferred by inaction
- Staff knowledge counts as the controller's
- A partial notification beats a late one
- Each breach is assessed on its own
Design techniques worth naming
- Pseudonymization with keys held separately
- Aggregation and coarse granularity by default
- Local processing instead of central collection
- Automatic deletion when retention expires
- Access controls tied to job role
- Privacy settings default to the tightest
Assessing breach risk
- Type of breach and data involved
- How easily people can be identified
- Severity of the likely consequences
- Special categories raise the stakes
- Number of individuals affected
- Whether the data was recoverable
Breach response failures
- Clock started at the board briefing
- A staff report sat unread for weeks
- No decision record for unnotified incidents
- Encryption claimed while keys were stolen
- Notice written in legal boilerplate
- No rehearsal before the real thing
Rapid recall: security articles
- Article 4(12)
- definition of a personal data breach
- Article 24
- controller responsibility
- Article 25
- design and default
- Article 32
- security of processing
- Article 33
- notify the supervisory authority
- Article 34
- communicate to the individuals
- Article 35
- data protection impact assessments
Clocks in one place
- Authority notice
- seventy two hours from awareness
- Individual notice
- without undue delay
- Processor to controller
- without undue delay
- Rights requests
- one month, extendable by two
- Prior consultation
- eight weeks, extendable by six
Overlapping notification duties
- Network security law
- separate deadlines to different authorities
- Communications providers
- their own breach rules apply
- Sector regulators
- finance and health add reporting
- Contractual notice
- customers may demand faster warning
- Law enforcement
- may ask you to hold announcements
- Insurers
- notice does not change legal duties
Reference strip: design, default, security, notification, records
Design
- Built in when means chosen
- A controller duty, not the vendor's
- Certification helps demonstrate it
Default
- Least data, shortest retention
- Fewest people with access
- Nothing public without action
Security
- Risk based Article 32 measures
- Test and evaluate regularly
- Processors owe it directly
Notification
- Seventy two hours to the authority
- High risk means telling people
- Encryption can excuse individual notice
Records
- Log every breach
- Keep the reasoning for silence
- Show the register on request
Quick exam traps
- Trap: The seventy two hour clock starts when the breach occurred
- Trap: Encryption removes the duty to notify the supervisory authority
- Trap: A processor must notify the supervisory authority within seventy two hours
- Trap: Breaches below a certain number of records need no record at all
- Trap: Data protection by design is satisfied by buying certified software
- Trap: Notification can wait until the investigation is complete
- Trap: Availability incidents such as ransomware are not personal data breaches
cybercertprep.com · original revision sheet written from the public body of knowledge