Incident Response

This policy explains how Zrico responds to security incidents, and what customers can expect from us when one happens. It applies to the Zrico website, dashboard (app.zrico.com), firm workspaces ({slug}.zrico.app) and the systems that support them. If this policy and your Data Processing Addendum (DPA) differ, the DPA controls.

Definitions

• Security event. Something that might affect the security of our systems or data, such as an alert, a failed sign-in spike or a vulnerability report. Most events are not incidents.
• Security incident. An event that actually threatens, or has compromised, the confidentiality, integrity or availability of our systems or customer data.
• Personal data breach (or breach). A security incident that leads to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, customer data.
• Customer data. Data a firm or its users put into Zrico, including chats, uploaded files and account information.
• Confirming a breach. The point at which we have reasonable certainty that a breach has occurred and that it affects a specific customer's data.

Severity levels

We set the level during triage and raise or lower it as we learn more. When in doubt, we choose the higher level.

Roles

We are a small team, so one person may hold more than one role. For every SEV-1 or SEV-2 incident we name:

• Incident lead. Runs the response, makes decisions, keeps a timeline.
• Technical responder(s). Investigate, contain and fix.
• Communications lead. Updates the status page, notifies affected customers and, where needed, authorities. Works with legal counsel.

Legal counsel and outside forensic specialists are brought in as the incident requires.

How we respond

1. Detect. Incidents come from monitoring and alerts, edge protection (Cloudflare and CrowdSec), vulnerability scans, reports to security@zrico.com, customer support requests and provider notices.
2. Triage. We confirm whether the event is an incident, set a severity level, name the roles and start an incident record with a timeline.
3. Contain. We limit the damage. Steps can include blocking addresses, revoking sessions and keys, rotating secrets, isolating or suspending an affected workspace, or taking a service offline.
4. Eradicate. We remove the cause: patch the vulnerability, remove malicious access, fix the misconfiguration.
5. Recover. We restore normal service, from encrypted backups if needed, and watch closely for signs the problem has returned.
6. Review. We hold a blameless post-incident review, record the root cause, and track follow-up actions to completion.

Throughout, we preserve logs and other evidence. Our logs do not contain prompts, responses or file contents, so investigations rely on access, network and system records.

Notifying customers

If we become aware of a breach that affects a customer's data, we will notify that customer without undue delay, and in any case within 72 hours of becoming aware of it. If we don't yet know everything, we send what we know and follow up as we learn more. We send the notice by email to the firm's owner and admins. If we cannot reach them by email, we use other contact details we have.

The notice will include, as far as we know at the time:

• what happened, and when it happened and was discovered
• what kinds of data and which users are or may be affected
• the likely consequences
• what we have done and will do to contain and fix it
• what the firm can do to protect itself and its clients
• a contact person for questions

If we do not yet know everything, we will send what we know and follow up as we learn more. Each customer remains responsible for any notices it owes to its own clients, employees or regulators. We will give reasonable help with those.

Status page

For incidents that affect availability or many customers, we post updates at https://status.zrico.com. Status page updates do not include details that could identify a specific customer or help an attacker. A status page post is not a substitute for direct notice to an affected customer.

Law enforcement and regulators

Where the law requires it, we notify regulators or other authorities of a breach within the required time. We may report criminal activity to law enforcement. If law enforcement asks us to delay a customer notice so as not to harm an investigation, we may do so only as far as the law allows, and we will notify affected customers as soon as the delay ends.

Post-incident review

After every SEV-1 and SEV-2 incident, we write a post-incident report. It covers the timeline, root cause, impact and the changes we are making to prevent a repeat. We share a summary with affected customers, usually within 30 days of resolving the incident. We may leave out details that would put other customers or our systems at risk.

Testing and updates

We review this policy at least once a year and after any SEV-1 incident.

Contact

To report a security issue or a suspected incident, email security@zrico.com. See our security page for how we handle vulnerability reports.