Responding to data requests

This guide outlines the key steps and considerations to take when responding to data requests.

Please note:

Data requests for sensitive data are assessed against relevant legislation, policies and agreements with other partner agencies, to determine if the data can be lawfully disclosed.
Engagement with legal, information and privacy experts may be needed to help decide on the data request.
There are no specific timeframes for considering a request. Data providers should acknowledge data requests and engage with the requestor to manage expectations.

1. Review the request

We have compiled a list of questions you need to consider when reviewing data requests.

Questions to consider	Recommended actions to take
Data request information
Is the data request from: NSW government sector agency Outside of NSW Government	If request is from a NSW government sector agency, note that the requested data is shared under the Data Sharing Act. If the request is from outside NSW government, assess the request against relevant compliance requirements of any relevant legislation such as: Privacy and Personal Information Act 1998 (PPIP Act) Health Records and Information Privacy Act 2002 (HRIP Act) Government Information (Public Access) Act 2009 (GIPA Act) State Records Act 1998. Apply the Five Safes Framework to guide your assessment.
Do we have the requested data? Yes No	If yes, check availability of the requested data. If not, inform the requestor that your agency does not have the requested data.
Is the requested data: Publicly available Can be made publicly available Restricted	If the data is publicly available, confirm that the requestor may use the data for their purpose. If the data can be made publicly available, inform the requestor of where to access the data. If the data is restricted, identify and document your agency’s requirements to fulfill the data request.
Does that data contain: confidential or commercial-sensitive information personal information health information	If yes to confidential or commercial-sensitive information, check and comply with the terms of the agreement or contract. If yes to personal and/or or health information: check with the requestor if a privacy impact assessment (PIA) has been undertaken. seek advice from your legal or information or privacy team or experts to: confirm compliance requirements to enable data sharing determine if a risk assessment or a privacy impact assessment should be undertaken. negotiate with the requestor to provide de-identified data to lessen privacy risks.
Is the data ready to be shared? Yes No	If yes, follow your agency's approval process. If not, inform the requestor regarding: gaps or issues with your agency's data your agency's capability and capacity to carry out activities that may be required such as: data cleansing or modelling de-identification data extraction any costs associated with preparing the data for sharing your agency's capacity to undertake the sharing within the timeframe and on an ongoing basis, if the data provision is recurring.
Authority to decide on the data request
Does your agency own the data? Yes No Unsure	If yes, identify and check with the data owner if they know of any restrictions or barriers in sharing the requested data. If not, check if your agency is permitted to share data under: a commercial agreement personal individual consent consent from the copyright owner of the requested data. If unsure, check your agency's information asset register or data catalogue to locate the data owner within your agency. Talk to your agency's information and subject matter experts to find and verify ownership of the requested data.
Is the purpose of the data request clear? Yes No	If yes, determine which legislation permits data sharing. If not, contact the requesting agency (Requestor) for additional information.
Can you share the requested data under: Data Sharing Act 2015 Government Information (Public Access) Act 2009 (GIPA Act) Privacy and Personal Information Act 1998 (PPIP Act) Health Records and Information Privacy Act 2002 (HRIP Act) Any applicable Public Interest Direction or Privacy Code of Practice State Records Act 1998	a. Data Sharing Act: Assess the purpose of the request against one of the permitted data sharing purposes: government policy making program management service planning and delivery. Identify if the requested data will contain: (see Question 4) confidential or commercial sensitive information – check and comply with the terms of the agreement or contract. private or health information – seek advice from your legal or information or privacy team or experts to confirm compliance requirements to enable data sharing. Check and document compliance requirements against the data sharing safeguards. Note that the Data Sharing Act only enables data sharing between NSW government sector agencies. b. GIPA Act Engage and seek advice from your legal, information or privacy team to help you: determine if you can share data via any of the four access pathways: Mandatory proactive release Authorised release Informal release Formal application. Comply with the GIPA Act requirements and your agency’s policy, procedures and processes. Communicate to the requestor if you can share data via any of the four access pathways. Provide them with additional information on the benefits and drawbacks of each pathway. Note that decisions made in relation to share data via GIPA Act should be authorised and documented. c. PPIP Act and HRIP Act Contact your legal, information and privacy team to: confirm compliance requirements to enable data sharing determine if a risk assessment or a privacy impact assessment should be undertaken. Negotiate with the requestor to provide de-identified data and inform them how de-identification may impact timeframes or may incur costs Read Data Sharing and Privacy: a guide for public sector agencies for more information. d. Public Interest Direction or Privacy Codes of Practice Inform the requestor and determine the next steps if the requested data falls under any of the following: Public Interest Directions made under the PPIP Act Health Public Interest Directions Privacy Codes of Practice. e. State Records Act Determine if data is at least 20 years old and is in the open access period. If so, data is open to public access and can be shared to the requestor. Inform requestor that data is open to public access and will be shared under this Act. If not, document and inform the requestor that data is not in the open access period or that data is subject to closed public access direction.
Does your agency have a data sharing approval process in place? Yes No	If yes, follow your agency's approval process. Communicate to the requestor information about the approval process and the status of the request. If not, check your agency's information asset register or data catalogue to identify the data owner, data custodian or the business system owner. If not and you are the data custodian or data owner or business system owner: determine if you can adopt your agency’s process on releasing information. If yes, follow the approval process. determine if you have the authority to approve data requests. Your agency’s relevant records, information and data policies provide information about roles and responsibilities. seek advice from your legal, governance, information and privacy experts on what process should be followed. Document your actions and decisions.
Readiness to share data
Does the requestor have the appropriate technology, infrastructure, policies and processes to receive and securely manage the data? Yes No	If yes, take note of details and confirm with the requestor. If not, liaise with the requestor to address any gaps.
Are all participants - from your agency and the requestor's agency - aware of their roles and responsibilities? Yes No	If yes, get confirmation and make a record of it. If not, document and confirm roles and responsibilities with the requestor and within your agency.
Can you supply the required metadata or a data quality statement? Yes No	If yes, provide the required metadata or data quality statement to the requestor. If not, document the metadata or write a data quality statement. You can use the Data Quality Reporting Tool to produce a data quality statement.
Does your agency have the capacity to undertake the sharing within the timeframe and on an ongoing basis, if the data provision is recurring? Yes No	If yes, confirm with the requestor. Communicate if there are any costs associated with sharing the data. If not, inform the requestor and identify the barriers and possible solutions.

Document any potential barriers and risks or issues that could arise from sharing data. Engage with the requestor to find solutions to mitigate risks.

Use the Five Safes Framework to guide you with your assessment of the data request.

2. Decide on the request

Decisions around whether data should be shared should involve an evaluation of the risks involved with sharing the data. Use the Five Safes Framework to guide you with your decision.

Once a decision is made to approve or refuse the data request, your agency should provide a written statement of reasons for the decision.

Approve the request

Below is a list of considerations or actions to take when you decide to approve the data request.

Identify the type of legal agreement you will need to share data. There are multiple types of agreements such as:

	Description	Suited for
Data Sharing Agreement (DSA)	DSAs identify the parameters which govern the collection, transmission, storage, security, analysis, re-use, archiving and destruction of the data.	establishing long-term data sharing relationships that may involve: ongoing transfers of data multiple transfers with different parameters including process for authorising further data requests
Memorandum of Understanding (MoU)	An MoU is a written agreement outlining the framework or key terms and conditions. It is not legally binding.	ongoing transfers that have consistent and formalised parameters.
Statement of Work (SoW)	The SoW is a document that provides detailed overview of the project, specifically the roles and responsibilities of the people working on the project. Information about the use, access and storage are included.	once-off data sharing with the requestor.

Communicate to the requestor that their data request is approved. Let them know if an in-principle approval is sufficient or if an agreement is needed.
Negotiate with the requestor for the terms and conditions. When negotiating:
1. Confirm project scope, objectives and outcomes.
2. Confirm data format, data variables, frequency and timeframe, and the platform or mechanism for data transfer or access
3. Agree an estimated timeframe for completion of the Data Sharing Agreement, building in time for internal reviews by legal officers, key stakeholders and decision-makers.
4. Confirm whether any additional consultation is needed within or external to the agency before a Data Sharing Agreement can be finalised.
5. Apply the Data Sharing Principles to ensure you have the appropriate controls in place to safely share data.

Refuse the request

Make a record that documents the reasons why your agency is refusing to fulfill the data request.
Inform the requestor of your agency's decision in writing.

Note: The reasoning for a final decision not to share data needs to be established in writing. Note that if the requestor disputes your reasons for not approving a request the requestor is able to make a formal access application under the GIPA Act.

3. Draft the agreement

Your agency can set terms and conditions for the release of data to the requestor to ensure that controls are in place on:

use of the data
the environment the data will be stored
the publication of outputs from the data.

When sharing data, it is important that the parties involved enter into an arrangement via an agreement.

Below are components you need to consider when entering into an agreement.

Examples of information and/or clauses

Parties to the agreement

Drafting notes:

Specify agencies and names of authorised persons who are entering into the agreement, i.e. the data provider(s) and the data recipient.

Name of Organisation
Role of organisation
- ☐ Data Provider
- ☐ Data Recipient / Requestor
- ☐ Intermediary
Australian Business Number
Address
Name of Authorised Representative
- Position
- Contact information

Purpose

Drafting notes:

Include information on:

anticipated outcomes of the project/program/initiative and how will the data requested help achieve these outcomes
individuals, groups, demographics or organisations that will be positively affected by this project
any specific legislative basis for permitting access to the data.

Purpose

Data is provided for the purposes of [state the purpose of the data sharing].

Acknowledgement:
□ The parties confirm that the sharing purpose complies with [name of legislation] under which this agreement is made and the data shared is reasonably necessary to achieve the purpose(s) as specified.

Term and variation of agreement

Drafting notes:

Specify:

when the agreement begins and ends
If applicable, review dates or intervals for review date
Frequency of supply of data: one-off, ongoing, defined timeframes
Circumstances that must be met and the processes that must be followed for the parties to vary this Agreement.

Term and variation of agreement

The agreement starts on [start date] and ends on [end date].

This agreement will be reviewed [expected interval date, e.g. every 6 months, annually, every 3 years, etc.].

The data will be provided on ongoing basis until [agreement end date]

Both parties must agree in writing to vary this agreement.

Details of data to be shared

Drafting notes:

Provide a brief description of the data to be shared. Include as much information as possible about the data.

Include data specifications or data quality statements or data dictionaries as part of the agreement.

Details of data to be shared

The Data Provider will supply [name of the dataset], with the following parameters:

Target population: [Program X] customers
Data types: number of customers, by suburb, by type of service
Level of granularity: unit record, aggregated
Timeframe of data: data from 2020-2025, by month and year
Location: postcode / suburb or statistical area level 4 (SA4)

Approvals required

Drafting notes:

Specify the approval processes required. Note that approvals process(es) required will be determined by the nature of the project. Not all options listed in the examples may be relevant.
Attach additional evidence as required.
Specify who is responsible for conducting or facilitating the approvals.

Approvals required

Data will be provided subject to: (select all options that apply):
☐ no approvals required
☐ ethics approvals
☐ financial approval (e.g. Digital Restart Approval)
☐ others, please specify (e.g. AI Review Committee)

Conditions of sharing

Use of data

Drafting notes:

Include clauses relating to:

the purpose for which the data may be used by the requester
specific restrictions on who may use, access or release any shared data

Use of data

The Data Recipient agrees it will:

use the Shared Data for the Approved Purpose(s) only
where necessary, nominate certain authorised users to have access to the Shared Data (Authorised Users) and ensure that only authorised users have access to the Shared Data
seek the authorisation and approval of the Data Provider before making public, or disclosing to any third party, the Shared Data or any document incorporating the Shared Data.

The Data Recipient will not:

permit access, or release any Shared Data, to a third party (except as set out in the Agreement or with the express consent of the Data Provider);
produce any information based on, or incorporating, the Shared Data that generates personal Information or health information (that is, it re-identifies a person), unless permitted by law.

Access to Data

Drafting notes:

Specify

method of data access
data access date
approval process on requests to change access to the data.

Access to Data

The Data Provider agrees to make the Shared Data available via [method of data access, e.g. API, secure File Transfer Protocol or online file sharing service] for the agreed term.

The parties may agree to make changes to the data scope as follows:

Recipient may send request via email and the Data Provider to acknowledge request.
Data Provider will confirm if requested changes are approved and from when changes will be applied.
Data Provider will provide reasons for not approving requested changes and the Recipient may appeal the decision.

Licence, copyright and intellectual property

Drafting notes:

Include details of:

any licence or copyright conditions
potential or restriction of commercial use of the data
attribution

Licence, copyright and intellectual property

The Data Provider grants to the Data Recipient a non-exclusive, non-transferable, royalty free licence to use, reproduce and adapt the Shared Data for the Approved Purposes (on the terms, and subject to the restrictions, set out in this Data Sharing Agreement).

Storage and security

Drafting notes

Specify your storage and security requirements. Include information on:

where will the data be stored once it has been shared or transferred
how will the data be stored
how will the data be delivered into the storage system
how long will the data be retained
security measures in place such as agency control of user credentials for authentication, data encryption, information dispersal, data separation, governance policies etc.
specific qualifications/certifications/accreditations required for people accessing the data.

Storage and security

The Data Recipient will store the Shared Data [name of the approved storage and provide further details relating to security measures in place]

Data provided by [Data Provider] to [Data Recipient] will be removed or destroyed by the [Data Provider] in compliance with the provisions of the State Records Act 1998 [or other relevant legislation.]

The [Data Recipient] will notify [Data Provider] when data is removed or destroyed.

Data provided under this Agreement will be retained or destroyed based on the information provided in the below table.

Dataset name	Retention period in years	Action	Trigger	Rationale
Customer survey data	5 years	Destroy	Project completed	The General Authority 28: Administrative Records 2.9.1 provides approvals for destruction.
Dataset 2	N/A	Destroy	Project completion report provided	Dataset is duplicate copy

Data Breach

Drafting notes:

Specify the data breach notification process.

Data Breach

The [Data Recipient] will immediately notify [Data Provider] if it becomes aware of any unauthorised access to, or use or disclosure of, any data, including the steps the [Data Recipient] is taking to remedy the data breach.

Termination

Drafting notes:

Include information on circumstances where the data sharing agreement may be terminated.

Termination

Either Party may terminate by giving [X] days written notice to the other Party for any reason or for a specified reason, or to terminate without notice if there has been a serious privacy or data breach.

4. Prepare data for sharing

Before you share data, check that the data does not contain:

Information which may identify an individual or community
commercial-sensitive or confidential information
any data that could trigger, create or contribute to a threat, issue, breach or vulnerability.

Let the requestor or data recipient know if you are intending to do the following as part of your data preparation:

Remove or modify personal identifiers such as a person’s name, address and date of birth as an essential component of de-identification.
Combine information or data that is likely to enable identification of an individual into categories. For example, age could be combined and expressed in ranges, like ‘age range: 25-39’, rather than in a single year like ‘age: 27’.
Manufacture ‘synthetic data’, which can be generated from original data and then substituted for it, while preserving some of the patterns contained in the original data. This removes any personal or sensitive information, while allowing general conclusions or insights to be released.
Introduce small amounts of random error, e.g. rounding or swapping data between records. This could include swapping modified identifying information for one person with the information for another person with similar characteristics to prevent the release of unique personal information.
Suppress data to ensure identifying or sensitive data is not released. For example, you may want to redact commercially sensitive figures or company names. Data suppression may impair the utility of a dataset so design data suppression methods with care.
Alter identifiable information in a small way such that the aggregate information or data is not significantly affected but the original values cannot be known with certainty.
Remove / encrypt / modify quasi-identifiers that are unique to an individual or that in combination with other of unique or remarkable characteristics (profession, significant dates etc), are reasonably likely to identify an individual.
Remove names and attach a coded reference or pseudonym to each record. This will allow data to be released without the individual being identified. The same coded reference should always be replaced by the same matching pseudonym to allow data insights to be maintained. With pseudonymisation, it is important to ensure that other publicly accessible data, such as electoral roll data, cannot be used to reintroduce the names that have been removed from the dataset.
Aggregate or display data as totals rather than individual values, so no data relating to or identifying any individual is shown. Small numbers in totals are often suppressed through ‘blurring’ or by being omitted altogether.
You can reduce the risk to privacy when publishing spatial information by:

increasing a mapping area to cover more properties or occupants
reducing the frequency or timeliness of publication, so that it covers more events, is harder to identify a recent case, or does not reveal additional data such as time or date of an event
removing the final ‘octet’ on IP addresses to degrade the location data they contain
using formats, such as heat maps, that provide an overview without allowing the inference of detailed information about a place or person
not publish spatial information at a household level.

Back to Data sharing