Previous posts in this series covered risk assessment, NIST CSF, and third-party risk management. Those are frameworks for evaluating and managing security posture. GDPR sits in the same space but from a different angle — it’s concerned with what happens to people when systems are built without privacy in mind, and it creates legal obligations around how personal data is collected, processed, and protected.
If you’re building or assessing systems that touch personal data — and that includes most systems, understanding GDPR isn’t optional. Even for organizations outside the EU, GDPR applies if you handle data belonging to EU residents. And beyond compliance, the principles it establishes are a reasonable baseline for how any organization should think about data.
Key Terminology
Any information that can identify a person either directly or indirectly. Direct identification includes a name. Indirect identification includes location data, online identifiers, or behavioral information that, when combined with other data, can identify an individual. A special category of sensitive personal data — political opinions, religious beliefs, sexual orientation — carries additional protections.
Any action performed on personal data: collecting, storing, using, sharing, selling, analyzing, or deleting it. If you’re touching personal data in any way, you’re processing it, and GDPR applies.
The living individual whose personal data is being processed. When you sign up for a platform or purchase a product, you become a data subject in that relationship.
The entity that determines why and how personal data is processed. An e-commerce site that collects your name and address to fulfill an order is the data controller. Controllers are ultimately accountable for personal data, even when they use third-party processors.
An organization that processes personal data on behalf of a data controller. Using the same example, the shipping company that receives your address to deliver an order is the data processor. A data processing agreement must be in place between controller and processor.
When personal data falls into the hands of an unauthorized party through hacking, human error, system failure, or poor security practices. GDPR requires notification to supervisory authorities within 72 hours of becoming aware of a breach.
What GDPR Is and Where It Applies
GDPR, the General Data Protection Regulation, is EU law that came into effect in May 2018. Its purpose is to give individuals stronger rights over their personal data and require organizations to handle that data responsibly. It replaced the Data Protection Directive, which had allowed each EU member state to create its own national privacy laws, resulting in fragmented and inconsistent protection across Europe.
Scope is broader than most people assume. GDPR applies to any organization that offers products or services to EU residents or monitors their behavior, regardless of where the organization is based. A US company with EU customers is subject to GDPR. An Australian SaaS provider with EU users is subject to GDPR. Geographic location of the company is irrelevant; what matters is whether EU residents’ data is being processed.
GDPR violations carry two tiers of fines. The first tier is up to €10 million or 2% of annual global revenue. The second tier is up to €20 million or 4% of annual global revenue. Fines are determined based on what happened, how it happened, the number of data subjects affected, the level of harm caused, and how long it took to resolve.
The Seven Principles
GDPR defines seven principles that govern how personal data must be processed. These are not aspirational guidelines. They are legal requirements that organizations must be able to demonstrate compliance with.
Lawfulness, Fairness & Transparency
Data must be processed on a valid legal basis, in a way that is fair to the individual, and with clear communication about how their data is used.
Purpose Limitation
Data collected for one purpose cannot be repurposed for something else without a new legal basis. The purpose must be specified before collection begins.
Data Minimization
Only collect data that is necessary for the stated purpose. Collecting more than you need is a violation, not a precaution.
Accuracy
Data must be kept accurate and up to date. Controllers must take steps to verify accuracy at collection and evaluate reliability before processing.
Storage Limitation
Personal data must not be kept longer than necessary for the purpose it was collected. Retention periods must be defined, documented, and enforced.
Integrity & Confidentiality
Data must be protected against unauthorized access, loss, or destruction through appropriate technical and organizational measures. This is where security controls directly support privacy compliance.
Accountability
Controllers must not only comply but be able to demonstrate compliance. Documentation, records of processing activities, privacy notices, and audit trails are all accountability mechanisms.
Lawful Bases for Processing
Every processing activity must have a valid lawful basis, and that basis must be identified before processing begins, not rationalized after the fact. There are six lawful bases under GDPR:
- Consent — freely given, specific, informed, and documented. The individual must have a genuine choice and the ability to withdraw.
- Contract — processing is necessary to perform a contract with the data subject or to take steps before entering one.
- Legal obligation — processing is required to comply with a law the controller is subject to.
- Vital interests — processing is necessary to protect someone’s life. Limited in scope and typically applies in medical emergencies.
- Public interest — processing serves a public benefit or official function.
- Legitimate interests — processing serves the controller’s or a third party’s legitimate interests, provided those interests are not overridden by the data subject’s rights and freedoms. Requires a balancing test.
No single lawful basis is inherently superior. The right basis depends on the purpose of processing and the nature of the relationship with the data subject. The chosen basis must be documented and disclosed in the organization’s privacy notice.
Individual Rights
GDPR grants individuals seven rights over their personal data. These rights can be exercised through an organization’s official channels, most commonly through a Data Protection Officer (DPO) where one is required.
Right to Be Informed
Individuals must be told that their data is being collected, the purpose, retention period, and who it may be shared with, in clear and plain language.
Right of Access
Individuals can request a copy of their personal data and supplementary information about how it’s being processed.
Right to Rectification
Individuals can request correction of inaccurate data and completion of incomplete data.
Right to Erasure
Also known as the right to be forgotten. Individuals can request deletion of their personal data in certain circumstances. Not absolute.
Right to Restrict Processing
Individuals can request that their data is suppressed rather than processed. Commonly exercised in cases involving automated decision-making.
Right to Object
Individuals can object to processing of their data in certain circumstances. For direct marketing, this right is absolute.
Right to Data Portability
Individuals can obtain their personal data in a portable format and transfer it to another organization. Applies only to data the individual has directly provided.
Privacy by Design and by Default
GDPR requires that privacy is built into systems from the ground up, not added after the fact. Privacy by design means considering data protection at the architecture stage. That means deciding what data is collected,, how it flows, where it’s stored, who can access it, and how long it’s retained. Privacy by default means that the most privacy-protective settings are the default, not the opt-in.
For anyone building or assessing systems, this is where GDPR intersects directly with technical work. Data minimization, access controls, encryption, retention policies, and audit logging are not just security controls. They are privacy requirements. A system that collects more data than necessary, retains it indefinitely, and provides broad access to it isn’t just poorly secured. Under GDPR, it’s non-compliant by design.
The integrity and confidentiality principle requires appropriate technical and organizational measures to protect personal data. That means encryption at rest and in transit, access controls, vulnerability management, and incident response — the same controls that underpin any security program. GDPR compliance and security program maturity are not separate tracks. They reinforce each other.
GDPR is often treated as a legal and compliance problem. It’s also a design problem. The organizations that struggle most with it are the ones that built systems without thinking about data flows, retention, or access — and now have to retrofit privacy into architecture that wasn’t built for it. The ones that manage it well treated privacy as a requirement from day one, the same way they treat availability or security.
