Skip to content
Service

Digital, Cyber & Technology Risk

An evidence-based read on where your cyber and technology risk actually sits, and whether the controls you are paying for are working.

The full-width track is every control you hold; the filled bar is how many survive to that stage. Far more are documented than have ever been tested, and fewer still hold up when sampled over a period. The unfilled remainder is labelled at each stage, because that shortfall is exactly what a status report is showing you as green.

There is usually a large gap between the controls an organisation has documented and the controls that are actually working. A policy exists, so the control is marked green. The tooling was purchased, so the capability is assumed. Nobody has opened the console in four months, the alerting rule silently stopped firing after a migration, and the quarterly access review was completed by someone approving their own team. None of that shows up in a status report.

This work closes that gap by testing rather than asking. Control walkthroughs with the people who operate them, evidence pulled from the systems themselves instead of from a questionnaire, and a maturity assessment that states the gap to your target rather than awarding a score with no destination. Where obligations apply, whether that is NZISM, HISO, PCI-DSS, or a customer contract, the assessment is scoped to those obligations rather than to a generic checklist.

The other half of the job is making the result usable. Cyber risk that lives in its own register, in its own language, gets read by the security team and nobody else. Integrated into the enterprise risk framework, described in the same terms as credit, safety, and operational risk, it competes for attention and funding on equal footing. That integration is usually what turns an assessment into a decision.

You might need this if

  • The audit committee asks for assurance and receives a status update instead
  • Controls are documented and reported green, but no one has tested whether they still work
  • Cyber risk sits in a separate register that the rest of the business never reads
  • You have a maturity score but nobody can explain what the gap to target would cost to close
  • An external questionnaire from a customer or insurer exposed answers nobody could evidence

Who it's for

Heads of risk, audit committees, and executives who need assurance over cyber and technology risk, whether or not a certification is in play.

How the engagement runs

  1. 01

    Scope and obligations

    Establish what you are actually accountable for: regulatory obligations, contractual commitments, and the threat profile that fits your sector. This is what the assessment is measured against.

  2. 02

    Walkthrough and evidence

    Sessions with the people who operate the controls, and evidence drawn from the systems themselves. Questionnaires record intentions; configuration and logs record reality.

  3. 03

    Effectiveness testing

    Sample-based testing of whether the control did what it claims, consistently, over a period. Design effectiveness and operating effectiveness are reported separately, because a well-designed control that nobody runs is still a gap.

  4. 04

    Reporting and integration

    Findings prioritised by business impact, a costed remediation roadmap, and the risks written into the enterprise register in the language the rest of the business already uses.

What's delivered

  • Cyber and technology risk assessment scoped to your obligations and threat profile
  • Control effectiveness testing that reports what works, not what is documented
  • Maturity review against a recognised model, with the gap to target made explicit
  • Cyber risk integrated into the enterprise risk framework and register, in the language the rest of the business already uses
  • Facilitated risk workshops, IT audit support, and assurance reporting for the audit committee

Proof point

Embedded information security risk management inside the existing enterprise risk framework at a lines utility, spanning corporate governance, ICT, and operational technology.

Common questions

How is this different from an audit?
An audit tests conformance against a standard and reports pass or fail. This starts from your risk and asks whether the controls meaningfully reduce it, which sometimes concludes that a conformant control is not worth what it costs. The two are complementary, and this work often makes the next audit considerably less painful.
Do we need to be pursuing a certification for this to be worthwhile?
No. Certification is one reason to do it and not the most common one. Most engagements start because a board, an insurer, or a major customer has asked a question the organisation could not answer with evidence.
Will this duplicate our internal audit function?
It should not. Internal audit generally lacks deep technical coverage of cyber and works to an annual plan. I work alongside them, and where a capable internal audit function exists the usual outcome is that I supply the technical testing and they retain the assurance opinion.
We have no framework at all. Is it too early?
It is the right time, not too early. Picking a framework before you know your obligations and your actual exposure tends to produce a control set that fits somebody else's organisation.
Get in touch

Let's talk about your security programme

Considering a vCISO, a security strategy and architecture, a SOC uplift, an AI assurance review, or a secure web build? Tell me where you are and where you need to get to.