GDPR: What Do You Need to Know?

Organizations must comply with GDPR requirements to safeguard user data, prevent misuse, get users' informed permission, and be subject to severe financial penalties for noncompliance. Check out this post for vital insights.

Since EU General Data Protection Regulation (GDPR) began enforcement on May 25, 2018, its real and severe penalties have been handed out. So, what is GDPR, to whom does it apply, and what happens when you run afoul of its regulations?

You can read the official regulations and try to understand what they mean, but it’s rough. It’s full of little gems like this:

"A group of undertakings should cover a controlling undertaking and its controlled undertakings, whereby the controlling undertaking should be the undertaking which can exert a dominant influence over the other undertakings." —GDPR Recital 37

…You can’t make this stuff up!

So, I thought it would be helpful to break it down, at least from a software perspective, and see what the key issues are that you should understand. If you see that it’s going to affect you, you’ll definitely want to take a deeper dive. GDPR will end up touching many parts of your organization, and you’ll want to get it right.

GDPR requires organizations to make sure that user data is well protected, not misused, users are given informed consent, and non-compliance is enforced by big financial penalties. For more information, read on.

What Is GDPR?

GDPR is all about protecting the data of people in the EU. This means protecting access to the data, not storing data you don’t need, encrypting personal data, and anonymizing data when possible.

In other words, all the steps you can take to limit the possibility of a data breach and the impact when a breach does occur. In addition, privacy includes unauthorized uses of data, like tracking users without their consent and any other use of data without explicit consent.

GDPR "was designed to harmonize data privacy laws across Europe, to protect and empower people in the EU with respect to their data privacy, and to reshape the way organizations across the region approach data privacy.

GDPR considers the general EU "right to be forgotten," which, in this context, means that if someone wants their data removed from your system, you have one month to act. It’s extendable by two more months for complex requests, as long as you tell them inside the first month.

Additionally, there are strict reporting requirements. You can’t have a breach and hide it, like what has happened several times recently in the U.S.

What Are the Penalties for Noncompliance With GDPR?

Fines. Fines are what happens. The amount of the fine can be based on the revenue of the parent organization, so it may be bigger than you think. Fines vary based on which provisions were violated, in two tiers that top out at 10 million EUR or 2% of global annual turnover and 20 million EUR or 4%, whichever is higher (more on that below). Make sure that you can prove compliance.

"In order to demonstrate compliance with this Regulation, the controller or processor should maintain records of processing activities under its responsibility." —GDPR Recital 82 (the binding requirement is Article 30)

CCPA vs. GDPR

The California Consumer Privacy Act (CCPA) has similar goals to GDPR but differs mainly in scope, since CCPA is specific to California and GDPR to the EU. California is also no longer the only U.S. state with this kind of law. As of 2026, twenty states have comprehensive consumer privacy laws in force, and there is still no comprehensive federal privacy law. In summary, the key differences between CCPA and GDPR are:

• Jurisdiction. Both laws deal with privacy, but GDPR covers people in the EU and EEA, while CCPA covers California residents.
• Scope. GDPR applies solely to individuals, whereas the CCPA makes the distinction of applying to consumers and households.
• Application. GDPR has a much broader scope and extends to all entities that might use personal data. The CCPA, on the other hand, applies only to for-profit businesses that handle the personal information of California "consumers" and "households" and meet a threshold, such as annual gross revenue above $26,625,000 (the current inflation-adjusted figure) or buying, selling, or sharing the personal information of 100,000 or more California consumers or households.
• Specifics of consent. The CCPA was originally light on details such as cookies and consent. That gap has narrowed, because California’s regulations now define valid consent, prohibit dark patterns, and require businesses to honor the Global Privacy Control opt-out signal. CCPA still has no equivalent of GDPR’s rules on international data transfers.
• Opt-in vs. opt-out. A basic principle of GDPR is that individuals are given the option to opt in to allow use of their data, so the default is always privacy. CCPA relies on opt-out for consumers, where the default is that their data can be used until they take the action to opt out on their own. If you do opt in, it complies with both sets of regulations.
• Scale of enforcement penalties. The CCPA penalties are relatively small compared to the GDPR enforcement cases that have been prosecuted. The largest GDPR fine to date, against Meta, was €1.2 billion.

California has also added obligations since this article was first written. Regulations that took effect in January 2026 require businesses that use automated decision-making technology for significant decisions, such as lending, housing, education, employment, and healthcare, to give consumers pre-use notice, an opt-out, and access, with compliance required by January 2027.

The same regulations require risk assessments for high-risk processing, with the first submissions to the state due in April 2028, and annual independent cybersecurity audits, phased in by revenue beginning in April 2028

CCPA Enforcement Examples

The State of California Department of Justice publishes their CCPA Enforcement Case Examples, and both the Attorney General and the California Privacy Protection Agency now announce enforcement actions by company name. The penalties are growing, and many of the violations are things engineering teams control. Recent examples include:

• General Motors agreed in 2026 to pay $12.75 million, the largest CCPA penalty to date, over selling drivers’ location and driving behavior data collected through OnStar.
• Disney agreed in 2026 to pay $2.75 million over opt-out requests, including Global Privacy Control signals, that were not honored across all of a consumer’s Disney services.
• Tractor Supply paid $1.35 million in 2025, then a record for the California Privacy Protection Agency, in part for failing to process consumer opt-out requests.
• Honda paid $632,500 to the California Privacy Protection Agency in 2025 for requiring more personal information than necessary to process privacy requests and for a cookie tool that made opting out harder than opting in.

The CCPA currently provides penalties of up to $2,663 for each violation and $7,988 for each intentional violation or violation involving the personal information of a consumer under 16. However, the threat of consumer lawsuits poses a larger risk.

GDPR Enforcement Examples

GDPR enforcement is usually on a much larger scope than CCPA and the examples show the large difference in the scale and scope of the two regulations:

• Meta fined €1.2 billion ($1.3 billion) in 2023 for transferring data collected from Facebook users in the EU to the U.S., violating GDPR international transfer guidelines.
• Amazon was fined €746 million in 2021 over advertising consent, but Luxembourg’s Administrative Court of Appeal annulled that fine in March 2026 on procedural grounds and sent the case back to the regulator. The infringement finding stands; the penalty does not.
• WhatsApp fined €225 million ($247 million) in 2021 for unclear privacy policies and a lack of transparency in how it was using user data.

GDPR noncompliance can result in serious and severe penalties, and the framework has two tiers.

Article 83(4) tops out at 10 million EUR or 2% of global annual turnover, whichever is higher, and covers controller and processor obligations, including data protection by design, records of processing, and breach notification.

Article 83(5) tops out at 20 million EUR or 4% and covers the core principles, the legal bases for processing, consent, data subject rights, and international transfers.

Who Needs to Follow GDPR Regulations?

Of course, companies in the EU need to follow GDPR, but as it turns out, even if you’re located elsewhere, if you have customers in the EU, then you’re also subject to GDPR.

If you’re not storing any personal information, this will be easy, but anyone with EU personal data must follow the guidelines. The same is true if you have employees in the EU.

It sometimes gets a bit tricky if you’re sharing user data or getting user data from elsewhere. If someone exercises the right to be forgotten, you must chase down all those shares and erase the data everywhere. So even if you’re getting data from someone else who is handing over EU personal data, you can be subject to the guidelines.

Overview of GDPR Regulations

With the aim to enhance individuals’ control and rights over their personal data, the regulation applies to any of the following based in the EU and EEA (European Economic Area, which includes Iceland, Liechtenstein and Norway):

• Any organization
• The data controller that collects data from individuals
• The processor, which is an organization that processes data on behalf of a data controller
• The data subject, which is a person

A key aspect of the GDPR is that it applies to organizations based outside the EU if they collect or process personal data of anyone in the EU/EEA, whether or not they are a citizen.

As we’ve seen, the penalties are large and are often levied against technology companies outside the EU. Unfortunately, the scope of GDPR is large and is considered "light of specifics" by privacy experts. Compliance is especially daunting for small and medium-sized businesses.

Key Concepts and Definitions

The key definitions of GDPR relate to the individual and the organizations that collect, process, store, and transfer their personal data.

• Personal data. Any information pertaining to a specific person who can be identified, either directly or indirectly, is considered personal data. For example, email addresses and names are personal as is geographic coordinates, gender, ethnicity, biometric information, political opinions, web cookies, and religious convictions. The definition can also apply to anonymized data if it is reasonably easy to identify a person from it.
• Data processing. Any action taken on data, whether automated or manual, is referred to as data processing. This includes activities on data for gathering, logging, organizing, structuring, storing, using, and erasing.
• Data subject. The individual whose data is processed is the data subject. In most cases, these are users of your product or visitors to your website.
• Data processor. Any organization or entity that processes data on behalf of the data controller.

Scope and Application of GDPR

The GDPR is designed to protect the data of people in the EU and EEA. It applies to any organization handling such data, regardless of whether they are based in the EU or not. This is known as "extra-territorial effect."

According to Recital 3 of the GDPR:

• The regulation applies to the processing of personal data by an establishment in the EU, irrespective of where the processing occurs.
• It also applies to the processing of personal data of data subjects in the EU by a controller or processor not established in the EU, if the processing activities are related to offering goods or services to such data subjects in the EU or monitoring their behavior within the EU.
• The regulation applies to the processing of personal data by a controller not established in the EU, but in a place where member state law applies by virtue of public international law.

The GDPR applies to non-EU organizations that offer goods or services to people in the EU or monitor their online behavior. Regulators look for clues to determine whether the organization set out to offer goods and services to people in the EU.

For example, If an organization uses web tools to track cookies or IP addresses of people who visit their website from EU countries, then it falls under the scope of the GDPR.

There are narrow exceptions, notably for "purely personal or household activity." One point worth correcting, because it is widely misunderstood: organizations with fewer than 250 employees get a limited exemption from record-keeping requirements under Article 30(5), and even that falls away if the processing risks people’s rights, is not occasional, involves special category data, or involves criminal conviction data. For most software companies, at least one of those applies. It is not a general exemption. Small companies are covered.

Consent Under GDPR

Consent and Transparency

GDPR states that users must consent to having any data about them collected and that this consent is based on "a clear affirmative act." Clear and affirmative means that the user must perform an action to opt in rather than the common "you’re in unless you opt out" methodology.

"For consent to be informed, the data subject should be aware at least of the identity of the controller and the purposes of the processing for which the personal data are intended." —GDPR Recital 42

On the web, a good example is a sign-up form that has a notice that data is going to be collected, what data it is, how it will be used, how to later opt-out (or be forgotten), and then the user must do something to agree, like click a checkbox. The days of pre-checked boxes no longer apply – the GDPR specifically forbids such currently typical methods:

"Silence, pre-ticked boxes or inactivity should not therefore constitute consent." —GDPR Recital 32

The use of the data must have some purpose related to why the data is being gathered and must be explained to the user:

"It should be transparent to natural persons that personal data concerning them are collected, used, consulted or otherwise processed and to what extent the personal data are or will be processed." —GDPR Recital 39

Controlling Personal Data

People in the EU are granted substantial control over their personal data, including access, transfer, correction, and the right to be forgotten, including:

"mechanisms to request and, where applicable, obtain, free of charge, in particular, access to and rectification or erasure of personal data and the exercise of the right to object." —GDPR Recital 59

The right to access one’s data is based on GDPR Recital 63 (the binding right is Article 15):

"A data subject should have the right of access to personal data,"

While the right to have corrections to the data made is in GDPR Recital 65 (the binding right is Article 16):

"A data subject should have the right to have personal data concerning him or her rectified."

Think about this the next time you’re fighting a credit reporting agency, and you’ll wish it applied to your own data.

GDPR further ensures that there are no vendor locks on user data. The right to transfer data is also enumerated:

"the data subject should also be allowed to receive personal data concerning him or her which he or she has provided to a controller in a structured, commonly used, machine-readable and interoperable format, and to transmit it to another controller." —GDPR Recital 68

This means that you can get your data from a vendor in a reasonable digital form so that you can move it to a different provider.

The right to be forgotten extends to organizations with whom data has been shared:

"the right to erasure should also be extended in such a way that a controller who has made the personal data public should be obliged to inform the controllers which are processing such personal data to erase any links to, or copies or replications of those personal data." —GDPR Recital 66

In other words, the erasure must cascade.

If you get data about a person from another organization and are going to use it and/or store it, you have to notify that person – so that they can give informed consent (see GDPR Recitals 60 and 61). This is also true if you decide to use the data in a way that was not included in the original consent.

"Where the controller intends to process the personal data for a purpose other than that for which they were collected, the controller should provide the data subject prior to that further processing with information on that other purpose and other necessary information." —GDPR Recital 61

And watch out for fully automated algorithms like loan applications:

"The data subject should have the right not to be subject to a decision, which may include a measure, evaluating personal aspects relating to him or her which is based solely on automated processing and which produces legal effects concerning him or her or similarly significantly affects him or her, such as automatic refusal of an online credit application or e-recruiting practices without any human intervention." —GDPR Recital 71

If you’re using fully automated algorithms to make decisions this one can trip you up.

Data Protection — Manage and Defend

The key term here is personal data, which is broader than the U.S. concept of personally identifiable information. It covers anything that identifies someone directly or indirectly, including cookie IDs and IP addresses. If you are doing any kind of web analytics, you are handling personal data and need to make sure what you are doing complies with GDPR.

One of the key aspects of handling personal data under GDPR is data protection by design and by default, which is a binding obligation under Article 25. The regulation states:

"the controller should adopt internal policies and implement measures which meet in particular the principles of data protection by design and data protection by default." —GDPR Recital 78

Data protection by design methodology is a way of saying that you cannot simply test security and data protection into your application. Rather than build some code and try to red-team test it, you need to design the application to be secure in the first place, so things like encryption are the default to be turned off only on an approved exception.

Secure by design means getting serious about static code analysis as well, with a big emphasis on software engineering standards and "preventative" static analysis rules.

And if you’re collecting health-related data, be extra careful. Health data is special category data under Article 9, which means processing is prohibited unless you have a lawful basis under Article 6 and a separate condition under Article 9(2), such as explicit consent.

Recital 53 lays out the health-related purposes that can justify it, including scientific research grounded in Union or member state law, with Article 89 setting the safeguards. Recital 54 covers processing for public health reasons without consent, and it ends with a line worth reading twice, which is that data processed for public health reasons should not then be processed for other purposes by third parties such as employers, insurers or banks.

Data retention is another important issue when collecting and storing personal data. The main principle here is to retain data no longer than necessary:

"…the right to have his or her personal data erased and no longer processed where the personal data are no longer necessary" —GDPR Recital 65

In other words, data that you only need for transitory purposes, like completing a transaction, should only exist for the amount of time required. After that, you should purge the data, rather than store it for convenience or future analytics.

It’s important to show that you need the data being collected as well:

"a data subject can reasonably expect at the time and in the context of the collection of the personal data that processing for that purpose may take place" —GDPR Recital 47

And later on, you can’t just use the data for something else, unless that something else is related to the original use of the data and/or processing (analyzing) the data.

"The processing of personal data for purposes other than those for which the personal data were initially collected should be allowed only where the processing is compatible with the purposes for which the personal data were initially collected." —GDPR Recital 50

The GDPR Principles

The key data protection principles of the GDPR are listed below.

Lawfulness, Fairness, and Transparency

Processing must be lawful, fair, and transparent to the data subject.

Purpose Limitation

You must process data for the legitimate purposes specified explicitly to the data subject when you collected it.

Data Minimization

You should collect and process only as much data as absolutely necessary for the purposes specified.

Accuracy

You must keep personal data accurate and up to date.

Storage Limitation

You may only store personally identifying data for as long as necessary for the specified purpose.

Integrity and Confidentiality

Processing must be done in such a way as to ensure appropriate security, integrity, and confidentiality (e.g. by using encryption).

Accountability

The data controller is responsible for being able to demonstrate GDPR compliance with all of these principles.

Key Rights Under GDPR

An important aspect of GDPR is outlining and enforcing an individuals’ rights in relation to their use of websites, software, and products that might collect personal information.

The Right to be Informed

Organizations must clearly inform and document how and what personal data is used.

The Right to Rectification

Individuals have the right to correct inaccurate personal information.

The Right of Access

All personal data is accessible by individuals and can be requested without charge.

The Right to be Forgotten (Erasure)

Individuals can require you to delete their data when one of the Article 17 grounds applies, such as the data no longer being necessary for the purpose you collected it for or consent being withdrawn with no other basis to fall back on. It is not absolute. Article 17(3) lets you keep what you need to meet a legal obligation, to establish or defend legal claims, or for archiving and research in the public interest. When erasure does apply, it cascades to everyone you shared the data with.

The Right to Restrict the Processing of Your Data

Individuals can request that the processing of their data be restricted or suppression of their data.

The Right to Data Portability

Individuals can get the data they provided to you, where you process it by automated means on the basis of consent or a contract, in a structured, commonly used, machine-readable format, and have it sent to another provider. It does not cover everything you hold about them, and in particular, not the profiles or scores you derived yourself.

The Right to Object

Individuals can object to processing based on legitimate interests or public task, in which case you must stop unless you can demonstrate compelling legitimate grounds that override their interests. For direct marketing the right is absolute: object once and you must stop.

Rights Regarding Automated Profiling and Decision Making

This restricts how much an individual’s data can be used by automated processes, including AI.

Data Breaches and GDPR

What Constitutes a Data Breach?

The GDPR defines a data breach as a "breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored or otherwise processed". This definition applies to both accidental and deliberate causes.

In simpler terms, a data breach under GDPR occurs when there is a security incident that compromises the integrity or confidentiality of personal data. This could be due to accidental or unlawful actions leading to the destruction, loss, alteration, unauthorized disclosure of, or access to, personal data.

Procedural Response to a Data Breach

The GDPR has specific guidelines regarding data breaches. According to Recitals 33 and 34 of the GDPR:

An organization must report a data breach to a data protection authority (DPA), also known as a supervisory authority (SA), if there is an incident leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data that leads to a potential risk to people’s rights and freedoms.

If the breach could result in loss of control over their personal data, discrimination, identity theft or fraud, financial loss, unauthorized reversal of pseudonymization, damage to reputation, loss of confidentiality of personal data protected by professional secrecy, or any other significant economic or social disadvantage to the natural person concerned, the company is required to report the incident.

Mandatory Breach Reporting

The data breach notification requirements are mandatory and time-sensitive under GDPR. Organizations must report personal data breaches that risk people’s rights to the relevant supervisory authority within 72 hours of becoming aware of the breach.

Article 33(4) allows the information to be provided in phases when the picture is still incomplete. Where the breach poses a high risk to the people affected, you have to tell them as well.

Failure to notify a data protection authority of a breach can result in a fine of up to €10 million ($11.3 million) or 2 percent of a company’s global turnover, whichever is higher.

GDPR Compliance

Compliance with the GDPR means that an organization meets the requirements for properly handling personal data as defined in the law.

Given its legal status and severe penalties, compliance requires serious attention for organizations that collect, process, and store personal information, which includes most commercial websites but also encompasses applications and physical products.

Steps Towards GDPR Compliance

The key aspects that organizations need to embrace include the following:

• Where you rely on consent, it is opt-in, not opt-out. Consent is only one of the six legal bases in Article 6, so pick the right basis for each processing activity first, then build the mechanics. Privacy by default, every time.
• Always ensuring that website visitors, applications, and product users are notified of the data collected.
• Obtaining explicit consent from users for that information-gathering.
• Notifying your supervisory authority within 72 hours when a breach risks people’s rights, and notifying the people affected when the risk to them is high.
• Conducting a data protection impact assessment (Article 35) where processing is likely to be high risk, including its data security.
• Appointing a data protection officer where Article 37 requires one.
• Being able to demonstrate that there are policies and procedures in place.
• Regular compliance reviews of policies and procedures ensure compliance.

Important Tips for Staying GDPR Compliant

GDPR has a large scope. There are some key principles that software developers can follow today to reduce the overhead and workload needed for compliance.

Here are some initial steps that software developers can take to ensure GDPR compliance.

• Training. It’s critical everyone in an organization understand what constitutes personal data. Personal data is any information that relates to an identified or identifiable living individual. Understand the key principles of the GDPR and how they apply to your application or product.
• Privacy by default. The user should have settings with maximum privacy when starting to work with your software. The protection level should remain unchanged if the user does not make any changes in the settings.
• Privacy built in. Introduce privacy into your software from the very beginning, even before the first piece of personal information gets into the system.
• Rationalize private data. The best course for the privacy-conscious future is to collect only the bare minimum of personal data. If you don’t need it, don’t collect it.
• Encrypt all personal data. Encryption reduces the possibility of exposing private data in transfer or storage. If possible, use end-to-end encryption to mitigate the damage of a possible data breach.
• Pseudonymization. Keep the info that allows identifying the person and the data about this person separately. Obfuscate personal details sufficiently so that their identity can’t be reconstructed.
• Understand and plan for user’s rights. Be aware of new rights for data subjects, such as the right "to be forgotten" and the right of portability.
• Report breaches on the clock. You have 72 hours from becoming aware of a breach to notify your supervisory authority for any breach that risks people’s rights. That is not 72 hours from deciding it is serious and not 72 hours from finishing the investigation. If you do not have the full picture yet, report what you have, because Article 33(4) lets you provide the rest in phases. Notify the people affected as well when the risk to them is high. Penalties for not doing so are very punitive.
• Know whether you need a DPO. Article 37 requires one if you are a public authority, if your core activities involve large-scale regular and systematic monitoring, or if they involve large-scale processing of special category or criminal conviction data. Size alone does not trigger it.
• Clear and concise compliance documentation. Clearly document all the ways that user data is collected and what it’s used for. Tell the user how the data is stored and who has access to it, including third parties. Document compliance audits and reviews.

So, What Do You Do Next?

I’d love to tell you that there is a silver bullet tool or set of tools that you can use to simply comply with GDPR, but that’s just not the case. However, Parasoft can do a lot to help you out.

First, you can use our static code analysis engines for Java, C/C++, and .NET with good security and privacy configurations to make sure that your code is as secure as possible. You can even configure them to enforce strict coding policies, like encryption by default.

Second, you can use service virtualization to drive complete end-to-end testing, even in an early phase on the developer desktop. Being able to fully test what happens to the data without having to have expensive test labs available makes it much easier to comply, and by allowing developers to perform deeper testing, you’ll find problems earlier when they’re easier and cheaper to fix.

Summary

It’s a little bit scary, and in some sense, it should be, given the potential financial penalties. But overall, it’s not that horrible unless your business model is based on tracking users and selling their data.

If you have a typical business model and have customer data and sales, you will find compliance isn’t a huge headache and will have the added benefit of making your overall system more secure in a world of increasing data breach frequency.

Set the right policies in place, employ thorough, comprehensive testing, and ensure your data privacy with strong static code analysis.