Tamper-evident configuration governance for Jira Cloud.

What SPHIOR Ledger does#

Jira configuration drifts constantly — workflows, schemes, permissions, custom fields, projects, and screens change, and after a while nobody remembers who changed what or why. SPHIOR Ledger answers three questions, continuously and automatically:

• What changed, when, and (when the audit log allows) by whom?
• What breaks if I change or delete this object? (blast-radius)
• Can I prove to an auditor that this record wasn't altered after the fact?

It records every configuration change in a tamper-evident, append-only ledger secured by a SHA-256 hash chain, and — on the Advanced edition — adds periodic access reviews and compliance control mapping (SOC 2, ISO 27001, NIST CSF, HIPAA, PCI DSS, J-SOX) on the same ledger.

How it works#

Jira does not emit real-time events for configuration or permission changes. SPHIOR Ledger therefore uses a scheduled snapshot + diff model:

1. A scheduled trigger captures the full state of your tracked objects from the Jira REST API.
2. The capture is normalized and hashed, then stored in Forge SQL inside your tenant.
3. The new snapshot is compared to the previous one; field-level differences are recorded as append-only diff rows.
4. Each record is linked into a hash chain — every record’s hash includes the previous record’s hash and a hash of its own content, so a silent edit is detected even if the chain is re-linked.
5. Old snapshots are removed by retention; diffs and the hash chain are never deleted.

This design is hands-off: after install, capture, diff, retention, and (Advanced) scheduled evidence generation all run on their own.

Getting started#

1. Install

Install from the Atlassian Marketplace. A 30-day free trial applies to every paid edition.

2. Approve the scope request

On install, Jira asks you to approve:

3. First snapshot

The first scheduled capture establishes a baseline(no diffs yet — there's nothing to compare to). From the next capture onward, changes appear in the Recent changes feed. You can also take a capture immediately with Run snapshot now.

Editions: Standard vs Advanced#

Editions are selected at purchase. Your installation and ledger are unaffected by an edition change — upgrading is a tier change, not a migration.

Audit module#

Tracked object types: workflows, workflow schemes, permission schemes, custom fields, projects, screens.

• Recent changes feed — a timeline of every change, filterable by object type.
• Diff viewer — field-level, human-readable differences (added / modified / deleted), with the raw before/after available on demand. The diff engine uses an LCS algorithm so a single mid-array insertion is reported as one change, not a cascade.
• Blast-radius (impact analysis) — before you touch an object, see what depends on it (e.g. “N screens use this custom field”, “this workflow scheme is used by M projects”).
• Actor attribution — when the Jira audit log confirms a single actor for a change, the row is marked with high confidence. When it can’t, the actor is shown as Unknown — we never guess. (Actor attribution requires a paid Jira plan with audit-log API access; Free-plan sites show Unknown for all actors.)
• Checkpoints — label a snapshot (e.g. “Pre-Q2 reorg baseline”), add notes, or protect it from retention.
• Health dashboard — capture success rate, time since last snapshot, chain verification, retention plan, and a compliance calendar of pending actions.

Access module (Advanced)#

Designed for SOC 2 CC6.6 / ISO 27001 A.9.2.5 / J-SOX periodic access review.

• Captures users, groups, group memberships, project roles, and role actors.
• A Group membership changes feed shows who gained or lost access.
• Periodic access review workflow: start a review for a period, decide each access item (Approve / Revoke / Flag), then attest with your electronic sign-off — the attestation is written into the hash chain.
• The reviewed snapshot is automatically protected from retention for the life of the review.

Compliance module (Advanced)#

Maps your configuration and access changes to control frameworks:

• SOC 2, ISO 27001, NIST CSF, HIPAA, PCI DSS, J-SOX.
• Each diff is automatically attributed to the relevant control(s) at capture time (append-only — historical attributions are never rewritten).
• Control coverage matrix: per control, see the last attestation, evidence count in the period, and what's due.
• Attest a control for a period; the attestation joins the same tamper-evident chain. Export a control-scoped evidence pack for an auditor.

Rollback (Advanced)#

Restore a single object — or a batch — to a previous snapshot state.

• Every rollback runs behind a blast-radius confirmation so you see what depends on the object before you restore it.
• 4-eyes approval (optional): turn on Require approval for rollback and a rollback must be proposed by one admin and approved by a different admin before it executes (SOX segregation of duties). Each step (propose / approve / reject / execute) is recorded in the hash chain.
• The rollback itself is recorded as an auditable event in the ledger.

Evidence packs & independent verification#

An evidence pack is a ZIP an auditor can verify without any access to your SPHIOR installation. Generate one for a snapshot, a date range, a checkpoint, or (Compliance) a control.

A pack contains:

• evidence-pack.html — a human-readable cover page with the chain verdict.
• diffs.csv, objects.csv, chain.csv — the underlying ledger data.
• signatures.txt — the SHA-256 of every other file.

To verify a pack independently

# 1. Verify the files weren't altered in transit
shasum -a 256 *.csv evidence-pack.html | diff - signatures.txt

# 2. Re-walk chain.csv: each row's record_hash must equal
#    sha256( prev_hash | payload_hash | ts_ms ), and each prev_hash
#    must equal the previous row's record_hash.

Advanced — scheduled evidence packs: generate packs automatically monthly, quarterly, or annually, aligned to your fiscal year (see below), and download them from Settings.

Compliance Cycle Engine: fiscal year, cadences, calendar#

(Advanced) Enterprises rarely run on the calendar year. Set your fiscal year start month in Settings (e.g. April for J-SOX, October for US federal), and every quarterly/annual boundary follows it:

• Scheduled evidence packs and access reviews align to your fiscal quarters and year. Period labels read e.g. “FY2026 Q2 (Apr–Jun 2026)”.
• The Compliance calendar (on the Health dashboard) shows the next access review due, overdue attestations, and rollback approvals waiting — so you see what this period needs at a glance.
• The annual value report summarizes the fiscal year: changes captured, high-risk changes caught, evidence packs produced, and chain integrity — the artifact you bring to a renewal or audit.

All cycle math is in UTC, matching how Forge schedules fire and how audit windows are conventionally defined.

Settings reference#

Roles & access#

SPHIOR Ledger is available to Jira administrators (it lives on the Jira admin page).

• Admin — full access.
• Auditor (Advanced) — a Jira admin you designate as read-only inside SPHIOR: they can view everything and export evidence, but cannot run snapshots, roll back, change settings, or reset the chain. Useful for segregation of duties. The account that installed the app cannot be made an auditor (self-lockout protection), and an installer-transfer flow lets you reassign that protected role.

Security, data residency & privacy#

• Runs on Atlassian / zero egress. SPHIOR Ledger makes no external API calls, uses no external storage, and runs no external compute. All data — snapshots, diffs, hash chain, attestations, evidence packs — stays in Forge storage inside your Atlassian tenant. You can verify this in the published manifest: no egress-capable modules are declared.
• Tamper-evident. SHA-256 hash chain on every record, with independent verification supplied in every evidence pack (see above).
• Append-only. Diffs, attestations, and the chain are never modified — even by retention, which only removes old snapshots.
• Personal data. The only PII stored is the Jira accountId (Atlassian's pseudonymous account identifier) for actor attribution. Right-to-erasure is handled through Atlassian: deleting an Atlassian account anonymizes the id at the platform level.
• Data & Privacy panel (in Settings) shows where your data lives, who can access it, current retention, and the GDPR/erasure path.
• Diagnostic export produces a redacted support bundle (no raw config, no real account ids) you can send to support yourself — SPHIOR staff have no direct access to your installation.

Usage limits#

To keep the service sustainable, daily caps apply (well above normal usage):

Reaching a cap pauses that action until 00:00 UTC; existing data is always readable.

FAQ#

Support#

• Support: support@sphior.com
• Response targets: 2 business days (Standard / trial), 1 business day (Advanced).