What Happens After a Penetration Test?

A penetration test does not end when the tester stops testing. Finding security weaknesses is only the first stage. The real value comes from understanding the results, correcting the problems and confirming that the fixes work.

After the testing finishes, you should receive a clear report explaining what was discovered, how serious each issue is and what your organisation should do next. You may also receive a technical walkthrough, support during remediation and a retest once the vulnerabilities have been addressed.

Here is what you should expect after a professional penetration test.

Critical findings should not wait for the report

You should not have to wait until the end of the engagement to learn that an attacker could compromise a critical system.

If the tester identifies an urgent vulnerability, such as unrestricted administrative access, exposed customer information or a route to take control of the network, they should notify your nominated contact immediately.

This allows your organisation to begin containing the risk while the rest of the testing continues. The notification should provide enough information for your technical team to understand the problem without disrupting the assessment unnecessarily.

Less urgent findings will normally be documented in the final report.

The tester prepares the penetration testing report

Once testing is complete, the tester analyses the evidence and prepares the report.

A good penetration testing report should work for two different audiences. Senior decision-makers need a concise explanation of the overall risk, while technical teams need enough detail to reproduce and correct each vulnerability.

The report will normally include:

• An executive summary
• The agreed scope and testing dates
• The methodology used
• Any testing limitations
• An overall assessment of the security posture
• Individual vulnerability findings
• Evidence showing how vulnerabilities were confirmed
• An explanation of the potential business impact
• Clear remediation recommendations
• A severity or risk rating for each finding

The report should prioritise the issues that present the greatest genuine risk. It should not simply reproduce the output of an automated vulnerability scanner.

The findings are reviewed with you

Receiving a report by email should not be the end of the conversation.

A post-test walkthrough gives your team an opportunity to discuss the findings directly with the tester. The tester can explain how an attack worked, which systems were affected and how separate weaknesses may have been combined.

This can be particularly important when several apparently minor problems form a more serious attack path.

For example, a tester might discover that an ordinary user can access an internal file containing a service account password. That password may then provide administrative access to a server, allowing the tester to obtain additional credentials and eventually compromise the wider domain.

The individual weaknesses matter, but understanding the complete attack path helps the organisation address the underlying causes rather than treating each symptom in isolation.

Your organisation agrees remediation priorities

Not every vulnerability can or should be treated in exactly the same way.

The report’s severity ratings provide a starting point, but remediation should also consider:

• Whether the affected system is exposed to the internet
• The sensitivity of the information involved
• Whether exploitation requires authentication
• How easily the vulnerability could be exploited
• Whether public exploit code exists
• Whether the weakness is already being exploited in the wild
• The importance of the affected system
• Existing monitoring and protective controls
• The operational effect of applying the fix

Critical and high-risk findings will normally require urgent attention. Medium and lower-risk issues should be planned according to the organisation’s risk appetite and remediation process.

Some fixes may be straightforward, such as removing an unnecessary service or changing an insecure configuration. Others may require application development, infrastructure changes, supplier involvement or a carefully managed maintenance window.

Remediation work begins

Responsibility for fixing the findings normally remains with the organisation being tested, its internal IT team, software developers or managed service provider.

The penetration testing company should still be available to clarify its recommendations.

A remediation recommendation should be specific enough to be useful. “Apply secure configuration” is not particularly helpful. The report should explain what needs to change and, where appropriate, refer to relevant vendor guidance or recognised security standards.

Your team should also look beyond the individual affected system.

If one server was using a shared administrative password, for example, the same practice may exist elsewhere. If one application endpoint was missing an access-control check, similar endpoints may contain the same weakness.

Effective remediation addresses both the reported instance and the wider root cause.

Some risks may be accepted rather than fixed

It may not always be practical to eliminate every finding immediately.

A legacy system might be awaiting replacement, a supplier may need time to provide a patch, or the cost of a change may be disproportionate to the immediate risk.

Where a vulnerability cannot be corrected promptly, the organisation should make a documented risk decision. Temporary measures might include:

• Restricting network access
• Disabling unnecessary functionality
• Increasing monitoring
• Adding multi-factor authentication
• Introducing an application or network filtering rule
• Removing public exposure
• Limiting access to specific users or locations

Risk acceptance should be an informed business decision, not simply the result of a finding being left unresolved.

The tester retests the fixes

Once remediation is complete, the tester should verify that the reported vulnerabilities have been corrected.

A retest is usually narrower than the original assessment. It focuses on the affected components and the evidence needed to determine whether each finding can be closed.

The result may be recorded as:

• Remediated
• Partially remediated
• Not remediated
• Risk accepted
• Unable to retest

A partially remediated issue may mean that the original attack has been made more difficult but the underlying weakness still exists. It can also mean that one affected system was corrected while similar systems remain vulnerable.

The tester should explain any remaining exposure clearly.

At Plainsight Security, remediation retesting is included in the engagement. We want clients to finish with verified fixes, not simply a list of problems.

An updated report or closure statement is issued

Following the retest, the original report may be updated to show the remediation status of each finding. Alternatively, the tester may issue a separate retest or closure document.

This evidence can be useful when demonstrating remediation to:

• Customers
• Auditors
• Insurers
• Regulators
• Procurement teams
• Senior management
• Investors
• Internal risk committees

The original finding should normally remain visible so that the report preserves an accurate record of what was discovered. Its status can then be updated to show that remediation was verified.

Lessons should feed into the wider security programme

A penetration test is a snapshot of the environment at a particular point in time. It does not guarantee that the organisation will remain secure indefinitely.

The findings should be used to identify broader improvements.

These might include:

• Improving security update management
• Reviewing administrative privileges
• Strengthening software-development practices
• Introducing regular vulnerability scanning
• Improving asset management
• Reviewing network segmentation
• Enhancing logging and monitoring
• Providing targeted staff training
• Updating secure configuration standards
• Testing other similar systems

Patterns are especially important. Several findings caused by weak access control, for example, may indicate a development or design problem rather than a handful of unrelated mistakes.

Plan when testing should happen again

Penetration testing should be repeated when the risk or environment changes materially.

A new assessment may be appropriate following:

• A major application release
• Significant infrastructure changes
• A cloud migration
• A merger or acquisition
• The introduction of remote-access services
• A serious security incident
• A customer or regulatory requirement
• Changes to sensitive business processes

Many organisations also arrange annual testing as part of their security-assurance programme.

The appropriate frequency depends on the sensitivity of the systems, the rate of change and the organisation’s contractual or regulatory obligations.

The test should lead to measurable improvement

The purpose of a penetration test is not simply to produce a report. It is to give your organisation evidence about how its defences behave when someone actively attempts to bypass them.

A professional engagement should leave you with:

• A clear understanding of the weaknesses found
• Practical remediation priorities
• Access to the tester for clarification
• Verification that completed fixes work
• Evidence you can provide to interested parties
• A better understanding of where future security investment is needed

If the engagement ends with an unexplained PDF and no support for what happens next, much of its potential value has been lost.

Plainsight Security provides external infrastructure, internal infrastructure and web application penetration testing for organisations across the UK. Every engagement includes clear reporting, a post-test walkthrough and remediation retesting.

If you need an independent assessment of your systems or application, contact us to arrange a no-obligation scoping call.