Incident notification policy

Introduction

→ About us

simplylogical.net (SL, we, our) is the registered business name of Sharrowlane Pty Ltd (ABN: 84 099 636 709, ACN: 099 636 709), operating from Ngunnawal Country – Unit 11, Level 3, 161 London Circuit Canberra City ACT 2601.

SL is a small, privately owned business that owns, develops, and manages 360 – Evaluation & Reporting Software and other software products (our software) that are licenced to our customers as software as a service (SaaS). SL also develops and manages SaaS products that are owned by third parties.

→ Purpose of this policy

SL is committed to providing high-quality services with confidence, value, and integrity. As such, we are committed to ensuring our software is safe to use and the information we manage is protected at all times.

This policy is the public part of our vulnerability disclosure program (VDP). The program contains internal processes and procedures.

This policy is our public statement of commitment regarding the reporting of vulnerabilities and supporting our customers in their vulnerability reporting obligations.

The scope of this policy is limited to vulnerabilities in our software. It is not to be confused with our customers’ vulnerability disclosure policies and programs.

Our action plan

We have plans that are supported by step-by-step guides that, in keeping with PSPF Policy No 11: Robust ICT systems, cover the entire system lifecycle – including implementation and monitoring.

When responding to vulnerabilities, incidents, and unplanned outages, the step-by-step guides include:

  • Assigning a cyber incident response leader
  • Steps for the leader to follow include notifying affected parties:
    • When they are to be notified
    • The level of detail to be included in the notifications.

Notification principles

Securing the system and data is the highest priority!

  • Communications may be delayed if they would exacerbate an incident.

We consider it our responsibility to ensure people who trust us with the storage of their personal and sensitive information know the information is protected in accordance with 360’s privacy statement.

In practice, in the event of an incident, we:

  1. Secure the system.
  2. Assess criticality.
  3. Seek assistance when necessary.
  4. Notify affected parties.
  5. Perform post mortems for non-trivial incidents.
  6. Keep affected parties informed.
  7. Learn and implement lessons learnt.

Notification methods

Our incident response leader is responsible for choosing the most appropriate notification methods from our suite of options:

  1. System offline – online message replaces the system portal(s).
  2. System alert – obtrusive message displayed without taking the system offline.
  3. System warning – unobtrusive message displayed without taking the system offline.
  4. Email.
  5. Phone.
  6. ACSC report.

Notification priorities

Our customers include government agencies (Commonwealth, State, and Local) and critical infrastructure entities. As such, our customers are legally required to report cyber security incidents to the ASD’s ACSC within a limited period of time – 12 hours and 72 hours depending on the nature of the incident.

Our incident response leader is responsible for notifying our affected customers as soon as possible to help them meet their reporting obligations. The criticality matrix below is used as a guide.

Our customers are responsible for meeting their reporting obligations. We will help as best we can.

→ Criticality matrix

Securing the system and data is the highest priority!

Communications may be delayed if they would exacerbate an incident.

Severity

Response

Communication
method(s)

0 – Not a concern
  • No further action
  • Email interested parties (optional)
1 – Low: Problem identified. No outage. No data leak.
  • Task(s) prioritised
  • Email interested parties (optional)
2 – Medium: Problem identified. Short (less than an hour) outage or minor data leak.
  • Regular communications
  • Post mortem
  • Task(s) prioritised

  • System warning (optional)
  • Email affected parties (expected)
  • Phone (expected)
3 – High: Problem identified. Prolonged (an hour to a day) outage or data leak of confidential material.
  • Regular communications
  • Post mortem
  • Task(s) prioritised

  • System offline (optional)
  • System warning (optional)
  • Email affected parties (expected)
  • Phone (expected)
  • ACSC report (optional)

4 – Critical: Problem identified. Protracted (more than a day) outage, data destruction, or major data leak.
  • Regular communications
  • Post mortem

  • Task(s) prioritised

  • System offline (expected)
  • System warning (optional)
  • Email affected parties (expected)
  • Phone (optional)
  • ACSC report (expected)