Does GDPR apply to your SaaS?
Find the real scope before you build the wrong thing.
Most teams do not need another GDPR explainer. They need a clear answer to four questions: does GDPR apply, why, which role do we play, and what engineering obligations follow from that role. This is that version.
The expensive mistake is starting with compliance work before you know whether GDPR applies.
Teams usually meet GDPR in one of two bad ways. Either procurement asks for a GDPR answer and nobody knows whether the product is actually in scope, or someone assumes GDPR applies everywhere and pushes engineering into weeks of work before anyone has answered the territorial and role questions.
RuleMesh takes the opposite approach. Start with scope. Then determine role. Then determine risk. Only then translate the answer into implementation work.
There are four decisions that matter first.
- check_circleDo you process personal data at all?If the system never touches personal data, the rest of the conversation usually ends there.
- check_circleDo any territorial triggers apply?EU establishment, offering goods or services into the EU/EEA, or monitoring behaviour inside the EU/EEA.
- check_circleAre you a controller, processor, or joint controller?That choice changes the obligations, evidence, and contract posture you need.
- check_circleHow risky is the processing pattern?Special-category data, automated decisions, large-scale processing, and children's data change the implementation burden fast.
Applicability is not only about geography.
For SaaS teams outside Europe, the common mistake is to treat GDPR as a location question. It is not only that. Article 3 pulls non-EU companies into scope when they target EU users or monitor their behaviour. For product teams, that usually means signup flows, pricing pages, analytics, cookies, ad targeting, or customer references matter as much as server location.
The second mistake is to stop at “GDPR applies” without determining role. Controllers own lawful basis, transparency, rights handling, and privacy-by-design decisions. Processors inherit a different shape of work: controller instructions, Article 28 terms, security, logging, and escalation.
A good applicability check should change what engineering builds next.
- 01If GDPR likely does not applyYou avoid premature compliance work, but keep a clean record of why. Useful when expansion or EU go-to-market is still on the roadmap.
- 02If GDPR likely applies and you are a controllerThe next work usually lands in lawful basis mapping, transparency notices, rights handling, retention, Article 32 security work, and accountability evidence.
- 03If GDPR likely applies and you are a processorThe next work usually lands in Article 28 contract posture, security, logging, controller-instruction handling, and breach escalation.
- 04If the risk tier is highDPIA workflow, special-category handling, DPO assessment, and stronger evidence requirements move to the front of the queue.
The output should not end at a label. It should route into implementation.
A real applicability result should not stop at “yes” or “no.” It should tell the team what role they likely play, what obligations flow from that role, which risk signals are present, and what engineering guides or reports to read next. That is why the RuleMesh checker links straight into the developer guide, the SaaS engineering checklist, the Article 27 explainer, and the data-transfer report.
Related resources
Run the checker on your own facts.
Public, structured, citation-backed triage for SaaS and engineering-led teams. No account required.