Paperlatch
Security Policy
Paperlatch · Last updated 29 September 2026
The short version. Our apps run entirely on Atlassian Forge, inside the customer's own Atlassian cloud site. We operate no server, hold no customer data, and make no outbound network calls. That removes most of what a security policy usually has to describe — and it is also why the parts below are short.
Reporting a vulnerability
Email support@paperlatch.com with the word security in the subject line. Please include what you found, how to reproduce it, and the app and version it affects.
- We acknowledge a security report within two business days.
- We aim to give an initial assessment, including whether we can reproduce it, within five business days.
- We will tell you when a fix ships, and we will credit you if you want to be credited.
Please do not test against another customer's Atlassian site, and do not access, modify or retain anyone else's data. Report it to us instead and we will reproduce it ourselves. We will not pursue a researcher who follows this policy in good faith.
Vulnerabilities in the Atlassian platform itself should go to Atlassian rather than to us. If in doubt, send it to us and we will forward it.
What our apps can reach
Each app declares the narrowest set of Forge scopes it needs, and the full list is published on the Permissions tab of its Atlassian Marketplace listing. For Confirm & Chase that is five read scopes, the app's own storage, and Atlassian's personal data reporting. For Page Approval it is four read scopes, the app's own storage, and personal data reporting.
- Neither app writes to customer content. Neither one holds a write scope for Confluence, and neither creates, edits, moves, restricts or deletes a page.
- Closed accounts are erased. Both apps use Atlassian's personal data reporting: once every reporting cycle they report the account IDs they hold, and erase the identity of every account Atlassian reports as closed.
- No acting on behalf of a user. No
ACT_AS_USER. - Email addresses are never read or stored. The user-read permission the apps hold covers profile information that includes an email address. We do not read that field and never write it to storage.
- No external egress. The apps make no outbound HTTP requests, so there is no third party to trust and no data to encrypt in transit to us.
Where data lives
In Atlassian Forge hosted storage, within the customer's own Atlassian cloud site. Forge hosted storage is data residency enabled: app data is pinned to the same location as the host product and migrates with it. Encryption at rest and in transit, key management, and physical security are Atlassian's, described in the Atlassian Trust Center.
We have no facility to read, export or connect to that data. This is a property of how the apps are built, not a promise about how we behave.
How the apps are built
- No secrets in the app. The apps hold no API tokens, passwords or shared secrets, and never ask an end user for one.
- Dependencies. Runtime dependencies are kept to the Forge SDK and its own requirements. Fewer dependencies is the control.
- Tests before release. Each release runs an automated suite that includes the failure paths — partial reads, refused requests, permission errors — because the rule the code is governed by is that missing, partial or unauthorised data must never be presented as a valid result.
- Platform updates. Forge apps are updated for every customer at once. A security fix does not wait for anyone to upgrade.
What we do not claim
Paperlatch is a small independent developer. We hold no SOC 2 report and no ISO 27001 certificate, and we have not completed a CAIQ questionnaire. We would rather say that plainly than imply an audit that does not exist. If your procurement process requires one, tell us what you need and we will tell you honestly whether we can meet it.
Incidents
If we become aware of a security incident affecting an app, we notify Atlassian within 24 hours through a P1 support ticket, update them at least every 6 hours until it is closed, and notify affected customers within 72 hours. What happened and what changed is published on this page afterwards.
The full plan, including what counts as an incident, what the notification contains and what we can and cannot do about data held inside your own site, is here: Incident Response Plan.
Changes
If this policy changes materially, the date at the top of this page will change.