GDPR Compliance for IT and SaaS Companies: Requirements Explained

GDPR compliance is a legal obligation, not a badge. The General Data Protection Regulation applies to any organisation that processes personal data within its scope, including software companies, SaaS providers and IT service firms based outside Europe. For many Indian and US IT companies, the GDPR arrives through a client: an EU customer asks you to sign a data processing agreement, answer a privacy questionnaire, and prove you can delete their users' data on request.

This guide explains when the GDPR applies to you, the difference between a controller and a processor, the principles and legal bases, the rights you must support in your software, security and breach duties, transfers out of the EU, fines, and the practical engineering work behind compliance. It reflects the regulation as in force at the review date; amendments proposed by the European Commission in its Digital Omnibus package were still being negotiated, and we will update this guide when they are adopted.

What is the GDPR?

The GDPR is Regulation (EU) 2016/679 of the European Parliament and of the Council on the protection of natural persons with regard to the processing of personal data and on the free movement of such data. As a regulation, it applies directly in every EU member state without needing national legislation, and it also applies in the European Economic Area countries Iceland, Liechtenstein and Norway. Member states may add rules in areas the GDPR leaves open, such as the age of consent for online services (Article 8) and employment data (Article 88), so national law still matters at the edges.

Three definitions in Article 4 drive everything else:

• Personal data: any information relating to an identified or identifiable natural person. Names and emails, but also IP addresses, device identifiers, location data and pseudonymised records that can be linked back to a person.
• Processing: any operation on personal data, from collection and storage to consultation, transfer and erasure. Hosting a database counts.
• Controller and processor: the controller decides the purposes and means of processing; the processor processes personal data on the controller's behalf.

History and why the GDPR was introduced

The GDPR replaced Data Protection Directive 95/46/EC, which dated from the early days of the commercial internet. Because a directive must be transposed into national law, the old regime produced different rules in each country and weak enforcement. The GDPR was adopted on 27 April 2016 and has applied since 25 May 2018.

Its goals were to give people control over their personal data in a world of online services, cloud computing and data-driven business models; to create one set of rules across the single market; and to make the rules enforceable, with large fines, accountability duties and cooperation between regulators through the European Data Protection Board (EDPB). Data protection is also a fundamental right under Article 8 of the EU Charter of Fundamental Rights, which shapes how courts read the regulation.

In November 2025 the European Commission proposed targeted amendments to the GDPR, alongside changes to other digital laws, in its Digital Omnibus package. At the date of our last review the Council had agreed its negotiating position and negotiations with the European Parliament were continuing. Until amendments are adopted and published, the existing text applies.

Who must comply with the GDPR?

Article 3 sets the territorial scope. The GDPR applies to:

1. Processing in the context of the activities of an establishment of a controller or processor in the EU, whether or not the processing takes place in the EU.
2. Controllers or processors not established in the EU, where the processing relates to offering goods or services to people in the EU (paid or free), or to monitoring their behaviour in the EU, such as tracking and profiling.

The EDPB's Guidelines 3/2018 explain the "targeting" test: signs include an EU language or currency, EU delivery, EU domain names or marketing aimed at EU customers. A website that is merely accessible from the EU is not enough on its own.

What it means for IT companies outside the EU

• A SaaS company that sells to EU users is a controller for its own customer data (accounts, billing, marketing) and usually a processor for the data its customers upload. It is directly subject to the GDPR and, if it has no EU establishment, must appoint an EU representative under Article 27 unless an exemption applies.
• An offshore development or IT services firm working for an EU client is typically a processor (or sub-processor) for client data. Even if the GDPR does not apply to it directly under Article 3, the client must bind it by contract to GDPR-level duties under Article 28, and transfer rules apply to the data it receives.
• Industries do not change applicability. Health, children's and biometric data are "special categories" (Article 9) or carry extra rules, which raises the bar for health-tech, ed-tech and identity products.

Key requirements: principles and lawful bases

The seven principles (Article 5)

• Lawfulness, fairness and transparency.
• Purpose limitation: collected for specified, explicit and legitimate purposes, not used in incompatible ways.
• Data minimisation: adequate, relevant and limited to what is necessary.
• Accuracy: kept accurate and up to date.
• Storage limitation: kept in identifiable form no longer than necessary.
• Integrity and confidentiality: appropriate security.
• Accountability: the controller is responsible for, and must be able to demonstrate, compliance.

The six lawful bases (Article 6)

Every processing activity needs one: consent, contract, legal obligation, vital interests, public task or legitimate interests. Consent must be freely given, specific, informed, unambiguous and as easy to withdraw as to give (Article 7), so pre-ticked boxes and consent bundled into terms of service do not work. For most B2B SaaS processing, "contract" or "legitimate interests" is the right basis; consent is often the wrong choice because it can be withdrawn at any time.

Special categories (Article 9)

Health, genetic, biometric data used to identify a person, racial or ethnic origin, political opinions, religious beliefs, trade union membership and data about sex life or sexual orientation are prohibited from processing unless one of the conditions in Article 9(2) applies, such as explicit consent.

Rights you must support in your software

Articles 12 to 22 give people rights that controllers must honour, normally within one month of the request, extendable by two further months for complex or numerous requests (Article 12(3)). Processors must help controllers respond (Article 28(3)(e)). In engineering terms, each right is a feature:

Right	Article	What the product needs
Information	13, 14	Clear privacy notices at collection points
Access	15	A way to find and export all data about a person, across services
Rectification	16	Editable profile data and admin correction tools
Erasure	17	Deletion that reaches databases, search indexes, caches, files, logs on a schedule, and processors
Restriction	18	A flag that stops processing other than storage
Data portability	20	Export in a structured, commonly used, machine-readable format such as JSON or CSV
Objection	21	Opt-outs, including an absolute right to object to direct marketing
Automated decisions	22	Human review for decisions based solely on automated processing with legal or similar effects

Backups are the usual hard case. Regulators generally accept that data in backups is deleted when the backup expires, provided it is not restored into live use in the meantime and the retention is documented. Write that down in your retention policy.

Controller and processor obligations

Accountability and privacy by design

Controllers must implement appropriate measures and be able to show them (Article 24), apply data protection by design and by default (Article 25), and keep records of processing activities (Article 30). The record-keeping exemption for organisations with fewer than 250 employees is narrow and does not apply to regular processing, so most software companies keep records anyway.

Processor contracts (Article 28)

A controller may only use processors that provide sufficient guarantees, and the relationship must be governed by a contract that includes the items in Article 28(3): processing only on documented instructions, confidentiality of staff, security under Article 32, rules on sub-processors, help with data subject rights, help with security and breach duties, deletion or return of data at the end, and audit rights. A processor may not engage a sub-processor without the controller's prior authorisation and must flow down the same obligations. For SaaS companies this means a data processing agreement (DPA) and a published, maintained list of sub-processors.

Data protection impact assessments (Article 35)

Required before processing likely to result in a high risk, such as large-scale processing of special categories, systematic monitoring of public areas, or systematic and extensive profiling. Supervisory authorities publish lists of processing that requires one.

Data protection officer (Articles 37 to 39)

Mandatory for public bodies and for organisations whose core activities involve large-scale regular and systematic monitoring, or large-scale processing of special categories. Many software companies are not required to appoint one but name a privacy lead.

Security and breach notification

Article 32 requires controllers and processors to implement appropriate technical and organisational measures, taking into account the state of the art, costs, and the risks. It names examples: pseudonymisation and encryption, ongoing confidentiality, integrity, availability and resilience of systems, the ability to restore data in a timely manner, and regular testing of effectiveness. It does not prescribe specific controls, which is why many organisations use ISO/IEC 27001 or a similar framework to structure their measures.

A personal data breach must be notified by the controller to the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to people (Article 33). A processor must notify the controller without undue delay. Where the breach is likely to result in a high risk, the people affected must also be told (Article 34). Every breach must be documented, including those not notified.

International transfers outside the EU

Chapter V (Articles 44 to 49) restricts transfers of personal data to countries outside the EEA. A transfer is allowed when:

• The Commission has adopted an adequacy decision for the country (Article 45). Adequacy decisions exist for, among others, the United Kingdom, Japan, South Korea, Switzerland and, for organisations certified under the EU-U.S. Data Privacy Framework, the United States. There is no adequacy decision for India at the date of review.
• Appropriate safeguards are in place (Article 46), most commonly the Commission's standard contractual clauses adopted in 2021, or binding corporate rules for groups (Article 47). After the Court of Justice's Schrems II judgment, exporters must also assess whether the law and practice of the destination country allow the clauses to be honoured, and add supplementary measures where needed.
• A specific derogation applies (Article 49), such as explicit consent for an occasional transfer. Derogations are not meant for routine transfers.

Remote access counts. If an engineer in India can read EU production data, that is a transfer, and the contract chain needs standard contractual clauses with a transfer impact assessment.

How to implement GDPR compliance step by step

1. Decide whether and how the GDPR applies: establishment, targeting, monitoring, and your role (controller, processor or both) for each data set.
2. Map your data: what personal data you collect, where it is stored, who can access it, which vendors receive it, and where it goes geographically. This becomes the Article 30 record.
3. Assign a lawful basis to each purpose, and fix consent flows that do not meet Article 7.
4. Write or update privacy notices that meet Articles 13 and 14.
5. Sign the contracts: DPAs with customers (as processor) and with your own vendors (as controller), sub-processor list, and standard contractual clauses where data leaves the EEA.
6. Build the rights features: access and export, deletion across systems, rectification, objection and marketing opt-out, with a request log and identity checks.
7. Set retention periods and implement automated deletion or anonymisation jobs.
8. Secure the data under Article 32: access control, encryption, logging, vulnerability management, backups and restore tests.
9. Prepare for breaches: detection, triage, a 72-hour notification playbook, and a breach register.
10. Run DPIAs for high-risk processing, including new AI features that profile users.
11. Appoint an EU representative if you are outside the EU and Article 27 requires it, and a DPO if Article 37 requires it.
12. Train staff and review regularly. Privacy by design means adding a privacy check to your product and change process.

Documentation and policies required

• Records of processing activities (Article 30), for controllers and processors.
• Privacy notices (Articles 13 and 14) and cookie notices where the ePrivacy rules apply.
• Records of consent where consent is the basis (Article 7(1)).
• Legitimate interest assessments where that basis is used.
• Data processing agreements (Article 28) and the sub-processor list.
• Transfer documentation: standard contractual clauses and transfer impact assessments.
• DPIAs (Article 35).
• Information security policy and the measures taken under Article 32.
• Breach register and notification records (Article 33(5)).
• Data subject request log and procedure.
• Retention schedule and data protection policy.

Audits, assessments and certification

There is no mandatory GDPR audit and no official "GDPR certified" status. Supervisory authorities can investigate, audit and request information (Article 58). Articles 42 and 43 allow certification mechanisms approved by authorities or the EDPB, but certification does not reduce the controller's responsibility, and only a small number of schemes have been approved. Claims of "GDPR certified" software should be read with care.

What customers do expect is evidence: answers to privacy questionnaires, your DPA and sub-processor list, a security attestation such as SOC 2 or ISO/IEC 27001, and sometimes a privacy management certification such as ISO/IEC 27701. Processors must also allow and contribute to audits by controllers (Article 28(3)(h)).

Timeline and cost considerations

The GDPR has applied since 2018, so there is no transition period left: if it applies to you, it applies now. How long it takes to get your house in order depends on the number of systems holding personal data, how scattered the data is, whether rights requests can be handled by software or need manual searches, and how many vendors and transfers you have.

Cost factors include legal advice on roles, bases and contracts; engineering work on rights, deletion and retention; security measures; a DPO or EU representative where required; privacy tooling (consent management, data discovery, request handling); and ongoing staff time. The biggest avoidable cost is retrofitting deletion and export into a product whose data model was never designed for it.

Benefits and consequences of non-compliance

Compliance lets you sell to EU customers, passes procurement privacy reviews, and reduces the volume and impact of breaches because you hold less data for less time. It also prepares you for other privacy laws modelled on similar principles, such as India's DPDP Act, Brazil's LGPD and the UK GDPR.

Article 83 sets two tiers of administrative fines: up to 10 million euros or 2 percent of total worldwide annual turnover of the preceding financial year, whichever is higher, for infringements such as processor and security obligations; and up to 20 million euros or 4 percent, whichever is higher, for infringements of the principles, lawful bases, rights and transfer rules. Authorities can also order processing to stop, require deletion, or suspend data flows (Article 58(2)). People can claim compensation for material or non-material damage (Article 82), and processors are liable when they breach their own obligations or act outside the controller's instructions.

Common mistakes and challenges for IT companies

• Assuming the GDPR does not apply because the company is outside the EU. Check Article 3 and your client contracts.
• Using consent for everything. It is often the wrong basis, and withdrawn consent stops processing you depend on.
• Deletion that stops at the main database. Search indexes, analytics tools, file storage, email platforms, logs and processors also hold personal data.
• No sub-processor control. Adding a new analytics or AI vendor without notifying customers breaches most DPAs.
• Logging personal data by default. Request bodies and full payloads in logs create hidden copies that outlive retention policies.
• Sending EU data to AI or support tools without a transfer mechanism or a DPA.
• Treating a security certification as privacy compliance. ISO/IEC 27001 or SOC 2 covers Article 32, not the rest of the regulation.
• Remote access from outside the EU without transfer safeguards. Support and engineering access is a transfer.

Best practices, tools and technologies

• Design data models with a clear owner for each personal data field, a retention period and a deletion path.
• Pseudonymise or tokenise identifiers in analytics and logs; keep the mapping separately and access-controlled.
• Encrypt personal data in transit and at rest; consider field-level encryption for sensitive fields.
• Build a data subject request workflow: verified request, automated discovery across systems, export, deletion, and a log of what was done.
• Use a consent management platform for cookies and marketing consent, and store consent records server-side.
• Offer EU data residency where customers need it, and document where support staff access data from.
• Run privacy reviews in the same pipeline as security reviews for new features.

These are the features we add to web applications and integrations when clients prepare for EU customers.

How the GDPR relates to other frameworks

Framework	Relationship
UK GDPR	The UK kept a domestic version after Brexit, now amended by UK legislation. Similar but separate.
ePrivacy Directive	Cookies, tracking and electronic marketing rules that sit alongside the GDPR.
ISO/IEC 27701	Certifiable privacy management system. Useful structure and evidence; not proof of legal compliance.
ISO/IEC 27001	Helps meet Article 32 security duties.
DPDP Act (India)	Similar concepts (fiduciary, processor, consent, rights, breach reporting) with important differences in bases and transfers.
CCPA/CPRA	California law with an opt-out model and service provider contracts, different from the GDPR's lawful-basis model.
EU AI Act	Applies alongside the GDPR to AI systems that process personal data.

Real-world enforcement examples

Public enforcement shows where regulators focus. In May 2023, the Irish Data Protection Commission fined Meta Platforms Ireland 1.2 billion euros and ordered it to suspend transfers of Facebook user data to the United States, following an EDPB binding decision on the use of standard contractual clauses after Schrems II. In 2021, Luxembourg's data protection authority fined Amazon Europe Core 746 million euros over its processing for targeted advertising. Both were appealed, but they show that transfers and lawful bases for advertising and profiling are high-risk areas.

For software companies, smaller decisions published by national authorities are often more instructive: fines for failing to answer access requests, for keeping data longer than necessary, for weak security leading to breaches, and for missing processor contracts. National authorities publish these on their websites, and the EDPB publishes summaries.

Next steps

1. Confirm whether and how the GDPR applies, and your role for each data set.
2. Build or update your data map and Article 30 records.
3. Put DPAs, a sub-processor list and standard contractual clauses in place.
4. Close the product gaps: export, deletion, retention, consent and audit logs.
5. Prepare a 72-hour breach playbook and test it.
6. Get legal advice on anything uncertain; this guide is not a substitute for it.

For product work, see our SaaS development services or contact us.

Frequently asked questions

Does the GDPR apply to companies outside the EU?

Yes, when they offer goods or services to people in the EU or monitor their behaviour there (Article 3(2)), and indirectly through contracts when they act as processors for EU clients.

What is the difference between a controller and a processor?

The controller decides why and how personal data is processed. The processor processes it on the controller's behalf and on its instructions. A SaaS company is often a processor for customer content and a controller for its own account and billing data.

Do we need a data protection officer?

Only if Article 37 applies: public authorities, or core activities involving large-scale regular and systematic monitoring or large-scale processing of special categories. Many software companies do not, but should still assign responsibility for privacy.

How fast must a data breach be reported?

The controller must notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk. Processors must tell the controller without undue delay.

How long do we have to answer a data subject request?

One month from receipt, extendable by two further months for complex or numerous requests, provided you tell the person within the first month (Article 12(3)).

Is there a GDPR certification?

Not in the sense of a general compliance certificate. Approved certification schemes can exist under Article 42, but they do not prove compliance. Be wary of products marketed as "GDPR certified".

Can we store EU personal data in India or the US?

Yes, with a valid transfer mechanism: the EU-U.S. Data Privacy Framework for certified US organisations, or standard contractual clauses with a transfer impact assessment, or another Chapter V mechanism. India has no adequacy decision at the date of review.

Do we need a DPA with our customers?

If you process personal data on their behalf, yes. Article 28 requires a contract with specific terms. Most SaaS companies publish a standard DPA.

Are IP addresses personal data?

They can be. The Court of Justice has held that dynamic IP addresses can be personal data where the holder has legal means to identify the person, and regulators generally treat them as personal data in analytics and logs.

What are the GDPR fines?

Up to 10 million euros or 2 percent of worldwide annual turnover for some infringements, and up to 20 million euros or 4 percent for others, whichever is higher in each case (Article 83).

Does the GDPR require encryption?

Not in every case. Article 32 lists encryption as an example of an appropriate measure. In practice, encryption in transit and at rest is expected for most systems, and encrypted data can reduce breach notification duties.

Is the GDPR changing?

The Commission proposed targeted amendments in its Digital Omnibus package in November 2025. At our last review they were still in negotiation between the Council and Parliament. This guide will be updated when changes are adopted.