Incident response procedure

The person who spots the issue raises it at once and opens an incident record. The record starts with what was seen, when, by whom and how. It is kept factual.

The aim is to stop the damage before investigating further.

1. 1Replace any exposed credential at the provider that issued it, in order of risk, then update every running service that depends on it and confirm the services are healthy.
2. 2Remove the source of the leak: delete the document or message, and revoke any shared link.
3. 3If a user account may be compromised, reset its credentials, end its active sessions and revoke its connected-account permissions. We do this before contacting the account holder, in case the account is in someone else's hands.

Once the incident is contained, we work out what happened. For each affected credential or system we answer:

• Where else might the credential have existed?
• What did it give access to, and what could someone have done with it?
• When was it first exposed, and could it have been used before we noticed?
• What evidence of misuse do we have, from provider audit records, our own logs and usage patterns?
• How sure are we of each answer: known, suspected or unknown?

The incident record is updated as the answers arrive. It lists which customers, if any, are affected.

If no customer is affected, no customer notification is needed, but the review in step 6 still happens.

If a customer is affected, even potentially:

• 24hours

  We notify the customer's nominated security contact without undue delay and in any event within 24 hours of confirming that the incident affects their personal data.

• The notification includes, as far as it is known: what happened, which data and approximately how many people or records are affected, the likely consequences, what we have done and will do, what the customer should do on their side, and a named contact.

• 5working days10working days

  We deliver a root-cause analysis within 5 working days of notification, and a written incident report within 10 working days. The report covers what happened, what was affected, what we have changed to prevent it happening again, and what, if anything, the customer should do.

• 72hours

  Where personal data is involved, the customer is the data controller and decides whether to notify its regulator, which under UK GDPR is within 72 hours of becoming aware. We give the customer's team the information it needs to do that.

When CogniScale itself holds the personal data (for example, enquiries made through our website, or our own sales and marketing contacts), CogniScale is the data controller. We then report the breach to the Information Commissioner's Office within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to people's rights and freedoms, and we tell the people affected without undue delay when the risk to them is high. The incident commander decides, and the incident record says why.

We return affected services to a known-good state and confirm they are healthy. Where a credential was replaced, we confirm that the old one no longer works. Where data must be restored, we restore from our encrypted backups, as described in the Backup and Recovery Statement. When the cause was a vulnerability, we add a test that would have caught it before release.

After every incident we hold a blameless review. It produces a written account covering the timeline, what worked, what failed, and a list of actions, each with an owner and a date. If the incident exposed a gap in a policy or procedure, we change it. The review is not finished until that change is made.