The DSP Operational Framework (Framework) is part of the ATO’s response to the business risks and security implications presented by the growth of our digital services across the digital economy.
If a DSP provides a software product or service that reads, modifies or routes any tax or superannuation related information and that product performs a role in the supply chain then that product or services is within scope of the Framework. This includes DSPs that use an intermediary (such as a gateway or sending service provider) to interact with the ATO.
More specifically, the DSP Operational Framework applies to software products and services that provide any of the below functionality:
- Business and tax accounting services, for example, activity statements and income tax returns.
- Payroll and employer services, for example, Single Touch Payroll reporting .
- Superannuation services, for example, Fund member rollover and reporting.
Note: Super services may have additional requirements above and beyond the Framework.
Due to a continually changing digital environment the requirements for DSPs will be subject to future changes based on risk.
What are the requirements?
The Framework uses a risk differentiated model in determining the requirements needed for utilising our application programming interfaces (APIs). Factors include:
- the API risk ratings
- volume of accessible individual taxpayer or superannuation records
- a number of elements of the DSPs operating model (for example, on premise or cloud based software, data hosting arrangements and if there is an intermediary within the supply chain to the ATO).
Further clarification and guidance for the requirements can be found in the DSP Operational Framework - Requirements to utilise ATO digital services (DOCX, 807KB).
There is a transition plan available for existing superannuation providers. Further information can be found at Transitioning existing superannuation providers.
Requirements for products and services controlled by the client
This includes desktop software or software hosted by the client on premise, or within either an infrastructure as a service (IaaS) or platform as a service (PaaS) environment.
|
Requirements |
Connects directly to the ATO |
Connects indirectly to the ATO (for example, via gateway or SSP) |
|---|---|---|
|
Personnel security |
(Mandatory) You need to demonstrate that appropriate processes and procedures are in place for hiring, managing and terminating employees and contractors. |
|
|
Encryption in transit |
(Mandatory) Encryption in transit is enforced using an approved cryptographic protocol (for example, TLS 1.3) and algorithm as per the Australian Government - Guidelines for using cryptography (PDF, 1.0MB) (May 2019). |
|
|
Encryption at rest |
Optional |
|
|
Payload encryption |
Not applicable |
Payload encryption solution is not currently available, but will be developed in the near future. |
|
Encryption key management
|
(Mandatory) Encryption key management (including public key infrastructure (PKI)) complies with Australian Government ISM. The scope of the policy where suitable should cover three categories:
|
|
|
Audit logging |
(Mandatory) Appropriate audit logging functionality is implemented by your software product to enable traceability of user access and actions. |
|
|
Product ID in message header |
(Mandatory) DSPs with multiple products will need one product ID per product. The Product ID of the software that produces the payload information must be included in the message. This requirement does not apply to SuperStream messages or sending service providers. |
|
|
Certification |
(Mandatory) Self-assessment against either:
|
|
|
Supply chain visibility |
Not applicable
|
(Mandatory) The supply chain visibility solution is being developed in the near future. Until then interim measures are in place. |
|
Data hosting |
Not applicable |
|
|
Multi-factor Authentication |
(Optional) The ATO recommends that multi-factor authentication (MFA) is applied, or the option is made available where practical to do so. DSPs that have not implemented MFA, should consider implementing passphrase management, account lockout and resetting passphrase practices described in the Australian Government - Guidelines for system hardening (PDF, 1.0MB). |
|
|
Security monitoring practices
|
(Mandatory) DSPs that utilise web services (ie: hybrid desktop environments) and are consuming medium and high risk APIs are required to have security monitoring in place. For example:
|
|
| DSP with an add-on marketplace |
(Mandatory) DSPs that allow 3rd party add-ons to connect to their software via an API should have security controls in place to govern access. If you are a DSP with an add-on marketplace you will need to provide us with additional information. |
|
Requirements for products and services controlled by the DSP
This includes software as a services (SaaS), gateways and sending service providers.
|
Requirements |
Low volumes of taxpayer or superannuation records (<10k) |
Highly leveraged or high volumes of taxpayer or superannuation records (>10k) |
|
|---|---|---|---|
|
|
Consumes no/low risk APIs only |
Consumes medium or high risk APIs |
|
|
Personnel security |
(Mandatory) You need to demonstrate that appropriate processes and procedures are in place for hiring, managing and terminating employees and contractors. |
||
|
Encryption in transit |
(Mandatory) Encryption in transit is enforced using an approved cryptographic protocol (for example, TLS 1.3) and algorithm as per the Australian Government - Guidelines for using cryptography (PDF, 1.0MB) (May 2019). |
||
|
Encryption at rest |
(Mandatory) Encryption at rest is mandatory for data repositories that hold or manage tax or superannuation related information. Encryption of data at rest is enforced using an approved algorithm (for example, AES-256) as per Australian Government - Guidelines for using cryptography (PDF, 1.0MB) (May 2019). Examples may include; full-disk, container, application or database level encryption techniques. |
||
|
Payload encryption Applicable when the product or service does not connect directly to the ATO and the supply chain visibility functionality is not available |
Payload encryption solution is not currently available, but will be developed in the near future. |
||
|
Encryption key management |
(Mandatory) Encryption key management (including public key infrastructure (PKI)) complies with Australian Government ISM. The scope of the policy where suitable should cover three categories:
|
||
|
Audit logging |
(Mandatory) Appropriate audit logging functionality is implemented by your software product to enable traceability of user access and actions. | ||
|
Product ID in message header |
(Mandatory) DSPs with multiple products will need one product ID per product. The Product ID of the software that produces the payload information must be included in the message. This requirement does not apply to SuperStream messages or sending service providers. |
||
|
Certification |
(Mandatory) Self-assessment against either:
|
(Mandatory) Self-assessment against either:
|
(Mandatory) Independent certification against either:
|
|
Supply chain visibility Applicable when the product or service does not connect directly to the ATO and the payload encryption is not used |
(Mandatory) The supply chain visibility solution is being developed in the near future. Until then, interim measures are in place.
|
||
|
Data hosting |
(Mandatory) Data hosting is onshore by default. Offshore hosting arrangements (including redundant systems) are managed by exception only.
|
||
|
Multi-factor Authentication |
End users accessing the product or service (Mandatory) Multi-factor authentication (MFA) is mandatory for end users that can access taxation or superannuation related information of other entities or individuals (for example, tax agents, employers) DSP staff accessing the product or service (including contracted labour) (Mandatory) MFA is mandatory for DSP staff with access to taxation or superannuation related information. This position applies unless the DSP can adequately demonstrate that the internal user does not perform a privileged administration role (system/database level) and the full range of compensating controls specified within the Australian Government Information Security Manual (ISM) have been suitably implemented. (Optional but recommended) MFA is optional but recommended for DSP staff (other than privileged users) without access to taxation or superannuation related information of other entities. Note: Tokens or temporary credential should be isolated to an individual device and expire once used. Any token or temporary credential should expire within 24 hours. DSPs that have not implemented MFA, should consider implementing passphrase management, account lockout and resetting passphrase practices described in the Australian Government - Guidelines for system hardening (PDF, 1.0MB). |
||
|
Security monitoring practices
|
Not applicable |
(Mandatory) Security monitoring is in place.
For example:
|
|
| Sending Service Provider |
(Mandatory for Sending Service Providers only) Sending Service Providers need to provide the following information:
|
||
| DSP with an add-on marketplace |
(Mandatory) DSPs that allow 3rd party add-ons to connect to their software via an API should have security controls in place to govern access. If you are a DSP with an add-on marketplace you will need to provide us with additional information. Note: Sending service providers/gateways are excluded from this definition. |
||
What happens if a DSP doesn't meet the Framework requirements?
We expect all DSPs to meet and maintain the relevant requirements of the Framework. We are committed to the protection of tax and superannuation information and will treat issues of non-conformance seriously.
We will work with DSPs to encourage conformance, however failure by DSPs to address issues will result in restrictions of access to services or de-whitelisting. The SBR Conditions of Use enables the ATO to lawfully suspend or terminate any software product, report or information from access to the SBR channel. For more information regarding de-whitelisting please see the DSP de-whitelisting process (PDF, 303kB).