Ley de Privacidad Australiana

Guidelines for developing codes
Issued under Part IIIB of the Privacy Act 1988

The Office of the Australian Information Commissioner (OAIC) was established on 1 November
2010 by the Australian Information Commissioner Act 2010.
All OAIC publications can be made available in a range of accessible formats for people with
disabilities. If you require assistance, please contact the OAIC.
Date of initial publication: (Month) 2013
Creative Commons
With the exception of the Commonwealth Coat of Arms, and to the extent that copyright subsists
in a third party, this report, its logo and front page design are licensed under a Creative Commons
Attribution 3.0 Australia licence (http://creativecommons.org/licenses/by/3.0/).
To the extent that copyright subsists in third party quotes and diagrams it remains with the
original owner and permission may be required to reuse the material.
Content from these guidelines should be attributed as: Office of the Australian Information
Commissioner, Guidelines for developing codes – issued under Part IIIB of the Privacy Act 1988.
Enquiries regarding the licence and use of the guidelines are welcome at:
Office of the Australian Information Commissioner
GPO Box 5218
Sydney NSW 2001
Telephone: 02 9284 9800
Email: [email protected]
Web: www.oaic.gov.au
Contents
Key terms ........................................................................................................... 1
Part 1 – Introduction ........................................................................................... 2
The Privacy Act and codes .................................................................................................... 2
Purpose of these guidelines .................................................................................................. 3
Who should use these guidelines? ....................................................................................... 3
Related publications ............................................................................................................. 3
Part 2 – Deciding and planning to develop a code ............................................... 4
Who can develop a privacy code? ........................................................................................ 4
Resource requirements......................................................................................................... 4
Reasons for developing a code ............................................................................................. 5
Assessing the need for an APP code ..................................................................................... 5
Code governance .................................................................................................................. 6
Who will be bound by the code? .......................................................................................... 6
Entities bound by APP codes.............................................................................................. 6
Entities bound by the CR code ........................................................................................... 7
Code developer representativeness ..................................................................................... 8
Options for privacy complaint handling and reporting ........................................................ 8
Monitoring and reporting compliance with a code .............................................................. 8
Getting help – what the Office of the Australian Information Commissioner can do ......... 9
Part 3 – Request by the Commissioner to develop a code ................................. 11
Circumstances where the Commissioner may request the development of a code ......... 11
Request requirements ........................................................................................................ 11
Identifying the appropriate code developer ...................................................................... 12
Development of codes by the Commissioner ..................................................................... 12
Part 4 – Developing codes ................................................................................. 14
Code requirements under the Privacy Act.......................................................................... 14
APP codes ......................................................................................................................... 14
The CR code...................................................................................................................... 14
Other matters that may be included in a code ................................................................... 15
APP codes ......................................................................................................................... 15
The CR code...................................................................................................................... 15
APP codes covering exempt acts or practices ................................................................. 16
Inclusion of matters unrelated to information privacy and credit reporting ..................... 16
Consultation on codes ........................................................................................................ 17
Developing explanatory material ....................................................................................... 19
Drafting style ....................................................................................................................... 19
Openness and transparency ............................................................................................... 19
Part 5 – Handling and reporting of privacy complaints ...................................... 21
Privacy complaint handling under the Privacy Act ............................................................. 21
Privacy complaint-handling by APP entities .................................................................... 21
Privacy complaint handling by credit reporting bodies and credit providers ................. 21
How the Commissioner investigates privacy complaints ................................................ 22
Developing procedures for internal handling and reporting of privacy complaints .......... 22
Internal handling of privacy complaints .......................................................................... 22
Reporting of privacy complaints ...................................................................................... 23
Part 6 – Applying for registration of a code ....................................................... 25
Application for registration of a code ................................................................................. 25
The form and manner of the application............................................................................ 25
Matters the Commissioner will consider in deciding whether to register a code ............. 26
Timeframes ......................................................................................................................... 26
Notification ......................................................................................................................... 27
The Codes Register.............................................................................................................. 27
Registration of codes – what this means ............................................................................ 27
Review by the Administrative Appeals Tribunal ................................................................. 28
Part 7 – Reviewing and varying registered codes and removing registered APP
codes ................................................................................................................ 29
Review of registered codes ................................................................................................. 29
Review of registered codes initiated by the code administrator .................................... 29
Review of registered codes by the Commissioner ........................................................... 29
Variations to a registered code ........................................................................................... 30
The form and manner of the application to vary a registered code .................................. 31
Removal of a registered APP code ...................................................................................... 32
The form and manner of the application to remove a registered APP code ..................... 33
Appendix A – Code registration checklist .......................................................... 35
Appendix B – Code variation checklist ............................................................... 36
Appendix C – Code removal checklist ................................................................ 36
Guidelines for developing codes – issued under Part IIIB of the Privacy Act 1988
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; entity1; 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.
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.
Page 1
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
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.
Page 2
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.
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.
Page 3
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
Page 4
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:
o 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
o 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?
Page 5
 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 on-going 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
Page 6
(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)).
Page 7
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
Page 8
auditing for, or investigating, serious or repeated interferences with privacy7 or systemic

issues8 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.
7
Serious or repeated interferences with privacy can attract a civil penalty under s13G 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).
Page 9
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.
Page 10
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, out of 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)).
Page 11
 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.
Page 12
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.
10
This is despite s 26B(c) which states than an APP code may cover an act or practice that is exempt.
Page 13
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
Page 14
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)
11
Explanatory Memorandum, p 208, available at:
www.aph.gov.au/Parliamentary_Business/Bills_Legislation/Bills_Search_Results/Result?bId=r4813.
Page 15
 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 pro-active 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
12
This provision covers exempts acts or practices within the meaning of subsection 7B(1), (2) or (3)
Page 16
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 code13
 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
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.
Page 17
 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.
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.
Page 18
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
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.
Page 19
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.
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.
Page 20
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) scheme17 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 (s21D).
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
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.
Page 21
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
Page 22
 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:
o making the procedures simple for individuals to follow and use, and providing
information about those procedures in a variety of accessible formats
o allowing individuals to make contact with the entity handling the privacy
complaint through a variety of communication channels
o providing individuals with assistance to make a written privacy complaint
o 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
Page 23
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.
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.
Page 24
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:
o the name of the code developer or entity that is applying for registration of
the code
o a request by the code developer for the Commissioner to consider the code
for registration
o the type of code which is the subject of the application (APP code or the CR
code)
o the preferred title of the code
o the name of the entity that will be the code administrator
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.
Page 25
 code developers should ensure that the following documentation is included with
the application:
o a copy of the code
o a statement of consultation (see paragraph 4.28)
o a copy of any explanatory material that has been prepared in relation to the
code
o 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)
o 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
o 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
Appendix A.
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:
Page 26
 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
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.
Page 27
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.
21
The registration of legislative instruments on FRLI is governed by the Legislative Instruments Act 2003.
Page 28
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 relevance22
 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:
o the issues raised by the review
o the findings of the review
o 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
22
The Commissioner should also be kept informed throughout the process.
Page 29
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.
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:
Page 30
 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:
complete, however the application would normally consist of a letter addressed to
the Commissioner which sets out the following:
o 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
o a request to consider the variation of registered code
o the type of code which is the subject of the application (APP code or the CR
code)
o the title of the relevant registered code
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
Page 31
o the details of the proposed variation

o the reasons for the variation
o any potential consequences resulting from the variation, including the impact
on entities bound by the registered code
o 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:
o 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
o 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
o 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
Page 32
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.
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:
complete, however it is recommended that the application take the form of a
letter addressed to the Commissioner which sets out the following:
o 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
25
Page 33
o a request to consider the removal of the registered APP code

o the title of the relevant registered APP code
o the reasons for the removal
o any potential consequences resulting from the removal of the registered APP
code, including the impact on entities bound by the registered APP code
o details of any consultation carried out with entities bound by the registered
APP code along with other relevant stakeholders.
Page 34
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)
Page 35
Appendix B – Code variation checklist

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
 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

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
 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)
Page 36

Ley de Privacidad Australiana

Uploaded by

Copyright:

Available Formats

Ley de Privacidad Australiana

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ley de Privacidad Australiana

Uploaded by

Copyright:

Available Formats

Guidelines for developing codes

Issued under Part IIIB of the Privacy Act 1988

Date of initial publication: (Month) 2013

1.6. Registered codes are disallowable legislative instruments. Entities bound by a

Purpose of these guidelines

Who should use these guidelines?

Part 2 – Deciding and planning to develop a code

2.3 In developing and implementing a code, resources may need to be allocated to

Reasons for developing a code

 to provide clarity, certainty and satisfaction to consumers seeking redress by

Assessing the need for an APP code

 Do entities have sufficient resources to develop and administer a code? Will

Who will be bound by the code?

Entities bound by APP codes

Entities bound by the CR code

Code developer representativeness

Options for privacy complaint handling and reporting

Monitoring and reporting compliance with a code

auditing for, or investigating, serious or repeated interferences with privacy7 or systemic

Getting help – what the Office of the Australian Information Commissioner

Part 3 – Request by the Commissioner to develop a code

Identifying the appropriate code developer

Development of codes by the Commissioner

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

Part 4 – Developing codes

4.6 The CR code must:

Other matters that may be included in a code

APP codes covering exempt acts or practices

Inclusion of matters unrelated to information privacy and credit reporting

 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

4.28 The Commissioner expects code developers to submit a statement of consultation

Developing explanatory material

4.34 The Commissioner expects codes to be written to a professional standard using

Openness and transparency

Part 5 – Handling and reporting of privacy complaints

5.2 It is open to the Commissioner to decline to investigate a privacy complaint on a

Privacy complaint handling by credit reporting bodies and credit providers

5.5 The general privacy complaint-handling scheme for credit-related complaints is

How the Commissioner investigates privacy complaints

Developing procedures for internal handling and reporting of privacy

Internal handling of privacy complaints

 provide that adequate explanation of the privacy complaint process is provided to

5.12 To assist in the development of internal privacy complaint handling procedures,

Reporting of privacy complaints

complaint information would complement the reporting of other information regarding

Part 6 – Applying for registration of a code

The form and manner of the application

Matters the Commissioner will consider in deciding whether to register a

6.8 In deciding whether it is appropriate to consult anyone about whether to register

The Codes Register

Registration of codes – what this means

Review by the Administrative Appeals Tribunal

Part 7 – Reviewing and varying registered codes and

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

Review of registered codes by the Commissioner

Variations to a registered code

In deciding whether it is appropriate to consult anyone about the variation, the

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

o the details of the proposed variation