Security Policy

Riskcadence for Jira · Last updated: October 18, 2026

1. Overview

Riskcadence: Risk Register & Risk Management for Jira ("the App") is built on the Atlassian Forge platform and operates entirely within Atlassian's infrastructure under the Runs on Atlassian trust boundary. It reads and changes risks with the permissions of the person using it, makes no outbound network calls to any external server, calls no AI service and stores no credentials of any kind. This document describes the App's security architecture and our practices.

2. Architecture & Runtime Environment

No developer-operated servers: There is no external backend, database, or infrastructure operated by us. All compute and storage is provided by Atlassian.
Sandboxed execution: Forge functions run in isolated, sandboxed containers with restricted system access managed by Atlassian.
No external network egress: The App declares no egress domains and makes no outbound requests to any server outside the Atlassian platform. No external API keys or third-party services are involved.
No AI services: The App does not call any AI service. Scores and levels are deterministic arithmetic on the values your team enters and on the risk matrix you define.
Bundled user interface: The screens, the dashboard widget and the Confluence macro are part of the App package and served by Atlassian; the App loads no third-party scripts, fonts, frames or images. Spreadsheets are read and written in your browser with a library bundled in the App.

3. Access Control

Control	Details
Each person's own permissions	Everything a person triggers, such as listing risks, changing a field, importing, starting or closing a review, building a report or publishing it, runs as the user, in the name of that person. Jira applies that person's permissions, including issue security, and Confluence applies page permissions. People see only the risks they may see in Jira.
App account, narrowly used	The App uses its own app account only for: writing the calculated fields it owns (Risk score, Residual score, Risk level) and recalculating them in the background, reading the metadata of those fields, reading all risks of a project once when a review is closed, so that its closing state does not depend on who closes it, and the display-name lookups of the weekly personal data job. Stored rows are always filtered by the reader's current visibility in Jira before anything is displayed, so a review, a comparison or a report never shows a risk the reader cannot see.
Minimal API scopes	`read:jira-work` (read risks, projects and search), `write:jira-work` (create and edit risks, comments, transitions, filters for reminders and issue properties), `read:jira-user` (names for history and pickers), `manage:jira-configuration` (company-managed setup: work type, fields, link type, screens), `manage:jira-project` (project schemes and screens during setup), `storage:app` (Forge key-value store and Forge SQL), `write:app-data:jira` (write the App's own calculated fields), `read:page:confluence` (check whether the user may view or edit the page before a published review state is shown or published; no page content is read) and `report:personal-data` (the weekly personal data report). The configuration scopes are used only by project or Jira admins during setup.
Admin actions checked on the server	Setup, changing the risk matrix, recalculating fields, example risks and the full export need a project or Jira admin; Jira confirms this with the user's permissions on every call. The browser cannot grant itself these rights.
Published review states	Only people who can edit the page can publish. Withdrawing is open to page editors and to the publisher while they can still view the page. Both are checked on the server with Confluence, as the user. A published state is stored under the page ID and macro ID of the Forge context, never from an ID sent by the browser, and bound to that page and macro. Showing it is a read of the App's own Forge storage after a check of the reader's permission to view the page, repeated each time; it makes no Jira request. Publishing reads the risks with the publisher's Jira permissions, and the confirmation tells the publisher what that shares. Jira permission changes after the fact do not withdraw a publication; withdrawing does.
Input validation	Project keys, work item keys and IDs are validated before use, filters are built on the server from validated values and escaped, and the browser cannot send JQL. Spreadsheet rows are validated again on the server, in batches of at most 25, and an import never creates a second risk for the same source ID.
License enforcement	The license is checked server-side on every request; if the Marketplace license of the site is inactive, the App shows a notice instead of data. A trial has the full functionality.
Developer access	None. We cannot read, access, or export any data stored in your Jira or Confluence site or in the App's Forge storage. All data resides within Atlassian's infrastructure.

4. Data Protection

Data in transit:

All Forge-to-Jira and Forge-to-Confluence API calls use Atlassian's internal secured transport (TLS 1.2+).
The App makes no outbound HTTPS calls to external services.

Data at rest:

The App stores the change history of risks, review sessions with their entries, decisions and closing states, published review states, saved register views, configuration, job status, short-lived import markers and anonymous daily usage counters in Atlassian Forge storage (Forge SQL and the key-value store), hosted by Atlassian with encryption at rest and data residency in the location of your Jira site.
The risks and their fields are stored by Jira itself.
No credentials or tokens are stored; there are none to store.
The personal data the App holds is Atlassian account IDs and, in published review states, display names. A weekly personal data report to Atlassian erases closed accounts and refreshes changed names. See the Privacy Policy.

Data minimization:

The App reads only the fields it needs and never reads work item descriptions, comments, attachments or page content.
Logs contain counts, project keys and error codes, never summaries, names, account IDs or free text. Retention and deletion are described in the Privacy Policy.

5. No External Credentials or Integrations

The App does not require or accept any API keys, tokens, passwords, or third-party credentials. There is no configuration that could expose user secrets, and there are no integrations beyond the Atlassian platform itself.

6. Dependency & Vulnerability Management

Runtime dependencies are limited to Atlassian's official Forge packages, React and a spreadsheet library for the import and the export of the register, maintained and patched by their publishers.
Build and test tooling is not included in the production runtime bundle.
We run npm audit before every deploy via an automated pre-deploy gate that blocks the release on high-severity findings in the App's own dependencies, plus a weekly automated audit. Current status: 0 known vulnerabilities in the production dependencies.
Security patches are deployed promptly via Forge; the Node.js runtime is maintained by Atlassian.

7. Incident Response

If a security issue is discovered in the App:

We investigate and begin remediation promptly upon notification or discovery.
A fix is deployed as a priority update via the Forge deployment pipeline.
Affected customers are notified via the Marketplace listing and, where possible, directly.

To report a security vulnerability, contact support@janekbehrens.de with the subject line "Security Report — Riskcadence". We aim to acknowledge reports within 2 business days.

8. Organizational Security Controls

Access to production: Deployments are performed exclusively by the maintainer (Janek Behrens) via the authenticated Forge CLI, behind an automated security gate.
Source code: Maintained in a version-controlled repository under the maintainer's control.
Sub-processors: Atlassian only — it hosts the App on Forge (runtime and storage) under Atlassian's Forge Data Processing Addendum, which includes Standard Contractual Clauses for transfers outside the EEA. All processing occurs within the Atlassian platform.

9. Compliance

GDPR: The App stores Atlassian account IDs and, in published review states, display names, and it erases closed accounts weekly. See our Privacy Policy.
Atlassian security requirements: Built to comply with Atlassian Forge security requirements, the Forge shared responsibility model and the Marketplace security review.
Runs on Atlassian: Operates under Atlassian's trust boundary, so Atlassian's infrastructure, security controls, and compliance certifications (SOC 2, ISO 27001, etc.) apply to the underlying platform.

10. What We Cannot Access

For complete transparency, we have no technical means to access:

Any data in your Jira or Confluence site (work items, pages, comments, attachments, user data)
The review data, history, published review states and other data in the App's Forge storage
Your Atlassian account credentials or session tokens
Any personal data of your team members

11. Contact

For security questions or to report a vulnerability:
Email: support@janekbehrens.de
Subject: Security Report — Riskcadence

Atlassian, Jira and Confluence are trademarks of Atlassian. Riskcadence is an independent app by Janek Behrens and is not made or endorsed by Atlassian; the product names only say which products the app works with.