2  Principle: Restricted Access Species Data (RASD) Should be Consistently Classified

Restricted Access Species Data are biodiversity related datasets about species that are restricted for one or more of the following reasons. The examples that are provided are not necessarily the only type of data within a category, nor the only types of possible actions that may be taken:

2.1 1. Personal Identifiable Information –

A dataset containing names or personal details about an individual, the release of which would be contrary to privacy legislation. For example, data held by a citizen science project contains personal information (names and addresses) of observers involved in the project. This constitutes personal information within the definition of most legislation and regulatory frameworks in Australia (see Personal Identifiable Information – legislative and regulatory instruments that affect RASD (Supplement 3)). While this applies to species data more generally, the use here refers to personal identifiable information associated with RASD only.

2.2 2. Indigenous Data –

For the current coverage of the framework the application of the CARE principles for Indigenous data governance (Collective Benefit, Authority to Control, Responsibility and Ethics) relates to a species point dataset that has been gathered by, or contains knowledge of, Indigenous peoples. The CARE principles are intended to recognise Indigenous data sovereignty. For example: data gathered by the Australian Government Indigenous Ranger Program. This data requires permission to be sought from Indigenous peoples before use (see Supplement 1 for more information and guidance).

2.3 3. Usage-Restricted Categories –

Represent species data where the dataset is constrained by third-party concerns. These are:

2.5 The Risks of Using RASD

The Risk Matrix (Table 1) is a tool to assist data custodians to understand the risks posed by RASD and what actions might be undertaken to mitigate these risks, both for existing data and for data produced in the future.

Two Australian Government risk classes are recognised within these RASD types: c) Official (Sensitive) – low to moderate impact, or
d) Official (Not Sensitive) – low impact

RASD risk classes generally fall within the equivalent of “Official - Government” risk classification. This means while action needs to be taken to manage RASD as per this framework, action only need be in line with normal institutional processes and thus does not require encryption or other high end security protocols.

The risk matrix for RASD shown in Table 1 shows: a) the types of RASD listed in this framework
b) a summary of the reason why it is sensitive
c) how it should be handled if data are managed according to the framework
d) what the sensitivity of the data are if the data are handled according to the framework.

The framework suggests handling of both existing (legacy) datasets and new datasets.

2.6 Table 1 - Risk Matrix for RASD

Note: This table only contains recommended handling and treatment for RASD based on recommended classifications under the Auditor General’s guidelines on classifying data. Commonwealth, State and Territory governments may have their own classification systems. None of the RASD types listed here are security classified within the meanings of classifications used by Commonwealth, State and Territory governments. Most RASD require routine levels of protection (the equivalent of the Auditor General’s class: OFFICIAL requiring dissemination limiting handling and marking (DLM)’).

For the purposes of this table, entity refers to the data custodian and considers risks to their organisation.

Table 1 is best viewed in the RASD Framework PDF document. It is available from pages 23-26.

For optimised viewing online, it is presented in 4 parts below by RASD type:

2.6.1 RASD Type: Personal

Categories Reason Handling of existing or new data Classification (after handling)
1. Personal Identifiable Information Privacy legislation requires the removal of information related to individuals from datasets and the control of de-contextualised datasets where an individual may be reasonably identified from the data. Handling of both data types:
Data should have fields including names and addresses excluded from the dataset before sharing.

Dataset should be annotated to record the dataset has been modified.

If both conditions met data can be shared publicly.
Official: (not sensitive – low impact)
Information from routine business operations and services. Potential impact on individuals from compromise of the information. Personal information as defined in the Privacy Act (includes names and address). The information needs management but is not sensitive.

2.6.2 RASD Type: Indigenous

2. Indigenous Data CARE principles require consultation with Indigenous parties about use of data before release. Existing Data
Data meeting the definition of Indigenous should be flagged as such in an attribute field.
Data custodians should consult with Indigenous parties before releasing data. If consultation allows for specified use by third parties it can be shared as a restricted dataset but should be annotated “not for external use” and shared under negotiated legal agreement.
If consultation does not allow use by third parties then the data should be withheld, or agreement sought from the data custodian for its release.

New data
New data should be gathered in consultation with Indigenous communities and community wishes should be captured in an attribute field that defines how data are to be handled. Negotiated legal agreements to contain clauses consistent with the Framework enabling sharing within government and, under negotiated legal agreement, with Approved Data Requestors, but community consultation may well remain a requirement.
Official: (not sensitive – low impact)
Information from routine business operations and services. Potential impact on communities from compromise of the information. The information needs management but is not sensitive.

2.6.3 RASD Type: Usage

Categories Reason Handling of existing or new data Classification (after handling)
3.1 Legal Contract Conditions in a standard form data licence agreement or negotiated legal agreement contractually limit data-sharing. Existing Data (where data licence agreements exist)
If standard form data licence agreement allows for specified use by third parties it can be shared as a restricted dataset but should be annotated “not for external use” and shared under negotiated legal agreement.

If standard form data licence agreement does not allow use by third parties then the data should be withheld, or agreement sought from the data custodian for its release.

New data
Future negotiated legal agreements to contain clauses consistent with the Framework enabling sharing within government and, under negotiated legal agreement, with Approved Data Requestors.

Dataset should be annotated to record the dataset is restricted.
Official: Sensitive – low to medium impact
Limited damage meets the definition of contract or agreement non-compliance
3.2 Legal Financial Written conditions on the dataset are part of current financial negotiations and transfer could compromise a financial process such as a tender. Existing Data (with data licence agreements in place)
If standard form data licence agreement allows for specified use by third parties it can be shared as a restricted dataset but should be annotated “not for external use” and shared under negotiated legal agreement.

If the release of the data are subject to an embargo period and the data license permits use after this period only, data can be shared as a restricted datasets after the embargo period has ended but should be annotated “not for external use” and shared under negotiated legal agreement.

If standard form data licence agreement does not allow use by third parties then the data should be withheld, or agreement sought from the data custodian for its release.

New data
Future Negotiated legal agreements to contain clauses consistent with the Framework enabling sharing within government and, under negotiated legal agreement, with Approved Data Requestors.

Dataset should be annotated to record the dataset is restricted.
Official: Sensitive – low to medium impact
Limited damage meets the definition of contract or agreement non-compliance
3.3 Non-Legal The dataset was acquired via informal agreement that the information would not be transferred (informal meaning no written Legal Contract) Existing Data
Data may be subject to restricted sharing under negotiated legal agreement or standard form data licence (where these already exist) with the data custodian or otherwise annotated as restricted.

New data
Future negotiated legal agreements to contain clauses consistent with the Framework enabling sharing within government and, under negotiated legal agreement, with Approved Data Requestors. Dataset should be annotated to record the dataset is restricted.
Official: (not sensitive – low impact)
Information compromise would not result in legal and compliance issues. The information needs management but is not sensitive.

2.7 Figure 2 - RASD Data Handling Process (see also Table: Restricted Access Treatments and Metadata)

flowchart showing the workflow of data request through to release or being withheld