Requirements for digital service providers

The requirements for digital service providers (DSPs) to use our digital services are an outcome of the DSP Operational Framework (Framework). This is part of the ATOs 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, then that DSP is in scope of the Framework and will need to meet the requirements as below. This includes DSPs that use an intermediary (such as a gateway or sending service provider (SSP)) to interact with the ATO.

DSPs already using our services will transition to meet these requirements over time. The timeframes for existing DSPs to meet the requirements are outlined in the DSP Operational Framework implementation approach. We consulted on this document through the DSP Operational Framework working group.

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 utilises a risk differentiated model in determining the requirements needed for utilising our application programming interfaces (APIs). Factors include:

• the API risk rating
• volume of accessible individual taxpayer or superannuation records
• a number of elements of the DSPs operating model (eg: on premise or cloud based software, data hosting arrangements and if there is an intermediary within the supply chain to the ATO).

Requirements for products and services hosted 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 (eg: via gateway or SSP)
Personnel security	A personnel security integrity check process should be in place
Encryption in transit	Encryption in transit is mandatory using Australian Signals Directorate Australian Government Information Security Manual (ISM) approved cryptographic algorithms and protocols (for example, TLS 1.2)
Encryption at rest	Optional
Payload encryption	Not applicable	The payload encryption solution is currently in development. The solution will be based on Cryptographic Message Syntax (CMS)
Encryption key management	Encryption key management (including public key infrastructure (PKI)) complies with ISM guidelines
Audit logging	Appropriate audit logging functionality implemented
Product ID in message header	The product ID of the software that produces the payload information must be included in the message header. The product ID must be unique to each DSP product. DSPs with multiple products will need one product ID per product.
Certification	Self-assessment against either: iRAP, ISO/IEC 27001, OWASP ASVS3.0 SOC2
Supply chain visibility	Not applicable	The supply chain visibility solution is currently in development
Data hosting	Not applicable
Authentication	Multifactor authentication is optional
Security monitoring practices	DSPs that utilise web services (ie: hybrid) are required to have security monitoring in place. For example: network / infrastructure layer application layer transaction (data) layer.

Requirements for products and services hosted 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	A personnel security integrity check process should be in place
Encryption in transit	Encryption in transit is mandatory using Australian Government Information Security Manual (ISM) approved cryptographic algorithms and protocols (for example, TLS 1.2)
Encryption at rest	Encryption at rest is mandatory using Australian Government Information Security Manual (ISM) approved cryptographic algorithms and protocols 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. The solution will be based on CMS
Encryption key management	Encryption key management (including PKI) complies with ISM guidelines
Audit logging	Appropriate audit logging functionality implemented
Product ID in message header	The product ID of the software that produces the payload information must be included in the message header. The product ID must be unique to each DSP product. DSPs with multiple products will need one product ID per product.
Certification	Self-assessment against either: iRAP ISO/IEC 27001 OWASP ASVS3.0 SOC2	Self-assessment against either: iRAP ISO/IEC 27001	Independent assessment against either: iRAP ISO/IEC 27001
Supply chain visibility Applicable when the product or service does not connect directly to the ATO and the payload encryption is not used	The supply chain visibility solution is currently in development
Data hosting	Data hosting is onshore by default. Offshore hosting arrangements (including redundant systems) are managed by exception only
Authentication	Multifactor authentication is mandatory
Security monitoring practices	Not applicable	Security monitoring is in place.   For example: network / infrastructure layer application layer transaction (data) layer

 

Minimum evidence requirements

As part of the Security Questionnaire (DOCX, 2.09MB), DSPs need to provide suitable evidence of how their product or service meets the relevant requirements. Examples of suitable evidence include:

• Authentication:
  • published product description
  • user manual, user description, user instructions paired with screen shots of the user interface

• Encryption – relevant combinations of:
  • screen shots (of the configuration page)
  • configuration files
  • product data sheet/white papers (together with Product purchase/ownership documentation such as receipts, front page of a contract of product/support/service)
  • Federal Information Processing Standard Validation documents (US government computer security standard, eg: FIPS 140-2)
  • product common criteria evaluation documents
  • product evaluation assurance level (EAL) documents.

• Certification:
  • iRAP letter of compliance or iRAP assessor engagement details
  • ISO/IEC 27001 documentation and certificate of compliance/registration or statement of applicability with certificate of compliance
  • OWASP ASVS3.0 or SOC2 assessment.

• Data hosting:
  • name of ASD certified data hosting provider
  • data hosting provider details, including:
    • provider name
    • provider location (onshore / offshore)
    • redundancy location
  • if data is stored offshore further evidence is required. See Additional conditions for offshore data hosting below for more information.

• Personnel security:
  • internal policy document and process description.

• Encryption key management:
  • Key Management Plan (internal documentation).

• Security monitoring practices:
  • network/infrastructure layer examples. Relevant combinations of:
    • screen shots (product page, the management console page)
    • product purchase/ownership doco (eg: receipts, front page of a contract of product/support/service)
    • configuration files
    • photos of the product
    • photos of SOC/SIEM centre (using the products).

• Application layer example:
  • screen shots of the function page in the application, and
  • reports from the backend system.

• Transaction (data) layer example:
  • reports from the backend system
  • previous unusual cases.

Additional requirement information

Certification and assessment

The ATO has assessed the following security standards:

• iRAP
• ISO/IEC 27001
• OWASP ASVS3.0
• SOC2

DSPs are able to request to use an alternative security standard if they feel it would be more suitable for their circumstances. These requests will be assessed on a case-by-case basis.

Payload encryption

Payload encryption can be used to provide end-to-end protection for sensitive or classified information. Payload encryption is the preferred solution for transporting sensitive or classified information through a supply chain. DSPs must, at a minimum, implement either payload encryption or supply chain visibility requirements. 

Supply chain visibility

When information is sent from one party to another (eg: from a taxpayer to the ATO), the data can be sent through a number of different parties in a ‘supply chain’. Each party in the supply chain can perform one or more functional roles.

The below design principles and functional roles will inform the development of a future technology solution to deliver supply chain visibility.

Supply chain visibility involves annotating the identity and functional role to the message for every DSP that reads or modifies the data – where the payload is not encrypted end-to-end (ie: payload-level encryption).

Where payload encryption has been implemented supply chain visibility is not required.

Design Principles

• The technical solution will seek to balance the need for risk mitigation against need for operational effectiveness
• If a DSP reads or modifies any data, the message must be annotated with that DSPs identity and functional role(s) in the supply chain
• DSPs are not responsible for information after it has been securely delivered to an authenticated and authorised customer
• If a DSP routes a message, the message must be annotated with that DSPs identity and functional role for operational support reasons

Functional roles within a supply chain

The functional roles within a supply chain are defined as:

• data collector - party responsible for the acquisition of data through user interface interaction or APIs
• data validator – party responsible for the verification of data types, structures, formats and/or data values
• data integrator – party responsible for combining data from multiple sources for use
• data analysis & extraction – party responsible for performing analysis on data to extract a data sub-set or additional derived/calculated data
• data transformer - party responsible for change syntactic representation of data
• data provider - party responsible for the payload (which may be encrypted)
• data transmitter - party responsible for the message with the payload (eg: ebMS3/AS4 transmission).

Onshore/Offshore data hosting

Storing data in a foreign jurisdiction presents additional risks that must be considered.

Requirements

Consistent with guidelines for APRA-regulated entities the ATO expects DSPs to apply a cautious and measured approach when considering retaining data outside the jurisdiction it pertains to. By default, the ATO expects DSPs to store data onshore.

Where there is a compelling reason for storing data outside of Australia a DSP must consult with the ATO prior to entering into any offshore data hosting arrangement so that the ATO may satisfy itself that the impact has been adequately addressed.  As part of the consultation:

• DSPs must demonstrate they have considered the jurisdictional risks of storing data in a foreign jurisdiction
• the ATO can provide advice on jurisdictional constraints.

The ATO will consider requests to host data offshore on a case-by-case basis.

Additional conditions for offshore data hosting

Consistent with APRAs Cross Industry Prudential Practice Guide CPG 235, the ATO expects the following would normally be applied to the assessment and ongoing management of offshore data hosting:

• enterprise frameworks such as security, project management, system development, outsourcing/offshoring management and risk management
• a detailed risk assessment
• a detailed understanding of the extent and nature of the business processes and the sensitivity/criticality of the data impacted by the arrangement
• a business case justifying the additional risk exposures.

Consistent with APRAs Prudential Standard Guide SPG 231, the ATO expects that DSPs would address the following specific risks and any other identified risks:

• country risk — the risk that overseas economic, political and/or social events will have an impact upon the ability of an overseas service provider to continue to provide an outsourced service to the DSP
• compliance (legal) risk — the risk that offshoring arrangements will have an impact upon DSPs ability to comply with relevant Australian and foreign laws and regulations (including accounting practices)
• contractual risk — the risk that a DSPs ability to enforce the offshoring agreement may be limited or completely negated
• access risk — the risk that the ability of a DSP to obtain information and to retain records is partly or completely hindered. This risk also refers to the potential difficulties or inability of the ATO to gain access to information using ATO information gathering powers
• counterparty risk — the risk arising from the counterparty’s failure to meet the terms of any agreement with the DSP or to otherwise perform as agreed.

The ATO expects that an offshoring arrangement would typically include a provision around security and confidentiality of information.

Where you are storing data outside of Australia you must:

• make it clear to your customers that their data is being stored in a foreign jurisdiction
• apply the Australian Privacy Principles
• provide guidelines to your customers, where your customers use your services to collect and store data about other individuals (eg: clients of tax practitioners, employees, etc) on where and how their data is being managed.

Identity and authentication

Requirements

Subject to the design and delivery of the Trusted Digital Identity Framework (TDIF) DSPs will be required to either:

1. use the current cloud authentication and authorisation (CAA) solution with the addition of a multifactor credential
2. consume the government provided TDIF credential, or
3. become a TDIF credential provider in their own right and consume their own credential.

In the interim, whilst the TDIF standards and solutions are being developed for use in software products, DSPs must:

4. review their security credential risks and develop a plan to manage identified risks
5. implement and mandate a multifactor credential solution for all users with access to taxation or superannuation related information or provide assurances that sufficient controls are in place to mitigate the risks.

Note

Many digital products and services perform tasks outside of the tax and superannuation space. User accounts that do not have access to taxpayer or superannuation related information are not required to meet the above requirements.

Changing circumstances and annual re-assessment

The ATO must be notified via your Account manager of any changes to your business or product environment, in relation to the information you supplied in your questionnaire response. Re-assessments will be conducted annually.

In line with standard industry practice, certification (both independent and self–assessed) must be current. The ATO also reserves the right to undertake ad hoc reviews to ensure DSPs maintain alignment to the requirements of the framework.

Monitoring and information incidents

Monitoring is considered a joint responsibility between the ATO and DSPs. The ATO conducts monitoring at the network, application and transaction layers. If anomalies or areas of concern are identified, we may re-assess your whitelisting suitability. This may include increasing the requirements that you need to meet or introducing additional requirements. The ATO will generally contact you or your representative unless exceptional circumstances apply.

Where you identify a breach through your own monitoring controls you must notify the ATO immediately via your Account manager to ensure appropriate action can be taken.

What happens if I don’t meet requirements

The ATO expects all DSPs will meet and maintain the relevant requirements of the Framework.

The ATO will endeavour to work through non-conformance issues with DSPs, however failure to address these issues will result in restriction 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.

The ATO is committed to the protection of tax and superannuation information and will treat issues of non-conformance seriously.