+1 (415) 612-6492
BaseBrainers

Airtable and GDPR: Data Inventory, Retention Clocks, and Answering a Deletion Request

Most Airtable bases collect personal data on day one. A form captures a name and an email, an automation copies it to a CRM, an AI field reads the message, and a shared view puts the lot in front of a contractor. None of that is a problem until someone emails asking what you hold about them, or a client's procurement team sends a data protection questionnaire before signing. Then "it's in Airtable" is not an answer.

This tutorial is the privacy layer that sits on top of the Airtable security checklist. That one is about who can get in. This one is about what you keep, for how long, where it lives, and how you answer a subject access or deletion request without hand-searching nineteen bases.

It is practical guidance from consultants, not legal advice. Your DPO or counsel owns the policy; your job is to make the base able to honour it.

Step 1: build a data inventory, in Airtable

You cannot defend what you have not listed. Create a governance base (or a table in an existing admin base) called Data inventory, one record per table that holds personal data:

  • Base and Table — where it lives.
  • Data subjects — multiple select: customers, candidates, employees, vendor contacts, website visitors.
  • Categories — multiple select: name, email, phone, address, CV, payment detail, health, biometric. Flag the special categories, because they carry stricter rules.
  • Lawful basis — single select: contract, legitimate interest, consent, legal obligation.
  • Source — form, import, API, manual entry, sync.
  • Retention period — number of months.
  • Deletion method — single select: automated, scripted, manual.
  • Leaves Airtable to — long text: every destination. Zapier, HubSpot, a Slack channel, a model used by an AI field, a Google Drive folder of generated PDFs.
  • Owner — collaborator.

The last field is where most audits break down. Personal data does not stay in the base. The Slack message your automation posts contains the lead's email; so does the generated quote PDF in Drive; so do the prompt logs for an AI field. An inventory that only lists tables will tell you a record is deleted when three copies survive outside Airtable.

Populate it by walking the workspace base by base. Budget an hour per base. If you cannot name the owner or the lawful basis for a table, that is itself a finding.

Step 2: minimise at the point of collection

The cheapest compliance work is not collecting the data.

  • Audit every form field. "Phone number" that nobody has ever called is a liability with no upside. Delete it.
  • Replace free-text "anything else?" boxes that invite people to paste sensitive detail with structured choices where you can.
  • Stop importing the whole CSV. When a client hands you a spreadsheet for a migration, import the columns the workflow uses, not all 60.
  • Check what your AI fields send. Every field you insert into a prompt leaves the base. If a classification only needs the message text, do not pass the phone number and the contract value along with it. Our AI field agents tutorial covers the prompt side.
  • Add a privacy notice link and, where consent is your basis, an explicit opt-in checkbox field on the form, writing to a Consent given checkbox plus a Consent timestamp field. Consent you cannot evidence is consent you do not have.

Step 3: make retention a field, not a policy document

A retention policy that lives in a PDF never deletes anything. Make it computable.

On each table holding personal data, add:

  • Retention anchor — a date field or formula marking the event the clock runs from. Last contact date, contract end, application date.
  • Delete after — formula: DATEADD({Retention anchor}, 24, 'months').
  • Retention status — formula flagging the state, for example:
IF(
  {Legal hold},
  "Hold",
  IF(
    IS_AFTER(NOW(), {Delete after}),
    "Due for deletion",
    IF(
      IS_AFTER(NOW(), DATEADD({Delete after}, -30, 'days')),
      "Due in 30 days",
      "Within retention"
    )
  )
)
  • Legal hold — checkbox. Anything in a live dispute, an open contract, or a statutory accounting window must never be auto-deleted. The hold flag beats the clock.

Then build a view Retention – due filtered to Retention status is Due for deletion and Legal hold unchecked. That view is your work queue.

Two warnings about automating the deletion itself. First, a scheduled automation that deletes records is an irreversible script running unattended against live data; see automations that fail silently for how to make it log and alert. Second, deleted Airtable records are recoverable from the trash and from snapshots for a period, which is a feature for accidents and a problem for "we erased it." Know your plan's snapshot window and state it honestly when you answer a questionnaire.

A safer default for most teams: automate the flagging, keep the deletion a reviewed monthly job, and log every run.

Step 4: an anonymisation pattern that does not orphan your reporting

Hard-deleting a contact record usually breaks something — the linked orders lose their customer, the revenue rollup drops, and someone restores it from a snapshot a week later. Anonymise instead, where the lawful purpose allows it:

  1. Keep the record and its links.
  2. Overwrite the identifying fields: Name becomes Deleted contact 4f2a, Email becomes empty, Phone, Address, and any notes are cleared, attachments removed.
  3. Keep the non-identifying facts you have a basis to keep — order totals, dates, region.
  4. Set Anonymised on and Anonymised by, and tick a Subject deleted checkbox so nothing re-enriches the record later.

Run it as a script so it is consistent, and remember the trail: revision history on those fields still holds the old values, so if full erasure is genuinely required you need record deletion plus awareness of the trash and snapshot windows, not an overwrite.

Step 5: answer a subject access request in under an hour

The request arrives as an email. You usually have a month. The work is finding every copy.

Prepare now:

  1. A search runbook. List, from the inventory, every table that could hold a person: contacts, inquiries, candidates, support threads, event attendees. For each, note the field to search (usually email, sometimes a normalised match key — see data quality).
  2. A match key. Lowercased, trimmed email in a formula field in every people table. Searching on it beats eyeballing Email fields with stray capitals and whitespace.
  3. A DSAR script. One Airtable script that takes an email address, loops the tables in the runbook, and writes a summary record plus a JSON export of matching records into a DSAR table. Twenty minutes of scripting now saves a frantic afternoon later. Batch your reads and respect rate limits as usual.
  4. A DSAR log table. Requester, Type (access, erasure, rectification, portability, objection), Received date, Due date formula at +30 days, Systems searched, Outcome, Responded date, attachments of what you sent. Regulators ask how you handled requests; this table is the answer.
  5. A downstream list. For each destination in Leaves Airtable to, note who to ask to delete their copy and how long they take. Your processors are part of your response.

Redact other people's data before you send anything. A long-text note that mentions two customers cannot go out whole.

Step 6: processors, residency, and the questionnaire

When a client asks where their data lives, they usually want four things, and you should have all four written down before you are asked:

  • The data processing agreement. Airtable publishes a DPA and sub-processor list. If you are the consultancy, you are typically a processor for your client and Airtable is a sub-processor; your contract needs to say so, and your client's DPA list needs to name Airtable.
  • Transfer mechanism. Airtable is a US company. Transfers out of the EEA or UK rest on standard contractual clauses and, where applicable, the EU–US Data Privacy Framework. Check Airtable's current trust documentation for the live position rather than quoting a blog post, including anything relevant to data residency options on enterprise plans.
  • Your sub-processors. Every tool in the chain is one: Zapier or Make, the e-signature provider, the PDF generator, the model behind an AI field, the backup target. List them with purpose and location.
  • Security posture. Point to Airtable's certifications and to your own controls — SSO, admin panel governance, scoped tokens, the review cadence in the enterprise governance guide.

Keep all four in a single Compliance pack document per client. The first questionnaire takes two days; every subsequent one takes an hour.

Step 7: the leak paths people forget

Run these checks quarterly. They are where privacy incidents in Airtable actually come from.

  • Public shared view links. A grid view shared to the web is a public dataset. Audit every share link, set expiry and password where kept, kill the rest.
  • Personal bases. Someone duplicated the client base into their personal workspace "to test something" two years ago. The admin panel will show it; see shadow bases in the governance guide.
  • Backups. Your nightly off-platform export is a full copy of the personal data, often sitting in a Drive folder with broader access than the base. Encrypt it, restrict it, and give it the same retention clock.
  • Attachments. CVs, ID scans, and signed contracts carry the most sensitive data in the base and the loosest controls. Attachment URLs are long-lived enough to be shared; treat them as sensitive. See attachments at scale.
  • Automation side effects. Slack notifications, emails to the team, and webhook payloads copy personal data out. Send a record link instead of the record contents wherever you can.
  • Sync and interfaces. A synced table can carry fields the downstream audience should not see; filter at source, not in the view.

A 90-minute starting point

If this is all new, do these four things this week:

  1. Build the Data inventory table and fill in your three biggest bases.
  2. Audit and kill every public share link you cannot justify.
  3. Add Retention anchor, Delete after, Legal hold, and the Retention – due view to your largest people table.
  4. Create the DSAR log table so the next request has somewhere to live.

Everything else — the script, the compliance pack, the automated flagging — builds on those.

BaseBrainers builds retention, DSAR, and governance tooling into client bases as part of our Airtable security and compliance work. If you are staring at a client questionnaire or a deletion request and you are not sure what your base actually holds, get in touch.