GDPR for SMBs: Why You Are Subject

If your small business handles personal data and touches anyone in the EU, the GDPR applies to you — regardless of where you are or how small you are. Maximum fines reach €20 million or 4% of worldwide turnover. Here is what a one- to three-person IT team must know.

The General Data Protection Regulation (GDPR) is the EU’s comprehensive privacy law, in force since 25 May 2018. Its purpose is to give individuals — "data subjects" — control over how their personal data is collected, processed, stored, and disclosed. Personal data is defined broadly: names, IP addresses, email addresses, phone numbers, anything relating to an identified or identifiable person.

A common reaction from small and non-EU businesses is "that doesn’t apply to us." It usually does. This article covers what an SMB IT admin needs: the three triggers that make you subject, the principles and lawful bases you must process under, the rights you must honor, the 72-hour breach clock, the record you must keep, and a 90-day readiness plan.

Why an SMB should care: controllers, processors, and fines

The GDPR binds both controllers (entities that decide the purpose and means of processing) and processors (entities that process data on a controller’s behalf). Most SMBs are controllers for their customer and employee data, and processors when they handle a client’s data — sometimes both.

The financial exposure is real. Maximum fines reach €20 million or 4% of a company’s total annual worldwide turnover, whichever is higher. Data subjects can also claim compensation for material or non-material damages. For a small business, a single serious infringement is an existential event, not a line item.

Article 3: the three triggers that make a non-EU SMB subject

The GDPR is not limited to companies physically in Europe. Its territorial scope is triggered in three circumstances:

1. Establishment in the EU — a controller or processor established in the EU is covered, regardless of where the actual processing happens.
2. Offering goods or services to EU data subjects — even with no EU establishment, you are covered if you process personal data relating to offering goods or services to people in the EU.
3. Monitoring the behavior of EU data subjects — non-EU organizations are covered if their processing relates to monitoring the behavior of people in the EU.

The line is "intent to target or monitor," not mere accessibility. A public website that Europeans can happen to reach is not enough. But if your site uses European languages, prices in Euros, actively recruits EU customers, or tracks the online behavior of EU visitors, you are bound by the GDPR. For a North American SMB with a EU-facing checkout or a EU-visitor analytics script, that is already the case.

Article 5: the seven principles, and Article 6: the six lawful bases

Every processing activity must satisfy the seven data-protection principles:

1. Lawfulness, fairness and transparency — a valid legal basis, reasonable handling, and transparency about what is collected, why, and for how long.
2. Purpose limitation — data collected for specified, explicit, legitimate purposes, not reused incompatibly.
3. Data minimisation — adequate, relevant, limited to what is strictly necessary.
4. Accuracy — accurate and kept up to date; inaccurate data rectified or deleted without delay.
5. Storage limitation — kept no longer than necessary.
6. Integrity and confidentiality — appropriate security against unauthorized processing, loss, destruction, or damage.
7. Accountability — the controller must be able to demonstrate compliance.

Each processing activity also needs one of six lawful bases: consent; performance of a contract; compliance with a legal obligation; protection of vital interest; legitimate interest (which must not override the individual’s rights); or public interest / official authority. Write the basis down per activity — "we need it" is not a lawful basis.

Data-subject rights and the 72-hour breach clock

The GDPR grants eight rights you must build workflows to support:

• Right to be informed — who collects the data, why, how long it is kept.
• Right of access — a free copy of their data and supplementary information, provided within one month.
• Right to rectification — correction of inaccurate or incomplete data.
• Right to erasure ("right to be forgotten") — deletion when the data is no longer necessary, consent is withdrawn, or processing was unlawful.
• Right to restrict processing — temporary limitation, for example while accuracy is contested.
• Right to data portability — their data in a structured, machine-readable format to move to another system.
• Right to object — stop processing, notably for direct marketing.
• Rights related to automated decision-making and profiling — not to be subject to decisions made without human involvement that have legal effects.

The breach clock is the part that hits IT hardest. Under Article 33, a controller must notify the supervisory authority without delay, and no later than 72 hours after becoming aware of a personal-data breach, unless the breach is unlikely to risk individuals’ rights. A workable SMB response process is five steps:

1. Detection and escalation — anyone or any system that detects an incident notifies the controller/admin immediately.
2. Severity assessment — evaluate the scope, the data accessed, and the consequences for individuals.
3. Authority notification — if there is a risk, notify the supervisory authority within 72 hours; if delayed, document the justification.
4. Subject notification — if the breach is high-risk to individuals, notify the affected data subjects without undue delay.
5. Documentation — record mitigation steps, scope, and lessons learned.

<!– block-cluster-cta –>

Article 30: the Record of Processing Activities (RoPA)

Article 30 requires you to document your processing activities. Even for a small business, this record is what lets you answer a data-subject request and prove accountability. A minimal RoPA — a spreadsheet is fine — needs one row per processing activity with these fields:

• Data category collected — what personal data (email, IP address, health data, etc.).
• Purpose of collection — why (billing, marketing, support).
• Lawful basis — consent, contract, legitimate interest, etc.
• Data location and recipients — where it is stored and who it is shared with.
• Retention period — exactly how long it is kept before deletion.
• Security safeguards — the technical and organizational measures (encryption, access controls).

Three pitfalls to avoid

1. Assuming GDPR does not apply because you are non-EU or under 250 employees. Size and location do not exempt you if you target or monitor EU users. The under-250-employee documentation exemption does not apply if your processing is frequent (not occasional), poses a risk to individuals, or involves special categories of sensitive data like health records or racial origin. Run a data-mapping exercise to find out whether you touch EU data.
2. Keeping no RoPA. Skipping documentation because you are busy is how you fail a subject access request. Write a short internal procedure that explains how, why, and for how long personal data is stored, and maintain the simple RoPA above.
3. Ignoring Article 32 (security of processing). Collecting data without technical guardrails violates "data protection by design and by default." Collect only what is necessary for a specific purpose, encrypt personal data, enforce strict access control, ensure you can restore access after an incident, and routinely test that these measures work.

Your first 90 days

A solo admin can build GDPR readiness in a phased 90-day plan:

Days 1–30 — Discovery and mapping. Audit and document every category of personal data you collect, where it is stored, and how it is used. Assess jurisdiction: review website traffic, customer lists, and marketing targets to determine whether you monitor or offer services to EU individuals. List every third-party processor (cloud storage, marketing tools) and review their security posture.

Days 31–60 — Documentation and policies. Build the RoPA from your data-mapping results. Assign a lawful basis to every data category. Update external privacy notices so they clearly state what is collected, why, the retention period, and the user’s rights. Draft a standard internal procedure for handling data-subject requests within the one-month deadline.

Days 61–90 — Technical controls and incident response. Implement Privacy by Design — data encryption, network segregation, strict identity and access management, and data minimisation enforced system-wide. Formalize a breach-response plan that lets you detect, assess, and notify within the 72-hour window. If you use new technologies, geo-tracking, or high-risk processing, run a Data Protection Impact Assessment (DPIA) first. Roll out brief awareness training so staff can spot and escalate a breach.

CTA

GDPR for an SMB is not a legal maze. It is knowing whether Article 3 catches you, writing a RoPA, and standing up a 72-hour breach response. Book a 30-minute GDPR applicability assessment, or download the complete GDPR for SMBs readiness guide.

Sources

• GDPR consolidated practical summary (EPSU) — GDPR definition and in-force date, controller/processor obligations, maximum fines (€20M / 4% worldwide turnover) and compensation, Article 5 seven principles, Article 6 six lawful bases, Article 30 RoPA contents, Article 32 security of processing, the data-breach definition and response process, and the 90-day control set.
• Plain-language GDPR guide (ICO-style, fs-privacy-gdpr) — the broad definition of personal data, the controller/processor distinction, the Article 3 "intent to target or monitor" test for non-EU businesses (European languages, Euro pricing, EU-customer recruitment, behavior tracking), the RoPA fields, and the data-subject rights.
• GDPR for SMBs brief (canon) — the jurisdiction and data-mapping framing for the non-EU applicability question.
• ISO/IEC 27001:2022 — the technical security measures that underpin Article 32 and breach-response documentation.