Product tour

Inside Dokimos.

A closer look at each part of the assurance chain, from requirement to decision, with screens from a fictional worked example.

Request early access How it works

01 · Plan In preparation

Requirements and controls

Map every obligation once to reusable controls, so a PCI DSS program, CRA readiness and ISO/IEC work share the same controls instead of copied spreadsheets.

What to do, how often and who owns it
Which evidence proves it, and how it is checked
Which other frameworks rely on the same control

Screenshot to come

02 · Do Available

Assurance calendar

Track what must happen, how often, who owns it, when it is due, what evidence is expected and which frameworks are affected if it slips.

Recurring activities with accountable owners, due dates and expected evidence
Overdue and due occurrences listed first; a row is done only when evidence is linked

An assurance calendar page with window, program, framework and state filters, and a table of occurrences showing activity, frequency, expected evidence, accountable owner, due date, state chips such as overdue, due, done and scheduled, and the frameworks each row serves, with fictional demo data. — **Assurance calendar.** Demo data.

03 · Do Upload available Connectors in development

Evidence intake

Upload what people produce. Each item is stored with its source, time, scope and SHA-256 hash, and checked again before it is relied on.

Reports, exports, attestations and tool output
Every finding ends at a hashed artefact

Evidence index listing each finding, its evidence file, artefact type, truncated SHA-256 hash and collection date. — **Evidence index.** Demo data.

04 · Check Available

Validation and review

Deterministic checks run first. Scanner and AI output stays candidate evidence until a named reviewer adjudicates it.

Raw tool severity shown next to the adjudicated rating
Missing or invalid evidence is reported as missing

A critical finding page with a severity spine, status chips, raw severity marked as adjudicated to critical, code location, impact and reproduction steps. — **Finding detail.** Demo data.

05 · Act Available

Findings and remediation

Gaps become owned actions with deadlines and acceptance criteria, and are checked again when they close.

Findings by assessment module and severity
Coverage limits stated, so silence is not read as safety

A findings overview page with a severity bar, a table of findings by assessment module, a findings index with component, severity and status, and a coverage limitation note. — **Findings overview.** Demo data.

06 · Act Available

Release gate

GO, GO WITH CONDITIONS, NO-GO or NO VERDICT against criteria agreed before testing. A gate verdict is a decision about recorded criteria, not proof that a product is secure.

Blocking criteria listed with their results
Incomplete input gives no verdict, never a pass

A release gate decision page showing a NO-GO verdict, the blocking criteria that failed and every gate criterion with its result. — **Release gate.** Demo data.

07 · Act Available

Reports and exports

Every report is a view of the record, never a hand-edited copy: technical remediation report, release gate decision and audit evidence pack.

HTML and PDF, with JSON, CSV and Markdown alongside
Framework readiness and executive views In development

Screenshot to come

Screens come from a fictional worked example. Dokimos helps you operationalise requirements, collect and validate evidence, assess readiness and report. It does not certify organisations, replace auditors, guarantee compliance or provide legal advice.

See it on your own requirements.

Dokimos is developed by CyberTwierdza and is in early access.

Request early access eugene.fateev@cybertwierdza.com