ACSETalk to us
  1. Home
  2. Solutions
  3. Audit readiness

Audit readiness

Walk into the audit with the evidence already sealed.

Audits rarely fail because a misconfiguration was missed. They fail when you can’t prove the fix was authorized, tested and reversible. ACSE records those answers as the work happens, so the evidence exists before anyone asks for it.

Talk to usSee how it works
Audit packages from sealed casesSealed cases stack into an audit package organized per framework control.AUDIT PACKAGESEALED CASESpci dss 4.0.1 · q3 · per control
01

Answer the hardest question

For every change: who approved it, what they saw, how it was tested and how to undo it.

02

Stop assembling screenshots

Audit packages come from sealed cases, organized by framework control.

03

Evidence an auditor can check alone

Your auditor verifies the record on their own machine, with no network and no ACSE account.

The question that fails audits

“Show me this fix was authorized, tested and reversible.”

A ticket and a screenshot don’t answer that. ACSE records the raw facts of every case: the finding, the policy version in force, the proposed change and its reasoning, the validation results, the approver’s identity and the exact view they approved, the merge and the verification.

Each record holds the hash of the one before it and is signed, then written to append-only storage in your own account. Change or remove one, and the chain shows it.

  • Approval bound to a hash of what the approver saw
  • Independent re-read of the cloud after the fix
  • Stored under Object Lock in your account
The record lives with youRecords for a finding, the proposed fix, the decision, the merge and the verification are chained, each holding the hash of the one before, and written to append-only storage in the customer’s own account.YOUR ACCOUNTobject lock · append-onlyfindingproposaldecisionmergeverifiedeach record holds the hash of the last

Inside a sealed case

What your auditor receives

  1. The finding and the ruleWhat failed, against which policy and framework version, at what time.
  2. The change and its proofThe fix as code, the offline plan, the policy re-check and the blast-radius judgement.
  3. The decisionWho decided, with step-up MFA, and the acknowledgements they made. By default, the author never approves their own change.
  4. The outcomeThe merge, the verification against the cloud and the observation window, closed with a seal.
Sealed, signed, ready for auditFour signed records for one change, from the approval decision to the verification, each pointing at the hash of the record before it, closed with a seal.RECORD 21decision · approveprev 3f0a…RECORD 22merge observedprev 9c1e…RECORD 23observed stateprev 71b2…RECORD 24verificationverdict: compliantprev e04d…SEALED · OBSERVATION WINDOW CLOSED ·✓

Governance on the record

The judgement calls, written down

Auditors want to see the decisions not to fix, too. Each one is a signed record with a second person behind it.

01

Attestations

A person’s statement that a control is met by means ACSE can’t observe, approved by a second person.

02

Exclusions

A control taken out of scope, with the reason recorded. It leaves the governed score and shows in both.

03

Exceptions

Accepted risk with a named owner, compensating controls and an expiry. No exception is permanent.

04

Legal holds

Preserve evidence for a matter at once. Releasing a hold takes two people.

Offline verification

Verified on the auditor’s own machine

Export a case as a bundle and hand it over. Your auditor runs the open verifier, in Python or TypeScript, and both must reach the same verdict on the chain, the signatures and the seal.

They don’t need an ACSE account or a network connection, and they don’t have to take ACSE’s word for anything.

Verified offlineAn auditor opens a case bundle on their own machine with no network and no ACSE account. The verifier confirms the chain, the signatures and the seal, and two independent verifiers agree.CASE BUNDLEacse-verify bundle.zip✓ chain intact✓ signatures valid✓ seal validpython and typescript agreeno network · no acse account

Questions

What people ask us

Which frameworks do audit packages cover?

Audit packages can be produced for any framework you have adopted: CIS, PCI DSS 4.0.1, NIST 800-53 Rev 5, FedRAMP Moderate, CCCS Medium, ISO 27001, SOC 2, and your own custom frameworks.

Can ACSE alter the evidence after the fact?

The evidence is written to append-only storage in your account and chained by hash, so even ACSE can’t rewrite it without the change being detectable.

Does ACSE make us compliant?

No tool can do that. ACSE gives you current posture against each framework and a verifiable record of how controls were met and failures fixed. Your auditor makes the judgement.

Keep reading

Related

Platform

Evidence

ACSE records every step of every fix in a signed, hash-chained, append-only record in your own account, which an auditor can verify offline.

ReadSolutions

Auditors

Verify ACSE evidence offline with an open verifier and no ACSE account: a signed, hash-chained record of who approved each change and how it was tested.

ReadTrust

Data boundary

ACSE runs in your account and sends only shapes and counts. Names, ids and credentials stay with you, and a deny-by-default registry governs what leaves.

Read

Talk to us

See ACSE on your cloud.

Tell us what you run and what your auditors ask for. We’ll show you the loop end to end: a real finding, a fix as code, an approval with MFA and the sealed record.

Talk to usExplore the platform