IBRAHIM OJOYETesting the method in public
Once AuditFlow OS worked for me, I wrote about the thinking behind it in public, one infographic a week for eight weeks, moving from framework understanding toward the tool rather than leading with it. The series opened by comparing IS4, NIST CSF and NCSC CAF, then went a level deeper into the CAF itself. From there it moved into the COMSEC audit cycle, the six controls every IS4 account has to prove, and what a defensible audit trail actually looks like. Week six set out the difference between GRC and cyber assurance. Week seven covered five red flags of audit failure, paired with a longer article. Week eight closed the series with the AuditFlow OS launch.
The positioning held the same line every week: this is practical audit and assurance capability being built in public, not a claim to senior authority.
The series tested whether the audit method could be explained without the reader already knowing IS4 or AuditFlow OS. Each week took one part of the method, framework comparison, CAF, COMSEC audit cycle, IS4 controls, defensible evidence, GRC versus assurance, audit red flags and the final launch, and turned it into a public teaching post.
Week 1 · Framework comparison
IS4, NIST CSF and NCSC CAF are often discussed as if they answer the same question. From my audit and assurance work so far, I do not think they do. They sit at different levels.
IS4 focuses on cryptographic material, handling requirements and technical control discipline. NIST CSF gives a broader cyber risk reference point across governance, protection, detection, response and recovery. NCSC CAF focuses on cyber resilience and assurance, especially where important services need to continue during and after cyber incidents.
The mistake is treating them as alternatives. Strong IS4 controls may show that cryptographic material is being handled correctly. That does not automatically prove wider cyber resilience. A CAF assessment may support assurance around critical services, but it does not replace specialist cryptographic control requirements. NIST CSF can help structure cyber risk, but it still needs to be translated into evidence, ownership and control testing.
This infographic maps the three frameworks across scope, audience and compliance style. Good governance is not about collecting frameworks. It is about knowing which question each framework answers.
#IS4 #NISTCSF #NCSCCAF #CyberResilience #GRC #InformationAssurance
Week 2 · The NCSC CAF, in depth
Last week I looked at how IS4, NIST CSF and the CAF relate. This week is a closer look at what the CAF actually measures. The CAF does not just ask whether a control exists. It asks whether the organisation can show that the control is working.
The four CAF objectives cover more than prevention: managing security risk, protecting against cyber attack, detecting cyber security events, and minimising the impact of incidents. From the evidence work I have been exposed to, detection and recovery can be harder to evidence than prevention.
Which CAF objective would be hardest for your organisation to evidence today?
#NCSCCAF #CyberResilience #CyberAssurance #InformationAssurance #GRC
Week 3 · The COMSEC audit cycle
The CAF explains what good cyber resilience should achieve. COMSEC audit work shows how specialist controls are checked in practice. An audit should not be treated as a one-off event: the COMSEC control assurance loop only works when review feeds back into planning.
One pattern I have seen is that teams can complete the report stage, assign actions, and then lose momentum before the fix is properly embedded. That creates repeat findings. An audit finding is not closed when someone says it has been fixed. It is closed when the evidence shows the fix is complete and traceable.
#COMSEC #HMGCompliance #CyberAssurance #AuditReadiness #InformationSecurity
Week 4 · IS4's six provable controls
In IS4 work, written procedures are only part of the picture. The records need to match the physical reality: who did what, when it happened, who authorised it, and whether the control was followed correctly. The main areas to focus on are governance, two-person integrity, secure disposal, personnel security, physical security and the control card framework.
A practical starting point is to review governance and TPI first, because those areas often connect to ownership, accountability and day-to-day control discipline.
#IS4 #HMGCompliance #COMSEC #AuditReadiness #CryptographicSecurity
Week 5 · What defensible evidence looks like
A folder of documents is not always an audit trail. A stronger evidence trail shows identity, timing and continuity: who completed an action, when it happened, what changed hands, who checked it, and where the record continued after the handoff.
The weak points often appear in movement logs, witness records, incident closure notes and actions that are recorded but not followed through. Auditors do not test good intentions. They test whether the record can stand without someone explaining it verbally.
#AuditTrail #CyberAssurance #COMSEC #InformationAssurance #HMGCompliance
Week 6 · GRC vs. cyber assurance
Defensible proof needs both structure and verification. That is where GRC and cyber assurance meet. A policy that has not been tested is still only a policy.
GRC helps define the structure: ownership, risk appetite, policies, controls, governance forums and reporting lines. Cyber assurance tests whether that structure works in practice. GRC designs the control environment, assurance checks whether it can be trusted.
#GRC #CyberAssurance #InformationAssurance #CyberResilience #ComplianceLeadership
Week 7 · Five red flags of audit failure
Audit failure often starts before the audit begins. From the audit and evidence work I have been exposed to, the issue is rarely just one missing document. It is usually a pattern: evidence scattered, control owners unclear, the trail cannot be reconstructed, actions recorded but not tracked to closure, preparation starting only when an audit date is confirmed.
Each pattern has a practical fix: put evidence in one place, name an owner per control, keep the trail readable, track actions until closure is evidenced, and treat readiness as routine work, not audit-week work.
#AuditReadiness #CyberAssurance #HMGCompliance #InformationAssurance #COMSEC
Week 7.5 · Companion article
What Auditors Notice Before They Check the Records
There is an informal test I apply at the start of any audit visit: "Tell me the current status of your records and who owns what." In a prepared account, this takes about five seconds. In an unprepared account, the answer involves locating files, explaining what happened last time, naming a colleague who normally handles this, and promising to send something later. That conversation tells me more than any document review that follows.
The gap between a prepared account and an unprepared one is not usually effort. It almost always traces back to one or more of five failure patterns.
Red Flag 1: Scattered evidence. Records exist but are spread across locations, formats and individuals. Minimum fix: one evidence location, one record format, nothing lives in email.
Red Flag 2: No named owner per control. When ownership is assigned to a role or team rather than a named person, accountability spreads until it effectively disappears. Minimum fix: a register of controls with a named individual against each one, updated whenever people change roles.
Red Flag 3: Inability to reconstruct the trail. If evidence was logged retrospectively, without consistent timestamps, the trail develops gaps under examination. Minimum fix: every action logged at the time it happens, with the name of the individual and a timestamp, as standard procedure.
Red Flag 4: Actions without closure. The gap between an action being assigned and being verified complete is where compliance programmes often fail. Minimum fix: each action has a completion date, closure evidence, and a second person who has confirmed it independently.
Red Flag 5: Last-minute preparation. Records updated in a compressed window immediately before a visit have a recognisable profile, and auditors notice. Minimum fix: treat the current state of the account as audit-ready at all times.
None of the five are difficult to address individually. The difficulty is keeping all five in place at once, since fixing one without the others lets it drift back. The goal is not to prepare harder before the next audit. The goal is to run the account so well that audit readiness is already visible in the records, ownership, timelines and closed actions.
The 5-second readiness check: Where is the evidence (one agreed location)? Who owns each control (a named individual)? Can the trail be reconstructed (a chronological record)? Are actions closed properly (closure evidence reviewed independently)? Is the account always ready (no last-minute rebuild required)?
#AuditReadiness #CyberAssurance #COMSEC #HMGCompliance #InformationAssurance #GRC #ComplianceLeadership
Week 8 · AuditFlow OS launch
Audit without structure is just inspection. Through my audit and assurance work, one recurring issue has stood out: process drift. Different templates, different evidence standards, different ways of recording findings from one review to the next. So I built AuditFlow OS: a Notion workspace designed to standardise the audit process from scoping through to evidence review, findings, actions and reporting.
The aim is simple: make audit work easier to repeat, compare and hand over. A finding raised in one cycle should be traceable in the next.
#GRC #AuditReadiness #CyberAssurance #Notion #IS4 #HMGCompliance #ISO27001
What this stage proved
Eight weeks of public engagement proved the method held up outside my own head: strangers could follow the reasoning, ask sharper questions back, and the explanations still made sense without AuditFlow OS in front of them yet.