GDPR doesn’t mandate specific encryption algorithms or key lengths; instead, it requires that personal data be protected using "appropriate technical and organisational measures" to ensure a level of security suitable to the risk.
Let’s see this in action. Imagine a small e-commerce business, "Artisan Crafts," that collects customer names, addresses, and payment card details.
Here’s a simplified view of their data flow and how encryption plays a role:
1. Website Form Submission: When a customer fills out an order form:
Customer fills form -> Data sent over TLS (HTTPS) -> Web server
The transmission from the customer’s browser to Artisan Crafts’ web server is secured by TLS (Transport Layer Security), commonly seen as HTTPS. This encrypts the data in transit, meaning it’s scrambled while traveling across the internet.
2. Data Storage: Once the data hits the web server, it needs to be stored.
Web server receives data -> Data written to database (e.g., PostgreSQL)
Here, Artisan Crafts decides to encrypt the sensitive fields in their PostgreSQL database, like customer_name and payment_card_number. They might use PostgreSQL’s built-in pgcrypto extension.
Example SQL for encryption:
-- Storing encrypted data
INSERT INTO customers (customer_name, email, encrypted_card_details)
VALUES ('Alice Smith', 'alice@example.com', pgp_sym_encrypt('{"number": "1234567890123456", "expiry": "12/25"}', 'mysecretkey'));
-- Retrieving and decrypting data
SELECT customer_name, email, pgp_sym_decrypt(encrypted_card_details, 'mysecretkey') AS decrypted_card_details
FROM customers
WHERE customer_name = 'Alice Smith';
This encrypts the data at rest, meaning it’s scrambled while sitting in the database files.
3. Payment Gateway Integration: Artisan Crafts uses a third-party payment gateway.
Web server sends payment details to Payment Gateway API -> Encrypted via TLS
The communication between their web server and the payment gateway is again secured with TLS. The actual credit card number might not even touch Artisan Crafts’ servers directly if they use a hosted payment page or a secure tokenization service.
4. Data Processing and Analytics: For internal reporting, Artisan Crafts might need to process order data.
Data extracted from database -> Decrypted for analysis -> Anonymized/Pseudonymized
Before analysis, sensitive data is decrypted. However, for broader analytics or sharing with marketing teams, they would pseudonymize or anonymize it. Pseudonymization involves replacing direct identifiers with artificial ones (e.g., replacing 'Alice Smith' with 'Customer_ID_12345'). Anonymization removes identifiers entirely.
Data Protection by Design and Default
This scenario illustrates "Data Protection by Design and by Default."
- By Design: Encryption was considered and implemented from the outset for sensitive data fields. It wasn’t an afterthought. Artisan Crafts chose to encrypt
customer_nameandpayment_card_numberin the database, and they ensuredHTTPSwas used for website communication. - By Default: When new customer accounts are created, or new orders are placed, the system automatically applies these encryption measures. Customers don’t have to opt-in to have their data encrypted in transit or at rest; it’s the standard, default protection.
The core problem this solves is mitigating the impact of a data breach. If Artisan Crafts’ database were compromised, an attacker would find encrypted payment card details and names, not plain text information. This significantly reduces the risk of identity theft or financial fraud for their customers. The specific choice of pgcrypto or a particular TLS version is less important than the principle of protecting the data at each stage.
The most surprising thing about GDPR’s encryption requirements is that they are not prescriptive about how to encrypt, but rather about the outcome of security. This means that a company could technically use older, less secure encryption methods if they can demonstrate that, given the specific risks and the nature of the data, those methods provide an "appropriate" level of security. However, this is a high bar to clear, and in practice, using current industry-standard strong encryption is the only sensible approach to meet the "appropriate" standard.
A common misconception is that if you encrypt data, you are automatically compliant. However, encryption is just one part of a holistic security strategy. If your encryption keys are poorly managed, stored insecurely, or if the system has other vulnerabilities (like SQL injection that allows attackers to bypass encryption or extract data before it’s encrypted), then encryption alone won’t satisfy GDPR. The key management itself must be secure.
The next concept to grapple with is the GDPR’s emphasis on data minimization and purpose limitation, which, when combined with encryption, further strengthens data protection.