Picture this: your web app launches to a warm reception across the UK and Netherlands. Users sign up. Data flows. Then, eight weeks later, a letter arrives from the Information Commissioner's Office. A user filed a complaint. Your cookie banner was non-compliant. Your data retention policy was missing. Your third-party analytics tool was sending data to servers outside the EEA without a valid transfer mechanism. The fine isn't the worst part — the remediation work is. And it all could have been avoided before a single line of code was written.
GDPR compliance is not a legal afterthought. For any web app serving users in the UK, EU, or EEA, it is a foundational engineering requirement. Yet most founders and SMB owners only start asking the right GDPR compliance web app development questions after something goes wrong. This guide answers the 15 most common ones — in plain English, without the legal jargon — so you can build right the first time.
Retrofitting compliance into a finished product is expensive. Depending on how deeply personal data is woven into your app's architecture, a post-launch GDPR remediation project can cost as much as a full rebuild. Database schemas need restructuring. Consent flows need redesigning. Third-party integrations need auditing and replacing. What costs €5,000 to build correctly from the start can cost €40,000 to fix after the fact.
European startups and SMBs face a specific pressure here. Unlike large enterprises with dedicated legal teams, founders are often making compliance decisions themselves, or delegating them entirely to a development agency that may not have European regulatory experience. The questions below are designed to close that gap. Whether you're briefing an agency, reviewing a proposal, or preparing for launch, these answers give you the foundation you need.
The General Data Protection Regulation applies to any organisation that collects, stores, or processes personal data about individuals in the EU or UK. If your web app has a login screen, a contact form, or an analytics tracker, you are processing personal data. Full stop.
The core principles under Article 5 require that data is collected for a specific, legitimate purpose; that you collect only what you need (data minimisation); that you keep it accurate; that you don't hold it longer than necessary; and that you protect it with appropriate security. These aren't aspirational guidelines, they're legal obligations with enforcement teeth. The UK ICO and EU supervisory authorities issued over €2.1 billion in GDPR fines between 2018 and 2025, according to GDPR Enforcement Tracker.
Yes. Under Article 6, every act of data processing must rest on one of six lawful bases: consent, contract, legal obligation, vital interests, public task, or legitimate interests. Most web apps rely on a combination of the first three.
Consent is appropriate for marketing emails and non-essential cookies. It must be freely given, specific, informed, and unambiguous, a pre-ticked box does not count. Contract covers data you need to deliver your service (a user's email address to send them their account confirmation). Legitimate interests is often misused as a catch-all, it requires a genuine balancing test against the user's rights and is not a shortcut around consent. Document your legal basis for each data type before development begins. This decision shapes your consent flows, your privacy policy, and your data retention rules.
Server location matters significantly. GDPR restricts transfers of personal data outside the EEA (and, post-Brexit, outside the UK) unless specific safeguards are in place. If you're using AWS, Google Cloud, or Azure, you can select EU-based regions (Frankfurt, Dublin, Amsterdam) to keep data within the EEA. That's the simplest path.
If your architecture requires data to flow to US-based services, a US-hosted CRM, a US analytics platform, a US support tool, you need a valid transfer mechanism. The most common is Standard Contractual Clauses (SCCs), which are pre-approved contract templates from the European Commission. Some US companies also participate in the EU-US Data Privacy Framework. The key point: "we use AWS" is not a compliance answer. "We use AWS eu-west-1 with SCCs in place for any US-bound data flows" is. Demand this specificity from your development agency.
Cookies are governed by both GDPR and the ePrivacy Directive (often called the "Cookie Law"). The practical result: any cookie that isn't strictly necessary for the service to function requires prior, informed consent before it's set. This includes analytics cookies, advertising cookies, and most third-party tracking pixels.
A compliant cookie consent implementation means: the banner appears before any non-essential cookies are loaded; users can accept or reject categories independently; the choice is stored and respected; and users can change their preferences at any time. Banners that pre-tick "analytics" or make "reject" harder to find than "accept" are non-compliant. The French CNIL and UK ICO have both issued significant fines specifically for dark-pattern cookie banners. Your development team should implement a consent management platform (CMP) like Cookiebot, OneTrust, or an open-source equivalent, and it must be configured correctly, not just installed.
GDPR grants users eight rights. The ones most relevant to web apps are:
You must respond to these requests within 30 calendar days. For a small team, that's a tight window if fulfilment is entirely manual. The better approach is to build self-service data management into your app from the start, an account settings page where users can download their data, update their profile, or delete their account. This is not just good compliance practice; it's good UX. Brief your development agency on these requirements during discovery, not after the database schema is finalised.
A Data Processing Agreement (DPA) is a contract required under Article 28 whenever a data controller (you) shares personal data with a data processor (a third party acting on your behalf). Your cloud hosting provider, your email service, your analytics platform, your payment processor, and your development agency, if they handle personal data on your behalf, all require a DPA.
The DPA must specify what data is being processed, for what purpose, for how long, and what security measures the processor will apply. Most major SaaS providers (AWS, Google, Stripe, Mailchimp) offer standard DPAs that you can accept through their dashboards. For your development agency, the DPA should be part of your main contract. If an agency can't produce or sign a DPA, that's a serious red flag. See our guide on development contract essentials for the broader contractual clauses to review before signing.
Every third-party tool you embed in your web app is a potential compliance liability. Google Analytics, Hotjar, Intercom, Drift, Facebook Pixel, all of these collect personal data, often sending it to US-based servers. Several EU supervisory authorities (Austria, France, Italy, Denmark) have ruled that standard Google Analytics implementations violate GDPR due to US data transfers.
Your options are: configure these tools with IP anonymisation and SCCs in place; switch to privacy-first alternatives like Plausible Analytics or Fathom (both EU-hosted, no personal data collected); or conduct a formal transfer impact assessment for each tool. The audit process is straightforward: list every third-party script your app loads, identify what data each one collects, where it sends that data, and what legal basis and transfer mechanism applies. This audit should happen before launch, not after a user complaint triggers it.
For a broader look at how API integrations interact with compliance requirements, our API integration FAQ covers the technical and contractual dimensions in detail.
Article 25 of GDPR requires "privacy by design and by default." In practice, this means your app should collect the minimum data necessary, default to the most privacy-protective settings, and build data protection into the system architecture, not add it as a layer on top.
Concrete examples: a registration form that asks only for email and password (not date of birth, phone number, and address unless you genuinely need them); analytics that are off by default until consent is given; user roles with the minimum permissions required for each function; automatic data deletion after a defined retention period. These are engineering decisions, not legal ones. Your development team needs to understand Privacy by Design as a technical requirement, not a compliance checkbox. When briefing an agency, ask specifically how they implement data minimisation in form design and what their default approach to user permissions looks like.
A DPIA is mandatory under Article 35 when your processing is "likely to result in a high risk" to individuals. Common triggers include: processing sensitive data (health, biometric, financial); large-scale profiling or behavioural tracking; systematic monitoring of publicly accessible areas; and processing data about vulnerable groups (children, employees).
For most standard SaaS or e-commerce web apps, a full DPIA may not be legally required, but a lightweight risk assessment is always good practice. The process involves identifying what data you process, assessing the risks to individuals, and documenting the measures you've taken to mitigate those risks. Your Data Protection Officer (if you have one) or a legal advisor can guide this. The output is a document that demonstrates you've thought carefully about risk, which is exactly what a supervisory authority wants to see if they ever investigate.
If your web app processes payments from European users, PSD2 (the EU's revised Payment Services Directive) and its Strong Customer Authentication (SCA) requirements apply to you. SCA mandates that online payments are authenticated using at least two of three factors: something the user knows (password/PIN), something the user has (phone/hardware token), and something the user is (biometric).
In practice, this means your checkout flow must support 3D Secure 2 (3DS2), the technical standard that enables SCA. The good news: if you're using a major European payment provider like Stripe, Adyen, or Mollie, SCA compliance is largely handled at the payment layer. What your development team needs to ensure is that your integration is configured correctly, not using legacy API calls that bypass 3DS2, and not suppressing authentication challenges in ways that shift liability back to you.
SCA exemptions exist for low-value transactions (under €30), trusted beneficiaries, and low-risk transactions assessed by the payment provider. Your payment provider's documentation will specify which exemptions apply and how to request them. The key development decision is choosing a payment provider with strong European SCA support and integrating their SDK correctly, not building a custom payment flow that bypasses these protections.
GDPR requires you to notify your supervisory authority (the ICO in the UK, or the relevant national authority in the EU) within 72 hours of becoming aware of a personal data breach, if the breach is likely to result in a risk to individuals' rights and freedoms. If the risk is high, you must also notify the affected users directly.
This 72-hour window is tight. Without the right technical infrastructure, you may not even know a breach has occurred within that timeframe. Your web app needs: centralised logging so anomalous access patterns are detectable; alerting systems that notify your team of unusual activity; and a documented incident response plan that specifies who does what when a breach is suspected. These are DevOps and security architecture decisions that need to be made during development. Our guide on DevOps and cloud deployment infrastructure covers the logging and monitoring foundations that support breach detection.
Article 32 requires "appropriate technical and organisational measures" to protect personal data, but it doesn't prescribe specific standards. In practice, regulators expect the following for web applications:
"Appropriate" is relative to the sensitivity of the data you process. A health app handling medical records faces a higher bar than a B2B SaaS tool handling business email addresses. Your development agency should be able to articulate what security measures they're implementing and why, not just assert that the app is "secure." For ongoing security costs post-launch, our website maintenance cost breakdown covers what European businesses typically budget for security upkeep.
Yes, a privacy policy is mandatory under Articles 13 and 14. It must be written in plain, clear language (not legal boilerplate that users can't understand) and must include:
The privacy policy must be accessible before users provide any data, typically linked in the footer, on registration forms, and in your cookie banner. It's a living document: every time you add a new third-party tool or change how you process data, the policy needs updating. Build a review cadence into your post-launch operations from day one.
This is the question that separates founders who build compliant products from those who spend their first year fixing them. Before your agency writes a single line of code, get clear answers to the following:
An agency that can answer these questions confidently, with evidence, is one that has built for European markets before. An agency that deflects or gives vague reassurances is one that will leave you with a compliance problem to solve post-launch. For a broader framework on evaluating development partners, see our guide on choosing between a freelancer and an agency for your first digital product.
It's also worth reviewing the 9 essential elements of project scope definition, compliance requirements belong in your scope document, not in a verbal conversation during a discovery call.
Compliance is not a binary state, it's a continuous posture. That said, a pre-launch compliance review should cover the following:
Third-party tools like GDPR.eu's compliance checklist provide a useful self-assessment framework. For higher-risk apps, a formal audit by a specialist (a DPO-as-a-service provider or a privacy law firm) is worth the investment before launch. Compliance is also not a one-time task, as your app evolves, new features may introduce new processing activities that require fresh assessment.
The 15 questions above cover the core of what European founders and SMB owners need to understand before building a web app. The common thread across all of them is timing: compliance decisions made during architecture and design cost a fraction of what they cost to retrofit after launch. Data models, consent flows, third-party tool choices, security architecture, these are all engineering decisions that have compliance consequences. They need to be made deliberately, with a development partner who understands the European regulatory environment.
At Axire Infotech, we build web apps for European startups and SMBs across the UK, Netherlands, Ireland, Germany, Belgium, and Sweden, and GDPR compliance is part of our standard development process, not an optional add-on. From Privacy by Design in our architecture decisions to DPA-ready contracts and compliant cookie consent implementations, we build products that are ready for European markets from the first sprint.
If you're planning a web app build and want to understand how compliance requirements affect your timeline and budget, our team can walk you through the specifics during a no-obligation discovery call. You can also explore our web development services to see how we approach scalable, secure builds for European clients, or view our project portfolio for examples of what we've delivered.
For a broader view of what a compliant, well-scoped development project looks like from budget to delivery, our development budget planning guide is a practical next step. And if you're ready to talk specifics about your project, contact our team, we'll respond with a clear, honest assessment of what your build requires, compliance included.
Let's discuss your project and create something amazing together.
