Informational Findings: When They Belong in a Pentest Report

An informational finding belongs in a pentest report when it changes what the client knows or should do: it makes another weakness easier to exploit, it will become a vulnerability if nothing changes, or it limited what the test could cover. Observations that change nothing, such as an open port the client expects or a banner with nothing behind it, belong in an appendix of raw output or nowhere.

What informational should mean

An informational finding has no direct impact of its own that the tester can describe and evidence, so it carries no severity. That is the whole difference from a low: a low finding has a real, if small, consequence, and an informational one does not until something else is added to it. If you can write the impact, the finding is at least low.

The rating is decided by the evidence, not by how far the tester got. A finding with a plausible route to harm is not informational because the time ran out before it was exploited; rate it on what the evidence shows and say what was not confirmed. Penetration testing severity levels covers the scale either side of it.

The common failure is using informational as a place to put everything a scanner said. A report with three rated findings and forty informational ones buries the three, and the reader who has to scroll past the forty learns to skip the section, including the one entry in it that mattered.

Four kinds worth writing up

• Contributing factors. Detailed error messages, version disclosure or a predictable naming pattern that made another finding easier to exploit. Say which finding it contributed to, so the reader sees why it is there.
• Hardening with no exploit today. A missing security header on a page with nothing that could be abused through its absence, or a service that answers more than it needs to. Worth a short entry as defence in depth, not as a demand.
• Things that will become findings. A certificate that expires next month, software that leaves vendor support this year, a deprecated protocol still enabled for one legacy client. Give the date, because the date is the point.
• Observations about the test itself. Rate limiting or a web application firewall that blocked tests, accounts that expired midway, a part of the scope that was unreachable. These change what the report can claim to have covered, and the client needs to know; proving what you tested when a client asks covers why.

What to leave out

Leave out anything you cannot justify in one sentence. Open ports and services the client expects are in the scope, not in the findings. A banner that reveals a fully supported version tells the reader nothing to act on. Every cipher suite a server offers is detail, not a finding; if there is a weak one, that is a rated finding, and the rest are output.

Scanner output deserves particular care, because tools report every observation as a result. Collapse it into one entry per issue before deciding whether the issue belongs at all; deduplicating vulnerability scanner findings covers how. Where the raw output is genuinely useful to the client, an appendix holds it without pretending each line is a finding.

How to present them

Keep informational entries apart from the rated findings, after the lows, under their own heading, so the severity order of the report stays honest. Each entry needs only four things:

1. A title that says what was observed and where.
2. The observation, in two or three sentences.
3. Why it matters: the finding it contributes to, the date it becomes a problem, or what it stopped the test from covering.
4. A suggestion, worded as a suggestion rather than a requirement.

Give them no score. A number invites someone to rank an entry against the rated findings, and an informational entry ranked anywhere is ranked wrongly. Group similar observations into one entry listing every host, as you would a rated finding.

Written well, an entry is short enough to read in passing and clear enough to act on:

Detailed error messages on the customer API. When a request is malformed, the API returns the full error from its framework, including the names of internal classes and the version of the database driver. This gave us the table names we used in finding 4, and it would shorten the work of anyone attempting the same. We suggest returning a generic error to the caller and keeping the detail in the server’s own logs.

Three sentences say what was seen, why it matters here and what to do, and the reference to finding 4 tells the reader this is not filler.

Informational findings and the client’s numbers

Clients track findings by severity, and informational entries should not distort those numbers. Leave them out of remediation targets, since there is nothing with a deadline to fix; vulnerability remediation timelines sets targets for the rated levels only. Leave them out of the headline counts in the executive summary too.

Keep them in the record all the same. The next test can then see whether the hardening was done, and an informational entry that appears in three consecutive reports is a pattern worth a sentence in the third one.

Some clients ask for informational entries to be removed from the report altogether, usually because the report goes to a customer or an auditor. That is a reasonable request: provide them separately, and say in the report that informational observations were supplied in a separate note, so nobody reading it concludes they were never made.