Verifying vCISO Lite's audit records

What this is worth to you

Audit evidence usually travels as files and screenshots. Everyone who touches it has to take someone's word that it's the same thing that was collected, and that the trail behind each decision is the one that happened. Sealing replaces that trust with a check anyone can run.

• If you're being audited: the evidence you gave your auditor, and what they decided about it, can be shown unchanged later, to your next auditor, a regulator or an acquirer's diligence team. Disagreements about what was sent and when are settled by showing it, not by recollection.
• If you're the auditor: the trail behind each decision stands on its own: what was read, when, and what was decided. A recipient of your report can confirm it's the PDF you issued without calling you.
• If you're relying on a report: you don't take the company's word or ours. The checks need nothing from us but public pages and a script you can read.
• Over time: the outside timestamps don't depend on us. A timestamp you saved can be checked offline years from now, and a log head you kept will expose any history rewritten since.

Four layers, each checkable by someone further away

A record on its own proves nothing; anyone can write a line in a database. Each layer below commits to the one beneath it and is checkable by a wider audience. The last layer is checkable by anyone with a network connection, and depends on a party that isn't us.

Sealed isn't the same as true. Every check here proves a record wasn't changed after it was written. None of them prove the record was right when it was written. That's the auditor's job, and nothing on this page replaces it.

A record's fingerprint and signature

Every event vCISO Lite records is an entry on a chain. Each organization's records are kept on separate chains per product, so tampering with one can't invalidate another.

Fingerprint

Each entry's entry_hash is SHA-256 over a serialization of these fields, in this order:

Because previous_hash is inside the fingerprint, each entry commits to every entry before it.

The exact bytes

The fingerprint is SHA-256 over one JSON object, written byte for byte by these rules:

1. Fields in the order above, as "name":value. Leave out event_subtype when it's empty. sequence_number is a bare integer; every other field except details is a string.
2. No whitespace anywhere outside strings.
3. Strings are raw UTF-8, with these escapes: \" \\ \b \f \n \r \t; any other character below U+0020 as \u00xx (lowercase hex); < > & as \u003c \u003e \u0026; U+2028 and U+2029 as \u2028 \u2029.
4. details is the event's own JSON. Object keys are sorted by UTF-8 byte length, then byte by byte, at every depth; arrays keep their order. Numbers are plain decimals that keep their written scale (1.50 stays 1.50), with no exponent (1e-7 becomes 0.0000001) and no negative zero.
5. timestamp is UTC to the microsecond, as 2026-10-07T18:04:05.12Z: trailing zeros of the fraction are dropped, and the fraction is dropped entirely when it's zero.

entry_fingerprint.py implements these rules with the Python standard library alone, and entry_vectors.json holds test vectors produced by our production hashing code: each gives a record's fields, the exact bytes and the fingerprint. The script reproduces all of them. If yours doesn't, the rules above are wrong, and we want to know.

Entries before May 24, 2026, 15:19 EDT carry no content fingerprint. An earlier serialization didn't survive database storage, so their fingerprints can't be recomputed from their contents. Their deletion, insertion or reordering is still detected through the chain links, but an edit to their contents wouldn't be. Every entry since then, including every vCISO Lite for Auditors entry, carries a full content fingerprint.

Signature

Each entry is signed with Ed25519 (RFC 8032). The signed message is exactly:

{chain_id} is the chain identifier that comes with the record. The prefix stops a signature from being replayed against any other value we sign; the chain identifier stops it being replayed against an identical entry on another chain. Each signature records the ID of the key that made it. Signing never blocks a write: if the key is unavailable the entry is stored unsigned and reported as unsigned, never as valid.

Batches, Merkle roots and an outside timestamp

Each chain's new entries are gathered into a checkpoint. A checkpoint records its sequence range, entry count and a Merkle root over those entries' fingerprints. It is chained to the checkpoint before it (previous_checkpoint_hash) and summarized as its own checkpoint_hash.

How often. Every chain with new entries gets a checkpoint at 00:00 and 12:00 UTC, and sooner if it reaches 10,000 entries. A chain with nothing new gets none. A new record is in a checkpoint, and that checkpoint in a published and timestamped log head, within 24 hours. Before October 7, 2026 a checkpoint waited for 10,000 entries, so slow-growing chains could wait much longer.

The Merkle root is then sent to an outside Time-Stamp Authority (RFC 3161; currently DigiCert, http://timestamp.digicert.com). The authority signs the root and the time it saw it. Its signature chains to a public root certificate we don't control, so neither we nor anyone else can backdate it. The timestamp's message imprint is the 32-byte root itself.

Two tree constructions

A checkpoint states which construction built its root (tree_epoch). Always use the one it names:

• Epoch 1 (checkpoints made before October 7, 2026). Leaves are the fingerprints as 64-character hex strings, in sequence order. Parent = SHA-256 of the two children's hex strings concatenated as text, written as hex; an odd last node is paired with itself. This shape doesn't commit to the leaf count, which is why we're moving checkpoints to epoch 2.
• Epoch 2: RFC 6962, unmodified. Leaves are raw 32-byte fingerprints; leaf hash SHA-256(0x00 || leaf), node hash SHA-256(0x01 || left || right), split at the largest power of two below the width. Checkpoints made from October 7, 2026 use it, as the public log always has. Older checkpoints stay on epoch 1, because their roots are already timestamped.

Any one entry can be proven to sit under a checkpoint's root with an inclusion proof: the sibling hashes along its path. You don't need the rest of the checkpoint's entries.

One append-only log of every checkpoint

Every checkpoint's checkpoint_hash is appended as a leaf to a single public transparency log spanning every organization (RFC 6962). Each time checkpoints are added, the log publishes a new head: the tree size and root. Each head is timestamped by the same outside authority. Heads are immutable once published.

Leaves are opaque per-checkpoint commitments and are never published. A consistency proof is served only when it reveals no individual leaf. A pair of even sizes is always served, so keep heads with even tree_size.

The log's strength comes from time and other people. A head you saved last month and a head you fetch today must be consistent; if we'd rewritten history, they couldn't be. A check run once and thrown away proves nothing tomorrow. Keep the heads you're given.

Commands you can run now

You need curl, openssl (1.1 or later) and Python 3. Nothing to install, no account.

A · Fetch the latest head

B · Check the outside timestamp on that head

external_anchor is a base64 RFC 3161 time-stamp response. Decode it, then have OpenSSL check it against the head's root and your system's trusted certificates:

Expected: Verification: OK. Change one character of the digest and it says Verification: FAILED. This proves the root existed by the stamped time, signed by an authority that isn't us.

C · Prove the log was only appended to

Download verify_consistency.py (Python standard library only, 84 lines; read it before you run it). Give it the size of a head you kept. It fetches the proof from that head to the latest and checks it with the RFC 9162 §2.1.4.2 algorithm:

It also re-fetches each head on its own and confirms it matches the head the proof was served with. A rewritten history fails here; a proof that stopped short fails here; a tampered element fails here.

D · Check an issued audit report

Open the report's code at verify.vcisolite.com and drop the PDF on the page. The fingerprint is computed in your browser; the file isn't uploaded. Or compute it yourself and compare it with the issued fingerprint the page shows:

E · Records you hold (organizations and their auditors)

An organization, and the auditors it grants access, can request a verifiable export of a slice of its records through our API. The export carries each entry, an inclusion proof for each entry already in a checkpoint, and the checkpoints with their timestamps. Offline, for each entry:

1. Fold the inclusion proof to the checkpoint's Merkle root, using the construction its tree_epoch names.
2. Check the checkpoint's RFC 3161 timestamp against that root, as in B.
3. Check the checkpoint's checkpoint_hash is in the public log: a checkpoint receipt carries the RFC 6962 inclusion proof to a published head. Then compare that head with the one you fetch from the log.

Entries newer than the latest checkpoint appear in the export, marked as not yet provable.

F · Recompute a record's fingerprint from its fields

Put a record's fields in a file by name (an entry from the export in E has them), then rebuild the bytes and the fingerprint. The vectors run first, so you know the script agrees with us before you trust its answer:

The printed SHA-256 must equal the record's entry_hash.

G · Check a seal, offline, from its receipt

A seal's page offers its receipt: verify.vcisolite.com/seal/{ref}/receipt.json. verify_receipt.py (standard library only) checks the signature against the published key, the record's path to its checkpoint, the checkpoint's own hash, its place in the public log and the head it sits under. It writes each timestamp to a file and prints the openssl ts -verify command that checks the authority's signature. If you downloaded the sealed record itself, pass it too, and its fingerprint is checked:

What none of this proves

• Truth. A seal proves a record wasn't altered after it was written. It doesn't prove the record was right.
• Records written since the last checkpoint. They're chained and signed, but not yet timestamped by the outside authority. That gap is at most a day.
• Contents of entries before May 24, 2026. Their order and presence are protected; their contents aren't.
• Equivocation you never look for. The log can only catch a rewritten history if someone compares heads across time. Keep the heads you're given.
• The authority itself. The timestamp is as trustworthy as the Time-Stamp Authority and its certificate chain, which your own trust store decides.

What these public endpoints reveal

Publishing verification material shouldn't publish anyone's business. Here is what each public endpoint discloses, and what it doesn't:

• The public log shows each head's size, root, publication time and timestamp. It shows no customer names, no record contents and no per-customer counts. Individual checkpoint commitments are never published, and a consistency proof is refused if it would expose one. What the log does show is how many checkpoints the whole platform has made over time.
• Seal links each carry a long random reference (160 bits) that can't be guessed or walked. Checking what a seal covers gives one answer for every miss, an unknown reference included, so probing it learns nothing. A seal's receipt shows the checkpoint its record is in: the checkpoint's number, the range and count of records it covers, when it was made, and the organization's ID inside its hash. A stranger needs those to recompute the checkpoint, so anyone you give a seal link can see them. They describe only that organization's own records.
• The signing key is public by design. It can verify our signatures; it can't make them.
• A report's code looks up what the report's cover shows. Codes are 16 random characters (80 bits), so they can't be guessed or walked. Share a code as you'd share the report itself.

Report and seal lookups, portal sign-in requests and the public log are rate-limited per IP address at our network edge.

What you can check today

This page will be updated as each of these ships. If something here doesn't work as described, that's a defect: tell us at support@vcisolite.com.

• RFC 6962, Certificate Transparency, §2.1 Merkle Tree Hash, inclusion and consistency proofs.
• RFC 9162, Certificate Transparency 2.0, §2.1.4 verification algorithms.
• RFC 3161, Time-Stamp Protocol.
• RFC 8032, Edwards-Curve Digital Signature Algorithm (Ed25519).