Incident Response

Version 1.0, approved 2026-09-21. The detection and paging described here is what is built and tested; the rota is the one recorded in eScryber's operations records. The notification windows below are commitments as of this version.

What counts as an incident

• Security incident: unauthorised access to, disclosure of, alteration of, or loss of customer data; a broken audit chain; a compromised credential or key; a vulnerability being exploited.
• Availability incident: the service, or signing specifically, unavailable or materially degraded beyond a few minutes; a background worker dead or a queue stalled; data not being delivered (email acceptance below threshold).
• Integrity incident: a completed document or certificate that does not match its recorded hash; a storage object claimed by more than one organisation.

How incidents are detected

Automatically, every five minutes, from the database rather than from the process claiming to be fine: worker heartbeats, queue age, the daily audit-chain verification, the nonprofit-verification backlog, stuck billing events, exhausted outbox deliveries, and email acceptance rate. Each condition pages or warns the on-call person once, escalates once if unacknowledged, and resolves once. External synthetic checks probe readiness and refusal behaviour from outside the deployment. And by report: security@escryber.com is read by the on-call person.

Who responds

Role	Primary	Backup	Hours
On-call / incident lead	Rodrigo Jimenez	Jerry Wilson	Monday–Friday, 7am–5pm US Central; pages outside these hours are answered on the next covered morning; no out-of-hours response is committed
Customer communication	Jerry Wilson	Rodrigo Jimenez
Security decisions (rotation, isolation)	Rodrigo Jimenez	Jerry Wilson

Escalation for a page alert is one hour; for a warn, 24 hours.

What we do

1. Contain. Use the kill switches to stop the affected capability (sending, outbound email, a specific integration) without taking the service down; rotate any credential that may be exposed; isolate rather than delete — nothing is removed from an audit table during an incident.
2. Assess. Establish what data, which organisations, over what period, from what cause. The operator audit log and per-document audit chains are the primary evidence; both are hash-chained and are verified before being relied on.
3. Notify. See below.
4. Recover. Restore service; where data was altered, restore from the last good state and record exactly what was restored (continuity).
5. Review. Within 10 business days write a post-incident review: timeline, cause, what detected it (or did not), what was told to whom, and the changes made. It is shared with affected organisations on request.

Who we tell, and when

Who	When	What
Affected organisations' owners	Without undue delay, and within 72 hours of confirming that their data was affected	What happened, what data, what we have done, what they should do, a named contact, and updates until closed
Recipients whose data was affected	Through the sending organisation, or directly where the organisation cannot be reached or asks us to	Same
Regulators	Where a law that applies to the affected data requires it — for United States organisations, typically a state breach-notification law naming a state attorney general or agency — within the deadline that law sets; otherwise we assist the affected organisation with its own obligations	What that law requires
All customers	For an availability incident of more than 30 minutes, or any security incident affecting the service as a whole	A status notice on the sign-in page and by email to owners, with a closing summary

We do not wait for a full understanding before the first notice; we say what we know, what we do not, and when the next update will come.

Security contacts and coverage

Security reports: security@escryber.com. Privacy requests: privacy@escryber.com. Both are read by the two people named above during the covered hours. Every credential the service holds is inventoried with an owner and a rotation procedure, and a tabletop exercise of the four incident types most likely for a signing service — cross-tenant exposure, a duplicate charge, a lost signed document, a leaked key — was walked through on 2026-09-12 against the procedures and tools in place; the summary of that exercise is available to customers on request and is not published.

Reporting a vulnerability

Send it to security@escryber.com. We acknowledge within two business days, keep you informed of progress, credit you if you wish once it is fixed, and do not pursue good-faith research that stays within your own test data and does not degrade the service for others.

Records

Every incident has a written record: detection time, response times, actions (each privileged action is already in the operator audit log with a reason), notifications sent, and the review. Records are kept for 3 years.

What this does not promise

No fixed time to resolution. No out-of-hours response beyond what the rota row says. The rota is two people; the plan records that and the fallback (a dated notice rather than a silent breach) is deliberate.