A penetration testing proposal arrives with a defined scope, a delivery schedule, and a price. A cyber incident arrives with uncertainty: which systems are affected, whether customer information is exposed, how long recovery will take, and who needs to be informed.
That difference matters in the boardroom.
Preventive security work can be planned around business priorities. Incident response competes with those priorities while the business is already under pressure.
For CEOs and IT Directors, the financial case for security testing starts with understanding the value exposed through everyday operations: customer accounts, payment workflows, confidential documents, and the systems employees rely on to work.
The cost of a breach extends beyond fixing the vulnerability
IBM’s 2025 Cost of a Data Breach Report recorded a global average breach cost of US$4.44 million, based on incidents experienced by 600 organizations. That figure provides context about the scale of potential damage; it is neither an SME-specific forecast nor evidence of a particular return on penetration testing. Source: IBM’s 2025 report announcement
An individual business needs its own loss model. Consider the costs that may follow a serious incident:
| Cost area | Potential business impact |
|---|---|
| Investigation and containment | Specialist support, forensic analysis, emergency access changes |
| Service interruption | Missed transactions, delayed delivery, manual workarounds |
| Recovery and engineering | Restoring systems, rebuilding environments, validating fixes |
| Customer and stakeholder response | Support demand, communications, contractual reviews |
| Legal and regulatory work | Advice, notifications, investigations, potential liabilities |
| Commercial disruption | Delayed deals, customer departures, additional security assessments |
Reputational damage deserves particular care. Assigning an arbitrary percentage of revenue to “lost trust” produces a weak business case. More useful measures include renewal delays, customer complaints, lost contracts, and additional procurement requirements.
The objective is to understand how an incident could affect this company’s ability to operate and earn revenue.
La Banque Postale: disruption can create pressure without a data leak
Between 22 December 2025 and 5 January 2026, La Poste Group’s infrastructure faced a distributed denial-of-service attack affecting access to digital services, including those of La Banque Postale in France.
According to the bank, the attack targeted internet access points. Its core banking system remained operational, with no intrusion, data alteration, or data leak. The bank also described the mobilization of approximately 400 cybersecurity and IT specialists across the group. Source: La Banque Postale’s incident review
This case illustrates the business importance of availability. Customers can experience disruption even when their information remains protected.
For an SME, the corresponding questions are practical:
- Can customers still place orders or access essential services?
- Can employees continue working if a critical platform becomes inaccessible?
- Have failover arrangements and communication procedures been exercised?
- Can the team distinguish an infrastructure failure from an attack?
A conventional application penetration test addresses only part of this exposure. Availability also requires appropriate protective infrastructure, monitoring, and authorized resilience exercises coordinated with hosting and service providers.
Binance: the loss was followed by an extensive recovery effort
On 7 May 2019, Binance disclosed a security breach in which attackers withdrew 7,000 BTC from its hot wallet. Its announcement described compromised API keys, two-factor authentication codes, and other potentially affected information. Binance said it would cover the incident through its SAFU fund and suspended deposits and withdrawals during its security review. Source: Binance’s May 2019 breach announcement
In a subsequent update, Binance described changes to API security, two-factor authentication, withdrawal validation, and risk management. It also reported working with external security specialists and other organizations to investigate and track the stolen funds. Source: Binance’s security incident update
The business lesson extends beyond the stolen assets. An incident can require simultaneous investigation, engineering changes, service restrictions, and sustained communication.
These public accounts do not establish that a specific penetration test would have prevented either incident. They illustrate different loss scenarios that a security programme should consider: compromised assets, exposed access mechanisms, and interrupted services.
Why testing still loses budget discussions
Testing has a visible cost. The loss it might help prevent remains uncertain.
That creates an uneven comparison. A product feature has a delivery date and an expected commercial benefit. A security assessment may identify work that consumes additional engineering capacity.
Three management practices can reinforce this problem.
First, ownership is fragmented. IT pays for testing, while operations, sales, customer support, and leadership absorb much of the disruption following an incident.
Second, teams measure activity instead of outcomes. A vulnerability count says little about whether an attacker could access another customer’s records or approve an unauthorized transaction.
Third, remediation is treated as a separate budget problem. Findings accumulate because the assessment was funded without reserving time to fix and retest them.
A stronger proposal connects the work to a business scenario:
Validate whether a compromised customer account could access another organization’s documents, then remediate and retest any confirmed authorization weaknesses.
That scope gives executives a clearer basis for deciding what deserves funding.
Can prevention really be ten times cheaper?
A testing programme may cost a fraction of a serious incident’s impact. However, a universal “10 times cheaper” claim requires evidence that accounts for testing scope, remediation costs, incident likelihood, and the losses actually avoided.
Consider this hypothetical example, using illustrative figures rather than market prices or a FIX quotation:
| Budget item | Illustrative amount |
|---|---|
| Scoped assessment and penetration testing | US$8,000 |
| Remediation and retesting | US$7,000 |
| Total preventive programme | US$15,000 |
| Estimated impact of one defined incident scenario | US$150,000 |
The incident impact is ten times the programme cost. That comparison does not demonstrate a tenfold return: the incident may never occur, and the programme cannot eliminate every attack path.
A more useful decision model is:
Estimated reduction in annual expected loss − annual programme cost
For example, if a US$150,000 loss scenario has an assumed annual probability of 15%, its expected annual loss is US$22,500. If the proposed controls reduce that probability to an assumed 5%, the expected loss becomes US$7,500.
The estimated reduction is US$15,000—equal to the illustrative programme cost.
Those probabilities are assumptions to challenge, rather than measured outcomes. Their purpose is to make the reasoning visible. Leadership can then examine whether the scope, costs, and expected risk reduction justify the investment.
A practical security testing roadmap for SMEs
1. Identify the business workflows that matter most
Start with systems that hold sensitive information, move money, or support essential operations.
For a B2B platform, that might include customer login, tenant separation, administrator access, document exports, and billing integrations.
Choose a small number of consequential scenarios before expanding coverage.
2. Address basic control gaps
Review access privileges, multifactor authentication, exposed services, software dependencies, and backup restoration.
Fixing obvious weaknesses first can help a specialist assessment concentrate on deeper problems. The appropriate sequence depends on the urgency and exposure of the system.
3. Commission a clearly scoped penetration test
Define the applications and APIs included, user roles available to testers, business logic to examine, testing window, and permitted techniques.
Agree on rules of engagement, data handling, escalation contacts, and stop conditions before execution.
Request findings that explain the affected workflow, evidence, business impact, and recommended corrective action.
4. Fund remediation and retesting together
Reserve engineering capacity when approving the assessment.
Assign an owner and target date to each material finding. Retest the relevant attack path after changes are made, and document any residual risk accepted by management.
A report becomes useful when its findings change the system.
5. Combine periodic testing with change-based reviews
Set testing frequency according to system exposure, business impact, contractual obligations, and applicable requirements.
Significant changes can justify additional testing between scheduled assessments: a new payment flow, revised permissions, a cloud migration, or an integration that introduces sensitive data access.
Automated checks can support routine coverage. Manual testing remains valuable for complex authorization and business logic.
6. Give leadership a short, actionable risk view
Track unresolved high-impact findings, remediation time, verified fixes, critical workflows tested, and risks awaiting a management decision.
This makes the budget discussion more concrete: leadership can see what was examined, what improved, and where exposure remains.
Turn security testing into an implementation plan with FIX
An effective engagement needs a path from business priorities to test execution, corrective action, and verification.
FIX’s Quality Engineering & Testing services support risk-based testing, security validation, and quality practices across the software lifecycle. Penetration testing can be included in an agreed engagement, delivered directly or through qualified partners according to project requirements.
Speak with FIX about consultation and implementation for your security testing programme. Share your application, critical workflows, and current concerns so the team can discuss an appropriate scope, delivery approach, and remediation and retesting requirements.
