A penetration test is not a risk number: what finance can and cannot take from the report

What does a penetration test report tell a CFO? It tells you what a tester was able to do, against a defined set of systems, during a defined set of days. It does not tell you what a breach would cost or how likely one is. A count of findings and a red, amber or green rating are not a risk number, and the report was never written to be one.

This piece is for the CFO of a mid-market company, whatever the ownership, who has just received a report or is about to commission one.

What does a penetration test actually do?

The U.S. National Institute of Standards and Technology (NIST) published its technical guide to security testing, Special Publication 800-115, in September 2008. It defines penetration testing as “security testing in which assessors mimic real-world attacks to identify methods for circumventing the security features of an application, system, or network.” Most tests, it says, look for combinations of weaknesses that together give an attacker more access than any one of them would.

The guide also lists what a test can help show. One item is “Defenders’ ability to detect attacks and respond appropriately.” That one matters to finance. A test can tell you whether anyone noticed.

The PCI Security Standards Council, which writes the payment card data standard, separates a penetration test from a vulnerability scan. In its 2017 supplement, a scan is “typically a variety of automated tools combined with manual verification.” A penetration test is “a manual process that may include the use of vulnerability scanning or other automated tools.” If a report is mostly a scan export, you have bought the cheaper thing. Ask which one you received.

Two limits follow from how the work is done. The first is scope. The PCI supplement outlines a report with a “Statement of Scope” and a “Statement of Limitations,” the latter covering restrictions such as testing hours and special handling for older systems. NIST says the rules of engagement should be signed by the test team leader and senior management, who confirm they understand “the test’s scope and boundaries.” What was left out is written down somewhere. It is usually near the front.

The second limit is time. NIST says an assessment “provides a snapshot of security at a given point in time.” A test run in March describes March. A new application in June, a changed vendor or a departed administrator makes it older than the calendar says.

Why is a count of findings not a risk number?

Suppose last year’s report listed two critical, five high and nine medium findings. This year’s lists one critical, six high and fourteen medium. Is the company safer? You cannot tell from those counts. A different tester may rate the same weakness differently. The scope may have grown or shrunk. A single critical finding on a test server holding no data may matter less than a medium one on the system that bills customers.

The most common scoring system behind those ratings says as much about itself. FIRST, which maintains the Common Vulnerability Scoring System, states in its version 4.0 user guide that the base score is “designed to measure the severity of a vulnerability and should not be used alone to assess risk.” It adds that the score is independent of “any factor associated with threat or the computing environment where the vulnerable system resides.” So the score describes the weakness. It does not describe your company.

The PCI supplement is candid on the same point. It says severity or risk ranking is a “common practice” and that the report “should clearly document how the severity/risk ranking is derived.” Where testers adjust a standard score, the report should show “a traceable set of reasoning.” Read that as a request you can make. If a rating changed from the standard score, you are entitled to see why.

Our view is that severity answers a technical question: how bad is this weakness in general? A financial question has three parts. How likely is a loss at our company this year? What would it cost? What would change those numbers? NIST’s December 2025 report on estimating cybersecurity risk, IR 8286A Rev. 1, describes exposure as “the product of likelihood and impact.” It also says “without supporting data, well-intentioned but misguided methods of risk analysis amount to little more than a guess.”

That second sentence cuts both ways. A tester who prints a dollar figure at the end of a technical report is estimating loss with data the tester may not have. Your revenue by system, your contract penalties and your recovery costs sit in your own records. A report can feed the likelihood side. NIST’s same report notes that if “several critical software vulnerabilities have remained uncorrected, there is an increased likelihood that a threat actor will be able to exploit a software vulnerability.” The findings are evidence. They are not the estimate.

Illustration, not data. Assume a test finds that an attacker could reach the customer billing database. Assume your finance team estimates an outage and clean-up would cost $2 million. Assume the IT lead puts the chance of that path being used in a year at 5 percent before the fix and 1 percent after. The numbers are invented and the method is a simple product. The point is that the 5 percent and the $2 million come from different people. The tester supplied neither.

What can finance reasonably take from the report?

More than it usually does. A report is a good source of facts about the company even when it is a poor source of a dollar figure. Five are worth pulling out.

• What was tested. Which systems, from outside or inside, and what the tester was given to start with.
• What was not tested. The limitations section, and anything the company chose to exclude.
• What is being done. Each finding that matters, with an action, a date and a cost where one exists.
• Who owns each decision. A name next to every action, and a name for any finding the company decides to leave open.
• What would change a decision. A change to the system, a new contract, a sale process or a renewal that would make the answer different.

NIST makes a related point in its guide. It says “a security test is much more valuable if it also results in a mitigation strategy being developed and implemented.” It also says the analysis should look for root causes, which may be “weaknesses in organizational processes and procedures as well.” A report whose fixes are all patches may have missed that. A report that says access reviews have lapsed has told you something about management, which is your territory.

The PCI supplement adds a point about cost. After fixes, the tester should retest “to validate the newly implemented controls mitigate the original risk.” If fixes drag on, it says a new test may be needed to reflect the current environment. A retest is a line in a budget. Ask whether it was priced into the first engagement.

NIST also lists uses for results that finance will recognize. One is to “conduct cost/benefit analysis for improvements to system security.” That analysis needs a cost for each fix and a loss estimate for each exposure. The report supplies the first only in part and the second not at all.

How might a board, lender, insurer or buyer read the report?

We can describe the questions without claiming what any of them requires. Your own advisors can say what applies to you.

A board member is likely to ask whether the company is safer than last year and what it would take to be sure. A report with changing scope cannot answer the first. A lender or an insurer may ask who has seen the report and what was done. A buyer in a sale process may ask for the report and read the open items as a to-do list for the price. In each case the same pattern holds. People read the gap between what was found and what was fixed, and they read who is named beside it.

There is also a smaller point about signatures. NIST describes senior management signing the rules of engagement. At a company without a CIO or CISO, someone still has to sign. We take that up in who owns technology when there is no CIO.

What should you ask the tester and the IT lead?

Put these to the tester before the final report is accepted.

• Which findings did you confirm by hand, and which came from a tool?
• What did you not test, and why?
• Where did you change a standard severity rating, and on what reasoning?
• Did anyone at the company notice you during the test?
• What would a retest cost, and what would it need to confirm?

Put these to the IT lead or the managed service provider.

• For each critical and high finding, who owns the fix and by what date?
• Which findings are you proposing to leave open, and who decides?
• Which of these findings share a cause, such as access reviews or patching?
• What changed in the environment since the test?

What should you take to your broker, auditor or counsel?

These are questions for your own advisors. We state no answer.

• To your broker: does the cyber application ask about penetration testing or open findings, and who at the company signs the answers?
• To your broker: if a test finds something after a policy begins, what do you want to be told and when?
• To your auditor: does the report change anything the auditors will ask the company about technology controls?
• To counsel: who should receive the report, and does how it is stored or shared matter?
• To counsel: does any contract, lender agreement or customer agreement mention testing or require delivery of results?

Where Preside fits

Preside is a Technology Operating Partner. It owns the reporting on technology cost, risk and direction to the CFO and the board, and works alongside your IT lead or managed service provider.

Preside does not perform penetration tests. It looks at the same ground from the finance and risk side: the exposures a test is likely to report, and what each could cost, as a dollar range with the inputs shown. When the work needs a specialist, Preside writes the scope, chooses the specialist, briefs them on your environment and oversees the work, so nothing resets. Preside is not paid by the providers it recommends.

FAQ

What does a penetration test report tell you?

It describes what a tester could do against a defined scope in a defined period. NIST describes penetration testing as assessors mimicking “real-world attacks.” Reports usually cover scope and method. They also list findings, severity ratings and fixes. They do not state the likelihood or dollar cost of a breach at your company.

Is a penetration test the same as a vulnerability scan?

No. The PCI Security Standards Council describes a scan as typically automated tools with manual verification, and a penetration test as “a manual process” that may use automated tools. A test tries to exploit weaknesses to defeat security features. A scan identifies and ranks them. PCI’s own rules call for scans more often than tests.

Can a penetration test give a dollar risk figure?

Not by itself. A dollar figure needs a likelihood and a cost of the event. NIST IR 8286A Rev. 1 describes exposure as the product of likelihood and impact. A test provides evidence for likelihood. Cost comes from your own records. Any dollar figure in a report should show its inputs and who supplied them.

How often should a company run a penetration test?

NIST’s 2008 guide says that because of its “high cost and potential impact,” testing “on an annual basis may be sufficient.” The PCI supplement says tests are required “at least annually and upon significant changes” for entities under that standard. Other obligations vary. Ask your auditor, insurer and counsel what applies to you.

Get a brief

If you want to talk through a report you have received, or one you are about to commission, get a brief. We send a note back, and it takes about twenty minutes to talk it through.

Sources

1. Technical Guide to Information Security Testing and Assessment (SP 800-115). NIST, September 2008. https://csrc.nist.gov/pubs/sp/800/115/final (record page) and https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-115.pdf (full text, sections 5.2, 5.2.2, 6, 7.3, 8.1, 8.2, Appendix B). Used for the penetration testing definition, what a test can show, snapshot-in-time, rules-of-engagement signatures, mitigation and root cause, uses of results, and the annual-testing sentence. Limits: written in 2008 for U.S. federal practice. Tools and threats have changed. It says nothing about dollar loss.
2. Information Supplement: Penetration Testing Guidance, Version 1.1. PCI Security Standards Council, September 2017. https://listings.pcisecuritystandards.org/documents/Penetration-Testing-Guidance-v1_1.pdf. Used for scan versus test, scope and limitations sections, severity ranking, retesting, and the annual-test statement. Limits: supplemental guidance for payment card environments. It says it does not replace any PCI standard. Nine years old.
3. CVSS v4.0 User Guide. FIRST. https://www.first.org/cvss/v4-0/user-guide. Used for the base score being a measure of severity and not risk. Limits: describes the scoring system only. Reports may use other systems.
4. Identifying and Estimating Cybersecurity Risk for Enterprise Risk Management (NIST IR 8286A Rev. 1). NIST, December 2025. https://doi.org/10.6028/NIST.IR.8286Ar1 (full text at https://nvlpubs.nist.gov/nistpubs/ir/2025/NIST.IR.8286Ar1.pdf). Used for exposure as the product of likelihood and impact, the “little more than a guess” warning, and the effect of uncorrected vulnerabilities on likelihood. Limits: guidance, not a requirement.
5. Preside’s description of its own role. Used only for the Preside section. Limits: Preside’s own statement.