Security Incident Response Plan

1. Scope and responsibilities

This plan covers security incidents affecting our apps, their build and release pipeline, and any infrastructure we control. Both apps are built and hosted on Atlassian Forge; we do not operate application servers, and we do not store customer data outside Atlassian.

2. How we detect incidents

• Atlassian automated security scanning — findings are tracked in AMS tickets for our app keys; we monitor them continuously.
• Dependency scanning — npm audit is run before every release; a release is blocked while a known vulnerability in a shipped dependency is open.
• Automated tests — a unit-test suite (23 tests for System Field Defaults, 68 for Space Access Audit) gates every deployment.
• Customer and researcher reports — sent to the security contact address above.

3. Severity and target response times

Where Atlassian's Marketplace Security Bug Fix policy sets a shorter window for a finding, that window takes precedence.

4. Response procedure

1. Triage — confirm the report, assign a severity from the table above, and open a private record.
2. Contain — if the issue is exploitable in production, ship the smallest safe mitigation first (for example, disabling an affected code path), then fix the root cause.
3. Remediate — fix on a branch, add a regression test, run the full test suite and dependency scan, then deploy to the development environment and verify before production.
4. Verify — reproduce the original issue against the fixed version, and confirm the fix from Atlassian's scanning where applicable.
5. Notify — see section 5.
6. Review — within 10 business days of closing, record what happened, the root cause, what detection or process change prevents a repeat, and update this plan if needed.

5. Notification commitments

• Atlassian — we respond to and resolve AMS findings through the AMS tickets, and we report incidents affecting a Marketplace app to Atlassian as required by the Marketplace Security Bug Fix policy and the security incident notification guide.
• Customers — if an incident could affect a customer's data or the security of their site, we notify affected customers without undue delay, describing the impact, the action taken and any steps they should take.
• Regulators or data subjects — where a legal notification duty applies, notifications are made within the timeframes the applicable law requires.

6. Records and review

For every incident we keep an internal record: date, severity, description, affected versions, root cause, remediation, timeline of the customer and Atlassian notifications, and the follow-up actions. This plan is reviewed at least annually, and after any Critical or High severity incident.