This page explains how we handle security incidents affecting Scolah Compass Platform (“Platform”), and what you can expect from us. Our contractual notification duties for personal data breaches are in the Data Processing Addendum.
1. Shared Responsibility
| Incident affects | Who leads the response | Scolah’s role |
|---|---|---|
| Scolah’s control plane: portal, API, signing, registry | Scolah | Detect, contain, investigate, notify you |
| Scolah software running on your servers: agent, operator, Compass, a bundle we published | Scolah, working with you | Publish a fix or mitigation, give guidance, support your investigation |
| Your servers, network or accounts | You | Help on request: block servers, rotate credentials we hold, explain Platform activity logs |
| A third-party catalog application | You, with the upstream project | Publish a fixed bundle when upstream releases one; tell affected customers |
We cannot see inside your servers. If you suspect an incident there, you hold the evidence: logs, disk images and access records.
2. How to Report
- Suspected incident affecting the Platform, or Scolah software: security@scolah.com, marked “Severity 1”. This is monitored 24/7.
- Vulnerability, with no sign of exploitation: see our Vulnerability Disclosure Policy.
3. Our Process
- Detect and triage. Alerts from monitoring, reports from customers and researchers, and supplier notices are triaged by an on-call engineer. Anything that may involve unauthorised access or personal data is treated as a security incident and escalated to the incident lead.
- Contain. For example: revoke credentials, block affected servers, withdraw a bundle version from the catalog, suspend compromised accounts, rotate keys.
- Investigate. Establish what happened, when, which customers and data are affected, and how. Evidence is preserved.
- Notify. Tell affected customers, as described below.
- Recover. Restore normal service, publish fixed software, help customers rotate credentials or upgrade.
- Learn. Within 10 business days of closing a significant incident, we write a post-incident review with its root cause and the actions we will take. Affected customers receive a summary.
4. Notifying You
| Situation | When we tell you |
|---|---|
| A personal data breach involving personal data we process for you | Without undue delay, and within 48 hours of becoming aware of it |
| A security incident that requires you to act (rotate a credential, upgrade, block a server) | As soon as the action is known |
| A vulnerability in Scolah software that affects your installations, once a fix exists | Before or at public disclosure |
We notify your organisation admins by email, and by a banner in the portal. Notifications include what we know at the time, even if incomplete: the nature of the incident, data and installations affected, likely consequences, what we have done, and what you should do. We update you as we learn more.
If you are the controller of affected personal data, you remain responsible for deciding whether to notify regulators and data subjects. We will give you the information you need to do so.
5. Credentials and Key Compromise
If we have reason to think an installation credential held by the Platform may be exposed, we will tell you and help you rotate it. If the release signing key were ever compromised, we would:
- Publish a new release key and a signed procedure for moving agents and operators to it
- Withdraw affected bundle versions
- Ask every customer to re-pin the release key, and block deployments until they have
6. Testing
We rehearse our incident procedures at least once a year, and update them after every significant incident.