Architect · Governance
In most growing companies the security program lives in one person's head: who accepts a risk, who approves an exception, who owns a control. It works until that person is on leave, or leaves. We design the operating model, the roles, decision rights, and governance, and the policy framework that holds it together, so the program survives a departure and stands up to a board.
Scope agreed in writing before any work. No obligation.
Security decisions get made, but only one person knows how, and the documentation is whatever is in their inbox. You are one resignation away from losing the program's memory.
Directors are now accountable for security and want a governance model they can see working: risk appetite, reporting, and decision rights, not a promise that it is handled.
You have policies, but they overlap, contradict, or were copied from a template and never owned. You need a coherent framework people actually follow, not a binder no one reads.
The method
We set out who owns what and who decides what: risk acceptance, exception approval, control ownership, captured as decision rights and a RACI rather than left to convention. The test is whether a new hire could read it and know who to ask.
Risk strategy, oversight, and board reporting are designed against NIST CSF 2.0's Govern function, now a function in its own right, so leadership accountability is structured rather than improvised. This is the layer regulators and boards increasingly ask to see.
Policies and standards are designed as a framework, with a clear hierarchy and ownership, so they reinforce rather than contradict each other and each has someone accountable for keeping it current.
The whole point is durability: the decisions are written down so the program does not depend on any individual remembering how it works. Continuity becomes structural, not heroic.
What you are commissioning
One named engagement from the Architect track backs this page. Scope is sized to your organisation and agreed in writing before any work begins.
Architect trackTypically 3–5 weeks
Decide who owns what, and write it down.
Best for programs that live in one person's head today.
Includes
Deliverables
Why it matters now
The shift of governance into a first-class function is not cosmetic; it is where accountability now sits.
Questions
No. Policies are the visible output; the substance is the operating model underneath, who owns what and who decides what. A stack of well-written policies with no ownership or decision rights behind them is exactly the failure mode this engagement exists to fix.
Usually we rationalise rather than replace. We assess what you have, fix the gaps, overlaps, and contradictions, establish ownership, and structure them into a coherent framework. Sound policy work is kept; it is the incoherence that gets removed.
In NIST CSF 2.0, Govern is a function in its own right, covering risk strategy, roles, policy, and oversight. Boards and regulators increasingly expect to see it operating, so designing against it means your governance speaks the language they now use.
Both expect defined roles, accountability, and oversight: APRA CPS 234 makes the board ultimately responsible, and ISO 27001's management-system clauses require it. The operating model gives you exactly that structure, evidenced, so it serves the obligation rather than sitting beside it.
An operating model, a policy and standards set, and a decision-rights and RACI map, so the program has a defined structure a new leader could pick up and a board could review.
One conversation, then the scope and the price in writing. Your enquiry arrives already marked for operating model & policy.