Security Incident Response & Escalation
This page is maintained by Georithm to explain the process we follow when a security incident is suspected or confirmed, the response targets we work to, and how you can reach us or escalate if you do not hear back. It describes our own practices during public beta; it is not an independent audit, certification, or a guarantee of any particular outcome.
- Version
- v1.0
- Last updated
- 29 July 2026
A security incident is any event that we believe compromises, or credibly threatens, the confidentiality, integrity, or availability of the Georithm service or the data held in it.
This includes suspected unauthorised access to accounts or data, bypass of our access controls or plan entitlements, payment or webhook anomalies, and exposure of credentials.
Georithm is in public beta. We publish this process so that customers and security researchers know what to expect, and so that our own team follows the same steps every time.
Email jerogz@georithm.info with as much detail as you can safely provide. Please do not use general support for security matters, and please do not post details publicly before we have had a reasonable opportunity to respond.
A useful report includes:
- A one-line summary of the issue
- The URL, screen, or endpoint affected
- Steps to reproduce
- The impact you believe it has
- The time you observed it, in UTC
- A contact address for follow-up
Please report identifiers only — never send us copies of another person's data. Signed-in customers can also find these contact details in Settings, under Security contact and escalation.
We classify every report and internal signal into one of four levels, which sets our response targets.
- P1 — Critical: confirmed or highly likely exposure of customer data, account takeover, payment fraud, or a full outage of the authenticated product. Acknowledged within 15 minutes, around the clock, with updates at least hourly until contained.
- P2 — High: an exploitable weakness without confirmed data loss, or a degraded security control such as MFA, rate limiting, or entitlement enforcement. Acknowledged within 4 business hours, with daily updates.
- P3 — Medium: a security-relevant defect with limited impact or unlikely preconditions. Acknowledged within 2 business days, with weekly updates.
- P4 — Low or informational: hardening suggestions and findings with no demonstrated exploit path. Acknowledged within 5 business days and tracked in our backlog.
These are the targets we work to. They are commitments of process and effort, not contractual guarantees, and we may reclassify an incident as we learn more.
- Detect and report. Signals come from our internal security monitoring, our automated security regression suite, our payment provider, or from you. Evidence is captured before anything is changed.
- Triage and classify. We name an incident commander who owns decisions and communications, assign a severity, and open an incident record with a running timeline.
- Contain. We stop the impact before root-causing: revoking sessions, disabling affected accounts or roles, tightening access rules, and rotating any credential that may have been exposed.
- Eradicate and recover. We fix the root cause, add a regression test so the same class of issue is checked automatically, re-run our full security regression suite, and restore normal service.
- Notify. We assess whether personal data was affected and notify the people and organisations who need to know.
- Review. Within five business days of resolution we run a blameless review and turn the findings into tracked actions.
If we determine that an incident affected your account or your data, we will contact you at the email address on your account.
Our notices aim to tell you: what happened, what data was involved, what we have done about it, what we recommend you do, and how to reach us with questions. Where we do not yet know something, we say so rather than speculate.
Where a personal data breach is likely to have occurred, we work to the notification timelines described in our Privacy Policy and GDPR Notice, including notifying the relevant supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware. Where Georithm acts as a processor for a business customer, the notification terms in our Data Processing Agreement apply.
If you have reported something and have not had a response within the acknowledgement window above, you can escalate:
- Reply to your original email to jerogz@georithm.info, quoting the time you first sent it.
- Email jerogz@georithm.info, referencing the original report, to reach the accountable owner directly.
- For anything involving personal data, copy jerogz@georithm.info so the privacy contact is included.
- If your concern is about how we handled a privacy matter, you retain the right to raise it with your data protection authority at any time, as described in our GDPR Notice.
We welcome good-faith security research under the rules set out in our Security Disclosure Policy. In short: use your own test accounts, do not access or exfiltrate data belonging to others, do not degrade the service for other users, stop immediately if you gain unintended access, and give us a reasonable window to remediate before publishing.
We do not currently operate a paid bug bounty. We are happy to credit researchers who report responsibly, if you would like that.
This document is provided as an original template for Georithm and is maintained by the account owner. It is app-owned editable content and is not legal advice or an independent certification. Replace every bracketed placeholder with your company details and have the final text reviewed by a qualified adviser before relying on it.