GDPR Compliance Guide for IT and Software Companies

The GDPR reaches far beyond Europe. An Indian SaaS start-up with users in Germany, a US agency building an app for a French retailer and an offshore team that supports an Irish bank's CRM can all be inside its scope. This guide explains when the GDPR applies to an IT company, what controllers and processors must actually do, and how to build a compliance programme that survives a client's due diligence and a regulator's questions.

What is the GDPR?

The General Data Protection Regulation is the European Union's main data protection law. As a regulation, it applies directly in every EU member state without national transposition, and it also applies in the EEA countries (Iceland, Liechtenstein and Norway). Member states add national rules in areas the GDPR leaves open, such as employee data and the age of digital consent.

Full form and definition

GDPR stands for General Data Protection Regulation. It governs the processing of personal data, meaning any information relating to an identified or identifiable living person. That includes names and emails, but also IP addresses, device identifiers, cookie IDs, location data and pseudonymised records that can be linked back to a person.

Law, standard or certification?

The GDPR is a law. You cannot be "GDPR certified" in the way you are ISO 27001 certified. Articles 42 and 43 allow approved certification schemes, and Article 40 allows codes of conduct, but these are optional ways to demonstrate compliance, not a licence to process data. Be wary of any vendor that sells a "GDPR certificate" as proof of compliance.

History and background of the GDPR

The GDPR replaced the Data Protection Directive 95/46/EC, which dated from 1995 and had been implemented differently in each member state. The European Commission proposed a reform in January 2012; the regulation was adopted on 27 April 2016 and became applicable on 25 May 2018 after a two-year transition.

Why was the GDPR introduced?

Three problems drove the reform: inconsistent national laws that made compliance expensive for companies operating across Europe, weak enforcement with small fines, and a 1990s law that did not anticipate social media, cloud computing and large-scale tracking. The GDPR created one set of rules, a one-stop-shop for cross-border enforcement through a lead supervisory authority, much higher fines and explicit rules for non-EU companies.

What is changing?

In November 2025 the European Commission proposed targeted GDPR changes as part of its Digital Omnibus package, including clarifications to the definition of personal data and simplifications for some record-keeping and breach rules. As of October 2026 these are proposals still being negotiated by the European Parliament and the Council; the current text of the GDPR continues to apply in full. This guide will be updated when any amendment is adopted.

Main objectives and purpose

• Protect the fundamental right of individuals to the protection of their personal data.
• Give people control through transparency and enforceable rights.
• Make organisations accountable: they must not only comply but be able to demonstrate compliance (Article 5(2)).
• Allow the free movement of personal data within the EU under one rulebook.
• Ensure that protection follows the data when it is transferred outside the EEA.

Who needs to comply with the GDPR?

Article 3 sets two tests. The establishment test covers any processing in the context of an EU establishment, wherever the processing happens. The targeting test covers organisations without an EU establishment that offer goods or services to people in the EU (paid or free) or monitor their behaviour in the EU, for example through tracking and profiling.

Common IT company scenarios

Scenario	Does the GDPR apply?
Indian SaaS company selling subscriptions in euros to EU businesses, with EU user accounts	Yes, as a controller for account data (targeting test) and usually as a processor for customer data
US software agency building and hosting an app for a client in Spain	Yes, as a processor acting for an EU controller; the client's contract will impose Article 28 terms
Offshore support centre with access to an EU client's CRM	Yes, as a processor or sub-processor; transfer safeguards are needed
Website that is reachable from the EU but targets only Indian customers, in rupees, with no EU marketing or tracking	Usually no; mere accessibility is not enough, but analytics that profile EU visitors can change this

Controllers and processors

A controller decides why and how personal data is processed. A processor processes it on the controller's behalf. Most SaaS companies are both: a controller for their own marketing, billing and account data, and a processor for the data their customers upload. Since the GDPR, processors have direct legal duties (security, records, sub-processor rules, breach notification to the controller) and can be fined directly.

Industries and geography

The GDPR is sector-neutral: it applies to software, e-commerce, healthcare, fintech, edtech, HR tech and adtech alike. Non-EU controllers and processors caught by the targeting test generally must appoint an EU representative (Article 27), with limited exceptions for occasional, low-risk processing.

Key requirements of the GDPR

The seven principles (Article 5)

Lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality; and accountability. Every other requirement flows from these.

Lawful basis (Articles 6 and 9)

Each processing purpose needs one of six lawful bases: consent, contract, legal obligation, vital interests, public task or legitimate interests. Consent is not always the right choice; for running a SaaS account, contract is usually the basis, and for product security logging, legitimate interests often fits. Special category data (health, biometrics used for identification, religion, sexual orientation and others) needs an additional Article 9 condition. Children's consent for online services requires parental authorisation below age 16, or a lower age down to 13 set by national law (Article 8).

Transparency (Articles 12 to 14)

People must be told, in clear language, who you are, what you collect, why, on what basis, who receives it, where it is transferred, how long it is kept and what rights they have.

Data subject rights (Articles 15 to 22)

Access, rectification, erasure, restriction, portability, objection and rights related to solely automated decisions with legal or similarly significant effects. Requests must be answered without undue delay and within one month, extendable by two further months for complex cases.

Accountability duties

• Data protection by design and by default (Article 25).
• Processor contracts with the content Article 28 prescribes, and controls over sub-processors.
• Records of processing activities (Article 30); the exemption for organisations under 250 employees is narrow and rarely applies to SaaS businesses that process data regularly.
• Data protection impact assessments for high-risk processing (Article 35).
• Data protection officer where core activities involve large-scale regular and systematic monitoring or large-scale special category data (Article 37).

Security and breach notification (Articles 32 to 34)

Appropriate technical and organisational measures, such as encryption, pseudonymisation, resilience, restore capability and regular testing. A personal data breach must be reported to the supervisory authority within 72 hours of becoming aware of it unless it is unlikely to result in a risk to individuals, and to affected people without undue delay when the risk is high. Processors must notify the controller without undue delay.

International transfers (Chapter V)

Personal data can leave the EEA only with a transfer mechanism: an adequacy decision (Article 45), appropriate safeguards such as the European Commission's standard contractual clauses or binding corporate rules (Article 46), or narrow derogations (Article 49). After the Court of Justice's Schrems II judgment in July 2020, exporters relying on SCCs must also carry out a transfer impact assessment. The EU-US Data Privacy Framework adequacy decision of 10 July 2023 covers transfers to certified US organisations. India does not currently have an adequacy decision, so transfers to Indian vendors usually rely on SCCs.

How to implement GDPR compliance: step by step

1. Confirm scope and roles. Decide where the GDPR applies, and for each data flow whether you are controller, joint controller or processor.
2. Map your data. Build a record of processing: categories of data and people, purposes, systems, recipients, sub-processors, transfers and retention. Include logs, backups, analytics and support tools, not just the production database.
3. Assign lawful bases. Document a basis for each purpose, with legitimate interests assessments where you rely on that basis.
4. Fix notices and consent. Rewrite privacy notices, and fix cookie banners so non-essential cookies load only after consent (cookie consent comes from the ePrivacy rules as implemented nationally, applied with GDPR consent standards).
5. Put contracts in place. Sign data processing agreements with customers and sub-processors, maintain a public sub-processor list, and execute SCCs for transfers.
6. Build rights handling. Create an intake channel, identity checks, and product features or scripts to export and delete a user's data across systems.
7. Harden security. Align controls to a recognised framework such as ISO 27001 and document them for Article 32.
8. Prepare for breaches. Write an incident response plan with a 72-hour clock, a breach register and notification templates for authorities, controllers and individuals.
9. Run DPIAs for high-risk features such as large-scale profiling, biometrics, employee monitoring or new AI functions.
10. Appoint roles. A DPO where required, an EU representative if you are outside the EU, and an internal privacy owner in any case.
11. Train and review. Train engineers, support and sales, and review the programme at least yearly.

Documentation required

• Records of processing activities (controller and processor versions)
• Privacy notices, cookie notice and consent records
• Lawful basis register and legitimate interests assessments
• Data processing agreements, sub-processor list and SCCs with transfer impact assessments
• DPIAs and the decisions they led to
• Information security policies and a description of technical and organisational measures
• Data subject request procedure and log
• Incident response plan and breach register (Article 33(5) requires all breaches to be documented, even unreported ones)
• Retention schedule and deletion procedures
• Training records

Audit and assessment requirements

The GDPR does not require an annual external audit. Supervisory authorities can investigate after a complaint, a breach report or on their own initiative, and can order access to records and premises. In practice, the most frequent "audits" an IT vendor faces are customer audits under Article 28(3)(h), which entitles controllers to audit their processors, usually satisfied through questionnaires, an ISO 27001 certificate or a SOC 2 report. Internal audits by the DPO or privacy team are good practice and support the accountability principle.

Estimated implementation timeline

Typical timeline for a 50 to 300 person SaaS or IT services company

Phase	Duration
Scoping, data mapping and gap assessment	3 to 6 weeks
Notices, lawful bases, cookie fixes and contracts	4 to 8 weeks
Rights handling, retention and deletion tooling	4 to 10 weeks, depending on architecture
Security alignment, breach process and DPIAs	4 to 8 weeks, in parallel
Training and first internal review	2 to 4 weeks

Most companies reach a defensible baseline in 3 to 6 months. GDPR compliance never "finishes": every new feature, vendor and market needs to be assessed.

Cost considerations

• Advice: privacy counsel or consultants for gap assessment, contracts and DPIAs.
• People: an internal privacy lead, and a DPO (internal or outsourced) where required.
• EU representative: a recurring service fee for non-EU companies.
• Tooling: consent management, data mapping and request handling tools.
• Engineering time: often the largest cost, for deletion, export, retention jobs and data minimisation.

Costs scale with the volume and sensitivity of data, not just headcount. A small B2B tool with business contact data costs far less to bring into line than a consumer health app.

Benefits of GDPR compliance

• Eligibility for EU contracts; enterprise buyers will not sign without a compliant DPA.
• Lower regulatory and litigation risk, including claims for compensation under Article 82.
• Cleaner data: less stored data means smaller breach impact and lower storage costs.
• A strong base for other privacy laws such as the DPDP Act and CCPA/CPRA, which borrow many GDPR concepts.
• Customer trust, which matters more as AI features process more personal data.

Risks and consequences of non-compliance

• Fines under Article 83: up to EUR 10 million or 2% of worldwide turnover for obligations such as security, records and processor duties, and up to EUR 20 million or 4% for breaches of the principles, lawful basis, rights and transfer rules, whichever is higher.
• Corrective orders, including bans on processing or orders to suspend transfers. In May 2023 the Irish Data Protection Commission fined Meta EUR 1.2 billion and ordered it to suspend unlawful EU-US transfers, the largest GDPR fine to date.
• Compensation claims from individuals and representative actions.
• Lost deals when a customer's privacy review fails.

Common implementation mistakes

• Treating the GDPR as a cookie banner and a privacy policy.
• Relying on consent for everything, then being unable to process when users withdraw it.
• Forgetting logs, backups, analytics, support tickets and staging copies in the data map.
• Using production personal data in test environments.
• Signing customer DPAs without checking that your sub-processors' terms match them.
• No tested way to delete a user across every system.
• Assuming a cloud region in the EU removes all transfer issues when support staff elsewhere can access the data.

Compliance challenges for IT companies

• Remote access from outside the EEA counts as a transfer, so offshore development and support teams need SCCs and transfer impact assessments.
• Multi-tenant SaaS must handle different customers' retention and deletion instructions.
• AI features raise questions about training on customer data, purpose limitation and automated decisions; see also the EU AI Act.
• Sub-processor chains in modern stacks are long; each needs a contract and a transfer mechanism.

Best practices and recommendations

• Make privacy review part of the product design process and the definition of done.
• Collect less: drop fields you do not need and set short default retention.
• Pseudonymise analytics and separate identifiers from behavioural data.
• Run a breach tabletop exercise with the 72-hour clock at least once a year.
• Combine GDPR work with ISO 27701 if clients ask for certifiable proof of a privacy programme.

Tools and technologies that help

• Consent management platforms that block tags until consent is given
• Data discovery and mapping tools that scan databases and SaaS apps for personal data
• Privacy request portals with identity verification and workflow tracking
• Key management and field-level encryption services
• Vendor risk management tools for sub-processor reviews

Tools speed up the work, but the decisions about purposes, bases and retention remain yours.

Relationship with other compliance frameworks

How the GDPR relates to other requirements

Framework	Relationship
ISO 27001	Provides the security management system behind Article 32; does not cover lawful basis or rights
ISO 27701	Certifiable privacy management system with controls mapped to GDPR duties
DPDP Act	India's law shares concepts such as notice, consent and breach reporting but has fewer lawful bases and different penalties
CCPA/CPRA	California law focused on notice, opt-outs of sale and sharing, and consumer rights
EU AI Act	Applies alongside the GDPR when AI systems process personal data

Real-world implementation examples

The following are illustrative composites based on common patterns, not named clients.

Indian B2B SaaS entering Europe

A 120-person HR software company signed its first German customer and received a 40-page DPA. It mapped data flows, appointed an EU representative, published a sub-processor list, signed SCCs with its Indian entity and US vendors, and built bulk export and deletion endpoints. The project took four months and became the template for later Indian DPDP Act work.

Agency acting as processor

A web agency maintaining e-commerce sites for EU retailers discovered that developers copied production databases to laptops for debugging. It introduced masked datasets, restricted production access to a jump host with logging, and documented the controls in its DPA annex.

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 in the EU (Article 3(2)), and when they process data as a processor for an EU controller under contract.

Is there a GDPR certification?

There is no mandatory GDPR certificate. Approved certification schemes and codes of conduct exist but are optional. ISO 27701 certification is often used as supporting evidence.

Do we need a data protection officer?

Only if your core activities involve large-scale regular and systematic monitoring of people, large-scale special category data, or you are a public authority. Many SaaS companies appoint one voluntarily or outsource the role.

How fast must we report a breach?

Within 72 hours of becoming aware of it to the supervisory authority, unless it is unlikely to result in a risk to individuals. Processors must tell the controller without undue delay.

Is consent required for all processing?

No. Consent is one of six lawful bases. Contract, legal obligation and legitimate interests are often more appropriate for B2B services.

Can we transfer EU personal data to India?

Yes, with a transfer mechanism. India has no adequacy decision, so standard contractual clauses plus a transfer impact assessment are the usual route.

What is a data processing agreement?

The contract between a controller and processor required by Article 28. It sets processing instructions, confidentiality, security, sub-processor rules, assistance with rights and breaches, deletion at the end of the service and audit rights.

How long can we keep personal data?

No longer than necessary for the purpose. The GDPR sets no fixed periods; you define them in a retention schedule, guided by legal obligations such as tax and employment laws.

Does the GDPR apply to B2B contact data?

Yes. Business emails and phone numbers of named people are personal data, although legitimate interests is often a valid basis for B2B communications, subject to national e-marketing rules.

What are the GDPR fines?

Up to EUR 20 million or 4% of worldwide annual turnover for the most serious infringements, and up to EUR 10 million or 2% for others, whichever is higher.

Do we need an EU representative?

Non-EU organisations subject to the targeting test generally do, unless their processing is occasional, low risk and excludes large-scale special category data.

Is the GDPR being changed?

The European Commission proposed targeted amendments in its Digital Omnibus in November 2025. As of October 2026 they are not law, and the current GDPR text applies.

Conclusion and next steps

For IT companies, the GDPR is less about legal theory and more about engineering discipline: knowing where personal data lives, collecting less of it, protecting it, deleting it on time and proving all of this to customers and regulators.

1. Confirm your role and scope for each product and client.
2. Build or refresh your record of processing.
3. Fix contracts, transfers and notices.
4. Close engineering gaps for rights, retention and security.
5. Review yearly and on every major product change.

This guide is general information, not legal advice. Get advice from qualified privacy counsel for your specific situation.

How we keep this guide up to date

We review this guide every six months and whenever the GDPR is amended, the EDPB adopts significant guidelines, or the European Commission issues or withdraws an adequacy decision. The Digital Omnibus negotiations are tracked closely and the guide will be revised once any change is adopted.