GDPR Made Simple: Controls, Audit, Checklist and DPDP Comparison
GDPR is the European Union’s law on personal data. Its full name is the General Data Protection Regulation (Regulation (EU) 2016/679). It has applied since 25 May 2018.
It protects people in the EU and EEA. It applies to any organisation that handles their data, even if that organisation is in India, the US or anywhere else. You are covered if you offer goods or services to people in the EU, or if you track their behaviour online (Article 3).
Personal data is any information that can identify a person, directly or indirectly. Examples: name, email, phone number, IP address, photo, location, employee records.
Special category data is more sensitive: health, biometrics, religion, political views, sexual orientation, trade union membership. You need an extra legal reason to use it (Article 9).
Why it matters
- Fines. Up to 20 million euros or 4% of yearly worldwide turnover, whichever is higher, for the most serious breaches. Up to 10 million euros or 2% for lesser ones (Article 83).
- Claims. People can ask for compensation if you cause them harm (Article 82).
- Business. Large customers often ask for proof that you follow GDPR before they sign a contract.
The seven principles (Article 5)
Every other rule in GDPR comes back to these.
- Be lawful, fair and open about what you do with data.
- Use data only for the reason you collected it.
- Collect only what you need.
- Keep it accurate and up to date.
- Do not keep it longer than you need to.
- Keep it safe.
- Be able to show that you follow all of the above.
Five points to remember
- Every use of personal data needs a legal reason (called a lawful basis).
- People have rights over their data. You must answer their requests within one month.
- It is not enough to comply. You must be able to prove it.
- If there is a serious data breach, you must tell the regulator within 72 hours.
- You are also responsible for the vendors you use and for data you send outside the EU.
Data controller and data processor
These two roles decide who has which duties. Many organisations get this wrong, so it deserves its own page on your site.
Who is who (Article 4)
- Controller. The one who decides why the data is used and how. It is the owner of the decisions.
- Processor. The one who handles data for the controller and follows the controller’s written instructions. It does not decide the purpose.
- Joint controllers. Two or more organisations that decide the purpose and the method together (Article 26). They must agree in writing who does what.
- Sub-processor. A processor hired by another processor. The controller must approve it first.
How to tell them apart
Ask one question: who decides why this data is being used, and how?
The EDPB explains this in its Guidelines 07/2020 on controllers and processors. The key point is that the role comes from what really happens, not from what the contract says. If a company is called a processor but decides its own purposes, the law treats it as a controller.
| Example | Role |
|---|---|
| A shop collects customer details to sell to them | Controller |
| The cloud company that stores those details | Processor |
| A payroll company that pays your staff on your instructions | Processor |
| An analytics tool that also uses your data to improve its own product | Controller for that extra use |
| Two companies running a campaign together with shared data | Joint controllers |
| A lawyer or auditor who uses their own professional judgement | Usually a controller |
What each one must do
| Topic | Controller | Processor |
|---|---|---|
| Legal reason for using data | Chooses and records it | Follows instructions |
| Telling people how data is used (privacy notice) | Does it | Helps |
| People’s rights requests | Answers within one month | Helps and passes requests on quickly |
| Records of processing (Art 30) | Keeps full records | Keeps records of what it does for each controller |
| Security (Art 32) | Responsible | Also directly responsible |
| Data breach | Tells the regulator within 72 hours, and people if the risk is high | Tells the controller without delay |
| Impact assessment (DPIA) | Leads it | Helps |
| Contract (Art 28) | Must have a written contract | Must follow it |
| Sending data outside the EU | Makes sure a legal method is used | Follows the instructions and the method |
| Liability (Art 82) | For breaking the rules in its own processing | If it broke processor duties or ignored the controller’s instructions |
What the contract with a processor must say (Article 28)
This contract is called a Data Processing Agreement (DPA). It must cover:
- what the work is, how long it lasts, what data is used and whose data it is
- that the processor acts only on written instructions, including for transfers abroad
- that staff keep the data confidential
- the security measures in place
- the rules for sub-processors (approval first, same duties passed down)
- help with rights requests, breaches and impact assessments
- deleting or returning the data when the service ends
- proof of compliance and the right for the controller to audit
The European Commission publishes ready-made Standard Contractual Clauses for controller-to-processor contracts.
Common mistakes
- Thinking a hosting or software vendor has no responsibility. Processors have their own legal duties.
- Signing the contract and never checking the vendor.
- Not knowing who the vendor’s sub-processors are.
- Not noticing that a vendor using your data for its own purposes has become a controller.
The GDPR controls in simple terms
GDPR does not hand you a fixed list of technical controls. It sets duties and expects you to choose measures that fit the risk to people (Articles 24 and 32). A practical way to organise the work is to group it into seven areas.
1. Governance and accountability
Someone must own privacy, and you must be able to show you follow written rules.
- Written policies approved by management (Articles 5(2) and 24)
- Privacy built into new products and systems, by design and by default (Article 25)
- A Data Protection Officer (DPO) if you are a public body, if you monitor people on a large scale, or if you handle special category data on a large scale (Articles 37 to 39)
- An EU representative if you are outside the EU but covered by GDPR (Article 27)
- Training for staff
2. A legal reason for every use of data (Article 6)
There are six lawful bases: consent, contract, legal obligation, vital interests, public task and legitimate interests. Pick one for each purpose and write it down.
- Consent must be freely given, specific, informed and a clear yes. Withdrawing must be as easy as giving it. Pre-ticked boxes do not count.
- Legitimate interests need a written test: why you need the data, whether there is a less intrusive way, and how it affects the people involved.
- Children: the default age for giving consent online is 16. Countries may lower it, but not below 13.
- Special category data needs a lawful basis from Article 6 plus a condition from Article 9.
3. Telling people and respecting their rights (Articles 12 to 22)
| Right | In plain words | Article |
|---|---|---|
| Be informed | Know who you are, why you use their data, how long you keep it and who gets it | 13, 14 |
| Access | Get a copy of their data | 15 |
| Correction | Fix wrong data | 16 |
| Erasure | Have data deleted in certain cases | 17 |
| Restriction | Ask you to pause using their data | 18 |
| Portability | Receive their data in a usable format and move it | 20 |
| Object | Ask you to stop, for example direct marketing | 21 |
| Automated decisions | Ask for a human to review important automated decisions | 22 |
You have one month to reply. For complex or many requests you can extend by two more months, but you must tell the person.
4. Know your data and your risks
- Records of processing (ROPA, Article 30): a list of what data you hold, why, who sees it, where it goes and how long you keep it.
- Data Protection Impact Assessment (DPIA, Article 35): a risk check before starting high-risk work, such as large-scale profiling, large-scale special category data or monitoring public spaces. If a high risk remains, you must consult the regulator first (Article 36).
- Other written checks: the legitimate interests test, transfer assessments and vendor risk checks.
5. Security (Article 32)
Use measures that match the risk. Typical ones are encryption, access control, multi-factor login, backups, logging, patching and regular testing. You must also be able to restore data after an incident. ISO/IEC 27001, ISO/IEC 27701 and ENISA guidance are useful references.
6. Data breaches (Articles 33 and 34)
- Spot the breach and contain it.
- Judge the risk to people.
- Tell the regulator within 72 hours of becoming aware, unless the breach is unlikely to put people at risk.
- Tell the affected people without delay if the risk is high.
- Record every breach in a register, even the ones you do not report.
7. Vendors and sending data abroad
- Have a written contract with every processor (Article 28) and check them from time to time.
- Sending data outside the EEA needs a valid method (Articles 44 to 49): an adequacy decision, Standard Contractual Clauses, Binding Corporate Rules, or a narrow exception.
- After the Schrems II court ruling, check that the destination country’s laws do not weaken the protection, and add extra safeguards if they do.
- The EU-US Data Privacy Framework covers certified US companies. Check its current legal status before you rely on it.
How to put GDPR in place, step by step
The timings below are a typical guide for a mid-size organisation. Adjust them to your size and risk.
Step 1: Get set up (weeks 1 to 2). Get a sponsor in senior management and a budget. Decide the scope: which companies, countries and systems. Name a DPO or privacy lead, and an EU representative if you need one. Form a small group from Legal, IT and Security, HR, Marketing, Procurement and Product.
Step 2: Find out what data you have (weeks 3 to 6). Map the personal data: where it is, who uses it, where it goes and how long it stays. Write the ROPA. List your vendors and work out whether each is a controller, a processor or a joint controller. Compare what you do today with the seven areas above to find the gaps.
Step 3: Fix the gaps (weeks 7 to 16). Choose and record a lawful basis for each activity. Fix consent forms and cookie banners (cookies are also covered by the separate ePrivacy rules). Update your privacy notices. Write the core policies: data protection, retention, rights requests, breach response, DPIA and vendor onboarding. Sign processor contracts and put transfer methods in place. Add the technical controls.
Step 4: Make it routine (months 4 to 6). Train all staff, with extra training for HR, marketing, support and engineering. Run a practice breach drill. Start a rights-request process with deadlines and tracking. Do DPIAs before any high-risk project.
Step 5: Check and improve (month 6 onwards). Run internal audits and vendor reviews. Report to management on a regular basis. Follow new guidance from the EDPB and your lead regulator, and update your policies.
How to measure progress
- Share of data uses that are mapped and recorded
- Share of vendors with a signed contract
- Rights requests answered on time
- Share of staff who finished training
- Breaches reported within 72 hours
- DPIAs finished before launch
- Data kept past its retention date
How to audit your GDPR compliance
An audit answers one question: can we prove that what we say we do is what we actually do?
Kinds of audit
- Internal audit by your own privacy, compliance or audit team.
- Vendor audit of your processors. Article 28 gives you the right to ask for this.
- External audit or certification, for example ISO/IEC 27701.
- Regulator inspection. Supervisory authorities can investigate and order you to provide information (Article 58).
Steps
- Plan. Decide what you are checking (which teams, systems and period) and what you are checking against (GDPR articles, your policies, your contracts).
- Collect documents. Records of processing, privacy notices, policies, processor contracts, DPIAs, the breach register, the rights-request log, training records and security reports.
- Test in practice. Pick a few data uses and follow them from start to finish. Check that your records match what the systems really do.
- Talk to the people who do the work. HR, marketing, IT, support, product.
- Check the technical side. Who has access, whether data is encrypted, whether deletion jobs run, whether consent is logged, what the cookie banner really does.
- Report. Rate each finding by how serious it is. Give every one an owner and a date.
- Follow up. Confirm that the fixes were made and tell management.
What to check
| Area | Question to ask | Evidence to see |
|---|---|---|
| Governance | Is there a DPO or privacy lead, a policy set and reporting to management? | Org chart, policies, meeting notes |
| Records (ROPA) | Is it complete, up to date and owned by someone? | The record with review dates |
| Lawful basis | Is a valid basis written down for each use? | Basis register, balancing tests |
| Consent | Is it specific, recorded and easy to withdraw? | Consent logs, screenshots |
| Privacy notices | Do they cover everything in Articles 13 and 14? | Published notices and versions |
| Rights | Are requests tracked and answered on time? | Request log, sample replies |
| DPIA | Were high-risk projects assessed before launch? | DPIA register |
| Security | Are the measures in place and tested? | Penetration tests, access reviews |
| Breaches | Is there a tested plan and a register? | Plan, drill results, register |
| Vendors | Are contracts signed, sub-processors known and checks done? | Contract list, due diligence files |
| Transfers | Is there a valid method and an assessment? | Clauses, transfer assessments |
| Retention | Is the schedule enforced by the systems? | Schedule, deletion logs |
| Training | Has everyone done it? | Completion reports |
A simple scoring scale
- 0 Nothing in place
- 1 Done informally, not written down
- 2 Written down but not followed everywhere
- 3 In place, followed and backed by evidence
- 4 Measured and reviewed regularly
Fix the biggest risks to people first: special category data, children, large-scale monitoring and transfers abroad. Then look at where a regulator would be most likely to act.
GDPR checklist
Governance
- A sponsor in senior management and a clear owner for privacy
- DPO appointed if required, with contact details published
- EU representative appointed if required (Article 27)
- Data protection policy approved
- Yearly training for all staff, extra training for key roles
Know your data
- Data inventory and data flow maps
- Records of processing kept up to date (Article 30)
- Special category and children’s data identified
- Retention schedule set and followed
Legal reasons and openness
- Lawful basis written down for every use of data
- Consent is clear, recorded and easy to withdraw
- Legitimate interests test done where you rely on it
- Privacy notices cover everything in Articles 13 and 14
- Cookie consent follows the rules
People’s rights
- A process for access, correction, erasure, restriction, portability and objection
- A way to check who is asking
- One-month deadline tracked
- Marketing opt-outs respected straight away
- Safeguards for automated decisions (Article 22)
Risk and security
- DPIA process and register
- Encryption, access control, multi-factor login and logging
- Regular vulnerability and penetration tests
- Backups tested
- Privacy considered in every new product or system
Breaches
- Incident plan that covers personal data
- 72-hour process and message templates ready
- Breach register for all incidents
- A practice drill in the last 12 months
Vendors and transfers
- List of vendors with their role (controller, processor, joint controller)
- Article 28 contract with every processor
- Sub-processors reviewed
- Vendors checked before hiring and from time to time after
- Valid transfer method and assessment for data leaving the EEA
Keeping it going
- Audit schedule
- Regular review and reporting to management
- Someone follows new guidance from regulators
RACI: who does what
R = does the work. A = final owner, only one per task. C = gives input. I = kept informed.
| Task | Management | DPO / Privacy lead | Legal | IT / Security | HR | Marketing | Procurement | Process owner |
|---|---|---|---|---|---|---|---|---|
| Approve privacy policy and plan | A | R | C | C | I | I | I | I |
| Data mapping and records | I | A | C | C | R | R | I | R |
| Lawful basis and consent | I | A | R | C | C | R | I | C |
| Privacy notices and cookies | I | A | R | C | C | R | I | C |
| Handling rights requests | I | A | C | R | R | R | I | R |
| DPIA | I | A | C | R | C | C | I | R |
| Security controls | I | C | C | A/R | C | I | I | C |
| Breach response | I | A | R | R | C | C | I | C |
| Vendor checks and contracts | I | C | R | C | I | I | A/R | C |
| Transfer assessments | I | A | R | C | I | I | C | C |
| Training | I | A | C | C | R | C | I | I |
| Retention and deletion | I | A | C | R | R | R | I | R |
| Internal audit and fixes | I | A | C | R | C | C | C | R |
| Reporting to management | A | R | C | C | I | I | I | I |
A point about the DPO. A DPO must be independent and must not decide the purposes and means of processing (Articles 38 and 39). If you want to keep that separation, make a privacy lead or a business owner the A in this table, and keep the DPO as an adviser who monitors compliance.
India’s DPDP law compared with GDPR
India’s Digital Personal Data Protection Act, 2023 (DPDP Act) and the DPDP Rules, 2025 are being brought in step by step. The Rules were notified on 13 November 2025. Rules about the Data Protection Board took effect straight away. The Consent Manager rules follow around 13 November 2026. Most other duties start around 13 May 2027. Some reports say this timeline may be shortened, so check the MeitY website for the latest dates.
Different names for the same roles
| GDPR | DPDP |
|---|---|
| Controller | Data Fiduciary |
| Processor | Data Processor |
| Data subject | Data Principal |
| Regulator (supervisory authority) | Data Protection Board of India |
| No special class | Significant Data Fiduciary (SDF), a larger or riskier organisation chosen by the government |
| No equivalent | Consent Manager, a registered service that helps people manage their consent |
The main differences
| Topic | GDPR | DPDP |
|---|---|---|
| Data covered | All personal data, digital and organised paper records | Digital personal data, and paper data that is later digitised |
| Who must follow it | Organisations in the EU, and those outside it that offer goods or services to people in the EU or monitor them | Processing in India, and outside India when offering goods or services to people in India |
| Sensitive data | Special categories with extra rules | No separate sensitive category |
| Legal reasons | Six, including legitimate interests | Consent, or a fixed list of legitimate uses. There is no general legitimate interests option |
| Privacy notice | Articles 13 and 14 | Separate, itemised notice in plain language, available in English or any of the 22 languages in the Eighth Schedule |
| Children | Age 16 by default (13 to 16 depending on the country) | Under 18. A parent’s verifiable consent is needed, and tracking or targeted ads aimed at children are banned, with some exemptions |
| People’s rights | Access, correction, erasure, restriction, portability, objection, automated decisions | Access, correction and erasure, grievance redressal, and nominating someone to act for them. No portability or objection right |
| Reply time | One month | Rules set up to 90 days for grievances |
| Data breach | Tell the regulator within 72 hours if there is a risk. Tell people if the risk is high | Tell every affected person and the Board. A detailed report goes to the Board within 72 hours |
| DPO | Only in certain cases | Only for Significant Data Fiduciaries, and the DPO must be based in India |
| Impact assessment and audit | DPIA for high-risk work | Significant Data Fiduciaries must do regular impact assessments and a yearly audit |
| Records of processing | Required (Article 30) | No direct equivalent, but you still need evidence |
| Data sent abroad | Restricted unless a valid method is used | Allowed in general, except to countries the government puts on a restricted list. Sector rules may be stricter |
| Processor contract | Detailed list of terms (Article 28) | A valid contract is required. The fiduciary stays responsible |
| Government bodies | Covered | Wide exemptions for the State and notified bodies |
| Regulator | Independent national authorities, with the EDPB coordinating | A Board appointed by the government. Appeals go to TDSAT |
| Compensation to people | Yes (Article 82) | No direct compensation. Penalties are paid to the government |
| Highest penalty | 20 million euros or 4% of worldwide turnover | Up to 250 crore rupees |
What this means in practice
- Build one privacy programme and add a layer for each country. Data mapping, vendor control, breach response, security and training are the same everywhere.
- GDPR is broader and more detailed. DPDP leans on consent. It is stricter in a few places: children under 18, the format of notices, and telling every affected person about a breach.
- Being GDPR-compliant does not make you DPDP-compliant. India has no general legitimate interests option, so some uses that are fine in the EU need consent or a specific legitimate use in India.
- Get ready for Consent Managers by keeping consent records that can connect to them.
- Check sector rules from bodies such as the RBI, SEBI, IRDAI and health regulators, which may add duties.
