Data protection and GDPR, answered
139 questions on data processing agreements, GDPR duties and cross-border transfers, answered in plain English for technology and SaaS businesses.
Data processing agreements, GDPR duties and cross-border transfers, answered directly, drawn from what technology and SaaS businesses actually search for.
Data processing agreements
If someone else touches personal data on your behalf, the contract is not optional.
A data processing agreement (DPA) is the written contract required whenever a controller lets a processor handle personal data for them. Under Article 28 of the UK GDPR and the EU GDPR it is a legal requirement, not best practice. If you are a SaaS business, your customers are usually the controller and you are the processor, so the DPA sits underneath your main agreement and describes what you are allowed to do with their data.
A compliant DPA has to cover a fixed list: subject matter and duration, nature and purpose of processing, types of personal data and categories of data subject, and then the eight processor obligations in Article 28(3). Those are documented instructions only, confidentiality of staff, Article 32 security measures, rules on sub-processors, assistance with data subject rights, assistance with breach notification and DPIAs, deletion or return at the end, and audit and information rights.
A data sharing agreement is a different animal. That is controller to controller, where each side decides its own purposes. It is not mandated by statute, but the ICO’s data sharing code of practice expects one, and it is the document that saves you when a regulator or a customer asks who was responsible for what. Getting the two confused is the single most common mistake we see in signed paperwork.
What is a data processing agreement?
A contract between a controller and a processor that sets out exactly how the processor may handle personal data on the controller’s behalf. It is required in writing by Article 28 UK GDPR and EU GDPR, and it must contain the specific terms listed in Article 28(3).
Is a data processing agreement a legal requirement?
Yes. Where a controller uses a processor, Article 28(3) requires a written contract or other legal act. There is no small business exemption. If you process personal data for a customer and there is no DPA, both sides are exposed, and it is usually the supplier who gets asked about it first in a security review.
When do you need a DPA?
Whenever one organisation processes personal data on the documented instructions of another. That includes hosting, support access to a customer’s tenant, analytics run for a client, outsourced payroll, and most sub-processors sitting under you. If you only ever handle data you decided to collect for your own purposes, you are a controller and you need different paperwork.
A client is asking us to sign a data processing agreement. Who can review it?
A commercial lawyer who works with data protection day to day, rather than a general practice. What matters is not just whether the clauses are lawful, but whether they are operationally survivable: audit windows you can actually meet, sub-processor change notice you can actually give, deletion timescales your architecture can actually hit. Eliga reviews these as embedded counsel, so the answer accounts for how you really run.
A client wants us to sign their DPA. What should we check?
Six things: whether the instructions clause is broad enough to cover what you actually do, whether sub-processor approval is a general authorisation or a right of veto, whether the audit right is unlimited on-site access, whether liability for data claims is carved out of your main cap, whether breach notification is a fixed clock like 24 hours, and whether the deletion obligation matches your backup retention.
Where can I get a GDPR data processing agreement drafted or reviewed?
From a commercial or data protection lawyer. A drafted DPA should be built off your real data flows, not a blank form, because the schedules are the part that carries the risk. Eliga drafts customer-facing DPAs for SaaS suppliers and reviews inbound ones on the buy side.
Data processing vs data sharing agreement: what is the difference?
A data processing agreement is controller to processor, where one side follows the other’s instructions. A data sharing agreement is controller to controller, where both sides decide their own purposes. The processing agreement is mandatory; the sharing agreement is expected by the ICO code but not required by statute.
Is a DPA template enough?
A template gets you the mandatory clauses. It does not fill in your schedules, describe your sub-processors, set your security measures, or reconcile your DPA with the liability cap in your main agreement. The template is the cheap part. The schedules and the interaction with the rest of the contract are where the risk actually lives.
What about DPA templates for the EU, US, South Africa or India?
The mandatory content changes by regime. EU and UK DPAs follow Article 28, and the European Commission has published its own standard contractual clauses for controller-processor use. US state privacy laws impose their own required processor terms, South Africa’s POPIA works through operator obligations in sections 20 and 21, and India’s DPDP Act uses a different data fiduciary and data processor structure. A UK template dropped into a South African or Indian deal will be missing terms.
GDPR, data protection duties and transfers
Most GDPR questions are really questions about who is responsible, and where the data goes.
GDPR compliance for a growing business comes down to a handful of things you can evidence: a lawful basis for each processing activity, a record of processing under Article 30, transparency through your privacy notice, security appropriate to the risk under Article 32, a route for data subject rights, a breach process that can hit 72 hours, and contracts with everyone who touches the data for you.
Data protection and data privacy are used interchangeably in conversation, but they are not quite the same. Privacy is the underlying right, the expectation that information about a person is not used in ways they would not expect. Data protection is the legal machinery that implements it: lawful bases, rights, duties, and the accountability principle that says you must be able to show your working.
Cross-border transfers are where UK and EU businesses most often get caught. Sending personal data outside the UK or EEA needs an adequacy decision, or a transfer mechanism plus a transfer risk assessment. In the UK that is the IDTA or the UK Addendum to the EU SCCs. In the EU it is the 2021 SCCs. Other regimes have their own rules: China’s PIPL requires a security assessment, standard contract filing or certification depending on volume and sensitivity, and Singapore’s PDPA requires comparable protection by contract or other means.
What are the GDPR requirements, in summary?
Have a lawful basis for every processing purpose, tell people what you do in a privacy notice, keep an Article 30 record of processing, apply security proportionate to the risk, honour data subject rights within a month, report qualifying breaches to the regulator within 72 hours, contract properly with processors, run a DPIA for high risk processing, and be able to demonstrate all of it.
What is the difference between data privacy and data protection?
Data privacy is the right and the expectation. Data protection is the legal framework that gives it effect through lawful bases, rights, obligations and accountability. In practice, when a customer asks about your privacy posture they usually want evidence of the data protection machinery.
When do you need a data protection officer?
Under Article 37 a DPO is mandatory if you are a public authority, if your core activities involve regular and systematic monitoring of individuals on a large scale, or if your core activities involve large scale processing of special category or criminal offence data. Outside those triggers you can appoint one voluntarily, but if you do, the statutory independence obligations attach.
When do you need a DPIA?
Where processing is likely to result in a high risk to individuals, which Article 35 illustrates with systematic profiling with legal effects, large scale special category processing, and large scale systematic monitoring of public areas. The ICO and EDPB both publish lists of processing that always requires one. New AI-driven decisioning almost always warrants a DPIA.
Do GDPR requirements apply to US companies?
They can. Article 3 extends the GDPR to organisations outside the EU or UK that offer goods or services to people there, or monitor their behaviour there. Being incorporated in Delaware does not put you outside scope if your product is sold to European users, and an Article 27 representative may also be required.
What are the cross-border data transfer requirements?
Either the destination has an adequacy decision, or you put a transfer mechanism in place and document a transfer risk assessment. UK exporters use the IDTA or the UK Addendum to the EU SCCs; EU exporters use the 2021 SCCs. Binding corporate rules are an option for intra-group transfers. The paperwork alone is not enough without the risk assessment behind it.
Does AWS or another cloud provider make us GDPR compliant?
No. A hyperscaler gives you infrastructure controls, a processor DPA and a set of certifications. Your lawful basis, your privacy notice, your retention, your rights handling and your own sub-processor chain remain yours. Buying a compliant platform is not the same as being a compliant controller.
Is a data protection policy template enough?
A policy template gives you a document. Accountability requires the document to be true. If your policy says you delete after 24 months and your backups keep data for seven years, the template has actively made things worse by creating a written statement you are breaching.
What are the GDPR requirements on contracts?
Article 28 for processors, Article 26 for joint controllers where you jointly determine purposes and means, and Chapter V transfer terms where data leaves the UK or EEA. Those are the three contractual hooks that most commercial agreements need to get right.
Privacy policies, website terms and SaaS T&Cs
Your terms are the product boundary. Generated ones describe a product you do not sell.
A privacy notice and a set of terms of service do different jobs. The privacy notice is a transparency obligation under Articles 13 and 14: what you collect, why, on what basis, who you share it with, how long you keep it, and what rights people have. The terms of service are the commercial contract: licence scope, payment, uptime, support, liability, termination and what happens to data at the end.
Generators and AI-written terms are attractive because they are instant. The problem is that they describe a generic product. They will not know that you have a free tier with different data handling, that you train models on aggregated usage, that your enterprise tier includes a private instance, or that you resell a third party component whose licence flows down to your customer. Terms that do not describe your actual product are worse than no terms, because they define your obligations in ways you cannot meet.
For SaaS specifically, the set is usually four documents: the terms of service or subscription agreement, the acceptable use policy, the DPA, and the service level commitment. Splitting them out matters, because it lets you change the ones that move often without reopening the commercial deal.
Who reviews SaaS terms and conditions for startups?
A commercial lawyer with SaaS experience, ideally one who reads them alongside your pricing page and your product roadmap. The common failures are not legal drafting errors, they are mismatches: terms promising a support response you do not staff, or a licence scope narrower than what customers actually do with the product.
Can I use an AI terms and conditions generator?
You can generate a first draft. Treat it as a checklist, not a contract. Generated terms routinely miss the things unique to you: your data use for model training, your third party component licences, your uptime commitment, your renewal and uplift mechanics, and the interaction between your liability cap and your DPA.
What should SaaS terms of service cover?
Licence or subscription grant and scope, permitted users and use restrictions, fees and renewal, service levels and credits, support commitments, customer data ownership and your right to use it, confidentiality, IP and feedback, warranties, liability caps and exclusions, indemnities, term and termination, data export and deletion, and governing law.
Do I need a separate acceptable use policy?
It helps. Putting prohibited use in a policy you can update on notice means you can respond to abuse patterns without renegotiating a signed contract. Keep the suspension right in the main agreement and the detail in the policy.
What is the difference between a privacy policy and a data processing agreement?
The privacy notice is a public statement to individuals about how you use their data. The DPA is a contract with a business customer about data you handle on their instructions. Different audiences, different legal basis for existing, and they should not contradict each other.
Is a free terms and conditions template safe to use?
For a simple brochure site, often yes. For a paid SaaS product with customer data, enterprise buyers, uptime promises and a liability cap, a free template is where the argument starts, not where it ends. The template will not be wrong so much as silent on the clauses that decide who pays when something breaks.
Do terms and conditions need to differ by country?
Consumer-facing terms do. Consumer protection rules, unfair terms regimes and mandatory local law override what your contract says, and Australian, EU and UK consumer regimes each have their own non-excludable guarantees. B2B terms travel further, but governing law and jurisdiction still need thought.
Still the wrong answer for your situation?
General answers only go so far. If you have a DPA on your desk, a client asking about your data protection posture, or cross-border transfer terms that do not fit your business, the useful conversation is about your facts.
Book a call: calendly.com/dhruve-eligaconsultancy
This page is general information about UK and EU data protection practice. It is not legal advice and it does not create a solicitor-client relationship.