Skip to main content
DraftIndicative placeholder for the section owner — amend, replace, or confirm as the first definitive version.

Doc owner: TBD

Incident Response Plan

Seeded from legacy Allied Information Security Policy (incidents and issues section). Content carried over for review. Severity classification, escalation matrix, customer notification SLAs, and integration with BCP/DR all need verification against current Allied operations.

Purpose​

To ensure information security incidents are detected, reported, contained, eradicated, and learned from.

Scope​

Applies to all Allied systems, data, and staff; covers both confirmed incidents and credible suspicions.

Roles and responsibilities​

RoleResponsibility
Security OfficerCoordinates incident response, leads initial fact finding, and runs the post-incident review
CEONotified of incidents; engaged where blameworthy malice/negligence is suspected
All staffReport suspected incidents promptly

Reporting security issues​

If you are unsure whether something might be a security issue, report it. Confirmed and suspected security issues must be reported to the Allied security officer at the earliest opportunity to enable damage limitation and risk mitigation processes to be put in place as fast as possible.

Security issues involve either the actual breach of the confidentiality, integrity or availability of an Allied information asset, or the discovery of a technical, procedural or other weakness which could realistically allow such a breach. Issues include, but are not limited to:

  • Loss of hardware.
  • Loss of any hard copies of passwords.
  • Successful/attempted logons by unauthorised users.
  • Detection of a virus/malware.
  • Mishandling of protectively marked data (Allied, Government or Third Party).
  • Emailing something to the wrong person.
  • Detection, or suspicion, of any compromised passwords (e.g. notification by password management solutions).
  • Notification of compromise by software/service provider.

Immediate action​

Relevant steps from the following list (as determined by the security officer) taken in sequential order:

  1. Inform the Allied security officer.
  2. Jointly perform initial incident characterisation.
  3. Device sanitisation:
    • Affected devices disconnected from the internet (hardware AND software switches/connections).
    • Full antivirus scans run. Disinfect as prompted.
    • Devices restarted.
    • Reconnect to the internet.
  4. All affected users change all affected passwords (guidance provided by the security officer).
  5. Inform CEO.
  6. Information audit:
    • Cloud access permissions and activity reviewed to identify any unauthorised activity/users. Contact cloud provider if there is any suspicion of information loss/manipulation.
    • Productivity tools access permissions and activity reviewed. Contact tool provider if there is any suspicion of information loss/manipulation.
    • Affected users verify email accounts to detect unauthorised access.
  7. In accordance with GDPR, notify any affected parties whose details might have been compromised. If a breach refers to the data or system of a customer, we usually have 24 hours to report it to the customer.
  8. Conduct post incident review.

Post-incident review​

If things go wrong, we will seek to understand why, rather than defaulting to blaming poor performance. Critique of practice is fundamental to the success of no-blame cultures because it allows processes to be effectively understood, deconstructed and put back together in better ways. Debriefs help ascertain what went wrong and what should be changed in future, and ensure everyone is on the same page.

The post incident review process takes place as follows:

  1. Initial fact finding by the Allied security officer with all relevant personnel. Balance-of-probability judgements employed by the security officer to determine the facts, minimising reliance on assumption as far as is reasonably possible.
  2. Consolidation of a short summary identifying underlying causes, drivers and impact, retained as a record. At this stage, if blameworthy malice/negligence is suspected on the part of an Allied employee, the CEO will be notified. (The threshold for designating behaviour as negligent must remain high in order to maximise voluntary engagement with good security practice.)
  3. Sharing of that information with all Allied personnel as part of the next suitable all-staff meeting.
  4. Review and adaptation of policy and practice if and as required, including effectiveness of immediate action and post-incident review processes.
  5. Review effectiveness of any new processes resulting from incident review.

Policy statements​

TBD — gap analysis to add: severity classification (e.g. P1–P4) and SLAs, on-call rotation, customer-notification template and contractual SLAs, regulator notification (ICO 72-hour rule), war-room communication channels, integration with POL-ENT-007 Business Continuity Plan and POL-DIG-012 Disaster Recovery Plan.