Someone Asks for Their Data. Would Anyone in Your Company See It?

A request landed in a DPO inbox I look after. A former customer of the company wanted to know what personal data it still held on him.

I read it and forwarded it to the right person in HR the same day. That was the whole job. Unremarkable.

But it only worked because the request had somewhere to land. A dedicated address, monitored, with someone whose job was to read it and pass it on.

That last part is what most companies are missing.

The failure point isn't the one you'd expect

When people picture an access request going wrong, they picture a refusal. Someone asks for their data, the company says no, and there's an argument about it.

That's rarely what happens.

Far more often, the request simply arrives somewhere quiet. A general info@ inbox. A "contact us" form feeding a mailbox three people half-watch. Someone sees it, assumes it's meant for a colleague, and moves on.

Nobody refused it. Nobody is counting the days. It just has no owner.

By the time it surfaces — if it surfaces — the goodwill is gone, and sometimes the deadline with it.

Why it slips

It slips for the same reason a lot of data protection work slips. The task is real, but it belongs to no one in particular.

In most SMEs, whoever handles data protection is also doing three other jobs. The public contact is often a shared inbox nobody was told to own. A request comes in looking like an ordinary customer query, gets triaged as "not mine", and sits.

There's no bad intent anywhere in that chain. Everyone who touched it had a reasonable reason to think it was someone else's.

That's exactly why it's dangerous. A problem that is nobody's fault is also nobody's job to fix.

What the law actually expects

Here's where the quiet inbox becomes a real risk.

Under the PDPA, you have 30 calendar days to respond to an access request. If you can't meet that, you have to tell the person, in writing, when you will. The clock starts when the request arrives — not when someone inside the company finally notices it. (PDPC guide to handling access requests)

You also can't refuse simply because the request is inconvenient. The PDPA sets out specific, limited grounds for not providing access — the main ones are listed in the Fifth Schedule — and there are separate situations where you must not give access at all, such as where doing so would reveal someone else's personal data. "We're busy" isn't on the list.

And if you ignore a request, or refuse it without a valid reason, the person doesn't simply go away. They can apply to the PDPC for an access review. At that point a missed email has become something you're explaining to the regulator.

None of this needs bad behaviour on your part. It only needs the request to land somewhere no one was watching.

What to check in your own business

You don't need a project for this. You need to answer a few honest questions about what happens when a request arrives.

  • Is there a single, dedicated contact point for data protection requests — not a general info@ that everyone and no one owns?
  • Is that inbox actually monitored, by a named person, on a known schedule?
  • When a request comes in, is there a clear path to escalate it to whoever can act — the way a request to a DPO inbox should route on to HR, IT or operations?
  • Is the request logged with the date it arrived, so the 30-day clock is visible and not living in one person's memory?
  • And the real test: if that person is on leave, or leaves the company, does the request still get seen?

If you're not sure of the answers, that's the gap. Not your ability to fulfil a request — most are straightforward once they reach the right desk — but whether they reach it at all.

The unglamorous fix

The fix isn't a bigger compliance programme. It's making sure external requests have one reliable way in, one clear way onward, and that they stay visible until someone acts.

That's the part we built into Veritos. External data protection requests come into a dedicated inbox, and Vera reads each one as it arrives, works out what it is, and flags it to the DPO. The DPO doesn't have to be sitting on the inbox to know a request has come in.

It doesn't stop at the alert. The request becomes a visible task rather than a message someone has to remember. A DPO who's also running HR or operations can have a genuinely busy week, and the request still sits there in plain view until it's dealt with. Nothing depends on it staying in one person's head.

To be clear about what this is and isn't: Veritos doesn't fulfil the request for you. You still decide what to provide and when. What it does is make sure the request is seen, understood and kept in front of you from the moment it lands — which is precisely the part that quietly fails in most companies.

The request that went nowhere didn't fail because someone made the wrong call. It failed because it never reached anyone who could make one.