Skip to content 
A security program is not underfunded simply because its budget is smaller than a peer’s. It is underfunded when the organization knows it has material risks or required controls and cannot operate, test or remediate them at the level its business needs.
That distinction matters for regulatory exposure. Regulators generally do not use one universal cybersecurity spending percentage. They look at the applicable obligations, the nature of the data and services involved, the organization’s risk, the controls that were expected and the evidence showing whether those controls were implemented and maintained.
The real danger is therefore not a low budget number. It is unfunded control debt.
The Security Funding Chain
A useful way to test whether security funding is adequate is to follow the money from risk to evidence.
| Stage | Question | Underfunding signal |
|---|---|---|
| Risk | Which business losses matter most? | No agreed priority scenarios |
| Control | Which safeguards reduce those losses? | Known control gaps remain unfunded |
| Operation | Who runs the controls? | Tools exist without enough operating capacity |
| Testing | How do we know the controls work? | Assurance depends on configuration screenshots or policy text |
| Remediation | How quickly are serious gaps fixed? | High-risk findings age without owners or dates |
| Evidence | Can the company demonstrate all of the above? | Audit and incident evidence must be recreated after the fact |
If the budget funds technology but not operation, testing and remediation, the organization may still have weak security outcomes.
Control debt is the better measure of underinvestment
ITechTrove uses control debt to describe a known security requirement that is incomplete, unreliable or untested.
Examples include:
- privileged users without the required authentication control
- critical systems missing from centralized logging
- unsupported software with no approved compensating control
- high-risk vulnerabilities beyond the remediation target
- backup recovery objectives that have never been tested
- former employees or service identities with unnecessary access
- critical suppliers with overdue risk reviews
Control debt is more useful than a broad maturity score because each item can have an owner, business impact and remediation cost.
NIST CSF 2.0 shows why funding must cover the full lifecycle
The NIST Cybersecurity Framework 2.0 organizes cybersecurity outcomes around six functions: Govern, Identify, Protect, Detect, Respond and Recover.
That structure is useful for funding because weak programs often concentrate spending in only one or two areas. An organization may have strong endpoint protection but poor asset inventory. It may collect logs but have no detection engineering. It may have incident-response software but no rehearsed recovery process.
NIST’s framework is outcome-based rather than a required spending formula. See the official NIST Cybersecurity Framework 2.0.
A budget review should ask which of the six functions contain the highest unresolved control debt.
Underfunding often appears first in the boring controls
High-profile security products are easier to justify than maintenance work. Yet many important controls depend on repetitive operational discipline.
Examples include access reviews, asset ownership, patching, log onboarding, detection tuning, backup testing, supplier reviews, tabletop exercises and remediation tracking.
These activities rarely produce a dramatic dashboard for executives. They do produce evidence that the security program is functioning over time.
When budgets tighten, cutting these activities can create a dangerous pattern: the company keeps the tools but loses the people and processes that make the tools effective.
Logging without investigation capacity is not complete coverage
A regulatory or incident-response requirement may call for appropriate logging, but collecting logs is only the beginning.
The organization also needs to know:
- which critical systems are covered
- whether timestamps and identities are reliable
- how long relevant records are retained
- which detections depend on those logs
- who investigates a high-confidence signal
- how evidence is preserved during an incident
A large SIEM bill cannot compensate for missing critical telemetry or an investigation queue nobody can service.
Remediation delay is where budget pressure becomes visible
A useful funding metric is not the number of security findings. It is the age of serious findings after the organization has decided they matter.
Track high-risk issues that exceed their remediation target. For each one, record whether the blocker is technical complexity, business availability, vendor dependency, staff capacity or lack of approved funding.
That gives leadership a direct view of where budget decisions are extending exposure.
Do not assume every overdue finding creates a regulatory violation. The importance depends on the applicable requirement and risk. But a repeated pattern of known, high-impact gaps without credible remediation is much harder to defend than a documented exception with an owner, rationale and time-bound plan.
A Minimum Viable Security Capability
Smaller organizations and fast-growing companies often cannot fund every advanced security capability at once. The answer is to sequence investment around a minimum viable capability rather than buying a little of everything.
A practical baseline should be able to:
- identify critical assets and data
- control and revoke access
- patch or otherwise manage known high-risk exposure
- collect enough evidence to investigate important events
- detect a defined set of material attack scenarios
- contain compromised identities or systems
- restore critical services from tested recovery paths
- manage significant supplier dependencies
- document exceptions and ownership
Only after those capabilities are dependable should the organization assume that another specialized tool will create more value.
People capacity is part of the control
Security budgets often separate headcount from technology as if one is overhead and the other is capability.
For many controls, that separation is artificial. Detection requires engineering and triage. Identity governance requires lifecycle administration. Cloud security requires architecture and remediation. Incident response requires people who know how the business systems fit together.
A useful budget proposal should therefore show operating capacity per control. If a new product needs two engineers to configure and maintain it, include that cost before approval.
Regulatory exposure is jurisdiction-specific
Cybersecurity obligations differ across privacy, financial, healthcare, critical-infrastructure and other regulatory regimes. A company should not assume that one framework or certification satisfies every obligation.
The safer approach is to maintain a requirement-to-control map:
| Requirement | Control | Owner | Evidence | Funding gap |
|---|---|---|---|---|
| Applicable obligation | How the requirement is met | Named accountable team | Test, log, report or record | What is not currently funded |
This makes regulatory funding discussions concrete. Legal and compliance teams can identify the obligation. Security and engineering can identify the control. Finance can see the cost of the gap.
Do not use arbitrary percentage benchmarks as the target
Industry spending surveys can provide context, but they are weak as a primary budgeting method.
Two companies with the same revenue may have completely different exposure because one processes regulated personal data, runs critical infrastructure or operates a large internet-facing environment while the other does not.
A stronger security budget starts with material loss scenarios and required obligations, then funds the control coverage needed to reduce them to an accepted level.
For a deeper allocation model, see ITechTrove’s guide to cybersecurity budget allocation mistakes.
What boards should see
Boards do not need a monthly inventory of security products. They need evidence of material risk and unresolved exposure.
A useful dashboard can include:
- critical control debt past due
- high-risk exceptions without current owners
- critical assets without required identity or logging coverage
- recovery tests that missed objectives
- open high-severity audit findings
- material supplier findings past due
- incidents that exposed a known unfunded control gap
That allows leadership to see where a funding choice is also a risk-acceptance choice.
A funding decision template
Every material security request should answer six questions:
- Which business or regulatory risk does this address?
- What control gap exists today?
- What evidence proves the gap exists?
- What people and operating cost are required after purchase?
- How will we test whether the control works?
- What exposure remains if the request is not funded?
This is more defensible than describing a product as “best practice” without tying it to an actual requirement or loss scenario.
Final takeaway
Underfunded security programs increase regulatory exposure when limited resources turn known risks into persistent control gaps, weak evidence, delayed remediation and untested recovery.
The goal is not to hit a universal cybersecurity spending ratio. It is to make sure the controls required by the organization’s risk and obligations can actually be operated and tested.
Track control debt, fund the full security lifecycle and make unresolved gaps visible to the people who are accepting the risk. That creates a much stronger regulatory and operational position than simply increasing the security budget without knowing where the money needs to go.
Author
Talha Qureshi is the founder and technology writer behind ITechTrove. He covers enterprise AI, cybersecurity, cloud infrastructure, B2B SaaS and emerging technology through practical, source-based analysis.
