DEV Community: Yanik Peiffer

GDPR for Developers: What You Actually Need to Know

Yanik Peiffer — Thu, 05 Feb 2026 10:36:28 +0000

GDPR for Developers: What You Actually Need to Know

Nobody gets into software engineering because they're excited about data regulations. GDPR is one of those topics that most of us want to hand off to the legal team and never think about again. And for the most part, that's fine. You don't need to become a privacy lawyer.

But if you're building systems that touch personal data, and you almost certainly are, there are parts of GDPR that land squarely on your desk. Not as legal questions, but as engineering requirements. The regulation doesn't just say "protect user data" in some vague sense. It defines specific things your system must be able to do, and those things have real architectural implications.

This post is my attempt to break down the parts of GDPR that actually matter to us as developers. No legalese, no compliance checklists, just the stuff you need to know to build systems that won't get your company into trouble.

What This Post Covers

What counts as personal data (it's broader than you think)
The core principles that should shape how you handle data
The rights users can exercise against your system

What Is Personal Data?

GDPR defines personal data as:

"Any information relating to an identified or identifiable natural person, where identifiable means someone who can be identified directly or indirectly by reference to identifiers like a name, identification number, location data, or an online identifier."

The key phrase here is directly or indirectly. The definition is intentionally broad, and it catches more than most developers expect.

The obvious stuff: names, email addresses, phone numbers, physical addresses, dates of birth. No surprises there.

The less obvious stuff: IP addresses, server access logs, cookie identifiers, session IDs, device fingerprints, user-agent strings. If you can trace it back to a specific person, even by combining it with other data, it's personal data. Your nginx logs? Personal data. Your analytics events with user IDs? Personal data.

The important nuance: pseudonymized data is still personal data. Hashing an email address or replacing a name with a UUID doesn't get you off the hook if the mapping between the pseudonym and the real identity exists somewhere in your system. Only fully anonymized data, where it's genuinely impossible to re-identify the person, falls outside GDPR's scope.

This matters because it affects decisions you make every day: what you log, what you store in your databases, what you pass between services, and what you send to third-party analytics tools.

GDPR Concerns for Developers

GDPR is a rabbit hole nobody wants to enter. The full regulation is dense, and most of it deals with organizational and legal obligations that aren't your problem as a developer. But there are two categories that absolutely are:

How you handle data, a set of principles that should shape your architecture
What users can demand, a set of rights that translate directly into system capabilities

Let's go through both.

The 7 Principles of Data Handling

Think of these as design constraints. They're defined in Article 5 of the GDPR, and every one of them has implications for how you build your systems.

1. Lawfulness, Fairness & Transparency

Any data processing must be legal and fair, and the information about what you're doing with user data must be easily accessible and written in plain language.

For you as a developer, this means: build clear consent flows, surface honest privacy notices, and don't do any hidden data collection. If your app is silently sending data to a third-party service that the user doesn't know about, that's a problem.

2. Purpose Limitation

Data should only be collected for specified, explicit, and legitimate purposes. You can't repurpose it for something the user didn't agree to.

A classic violation: collecting an email address for login, then silently feeding it into a marketing pipeline. If the user signed up to use your app, that's not consent to receive your newsletter.

3. Data Minimisation

Processing must be adequate, relevant, and limited to what is necessary. Don't collect more than you need.

Don't ask for a date of birth if all you need is an age verification boolean. Don't log full HTTP request bodies if you only need status codes for monitoring. Every additional piece of personal data you collect is a liability in terms of storage, security, and compliance.

4. Accuracy

Personal data must be kept up to date, and inaccurate data should be corrected promptly.

This means your system needs mechanisms for users to update their own data. Think profile update endpoints, data validation on input, and workflows for handling correction requests.

5. Storage Limitation

Data should only be stored for as long as it's necessary for the purpose it was collected for. Once it's no longer needed, it should be deleted.

This is where things get interesting in distributed architectures. You need TTLs on your data, retention policies, and automated deletion jobs. But when a user's data lives across ten different microservices, each with its own database, cache layer, and possibly a separate event store, coordinating that cleanup is a real engineering challenge.

6. Integrity & Confidentiality

Personal data must be processed securely, with protection against unauthorized access, accidental loss, and damage.

The practical checklist: encryption at rest and in transit, proper access controls, audit logging, and regular security assessments. Nothing new here, but GDPR makes it a legal requirement, not just a best practice.

7. Accountability

You must be responsible for, and able to demonstrate, compliance with all of the above.

Good intentions aren't enough. You need audit trails, processing records, and documentation that proves your system handles data correctly. If a regulator comes knocking, "we think we're compliant" doesn't cut it.

Rights That Users Can Exercise

This is where GDPR gets very concrete for developers. Users have a set of rights they can actively exercise against your system, and each one translates into a capability your software must support.

Here's the short version:

Access: "Show me what you have on me."
Your system must be able to locate and export all personal data you hold on a given user, across all services.

Rectification: "Fix my data."
Users can request corrections to inaccurate data, and those corrections need to propagate everywhere the data lives.

Erasure: "Delete everything about me."
The right to be forgotten. Every service, every cache, every search index, every backup, all of it needs to be covered.

Portability: "Give me my data so I can take it elsewhere."
You need to provide the user's data in a structured, machine-readable format, typically JSON or CSV.

Restriction: "Stop processing my data, but don't delete it."
Your system needs a way to freeze data in place without actively using it.

Objection: "I don't want you using my data for this purpose."
Users can opt out of specific processing activities, like marketing or profiling.

No Automated Decisions: "Don't let an algorithm decide things about me."
If your system makes automated decisions that significantly affect users (credit scoring, automated rejections, etc.), you need a human-review fallback.

The bottom line: users can ask you to find, fix, freeze, export, or delete their data at any time, and you have 30 days to comply.

Best Practices for AWS IAM: Strengthening Your Security

Yanik Peiffer — Thu, 05 Oct 2023 13:17:54 +0000

Amazon Web Services (AWS) Identity and Access Management (IAM) is the cornerstone of security when it comes to managing access to AWS resources. And everyone that has worked with AWS knows, how powerful and sometimes complicated IAM can be. At least I had some trouble when I began diving into the AWS universe.

To make your AWS account, but also your infrastructure, secure, there are many best practices out there that we can, and probably should, implement. From my experience, the following ten practices are crucial when using AWS as a production environment.

What security best practices do you always make sure to follow?

1. Safeguard Your AWS Root User Access Keys

This should be your first action after setting up your AWS account. You never want someone to have access to your AWS account as a root user. There are horror stories out there, where people had to pay immense AWS bills because their root account got hijacked. And no one wants to be that person who needs to ask AWS to regain access (if that's even possible).

To avoid your root access being stolen, give it a very secure password, store it in a vault, and just never use it to access AWS. You can create yourself as an IAM user with the required permissions for your daily operations.

2. Enable Multi-Factor Authentication (MFA)

The second action you want to do after setting up your AWS account is to enable multi-factor authentication. In a perfect world, every IAM user should have MFA enabled. But for sure your root access user needs to have it. With MFA you can add a layer of security by requiring users to provide a second authentication factor, such as a time-based one-time password (TOTP) generated by a phone. It is not even bound to a specific app, you can use e.g. Google Authenticator or Microsoft Authenticator.

3. Use Roles for Delegating Permissions

IAM roles are a powerful feature in IAM that allows you to grant permissions to entities like AWS services, users, or resources without the need to share long-term access keys. Roles work by defining a set of permissions, which are specified in an IAM policy, and then allowing trusted entities to assume the role. Once, a service or a user makes use of the role, AWS creates temporary credentials. You can use roles throughout your whole AWS infrastructure.

4. Follow the Principle of Least Privilege

The principle of least privilege means, that by default, a user or a role does not have any permission at all. Depending on the needs, you grant atomic permission required to perform only necessary tasks. Every additional, not necessary permission, can create a security vulnerability.

Sounds good in theory, right? Especially when starting with AWS, it is quite difficult and time-consuming to only apply the least privilege to users. There are many situations where I'm stuck debugging because some roles do not have the correct permissions. But anyway, this practice is crucial when setting up a production environment. We can start with giving wider permissions, but at some point, we need to take our time and focus on securing all roles down to the least privileges.

5. Begin with AWS Managed Policies

A good starting point when digging into IAM and policies is to use the default policies that AWS offers. There are many and for every scenario, you can find a matching policy. In many cases though, the default policies give a user/role too many permissions. Always consider modifying the policy and remove all unnecessary permissions.

6. Implement a Strong Password Policy

Strong passwords should be used by any user who wants to work with AWS. Make sure to force everyone to have a strong password by defining robust password policies for your IAM users. IAM gives you various options to configure: require complex passwords, regular password changes, and lockouts after too many failed login attempts.

7. Utilize Roles for Applications on EC2 Instances

When you want to connect applications that run on an EC2 instance to other resources such as databases or S3 storage, you can make use of roles. As an alternative to storing credentials within your EC2 instance, roles simplify the whole access to those resources. AWS automatically creates temporary credentials when your EC2 instance makes use of a provided role. On top of simplicity, you make your setup more secure.

8. Avoid Sharing Access Keys

I cannot think of any scenario where it is really necessary to share access keys. We always want to make sure that we know who is using our infrastructure. Make sure to create independent access keys for every user who needs to interact with AWS. This might be more effort setting up all users, but in the end, it is easier to reject access to single parties if you have to.

9. Remove Unnecessary Access Permissions

I created a recurring reminder to check our AWS permissions every three months. Most of the time there is no need to modify anything, but this way I make sure that we always use policies with the least privileges and only authorized users have access to our AWS account.

10. Monitor and Audit AWS Activities

Services like AWS CloudTrail allow you to track actions across your AWS account, focusing on security compliance and threat detection. It helps you maintain security compliance by tracking and recording all API calls and actions performed within your AWS account. Monitoring activities allows you to detect suspicious or unauthorized actions. You can set up alerts and triggers to notify you when specific events occur, such as failed login attempts, changes to security groups, or access to sensitive data.

Conclusion

In conclusion, implementing these AWS IAM best practices is not just about ticking off items on a security checklist, it's about building a robust, and secure foundation for your AWS environment. In my opinion, there are more exciting topics within the AWS world, but mastering IAM is one of the most important ones. We should always focus on improving the security of our infrastructures. And of course, it let's us sleep better at night, knowing we won't wake up to a data breach. 😉