Further guidance on requirements

Detailed information on each of the security control requirements is provided on this page. If you require additional information or assistance, you can visit the DSP hub or contact the Digital Partnership Office (DPO) via the DSP service desk in Online services for DSPs.

On this page

Annual reviews

You must provide annual assurance that your products and services remain compliant with the controls and requirements of the DSP OSF. We will raise an OSF annual review ticket via the DSP service desk and email you instructions on the actions you should take for your annual review.

The annual review includes a review of your self-assessment or independent certification currency. A self-assessment is deemed current for 2 years from the date of our initial approval. The validity of the independent certification currency is determined by the expiry date listed on the certificate.

Audit logging

Audit logging seeks to ensure traceability of access and actions within software which can be used for detection of anomalies or to support the investigation of a security incident. In the event of a security incident, you will need to supply us with relevant audit logs.

Audit logging needs to include:

  • access and event-based logs including changes to privileges, permissions, and authorisations
  • users with privileged access must also be identifiable within these logs
  • shared login credentials are not permitted, and each individual user and session will need to be uniquely identifiable through audit logs
  • logs must be kept for a minimum of 12 months and must not be deleted within this period.

Evidence required

DSPs must provide dummy or authentic access and event logs (sensitive information redacted) which include:

  • authentication and authorisation
  • date and time of the event
  • username / identifier
  • success or failure of the event
  • event description
  • ICT equipment location and identification.

You can provide an audit log policy to cover the inclusions requested (such as retention and no shared logins).

It is recommended you adopt a risk-based approach to implement controls from the Australian Cyber Security Centre Guidelines-System-Monitoring or equivalent industry standard such as NIST Guide to Computer Security Log Management.

Authentication

Multi-Factor Authentication

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 something you:

  • know - such as a password or a response to a security question
  • have - such as a one-time pin, SMS message, smartcard, or software certificate
  • are - such as biometric data, like a fingerprint or facial geometry.

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 have (such as a physical token) or are (such as fingerprint.

MFA for DSP controlled environments

This requirement seeks to minimise the opportunity for unauthorised users to access Taxation, Accounting, Payroll, Business Registry or Superannuation related information. Under this security control requirement:

  • MFA must be permanent and cannot be disabled by the client.
  • MFA is required for all users of software products that are controlled or hosted by the DSP (for accessing information for themselves or other entities or individuals).
  • all cloud environments must have MFA in place to access any data in scope of the DSP OSF
  • MFA is required for all DSP staff with privileged user access
  • inactive session time-out occurs after a maximum 30 minutes (15 minutes is preferred). This is a screen lock process where full MFA is not required to unlock.
  • remember me on this device must be limited to 24 hours
  • brute force lockouts are applied after a maximum of 5 unsuccessful login attempts. This specifies that an event must occur, not how each DSP handles this lockout before a client can re-try logon. We do not seek the details of the lockout process, only that it occurs.
  • shared logins are not permitted and need to be blocked by the DSP. Each individual user and session will need to be uniquely identifiable through audit logs
  • authenticator apps can be used such as Microsoft Authenticator, Symantec VIP or Google Authenticator, and will need to demonstrate how MFA is enforced at login
  • social media credentials are not recommended to be used for MFA to sign in. However if your solution is based on the use of social media credentials you must contact the DPO to discuss your proposed solution.

Further information on each MFA method can be found at ACSC: Implementing Multi Factor Authentication.

If you have not implemented MFA, you should consider implementing passphrase management, account lockout and resetting passphrase practices described in the Australian Government Guidelines for system hardening.

Single sign on

DSPs must seek advice from the DPO on the use of enterprise Single Sign On (SSO) to support their clients.

When implementing enterprise SSO, you must ensure that:

  • disablement of MFA is controlled by the DSP, not the client
  • encryption in transit between the client’s system and software uses an approved protocol as per the Australian Government Guidelines for using cryptography
  • remember me on this device is limited to 24 hours
  • SSO tokens is limited to a maximum period of 24 hours
  • tokens or temporary credentials are isolated to an individual device and expire once used - tokens or temporary credentials must expire within 24 hours
  • SSO occurs behind the client’s enterprise firewall such as a gateway
  • brute force lockouts are applied after a maximum of five unsuccessful login attempts
  • credentials are stored separately from the system that grants access
  • confirmation passwords are hashed, salted, and stretched
  • inactive session time-out occurs after a maximum 30 minutes, 15 minutes is preferred (This is a screen lock process where full MFA is not required to unlock).
  • ACSC authentication hardening includes additional guidance to support DSPs implementation.

Note: Short Message Service (SMS) are more susceptible to compromise by an adversary than others. We therefore recommend you use an alternative authentication factor when appropriate. 

Evidence required

  • Advise DPO that SSO has been implemented and meets the advised standards.

We treat these implementation statements from DSPs regarding their (or their clients) SSO implementations; that they meet the intended aim of MFA, securing authentication and authorisation processes as MFA does.

Certification

Independent Certification

The independent certification requirement provides us with a level of assurance that DSPs have robust security practices in place across their organisation. This is done by attaining independent certification against the iRAP or ISO/IEC 27001 standards.

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

We do not prescribe which standard you should apply or provide links to them. Your choice of standards should be made based on its 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.

The DPO recognises you may not be fully compliant with the complete range of controls of your chosen standard. The controls you should be compliant with will depend on your organisation’s operating model and the architecture of the product. We also acknowledge there may be areas where you are unable to demonstrate compliance with controls. In this scenario you will be required to offer supporting commentary to substantiate the non-compliance or the manner and timeframe in which you expect to address the gap.

Independent certification should be reviewed at prescribed intervals or when significant changes occur within your environment. To meet the requirement for independent certification, you must maintain ongoing independent certification, and you will need to supply us with evidence of this.

If there is a significant change in the environment that affect the controls  addressed as part of independent certification, you are required to submit a revised version to us as soon as possible.

IRAP/ISM

The Australian Signals Directorate (ASD) 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 the organisation as a whole, (governed by a defined scope), and it 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 a formal procurement or tendering process.

ISO/IEC 27001

ISO 27001 is generally completed at the organisational level. However, large organisations with diverse service or product offerings may limit the scope of the independent certification to relevant policies, procedures, and systems of the business unit responsible for the primary products or services which hold or transact Taxation, Accounting, Payroll, Business Registry or Superannuation data.

To obtain independent certification, you will be required to engage a qualified, independent assessor annually to conduct an audit of your business in relation to the standard.

Evidence required

  • Completed documentation demonstrating conformance to one of the approved security standards outlined above
  • Statement of applicability
  • Letter of compliance
  • Copy of certificate upon completion of independent certification.

Self-Assessment

The self-assessment requirement provides us with a level of assurance that DSPs have robust security practices in place across their organisation. This is done by self-assessing against one of the following standards:

  • ISO/IEC 27001
  • ISO/IEC 27002
  • SOC2
  • OWASP ASVS 3.0 or latest version
  • NIST

As part of the self-assessment, you will need to determine which controls from the chosen standard apply to your organisation. Where you deems a control is not applicable, you should provide a short description as to why.

The scope of certification should cover relevant organisational policies, procedures and data repositories that hold or manage Taxation, Accounting, Payroll, Business Registry or Superannuation related information.

The DPO will accept this as evidence across multiple products when you can attest that each product or service is covered under the certification.

You can request to use an alternative security standard if you consider it more suitable given your circumstances. These requests will be assessed on a case-by-case basis.

Your choice of what standard to self-certify against should be made based on its suitability to your organisation. We do not prescribe which standard you should use.

The DPO recognises you may not be fully compliant with the complete range of controls of your chosen standard. The controls you should be compliant with depends on your organisation’s operating model and the architecture of your product or service.

We also acknowledge there may be areas where you are unable to demonstrate compliance with controls. In these scenarios you will be required to offer supporting commentary to substantiate the non-compliance or the manner and timeframe in which you expect to address the gap.

Your self-assessment should be reviewed at prescribed intervals or when significant changes occur within your environment. However, you must review your self-assessment annually and resubmit an updated version every 2 years.

If there has been a significant change in your environment which affects the controls you addressed as part of your self-assessment, you will be required to submit a revised version to us as soon as possible.

ISO/IEC 27001

ISO/IEC 27001 is generally completed at the organisational level, however large organisations with diverse product or service offerings may limit the scope of the self-assessment to relevant policies, procedures, and systems of the business unity response for the primary products or services which hold or transact Taxation, Accounting, Payroll, Business Registry or Superannuation data.

All controls need to be answered, with notes next to each control as to how you achieved compliance or why the control does not apply.

We do not expect you to be compliant with all controls, as this will depend on your organisation’s operating model and the architecture of your product or service.

ISO/IEC 27002

ISO/IEC 27002 provides guidance for organisational information security standards and information security management practices. It includes the selection, implementation and management of controls taking into consideration the organisation's information security risk environment.

It is designed to be used by organisations intending to:

  • select controls within the process of implementing an Information Security Management System based on ISO/IEC 27001
  • implement commonly accepted information security controls
  • develop their own information security management guidelines.

ISO/IEC 27017

ISO/IEC 27017 provides guidelines for information security controls that apply to the use of cloud services by providing an additional implementation guidance for 37 controls specified in ISO/IEC 27002 and 7 additional controls related to cloud services.

OWASP ASVS 3.0

OWASP ASVS 3.0 is completed at the product or application level. The controls need to be completed to Standard 2 as a minimum, with notes next to each control detailing what you need to do to manage the control, and if it does not apply, why.  We do not expect you to be compliant with all Standard 2 controls, as this will depend on the architecture of your product or service.

SOC2

SOC2 (System and Organizational Controls) is generally completed at the product or application level. It refers to a collection of control criteria related to how an organization regulates their information. The controls relate to 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 it is most suited to IT service providers.

NIST

The National Institute of Standards and Technology (NIST) is a policy framework of computer security guidance to assess and approve an organisations’ ability to prevent, detect and respond to cyber-attacks.

The framework is devised into five main functions of identify, protect, detect, respond, and recover. These functions support an organisation in expressing a level of cyber security risk by addressing threats and developing learnings.

NIST is to be completed via a maturity assessment and can only be applied to Category B (medium to high-risk APIs) and Category C (low to no risk APIs) DSPs.

Evidence required

Documentation demonstrating compliance to one of the approved security standards must include notes on how controls are applied in your organisation and if applicable, why certain controls may not be applied.  

Data hosting

DSPs must provide details of their hosting provider to us.

This requirement seeks to limit the risk of access to Taxation, Accounting, Payroll, Business Registry or Superannuation related information by individuals with no authority, including foreign actors.

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

If you have a compelling reason for storing data outside Australia, you must consult us to ensure the impacts are adequately addressed. As part of this consultation, you must demonstrate that you have considered the jurisdictional constraints.

Our preference is for all redundancy locations to mirror the primary production environment. Where strong encryption controls and alignment to APRA Prudential Practice Guide CPG 235 Managing Data Risk (PDF, 328.44KB) and APRA Prudential Practice Guide SPG 231 Outsourcing (PDF, 249.51KB) are applied you can discuss the suitability of redundancy hosting arrangements in an offshore location with us. Applications will be reviewed on a case-by-case basis. 

Consistent with APRA Prudential Practice Guide CPG 235 Managing Data Risk, we expect the following to 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 APRA Prudential Practice Guide SPG 231 Outsourcing (PDF, 249.51KB), we expect you to complete a risk assessment against the following risks, including details of the steps you will take to mitigate them:

  • Country: risk that overseas economic, political and/or social events will have an impact on the ability of an overseas service provider to continue to provide an outsourced service to you as the DSP.
  • Compliance (legal): risk that offshoring arrangements will have an impact on your ability to comply with relevant Australian and foreign laws and regulations (including accounting practices).
  • Contractual: risk that your ability as a DSP to enforce the offshoring agreement may be limited or completely negated.
  • Access: 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 our information gathering powers.
  • Counterparty: risk arising from the counterparty’s failure to meet the terms of agreement with you as a DSP or to otherwise perform as agreed.

We expect that an offshoring arrangement would typically include a provision around security and confidentiality of information.

If you are storing data outside Australia, you must:

  • make it clear to customers that their data is being stored in a foreign jurisdiction
  • apply the Australian Privacy Principles
  • provide guidelines to your customers around where and how their data is being managed.

Evidence required

  • Provider name
  • Provider location (region)
  • Redundancy location (region)
  • Provider certification (ASD or another security standard).

If you are storing data offshore you will need to contact the DPO.

Encryption key management

DSPs need to demonstrate a policy or process is in place to govern the lifecycle management of encryption keys and minimise the risks of compromised keys.

The scope of this policy should cover three categories:

  • Asymmetric/public key algorithms
  • Hashing algorithms and
  • Symmetric encryption algorithms.

The use of algorithms must align to the Australian Government Guidelines for using cryptography.

A key management policy or plan must include generation, distribution, storage, renewal, revocation, recovery, archiving and destruction of encryption keys. For more information see attachment F in APRA Information Security CPS 234 (PDF, 837KB).

Evidence required

Copy of your key management policy or plan which includes:

  • Generation
  • Distribution
  • Storage
  • Access
  • Renewal
  • Revocation
  • Rotation
  • Archiving
  • Length and complexity of keys
  • Destruction of compromised encryption keys
  • Recovery

Encryption at rest

The scope of encryption at rest covers data stored for the purpose of Taxation, Accounting, Payroll, Business Registry and Superannuation transactions including Personally Identifiable Information (PII).

The approved symmetric encryption algorithms are Advanced Encryption Standard (AES) using key lengths of 128, 192 and 256 bits, and Triple Data Encryption Standard (3DES) and three distinct keys as per the Australian Government Guidelines for using cryptography.

DSPs can choose to apply this control by either encrypting the disk, container, application, or database. Alternatively, you may choose to apply partial encryption to data at the block, field, or column level but this must cover data that is stored for the purpose of Taxation, Accounting, Payroll, Business Registry and Superannuation transactions including Personally Identifiable Information (PII).

If you have implemented encryption at rest, further controls are recommended. More  information on implementing network segmentation and segregation can be found at ACSC Implementing Network Segmentation and Segregation.

Evidence required

One of the following:

  • Screenshot showing encryption enabled, confirmation of method of encryption applied, and algorithm used
  • Licensing agreement or invoice with whitepaper
  • Policies relating to data classification when applying block, field, or column level encryption
  • Where encryption at rest is not viable, provide a screenshot/policy which demonstrates all the below have been met
  • User/system role-based access controls and active logging and monitoring protocols
  • Restricting or limiting access to databases using the principle of least privilege
  • Separation of hosts and segregation of networks or micro segmentation
  • Intrusion Prevention and detection controls.

Further information is available at ACSC Implementing Network Segmentation and Segregation.

Encryption in transit

This requirement seeks to protect the confidentiality and integrity of Taxation, Accounting, Payroll, Business Registry and Superannuation information in transit.

You are required to provide evidence that an approved protocol TLS 1.2 or higher is used as per ACSC Guidelines for using Cryptography and Annex A of ACSC Implementing Certificates, TLS and HTTPS.

Evidence required

All cloud products must provide one of the following:

  • Back-end configuration of TLS (for example, load balancer)
  • SSL labs report for public certificates.

All indirectly connecting products must provide one of the following:

  • Licensing agreement with SSP
  • Screenshots from SSP portal
  • Screenshot of API call to 3rd party showing TLS protocol.

Note: Desktop products that directly connect to the ATO are not required to provide evidence for this requirement.

Entity Validation

Entity validation ensures that the consumer or user of a commercial software product is a legitimate business and has a genuine need to access a DSPs software.

To complete entity validation, you must verify the entity against a reliable and independent source such as the Australian Business Register. Additionally, you must obtain valid client contact details that includes a confirmed email and phone number.

When a consumers does not have an ABN, for example a student using software for research purposes, you are required to validate their contact information only.

Note: Entity validation does not negate the need for DSPs to meet specific service requirements relating to verification. For example, SuperMatch requires specific customer verification requirements as part of the terms of use.

Evidence required

DSPs need to provide evidence that demonstrates entity validation is in place as part of the product registration/purchase process.

Personnel Security

This requirement seeks to mitigate threats from malicious internal actors (otherwise known as trusted insiders).

You need to demonstrate 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 or pre-employment screening
  • Previous employment checks
  • Police checks
  • Employee obligations
  • Separation activities

Note: Micro DSPs, those with one or two employees, are exempt from this requirement unless contractors or non-employees have access to source code or Taxation, Accounting, Payroll, Business Registry or Superannuation related information.

Evidence required

  • Internal policy documents detailing how employees maintain confidentiality of enterprise information
  • Process descriptions detailing pre-employment screening and separation procedures
  • Sample contracts detailing conditions of employment.

Security monitoring

This requirement seeks to minimise the risk and impact of cyber incidents by having controls in place to detect, prevent and respond to cyber-attacks.

Monitoring is a joint responsibility between us and you.

We expect DSPs to be able to demonstrate that:

  • appropriate processes and procedures are in place to monitor networks, applications and transactions
  • you regularly scan your environment for threats and take appropriate action when anomalies are detected.

Evidence required

  • Screenshot of an intrusion detection system such as a firewall that generates alerts
  • Approach to detect anomalies or a screenshot of a security event and incident management dashboard
  • Intrusion prevention system which protects end points and scans the DSP environment to prevent malicious events
  • Policy demonstrating actions that will be taken where anomalies are detected.

Supply Chain

Visibility of the supply chain allows for the identification of entities (and the functional roles within) that are involved in the transmission of information that generates the payload to the ATO. This includes details of any third-party connections to your product or service via APIs.

The functional roles within a supply chain can be defined as:

  • Data collector: party responsible for the acquisition of data through a 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 and extraction: party responsible for extracting and /or performing analysis on data.
  • Data transformer: party responsible for changing the representation of data to a file format (such as from CSV to XML).
  • Data provider: party responsible for the payload, which may be encrypted.
  • Data transmitter: party responsible for the message with the payload (for example, ebMS3/AS4 transmission). These requirements are an interim measure only and may change when the supply chain visibility solution is available.

Evidence required

DSPs are required to provide the business details of the participants in the supply chain including:

  • Entity name
  • ABN
  • Service provider role or function.

DSPs with an add-on marketplace will need to provide additional information.

Third Party add-on marketplaces

This requirement seeks to identify security controls and policies you need to implement when partnering with third party add-on providers that allow connection via an API.

Examples of add-ons include:

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

Note: SSPs and gateways are not considered as DSPs with add-on marketplaces.

Evidence required

  • Information and details of the security standard you adopt to govern your add-ons. We do not prescribe or mandate a security standard DSPs apply to their third-party add-ons, but recommend the Security Standard for Add-on Marketplaces (SSAM) as a baseline
  • A list detailing the third-party developers name with hyperlinks to their product or services.

The Security Standard for Add-on Marketplaces (SSAM) provides guidance for cloud based third party add-ons who integrate via API with DSPs. This standard applies to:

  • third party add-on developers with more than 1,000 connections to Australian business customers of a DSP
  • those connected to the practice client list of an Australian tax or BAS agent (practice connection). 
Last modified date