Incident Response Plan

Table of Contents


This security incident response plan is intended to establish controls to ensure detection of security vulnerabilities and incidents, as well as quick reaction and response to security breaches.


This policy applies to all users of information systems within Social Workshop Ltd.  This typically includes employees and contractors, as well as any external parties that come into contact with systems and information controlled by Social Workshop Ltd (hereinafter referred to as “users”).  This policy must be made readily available to all users.


A key objective of Social Workshop Ltd’s Information Security Program is to focus on detecting information security weaknesses and vulnerabilities so that incidents and breaches can be prevented wherever possible.

Social Workshop Ltd is committed to protecting its employees, customers, and partners from illegal or damaging actions taken by others, either knowingly or unknowingly.  Despite this, incidents and data breaches can still happen; when they do, Social Workshop Ltd is committed to rapidly responding to them, which may include identifying, containing, investigating, resolving , and communicating information related to the breach.

This policy requires that all users report any perceived or actual information security vulnerability or incident as soon as possible using the contact mechanisms prescribed in this document.  In addition, Social Workshop Ltd must employ automated scanning and reporting mechanisms that can be used to identify possible information security vulnerabilities and incidents.  If an incident is confirmed as a breach, a set procedure must be followed to investigate, contain, resolve, and communicate information to employees, customers, partners and other stakeholders.

Within this document, the following definitions apply:

  • Information Security Vulnerability:

A vulnerability in an information system, information system security procedures, or administrative controls that could be exploited to gain unauthorized access to information or to disrupt critical processing.

  • Information Security Incident:

A suspected, attempted, successful, or imminent threat of unauthorized access, use, disclosure, breach, modification, or destruction of information; interference with information technology operations; or significant violation of information security policy.

Roles and Responsibilities

The Compliance Team will facilitate and maintain this policy and ensure all employees have reviewed and read the policy.


  • All users must report any system vulnerability, incident, or event pointing to a possible incident to the Compliance Team as quickly as possible but no later than 24 hours.
  • Incidents must be reported by sending an email message to security@socialsync.io or via official internal communication channels to the Compliance Team with details of the incident.
  • Users must be trained on the procedures for reporting information security incidents or discovered vulnerabilities, and their responsibilities to report such incidents.
  • Information and artifacts associated with security incidents (including but not limited to files, logs, and screen captures) must be preserved in the event that they need to be used as evidence of a crime.
  • All information security incidents must be responded to through the incident management procedures defined below.

Periodic Evaluation

It is important to note that the processes surrounding security incident response should be periodically reviewed and evaluated for effectiveness.  This also involves appropriate training of resources expected to respond to security incidents, as well as the training of users regarding Social Workshop Ltd expectation for them, relative to security responsibilities.

Reporting Incidents

The following situations are to be considered for information security event reporting:

  • Ineffective security control;
  • Breach of information integrity, confidentiality or availability expectations;
  • Human errors;
  • Non-compliances with policies or guidelines;
  • Breaches of physical security arrangements;
  • Uncontrolled system changes;
  • Malfunctions of software or hardware;
  • Access violations; and,
  • Malfunctions or other anomalous system behavior indicative of a security attack or actual security breach.

All incidents should be reported to the Compliance Team either via internal communication channels or via email to compliance@socialsync.io.

Establishing Incident Scope

Everything that follows in this plan is decided from the scope of a given breach, so naturally, the first stage is information gathering. It is important to collect as much detail about all aspects of the breach as possible.

If the information is coming from a third party, don’t forget to take contact details from them so you can follow up and collect more information later.

Investigation: Collect Breach Material
  • When did the event happen?
  • How was it discovered?
  • Who discovered it?
  • Have any other areas been impacted?
  • What is the scope of the compromise?
  • Does it affect operations?
  • Has the source (point of entry) of the event been discovered?


It is critical to gather and protect any and all logs which were routinely saved to log servers (such as CloudWatch Logs) during the course of business as usual (BaU).  These logs will be critical in later phases of the incident, and for lessons learned.  All information should be collected into collaborative workspaces such as a Google Doc, or other Google Drive file if that is more appropriate.

This material should be shared with the Compliance Team immediately, and then with Company Directors.

The goal of this exercise is to have all the information necessary to determine what happened, so we are able to determine how it happened in later steps.


The next most important task is to stop things getting worse.  This is achieved by reviewing the information from the scoping exercise above.  If it is not possible to contain the breach with the information currently available, go back to the previous step and collect more information until it is possible.

Containment might involve bringing core business systems offline such that data leaks cannot spread further.  In this case, action should be taken before alerting customers and other stakeholders, but would be done collaboratively with senior management after making them aware of the situation as per the scoping section above.

Think about what measures you need to take immediately, and what measures you might need to think about for future containment.  For example, turning a server off right now might be the best way to contain an ongoing data breach.  In the medium term, you might need to speak to the DevOps engineer so they can plan to harden the system when instructed to do so.  And longer term, you might plan to conduct more targeted, or more detailed penetration tests.

After making these high-level plans, make sure to initiate contact with those resources who will play a role in remediation at those longer-term stages, to make sure they are available when you need them.

If it is appropriate to do so, contact the people you spoke with in the scoping phase after you believe the incident has been contained, and confirm with them that no further breach activity is apparent to them.

By the end of this phase, the incident is not getting any worse, and everybody understands what actions need to be taken to recover the situation.


Fix-forward is a term used mainly in change management, and it describes the process of repairing the current situation, rather than rolling back to a previously known-good state.  This is appropriate in a data incident, since a rollback is not possible, so we need to move forward from where we find ourselves, and fix the problems.

  • Have compromised user accounts been disabled?
  • Have affected computer systems been quarantined?
  • Have relevant backups been restored?

After restore activities have been completed, it is critical that thorough tests are undertaken.  Use all the information gathered in the first phase of the incident to ascertain whether any threats still exist within the environment before moving on from this phase, even if it delays progress significantly.  As always, communication is the key, and progress reports should be fed back to senior management.

By the end of this phase, systems are back online, and states have been preserved for later investigation.  A lessons-learned phase follows on from this, and it will help to have a snapshot of all data assets and business resources as they were at the time of the incident.  These can be reconstructed in a “cleanroom” environment for further information gathering later.


This phase should be in tandem with the Fix-Forward phase, ideally by somebody other than those involved in the fix-forward effort.

Customers and stakeholders appreciate being made aware of incidents early.  By this stage of the plan, we know what happened, and we know what we are currently doing to resolve the situation.

As well as customers and stakeholders, it may be necessary to involve relevant authorities at this stage.  If criminal proceedings need to take place, speak to law enforcement at this stage.  Also think about any information governance bodies who may need to be made aware.  These bodies differ from region to region, and this is always at the discretion of the Company Directors.

By the end of this phase, all information which key stakeholders may need to be made aware of has been collected and passed to senior management for further action.

Lessons Learned

An occurrence of a particular incident must never be allowed to happen again, and lessons must be learned to further this endeavour.  After an incident has been resolved, a post-mortem should be conducted to include root cause analysis and documentation of any lessons learned.

This phase cannot be rushed, and should involve key stakeholders where appropriate.  Senior management should always be represented at these meetings.

  • How could the incident have been brought to the attention of Social Workshop Ltd sooner?
  • What changes need to be made to the security?
  • How should employees/contractors be trained differently?
  • What weakness did the breach exploit?
  • What could be done to limit the scope of damage caused by similar incidents?
  • How could you collect more information about such breaches to help resolve them in future?
  • How can data be better protected?
  • How will you ensure a similar breach doesn’t happen again?
  • How could future incidents be resolved more quickly?
  • What went well, and what would you change next time?

Depending on the severity of the incident, the Company Directors may elect to contact external authorities, including but not limited to law enforcement, private investigation firms, and government organizations as part of the response to the incident.

By the end of this phase, a number of actions, and importantly, deadlines for those actions, should have been agreed by stakeholders.

Revision history

VersionDateDescription of Changes
V1August 17th, 2022Initial Creation
V2August 30th, 2022Publication