Incident Response Policy

1. What counts as an incident

A security incident is any event that exposes, alters or destroys customer data or credentials, grants access to someone who should not have it, or compromises a system PsiGuard runs on. Examples: a leaked API key or secret, unauthorised access to an account or to infrastructure, a vulnerability that could be exploited, a sub-processor breach that touches our data. A service incident is an outage or malfunction without a security dimension; it follows the same steps with lighter communication.

2. Roles

The Founder is the incident lead and the single point of contact. The product is operated day to day by one person, so there is no hand-off chain; the value of this policy is that the steps are written down in advance so they are followed under pressure rather than improvised.

3. How incidents are detected

• Reports: anyone can report a suspected issue to [email protected]; the Security page publishes this address and asks for responsible disclosure.
• Monitoring: hosting-provider logs and alerts, Stripe and Firebase notifications, and the service's own records of API activity (including each key's last use) and admin counts, which make unexpected usage visible.
• Sub-processor notices: breach notifications from the providers listed in SEC-01 §6.

4. Response steps

1. Confirm and record (as soon as noticed). Write down what was observed, when, and how it was found. Start an incident note that is kept for the life of the incident.
2. Contain (first hour). Stop the exposure: revoke the affected API key(s); rotate the compromised secret in the hosting environment and redeploy; revoke the session or disable the account involved; if needed, take the affected route or the whole service offline. Containment comes before diagnosis.
3. Assess (first day). Determine which accounts and which data classes (SEC-03 §2) were affected, over what period, and whether anything left our systems. Where the answer is unknown, assume the wider scope.
4. Notify. Affected customers are told by email within 72 hours of confirmation, sooner when an action on their side (such as rotating a provider key) would reduce harm. The notice states what happened, what data was involved, what we have done, and what they should do. Where law requires notice to a regulator, that is made within the required period.
5. Recover. Restore normal operation, verify the fix in production, and confirm that revoked or rotated credentials have fully replaced the old ones.
6. Review (within two weeks). Write a short post-incident review: root cause, timeline, what worked, what did not, and concrete changes. Changes that touch a policy are made under SEC-01 §7.

5. Customer-side exposure

If a customer reports that their own PsiGuard key has leaked, we revoke it on request immediately and help them issue a replacement. If we detect a key behaving unexpectedly, we may suspend it proactively and contact the account owner. Customers who connected their own AI-provider key should rotate it with that provider if there is any chance it was exposed; we will say so plainly in any notice.

6. Communication principles

• Tell affected customers what we know, when we know it, in plain language; correct it as understanding improves rather than waiting for a perfect account.
• Do not speculate about cause in public before the review is done.
• Never disclose another customer's data, or PsiGuard's internal monitoring details, in the course of explaining an incident.

7. Records and testing

Incident notes and reviews are kept for at least two years. This policy is walked through at each annual review with a tabletop scenario (for example: "a provider key appears in a public repository") to confirm the steps still match how the service is actually run.