Incident Response

How Sparcle responds to software-vendor-side incidents.

Sparcle ships software that runs in customer infrastructure. Most security incidents that affect customer-owned data are customer-side, and the customer's incident response runs the response. This page describes software-vendor-side incident response: how Sparcle detects, triages, mitigates, and communicates incidents in the code, releases, and delivery infrastructure Sparcle itself controls (a CVE in a shipped Bolt or Aeira release, a cosign signing-key compromise, a sub-processor breach in our delivery chain). The customer notification SLAs that bind Sparcle contractually are codified in the executed MSA, BAA, or DPA.

Contact security Back to Trust Center

The framework

Five phases.

The same shape the major incident-response frameworks (NIST SP 800-61, ISO 27035, FIRST) prescribe, sized to a software vendor that ships into customer infrastructure rather than operating customer data plane.

1. Detect

We discover an event via monitoring (Prometheus alerts on bolt-api and Aeira components), customer report, vendor advisory feed, or vulnerability disclosure.
2. Triage

The responding engineer classifies severity (SEV1 to SEV4), assigns an incident lead, and opens a private incident channel and incident ticket. Acknowledgement to the customer (or, for public-facing issues, the reporter) happens within the target acknowledgement window for that severity.
3. Stabilize

We contain the issue with the shortest path to reducing customer impact, even if that is a partial mitigation. Permanent fixes follow stabilization, not the other way around.
4. Mitigate

Engineering ships and verifies the fix in a controlled rollout, with customer-specific guidance where the fix requires a customer-side action (Helm chart upgrade, configuration change, key rotation).
5. Validate and communicate

We confirm closure with telemetry and, for customer-impacting incidents, with the affected customer. Public post-incident review follows for any incident that required customer notification.

Severity classification

Acknowledgement and patch targets.

Severity is assigned by the responding engineer at triage and is the input to our notification cadence. Severity can be downgraded or upgraded as the incident evolves; every change is recorded in the audit chain. Patch SLAs match the Vulnerability Disclosure Policy.

Severity

Definition

Acknowledgement + patch target

SEV1

Critical: actively exploited vulnerability in a current Bolt or Aeira release; compromise of the cosign signing key or build pipeline; sub-processor breach with customer-data implications.

Acknowledgement within 1 business day. Patch shipped within the Critical SLA (7 days per the VDP).

SEV2

High: confirmed exploitable vulnerability in a current release without active exploitation; high-severity CVE in a deployed dependency with no workaround.

Acknowledgement within 1 business day. Patch shipped within the High SLA (30 days per the VDP).

SEV3

Medium: vulnerability with an available workaround; sub-processor incident without customer-data impact; documentation security gap.

Acknowledgement within 3 business days. Patch shipped within the Medium SLA (90 days).

SEV4

Low: minor issue in a non-current release; cosmetic issues; advisory items without exploitability.

Acknowledgement within the next quarterly release window.

Customer notification

When and how we notify.

Notification timing is a function of the regulatory regime governing the data, the contract executed with the customer, and the operational reality of the incident. The table below summarizes the floor; specific MSA, BAA, or DPA terms may be tighter.

Scenario

Notification commitment

Vendor-shipped CVE in a current Bolt or Aeira release

Customer advisory plus patched release within the patch SLA (Critical 7 days, High 30 days, Medium 90 days, Low next quarterly release). CVE assigned where appropriate. Advisory mailing list receives notification out of band; coordinated disclosure timing follows the VDP.

Cosign signing-key or build-pipeline compromise

Public advisory and key revocation within 24 hours of confirmation. Customer-side rebuild and re-pull guidance ships with the advisory.

Sub-processor breach affecting Sparcle's delivery chain (source-code host, signing transparency log, etc.)

Notification to affected customers within 24 hours of confirmation. Sub-Processor Disclosure updated within 30 days per the standard change-notice timeline.

Contractual notification to a specific customer

Within the SLA defined in the executed MSA or order form. Default for vendor-side incidents affecting the customer's environment is 72 hours.

HIPAA or GDPR breach-notification clauses in the executed BAA or DPA

Where the executed contract binds Sparcle to HIPAA breach notification (60 days per 45 CFR 164.404) or GDPR breach notification (72 hours per Art. 33) for incidents Sparcle is the trigger for, those clauses govern. Customer-side incidents in the customer's own deployment fall under the customer's own BAAs and DPAs with their LLM, cloud, and IdP providers, not Sparcle's.

Communication channels

Where you hear from us during an incident.

Customer security contact on file

The email address you provide on the executed MSA or DPA is the primary notification channel during a customer-affecting incident. Keep it current. We recommend a shared inbox monitored by your security team rather than an individual.

Public security advisories

Software-defect advisories are published with the patched release, including CVE assignment where appropriate, affected version range, severity, and mitigation guidance. Customers on our advisory mailing list receive these out of band.

Post-incident review

For any incident requiring customer notification, we publish a post-incident review covering root cause, customer impact, what worked, what did not, and the changes we are making. PIRs are shared with affected customers directly and, where appropriate, published publicly.

Honest framing

What this framework is, and what it is not.

Operating model today

Sparcle's security program is run by the founding team. The acknowledgement and patch SLAs above are the binding commitments; an executed MSA, BAA, or DPA defines the cadence Sparcle runs for that customer and takes precedence over this page. Deeper coverage tiers (paged on-call, dedicated security engineer, 24/7 staffing) activate in lockstep with the customer contracts that require them, per the maturation path above.

What ships in the box today

A documented five-phase response plan; a written runbook the responding engineer follows; the Vulnerability Disclosure Policy's patch SLAs as binding commitments; audit-chain evidence on every admin action taken during a response; a sub-processor disclosure with a 30-day change-notice window for customers; and a tamper-evident Merkle-sealed audit chain that customers can independently verify.

What activates with scale

A 24/7 staffed security operations center, a formal CSIRT charter, a paged on-call rotation, and a third-party-attested incident-response certification activate at the customer-contract thresholds that warrant them. The SLAs on this page remain the binding floor at every stage; tighter contractual figures take precedence.

Sparcle does not host your data

In the production deployment topology, customer data lives in the customer's infrastructure. Most security incidents that affect customer-owned data are incidents the customer responds to, not Sparcle. Sparcle's role is software-vendor-side: ship advisories, ship patches, and support the customer's response.

Maturation path

How the security program grows with the customer relationship.

Sparcle's security program is staged to match the customer relationship. The commitments below activate at each phase; subsequent phases add commitments without regressing prior ones. The acknowledgement and patch SLAs published on this page are the binding floor at every stage. The executed contract for that phase is what governs.

Design-partner stage (pre-pilot)

Founder-led security response within 1 business day during business hours. Joint threat-model session and architecture review under mutual NDA. Sub-processor disclosure and DPA template shared for customer counsel review. Vulnerability reports go to founder-led triage. The customer's input directly informs the security roadmap; no formal SLA beyond the acknowledgement targets on this page.

Pilot stage (executed pilot agreement)

Acknowledgement and notification cadence tightens to match the executed pilot agreement. Named primary security contact at Sparcle (founder-level), available during pilot hours. Joint deployment runbook produced for the customer's environment. For AWS or Vault deployments, a Day-1 customer-side KMS conformance run is part of the pilot kickoff. Sub-processor change notifications begin at signature. Pilot post-mortem at conclusion includes any security-program gaps surfaced for closure before production.

Post-deployment (production contract)

Contractual MSA, BAA, or DPA cadence governs all notification timelines and overrides any general statement on this page. Dedicated security engineer hired at the engagement threshold defined in the executed contract. Paged on-call rotation added in proportion to production stakes; SEV1 acknowledgement window shortens to the contractual figure. Annual third-party penetration test. SOC 2 Type I (Q4 2026 target) followed by Type II (Q2 2027 target). Sub-processor onboarding gated by customer approval per the executed DPA.

Past incidents

None to disclose.

No production incidents involving customer data have occurred. Internal-only events (build-pipeline regressions, development-environment issues) are tracked separately and do not appear here. This section will be backfilled with summarized public post-incident reviews if a customer-impacting incident occurs in the future, and remains the place to look for that history.

Questions about how this would work with your environment?

Framework version 0.2. The deeper runbook is shared under NDA during pilot evaluation.

Schedule review [email protected]