Enterprise Compliance & Security Mapping

Compliance Disclaimer & Boundaries

Asymm Systems apps provide technical enforcement mechanisms that support compliance with industry frameworks. However, software tools alone cannot confer certification. Your external qualified auditor decides whether your change management policies and implementation satisfy regulatory mandates. Customers remain responsible for validating standard operating procedures, training personnel, and configuring appropriate workflow gates within Jira Cloud.

1. SOC 2 Type II (Trust Services Criteria CC8.1)

AICPA TSC CC8.1 mandates that organizations authorize, design, develop or acquire, configure, test, approve, and implement changes to infrastructure, data, software, and procedures:

SOC 2 CC8.1 Control Focus	Asymm Suite App	Technical Enforcement Mechanism
Formal Change Authorization	LedgerSeal	Records the approver, the time, the meaning of the approval and a SHA-256 snapshot of the issue at approval. The attestation is signed with Ed25519 by the Asymm Systems key of the app. A Jira workflow validator blocks the release transition for issues that are not sealed.
Post-Approval Integrity	LedgerSeal	Detects changes to covered fields, comments and attachments after approval and shows them in the issue panel. The workflow validator blocks the release transition until an approver approves the changes.
Separation of Duties	DefinitionGuard & LedgerSeal	DefinitionGuard lets admins mark DoD items that the assignee may not tick or waive; anyone who was the assignee after the item was opened counts as the assignee. LedgerSeal refuses an approval or a revoke from anyone who changed a covered field, a comment, a work log or an attachment since the last seal.
Verification & Testing Evidence	DefinitionGuard	Lets admins require evidence (a link or a note) on DoD items, such as a CI test report or a security scan, before an issue can transition into Done. DefinitionGuard checks the link format, not the content behind the link.

2. ISO/IEC 27001:2022 (Control A.8.32 - Change Management)

ISO 27001 Control A.8.32 requires that changes to information processing facilities and information systems be subject to change management procedures:

ISO 27001 A.8.32 Requirement	Asymm Suite Implementation
Identification & Record of Changes	Seals, detected changes, approvals of changes, revokes, DoD ticks and waivers are recorded with timestamps; LedgerSeal names people by a pseudonymous token that it links to the Atlassian account until the account is closed. Jira itself records the ticket edits.
Evaluation of Potential Impact	FourRealities shows, for each issue, whether there is evidence for intent (a linked Confluence page or decision issue), process, code (pull requests in the Jira Development field) and audit, so reviewers can see the gaps. It does not read pull request approvals.
Formal Approval Requirements	Workflow validators enforce mandatory approval seals and completed Definition of Done items prior to release state transitions.
Audit Trail Continuity	LedgerSeal keeps a hash-chained history per issue: each entry contains the SHA-256 hash of the entry before it. This makes changes to stored entries detectable.

3. FDA 21 CFR Part 11 (Electronic Records & Signatures)

For life sciences, pharmaceutical, and medical device organizations subject to FDA 21 CFR Part 11 regulations:

21 CFR Part 11 Section	Regulatory Requirement	LedgerSeal Technical Implementation
§ 11.10(e) Audit Trails	Secure, computer-generated, time-stamped audit trails to independently record operator actions.	LedgerSeal keeps tamper-evident, hash-chained records of seals, detected changes, reasons, approvals of changes and revokes. The record can be copied as standalone JSON and checked with the offline verifier. The chain does not stop someone who can rewrite the app storage (including the vendor) from writing a new consistent chain.
§ 11.50 Signature Manifestations	Signatures must manifest: printed name of signer, date/time, and meaning (review, approval, responsibility).	Partly met. Each seal records the date, time and meaning of the signature. The signer's name is shown from their Atlassian account while it exists; after the account is closed, it is shown as a deleted user, so a printed name is not kept in the record.
§ 11.70 Signature Linking	Electronic signatures must be linked to their respective records to ensure signatures cannot be excised or transferred.	Each seal is linked to the issue's snapshot hash and certificate ID in the hash-chained history. The attestation (which contains the snapshot hash and certificate ID) is signed with Ed25519. This is a signature by the app, not a cryptographic signature by the approver. Your auditor decides whether this meets 11.70.
§ 11.200 / 11.300 Electronic Signature Components and Controls	At least two distinct identification components at signing; controls for identification codes and passwords.	Not met: LedgerSeal does not re-authenticate the signer and does not perform two-component signing. Use your own controls if your predicate rules need Part 11 signatures.

4. Vendor Security Assessment (CAIQ-Lite / SIG-Lite)

Pre-filled answers to standard enterprise InfoSec vendor questionnaires:

Questionnaire Domain	Standard Question	Asymm Systems Answer
Architecture & Hosting	Where does application compute and storage reside?	100% within Atlassian Cloud. Compute runs on Atlassian Forge. Data is stored in Atlassian Forge storage for the customer's installation. Asymm Systems operates no external servers.
Data Egress & Exfiltration	Does the application transmit data to external APIs?	No. No Forge manifest declares an external egress endpoint. The apps call only Atlassian APIs of the customer's own site (FourRealities also searches Confluence pages on that site). All hashing and verification run on Atlassian Forge.
Data Encryption	How is data encrypted at rest and in transit?	Encryption at rest and in transit is provided by the Atlassian Cloud platform under Atlassian's own security controls. The apps add no separate storage.
Authentication & Access	How are user permissions authenticated?	Users sign in through Atlassian; the apps have no separate login. App permissions follow the Uniform Permission Standard: Jira permissions plus approver groups chosen by a Jira administrator.
Personal Data	What personal data does the application store?	CascadePlan stores Atlassian account ids only: of who froze a baseline, of who requested or reviewed a scope change, and of each person who works on a task through a Jira sub-task. It reports them each week to Atlassian's personal data reporting service and removes the id of a closed account. LedgerSeal, DefinitionGuard and FourRealities store Atlassian account ids to record who did each action; DefinitionGuard stores them as pseudonyms, reports them each week and deletes the link of a closed account. The privacy policy lists what each app stores.
AI / LLM Ingestion	Are customer tickets sent to external LLMs?	No. Zero third-party AI APIs are used. All scoring and hashing is deterministic code running on Atlassian Forge.
Vulnerability Management	How do you handle security vulnerabilities?	Responsible disclosure address: `[email protected]`. Initial response within 72 hours. Fixes follow Atlassian's Marketplace security bug fix policy for cloud apps: critical within 10 days, high within 4 weeks. See the security policy.