Trust center
Incident Response Plan
Last updated:
Scope
An incident is any event that degrades or interrupts Hooq’s service (sync delay, sync failure, UI unavailable), or that puts customer data at risk (suspected unauthorized access, data corruption, cross-tenant exposure, leaked credential).
Roles
- Incident lead. Runs the incident, owns communications and the decision to close it.
- Engineer on call. Investigates and fixes.
- Communications owner. Posts to the status page and writes customer notices. May be the incident lead.
1. Detect
Sources: customer reports to the support or security contact; Atlassian notices (Forge platform incidents, Partner Security Incident Response Program, Marketplace notices); Hooq’s own monitoring (the developer reads the app’s logs through the Atlassian Forge logging tools to find issues before they are reported; the in-app Troubleshooting tab). Anyone who suspects an incident tells the incident lead immediately.
2. Triage and classify
Promptly after detection: confirm the problem, assign severity (below), name the incident lead, decide whether customer data or availability is affected, and decide whether Atlassian must be notified. Security incidents are reported to Atlassian promptly, as the Atlassian developer terms require.
| Severity | Definition | Examples |
|---|---|---|
| SEV1 Critical | Confirmed or likely exposure, loss or corruption of customer data; or Hooq sync or UI unavailable for most customers | Cross-tenant data exposure; sync writes wrong data at scale; leaked signing secret |
| SEV2 Major | Core function degraded for many customers, workaround exists, no data exposure | Sync delayed by hours; panel fails to load |
| SEV3 Minor | Limited impact: one feature, a few customers, or cosmetic | A single field type not syncing; wrong label in the UI |
| SEV4 Informational | No customer impact | Internal error pattern, near miss |
3. Communicate
- Status page: post an incident that affects customers, update it until it is resolved, and mark it resolved when done.
- Direct notice: affected customers are told directly when their data is involved, without undue delay and no later than 72 hours after confirmation of a breach affecting their data.
- Atlassian: reported through the partner incident channels for security incidents and for suspected Forge platform causes.
- Customer names, site URLs and work item content are never posted publicly.
4. Resolve
Mitigate first (disable the faulty feature, roll back, or deploy a fix), then fix the root cause. Verify with a real sync before closing. Security fixes follow the fix targets in Security and Incident Response.
5. Post-incident review
For every SEV1 and SEV2 (and any security incident): a written review within 10 business days, covering timeline, root cause, customer impact, what went well and badly, and corrective actions with owners and dates; shared with affected customers and summarized on the status page. Corrective actions are tracked until done, and recurring causes feed prevention work (tests, monitoring, design changes). The review is blameless.
Status page
The Hooq status page lists the state of each component: Hooq sync, the Hooq admin pages and issue panel, and the Atlassian Forge platform. States are Operational, Degraded performance, Partial outage and Major outage; the words are always shown, not only a colour. Hooq runs on the Atlassian Forge platform and Jira Cloud, so when Atlassian has an incident Hooq may be affected. Atlassian publishes its status at status.atlassian.com (developer platform: developer.status.atlassian.com).
Review of this plan
This plan is reviewed at least once a year and after every SEV1.