Validation Support
Regulated industries require that computerized systems be validated before use (21 CFR Part 11, EU Annex 11 §3, GAMP 5). This page provides the system description, qualification guidance, and supporting documentation to help your organization complete its validation activities for SealDoc.
Note: Validation is your organization's responsibility. SealDoc provides the technical controls and documentation described here to support your validation program. These materials do not constitute validation evidence on their own — they are inputs to your validation process.
System Description
SealDoc is an electronic signature and audit trail application for Atlassian Jira and Confluence. It is classified as a GAMP Category 4 (configured product) system.
| Attribute | Description |
|---|---|
| System name | SealDoc for Jira |
| Vendor | Maciej Jezierski (be4.software) |
| Platform | Atlassian Forge (serverless runtime within Atlassian Cloud) |
| Data storage | Forge SQL (MySQL-compatible) for structured data; Forge Storage (key-value) for configuration |
| Infrastructure | Atlassian-managed. Atlassian Cloud is SOC 2 Type II certified (Atlassian's certification, not SealDoc's) — see Atlassian Trust Center |
| External dependencies | None — no external servers, APIs, databases, or data egress |
| Authentication | Atlassian-managed identity (SSO/2FA/SAML). SealDoc adds a signing PIN as a second identification factor for the signing ceremony. |
| Deployment model | SaaS — deployed via Atlassian Marketplace, updated by the vendor. Customer cannot modify application code. |
| GAMP category | Category 4 — Configured Product |
System Boundaries
SealDoc operates within the Atlassian Forge sandbox. The system boundary includes:
- Inputs: Jira issue data (summary, description, status, priority, attachments, custom fields), Confluence page content, user identity (Atlassian account ID), signing PIN, user actions (sign, approve, reject, revoke, configure).
- Processing: Content hash computation (SHA-256), PIN verification (PBKDF2-SHA512), hash chain maintenance, HMAC chain sealing, approval state machine, separation of duties enforcement.
- Outputs: Signature records, audit trail entries, approval status, CSV/PDF exports, chain validation results.
- Interfaces: Jira REST API (read issue data), Confluence REST API (read page data), Forge SQL (read/write), Forge Storage (read/write). No outbound network calls.
Data Flow
- User opens a Jira issue or Confluence page containing the SealDoc panel.
- SealDoc reads document content via the Jira/Confluence REST API.
- User initiates a signing ceremony: selects meaning, affirms identity, enters PIN.
- SealDoc computes a SHA-256 content hash of the document, verifies the PIN, checks separation of duties and account status.
- Signature record is written to Forge SQL. An audit trail entry is appended to the hash chain. The chain seal (HMAC) is updated.
- If the document is later edited, SealDoc receives a Forge event, revokes active signatures, and logs the revert in the audit trail.
Qualification Guidance (IQ/OQ/PQ)
The following guidance helps your validation team develop Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) protocols for SealDoc.
Installation Qualification (IQ)
IQ verifies that the system is installed correctly and operates in a suitable environment.
| Check | Expected Result | How to Verify |
|---|---|---|
| App installed from Atlassian Marketplace | SealDoc appears in Jira Administration → Apps | Navigate to Jira admin, confirm SealDoc is listed and active |
| Forge modules active | Issue panel, project page, and admin page are accessible | Open a Jira issue and confirm the SealDoc panel appears in the sidebar |
| Forge SQL provisioned | Database tables created (signatures, audit_log, entity_status, user_signing_pins, user_signing_keys) | Perform a test signing and verify audit entries are recorded |
| Version matches expected | Installed version matches the validated version | Check version in Jira Administration → Apps → SealDoc |
| Permissions configured | Default permission groups (sign-sealdoc, audit-sealdoc, manage-sealdoc) are active | Check Admin → SealDoc → Permissions tab |
Operational Qualification (OQ)
OQ verifies that the system operates correctly within its specified parameters.
| Test | Expected Result |
|---|---|
| Create signing PIN (4-6 digits) | PIN accepted, confirmation shown |
| Reject non-numeric or wrong-length PIN (e.g., "abc", "12") | PIN rejected with error message |
| Sign a Jira issue with valid PIN | Signature recorded with content hash, audit entry created |
| Sign with incorrect PIN (3 times) | Account locked for 15 minutes after 3rd failure |
| Self-revoke a signature | Signature marked as revoked, audit entry logged |
| Edit a signed issue | All signatures auto-revoked, status reverts to Draft |
| Submit for review, approve with quorum | Status transitions Draft → In Review → Approved |
| Reject a document in review | Status reverts to Draft, rejection reason logged |
| Separation of duties (submitter tries to approve) | Approval blocked with error message |
| Assign safety classification | Classification saved, per-class rules enforced |
| Export audit trail as CSV | CSV file downloaded with all fields and hash chain data |
| Export audit trail as PDF | PDF file downloaded with formatted audit table |
| Run chain validation | Validation passes with no integrity errors |
| GDPR erasure request | Display names anonymized, hash chain intact |
| Batch sign multiple issues | All issues signed with individual content hashes |
Performance Qualification (PQ)
PQ verifies that the system performs correctly under real-world conditions over time.
| Test | Expected Result |
|---|---|
| Sign 10+ documents across multiple projects | All signatures recorded correctly, no data loss |
| Multiple users signing concurrently | No race conditions, all audit entries maintain hash chain integrity |
| Chain validation after 50+ audit entries | Validation passes, no gaps or hash mismatches |
| PIN expiry after configured period | User prompted to create new PIN, old PIN no longer accepted |
| Hourly HMAC seal checkpoint | Seal entries present in audit log at scheduled intervals |
Risk Management
SealDoc's risk management approach is guided by ICH Q9 (Quality Risk Management) and GAMP 5 principles. Key risks and mitigations:
| Risk | Impact | Mitigation |
|---|---|---|
| Unauthorized signature | Regulatory non-compliance | Two-component signing (session + PIN), account active verification, separation of duties |
| Audit trail tampering | Loss of data integrity | Hash-chained entries (SHA-256), HMAC sealing, append-only storage, gap detection |
| Stale approval on modified content | Approved document no longer matches signed version | Auto-revert on edit: all signatures revoked when content changes |
| PIN compromise | Unauthorized signing by impersonator | PBKDF2-SHA512 hashing (600K iterations), 3-attempt lockout, 180-day expiry, admin force-expire |
| Data loss | Loss of signatures and audit trail | Atlassian Forge infrastructure with built-in backup/redundancy (see Backup & Recovery below) |
| Deactivated user signing | Signature from unauthorized person | Account active check before every signing ceremony (fail-closed) |
| Self-approval | Insufficient review | Separation of duties enforcement (person-level or department-level) |
Vendor Quality Statement
EU Annex 11 §3 requires that regulated companies assess their software suppliers. The following information supports your vendor qualification process:
| Attribute | Description |
|---|---|
| Vendor | Maciej Jezierski, trading as be4.software |
| Location | Radwanice, Poland (EU) |
| Development practices | Version-controlled source code (Git), automated testing (unit and integration tests via Vitest), TypeScript strict mode, code review before release |
| Testing | Automated test suite covering content hash computation, permission enforcement, settings validation, and entity property sync. Manual verification against OQ test cases before each release. |
| Release process | Deployed through the Atlassian Marketplace. Each release is version-numbered and tested against the OQ test cases. Schema migrations are additive and do not delete existing data. |
| Security | SealDoc has not undergone an independent third-party security audit or penetration test. The application runs within the Atlassian Forge sandbox, which limits its attack surface. PIN storage uses PBKDF2-SHA512 with 600K iterations. |
| Support | Available via contact@be4.software and the support portal. |
Change Control
SealDoc is a vendor-managed application deployed through the Atlassian Marketplace. Changes are managed as follows:
- Application updates — new versions are deployed by the vendor through the Atlassian Marketplace. Updates are applied automatically by Atlassian Forge — there is no option to defer or schedule updates at the customer level. Each version is tested against the OQ test cases before release. Organizations that require controlled change windows should monitor the changelog and re-execute critical OQ test cases after each update. Contact support if you need advance notification of upcoming releases.
- Configuration changes — admin settings changes (signature policies, safety schemes, permissions) are logged in the audit trail with the administrator's identity, timestamp, and old/new values.
- Database schema changes — schema migrations are applied automatically on app startup. Migrations are additive (new tables, new columns) and do not delete existing data.
- Customer responsibility — your organization should maintain a change control record for SealDoc updates as part of your computerized systems inventory. Record the version number, date of update, and any re-validation activities performed.
Backup & Recovery
SealDoc data is stored entirely within Atlassian Forge infrastructure. Backup and recovery are handled by Atlassian:
- Forge SQL — Atlassian provides infrastructure-level redundancy for Forge SQL databases. Atlassian does not publish specific recovery point objectives (RPO) or recovery time objectives (RTO) for Forge SQL. Refer to the Atlassian Trust Center for current infrastructure guarantees.
- Forge Storage — configuration data stored in Forge key-value storage follows Atlassian's standard durability guarantees.
- No SealDoc-managed backups — because SealDoc runs entirely on Forge with no external infrastructure, there are no vendor-managed backup systems. All durability guarantees come from Atlassian.
- Export for offline backup — administrators can export the audit trail as CSV or PDF at any time. We recommend periodic exports as part of your organization's backup procedures.
- Uninstallation — uninstalling SealDoc removes all Forge SQL and Forge Storage data. This action is irreversible. Export your audit trail before uninstalling.
For Atlassian's current infrastructure SLAs and data protection commitments, refer to Atlassian Trust Center.
Business Continuity
SealDoc's availability depends on the Atlassian Forge platform:
- If Forge is unavailable — SealDoc will be unavailable. Signatures cannot be collected or verified until Forge is restored. Existing Jira issues and Confluence pages remain accessible through Jira/Confluence directly.
- If the app is deactivated — SealDoc data remains in Forge SQL and can be restored by reactivating the app. No data is lost during deactivation.
- If the vendor ceases operations — SealDoc runs as a standard Forge app. The application code is deployed to Atlassian's infrastructure. Atlassian's Marketplace policies govern continued access to installed apps if a vendor becomes inactive. Your data remains in Forge SQL as long as the app is installed.
- Recommended precaution — maintain periodic CSV/PDF exports of your audit trail as an offline record independent of the SealDoc application.
Periodic Review
EU Annex 11 §11 requires that computerized systems be periodically evaluated to confirm they remain in a validated state. Recommended review activities for SealDoc:
| Activity | Frequency | Description |
|---|---|---|
| Chain validation | Monthly | Run the built-in chain validation tool from the project page. Verify that all hash chain and HMAC checks pass. |
| Audit trail review | Quarterly | Review the audit trail for unexpected actions (unauthorized signatures, unusual revocations, configuration changes). |
| Version check | After each update | Verify the installed version matches the latest validated version. Re-execute critical OQ test cases if the update includes functional changes. |
| Permission review | Quarterly | Verify that permission groups (sign-sealdoc, audit-sealdoc, manage-sealdoc) are assigned to the correct users and groups. |
| PIN hygiene | Semi-annually | Review PIN expiry settings. Force-expire PINs for users who have left the organization. |
| Export verification | Semi-annually | Export the audit trail as CSV and verify that the exported data is complete and the hash chain can be independently verified. |
Known Limitations
The following limitations are inherent to SealDoc's architecture and should be documented in your validation protocol:
| Limitation | Details | Mitigation |
|---|---|---|
| Timestamp source | Audit entry timestamps are generated server-side by the Forge runtime clock (UTC). There is no independent time stamping authority (TSA) or NTP attestation. The timestamp cannot be independently verified against an external time source. | The Forge runtime clock is managed by Atlassian's infrastructure. For organizations requiring an independent timestamp authority, document this limitation in your validation protocol and consider periodic cross-referencing with external records. |
| Signature format | Signatures are stored as structured database records in Forge SQL, not in a standardized long-term signature format (PAdES, XAdES, CAdES). Signature records are verifiable within SealDoc but are not portable to external signature verification tools. | Export audit trails as CSV for offline archival. Content snapshots provide a record of what was signed. |
| Forge SQL data residency | Forge SQL data hosting location is determined by Atlassian and may differ from the Jira Cloud instance's data residency setting. The customer cannot control or verify the physical location of Forge SQL data. | Refer to Atlassian Trust Center for current Forge infrastructure details. Document this in your data residency assessment. |
| Confluence content hash scope | For Confluence pages, the content hash covers page title and body content only. Embedded macro output, external images, attached files, comments, and page version history are not included. | Document which Confluence content is covered by the hash in your signing SOPs. Avoid relying on embedded macro output for signed content. |
| Attachment file content | For Jira issues, attachment filenames and sizes are included in the content hash, but attachment file content is not hashed due to Forge runtime constraints. | If attachment integrity is critical, implement procedural controls (e.g., separate checksums for attached files documented in the issue description). |
Platform Constraints
SealDoc runs on Atlassian Forge, which imposes certain platform-level constraints that may affect high-volume installations:
| Constraint | Limit | Impact |
|---|---|---|
| Execution timeout | 25 seconds per function invocation | Batch signing is limited to 10 documents per request to stay within this budget. Large audit trail exports are paginated internally (5,000 rows per batch, 100,000 row safety cap). |
| Storage limit | 10 GB per app per site (Forge SQL) | High-volume installations should configure a retention policy and monitor storage usage. Indefinite retention is the default but may not be sustainable for sites with thousands of daily audit entries. |
| Invocation concurrency | 100 concurrent invocations per product per site | Heavy concurrent usage (many users signing simultaneously) may result in errors. Users should retry after a brief wait. |
| Cold starts | 1–3 seconds on first invocation | The first signing ceremony after a period of inactivity may be slower than subsequent operations. |
Jira Issue Deletion
If a Jira issue that has been signed is deleted by a Jira administrator:
- Signature records are preserved — all signature records and audit trail entries remain in Forge SQL. They reference the original issue key and ID.
- Audit trail integrity is maintained — the hash chain is not affected by issue deletion because signature data is stored independently in Forge SQL, not on the Jira issue itself.
- Content cannot be re-verified — because the Jira issue no longer exists, the content hash cannot be recomputed for comparison. The stored content snapshot remains as the record of what was signed.
- Recommendation — in regulated environments, avoid deleting Jira issues that have been signed. If deletion is required, export the audit trail for the affected issue before deletion.
Multi-Site Isolation
SealDoc data is isolated per Jira Cloud site. Each site has its own Forge SQL database and Forge Storage instance. There is no data sharing between sites. If your organization has multiple Jira Cloud instances, each instance runs an independent copy of SealDoc with its own signatures, audit trail, settings, and HMAC sealing key.
Compatibility
SealDoc is compatible with the following Atlassian products:
- Jira Cloud — all project types (company-managed and team-managed). SealDoc works identically in both.
- Confluence Cloud — page signing via the page actions menu.
- Jira Service Management (Cloud) — JSM issues are standard Jira issues and are fully supported for signing.
SealDoc is not compatible with:
- Jira Data Center — Forge apps run exclusively on Atlassian Cloud.
- Jira Server — Server deployments are not supported by the Forge platform.
- Confluence Data Center / Server — same as above.