Last updated: 26 August 2026
This page describes how Space Access 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.
Space Access 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 Confluence site. Hosting, network security, tenant isolation and physical security are therefore Atlassian's, under Atlassian's own security programme and certifications.
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.
The app holds a single write scope, and it is used only to apply a removal the administrator has reviewed and approved on screen. Nothing is written without that explicit action, and the app refuses a change that would lock the person making it out of the space. Every change is recorded — when, who ran it, which spaces, which principal — so an administrator can audit it afterwards.
Space Access deliberately uses granular scopes instead of the broad classic ones, and asks for no content scopes at all: it cannot read a page, a comment or an attachment. It reads the list of spaces and their permission entries — the audit the app exists to produce — plus names, groups and the site edition. 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.
npm audit before a release, and the
app is kept on Atlassian's current Forge runtime.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.
We keep a written incident response plan covering intake, triage, containment, notification and the write-up afterwards. In short:
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.
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.
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.