Security — Fair Hours

Last updated: 26 August 2026

This page describes how Fair Hours is built, hosted and maintained, and how to report a security problem. It is deliberately separate from the Privacy Policy, which covers what the app stores and who can read it.

How the app is hosted

Fair Hours runs entirely on Atlassian Forge. We operate no servers, no databases and no infrastructure of our own. The app's code runs on Atlassian's platform and its data lives in Forge storage, inside the Atlassian cloud region of your own Jira site. Hosting, network security, tenant isolation and physical security are therefore Atlassian's, under Atlassian's own security programme and certifications.

No data leaves your site

The app's manifest declares no external permissions and no egress. The app makes no request to any host outside Atlassian, which means data physically cannot be sent anywhere else. There is no analytics, no telemetry and no third-party error reporting. There are no sub-processors: nothing about your site or your people reaches us or anyone else.

Encryption

• In transit — all traffic between the browser, the Forge runtime and the Jira REST API is over TLS, provided by Atlassian.
• At rest — app data is held in Forge storage and encrypted by Atlassian.
• Secrets — the app stores no encryption keys, passwords or API tokens, and it never asks a customer for a password or a personal access token. It authenticates through Forge itself.

Permissions and access control

Every worklog write is made as the signed-in user, never as the app, so the record belongs to its real author and a customer's own JQL on the worklog author keeps working. Who may edit a timesheet or approve a month is decided by a pure function in the engine and enforced on the server, so a hidden button is never the only thing standing between a person and an action they are not allowed to take.

Least privilege

Fair Hours reads the projects, issues and logged work the timesheet and the cost report are built from, and writes logged time. The granular worklog scopes were tried first and refused by the platform, so the two classic work scopes are the only ones Forge accepts for worklogs today; every other scope the app holds is granular. The full list of scopes, with the reason for each one, is published on the app's Marketplace listing and was given in writing to the Atlassian app review team.

How the app is built and released

• Every release is gated by an automated test suite that must pass before the app can ship, together with a clean lint and a clean build. A rule that matters for safety is proven by planting the defect and watching the suite fail, so a green suite means something.
• Dependencies are scanned with npm audit before a release, and the app is kept on Atlassian's current Forge runtime.
• The development machine runs a supported operating system with automatic updates and endpoint anti-malware enabled.
• The Atlassian account used to publish the app is protected with two-step verification.

Reporting a vulnerability

Write to support@saoirsesoftware.com, or open a request on our support portal. Please include what you found, how to reproduce it, and what an attacker could do with it. Every report is acknowledged in writing within one business day and given a single owner. We do not take legal action against anyone who reports a problem to us in good faith and gives us reasonable time to fix it.

We triage within three business days, using CVSS v3 and Atlassian's severity levels, and we follow the Atlassian Marketplace security bug fix policy: critical within 2 weeks, high within 4 weeks, medium within 6 weeks, low within 6 months, measured from confirmation.

If something goes wrong

We keep a written incident response plan covering intake, triage, containment, notification and the write-up afterwards. In short:

• Atlassian is notified within 24 hours of our confirming a critical or high severity issue, or any incident involving end-user data, through Atlassian's security incident channel.
• Affected customers are notified using Atlassian's app vulnerability notification template: what happened, what data was involved, what they need to do, and when the fix lands.
• As a processor, we notify the customer — the controller — without undue delay so they can meet their own GDPR obligations. That commitment is written into our Data Processing Agreement.
• Because the app runs on Forge, containment means shipping a corrected version, and where the risk justifies it, disabling the affected function in the app itself.

Keeping and erasing data

Once a week, on its own, the app asks Atlassian whether any account it still holds information about has been closed or updated, and erases or refreshes its record accordingly. When an administrator uninstalls the app, Atlassian deletes the app's storage for that site as part of the normal uninstall. A request to remove data sooner, or to see what is held, is handled within 30 days — see the Privacy Policy.

What we do not have

We would rather say this plainly than let a checklist imply otherwise. Saoirse Software is a small Irish software company, and today we run no bug bounty programme, no external penetration test and no ISO 27001 or SOC 2 certification. Nothing on this page is claimed unless it is actually in place. When that changes, this page changes with it, and the date at the top changes too.

Contact

Security contact: support@saoirsesoftware.com — monitored Monday to Friday, 09:00–17:00 Europe/Dublin. The same address is registered on the app's Marketplace listing and on our partner profile.