Home / Knowledge hub / Informational finding
Knowledge hub
Informational finding
An observation that is not a vulnerability but is worth knowing about.
What it means
An informational finding is something a tester noticed that is not a vulnerability on its own but may help an attacker, or point at a weakness in practice. A server version in a header, a verbose error, a missing optional security header and an exposed test page are typical examples.
The label says there is nothing to exploit directly. It does not say there is nothing to do. It marks items for your judgment, outside the main list of fixes that need to be scheduled, so that the team can decide each one on its merits.
Why it matters
Informational items give an attacker context. A version number points to known flaws. A stack trace reveals file paths and libraries. A comment in the page source mentions an internal system. None breaks in by itself, but each shortens the guesswork for the next step.
They also test a report's honesty. Reports padded with informational items to look thorough bury the findings that matter. A report with none might be hiding observations. A good one keeps them in a separate section and says plainly why each is there.
How it shows up
Look at three questions. Could it help someone use a real flaw? Does it breach a standard you must follow, such as a header requirement? Is it cheap to fix? If the answer to any is yes, fix it in a routine change and move on. Note that an item can be informational in one app and a real finding in another, depending on what it exposes.
Do not let them enter the vulnerability backlog as if they were urgent. Keep them separate, review them in batches, and accept the ones you decide to leave (see risk acceptance). Related fixes are often one-line configuration changes, such as security headers or error handling.
Questions people ask
Informational finding, answered
Is an informational finding a vulnerability?
Not on its own. It is an observation about the app, not a flaw you can use directly. Some can become part of a chain that leads to a real vulnerability when combined with other weaknesses.
Do we have to fix informational findings?
Not by default. Fix those that are cheap, those that leak useful detail, and those a standard or customer requires.
Record a decision for the rest, even if the decision is to leave it.
How is it different from low severity?
A low severity finding is a real flaw with limited impact. An informational one is not a flaw at all, only something worth knowing.
The line is not always sharp, so reports should explain their choice.
Do auditors care about them?
Sometimes. A compliance review may treat a missing required header as a finding, whatever the label says in a pentest report.
Check what the standard actually demands.
Should they be in the report?
Yes, in their own section, short and clearly separate. Hiding them withholds context. Mixing them with real flaws buries the important items.
Keep each to a line or two.
Sources
Where this comes from
Related
Terms that sit next to this one
Security headers
Response headers that switch on browser protections against common web attacks.
Severity
How bad a finding is, from critical down to informational.
Security finding
One confirmed weakness in a report, with the evidence to show it is real.
Penetration test report
The document that lists what was found, how, how bad it is and how to fix it.
Risk acceptance
Deciding, on the record, to live with a known issue rather than fix it.
Is it noise or a clue?
Our report keeps what we exploited apart from what we only observed, so the serious items are not buried under notes. If we did not break it, we do not report it as a finding. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.