Security Statement

Last updated: 2026-05-31

Infrastructure and data residency​

Attestsys apps process and store all customer data exclusively on Hetzner Cloud infrastructure in Nuremberg, Germany (EU). No customer data is transferred to or stored in the United States or any other non-EU jurisdiction.

• Provider: Hetzner Online GmbH, Nuremberg, Germany
• Certification: BSI C5 Type 2 (German Federal Office for Information Security cloud security attestation), ISO 27001:2022
• Data residency claim: EU only at launch. Customers requiring US or APAC residency must contact us for an Enterprise contract.
• Legal framework: German and EU law only. No US CLOUD Act exposure — Hetzner is a German company with no US parent.

Encryption​

In transit​

All connections between Jira clients (via the Atlassian Forge platform) and the Attestsys backend use TLS 1.2 or higher. The backend API is served on a dedicated EU-hosted endpoint with HSTS enabled.

At rest​

All data stored on the Attestsys backend is encrypted at rest using AES-256 in GCM mode (envelope encryption for cryptographic key material), running on Hetzner Cloud infrastructure in Nuremberg, Germany.

Cryptographic key material​

ECDSA private keys (per-tenant signing keys) are stored with AES-256-GCM envelope encryption. The key-encryption key (KEK) is held separately from the wrapped key material. Private keys are loaded into memory only for the duration of a signing operation, then immediately zeroized from memory (set to zero bytes before GC eligibility).

Authentication​

Forge Invocation Token (FIT) validation​

All requests from the Atlassian Forge platform to the Attestsys Forge Remote backend are authenticated using Forge Invocation Tokens (FITs). The backend validates every FIT as a signed JWT against Atlassian's published JWKS endpoint (https://forge.cdn.prod.atlassian-dev.net/.well-known/jwks.json) on every incoming request. Requests with missing, expired, or invalid FITs are rejected with HTTP 401.

This satisfies the Atlassian Cloud Security Requirements for Marketplace apps (normative "must" language).

Ingestion credentials (HMAC)​

Event ingestion from the Forge app to the backend uses HMAC-based credentials. HMAC keys are:

• Stored with AES-256-GCM envelope encryption at rest
• Never logged
• Compared using constant-time comparison to prevent timing attacks
• Zeroized from memory immediately after use

Operator endpoints​

Sensitive operator-only endpoints (e.g., GDPR tenant erasure) are protected by a separate operator credential, held only by the Attestsys operations team and never exposed to customers.

Data egress from Atlassian infrastructure​

Attestsys apps use Forge Remote — Jira event data is forwarded from the Atlassian Forge platform to the Attestsys backend on Hetzner Cloud for cryptographic processing and storage. This constitutes data egress from Atlassian's infrastructure.

What data leaves Atlassian infrastructure:

• Jira event payloads: event type, issue key, actor accountId, timestamp, and changed field values (as produced by Jira's event webhook system)
• Jira workspace identifier (cloudId)

What does not leave Atlassian infrastructure:

• Jira issue descriptions, attachment content, or comment text beyond what the Jira webhook event payload contains

All egressed data is processed exclusively on Hetzner Cloud EU infrastructure (see above) and is subject to the Data Processing Agreement.

Because Attestsys uses Forge Remote, the app does not qualify for Atlassian's Runs on Atlassian trust badge. We consider EU-only data residency on certified German infrastructure (BSI C5 Type 2 + ISO 27001:2022) to be a stronger trust signal for compliance-focused customers than the RoA badge, which carries no geographic data residency guarantee.

Cryptographic evidence chain security​

The cryptographic evidence chain is an additional security property — not just a product feature. See Cryptographic Verification for full technical detail.

Key security properties:

• Per-entry signing: each audit entry is individually ECDSA-signed (P-256, RFC 6979 deterministic)
• Hash chaining: each entry contains the SHA-256 hash of the previous entry's signed payload — any past modification is mathematically detectable
• RFC 3161 trusted timestamping: timestamps are issued by independent third-party timestamp authorities, not by the Attestsys server clock. Every event gets a per-event non-qualified timestamp from a public RFC 3161 TSA (such as FreeTSA or DigiCert), clearly labelled. Paid tiers add a daily qualified checkpoint over the audit chain from a Qualified Trust Service Provider on the EU Trusted List (e.g. QuoVadis Trustlink B.V. NL, GlobalSign nv-sa BE); Enterprise adds per-event qualified timestamping with a selectable QTSP.
• Insert-only audit table: chain entries are never updated or deleted — corrections and redactions are appended as new entries, preserving chain continuity
• GDPR erasure compatibility: tenant key erasure tombstones the signing key and appends a signed tombstone entry before key deletion, preserving chain continuity while enabling GDPR compliance

GDPR and data subject rights​

Attestsys acts as a data processor under Regulation (EU) 2016/679 (GDPR) for all customer data. The data controller is the customer (the Jira workspace administrator).

Data subject rights (erasure, access, portability, restriction) are handled as follows:

• Audit chain entries are never deleted in response to data subject requests — deletion would break the cryptographic chain. Instead, a signed redaction marker is appended to the chain
• Personal identifiers in chain entries (Atlassian accountIds) can be identified and reported via the Atlassian Personal Data Reporting implementation on a cycle of at most 7 days
• Full tenant erasure (key tombstoning + credential revocation) is available on request for GDPR Art. 17 compliance

A full Data Processing Agreement is available on request.

"Doesn't keeping records with an outside vendor create risk?"​

A fair question — security teams are rightly wary of shipping internal data to a third party. Three facts about how Attestsys is built address it:

1. We are not a log-management system and do not take custody of your logs. Attestsys records Jira workflow events (issue created / changed / commented — the fields listed in our privacy policy), not your server logs, source code, or infrastructure telemetry. The blast radius of the data we hold is deliberately narrow.
2. Verification does not require trusting Attestsys. Every export bundle is verified offline by the included verify.html — signatures, hash chain, and RFC 3161 timestamps check out in the recipient's browser with no network calls to us. The point of the design is that the relying party doesn't have to take our word (or our availability) for anything. The RFC 3161 timestamps themselves come from independent Timestamp Authorities, not from Attestsys clocks.
3. EU residency + retention control. All processing stays on EU infrastructure (Hetzner, Nuremberg), and event payload bytes are deletable under your retention policy — only the cryptographic envelope (signature, chain linkage, timestamp token) is kept so the chain remains verifiable.

In short: an internal log server with separated admin access is a good answer for internal accountability. Attestsys exists for the moment the audience is outside your trust boundary — and for that audience, independent verifiability is the property that matters, not where the copy sits.

Vulnerability disclosure​

To report a security vulnerability, contact security@attestsys.com. We respond in accordance with the Atlassian Security Bug Fix Policy for Marketplace apps (Critical 10 days, High 4 weeks, Medium 12 weeks, Low 25 weeks).

Sub-processors​