GDPR is here

If the recent flurry of emails from organisations sending privacy policy updates didn’t tip you off, the new EU General Data Protection Regulation (GDPR) commences today.

Reading every one of those emails (something even those of us in the privacy world struggle with), might give you the impression that there’s a standard approach to GDPR compliance. But the truth is that how your organisation has (hopefully) prepared for GDPR, and how it will continue to improve its privacy practices, is highly variable.

We’ve covered the GDPR at length on this blog, and a collection of links to our various articles is at the bottom of this post– but first, we’d like to set out a few thoughts on what the GDPR’s commencement means in practice.

Remember the principles

If the GDPR applies to your organisation, you’ve presumably taken steps to prepare for the requirements that apply under the new privacy regime. Among these are new requirements relating to data breach notification, as well as new rights and freedoms for individuals whose personal data you may be processing.

One aspect of GDPR that has received plenty of attention is the new penalties, which can be up to 4% of an organisation’s annual turnover, or 20 million Euros (whichever is greater). Certainly, those numbers have been very effective in scaring plenty of people, and they may cause you to check once again whether your organisation fully meets the new requirements under the GDPR.

However, the reality isn’t quite so straightforward (or scary). Much of the GDPR is principles-based, meaning that there isn’t always a single way to comply with the law – you need to take account of your organisation’s circumstances and the types of personal data it processes to understand where you stand in relation to GDPR’s requirements.

Although we don’t expect EU supervisory authorities to provide an enforcement ‘grace period’, we’re also of the view that enforcement activities will ramp up gradually. The authorities understand that, for many organisations, GDPR compliance is a journey. Those organisations that can demonstrate they’ve taken every reasonable step to prepare for GDPR, and which have a plan for continuing to improve their privacy compliance and risk programs, will be far better placed than those that have done little or nothing to get ready for the new law.

If your organisation still has work to do to comply with the GDPR, or you want to continue improving your organisation’s compliance and risk program (and there is always more to do!), there is plenty of help available to help you navigate GDPR and understand how it applies to your organisation.

Our previous coverage of the GDPR

Tim compares Australia’s Privacy Act with the GDPR

Melanie spoke to Bloomberg about driving competitive advantage from GDPR compliance

Head to Head: the GDPR and the Australian Privacy Principles (Part 1 and Part 2)

A Lesson in Data Privacy: You Can’t Cram for GDPR

Facebook and Cambridge Analytica: Would the GDPR have helped?

5 things you need to know about GDPR’s Data Protection Officer requirement


If you enjoyed this and would like to be notified of future elevenM blog posts, please subscribe below.

5 things you need to know about GDPR’s Data Protection Officer requirement

This article was originally published in issue #83 of Privacy Unbound under the title ‘5 Questions about DPOs’. Privacy Unbound is the journal of the International Association of Privacy Professionals, Australia-New Zealand (iappANZ).

1. What is a ‘DPO’, anyway? What are they even supposed to do?

In a nutshell, the Data Protection Officer (DPO) is a senior advisor with oversight of how your organisation handles personal data.

Specifically, DPOs should be able to:

  • inform and advise your organisation and staff about their privacy compliance obligations (with respect to the GDPR and other data protection laws)
  • monitor privacy compliance, which includes managing internal data protection activities, advising on data protection impact assessments, training staff and conducting internal audits
  • act as a first point of contact for regulators and individuals whose data you are handling (such as users, customers, staff… etc.) (Art. 39(1)).

2. But we’re not based in Europe, so do we even need one?

Well, even if you aren’t required to have one, you should have one. If you’re processing, managing or storing personal data about EU residents, you’ll need to comply with the requirements of the GDPR – this is one of those requirements, whether you’re based in the EU or not.

Specifically, the GDPR requires that you appoint a DPO in certain circumstances (Art. 37(1)).

These include if you carry out ‘large scale’ systematic monitoring of individuals (such as online behavioural tracking).

You’ll also need to appoint a DPO if you carry out ‘large scale processing of personal data’, including:

  • ‘special categories of data’ as set out in article 9 – that is, personal data that reveals racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric identifiers, health information, or information about person’s sex life or sexual orientation.
  • data relating to criminal convictions and offences (per Art. 10).

The Article 29 Working Party has stated[1] that ‘large scale’ processing could include, for example, a hospital processing its patient data, a bank processing transactions, the analysis of online behavioural advertising data, or a telco processing the data required to provide phone or internet services.

Even if you don’t fit into one of these categories, you can still appoint a DPO in the spirit of best practice, and to ensure that your company is leading from the top when it comes to privacy.

In this respect, New Zealand is already ahead of the game. Entities covered by the New Zealand Privacy Act are already required to have a privacy officer, and they largely fulfil the same functions as a DPO.[2] However, they’ll still need to meet the other DPO requirements; see below.

While Australia hasn’t made having a privacy officer an express requirement for the private sector, the Office of the Australian Information Commissioner recommends that companies appoint a senior privacy officer as part of an effective privacy management framework.[3]

Government agencies aren’t off the hook

Being Public Service will not save you. Public authorities that collect the information of EU residents are also required to have a DPO (Art. 37(1)).

It’s worth noting that Australian Government agencies will need to appoint privacy officers and senior privacy ‘champions’ under the Australian Government Agencies Privacy Code,[4] which comes into force on 1 July 2018. Agency Privacy Champions may also be able to serve as the DPO.

As New Zealand Government agencies already have privacy officers, the only question they must answer is whether their privacy officer meets the other DPO requirements; see below.

3. OK, fine. We get it. We need a DPO. Who should we appoint?

The DPO needs to be someone that reports to the ‘highest management level’ of your organisation; that is, Board-level or Senior Executive (Art. 38(3)).

They’ll need to be suitably qualified, including having expert knowledge of the relevant data protection laws and practices (Art. 37(5)).

The DPO also needs to be independent; they can’t be directed to carry out their work as DPO in a certain way, or be penalised or fired for doing it (Art 38(3)). You’ll also need to ensure they’re appropriately resourced to do the work (Art. 38(2)).

If you’re a large organisation with multiple corporate subsidiaries, you can appoint a single DPO as long as they are easily accessible by each company (Art. 37(3)).

You can appoint one of your current staff as DPO (Art 37(6)), as long as their other work doesn’t conflict with their DPO responsibilities (Art. 38(6)). This means that you can’t have a DPO that works on anything that the DPO might be required to advise or intervene on. That is, they can’t also have operational responsibility for data handling. This means you can’t, for example, appoint your Chief Security Officer as your DPO.

4. But that means we can’t appoint any of our current staff. We can’t take on any new hires right now. Can we outsource this?

Yes, you can appoint an external DPO (Art 37(6)), but whoever you contract will still need to meet all of the above requirements.

Some smaller companies might not have enough work to justify a full-time DPO; an outsourced part-time DPO might be a good option for these organisations.

It might also be hard to find qualified DPOs, at least in the short term; IAPP has estimated that there will be a need for 28,000 DPOs in the EU.[5] A lot of companies in Australia and New Zealand are already having trouble finding qualified privacy staff, so some companies might have to share.

5. This all seems like a lot of trouble. Can we just wing it?

I mean, sure. If you really want to. But under the GDPR, failure to meet the DPO obligations may attract an administrative fine of up to €10 million, or up to 2% of your annual global turnover (Article 83(4)). Previous regulatory action in the EU on privacy issues has also gained substantial media attention. Is it really worth the risk? Especially given that, in the long run, having robust privacy practices will help you keep your users and your customers safe – having an effective DPO may well save you money.

[1] http://ec.europa.eu/information_society/newsroom/image/document/2016-51/wp243_annex_en_40856.pdf

[2] S23, Privacy Act 1993 (NZ); http://www.legislation.govt.nz/act/public/1993/0028/latest/DLM297074.html

[3] https://www.oaic.gov.au/agencies-and-organisations/guides/privacy-management-framework

[4] https://www.oaic.gov.au/privacy-law/privacy-registers/privacy-codes/privacy-australian-government-agencies-governance-app-code-2017

[5] https://iapp.org/news/a/study-at-least-28000-dpos-needed-to-meet-gdpr-requirements/


If you enjoyed this and would like to be notified of future elevenM blog posts, please subscribe below.

Our view on APRA’s new information security regulation

For those of you who don’t work in financial services and may not know the structure associated with APRA’s publications, there are Prudential Practice Guides (PPGs) and Prudential Standards (APSs or CPSs). A PPG provides guidance on what APRA considers to be sound practice in particular areas. PPGs discuss legal requirements but are not themselves legal requirements. Simply put, this is APRA telling you what you should be doing without making it enforceable.

On the other hand, APSs and CPSs are regulatory instruments and are therefore enforceable.

Until now, those working within a cyber security team at an Australian financial services company had PPG 234 – Management of security risk in information and information technology (released in 1 February 2010) as their only reference point as to what APRA were expecting from them in regard to their cyber security controls. But things have moved on a fair bit since 2010. Don’t get us wrong, PPG 234 is still used today as the basis for many ‘robust’ conversations with APRA.

APRA’s announcement

That leads us to the Insurance Council of Australia’s Annual Forum on 7th March 2018. It was at this esteemed event that APRA Executive Board Member Geoff Summerhayes delivered a speech which noted:

“APRA views cyber risk as an increasingly serious prudential threat to Australian financial institutions. To put it bluntly, it is easy to envisage a scenario in which a cyber breach could potentially damage an entity so badly that it is forced out of business.

“….What I’d like to address today is APRA’s view on the extent to which the defences of the entities we regulate, including insurers, are up to the task of keeping online adversaries at bay, as well as responding rapidly and effectively when – and I use that word intentionally – a breach is detected”

Summerhayes then went on to announce the release of the consultation draft of CPS 234 – Information Security. Yeah, actual legislative requirements on information security.

So what does it say?

Overall there are a lot of similarities to PPG 234 but the ones that caught our eye based upon our experience working within financial services were:

Roles and responsibilities

  • “The Board of an APRA-regulated entity (the Board) is ultimately responsible for ensuring that the entity maintains the information security of its information assets in a manner which is commensurate with the size and extent of threats to those assets, and which enables the continued sound operation of the entity”. – Interesting stake in the ground from APRA that Boards need to be clear on how they are managing information security risks. The next obvious question is what reporting will the Board need from management for them to discharge those duties?

Information security capability

  • “An APRA-regulated entity must actively maintain its information security capability with respect to changes in vulnerabilities and threats, including those resulting from changes to information assets or its business environment”. – Very interesting. There is a lot in this provision. First, there is a push to a threat based model, which we fully endorse (see our recent blogpost: 8 steps to a threat based defence model). Next, there is a requirement to have close enough control of your information assets to determine if changes to those assets somehow adjust your threat profile. Definitely one to watch. That brings us nicely to the following:

Information asset identification and classification

  • “An APRA-regulated entity must classify its information assets, including those managed by related parties and third parties, by criticality and sensitivity. Criticality and sensitivity is the degree to which an information security incident affecting that information asset has the potential to affect, financially or non-financially, the entity or the interests of depositors, policyholders, beneficiaries, or other customers”. – This really is a tough one. From our experience, many companies say they have a handle on this for their structured data with plans in place to address their unstructured data. In our experience however, very few actually do anything that would stand up to scrutiny.

Implementation of controls

  • “An APRA-regulated entity must have information security controls to protect its information assets, including those managed by related parties and third parties, that are implemented in a timely manner”. – Coming back to the previous point, there is now a requirement to have a clear line of sight of the sensitivity of data, this just adds to the requirement to build effective control over that data.
  • “Where information assets are managed by a related party or third party, an APRA-regulated entity must evaluate the design and operating effectiveness of that party’s information security controls”. – Third party security assurance is no longer a nice to have folks! Third party risk is referenced a couple of times in the draft, and so definitely seems to be a focus point. This will be very interesting as many companies struggle getting to grips with this risk. The dynamic of having to face into actual regulatory obligations however, is a very different proposition.

Incident management

  • “An APRA-regulated entity must have robust mechanisms in place to detect and respond to information security incidents in a timely manner. An APRA-regulated entity must maintain plans to respond to information security incidents that the entity considers could plausibly occur (information security response plans)”. – We love this section. A very important capability that often gets deprioritised when the dollars are being allocated. Whilst the very large banks do have mature capabilities, most do not. Pulling the ‘Banks’ industry benchmark data from our NIST maturity tool we see that for the NIST domain Respond, the industry average is sitting at 2.39. So in maturity terms it is slightly above Level 2 – Repeatable, where the process is documented such that repeating the same steps may be attempted. In short, many have a lot to do in this space.

Testing control effectiveness

  • “An APRA-regulated entity must escalate and report to the Board or senior management any testing results that identify information security control deficiencies that cannot be remediated in a timely manner, to enable an assessment and potential response by the Board or senior management to mitigate the exposure, as appropriate”. – Yep, we also love this. Putting formal requirements around the basic principle of ‘fix what you find’! The key message from us to Boards and senior management is make sure you are clear on what is in/out of scope for this testing and why.
  • “Testing must be conducted by appropriately skilled and functionally independent specialists”.- The Big 4 audit firms will be very excited about this one!

APRA Notification

  • “An APRA-regulated entity must notify APRA as soon as possible, and no later than 24 hours, after experiencing an information security incident”. –  Eagle-eyed readers will spot that this reflects mandatory data breach obligations that recently came into force under the Privacy Act on 22 February. The Privacy Act requires entities that experience a serious breach involving personal information, to notify the OAIC and affected individuals ‘as soon as practicable’ after identifying the breach. Another example of how companies now have to contend with notifying multiple regulators, on different time-frames. 

Conclusion

CPS 234 is just a draft, and ultimately the final product may be vastly different. Nevertheless, we feel APRA’s approach is a positive step to drive awareness of this significant risk, and one which will hopefully be used to baseline the foundational cyber security capabilities noted within. Well done, APRA!

Consultation on the package is open until 7 June 2018. APRA intends to finalise the proposed standard towards the end of the year, with a view to implementing CPS 234 from 1 July 2019.

Link to the consultation draft.


If you enjoyed this and would like to be notified of future elevenM blog posts, please subscribe below.

In Privacy Awareness Week, will Australia follow the GDPR?

Last week, the headlines told us that the senate backs GDPR style laws in Australia.

But what does this really mean in terms of the government’s commitment to reviewing privacy in Australia?

This does not (necessarily) mean the law will be reviewed

In short, it means very little.  The senate’s support of senator Jordon Steele-John’s notice of motion calling on the Government to consider the impact of our current privacy laws on Australians and look to the GDPR as a potential model for privacy protections for Australians holds no commitment as the senate cannot commit the government to action.

What it does signify is something very big and that is, a shift in the willingness of the senate to stand behind the Greens’ position that Australian privacy laws must be scrutinised.  Just two months ago, senator Steele-John put forward a very similar notice of motion and it was shut down, as were a couple of other privacy related motions.

Why did this one pass? (What has changed)

There are a few likely reasons why this one passed.  Putting aside matters of semantics and the politics of calling on government to subject itself to tighter scrutiny, (which was the case in motions no 749 and no 786), there is one material reason why this motion passed.

In the last two months, consumers have started to wake up to something we privacy professionals have worried about for a while – and that legal compliance is not enough and can, in fact, be damaging if ethical behaviours and transparent practices are perceived to be lacking.

There has been an enormous groundswell in Australia over the last two months, with both Facebook Cambridge Analytica and Commonwealth Bank blitzing the press with actions they have taken – or not taken – which although arguably lawful, have not met public perceptions of fairness and ethics.  Put simply, community expectations have surpassed legal standards.

So, senator Steele-John had his day, and time will tell whether this will serve as a prompt for government to call for a review of Australian privacy law in view of the GDPR.

There are plenty of other reasons why GDPR compliance makes sense, but we’ll leave that to a future blog.

Happy Privacy Awareness Week!


If you enjoyed this and would like to be notified of future elevenM blog posts, please subscribe below.