Start by mapping EU-facing data flows, behavior tracking, platform functions, and AI usage, then assign owners for each decision area. Check whether GDPR Article 3(2) applies, keep an Article 30 record current, and confirm with counsel if Article 27 representation is required for your non-EU setup. In parallel, decide whether OSS fits your VAT model for eligible cross-border activity. Use one rule throughout: do not publish or negotiate any compliance claim unless a dated supporting document already exists.
Before you sell into the EU, decide your exposure, assign clear owners, and define what proof you can show on demand. For SaaS expansion to the EU, this is not abstract risk management; it affects buyer confidence during procurement and legal review, and how well your team handles diligence when questions get specific. Start with scope.
GDPR is usually the first check. It can apply even if you are outside the EU when you offer goods or services to people in the Union or monitor behaviour in the Union.
DSA is different. It targets online intermediary and platform services. It entered into force on 16 November 2022 and started applying broadly to online platforms in the EU from 17 February 2024.
DMA is narrower and tied to gatekeeper status for core platform services, so treat it as a specific exposure test, not a default assumption for every SaaS company. The AI Act adds risk-based rules for AI developers and deployers. It entered into force on 1 August 2024, with full applicability on 2 August 2026 and earlier exceptions from 2 February 2025.
| Pillar | Core owner | Business risk controlled | Concrete deliverable |
|---|---|---|---|
| 1. Legal & Governance Foundation | Founder, legal, privacy lead | Mis-scoped GDPR duties, weak accountability, poor diligence responses | Scope map, governance decisions, and core legal documentation |
| 2. Product Readiness | Product, engineering, security | Features that create avoidable privacy, platform, or AI exposure | Product controls and evidence tied to your actual feature set |
| 3. Go-to-Market Execution | Sales, marketing, customer success | Go-to-market friction from unclear compliance posture | Buyer-facing proof points, review-ready answers, and sales scripts |
Quick checkpoint before you continue: list your EU-facing data flows, behaviour tracking, any marketplace or user-posted content features, and any AI features you build or deploy. A common mistake is treating everything as "just GDPR," or assuming DSA or DMA applies automatically.
Work through this playbook in order. The sections below turn each pillar into practical checklists, decision rules, and answer scripts you can use with counsel, product, and sales.
Related: A Guide to the California Consumer Privacy Act (CCPA) for Freelancers.
In this pillar, focus on VAT mechanics you can verify now, while broader legal and governance workstreams run with counsel in parallel.
Start with a shared intake sheet that names owners and review dates, so your team can track VAT decisions and supporting records in one place.
Keep your contract and DPA workflow usable under pressure, but leave specific GDPR/DPA requirements to counsel rather than trying to force them into this OSS grounding.
Coordinate entity planning with VAT operations, and validate legal and tax conclusions with local advisers.
For VAT operations, OSS is the practical lever to decide early:
| OSS scheme | Filing cadence | Operating note |
|---|---|---|
| Non-Union | Quarterly | Register in one Member State of identification; report all supplies covered by this scheme via OSS. |
| Union | Quarterly | Optional scheme; once used, report all supplies covered by this scheme via OSS. |
| Import | Monthly | Monthly OSS returns under the import scheme. |
Cross-border transfer specifics sit outside this OSS grounding pack, so verify them separately before you make external commitments.
For a contract-structure walkthrough (separate from OSS VAT mechanics), see How a US-based SaaS consultant should structure a contract with a German enterprise client.
Before you lock your EU invoicing workflow, validate counterpart VAT details so your tax-treatment decisions are documented from day one: Check a VAT number.
If a feature touches personal data, do not start engineering until the spec spells out purpose, lawful basis, rights handling, and deletion coverage. This is where legal theory turns into product behavior, or into avoidable cleanup later.
If these requirements live in side notes, they get dropped. Put them in the PRD and make them mandatory before development starts. Required fields should include:
| PRD field | What to define |
|---|---|
| Data minimisation | List each field collected, why it is needed, and what you intentionally do not collect |
| Lawful basis by purpose | Map each processing purpose to a legal basis; do not use one blanket basis for mixed purposes |
| Consent UX (when consent is used) | Show the exact affirmative action that captures consent; pre-ticked boxes, silence, and inactivity do not count, and withdrawal must be as easy as giving consent |
| User-rights handling | Define the access, erasure, and portability path, including who owns response timing |
Use a release gate. If any required field is missing, the ticket does not move to development.
A good PRD is not enough on its own. The requirement has to show up in acceptance criteria, test cases, and release checks so you can verify that the product behaves the way the spec says it should. For each personal-data path:
Design rights handling to the GDPR timing model: respond without undue delay and within one month by default. You can extend by two further months for complex or numerous requests, with notice and reasons.
A common failure mode is stopping at row deletion in the primary database. That is not enough. Before you call erasure or portability "done," cover the full data chain:
For erasure, include downstream notification logic where data was made public. For backups, document how erased data is prevented from being reintroduced after restore. For portability, provide data in a structured, commonly used, machine-readable format and support transmission without hindrance. Log completion evidence for each request: request ID, scope, systems checked, vendors notified, completion time, and any exception path used.
AI features need a separate intake before release. Do not let product self-classify them in isolation, and do not wait until launch to ask what rule set applies. Run each AI feature through a three-step intake:
| Step | Requirement | Note |
|---|---|---|
| Scope check | Assess whether it is an AI system in scope using Commission guidance on the AI system definition | AI features need a separate intake before release |
| Risk triage with legal review | The AI Act uses 4 risk levels; do not self-classify in product alone | Do not let product self-classify them in isolation |
| Documentation gate | Maintain an AI file with model description, intended use, data sources, evaluation results, human oversight notes, incident owner, and placeholders for "Add current requirement after verification." | Keep timeline awareness current in the same file |
Keep timeline awareness current in the same file:
Subprocessor review usually goes more smoothly when legal, security, and procurement can all use the same comparison table. Keep it short enough to run, but specific enough to catch real gaps.
| Vendor | Role | Data touched | Transfer path | Contractual safeguards to verify | Review owner |
|---|---|---|---|---|---|
| Hosting provider | Infrastructure/subprocessor | Production data, backups, logs | EEA-only or third country | DPA, subprocessor terms, transfer safeguard where needed (including SCCs where relevant), equivalent protections | Security or legal |
| Analytics tool | Subprocessor | Event data, identifiers, usage logs | Actual storage and access path | DPA, purpose limits, deletion support, transfer safeguard review, equivalent protections | Product ops |
| Support platform | Subprocessor | Tickets, attachments, account data | Agent access and storage path | DPA, confidentiality, deletion/export support, transfer safeguard review, equivalent protections | Support lead |
Escalate when a vendor cannot explain transfer paths, will not provide equivalent protections, or cannot support your deletion and portability process. We covered this in detail in How to Create a Privacy Policy for a SaaS Application.
Use legal and tax readiness in sales only when each claim maps to a current artifact. In practice, VAT proof is often more useful than broad trust language because buyers can verify it quickly during diligence.
Buyers do not need slogans. They need evidence that you will not create VAT cleanup risk after signature. Lead with claims you can back with a current registration record, filing path, or internal memo.
OSS is a useful example. The schemes are optional. If you opt in, you must report all supplies that fall under the chosen scheme through the OSS return. OSS returns are additional to standard VAT returns. That level of specificity signals operating readiness.
| Claim you can make | Evidence artifact | Buyer concern addressed | Where it belongs |
|---|---|---|---|
| "For eligible EU sales, we manage VAT through OSS in one Member State of identification." | OSS registration confirmation and short memo naming the scheme (Union, non-Union, or import) | "Will cross-border VAT be handled consistently?" | Site trust page, sales call |
| "Our team treats OSS returns as additional to standard VAT returns." | Filing calendar showing OSS cadence plus domestic VAT return obligations | "Are you oversimplifying VAT compliance?" | Sales call, contract notes |
| "If we use the cross-border SME scheme, we track prior notification through MSEST and rely on it only after EX number issuance." | Prior notification receipt, EX number record, quarterly turnover reporting template across the 27 Member States | "Are you claiming exemption treatment too early?" | Sales call, diligence pack |
| "For unclear cross-border VAT treatment, we have a path to assess a VAT Cross-border Ruling where available." | Internal tax memo and filing plan in the participating country where you are VAT-registered | "What if VAT treatment is uncertain?" | Late-stage diligence, contract review |
Before any claim goes live, confirm the artifact owner, date, and jurisdiction so sales is using something current.
Sales scripts should help reps stay accurate, not sound confident while guessing. Keep them short, point reps to approved documents, and require a detail check before anything is shared.
"For eligible EU supplies, we can use OSS and register in one Member State of identification. Confirm the scheme in use (Union, non-Union, or import) before sharing."
"If we use OSS for a scheme, we declare all supplies under that scheme through OSS returns, and those returns are additional to standard VAT returns. Confirm filing cadence before sharing."
"For cross-border SME treatment, we use prior notification through MSEST and do not represent exemption status before EX number issuance. Confirm turnover tracking and quarterly reporting status before sharing."
"For complex cross-border VAT treatment, we can assess a VAT Cross-border Ruling where available and file in the participating EU country where we are VAT-registered under local ruling conditions."
Most trust problems here are self-inflicted. Marketing copy and contract terms need to match the VAT operating model you can document. Use these guardrails:
| Check | What to confirm |
|---|---|
| Deal-specific VAT position | Confirm OSS scheme choice, domestic return obligations, and whether any SME treatment depends on prior notification, the EUR 100 000 Union turnover limit, or EX number issuance |
| Fallback positions | Pre-approve fallback positions for core contract terms and customer paper versus your paper; flag non-delegable points as legal-only |
| VAT Cross-border Ruling | For complex structures, decide early whether to assess a VAT Cross-border Ruling; if yes, file in a participating EU country where you are VAT-registered and follow that country's national VAT ruling conditions |
| Timeline risk | SME registration should generally complete within 35 working days, but additional investigations can extend timing, so avoid fixed exemption promises before confirmation |
To keep contract-stage speed without adding risk, prep this checklist before first redlines:
Practical standard: claim less, prove more, and tie each promise to a current artifact. If you want a deeper dive, read Taxes in Germany for Freelancers and Expats.
Once you have the answers, turn them into an operating plan: assign an owner, keep each artifact current, and set a review date. That is how you move from anxiety to control.
Legal risk drops when your legal or ops owner can show evidence on demand, not just policy language. Keep one current pack with your processing records, your transfer map for any data leaving the EEA, and the safeguard used for each path, whether adequacy, SCCs, or BCRs. Keep your breach register in the same pack. If a breach is notifiable, the DPA timeline is 72h, and all breaches still need to be documented internally.
Execution improves when privacy by design and by default are built into delivery, not patched in later. Give product, engineering, and support clear ownership of data-subject request handling, including request-date tracking and the one-month deadline for any extension notice when more time is needed. A simple test works here: support should be able to show the request date, owner, and extension reason without legal having to rebuild the timeline.
Deal friction drops when sales, finance, and customer success answer with documents instead of assurances. For B2C tax flows, confirm whether OSS fits your model so you can centralize eligible VAT reporting through one portal. If you provide cloud or data-processing services, keep customer switching and export procedures documented so buyers can see how transitions happen with minimal disruption.
| Reactive behavior | Early behavior |
|---|---|
| You wait for a prospect questionnaire, then scramble for answers. | You maintain a current evidence pack, so diligence moves faster and with fewer escalations. |
| You discover cross-border transfers during contract redlines. | You map each EEA transfer path in advance and tie it to adequacy, SCCs, or BCRs. |
| You handle access or deletion requests from inbox memory. | You track request dates, owner, and any extension notice due within one month in a repeatable process. |
| You treat switching and portability as a future roadmap item. | You document export and transition steps early, which reduces procurement friction. |
Run this as one repeatable cycle. Legal reviews artifacts, product reviews defaults and request handling, and go-to-market reviews buyer-facing proof and VAT choices. Confidence comes from current evidence, not last-minute explanations.
You might also find this useful: A Guide to GDPR Compliance for SaaS Businesses.
If you want to operationalize this playbook, review Merchant of Record for business.
Start with a data map if your non-EU business offers goods or services to people in the Union or monitors behavior there. Build an Article 30 record of processing activities that covers what data you process, why you process it, and whether transfers leave the EEA. Keep that record dated and owned so legal can validate scope and transfer risk.
You need one when GDPR Article 3(2) applies to your non-EU business. In that case, Article 27 requires you to designate a representative in the Union in writing. Keep the written appointment with your processing records so counsel can test your scope analysis, and confirm with legal if an exemption may apply.
Treat these as separate rule sets with different triggers, not one combined track. Start by mapping product function, user base, and market role, then document which framework applies and why for legal review. | Rule | Who it applies to | What triggers scope | Your first compliance move | | --- | --- | --- | --- | | GDPR | Controllers/processors handling personal data, including certain non-EU businesses | Article 3(2): offering goods/services to people in the Union or monitoring behavior there | Build and maintain your Article 30 processing record; map transfers outside the EEA | | DSA | Providers of intermediary services and platforms offering services in the Union | Intermediary/platform role; generally applicable since 17 February 2024 | Confirm whether your service intermediates user or third-party activity | | DMA | Providers designated as gatekeepers for core platform services | Commission designation using objective criteria (including turnover/valuation and user thresholds) | Check whether you are near gatekeeper criteria; if designated, plan for the 6-month compliance window | | EU AI Act | Actors involved with AI systems placed on the market, put into service, or used in the Union | Whether the feature is an AI system and its risk category | Inventory AI features, assign risk, and start documentation early |
Not automatically, but transfers outside the EEA are restricted and must meet GDPR Chapter V conditions. If your data flows leave the EEA, identify each transfer path now rather than assuming localization alone solves scope. Document hosting regions, vendors, support access routes, and the transfer basis for legal validation.
It applies when your product places on the market, puts into service, or uses AI systems in the Union. Start now with an AI feature inventory. The Act entered into force on 1 August 2024, and first rules started applying on 2 February 2025, including AI literacy and limited prohibited use cases. For features that may be high-risk, prepare technical documentation before release and keep it up to date.
Decide this first by customer type: consumer (B2C) or taxable business (B2B). For B2C services, verify the customer-country position and use OSS for qualifying cross-border flows if you opt in. OSS is optional and can centralize declaration and payment through one Member State, including the non-Union route for non-EU suppliers. For B2B scenarios, verify taxable-person status and whether customer liability applies. Then document customer status evidence, location evidence, and your OSS choice, if any, with a final check of current country-specific rates, invoicing rules, and local requirements through the relevant national tax authority before go-live.
An international business lawyer by trade, Elena breaks down the complexities of freelance contracts, corporate structures, and international liability. Her goal is to empower freelancers with the legal knowledge to operate confidently.
Priya specializes in international contract law for independent contractors. She ensures that the legal advice provided is accurate, actionable, and up-to-date with current regulations.
Educational content only. Not legal, tax, or financial advice.
Low-stress compliance in Germany comes from decision order, not tax tricks. Use this sequence: confirm core facts, apply conservative temporary assumptions, verify the few points that can break invoices or filings, and keep one evidence file that explains each decision.
Privacy risk is delivery risk for many freelancers who handle client data. The practical move is to assess likely CCPA exposure early and put baseline controls in place before a client issue forces rushed decisions.
**Use GDPR for SaaS businesses as an operating playbook that protects trust and gives you defensible legal decisions before onboarding.**