The Personal Data Protection Act (PDPA) is Singapore’s data privacy regulation. In this blog post, we look at some of the differences between PDPA and European Union’s General Data Protection Regulation (GDPR), and the general perception and applicability of PDPA.
Privacy regulation tends to be a secondary consideration for many organisations dealing with the Monetary Authority of Singapore’s (MAS) regulation – an especially common situation with FinTech start-ups. For some, that is justified as they are purely Business-to-Business (B2B) and don’t handle any personal data other than staff information in an HR system. PDPA tends to be more forgiving than the European Union’s GDPR for business relationships, so there is less pressure to be compliant. Prioritising MAS compliance is also understandable for FinTech start-ups given their limited time and budget, and the more severe penalties for MAS non-compliance.
Some organisations believe that they are probably sufficiently PDPA compliant because they are already MAS compliant. However, MAS regulation focuses on data security and loss, while PDPA focuses on how data is collected and used. Two-sides of the same coin and, arguably, equally important.
PDPA Update in February 2021
This February, the PDPA was updated with a stronger focus on compliance and consequences. A fine of up to 10% Singapore-derived revenue (not profit!) can now be used as a sizeable stick to ensure organisations comply with the privacy regulations. The ‘up to’ of that statement is quite crucial. The exact amount is not black and white but depends on many factors. Culpability, wilful neglect, following guidelines, procedures being adequately socialised, and reporting the breach within three days are just some of the things that the PDPA commission will look at when determining an appropriate fine to levy. For smaller businesses with less revenue, the cost impact outside of the fine can also be significant. Small-to-medium enterprises (SMEs) can expect around S$ 50,000 in legal and other costs to deal with a breach; larger SMEs S$ 200,000 or more, and considerably more for multinational corporations (MNCs).
Note that it is not wise to disregard anything the PDPA commission puts forward as ‘guidelines’ because compliance with these will still be assessed in the event of a breach. Non-compliance, and in the absence of more stringent guideline adherence such as GDPR, can be a factor in determining the fine to be levied.
PDPA now places more emphasis on the requirement that processes and policies should not just be for show. Having a document with procedures is inefficient on its own; they want to see that these documents have been socialised with the organisation and that employees know how to respond to events. This will be scrutinised in the event of a breach and when determining the fine to be levied against the organisation. The data breach plan is a critical component of these procedures. This document should detail likely scenarios with risk assessments and response plans. Relevant staff need to be aware of the plan and be provided with any necessary training to execute on it.
Statistically, breaches are most likely to happen Friday or Saturday night or early morning. Relevant team members need to be on-call and available on the weekend in case any breach should occur. Practice drills for executing scenarios from the plan are also strongly recommended. Evidence of having done this regularly could help reduce the fine in the event of a breach.
Derived Personal Data
One aspect of personal data that is often overlooked is ‘derived personal data’. This is especially relevant to vendors collecting and tracking data and providing reports or insights to clients. It can be a pitfall to assume that the data provided cannot be used to identify a specific person and that it is therefore not considered personal data relieving them from any regulatory restrictions. Such vendors (and the clients) need to factor in that clients will have their own data sets such as on-premises security camera footage or website analytics. If it is possible to combine the two data sources and link them, for example, by dates and locations, it may be possible to derive personal identities from the combined pool of data. In this case, the data sources may still be considered personal data in the event of a breach.
PDPA or GDPR Compliance
Is it worthwhile spending time and money becoming compliant with PDPA, or is that time better spent just being compliant with GDPR? As the strictest regulation globally, complying with GDPR most likely means the organisation is compliant in most, if not all, other regions. The answer is that it depends on the organisation and its plans for growth outside of Singapore.
Becoming compliant with GDPR generally means more work for the organisation as there are several requirements that are not required for other regulations – including PDPA. This up-front investment does mean that the organisation can immediately work with users based in the EU (or California, which has similarly strict regulation) without fear of non-compliance, which can be an attractive prospect for organisations aiming for global availability.
A few points in PDPA are more business-friendly and may make it more attractive over GDPR to organisations focused on the local Singaporean market:
- Business email addresses are not considered personal data. These can be used (and abused) as much as public data. So, purely B2B businesses can often get away with having limited concerns about PDPA, at least for their business in Singapore.
- If the organisation obtained user consent for an original set of personal data uses but wishes to expand on those uses later on, there are some exemptions that permit organisations to go ahead without obtaining explicit consent for the new uses. Exemptions include the use of data for business improvements, product improvement and personalisation.
- How an organisation tracks who, what, and when data was accessed and processed is not strictly enforced in PDPA. However, how the organisation chooses to do this may be a point of consideration for the size of the fine in case of a breach.
- GDPR has very strict and specific requirements on contractual agreements between an organisation and any vendors or subcontractors it works with that access or process personal data. The PDPA approach encourages organisations to address this in their own agreements with third parties, but it does not provide any hard requirements for this. How an organisation does this is, again, something that could impact fines in case of a breach and should be introduced into contract negotiations processes when dealing with third parties.
- Requirements around international data transfer are a lot more straightforward in PDPA. While the basic premise in GDPR is relatively simple – `overseas facilities should offer the same levels of protection and compliance that the local entity does`, the specifics are no less than seven articles with detailed requirements that can be quite far-reaching and difficult to enforce for organisations.
While these are great points, one final consideration is that PDPA seems to be aligning more and more with GDPR, so there is no guarantee that the business-friendly aspects of PDPA will be retained over time. This applies especially to the currently not strictly enforced sections, such as how data access is tracked, agreements between organisations and vendors or subcontractors, and international data transfers.
Sourced would recommend any organisations that do or plan to do business outside of Singapore to try and comply with GDPR. Organisations that will remain local or have the budget to implement separate global and regional privacy regulation compliance could benefit from the more business-friendly aspects of PDPR while they are available. In either case, organisations should closely follow privacy regulations for any new updates that can impact the organisation, and PDPA should not be disregarded just because the organisation is already MAS compliant.
To find out more about the PDPA, please visit Singapore government’s PDPA site here: