IBRAHIM OJOYEProving the workflow before writing any software
The question packs worked on paper, but each new engagement still needed a way to connect framework domains, evidence requests, findings, actions and reporting in one place. I rebuilt the method as AuditFlow OS in Notion, using linked databases for audits, evidence, findings, controls, actions and reports.
The Notion version also tested whether the model could hold more than one framework. It started with the readiness pack method, then expanded into a wider framework library across IS4, ISO 27001, NIST CSF, NCSC CAF and related assurance areas. Some AI and data governance frameworks were explored as future library candidates, but the core product remained audit readiness and evidence traceability. The SaaS beta currently supports five frameworks as starting points; NIST AI RMF and ISO 42001 may be added later.
These are screenshots from the live Notion workspace, in Notion's own styling. A few records are labelled "(Test)": sample data kept in on purpose to show the structure, not real audit findings.
The workspace follows the audit through in order: plan it, work it, track evidence against it, log what's found, link findings to risk and control, close out the remediation, and report up.
Proving the operating model before writing any software
One workspace instead of separate files per stage
Audit records, evidence, findings, actions, controls and reports were built as related records rather than separate files copied stage to stage, Control → Audit → Evidence → Finding → Action. Slower to set up, since every relation and rollup needed real design, but it removed the need to reconstruct why a finding existed or what evidence backed it.
Evidence as a first-class record, not an attachment at the end
Evidence got its own tracker, since reviewing it is part of the audit work, not paperwork tacked on afterward: what was requested, what came back, its status, what it supported. One more database to maintain, in exchange for missing and partial evidence actually being visible instead of buried in a folder.
Actions kept separate from findings, on purpose
A finding described the issue and risk; an action recorded the agreed work, owner and deadline, linked but distinct. Combining them into one row would have saved setup time, but wouldn't cope with one finding producing several actions, or remediation continuing after the report was done.
Simple, visible risk scoring instead of a black box
Likelihood and impact combined into a risk score and level, kept deliberately simple rather than building a more complex risk engine for an MVP. The formula didn't replace auditor judgement, it made the basis for prioritisation visible and editable instead of implicit.
Management response modelled, not enforced
Response position, agreed actions and target dates were structured as part of the record, but Notion couldn't reliably enforce an approval step or block a status change. That gap, not a mistake, is what shaped what the SaaS build had to do differently.
Leaving Notion only once the workflow was proven
The build proved the operating model: connected audits, findings, evidence, actions and reporting all working as one system. It also hit a real ceiling, role-based access, enforced approvals, immutable issued reports and multi-organisation use needed more than a duplicable workspace could give. The SaaS build picked up from there, not from a blank page.
What this stage proved
Notion proved the operating model could actually work as one connected system, not just a set of related documents. It also proved, by hitting them, exactly which limits a duplicable workspace could not get past: enforced approvals, locked reports, and real role-based access.