David, you’ve led security across Fortune 500s, startups, higher education, and hybrid-cloud environments. What has most changed how you think about building an effective cybersecurity program?
The biggest change in my thinking has been recognizing that an effective cybersecurity program is not defined by how many tools you deploy or how mature you appear on paper. It is defined by how well the program understands the business, identifies the risks that actually matter, and translates those risks into action.
Earlier in my career, the industry often approached security as a primarily technical problem. Today, I think about it much more as a business-risk and operational-resilience problem. You can have great technology and still have significant exposure because identity is poorly governed, systems are misconfigured, processes are fragmented, or nobody clearly owns the risk.
The strongest programs I have seen start with visibility and prioritization. Understand what you are protecting, how the business operates, where the material risks exist, and what would actually disrupt the organization. Then build the people, process, and technology around those realities.
That sounds simple, but it requires discipline. Security teams are constantly being presented with new threats, technologies, and regulatory requirements. Leadership's job is to separate what is urgent from what is simply loud.
You’ve highlighted the growing problem of cybersecurity debt. Where is that debt accumulating most rapidly, and what are organizations underestimating about it?
Cybersecurity debt is accumulating anywhere organizations are making short-term decisions without accounting for the long-term security consequences.
Identity is one of the biggest areas. Organizations accumulate excessive privileges, stale accounts, inconsistent authentication controls, and complex relationships between Active Directory, Entra ID, SaaS platforms, and cloud environments. Over time, those issues become very difficult to unwind.
Cloud and SaaS are another major source of debt. Business units can deploy technology incredibly quickly, but security architecture, configuration management, monitoring, and governance often lag behind.
There is also technology debt inside the security program itself. Organizations continuously add EDR, SIEM, CSPM, SSPM, identity, vulnerability management, and GRC platforms without retiring older capabilities or ensuring everything is properly integrated.
What organizations often underestimate is the compounding effect. One configuration gap may appear manageable. Hundreds of small gaps accumulated over five or ten years create an attack surface that nobody fully understands.
CISOnow brings CISO-level leadership to organizations without a traditional full-time CISO. When you first engage an organization, how do you identify the risks that actually need executive attention?
When CISOnow first engages with an organization, we try not to begin with technology. We begin with the business.
We want to understand what the organization does, what systems and data are essential to its mission, what could materially interrupt operations, what regulatory or contractual obligations exist, and where leadership already has concerns.
From there, we evaluate the security environment and connect technical findings back to business impact.
Executives typically don't need a list of 200 vulnerabilities. They need to understand: What could materially hurt us? How likely is it? What would the impact be? What are we doing about it? What resources or decisions are required?
One of the most important roles of a CISO is to reduce complexity. The security organization may be dealing with thousands of alerts, vulnerabilities, and controls, but executive leadership needs a much smaller set of prioritized risks that can be understood, owned, and acted upon.
With security stacks expanding across EDR, MDR, SIEM, identity, cloud, SaaS, and GRC, how do you distinguish between a genuine technology gap and a problem caused by tool sprawl or poor integration?
Before buying another security product, I usually ask three questions: Do we already own a capability that can address this problem? Is it configured and integrated correctly? And does someone actually own the operational process around it?
Very often, the problem isn’t that an organization lacks technology. It is that the technology it already purchased isn't being fully utilized.
I’ve seen organizations with very sophisticated security stacks where individual platforms may be operating at a fraction of their capability. Telemetry isn't integrated, alerts aren't tuned, workflows aren't defined, and nobody has the time to continuously optimize the environment.
That's why architecture and operational maturity matter so much.
A genuine technology gap exists when you have clearly defined the risk or operational requirement, and the existing architecture cannot reasonably address it. Tool sprawl happens when organizations keep purchasing technology before answering that question.
Your proprietary C³ Cybersecurity Assessment goes beyond compliance-driven evaluations. What does it uncover that conventional assessments often miss, and how do you turn those findings into actionable priorities?
One of the reasons we developed the C³ Cybersecurity Assessment was that many traditional assessments end with a compliance score or a very long list of findings.
Those outputs can be useful, but executives still ask, “What do we actually do first?”
C³ looks at the security program through the lens of recognized frameworks such as NIST CSF, CIS Controls, and ISO 27001, but the objective isn't simply to measure compliance. We look at how controls actually operate, how technology is being used, where operational dependencies exist, and whether the security program is aligned with the organization's real-world risk.
The most important output is prioritization.
We want an organization to leave the assessment understanding what needs immediate attention, what should happen over the next several quarters, what investments may be required, and what risks can reasonably be accepted.
A good assessment shouldn't sit on a shelf. It should become a practical security roadmap.
As vendors increasingly market AI-powered security capabilities, what evidence should buyers demand before trusting claims around AI-driven detection, analysis, or response?
The term “AI-powered” has become so common that buyers need to get much more specific.
I would ask the vendor: What exactly is AI doing? What data is the model analyzing? What decision is it making? What happens when it is wrong? And where does human validation occur?
Then ask for measurable evidence.
If a vendor claims AI improves detection, show the improvement in detection rates. If it reduces analyst workload, quantify the reduction. If it automates response, explain which actions are automated and what controls exist around those actions.
Buyers should also understand how their data is being used, whether it is retained, whether it is used to train models, and what protections exist around sensitive information.
AI can absolutely improve cybersecurity, particularly around analysis, correlation, and automation. But organizations should evaluate it the same way they evaluate any important security capability: based on evidence, transparency, and measurable outcomes rather than terminology.
When a security investment requires significant budget, what makes a cybersecurity business case credible to CFOs and other non-security executives beyond simply presenting the risk?
The strongest security business cases connect the investment to something the business already understands.
Saying “we have cyber risk” generally isn't enough. The question is what that risk means financially and operationally.
Could an incident interrupt revenue? Affect customers? Create regulatory exposure? Increase cyber-insurance costs? Require significant recovery resources? Prevent the company from meeting contractual requirements?
Then the CISO needs to explain what the proposed investment changes.
I also think security leaders should present alternatives. What happens if we fully remediate the risk? Partially mitigate it? Transfer some of it? Or accept it?
That changes the conversation from “security wants another tool” to an executive discussion about business risk and investment.
CFOs don't necessarily expect every cybersecurity investment to produce traditional ROI. They do expect clarity about why the organization is spending the money and what outcome it is buying.
A successful PoC can still fall short in production. What should buyers validate to uncover deployment friction, workflow impact, false positives, integration gaps, and the effort required from their security teams?
A PoC should test much more than whether the product technically works.
I want to understand what operating the product will look like six months after the sales engineers leave.
How difficult is deployment? How much tuning is required? How many false positives will the security team have to manage? Does it integrate with the organization's existing identity, SIEM, ticketing, and security infrastructure? Who will operate it? How many hours per week will that require?
I also want the actual analysts and engineers who will use the technology involved in the evaluation.
One of the biggest mistakes organizations make is evaluating technology in an artificially clean environment. Production environments are messy. There are legacy systems, business exceptions, incomplete inventories, and competing priorities.
A good PoC should intentionally expose those realities rather than avoid them.
CISOnow works across advisory, assessments, and security technologies. From this vantage point, what separates a technically strong security vendor from the right fit for an organization? What should CISOs look for before committing?
A vendor can have an excellent product and still be the wrong partner for a particular organization.
Technical capability matters, but fit also depends on operational complexity, integration requirements, internal skills, budget, support model, and where the organization is in its security maturity.
I look closely at implementation requirements and what happens after the sale. Who supports the customer? How quickly can issues be escalated? How much engineering is required from the customer's own team? How transparent is the vendor about limitations?
I also pay attention to whether the vendor is willing to tell a customer when their product isn't the right solution. That says a lot.
At CISOnow, we work across advisory services, assessments, and security technologies, which gives us the ability to evaluate a solution from the customer's side of the table. Sometimes the right recommendation is new technology. Other times, it is optimizing what the organization already owns.
Ultimately, the right technology is the technology that meaningfully reduces risk and that the organization can successfully operate.
