Effective: September 2026
How we detect, classify and resolve incidents affecting our apps. See also our Data Security and Privacy Statement and Service Level Agreement.
Service status
Live and historical status for each app is published at statuspage.simple-reports.com, where you can subscribe for notifications.
Detection
Detection does not depend on someone watching a screen. Incidents reach us through:
-
Continuous automated scanning of third-party dependencies.
-
Automated error and performance monitoring in the apps.
-
Security checks on every build – secret scanning, dependency gating, static analysis. A build that fails them cannot be deployed.
-
Customer reports through our support channels.
-
Independent researchers, via the Atlassian Marketplace Bug Bounty programme.
-
Atlassian, through the Partner Security Incident Response Program.
Automated detection runs continuously; human assessment follows the business hours in our Service Level Agreement.
Classification and resolution
Security vulnerabilities are scored using CVSS, with severity levels and deadlines aligned to Atlassian's Security Bug Fix Policy. Deadlines run from the point a vulnerability is reported or triaged.
|
Severity |
CVSS |
Fixed within |
|---|---|---|
|
Critical |
9.0 and above |
10 days |
|
High |
7.0 and above |
4 weeks |
|
Medium |
4.0 and above |
12 weeks |
|
Low |
Below 4.0 |
25 weeks |
These are maximum windows, not targets; confirmed vulnerabilities are prioritised above other work. A service disruption – an app unavailable, or a core workflow broken with no reasonable workaround – is treated as critical regardless of CVSS.
Communication
-
Service disruptions are posted to our status page and updated until resolved.
-
Security incidents affecting customer data are reported directly to affected customers, and to Atlassian.
-
Incidents with no customer impact are resolved without notification, so a status page entry always means something that could affect you.
After an incident
Every incident with customer impact, and every confirmed vulnerability, gets a written root cause analysis covering:
-
What happened – summary and timeline.
-
Why it happened – root cause and contributing factors.
-
What worked – controls that behaved as intended.
-
Corrective and preventive actions, each tracked to completion.
-
Residual risks, recorded in our risk register.
An incident is closed when the cause is understood and the preventive work is done, not when the symptom stops. Corrective actions address the cause actually found, rather than adding unrelated controls.
Reporting a security issue
We encourage responsible disclosure. Report vulnerabilities to info@simple-reports.com, or through the Atlassian Marketplace Bug Bounty programme, where our apps are in scope.
Please include enough detail for us to reproduce the problem. We will acknowledge your report, keep you informed, and credit you if you would like us to.