Privacy practices - Asymm Systems

Waitlist subscriber data

When you sign up for early access notifications about an Asymm product (Eliya FIPS variant, .deb / .rpm packages, macOS binary, Asymm Forensics, etc.), we collect:

Email address (required): to send you the notifications you signed up for
Use case description (optional): to help us understand who's waiting and why
Timestamp of signup: for operational reasons
Confirmation status: whether you've completed the double opt-in confirmation

We do NOT collect

Your name (unless you provide it in the optional use case field)
Your IP address (beyond what's required for spam prevention during signup)
Tracking cookies
Any analytics on your behaviour

What we DO with this data

Send you product-launch notifications when the products you signed up for ship
Send you quarterly progress updates about those products
That's it.

What we will NEVER do

Share it with third parties
Sell it to anyone
Use it for advertising
Use it for any product other than the ones you signed up for
Send you unsolicited marketing about unrelated topics

Your rights

Unsubscribe. Every email we send includes a one-click unsubscribe link. If you unsubscribe from a product list, you stop receiving emails from that list immediately.

Data export. Email [email protected] to request an export of all personal data we hold about you. We respond within 30 days.

Data deletion. Email [email protected] to request deletion of your personal data. We delete within 30 days and confirm by email.

GDPR. EU subscribers have full GDPR rights including data portability, rectification, and the right to object to processing. Email [email protected].

GitHub and public repository contributions

If you contribute to Asymm's public repositories on GitHub (issues, pull requests, discussions), GitHub's privacy policies apply. Asymm does not aggregate or process this data beyond GitHub's normal operations.

Website analytics

Asymm's website (asymm.systems) does not use third-party analytics (Google Analytics, Mixpanel, Heap, Amplitude, etc.). We do not track visitor behaviour across the site.

Server access logs are retained for 30 days for operational reasons (debugging, security incident response). They are not used for marketing or analytics.

Jira Governance Suite apps for Jira Cloud

CascadePlan, LedgerSeal, DefinitionGuard and FourRealities are Atlassian Forge apps. This section states how they handle End User Data (Atlassian Marketplace Partner Agreement, section 8.4(e)).

What is the same for every app

Sharing: none. The apps make no calls outside your Atlassian site, and no data is sent to Asymm Systems or any third party.
Where it is stored: in Atlassian's Forge hosted storage for your site, which Atlassian hosts in your site's data residency location (for example the EU, the US or Australia), and, where stated below, in issue properties of your Jira issues.
Responsibility: Asymm Systems, not Atlassian, is responsible for the apps' processing of this data.
Deletion: after you uninstall an app, Atlassian keeps its Forge hosted storage for 28 days and then deletes it. Issue properties stay with the issues until the issues are deleted. For other requests, write to the privacy contact below.
No email addresses are stored by any of the apps.

CascadePlan

What it accesses and stores: it reads the project's Jira issues (keys, ids, summaries, types, status, assignee, estimates, time spent, due dates, parents, links) as the signed-in user, to show the plan. It stores planning data: the row order and columns of each plan, plan filters, hand-set progress and targets, the plan list, baselines (issue id and key, Jira estimate, start, end, done) and scope-change requests. It sets issue properties on your issues: cascadeplan.dates (start and end), cascadeplan.links (dependency trigger percents) and, on issues it created, cascadeplan.create (a create id).
Personal data: the Atlassian account id of the person who froze a baseline, of who requested or reviewed a scope change, of each person who works on a task through a Jira sub-task, and of the Jira administrator who last saved the approver groups. Each of these account ids is reported to Atlassian's personal data reporting service once every 7 days, and the records of a closed account are changed to name no one. A user sees the baseline items only of the issues that user can browse in Jira. A contributor name that matches no account (for example a placeholder role) is kept as typed.
Deletion: deleting a plan deletes its data and its baselines.

LedgerSeal

What it accesses and stores: it reads the issue it seals. It stores, in Atlassian Forge storage on your site: seal records, which name every person they mention (signers, people who changed the issue, and people named in the sealed content such as the assignee, comment authors and mentions) by a pseudonymous token: a keyed hash of the Atlassian account id under a key only the app can read. A pseudonymous token is still personal data: the app can link it to the account id that Jira shows on the issue. It also stores one record per person who sealed, revoked or changed a sealed issue, linking the token to the Atlassian account id; the account id of the Jira admin who last saved the approver groups; and the issue content that was sealed (field values, comments, attachment names), as Jira holds it. It sets the issue property ledgerseal-cert (the seal status, certificate id, snapshot hash and seal date), which holds no personal data.
Code signing: in projects where a Jira admin turned code signing on, LedgerSeal asks Jira to email each signer their own single-use code (scope send:notification:jira); Jira sends the email. LedgerSeal stores, per person, the party token, the lockout state and a hash-chained history of code requests and attempts. It keeps a code only as a keyed hash, for at most a day. It stores no email address.
Personal data: no email address and no display name is stored. Every week LedgerSeal reports these account ids to Atlassian's personal data reporting API; when Atlassian reports an account as closed, LedgerSeal deletes the link from the token to the account and the admin id, so the app no longer holds the account id, and the panel shows a deleted user. A deleted issue's records are deleted. Forge storage is deleted 28 days after the app is uninstalled; the ledgerseal-cert issue property stays on the issues. LedgerSeal sends no data outside your Atlassian site.

DefinitionGuard

What it accesses and stores: it reads the issue and its workflow. It stores the Definition of Done checklist state of each issue and its history in Forge storage, and sets the issue property definitionguard-dod (a summary of the checklist).
Personal data: who completed, waived, reopened or reset each checklist item, and who saved a template, the exempt statuses or the approver groups. DefinitionGuard stores each person as a random pseudonym; the Atlassian account id is kept only in one link per person. The app reports these account ids to Atlassian every week and deletes the link of every account Atlassian reports as closed; the history then shows "A deleted user". Evidence links, evidence notes and waiver reasons are free text that you write and may name people. The issue property definitionguard-dod holds no personal data.

FourRealities

What it accesses and stores: it reads the issue, its Development field, its changelog and the issue properties of LedgerSeal and DefinitionGuard, and searches the Confluence pages of your own site. It stores snapshots, exception events, rework reasons and site settings in Forge storage. When you make an evidence report, it stores the report files in Forge Object Store on your site. The report files hold, in plain text: each issue's key, type, status and current summary (up to 120 characters); who changed which field and when, with the old and new values of fields that are not free text; the reasons of Code exceptions; rework reasons and their notes; the address (URL) and title of a linked Confluence page, which users type and which can hold any text; the key and type of a linked decision issue, never its title or content; and evidence references: LedgerSeal certificate ids and hashes (such as the Definition of Done hash). Reports are removed when their retention ends (400 days by default; a Jira administrator can choose 90 days to 7 years). Some small records outlive it: a deletion record (tombstone, with the administrator's reason) stays while the app is installed; the list entries of failed, expired and deleted reports stay until the newest 200 entries of the project push them out; and the link from each party token to an Atlassian account id stays while the account is open (it is reported to Atlassian every week, and removed when the account closes).
Personal data: Atlassian account ids only where a rule needs them: who requested or decided a Code exception, who gave a rework reason, and the assignee, for the "My issues" filter. No names are stored; the dashboard reads names from Jira each time it shows them. FourRealities reports these ids to Atlassian every week and erases the ids of closed accounts; the panel then shows "a former user". Evidence report files name people by a pseudonymous token, a keyed hash of the Atlassian account id under a key only the app can read; the app keeps one link from each token to the account id and reports these account ids to Atlassian every week. When Atlassian reports an account as closed, the link is removed, so the report shows a former user and the signed files never change. The people file of a download maps tokens to account ids and names as the downloading user; it is removed 24 to 25 hours after the download.

Privacy contact

Privacy questions, concerns, or requests: [email protected]. Response target: within 7 days for questions, within 30 days for data requests.

Updates to this policy

When we update this privacy policy, the change is documented in the policy's git history. For substantive changes that affect how we use your data, we email subscribers before the change takes effect.