Skip to main content
Skip to secondary navigation
Menu
Australian Government - Office of the Australian Information Commissioner - Home

Guidelines for developing codes

Issued under Part IIIB of the Privacy Act 1988 – Consultation draft

(PDF version 1MB)

Contents

Key terms

Part 1 – Introduction

Part 2 – Deciding and planning to develop a code

Part 3 – Request by the Commissioner to develop a code

Part 4 – Developing codes

Part 5 – Handling and reporting of privacy complaints

Part 6 – Applying for registration of a code

Part 7 – Reviewing and varying registered codes and removing registered APP codes

Appendix A – Code registration checklist

Appendix B – Code variation checklist

Appendix C – Code removal checklist


Key terms

The following terms used in these Guidelines are defined in s 6(1) of the Privacy Act 1988 (Privacy Act):

Agency; APP code developer; APP entity; Commissioner; credit provider; credit reporting body; credit reporting complaint; CR code developer; entity[1]; personal information

The following terms used in these Guidelines are also defined in the Privacy Act (other than in s 6(1)):

APP code has the meaning given in s 26C of the Privacy Act

Australian Privacy Principles is defined in s 14 of the Privacy Act as the principles set out in Schedule 1 to the Act.[2]

Codes Register has the meaning given by s 26U of the Privacy Act

CR code has the meaning given by s 26N of the Privacy Act

Organisation has the meaning given by ss 6C and 6E of the Privacy Act

Original registered code has the meaning given by ss 26J(6) and 26T(5) of the Privacy Act

Registered APP code has the meaning given by s 26B of the Privacy Act

Registered CR code has the meaning given by s 26M of the Privacy Act

The following terms used in the Guidelines are not defined in the Privacy Act:

Code means either an APP code or the CR code

Code administrator or code administration committee is a body established to oversee the operation, (including monitoring and reporting) of a code

Code developer or Code development committee means either an APP code developer or the CR code developer and is a body that has responsibility for developing and seeking approval for the registration of a code. A code development committee may form part of a code developer or may be a separate body working on the behalf of the code developer

Minister means the Commonwealth Attorney-General

Privacy complaint means a complaint about the handling of personal information and, in relation the CR code, includes credit reporting complaints.


Part 1 – Introduction

The Privacy Act and codes

1.1. The Privacy Act 1988 (Privacy Act)[3] contains 13 Australian Privacy Principles (APPs), which regulate the handling of personal information. The APPs apply to ‘APP entities', which includes most Australian, ACT and Norfolk Island government agencies and many private sector and not for profit organisations. Part IIIA of the Privacy Act regulates the handling of consumer credit-related information and applies to credit reporting bodies (CRBs), credit providers and other entities in relation to their handling of consumer credit-related information.

1.2. Part IIIB of the Privacy Act allows for the Australian Information Commissioner (the Commissioner)[4] to approve and register enforceable codes which are developed by entities, on their own initiative or on request from the Commissioner, or by the Commissioner directly.

1.3. APP entities (or a body or association representing them) are able to develop written codes of practice for the handling of personal information, called APP codes, that set out how one or more of the APPs are to be applied or complied with, and the APP entities that are bound by the code.

1.4. The Privacy Act also requires the development of a code of practice about credit reporting, called the CR code. The CR code sets out how the Privacy Act's credit reporting provisions are to be applied or complied with by credit reporting bodies, credit providers and other entities bound by Part IIIA.

1.5. Codes do not replace the relevant provisions of the Privacy Act, but operate in addition to the requirements of the Act. A code cannot lessen the privacy rights of an individual provided for in the Privacy Act.

1.6. Registered codes are disallowable legislative instruments. Entities bound by a registered code must not do an act, or engage in a practice, that breaches that code (ss 26A (APP codes) and 26L (CR code)). A breach of a registered code will be an interference with the privacy of an individual under s 13 of the Privacy Act and subject to investigation by the Commissioner under Part V of the Privacy Act.[5]

Purpose of these guidelines

1.7. Section 26V of the Privacy Act provides the Commissioner with the power to make written guidelines relating to codes.[6] The purpose of these guidelines is to provide guidance which will:

  • assist APP entities to decide whether it is appropriate for them to develop an APP code
  • clarify when the Commissioner will request an entity to develop a code, or when the Commissioner will develop a code on his or her own initiative
  • assist APP code developers and the CR code developer to develop relevant codes either on their own initiative or following a request from the Commissioner
  • outline the matters that will need to be addressed in the development and registration of a code
  • advise relevant entities on matters related to reviewing, varying and removing registered codes
  • assist APP and CR code developers that wish to include additional matters in a code, such as the coverage of exempt acts or practices, the inclusion of internal privacy complaint handling and reporting procedures.

1.8. These guidelines also assist APP and CR code developers by outlining matters that the Commissioner may consider when deciding whether to:

  • approve an application to register a new code
  • review the operation of a registered code
  • vary or remove a registered code.

Who should use these guidelines?

1.9. These guidelines should be used by entities that are:

  • considering developing a code
  • code developers who are developing a code on their own initiative or following a request from the Commissioner
  • code administrators (persons or bodies responsible for overseeing the ongoing administration of a code).

Related publications

1.10. Entities planning to develop a code are encouraged to first gain a detailed understanding of the Privacy Act, in particular, the APPs (for APP codes) and/or Part IIIA (for the CR code). Information to assist entities is available on the OAIC website.


Part 2 – Deciding and planning to develop a code

Who can develop a privacy code?

2.1 Any entity or group of entities subject to the Privacy Act, or body or association representing those entities, may develop a code and make an application to the Commissioner to have it registered.

Resource requirements

2.2 The development and implementation of a code requires a commitment of resources. The costs will vary greatly, depending, for example, on whether the code establishes internal handling and reporting of privacy complaints procedures, the size and nature of the entities covered by the code and the nature of the code itself.

2.3 In developing and implementing a code, resources may need to be allocated to the following matters:

  • investigating the need for a code
  • establishing an administrative mechanism responsible for developing the code, such as a code development committee
  • drafting the code
  • seeking legal or professional advice
  • involving all stakeholders (including consumers) in an effective public consultation
  • establishing a code administrator to oversee the operation of the code
  • maintaining a register of entities bound by the code and information about the code on a website
  • hiring and training support staff for the code administration
  • financing the development and ongoing administration of the code, including in relation to regularly reporting on, and independent reviews of, the code.

2.4 Codes that include internal privacy complaint handling and reporting procedures (see Part 5) may need additional resourcing for the following matters:

  • investigating the need for internal privacy complaint handling and reporting procedures
  • developing the procedures
  • seeking legal or professional advice
  • administering the procedures, investigating privacy complaints and external reporting
  • reviewing the privacy complaint handling procedures on a regular basis
  • advising entities bound by the registered code on the operation of the privacy complaint handling procedures

Reasons for developing a code

2.5 Some of the reasons why entities may wish to develop a code include:

  • to give entities a sense of active ownership of their privacy obligations
  • to send a positive statement to the community that a particular entity or group of entities are mindful of the privacy concerns of individuals and are pro-active in protecting their privacy rights. This can be done by adopting a code:
    • that incorporates higher standards for privacy protection than the Privacy Act requires. For example, a code which deals with acts or practices that would otherwise be exempt under the Privacy Act (see paragraphs 4.8–4.19), and
    • with vigorous privacy assurance processes (through independent audit or monitoring programs).
  • to change the culture of an entity or industry by raising awareness of privacy and introducing a compliance regime
  • to serve as a guide to privacy regulation by providing entities with a single document that incorporates all its related legislative requirements and written in a way that is applicable to a particular industry
  • to promote industry integrity that, among other things, may serve to lessen consumer demand for further regulatory intervention
  • to allow entities and industries to develop higher standards or introduce additional principles in order to comply with the privacy directives of other countries or trading partners. This will be particularly relevant to entities with global operations
  • to build trust in the use of new and emerging technologies that may impact on personal information handling practices
  • to provide clarity, certainty and satisfaction to consumers seeking redress by incorporating privacy complaint handling procedures in a code.

Assessing the need for an APP code

2.6 In deciding whether to develop an APP code, APP entities may wish to consider the following matters:

  • What are the benefits and risks for the entity or entities developing the code and all the entities that will be bound by the code?
  • Do entities want to incorporate higher standards for privacy protection than the APPs require to facilitate best privacy practice in their industry or sector?
  • Do entities need to promote cultural change in relation to privacy or build trust in new or emerging technologies that may impact on personal information handling practices?
  • Do entities have sufficient resources to develop and administer a code? Will entities bound by the code have sufficient resources to implement the code's requirements?
  • Is there an existing code that may be suitable for adoption without the need to develop a separate code?

Code governance

2.7 In most cases the Commissioner will expect entities that develop a code to have in place the governance arrangements necessary to properly develop and administer a code. Governance arrangements may include entities using a code developer or forming a code development committee or some other administrative mechanism to manage the development of a code.

2.8 Generally, code developers or code development committees are responsible for drafting a code. This includes explaining to relevant stakeholders and any interested party why the code is being developed and what it intends to achieve. A code developer and code development committee may be the same entity or they may be separate bodies which perform specific tasks during the development process.

2.9 The Commissioner generally expects that governance arrangements will also include the establishment and appropriate funding of a code administrator and / or code administration committee to oversee the regular operation of a code once it has been registered. Code administrators or code administration committees are bodies established to oversee the ongoing administration of the code, including any need for variations, the maintenance of an accessible record of code members (paragraphs 2.12–2.18), monitoring and reporting compliance (paragraphs 2.26–2.29) and instigate regular independent reviews of codes to ensure they operate effectively and remain relevant (paragraphs 7.1–7.6).

2.10 The type of governance arrangements that are ultimately adopted may depend on the circumstances of the particular code. For example, given the importance of the CR code to the credit reporting regime, and the sensitivity of credit reporting information, the Commissioner would expect the CR code to be accompanied by clearly articulated governance arrangements regarding the ongoing administration of the code. Further, where mechanisms such as code development or administrative committees are used, the Commissioner would generally expect them to be broadly representative of the entities that will be bound by the code and be transparent in their operations.

Who will be bound by the code?

2.11 It must be clear which entities (or activities of entities) are bound by a code at any given time.

Entities bound by APP codes

2.12 Under the Privacy Act, APP codes must clearly state the APP entities that are bound by the code or establish a way of identifying the APP entities bound by the code (s 26C(2)(b)). Code requirements under the Privacy Act are discussed in paragraphs 4.1–4.7.

2.13 As APP entities bound by the code may be subject to privacy complaints for not complying with the code, it is essential that the code enables entities bound by the code to be clearly identified. This may be done, for example, by listing the entities in the code itself. However, there may be situations in which it is more effective for a code to describe a way in which entities bound by the code can be identified. For example, an industry association that develops a code for all members of that association may be able to describe all association members as being bound by the code. This method may be more practical if it is envisaged that code membership will change over time.

2.14 If an APP code only describes the way in which entities that are bound by the code can be identified, the Commissioner will expect an easily accessible and up to date online record of current entities bound by a code to be maintained by the code administrator. The Commissioner expects that an application to register an APP code include a statement as to how the online record will be maintained. The Commissioner considers that failure to maintain an up to date online record of entities bound by the code would constitute a reason to remove a registered APP code. The online record should also link directly to the code.

2.15 The code administrator should ensure that the online record is accessible to all individuals by:

  • making the online record simple for individuals to follow and use
  • providing access to the online record in a variety of accessible formats.
  • allowing individuals to make contact with the entity or code administrator who is handling the online record through a variety of accessible communication channels.

2.16 This information should also be readily available to individuals who do not have access to the Internet. This could be in the form of a printed version of the online record, which is made available to individuals on request.

2.17 If the code is intended to cover an APP entity that is the parent company of a number of subsidiary companies (that are also APP entities), and it is intended that each subsidiary is to be bound by the code, either the code or the online record should include the names of all subsidiary companies that will be bound by the code. Names should include the entity's legal name and any trading names.

2.18 An organisation which is not covered by the Privacy Act but wants to be bound by an APP code will need to ‘opt-in' to being covered by the Act. Section 6EA of the Privacy Act allows a small business operator not otherwise covered by the Privacy Act to choose to be treated as an organisation, and therefore an APP entity, for the purposes of the Act.

Entities bound by the CR code

2.19 The CR code must bind all credit reporting bodies (s 26N(2)(c)).

2.20 The Commissioner also expects the CR code to bind all credit providers as well as any other entities subject to Part IIIA of the Privacy Act. However, where parts of the CR code only apply in relation to certain classes of entities subject to Part IIIA, then the CR code should specify the entities within that class, or a way of determining which entities are in that class.

Code developer representativeness

2.21 In deciding whether to register an APP code, the Commissioner will consider whether the APP code developer has demonstrated that they generally represent the APP entities that will be bound by the code. An APP code developer may be able to demonstrate this by showing that they have conducted an appropriate consultation with entities that will be bound by the code (consultation on codes is discussed in paragraphs 4.22–4.28).

Options for privacy complaint handling and reporting

2.22 A breach of a registered APP code or the registered CR code by an entity bound by the code is an interference with the privacy of an individual for the purposes of the Privacy Act.

2.23 An individual can complain to the Commissioner about an interference with their privacy. The privacy complaint would be dealt with by the Commissioner in accordance with the privacy complaint handling procedures established under Part V of the Privacy Act.

2.24 An APP code developer may choose to include procedures relating to the internal privacy complaint handling and reporting by entities bound by the APP code (see Part 5). The inclusion of these procedures can ensure a consistent approach to internal privacy complaint handling and reporting by all entities bound by that APP code and the Commissioner encourages the inclusion of these procedures in all codes.

2.25 In relation to the CR code, Part IIIA of the Privacy Act contains specific obligations, rights and procedures in relation to the handling of privacy complaints made to a credit reporting body or credit provider. The CR code should specify particular internal procedures or other internal complaint handling and reporting matters to ensure a consistent approach to managing and reporting these complaints by all entities bound by the CR code.

Monitoring and reporting compliance with a code

2.26 The Commissioner expects code developers to have in place, as part of the ongoing code governance, mechanisms for the regular monitoring and reporting by code administrators to the Commissioner of information regarding the code's effectiveness in achieving compliance from entities bound by the code. These mechanisms should include auditing for, or investigating, serious or repeated interferences with privacy[7] or systemic issues[8] related to compliance with a code. Specific reporting requirements for codes that contain internal privacy complaint handling procedures are discussed in Part 5.

2.27 In the interests of efficiency and openness, the Commissioner expects code administrators to:

  • provide, by 31 July each year, a report to the Commissioner covering the 12 month period ending on 30 June of the same year, to enable the Commissioner to include information about registered codes in the Office of the Australian Information Commissioner (OAIC)'s annual report.[9] However, serious or repeated interferences with privacy in relation to compliance with the Code should be reported as soon as the code administrator becomes aware of them
  • provide accurate, up to date and sufficient information in the report, including in relation to any systemic issues, or serious or repeated interferences with privacy that have occurred during the year, for the Commissioner, stakeholders and the general public to make a fully informed judgement on the code's effectiveness in achieving compliance from entities bound by the code. In relation to codes which have internal privacy complaint handling procedures, if there are any privacy complaints made by individuals to the entities bound by the code about non-compliance with the code, this will need to be included in the report (see Part 5)
  • where information regarding a code's effectiveness in achieving compliance has significantly changed from the last report, provide a description of the change and the reasons for the change
  • publish the report online.

2.28 If reports are not provided or they indicate a lack of compliance with a registered code, this may inform the Commissioner's decision to review or to vary or remove the registered code (see Part 7).

Getting help – what the Office of the Australian Information Commissioner can do

2.29 The Commissioner expects code developers to notify the Commissioner of their intention to develop a code. The Commissioner also expects code developers to keep the Commissioner informed throughout the code drafting process.

2.30 In the first instance, code developers should consult these guidelines, the Privacy Act and related publications. Additionally, OAIC staff may be able to provide some general (non-legal) advice to code developers and code administrators. However, any advice would not fetter the discretion of the Commissioner in deciding whether to register the code.

2.31 If requested the OAIC will provide a link from its website when a code developer is consulting on its draft.

2.32 To avoid a potential conflict of interest between providing advice and approval of a code by the Commissioner, OAIC staff will not participate on code development or administrative committees.


Part 3 – Request by the Commissioner to develop a code

Circumstances where the Commissioner may request the development of a code

3.1 The Commissioner may request the development of a code (ss 26E(2) (APP codes) and 26P(1) (CR code)).

3.2 The Commissioner will only request an APP code developer to develop an APP code where the Commissioner is satisfied it is in the public interest for the code to be developed. The following is a non-exhaustive list of circumstances where the Commissioner may make such a request:

  • the code would be the most effective way of resolving an identified privacy issue within a sector or industry. For example, if a particular industry has a history of privacy breaches or has been the subject of a large number of privacy complaints to the Commissioner in a short period of time
  • the code would clarify an uncertainty regarding the application of the APPs to a particular sector, industry or group of entities, eg where a new or emerging technology may impact personal information handling practices
  • the benefits of the code to the general public as a whole would outweigh any costs, including economic and efficiency costs
  • a new code is required as the Commissioner has formed the view that a registered APP code is ineffective, outof date or irrelevant but the entities bound by the code have generally expressed a desire to continue to be bound by a code.

3.3 The Commissioner may request a CR code developer to develop the CR code (s 26P(1)). Unlike the development of an APP code by the Commissioner, a public interest test does not need to be met. The CR code is a necessary part of the credit reporting regulatory scheme and it is envisaged that there will always be a CR code in place.

Request requirements

3.4 Under the Privacy Act, a request from the Commissioner to develop a code must:

  • be in writing
  • specify the period in which the code developer must comply with the request (ss 26E(3)(a) (APP codes) and 26P(2)(a) (CR code)). The period must run for at least 120 days from the date of the request is made to allow for an effective consultation to take place (consultation requirements that must be followed by code developers are discussed in paragraphs 4.22–4.28). If necessary, the Commissioner may extend the period for whatever period of time that the Commissioner considers appropriate in the circumstances (ss 26E(4)(b) (APP codes) and 26P(3)(b) (CR code)).
  • inform the code developer that a code is a binding instrument which contains enforceable obligations on code members once registered (ss 26E(3)(b) (APP code) and 26P(2)(b) (CR code))
  • be publicly available as soon as practicable after the request to the code developer is made (ss 26E(7) and 26P(5)). A copy of the request will be published on the OAIC website.

3.5 The Commissioner may, in the request, specify one or several matters that a code must deal with and set out the entities or class of entities that should be bound by the code (ss 26E(5) and 26P(4)). While it is not mandatory for the Commissioner to specify any such matters in the request, the Commissioner will generally provide guidance on these matters.

3.6 In relation to requests for developing APP codes, the Commissioner's request cannot require the requested code to deal with exempt acts or practices (s 26E(6)). However, APP code developers can, on their own initiative, deal with exempt acts or practices, and can include such provisions in the APP code if they wish. If this occurs, the Commissioner can consider those provisions along with the rest of the code provisions when the APP code developer applies for registration of the code.

Identifying the appropriate code developer

3.7 The Commissioner's request to develop a code will specify a code developer, and will not take the form of a general public request for someone to develop a code.

3.8 An APP code developer and the CR code developer could be an entity, a group of entities, or an association or body representing one or more entities. For example, the Commissioner may conclude that the expertise required to develop a code is spread across several entities and therefore will request that they jointly develop the code.

3.9 The factors which will be taken into account by the Commissioner in identifying the appropriate code developer include whether the entity, group of entities, or association or body:

  • has the capacity to develop a code including whether they have the resources and expertise, and
  • is generally representative of the entities in the sector or industry to which the code will apply.

Development of codes by the Commissioner

3.10 Having given the code developer the opportunity to develop a code, the Commissioner has the option of developing a code (ss 26G (APP codes) and 26R (CR code)). This can occur:

  • where a code developer has failed to comply with a request to develop a code, or
  • where a code developer has developed a code as requested by the Commissioner and the Commissioner has decided not to register the code.

3.11 The Commissioner's decision to register a code is discussed at Part 7.

3.12 Before the Commissioner develops an APP code, the Commissioner will satisfy him or herself that it is in the public interest to do so (s 26G(2)). In considering the public interest, the Commissioner may consider the interests of stakeholders relevant to the industry or activity to which the code will apply, the interests of segments of the public (for example people with a disability or children), as well as the public interest at large.

3.13 Any APP code developed by the Commissioner will not cover exempt acts or practices (s 26G(2)).[10]

3.14 In developing a code, the Commissioner will undertake consultation on the code (ss 26G(3) and 26R(2)). The Commissioner will make a draft of the code publicly available on the Commissioner's website and invite public submissions on the draft code. The period in which submission may be made will be at least 28 days. Matters the Commissioner might take into account in considering whether a period longer than 28 days is necessary include:

  • the expected level of interest in the code
  • the number of expected stakeholders
  • the complexity of the code
  • the expected impact of the provisions in the code on the practices or procedures of stakeholders.

Part 4 – Developing codes

Code requirements under the Privacy Act

APP codes

4.1 An APP code developer may develop an APP code either on their own initiative or following a request from the Commissioner (ss 26E(1)and 26E(2)).

4.2 Section 26C outlines what an APP code must do and what other matters it may deal with. An APP code must:

  • be in writing
  • be about information privacy
  • set out how one or more of the APPs are to be applied or complied with
  • specify the APP entities that are bound by the code, or a way of determining the APP entities that are bound by the code
  • set out the period during which the code is in force (which must not start before the day the code is registered on the Code Register).

4.3 An APP code is not required to deal with all the APPs, although it may do so, but it must deal with at least one APP. An APP code may also impose additional privacy-related obligations that go beyond the requirements of an APP (paragraphs 4.8–4.19).

4.4 Generally, an APP code will commence operation on registration. However, a code developer may specify a time for commencement after registration of the code. Similarly, a code will continue to be in force until it is de-registered (see Part 7). However, a code developer may specify a period for which the code will be in force.

The CR code

4.5 The Commissioner may request a CR code developer to develop the CR code (s 26P(1)).

4.6 The CR code must:

  • be in writing
  • be about credit reporting
  • set out how one or more of the provisions of Part IIIA are to be applied or complied with
  • make provision for, or in relation to, matters required or permitted by Part IIIA to be provided for by the registered CR code
  • bind all credit reporting bodies
  • specify the entities bound by the code or specific parts of the code or specify a way of determining those entities (s 26N(2)(e)). The Commissioner expects that the CR code will bind all credit providers and other entities subject to Part IIIA in whole or in part.

4.7 The CR code is not required to deal with all the provisions of Part IIIA. However, there are provisions in Part IIIA which specify matters that must be contained in the CR code or matters which the CR code is permitted to address. The Explanatory Memorandum to the Privacy Amendment (Enhancing Privacy Protection) Act 2012 also specifies matters with which the CR code is expected to deal.[11] The Commissioner expects that the CR Code would deal with all these matters.

Other matters that may be included in a code

APP codes

4.8 An APP code may:

  • impose additional requirements to those imposed by one or more of the APPs, so long as the additional requirements are not contrary to, or inconsistent with, any of the APPs
  • cover exempt acts or practices (discussed below)
  • deal with the internal handling of privacy complaints and provide for reporting to the Commissioner about those complaints (see Part 5)
  • deal with any other relevant matters (s 26C(3)). These must be relevant to privacy in general and the APPs in particular – see paragraphs 4.20–4.21.

4.9 However, an APP code is not required to include any of the above matters.

4.10 Section 26C(4) states that an APP code may also be expressed to apply to any one or more of the following:

  • all personal information or a specified type of personal information;
  • a specified activity, or a specified class of activities, of an APP entity;
  • a specified industry or profession, or a specified class of industries or professions
  • APP entities that use technology of a specified kind.

4.11 The purpose of the code will normally dictate the types of personal information, activities, industry or technology that the code covers.

The CR code

4.12 Section 26N(3) states that the CR code may:

  • impose additional requirements to those imposed by Part IIIA, so long as the additional requirements are not contrary to, or inconsistent with, that Part
  • deal with the internal handling of privacy complaints or provide for the reporting to the Commissioner about privacy complaints (see Part 5)
  • deal with any other relevant matters (which must be relevant to credit reporting and, specifically, Part IIIA – see paragraphs 4.20–4.21).

4.13 However, the CR code is not required to include any of the above matters.

4.14 Section 26N(4) states that the CR code may be expressed to apply differently in relation to:

  • classes of entities that are subject to Part IIIA
  • specified classes of credit information, credit reporting information or credit eligibility information
  • specified classes of activities of entities that are subject to Part IIIA.

4.15 The ability for the CR code to apply differently in relation to those matters will allow sufficient flexibility for the CR code to provide detailed guidance about how the provisions of Part IIIA may be applied or complied with.

APP codes covering exempt acts or practices

4.16 Unlike codes developed by the Commissioner, an APP code developer may include obligations in an APP code that deal with certain acts or practices that would otherwise be exempt under the Privacy Act (s 26C(3)(b)).[12]

4.17 Exempts acts or practices that may be the subject of an APP Code include the handling of employee records by organisations. If a registered APP code covers exempt acts or practices, the Privacy Act will apply to those acts or practices as if they were not exempt (s 26D).

4.18 The Commissioner encourages APP code developers to consider covering exempt acts and practices as this would enable entities to protect the personal information of individuals in circumstances not otherwise covered by the Privacy Act. Including such provisions could benefit entities bound by the APP code as it would:

  • send a positive statement to the general public that they are proactive in protecting individual privacy rights by incorporating higher standards for privacy protection than the Privacy Act normally requires
  • allow for entities and industries which operate in overseas jurisdictions where higher privacy standards apply to match those higher standards in their Australian operations.

4.19 The ability for a code to cover exempt acts or practices may be a reason why entities wish to develop an APP code.

Inclusion of matters unrelated to information privacy and credit reporting

4.20 To the extent that a code developer wished to include matters that are unrelated to information privacy or credit reporting when developing a code, these matters would not form part of the code registered by the Commissioner. If a code developer wishes to associate these matters with a code, the Commissioner would expect them to be clearly identified and dealt with in a document separate to the code. That document would not form part of the code submitted to the Commissioner for approval and registration, nor would it form part of any registered code and those matters would not be binding under the Privacy Act on entities bound by the code.

4.21 Despite not forming part of the code, it is expected that code developers inform the Commissioner during the development of the code that they intend to include other matters unrelated to information privacy and credit reporting in a separate document. This is to ensure that the Commissioner is aware of unrelated matters that may have an impact on, or provide the context for, the personal information handling practices of particular sectors or industries that will be bound by the code.

Consultation on codes

4.22 Under the Privacy Act, code developers are required to undertake a public consultation before making an application to register a code (ss 26F(2) (APP codes) and 26Q(2) (CR code)). Specifically, a code developer must:

  • make a draft of the code publicly available, for example on a website of the code developer or some other suitable website
  • invite the public to make submissions to the developer about the draft within a specified period (which must run for at least 28 days) to ensure that members of the public have sufficient time to consider the draft of the code[13]
  • give consideration to any submissions made within the specified period.

4.23 The Commissioner expects the code developer to bring the draft of the code to the attention of stakeholders to ensure that they are aware of the public consultation period. Relevant stakeholders include:

  • entities that may have an interest in being bound by the code
  • individuals and entities that may be impacted by the code
  • relevant community and industry associations.

4.24 The appropriate way to bring the code to the attention of relevant stakeholders will depend on the circumstances but will usually include:

  • placing the code or information about the code online
  • public notices in newspapers and industry publications
  • direct engagement with relevant government agencies, industry groups and consumer representatives
  • requesting the OAIC to include a link on its website to the consultation.

4.25 When formulating a consultation, the Commissioner expects code developers to ensure the following matters:

  • that participation in the consultation is accessible to all interested stakeholders
  • that full and proper consideration is given to the comments raised by the affected parties and stakeholders consulted
  • that comments are considered promptly and, where appropriate, relevant stakeholders are included in any redrafting exercise as part of an ongoing consultation process.

4.26 Code developers may also need to consult with relevant regulators and other Government agencies to assess any other legal issues associated with codes. For example code developers should consult the Australian Competition and Consumer Commission (ACCC) if it is possible that a code might encourage anti-competitive conduct.[14]

4.27 When considering whether to register a code, the Commissioner will have particular regard to the views of stakeholders provided to the code developer during the consultation. The Commissioner expects the code developer to make a reasonable effort to work with stakeholders to resolve issues before a code is submitted to the Commissioner for registration. Failure to make reasonable efforts to resolve issues with stakeholders could adversely affect the Commissioner's decision to register a code.

4.28 The Commissioner expects code developers to submit a statement of consultation with the application to register the code, which contains the following details:

  • the period that the draft code was available for public consultation
  • the entities likely to be affected by the code
  • the methods that were employed by the code developer to consult with entities and the public
  • a list of entities and individuals who made submissions to the draft of the code (the Commissioner may seek to review the submissions at a later stage)
  • where the code was changed following feedback from the consultation, the details of these changes
  • a summary of any issues raised by the consultation that remain unresolved (if any)
  • the reasons why any other feedback was not incorporated into the final document.

4.29 Registration requirements for codes are discussed in more detail in Part 6.

Developing explanatory material

4.30 A code developer may wish to prepare explanatory material in relation to a code.

4.31 While the Commissioner expects code developers to include all relevant obligations in the code itself, the Commissioner recognises that there may be instances where additional explanatory material is necessary. For example, in the case of practical examples about how the code may be complied with or other material that may assist with understanding the obligations set out in the code.

4.32 The Commissioner expects the code developer to bring any explanatory material that is developed in relation to a code to the Commissioner's attention, either at the time of the application, or if it is prepared at a later time, at that later time. Although the Commissioner is not required to consider the explanatory material, the Commissioner may use the explanatory material to inform his or her understanding of the intended operation of the code.

Drafting style

4.33 As registered codes are legally binding, it is important that entities bound by the code, the Commissioner, other stakeholders and the general public are able to easily understand and interpret the code.

4.34 The Commissioner expects codes to be written to a professional standard using plain English language that is clear, concise and easy for individuals to understand. Obligations should be set out in the code in a logical order. For example, obligations could be grouped under headings for each relevant APP and in the order in which the APPs appear in the Privacy Act. This will ensure that obligations in the code follow the lifecycle of the handling of the personal information.

4.35 Language used in the code should be consistent with the Privacy Act to make it easier for individuals to understand the code and for the Commissioner to apply in relation to a privacy complaint.[15] For example, where it is consistent with the proposed code content, code developers should adopt the definition of terms and language contained in the Privacy Act.

4.36 Technical or industry specific language or jargon should be avoided as it may limit individuals from fully understanding the code. Where it is necessary for a code to use technical or industry specific language, the Commissioner expects the code to include definitions that clearly explain such terms.

Openness and transparency

4.37 To ensure that a code operates in an open and transparent way, the Commissioner expects that where mechanisms such as code development or administrative committees are used, they would generally have representatives from relevant stakeholder groups and be transparent in their operations.

4.38 APP 1 requires APP entities to set out in a document their clearly expressed and up to date policies about how they manage personal information. This includes information about how an individual may complain about a breach of the APPs, or a registered APP code (if any) that binds the entity, and how the entity will deal with such a privacy complaint (APP 1.4(e)). The APP entity must take reasonable steps to make this document available to anyone who asks for it (APP 1.5 and 1.6).

4.39 Part IIIA of the Privacy Act states that CRBs and credit providers must have a clearly expressed and up to date policy about the management of credit-related information.[16] The policy of the CRB or credit provider must include information on how an individual may complain about a failure of the body or provider to comply with the registered CR code and how the body or provider will deal with such a complaint (ss 20B(4)(h) and 21B(4)(g)). A CRB or credit provider must also take reasonable steps to make this policy available free of charge and in an appropriate form (ss 20B(5)(a)–(b), 21B(5)(a)–(b) and 21B(6)).

4.40 In line with these requirements the Commissioner expects codes to contain provisions which require entities bound by the code to have information about the code and links to it on their website (if they have a website) and to take reasonable steps to make available a copy of the code and any relevant explanatory material on request, free of charge and in an accessible way.


Part 5 – Handling and reporting of privacy complaints

Privacy complaint handling under the Privacy Act

Privacy complaint handling by APP entities

5.1 APP entities are required to implement practices, procedures and systems to deal with privacy-related inquiries or privacy complaints from individuals (APP 1.2). The Commissioner generally expects that an individual's privacy complaint will follow a three-stage process:

  1. the individual first makes a privacy complaint to the APP entity
  2. if the individual is not satisfied with the outcome, the individual may make a privacy complaint to a recognised external dispute resolution (EDR) scheme[17] of which the APP entity is a member
  3. if the APP entity is not a member of a recognised EDR scheme, or the individual is not satisfied with the outcome of the EDR process, the individual may make a privacy complaint to the Commissioner under s 36 of the Privacy Act.

5.2 It is open to the Commissioner to decline to investigate a privacy complaint on a number of grounds, including where the individual did not first make a privacy complaint to the APP entity, or if the Commissioner considers that the privacy complaint is already being dealt with by a recognised EDR scheme or would be more effectively or appropriately dealt with by a recognised EDR scheme of which the APP entity is a member (s 41(1)(dd).

Privacy complaint handling by credit reporting bodies and credit providers

5.3 The Privacy Act contains more prescriptive requirements for credit reporting bodies' and credit providers' privacy complaint handling processes. Like APP entities, credit reporting bodies and credit providers are required to implement practices, procedures and systems to deal with privacy-related enquiries or complaints from individuals (ss 20B(2) and 21B(2)). In addition, Division 5 of Part IIIA of the Privacy Act sets out how credit reporting bodies and credit providers must deal with privacy complaints about credit-related information.

5.4 Credit providers must also be members of a recognised EDR scheme to be able to disclose information to credit reporting bodies (s 21D).

5.5 The general privacy complaint-handling scheme for credit-related complaints is modified for CRBs and credit providers where the privacy complaint relates to an individual's request for access to or correction of their credit-related information. If an individual requests access to or correction of their credit-related information and the request is refused, the Privacy Act does not require the individual to then make a privacy complaint to the credit reporting body or credit provider. Rather, the individual may make a privacy complaint directly to a recognised EDR scheme of which the credit reporting body or credit provider is a member, or to the Commissioner (s 40(1B)).

How the Commissioner investigates privacy complaints

5.6 Code developers, code administrators and entities bound by a registered code who require more information about the handling of privacy complaints by the Commissioner, should consult guidance issued by the Commissioner, such as the Privacy Complaints Practice and Procedure Manual, the Enforcement Guidelines, the Determination Guidelines, practice notes, case notes and determinations, which are available on the OAIC's website.

Developing procedures for internal handling and reporting of privacy complaints

5.7 The Commissioner encourages code developers to consider developing and including in a code, provisions for the internal handling of privacy complaints and reporting to the Commissioner on those complaints (ss 26C(3)(c)–(d) (APP codes) and 26N(3)(b)–(c) (CR code)). These procedures would be implemented by all the entities bound by the code to ensure a consistent approach to the internal handling of privacy complaints.

5.8 In order to keep the procedures simple and ensure that they can be easily interpreted, the Commissioner suggests that internal privacy complaint handling procedures cover all Privacy Act related privacy complaints rather than just complaints concerning breaches of the code.

5.9 A registered code which contains procedures for the internal handling and reporting of privacy complaints does not affect an individual's right to complain to a recognised EDR scheme, or to the Commissioner under Part V of the Privacy Act.

Internal handling of privacy complaints

5.10 In relation to codes that contain procedures related to the internal handling of privacy complaints the Commissioner expects these procedures to be consistent with the following requirements. The procedures should:

  • clearly outline the internal privacy complaint handling process, including how privacy complaints are made to an entity and how they will be dealt with by that entity. This may include the process for lodging privacy complaints, timeframes for investigating and responding to privacy complaints, the criteria used for assessing privacy complaints and how privacy complaints may be resolved
  • clarify that the internal process does not remove the right of individuals to make a privacy complaint to a recognised EDR scheme, or to the Commissioner under Part V of the Privacy Act
  • provide for privacy complaints to be handled by staff with appropriate skills and training
  • provide that adequate explanation of the privacy complaint process is provided to the individual
  • ensure that the privacy complaint process is accessible to all individuals by:
    • making the procedures simple for individuals to follow and use, and providing information about those procedures in a variety of accessible formats
    • allowing individuals to make contact with the entity handling the privacy complaint through a variety of communication channels
    • providing individuals with assistance to make a written privacy complaint
    • providing appropriate facilities and assistance for disadvantaged individuals or those with additional needs, such as free access to interpreters
  • allow privacy complaints to be handled with as little formality and technicality, and as quickly as a proper consideration of the privacy complaint permits
  • ensure that the privacy and confidentiality of information collected in the course of investigating and managing privacy complaints is maintained, for example, by outlining how entities would handle and secure that information and the circumstances under which it may be provided to third parties and handled internally
  • ensure that the investigation and resolution of privacy complaints is conducted with procedural fairness. For example, privacy complaint decisions are made on the basis of specific criteria and relevant information before the entity
  • ensure appropriate tracking of privacy complaints so that privacy complaints are dealt with in a timely way, and can be easily reported on.

5.11 If a code contains internal privacy complaint handling procedures, whether the procedures are consistent with the above criteria will be a relevant consideration in the Commissioner's decision to register a code.

5.12 To assist in the development of internal privacy complaint handling procedures, the Commissioner encourages code developers to consider the OAIC's Privacy complaints practice and procedure manual.

Reporting of privacy complaints

5.13 After the end of each financial year, the Commissioner must give the Minister a report on the operations of the OAIC during that year (the OAIC's Annual Report), which includes information about the operation of registered APP codes that contain procedures for making and dealing with privacy complaints (ss 30 and 32(1)(b) of the Australian Information Commissioner Act 2010). This information includes details about the number of privacy complaints made under these codes, their nature and outcome. The Commissioner will also report on the operation of the CR code.

5.14 The most efficient way in which the Commissioner is able to provide the necessary information in its Annual Report is from reports provided by code administrators to the Commissioner. The provision, by code administrators, of annual reports about the operation of codes is already discussed at paragraphs 2.26–2.28. The reporting of privacy complaint information would complement the reporting of other information regarding the code's effectiveness in achieving compliance from entities bound by the code.

5.15 Where a code includes procedures for privacy complaint handling the Commissioner expects that the code should also include a requirement for entities bound by the code to report information about their privacy complaint handling to the code administrator, so that the code administrator can include that information, or a summary of it, in their annual report to the Commissioner.[18]

5.16 The information provided to the Commissioner by the code administrator about privacy complaints made to entities bound by the code should include the following:

  • the number of privacy complaints received
  • the number of privacy complaints finalised and the age and status of open cases
  • the time taken by entities to resolve the privacy complaints
  • sufficient information about the privacy complaints received to identify the nature of the privacy complaints and, where finalised, their outcomes.

5.17 The Commissioner also expects that the code would include an obligation on the entities bound by the code to report the above information, about privacy complaints made to them, directly to the Commissioner if the code administrator fails to provide the information to the Commissioner.


Part 6 – Applying for registration of a code

Application for registration of a code

6.1 A code is binding and comes into force once it is registered by the Commissioner. Code developers must apply to the Commissioner for the registration of a code (ss 26F(1) (APP codes) and 26Q(1) (CR code)). The registration of a code is at the discretion of the Commissioner (ss 26H(1) (APP codes) and 26S(1) (CR code)). Each code will be assessed by the Commissioner on its merits.

6.2 Code developers are required to undertake a public consultation before making an application to register a code (see paragraphs 4.22–4.28). In deciding whether to register the code, the Commissioner may also consult any person he or she considers appropriate (ss 26H(2)(a) (APP codes) and s 26S(2)(a) (CR code)).

6.3 Code developers may, with the Commissioner's consent, vary a code at any time before the Commissioner registers the code (ss 26F(4) (APP codes) and 26Q(4) (CR code)). This allows the code developer to make variations that respond to concerns or comments made by the Commissioner or others. Even if variations are made to the code at the suggestion of, or in response to comments from, the Commissioner, this does not affect the Commissioner's discretion to register the code.

The form and manner of the application

6.4 An application for the registration of a code must be made in the form and manner specified by the Commissioner and must be accompanied by the information specified by the Commissioner (sections 26F(3) (APP codes) and 26Q(3) (CR code)).

6.5 Code developers must satisfy the following requirements when submitting an application to register a code:

  • an application must be made in writing.[19] There is no formal application form to complete, however the application would normally consist of a letter addressed to the Commissioner which sets out the following:
    • the name of the code developer or entity that is applying for registration of the code
    • a request by the code developer for the Commissioner to consider the code for registration
    • the type of code which is the subject of the application (APP code or the CR code)
    • the preferred title of the code
    • the name of the entity that will be the code administrator
  • code developers should ensure that the following documentation is included with the application:
    • a copy of the code
    • a statement of consultation (see paragraph 4.28)
    • a copy of any explanatory material that has been prepared in relation to the code
    • if an APP code only describes the way in which entities that are bound by the code can be identified, a statement as to how the online record will be maintained (see paragraph 2.14)
    • if all of the requirements in these guidelines are not met, a statement explaining why those requirements have not been met or why they are not relevant
    • any other material that may be relevant to the Commissioner's decision to register the code.

Matters the Commissioner will consider in deciding whether to register a code

6.6 In deciding whether to register a code, the Commissioner will consider whether it meets the requirements for codes sets out in Part IIIB of the Privacy Act. The Commissioner will also consider several other matters in deciding whether to register the code, including whether the code meets the requirements set out in these guidelines.

6.7 In deciding whether to register a code, the Commissioner may consult any person the Commissioner considers appropriate (ss 26H(2)(a) (APP codes) and 26S(2)(a) (CR code)).

6.8 In deciding whether it is appropriate to consult anyone about whether to register the code, the Commissioner will consider the extent to which entities that will be bound by the code and members of the public have been given an opportunity to comment on it. If considered appropriate, the Commissioner may consult industry groups that represent those that will be bound by the code, advocacy associations that represent the interests of the community, and others that have an interest or who may be affected by the registration of the code.

6.9 For a non-exhaustive checklist of matters set out in these guidelines that will be considered by the Commissioner when deciding whether to register a code see AppendixA.

Timeframes

6.10 An acknowledgement of the receipt of the application will be sent within seven working days. Timeframes for assessing a code application will vary depending on a number of factors, including:

  • the length and complexity of the code, the application and any accompanying materials
  • the comprehensiveness of the consultation process undertaken by the code developer – if the Commissioner is not satisfied that an adequate consultation has been undertaken, then the Commissioner may request that additional consultation occur, or conduct his or her own consultation
  • whether all documentation has been provided to the OAIC at the time the code is submitted for registration

6.11 Generally, the OAIC intends to decide on a code registration application within four months of receipt.

Notification

6.12 The Commissioner will notify the code developer of a decision to register the code in writing. The decision will include the date when registration is to take effect.

6.13 The Commissioner will also notify the code developer of a decision not to register a code. The Commissioner's notice will include reasons for that decision (ss 26H(3) (APP codes) and 26S(3) (CR code)).

The Codes Register

6.14 The Privacy Act requires the Commissioner to keep a register, known as the Codes Register, which includes the APP codes and the CR code the Commissioner has decided to register (s 26U(1)). Where the Commissioner approves a variation to an APP code or CR code, the Codes Register will include the relevant code as varied (ss 26J(6)(b) (APP codes) and 26T(5)(b) (CR code)). However, the Codes Register will not include any code that the Commissioner has removed from the Register (s 26U(2)). Variations and the removal of codes are discussed in Part 5.

6.15 The Codes Register will always include one, and only one, CR code (s 26S(4)).

6.16 The Codes Register, including the full content of any registered APP codes and the registered CR code will be made publicly available on the OAIC's website: www.oaic.gov.au (s 26U(3)).

Registration of codes – what this means

6.17 APP codes and the CR code come into force and are binding on those entities specified in the code to be bound by the code once they are registered by the Commissioner on the Codes Register and have commenced (ss 26B(1) (APP codes) and 26M(1) (CR code)).[20]

6.18 The Privacy Act states that registered codes are legislative instruments. Legislative instruments must be registered on the Federal Register of Legislative Instruments – (FRLI).[21] The Commissioner is responsible for registering the code on the FRLI.

6.19 This means that there is a double registration process for codes – first on the Codes Register and then registration as a legislative instrument on the FRLI. However ss 26B(3) (APP codes) and 26M(3) (CR code) state that:

  • the code comes into force on the day it is registered on the Codes Register or
  • on a later date specified in the code that has been registered on the Codes Register, even if this is before the date it is registered on the FRLI.

Review by the Administrative Appeals Tribunal

6.20 Code developers can make an application to the Administrative Appeals Tribunal (AAT) for review of decisions by the Commissioner not to register a code (s 96). More information about making an application for review to the AAT is available on the AAT's website: www.aat.gov.au.


Part 7 – Reviewing and varying registered codes and removing registered APP codes

Review of registered codes

Review of registered codes initiated by the code administrator

7.1 The Commissioner expects that the governance arrangements for registered codes will include code administrators initiating regular independent reviews of the operation of the code to ensure that it remains effective and relevant (see paragraph 2.9). The Commissioner expects that a code review would generally be overseen by a suitably independent person and where practicable supported by a steering group which would include at least one representative from a relevant consumer group.

7.2 The Commissioner expects that an independent review of a code would:

  • occur at regular intervals, at least every 5 years, and have a scope broad enough to capture all potential issues related to the codes effectiveness and relevance[22]
  • include a public consultation process (including with relevant stakeholders eg entities bound by the Code, individuals who transact with those entities
  • result in a report made publicly available online which outlines:
    • the issues raised by the review
    • the findings of the review
    • the actions taken, or that will be taken, by the code administrator and / or the entities bound by the code to address issues identified by the review .

7.3 The code administrator may also decide to initiate an independent review of a registered code before a regular review is due. For example a code administrator may initiate an independent review if the regular monitoring indicates a lack of compliance with the registered code (see paragraphs 2.26–2.29) or the code administrator becomes aware of systemic issues that would justify a review.

Review of registered codes by the Commissioner

7.4 The Commissioner may also review the operation of a registered APP code or the registered CR code (s 26W). Instances where the Commissioner may decide to review a registered code include where the Commissioner becomes aware:

  • of a change in industry practices, technology or consumer expectations that may impact the effective operation of the code
  • that there may be a lack of compliance, with a registered code

7.5 The Commissioner may ask the code administrator to assist the review by conducting an investigation and analysis of specific issues and report on those issues. This approach may be appropriate where the code administrator's expertise would be helpful to the review.

7.6 The outcome of any review of a code may inform a decision by the Commissioner to approve a variation of a registered APP code or the registered CR code, or to remove a registered APP code from the Codes Register.

Variations to a registered code

7.7 The Commissioner may approve, in writing, a variation of a registered code (ss 26J (APP codes) and 26T (CR code)). A variation may occur in a number of ways:

  • a body or association representing one or more entities bound by the registered code (such as the code administrator) may apply for a variation
  • an entity bound by the registered code may apply for a variation
  • the Commissioner may prepare a variation on the Commissioner's own initiative.

7.8 Where the Commissioner decides to vary a registered APP code on the Commissioner's own initiative, the variation cannot include provisions that deal with exempt acts or practices (s 26J(3)). However, where an entity or representative body applies for a variation of an APP code, the variation may deal with exempt acts or practices.

7.9 Before deciding whether to approve a variation, the Commissioner will undertake a consultation (ss 26J(4) (APP codes) and 26T(3) (CR code)), which includes:

  • making a draft of the variation publicly available on the OAIC website
  • consulting any person the Commissioner considers appropriate about the variation.

In deciding whether it is appropriate to consult anyone about the variation, the Commissioner will consider the extent to which entities bound by the code and members of the public have been given an opportunity to comment on the variation. If considered appropriate, the Commissioner may consult industry groups that represent those bound by the code, advocacy associations that represent the interests of the community, and others that have an interest or who may be affected by the variation.

7.10 In deciding whether to approve a variation, the Commissioner will consider the matters specified in these guidelines (ss 26J(5) (APP codes) and 26T(4) (CR code)). The decision will primarily be informed by whether the proposed variation effectively addresses the issues it seeks to resolve.

7.11 For a non-exhaustive checklist of matters set out in these guidelines that will be considered by the Commissioner when deciding whether to vary a registered code see Appendix B.

7.12 If the Commissioner decides to vary a registered code, the Commissioner will:

  • notify the person or entity that applied for the variation (if applicable), as well as the code administrator, of the decision, including the date on which the variation will occur
  • unless the circumstances require that the variation take place in a shorter timeframe, publish a public notice about the proposed variation of the registered code on the OAIC's website at least 28 business days before the registered code is due to be varied. During this period the Commissioner expects the code administrator to inform the entities that are bound by the registered code of the date of the code's variation
  • on the Codes Register add the code as varied and remove the original registered code (ss 26J(6) (APP codes) and 26T(5) (CR code))[23]
  • publish a notice on the OAIC's website for 28 days following the date of variation stating that the original registered code has been varied.

7.13 The Codes Register will always contain the current version of the registered code. The registered code, as varied, will also be a legislative instrument, and the Commissioner will ensure that the code, as varied is registered on FRLI and that the original registered code is noted as ‘ceased' on FRLI.

The form and manner of the application to vary a registered code

7.14 An application for a variation of a registered code must be made in the form and manner specified by the Commissioner and must be accompanied by the information specified by the Commissioner (ss 26J(2) (APP codes) and 26T(2) (CR code)).

7.15 An application to vary a registered code must satisfy the following requirements:

  • an application must be made in writing.[24] There is no formal application form to complete, however the application would normally consist of a letter addressed to the Commissioner which sets out the following:
    • the name of the entity that is applying for the variation of the code and whether the entity is bound by the code or is a body or association representing one or more entities that are bound by the code
    • a request to consider the variation of registered code
    • the type of code which is the subject of the application (APP code or the CR code)
    • the title of the relevant registered code
    • the details of the proposed variation
    • the reasons for the variation
    • any potential consequences resulting from the variation, including the impact on entities bound by the registered code
    • details of any consultation carried out with entities bound by the registered code along with other relevant stakeholders.
  • entities should ensure that the following documentation is included with the application:
    • a copy of the variation as a marked up version of the current registered code, unless that is impracticable, then in a separate document showing the complete code as varied
    • if all of the requirements in these guidelines are not met, a statement explaining why those requirements have not been met or why they are not relevant
    • any other material that may be relevant to the Commissioner's decision to register the code as varied.

Removal of a registered APP code

7.16 The Commissioner may remove a registered APP code from the Codes Register (s 26K). There are no procedures for removing the registered CR code. There will always be a CR code in force. Any changes to the registered CR code will be made by way of variation to the registered CR code.

7.17 In deciding whether to remove a registered APP code, the Commissioner will consider the matters specified in these guidelines (s 26K(4)).

7.18 As with a variation, the Commissioner can remove a registered APP code in a number of ways:

  • on the application of a body or association representing one or more entities bound by the code
  • on the application of an entity bound by the code
  • on the Commissioner's own initiative.

7.19 In removing a registered APP code, the Commissioner will undertake a consultation in the same way as for a variation of a registered code (s 26K(3)).

7.20 Before deciding whether to remove a registered APP code, the Commissioner will undertake a consultation with any person the Commissioner considers appropriate about the removal. The Commissioner will usually consult entities bound by the code that will be affected by the removal.

7.21 In deciding whether it is appropriate to consult any person, the Commissioner will consider the extent to which entities bound by the code, or members of the public, have been given an opportunity to comment on the removal. The Commissioner may consult those persons, or may consult advocacy associations that represent the interests of the community, industry groups and others that have an interest or who may be affected by the removal.

7.22 For a non-exhaustive checklist of matters set out in these guidelines that will be considered by the Commissioner when deciding whether to remove a code from the register see Appendix C.

7.23 If the Commissioner decides to remove a registered APP code from the register, the Commissioner will:

  • notify the person or entity that applied for the removal (if applicable), as well as the code administrator, of a decision to remove the registered APP code, including the date on which the removal will occur
  • unless the circumstances require that the removal take place in a shorter timeframe, publish a public notice about the proposed removal of the registered APP code on the OAIC's website at least 28 business days before the registered code is due to be removed. During this period the Commissioner expects the code administrator to inform the entities that are bound by the registered code of the date of the code's removal from the Codes Register and advise that following this date the registered code will no longer be in force
  • remove the registered APP code from the Codes Register on the specified date
  • ensure that the registered APP code is noted as ‘ceased' on FRLI
  • publish a public notice that the registered APP code has been removed from the Codes Register on the OAIC's website for 28 days following the date of removal.

The form and manner of the application to remove a registered APP code

7.24 An application for the removal of a registered APP code must be made in the form and manner specified by the Commissioner and must be accompanied by such information as is specified by the Commissioner (s 26K(2)).

7.25 An application to remove a registered code must satisfy the following requirements:

  • an application must be made in writing.[25] There is no formal application form to complete, however it is recommended that the application take the form of a letter addressed to the Commissioner which sets out the following:
    • the name of the entity bound by the code or the body or association representing one or more of the entities that are bound by the registered APP code applying for the removal
    • a request to consider the removal of the registered APP code
    • the title of the relevant registered APP code
    • the reasons for the removal
    • any potential consequences resulting from the removal of the registered APP code, including the impact on entities bound by the registered APP code
    • details of any consultation carried out with entities bound by the registered APP code along with other relevant stakeholders.

Appendix A – Code registration checklist

This is a checklist of the primary matters mentioned in these guidelines that the Commissioner will consider in deciding whether to register a code. This list is not exhaustive and not all matters apply eg when the code has been developed by the Commissioner:

  • whether the code developer has provided all relevant documentation with the application (paragraph 6.5)
  • whether the code satisfies the requirements in Part IIIB of the Privacy Act (paragraphs 4.2–4.7)
  • whether there is an existing code that would be more suitable for adoption (see paragraph 2.6)
  • whether there are appropriate governance arrangements in place to develop and administer the code (see paragraphs 2.7–2.10 and 7.1–7.6)
  • the representativeness of the code developer (see paragraph 2.21)
  • whether there are appropriate reporting mechanisms (see paragraphs 2.26–2.29 )
  • whether there will be an easily accessible and up to date online record of entities bound by a code (see paragraphs 2.12–2.18)
  • in the case of the CR code, whether it binds all credit providers as well as any other entities subject to Part IIIA of the Privacy Act (see paragraph 2.20)
  • whether there are internal privacy complaint handling procedures (see paragraphs 2.22–2.25) and that they satisfy the matters set out in Part 5.
  • whether there was initial notification of, and updates on, the code's development (see paragraphs 2.30) and any associated documents have been brought to the Commissioner's attention (paragraphs 4.20–4.21)
  • whether the code developer satisfied the public consultation requirements and any views of stakeholders obtained during the consultation (paragraphs 4.22–4.28)
  • whether the code meets the drafting style requirements (paragraphs 4.33–4.36)
  • whether the openness and transparency matters have been addressed (paragraphs 4.37–4.40)
  • any matters raised by any person whom the Commissioner consults (paragraphs 6.6–6.9).

Appendix B – Code variation checklist

This is a checklist of the primary matters mentioned in these guidelines that the Commissioner will consider in deciding whether to vary a registered code. This list is not exhaustive and not all matters apply eg when the variation is on the Commissioner's own initiative:

  • whether the applicant has provided all relevant documentation with the application (paragraph 7.15)
  • whether the proposed variation effectively addresses the issues it seeks to resolve (paragraph 7.10)
  • whether adequate consultation has occurred and the views of the entities bound by the code and others about the proposed variation (paragraphs 7.9, 7.15).

Appendix C – Code removal checklist

This is a checklist of the primary matters mentioned in these guidelines that the Commissioner will consider in deciding whether to remove an APP code from the register. This list is not exhaustive and not all matters apply eg when the removal is on the Commissioner's own initiative:

  • whether the applicant has provided all relevant documentation with the application (paragraph 7.25)
  • whether the operation of a registered APP code's governance arrangements remain effective including whether the code administrator is monitoring and reporting the registered APP code's effectiveness (paragraphs 2.7–2.10 and 2.26–2.29)
  • if the registered APP code has internal privacy complaint handling and reporting procedures, whether the entities bound by the code are adhering to those procedures (Part 5)
  • if a review of the code by the Commissioner or an independent review initiated the code administrator (paragraphs 7.1–7.7), or the reported information from the code administrator or entities bound by the registered code (paragraphs 2.26–2.29 and 5.13–5.16) indicates the registered APP code is not operating effectively
  • whether the registered APP code is out of date or irrelevant including if no entities remain bound by the code (paragraph 3.2)
  • a failure to maintain an up to date online record of entities bound by the registered APP code (paragraphs 2.14–2.17)
  • whether adequate consultation on the removal has occurred and the views of the entities bound by the registered APP code and others about the proposed removal (paragraphs 7.19–7.21)

Footnotes

[1] Entity includes entities regulated by the credit reporting provisions in Part IIIA of the Privacy Act.

[2] The APP set out standards, rights and obligations in relation to the handling and maintenance of personal information by APP entities, including dealing with privacy policies and the collection, storage, use, disclosure, quality and security of personal information, and access and correction rights of individuals in relation to their personal information.

[3] In this guide, unless otherwise indicated, any references to sections of an Act are to sections of the Privacy Act 1988 as amended by the Privacy Amendment (Enhancing Privacy Protection) Act 2012.

[4] The Australian Information Commissioner is the head of the Office of the Australian Information Commissioner, an independent statutory agency which has functions in relation to information policy and independent oversight of privacy protection and freedom of information. The Commissioner is supported by two other statutory officers: the Privacy Commissioner and the Freedom of Information Commissioner. More information is available at: www.oaic.gov.au

[5] Under subsection 13(1)(b), an act or practice of an APP entity will be an interference with the privacy of an individual if it breaches a registered APP code that binds the entity in relation to personal information about the individual. Under s 13(2)(b) the same applies to entities that breach the registered CR code in relation to personal information about the individual and the code binds the entity.

[6] Under subsection 28(1)(c)(ii)–(iii), the Commissioner also has guidance related functions for promoting an understanding and acceptance of a registered APP code and the registered CR code.

[7] Serious or repeated interferences with privacy can attract a civil penalty under s 13G of the Privacy Act. More information in relation to serious or repeated interferences with privacy is available on the OAIC website.

[8] Systemic issues relate to problems inherent in the code or in the way the code operates where a change to the code or to the structure, organisation or policies in relation to the operation of the code could alleviate the systemic problem.

[9] The OAIC's annual report to the Minister regarding the operations of the OAIC must include information about registered APP codes which include internal complaint and report handling procedures – this is discussed in greater detail in Part 5 of these guidelines (see s 31(1)(b) of the Privacy Act).

[10] This is despite s 26B(c) which states than an APP code may cover an act or practice that is exempt.

[11] Explanatory Memorandum, p 208, available at: www.aph.gov.au/Parliamentary_Business/Bills_Legislation/Bills_Search_Results/Result?bId=r4813.

[12] This provision covers exempts acts or practices within the meaning of subsection 7B(1), (2) or (3)

[13] The 28 day consultation period is the minimum period that must be offered, but the code developer may consider a longer period, depending, for example, on the expected level of interest in the code, the number of expected stakeholders, the complexity of the code, or the expected impact of the provisions in the code on the practices or procedures of stakeholders.

[14] In drafting a code, entities should be mindful of the Competition and Consumer Act 2010 (CCA) which prohibits various forms of anti-competitive conduct. Further information regarding the CCA can be obtained from the ACCC's website at: www.accc.gov.au

[15] Using the words and language of the Privacy Act will also reinforce that a code can't reduce the privacy protections provided for by that Act.

[16] Obligations regarding credit information and eligibility information management policies for CRBs and credit providers are contained in ss 20B(3)–(6) and 21B(3)–(7) respectively

[17] The Privacy Act gives the Commissioner the discretion to recognise EDR schemes to handle privacy-related complaints and to decide not to investigate an act or practice if a complaint about the act or practice is being dealt with by a recognised EDR scheme or would be more effectively or appropriately dealt with by a recognised EDR scheme. For more information see Parts IV and V of the Privacy Act.

[18] As noted in paragraphs 2.29–2.31 the Commissioner expects that serious or repeated interferences with privacy would be reported to the OAIC as soon as the code administrator becomes aware of them.

[19] The Commissioner prefers receipt of all documentation in electronic format, preferably in Microsoft Word, in addition to any other format. As well, formatting of documentation that will assist making it as accessible as possible when published on the web is preferred. The OAIC can be contacted for assistance relating to the preferred formatting.

[20] Also see ss 26C(5) (APP codes) and 26N(5) (CR code) which are declaratory provisions which state that APP codes and the CR code are not legislative instruments. This is because codes are not enforceable until they are registered on the Codes Register. Once the code is registered on the Codes Register by the Commissioner and comes into force, it will at that point be a legislative instrument.

[21] The registration of legislative instruments on FRLI is governed by the Legislative Instruments Act 2003.

[22] The Commissioner should also be kept informed throughout the process.

[23] A variation comes into effect on the day specified in the Commissioner's approval. However, as registration is the act that ensures a code is enforceable, the variation cannot take effect before the whole code, as varied, is registered in the Codes Register. The variation itself is not registered. The whole code is replaced with a new version of the code that incorporates the variation.

[24] The Commissioner prefers receipt of all documentation in electronic format, preferably in Microsoft Word, in addition to any other format. As well, formatting of documentation that will assist making it as accessible as possible when published on the web is preferred. The OAIC can be contacted for assistance relating to the preferred formatting.

[25] The Commissioner prefers receipt of all documentation in electronic format, preferably in Microsoft Word, in addition to any other format. As well, formatting of documentation that will assist making it as accessible as possible when published on the web is preferred. The OAIC can be contacted for assistance relating to the preferred formatting.