How to adapt my company to the GDPR: a step-by-step guide

Q: Where do I start adapting my company to the GDPR?

With the data inventory. Before drafting a single clause or buying a template, you need to know what personal data the company processes, about which people, for what purpose and who handles it. That inventory is the foundation on which everything else is built: the Record of Processing Activities (art. 30 GDPR), the legal bases (art. 6), the security measures (art. 32) and the information to the data subject (art. 13 and 14). Adapting a company well is not filling in generic documents, but analysing the specific activity it carries out.

Adapting a company to the GDPR is not buying a pack of documents and filing them away. It is a process that runs through the whole activity of the business: knowing what data you process, why you may process it, how you protect it, what you tell the person it belongs to and what you do when something goes wrong. This guide orders that process into nine steps, each with its legal basis, so you can see the full path of GDPR adaptation for an SME or a self-employed professional, without shortcuts and without noise.

In 15 seconds

Adaptation is built on proactive accountability (art. 5.2 and 24 GDPR): nothing is notified in advance, but you must be able to demonstrate that you comply.
Start with the data inventory and continue with the legal bases (art. 6), not the other way around.
The documentation (RoPA under art. 30, information notices, art. 28 contracts) is a consequence of the analysis, not a substitute for it.
Adapting well means analysing your specific activity, not handing out identical templates to everyone.

Before getting into the steps, one idea that orders everything else: the GDPR does not work like a list of formalities you tick off and forget. It works like a system. Each step relies on the previous one —you cannot define your legal bases if you do not first know what data you process, nor draft a correct information notice if you have not fixed those bases— and all of them together sustain a single obligation: that the company knows what it does with the data and can prove it. Read them in order.

Step 1. Starting point: proactive accountability

Everything begins with a change in logic. The GDPR replaced the old model of notifying files in advance with that of proactive accountability (art. 5.2 and art. 24 GDPR): you no longer ask for permission or register anything beforehand, but you have to be able to demonstrate at any moment that you process the data in accordance with the regulation. The burden of proof shifts to the company. Adapting is, in essence, building that capacity to demonstrate.

And what has to be demonstrated is respect for the principles of art. 5 GDPR, which are the backbone of everything that follows:

Lawfulness, fairness and transparency: processing the data with a legal basis and in a way that is clear to the person affected.
Purpose limitation: collecting the data for specified purposes and not later using it for something incompatible.
Minimisation: asking only for the data you really need for that purpose, not one more.
Accuracy: keeping the data up to date and correcting anything inaccurate.
Storage limitation: not keeping the data longer than necessary.
Integrity and confidentiality: protecting it with appropriate security measures.

These principles are not decoration: they are the criterion against which every later decision is judged. Whenever you are in doubt in any of the following steps —whether you can keep a piece of data, for how long, for what— the answer almost always lies in going back to art. 5. If you want the full conceptual framework, start with what data protection is.

Step 2. Data inventory: what you process and how it is categorised

Before documenting anything, you have to look inward. The data inventory is the fieldwork that almost no one does and on which everything depends: going through the organisation and noting what personal data comes in, where it is stored, who handles it and where it goes out. Without this map, any later document will be a guess.

A key part of the inventory is to categorise what you find, because not all data carries the same weight in law:

Basic or common data: name, national ID, address, phone number, email, billing data, professional data. These are most of the data any business processes.
Special categories (art. 9 GDPR): data revealing racial or ethnic origin, political opinions, religious beliefs, trade union membership, health data, data concerning sex life, as well as genetic and biometric data used to identify a person. They are subject to reinforced protection and severe restrictions.

The distinction matters because it changes everything that comes after: the legal basis required, the security measures demanded and the risk level of the processing. Detecting that you process art. 9 data —many companies do it without realising, for example when managing sick leave for their staff— conditions the rest of the adaptation. To understand what falls into this category and how it is handled, see specially protected data: special categories.

Step 3. Legal bases: why you may process each piece of data

Processing data without a basis that legitimises it is processing it unlawfully. That is why, for each processing activity in the inventory from the previous step, you have to identify which of the bases in art. 6 GDPR it relies on. It is not a formality: it is what separates lawful processing from unlawful. The bases of art. 6 are:

Consent of the data subject.
Performance of a contract to which the data subject is a party.
Compliance with a legal obligation of the controller.
Protection of vital interests of the data subject or of another person.
Task carried out in the public interest or exercise of official authority.
Legitimate interest of the controller or a third party, provided the rights of the data subject do not override it.

A common mistake is to think that everything is legitimised by consent. It is not: managing the relationship with a customer normally relies on performance of the contract, and issuing invoices on a legal obligation. Consent is reserved for processing where no other basis fits, such as sending commercial communications. Choosing the wrong basis has knock-on consequences, because the information you give and the rights the person can exercise depend on it.

And there is a nuance that cannot fail: if in step 2 you detected special category data (art. 9), consent under art. 6 is not enough on its own. This data requires a dual basis: a legitimising basis under art. 6 and, in addition, one of the exceptions of art. 9.2 that lift the general prohibition on processing it. Both, at the same time. To go deeper into how the basis of each processing activity is defined and what happens when data is disclosed or communicated, see processing, disclosure and transfers of data.

Step 4. Documentation: RoPA, notices and processor contracts

With the inventory done and the bases defined, it is time to put it in writing. This is the part many confuse with "adapting to the GDPR", when in reality it is only the documentary reflection of the three previous steps. Three pieces concentrate the bulk of the documentation:

The Record of Processing Activities (art. 30 GDPR)

The RoPA is the document under art. 30 GDPR that inventories, processing by processing, what data you handle, for what purpose, about which people, for how long and with what security measures. It is the documentary heart of adaptation and the formal translation of the inventory from step 2. The belief that small companies are exempt is, in most cases, false. Here is the full guide to building it: Record of Processing Activities (RoPA): what it is and how to do it.

The information notices

These are the texts with which you inform the data subject at the moment you collect their data: on web forms, contracts, customer records or the footer of your emails. They are not generic: they must tell the truth about your purposes and your legal bases, the ones you set in step 3. Their specific content is detailed in step 6.

The processor contracts (art. 28 GDPR)

Every time a third party processes data on behalf of your company —the gestoría, the email provider, the cloud CRM, the IT maintenance firm— it acts as a data processor and art. 28 GDPR requires that relationship to be governed by contract. An important detail: when the relationship ends, the processor should not simply "destroy" the data, but return it or allow you to export it so that you can meet your own retention periods; destruction comes afterwards. Understand this figure properly in what the data processor is.

Step 5. Security and risks: proportionate measures

Documenting the data does not protect it; you have to defend it. Art. 32 GDPR requires you to apply technical and organisational measures proportionate to the risk of each processing activity. There is no closed, mandatory catalogue for everyone: an advisory firm that processes health data from sick leave needs more safeguards than a business that only keeps contact details. Proportionality is the rule.

In practice, these measures translate into day-to-day routines: role-based access control, individual passwords, device encryption, backups, screen locking, staff confidentiality duties and control of paper copies. Ordering all of this in a living document is the function of an information security policy.

When the analysis in step 2 reveals a processing activity likely to entail a high risk to people's rights and freedoms, art. 32 falls short and art. 35 GDPR comes into play: the Data Protection Impact Assessment (DPIA), a prior and deeper analysis of the risk and of how to mitigate it. Not all processing needs one, but identifying it in time is part of adapting well. Here is an explanation of when it applies: Data Protection Impact Assessment (DPIA).

Step 6. Duty to inform: transparency with the data subject

Transparency is a principle of art. 5 that takes shape in a very tangible obligation: informing the person of what you do with their data, before or at the moment of collecting it. The GDPR distinguishes two situations:

Art. 13 GDPR: when the data is obtained directly from the data subject (they fill in your form, sign your contract, give you their card).
Art. 14 GDPR: when the data is not obtained from the data subject, but from a third party or a publicly accessible source.

In both cases you have to communicate who you are, for what purpose and on what basis you process the data, to whom you disclose it, how long you keep it and how they can exercise their rights. A common misconception: the fact that a processing activity does not need consent —because it relies on the contract or a legal obligation— does not exempt you from the duty to inform. The privacy notice must be handed over all the same, at the first contact. The most visible expression of this duty is the website privacy policy; how to draft it is detailed in your company's website privacy policy.

Step 7. Data subjects' rights: a procedure to handle them

Adapting is not only being able to demonstrate what you do: it is being ready to respond when a person exercises their rights. The GDPR grants each data subject a set of rights (arts. 15 to 22 GDPR) and the company must have a procedure to handle them on time:

Access (art. 15): knowing what data of theirs you process and obtaining a copy.
Rectification (art. 16): correcting inaccurate or incomplete data.
Erasure (art. 17): the "right to be forgotten", with its limits.
Restriction of processing (art. 18): "freezing" the use of the data in certain cases.
Portability (art. 20): receiving the data in a structured format to take it to another controller.
Objection (art. 21): objecting to processing based on legitimate interest or to advertising.

This is where the circle closes with the previous steps: to respond to a right of access or erasure you need the RoPA from step 4, because it is the map that tells you where that person's data is and who holds it. A rights procedure with no inventory behind it is worthless. How to articulate the response to each one is explained in the rights of access, rectification, erasure and objection.

Step 8. Data Protection Officer: when one must be appointed

Not every organisation needs a Data Protection Officer (DPO), but they all must check whether it applies. The appointment is mandatory in the cases of art. 37 GDPR —essentially, when large-scale processing of data, regular and systematic monitoring of people, or the processing of special categories are part of the core of the activity— and in the additional cases listed in art. 34 LOPDGDD for certain entities in Spain.

This is orientative information: the obligation to appoint a DPO depends on the scale, volume and exact type of processing of each organisation, and each case requires an individual analysis. If you want to see the cases in detail and assess whether your activity fits, here is the reference: Data Protection Officer.

Step 9. Breach protocol: what to do when something fails

The last piece of an adapted company is the one that is triggered when the rest has not been enough. A security breach —a stolen laptop, ransomware, an email with data sent by mistake, unauthorised access— can happen to anyone, and what sets a prepared organisation apart is having a protocol ready before it happens.

The GDPR sets two obligations that are triggered by a breach:

Notification to the supervisory authority (art. 33 GDPR): unless the breach is unlikely to result in a risk to people's rights, it must be notified to the competent authority without undue delay and, where feasible, within a maximum of 72 hours of becoming aware of it.
Communication to the affected individuals (art. 34 GDPR): when the breach entails a high risk to their rights and freedoms, it must also be communicated to the people affected.

The 72 hours of art. 33 run from when the company becomes aware of the breach, not from when it decides to react. That is why the protocol has to be defined in advance: who detects, who decides, who notifies. Improvising it in the heat of the moment is the surest way to miss the deadline. The full procedure, step by step, is in security breach: what to do.

Summary table of the process

The nine steps, their essential content and the article where each one is developed:

Step	What it involves	Legal basis
1. Proactive accountability	Being able to demonstrate compliance and respect the principles of processing.	Art. 5.2 and 24 GDPR
2. Data inventory	Identifying what data you process and distinguishing basic data from special categories.	Art. 5 and 9 GDPR
3. Legal bases	Assigning each processing activity its basis; dual basis if there is art. 9 data.	Art. 6 (and 9.2) GDPR
4. Documentation	RoPA, information notices and processor contracts.	Art. 30 and 28 GDPR
5. Security and risks	Measures proportionate to the risk; DPIA if the risk is high.	Art. 32 and 35 GDPR
6. Duty to inform	Delivering the information to the data subject according to the source of the data.	Art. 13 and 14 GDPR
7. Data subjects' rights	Procedure to handle access, rectification, erasure, objection, etc.	Art. 15 to 22 GDPR
8. Data Protection Officer	Checking whether a DPO must be appointed (individual analysis).	Art. 37 GDPR and 34 LOPDGDD
9. Breach protocol	Notify the authority (72 h) and communicate to the affected individuals if the risk is high.	Art. 33 and 34 GDPR

"Adapting a company to the GDPR is not handing the same folder of templates to everyone. It is sitting down to look at what that business really does with the data and building the documentation from there. The first is a service; the second is a PDF that looks like the law but does not describe your company."

Mario P. Talamillo · Managing Partner, Certix®

Adaptation checklist

A quick list to place where your organisation stands. It does not replace individual analysis, but it helps to see the gaps:

☐ I understand the principle of proactive accountability and the principles of art. 5.
☐ I have made the inventory of the data my company processes.
☐ I have distinguished basic data from special categories (art. 9).
☐ Each processing activity has its legal basis identified (art. 6).
☐ If I process art. 9 data, I have also fixed its art. 9.2 basis (dual basis).
☐ I have the Record of Processing Activities (art. 30) and it reflects my real activity.
☐ My information notices are my own, not generic.
☐ I have processor contracts (art. 28) with all my providers that process data.
☐ My security measures are proportionate to the risk (art. 32).
☐ I have assessed whether any processing requires a DPIA (art. 35).
☐ I inform data subjects at the first contact (art. 13 and 14).
☐ I have a procedure to handle rights (arts. 15 to 22).
☐ I have checked whether I must appoint a DPO (art. 37 GDPR / 34 LOPDGDD).
☐ I have a breach protocol with the 72 h deadline in mind (art. 33 and 34).

Frequently asked questions

Where do I start adapting my company to the GDPR?

With the data inventory. Before drafting a clause or buying a template, you need to know what personal data the company processes, about which people, for what purpose and who handles it. That inventory is the foundation on which everything else is built: the RoPA (art. 30 GDPR), the legal bases (art. 6), the security measures (art. 32) and the information to the data subject (art. 13 and 14). Adapting a company well is not filling in generic documents, but analysing the specific activity it carries out.

How long does it take to adapt a company to the GDPR?

It depends on the size of the organisation and the complexity of its processing. Adaptation is not a formality that closes on a set date: the GDPR is built on proactive accountability (art. 5.2 and 24), which is an ongoing obligation. Part of the work is initial (inventory, documentation, notices), but keeping it consistent afterwards —when you change software, add a provider or open a new purpose— is permanent. That is why the question is not when it ends, but how it is sustained over time.

Is GDPR adaptation mandatory for the self-employed?

Yes. The GDPR and the LOPDGDD apply to anyone who processes personal data in the course of a professional or business activity, regardless of their legal form. A self-employed professional who manages a customer base, sends invoices or keeps contact details is processing personal data and must comply with the principles of art. 5, identify their legal bases (art. 6), inform data subjects (art. 13) and handle their rights (arts. 15 to 22). The volume is smaller than in a large company, but the obligation is exactly the same.

Is a generic template enough to adapt my company to the GDPR?

No, or at least not on its own. A template may serve as a formal starting point, but the GDPR requires the documentation to reflect the real processing of your organisation: your purposes, your legal bases, your providers, your retention periods. A Record of Processing Activities copied from another company describes an organisation that is not yours, and therefore breaches art. 30 even if it looks complete. Adapting well means analysing the specific activity, not handing out identical documents to everyone.

In summary

Adapting a company to the GDPR means going through, in order, these nine steps: understanding proactive accountability, inventorying the data, assigning legal bases, documenting, protecting, informing, handling rights, assessing the DPO and preparing the breach protocol. Each piece relies on the previous one and none stands on its own. The difference between a truly adapted company and one with a folder of nice documents comes down to a single point: whether those documents describe the real activity of the business or someone else's. The logical next step is an individual analysis of what your organisation really processes.