Security

This page is for administrators and security reviewers. What the app stores, and for how long, is in the privacy policy; who processes it is on Subprocessors; where it's kept, and what's in scope for data residency, is on Data residency.

Architecture

• The app's pages run inside Jira on Atlassian Forge. Atlassian signs every request they make to the app's server.
• The server runs on Cloudflare Workers. It keeps no data of its own between requests.
• Data lives in a Neon Postgres database in the European Union (Frankfurt, Germany), with a short-lived cache in Upstash.

Who is asking, and what they may see

• Every request is verified. The server checks the signature Atlassian puts on each request against Atlassian's published keys, and refuses anything unsigned, expired or meant for another app. No data can be read or changed without it. The only other way in is the return from Google or Microsoft when someone connects a calendar, which can only complete a connection that person started in the app.
• Your site's data is kept apart. Every stored row belongs to one Jira site, and every query is limited to the site the request came from.
• Jira's own permissions apply. When the app reads Jira for you, it does so as you, so it only sees issues and projects you can see in Jira.
• Roles decide the rest. What someone can see in the app (their own time, their team's, the projects or accounts they lead, or everything) comes from the role an administrator gives them. Only the person who logged a worklog or a plan can change or delete it, whatever anyone else's role. Suggested worklogs and calendars are private to their owner.
• Automated tests check these rules on every change to the code, before it can be released.

Protecting the data

• In transit: every connection (your browser to Jira, Jira to the server, the server to the database, the cache, Jira and email) uses TLS.
• At rest: Neon encrypts the database on disk.
• Secrets we must keep (the access to a calendar you connect, a Tempo API token) are also encrypted by the app itself, with AES-256-GCM, under a key held only as a server secret. A copy of the database alone does not reveal them.
• Absence supporting documents (medical certificates) are encrypted by the app the same way, file by file. Before one is kept, the server reads its type from its own bytes (PDF, PNG, JPEG or WebP only), checks an image's size before anything opens it, and refuses a PDF that is encrypted or holds scripts, launch actions, attachments or forms, looking inside its compressed parts too. Photos are redrawn by the browser first, which drops their metadata.
• Error reports sent to Sentry carry no IP addresses and have request credentials removed.
• No AI training, no advertising, no selling of any data.

Records of what happens

• An audit log in the app records who changed what, when, and to whom: worklogs, plans, timesheets, teams, roles, settings, reports. Administrators (and people given access) can search and export it. Entries are kept 6 to 7 months. Every opening of an absence's supporting document is recorded, with who opened it.
• Server errors are reported to Sentry and reviewed.

Backups and recovery

• Neon keeps the database's history so it can be restored to any moment in the last [to fill: the restore window of the Neon plan].
• Restoring is rehearsed [to fill: how often, and the date of the last rehearsal].

Deleting data

• When the app is uninstalled, or its subscription lapses, all of the site's data is deleted 60 days later. Site administrators are emailed before. Reinstalling within those 60 days keeps everything.
• Absence supporting documents are deleted a year after their absence ends (the absence stays), at once when the app is uninstalled, and when the person's Atlassian account is closed.
• Older data is cleared on a schedule: audit entries after 6 to 7 months, the Jira activity kept for suggestions after about three months.
• A person disconnecting a calendar deletes its access at once.

Staying within Jira's limits

The app respects Jira's rate limits: it waits when Jira asks it to, and tells people when Jira, not the app, is the reason something must wait. Every request is designed to finish well within the time Forge allows.

Our side

• Access to the production systems: [to fill: who has it, and that every provider account uses two-factor authentication].
• Code changes go through automated checks (types, lint, tests) before release.
• The app's dependencies are checked against the known-vulnerability databases before each release, and a vulnerable package is replaced by its fixed version. [to fill: whether automatic update alerts, such as Dependabot, are on.]

Incidents

The app's current status, and past incidents, are on [to fill: status page URL].

If a security incident affects your data, we will tell your site's administrators without undue delay, and within [to fill: for example 72 hours] of becoming aware of it, with what happened and what we are doing about it.

Reporting a vulnerability

Write to [to fill: security email]. We will reply within [to fill: for example 3 working days]. Please give us a chance to fix the issue before making it public.