Do you need a DPA for your contact form?

If you only run a personal blog, a DPA is rarely the bottleneck. If you sell to companies in the EU/UK or to agencies that resell your stack to those companies, procurement will ask for one.

When buyers ask

• Enterprise or mid-market security questionnaires
• Agency clients who are controllers under GDPR
• Any deal where legal reviews sub-processors

What a useful DPA covers

1. Roles: customer as controller, vendor as processor
2. Categories of data (form fields you choose to collect)
3. Sub-processors and locations
4. Retention and deletion
5. Security measures at a practical level
6. Breach notification language

FormHeron’s stance

A processor DPA is available to every account, including Free. Sub-processors are listed publicly. We state EU storage and India operations without pretending remote support is not a transfer topic. We do not market “GDPR compliant” as a bare badge.

Read the DPA, privacy policy, and sub-processors. Broader context: GDPR and contact forms.

Agency checklist

• Name the form backend in your client DPA or privacy schedule
• Use one project per client where isolation helps
• Prefer export/delete paths you can demonstrate in a security review
• Avoid collecting special-category data through open web forms

What “available to every account” means

You should not need an enterprise sales call to get a processor agreement for a form backend. FormHeron publishes a DPA for Free, Indie, and Pro. If a vendor gates the DPA behind annual contracts, that is a product choice — know it before you design a multi-client agency stack on them.

Red flags in vendor paperwork

• No sub-processor list or “available on request only”
• Claims of EU hosting with no operator location disclosure
• No export/delete story for end-customer data
• Unlimited retention with no purge job
• Unqualified “GDPR compliant” as the entire security page

Product: features · pricing · start free.