Incident Response
How Parascope classifies security incidents, the response times one operator commits to, the containment that runs as a single command, and when you get notified.
This page sets out what Parascope treats as a security incident, how quickly a response starts, and what you are told once it does. The response times below are sized for a company with one operator. They are slower than the numbers a staffed team publishes, and they are written down here because a commitment that gets met is worth more to your review than one that reads well.
Severity levels
| Severity | What it covers | Examples |
|---|---|---|
| SEV-1 (Critical) | An active data breach, a failure of isolation between tenants, or compromise of the control plane | One tenant can read another tenant's data; an attacker holds cluster administrator access |
| SEV-2 (High) | Credential exposure, one tenant's data at risk, or a compromised dependency reaching the build | An API key found in a public repository; a malicious package detected in a dependency |
| SEV-3 (Medium) | A security control that failed to do its job, a misconfiguration found, or a brute-force attempt | A network policy not enforcing what it should; an unusual login pattern |
| SEV-4 (Low) | A hardening gap or a security improvement worth making | A missing security header; a dependency carrying a low-severity CVE |
Severity follows from the impact of the incident. A researcher's disclosure, a customer email, and an automated alert are classified against the same table.
The response times we commit to
| Severity | Response starts within |
|---|---|
| SEV-1 | 1 hour |
| SEV-2 | 4 hours |
| SEV-3 | Next business day |
| SEV-4 | Scheduled into the remediation backlog |
"Response starts" means triage begins, the blast radius is scoped, and containment follows from what triage finds. It is not a resolution time. How long a fix takes depends on the incident, and the post-incident report is where that timeline is written down.
The clock starts when the operator becomes aware. Detection is automated and continuous, and alerts reach the operator by email and push notification at any hour, so an overnight SEV-1 can be picked up before morning. There is no rotation and no second person to page, so treat out-of-hours pickup as best effort. The commitment is the table.
Faster targets exist on paper. A 15-minute SEV-1 response, a one-hour SEV-2, and a separate incident commander coordinating the response are the plan for when a second operator joins and an on-call rotation exists. They are not in force today, and this page does not offer them. What compensates in the meantime is the containment in the next section, which is automated because the human response is slower.
Containment that runs as a command
The containment actions worth automating are the ones that need to happen before an investigation finishes. Three exist today, each reachable as a single control-plane operation.
Tenant suspension. One control-plane command revokes a tenant's messaging account and puts its API into read-only mode. Every client authenticating as that tenant loses its connection, including the cloud collectors and any appliance running inside your network, so incoming data stops at the boundary. On the API side, mutating requests return 403 while reads and health checks carry on. The action reverses when the incident is closed, and reactivation restores writes.
Credential rotation and revocation. Database passwords, messaging credentials, and the collector API key rotate on a schedule and can also be rotated on demand from the control plane. The API-key rotation mints the replacement, restarts the workloads onto it, and revokes the old key last, so rotation under pressure does not require an outage. Individual API tokens and service keys revoke immediately and stop working on the next request that presents them.
Appliance credential revocation. An appliance's messaging credentials can be revoked one appliance at a time, leaving other appliances in the same tenant connected. An appliance reaches the platform only over that messaging connection, which carries both its data and its management traffic, so revoking those credentials closes both paths in one action. Tenant Isolation Architecture describes that connection.
Decommissioning an appliance in the interface marks it retired in the platform's records. Cutting its credentials is the separate command above, and that is the one an incident response reaches for.
What you get told, and when
Affected tenants are notified. For an incident that exposed data, notification is mandatory.
Personal data breaches carry a 72-hour clock. Parascope acts as a processor for the data you put in it. Under the data processing agreement we offer, which is currently in legal review, a personal data breach is reported to you without undue delay and no later than 72 hours after we become aware of it, which is the window Article 33(2) of the GDPR sets for a processor notifying a controller. The notification covers the nature of the breach, the categories and approximate number of data subjects affected, the likely consequences, and the measures taken or proposed. Your own notification to a supervisory authority runs on its own 72-hour clock, and this commitment is sized so that clock is not spent waiting on us.
SEV-1 and SEV-2 get a written report within a week. The report is blameless and covers the timeline, the root cause, the impact, and the follow-up actions that came out of it. Affected tenants receive it. One week is the honest figure for a single operator who has just finished remediating the incident.
Platform incidents are posted publicly. The status page carries incidents as they happen, and closed incidents stay published. Availability, Backups and Disaster Recovery covers the status page and the recovery targets the platform is designed against.
What this does not cover
No staffed on-call rotation. Monitoring is continuous. Human response happens in working hours, and out-of-hours pickup is best effort. Availability, Backups and Disaster Recovery states the same thing from the availability side, and it is the fact that shapes the numbers on this page.
No incident commander. Triage, containment, investigation, recovery, and the write-up are done by the same person, so the coordination role a larger team separates out does not exist here.
Suspension does not freeze everything inside the tenant. The read-only lock described above is narrow but it is not total: scheduled maintenance jobs in the tenant namespace keep running, and a small set of write-shaped requests that are reads in substance (the query endpoint) or per-user preferences (notifications, watching a configuration item) remain allowed.
No published response or recovery averages. There is no incident history long enough to compute a meaningful average from, so the figures on this page are commitments. What has happened is on the status page, where you can read it without asking us.
Verify it yourself
- Read the incident history. parascope.instatus.com publishes incidents and keeps the closed ones, so you can see how past incidents were communicated and how long they ran.
- Test the reporting path. The Vulnerability Disclosure Policy publishes its own response table: acknowledgment within 2 business days, triage within 5, a fix timeline communicated within 10. Sending a report to [email protected] is the cheapest way to find out whether those hold.
- Read the breach clause in contract language. Ask [email protected] for the data processing agreement, which is in legal review today. Its breach notification section is where the 72-hour commitment above is written down.
- Check the recovery side. Availability, Backups and Disaster Recovery covers backups, what the weekly verification job proves, and the recovery targets.
- Controls with their own verify pointers are listed in the control matrix.
Availability, Backups and Disaster Recovery
The availability target and how it is defined, the three backup layers and what is kept, what the weekly verification job proves, and the recovery targets the platform is designed against.
AI Features and Your Data
The two Parascope surfaces that call a language model, what text reaches the provider on each, where it goes, how long it is kept, and how model output is gated before anything acts on it.