Netlify DPA: What a Data Processing Agreement Covers, and a Checklist for Any Host

A Data Processing Agreement, or DPA, is the contract that governs how a hosting provider is allowed to handle personal data on a customer’s behalf under GDPR; it names the provider as a processor, the customer as the controller, and sets out what the provider can and can’t do with that data, who else might touch it, and what happens if something goes wrong. Netlify’s DPA is incorporated by reference into its standard terms rather than requiring a separate signature for most customers, and is published as a downloadable document referenced from both its GDPR page and its privacy policy. What that means in practice, and what to check in any host’s DPA, follows below.

A DPA isn’t a formality that exists to satisfy a compliance checkbox; under GDPR, processing personal data through a third-party service without a valid DPA in place is itself a compliance gap, independent of anything else going right or wrong with that data. Most hosting providers process personal data in some form the moment a site collects an email address, logs an IP address, or stores a user record in a database, which makes the DPA question relevant to nearly every hosting decision involving EU users, not just large enterprise contracts. This looks at what a DPA actually is, what Netlify’s covers based on its own published documentation, and a general checklist for evaluating any host’s DPA, since the shape of a good one doesn’t change much between providers.

Table of contents

• What a DPA actually is, and what it isn’t
• What a typical hosting DPA covers
• What Netlify’s DPA covers, based on its published documentation
• Getting a DPA signed or referenced
• A DPA checklist for evaluating any host
• Where this fits next to the rest of the stack
• How this fits the rest of the stack
• FAQ

What a DPA actually is, and what it isn’t

Under GDPR, the organization that decides why and how personal data is processed is the controller, typically the business running the site. A hosting provider storing that data on the controller’s behalf, without deciding independently what to do with it, is a processor. Article 28 of GDPR requires a contract between them, the DPA, before that processing happens, setting out the scope, purpose, and duration of processing, the categories of data and data subjects involved, and the processor’s obligations.

A DPA is not the same document as a privacy policy. A privacy policy is a public statement telling end users what happens to their data; a DPA is a contract between the business and its processor governing how that processor is allowed to handle data on the business’s behalf. A host can have an excellent privacy policy and still not have a proper DPA in place for its business customers, since the two documents answer different questions to different audiences.

What a typical hosting DPA covers

• Subprocessors: who else the provider shares data with, such as a CDN, an email service, or a database vendor, usually with a right to object to new ones or at least advance notice when they’re added
• Standard Contractual Clauses, or SCCs: the mechanism that makes an international transfer of EU personal data to a country without an adequacy decision legally valid, referenced or attached where the provider’s infrastructure spans regions
• Breach notification terms: how quickly the processor must tell the controller about a data breach, since the controller has its own, usually shorter, notification clock to the relevant supervisory authority once it knows
• Deletion and return of data: what happens to the data when the contract ends, and on what timeline
• Security measures: a description, sometimes an annex, of the technical and organizational measures the processor uses to protect the data

A DPA missing more than one or two of these is worth a closer look before signing anything, particularly the subprocessor and breach notification terms, since both directly affect how quickly and completely a controller can meet its own GDPR obligations downstream.

What Netlify’s DPA covers, based on its published documentation

Netlify’s GDPR and CCPA page states that its DPA is incorporated by reference into its terms and conditions, meaning accepting Netlify’s standard terms accepts the DPA along with them for most customers, rather than requiring a separate signed copy for every account. The document itself is published as a downloadable PDF, linked from both that page and Netlify’s privacy policy.

That privacy policy also addresses international transfers explicitly, noting that personal data may be processed in jurisdictions without an EU adequacy decision, governed by the same DPA, language that typically points to SCCs or an equivalent transfer mechanism doing the legal work behind the scenes. Netlify’s own support forum shows customers repeatedly asking whether a separate signed DPA is available, with the consistent answer pointing back to the incorporated-by-reference document rather than a bespoke signing process, which is worth expecting rather than being surprised by.

This pattern, terms-based incorporation rather than a bespoke signature, is common enough among hosting and SaaS providers that the absence of a dedicated signing flow shouldn’t be read as the DPA not existing; it’s worth checking the terms and privacy pages specifically before concluding a provider has skipped this obligation.

Getting a DPA signed or referenced

For a provider whose DPA is incorporated by reference, as Netlify’s appears to be for standard accounts, there’s often no additional signature step: the DPA already governs the relationship as part of accepting the terms of service, and the downloadable copy exists mainly for a customer’s own records or for showing to their auditors or larger customers who ask for it directly. For the pricing side of evaluating Netlify more broadly, see Netlify Cost and Netlify Free Plan.

Some providers, particularly at enterprise tiers, do offer a separately countersigned DPA on request, sometimes with negotiated terms rather than the standard published version. Whether that’s needed depends on the controller’s own obligations; a business processing sensitive data at scale, or one whose own customers contractually require evidence of a countersigned DPA specifically, should ask the provider directly rather than assuming incorporation-by-reference is sufficient for their case.

Asking the question directly, by support ticket or account representative, is a reasonable first step regardless of company size, and a provider unable to answer it clearly is itself useful information.

A DPA checklist for evaluating any host

1. Find it before signing up, not after: a provider’s DPA, or the statement that it’s incorporated by reference, is usually linked from its privacy or legal page; if it isn’t findable at all, that’s worth asking about directly.
2. Check the subprocessor list, and whether the provider commits to notifying customers before adding new ones.
3. Confirm an international transfer mechanism is named, SCCs being the common one, if the provider or its subprocessors operate outside the customer’s region.
4. Read the breach notification timeline: a vague without undue delay is weaker than a specific number of hours or days.
5. Check what happens to data when the contract ends: deletion, return, and on what timeline.
6. Keep a copy for your own records, whether it required a signature or not, since a controller may need to produce it during an audit or a data subject access request.

None of this is specific to Netlify; the same checklist applies to any host, database provider, or third-party service processing personal data on a business’s behalf, and running through it takes a few minutes against a document that’s usually already public.

Where this fits next to the rest of the stack

A DPA covers the legal relationship; it doesn’t replace the architectural choices that make GDPR compliance easier in practice: keeping EU user data on infrastructure within the EU where that’s required, using a managed database with clear backup and deletion behavior rather than an ad-hoc script nobody remembers how to run, and knowing exactly which subprocessors touch the data before a customer or auditor asks. Our post on EU Hosting and GDPR covers the infrastructure side of that in more detail, what actually has to live in Europe versus what’s a preference rather than a legal requirement.

For any hosting provider a business is evaluating, including RunxBuild’s own dashboard, the DPA question is worth asking early rather than discovering the answer during a compliance review that’s already under time pressure. None of that is unique to any one provider either; it’s the same short list worth confirming with any host, database vendor or analytics tool that touches personal data on a project’s behalf.

How this fits the rest of the stack

A DPA is boring paperwork right up until a data subject request or a security incident makes it the only thing standing between a business and a much worse conversation with a regulator. Netlify’s approach, incorporated by reference, published as a PDF, no separate signature required for most accounts, is a reasonable, common pattern, and the checklist above works whether the DPA in question is Netlify’s or anyone else’s.

The DPA question is worth asking about any provider a personal-data-handling project runs on, RunxBuild included. The RunxBuild hosting calculator is a reasonable place to start pricing the managed database and service pieces underneath that decision, once the legal side is settled.

Useful related references:

• EU Hosting and GDPR: What Actually Has to Live in Europe
• Netlify Cost: How Usage-Based Hosting Bills Actually Add Up
• Netlify Free Plan: How to Read a Free Tier Before You Depend On It
• Databases on RunxBuild

FAQ

What is a Data Processing Agreement (DPA)?

A DPA is the contract required under GDPR Article 28 between a controller, the business deciding why and how personal data is processed, and a processor, a provider handling that data on the controller’s behalf, such as a host. It sets out the scope and purpose of processing, the categories of data involved, subprocessors, security measures, and what happens to the data when the relationship ends.

Does Netlify have a DPA?

Yes. According to Netlify’s own GDPR and CCPA page, its DPA is incorporated by reference into its standard terms and conditions, meaning it governs the relationship automatically for most customers rather than requiring a separate signature. It’s also published as a downloadable document, referenced from both that page and Netlify’s privacy policy.

Is a privacy policy the same thing as a DPA?

No. A privacy policy is a public statement to end users about what happens to their data. A DPA is a contract between a business and its processor, a host for example, governing how that processor may handle data on the business’s behalf. A provider can have a thorough privacy policy and still lack the contractual DPA a business customer needs for its own compliance.

What should a hosting provider’s DPA include?

A named list or category of subprocessors with notice of changes, a transfer mechanism such as Standard Contractual Clauses for data leaving the EU, a specific breach notification timeline rather than a vague commitment, a description of security measures, and clear terms for data deletion or return when the contract ends. A DPA missing several of these is worth questioning before relying on it.

Do I need a signed DPA for every hosting provider I use?

If the provider processes personal data on your behalf, GDPR expects a valid DPA to be in place, whether that’s a document you separately sign or one incorporated by reference into the provider’s standard terms, as Netlify’s is for most accounts. Larger or more sensitive processing relationships sometimes warrant asking for a separately countersigned version instead of relying on incorporation by reference.