AuditFlow OS Build History · Stage 1 of 5

The Cyber and GRC Readiness Pack Series

← See the full journey

Where it started

Turning shadowing into a method

This started as a learning problem, not a portfolio idea. During onboarding, audit preparation depended heavily on who I was shadowing: four senior colleagues, four different ways of preparing, questioning, pressing for evidence and explaining findings. Keeping informal notes from each session would have captured useful points, but not a consistent method, so I looked for what stayed constant across all four styles and turned that into a repeatable structure: evidence requests, fieldwork questions, red flags and assessment criteria.

HMG IS4 came first because it was the live audit problem in front of me, tied to current COMSEC work. Only once that pack was built and used did I take the same audit method, define scope, ask structured questions, request evidence, challenge the position, record findings separately from evidence gaps, score readiness, agree remediation, and remap it onto ISO 27001, NCSC CAF and NIST CSF 2.0. The later three packs reuse the method IS4 proved, not a copy of its content: each one rebuilt around that framework's own domains, not IS4's COMSEC lifecycle structure wearing a different label.

IS4 Compliance Audit question pack overview
1. IS4 Compliance Audit
Download IS4 pack →
ISO 27001 Readiness Audit question pack overview
2. ISO 27001 Readiness Audit
Download ISO 27001 pack →
NCSC CAF Readiness Audit question pack overview
3. NCSC CAF Readiness Audit
Download NCSC CAF pack →
NIST CSF 2.0 Readiness Audit question pack overview
4. NIST CSF 2.0 Readiness Audit
Download NIST CSF pack →
Decisions and compromises

Building the method once, then reusing it deliberately

Extracting constants instead of copying one person's style

The pack was built by finding what repeated across four different shadowing styles: opening context, evidence requests, fieldwork questions, risk ownership, training, physical security, personnel access, accounting, movement, disposal, incidents, findings and closing actions. That avoided copying any one senior colleague's personal method, but meant the pack had to be broader than any one person's preferred running order. It became a reference and preparation tool, not a script to read word for word.

Flagging evidence inside the questions, not in a separate checklist

Questions needing supporting documentation were marked inside the question set itself, so I could see, at the point of asking, whether a verbal answer was enough or evidence had to be requested. A separate evidence checklist would have made the questions shorter, but increased the chance evidence was requested late or inconsistently. The trade was a busier question table for better fieldwork discipline.

Deep-dive challenge points, good practice and red flags

Audit learning isn't only knowing what to ask first, it's knowing where to press further, when to sample records, and how to test whether a process works in practice. Each section also compares what good looks like against red-flag indicators, so mixed evidence can be judged against a practical benchmark rather than memory alone. Neither replaces the source standard or senior review, they're prompts for judgement, not final authority, which is why the wording stayed practical and cautious rather than definitive.

Word documents before Notion or SaaS

The packs were written as Word documents first because the method needed to be proven before it became a database or product. Starting directly in Notion or a SaaS build would have looked more like a product from day one, but it would have hidden whether the audit logic actually worked. The compromise was sequencing: prove the content first, then move it into AuditFlow OS once it held up.

Remapping each framework instead of relabelling IS4

A faster option would have been renaming IS4's domains into each new framework's headings. That would have been inaccurate, so each pack was rebuilt around its own structure instead: ISO 27001 around ISMS scope and the Statement of Applicability, CAF around its four objectives and a named essential function, NIST CSF 2.0 around its six functions with maturity tiers kept as a discussion prompt, not a headline score. Same evidence-led rhythm, different framework underneath each time.

Readiness tool, not a certification claim

The packs are positioned as readiness and preparation tools, not official NCSC, ISO, NIST or government assessment products, and they don't auto-calculate an assurance position from the number of questions answered. That's deliberate: one serious evidence gap can matter more than several minor positive answers, so the packs support judgement rather than replacing it. No restricted audit details or client records appear in them either, the value is in the structure and method, not confidential examples.

What this proved

What this stage proved

The packs proved that the audit method could be standardised without flattening the differences between frameworks. The same rhythm could be reused across IS4, ISO 27001, CAF and NIST CSF, but each pack still needed its own domains, evidence expectations and scoring language.