CHAPTER TWO - LEGISLATIVE OVERVIEW
CHAPTER THREE - ISSUES TO CONSIDER BEFORE DEVELOPING A PRIVACY CODE
CHAPTER FOUR - ISSUES TO CONSIDER WHEN DEVELOPING A PRIVACY CODE
CHAPTER SIX - APPLYING FOR APPROVAL OF A PRIVACY CODE
CHAPTER SEVEN - HOW TO VARY YOUR APPROVED PRIVACY CODE
The Privacy Act (1988)(Cth) (the Act) as amended by the Privacy Amendment (Private Sector) Act 2000 gives important privacy rights to individuals but also recognises the rights of business to achieve their objectives in an efficient way. The Privacy Commissioner is required to uphold this ideal and will work with all stakeholders, taking a balanced approach that protects the individual's rights while enabling business to continue operating in a profitable way.
One way the Act works to achieve this goal is by allowing organisations to have and enforce their own privacy codes that continue to uphold the privacy rights of individuals while allowing some flexibility of application for organisations. The purpose of these guidelines is to help organisations develop privacy codes to this end.
The guidelines will do this by explaining the features of a privacy code and the standards of content and application that must be met before the Privacy Commissioner will approve it to replace the default principles provided by the Act. They will also explain the procedures for having a code approved and the necessary requirements for its ongoing operation.
The Act gives the Privacy Commissioner the power to make written guidelines that will assist organisations develop and implement a privacy code, deal with complaints and set out the requirements under which a code may be approved. These Code Development Guidelines (the Guidelines) act as the Privacy Commissioner's formal guidelines in relation to section 18BF(1)(a)-(c) of the Act. Section 18BB(4) allows the Privacy Commissioner to consider matters specified in these guidelines when approving a privacy code.
Section 18BB(3)(a)(i) of the Act states that the Privacy Commissioner must be satisfied that the procedures set out in a code meet the prescribed standards. The Attorney General has responsibility for prescribing these standards in regulation. It is likely that the prescribed standards will be based on the Benchmarks for Industry-Based Customer Dispute Resolution Schemes (the "Benchmarks"), released in August 1997 by the Hon Chris Ellison, then the Minister for Customs and Consumer Affairs. The Benchmarks are reproduced in Appendix 1 and there is further discussion of the requirements they set out in chapter 5.
|
The purpose of:
|
These Guidelines are divided into 7 chapters and include in the appendices a set of standards for codes containing complaints handling processes (as discussed above). Chapters 4 and 5 require additional explanation as to their structure since they differ in style and purpose from the other chapters in the Guidelines.
Chapter 4 is split into two categories of advice. The main body of chapter 4 is designed to give assistance to organisations developing and implementing a privacy code. In doing so it will explain any requirements prescribed by the Act as well as give advice on ways organisations can comply with these requirements in practice.
The bolded sections in chapter 4 are the Privacy Commissioner's formal guidelines under section 18BF(1)(c) of the Act. They set out in point form additional requirements that the Privacy Commissioner will consider before a code is approved. These dot points will be informed by the commentary in the main body of chapter 4.
Chapter 5 is divided into two parts - part 5A and part 5B. Part 5A is similar in intent to the main body of chapter 4. It sets out matters that code proponents will need to consider with regards to having a complaints handling process included in a code. Part 5A also seeks to explain the requirements and obligations associated with having a complaints mechanism built into a code. This explanation will inform part 5B.
Part 5B provides a set of formal guidelines issued by the Privacy Commissioner under section18BF(1)(b) of the Act with regards to making and dealing with complaints under an approved code.
Code adjudicator - is a decision maker that is responsible for the determination of complaints under a code. The code adjudicator will have a well-defined independence from the members of the scheme.
Code administrator - this is a body established to oversee the running and operation of the code and (where applicable) the dispute resolution scheme. The code administrator must have a well-defined independence from the members of the scheme.
Code member - is any organisation that has agreed to be bound by a privacy code.
Code proponent - is an organisation, or body representing a group of organisations, that has responsibility for developing, seeking approval for, and/or implementing a code.
Complainant - is an individual who has lodged a complaint with a code adjudicator.
Complaint - is a written allegation made by an individual that a specified respondent has improperly handled the individual's personal information.
Complaints procedures - are a set of procedures for making and dealing with complaints under a code lodged for approval by the Privacy Commissioner.
Credit Reporting Provisions - are a set of provisions that relate to Part IIIA of the Privacy Act 1988.
National Privacy Principles (NPPs) - are a set of 10 principles, prescribed in the Act, that are intended to form the basis for the protection of personal information. Private sector organisations will be bound by the NPPs unless they have their own privacy code that is approved by the Privacy Commissioner. The Principles cover matters such as the collection, use and disclosure of personal information, data quality, access and data security. (The NPPs are formally set out in schedule 3 to the Act and are not to be confused with the Information Privacy Principles, which play a different role to the NPPs.)
OFPC - refers to the Office of the Federal Privacy Commissioner.
Organisation - is defined by the Act to be an individual, a body corporate, a partnership, any other unincorporated association, or a trust. The full definition is more formally set out in section 6C of the Act.
Prescribed Standards - are a set of standards, prescribed by regulation, that provide advice on the processes for alternative dispute resolution schemes. The prescribed standards are likely to be based on the Benchmarks for Industry-Based Customer Dispute Resolution Schemes which were released by Senator the Hon. Chris Ellison, Minister for Customs and Consumer Affairs in August 1997.
Respondent - is the code member that is subject to a privacy complaint by an individual under a code.
Spent Conviction Scheme - refers to Part VIIC of the Crimes Act 1914
Tax File Number Guidelines - refers to the mandatory Tax File Number Guidelines issued by the Privacy Commissioner under section 17 of the Privacy Act 1988.
The definitions in section 6 of the Act also apply to these Guidelines.
Any sole organisation, group of organisations or industry body/association representing the interests of its members can make an application to have a privacy code approved. There is also potential for applications to be made by profit seeking third parties (that is, non representative bodies) that intend to attract organisations to an alternative dispute resolution scheme.
Each code will be judged on its merits and in relation to the Act and these Guidelines regardless of the nature of the code proponent. However, the Privacy Commissioner will also be considering how codes interact and relate with each other in the marketplace.
This chapter gives organisations an explanation of how privacy codes will fit in the new legislative framework. It will explain what is meant by "co-regulation" in the context of the Act and discuss the responsibilities of organisations and the Office of the Federal Privacy Commissioner (OFPC) under the new regime. It will also put these Code Development Guidelines into a broader context by discussing how they relate to the National Privacy Principles (NPPs) and the NPP Guidelines that will be released by the Privacy Commissioner later in the year.
In 1980 the Organisation for Economic Cooperation and Development (OECD) produced a set of guidelines for the protection of privacy and transborder flows of personal data1. These guidelines were developed in part as a response to OECD interest in ensuring personal data could flow freely to enhance trade and other interests. The OECD saw privacy issues as a key element that needed to be addressed and developed guidelines that aimed to prevent violations of an individual's right to privacy, which might occur through the unlawful storage of personal data, the storage of inaccurate personal data, or the abuse or unauthorised disclosure of personal data.
Australia used these guidelines in developing its own privacy legislation in the mid to late 80's following a number of inquiries and policy direction including a proposal for a national identification number and the introduction of the enhanced tax file number scheme. The resulting privacy legislation, in the first instance, only applied to the operations of the Commonwealth Public Sector and to both private and public sectors with respect to tax file numbers. Subsequent amendments added provisions for regulating the credit reporting sector. Coverage of the Act has only now been comprehensively extended to the private sector via the Privacy Amendment (Private Sector) Act (2000) (Cth).
The most recent amendments to the Act provide for a national and consistent set of privacy standards for the private sector. It implements a set of National Privacy Principles (the NPPs) that outline minimum requirements in relation to how private sector organisations should collect, use, keep secure and disclose personal information. The principles also give individuals a right to know what information an organisation holds about them and a right to correct it if it is wrong. The Act also provides arrangements for enforcing these rights.
Further to the minimum requirements of the NPPs (which operate as a set of default privacy principles), the Act establishes a framework in which organisations can develop specialised privacy codes for the handling of personal information. These privacy codes, when approved, will replace the NPPs. This "co-regulatory" component in the legislation is designed to allow for some flexibility in an organisation's approach to privacy but at the same time guarantee consumers that their personal information is subject to minimum standards that are enforceable in law.
The Act does exempt some organisations and practices from its coverage. The OFPC has produced information sheets that give an overview of these exemptions. They are available on the Privacy Commissioner's website at www.privacy.gov.au
1OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data" (1980) are available at: "www.oecd.org.
The new legislation adopts a co-regulatory approach to privacy regulation. The Government decided that the privacy concerns of consumers could best be addressed if organisations were allowed some room to negotiate an appropriate privacy standard with its customers. The co-regulatory approach provides an effective and comprehensive data protection framework for the private sector in Australia but still allows some flexibility of application.
The term "co-regulation" is difficult to define in a general sense as it has the potential to apply to an array of regulatory systems. However, as the term relates to the Act it can be thought of as: a legislative framework in which organisations can gain official recognition for codes of practice that they themselves develop and implement. The most important difference from "self-regulation" is that should organisations covered by the Act choose not to have a code, they must handle personal information in accordance with the NPPs in the Act. These requirements are enforced by law.
The flexible nature of co-regulation will give organisations (or groups of organisations) the option of tailoring the NPPs to fit industry specific sensitivities or market needs. Organisations will have the option of adopting and implementing their own privacy code with the Privacy Commissioner as the adjudicator, or adopting a code that provides for a code adjudicator to resolve consumer complaints.
While there is some flexibility in the new arrangements, it is important to recognise that the Act does not give an organisation complete freedom when collecting and handling personal information. In particular, the Privacy Commissioner must approve each privacy code before it can replace the minimum privacy standards embodied in the NPPs. Once an organisation has had a code approved (or agreed to comply with an existing code) it will be bound by it until it subscribes to the coverage of another code, or reverts to the coverage of the NPPs. Where an organisation chooses not to adopt an approved code it will be bound by the NPPs.
The Act is quite specific about the standards that must be embodied in a code and the process an organisation must go through before the Privacy Commissioner may approve a code. The purpose of later chapters in these guidelines is to set out these processes. When deciding whether or not to approve a code the Privacy Commissioner must consider whether the code incorporates all the NPPs and provides the individual with at least the overall equivalent level of protection. That is, the privacy rights of an individual cannot be lessened by the use of a code. (This will be discussed further in Chapter 4.)
These guidelines should not be read in isolation. They are designed to help organisations understand, and develop privacy codes but do not provide detail on, for example, the NPPs. Organisations planning to develop a code are encouraged to also develop a detailed understanding of the legislation and, in particular, the NPPs.
To help organisations understand the legal obligations contained in the NPPs, the Privacy Commissioner will, from time to time, release guidelines that explain the NPPs. These guidelines will give more information about how the Privacy Commissioner will evaluate the privacy practices of organisations. A privacy code will not be approved if there is potential for the application or interpretation of the principles or accompanying material in a code to undermines the standards set by these NPP guidelines. (Refer to Chapter 4 for further information.)
Because personal health information is considered to be particularly sensitive, the Privacy Commissioner will also release guidelines on the application of the NPPs in the health services sector. Although the general NPP guidelines will explain how the NPPs apply to personal health information, organisations that handle personal health information and also provide health services should consult the health related guidelines before submitting a code of conduct for approval.
Organisations that are unclear about what is involved in developing and implementing a privacy code may find this chapter useful. It is designed to help an organisation build a basic understanding of the substance and role of codes. This understanding can then be applied to an organisation or industry circumstance for the purpose of evaluating the best regulatory option.
There are many arguments for why an organisation may want to adopt a privacy code, however, adopting a code is not mandatory. An organisation may choose to comply with the default NPPs if they are likely to satisfy its objectives.
If an organisation decides that it wants to adopt a privacy code, it is likely that the decision will be based on:
Before embarking on the code development process, it is advisable that organisations check for any existing privacy codes that may have been developed by industry participants or industry associations that may have overlapping coverage. The reason for this is that an excess of privacy codes in an industry is likely to lead to consumer confusion - something the Privacy Commissioner wants to avoid. (Please refer to chapter 4 for additional information on matters that the Privacy Commissioner will consider before approving a privacy code.)
Following is a short list of reasons why an organisation might decide to adopt a code rather than simply comply with the baseline NPPs. This list is by no means exhaustive nor is it all-inclusive, it is simply designed to help organisations work through the rationale for having a code.
With the commencement of the new amendments to the Act on 21 December 2001, the Privacy Commissioner will have additional complaint handling functions due to a wider coverage of private sector organisations. Private sector organisations that are subject to the Act will either be bound by the NPPs in the Act or a code approved by the Privacy Commissioner that contains principles that are at least overall equivalent to the NPPs and to which the organisation has subscribed.
Individuals will still be able to complain about interferences with their privacy, however the Privacy Commissioner will not be the only avenue for redress. The Privacy Commissioner will handle complaints about breaches of the NPPs in the Act. If an approved code contains a complaints handling process, a code adjudicator will investigate complaints against a code subscriber instead of the Privacy Commissioner. The code proponent may appoint the Privacy Commissioner to be the code adjudicator if the Privacy Commissioner agrees, or it may appoint an independent code adjudicator.
As it is possible for the privacy rights of individuals to be upheld by a code adjudicator as well as the Privacy Commissioner under the co-regulatory model, the success of co-regulation will largely depend on effective communication between all parties, and particularly with individuals. It will be important for individuals to be able to easily find out whether an organisation is bound by the NPPs or an approved code and whether the Privacy Commissioner or an independent code adjudicator will deal with their complaint if they are unable to resolve it directly with the organisation concerned. The mechanism for making this information readily available is discussed in chapters 4 and 5.
The Privacy Commissioner will also be able to review complaint decisions made by an independent code adjudicator. Determinations made by a code adjudicator may be enforced by orders of the Federal Court of Australia or the Federal Magistrates Court.
|
A summary of code options:
|
Organisations will also need to be aware that develop and implementing a privacy code will necessarily require a commitment of resources. Obviously the costs will vary greatly from scheme to scheme with likely variants being whether or not the scheme establishes its own complaint handling body, the size and nature of the organisation/industry that will be covered by the code, and the nature of the code itself.
The following list is designed to assist organisations developing a privacy code by raising matters that should be considered before embarking on the process. Each of these matters will be discussed in more detail in later chapters.
The Office of the Federal Privacy Commissioner (OFPC) is able to provide some assistance to organisations that are considering or are in the process of developing a code. These guidelines will be the first source of assistance.
The OFPC will also provide some support to steering committees or related groups through privacy introduction workshops or presentations early in the code development process.
It will also provide a contact officer from its policy section to provide general (non-legal) advice to code development steering committees and assist them to resolve any privacy issue that is proving difficult for the committee.
However, OFPC staff will not be available to participate as a fulltime or part-time member or observer in any private sector code development committee. This will ensure that any potential conflict of interest arising between this sort of assistance and the formal approval of a code by the Privacy Commissioner is avoided.
The Privacy Commissioner understands that where there is collective industry action to sanction breaches of a privacy code there is the potential for such action to breach the competition provisions of the Trade Practices Act 1974 (Cth). The OFPC will consult with the ACCC and the Attorney General's Department on this matter and develop this section further before the guidelines are finalised.
Once an organisation has decided to develop a privacy code there are a number of things that will need to be considered further. Some of these matters are discussed in some detail in Chapter 4, while Chapter 5 will outline considerations and requirements in relation to complaints systems and code adjudication.
Chapter 4 is split into two categories of advice distinguished by the main body of text and the highlighted sections at the end of each subchapter. The main body of chapter 4 serves two functions. It forms a set of guidelines issued by the Privacy Commissioner under section 18BF(1)(a) of the Act, which give assistance to organisations developing and implementing a privacy code. It also serves to inform the guidelines issued by the Privacy Commissioner as established under section 18BF(1)(c) of the Act.
The second category of information will be a set of formal guidelines issued by the Privacy Commissioner as provided for by section 18BF(1)(c) of the Act (the highlighted sections). These formal guidelines list all the things a code proponent is required to do before the Privacy Commissioner will approve a code.
One of the key features of the co-regulatory approach to the Act is that industry has the opportunity to benefit from developing privacy codes and handling any complaints associated with the operation of these codes. However, along with this opportunity comes the responsibility of ensuring that codes, which are essentially replacing the legislation, are adequately discussed with the relevant stakeholders.
When government initiates and develops regulation, and industry develops voluntary codes of conduct on other issues, extensive consultation is generally a key element. Privacy codes should not offer less opportunity for the public to comment on and examine industry led regulation, particularly when the code seeks to replace consumer protection under default legislation. Effective consultation will ensure that codes adequately meet the needs and expectations of both industry and individuals. The credibility and integrity of the co-regulatory approach depends on privacy codes gaining widespread support and acceptance from stakeholders (especially consumers).
The Privacy Commissioner is unlikely to approve a code unless consultation conducted by the code proponent has produced no serious objections from relevant stakeholders - particularly those representing consumer interests. If a code proponent cannot clearly demonstrate that all relevant stakeholders have had an adequate opportunity to comment on a code then the Act allows the Privacy Commissioner to conduct a separate public consultation process. However, relying on the Privacy Commissioner to undertake consultation will generally mean that the approval process will be subject to considerable delay.
The Privacy Commissioner will not use these consultation powers to broker a resolution between the code proponent and other stakeholders who have raised serious objections. Unless the code proponent can work directly with stakeholders to resolve such differences, the Privacy Commissioner is most unlikely to approve a code subject to such objections.
Defining adequate consultationThe Act states that the Privacy Commissioner can only approve a code after being satisfied that the public has been given an adequate opportunity to comment on it. The term adequate is a subjective one and therefore will be judged according to varying conditions and circumstances. For example, where an industry is highly specialised and has a distinct clientele it may not be necessary to consult directly with a broad range of interest groups. Instead, adequate consultation in this circumstance may involve consulting only a small number of industry and community representatives that specialise in the field.
Consultation strategies will play an important part in the process of judging adequate consultation. It is important that consultation strategies not put up barriers or restrict opportunities for certain groups to respond. Some members of the community, for example, those with disabilities or with limited English language skills, may find it difficult using some communications channels or may need different timeframes in order to participate in a consultation process. An organisation should consider the methods it chooses to use for consultation and examine them for any potential access problems. For example, if your stakeholders come from English speaking and non-English speaking backgrounds, it may be inappropriate to only advertise in English language newspapers.
In most cases organisations will be expected to consult widely on a draft of a proposed privacy code. The main purpose of this is to ensure that key stakeholders and others impacted upon by the proposed code have not only been consulted but are largely supportive of it.
|
Example 1 An industry body representing financial advisers in NSW wants to consult on a proposed industry based privacy code. It might use the following methods:
|
The Consumer Affairs Division of the Department of the Treasury has issued a paper entitled Getting it Right: Ideas for Consulting Communities. This document describes the three key elements of effective consultation: careful planning, appropriate implementation and responsible outcomes, and provides helpful advice on how to conduct effective public consultation.
The Department of Family and Community Services has issued a paper called Inclusive Consultation: A practical guide to Involving People with Disabilities - available at http://www.facs.gov.au/disability/ood/consgide.htm. This guide has been developed to provide practical advice on how to consult with people with disabilities. It also offers strategies that are relevant for all consultations in order to cater for the broad needs of the community.
Other suggested methods of communicating with community stakeholders include:
Formal guidelines in relation to s.18BB(2)(f)
Section 18BB(2)(a) of the Act provides that the Privacy Commissioner can approve a privacy code if, and only if, the code incorporates all the NPPs or sets out obligations that, overall, are at least the equivalent of all the obligations set out in those Principles.
This means that the Act does not limit the drafting of codes to an exact reproduction of the NPPs. Instead it gives organisations the option of modifying the default principles to best suit an organisations needs. Some examples of how the default principles can be modified in codes include:
However, as stated above, a code that modifies the NPPs in any way must still be at least overall equivalent. When deciding whether a code is equivalent, the Privacy Commissioner, among other things, will refer to any guidelines issued by the Privacy Commissioner on the application of the NPPs. These guidelines document the Privacy Commissioner's view of how the NPPs should be applied. Codes will not be approved if they undermine the interpretation expressed in these guidelines, as this will necessarily lessen the obligations set out in the NPPs. The Privacy Commissioner will also consider the views of consumers and other stakeholders when judging equivalency.
Given that the Act requires an approved code to be overall equivalent to the NPPs, there is the potential for a code proponent to seek approval to have obligations under a principle lowered, providing that they can clearly demonstrate that the code adequately compensates for this reduction in other ways.
Codes can not be approved if there is the potential that individuals will have less protection than they would otherwise be afforded under the default principles.
|
EXAMPLE 2 - Higher obligations
An organisation that collects personal information for a primary purpose only, may decide to relinquish its right to use and disclose personal information for a secondary purpose on the basis that it is a related purpose and there is a reasonable expectation (i.e. NPP 2.1 (a)) Instead, they may choose to rely mainly on obtaining consent from the individual before using personal information for a secondary purpose should the need arise. This approach would offer additional protection to the individual, and the removal of this subsection does not detract from any of the organisations obligation. As such, it would be considered at least equivalent. |
|
EXAMPLE 3 - Industry Specific Language / Context
An industry association, which represents organisations that predominantly collect consumer profiling information, may wish to modify NPP1 in the following way:
The addition of the bracketed words does not detract from the broader definition of personal information. It may, however, help the members understand what is meant by personal information in the context of the industry. Note that the same outcome could have been achieved by the addition of explanatory material to the code which makes it clear to the member organisations that consumer profiling information is personal information. |
Formal guidelines in relation to s.18BB(2)(a)
Explanatory material to a code can help to tailor a set of privacy principles to the specific needs of an organisation or industry. It is likely that explanatory material will take the form of practical examples or written statements suggesting ways that certain principles can be practically followed.
Privacy Commissioner as Complaint HandlerIf a privacy code does not include a complaint handling mechanism the Act provides that the Privacy Commissioner will handle any complaints made under the code.
The guidelines to the NPPs, which will explain how the Privacy Commissioner expects the NPPs to operate in practice, will be relevant to the investigation, resolution or determining of complaints. Although the guidelines will not be legally binding in a direct sense, they will provide organisations and individuals with a guide as to how the Privacy Commissioner may deal with complaints.
Code Adjudicator as Complaint HandlerWhere a code is to include a complaint handling mechanism the Act provides that an independent code adjudicator must be appointed to handle complaints. A code proponent may wish to develop materials that will help the code adjudicator to more effectively handle complaints. In some cases the NPP guidelines will be used for this purpose but it is possible for an organisation to develop industry specific explanatory material.
If the explanatory, or interpretive, material is intended to be binding on the code adjudicator, it should be included in the application for code approval. In general the material should be consistent with the interpretation of the NPPs as outlined in the Privacy Commissioner's NPP Guidelines. However, departures from the NPP Guideline interpretation may be approved if the changes have been included as part of the consultation process and there is evidence of support for the changes and the changes do not affect the code's overall equivalency.
Formal guidelines in relation to explanatory material to a codeThe Act requires that before the Privacy Commissioner can approve a code, the code must either:
It must be clear to the Privacy Commissioner, other regulators and individuals, which organisations (or parts of organisations) are bound by a code at any given time. Therefore, one of the obligations of a code administrator will be to maintain a clear and easily accessible record of code participants. One way of doing this is to maintain an up to date website with links to relevant organisations and to the Privacy Commissioner's website. (The OFPC will also maintain a website that provides for a register of all approved codes with appropriate links.) It would also be advisable to devise ways to make this information readily available to individuals who do not have access to the Internet.
Organisations or industries that would prefer not to maintain an online register would need to convince the Privacy Commissioner that individuals would be advantaged by an alternative system. In each case the register of organisations bound by the code would need to be well maintained and up to date.
If the code is intended to cover an organisation that is the parent company of a number of subsidiary organisations, and it is intended that each of the subsidiary organisation are to be bound by the code, then the names of all subsidiary organisations must be included.
If an organisation states that it complies with an approved privacy code but is not registered in some way with the code administrator, the Privacy Commissioner will deem the organisation not to be bound by the code. Such organisations should also consider the implications of this behaviour in terms of other legal requirements, including the Trade Practices Act 1975 (Cth).
Formal guidelines in relation to s.18BB(2)(b) and s.18BB(2)(d)
The Privacy Commissioner can only approve a privacy code when being bound by the code is a voluntarily act of an organisation, that is, when it is not compulsory for any organisation to be bound. This requirement is set out in the Act to ensure that the flexible approach embodied in the co-regulatory regime is supported.
Industry associations that represent organisations for which membership of the association is required by law (for example professional accreditation bodies) will need to take particular care that any proposed privacy code does not become a requirement of membership. This will also be an issue for organisations that are required by law to be bound by a code of conduct that regulates other industry practices for which the proposed privacy code is to be incorporated.
|
EXAMPLE 4 A Government regulator requires, as a condition of licensing, an organisation to be bound by an industry code of conduct that regulates one aspect of its operations. The industry body is seeking to incorporate the National Privacy Principles into this code of conduct as a way of streamlining its complaint handling processes. In this situation the Privacy Commissioner could not approve the proposed code as the code would appear to bind all members of a particular industry. In this situation the best solution may be for the industry body to allow the privacy elements of the proposed code to be optional for its member organisations. |
Formal guidelines in relation to s.18BB(2)(c)
Before the Privacy Commissioner will approve a code, it will need to have a built in review process, guaranteeing the periodic review of the operations of a code by an independent review body. This is also a requirement of the Prescribed Standards.
Periodic reviews should be undertaken at least once every three years and should encompass the content of the code and the operation of the external complaints resolution scheme where applicable. This is designed to help ensure that the code is meeting all the proposed objectives and remains relevant and up to date in a changing marketplace.
A review should allow for government, consumers and other stakeholders to comment on the operations of a privacy code. A response from the code administrator must accompany the independent report based on the review and must be submitted to the Privacy Commissioner within 30 days of the report being finalised. Ideally all reports should also be made public to allow for public comment.
If the Privacy Commissioner becomes aware that an independent review has not occurred after the period indicated at the time of code approval, the option of revoking the code may be considered.
Formal guidelines in relation to code review
The Act allows for the Privacy Commissioner to approve a privacy code that is intended to operate for a limited period of time, or that will expire in certain circumstances. If an organisation intends to submit a limited life code the following will need to be clearly illustrated in the code:
Formal guidelines in relation to s.18BB(6)
The Act provides for the Privacy Commissioner to approve a code that covers only certain operations of an organisation. For example, a code can apply to:
If an organisation proposes a code to cover only certain aspects of its operations then the code must make absolutely clear what operations are covered by the code and what operations are bound by the default principles. The key here is avoiding any type of consumer confusion as to what is covered by a code. Therefore, depending on the nature of the proposal it may be appropriate for the code administrator to implement additional measures to advertise the existence of the code to consumers and clearly explain the circumstances of the codes operations.
Formal guidelines in relation to s.18BB(7)
An approved privacy code will replace the default privacy principles in the Act meaning that the code will be binding on its signatory members as though it were a piece of legislation. Because of this, a code must be carefully drafted to an appropriate legal standard. An organisation should take particular note of this requirement if it intends to modify the existing principles or include a complaints handling mechanism.
Each paragraph in the code should be numbered.
To help individuals and organisations understand their rights and obligations, the code must be unambiguous and clear - and where possible written in plain English.
In general, a code should not include industry jargon unless the language is clearly understood by all stakeholders, or a list of definitions is included in the code.
If an organisation does not have expertise in drafting codes, it may be useful to enlist outside expertise.
Formal Guidelines in relation to drafting the code
Regulatory Impact Statements (RIS) Government policy requires the Privacy Commissioner to consult with the Office of Regulation Review (ORR) as part of the code approval process. Part of this consultation includes the preparation of a Regulation Impact Statement (RIS). Before the Privacy Commissioner can complete the RIS, the proponent must supply all the necessary information. The Privacy Commissioner has prepared a template in the form of a draft RIS that must be completed and submitted to the Privacy Commissioner with the code.
See Appendix 3 for a copy of the template.Formal guidelines in relation to drafting a RIS
Although co-regulation is the underpinning concept of the Act, the Privacy Commissioner recognises that approving multiple codes for a particular industry or sector may not lead to an overall satisfactory outcome for both business and consumers. Therefore, before approving a code the Privacy Commissioner will need to be satisfied that, among other things, the code does not create consumer confusion about privacy protection within an industry.
Given that the Privacy Commissioner will consider the market circumstances in which a code is to operate and the potential for consumer confusion, it is recommended that code proponents include with the application information on the following:
The Privacy Commissioner will also be considering the views of other stakeholders in relation to these matters.
The Act does not require a code administrator to publicise the existence of an approved code. However, given an effective code would be one that allowed organisations to better differentiate themselves in the marketplace, promotion of the code is likely to be a preferred option for most organisations. The Privacy Commissioner recommends promotion of a code as a good practice means to ensure that individuals are aware of the fact that an organisation is bound by a code.
While the law does not require publicity for a code, the Privacy Commissioner does require code members to make known the existence of a code during the course of a relevant transaction. For example, if an individual requests more information about an organisation's information handling practices, organisations will need to make this information available (this is also an obligation under NPP 5).
If a code provides for a complaints handling mechanism, individuals must be made aware of where to lodge complaints. This information must be available on request.
Individuals who require a copy of a code should also be able to obtain one on request from a code compliant organisation.
In addition to the above, there is value in promoting a code to code members. By encouraging compliance with a code, and assisting code members develop systems that allow them to comply, a code administrator will be able to build the image of an organisation or industry that respects the privacy rights of individuals.
Formal Guidelines for Code PromotionThis chapter provides information for code proponents about the option of having a complaint handling process built in to a code. It describes how such a complaint process would interact with the overall federal privacy complaint environment of the private sector.
Chapter 5, is divided into two parts - part 5A and part 5B. Part 5A will discusses matters code proponents should consider with regards to having a complaints handling process; it explains the requirements and the obligations specified in the Act; and will work to inform the provisions in part 5B.
Part 5B provides a set of formal guidelines issued by the Privacy Commissioner with regards to making and dealing with complaints under an approved privacy code. The Privacy Commissioner must be satisfied that a proposed code meets these guidelines before approving it.
The Privacy Commissioner must also be satisfied that a proposed complaint handling process meets standards prescribed in the Act. Appendix 1 reproduces the 1997 document titled, Benchmarks for Industry-Based Customer Dispute Resolution Schemes that was released by the then Minister for Customs and Consumer Affairs, the Hon Chris Ellison. The Attorney General has indicated that the Benchmarks will form the basis for these prescribed standards.
The Privacy Commissioner currently has jurisdiction over private sector organisations in respect to the handling of consumer credit information, tax file number information and spent conviction information. These types of information are regulated respectively by the Credit Reporting Provisions in Part IIIA of the Privacy Act; the Tax File Number Guidelines issued under section 17 of the Act; and the Spent Conviction Scheme in Part VIIC of the Crimes Act 1914 (Cth).
Once the new amendments to the Act have commenced operation, the Privacy Commissioner will retain the complaint handling roles in relation to these areas of jurisdiction. Irrespective of the provisions in an approved code, a subscriber to the code will still have to comply with the requirements upon it under the Credit Reporting Provisions, the Tax File Number Guidelines and the Spent Conviction Scheme. It will not be possible for a code adjudicator to make decisions about compliance with the provisions in these pieces of legislation. However, the NPPs or the equivalent under an approved code will also apply to consumer credit information, tax file number information and spent conviction information because these are simply specific types of 'personal information'.
This may cause some confusion for individuals who wish to make a complaint concerning these types of information as to whom the complaint should be directed. Individuals will have the option of complaining to the Privacy Commissioner that a breach of the Credit Reporting Provisions, the Tax File Number Guidelines, the Spent Conviction Scheme or the NPPs has occurred, or complaining to a code adjudicator that a breach of the approved code has occurred.
In some cases, it may be difficult for code adjudicators to decide whether a complaint would be more appropriately handled by the Privacy Commissioner, such as where only a comparatively small part of the personal information involved in the alleged breach may be one of the types of personal information regulated by the more specific legislation.
|
Example 5 A complaint may involve an individual's accountant who has allegedly improperly disclosed extensive information about the individual's financial and taxation affairs, and the individual's tax file number was also disclosed because it appeared in several places amongst the documents. The disclosure of all of the individual's personal information is regulated by NPP2.1 or the equivalent under an approved code. However, the disclosure of the tax file number itself is also regulated by Guideline 2 of the Tax File Number Guidelines. |
It is more appropriate for the Privacy Commissioner to handle a complaint from an individual about the improper handling of his or her consumer credit information, tax file number information or spent conviction information. The provisions of the relevant legislation were designed to offer greater protection over these specific types of personal information. It is also possible that an organisation may have committed a tax file number offence or a credit reporting offence in the course of dealing with an individual's information and, under section 49 of the Act, the Privacy Commissioner is obliged to refer such matters to the Australian Federal Police or the Commonwealth Director of Public Prosecutions for the purpose of those authorities considering criminal proceedings against the organisation.
It is important that individuals are aware that the Privacy Commissioner is the more appropriate person to consider such complaints and consequently, code adjudicators will be required under the Privacy Commissioner's Guidelines to inform complainants of this and will be able to refer such complaints to the Privacy Commissioner.
Where the handling of personal information by an organisation is regulated by the NPPs in the Act, an individual's complaint of an interference with his or her privacy will be handled by the Privacy Commissioner in the same way as a complaint under the current jurisdiction. The Privacy Commissioner's existing powers and discretions in the Act will also apply to complaints where an organisation is subject to the default principles.
This does not mean that private sector organisations will not be able to resolve complaints directly with an individual. Indeed, the Privacy Commissioner strongly encourages such direct resolution in the first instance. In addition, under section 40(1A) of the Act, the Privacy Commissioner must not investigate a complaint under the NPPs, unless the respondent has had an adequate opportunity to deal with the complaint.
Where the Privacy Commissioner has approved a code that does not include a complaint handling process, complaints about a breach of the code will be handled by the Privacy Commissioner in accordance with the complaint handling process set out in the Act. That is, a similar approach to that used for handling a complaint under the NPPs.
Whether or not a code proponent wishes to include complaint adjudication provisions in the proposed code is a matter the code proponent will need to consider carefully. Part 5A.4 of this document elaborates on some of the considerations that a code proponent may wish to take into account in making this decision.
Reasons for having a complaints handling process built into a code
Code adjudicators will have very similar powers to those of the Privacy Commissioner for handling complaints. A code adjudicator will be able to dismiss complaints on certain grounds and will be able to order a subscriber to undertake remedies analogous to those that the Privacy Commissioner may order under section 52 of the Act to resolve a complaint. This means code members can potentially benefit from increased customer confidence associated with having access to a complaint resolution process that is virtually the same as the Privacy Commissioner's and is also tailored to the particular circumstances of the sector covered by the code.
Initial customer confidence in an independent process would also come from customers being made aware that they can always request the Privacy Commissioner review any decision made by the code adjudicator.
Over time, code adjudicators could be expected to develop specialist industry knowledge and experience and establish solid contacts with the code members that should lead to efficient and consistent complaint resolutions.
Subscribers to a code containing a complaint handling process may also be able to offer their customers a one-stop dispute resolution service that will be able to deal with multi-faceted problems, including privacy issues, that customers have with a code member. An organisation that chooses to have its own code and has an existing complaint or customer service infrastructure would be able to appoint a person in the infrastructure as the code adjudicator under the code process provided they meet the prescribed standards and the Privacy Commissioner's guidelines.
An organisation that is able to successfully resolve the majority of its customers' concerns, including concerns about information privacy, without the need for recourse to the Privacy Commissioner may also be able to build strong relationships with its customers.
If the code adjudicator circulates its findings from resolved complaints, without identifying the parties, all code members will benefit from learning how customers expect their personal information to be handled and best practice will develop specifically for the sector covered by the code. In this way, even code members that have very few complaints will still benefit from participating in the scheme.
Potential costs associated with having a complaints handling process
In Chapter 3, there is some discussion about the likely resources necessary for developing a code such as obtaining professional advice, consulting with industry members and peak bodies, and consulting with members of the public.
While code members will bear some costs arising from having an approved code, such as supporting the code administrator, these costs will increase if there is a complaint handling process under the code as well. If a complaint handling process is included in the code, under section 18BB(3)(b) of the Act, it is mandatory to have a code adjudicator to make decisions on complaints under that process.
A code adjudicator would have to be provided with an infrastructure within which to carry out its functions, such as providing information to individuals, receiving and investigating complaints, and reporting to the Privacy Commissioner. The infrastructure will largely be determined by the requirements upon code adjudicators under the Act, the prescribed standards, the Privacy Commissioner's guidelines and the particular features of the complaint handling process under the approved code. The volume of complaints received will also have a bearing on the size and complexity of the infrastructure.
At the very least, the code adjudicator would require funding, support staff and administrative services to be able to independently carry out investigations and meet the associated requirements, such as reporting to the Privacy Commissioner. Benchmark 2.9 of the prescribed standards specifically provides that a scheme must have sufficient funding to enable it to meet its functions and obligations in accordance with the Benchmarks. (Refer to Appendix 1)
Even if a code includes complaint handling processes, it is possible to appoint the Privacy Commissioner as the code adjudicator. The Privacy Commissioner will not agree to perform this role under such an approved code unless the code proponent meets the full cost of the Privacy Commissioner providing the service.
Under the prescribed standards, there must be an overseeing entity that has overall responsibility for the complaint handling process under the code. It has such roles as hiring and managing the code adjudicator and the code administrator. For an organisation with its own code, this would at least require the diversion of existing resources and possibly the commitment of additional resources. For a jointly subscribed code, code members will have to fund this entity as well.
Code members will also have to devote resources to training the relevant staff in their organisation about the operation of the complaint handling process under the code (although similar training would be necessary anyway if the Privacy Commissioner is to deal with complaints under the process set out in the Act). Ideally, a code member will need to have a staff that is able to effectively deal with a complaint under the terms of the code in order to avoid the need for the code adjudicator to become involved. Staff will also need to have the skills to respond to the code adjudicator if the matter is taken up.
The prescribed standards also impose a number of procedural requirements upon code administrators and code members that will require a certain allocation of resources. For example, under Benchmark 1.1 to 1.6 inclusive, the standards require the code administrator to promote the existence of the scheme in the media or by other means and to do so in such a way as to be sensitive to disadvantaged customers or customers with special needs. Code administrators are obliged to produce readily available material about the operation of the scheme and to require code members to inform customers about the scheme. Meeting these procedural requirements will also require resources and training for the staff of the administrators and the code members.
A flow chart explaining the complaints handling process is at Appendix 4.
Requirements for a complaint handling process under an approved code
Having privacy complaints handled by a code adjudicator is an alternative to complaints being handled by the Privacy Commissioner under the process in the Act. However, for reasons of consistency the processes for handling complaints under a code must meet many of the same requirements. The complaint handling process must be readily accessible and simple for individuals to understand, so that they are able to negotiate their way through the process without the necessity of legal representation. As most individuals will have no experience in dealing with such processes, it is essential that the process be structured in such a way that gives individuals confidence in the way their complaint is being handled. To that end, prescribed under the Act are a set of complaint handling standards which must be followed. As well, the Act gives the Privacy Commissioner powers to issue guidelines on designing a complaint handling process for inclusion in a code.
Where a code lodged for approval by the Privacy Commissioner includes a complaint handling process, the Privacy Commissioner must be satisfied that the requirements set out in sections 18BB(3)(a) to (l) of the Act have been complied with before he or she may approve the code.
In particular, section 18BB(3)(a) provides that the Privacy Commissioner must be satisfied that any complaint handling process in a code must meet both the prescribed standards and any guidelines issued by the Privacy Commissioner for making and dealing with complaints.
Explanation of the prescribed standards under section 18BB(3)(a)(i) of the Act
Under this provision, the Attorney General may issue prescribed standards that must be met by any code complaint handling process. As at the date of issue of these draft guidelines no standards had been prescribed. However, the Attorney General has already undertaken to prescribe standards based upon the Benchmarks for Industry-Based Customer Dispute Resolution Schemes (the "Benchmarks"). The Benchmarks were released in August 1997 by the Hon Chris Ellison, then the Minister for Customs and Consumer Affairs.
The Benchmarks are currently under review. The Attorney-General's Department has indicated that the Benchmarks will be prescribed before the review has been completed, if necessary, in order to have standards prescribed to facilitate the approval of codes containing complaint handling processes and before these guidelines are finalised. Once the review is complete the Benchmarks will be re-prescribed.
The Benchmarks are attached at Appendix 1 for information and may also be found at: www.treasury.gov.au
Explanation of the guidelines issued by the Privacy Commissioner referred to in section 18BB(3)(a)(ii) of the Act
Under section 18BF(1)(b) of the Act, the Privacy Commissioner has the power to issue guidelines for making and dealing with complaints. These guidelines are intended to supplement the prescribed standards and contain guidance on some specific aspects of complaint handling that the Commissioner considers should be specified in a process under a code. The Privacy Commissioner's guidelines form part B of chapter 5.
The Privacy Commissioner also has power to issue guidelines under section 18BF(1)(c) of the Act, which under section 18BB(4) may be considered when making a decision about whether to approve or decline a code lodged for approval. These guidelines could potentially include further requirements for a complaint handling process under an approved code. However, it is unlikely that the Privacy Commissioner would include any requirements for complaint handling processes in such guidelines, as it would clearly be preferable for the requirements to reside in as few sources as possible. At this stage, the requirements for complaint handling processes under a code already arise from three places: Part IIIAA of the Act, the prescribed standards and the Privacy Commissioner's guidelines issued under s18BF(1)(b) of the Act.
Code adjudicators will not necessarily have to fully investigate every complaint.
Complainants should attempt in the first instance to resolve their complaints directly with the subscriber and to give the subscriber a reasonable opportunity to deal with the complaint before the code adjudicator needs to consider the matter. The Privacy Commissioner has taken the view under his or her existing jurisdiction that, generally speaking, it is reasonable for a respondent to have sixty days in which to deal with an individual's complaint before the Privacy Commissioner would consider investigating the matter. The Privacy Commissioner considers that code adjudicators should have a similar discretion.
|
Issue for comment: Is sixty days a reasonable period to allow a subscriber to respond before the code adjudicator must consider the complaint? |
If the complainant has complained to the code member directly and has not received a reply or is not satisfied with the response, the code adjudicator must determine the complaint. The code adjudicator also has the option of referring the complaint to another adjudicator or to the Privacy Commissioner. The requirements in relation to referring complaints between adjudicators are listed in part B of chapter 5.
A code adjudicator will be able to determine that a complaint is dismissed under one or more of the grounds in Guideline 5 of the Privacy Commissioner's guidelines. These grounds are similar to the discretion conferred on the Privacy Commissioner under section 41 of the Act and include that the complaint is dismissed because it is frivolous or vexatious or there is no evidence of a breach. The Privacy Commissioner considers that these should be reviewable decisions that either of the parties may bring forward for review.
Further to this, the Privacy Commissioner strongly encourages code adjudicators to conciliate outcomes so that, wherever possible, the determination is in fact simply the recording of an outcome that all parties have already agreed upon. This is analogous to the way the Privacy Commissioner currently handles complaints. This approach is explicitly provided for in Part 5B Guideline 5.1(vi), which allows the adjudicator to determine that the complaint be dismissed where the adjudicator concludes the respondent has taken steps to adequately deal with the complaint.
Referral of complaints by a code adjudicator to the Privacy Commissioner
There are two situations where referral of complaints to the Privacy Commissioner can occur.
Firstly, where the complaint is against an organisation that is carrying out functions or services that involve the handling of personal information under contract with a Commonwealth agency. In such cases, a code adjudicator is obliged under section 40A of the Act to refer the matter to the Privacy Commissioner and the Privacy Commissioner must accept the complaint.
Secondly, it is possible under section 40(1B) of the Act for a code adjudicator to refer a complaint that could normally be investigated by the code adjudicator to the Privacy Commissioner. The Privacy Commissioner does not have to accept such complaints and generally takes the view that where an approved code with an independent complaint handling process has been set up, the code adjudicator should deal with all complaints received except in exceptional circumstances.
Reviewing a decision made by a code adjudicator
An individual who is not satisfied with a determination by a code adjudicator may, under section 18BI(1) of the Act, request the Privacy Commissioner review the determination (except where the Privacy Commissioner is the code adjudicator).
A review by the Privacy Commissioner of a code adjudicator's determination is treated in the same way as a complaint received by the Privacy Commissioner under the normal complaint investigation powers. While it is possible for the review to effectively be a fresh investigation of the complaint, it may only be necessary for the Privacy Commissioner to reconsider the decision, if the Privacy Commissioner is satisfied that all of the relevant issues have been investigated and all material evidence has been obtained. The Privacy Commissioner may also proceed to a determination under section 52 of the Act for the purpose of settling the complaint. Determinations by the Privacy Commissioner under section 52 of the Act may be enforced in the Federal Court or the Federal Magistrates Court.
The Federal Court or the Federal Magistrates Court does not review determinations of the Privacy Commissioner or a code adjudicator by way of appeal from a complainant or respondent that is dissatisfied with the determination.
The role given to the Federal Court or the Federal Magistrates Court (collectively, the Court) is to consider making enforcement orders against a respondent that is obliged to take particular action under a determination made by either the Privacy Commissioner or a code adjudicator. The Court will conduct a de novo hearing on the issue of whether or not the respondent has breached the Act or an approved code, however, respondents do not have standing under the Act to commence enforcement proceedings as means of instituting a review of a finding that they have breached the Act or an approved code.
Sources of complaint handling requirements
Once the Privacy Commissioner has approved a code containing a complaint handling process, the code adjudicator must handle complaints in accordance with the process set out under the code. In some circumstances, the code adjudicator may have to refer to certain specific provisions in the Act, such as those that regulate the referral of complaints to the Privacy Commissioner, however generally speaking the code should be a stand-alone document.
The prescribed standards and the Privacy Commissioner's guidelines for making and dealing with complaints do not play a role in relation to the handling of specific complaints made under an approved code. Essentially, the prescribed standards and the Privacy Commissioner's guidelines for making and dealing with complaints are binding upon the Privacy Commissioner for the purpose of approving a code. However, the Commissioner has power to revoke a code. In this way, the operations of a code and its adjudicator can be reviewed if necessary. The Commissioner would consider the prescribed standards and the guidelines in the course of such a review. Chapter 7 covers the review and revocation of codes in more detail.
Reporting to the Privacy Commissioner
A major on-going requirement is providing the Privacy Commissioner with annual reports on complaints handled by the code adjudicator. In order for the Australian public to hold confidence in a co-regulatory privacy complaint handling model, it is vital that information on the effectiveness of complaint handling processes under approved codes is readily available.
The Privacy Commissioner is required, under section 97(2A) of the Act, to include in the Commissioner's annual report to the Minister, a statement about the operation of approved privacy codes that contain a complaints handling procedure. The Commissioner is required to include a statement about action taken by adjudicators to monitor compliance with the codes, and details about the number, nature and outcome of complaints made under codes. In order for the Commissioner to be able to meet this requirement, it is necessary for the Commissioner to receive adequate information to assess the effectiveness of complaint handling processes under approved codes. The Commissioner will gain some insight by way of the decisions that are submitted for review, however the most important means will be the reports that must be provided to the Commissioner.
The reporting requirements are set out in section 18BB(3)(h) to (l) of the Act and in part B of chapter 5 of these guidelines. These reports must be provided to the Privacy Commissioner in the required format and within the required timeframe which are spelt out in Guideline 6.1(i) and (ii). The prescribed standards also require that the code adjudicator prepare certain reports in relation to the operation of the code under Benchmarks 4.3, 5.13 and 6.13 and provide them to the overseeing entity. These reports would be informative to the Commissioner.
Confidence in the complaint handling process under a particular code may be put at risk if proper reporting to the Privacy Commissioner does not occur. If these reports are not provided or they indicate inconsistencies with other similar schemes or there appear to be anomalies in the statistics, the Privacy Commissioner may approach the code administrator using the general review power in section 18BH of the Act. Such a review may lead to revocation of the code, as this is the only way for the Privacy Commissioner to terminate the operation of a flawed complaint handling process under an approved code.
Internal and Independent reviews
Benchmark 6 of the prescribed standards also includes on-going obligations upon a code administrator to have processes in place to deal with complaints about the scheme and an internal complaints mechanism.
There is also an obligation to commission independent reviews of the operation of the scheme against factors set out in Benchmark 6.12. Unlike the reports on complaint handling that must be given the Privacy Commissioner annually, Benchmark 6.11 requires these independent reviews to be undertaken within three years from the establishment of the scheme and regularly thereafter. The reviews must be undertaken in consultation with relevant stakeholders and the Privacy Commissioner would be such a stakeholder.
Where a code has been lodged under section 18BA of the Privacy Act 1988 for approval by the Privacy Commissioner and the code sets out procedures for making and dealing with complaints, those procedures must also satisfy the following guidelines issued by the Privacy Commissioner pursuant to section 18BF(1)(b) of the Act before the Privacy Commissioner may approve the code under section 18BB(2) of the Act.
1 |
Representative Complaints |
1.1 |
The complaints handling process under a code must include a process for accepting, investigating and making a decision on a representative complaint. |
2 |
Determinations |
| 2.1 | The code adjudicator is obliged to determine a complaint, except where: |
(i) |
the complainant has not first complained the respondent and, |
(a) |
the complaint has not been resolved to the satisfaction of the complainant, or |
||
(b) |
the respondent has not responded to the complaint within 60 days from the date that the complaint was lodged with the respondent; |
(ii) |
the complaint has been referred to the Privacy Commissioner under sections 40(1B) or 40A(2)(b) of the Act; or |
(iii) |
the complaint has been referred to another code adjudicator in accordance with guideline 4 of these guidelines. |
| 3 | Referral of complaints to the Privacy Commissioner under section 40(1B) |
3.1 |
The Privacy Commissioner generally expects that code adjudicators will deal with all complaints received by them, except those that must be referred to the Privacy Commissioner under the Act. The Privacy Commissioner expects code adjudicators to determine complaints properly and diligently and to be appropriately resourced to be able to do so. This provision was not intended to be relied upon by code adjudicators simply for the purpose of passing difficult or complex complaints to the Privacy Commissioner for resolution. |
3.2 |
A code adjudicator must have reasonable grounds for believing that a complaint should be referred to the Privacy Commissioner. If a code adjudicator refers a complaint to the Privacy Commissioner and the Privacy Commissioner declines to accept it, the Privacy Commissioner would be obliged to give reasons for doing so. The Privacy Commissioner does not expect this process to be used by code adjudicators as a means of seeking insight into the way in which the Privacy Commissioner views a complaint. |
| 3.3 | The complaints procedures must provide that a code adjudicator may refer a complaint to the Privacy Commissioner under section 40(1B) only where: |
(i) |
section 40A(1) of the Act requires the complaint to be referred because the respondent is a contracted service provider for a Commonwealth contract and the act done or the practice engaged in by the respondent, that is the subject of the complaint, was for the purposes of meeting (directly or indirectly) an obligation under the contract; |
|
(ii) |
there would be a conflict of interest if the code adjudicator made a decision on the complaint; |
|
(iii) |
the respondent to the complaint is not a subscriber to the code under which the code adjudicator makes decisions on complaints and the code adjudicator is unable to identify another approved code under which the complaint could be more appropriately handled; or |
|
(iv) |
The complaint would be more appropriately dealt with by the Privacy Commissioner under the Tax File Number Guidelines, the Credit Reporting Provisions, or the Spent Conviction Scheme and the complainant has agreed to the referral. |
4 |
Referral of a Complaint to another Code Adjudicator |
4.1 |
A code adjudicator may refer a complaint to another code adjudicator if the first-mentioned code adjudicator: |
(i) |
considers that another code is more appropriate in its application or remedies to the circumstances of the complaint; |
|
(ii) |
has consulted with the code adjudicator that is proposed to deal with the complaint about whether the complaint would be more appropriately dealt with by that code adjudicator; |
|
(iii) |
has advised the complainant of the reasons for the proposed referral and the complainant agrees to the referral; and |
|
(iv) |
has advised the Privacy Commissioner in writing of the proposed referral and the Privacy Commissioner has not notified the code adjudicator within seven days of receiving the advice that the referral should not take place. |
5 |
Dismissal of complaints |
5.1 |
The complaints procedures must provide that a code adjudicator may only dismiss a complaint under a determination where he or she is satisfied that one or more of the following grounds apply: |
(i) |
there is no breach of the approved code; |
|
(ii) |
there is no evidence of a breach; |
|
(iii) |
the complaint is frivolous or vexatious; |
|
(iv) |
the complainant has expressly withdrawn the complaint or requested that no further action be taken on the complaint; |
|
(v) |
the respondent has taken steps to adequately deal with the subject of the complaint; |
|
(vi) |
the act or practice complained about is the subject of an application under another Commonwealth enactment and the subject-matter of the complaint has been, or is being, dealt with adequately under that enactment; or |
|
(vii) |
the act or practice complained about could be the subject of an application under another Commonwealth enactment for a more appropriate remedy. |
6 |
Reporting to the Privacy Commissioner |
6.1 |
The complaints procedures must provide that: |
(i) |
in accordance with section 18BB(3)(h) of the Act, the report to the Commissioner on the operation of the code shall be provided to the Commissioner: |
(a) |
in an electronic format specified, from time to time, by the Privacy Commissioner; and |
||
(b) |
using a template issued annually by the Commissioner two months prior to the commencement of the financial year (or in the case of the first report, two months prior to the commencement of the Privacy Amendment (Private Sector) Act 2000). |
(ii) |
in accordance with section 18BB(3)(i) of the Act, the report to the Commissioner on the operation of the code for a given financial year shall be provided to the Privacy Commissioner within two months of the end of the financial year; |
|
(iii) |
in conjunction with the matters to be included in the report to the Commissioner on the operation of the code as required under section 18BB(3)(k) of the Act, the report shall include: |
(a) |
the number of unresolved complaints as at the end of the financial year and the status of those complaints categorised as: |
|
(b) |
of the complaints received during the financial year, the number where the code adjudicator has exercised the discretion conferred by Guideline 3.1(i) and referred the complainant to the subscriber to attempt to resolve the matter directly before the code adjudicator would consider the matter further; and the complainant has not first complained the respondent and, |
||
(c) |
of the complaints referred to in paragraph (b), the number that were resubmitted to the code adjudicator for reconsideration due to the complainant not being satisfied with the response of the subscriber. |
(iv) |
in conjunction with the matters to be included in the report on the operation of the code as required under section 18BB(3)(ka) of the Act, the summary for each complaint finally dealt with during the relevant financial year shall specify the time taken to resolve the complaint; |
|
(v) |
subscribers to the code must report annually to the code administrator on complaints received by them directly from individuals during the financial year and the report must include the number of complaints received, the nature of the complaints by reference to the relevant NPP or equivalent under the code, the outcome of the complaint, and the number of complaints that have been resolved to the satisfaction of both parties; |
|
(vi) |
the report on the operation of the code from the code adjudicator to the Commissioner shall also include: |
(a) |
an aggregate report based on the information provided to the code adjudicator in accordance with Guideline 6.2 (v); |
||
(b) |
the number of complaints received during the financial year that were referred to another code adjudicator or to the Privacy Commissioner and the reason for the referral; and |
||
(c) |
a copy of reports given to the overseeing entity during the relevant financial year on the operation of the code as required in the prescribed standards. |
(vii) |
the report under section 18BB(3)(h) shall also include statistical information on the number of enquiries that the code adjudicator received during the financial year, set out in categories agreed in consultation with the Privacy Commissioner during the process of approving the code. |
|
(viii) |
the report under section 18BB(3)(h) shall also include statistical information on: |
(a) |
the geographical source of complaints by State or Territory of Australia, and |
||
(b) |
the number of complaints received during each calendar month. |
This chapter is designed to help direct organisations wanting to submit a code to the Privacy Commissioner for approval under the Act. It will also provide a summary of what can be expected during the consideration process.
An application for approval of a privacy code should be made in writing or email and must be accompanied by supporting documentation. There is no formal application form to fill out. Instead the application document should set out the following:
The application should be forwarded to:
Office of the Federal Privacy Commissioner
Code Approval Team
GPO Box 5218
Sydney 1042
Or delivered to: level 8, 133 Castlereagh Street, Sydney, 2000.
Or by email to: privacy@privacy.gov.au
Please note that if submitting a code for approval via email that the transaction may not be a secure transaction. Due care will be needed to protect any confidential information accompanying the application.
Upon receiving an application to approve a privacy code from an organisation, the OFPC will send an acknowledgement letter to the proponent within 7 days.
Timeframes for assessing a code application will vary depending on a number of factors. These may include:
As a general rule, the OFPC intends to assess proposed codes within two month of receiving an application.
The Privacy Commissioner's approval for a code will be made to the organisation in writing. The approval will include the date when approval will take effect, which will not be before the day on which approval is given.
If the Privacy Commissioner has made a decision not to approve a code, the organisation will be notified in writing. Notification will include:
Section 18BG of the Act requires the Privacy Commissioner to keep a register of approved codes. When a code is approved, the title, the code administrator, and contact details will be placed upon the Privacy Commissioner's register of approved privacy codes. It is anticipated that the register will be available in an up to date format on the Privacy Commissioner's website on www.privacy.gov.au.
This chapter will explain the procedures for amending or terminating a code and will outline the conditions under which a code approval can be revoked by the Privacy Commissioner.
An organisation may apply in writing (or email) to the Privacy Commissioner for approval of a variation to an approved privacy code. An organisation must provide the Privacy Commissioner with a copy of the amended code.
In deciding whether to approve the variation, the Privacy Commissioner will consider all the matters listed in chapter 4. However, if the amendment is minor in nature, the Privacy Commissioner can choose to waive the organisation's obligation to consult with members of the public. If the Privacy Commissioner chooses this option, it is likely that the Privacy Commissioner will undertake some direct consultation with appropriate consumer and stakeholder representatives.
If the proposed amendment is considered to be a major amendment (that is, it is likely to have a significant effect on the operations embodied in the code or is likely to have a measurable impact on a group of individuals) the amending organisation will be required to conduct a public consultation as discussed in chapter 4.
Under section 18BE of the legislation, the Privacy Commissioner has the power to revoke an approved privacy code. Revocation can occur at the discretion of the Privacy Commissioner or on request of the code administrator.
Following are some likely triggers that would lead the Privacy Commissioner to consider revoking a code.
If consensus cannot be reached the Privacy Commissioner may begin procedures for revocation. The procedures will be:
If a code is to be revoked on the request of the code administrator, the code administrator will be required to conduct a public education campaign, informing consumers of the intent to have the code revoked and the effects this is likely to have on the protection of their personal information.
Revoking the complaints handling mechanisms under a code
The Privacy Commissioner is unable to revoke only part of a code and leave the remainder intact. The Privacy Commissioner is also unable to vary a code under section 18BD of the Act of his own volition, so this mechanism can't be used by the Privacy Commissioner to, in practical terms, revoke just the complaint handling process.
If the Privacy Commissioner has decided that the complaint handling process under a code is seriously flawed and the code administrator was not prepared to submit a code with appropriate variations for approval, the Privacy Commissioner's only option would be to revoke the code in full in accordance with the revocation process set out in section 18BE of the Act.
If the Privacy Commissioner took the view that a complaint handling process under a code that had been approved in accordance with the prescribed standards, may not comply with subsequently prescribed standards, the Privacy Commissioner may review the operation of the code to inform a decision to revoke the code, unless the code administrator proposed a suitable variation to the code.
These Benchmarks were released by the Hon Chris Ellison, Minister for Customs and Consumer Affairs, in August 1997.
Source:
http://www.treasury.gov.au/publications/ConsumerAffairs/IndustrySelf-Regulation/BenchmarksForIndustry-BasedCustomerDisputeResolutionSchemes/index.asp| The scheme makes itself readily available to customers by promoting knowledge of its existence, being easy to use and having no cost barriers. |
Purpose
To promote customer access to the scheme on an equitable basis.
Key Practices
Awareness/Promotion
1.1.The scheme1 seeks to ensure that all customers of the relevant industry are aware of its existence.
1.2.The scheme promotes its existence in the media or by other means.
1.3.The scheme produces readily available material in simple terms explaining:
1.4.The scheme requires scheme members2 to inform their customers3 about the scheme4.
1.5.The scheme ensures that information about its existence, procedures and scope is available to customers through scheme members:
1.6.The scheme promotes its existence in such a way as to be sensitive to disadvantaged customers or customers with special needs.
Access
1.7.The scheme seeks to ensure nation-wide access to it by customers.6
1.8.The scheme provides appropriate facilities and assistance for disadvantaged complainants or those with special needs.
1.9.Complainants can make initial contact with the scheme orally or in writing but the complaint must ultimately be reduced to writing.7
1.10.The terms of reference of the scheme are expressed clearly.
Cost
1.11.Customers do not pay any application or other fee or charge before a complaint is dealt with by the scheme, or at any stage in the process.
Staff Assistance
1.12.The scheme’s staff have the ability to handle customer complaints and are provided with adequate training in complaints handling.
1.13.The scheme’s staff explain to complainants in simple terms:
1.14.The scheme's staff assist complainants to subsequently reduce a complaint to writing, where complainants need assistance to do so.
Use
1.15.The scheme’s processes are simple for complainants to understand and easy to use.
1.16.The scheme provides for a complainant's case to be presented orally or in writing at the determination stage, at the discretion of the decision-maker.
1.17.The scheme provides for complainants to be supported by another person at any stage in the scheme's processes.
Non-adversar