Épreuve

$ man épreuve

ÉPREUVE(1)Épreuve manualÉPREUVE(1)

NAME

épreuve · threat-informed audit readiness for SOC 2. Every control claims it works. Put it à l'épreuve.

SYNOPSIS

épreuve recon      <register> [--vendors] [--peer-breaches] [--incidents]
épreuve hunt       <target> [--positions] [--payload <your-record>]
épreuve challenge  <result> --reviewer <name>
épreuve debrief    [--view team|risk|board|engineering|auditor]
épreuve --pilot    épreuve --for team|auditor    finger ayoub    sessions -l

DESCRIPTION

Épreuve performs a completed, bounded assessment of your SOC 2 controls with the scrutiny of a red-team engagement. You keep your platform, your risk register, your control operation and your auditor. We take responsibility for the examination and its conclusions, and you pay for completed examination whatever it finds. The work runs in four windows.

01 recon

Steps 00 to 02. Start from your risk register as it is, even when it is generic or stale. Enrich it with breaches at comparable companies, breaches involving your vendors, the types of data you hold and, where you authorise it, your own incident records. Work each top risk into a handful of concrete scenarios, attack and failure paths alike, and write down the protection each path requires. Map that protection to the controls that claim to provide it, listed in your framework or not, judging each by its capability, coverage and reliability against the path. Output: claims to hunt, ordered by the risk they answer to.

02 hunt

Steps 03 to 05. Reconcile the population every position depends on across authoritative sources, and print expected against obtained. Mark the assumptions inside each claim as positions, §like this§, and attack them one at a time with a payload taken from your own records, under scoped, time-bounded, authorised access. Every procedure addresses population completeness, period coverage, the intended protection, and exceptions and bypass paths. Documents, interviews and observation stay in the method where an API cannot answer the question. Each position prints a status and a confidence.

03 challenge

Step 06. An adversarial agent raises structured objections and a named reviewer decides; a hold blocks release until evidence or accountable review resolves it. Together they attack our answer before you see it: favourable conclusions, false alarms, and whether the procedure was adequate at all. Missing evidence stays open; it is never counted as a pass. Review can hold a result. It never turns broke into held. “Procedure completed, but no conclusion was issued” is a legitimate line in a debrief.

04 debrief

Steps 07 and 08. One assessment, several views. Your team gets broke, held and open per control with confidence printed and a remediation order. Risk owners get the positions, which are the assumptions in your register, with what held and what did not. The board gets material findings, uncertainty and progress on one page. Engineering gets the trace: exact payload, record and assertion, so they can reperform it. Your auditor gets the handover. The first page of every debrief says what was not run.

THE LOOP

Every scenario runs the same nine steps, and a retest is the loop re-entered where the fact changed. Code executes, an adversarial agent and a named reviewer attack the answer, a person releases.

00 risk · 01 reconyour register as it is, plus what we may add: breaches at comparable companies, breaches involving your vendors, the data you hold, your incident records → the top risks, high or critical, each with its signals and their provenance · a missing or under-rated risk comes back to you as an evidence-backed challenge; you own the register

01 scenario · 01 reconone risk → a handful of concrete paths, attack and failure alike, each with the protection it requires

02 claim · 01 reconthe required protection → the controls that claim to provide it, listed in your framework or not, with their assumptions marked as positions · each control is judged by its capability, coverage and reliability against the path, never averaged into a score

03 populate · 02 huntpositions, sources, period → expected against obtained population, exclusions, source health · a sample supports only its own inference; one application does not establish all applications

04 procedure · 02 huntone position → a versioned procedure: payload, assertion, oracle, limits, and the exact authority to run it

05 run · 02 huntprocedure, population, period → one result per position: held, broke, open or not run, with its confidence · same inputs, same bytes; any change is a new revision, never an edit

06 challenge · 03 challengeresults and the reasoning behind them → release, or a hold that blocks release until evidence or a named reviewer resolves it · an adversarial agent objects, a named reviewer decides; four failures block our release whatever your controls did

07 debrief · 04 debriefreleased and held results across the scope → one assessment, several views: team, risk owners, board, engineering, auditor · not run is printed first; held is a result, not an absence

08 retest · 04 debriefyour fix, a new period → a new run linked to its parent; the original finding stays · re-enter the loop where the fact changed

INVARIANTS

A result is a function of its inputs: same procedure version, population and period, same bytes. Any change is a new revision.
AI proposes, code executes, people approve. Model agreement is not approval.
Missing evidence is never a pass. Our unfinished work is never your evidence limitation.
A hold blocks release. Review never turns broke into held.
The original result survives the retest. Scope never shrinks silently.
Our release is blocked by an unsupported favourable conclusion, an unsupported adverse conclusion, a missed known material failure, missing evidence treated as a pass, whatever your controls did.
Held, with its confidence and limits, is as useful as broke. There is no finding quota.

POSITIONS

The sample target on this site, T-D1 on the fictional Alder Works, carries one claim with four positions:

Ordinary users §can only§ reach customer files §through central SSO§ §with MFA§, and emergency access is §separately approved§.

Position 2 broke, certain: the application still accepted local username and password. Positions 1 and 3 held, firm. Position 4 stayed open, tentative, because the approvals were never delivered. The reviewer held the result until they arrive. Severity and confidence are printed separately on every line, in the style of a scanner: certain, firm or tentative.

EXIT STATUS

0 heldthe position survived its payload

1 brokethe position failed; the claim is unsupported at that point

2 openevidence missing, undelivered or inconclusive; no conclusion issued

77 not runthe procedure did not run; printed first, never hidden

FILES

debrief/assessmentreviewed control assessment: supported conclusions, findings, explicit unknowns

debrief/decision-briefremediation priorities, risk-register assumptions, board use

handover/workpapers, procedure and software versions, reconciled populations, permitted evidence access, so an authorised examiner can challenge and repeat the work

handover/*.jsonmachine-readable records consistent with the assessment

ENVIRONMENT

PLATFORMyours, unchanged. We do not sell you a tool to operate.

REGISTERyours. We enrich it and challenge it; we do not replace it.

AUDITORyours. They decide what to reuse and sign their own report.

RISKmanagement's. We inform decisions; we do not accept risk or own remediation.

LIMITS

Not a penetration test. Not an attestation. No continuous monitoring, hosted trust centre or remediation done for you. No favourable result promised. The sample hunt on this site runs a fixed procedure against a fictional company with no live model; it shows the grammar, not a customer finding.