Paperlatch
Incident Response Plan
Paperlatch · Last updated 30 September 2026
The short version. Atlassian is told within 24 hours, affected customers within 72 hours, and Atlassian receives progress updates at least every 6 hours until the incident is closed. Paperlatch is one person, so this plan names what that person does, in what order, rather than describing a team that does not exist.
What counts as an incident
- A vulnerability in one of our apps that could expose, alter or destroy customer data, or allow access beyond the permissions the app declares.
- Compromise of an account or credential that can publish or modify one of our apps: the Atlassian developer account, the Marketplace partner account, the source repository, or the domain.
- A report from a researcher, a customer, Atlassian, or an automated scan that credibly indicates either of the above.
- Discovery that an app behaved outside its declared permissions, or retained data it states it does not retain.
A functional bug that does not touch security is handled through ordinary support, not this plan. If it is unclear which applies, it is treated as an incident until it is shown not to be.
Roles
Paperlatch is a single-person partner. One person holds every role below, and that is stated plainly rather than disguised.
- Incident lead, security contact and communications: the owner of support@paperlatch.com, who also holds the Atlassian developer account and the Marketplace partner account.
- Escalation outside the company: Atlassian Marketplace Security, through the Developer and Marketplace Support portal. Where an incident carries legal or regulatory exposure, external legal counsel is engaged before customer notification goes out.
Detection
We expect to learn of an incident from one of these, and we watch all of them:
- Email to support@paperlatch.com, checked on business days.
- Atlassian Marketplace Security tickets and automated scan results on the app.
- Advisories on the app’s own dependency tree.
- Reports from customers or researchers under the security policy.
The clock
| When | What happens |
|---|---|
| Hour 0 | The report is acknowledged in writing to whoever made it, and a written record is opened: what is known, when it was learned, and from whom. |
| Within 24 hours | Atlassian is notified through a P1 ticket in the Developer and Marketplace Support portal, with whatever is known at that point. The ticket is raised on the known facts; it is not delayed to make the picture complete. |
| Every 6 hours | Progress update to Atlassian on the same ticket until the incident is closed, including when the update is that nothing has changed. |
| Within 72 hours | Affected customers are notified by email to their Atlassian site administrators, after legal review where the incident involves personal data. |
| After closure | Post-incident review submitted to Atlassian, and a public note added to the security policy page. |
What the notification to Atlassian contains
- Incident category and scope.
- Impact on end-user data, and the number of customers affected.
- The types of data involved, if any.
- Expected time to resolution.
- Containment already applied, and containment planned.
- The plan for communicating with end users.
- Root cause, if it is known yet.
- Remedial action to prevent recurrence.
- A contact for ongoing communication.
Where something is not yet known it is reported as not yet known, and updated later. Nothing is estimated into a gap.
Containment
These are the levers we actually have, in the order we would reach for them:
- Ship a fix. Forge apps update for every customer at once, so a corrected version reaches everyone without anyone having to upgrade. This is usually both the fastest containment and the remedy.
- Roll back to the last version known to be sound, by the same route.
- Delist the app from the Atlassian Marketplace to stop new installations while a fix is prepared.
- Revoke and rotate the credentials of any account implicated, and re-verify multi-factor authentication on all of them.
What we cannot do, and why it matters here
Our apps hold no customer data outside the customer’s own Atlassian site, and we have no facility to read, export or connect to it. That removes several classes of incident entirely: there is no database of ours to breach and no backup of ours to leak. It also means that in an incident affecting data stored by the app, the customer’s site administrator can act on that data and we cannot. Our notification will say so explicitly, and will state what the administrator needs to do.
Preparedness
- Source code is held in version control with multi-factor authentication required.
- Multi-factor authentication is required on the Atlassian developer account, the Marketplace partner account, the source repository and the domain registrar.
- Development workstations run endpoint protection and are not portable.
- Each release runs an automated test suite that exercises failure and permission paths, not only the paths that succeed.
- The dependency tree is audited, and an advisory that is reachable from the app is treated as an incident.
Contact
support@paperlatch.com — put the word security in the subject line. Reporting guidance, including our response targets and safe harbour, is on the security policy page.