---
title: Practical GDPR for SMEs: the bare minimum you need in order
locale: en
url: https://bitora.es/en/blog/rgpd-practico-pyme/
---

# Practical GDPR for SMEs: the bare minimum you need in order

*2026-08-26*

Data processing agreements, data minimization and access logs, explained without legal jargon, for companies without an in-house legal team.

GDPR sounds like legal paperwork that only matters if there is an inspection. In practice, it is also a short list of concrete technical decisions that reduce real risk, and that many SMEs leave unresolved simply because nobody translated them into something actionable.

## First: the data processing agreement

If an outside provider processes your customers' personal data on your behalf (hosting, email marketing, a CRM, an AI agent), there needs to be a signed data processing agreement, not just a mention buried in terms of service nobody read. This document defines what that provider can do with the data, how long it keeps it, and what happens if there is a security breach.

> **Watch out:** a mention in the terms of service does not replace a signed data processing agreement.

## Minimization: collecting less is cheaper and safer

A simple principle that gets ignored constantly: you should only collect data you are actually going to use. A contact form that asks for date of birth "just in case" adds risk (more data to protect) with no real benefit. Less data also means lower storage cost and a smaller surface if an incident happens.

## Access logs: the part almost nobody has

If someone asks "who accessed this customer's data, and when?", most SMEs have no answer. A basic access log (who accessed what, and when) is not complex to implement, and it is exactly what you are asked to demonstrate in an inspection or when a customer exercises their right of access.

## The rights you need to be able to fulfill in practice

- **Access:** a customer should be able to request what data you hold on them, and you should be able to deliver it within a reasonable timeframe.
- **Rectification:** being able to correct a wrong piece of data without it staying duplicated across three different systems.
- **Erasure ("right to be forgotten"):** being able to actually delete a person's data, not just mark it inactive in a table that still exists.

If these three processes are not defined before someone requests them, the first real request becomes an improvised emergency.

## Where the data lives matters too

As we covered in another article on [where your data actually lives](/en/blog/donde-viven-tus-datos/), the physical location and real control of the server directly affect which law applies and who can demand access to that data. It is not a separate topic from GDPR: it is part of the same decision.

## How we do it at Bitora

When we build a system that handles personal data, we include field minimization, access logging and data processing agreements with any outside provider involved from the design stage. It is not a layer added at the end: it is part of how it gets built from day one.

If you are not sure where your current compliance stands, see the full approach on [business intelligence](/en/services/business-intelligence/).