Privacy Policy

1. Where the app runs

Contextra Secure Field is built on Atlassian Forge and runs entirely on infrastructure operated by Atlassian. Contextra Labs operates no servers, no database and no analytics endpoint for this app.

The app declares no external domains in its manifest for the core product. It makes no network request to any third party — not for analytics, error reporting, telemetry, or any other purpose. Every byte the app handles stays inside Atlassian's platform.

The only outward-facing links are the optional "leave a review" prompt, to the app's Atlassian Marketplace listing, and a mailto: link to our support address. Neither is contacted unless you click it, and neither carries any of your data.

2. What the app reads

To do its job the app reads, through Atlassian's APIs and only within the sites where it is installed:

• The field's own configuration — the allow-list, second-factor toggle, auto-expiry setting, and whether bring-your-own-key is enabled
• The issue's assignee, reporter, creator, project and project lead — re-resolved on every reveal/edit attempt, to evaluate the allow-list against Jira's own current data, never against a client-supplied claim
• The calling user's group and project-role membership — for the same allow-list evaluation
• JSM request participant membership — for fields that allow-list "JSM request participants"
• Your licence status — supplied by Atlassian, used to gate saving and revealing when inactive

3. What the app stores — read this section carefully

Secure Field's entire purpose is to store a value you consider sensitive, so this is the most important section in this policy.

The field's own Jira-visible data

The custom field's own value — the data Jira itself stores and could return through its own REST API — is only ever { v, hasValue, updatedAt }: a schema version number, a boolean for whether a value is currently set, and a timestamp. Never the secret itself, never ciphertext, never a reference that could be used to reconstruct it.

The encrypted value

The value you save is encrypted with AES-256-GCM inside the app's backend before it is ever stored, and stored in Forge's own key-value store — reachable only through this app's own resolver, which re-checks the field's allow-list against Jira on every single read. By default the encryption key is generated and held by the app itself, inside Forge storage; if you enable "bring your own encryption key," you supply the key instead — see the note on that option in section 6.

The Secure Attachment field's file content

For the companion attachment field type, the same encryption and storage model applies to a small file (up to 90 KB) instead of a short value — encrypted before storage, decrypted only for an allow-listed user's download request.

Configuration

Per-field settings — the allow-list (account ids, group ids, or role ids), the separate audit-visibility allow-list, the second-factor toggle, the auto-expiry setting, and whether BYOK is enabled — are stored via Forge's key-value store, inside your Atlassian site.

The audit log — itself personal data

Every reveal, edit, and denied attempt is recorded as an entry containing the issue id, the field id, the Atlassian account id of the person who took the action, the action type, and a timestamp. This log is itself personal data about the people who access your fields — a fact this policy states plainly rather than leaving implicit. It never contains the secret value itself.

4. Personal data — read this section too

The value you store may itself be, or relate to, personal data — a password, an API key, or another credential tied to a specific person is a normal, expected use of this field. Contextra Labs does not inspect, scan, or attempt to identify the meaning of anything stored through the field; the app encrypts and decrypts opaque bytes, gated only by the allow-list you configure.

The audit log records who accessed or was denied access to a field, and when — this is personal data about your users, generated by the app itself as part of the security feature it provides, not data you upload. It is visible only to people on the field's own, separately configurable audit allow-list.

Contextra Labs is a processor, not a controller, of any personal data encrypted through this app, and of the audit log entries the app generates on your behalf. You, the customer, decide who is on each field's allow-list; Atlassian hosts the storage; Contextra Labs operates the app's encryption and permission-check logic without ever holding a copy of the decrypted value or the audit log outside Atlassian's infrastructure.

5. Data location, retention and sub-processors

All processing and all storage happen within Atlassian's infrastructure, in the region Atlassian assigns to your site. Contextra Labs holds no copy of anything outside it.

An encrypted value is retained until it is overwritten, its configured auto-expiry passes, or the app is uninstalled — whichever happens first. Configuration and the audit log are deleted when the app is uninstalled.

Sub-processors: none. The store this app uses — Forge's own key-value store — is operated by Atlassian itself, not a third party engaged by Contextra Labs.

6. How to remove everything

• Clear an individual value by overwriting it, or by setting the field's auto-expiry (section 9 of the documentation) so it clears itself automatically.
• Remove a field's configuration by deleting the custom field itself from Jira admin, which removes its stored configuration and encrypted values along with it.
• Uninstall the app. Every encrypted value, every field's configuration, and the entire audit log are deleted by Atlassian along with the app's storage. Nothing survives an uninstall — a deliberate difference from a field type meant to hold ordinary content.

7. Your rights

Because a field's value may relate to a person other than the Jira account holder — for example, a credential issued to a specific individual — and because the audit log records the activity of your own users, data-subject requests concerning that content should generally be directed to you, the Jira site owner, as the data controller for what your organisation chooses to store and who it grants access to. Contextra Labs holds no independent copy to export or erase outside Atlassian's infrastructure.

Contextra Labs is established in Dubai, United Arab Emirates. Where we do process personal data — in practice, only an email address if you write to support — we do so in accordance with UAE Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data and, where it applies to you, the EU General Data Protection Regulation. You may exercise any right you hold under those laws by writing to our support address.

8. Security

The app runs in Atlassian's Forge sandbox, inherits Atlassian's authentication and permission model, and requests the minimum scopes it needs: read:jira-work, read:jira-user, write:jira-work, read:servicedesk-request and storage:app.

Values are encrypted with AES-256-GCM inside the app's backend only — never in the browser — and every reveal or edit re-checks the caller's identity against Jira's own APIs at the moment of the request, never trusting a claim the client supplies. See the Security Policy for the full detail.

9. Changes to this policy

Material changes will be published on this page with an updated date, and noted in the app's release notes.

10. Contact

support@contextra-labs.com

See also the Terms & EULA, Security Policy, and Data Processing Agreement for Contextra Secure Field for Jira.