Incident Response Plan

← Back to the Trust Centre

1. Purpose

This plan sets out how xlabs (Pty) Ltd ("xlabs", "we") detects, contains, notifies and learns from incidents that affect Clara. It applies to Clara at getclara.co.za and its organisation sub-domains, to the databases and services that run it, and to the information organisations keep in it. Read it with the POPIA Statement and the Clara privacy policy.

2. Definitions

3. Severity levels

The incident lead sets a severity during triage and changes it as facts emerge. Severity decides how fast we act and who we tell.

4. Roles

The Information Officer is the incident lead for every incident. The incident lead:

• decides the severity and the response;
• coordinates everyone working on the incident, including service providers;
• decides when and how affected organisations and others are told;
• keeps the incident record and leads the review.

The affected organisation, as responsible party, decides whether and how to notify the Information Regulator and its data subjects. We support it throughout. For incidents on a service provider's side, we rely on that provider's own incident notification commitments, and we monitor their status pages and security notices.

5. Response phases

Each incident moves through these phases. Some run in parallel, and notification can start before containment is complete.

1. Detect. Incidents come from reports to miles@xlabs.co.za, users and organisations, our ongoing security testing, error and audit logs, and alerts from our service providers.
2. Triage. The incident lead confirms what happened, sets the severity, decides whether personal information may be involved and opens an incident record.
3. Contain. We limit the harm: for example by suspending a user, an agent, a connection or a feature, rotating keys and connection secrets, or blocking a route.
4. Eradicate. We remove the cause: fix the code, update the vulnerable component or close the gap that allowed it.
5. Recover. We restore normal service, using backups, and point-in-time recovery where it is enabled, where data was lost or damaged, and check that the fix holds.
6. Notify. We tell affected organisations what happened and what they need to do, as set out below.
7. Review. We review the incident and make changes so it does not happen again.

6. Notifying organisations

Where personal information an organisation keeps in Clara may have been compromised, xlabs, as operator, tells the organisation without undue delay. We do not wait for the investigation to finish before giving it what we know.

Our notice explains, as far as we know at the time:

• what happened and when;
• what information and which records may be affected;
• what we have done and are doing about it;
• what the organisation and its data subjects can do to protect themselves;
• who to contact for updates.

We then help the organisation notify the Information Regulator and the people affected (section 22), with the facts, records and wording it needs. We send updates as we learn more. Where xlabs is the responsible party, such as for user accounts and billing contacts, we notify the Regulator and the people affected directly.

The law may require us to delay a notice only where a public body responsible for investigating crime, or the Regulator, decides that notice would impede a criminal investigation.

7. Evidence and audit logs

Clara keeps records that help us understand an incident:

• an audit log of every change to key records, whatever made the change, with the old and new values and who or what made it;
• records of approvals, so we can see who signed off each client-facing send, payment and accounting write;
• sign-in, error and service logs from Clara and its service providers.

During an incident we preserve the relevant logs and records before making changes where we can, and record each action we take, with the time and the reason. Access to incident records is limited to the people working on the incident. Evidence is kept for as long as the review, the organisation's needs or the law require.

8. Post-incident review

After every Critical or High incident, and any incident involving personal information, the incident lead runs a review. It records:

• a timeline of what happened and what we did;
• the root cause;
• what worked and what did not;
• actions to prevent it happening again, each tracked until done.

Security weaknesses are logged and tracked in our security audit until they are fixed and the fix is verified. Where it helps, we share the outcome of the review with affected organisations. We update this plan when a review shows it should change.

9. Reporting an issue

If you think Clara has a security weakness, your account has been used without your permission, or information has gone where it should not, email miles@xlabs.co.za at once. Tell us what you saw, when, and how to reach you. Users should also tell their organisation's administrator.

Do not test or use a weakness further, or share it with anyone else. We will not act against anyone who reports a weakness in good faith.

10. Contact

Information Officer, xlabs (Pty) Ltd: Miles Marshall, CEO, miles@xlabs.co.za.
Information Regulator (South Africa): inforegulator.org.za

11. Review

We review this plan at least once a year, after any Critical incident, and whenever Clara changes materially. The version and effective date above identify the current version.