Digital Service Provider Operational Framework

Requirements to utilise ATO digital services

UNCLASSIFIED

Contents

OVERVIEW............................................................................................................................................ 3

KEY UPDATES....................................................................................................................................... 3INTENT................................................................................................................................................. 4SCOPE................................................................................................................................................. 4APPLICATION OF THE SCOPE IN DIFFERENT CIRCUMSTANCES...................................................................4

REQUIREMENTS................................................................................................................................... 6

UNDERSTANDING HOW THE REQUIREMENTS APPLY TO YOU.....................................................................6REQUIREMENTS FOR PRODUCTS AND SERVICES CONTROLLED BY THE CLIENT..........................................6REQUIREMENTS FOR PRODUCTS AND / OR SERVICES CONTROLLED BY THE DSP......................................9

FURTHER GUIDANCE ON THE REQUIREMENTS............................................................................11

PERSONNEL SECURITY........................................................................................................................ 11ENCRYPTION IN TRANSIT.....................................................................................................................12ENCRYPTION AT REST......................................................................................................................... 12PAYLOAD ENCRYPTION........................................................................................................................13ENCRYPTION KEY MANAGEMENT..........................................................................................................13AUDIT LOGGING.................................................................................................................................. 14PRODUCT ID IN MESSAGE HEADER......................................................................................................14SELF-CERTIFICATION.......................................................................................................................... 14INDEPENDENT CERTIFICATION.............................................................................................................16SUPPLY CHAIN VISIBILITY.....................................................................................................................17DATA HOSTING................................................................................................................................... 18MULTI-FACTOR AUTHENTICATION........................................................................................................20SECURITY MONITORING PRACTICES......................................................................................................21SENDING SERVICE PROVIDERS (SSPS)...............................................................................................22DSPS WITH ADD-ON MARKETPLACES...................................................................................................22

MEETING THE FRAMEWORK REQUIREMENTS AND ONGOING EXPECTATIONS......................23

OPERATIONAL FRAMEWORK APPROVAL PROCESS.................................................................................23ANNUAL REVIEWS............................................................................................................................... 23INDEPENDENT CERTIFICATION / SELF-CERTIFICATION MAINTENANCE.....................................................23CHANGING CIRCUMSTANCES................................................................................................................24MONITORING AND DATA BREACHES......................................................................................................24AWARENESS OF OTHER OBLIGATIONS..................................................................................................25WHAT HAPPENS IF A DSP DOESN’T MEET THE FRAMEWORK REQUIREMENTS?.......................................25EVOLUTION OF THE FRAMEWORK.........................................................................................................25QUESTIONS........................................................................................................................................ 25

APPENDIX: GLOSSARY.....................................................................................................................26

MAJOR VERSION HISTORY...............................................................................................................29

UNCLASSIFIED EXTERNAL 2

Key updates Clarification regarding the approval process and requirements for using single

sign on for enterprise customers Link included to de-whitelisting process document

UNCLASSIFIED EXTERNAL 3

Overview

IntentThe Digital Service Provider (DSP) Operational Framework (the Framework) has been established to respond to the business risks and security implications presented by the growth of our digital services across the digital economy.

The Framework seeks to protect tax or superannuation related information as well as the integrity of the taxation and superannuation systems which support the Australian community. This is achieved by setting out the minimum level of requirements a DSP needs to meet in order to consume ATO services.

The Framework is a response to known examples of:

Information misuse – including identity theft, personal gain or commercial advantage Financial system misuse – including tax refund fraud Destructive cyber behaviour – including individual or system hacks

ScopeWhere 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 e.g. activity statements and income tax returns Payroll and employer services e.g. Single Touch Payroll reporting Superannuation services e.g. 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.

Application of the scope in different circumstances

Significant modification of commercial software

Clients that customise key components of commercial software products may be regarded as in scope of the Framework.

In these circumstances, consideration will be given to:

whether the client would be classed as an in-house developer, any changes to the way that the payload is generated, and the extent to which the payload generated by the customised solution differs from the

original.

Clients should contact the ATO to discuss their individual circumstances.

UNCLASSIFIED EXTERNAL 4

In-house developers

Where a product or service is being developed to manage a business’s own affairs, it may be deemed as ‘in-house’ and fall outside the scope of the Framework.

To be considered as in-house, the product or service must meet all of the following criteria:

Be developed to manage the business’s own taxation, superannuation or payroll affairs only

Have no expectation of commercial gain Not be distributed outside the organisation Be controlled by the business Interact with less than 10,000 taxation or superannuation records

Products deemed as in-house, will be provided with terms and conditions that you will be required to accept.

Although products or services deemed as in-house do not need to meet all the requirements of the Framework, we strongly suggest its adoption as good practice.

DSPs providing diverse product/service offering beyond tax and super

Large organisations with diverse service/product offerings, may limit the scope of the framework to relevant policies, procedures and systems of the business unit responsible for the primary products or services which hold or transact tax or super information.

You should contact the ATO to discuss your individual circumstances.

DSPs that are part of a group of companies

If you are part of a large group of companies, you may limit the scope of the framework to relevant policies, procedures and systems of the business unit responsible for the primary products or services which hold or transact tax or super information.

You should contact the ATO to discuss your individual circumstances.

Products or services producing a .CSV file

When you develop a product or service that produces a .csv or similar file which is then transformed and transmitted via an SSP, and you make that product or service available commercially, it is in scope of the Framework.

UNCLASSIFIED EXTERNAL 5

Understanding how the requirements apply to youThe requirements you will need to meet in order to be approved under the Framework and start consuming ATO services is dependent on a few factors:

the API risk rating of the service/s you are looking to consume whether the product or service you are developing stores and/or transacts with a volume

of greater than 10,000 accessible individual taxpayer or superannuation records your operating model (e.g.: product or service is controlled by the client or controlled by

the DSP).

Requirements for products and services controlled by the clientClient controlled products and services include desktop software and server based software where the application is primarily under the control of the client.

Examples can include but are not limited to:

A software product hosted on the client’s premise (e.g. desktop, local server or private cloud solutions)

A software product hosted on infrastructure that is outside the clients premise but is controlled by the client (e.g. Infrastructure as a Service)

A single instance of a software service that is hosted by the DSP in a single or multi-tenant infrastructure where the client has sole control of the application and control and ownership of the data.

Other scenarios may fall under ‘products and services controlled by the client’ beyond what is listed above.

In the case of a DSP providing a hosted single or multi-tenanted environment for the client, access as a DSP should be limited to maintenance and support activities with client consent. DSPs in this situation must ensure that:

Each instance of the software service is unique for each client Software instances are secured through certificate exchange or multi-factor

authentication

Where the above conditions are not met see ‘Requirements for products and services hosted by the DSP’.

UNCLASSIFIED EXTERNAL 6

Requirements

Requirements for products and / or services controlled by the client

Requirements Connects directly to the ATO Connects indirectly to the ATO (e.g. 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 (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:

Asymmetric/public key algorithms Hashing algorithms Symmetric algorithms

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.

Self-Certification (Mandatory) Self-Certification against either:

iRAP ISO / IEC 27001 SOC2 or OWASP ASVS 3.0 or latest version

UNCLASSIFIED EXTERNAL 7

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 (April 2019.

Security monitoring practices

(Mandatory) DSPs that utilise web services (e.g. hybrid desktop environments) and are consuming medium and high risk APIs are required to have security monitoring in place.

For example:

network / infrastructure layer

application layer

transaction (data) layer

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.

UNCLASSIFIED EXTERNAL 8

Requirements for products and / or 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 (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 (May 2019).

Examples may include; full-disk, container, application or database level encryption techniques.

Payload encryption 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:

Asymmetric/public key algorithms Hashing algorithms Symmetric algorithms

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.

UNCLASSIFIED EXTERNAL 9

Self-Certification or Independent Certification

(Mandatory) Self-Certification against either:

iRAP

ISO/IEC 27001

SOC2 or OWASP ASVS

3.0 or latest version

(Mandatory) Self-Certification against either:

iRAP or

ISO/IEC 27001

(Mandatory) Independent Certification against either:

iRAP or

ISO/IEC 27001

Supply chain visibility (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) Multifactor authentication (MFA) is mandatory for end users that can access taxation or superannuation related information of other entities or individuals (e.g. tax agents, employers).

(Optional but recommended) MFA is optional but recommended for end users that only have access their own information and do not have access to taxation or superannuation related information of other entities or individuals. (e.g. employees accessing employee portals).

DSP Staff (including contracted labour) accessing the product or service(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.

NoteTokens or temporary credential should be isolated to an individual device and 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 (April 2019).

UNCLASSIFIED EXTERNAL 10

Security monitoring practices

Not applicable (Mandatory) Security monitoring is in place.

For example:

network / infrastructure layer

application layer

transaction (data) layer

Sending Service Provider

(Mandatory) Sending Service Providers need to provide the following information:

Intended business model (i.e. will the service be offered to market)

Functional role(s) performed within the supply chain Services that will be offered (e.g. file upload, portal,

REST API etc.) Architecture of the service, including services that are

hosted on shared infrastructure

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.

You must provide suitable supporting evidence to demonstrate that all applicable requirements of the Framework have been met. Where evidence contains sensitive or confidential information you may remove this prior to sending through to the ATO. For the evidence to be acceptable in the event sensitive or confidential information is removed, it must still contain all the relevant details to demonstrate that the requirement has been met.

Personnel securityThis requirement seeks to mitigate threats from malicious internal actors (trusted insiders).

You need to demonstrate that appropriate processes and procedures are in place for hiring, managing and terminating employees and contractors. Processes and procedures may include but are not limited to:

Identity proofing/pre-employment screening Qualification checks Previous employment checks Police checks

UNCLASSIFIED EXTERNAL 11

Further guidance on the requirements

Employee obligations Separation activities

Micro DSPs (one or two employees) are exempt from this requirement unless contractors or non-employees have access to source code or taxation or superannuation related information.

Evidence required

Internal policy document detailing how employees maintain confidentiality of enterprise information,

Process descriptions detailing pre-employment screening and separation procedures or

Sample contracts detailing conditions of employment

Micro DSPs

Written confirmation that no contractors or non-employees have access to the source code or taxation or superannuation related information

Encryption in transitThis requirement seeks to protect the confidentiality and integrity of taxation or superannuation related information in transit.

You need to provide evidence that your product or service utilises TLS 1.3 or another ISM approved cryptographic algorithm and/or protocol. If you use an SSP and they are providing encryption in transit, you will need to demonstrate your relationship with the SSP.

Evidence required

When directly connecting to the ATO a screenshot of one of the below:

SSL certificates Showing HTTPS protocol being enforced Call to API TLS handshake protocol being enforced.

When using an SSP/Gateway to indirectly connect to the ATO:

Licensing agreement or contract for service with SSP Call to the SSP REST API Handshake agreement with SSP showing TLS 1.3 or HTTPS being enforced Screenshots from within SSP portal configuration page showing DSP as a linked

entity.

Encryption at restThis requirement seeks to protect taxation or superannuation related information from unauthorised access.

The scope of encryption at rest covers data repositories that hold or manage tax or superannuation related information.

UNCLASSIFIED EXTERNAL 12

You can chose to apply encryption at the disk, container, application or database level. Encryption at rest should follow Guidelines for using Cryptography (May 2019).

Evidence required

Screenshot showing encryption enabled at the database or disk level with the type of encryption at rest being used

When using ‘out of the box’ encryption a licensing agreement or screenshot showing ‘out of the box’ encryption at rest enabled

If using the infrastructure of a cloud provider to encrypt data at rest, an invoice or contract agreement could be provided or screenshot from within the cloud environment showing encryption enabled.

Where encryption at rest is not viable, evidence must be provided of a full range of data protection controls.

These must include:

User/system (service account) access control (including authentication and authorisation) and active logging and monitoring protocols

Intrusion Detection System/Intrusion Prevention System Internal employee screening or vetting Isolation of/and handling procedures for sensitive data including restrictions such as

‘need to know’ principles.

Payload encryptionThis requirement seeks to protect the confidentiality and integrity of taxation or superannuation related information from the source to the end point.

Payload encryption solution is not currently available, but will be developed in the near future.

Encryption key managementThis requirement seeks to minimise the risks of compromised encryption keys.

You need to demonstrate that a policy or process in place to govern the use of your encryption keys.

The scope of this policy should cover three categories: asymmetric/public key algorithms, hashing algorithms and symmetric encryption algorithms.

Evidence required

Your key management plan should cover the generation, distribution, storage, access, renewal, revocation, rotation, length and complexity of keys, recovery, archiving and destruction of compromised encryption keys.

Audit logging This requirement seeks to ensure traceability of access and actions.

UNCLASSIFIED EXTERNAL 13

Audit logging should include both application level (access logs) and event based actions. Audit logs are not required to be submitted to the ATO on a regular or ongoing basis. You will need to be able to access or supply the logs on the occurrence of a security event where further investigation of the data is required.

You should consider your environment and what logging should be implemented and ensure that the logging records include the following where applicable:

Date and time of the event Relevant user or process Event description Success or failure of the event Event source e.g. application name ICT equipment location and identification Data identifiers (product ID, Tax File Number (TFN)).

Evidence required

Sample of a dummy audit log in CSV format. A data dictionary that describes the data attributes and maps against key audit log

components.

Product ID in message header This requirement seeks to ensure visibility of the software product or service that initiated a transaction.

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.

Evidence required

Screen shot of the product ID in the message header.

Self-CertificationThe self-certification requirement seeks to provide the ATO with a level of assurance that you have robust security practices in place across your organisation. This is done by way of self-certifying against one of the below standards:

iRAP ISO/IEC 27001 SOC2 or OWASP ASVS 3.0 or latest version

As part of the self-certification, you will need to determine which controls from the chosen standard apply to your organisation. Where you deem a control not applicable a short description should be provided as to why.

The scope of certification should cover relevant organisational policies, procedures and data repositories that hold or manage tax or superannuation related information.

UNCLASSIFIED EXTERNAL 14

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

The ATO are unable to prescribe which of the above methods you should use. The choice of what standard to self-certify against should be made on the basis of suitability to your organisation.

We don’t expect you to be fully compliant with the complete range of controls of your chosen standard. The controls that you should be compliant with will be dependent on your organisation’s operating model and the architecture of your product. We also acknowledge there may be areas where you are unable to demonstrate compliance with particular controls. In these scenarios you will be required to offer supporting commentary to substantiate the non-compliance or the manner / timeframe in which you expect to address the gap.

Your self-certification should be reviewed at prescribed intervals or when significant changes occur within your environment. For the purpose of meeting the framework requirement for self-certification, you must review your self-certification annually and resubmit an updated version every 2 years. Where you have had a significant change in your environment which affects the controls you have addressed as part of your self-certification, you are required to submit a revised version to the ATO as soon as possible.

IRAP

The ASD’s Information Security Registered Assessors Program (iRAP) accredits ICT professionals to assess organisations against the Australian Government’s Information Security Manual (ISM). An iRAP assessment will typically cover your organisation as a whole, (governed by a defined scope), and assesses 24 key security domains against the ISM.

ISO/IEC 27001

ISO 27001 is generally completed at the organisational level, however large organisations with diverse service/product offerings may limit the scope of the self-certification to relevant policies, procedures and systems of the business unity response for the primary products or services which hold or transact tax or super information.

All controls need to be answered, with notes next to each control as to what you do or why the control does not apply to you. We don’t expect you to be compliant with all the controls this will be dependent on your organisation’s operating model and the architecture of your product.

OWASP ASVS 3.0

OWASP ASVS 3.0 is completed at the product/application level.

OWASP ASVS 3.0 controls need to be completed to standard 2 as a minimum, with notes next to each control as to what you do to manage the control or if a control doesn’t apply to your product why it doesn’t apply. We don’t expect you to be compliant with all standard 2 controls this will be dependent on your products architecture.

SOC2

SOC2 is generally completed at the product/application level

UNCLASSIFIED EXTERNAL 15

SOC stands for “system and organizational controls” and is a collection of control criteria related to how organisations regulate their information. Some controls which are addressed include risk management, change management, system operations, logical and physical access controls and monitoring of controls. SOC2 is the most comprehensive in the SOC family and the most suited to IT service providers.

Evidence required for Self-Certification

Completed documentation demonstrating your conformance with the requirements (full control suite) of one of the approved security standards including comments on why certain controls may or may not be applicable to your organisation and how controls that do apply are addressed

Independent CertificationThe independent certification requirement seeks to provide the ATO with a level of assurance that you have robust security practices in place across your organisation.

This is done by way of attaining independent certification against one of the below standards:

iRAP ISO/IEC 27001

As part of the independent certification exercise, you will need to determine which controls from the chosen standard apply to your organisation. Where you deem a control not applicable this should be addressed in the statement of applicability.

The ATO are unable to prescribe which of the above methods you should use or provide links to them. The choice of what standard to complete independent certification against should be made on the basis of suitability to your organisation.

The scope of independent certification should cover relevant organisational policies, procedures and data repositories that hold or manage tax or superannuation related information.

We don’t expect you to be fully compliant with the complete range of controls of your chosen standard. The controls that you should be compliant with will be dependent on your organisation’s operating model and the architecture of your product. We also acknowledge there may be areas where you are unable to demonstrate compliance with particular controls. In these scenarios you will be required to offer supporting commentary to substantiate the non-compliance or the manner / timeframe in which you expect to address the address the gap.

Your independent certification should be reviewed at prescribed intervals or when significant changes occur within your environment. For the purpose of meeting the framework requirement for independent certification, you must maintain your independent certification on going. This evidence needs to be supplied to the ATO. Where you have had a significant change in your environment which affects the controls you have addressed as part of your independent certification, you are required to submit a revised version to the ATO as soon as possible.

IRAP

UNCLASSIFIED EXTERNAL 16

The ASD’s Information Security Registered Assessors Program (iRAP) accredits ICT professionals to assess organisations against the Australian Government’s Information Security Manual (ISM). An iRAP assessment will typically cover your organisation as a whole, (governed by a defined scope), and assesses 24 key security domains against the ISM. iRAP assessments may be mandated as a firm requirement, for commercial entities seeking to offer ICT services to federal government agencies as part of formal procurement / tendering processes.

ISO/IEC 27001

ISO 27001 is generally completed at the organisational level, however large organisations with diverse service/product offerings may limit the scope of the independent certification to relevant policies, procedures and systems of the business unity response for the primary products or services which hold or transact tax or super information.

In order to obtain independent certification you will be required to engage a qualified, independent assessor who will conduct an audit of your business in relation to the Standard.

Evidence required

Completed documentation demonstrating your conformance with the requirements (full control suite) of one of the approved security standards outlined above.

Statement of Applicability Letter of Compliance Copy of certificate upon completion of independent certification

Conditional Approval

Where you are undertaking independent certification, you may be eligible for conditional approval where this is the only requirement outstanding. This allowance has been made as the timeframe to attain independent certification being heavily reliant on a third party. Evidence will need to be provided that you have engaged a relevant certifying body to perform the independent certification against either:

iRAP ISO/IEC 27001

Evidence required

Letter of Engagement with a start date, completion date, scope of work and assessor details

Supply chain visibilityThe supply chain visibility requirement seeks to identify the entities and annotate their functional roles involved in the transmission of information from the system which generates the payload through to the ATO. This requirement is only relevant where your product or service does not directly connect to the ATO and the payload is not encrypted.

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

UNCLASSIFIED EXTERNAL 17

Data Integrator: Party responsible for combining data from multiple sources for use Data Analysis and 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. (e.g.

ebMS3/AS4 transmission).

These requirements are an interim measure only and may change when the supply chain visibility solution is available.

Evidence required

Until a supply chain visibility solution is available, DSPs are required to provide the business details of the participants in the supply chain including:

Entity name ABN Service provider role or function.

Data hosting This requirement seeks to limit the risk of access to taxation and superannuation related information by individuals no authorised to access – including foreign actors.

Where you use a hosting provider you will need to provide their details to the ATO. The use of an ASD certified hosting environment is recommended but not mandatory.

Additional conditions for offshore data hosting

By default, you should host data onshore. Offshore hosting arrangements will be managed by exception on a case by case basis. Where you are planning to host data offshore, additional evidence will be required to satisfy the data hosting requirement.

Where there is a compelling reason for storing data outside of Australia, you must consult with the ATO to ensure that the impact has been adequately addressed. The ATO can provide advice on jurisdictional constraints. As part of the consultation DSPs must demonstrate they have considered the jurisdictional constraints.

The ATO’s preference is for all redundancy locations to mirror those of the primary production environment. Where there are strong encryption controls and alignment to the APRA guides CPG 235 – Managing Data Risk and SPG 231 – Outsourcing, you may consult with the ATO on suitability of redundancy hosting arrangements in an offshore location. Applications will be reviewed on a case by case basis.

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

UNCLASSIFIED EXTERNAL 18

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 complete a risk assessment against the below risks and steps to mitigate 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 you as the DSP

compliance (legal) risk — the risk that offshoring arrangements will have an impact upon your ability to comply with relevant Australian and foreign laws and regulations (including accounting practices)

contractual risk — the risk that your ability as a DSP to enforce the offshoring agreement may be limited or completely negated

access risk — the risk that your ability as 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 you as a 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 (e.g. clients of tax practitioners, employees, etc.) on where and how their data is being managed.

Evidence required

Provider name Provider location (physical address) Redundancy location (physical address) Whether the provider is ASD certified or assessed against another security standard

Offshore data hosting

If you are storing data off-shore you will need to contact the DPO in the first instance.

Multi-Factor Authentication This requirement seeks to minimise the opportunity for unauthorised users to access taxation or superannuation related information.

Multi-factor authentication (MFA) is defined as a method of authentication that uses two or more authentication factors from different categories, to authenticate a single claimant to a single authentication verifier. The authentication factors can be categorised as:

UNCLASSIFIED EXTERNAL 19

Something you know, such as a password or a response to a security question Something you have, such as a one-time pin, SMS message, smartcard, or software

certificate Something you are, such as biometric data, like a fingerprint or user’s voice

Single-factor authentication generally falls into the ‘something you know’ category such as a password. MFA requires a user to prove they have physical access to a second factor that they either have (e.g. a physical token) or are (e.g. fingerprint).

Further information on each method can be found at ACSC Protect: Multi-factor authentication (PDF)

The requirements for MFA are determined by your setup in combination with the type of user and access to other individuals or entities data.

Although MFA is not a mandatory requirement for products or services which are controlled by the client, the adoption and implementation of MFA is highly recommended.

For DSP controlled products or services the following circumstance is an example of when MFA is not mandatory but is highly recommended (note: this is not an exhaustive list).

Example: End users or external users that only have access to their own information and do not have access to taxation or superannuation related information of other entities or individuals. (E.g. employees accessing employee portals)

Example: Internal users who access tax and super data and the DSP can adequately demonstrate that the internal user does not perform a privileged administration role (system / database level) and that good passphrase practices including single factor authentication controls, account lockouts, resetting passphrases, session and screen locking as described in the Australian Government Information Security Manual (ISM) are implemented. The following circumstances are examples of when MFA is mandatory (note: this is not an exhaustive list):

Example: End users or external users who can access taxation or superannuation related information of other entities or individuals (e.g. tax agents, employers).

Example: DSP staff who perform a privileged user role as defined in the Australian Government Information Security Manual (ISM) with access taxation or superannuation related information.

Enterprise Customers

By exception, DSPs must seek advice from the ATO on the use of Single Sign On (SSO) for enterprise customers that access a DSP’s system from behind their enterprise firewall. SSO must be controlled by the DSP and only enabled for a customer where the below controls are in place.

In considering whether to support SSO for their customers, DSPs must ensure that that the customer:

is an enterprise that has control over the access management solutions e.g. (does not use social media as a sign in)

UNCLASSIFIED EXTERNAL 20

has strong encryption in place e.g. TLS1.2 has a password or passphrase management policy, covering length and complexity

including salt, hashing enforces brute force lockout

Note

End users are those individuals, external to the DSP, who actually use the product or service.

DSP staff are those staff (including contractors) working for or on behalf of the DSP. The ATO may consider exceptions to mandatory MFA for end users of DSP hosted

products/services in extenuating circumstances. Where the transaction is authenticated within a machine to machine interaction, multi-

factor authentication (MFA) is not applicable. 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 good

passphrase practices including single factor authentication controls, account lockouts, resetting passphrases, session and screen locking as described in the Australian Government Information Security Manual (ISM)

A privileged user is defined as a user who can alter or circumvent a system’s security measures – this may include the capability to modify system configurations, account privileges, audit logs, data files or applications.

Evidence required

User manual, user description or instruction paired with screen shots of the user interface

Security monitoring practicesThis requirement seeks to detect and respond to cyber-attacks, channel misuse and business threats. Monitoring is a joint responsibility between the ATO and you as the DSP. Where relevant you need to be able to demonstrate that you scan your environment for threats and that you take appropriate action where you detect anomalies.

Evidence requiredNetwork / infrastructure layer - relevant combinations of:

screen shots of an intrusion detection system or firewall that generates alerts. If a DSP uses a third party a screenshot from within the solution showing the monitoring capabilities, dashboard etc.

photos of your Security information and event management dashboard If leveraging off a cloud provider you can provide either an invoice or screenshot from

within the environment showing the type of monitoring captured.

Application layer – relevant combinations of:

screen shots of the function page in the application, and reports from the backend system.

Transaction (data) layer – relevant combinations of:

reports from the backend system Screenshots of an anomaly detection system.

UNCLASSIFIED EXTERNAL 21

Sending Service Providers (SSPs) This requirement seeks to understand details of a sending service provider’s (SSP) model and value chain. If you will be acting in a capacity of an SSP you will need to provide additional information.

Evidence required

Intended business model (i.e. will the service be offered to market) Functional role(s) performed within the supply chain Services that will be offered (e.g. file upload, portal, REST API etc.) Architecture of the service, including services that are hosted on shared infrastructure

SSPs may also be required to provide:

Published product description Screen shots displaying the method of connection

DSPs with add-on marketplacesThis requirement seeks to identify DSPs that allow third-party add-ons to connect to their software via an API and what if any security controls are in place to govern their access. For this purpose SSPs/gateways are not considered as DSPs with add-on marketplaces.

Examples of add-ons:

Accounting/taxation: inventory, CRM, OCR scanning Payroll: timesheets, rostering, pay calculator Superannuation: audit integrations, share registries

If you are a DSP with an add-on marketplace you will need to provide additional information.

Evidence required

Details on the security standard you adopt to govern your add-ons. Whilst the ATO does not prescribe or mandate the security standard you apply to your 3rd party add-ons, we can recommend the ABSIA Security Standard for Add-on Marketplaces (SSAM) as a baseline.

List of your third-party add-ons with more than 1,000 Australian business connections and/or a connection to an Australian tax agent/practice. The list should include:

o The third-party developers nameo Hyperlink to their product

Operational Framework approval processDSPs seeking approval are required to submit a completed security questionnaire to the ATO via the DPO. The responses in the questionnaire should provide evidence that reasonably substantiates the implementation of the requirements.

UNCLASSIFIED EXTERNAL 22

Meeting the framework requirements and ongoing expectations

Once all the relevant information has been provided the ATO will assess the evidence provided and either:

grant approval grant conditional approval.

Conditional approval

Conditional approval is granted only in situations where the DSP is undertaking necessary steps to meet the Framework requirements of MFA and independent certification. At this time progress will be assessed and a determination made as to whether the conditional approval will continue or the DSP’s access will be suspended until such time as they meet the requirements.

Terms and conditions

Each approval will include terms and conditions. Every DSP is required to accept outlined terms and conditions unique to their circumstances prior to being whitelisted.

Annual reviewsThe ATO will conduct an annual review of all DSPs who have been approved under the Framework. During this process, DSPs will be required to revisit the Framework requirements and provide assurance of their compliance.

DSPs will be provided with a review date as part of their approval – typically 12 months after approval. One month prior to the review date, the DPO will remind the DSP of the review.

As part of the review, DSPs will need to confirm if there have been any changes to their business or product environment. Where this is the case, the DSPs may need to provide additional information in line with the requirements. Where there have not been any changes in the business / product environment, DSPs will need to provide formal confirmation.

Independent Certification / Self-Certification maintenanceThe annual review process includes a review of a DSPs independent certification or self-certification. The currency of an independent certification is determined by the expiry date listed on the certificate itself. Self-certification is deemed as current for 2 years from the date of initial approval by the ATO.

DSPs will also need to provide assurance that independent and self-certification has been maintained. For DSPs with independent certification, this may include surveillance audits.

Changing circumstancesThe ATO must be notified via Online Services for DSPs or DPO@ato.gov.au of any material changes to your business or product environment (i.e. relating to the information you supplied in your questionnaire response.)This may include, but not be limited to:

change of ownership or significant Director changes changes in data hosting increase in client base (i.e. greater than 10,000 unique taxation or superannuation

records)

UNCLASSIFIED EXTERNAL 23

additions or changes to DSP product or service offerings.

In this circumstance, a new Security Questionnaire may need to be provided, including updated evidence.

The ATO also reserves the right to undertake ad hoc reviews to ensure DSPs maintain alignment to the requirements of the Framework.

Monitoring and data breachesMonitoring 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, the ATO will work with the DSP to address and limit the damage of the threat. This may include increasing the requirements a DSP needs to meet or introducing additional requirements.

The ATO will generally contact a DSP before taking action unless exceptional circumstances apply.A data or identity security breach may include:

Identity details being accessed or seen by an unauthorised third party Identity details being lost or stolen due to illegal access by a third party activity (e.g.

common online threats such as malware, spyware or ransomware). Mistakenly providing information to the wrong person, for example sending details out

to the wrong email address. A breach of a third party product or service which integrates with a DSP’s API

(application programming interface).

Where a DSP identifies a breach through their own monitoring controls or have been informed directly by a client or third party, the ATO must be notified immediately. This can be done via your account manager, Online Services for DSPs or DPO@ato.gov.au to ensure appropriate action can be taken.

In order for the ATO to take action to limit the damage and identify the source of the threat, the following information is requested:

appropriate contact person (specialist IT security/fraud representative) nature of the incident number of affected records date and timestamp session ID reference host Services (Internet Service Provider)/IP address device ID (ESID) if available TFN information non-TFN information (name/address/biographical information) product name and type (desktop or cloud) what format the data was in (e.g. CSV or encrypted).

Awareness of other obligationsIn addition to the requirements of the Framework, DSPs need to be aware of their obligations under:

Notifiable Data Breach scheme under Part IIIC of the Privacy Act 1988 (Privacy Act).

UNCLASSIFIED EXTERNAL 24

For further information on the Notifiable Data Breach scheme, please refer to https://www.oaic.gov.au/privacy-law/privacy-act/notifiable-data-breaches-scheme

Australian Privacy Principles, contained in schedule 1 of the Privacy Act 1988 (Privacy Act)

For further information on the Australian Privacy Principles, please refer to https://www.oaic.gov.au/privacy-law/privacy-act/australian-privacy-principles

What happens if a DSP doesn’t meet the Framework requirements?The ATO expects all DSPs will meet and maintain the relevant requirements of the Framework. The ATO is committed to the protection of tax and superannuation information and will treat issues of non-conformance seriously.

The ATO will endeavour to work through non-conformance issues with DSPs; however failure to address 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 de-whitelisting process document outlines when and how a de-whitelisting may occur.

Evolution of the frameworkThe requirements of the Framework will change over time to respond to new and emerging risks. Proposed updates will be consulted with industry and their representatives, to establish the scale of the changes and transition timeframes. DSPs that have been approved or are working towards approval will be provided reasonable time to transition meet any updated requirements.

QuestionsShould you have any questions in relation to this document or your requirements as a DSP, please contact us via Online Services for DSPs or DPO@ato.gov.au and a member of our team will be in contact with you.

Term Definition

Accessible Information that is readily available and easily obtained by the end user.

Add-on marketplace API interfaces that are offered by a DSP, for use by other third party software developers to provide additional value add services to end customers.

UNCLASSIFIED EXTERNAL 25

Appendix: Glossary

Term Definition

Application programming interface (API)

An API is a set of subroutine definitions, protocols and tools for building application software.

Application Security Verification Standard (ASVS 3.0)

A framework of security requirements and controls that focus on normalising the functional and non-functional security controls required when designing, developing and testing modern web applications.

ATO wholesale services Standard Business Reporting, Rest

Australian Signals Directorate (ASD)

The ASD produces the Australian Government Information Security Manual (ISM). The manual is the standard which governs the security of government ICT systems. It complements the Protective Security Policy Framework (PSPF).

Cloud software Software that is delivered, stores data and is managed remotely from its users or their technology infrastructure. For example Software as a Service (SaaS).

Commercial software Software which is produced for the purpose of on-selling.

Data at rest Data which is in storage and is not actively moving from device to device or network to network.

Data breach A data breach is an unauthorised access or disclosure of personal information, or loss of personal information. Data breaches may be caused by malicious action, human error or a failure in information handling systems.

Data in transit Data that is actively moving from one location to another for instance device to device or network to network.

De-whitelisting The process of preventing the ability to transact with ATO production services.

Digital service provider (DSP)

Software or solution providers that produce digital systems that perform any function within any digital supply chain handling tax payer or superannuation data.

Direct to ATO, product hosted on customer’s premise or on customer’s IaaS/PaaS Cloud

Software that is loaded and stored on a client’s local computer, service (IaaS/PaaS) and or device and transmits direct to the ATO.

ebMS3 A set of layered extensions to the SOAP protocol, providing security and reliability features enabling e-Commerce transactions.

ATO is using the eBMS3 standard with the addition of the AS4 profile.

Encryption The process of encoding information in such a way that only the

UNCLASSIFIED EXTERNAL 26

Term Definition

person (or computer) with the ‘key’ can decode it.

Highly leveraged or high volumes of taxpayer or superannuation records

A DSP product or service that stores over 10,000 ‘accessible individual taxpayer or superannuation related information’ records. Records that relate to the same individual are only counted once OR any gateway or SSP.

Hybrid model An operating model which uses a combination of software types and connections.

Indirect to ATO, product hosted on customer’s premise or on customer’s IaaS/PaaS Cloud via gateway

Software that is loaded and stored on a client’s local computer, service (IaaS/PaaS) and or device and uses a gateway or SSP to facilitate the transmission of a message to the ATO.

Information security Manual (ISM) approved cryptographic algorithms

Algorithms which have been extensively scrutinised by industry and academic communities in a practical and theoretical setting and have not been found to be susceptible to any feasible attack.

Taxpayer or superannuation related information

Information that has been stored for the purpose of a taxation or superannuation law and identifies, or is reasonably capable of being used to identify an individual or other entity. Note – information related to payroll is considered to be taxation related.

The Information Security Registered Assessors Program (IRAP)

An ASD initiative to provide high-quality information and communications technology (ICT) services to government in support of Australia's security.

IRAP provides the framework to endorse individuals from the private and public sectors to provide cyber security assessment services to Australian governments.

In-house developed product

A product which has been developed for exclusive use by the organisation to manage their own payroll and other affairs; the product cannot be sold to other organisations.

ISO/IEC 27001 A family of standards which assist the ATO in managing the security of assets such as financial information, intellectual property or information entrusted by third parties.

ISO/IEC 27001 is recognised as the international standard for managing information security.

Mandatory (requirement) Requirement must be in place (or towards being implemented) before ATO services can be used in production.

Optional (requirement) Requirement does not have to be in place to access ATO services in production, but it is recommended.

UNCLASSIFIED EXTERNAL 27

Term Definition

Payroll information For the purpose of this document payroll information is data used for reporting payroll information to the ATO.

Privileged user A user who can alter or circumvent a system’s security measures – this may include the capability to modify system configurations, account privileges, audit logs, data files or applications.

Sending service provider (SSP)

A DSP that facilitates the transfer of STP compliant electronic data messages.

Service Organization Control 2 (SOC2)

An audit report which covers operational control systems following. Predefined criteria around security, availability, process integrity, privacy and confidentiality.

Whitelisting The process of gaining access to transact with ATO production services.

UNCLASSIFIED EXTERNAL 28

Document Details

Attributes Details

Version 5.1

Date updated January 2020

Document Name Digital service provider Operational Framework Requirements to utilise ATO digital services

Contact Online Services for DSPs or DPO@ato.gov.au

Version Changes Date Released

0.1 Document creation and draft released December 2017

1.0 Finalised version released February 2018

2.0 Major version released. Key changes include:

Scope of the framework as it applies to an in house developer Updated transition strategy Extended the requirements for sending service providers Further clarity of annual review process and data breach

processes Removed the instructional material How it fits into development process

August 2018

3.0 Major version released. Key changes include:

Scope and requirements:

In house DSP description updated Significant customisation of commercial software added Refined scope in the context of large and/or diverse

organisations Updated the definition of client hosted to client controlled Guidance provided on multi-factor authentication

requirements Alternate controls to protect data at rest (encryption at rest) Clarified that payroll data is covered under tax related

information Details of Annual review and changing circumstances process

December 2018

UNCLASSIFIED EXTERNAL 29

Major Version History

added What happens when a DSP doesn’t meet the framework added Evolution of the framework updated Intent, examples of evidence and further guidance notes for

each requirement Glossary added

4.0 Updated wording changes to align with the DSP operational framework security questionnaire version 1.3.

June 2019

5.0 Added requirements for DSPs with add-on marketplaces. October 2019

5.1 Minor updates include:

Clarification regarding the approval process and requirements for using single sign on for enterprise customers

Link included to de-whitelisting process document

January 2020

UNCLASSIFIED EXTERNAL 30