Loading page…
Our approach
Nine phases, in the order they have to happen. Each one ends in something you can read and challenge before the next begins — so no stage depends on trusting that the previous one went well.
Operating principles
These determine how the phases are applied. They are also the things we will not compromise on to shorten a timeline.
The audience determines the programme. A certification body, a supervisory authority, an enterprise customer and your own board each need a different thing demonstrated, and scoping starts by naming which one is driving the work.
Where we implement, a separate team audits, and the separation is documented. That is what allows a certification body or an audit committee to rely on the result rather than question it.
No phase depends on trusting that the previous one went well. Each ends in an output you can read, challenge and approve before the next one starts.
Controls are agreed with the people who will run them. A framework designed in isolation is technically correct and operationally ignored — which is the most common reason a second implementation is needed.
The test of a programme is not the certificate. It is whether the registers are still current, the reviews still happen and the evidence is still there twelve months later.
The advisory work stands on its own. We implement into whatever system you already run, and offer SecureGRC where you want the framework and the tooling to come from the same team.
The method
An engagement rarely starts at phase one — most organisations enter partway through. What matters is that no phase is skipped silently, because the ones most often skipped are context and validation, and those are the two that determine whether the result holds.
Before any assessment, we establish what the organisation is accountable for and to whom. A control environment only makes sense against the obligations it exists to satisfy, and those obligations come from regulators, certification bodies, contracts and the board in different proportions for every client.
We establish a defensible baseline rather than an assumed one. That means document review, interviews with the people who operate the controls, and walkthroughs that test whether a control works as described. A control that exists on paper and not in practice is recorded as the latter.
Findings are set against the specific requirement they fail, not against a generic maturity model. Each gap carries a severity, an owner, an effort estimate and the clause or obligation it relates to — so the remediation plan can be argued about on its merits rather than accepted on trust.
Gaps are translated into risk in the organisation's own terms — its taxonomy, its scoring method, its appetite. This is where the conversation moves from a technical finding list to a decision leadership can actually make, because it establishes what the organisation is prepared to accept and what it is not.
The target state is designed with the people who will operate it, not for them. Where several standards apply, controls are rationalised into one set so a single control tested once satisfies every requirement it maps to — the alternative is parallel programmes that duplicate effort and disagree with each other.
Design becomes operation. Registers are populated with real entries rather than templates, owners accept their assignments explicitly, and the programme is moved off documents into a system with workflow, reminders and reporting attached — SecureGRC where the client wants it, or the platform they already run.
Before we call anything complete, it is tested. Controls are tested for operating effectiveness, not just design. Where certification is the objective, an internal audit and management review cycle is run in full, so the first time the system is examined is not by the certification body.
Leadership gets a defined reporting pack produced on a schedule from live records — risk against appetite, control health, open findings, overdue actions — with the data definition behind every metric stated. Reporting assembled by hand for each meeting decays the moment attention moves elsewhere.
Every engagement ends with the capability inside the client organisation: the team trained, at least one full reporting cycle run alongside them, and a scheduled review point. The measure of a good engagement is that the client needs us less afterwards, not more.
Engagement shapes
Which shape fits depends on where you are starting and what has to be demonstrated. Most programmes combine two — an assessment that establishes the baseline, then the implementation it justifies.
A defined, time-boxed review producing a baseline and a rated finding list. Used when the organisation needs to know where it stands before committing to a programme.
A programme that takes a framework from design through to operation, with the registers populated and the owners assigned. The most common shape where certification or a regulatory deadline is driving the work.
Testing and audit carried out independently of whoever implemented the control, with the separation documented so the result can be relied on externally.
Continuing involvement after implementation — running or supporting the cycle, handling surveillance audits, and keeping the framework current as obligations change.
Applied by practice
Each practice page sets out the phases as they apply to that discipline, together with the specific deliverables that engagement produces.
About the method
Start with the requirement
Describe what has to be demonstrated, to whom, and by when. You will get a candid view of which phases apply, what each would produce, and where the scope is narrower than you expect.