The not-so new Privacy Principles


The not-so new Privacy Principles

Issue 18, August 2014

There has been has been a lot of press around the new changes the Privacy Act 1998 that came into force on 12 March 2014 and in this article, we look at some common themes that may affect organizations.

There has been a lot of press around recent changes to the Privacy Act 1998 (the Act) that came into effect in March this year, including reports that many organisations were not ready for the changes.

It should be remembered, however, that the majority of the Australian Privacy Principles (APPs) are generally not new, and have been around, albeit in their original ‘information’ or ‘national’ designations, for a number of years. For example, the use of reasonable security safeguards to protect against loss, unauthorised access, use, modification or disclosure, and other misuse of data has been required since the legislation was first enacted in 1988.

Companies cannot expect that being ‘only slightly late’ to meet the APPs, will be an acceptable reason not to comply – at least certainly not for those that have been around a while.

As the Act is principle-based, there is room for a large variance in interpretation. This provides the benefit of flexibility across a wide range of organisations with varying volumes and sensitivity of personal data. Organisations with large volumes and/or sensitive data, for example, would generally be expected to have more stringent data practices and procedures in place.

However, this variance has also led to a lot of questions from those tasked with the responsibility of complying with the Act in terms of what is ‘reasonable’. Certainly in countries that have already gone through similar changes (i.e. new requirements and greater powers of enforcement), organisations have typically been trying to position themselves where they can defend their actions should the worst happen and they experience a breach.

From our work on privacy related issues – with organisations in Australia and internationally – a number of common themes have emerged.

De-identified personal data that may not on its own be classed as personal data, can easily become identifiable data again if people who have access to it also have access to personal identifiable data, or do not appropriately segregate the storage of the two data types. It is important to consider how an organisation manages and maintains the segregation of these data types, from both system and user perspectives.

De-identified data bridge problem

This has generated major discussion in Australia as organisations attempt to locate all data that is disclosed internationally, both internally and externally, and decide whether they list this in their publicly available privacy policy information.

We are already seeing examples of varying transparency among organisations in relation to this information – those that take steps to make sure these locations meet the Act’s requirements and/or protect personal data, as well as those that request consent that they will not take responsibility for personal data in these locations.

Does being more transparent and taking responsibility for protecting data overseas create more trust from a customer perspective?

Cross border disclosure

Spreadsheets are still widely used for analysing volumes of personal data, and we expect this trend will continue. But organisations also need to take steps to secure personal information in these files. Questions to ask to aid in the protection of personal data on these and similar file types, include:

  • Does the file need to be created in the first place?
  • Is it required to be retained after use?
  • Do users need to use this file outside the office environment (i.e. by mobile workers who might need to access it)?

Use of spreadsheets

The ease and speed of setting up a Cloud service has huge appeal, and this is being utilised across many organisations. But from a privacy perspective this creates opportunity for personal data to be shared across other infrastructure and users, without the upfront due diligence that may have existed by using the traditional [internal] IT approach.

Organisations need to carefully consider how they control privacy requirements for Cloud projects. They should look back at how recent Cloud services were procured, and identify the common teams and individuals involved so they can put in place key checkpoints that ensure important privacy validation questions are asked before the project goes live, or make key decisions that could impact personal information protection.

Use of the Cloud

Although an organisation’s privacy policy provides guidance externally, it isn’t necessarily aimed at guiding employees with the management of internal personal data. Employees need specific guidance on internal privacy policies so they know how to adopt these into their own roles. There is often a gap in formally defining the procedures internally, and varying degrees of success in making individuals aware of the privacy practices and procedures they should be adhering to.

Awareness of procedures and practices

Following a PIA process to both add-in and justify any privacy requirements is crucial to improving privacy take-up and embed it into all new projects and change. There may be a fear about the potential overhead a PIA could bring, however it is important to remember the objective of the PIA is to help ask the questions that lead to the correct controls being put in place for projects and change involving personal data. It is important that the process used for this is simple, but also flexible, based on the amounts or type of personal data involved.

In conclusion, regardless of an organisation’s level of compliance with the Act, it is important to ask the following:

  • Do employees know the privacy practices and procedures they should be following?
  • Is the organisation aware how its employees use personal data and where this is stored?
  • Is the impact of privacy now embedded into all new projects and change decisions involving personal data?
  • Is the organisation in a defensible position in the event of a breach – can it demonstrate actions and protections in place were reasonable?

Embedding Privacy Impact Assessments (PIA) into business as usual

Did you find this useful?