Frequently Asked Questions

SealDoc is an electronic signature and audit trail app for Atlassian Jira and Confluence. It lets teams sign Jira issues and Confluence pages with tamper-evident, hash-chained audit trails. It is designed for internal document control and approval workflows in regulated industries (pharma, medtech, automotive, aerospace).

No. SealDoc is designed for internal document control — signing off on requirements, design documents, test protocols, SOPs, and similar artifacts within your Jira and Confluence instance. It is not designed for external-party contract signing, wet-ink replacement, or notarization. If you need external parties to sign contracts, use a dedicated contract signing service.

SealDoc supports Jira Cloud (all project types: company-managed and team-managed) and Confluence Cloud (page signing via the page actions menu). Jira Service Management (Cloud) issues are also fully supported since they are standard Jira issues. SealDoc does not support Jira Data Center, Jira Server, or Confluence Data Center/Server — it runs exclusively on Atlassian Forge (Cloud only). Note: permission group behavior may differ slightly between company-managed and team-managed projects due to Jira's different permission models.

All SealDoc data is stored within Atlassian's infrastructure — Forge SQL for structured data and Forge Storage for configuration. SealDoc does not operate external servers, databases, or APIs. No data leaves the Atlassian platform. See the Privacy Policy for details.

Uninstalling SealDoc permanently deletes all Forge SQL and Forge Storage data (signatures, audit trail, settings, PINs). This action is irreversible. Your Jira issues and Confluence pages are not affected. Always export your audit trail before uninstalling.

No. SealDoc provides simple electronic signatures as defined by eIDAS Art. 3(10), with optional controls aligned to Art. 26 (advanced electronic signature requirements). SealDoc is not an Advanced Electronic Signature (AES) or Qualified Electronic Signature (QES) provider. QES requires a Qualified Trust Service Provider (QTSP) and a qualified signature creation device per eIDAS Art. 3(12) and Annex II. See the compliance mapping for the full eIDAS breakdown.

SealDoc provides the technical controls that 21 CFR Part 11 requires: two-component signing (§11.200), tamper-evident audit trails (§11.10(e)), content hash integrity (§11.70), separation of duties (§11.10(g)), and authority checks (§11.10(f)). However, compliance is not a property of the software alone — it requires your organization's validation program, SOPs, training, and procedural controls. SealDoc provides the tools; your quality system provides the compliance framework. See Validation Support for guidance.

21 CFR Part 11 §11.200(a)(1) requires "at least two distinct identification components" for electronic signatures. In SealDoc, the two components are: (1) the user's Jira session identity (who you are, managed by Atlassian SSO/2FA/SAML) and (2) a personal signing PIN (something you know, verified by SealDoc). This is not the same as multi-factor authentication (MFA) — it is a regulatory signing requirement specific to Part 11.

SealDoc provides safety classification labeling (ASIL, DAL, Risk Class, or custom schemes) and per-class approval rules that enforce minimum signers based on assigned safety level. These standards require much more than labeling — they mandate hazard analysis, failure mode analysis, tool qualification, and comprehensive safety lifecycle processes. SealDoc supports the classification and sign-off aspects; your organization's safety management system handles the rest.

SealDoc's audit trail is tamper-evident, not immutable in the strict sense. The underlying Forge SQL database is managed by Atlassian and is technically mutable at the infrastructure level. What SealDoc guarantees is detection: every audit entry is linked in a SHA-256 hash chain, and the chain is periodically sealed with HMAC-SHA256. If any entry is modified, inserted, or deleted, the chain validation tool will detect the tampering. This is the standard approach for application-level audit trails in regulated environments.

SealDoc stores: Atlassian account IDs, display names, signing PIN hashes (PBKDF2-SHA512, never plaintext), signer affirmation text (typed name), signature metadata (meaning, comment, timestamp), and audit trail entries. No analytics, cookies, or telemetry. See the Privacy Policy for the complete list.

SealDoc anonymizes the user's display name in audit trail entries and signature records. The hash chain is preserved because account IDs (pseudonymous identifiers) and signer affirmation text (hash chain inputs) are retained under GDPR Art. 17(3) exemptions. The result: the person is no longer identifiable by name, but the audit trail's cryptographic integrity remains intact. See the Privacy Policy for details.

Yes. A standard DPA covering GDPR Article 28 requirements is available at /sealdoc/dpa. It covers processing scope, sub-processors (Atlassian only), security measures, breach notification, data subject rights, and audit provisions.

When a document is signed, SealDoc computes a SHA-256 hash of the document's content at that moment. For Jira issues, this covers: summary, description, status, priority, attachment metadata (filenames and sizes), and safety classification. Attachment file content is not hashed due to Forge runtime constraints. For Confluence pages, the hash covers: page title and body content. Embedded macro output, external images, attached files, comments, and page version history are not included in the Confluence hash. See the signatures documentation for the full scope.

All active signatures are automatically revoked, and the document's approval status reverts to Draft. This "revert on edit" behavior prevents stale approvals and is required by 21 CFR Part 11 §11.10(c) and EU Annex 11 §10. The revocation is logged in the audit trail.

Yes. SealDoc supports multi-person sign-off with different signature meanings (Approved, Reviewed, Verified, Witnessed, Authored, Acknowledged). You can configure a minimum number of signers required for approval. Separation of duties is enforced — the person who submits cannot be the sole approver.

Yes. SealDoc works with all Jira issue types — standard types (Bug, Task, Story, Epic, Sub-task) and custom issue types. Signing is available for any issue regardless of type. The content hash scope (summary, description, status, priority, attachments, safety classification) is the same across all issue types.

SealDoc runs on Atlassian Forge, which imposes: 25-second execution timeout per function invocation (batch signing limited to 10 documents), 10 GB storage per app per site (monitor with retention policy), 100 concurrent invocations per product per site, and 1–3 second cold starts after inactivity. See Platform Constraints for details.

Yes, optionally. SealDoc supports ECDSA and Ed25519 digital signatures where the private key is generated and held client-side. This provides stronger cryptographic non-repudiation than PIN-based signing. PKI is optional — organizations can use PIN-only signing if PKI is not required by their regulatory framework.

SealDoc supports 11 languages: English (US), English (GB), French, German, Spanish, Japanese, Korean, Chinese (Simplified), Portuguese (Brazil), Italian, and Dutch. The language is automatically detected from your Jira locale.

SealDoc is available on the Atlassian Marketplace with per-user monthly pricing. See the Marketplace listing for current rates, free trial availability, and volume discounts.

Trial availability is managed through the Atlassian Marketplace. Check the Marketplace listing for current trial options.