GDPR-Compliant Form Data Handling in Google Sheets

Before we go any further, a clear line. We are software engineers, not solicitors or data protection officers. Everything in this article is a description of common technical patterns we see in WordPress and Google Sheets deployments, not a legal opinion on your specific business.

GDPR compliance is jurisdiction-specific, sector-specific, and fact-specific. The same form on a German B2B SaaS site, a UK charity, and a US ecommerce store with EU customers will have three different lawful-basis analyses and three different retention conclusions. Your DPO or qualified legal counsel is the authority on whether any given setup actually meets Article 5 and Article 6 obligations.

Treat the rest of this post as a working checklist, not a verdict. Use it to brief your lawyer, configure SheetLink, and understand where your privacy policy obligations sit. Where we cite specific GDPR articles, we cite the public regulation text, not a paid interpretation service.

Article 5 lists the principles every controller has to satisfy. Walking through them with a form-to-Sheets pipeline in mind makes the abstract concrete.

• Lawfulness, fairness, transparency. The user knows what they are giving up and why. Your form's privacy notice and the consent text together carry this load.
• Purpose limitation. The data only gets used for the purpose stated at collection. A "contact us" form cannot silently feed a marketing sequence.
• Data minimisation. You collect only what you actually need. If the sales rep does not call the phone number, the phone field should not exist.
• Accuracy. The user can correct wrong data. Build a path for that, even if it is just an email address that triggers a manual edit.
• Storage limitation. You delete data once the original purpose is satisfied. A row sitting in Sheets for five years "just in case" fails this test.
• Integrity and confidentiality. The data is protected against unauthorised access. Sheet sharing settings and Workspace 2FA are the practical levers.
• Accountability. You can demonstrate compliance with all of the above. Article 30 records, retention logs, consent timestamps.

None of these are toggles. They are habits a team builds once and revisits during every quarterly hygiene pass.

The mechanics of a valid consent checkbox are surprisingly strict. The UK ICO and EDPB guidance on Article 7 has been consistent since 2018, and supervisory authorities have fined organisations over each of the points below. Build the form once and you stop worrying about it.

• Unticked by default. Pre-ticked boxes are not consent. The CJEU said so explicitly in the Planet49 ruling.
• Specific wording. "I consent to Acme Ltd storing my name and email and contacting me about my enquiry." Not "I agree to the terms."
• Separate purposes get separate boxes. Marketing list opt-in and transactional contact are two different consents and need two boxes.
• Audit trail. Store the timestamp, the exact text shown, the form version, and the IP at submission alongside the row.
• Easy withdrawal. One-click unsubscribe in every marketing email, plus a public address for general withdrawal requests.

SheetLink passes any consent fields you build into the form straight through to your Sheet, with the checkbox state stored as a string. Add a hidden field with the consent version (for example, consent_v3_2026-04) so a later review can match the exact text against the row. That single column has saved more compliance audits than any plugin setting.

WordPress ships native privacy tooling at Tools > Export Personal Data and Tools > Erase Personal Data. They are not magic. They are filter hooks (wp_privacy_personal_data_exporters and wp_privacy_personal_data_erasers) that plugins must register against. If a plugin does not register, its data is invisible to those screens.

SheetLink registers both an exporter and an eraser for the WordPress-side records it controls: form submission logs, retry queue entries (see retry queue troubleshooting), consent metadata, and the local analytics cache. When a user invokes their right of access under Article 15 or right to erasure under Article 17, the WordPress flow walks every registered exporter or eraser and produces a single ZIP or confirmation page.

The flow is admin-mediated. A user emails you, you create a request in the WordPress admin keyed on their email, the user confirms by clicking a verification link, and you then click Send export or Erase data. The 30-day clock under Article 12(3) starts when you receive the original request, not when you click the button. Build a ticket process around it, do not rely on memory.

Article 15 gives every data subject the right to ask what you hold on them, why, and who you share it with. Article 12(3) gives you one month to respond, extendable by two months for complex requests with a written explanation. Most SARs are simple, but the format trips teams up.

The minimum response includes: every personal data field you hold (name, email, phone, IP, message contents, consent record), the purposes of processing, the categories of recipients (Google Workspace, your CRM, any enrichment tools), the retention period or the criteria used to set it, and the user's other rights (rectification, erasure, portability, complaint to a supervisory authority).

Provide it in a structured, commonly used, machine-readable format. CSV or JSON is the standard. The WordPress export tool produces an HTML ZIP, which is acceptable, but for SAR responses including Sheet data, append a CSV row export from the Sheet itself. A typical flow looks like this:

1. Receive the SAR by email and timestamp it.
2. Verify the requester's identity through the email confirmation flow.
3. Run the WordPress export, plus a Sheet-side CSV filter on their email.
4. Bundle everything into a single archive and send via a secure link.
5. Log the response date in your Article 30 register.

The 30-day clock is firm. Build the muscle so you can hit it without scrambling.

Article 28 requires a written contract between you (controller) and every processor that handles personal data on your behalf. For a typical WordPress-to-Sheets stack, that means at least three DPAs sitting in your records.

Article 30 then asks you to keep a Record of Processing Activities listing every processor, the categories of data shared, the legal basis for the transfer, and the retention period. A simple spreadsheet works. The point is that an auditor can ask for it on a Tuesday and you can produce it on the Wednesday. Add new processors to the register the same day you sign their DPA, never "later this week."

Article 9 designates a set of "special categories" of personal data: health, biometric, racial or ethnic origin, political opinions, religious beliefs, trade union membership, sex life, and genetic data. Processing them requires a higher bar, usually explicit consent under Article 9(2)(a) plus one of the standard Article 6 bases plus, in many cases, a Data Protection Impact Assessment.

The practical answer for a Sheet-based stack is short: do not. SheetLink does not have a HIPAA Business Associate Agreement, Google Workspace's standard tier does not either, and a default Sheet has none of the access controls a compliant health stack needs. Routing patient intake forms or therapy notes through Sheets is a regulator headline waiting to happen.

Payment card data sits in PCI-DSS territory rather than GDPR special categories, but the answer is the same. Use Stripe, Adyen, or another PCI-DSS-scoped processor and store only metadata (last four digits, transaction ID, amount) in your Sheet. The full PAN should never touch your form.

If you genuinely need to capture special-category data on a WordPress form, the right path is a dedicated, scoped platform with a signed BAA or equivalent, not Sheets with extra encryption. Use SheetLink for everything else and route the special-category flow elsewhere.