These are the key topics covered in this guide:
- Start with a data inventory and map your processing activities
- Define your legal bases correctly, do not rely only on consent
- Embed privacy by design and by default
- Manage your vendors and processors properly
- Build a process to handle data subject rights requests
- Prepare a breach response procedure
- Train your whole team, not just Legal and IT
- Review, audit and improve continuously
- Common mistakes to avoid
- How PrivaLex can help
The GDPR has been directly applicable across the EU since May 2018. If your organisation processes personal data of individuals in the EU, compliance is not optional, and supervisory authorities actively enforce it. But knowing what the regulation requires and implementing it correctly in day-to-day operations are two different things. This guide covers the practical steps that make GDPR compliance real, not just documented.
1. Start with a data inventory and map your processing activities
You cannot protect data you do not know you have. The foundation of GDPR implementation is understanding what personal data you collect, where it is stored, who has access to it, for what purpose, and for how long. This is not a one-time exercise; it is the foundation of your Record of Processing Activities (ROPA), which Article 30 requires most controllers and processors to maintain.
Pay particular attention to shadow IT: tools and applications that teams use without going through IT procurement. These are common sources of undocumented personal-data processing. Map data flows across teams, tools, and vendors. The output of this exercise drives every other element of your compliance programme: legal bases, retention periods, data minimisation, vendor agreements, and risk assessments.
A small organisation should not assume it is automatically exempt from maintaining records. The Article 30 exemption is limited and may not apply where processing is not occasional, is likely to create risk, or involves special-category or criminal-offence data. Document the decision, keep the inventory current, and review it whenever a new tool, product, market, or vendor is introduced.
2. Define your legal bases correctly, do not rely only on consent
Many organisations default to consent as their legal basis for all processing. Consent is one of six lawful bases under Article 6 of the GDPR, but it is also the most fragile: it must be freely given, specific, informed, and unambiguous, and it can be withdrawn at any time. If you rely on consent for processing that is actually necessary for a contract or a legal obligation, you have created unnecessary complexity for no compliance benefit.
The six lawful bases are:
- Consent, Article 6(1)(a): appropriate for marketing communications, optional features, and non-essential cookies.
- Contract, Article 6(1)(b): processing necessary for the performance of a contract with the data subject or to take pre-contractual steps.
- Legal obligation, Article 6(1)(c): processing required to comply with a law applicable to the controller.
- Vital interests, Article 6(1)(d): processing necessary to protect someone’s life.
- Public task, Article 6(1)(e): processing in the exercise of official authority or in the public interest.
- Legitimate interests, Article 6(1)(f): processing necessary for the legitimate interests of the controller or a third party, where those interests are not overridden by the data subject’s rights.
Where legitimate interests are used, retain a documented Legitimate Interests Assessment that tests the purpose, necessity, and balance of interests. If the processing involves special-category data, such as health, biometric, genetic, or religious-belief data, an Article 6 lawful basis is not enough: a separate Article 9 condition is also required.
Documenting the chosen legal basis for each processing activity in the ROPA is an important part of accountability and gives the organisation a defensible explanation for why the processing takes place.
3. Embed privacy by design and by default
Privacy by design and by default, under Article 25, requires that data protection be integrated into systems and processes from the outset, not added after the fact. In practice, this means involving the DPO or privacy lead during product planning, not after launch; collecting only the data genuinely needed for the stated purpose; applying the most privacy-protective settings by default; and conducting a Data Protection Impact Assessment before introducing high-risk processing.
Embedding privacy into sprint cycles and product decision-making prevents costly remediation work later, speeds up audits, and builds user trust. Fixing privacy issues after a product is in production is consistently more expensive than building them in from the start.
Before a new product, feature, or significant system change goes live, use a short privacy gate. Confirm the purpose and legal basis, the minimum data needed, retention periods, access permissions, vendor involvement, international transfers, security measures, and whether a DPIA is required. This gives product, security, and privacy teams a clear point at which to identify issues before they become expensive to correct.
4. Manage your vendors and processors properly
Any third party that processes personal data on your behalf is a data processor under the GDPR. You are responsible for ensuring that every processor provides sufficient guarantees regarding their technical and organisational measures under Article 28. In practice this requires:
- A Data Processing Agreement with every processor, covering the subject matter, duration, nature, and purpose of processing; the type of personal data and categories of data subjects; and the processor’s obligations.
- Due diligence before onboarding new processors, reviewing their security measures, sub-processor arrangements, and compliance posture.
- An up-to-date vendor register as part of the ROPA, documenting each processor, the data shared, and the contractual basis.
- International-transfer safeguards where processors are located outside the EEA, including adequacy decisions, Standard Contractual Clauses, or other Article 46 mechanisms.
A data breach at one of your processors is still an incident your organisation must assess and manage. Vendor management is not an administrative formality; it is a material compliance and commercial risk. For more on managing international transfers, see this guide on privacy risks every SaaS founder overlooks.
A Data Processing Agreement does not by itself make an international transfer lawful. Where data is accessed from or transferred to a country outside the EEA, record the transfer mechanism, assess the circumstances of the transfer where required, and review whether supplementary safeguards are needed. Vendor reviews should also continue after onboarding, particularly when a provider changes its sub-processors, hosting arrangements, or security model.
5. Build a process to handle data subject rights requests
The GDPR grants individuals a set of rights over their personal data: the right to access under Article 15, rectification under Article 16, erasure under Article 17, restriction of processing under Article 18, data portability under Article 20, and objection under Article 21.
These rights only work in practice if the organisation can respond within one month of receipt. The deadline can be extended by a further two months for complex or numerous requests, but the data subject must be informed of the extension within the first month.
Document a clear internal procedure: who receives and logs requests, who is responsible for responding, how identity verification is handled, and how the deadline is tracked. Automate where possible. Do not forget edge cases: requests from former employees, data held by processors on your behalf, or requests that appear to be fraudulent or vexatious.
A reliable request workflow should record the date received, identity-verification outcome, request type, systems searched, relevant processors contacted, exemptions or redactions considered, approval of the response, and the date sent. The aim is not only to meet the deadline, but also to demonstrate a consistent and proportionate decision-making process.
6. Prepare a breach response procedure
Article 33 requires controllers to notify the supervisory authority of a personal-data breach within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to individuals. Where the breach is likely to result in a high risk to individuals, Article 34 additionally requires notification to the affected data subjects without undue delay.
Having a documented breach-response procedure before an incident occurs is the difference between a managed response and a chaotic one. The procedure should define how incidents are detected and reported internally, who makes the risk assessment, who notifies the supervisory authority and data subjects, what information must be included in the notification, and how the incident is documented for internal records under Article 33(5).
Processors must notify the controller without undue delay after becoming aware of a breach. Controllers should not wait until every fact is known before assessing whether notification is required: an initial notification can be made within the deadline and supplemented as the investigation develops. Every breach should be documented, including the reasoning where notification was not required, the containment steps taken, and the corrective actions introduced afterwards.
For additional practical guidance, see the European Data Protection Board’s breach guidance.
7. Train your whole team, not just Legal and IT
GDPR compliance is not a function of Legal or IT alone. Every team that handles personal data: Sales, Support, HR, Marketing, and Engineering has responsibilities. Article 39(1)(b) includes awareness-raising and training of staff involved in processing operations among the DPO’s tasks where a DPO is required.
Accountability means being able to show that privacy measures are appropriate and working in practice. Training is one of those measures, but it should be proportionate to each team’s role rather than a generic course delivered once and forgotten.
Training should be role-based: what the Sales team needs to know differs from what Engineering needs. It should also be refreshed when significant changes occur, such as a new tool, new product feature, incident, or updated process.
Annual refresher training can be a useful practical baseline, but it is not a universal legal timetable. Maintain attendance records, materials, completion evidence, and simple measures of understanding, such as short scenario exercises or quizzes.
In Spain, eligible privacy and cybersecurity training may be funded through FUNDAE, subject to the applicable conditions and the organisation’s available credit. PrivaLex can support the training and funding process where it is applicable.
8. Review, audit and improve continuously
The GDPR’s accountability principle under Article 5(2) requires organisations to demonstrate compliance at any time, not only when an audit is scheduled. That means treating GDPR implementation as a continuous programme, not a project with an end date. Technologies evolve, processing activities change, new vendors are onboarded, and the regulatory landscape shifts. Regular reviews keep the programme current.
A periodic GDPR audit, carried out internally or with an external partner, is a reliable way to identify gaps before they become incidents or enforcement actions. An external DPO or privacy consultant can support this review without consuming the internal team’s time.
Make the review measurable. Track whether the ROPA is current, DPIAs are completed where required, vendor agreements are in place, rights requests are answered on time, training is complete for relevant teams, and breach-response exercises have been tested. These indicators help management see whether the privacy programme is operating rather than simply existing on paper.
4 common mistakes to avoid
1. Treating GDPR implementation as a one-time exercise
The most damaging assumption in GDPR implementation is that you can complete it once and move on. Processing activities change, new regulations interact with the GDPR, supervisory-authority guidance evolves, and data breaches happen. Compliance requires ongoing maintenance.
2. Using consent as the default legal basis
Using consent as the default legal basis for processing that would more appropriately rely on contract or legitimate interests creates unnecessary obligations, more complex consent management, more withdrawal requests to handle, and a weaker legal basis that does not reflect the reality of the processing relationship.
3. Failing to manage processor risk
A data breach at a processor without a DPA in place is a direct GDPR risk for the controller. Vendor reviews should include the DPA status, data categories shared, relevant transfer safeguards, sub-processor arrangements, and a clear owner for follow-up actions.
4. Overlooking special-category data
If a product or operation involves health data, biometric data, religious beliefs, political opinions, sexual orientation, or genetic data, it may involve special-category data under Article 9. This requires an additional Article 9 condition alongside the Article 6 lawful basis and usually calls for stronger safeguards. Many organisations overlook this when their products handle health-adjacent or HR data.
How PrivaLex can help
PrivaLex Partners helps organisations turn GDPR compliance from a collection of isolated documents into a practical privacy programme that can be explained, evidenced, and maintained over time. The focus is on understanding how personal data actually moves through the business, then translating that reality into clear responsibilities, proportionate controls, and records that support accountability.
Its support can cover the full implementation journey: data mapping and ROPA development, legal-basis analysis, privacy-by-design reviews, DPIAs, vendor and Data Processing Agreement management, international-transfer safeguards, staff awareness, breach-response preparation, and GDPR audit readiness. Rather than applying generic templates, PrivaLex helps connect policies and procedures to the organisation’s products, systems, teams, and real decision-making processes.
For organisations that need continuing privacy oversight, PrivaLex can also provide External DPO services. This helps keep the programme current as new vendors, technologies, markets, or processing activities are introduced, while maintaining an independent point of view for reviews, internal questions, incidents, and regulatory changes.
The result is a GDPR programme designed not only to respond to an audit, but also to strengthen customer trust, support commercial due diligence, and give teams a clearer way to handle personal data responsibly.
Make GDPR part of everyday operations
Effective GDPR implementation is not about producing the most policies. It is about making good privacy decisions consistently: knowing which data is processed, why it is needed, who can access it, how vendors are controlled, and how the organisation responds when something changes or goes wrong.
When these controls are connected to everyday workflows and reviewed regularly, GDPR becomes a practical foundation for trust, product growth, and audit readiness, not a compliance project that only appears when a customer or regulator asks questions.
Contact PrivaLex to assess the current maturity of your GDPR programme and identify the most relevant next steps.
Frequently Asked Questions (FAQs)
Yes. The GDPR applies to any organisation that processes personal data of individuals in the EU, regardless of size. There is a limited exemption from the Article 30 ROPA obligation for organisations with fewer than 250 employees, but only for processing that is not likely to result in a risk to data subjects, is not carried out regularly, or does not involve special category or criminal data. For most startups, at least some processing activity is regular and systematic, so the exemption does not apply in full.
The GDPR provides for two tiers of fines. The higher tier, up to €20 million or 4% of total worldwide annual turnover, whichever is higher, applies to infringements of the core principles of processing, the conditions for consent, data subject rights, international transfer rules, and DPO obligations. The lower tier, up to €10 million or 2% of turnover, applies to other obligations such as record-keeping, security measures and breach notification. Supervisory authorities also have the power to issue warnings, reprimands, temporary or permanent processing bans, and to order rectification.
You must respond within one month of receipt of the request. This can be extended by a further two months where requests are complex or numerous, but you must inform the data subject of the extension and the reasons within the first month. You must respond free of charge unless the request is manifestly unfounded or excessive, in which case you may charge a reasonable fee or refuse to act on the request.
Not in all cases. Standard Contractual Clauses (SCCs) are one of several transfer mechanisms available under Article 46. Others include adequacy decisions (where the European Commission has determined that a third country provides an adequate level of protection, for example, the UK or Japan) and Binding Corporate Rules (BCRs) for intra-group transfers. Where a transfer mechanism exists, a Transfer Impact Assessment (TIA) is also recommended to verify that the mechanism is effective in practice given the legal environment of the destination country.
Privacy by design and by default is a legal obligation under Article 25, not a best practice. It requires controllers to implement appropriate technical and organisational measures to integrate data protection principles into processing activities, both at the time of designing the processing and at the time of the processing itself. In practice this means: data minimisation by default, access controls, encryption where appropriate, and ensuring that the most privacy-protective options are the default settings in your products.
