GDPR and an Automated WhatsApp Inbox: The Shape of It

If you serve customers in the EU or the UK, GDPR applies to your WhatsApp inbox, and it is not simply India's DPDP with the names changed. The two regimes overlap in instinct and differ in detail, and the details are where businesses get caught.

This is not legal advice and cannot be. The obligations depend on facts about your business — what you sell, to whom, from where, and what you do with what you collect. Take advice from somebody qualified. What follows is the shape, so you can have a better conversation with them.

Where the two regimes pull apart

Four places worth knowing about, none of which a blog post can resolve for you.

A lawful basis is not the same as consent. GDPR asks you to name a basis for processing, and consent is only one of several. Businesses frequently assume they need consent when a different basis fits better, or assume they have a basis when what they actually have is habit.

Access and portability are specific. A person may ask what you hold, and may ask for it in a form they can take elsewhere. "We'll dig through the threads" is not a process. The practical test is whether you could answer such a request in a working week without it ruining that week.

Erasure has edges. It is not absolute, and there are grounds for retaining some records. Which of those apply to you is exactly the kind of question that needs a real answer rather than a guess.

Where the data goes matters. Transfers outside the EU have their own rules. For a messaging channel this is not theoretical — the platform, and any vendor you connect, are both processing on somebody's infrastructure somewhere.

The part that is genuinely mechanical

Strip away the judgement calls and a short list remains, and it is the list to put to any vendor.

Data minimisation is the lever that actually reduces work

The cheapest field to secure, export, and erase is the one you never collected.

That sounds like a slogan and it is arithmetic. Every attribute you store multiplies across every obligation: it has to be findable for an access request, deletable for an erasure request, defensible if somebody asks why you have it, and protected in the meantime. Four costs per field, forever.

What automation adds to the problem, specifically

Two things that a purely manual inbox does not have.

Scale of exposure. A person answering messages reads a few hundred. A system with a shared login and no access log means everyone reads everything, forever, with no record.

Decisions made by software. An automated reply is a processing activity. It is worth being able to say what triggered it, what was sent, and why — which is an argument for a system that records its refusals as well as its sends, rather than one that only logs success.

How the mechanics work on the channel we do run

PostEngage answers Instagram comments and DMs. There is no WhatsApp in the product. The parts that correspond to the above, and that would carry across:

A data request produces a downloadable export. Erasure is a separate operation walking a fixed list of tables in a fixed order — and it is the same list that drives the export, so what you can download and what gets deleted cannot drift apart. Staff access is by named account, and administrative actions are written to an append-only record by the same guard that authorises them.

None of that makes anybody compliant. It makes the requests answerable, which is the part a vendor can honestly own.

What to do before you need it

Write down, on one page: what you collect, why, who can read it, how long it stays, and who you would ask if somebody exercised a right tomorrow. Most businesses discover during that exercise that they are keeping several things for no reason at all, and deleting those is the single fastest way to reduce the surface.

If your customers are in India rather than the EU, the DPDP post is the closer fit. For the inventory question — what this channel actually generates — that is here.