A practical guide for developers to GDPR compliance

1. GDPR for developers
Bozhidar Bozhanov

2. About me
• Founder and CEO of LogSentinel
• Former IT advisor to the deputy prime minister of Bulgaria
• Software engineer
• Privacy advocate
• Top 50 stackoverflow contributor
• https://techblog.bozho.net
• @bozhobg

3. What is GDPR?
Regulation
Panic!
Opportunity
• a.k.a. direct common EU law
• overrides / supercedes national data protection laws
• extends the existing directive
• Huge fines for non-compliance (4% of turnover or 20 million euro)
• Insufficient understanding on what has to be done (consultants,
regulators, companies)
• To really protect your customers’ data
• To get your systems secure

4. Pros and cons of GDPR
• Cons:
• Bureaucratic
• Not always clear
• Requires most systems to be upgraded (burden)
• Doesn’t solve all data protection issues
• Leaves issues at the discretion of local regulators
• Pros:
• Unifies data protection in Europe
• Mandates best practices
• Requires consciousness about personal data processing

5. Why do YOU care?
• You may be:
• implementing GDPR-related upgrades
• be designated as a DPO (data protection officer)
• implementing anything that handles data
• conscious about personal data in your organization

6. Terminology
Data subject
Personal data
Data processing
• a.k.a. User (person whose personal data is processed)
• Any data about an identifiable or identified person
• Any operation (manual or automated) on personal data
Controller • The entity (company) that requests and uses the data
Processor
• Any entity that processes data on behalf of a controller (e.g. cloud
service providers)

7. GDPR principles
Lawfulness
Purpose limitation
Data minimisation
Accuracy
Storage limitation
Integrity and confidentiality
…magic

8. What about cookies?
• ePrivacy directive -> ePrivacy regulation
• Somehow different than GDPR
• Answers some questions unanswered by GDPR:
• Tracking cookies
• Traffic data
• Direct marketing
• Opinion – should have been a unified regulation
• With the upcoming ePrivacy regulation – no more useless cookie warnings
• Also: directive for processing personal data by law enforcement

9. When to process personal data
• User’s consent
• Performance of a contract
• If required by law
• Legitimate interest of the controller (including direct marketing)
• Combination of the above

10. GDPR functionalities
• Functionalities are only part of it – processes/procedures/rules must also exist
• “Forget me” (the right to erasure)
• Mark profile as restricted (right to restriction of processing)
• Export data (right to portability)
• Allow profile editing (right to rectification)
• “See all my data” (right to access)
• Consent checkboxes
• Age checks
• Data destruction (data minimization principle)

11. “Forget me”
• Delete all data relating to a user
• void forgetUser(UUID userId);
• Useful for integration tests
• What about foreign keys?
• Allow nullable foreign keys
• Anonymize user (leave only ID)
• Cascade delete
• Option: mark for deletion (+user cleanup job)

12. “Forget me”
• Event-sourcing?
• Crypto-shredding
• Blockchain?
• Notify 3rd parties / call 3rd parties APIs:
• CRMs, Payment gateways, etc.
• Return 404 for indexable pages
• Backups – store anonymized IDs separately
• “My data model doesn’t allow for it” is no excuse

13. Restrict processing
• Mark user as “restricted”
• Boolean database column
• Button on profile page “restrict processing of personal data”
• Button on admin page
• Don’t show in searches, don’t send emails, don’t include in automated processing
• Mark as restricted in 3rd party systems (e.g. with a custom field)
• Don’t show on public pages / 404
• Why?
• Edge cases: user objects to erasure;

14. Export data
• Right to data portability (no vendor lock-in; in theory)
• Formats: JSON, XML, CSV or other standards
• Schema: prefer schema.org
• Could be a background process that sends email when done
• Could be a manual process (easier to get compliant)
• All personal data + all data, associated with the user (orders, messages, etc.)
• Logs? No
• Data from 3rd party systems? Yes
• they should have that functionality as well

15. Editable user profile
• Right to rectification
• All personal data fields should be editable
• Could be a manual support process: “please fix my name”
• Data obtained from 3rd parties
• If email/phone is included, user should be able to identify with that email/phone
(“shadow accounts”)
• If not – manual process

16. Ask for consent
• No more “I accept the Terms and conditions and the privacy policy”
• Unchecked checkbox for each processing purpose on registration
• Data processing business processes to be listed in a register
• User should be able to withdraw consent from the user profile page
• If data is used for machine learning, get explicit consent for that
• Store consent in a secure way
• Boolean column may or may not be enough, depending on the regulator
• Consents table?
• Timestamping?
• Re-request consent for existing users via email
• Oral consent
• Workarounds: consent vs contract with electronic signature?

17. “See my data”
• Overlaps with “export data”
• Allow non-registered users to check if you have data about them
• Confirm email
• Show the processing records from the register

18. Age check
• On registration ask for age / date of birth / (checked) checkbox “I’m older than 16”
• Ask parent for consent
• How?
• Nobody has a clue 
• “The controller shall make reasonable efforts to verify in such cases that consent is
given or authorised by the holder of parental responsibility over the child, taking into
consideration available technology.”
• Proposal: ask for parent’s email, send a link and get the registration confirmed
• Proposal: upload “parent selfie”
• Proposal: eID

19. Limit data retention
• Don’t store data for longer than “necessary”
• Database column for “data retention deadline”
• Scheduled job to delete/anonymize/pseudonymize data that past its deadline
• Deadline vs confirmation event, e.g. “goods delivered”
• Applicable to “purchase without registration”
• Theoretically applicable to registered users
• In practice: “I agree to having my address stored for the purpose of not entering it
again on subsequent purchases”

20. Do’s (encryption)
• Encrypt data in transit
• between application and database
• between application and 3rd parties
• between application and database nodes (gossip)
• between multiple applications / microservices
• obviously: between user and application
• between load balancer and application?
• Encrypt data at rest
• LUKS or database-specific encryption
• Encryption key: ideally on HSM / AWS KMS / …
• Encrypt backups

21. Do’s
• Implement pseudonymization
• replace personal data with bcrypt/PBKDF?
• don’t use real production data for staging/test
• pseudonymize for machine learning purposes
• Protect data integrity
• Simple solution: do nothing  Procedures should indicate integrity is guaranteed by
the database via checksums
• Other options: checksum column per record, enforced in the application layer, audit
trail, 3rd party solutions like LogSentinel

22. Do’s
• Have your GDPR register of processing activities in something other than Excel
• Internal web app / microservice or a 3rd party service
• Integrate with consent checkboxes and “right to access”
• Correlate audit logs with processing activities
• Audit log for the register itself
• Backups, high availability
• Log access to personal data
• Implied from the accountability principles
• Correlate with processing activity
• Search results / lists? Log “User X did query Y”
• Register all API consumers (no anonymous access)

23. Data breaches
• Notify data protection regulator
• Notify controllers (if you are a processor)
• Notify users
• Option: Configure your security incident system to report to the data protection regulator
• Have proof of when the breach was discovered (timestamp emails/issues?)
• Will it help? Questionable
• (Dilbert)

24. Don’t’s
• Don’t use data for purposes other than what he user has agreed with
• Request consent via email for new purposes
• Legitimate interests can be dynamically added
• Don’t log personal data – just ID
• Cleanup old log files
• Don’t put unnecessary registration fields
• Don’t assume 3rd parties are compliant
• Don’t assume having ISO XXX makes you compliant
• Don’t dump personal data on public servers/buckets 
• …and other obvious stuff

25. Conclusion
• GDPR would require changes, mostly
• Best practices
• Useful to customers
• The majority of changes can be implemented within 2-3 sprints
• GDPR forces better understanding of data flows
• Compliance likely to be checklist-based
• Beware of consultants claiming GDPR will require rewriting everything and asking for a
lot of money
• Regulators will need some teaching
• The spirit of the regulation: be conscious about personal data

26. Thank you
Bozhidar Bozhanov: bozhidar.bozhanov@logsentinel.com