Preparing for SOC2 Type II: Configuring Immutable Edge Audit Trails

A core requirement of SOC2 Type II Trust Services Criteria (TSC) is Trustworthiness of System Logs. System administrators must be unable to delete or modify records of who downloaded files, when they were transferred, or who rotated quorum vault keys.

We guarantee this in ShareBolt using a chained, cryptographically linked ledger. Every log record forms a block containing the hash of the preceding block. If an attacker tampers with record \(N-1\), the hash chain breaks on block \(N\), failing verification checks.

Cryptographic Chain Code

Here is the Javascript implementation we use to construct, serialize, and append new audit events to our SQLite/JSON ledger backend:

class AuditBlock {
  constructor(index, timestamp, action, payloadHash, prevHash) {
    this.index = index;
    this.timestamp = timestamp;
    this.action = action;
    this.payloadHash = payloadHash;
    this.prevHash = prevHash;
    this.hash = this.calculateHash();
  }

  calculateHash() {
    const data = `${this.index}${this.timestamp}${this.action}${this.payloadHash}${this.prevHash}`;
    return sha256(data); // cryptographic SHA-256 hash
  }
}

Mathematical Formulation

Each block hash \(H_n\) is defined by the concatenation (\(\mathbin{\|}\)) of metadata parameters:

Because SHA-256 is collision-resistant, altering any variable (like changing a timestamp or download action parameter) will produce an entirely different hash, breaking downstream pointers.

What SOC2 Type II Actually Requires from Your Audit Log

SOC2 Type II evaluates whether your controls operated effectively over a period of time — typically 6 to 12 months. For file transfer systems, the relevant criteria are CC6.1 (logical access controls), CC7.2 (monitoring of system components), and CC9.2 (vendor and business partner management). Each requires that access events be logged in a way that precludes modification by system administrators.

A standard append-only log stored in a database is insufficient: a database administrator with DELETE privilege can remove records without detection. A cryptographic hash chain ensures that any deletion or modification is immediately visible at the next verify call — because the hash of the modified block no longer matches the prevHash stored in the following block.

The Full Block Hash Formula

ShareBolt’s ledger hashes all transfer-relevant fields together, including the storage region:

const blockRegion = block.region || 'us-east';
const textToHash = [
  blockIndex,
  action,
  senderStr,
  recipientStr,
  fileHash,
  fileSizeBytes,
  classification,
  timestampStr,
  block.prev_hash,
  blockRegion          // region is tamper-evident
].join('|');
const computedHash = crypto
  .createHash('sha256')
  .update(textToHash, 'utf8')
  .digest('hex');

The region field is critical for GDPR Chapter V compliance: if an EU transfer record’s region is changed from eu-central to us-east post-hoc, the hash chain breaks on the next block and the tampering is detected. This makes the audit ledger a reliable residency compliance artefact, not just an access log.

Ed25519 Per-Entry Signatures

A hash chain prevents undetected modification but does not prove origin — an attacker who can replay the hash computation could rebuild a fraudulent chain. Ed25519 signatures close this gap: each block is signed with the audit service’s private key before being written to the ledger. The corresponding public key is published at GET /v1/audit/public-key and verifiable offline.

// Verify a single block offline
const { createVerify } = require('crypto');
function verifyBlock(block, publicKeyPem) {
  const payload = JSON.stringify({
    block_index: block.block_index, action: block.action,
    sender: block.sender,         recipient: block.recipient,
    file_hash: block.file_hash,   file_size_bytes: block.file_size_bytes,
    classification: block.classification,
    timestamp: block.timestamp,   prev_hash: block.prev_hash,
    hash: block.hash,             region: block.region,
  });
  const v = createVerify('Ed25519').update(payload, 'utf8');
  return v.verify(publicKeyPem, block.signature, 'base64');
}

Exporting for SIEM and Auditor Review

SOC2 auditors require evidence that log monitoring is continuous, not spot-checked. ShareBolt’s CSV streaming export is designed for this: GET /v1/audit/entries?format=csv&from=2026-01-01&to=2026-06-30 streams the full ledger as UTF-8 CSV, with columns for block_index, action, sender, recipient, file_hash, timestamp, hash, prev_hash, region, signature. The stream is chunked and does not buffer the full result set in memory — safe for ledgers of any size.

Feed this directly into Splunk (scripted input), Datadog (log agent file tail), or any SIEM that accepts CSV. The hash and signature columns allow your SIEM to independently verify chain integrity on ingestion — no trust in the export mechanism required.