Product tour
Nothing below is a concept render. These are screenshots of the shipping
build with the demo dataset loaded, the same dataset you get from
SEED_DEMO_DATA=true on the first boot. Click any image to enlarge it.
01 · Frameworks and controls
Three complete control libraries ship pre-loaded and seed themselves on first boot: SOC 2 (61), ISO/IEC 27001:2022 (93) and PCI DSS v4.0.1 (63). Each control carries a category, an objective, a status, an owner and the evidence linked to it.
On this screen you can
Twenty cross-framework themes ship with the libraries, each naming the SOC 2, ISO and PCI controls that address the same requirement. CC6.1, A.5.15 and 7.1 are one theme, so a single policy is evidence for all three. Read through /api/crosswalk/; no screen yet.
The control ↔ document relationship is many-to-many and editable from either side. Add a policy from the Controls screen, or map controls from the Documents screen. It is the same link, and unlinking from one place unlinks it everywhere.
A control owner is a person with a login, not a text field. That is what makes ownership coverage meaningful, routes the reminder, and lets an owner answer a PBC line without seeing the rest of the package.
02 · Documents and evidence
Not an empty drive you have to organise. The tree is created from the control libraries (framework, then category, then control) on disk and mirrored in the app, with your own subfolders wherever you want them.
Version archives the current file and increments; the old bytes stay retrievable, which matters when an auditor asks what the policy said during the window. Rename, Move and Mark reviewed are separate permissions, each an audit-log entry.
Set a cadence from monthly to biennial and the next review date is derived. Owners and the compliance address are emailed at 30, 14, 7 and 1 days out, and once when it goes overdue. Each window fires exactly once and is recorded, so a restart does not re-send yesterday's mail.
Permissions are per folder, granted to a role or a user at view, edit or manage, and inherited by every subfolder. Effective access resolves server-side. Auditor roles are capped at view whatever they are granted.
Open in browser
Downloading evidence to look at it is how copies of your policies end up in Downloads folders on laptops you do not control. The viewer renders in place, and the way it renders is deliberately conservative.
03 · Dashboard and analytics
A readiness snapshot is recorded daily. The trend line and the month-over-month delta come from that history, so the figure you show your board is reproducible rather than re-derived each time.
Dashboard. The calendar merges review dates, audit milestones and tasks; filter by type, click a day for detail.
Analytics. Ownership coverage across controls, documents and risks: usually the most useful number on the page.
The next reviews due, with Mark reviewed inline for managers and owners with edit access. Clearing the queue takes one pass, not a tour of the folder tree.
What share of controls have at least one document linked. The gap between “implemented” and “evidenced” is where audits go wrong, so it gets its own tile.
Open risks, how many are being mitigated, how many accepted, and how many are past their due date: linked straight into the register.
Computed per person: your documents and risks that are due, tasks assigned to you, cadences you own that are behind. A manager's tray widens to the organisation. The emailed digest is off by default; turn on daily or weekly in Settings.
04 · Risk register
Likelihood × impact on the 5×5 grid auditors expect, producing low, moderate, high or critical. Each entry carries status, treatment, owner, an optional control and Jira key, a due date and a note trail.
Import that survives contact with reality
Managers create and edit; the risk's owner can edit theirs; anyone with access can add notes. An auditor's exception can be pushed into the register in one click, arriving with the package and control referenced.
05 · Access reviews and the audit trail
Two of them: the periodic user access review, and the append-only record of every change that happened. Between them they cover a surprising share of what an assessor asks for in the first week.
Start new review snapshots every account as it stands, so the grid does not shift under you. Record a decision and a note per row, export the CSV, then complete it. The API refuses to complete while any row is pending, and a completed review is read-only evidence.
Middleware records the top-level field names of every mutating request, never the values, dropping password, token and code keys outright. Sign-ins, failures with the reason, and sign-outs are written explicitly. There is no API to edit or delete an entry.
06 · Vendors and shared responsibility
The register, with assurance and its expiry visible before it lapses.
RACI per control, across people and vendors.
SOC 2 reports, ISO certificates, PCI AOCs, penetration tests and DPAs, each with an expiry date. Posture and risk rating are derived from what is on file and how close it is to lapsing. A bridge-letter reminder fires when a SOC report lapses with nothing newer behind it.
Vendors send their matrix in whatever shape their template happens to be. The importer scores headers to find the columns, promotes a mark column by its values, and never guesses at prose it does not recognise. Nothing is written until you confirm what it read.
One click emails the vendor's contact a personal link, valid 14 days by default and 90 at most, one live link per vendor with a revoke button. They answer in a browser with no account, the token is stored hashed, and the submission returns as a pending assessment for you to accept or reject.
07 · Audit packages
A sealed, hash-pinned package whose canonical manifest (every control snapshot and the SHA-256 of every evidence file) carries a detached Ed25519 signature, issued to named auditors for a fixed window, and verified offline without us.
What sealing does
SIGNING_KEY_FILE), never in a tableINTEGRITY.txt. The seal detects a substitution rather than preventing one./api/signing-keys/, so the auditor can compare it against the bundle. One key signs the whole installation, so the manifest names the organisation inside the signed bytes.What the auditor receives
manifest.json with its digest in MANIFEST.sha256, manifest.sig, signing-key.pub, SHA256SUMS, controls.csv, evidence.csv, samples.csv, trail.csv, INTEGRITY.txt, a README.txt, the evidence itself, and a stdlib-only verify.py that checks the manifest signature and every listed digest with nothing installedThe organisation states population size, source and sampling method while the package is a draft, and may list items. Those are sealed into the manifest. Afterwards the auditor adds selections and records a verdict per item.
Next year's package from last year's: the same controls re-snapshotted with today's evidence, the predecessor named in the manifest, and a year-over-year panel showing scope changes, replaced evidence and last year's still-open exceptions.
The auditor raises lines from inside the package, or you transcribe the ones they emailed. Each is assigned, dated and chased in the tray, by email and in Slack or Teams, then answered by attaching documents and marking it provided.
$ unzip conformiti-package-fy26-soc2.zip && cd conformiti-package-fy26-soc2 $ sha256sum -c SHA256SUMS evidence/access-control-policy-v4.pdf: OK evidence/user-access-review-2026-Q1.csv: OK … $ python3 verify.py manifest digest d41f0e…9ab2 OK signature Ed25519 OK (key 8c:1a:…:e7) files 214/214 OK # no network, no dependencies, no vendor involvement
08 · The rest of the governance calendar
The unglamorous evidence that a programme is being run by people, on a cadence, with minutes.
Series with a required cadence per year: steering committee quarterly, risk review semi-annually. The badge compares minutes recorded this year against what the calendar demands so far, so a series is not marked behind in January for a meeting due in November.
Who represents which part of the business in the programme, with an accountable owner per group and members tagged by department. Useful evidence for the “security is governed across the organisation” questions, and useful in practice for knowing who to ask.
An administrator connects an Atlassian site, with the token stored server-side and never sent to the browser, and tracks boards by id. Everyone reads those boards without a Jira seat. The integration is read-only, https and public hosts only, redirects refused, hardened against SSRF.
09 · Identity, roles and settings
Capabilities are enforced by the API. The interface only shows write controls where the API would accept them, which is the opposite of the common arrangement, where a hidden button is the whole security model.
otpauth:// URI for any authenticator, plus ten single-use backup codes owned by the account rather than the authenticator.| Role | Manage users | Manage frameworks | Manage documents | Manage folders | View all | Auditor |
|---|---|---|---|---|---|---|
| Administrator | ✓ | ✓ | ✓ | ✓ | ✓ | No |
| Compliance Manager | No | ✓ | ✓ | ✓ | ✓ | No |
| Control Owner | No | No | granted folders | No | No | No |
| Auditor | No | No | No | No | registers read-only; documents by grant | ✓ |
| Viewer | No | No | No | No | No | No |
Custom roles come from the same capability flags. Folder grants are inherited by every subfolder, and effective access resolves to the highest of superuser, view-all, ownership and the strongest grant on the folder or any ancestor. Auditor roles are then capped at view.
10 · Workspaces
Every organisation-owned row: frameworks and controls, folders and documents, risks, vendors, packages and their request lists, reviews, meetings, groups, the calendar, Jira, readiness history, the audit trail, roles and people: belongs to a workspace.
Scoping is applied at the ORM, not the view layer: a queryset carries its workspace filter every time it is chained, so a view that forgets to scope still returns only the active workspace's rows.
X-Workspace: <slug>, remembered by the SPA) and archives one, which refuses its people at sign-in, ends their sessions, and drops it from every scheduled job. Nothing is deleted.Who this is for
| MSPs and consultancies | One deployment holding each client's programme, scoped in the database. The compliance mailbox and the Slack or Teams channel are still one per installation, so every client's reminders and daily summary land in the same place. A channel per organisation is the next item on the roadmap. |
|---|---|
| Groups and holding companies | Several regulated entities, separate scopes and separate auditors, one operations burden. |
| Separate certifications | A payments subsidiary in PCI scope kept apart from the rest of the group's ISO programme. |
| Staging and production | A workspace to rehearse a framework rollout in, without a second deployment to maintain. |
Editions
Every screen on this page ships in Core under the MIT licence, with nothing switched off. The copilot, the trust page and the multi-client console are the paid editions, installed on top.
A compliance copilot that drafts from your own control objectives on your own model key, a public trust centre, a custom framework builder, PII redaction and e-signature.
One console across every client organisation, a partner role that is not a superuser, white-label and TPRM at portfolio scale.
Gallery
Shown in Ledger Dark. Three other theme packs ship with it (Audit Ledger, Nimbus and Obsidian) plus four accent packs and a custom accent colour.
Install it in a minute and load the demo dataset, or book thirty minutes and we will drive.
Next
Both take about a minute. Everything on this page is in the MIT-licensed build. There is no “request access” gate between you and the product.