Security incident response
How to report a security problem, and what happens next.
Reporting a security issue
| Channel | Use it for | Response |
|---|---|---|
| security@eworks.cloud | Vulnerabilities, suspected breach, abuse | Acknowledged within 1 hour, 24/7 |
| Trust panel in e.dash → "Report a security issue" | Authenticated reports with workspace context | Same, plus automatic case linkage |
| On-call escalation via your support channel | Active exploitation, data exposure in progress | Pages the on-call engineer immediately |
Include what you observed, when, affected workspace ID, request IDs from the audit log if you have them, and reproduction steps. A PGP key for sensitive reports is published at https://eworks.cloud/.well-known/security.txt.
Good-faith security research is welcome. Do not access other tenants' data, do not run denial-of-service tests against production, and give us a reasonable window before public disclosure.
Response timeline
| Phase | Target | What happens |
|---|---|---|
| Detection and triage | Under 1 hour | Alert or report validated, severity assigned, incident commander named |
| Containment | Under 4 hours | Credentials revoked, sessions terminated, affected paths isolated or disabled |
| Eradication | Under 24 hours | Root cause removed, patch deployed, indicators swept across the fleet |
| Customer notification | Under 72 hours of becoming aware | Affected controllers notified with facts known at that point |
| Recovery | Severity-dependent | Service restored, heightened monitoring for 14 days |
| Post-incident review | Within 5 business days | Blameless review, corrective actions with owners and dates |
Severity levels
| Severity | Definition | Paging |
|---|---|---|
| SEV-1 | Confirmed unauthorized access to customer data, or platform-wide outage | Immediate page, executive bridge |
| SEV-2 | Exploitable vulnerability, single-tenant exposure, auth degradation | Immediate page |
| SEV-3 | Contained issue with no evidence of exposure | Next business hour |
| SEV-4 | Hardening finding, no exploitability | Tracked in the backlog |
Forensics
- Audit log analysis. The 7-year immutable trail is the primary evidence source; request IDs correlate application logs, API gateway logs and audit events into a single timeline.
- Chain verification. The audit hash chain and daily digest anchors are verified first, to establish that evidence is intact.
- Scope determination. Actor, tenant, records touched and time bounds are established before any remediation that could destroy evidence; snapshots are taken and held under legal hold.
- Threat modeling. The affected component is re-modeled against STRIDE to find sibling paths sharing the same assumption.
- Root cause. Written as a causal chain, not a single culprit, with the controls that should have caught it earlier.
Communication
Customer notifications are sent by the incident commander to workspace admins and any registered security contact, and include:
- What happened and when it was detected.
- Which workspaces and data categories are affected — or a clear statement that scope is still being determined.
- What we have done to contain it.
- What you should do, if anything (rotate keys, review sessions, notify your own regulator).
- Named contact and the time of the next update.
Follow-up updates are sent at least every 24 hours while an incident is open. A public post-incident report is published for every SEV-1, and a transparency report summarizing incident counts, response times and law-enforcement requests is published twice a year.
Regulatory clock. As processor, eworks.cloud notifies you without undue delay and within 72 hours. The controller-to-authority notification under GDPR Art. 33 and LGPD Art. 48 is yours to make. Keep your security contact in e.dash current so the clock never starts late.
Secure development practices
The fastest incident response is the incident that never ships.
- Code review. Every pull request needs at least one approving review and zero open security findings before merge. Changes touching auth, tenancy or encryption require a second reviewer from the security group.
- Dependency management. Dependabot raises automated update PRs; Snyk scans the manifest on every build. Critical advisories are patched within 48 hours, high within 7 days.
- Secret management. No credentials in code, ever. Runtime secrets come from AWS Secrets Manager, with HashiCorp Vault for multi-cloud and short-lived dynamic credentials. Commit-time secret scanning blocks the push; any leaked value is treated as compromised and rotated.
- SAST and DAST. Static analysis and dependency scanning gate every pull request; dynamic scanning runs nightly against a production-like environment. Findings above medium block release.
- Penetration testing. An independent third party tests the platform annually, plus after any major architectural change. Remediation is tracked to closure and the report is included in SOC 2 evidence.
- Infrastructure as code. All environment changes are reviewed, versioned and reproducible; drift is detected daily.