Security policy

Reporting a vulnerability

Please include enough detail to reproduce the issue: the affected version, the steps taken, and what you observed.

We will acknowledge your report within two working days and give you an assessment — whether we can reproduce it, how serious we judge it to be, and what we intend to do — within ten working days. We will keep you informed until it is resolved, and we will credit you when we publish a fix if you would like us to.

We ask that you give us a reasonable opportunity to fix an issue before disclosing it publicly, and that you do not access, modify or delete data belonging to anyone else while investigating. We will not pursue legal action against anyone acting in good faith under these terms.

We do not currently operate a paid bug bounty.

How the app is built

Capasight:Lite is an Atlassian Forge app. This is the single most important fact about its security posture, because it removes whole categories of risk rather than mitigating them:

• No servers of our own. All code runs on Atlassian's infrastructure, inside the customer's own site. There is no hosting account, no database and no network perimeter of ours to breach.
• No egress. The app makes no external network calls. It has no external permissions declared in its manifest, so the platform itself prevents outbound traffic. There are no third-party services and therefore no subprocessors.
• No write access to Jira. Every Jira scope the app holds is a read scope. It cannot create, modify or delete anything in a customer's site, and it reads teams with the view-only Atlassian Teams scope, never the one that manages them.
• Your permissions decide what you see. Every read made in a person's own context is performed with that person's credentials, so Jira's permission model decides what they can see. There is one exception: the background read that builds the portfolio snapshot runs on a queue where there is no user to read as, so it reads with the app's own credentials. Atlassian's security requirements are explicit about what must then happen — “always validate user permissions before using asApp()… for actions triggered in user context” — so that validation happens when the data is served, twice, and both times Jira decides:
  • every row is filtered to the spaces the viewer can browse in Jira;
  • every row under a work item security level is withheld unless Jira confirms, as the viewer, that they may see that work item — and the viewer is told how many were withheld.
  Both fail closed: if Jira cannot be asked, nothing is shown rather than too much. Someone with no access to a space in scope is shown an empty portfolio and told why, never somebody else's work.
• The app's own credential is confined to the background read. It is scoped to that read's own call chain rather than set for the process, following Atlassian's tenant-isolation guidance, so it cannot carry over into a request made on a person's behalf. Jira applies work item security to the app's own account as well, so work behind a security level the app has not been granted is never read at all.
• Changes are authorised on the server. Configuration is site-wide, and only a Jira administrator — or, for the planning fields, a member of a Jira group an administrator has nominated — can change it. Every write checks the caller's role in the resolver that performs it, not by hiding a button, and a request that cannot be confirmed is refused.
• Runs on Atlassian. The app is eligible for Atlassian's Runs on Atlassian programme, which recognises apps that run entirely on Atlassian's platform with no data leaving it.

What the app stores, and where

Everything the app stores is held in Atlassian's own storage inside the customer's site. Nothing is copied anywhere else, because there is nowhere else.

Configuration and saved views. What an administrator or a nominated planner entered: names of teams, ARTs and value streams and the Atlassian teams they are linked to, team velocities, estimate scales and thresholds, the sprint cadence, excluded space keys, Jira field identifiers, the organisation's own names for its groups, and the names of the Jira groups nominated as planners. Saved views are named sets of filters shared across the site. None of it identifies a person.

A portfolio snapshot. A large portfolio cannot be read inside the twenty-five seconds a Forge resolver is allowed, so it is read by a background process and the screens are served from the result. That snapshot is held in Forge SQL, the database Atlassian provisions and hosts for each installation.

For each work item in scope it holds: the work item and space key, the item's summary, its work type and level, its parent, its start, due and created dates and the date range of the work beneath it, its t-shirt size, the story points rolled up beneath it in total and by team and how many have been accepted, its status, its rank, the Jira team on it and on the work beneath it, and the identifier of any work item security level on it — kept so that level can be enforced when the row is served. Nothing else — no descriptions, no comments, no attachments, no assignee, reporter or any other user identity, and no Atlassian account identifiers.

It is replaced in full by each build, only the two most recent are kept, and it is rebuilt when it is more than twelve hours old, when an administrator changes the space scope or field mapping, or when anyone presses Refresh.

Working records. Measured team velocities, the dates of each team's Jira sprints, Jira's work-type icons, when the last full read ran and which spaces it covered, and a record of teams renamed or moved in Jira.

What each person last had open. So that Franklin, the app's assistant in Rovo, can answer about the page in front of someone, the app keeps one short record per person under their Atlassian account ID: the page, level, group, saved view and item they have open, as identifiers rather than names, with the browser's time zone and language. It counts for 30 minutes and is deleted within the hour after that. Because the app erases every record itself this quickly, it does not report them to Atlassian's personal data reporting service. It is the only personal data the app keeps.

Data residency. Forge hosted storage — the key-value store and Forge SQL alike — is covered by Atlassian's data residency programme: an app storing all of its data this way is pinned to the same location as the host product and migrated automatically whenever that product's data is moved. Everything the app holds therefore sits in the same region as the Jira site it was read from, without the customer doing anything.

Deletion. Uninstalling the app deletes all of it. Atlassian soft-deletes the data at once, so the app can no longer read it, and destroys it at the end of its 28-day retention period; within 21 days it can be relinked to a new installation only at the customer's request.

Logging

Atlassian's platform records application logs, which we can read for support and diagnosis. We deliberately record only counts, statuses and the kind of action refused. We do not log work item keys, work item summaries, field names or values, team names, the names of saved views, user identities, or the contents of Jira's responses. Error handling records the HTTP status of a failed call and never the response body, because Jira quotes the request back in its errors — a JQL clause, a field name, sometimes a work item key — and all of that is the customer's. The background snapshot build logs counts and outcomes on the same terms. Atlassian's platform alerts us when the app's error rate rises.

For Franklin, the app logs which question was asked, which of its inputs were filled (by name, never the value), counts and timings — never the question's wording, an account ID or the answer.

Development practices

• All source is held in version control, protected by multi-factor authentication, and every change passes the automated checks below and is exercised on a development site before it is released.
• Static analysis (ESLint) and Atlassian's own forge lint run against every change, and both must be clean before a deployment.
• An automated suite runs before every deployment. It includes tests of every authorisation check — each write refused to a caller without the role for it, rows filtered by space and by work item security, and both failing closed when Jira cannot be asked — and of the app's own credential staying confined to the background read. The shared libraries the app is built on carry more than 1,600 tests of their own, run before each of their releases.
• Permission filtering is also verified on a real Jira site against a second, non-administrator account, with work item security levels and space access changed and restored for the test.
• Dependencies are kept to the minimum the app needs: Atlassian's own Forge packages, and React, which Atlassian's UI Kit requires. They are checked for published advisories before every release — a high or critical advisory stops the release — and again twice a week and whenever a change reaches the main branch, and GitHub alerts us the day a new one is published. Advisories are fixed within Atlassian's deadlines (critical within 10 days, high within 4 weeks), including those inside Atlassian's own packages, which we pin to patched versions until the platform catches up. At the 4.3.0 release (30 October 2026) there were none outstanding: no published advisory against any dependency of the app or the libraries it is built on.
• Changes are deployed to a development environment and exercised against a real Jira site before production.
• User-supplied values used in Jira queries are validated against a strict allowlist pattern before use, and all API paths are constructed with Atlassian's parameterised route helper rather than string concatenation.
• The app keeps no state between requests in memory, following Atlassian's guidance that a warm Forge container may serve more than one invocation.

Access control

Access to the app's source, its Forge deployment credentials and its Marketplace partner account is restricted to named individuals and protected by multi-factor authentication. Who has access is reviewed every quarter. Deployment credentials are held only on company-controlled machines, are created with an expiry of one year or less, and are replaced at once if a device is lost, a person's access ends or a credential may have been exposed.

Incident response

If we become aware of a security incident affecting the app, we will assess its scope, fix the cause, and notify affected customers directly at the technical contact held by Atlassian for their site. We notify Atlassian within 24 hours of becoming aware of an incident, as its Marketplace partner rules require, and keep it updated until the incident is resolved. Where a personal-data breach is notifiable under UK GDPR, we will notify the Information Commissioner's Office within 72 hours of becoming aware of it. The realistic scope of any such incident is narrow, because the app copies nothing outside the customer's own Atlassian site, and the only personal data it keeps is the 30-minute record of what each person last had open: the snapshot it holds contains work-item fields, not people. Work item summaries are customer content and could in principle contain anything the customer has written there, which is why they are treated as customer data throughout and never leave the site. The obligation stands regardless of scope.

Capasight for Azure DevOps

Capasight for Azure DevOps is an Azure DevOps extension. Like Capasight:Lite, it keeps your data inside the platform it runs on.

How it is built

• No servers of our own. The extension runs in your browser, inside Azure DevOps, and its files are served by Microsoft from the Visual Studio Marketplace. It uses no third-party services and therefore engages no subprocessors.
• No personal access tokens. It reads work items with a short-lived token Azure DevOps gives it for each read. It never asks for or stores a personal access token.
• No write access to work items. It writes nothing to your work items.
• Your permissions decide what you see. It reads Azure DevOps as you, with your own permissions: work in an area you may not view is left out of every figure.
• Changes are authorised by Azure DevOps. Configuration is kept in the project's properties, where Azure DevOps' own “Manage project properties” permission decides who may change it, and the extension asks Azure DevOps for that permission each time it is opened.

What it stores, and where

Everything the extension stores is held by Azure DevOps, in your organisation: the configuration in the project's properties, and each person's snapshot of the portfolio in extension storage that only that person can read. It collects no personal data of its own — no user identifiers, no names of people, no email addresses and no user activity — and it keeps no logs and sends no telemetry. What it holds, and how to remove it, is set out in full in the privacy policy.

Development and incidents

Its dependencies are checked for published advisories before every release — a high or critical advisory stops the release — and again every week, and GitHub alerts us when a new one is published. If we become aware of a security incident affecting the extension, we tell Microsoft at the earliest opportunity, as its Publisher Agreement requires, and notify affected customers directly.

Capasight for monday.com

Capasight for monday.com is a monday.com app. Its screens have no server of their own; the one server is the one behind Franklin, Capasight's assistant in monday sidekick, and it runs on monday.com's own hosting.

How it is built

• No servers of our own. The screens run in your browser, inside monday.com, served from monday.com's CDN. There is no database of ours and no third-party service.
• Your permissions decide what you see. The app reads boards through monday.com's API as the person using it, so it sees only what monday.com lets them see. The page holds no token.
• No write access to boards. Every scope it holds is a read scope — boards:read, workspaces:read, me:read, teams:read and account:read — and it writes nothing to boards.
• Franklin keeps nothing. Franklin's tools run on monday code, monday.com's own hosting, in its United States region. Every request must carry monday.com's signature, which is checked before anything is read, and every read is made as the person asking. Each person's snapshot is held in the server's memory while they use Franklin and written nowhere. Its logs name the question, the account and how long the answer took — never board content; a failure is logged by its kind and HTTP status, never by its message, which can quote board data.

What it stores, and where

Configuration and saved views are kept in monday.com's app storage for your account. Capasight's own roles decide who may change what — a monday.com account admin, a member of a monday.com team the admins nominated to plan, or everyone else — and every save is cut down to what that person's role allows. The configuration holds no work data and no secrets. Each person's snapshot of the portfolio stays in their own browser, readable only by them. What the app holds is set out in full in the privacy policy.

Development and incidents

Its dependencies, including those of Franklin's server, are checked for published advisories before every release — a high or critical advisory stops the release — and again every week, and GitHub alerts us when a new one is published. If we become aware of a security incident affecting the app, we tell monday.com within 24 hours and before any customer, as its Developer Terms require, and then notify affected customers directly.

Hosted Capasight

Capasight at app.capasight.co.uk is a service we host and operate ourselves, on Amazon Web Services in the US East (N. Virginia) region, us-east-1. Unlike the three marketplace apps, there is no platform between it and you, so this section describes what is in place today.

• Two-step sign-in for every user.
• Each workspace's data kept apart, and tested on every route.
• Credentials and two-step secrets sealed with AWS KMS; server secrets in AWS Secrets Manager.
• TLS and security headers.
• Read-only tracker access.
• Every request checked against a schema.
• An audit trail kept for a year, and logs held where the servers cannot erase them.
• Daily operating-system patching.
• Dependency, image and code scanning on every change.
• Reviewed against OWASP ASVS Level 2 (November 2026).

In more detail

• HTTPS only. The service is served only over HTTPS, with certificates issued and renewed automatically.
• Tracker credentials are sealed. A credential you save for a tracker such as Jira or Smartsheet is encrypted with AWS KMS, bound to your organisation and to that connection, so a copy taken anywhere else will not open. No part of the service ever returns it.
• Smartsheet is read, never written. If your portfolio is kept in Smartsheet, Capasight reads your initiative sheet, either through a Smartsheet service account you share it with as a Viewer or from an Excel export you upload. It never changes the sheet. From each row it keeps only the name, t-shirt size, dates, done status, place in the sheet and the Jira items the row names. An uploaded file is read and not kept. Removing the Smartsheet connection removes those rows with it, and they leave the daily backups within 30 days. Smartsheet and Jira integration details →
• Monitored around the clock. An external check requests the service's health page every 30 seconds from several regions, and AWS's own checks on the host run alongside it. A failure lasting two minutes emails us, and a fault in AWS's hardware under the host is recovered automatically.
• Backups. The database is backed up daily to an encrypted Amazon S3 bucket that is closed to public access, and each backup is kept for 30 days.
• Every change is tested and audited. Every change must pass its automated tests and a check of its dependencies for published advisories before it is deployed. The dependency check also runs every week, and GitHub alerts us when a new advisory is published. On 24 October 2026 this check found one critical and eight high advisories, and all of them were fixed that day.
• Incidents. There is no marketplace in between, so if we become aware of a security incident affecting the service, we notify affected customers directly and without undue delay, and tell them to rotate any credential that may have been exposed.

Certifications

We do not currently hold SOC 2, ISO 27001 or equivalent certification for any Capasight product. The platform Capasight:Lite runs on is covered by Atlassian's own certifications, which are published in the Atlassian Trust Center.

Contact

security@capasight.co.uk for security matters.
contact@capasight.co.uk for everything else.