Andy Curtis is an experienced cybersecurity leader and CISO with a background in information security implementation, architecture, and strategic security programs across government, finance, and enterprise environments. As CISO at Gadget Access, he has worked across frameworks including ISO 27001, NIST, and Essential Eight, helping organizations strengthen their security posture while aligning cyber initiatives with broader business priorities. His approach combines hands-on technical expertise with a strong understanding of risk, governance, compliance, and the realities of operating security programs at scale.
In this edition of CISO Tips, Curtis shares a practical perspective on making cybersecurity more effective by connecting technical decisions to measurable business outcomes. From avoiding unnecessary security-tool sprawl and translating vulnerabilities into executive-level risk, to testing incident response plans and proving that backups can actually support recovery, his advice centers on one core principle: security teams should focus less on collecting tools and metrics and more on reducing material risk. For Curtis, that means learning to communicate in the language of business, making informed trade-offs, and ensuring that cybersecurity decisions ultimately support the organization’s ability to operate and recover.
Complete this sentence: “Before you buy any new security tool, first...”
...prove it will reduce a material risk—and prove you can operate it.
The license fee is only the admission price. The real cost includes implementation, integration, data ingestion, training, tuning, support, additional infrastructure, operational headcount and the time required to investigate whatever the new dashboard turns red.
I am a supporter of best-of-breed technology when an organization can afford best-of-breed integration and operations. Otherwise, you can end up with several excellent products collaborating mainly through their invoices.
Sometimes a well-integrated platform delivers a better overall outcome than a collection of individually superior tools with gaps between them. Equally, consolidating everything onto one platform simply because the vendor has an attractive bundle can introduce lock-in and concentration risk. The right answer depends on coverage, interoperability, operational maturity and the risk being treated—not which logo appears highest on an analyst diagram.
A vendor-sponsored 2025 survey of 1,000 executives found that participating organizations were using an average of 83 security solutions from 29 vendors. That does not prove platforms are always better, but it does confirm that integration overhead is not something CISOs have collectively imagined after too much coffee.
The CISO’s job is not to assemble the most impressive security-tool collection. It is to achieve the greatest sustainable reduction in risk for the money available.
What’s one rule you enforce on your team that other teams would find strict?
Everyone in the security team must be able to explain their work in business, executive, and risk language.
I do not expect every analyst or engineer to become a miniature CFO. I do expect them to understand the business service they are protecting, the risk scenario they are changing, the consequence of doing nothing, and the decision required from management.
“We have 4,700 vulnerabilities” is information.
“Three internet-facing vulnerabilities create a credible path into the customer payments environment, and the remediation owner needs an approved outage before Friday” is decision support.
A technical finding without business context is unfinished work.
This is not about dumbing down the technical truth. It is about expressing that truth in the operating language of the audience. Executives generally think in terms of objectives, exposure, obligations, trade-offs, money, customers and accountability. Security professionals should be able to move between those concepts and the technical detail without losing accuracy in either direction.
Current ASD guidance explicitly treats business acumen, communication and relationship-building as core CISO capabilities, and expects cyber reporting to translate security issues into operational, financial and legal risk. I apply that expectation across the team rather than reserving it for whoever attends the board meeting.
CVSS 9.8 may be technically correct. It is rarely a complete executive sentence.
What’s a number or ratio that guides how you allocate budget, headcount, or your own time?
My starting ratio is 50:50.
Roughly half of the program should be driven top-down by material business risks: critical services, crown-jewel data, regulatory obligations, credible threat scenarios and the consequences the organization genuinely cannot tolerate.
The other half should be driven bottom-up by operational reality: unsupported systems, excessive privileges, weak configurations, failing backups, poor asset visibility, incomplete logging and all the low-hanging fruit that has somehow remained on the tree for six budget cycles.
The top-down half prevents the security team from becoming extremely efficient at fixing the wrong things. The bottom-up half prevents the enterprise risk register from becoming a beautifully formatted description of controls that do not actually work.
NIST CSF 2.0 reinforces this linkage: practitioners implement and measure risk treatment activities, while executives integrate cyber risk information with the organization’s wider enterprise risk decisions. Both views are necessary because neither strategy nor telemetry is sufficient by itself.
I use industry spending benchmarks and breach-cost studies as reasonableness checks, not as allocation formulas. “Our peers spend 12 percent” does not tell me whether our identity architecture is sound, whether our backups restore or whether half the estate is running on something last patched during the Howard government.
The ratio is a compass, not a religion. It should move as risks, maturity and business priorities change. Incidents, in particular, have very little respect for resource-allocation models.
What’s one line that works when asking the board or CFO for a budget?
“It is cheaper than one material breach every five years.”
That line gets attention. It does not, by itself, earn approval.
The next slide needs to contain the arithmetic: the credible scenario, the business services affected, the potential outage, the likely response and recovery cost, the customer and regulatory consequences, and how much the proposed investment will reduce either the likelihood or the impact.
The argument should not be, “Cyber incidents are expensive, therefore approve everything in my spreadsheet.” It should be, “Here is a plausible loss scenario, here are the available treatment options, here is what each option costs, and here is the residual exposure under each choice.”
IBM’s 2025 study reported a global average breach cost of US$4.4 million across the organizations studied. That is useful context, but a generic worldwide average is not a substitute for understanding your own economics. A CFO should see the potential interruption to your services, your revenue, your customers and your obligations—not an impressive-looking number borrowed from somebody else’s breach.
Fear may secure a meeting. Credible options, quantified assumptions and transparent trade-offs secure a budget.
What should a CISO cut from their program tomorrow with zero regret?
Raw technical reporting to executives who cannot reasonably act on it.
I would immediately cut the 40-page reports filled with vulnerability counts, firewall events, malware detections, phishing statistics, and screenshots from security products. That information may be valuable to security operators, engineers and control owners. It is usually not useful in its raw form to a board or executive committee.
Executive reporting should answer a smaller set of harder questions:
What important business service is exposed? What is the credible scenario? Is the exposure increasing or decreasing? Are the relevant controls working? Who owns the treatment? What decision or intervention is required, and by when?
The underlying technical evidence should still exist. It should simply be presented at the level where someone can use it.
AICD guidance recommends that board reporting go beyond isolated technical measures and traffic lights to include risk outcomes, relevant threats and trend information. ASD guidance similarly expects reporting to be structured around business functions and to cover risk profiles, key systems, uplift activity, incidents and expected returns on security investment.
A board pack is not a SIEM export wearing a tie.
What’s your 60-second test for whether a vendor pitch is worth your time?
I ask one question:
“In one minute, explain the problem you believe we have, the measurable outcome you will improve, and what we can stop doing if your product works.”
A good vendor will have asked enough questions to understand the environment, the existing controls, the operating model, the constraints and the outcome we are trying to achieve.
They will also be able to discuss implementation effort, dependencies, staffing requirements, data quality, integration limitations and where their product is not the answer.
A weak vendor will respond with the company origin story, three analyst quotations, the phrase “single pane of glass” and an urgent announcement that artificial intelligence has changed everything since Tuesday.
I am also interested in whether the proposed solution replaces or simplifies anything. Adding one more console, agent, data lake, workflow and set of alerts is not necessarily an improvement simply because the demonstration contains a colorful attack graph.
Current ASD procurement guidance emphasizes supplier transparency, security track record, lifecycle considerations and clear allocation of responsibilities between customer and supplier. Those are much better indicators of a sustainable relationship than the smoothness of the demonstration environment.
Any vendor can demonstrate a dashboard. The grown-up conversation is about the operating model.
What’s one meeting, report, or process you eliminated, and what replaced it?
I eliminated the vulnerability meeting that consisted of security reading scanner results aloud to people who were quietly reconsidering their career choices.
It was an activity meeting rather than a risk meeting. We could spend an hour discussing thousands of findings without answering the most important question: which weaknesses create a credible path to material business impact?
I replaced it with an application and business-service risk review.
Instead of beginning with vulnerability volume, we begin with business criticality, internet exposure, sensitive data, identity and privilege pathways, known exploitation, exploit probability, compensating controls, remediation ownership, and trend. The scanner results still provide evidence, but they no longer dictate the agenda.
This matters because no single technical score represents organizational risk. FIRST’s EPSS estimates the probability that a vulnerability will be exploited, but explicitly warns that it is not a complete risk score. Asset purpose, value, accessibility, controls and potential impact must still be considered.
We use RAG reporting because it gives executives a rapid view of hotspots and creates some healthy competition between teams. But RAG is navigation, not analysis. Green is not a control, and red is not a diagnosis. A red customer-payment platform and a red internal test server are not equivalent merely because PowerPoint has assigned them the same shade.
The new discussion is not, “Who has the most vulnerabilities?”
It is, “Which application is most likely to hurt us, who owns the response, and is the exposure moving in the right direction?”
In the first 10 minutes of an incident, what’s the one action teams most often skip?
Activating the business response, rather than only the technical response.
Technical teams quite reasonably begin containing the threat, collecting evidence and working out what happened. But a significant incident also needs an incident commander, a decision log, a reliable communications channel and early engagement from the people responsible for legal, communications, business continuity, critical services and executive decisions.
Someone should also be given explicit responsibility for protecting and validating the recovery path. That does not mean immediately restoring systems or connecting backup infrastructure to a potentially compromised environment. It means establishing whether the backups are isolated, current and likely to be usable; whether the associated credentials may be compromised; and whether there is a clean recovery path available when it is needed.
Backups are frequently treated as a magic incantation: somebody says, “We have backups,” and everyone feels better. The useful question is whether we can restore the right services, from trustworthy data, within a timeframe the business can survive.
ASD guidance emphasizes enacting the incident response plan once an incident is identified, while its continuity guidance highlights the need to maintain communications and critical business functions when normal systems are unavailable.
The SOC can contain malware. It cannot, by itself, authorize customer communications, decide whether payroll outranks email for recovery, or explain the situation to the regulator.
What’s one question every CISO should ask their team this week?
“When did we last prove, in practice, that our incident response and business continuity plans work together?”
Not when were they last reviewed.
Not when did somebody update the document footer.
When were they last road-tested under realistic conditions, involving the people, suppliers and decision-makers who would actually be required during an incident?
A meaningful exercise should test decision authority, escalation paths, out-of-band communications, executive availability, legal and regulatory thresholds, supplier contacts, manual business workarounds, backup restoration, service-recovery priorities and the assumptions behind recovery time and recovery point objectives.
It should also expose awkward practical details. Are the emergency contact details stored somewhere accessible when email is down? Can the crisis team collaborate without using the potentially compromised corporate environment? Does the person named as incident commander still work here? Can the backup be restored, or has the organization merely been paying to store it very carefully?
Current ASD guidance requires incident management policies and associated response plans to be exercised at least annually, and separately expects boards or executive committees to participate in planning and exercises for major cyber incidents. For a critical or rapidly changing environment, annual testing should be treated as a floor rather than an aspiration.
A tabletop exercise that ends with everyone congratulating themselves is often just a meeting with a plot.
What’s a phrase or framing you use to translate a technical risk for executives?
I use a structure like this:
“This creates a credible pathway to [critical service] being unavailable or compromised for [period], affecting [customers, operations or data], with a plausible financial impact of [$X–$Y]. We can reduce the likelihood or duration through [action] at a cost of [$Z]. The decision required is [choice].”
That framing translates the technical condition without hiding it. It connects the weakness to a business promise, explains the plausible scenario, acknowledges uncertainty, quantifies the potential consequence and makes the decision explicit.
I also try to make “reputational damage” less abstract. Reputation is not a mysterious cloud that descends after an incident. It can appear as customer attrition, reduced conversion, lost bids, delayed sales, increased support demand, regulatory scrutiny, partner concern or prolonged executive distraction. Where possible, I connect reputation to those observable commercial and operational effects.
The use of ranges is important. Cyber quantification should improve decision-making, not manufacture false precision. Saying the impact is plausibly between $3 million and $8 million, based on stated assumptions, is often more credible than claiming the answer is exactly $5,421,763 because a spreadsheet contains several decimal places.
Both ASD and NIST expect cyber risk information to support broader organizational risk and investment decisions rather than remain isolated in specialist terminology.
Executives do not need a guided tour of the CVE. They need to know which promise to customers it could break.
What’s your best tip for surviving the CISO role in exactly five words?
Learn to talk executive risk.
More tips from the series: