Security Incident Policy (customer-shareable)¶

✓ This document is safe to share with customers, partners, regulators under NDA, and prospective auditors. Internal forensic detail (specific tooling commands, log query syntax, contact rosters) lives in the operational runbook at docs/runbooks/ and per-incident post-mortems at docs/security/internal/post-mortems/.

Scope: this document describes how the Evospin team handles a security event from detection through customer notification — privacy breaches, data exfiltration, credential leakage, etc. The Critical/High/Medium/Low rubric below applies to external disclosure SLAs only. For operational incident response (production outages, performance regressions, queue stalls), use the on-call runbook at ../handover/oncall-runbook.md which uses a separate P0/P1/P2/P3 scheme.

This runbook describes how the Evospin team handles a security event from detection through customer notification. It is intentionally written at the level of detail a customer needs to evaluate our process — detailed enough to demonstrate maturity, abstract enough to remain durable across personnel and tooling changes.

1. Detection¶

We detect potential security events through six channels, listed by descending typical signal-to-noise ratio:

Automated monitoring — Prometheus / Sentry / Loki alert rules covering authentication anomalies, balance-integrity invariants, error-rate spikes on hot endpoints, and unexpected privilege transitions.
Routine audits — periodic external penetration tests and internal code-review passes documented in our findings register.
Dependency advisories — GitHub Security Advisories for our direct and transitive dependencies, surfaced via continuous dependency-audit jobs in CI.
Customer reports — issues raised through the support channel; security-relevant tickets are escalated within one business day.
External researcher reports — emails to {{TBD: security@ebit.example}}; we acknowledge within one business day.
Operator observation — admin-panel users escalating via our internal escalation channel.

2. Reporting channel¶

Email. {{TBD: security@ebit.example}}

PGP key. {{TBD: published key fingerprint and link.}}

Subject-line convention. "Security report — ". Clear, neutral subject lines help us route quickly.

What to include. - A description of the issue and its expected impact. - Steps to reproduce, if known. - Whether the issue is being actively exploited in the wild. - Whether you require a coordinated disclosure timeline.

Acknowledgement SLA. One business day from receipt of the report. We will reply with a tracking ID and an initial severity assessment.

Bug bounty. {{TBD: confirm policy.}} If a formal bounty program exists, the reporter will be directed to its terms in the acknowledgement reply.

Safe-harbor. Researchers acting in good faith — no destructive testing, no exfiltration, no public disclosure before our resolution window — will not be subject to legal action by Evospin. This commitment is provisional pending publication of a full safe-harbor policy.

3. Triage SLA¶

Within one business day of report we assign a severity and begin work. The severity classification follows the same rubric as our internal risk register:

Severity	Triage start	Mitigation target	Permanent fix target	Notification target
Critical	Within 4 hours	24 hours	7 days	Within 24 h of confirmed exploitation, or within 72 h of confirmed exposure
High	Within 1 business day	5 business days	30 days	Within 5 business days if customer data affected
Medium	Within 2 business days	30 days	90 days	Aggregated in periodic transparency report
Low	Within 5 business days	Best effort	Best effort	Aggregated

"Mitigation" means a control (rate-limit, feature flag, traffic block, configuration change) that materially reduces the risk while a permanent fix is developed. "Permanent fix" means the underlying defect is removed.

4. Resolution flow¶

┌──────┐   ┌────────┐   ┌──────────┐   ┌─────────┐   ┌──────────┐   ┌─────────┐
│Report│──▶│Triage &│──▶│Reproduce │──▶│Mitigate │──▶│Permanent │──▶│Verify & │
│      │   │assign  │   │& assess  │   │(if      │   │fix       │   │close    │
│      │   │severity│   │impact    │   │needed)  │   │          │   │         │
└──────┘   └────────┘   └──────────┘   └─────────┘   └──────────┘   └─────────┘
                              │             │             │
                              ▼             ▼             ▼
                        ┌──────────────────────────────────────┐
                        │ Customer-notification decision point │
                        └──────────────────────────────────────┘

4.1 Triage and assignment¶

A security on-call engineer is assigned. They confirm the report (or close it as a duplicate / out-of-scope / non-issue), set a severity, and open an internal tracking ticket.

4.2 Reproduction and impact assessment¶

We reproduce the issue in a non-production environment whenever possible, determine the affected user-set or data-set, and document the assessment. If the issue is being actively exploited, we begin mitigation in parallel rather than waiting for a complete assessment.

4.3 Mitigation¶

A short-term control is rolled out to reduce risk while the permanent fix is developed. Examples: feature-flag a vulnerable endpoint off, deploy a WAF rule, rotate a credential, or disable a specific code path.

4.4 Permanent fix¶

Engineering develops, tests, and deploys a permanent fix. Every fix lands behind:

Code review by a second engineer.
Automated test that pins the fix (the test fails on a regression).
Where applicable, a runtime invariant (constraint, guard, schema check).

4.5 Verification and close¶

The fix is verified in production via the test that pins the fix, plus targeted observability checks. The internal tracking ticket is closed with a verification note. The corresponding entry in the customer-shareable risk register transitions to Mitigated.

4.6 Post-mortem¶

For Critical and High incidents, a post-mortem doc is produced within 10 business days of resolution. The post-mortem documents the timeline, root cause, impact, lessons, and a list of tracked action items. Post-mortems are internal; abridged summaries are shared with affected customers on request.

5. Customer notification policy¶

We notify affected customers when one or more of the following is true:

Confirmed exposure of customer data — we always notify, regardless of severity.
Confirmed financial impact to a customer's account — we always notify the affected customer.
Critical or High issue for which we believe a reasonable customer would want to know, even absent confirmed exposure (e.g. credential leak with unclear blast radius).
Regulatory notification triggered — we notify alongside the regulatory filing.

What a notification contains¶

A non-technical summary of what happened.
A statement of what data, if any, was exposed.
The actions we have taken.
The actions, if any, we recommend the customer take.
A point of contact for follow-up questions.
The expected timing of any further updates.

Channels¶

Email to the account contact on file.
In-product banner for issues affecting active sessions.
Status page — {{TBD: confirm URL}} — for issues affecting service availability.
Direct call for material incidents affecting enterprise customers, in addition to written notice.

Timing¶

Critical with confirmed exposure: within 24 hours.
Critical with no confirmed exposure but plausible: within 72 hours.
High with customer-data impact: within 5 business days.
Other: aggregated in a periodic transparency report (cadence: {{TBD}}).

Regulatory filings¶

We comply with notification obligations applicable to the jurisdictions in which we operate. Where required, we file with the relevant authority within the legal window (typically 72 hours from confirmed personal-data breach in jurisdictions following GDPR-style frameworks). The compliance team owns the filing process and operates from the contact roster maintained internally.

6. Post-incident review¶

Every Critical or High incident is reviewed in a blameless post-mortem within 10 business days of resolution. Reviews cover:

Timeline of events.
Root cause and contributing factors.
Effectiveness of detection: was the issue caught early enough?
Effectiveness of response: did the runbook work?
Action items: what changes will we make to prevent or detect this class of issue earlier?

Action items are tracked in our internal register and revisited monthly until closed.

7. For deeper detail¶

The following documents are not customer-shareable and contain the operational specifics that this runbook abstracts. They are referenced here only for completeness:

Internal full-detail findings: docs/security/internal/findings.md
Internal threat model: docs/security/internal/threat-model.md
Past incidents and post-mortems: docs/security/internal/incident-history.md
Operational runbooks: docs/runbooks/

If you are a customer or partner who needs more detail than this runbook provides, please contact us via the reporting channel above and we will discuss what we can share under NDA.

8. Versioning and review¶

This runbook is reviewed quarterly. The current owner is the security on-call lead. Substantive changes — new channels, changed SLA targets, changed severity definitions — are version-bumped under the doc-version system and announced to subscribed customers via the standard customer-comms channel.

Last reviewed. {{TBD: review-date}} Next review. {{TBD: review-date + 3 months}} Owner. {{TBD: name / role}}