A DSP reports a data breach, a security event in which confidential taxpayer information (individual or non-individual) in its system is reasonably suspected to have been exposed to an unauthorised third party, including through fourth-party supply chains or integrated services, within one business day of identifying it, through the report data breach ticket in the DSP service desk. The initial report gives the product name, date identified, whether the issue is ongoing, the types of information affected and the approximate number of client records; forensic evidence (logs, screenshots, summaries of unauthorised changes) and technical metadata (IP addresses, session IDs, indicators of compromise) follow when available. Confidential taxpayer information includes TFNs, government ID documents, banking details, employee payroll, tax or super information and identity attributes linked to tax records. Security events without exposure of such information usually need not be reported, but if unsure the DSP reports. Failure to report a known breach may lead to de-whitelisting; reporting to the ATO does not replace notification to the OAIC under the Notifiable Data Breaches scheme. (v6.0 and v6.05 asked for immediate reporting, within a few hours, of security incidents or breaches.)
This control maps to 2 controls across 1 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
The graph holds this control, the 2 it maps to, and the evidence behind each claim, over MCP and REST.