GDPR Requirements — Explained in Simple Language

It covers 60 requirements across 8 key areas.

This is intentionally not a simple checklist. A checklist only asks, “Do you have this?” This document goes one step further and explains what is actually required and what evidence can prove that you are doing it.

If you first want to understand how prepared your organisation is, you can use a GDPR readiness assessment that gives you a score out of 100.

________________________________________

1. Understanding Whether GDPR Applies to You

Relevant Articles: 4, 3, 27 and 30

You must know your role when handling personal data

For every activity involving personal data, you should know whether you are:

• A Controller — you decide why and how the data is used.

• A Joint Controller — you decide these things together with another organisation.

• A Processor — you handle data based on someone else's instructions.

Evidence: A written record for each processing activity showing your role.

Simply calling yourself a “processor” in a contract does not automatically make you one. What matters is who actually decides the purpose and method of processing.

You must determine whether GDPR applies to your organisation

You need to check whether:

• You are established in the EU.

• You offer goods or services to people in the EU.

• You monitor the behaviour of people in the EU.

Evidence: A documented territorial-scope assessment.

Organisations outside the EU may need an EU representative

If you are outside the EU but GDPR applies to you, you may need to appoint a representative in the EU.

Evidence: Written appointment details and the representative's information in your privacy notice.

If this requirement does not apply, document why.

You must maintain a Record of Processing Activities (ROPA)

Your Article 30 record should include information such as:

• Who you are.

• Why you process the data.

• Categories of people whose data you process.

• Types of personal data collected.

• Who receives the data.

• International transfers and safeguards.

• How long data is kept.

• Security measures used.

Evidence: A current Article 30 Record of Processing Activities.

A simple spreadsheet listing your IT systems is not automatically an Article 30 record.

Your records must always be current

The information must be written down, regularly updated and available if a regulator asks for it.

Evidence: Version history, review dates and proof that the record can be produced when requested.

________________________________________

2. Having a Lawful Reason to Use Personal Data

Relevant Articles: 6, 7, 9 and 10

Every processing activity needs a lawful basis

For every activity, you must identify the legal reason that allows you to process the data.

Evidence: The lawful basis recorded for each activity in your ROPA.

If you use legitimate interest, you need an assessment

You must document why the processing is necessary and why your interest does not unfairly override the individual's rights.

Evidence: A dated Legitimate Interests Assessment covering:

• Purpose.

• Necessity.

• Balancing of interests.

The lawful basis should be decided before processing starts

You should not choose a legal basis after processing has already started simply because it is convenient.

Evidence: Records showing that the legal basis was decided in advance.

Special category data requires additional protection

This includes data relating to areas such as:

• Health.

• Race or ethnic origin.

• Religion.

• Political opinions.

• Trade union membership.

• Biometrics.

• Sex life or sexual orientation.

You need both a normal lawful basis and, where required, an additional Article 9 condition.

Evidence: The Article 9(2) condition and any additional national legal requirements.

Criminal offence data requires specific legal authority

If you process criminal offence data, you must have a valid legal basis for doing so.

Evidence: The relevant law or official authority.

If you do not process such data, record this as not applicable and explain why.

Consent must meet GDPR requirements

Where consent is used, it must be:

• Freely given.

• Specific.

• Informed.

• Clearly given through an affirmative action.

Evidence: Consent records showing:

• What the person agreed to.

• When they agreed.

• How they agreed.

• Which privacy notice they saw.

Pre-ticked boxes are not valid consent.

Consent must be separate and easy to understand

Consent should not be hidden inside complicated terms and conditions.

Evidence: The actual consent form, screen or wording shown to the individual.

People must be able to withdraw consent easily

It should be just as easy to withdraw consent as it was to give it.

Evidence: The withdrawal process and records showing that withdrawals were acted upon.

Do not use consent where it is not genuinely voluntary

For example, employees may not always be in a position to freely refuse consent because of the relationship between employer and employee.

Evidence: A review showing where consent is being used and whether it is genuinely appropriate.

________________________________________

3. Telling People How You Use Their Data

Relevant Articles: 12, 13 and 14

When you collect data directly from someone, you must inform them

Your privacy notice should explain the information required under Article 13, including:

• Who you are.

• DPO details, where applicable.

• Why you use the data.

• Legal basis.

• Legitimate interests, where applicable.

• Who receives the data.

• International transfers and safeguards.

• Retention periods.

• Individual rights.

• Right to withdraw consent.

• Right to complain.

• Whether providing the data is mandatory.

• Automated decision-making, including meaningful information about how it works.

Evidence: The actual privacy notice provided to people.

When you obtain data from another source, you must inform the person

Generally, the person must be informed within one month or earlier, such as at the first communication, depending on the circumstances.

Evidence: Article 14 privacy notice, including the source and categories of data, plus evidence showing when it was provided.

Privacy notices must be easy to understand

They should be:

• Clear.

• Concise.

• Easy to find.

• Written in plain language.

Evidence: The actual version of the privacy notice being used.

Keep previous versions of your privacy notices

You should be able to identify what privacy information a person was shown at the time their data was collected.

Evidence: Version history with dates.

________________________________________

4. Respecting People's Data Rights

Relevant Articles: 12, 15–22

People have the right to access their data

They should be able to obtain their personal data and relevant information about how it is being used.

Evidence: A documented request process, appropriate identity checks, request records and sample responses.

Your search must cover all relevant systems

When responding to an access request, you may need to search:

• Databases.

• Email.

• Customer support systems.

• Ticketing systems.

• Backups.

• Analytics platforms.

• Third-party systems.

Evidence: A record of the systems that were searched.

Searching only the main database may not be enough.

People can ask for incorrect data to be corrected

They can ask you to correct inaccurate or incomplete information.

Evidence: Correction records.

People may have the right to have their data deleted

Where the right applies, you must delete the relevant personal data.

Evidence: Records showing what was deleted and where, including relevant downstream systems and backups where applicable.

If you refuse a deletion request, record the specific legal reason.

People can ask you to restrict processing

Instead of deleting data, an individual may have the right to ask you to stop or limit its use.

Evidence: Restriction records and evidence showing how the restriction is applied in your systems.

You may need to inform other organisations

If you have shared someone's data with others, you may need to inform those recipients when the data is corrected, deleted or restricted.

Evidence: Records showing that recipients were notified.

Data portability may apply

In certain situations, people have the right to receive their data in a structured, commonly used and machine-readable format.

Evidence: Portability requests and the format in which data was provided.

People can object to processing

People may have the right to object to certain processing activities.

For direct marketing, an objection must be respected.

Evidence: Objection records and a suppression system that prevents further marketing across relevant channels.

You must identify significant automated decisions

If a decision is made entirely by automated means and has legal or similarly significant effects on a person, you must identify it and apply the required safeguards.

Evidence: Identified activities, legal basis, safeguards and human-review arrangements.

Human review must be genuine

If you say a person can review an automated decision, the person must actually have meaningful authority to review or change the decision.

Evidence: Review times, override rates and examples where human reviewers reached a different decision.

Requests normally need to be answered within one month

You must track response deadlines carefully.

If an extension is permitted, it must be properly justified and communicated within the required period.

Evidence: Your request register showing response dates and any extensions.

Requests should normally be free

You generally cannot charge a fee unless the request is legally considered unfounded, excessive or otherwise falls within an applicable exception.

Evidence: Records supporting any fee or refusal decision.

________________________________________

5. Privacy by Design and Keeping Data Only as Long as Needed

Relevant Articles: 5, 25, 35 and 36

Privacy should be considered from the beginning

When developing a new product, service, system or process, privacy should be considered during the design stage — not after everything has been built.

Evidence: Privacy requirements included in project, design and procurement processes.

Privacy should be the default

Systems should normally be configured to use:

• Only the data that is needed.

• Limited sharing.

• Appropriate access.

• Limited visibility.

Evidence: Default system configuration and access settings.

You must know when a DPIA is required

A Data Protection Impact Assessment (DPIA) is required for certain high-risk processing activities.

Evidence: DPIA screening criteria and completed DPIAs where required.

A DPIA should properly assess the risks

It should consider:

• What processing is being performed.

• Whether it is necessary.

• Whether it is proportionate.

• Risks to individuals.

• Measures used to reduce those risks.

Where appropriate, advice from the DPO and views of affected people should also be considered.

High remaining risk may require regulator consultation

If significant risk remains after safeguards are applied, you may need to consult the relevant supervisory authority before processing begins.

Evidence: Consultation records, where applicable.

Only collect data that you actually need

Do not collect personal information simply because it might be useful later.

Evidence: Reviews of forms, fields and databases demonstrating data minimisation.

You must define retention periods

You need to know:

• How long each category of data is kept.

• Why it is kept for that period.

• What happens when the retention period ends.

Evidence: Retention schedule and proof of actual deletion or anonymisation.

This should also consider backups, archives, emails and test environments where applicable.

Anonymised data must genuinely be anonymous

If you call data “anonymous,” people should not reasonably be identifiable from it.

Evidence: The anonymisation method and assessment.

Pseudonymised data is still personal data and remains subject to GDPR.

________________________________________

6. Security and Data Breaches

Relevant Articles: 28, 32, 33 and 34

Security measures must match the level of risk

You must have appropriate technical and organisational security measures and document them.

These may include:

• Encryption.

• Pseudonymisation.

• Confidentiality controls.

• Integrity controls.

• Availability and resilience.

• Disaster recovery and restoration capabilities.

Evidence: Security measures linked to identified risks.

Security controls must be tested regularly

It is not enough to simply have security controls. You should test whether they actually work.

Evidence: Examples include:

• Penetration tests.

• Vulnerability assessments.

• Backup restoration tests.

• Security testing records.

You must be able to detect and report breaches

Employees and processors should know how to report a suspected personal data breach.

Evidence: Breach detection arrangements and reporting procedures.

Certain breaches must be reported within 72 hours

Where the GDPR reporting threshold is met, the supervisory authority generally needs to be notified within 72 hours after becoming aware of the breach.

Evidence: Notification records and timestamps.

You should not necessarily wait until every detail is known before beginning the notification process.

Every breach must be recorded

Even breaches that are not reported to the regulator must generally be documented internally.

Evidence: Breach register showing:

• What happened.

• The impact.

• Actions taken to address the issue.

High-risk breaches may need to be communicated to individuals

If a breach creates a high risk to people, they may need to be informed without unnecessary delay and in clear language.

Evidence: Copies of communications, dates and the reasoning behind any decision not to notify.

Processor contracts must meet Article 28 requirements

If another organisation processes personal data for you, your contract should address the required areas, including:

• Documented instructions.

• Confidentiality.

• Security.

• Sub-processors.

• Assistance with data subject rights.

• Assistance with breaches.

• Data deletion or return.

• Audit rights.

Evidence: Processor agreement reviewed against Article 28 requirements.

Check processors before appointing them

A signed contract alone does not prove that the processor is suitable.

Evidence: Due diligence records.

Sub-processors must also be controlled

You should know who your processors use and ensure appropriate authorisation and contractual protections exist.

Evidence:

• Sub-processor list.

• Authorisation records.

• Change notifications.

• Objection records.

• Relevant contracts.

Joint controllers need a clear arrangement

If two organisations jointly decide how and why personal data is processed, they should document their respective responsibilities.

The essential information should also be made available to individuals.

Evidence: Joint controller agreement and published explanation.

________________________________________

7. Sending Personal Data Outside the EEA

Relevant Chapter: Chapter V and Article 49

Know where your data is going

You should identify all transfers of personal data outside the EEA.

This should include:

• Service providers.

• Cloud hosting locations.

• Support access.

• Sub-processors.

• Other international access arrangements.

Evidence: International transfer register showing the destination, recipient and transfer mechanism.

Every international transfer needs an appropriate legal mechanism

For example, this may involve an adequacy decision or appropriate contractual safeguards such as Standard Contractual Clauses, where applicable.

Evidence: Current adequacy decision information or completed contractual safeguards.

Assess the laws of the destination country

You should consider whether the laws of the destination country could undermine the protection provided by your transfer mechanism.

Evidence: A documented Transfer Impact Assessment for relevant transfers.

Additional safeguards may be needed

Where the normal safeguards are not enough, additional technical, contractual or organisational measures may be required.

For example, stronger encryption arrangements may be used where appropriate.

Evidence: Documented additional safeguards and decisions taken.

Derogations should not become a routine transfer method

Where you rely on a GDPR derogation for an international transfer, the conditions must genuinely be met. Derogations are generally not intended to support routine, repeated transfers.

Evidence: Documentation showing why the specific derogation applies.

________________________________________

8. Governance and Proving Compliance

Relevant Articles: 5, 31, 37, 38, 42 and 83

Determine whether you need a Data Protection Officer

You should assess whether your organisation falls into one of the situations where GDPR requires a DPO.

Evidence: A documented DPO assessment.

If you have a DPO, they must be able to work independently

The DPO should have appropriate access to senior management and should not be improperly instructed about how to perform their duties.

You should also check for conflicts of interest.

Evidence:

• Reporting structure.

• Independence arrangements.

• Conflict-of-interest assessment.

The DPO should be involved early

Where a DPO is required, they should be involved in matters that affect personal data from an appropriate early stage.

They should also have the resources needed to perform their role.

Evidence: Project records, meeting records and other evidence of DPO involvement.

You must be able to prove compliance

GDPR is not simply about having policies.

You should be able to demonstrate that your organisation actually follows them.

Evidence may include:

• Approved policies.

• Review dates.

• Training records.

• Staff and contractor training.

• Governance meeting minutes.

• Internal audits.

• Compliance monitoring.

• Corrective actions and closure records.

Be careful when claiming GDPR certification

If an organisation claims to have GDPR certification under Article 42, the certification should actually be based on an approved GDPR certification scheme and appropriate certification arrangements.

Evidence: Relevant approved scheme and certification body details.

If you do not make such claims, document this as not applicable.

Be ready to cooperate with regulators

You should be able to respond efficiently if a supervisory authority contacts you.

Evidence:

• Complaints process.

• Identified lead supervisory authority, where applicable.

• Regulatory correspondence register.

• Organised evidence that can be provided quickly.

Senior management should understand the potential financial exposure

Management should understand the possible consequences of non-compliance.

Under GDPR, certain infringements can result in administrative fines of up to €20 million or 4% of worldwide annual turnover, whichever is higher, depending on the infringement.

Evidence: Records showing that senior management or the board has been informed.

________________________________________

How to Use This Document

This document is not asking you to create a huge collection of manuals, templates and files.

The real requirement is to show that your organisation:

1. Made the right decisions deliberately.

2. Documented those decisions.

3. Implemented what was decided.

4. Can provide evidence when asked.

5. Reviews and updates the system when circumstances change.

The goal is not to create hundreds of pages of documentation.

More documents do not automatically mean better compliance.

A long procedure that nobody follows can actually create a bigger problem because an auditor may identify the difference between what the procedure says and what people actually do.

The important test is simple:

Does the person responsible for the task recognise their actual work in the documented process?

A good GDPR system is therefore not about having the most paperwork. It is about having clear decisions, practical controls, real implementation and reliable evidence.