From security control to vendor decision

The Information Security Manual (ISM), published by the Australian Signals Directorate, is a long catalogue of controls. Most organisations use it as a compliance checklist.

A senior leader who approves a security investment does not need the catalogue. They need the few controls that decide the choice in front of them, and a plain account of what each option leaves uncovered.

That translation is the work. It turns a framework used for compliance into one that supports a decision.

Vendor evaluation often stops at features. A product offers multi-factor authentication, so the requirement is marked as met. The question that matters is whether the product, configured the way the organisation will run it, satisfies the control.

We map each relevant ISM and Essential Eight control to the capabilities of each candidate product, for example in identity and privileged access management. Where a product has the feature but does not meet the control, the gap is recorded. What remains is residual risk, and it is named for each option.

The output is a decision matrix. A debate between preferences becomes a comparison with the gaps in view.

The matrix also shows where no candidate meets a control. That is a finding in its own right. The organisation can accept the residual risk, add a compensating control, or widen the market before it commits.

Requirements decide the quality of a request for quote. In a hybrid environment, each control has to work on premises and in the cloud, so each requirement has to say both.

We elicit requirements from technical and business stakeholders and write each one as a criterion that can be tested. Each requirement traces to the control it supports. Vendor responses are then scored against evidence, not against a list of features.

The trace serves later as well. When the decision is reviewed, the record shows why the chosen vendor met the requirements and where the others did not.

A control such as restricting Microsoft Office macros means little to a non-technical executive. The case for it does. Macros are a common way for an attacker to run code on a staff computer, and from there to reach the systems that hold client records.

We write each priority control as a short case: how the attack works, what it would mean for the organisation's operations and obligations, and how much effort the treatment takes. The proportion between the treatment and the risk is then visible.

The same method works for controls that cost more to apply, such as application control or restricted administrative privileges. Each one gets the same short case, so a leader can compare them side by side.

Maintenance that looked like routine upkeep becomes risk reduction with a stated reason. A leader can fund work on that basis.

This work is independent assurance, not delivery. The first line selects and runs the tools. The second line challenges the choice before the organisation commits, and checks that the proposed solution meets the control.

Keeping the two apart matters. The people accountable for the risk see it before they approve the spend, and the record shows that the challenge took place.

We do this work in our cyber security governance and business analysis engagements, against the Essential Eight and the ISM.