Do we need to comply with GDPR if we are not based in Europe? That is the question most founders and product leads are actually searching for — and the answer is almost certainly yes, if any of your users are in the EU or UK. GDPR applies based on where your users are located, not where your company is incorporated. A SaaS company in Austin, a mobile app built in Bangalore, a B2B platform headquartered in Singapore — if EU residents are using your product, you are in scope. The question is not whether GDPR applies to you; it is how to build your product so that compliance is a feature rather than a fire drill.
Start With Data Mapping — Before Anything Else
You cannot protect data you do not know you have. The first practical step in GDPR compliance for software companies is building a data map (formally called a Record of Processing Activities, or RoPA). This is not a spreadsheet project for your legal team — it is an engineering and product exercise.
For every category of personal data your product handles, document:
- What data you collect (email, name, IP address, behavioural events, payment details, etc.)
- Why you collect it (the lawful basis — more on that below)
- Where it is stored (which database, which cloud region, which third-party services receive it)
- How long you retain it
- Who has access to it, internally and externally
- Whether it crosses borders (EU data stored on US servers requires additional safeguards)
This exercise typically surfaces surprises: analytics SDKs sending event data to US servers, support tools storing conversation history indefinitely, old staging environments containing production user data from a migration two years ago. Those surprises are your priority list.
Lawful Basis: You Need One for Everything
GDPR does not prohibit processing personal data — it requires a documented lawful basis for each processing activity. The six lawful bases are often oversimplified in compliance guides, but these are the ones that matter most for software products:
Consent
Freely given, specific, informed and unambiguous. Pre-ticked boxes are invalid. Bundled consent ("by signing up you agree to everything") is invalid. Consent must be withdrawable as easily as it was given. Consent is appropriate for marketing emails, optional analytics and personalisation features. It is not the right basis for processing necessary to deliver your core service.
Contractual necessity
Processing that is genuinely necessary to deliver the service the user signed up for. If a user creates an account to use your SaaS product, storing their email and name is contractually necessary. This is the cleanest basis for core product functionality.
Legitimate interests
A flexible basis that requires a documented balancing test — your interest in processing the data weighed against the data subject's rights. Often used for fraud prevention, security logging and certain analytics. Not a catch-all; you need to document the balancing test.
Avoid defaulting to consent for everything — it creates operational overhead (consent records, withdrawal flows) and can be revoked, breaking functionality users depend on. Match the basis to the purpose.
Consent Management in Practice
For processing that requires consent — primarily marketing and optional analytics — your implementation needs to be more deliberate than a cookie banner your users click through in two seconds to make it disappear.
- Granular consent: Give users separate controls for different purposes. "Accept all" is fine as an option; it should not be the only option.
- Consent records: Log what the user consented to, when, and what version of your privacy notice was shown at the time. You may need to prove consent in a regulator inquiry.
- Withdrawal flows: Unsubscribing from marketing should work in one click. Withdrawing analytics consent should immediately stop tracking — not batch it for the next daily job.
- Re-consent on material changes: If you change what you do with data, you need fresh consent for activities that depend on it.
Handling Data Subject Access Requests (DSARs)
Under GDPR, individuals can ask you what data you hold about them, request corrections, ask for deletion ("right to be forgotten"), or request a portable export. You have 30 days to respond. At scale, doing this manually is not sustainable.
Build DSAR handling into your product early:
- Data inventory completeness: You can only fulfil DSARs accurately if your data map is current. An incomplete map leads to incomplete responses, which is itself a compliance failure.
- Identity verification: You must verify the requester is who they say they are before releasing or deleting data. Build an identity verification step into your DSAR intake process — usually email verification plus, for sensitive data, a second factor.
- Deletion cascade: "Right to be forgotten" requests require deleting data across your entire stack — primary database, analytics events, backups, data warehouse, third-party integrations. If your analytics platform receives a user ID, you need a way to submit a deletion request to them too. Map this out before you receive the first request.
- Portability export: Build a data export feature. This is a good product feature anyway (it reduces lock-in anxiety) and satisfies portability obligations simultaneously.
| DSAR Type | GDPR Article | Deadline | What you need to build |
|---|---|---|---|
| Access request | Article 15 | 30 days | Data export across all systems, readable format |
| Rectification | Article 16 | 30 days | Self-service profile editing or manual correction flow |
| Erasure | Article 17 | 30 days | Deletion cascade across all data stores and processors |
| Portability | Article 20 | 30 days | Machine-readable export (JSON or CSV) of user data |
| Restriction of processing | Article 18 | Immediate | Flag-based processing suspension per user |
Privacy by Design: Engineering It In, Not Bolting It On
Privacy by Design is an explicit GDPR requirement (Article 25), not just a philosophy. In practice for software teams, it means a checklist of architectural decisions that need to happen before code is written, not after a privacy audit:
- Data minimisation: Collect only what you need for the documented purpose. If you are building a task manager, you do not need date of birth. If you are building a booking system, you do not need to store the full credit card number post-authorisation.
- Pseudonymisation: Replace direct identifiers with pseudonymous tokens in analytics and logs. Your event analytics can tell you what users do without needing their real email in every event record.
- Default to private: New user accounts should default to the most restrictive privacy settings. Opt-in to sharing, not opt-out.
- Access controls: Limit internal access to personal data on a need-to-know basis. Your customer support team does not need read access to payment history; your data analysts do not need access to unmasked email addresses.
- Retention schedules: Define retention periods for every data category and implement automated deletion. Keeping data indefinitely "just in case" is not a lawful basis.
Third-Party Processors and Data Transfer Agreements
Every third-party service you integrate — Stripe, Intercom, Mixpanel, your cloud infrastructure provider — is a data processor if they receive personal data from your product. GDPR requires a Data Processing Agreement (DPA) with each processor. Most established vendors provide standard DPAs; you just need to execute them. Where data crosses from the EU to the UK (post-Brexit), US, India or other jurisdictions, you need additional transfer mechanisms — Standard Contractual Clauses (SCCs) are the most practical option for most companies.
Building software with EU users for clients? The teams at Mexilet Technologies routinely implement privacy-by-design patterns as part of product development — because retrofitting data architecture after growth is always more expensive than building it correctly the first time.
Frequently Asked Questions
Does GDPR apply to B2B SaaS where our customers are businesses, not individuals?
Yes, if your product processes personal data of individuals — even if those individuals are your customers' employees or end users. B2B does not mean GDPR exempt. If your platform stores contact names, email addresses, usage logs or behavioural data tied to identifiable people, GDPR applies. You are typically a data processor (your customer is the controller), which means you need DPAs in place with your customers and need to be able to support their obligations to their own users.
What counts as personal data under GDPR?
More than most developers assume. Name and email are obvious. IP addresses, device IDs, cookie identifiers, precise geolocation, behavioural event streams tied to a user ID, and even pseudonymous data that could be re-linked to a real person all qualify. Truly anonymised data is out of scope, but genuine anonymisation is technically harder than it sounds — aggregated data with small group sizes can still be re-identified.
How big does our company need to be before GDPR matters?
There is no size exemption. A solo founder with 500 EU users is in scope. The practical difference for small companies is that most regulators focus enforcement on larger, more egregious violations — but that is a risk tolerance decision, not a legal one. Companies under 250 employees have a limited exemption from maintaining formal written records of processing activities, but only for non-systematic or occasional processing. Regular product data collection is not occasional.
What happens if we get a GDPR fine?
Fines are tiered. Less severe violations (administrative failures like incomplete records) can attract fines up to €10 million or 2% of global annual turnover, whichever is higher. More serious violations (unlawful processing, insufficient consent, failure to honour rights) can reach €20 million or 4% of global turnover. In practice, the large headline fines go to large companies with systemic failures. Smaller companies more commonly face regulatory investigations, corrective orders and reputational damage — which are expensive in their own right even without a financial penalty.
If you'd rather not build it alone, see our cybersecurity services and secure cloud & DevOps.
GDPR compliance is not a one-time checkbox — it is an ongoing engineering and operational commitment. If you want a clear picture of what it would actually cost and take to build compliant data handling into your product, request a tailored estimate from the Mexilet team. We will map out the technical work against your specific architecture and give you a realistic scope before any engagement begins.