Security incident response policy
How Organiz prevents, detects, and responds to security incidents.
Effective date: September 26, 2026 Last updated: October 7, 2026
This policy describes how Organiz identifies, contains, and responds to security incidents, and what clients can expect if one affects their data.
What counts as a security incident
A security incident is any confirmed or reasonably suspected event that compromises the confidentiality, integrity, or availability of client or member data, or of the systems that handle it. Examples: unauthorized access to an account or organization's data, exposure of an encrypted credential (like a connected integration's API key), or a vulnerability that could let one organization access another's data.
We classify incidents by severity:
| Severity | Definition | Example |
|---|---|---|
| Critical | Confirmed unauthorized access to personal data, or a live exploit affecting multiple organizations | A bug lets one org read another org's member data |
| High | A vulnerability with clear exploit potential, not yet confirmed as exploited | An access-control gap discovered in review, before any exploitation |
| Moderate | A security-relevant defect with limited or no data exposure | A missing input validation check with no evidence of misuse |
| Low | A hardening opportunity with no direct exposure | A defense-in-depth improvement |
Our standing security practice
Security review is part of how changes ship at Organiz, not a periodic audit. Every change goes through code review, and changes to our server endpoints are checked against a documented security checklist. It covers whether the caller is signed in and allowed to act on that specific resource, whether input is validated, whether error messages stay free of internal detail, and whether a connected integration's credential is encrypted at rest and never logged. Automated tests and lint checks run on every change before it can merge.
When we fix a significant security issue, we fix its root cause, not just the symptom, and record it in an internal security log with the fix, so the same kind of issue doesn't come back elsewhere in the codebase.
Roles and responsibilities
| Role | Person | Responsibility |
|---|---|---|
| Incident owner | Saulo Oliveira, CTO (saulo@organiz.org) | Leads the response: severity, containment, fix, and review |
| Escalation contact | Kedar Reddy, Founder & CEO (kedar@organiz.org) | Owns client communication and steps in if the owner can't be reached |
Reports sent to security@organiz.org reach both.
Detection and reporting
Incidents can surface through code review, testing, client reports, or independent security research. Anyone, staff, client, or independent researcher, can report a suspected issue to security@organiz.org, and we treat every report as credible until we've confirmed otherwise.
Response process
- Identify. Confirm whether a reported or detected issue is a real incident, and assign it a severity.
- Contain. Limit the exposure immediately, this might mean disabling a feature, rotating a credential, or blocking an access path, before a full fix is ready.
- Fix. Address the root cause, not just the immediate symptom, and add a regression check where practical so the same issue can't silently reappear.
- Recover. Confirm the fix is deployed and verify the exposure is fully closed.
- Review. Document what happened, why, and what changes as a result, the same way we already do for every security issue found in day-to-day review.
Client notification
For a Critical or High severity incident that affects a client's data, we will notify that client within 72 hours of confirming the incident, with what we know at the time and how we're responding. We'll follow up as our understanding develops.
Contact
To report a suspected security issue, email security@organiz.org. You don't need to go through a bug bounty program. We accept and respond to every good-faith report.
See also our Privacy Policy and Data Retention Policy.