Overview

This standard governs third party software that connects to the AccountKit API. It sets the security requirements a third party developer must meet before we grant API access, the evidence we collect, and what happens when a developer no longer meets the requirements.

This standard is the counterpart to the External Providers Policy. That policy covers suppliers AccountKit buys from. This standard covers developers who connect to us and gain access to our customers' data.

AccountKit adopts the Security Standard for Add-on Marketplaces (SSAM - https://www.dspanz.org/best-practice/addon-security-standard/) as the control set for third party integrations. SSAM is an extension of the ATO's Digital Service Provider Operational Security Framework, co-developed by the ATO and DSPANZ. Where this standard sets a requirement, SSAM defines the underlying control.

A plain English summary of these requirements, written for developers, is published at https://www.account-kit.com/third-party-integration-security-requirements

Scope

This standard applies to any third party that connects to an AccountKit API, whether listed publicly, offered privately, or built by a customer firm.

It does not apply to suppliers AccountKit engages to deliver its own services. Those fall under the External Providers Policy.

Responsibilities

CEO approves or refuses every integration before API access is granted. No integration goes live without recorded approval.

Information Security maintains this standard, sets the access tier for each integration, holds the evidence, and runs the annual review.

Development issues and revokes API credentials, and enforces the granted scopes in the product.

Access Tiers

The depth of assessment follows the access being requested. Every tier carries mandatory obligations. There is no tier where assessment is skipped.

 

⚠️ Tier 1 is not low risk in regulatory terms. Access to a BAS or tax agent's client list is a named trigger for ATO add-on reporting regardless of how few records are read. Tier 1 sets the floor for assessment depth, not an exemption.

Requirements by tier

5.1 All tiers

Every integration, without exception:

• Acceptance of the Third Party Integration Security Terms, or a signed Third Party Integration Security Agreement
• A named security contact at the developer, kept current
• Access limited to the scopes needed for the stated purpose, and no more
• Annual re-attestation against SSAM
• Recorded CEO approval before credentials are issued
• Entry in the integration register

5.2 Tier 1

Completed SSAM self assessment, or

• Evidence of a completed security review by another DSP whose review is built on SSAM (Xero, Intuit, MYOB, Reckon), passed within the last 24 months
• A listing in another DSP's app store is not evidence. AccountKit accepts the completed review, sighted and dated, not the listing.

5.3 Tier 2

Tier 1 requirements, plus a documented review of:

• Authentication and API token handling, including storage and rotation
• Where customer data is held, and in which country
• Sub-processors with access to AccountKit customer data

5.4 Tier 3

Tier 2 requirements, plus:

• A current ISO 27001 certificate or SOC 2 Type II report whose scope covers the product connecting to AccountKit, or a full SSAM assessment with supporting evidence
• Summary results of a penetration test carried out in the last 12 months
• A documented risk assessment presented to the CEO before approval

A certificate is only accepted after the scope statement has been read and confirmed to cover the integrating product. The certificate alone is not evidence.

5.5 Tier 4

Tier 3 requirements, plus:

• Independent certification is mandatory, not an alternative
• Full penetration test report, not a summary
• A contractual right for AccountKit to audit, or to appoint an agreed independent auditor

Assessment and approval

Every integration is assessed using the Integrator Evaluation Checklist. The checklist records the scope requested, the tier, the evidence sighted, and the approval. A completed checklist is held for each integration.

Access is granted only after the CEO has approved and the checklist is complete.

Ongoing obligations

Change of scope. A developer seeking wider access is reassessed at the new tier before access changes.

Annual review. Every integration is reviewed each year. The review confirms the developer's assessment or certification is current, the granted scopes still match the stated purpose, and the security contact is correct.

Breach reporting. A developer must report any security incident affecting AccountKit customer data within 24 hours of detection. AccountKit reports incidents involving a third party add-on to the ATO in line with the DSP Operational Security Framework.

Failure to meet the standard

Where a developer no longer meets the requirements for its tier, AccountKit follows the remediation path set out in SSAM:

1. Written notice describing the failure
2. Up to 30 days for the developer to provide a treatment plan
3. Up to a further 60 days to complete remediation
4. Where the failure is not resolved within 90 days, API access is limited or withdrawn and any listing removed

AccountKit may suspend access immediately, without notice, where an unresolved failure puts customer data at risk.

Offboarding

When an integration ends, for any reason, AccountKit revokes credentials and the developer deletes all AccountKit customer data it holds, including backups, and confirms deletion in writing within 30 days.

Register and reporting

AccountKit maintains a register of every integration recording the developer, the tier, scopes granted, approval date, evidence held, and review due date.

Each year AccountKit provides the ATO with a list of third party developers with more than 1,000 connections to Australian business customers, or with access via API to a registered BAS or tax agent's client list.