Data Security and Privacy Statement

Space Blueprints for Confluence, published by Matify. Last updated: 18 October 2026.

Overview

Space Blueprints lets a Confluence administrator turn an existing space into a blueprint, lets any licensed user request a new space through a form, and provisions that space once an administrator approves it. This statement describes exactly what the app reads, what it writes, what it keeps and where that data lives.

The short version: the app runs entirely on Atlassian's own platform, stores only metadata and Atlassian account ids, and sends nothing anywhere else.

Hosting and architecture

The app is built on Atlassian Forge. Its code runs on Atlassian-hosted compute and its data lives in Atlassian-hosted storage inside your site's own region. There is no Matify server, no external database, no queue outside Atlassian and no third-party service in the request path.

There is no external data egress of any kind: no analytics, no error reporting service, no content delivery network, no remote fonts. The user interface is bundled and served from the app itself.

Data the app processes

Data	Read	Stored	Why
Space metadata (id, key, name, type, status, homepage id)	Yes	Yes	The inventory, blueprint definitions and provisioning need to know which spaces exist.
Page metadata (counts, parent, last modified date)	Yes	Counts and dates only	Blueprint fidelity reports and "last activity" in the inventory.
Space role assignments and permissions	Yes	As a hash only	Drift detection compares a fresh hash with the previous one. The app does not keep a copy of who holds which permission.
Space labels	Yes	As a hash only	Same as above.
Atlassian account ids	Yes	Yes	Requester, approver, space owner and the actor on each audit row.
Request details (proposed name, key, purpose)	Yes	Yes	The request itself, and the audit trail of what was approved.
Blueprint definitions and naming policies	—	Yes	Configuration an administrator created.
Page content, attachments, comments	No	No	The page tree is copied by Atlassian's own server-side copy task. Content never passes through app code.
Email addresses, names, profile data	No	No	The app resolves display names for rendering only and never stores them.

Personal data

The app stores Atlassian account ids. They identify a person, so the app treats them as personal data and implements Atlassian's personal data reporting API: Atlassian can ask which account ids the app holds, and can instruct the app to erase them. On erasure the app removes the id from its records and marks the record accordingly. It never deletes a customer's space, page or content in response.

No other personal data is stored. The app holds no email addresses, no display names, no profile information and no page content.

Data storage, retention and deletion

Where: Forge hosted storage (key-value store and custom entities), pinned to the region of the

Confluence site the app is installed on.

Retention: audit rows are kept for 24 months by default and the retention period is configurable

between 6 and 60 months. Inventory snapshots keep the newest twelve per space. Blueprints, naming policies and requests are kept until an administrator deletes them.

Deletion: administrators can delete blueprints, policies, requests and audit ranges at any time,

and "Delete all app data" removes everything the app stores in one guarded action.

On uninstall: Forge removes the app's storage. Spaces, pages, labels, space properties and role

assignments the app created remain in Confluence, because they are your content, not the app's.

Tenant isolation

Forge storage is scoped to a single installation. The app holds no cross-site cache and no shared identifier. Data from one Confluence site is never readable from another.

Data residency

The app uses only Atlassian-hosted storage and therefore follows the data residency of the Confluence site it is installed on.

Permissions the app requests, and why

Scope	What it is for
`read:space:confluence`	Read the space inventory, space labels and space properties.
`write:space:confluence`	Create the requested space and write the blueprint reference and review date onto it.
`read:space.permission:confluence`	Read the space role catalogue and a space's role assignments, for drift detection.
`write:space.permission:confluence`	Assign the owner their role on the newly created space.
`read:page:confluence`	Page counts, last-activity dates and blog-post detection for blueprint fidelity and the inventory. Page bodies are never read.
`read:configuration:confluence`	Read whether the site uses role-based space access, to choose the correct create path.
`write:confluence-content`	Start Confluence's own page-hierarchy copy task.
`write:confluence-space`	Apply space labels, create a space on sites without role-based access, and receive the permissions-updated and deleted space events, which require it. Never used to delete.
`read:confluence-space.summary`	Poll the status of the copy task, and receive space events.
`read:confluence-user`	One call, made as the signed-in person, that confirms they are a Confluence administrator before an administrative action runs. Never used to look up anyone else.
`storage:app`	The app's own storage.
`report:personal-data`	Report stored account ids to Atlassian and honour erasure requests.

The app does not request permission to read attachments, read email addresses, or change site configuration. Version 4.0.0 removed read:confluence-content.summary, which earlier versions requested without using.

What the app deliberately does not do

It never deletes or archives a space or a page, including when provisioning fails part-way. A failed

run is reported with a retry, and any cleanup is left to an administrator.

It never copies page-level restrictions from a blueprint. Copying them would create access rules in a

new space that nobody reviewed, so copyPermissions is off and stays off.

It never makes a change as one of your users. The app performs its work under its own app identity,

and records in the audit trail which person requested and which person approved. It uses a person's own authority only to ask Confluence what that person may do (see Access control below).

Logging

The app writes structured operational logs to Forge: request ids, space ids, step names, durations and error codes. Logs contain account ids where an action needs attribution. They never contain page content, space descriptions, request purpose text, display names or email addresses.

Access control

Every permission decision is made in the app's backend and answered by Confluence itself, through Confluence's REST API, as the signed-in person (asUser()):

Administrative actions (blueprints, approvals, settings, inventory, audit log, data deletion)

run only when the call comes from the app's page in Confluence administration and GET /wiki/rest/api/user/current?expand=operations confirms the person is a Confluence administrator.

A space's own Space Blueprints page reads and re-checks only that space, and only when

GET /wiki/api/v2/spaces/{id}/operations confirms the person administers it.

The blueprint gallery and new requests offer a blueprint only when Confluence confirms the

requester can view its source space.

Every check fails closed: if Confluence cannot confirm a permission, the action is refused. The app's own identity (asApp()) is used only for provisioning steps that need it, after an administrator's approval, and for the scheduled inventory sweep.

Encryption

In transit: every call between the app, Confluence and Forge storage uses Atlassian's

authenticated APIs over TLS 1.2 or higher. The app makes no other network calls.

At rest: all data the app stores is held in Forge hosted storage, which Atlassian encrypts at

rest with AES-256.

The app holds no credentials, API tokens or secrets of its own, so there are no keys for it to manage.

Vulnerability management

Dependencies: a small set of pinned packages, checked with npm audit before every release. A

release does not ship with a known high or critical advisory in a production dependency. The 4.0.0 release was checked on 18 October 2026: 0 known vulnerabilities.

Testing: an automated suite of more than 260 tests runs before every release, including tests

that try to reach every administrative function as a non-administrator, as a space administrator and with a forged payload.

Input validation: all input from the interface is validated on the server before use.

Administrator-supplied naming patterns are length-bounded and screened for patterns that could hang the evaluator.

Least privilege: every scope maps to an endpoint the app calls, checked against Atlassian's

published API specifications. No scope can delete anything.

Reporting and fixing: vulnerabilities can be reported privately (see Contact). Reports are

acknowledged within one business day and fixed within the periods set by Atlassian's Security Bug Fix Policy for Marketplace apps, for example within 10 days for a critical vulnerability. Our disclosure policy: https://github.com/Matify25/matify-support/blob/main/SECURITY.md

Incidents: if a vulnerability or incident affects customer data, Matify notifies the affected

customers and Atlassian without undue delay.

Certifications

Matify does not hold its own SOC 2 report or ISO 27001 certificate. The app runs entirely on Atlassian's Forge platform, which is SOC 2 attested and ISO 27001 certified, and stores data only inside that platform boundary, so hosting, storage, encryption at rest and backups are covered by Atlassian's controls. The app is eligible for Atlassian's Runs on Atlassian programme.

Other practices

The audit trail is append-only.
Operational logs never contain page content, display names or email addresses.

Subprocessors

None. The app uses no third-party service.

Contact

Security or privacy questions, including vulnerability reports: mira.maty@web.de, with security in the subject line. Please report suspected vulnerabilities privately rather than in a public issue. GitHub's private vulnerability reporting is also enabled on https://github.com/Matify25/matify-support.