What a penetration test actually finds

A penetration test reveals vulnerabilities that provide access to systems, applications, accounts, or data. Basic testing results in a list of technical issues, while thorough testing identifies which weaknesses can be exploited, how they are interconnected, and the potential risks they pose to the business.

This transforms the findings list into a strategic decision tool for security leaders, internal IT teams, and boards that need to prioritise which issues require immediate attention.

A long report is not automatically a strong report. Length often hides the practical problem. Findings need to show what was accessible, which controls failed, what level of access was achieved and where the exposure sits in the business.

Penetration testing validates exploitable weaknesses

A vulnerability scan identifies suspected weaknesses. A penetration test validates whether those weaknesses create a realistic attack path.

The scope of a test determines what vulnerabilities can be uncovered. Different types of assessments—such as external infrastructure tests, internal network tests, web application penetration tests, cloud assessments, and Microsoft 365 security assessments—focus on different areas of security. It’s important to note that a narrowly scoped test of a single web application does not guarantee the overall safety of the wider network. Additionally, an external penetration test may not identify all internal access issues unless these aspects are explicitly included in the rules of engagement.

Exposed services are a common starting point. These include open ports, internet-facing admin panels, remote access services, development systems, forgotten subdomains and services that should not be publicly reachable. An exposed service is not automatically a serious issue. It becomes more important when it is unpatched, poorly configured, weakly authenticated or connected to systems that hold sensitive data.

Authentication and access control findings often carry more risk than they first appear to. Missing multi-factor authentication (MFA), weak password controls, poor lockout rules, shared accounts and excessive privileges all create pressure points. In web applications, broken access control is especially serious because it allows users to access data or functions they should not be able to.

Application findings vary by build, framework and business process. A web application penetration test might find injection flaws, insecure file uploads, poor session handling, unsafe error messages, weak application programming interface controls, or authorisation checks that fail during manual testing. Treating those weaknesses as developer-only issues hides the operational consequence. A client portal, payment process, case management system or internal workflow that exposes data creates accountability beyond the development team.

Configuration issues are another common category. Servers, firewalls, cloud services, Microsoft 365 tenants, and software platforms rarely fail due to a single dramatic mistake. More often, risk builds through small configuration decisions that nobody revisits. Default settings remain in place. Legacy protocols stay enabled. Test accounts are not removed. Storage is over-permissive. Logging is incomplete. Conditional access policies do not cover the accounts that matter most.

Patch gaps still matter, but not every missing patch deserves the same urgency. A critical vulnerability on an internet-facing system has a different risk profile from a low-impact issue on an isolated internal asset. A credible penetration test does not treat patching as a flat list. It shows which gaps are exploitable, what compensating controls exist, and where delays leave the organisation exposed.

Internal penetration testing often finds weaknesses in privilege, segmentation and credential handling. A tester might begin with standard user access and then identify routes to higher privileges, sensitive file shares, administrative tools or business systems. Poor segmentation allows one compromise to spread further than leadership expects. Excessive permissions make that movement easier.

Data exposure is one of the findings that forces non-technical leaders to pay attention. The issue might be a database, an export folder, a cloud storage location, a misconfigured application role or credentials stored where they should not be. The report needs to state what was accessible, from where, by whom and what the likely consequence would be.

Penetration testing can also expose monitoring and response gaps. If the test activity creates behaviour that should have triggered an alert, the Security Operations Centre (SOC), internal IT team, or outsourced provider needs to explain what was observed and what action was taken. If nobody notices, the finding is not limited to one system. It says something about operational detection.

Attack paths explain the business risk

Severity labels are useful, but they do not always explain business risk. A finding marked medium in isolation might become serious when combined with weak identity controls, excessive permissions and poor logging.

A tester might identify an exposed remote access service, enumerate users, test authentication controls, find reused credentials, access an internal system and then discover that the account has more permissions than expected. None of those stages should be judged only as standalone items. The risk comes from the chain.

Low-cost testing usually shows its limits at this point. Automated scanning identifies known weaknesses quickly. It is useful for coverage and routine hygiene. It does not reliably explain which combination of weaknesses gives an attacker a path to sensitive systems or data. Manual testing validates exploitability, removes false positives, and shows where remediation will reduce risk the most.

A vulnerability assessment identifies potential weaknesses. A penetration test tests whether those weaknesses stand up under controlled exploitation. A vulnerability assessment often produces coverage. A penetration test needs to produce evidence, prioritisation and context.

Evidence has to be specific. Screenshots, affected assets, test steps, payload examples, account context, access level, data exposure and business impact all matter. A finding that says “weak access controls were identified” is too vague to drive remediation. A finding that shows a standard user accessed another client’s record, exported sensitive data or reached an administrative function gives the business something concrete to fix.

Boards do not need every technical detail. They do need to know whether the finding affects revenue systems, client data, regulated information, privileged accounts, operational continuity or contractual assurance. A security lead needs enough detail to reproduce and fix the issue. A finance or operations leader needs to understand whether remediation requires internal time, supplier work, system changes, downtime, or additional controls.

Penetration testing is scoped, time-bound and point-in-time. A clean report does not prove that the organisation is secure. It proves what was tested, under what conditions and what was found at that time.

Treating one test as permanent assurance creates a false sense of control.

Strong findings are clear enough to fix

The quality of a penetration test is visible in the findings. A weak finding describes a problem. A strong finding provides the technical owner with enough evidence to reproduce the issue and leadership with enough context to understand why it matters.

A credible finding should include the affected asset, the tested route, the evidence collected, the level of access achieved, the likely impact and the recommended remediation. Where the issue is theoretical or dependent on other conditions, the report should say so. Where the issue creates direct exposure, the language should be plain.

This is where provider behaviour becomes visible. Some reports bury the client in severity labels, screenshots and generic remediation text. That pushes interpretation back onto internal teams that already have to manage users, suppliers, tickets, incidents, audits and system change.

Clear findings reduce ambiguity. They make it easier to separate critical issues from hygiene improvements. They help technical teams identify the owner. They help risk leaders explain the exposure without exaggerating it. They give the board a better answer than a colour-coded chart.

Conosco helps clients interpret penetration testing findings, prioritise remediation and involve the right technical owners where fixes are needed. The value lies in making the findings usable. A test that exposes weaknesses without giving the organisation a clear route to action leaves too much work unresolved.

A penetration test should leave the business with a sharper view of what can be exploited, which systems are affected and which findings need attention first. Anything weaker is hard to defend when leadership asks what the test actually found.

For more information on booking a Penetration Test with Assurance, speak to an expert today.