← Back to Trust Center

Incident response

EFFECTIVE: MAY 1, 2026 · LAST UPDATED: MAY 1, 2026

This page describes how Arx detects, classifies, contains, communicates about, and learns from security incidents. It is the public-facing summary of our incident-response plan; detailed runbooks live in our internal documentation and are available to assessors under NDA.

1. Scope & definitions

This plan covers any event that may compromise the confidentiality, integrity, or availability of:

• customer workspace data stored or processed by Arx;
• customer authentication credentials or OAuth tokens we hold;
• the Arx production infrastructure (foundersarx.com, app.foundersarx.com, api.foundersarx.com); or
• internal systems used by Arx personnel that could be leveraged to attack the above.

A security event is an observable occurrence that may indicate a security weakness. A security incident is a confirmed event that has compromised, or is reasonably likely to have compromised, the resources above. A data breach is an incident that resulted in unauthorised access to, disclosure of, or destruction of personal data.

2. Detection sources

• Automated alerts from our observability backend (error rates, authentication anomalies, integration failures).
• Provider alerts from Vercel, Railway, Supabase, and Stripe (failed deploys, suspicious activity, abuse signals).
• Customer or end-user reports to security@foundersarx.com.
• External vulnerability reports through our responsible disclosure program.
• Internal audits of access logs, audit trails, and dependency advisories.

3. Severity classification

The on-call engineer assigns one of four severities at the time of declaration. The severity can be re-graded as the picture becomes clearer.

• SEV-1 (Critical). Confirmed or strongly suspected unauthorised access to customer data, workspace-to-workspace data leakage, takeover of an administrative account, ransomware, or complete production outage. Response begins immediately, day or night.
• SEV-2 (High). Confirmed exploitable vulnerability in production, significant degradation affecting many customers, loss of a critical security control, or credential exposure of an Arx employee account with production access. Response begins within 1 hour during business hours, 4 hours otherwise.
• SEV-3 (Medium). Limited-scope vulnerability, minor data-integrity issues, partial outage of a non-critical feature, or unauthorised access to non-customer data. Response begins within 1 business day.
• SEV-4 (Low). Security event with no demonstrated customer impact (e.g., suspicious scanning, low-confidence anomaly). Triaged within 5 business days.

4. Response process

Every declared incident follows the same six phases. Phases run concurrently where appropriate.

1. Identify. Confirm the event, capture initial evidence (logs, screenshots, request traces), and open an incident ticket with a unique identifier.
2. Contain. Stop the bleeding. Revoke compromised credentials and tokens, disable affected accounts, roll back recent deploys, block abusive IPs, or take the affected surface offline as needed. Containment actions are logged in the incident ticket.
3. Eradicate. Identify root cause. Patch vulnerable code, rotate keys, remove unauthorised access, and verify that the root cause is no longer present in production.
4. Recover. Restore affected services to normal operation. Validate from monitoring and targeted tests that the incident has not recurred.
5. Communicate. Notify affected customers and, where applicable, regulators (see §6). Update internal status throughout.
6. Review. Conduct a blameless post-incident review (see §7) and feed actions into the engineering backlog.

5. Roles & responsibilities

• Incident Commander. Drives the response, owns decisions, keeps the timeline, and is the single source of truth during the incident. Typically the on-call engineer or the engineering lead.
• Technical Lead. Investigates, executes containment and eradication, and proposes remediation. Coordinates with provider support if needed.
• Communications Lead. Drafts and sends customer and stakeholder communications under the Incident Commander's sign-off. Owns post-incident write-ups.
• Executive Sponsor. A company officer is informed for every SEV-1 and SEV-2 and is consulted on disclosure decisions.

6. Customer & regulator notification

When an incident materially affects customer data, we notify the affected workspace owner in writing without undue delay after confirmation. Notification includes:

• a description of the incident in plain language;
• the categories of data affected, to the extent then known;
• the measures we have taken to contain and remediate;
• the measures we recommend customers take (e.g., rotate API keys, review access logs);
• a single Arx contact for follow-up; and
• a commitment to a written post-incident summary once the investigation has concluded.

Where applicable law imposes a specific notification deadline (for example, the 72-hour notification obligation under GDPR Article 33), we comply with it. Where Arx acts as a data processor, we notify the customer (the controller) so the customer can meet their own notification obligations to their end users and regulators.

Public communication, where appropriate, is published on the Arx status page and announced to all account owners by email.

7. Post-incident review

For every SEV-1 and SEV-2 incident we run a blameless post-incident review within 10 business days of closure. The review produces a written report covering: timeline, root cause, what worked, what did not, and a prioritised list of action items with owners and due dates. Action items are tracked in the engineering backlog and reported in the next leadership review. The post-incident report is shared with affected customers on request.

8. Tabletop exercises

At least annually we run a tabletop exercise that walks the team through a simulated incident — typically a credential leak, a third-party compromise, or a privilege-escalation bug. Lessons learned feed back into this plan, our SSDLC, and our vulnerability management procedures.

9. Contact

• Report an incident — security@foundersarx.com
• Privacy questions — privacy@foundersarx.com
• See also — Security overview, Responsible disclosure, Secure SDLC

This page is the public summary of our incident-response plan. Detailed playbooks (provider-specific containment steps, evidence-handling instructions, contact lists) live in our internal documentation and are available to assessors under NDA.