From ISM Control to Vendor Decision: Translating Cyber Risk for People Who Sign the Cheque
A security control framework is only as good as a senior leader's ability to act on it. At the Queensland Police Service, my work turned the ISM from a compliance document into a basis for IAM/PAM investment and procurement decisions.
From ISM Control to Vendor Decision: Translating Cyber Risk for People Who Sign the Cheque
A security control framework is only as good as a senior leader's ability to act on it. The Australian Government's Information Security Manual (ISM) runs to hundreds of controls. A board does not need all of them; it needs to understand the handful that change a decision — and what it costs to treat them or accept them. Bridging that gap was the core of my cyber security work at the Queensland Police Service: turning the ISM from a compliance document into a basis for investment and procurement decisions.
Mapping controls to capability, not just to a checklist
The starting point was disciplined: take the ISM and Essential Eight controls and map them directly against candidate Identity and Access Management (IAM) and Privileged Access Management (PAM) solutions. Not "does this product have a feature called PAM," but "which specific ISM controls does this capability satisfy, partially satisfy, or leave open."
That mapping is where the real work lives. A control framework lists what should be true. A capability assessment establishes what would be true under each option, and where the residual risk sits. Done properly, it converts a security debate into a decision matrix: each vendor option scored against the controls that matter, with gaps made explicit rather than discovered after signing.
Requirements elicitation for the vendor RFQ
That control-to-capability mapping fed directly into a vendor RFQ process for an on-premise / hybrid Oracle Cloud environment. Hybrid is where identity and privilege controls get genuinely hard — the controls have to hold across the on-prem estate and the cloud tenancy, and the seams between them are exactly where privilege escalation and access drift occur.
My role was to elicit and structure the requirements that the RFQ would be evaluated against: drawing the real needs out of technical and business stakeholders, expressing them as testable requirements, and tying each back to the ISM control it was there to satisfy. The benefit of that traceability is that procurement stops being a feature beauty-contest and becomes an evidence-based selection — every requirement justified by a control, every vendor response assessable against the same baseline. It also gives the second line a defensible record of why a given solution was chosen, which is the question that gets asked after, not before.
Case studies that make a control legible to a senior leader
The hardest part of cyber governance is rarely the control itself — it's getting a non-technical decision-maker to understand the risk well enough to fund the treatment. So I built case studies that explained specific ISM controls in terms of impact and treatment, pitched at senior-leader level.
The management of macros is a good example. To an engineer, "restrict and control Microsoft Office macros" is a line item. To an executive, that line item is invisible until you explain it as a story: macros are a primary delivery mechanism for malware; an unmanaged macro is a direct path from a routine email attachment to a compromised network; the treatment — controlling which macros can run, from where, and signed by whom — is a small operational change against a disproportionately large reduction in attack surface. Framed that way, the control stops being IT housekeeping and becomes an obvious risk-reduction investment.
That translation skill — take a technical control, express its impact and treatment in the language of the person who has to approve it — is the difference between a security framework that sits in a drawer and one that actually changes how an organisation behaves.
Why this is second-line work
Mapping controls to capability, demanding traceability from requirement to control, and translating technical risk into executive decisions is not first-line delivery — it's the independent challenge and assurance function applied to security. The value isn't in standing up the IAM tool; it's in establishing, before anyone commits, whether the proposed solution actually satisfies the controls the organisation is accountable for, and making the residual risk visible to the people who own it.
Based on cyber security maturity work delivered at the Queensland Police Service, aligned to ASD/ISM controls and the Essential Eight.