Security policy

The short version

Architecture and data residency

• Application code runs in Atlassian's managed Forge runtime — we host nothing.
• App data (for FastPoll: poll definitions and votes; for FastPoker: sessions, votes, accepted estimates and project settings; for FastGantt: a cached projection of your Jira issues plus the app's own settings; for FastRisk: per-project matrix settings and review-reminder markers, and nothing else — the risk assessments themselves are stored in Jira custom fields on your own issues, not in app storage; for FastAudit: a custom field inventory, weekly snapshot counts and a cleanup journal) is stored in Forge hosted storage in your Atlassian tenant, and inherits Atlassian's hosting, residency and security controls.
• Encryption in transit (TLS) and at rest is provided by the Atlassian platform. Our apps implement no cryptography of their own and hold no keys.
• Tenant isolation is enforced by the platform. Within an installation, app data is further partitioned by scope (per issue, per project, per dashboard gadget), derived server-side.
• We keep no copy of your data, and have no API or backdoor to read it. A consequence worth stating plainly: we also cannot restore your data — durability is a platform function.

Data residency

Because our apps store all in-scope End-User Data exclusively in persistent Atlassian Forge hosted storage, they qualify for Atlassian's data residency programme and are shown to administrators as PINNED. In practice:

• If your Jira site is pinned to a location, the app's data is automatically located there too — no configuration is needed from you or from us.
• If you later move your Jira data to another supported location, the app's data is migrated along with it by Atlassian.
• Supported locations follow Atlassian's own list — currently Australia, Canada, EU, Germany, India, Japan, Singapore, South Korea, Switzerland, the United Kingdom, the USA, and Global — and automatically include any new location Atlassian adds.

Atlassian requires app vendors to state which data is in scope. For our apps:

Application security

• Least-privilege permissions. Each app declares only the Atlassian scopes it needs, justified individually in its manifest, and a site administrator must consent to them at install time.
• Identity is never taken from the client. The acting user and the data scope are always derived server-side from the platform request context, so a client cannot claim to be someone else or reach another scope.
• Integrity rules are enforced server-side. For FastPoll that means one vote per person, open/closed gating, creator-only management of a poll, and — importantly — results that are withheld from the API response when hidden, not merely hidden in the interface.
• Input is validated and bounded server-side, including size caps that prevent storage abuse.
• No privilege escalation through the app. Almost every Jira call is made as the signed-in user, so Jira enforces their own permissions. The one FastPoll action performed with app-level rights — posting a results comment when a poll closes — first verifies with Atlassian's Authorize API that the person closing the poll is allowed to comment on that issue.
• FastPoker holds no copies of user profile data. It stores Atlassian account IDs as references — the minimum needed to keep one vote per person — and reads display names from Jira at the moment the participant list is drawn, following Atlassian's guidance not to hold copies of user profile data. Closing or expiring a session deletes every row keyed by an account ID; what remains is the estimate history, which has no account IDs in it.
• FastPoker's authorisation model. Facilitator-only actions (reveal, change issue, accept, close) are verified server-side against the invocation context, never a value sent by the browser; project settings additionally require Jira project-administration rights, checked as the signed-in user and failing closed. Votes are withheld from the API response until the round is revealed — including from the facilitator — and every request is scoped to the caller's own project, so a session in one project cannot be read or driven from another.
• FastGantt's write and read paths, stated plainly. Every write (rescheduling, field edits, creating or deleting issue links) is performed as the signed-in user — Jira enforces that user's own permissions. The app's background sync reads project issues with app-level permission to build the per-project cache that makes large timelines fast; that cache is scoped to the project the viewer has opened and is never reachable across projects. One consequence to be aware of: within a project, the cached timeline is shared by everyone who can open that project's FastGantt page, so Jira issue-level security restrictions between members of the same project are not re-applied per viewer. If you use issue security levels to hide issues from some members of the same project, take this into account when adopting FastGantt there.
• FastRisk can physically only write its own six fields. Every read runs as the signed-in user, so Jira filters what they can see and the app cannot surface an issue somebody could not already find. Writes go through the Atlassian interface for app-owned field values, which the platform restricts to fields the app owns — so no summary, status, assignee, comment or other app's field is reachable, by construction rather than by convention. That interface is authenticated as the app rather than as the caller, which means Jira applies no permission check of its own; FastRisk therefore re-verifies the user's own Jira permission to edit that specific issue on the server before every single write, so a stale browser tab or a crafted payload cannot write an assessment the user is not entitled to make. Its one other write is a comment on an issue whose review date has lapsed.
• FastRisk stores no personal data, so there is none to protect. No name, no email address, not even an Atlassian account ID. Risk owners are read from Jira when a page or a reminder is rendered and never written to app storage; there is consequently nothing for it to report or erase through the Forge Privacy API. On uninstall it deletes every record it holds, and deliberately leaves your assessments alone — they are values in your own Jira fields, and erasing a customer's risk register would be destroying their records rather than removing ours.
• FastAudit changes configuration reversibly, and re-checks before it does. Its scans are read-only. The only changes it can make are moving a custom field to Jira's own field trash and restoring it again — both performed as the signed-in user, so Jira enforces that user's permissions, and neither able to delete a field permanently or alter the data a field holds. Every request re-verifies Jira administrator rights server-side, and every field submitted for cleanup is re-screened against the stored inventory, so a stale page or a crafted payload cannot trash a field the last scan judged healthy or locked. Each action is written to the audit journal before it is reported as done.
• Closed accounts are erased from FastAudit's journal. The acting administrator's account ID is the only personal data it stores. Entries are deleted automatically after 90 days, and the app reports the accounts it holds to Atlassian weekly through the Forge Privacy API, redacting the account ID as soon as Atlassian reports the account closed — the record of what changed survives, the identifier does not.
• No third-party code or tracking. No external scripts, fonts, CDNs, analytics or trackers are loaded. There is no egress path for them.

Secure development

• All code is held in a private repository with access limited to authorised developers, and no credentials or tokens are committed.
• Every change is type-checked, linted against the platform's rules, and covered by an automated test suite — including dedicated tests for the security-critical seams (authorisation, anonymity, visibility gating).
• Non-trivial changes undergo code review and, where security-relevant, an explicit security review before release.
• Fixes ship fast: a corrected version can be built, tested and deployed within minutes, and all customers run the same deployed version — no coordinated upgrade is required.

Logging and monitoring

Atlassian surfaces application error logs and operational metrics to us through the developer console; site administrators control this and can disable log sharing at any time in Atlassian Administration. Our logging is deliberately sparse and never contains your content — no poll questions, options, ballots, names or account identifiers.

Incident response

We maintain a documented incident response plan, aligned to Atlassian's app security incident management guidelines. It defines what counts as an incident and the steps we follow:

• Acknowledge a security report within 2 business days.
• Investigate — root cause, whether data was actually affected, how long the issue persisted, and which users and data types are involved.
• Notify Atlassian within 24 hours of identifying an incident, as a P1 ticket, with status updates at least every 6 hours while we remediate.
• Contain before perfecting the fix — up to temporarily delisting the app if that is what limits exposure.
• Remediate, with a regression test for the specific defect. Every customer runs the same deployed version, so a fix reaches everyone within minutes and no upgrade is required of you.
• Notify affected customers within 72 hours, and — for personal-data breaches — the relevant supervisory authority.
• Review afterwards: confirm nothing remains, document the cause and the prevention, and update the plan.

Remediation timeframes follow Atlassian's Security Bug Fix Policy, which sets deadlines by CVSS severity (critical issues within 10 days for cloud apps). Because we hold no copy of your data, the realistic incident surface is the application logic and our development pipeline — both covered above.

In the interest of accuracy: the plan is documented and maintained, but has not yet been exercised in a tabletop test, and we do not currently retain an external incident response partner.

Reporting a vulnerability

Compliance posture — stated plainly

We would rather be accurate than impressive:

• The platform that hosts and stores all customer data (Atlassian) holds SOC 2, ISO 27001 and other certifications, published at atlassian.com/trust.
• Nirama Solutions itself holds no third-party security certification and has not commissioned an independent penetration test. We are a small vendor; our security case rests on the architecture (nothing to exfiltrate from us), least-privilege permissions, and disciplined development practice — not on paperwork we do not have.
• We publish a CAIQ-Lite self-assessment covering these controls question by question — including the gaps.

Contact

Security: security@niramasolutions.com
General support: support@niramasolutions.com
Nirama Solutions AB, Sweden