Love.Law.Robots.

Love.Law.Robots. is moving!

You're browsing the original version of the Love.Law.Robots. Check out the new site. It's prettier and packs loads of new features!

PDPC raises the bar on third party due diligence

Featured Image `

One of the latest, in what now seems to be a monthly release schedule, PDPC’s decisions may raise some eyebrows for careful readers. In Zero1 Pte. Ltd. and XDEL Singapore Pte. Ltd. [2019] SGPDPC 37, a telco and its courier services provider were penalised $4,000 and $7,000 respectively. XDEL had implemented a notification page which mistakenly discloses personal data of customers receiving SIM cards from Zero1. By entering dummy information into a URL, a hacker could access the personal data of many customers. Clearly, XDEL did not implement this feature well.

Then it gets interesting. Zero1 highlighted they did not have the technical expertise to deal with this risk. One of their representations puts it bluntly: it is not “reasonable” to expect Zero1 to audit the website and pinpoint this bug to XDEL.

Reasonable security arrangements in this case would entail minimally making an effort to identify the possible risks and seeking assurance that the data intermediary had taken steps to protect against those risks.

Zero1 Pte. Ltd. and XDEL Singapore Pte. Ltd. [2019] SGPDPC 37 at [13]

The PDPC did not agree. “… what is required is not technical oversight but an identification of foreseeable risks, and then requiring XDEL to take reasonable measures to address them” Zero1 should have identified the risk that someone could amend the URL and use it to retrieve personal data. Then Zero1 would have spoke to XDEL and dealt with it.

Thing 1: You don’t “need” technical expertise? You need a DPO.#

I might have to rewrite this post quite a bit. Minimal may no longer mean putting a data protection clause into a service agreement and expecting service providers to not screw up. Rather, the PDPC appears to suggest that “obvious” vulnerabilities such as this one needs to be identified and addressed.

Was a failure to validate input obvious? It depends on your background. If you regularly read PDPC decisions, you might have groaned. A web developer might feel sorry and briefly check his own code. If you don’t know what a REST application is, I bet you don’t know you could do all this “hacking” with just your web browser.

I strongly suspect the persons involved aren’t so tech savvy. Unfortunately, the PDPC is telling off the persons involved that they should have known better.

Here’s another bitter point: the PDPC squandered an opportunity to sell the data protection officer profession. If someone familiar with data protection was involved in the project, this bug might have been pointed out. The DPO might not have discovered this particular bug, but it would go far in proving that there was minimal effort. Given the PDPC’s focus on developing a DPO profession in Singapore, this would have been a real life case study of its benefit.

Thing 2: From Hindsight to Foresight#

Here’s why this decision feels uncomfortable to me. Companies employ service providers to perform a better job than they would in-house. Sometimes, better service providers suggest innovative solutions like a online notification page. A better job also means less direct oversight is needed because the service provider know better,

However, if employing a service provider increases exposure to risk which you cannot control, I would think harder about going ahead with one.

It is difficult for a regulator to balance promoting compliance and highlighting risk. The gigantic SingHealth decision was convincing in explaining how and to what extent both organisations were liable, but the rationale is not so convincing here.

I believe that the difference is that this decision focused too much on what was wrong in hindsight, whereas SingHealth explained how the planning and the implementation of the compliance structures failed, ie. failing in foresight. For example, we don’t really know how the organisation and the contractor divided their responsibilities. Did the organisation evaluate the contractor’s capabilities? Were they involved in the planning, testing and implementation of the feature? If they did nothing but put in a contract clause, then there’s hardly evidence of technical naivete, but of carelessness.

Thing 3: Let’s move away from fines please#

Fines grab headlines. Fines are easy to understand. I love numbers, and I focus on them all the time.

However, quite frankly, they are (and will be in Singapore for quite some time) trifling. What’s a $4,000 fine to a telco? Data Protection fines in Singapore are not intended to cripple an organisation, but to signal the importance of compliance. In due course, especially when an organisation know that data breaches are always possible, fines will be covered by insurance.

In order for the PDPC to develop the DPO profession and to have more “bite”, I firmly believe that fines are not the best way to go about it. Instead, a creative use of directions will be far more effective than a fine.

For now, directions are used to force an organisation to deal with a data breach. In this decision, since the organisation have rectified its webpage, no “further directions relating to the breach are issued”. As such, many PDPC decisions suggest that the work ends when the organisation has been “punished” for the data breach. However, this deals with a problem but hardly its root cause.

A more creative use of directions focuses on an organisation’s compliance structure, quite like the FCPA. I know this means we would learn more about the background to a data breach. However this would make PDPC decisions far more useful to DPOs. Being held in contempt of a court order would also surely be more painful than a fine. There’s already precedent when an organisation has no data protection policies. Therefore, an organisation which does nothing but put an indemnity clause in its contract would not be a new place.