Runs on Atlassian Forge
Compliance mapping
SealDoc provides the technical controls — hash-chained audit trails, two-component signing, and approval workflows — to support your compliance program.
Feature to compliance mapping
Every compliance-relevant SealDoc feature mapped to the standards it satisfies
| SealDoc Feature | What It Does | Regulatory Requirement |
|---|---|---|
| Electronic Signatures | Multi-person sign-off with meaning (Approved / Reviewed / Verified / Witnessed / Authored / Acknowledged), signer identity, comment, and timestamp. | Supports 21 CFR Part 11 §11.50, §11.100, eIDAS Art. 3(10), EU Annex 11 §14 |
| Signing PIN | PBKDF2-SHA512 hashed PIN as second identification factor. 3-attempt lockout (15 min), 180-day expiry, transparent rehashing. | 21 CFR Part 11 §11.200(a)(1) — two distinct identification components |
| Signer Affirmation | Signer types their full name to affirm intent before signing. Combined with signature meaning to capture why. | 21 CFR Part 11 §11.200(a)(1) — intent affirmation, eIDAS Art. 3(10) |
| Tamper-Evident Audit Trail | Application-enforced insert-only log of every sign, approve, reject, revoke, classify, and configure action. Per-entry hash chain with gap detection. Insert-only behavior is enforced at the application layer; the underlying Forge SQL database is managed by Atlassian. | 21 CFR Part 11 §11.10(e), EU Annex 11 §9 |
| Content Hash | SHA-256 hash of document content captured at signing time. Jira issues: summary, description, status, priority, attachment metadata (filenames and sizes), and safety class. Attachment file content is not hashed due to Forge runtime constraints. Confluence pages: page title and body content. Embedded macro output, external images, attached files, comments, and page version history are not included. See Signatures docs for full scope. | 21 CFR Part 11 §11.70, EU Annex 11 §7 — signature/record linking |
| HMAC Chain Sealing | Periodic HMAC-SHA256 checkpoint of the audit chain. Fires after every write + hourly scheduled seal. Detects retroactive tampering. | EU Annex 11 §7, §9 — data integrity verification |
| Approval Workflow | Draft → In Review → Approved state machine. Configurable minimum signers quorum. Auto-revert to Draft on content edit. | 21 CFR Part 11 §11.10(f), EU Annex 11 §14 — authority checks |
| Revert on Edit | All signatures are automatically revoked when the signed content changes. Prevents stale approvals on modified documents. | 21 CFR Part 11 §11.10(c), EU Annex 11 §10 — change control |
| Safety Classification | Supports safety classification labeling for organizations following ISO 26262, DO-178C, or IEC 62304. Per-document ASIL, DAL, Risk Class, or custom scheme. Per-class approval rules enforce minimum signers based on assigned safety level. These standards require comprehensive safety lifecycle processes beyond what SealDoc provides — SealDoc supports the classification and sign-off aspects only. | Supports labeling used in ISO 26262, DO-178C, and IEC 62304 environments |
| Separation of Duties | Configurable submitter ≠ approver enforcement at person-level or department-level. When independence is enabled, self-approval is blocked. | 21 CFR Part 11 §11.10(g), EU Annex 11 §12 — security |
| GDPR Erasure | Anonymize signer display names while preserving hash chain integrity. Compliant data erasure without breaking the audit trail. | GDPR Art. 17 — right to erasure |
| Data Residency | All data stored within Atlassian infrastructure (Forge + SQL). No external API calls, no data egress. | GDPR Art. 44-49, data sovereignty requirements. Atlassian Cloud infrastructure is SOC 2 Type II certified (Atlassian's certification) |
| Retention Policy | Configurable audit log retention period. Data preserved according to organizational retention requirements. | 21 CFR Part 11 §11.10(c), GDPR Art. 5(1)(e) — storage limitation |
How SealDoc maps to your standard
Detailed mapping for the four regulatory frameworks SealDoc addresses
21 CFR Part 11 FDA
21 CFR Part 11 defines FDA requirements for electronic records and electronic signatures. SealDoc addresses the key provisions:
| Section | Requirement | SealDoc Feature |
|---|---|---|
| §11.10(a) | Validation of systems to ensure accuracy, reliability, and performance | SealDoc provides system documentation, test protocols, and qualification guidance to support your organization's §11.10(a) validation program. See Validation Support |
| §11.10(b) | Ability to generate accurate and complete copies of records | Audit trail export as CSV (tabular, all fields including hash chain data) and PDF (formatted report). Content snapshots stored with each signature. |
| §11.10(c) | Protection of records to enable accurate retrieval | Content hash captures document state at signing; revert on edit prevents stale approvals |
| §11.10(d) | Limiting system access to authorized individuals | Authentication managed by Atlassian (SSO/2FA/SAML). SealDoc adds permission groups (sign-sealdoc, audit-sealdoc, manage-sealdoc) scoped to Jira groups |
| §11.10(e) | Secure, computer-generated, time-stamped audit trail | Insert-only audit log with hash chain, per-entry server-generated timestamp (Forge runtime clock, no independent TSA — see Known Limitations) and user |
| §11.10(f) | Operational system checks to enforce sequencing | Approval workflow state machine (Draft → In Review → Approved) |
| §11.10(g) | Authority checks — only authorized individuals sign | Separation of duties + account active verification |
| §11.50 | Signed electronic records — signer identification | E-signatures with account ID, display name, meaning, timestamp |
| §11.70 | Signature/record linking | Content hash (SHA-256) binds signature to document snapshot |
| §11.100 | General requirements for electronic signatures | Unique to individual signer, cannot be reused or reassigned |
| §11.200(a)(1) | At least two distinct identification components | Jira session (identity component) + signing PIN (knowledge component). Signer affirmation (typed name) captures intent as a separate §11.200(a)(1) requirement |
| §11.300 | Controls for identification codes/passwords — uniqueness, periodic revision, loss/compromise procedures | PINs are personal to each user (one PIN per Jira account), expire after 180 days (configurable), 3-attempt lockout with 15-minute cooldown, admin force-expire for compromised/departing users |
EU Annex 11 GMP
EU Annex 11 provides guidelines for computerized systems in GMP environments. SealDoc addresses data integrity and electronic signature requirements:
| Section | Requirement | SealDoc Feature |
|---|---|---|
| §3 | Supplier and service provider assessment | SealDoc is a vendor-managed Forge app. A vendor quality statement is available to support your supplier assessment process |
| §4 | Validation — evidence that the system meets its requirements | IQ/OQ/PQ qualification guidance, system description, risk assessment, and test protocols are provided in the Validation Support documentation |
| §5 | Data — entry and amendment noted with identification of operator | SealDoc records the identity of the user who signs, approves, rejects, revokes, or configures. Data entry tracking for Jira issue fields (summary, description, etc.) is handled by Jira's own audit log, outside SealDoc's system boundary |
| §6 | Accuracy checks — critical data entered should have an additional check | Content hash (SHA-256) verifies document accuracy at signing time. Chain validation tool independently recomputes and verifies all audit entry hashes |
| §7 | Data storage — integrity verification | Hash chain with per-entry SHA-256 hashing; HMAC sealing for chain-wide integrity |
| §7.1 | Data protected against damage by physical and electronic means | All data on Atlassian Forge infrastructure. Atlassian Cloud is SOC 2 Type II certified (Atlassian's certification, not SealDoc's) — see Atlassian Trust Center |
| §8 | Printouts — ability to obtain clear printed copies of data | Audit trail exportable as PDF (formatted report) and CSV (tabular data). Content snapshots viewable and printable from the SealDoc UI |
| §9 | Audit trail — chronological, not alterable | Insert-only audit log, gap detection via previous_entry_hash |
| §10 | Change management — any changes traceable | Revert on edit auto-revokes signatures; every change logged in audit trail |
| §11 | Periodic evaluation — confirm system remains in a validated state | Built-in chain validation tool, recommended monthly review schedule, periodic review guidance in Validation Support |
| §12 | Security — physical and logical access controls | Separation of duties, signing PIN, account active verification |
| §14 | Electronic signatures — equivalent to handwritten | Multi-meaning signatures with signer identity, affirmation, and timestamp |
| §17 | Archiving — data retrieval throughout retention period | Configurable retention policy; data stored in Forge SQL. Note: uninstalling SealDoc deletes all Forge SQL data — export audit trails before uninstalling |
eIDAS EU
eIDAS (EU Regulation 910/2014) establishes a legal framework for electronic signatures across the European Union. SealDoc provides electronic signatures as defined by Art. 3(10), with controls partially aligned to Art. 26 requirements for advanced electronic signatures (AES). SealDoc does not itself constitute an AES or QES provider — advanced electronic signatures require signature creation data under the signatory's sole control (Art. 26(c)), and qualified electronic signatures (QES) require a Qualified Trust Service Provider (QTSP) and a qualified signature creation device per Art. 3(12) and Annex II. SealDoc includes provisional PKI infrastructure (ECDSA/Ed25519 key registration) that is not yet integrated into the standard signing UI. Organizations requiring AES or QES should not rely on this feature for Art. 26(c) compliance at this time.
| Article | Requirement | SealDoc Feature |
|---|---|---|
| Art. 3(10) | Electronic signature definition — data in electronic form attached to other data | Signature records stored as structured data linked to signed content via hash |
| Art. 25(1) | Legal effect — not denied legal effect solely on electronic form | Signatures include signer identity, meaning, timestamp, and content hash |
| Art. 26(a) | Uniquely linked to the signatory | Signatures bound to Jira account ID (Atlassian-managed identity) |
| Art. 26(b) | Capable of identifying the signatory | Signer affirmation (typed name) + Jira account identity |
| Art. 26(c) | Created using data under the signatory's sole control | The signing PIN is personal to the signer, but is verified server-side on Forge — this does not constitute "sole control" in the strict Art. 26(c) sense. SealDoc includes provisional PKI key registration (ECDSA/Ed25519) with client-side key generation. This feature is not yet available through the standard signing ceremony. Organizations should not rely on this for Art. 26(c) compliance at this time. |
| Art. 26(d) | Linked to data so that subsequent changes are detectable | Content hash (SHA-256) + HMAC chain sealing detect any post-signature modification |
GDPR EU Data Protection
GDPR governs personal data processing. SealDoc minimizes data collection and provides compliant erasure that preserves audit trail integrity:
| Article | Requirement | SealDoc Feature |
|---|---|---|
| Art. 5(1)(c) | Data minimization | Only stores account ID, display name, and signing data — no additional PII |
| Art. 5(1)(e) | Storage limitation | Configurable retention policy for audit log entries |
| Art. 5(1)(f) | Integrity and confidentiality | Hash chain + HMAC sealing ensure data integrity; Forge sandboxing for confidentiality |
| Art. 17 | Right to erasure (right to be forgotten) | GDPR erasure anonymizes display names while preserving hash chain integrity. For customers subject to regulatory frameworks (e.g. 21 CFR Part 11, EU Annex 11), pseudonymous identifiers and hash chain inputs are retained under Art. 17(3)(b) (legal obligation). For other customers, retention is justified under Art. 17(3)(e) (establishment, exercise or defence of legal claims) |
| Art. 25 | Data protection by design and by default | No external servers, no analytics, no cookies — all data on Atlassian Forge |
| Art. 44-49 | Transfers of personal data to third countries | Data processed within Atlassian Forge infrastructure — no third-party data transfers. Forge hosted storage respects the customer's Atlassian Cloud data residency setting. |