Data Breach Response Plan

Our data breach response plan consists of the following steps:

1. Detection and analysis.

   Key participants: CTO and DevOps team.

   The first signs of a breach are typically seen via suspicious activity, which could include increased traffic to sensitive endpoints, increased error rates, and unexpected usage patterns. Suspicious activity can be related to customer information, accounts and related services.

   Discretion needs to be applied to determine whether suspicious activity is indeed occurring (for example, increased traffic to an authentication endpoint may be due to normal user activity). The overall objective is to determine if a breach has indeed occurred, and to assess the potential impact. The CTO should be notified if any suspicious activity is detected. The breach should be logged in the data breach register and should be updated as the remaining steps are completed.

2. Engagement of third parties for forensic analysis and legal counsel

   Key participants: CTO and DevOps team.

   We engage third parties for analysing the scope of the breach from a customer impact, legal, and infrastructure point of view. Even if it is not yet certain that the activity is indeed suspicious, it is worthwhile to engage third parties early for independent input and counsel. A Non-Disclosure Agreement should be utilised to ensure the confidentiality of discussions with third parties.

3. Containment

   Key participants: CTO and DevOps team, Customer support and communications.

   The objective of this step is to prevent continued access to breached endpoints, systems, and databases. It is important to take action quickly. Taking action could involve stopping unauthorised access, recovering records, or shutting down the system that was breached. If this is not practical, then revoke or change access privileges or address weaknesses in physical or electronic security.

   The following questions from the OAIC are useful to determine containment activities:

   1. How did the data breach occur?
   2. Is the personal information still being shared, disclosed, or lost without authorisation?
   3. Who has access to the personal information?
   4. What can be done to secure the information, or stop the unauthorised access or disclosure, and reduce the risk of harm to affected individuals?

4. Assessment

   Key participants: CTO and DevOps team, Legal Counsel, forensic analysis partner.

   In order to complete forensic analysis, the forensic analysis partner will require copies of access logs, web proxy logs, and application logs. The purpose of the analysis is to independently confirm suspicious activity, and the scope and extent of the breach.

   The output of this activity is a report that can typically be shared with privacy agencies.

   In the assessment of the breach, consider:

   1. the type or types of personal information involved in the data breach
   2. the circumstances of the data breach, including its cause and extent
   3. the nature of the harm to affected individuals, and if this harm can be removed through remedial action

5. Notification

   Key participants: CTO, Legal counsel, Partnership managers.

   A non-exhaustive list of the important agencies and typical timeframes for notification include: the ICO (UK, within 72 hours), the OAIC (Australia, within 30 days).

   Based on the assessment in the previous step, and information about the scope of the breach (such as the number of affected users in each country), legal counsel will advise which jurisdictions are affected, and which agencies need to be notified. Different jurisdictions have different criteria about when breach notifications are deemed to be compulsory. Some jurisdictions require notifications for all breaches, while others have thresholds for notification based on the number of affected customers. We err on the side of transparency and notify agencies if there’s any room for doubt. Legal counsel will help draft responses to agencies for internal feedback before they are submitted.

   Partners are also notified about the nature and the impact of the breach. Partners may request to review draft versions of filings to agencies before they are submitted.

   Affected customers are notified about the breach, and any steps that need to be taken. During containment, for example, passwords may have been reset, and customers should receive instructions about what actions they would need to take.

   Based on the assessment, scope, and scale of the breach, law enforcement in the relevant jurisdictions may need to be notified.

6. Review

   Key participants: CTO, DevOps team, development team.

   Based on the findings of the forensic analysis, the objective of a review is to:

   1. Identify any temporary or permanent mitigation that may be required
   2. Updates to, or the creation of new policies related to the breach
   3. Evaluate the need for the introduction of new tools to prevent future attacks
   4. Evaluate the need for training and personnel
   5. Schedule periodic audits to ensure that the underlying issue is addressed
   6. Review the root cause of the breach

7. Complete responses to agencies

   Key participants: CTO, DevOps team, Legal counsel

   If the previous steps are completed appropriately, notified agencies may or may not require further action. If further action is required, these requests will need to be addressed to the satisfaction of the agency. Legal counsel will assist with further responses. Once all actions are completed, the case can be marked as closed in the data breach registry.

For more information, please contact us by sending an email to dpo@3plearning.com.