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 the supervisory authorities are actively enforcing 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.
2. Define Your Legal Bases Correctly
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, 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. Requires a three-part balancing test.
Documenting your chosen legal basis for each processing activity in your ROPA is not optional, it is a core accountability requirement and the first thing a supervisory authority will examine.
3. Embed Privacy by Design and by Default
Privacy by design and by default (Article 25) requires that data protection be integrated into your systems and processes from the outset, not added after the fact. In practice this means: involving your DPO or privacy lead during product planning, not after launch; collecting only the data you genuinely need for the stated purpose (data minimisation); applying the most privacy-protective settings by default; and conducting a Data Protection Impact Assessment (DPIA) before introducing high-risk processing.
Embedding privacy into your 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.
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 (Article 28). In practice this requires:
- A Data Processing Agreement (DPA) 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 your ROPA, documenting each processor, the data shared and the contractual basis.
- International transfer safeguards where processors are located outside the EEA, Standard Contractual Clauses (SCCs), adequacy decisions or other Article 46 mechanisms.
A data breach at one of your processors is your breach too. Vendor management is not an administrative formality, it is a material compliance and commercial risk. For more on managing international transfers, see our guide on privacy risks every SaaS founder overlooks.
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 (Article 15), rectification (Article 16), erasure (Article 17), restriction of processing (Article 18), data portability (Article 20) and objection (Article 21). These rights only work in practice if your organisation can respond to them 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 you track the deadline. Automate where possible. Do not forget edge cases, requests from former employees, requests for data held by processors on your behalf, or requests that appear to be fraudulent or vexatious (which the GDPR permits you to refuse or charge a reasonable fee for).
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. Your 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 your internal records under Article 33(5).
7. Train Your Whole Team
GDPR compliance is not a function of Legal or IT alone. Every team that handles personal data, Sales, Support, HR, Marketing, Engineering, has obligations. Article 39(1)(b) requires the DPO to raise awareness and train staff involved in processing operations. Article 5’s accountability principle requires you to be able to demonstrate that training has taken place.
Training should be role-based (what the sales team needs to know differs from what Engineering needs), periodic (at least annually, and when significant changes occur), and documented (attendance records, materials and evidence of completion). In Spain, this training can be fully or partially funded through FUNDAE, the state employment training fund. PrivaLex manages the full FUNDAE process so the training cost does not need to come from your compliance budget.
8. Review, Audit and Improve Continuously
The GDPR’s accountability principle (Article 5(2)) requires you to be able to demonstrate compliance at any time, not just 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 your programme current.
A periodic GDPR audit, internal or with an external partner, is the most reliable way to identify gaps before they become incidents or enforcement actions. An external DPO or privacy consultant can support this review without consuming your internal team’s time.
Common Mistakes to Avoid
Treating compliance as a one-time project
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.
Relying on consent for everything
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.
Not having signed DPAs with every processor
A data breach at a processor without a DPA in place is a direct GDPR violation by the controller. Supervisory authorities consistently find this as a gap in enforcement actions. Your vendor list should have a DPA status column.
Ignoring special category data in the ROPA
If your product or operations involve health data, biometric data, religious beliefs, political opinions, sexual orientation or genetic data, you are processing special category data under Article 9. This requires an explicit legal basis under Article 9(2) in addition to a lawful basis under Article 6, and significantly higher safeguards. Many organisations overlook this when their products handle health-adjacent or HR data.
How PrivaLex Can Help
At PrivaLex Partners we help organisations turn the GDPR from a compliance burden into a structured, auditable programme that builds trust with clients, partners and regulators. Our support covers the full implementation cycle: data mapping and ROPA development, legal basis analysis, privacy by design reviews, vendor contract management, staff training, GDPR audits, breach response preparation, and ongoing External DPO services for organisations that need continuous oversight.
Contact PrivaLex to discuss where your programme stands and what the next steps look like.
Frequently Asked Questions (FAQs)
Does the GDPR apply to my startup if we have fewer than 250 employees?
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.
What is the maximum fine for GDPR non-compliance?
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.
How long do we have to respond to a data subject access request?
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.
Does the GDPR require us to use Standard Contractual Clauses for all international transfers?
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.
What is privacy by design and is it mandatory?
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.
Next Step
GDPR compliance is not a destination, it is an ongoing programme. Whether you are starting from scratch, have a compliance framework that needs updating, or need ongoing support through an External DPO, PrivaLex can help you build something that is practical, auditable and proportionate to your risk profile. Book a call to get started.
