Manage and Report Security Incidents

The purpose of predefined security incident response plans is to quickly and effectively respond to attempted or actual security breaches. It’s the last line of defense activity that works like a seatbelt - you hope you don’t need it but it may save you when you do. 


The Consumer Data Right gives Australian’s control of their data. That enables innovation in new products and services to those consumers. To participate as a data recipient, there are five governance requirements and 24 information security requirements. These are independently audited by a qualified firm like AssuranceLab, and included in an assurance report for accreditation. The capability to manage and report security incidents is one of the five governance requirements in Schedule 2, Part 1. 


Security incidents can arise from exploited vulnerabilities, access control failures, deliberate or accidental data leakage. The prevention of these is covered in the respective practices of a Vulnerability Management Program, Access Control Policy, and Data Loss Prevention practices. These topics themselves are broad, with various types of risks and threats that may cause these incidents. There are three main types of security incidents that should be considered in defining the management and response; 


  1. System security breach 

System security breaches occur when unauthorised users are able to access systems that they shouldn’t. This may be from technical vulnerabilities or access control failures. The average system security breach is identified almost 365 days after they occur! These breaches may not give access to sensitive data or resources immediately or even at all. The longer they go without identification, the higher the risk of sensitive assets being exploited. This may be a ransomware attack, getting access to valuable data and exploiting that for gain, or other malicious activity designed to damage your company’s operations or reputation. 


  1. Major disruption 

Major disruptions are a type of security incident that is often overlooked or not considered to have direct security implications. Any major disruption to your systems or even business processes can have security implications by disrupting your usual system protections. Whether that’s a distributed denial-of-service attack, a failure in critical third-party services you rely on, or a major operational event that disrupts your usual business practices. These can leave your company, systems, and data vulnerable. These major disruption incidents are sometimes covered in the Business Continuity Plan rather than a Security Incident Response Plan. In either case, security implications including ensuring the continuity of your security practices, should be considered. 


  1. Data breach 

A data breach may happen directly or as a consequence of the above two types of security incidents. It can also happen directly with data leakage that may be accidental or deliberate. Many security incidents have an internal component. That means your technical vulnerability management and access control may both be effective but authorised personnel with data access can deliberately or accidentally leak that data outside the organisation.

Whichever type of security incident occurs, the purpose of the response plan is to first contain or mitigate the impact as soon as possible, then seek to "resolve" it the best way possible. In some cases, the damage can’t be undone but that resolution may be to notify your customers and other stakeholders of what’s occurred and implement safeguards to prevent it from happening again. 


The security incident response plan should help ensure you’re as well prepared as you can be for these events. Part of that is testing the plans either through simulation, live tests, or just a desk-based run-through. There are usually many assumptions built into response plans like the availability of staff, communication lists, operability of systems, etc. These assumptions may not hold up in some of these incident scenarios or may too long to enact. The types of information included in the Security Incident Response plans usually include:

  • Roles and responsibilities 
  • An allocated incident response team and contacts
  • Types of security incidents that may occur 
  • When to, or who can enact the response plans
  • Key stakeholders and contact information (third party service providers, customers, Senior mgt, Board, PR contacts) 
  • Approved Communication channels and distribution lists 
  • Response steps and considerations 
  • Mitigation strategies
  • Compliance requirements (eg. notifying the regulators, customers within X period)
  • Post-incident review requirements for “lessons learned”
  • Plan testing and update practices
  • Linkages to other related documents and processes like the Business Continuity Plan, Incident Management Policy, and Disaster Recovery Plan
  • Templates and defined processes for reporting security incidents to the relevant authorities and impacted customers/users

If you're wondering what this looks like "on paper" - get in touch with our team <>. We're happy to share examples and guide you through how this may look for your business.


The CDR Perspective


The CDR Schedule 2, Part 1 requires the following in relation to managing and reporting security incidents:

  • (1) An accredited data recipient must have procedures and practices in place to detect, record, and respond to information security incidents as soon as practicable.
  • (2) The accredited data recipient must create and maintain plans to respond to information security incidents that it considers could plausibly occur (CDR data security response plans).
  • (3) The accredited data recipient’s CDR data security response plans must include procedures for:
    • (a) managing all relevant stages of an incident, from detection to post-incident review; and
    • (b) notifying CDR data security breaches to the Information Commissioner and to CDR consumers as required under Part IIIC of the Privacy Act 1988; and
    • (c) notifying information security incidents to the Australian Cyber Security Centre as soon as practicable and in any case no later than 30 days after the accredited data recipient becomes aware of the security incident.
  • (4) The accredited data recipient must review and test its CDR data security response plans:
    • (a) when there is a material change to the nature and extent of threats to its CDR data environment or to the boundaries of its CDR data environment— as soon as practicable; and
    • (b) where no such material changes occur—at least annually.
  • (5) In this clause: the Australian Cyber Security Centre means the cybersecurity function within the Australian Signals Directorate.

About AssuranceLab


AssuranceLab is a modern cybersecurity audit firm that issues assurance reports (ASAE 3150, SOC 1/2). We're experts in the latest software and cloud providers. We guide your team through the compliance practices in a way that fits your environment and culture. We work closely with clients through our agile and collaborative approach; saving time, costs, and headaches along the way.

Some additional information in one line