Information checked: 23 October 2026. Website security testing should answer a defined question within an authorised scope. This guide compares scans, reviews and penetration tests; none provides a permanent guarantee that a website cannot be compromised.
After a major security alert, it is natural to ask whether somebody can “test the website and confirm it is safe”. The difficulty is that different tests answer different questions. A public scanner, a review of hosting evidence and an authorised penetration test can each be useful, but they do not inspect the same things or support the same conclusions.
PHP2Shell makes those distinctions practical. Our PHP2Shell overview explains the incident background. This article helps a business choose the right kind of assessment, prepare a useful scope and turn the findings into completed work rather than collecting a reassuring badge.
Begin with the question you need answered
Write the question in plain language. You may need to know whether the active PHP package contains a vendor fix, whether the enquiry journey still works after maintenance, whether suspicious activity warrants investigation, or whether a complex application has exploitable weaknesses. Those are distinct questions requiring different evidence.
For patch status, the host’s package and deployment evidence may be more directly relevant than a generic external scan. For broken checkout, functional testing is the immediate tool. For suspected historical compromise, evidence review and incident-response expertise may be needed. Avoid buying a broad service before the problem has been defined.
Identify the decision the answer will support. Will it determine whether a change can be released, whether a supplier task can close, or which remediation to prioritise? A test that produces a long report without helping a decision may be poorly scoped even if its technical work is competent.
What an automated vulnerability scan can contribute
An automated scan can examine defined targets for patterns or conditions its checks recognise. Depending on the tool and access, it may review publicly exposed services, known software issues or configuration indicators. It can help identify areas that deserve attention and support a repeatable monitoring process.
Ask what the scanner actually inspected. Was it limited to public pages? Did it use authorised credentials? Were all relevant subdomains included? Did a firewall block its requests? Were failed checks reported separately from passed checks? A result is only meaningful when the coverage and limitations are understood.
Version detection needs particular care. A tool may see an abbreviated software label while the host uses a vendor-maintained package with backported fixes. The correct response is to reconcile the finding with supplier evidence, not automatically dismiss the alert or assume that the scanner’s label is definitive.
Why a clean scan is a limited finding
A scanner can report that it did not detect the issues covered by its checks under the conditions of that run. That is narrower than proving that no weaknesses exist. It may not understand bespoke workflows, business logic, restricted areas or every interaction between components. The report should describe those limits clearly.
Similarly, a detection may require validation. Some findings reflect incomplete information, a configuration that differs from the tool’s assumption or a condition that needs contextual assessment. Ask for a process to review findings and retain the evidence behind decisions. “False positive” should be an explained conclusion, not a convenient label for work nobody wants to do.
Use scans as part of ongoing vulnerability management. Record the date, scope, tool coverage and follow-up owner. A clean result from months ago does not establish today’s status after software, configuration or application changes. The value comes from a maintained process, not a one-time green indicator.
What a technical review can establish
A technical review can examine evidence that an external scanner cannot see. The reviewer may assess hosting-package records, configuration, application dependencies, access arrangements or maintenance processes within an agreed scope. That can help explain why a scan result appears inconsistent with the provider’s patch statement.
Define the expected output. For example, a PHP patch review could identify the application, active runtime, vendor advisory, installed fixed package and activation evidence. An access review could identify account ownership and unnecessary permissions. Neither should be presented as a full penetration test unless that work was actually commissioned and performed.
Reviews also have limits. The quality of available records, the reviewer’s access and the time allowed affect what can be established. Ask the report to identify unverified assumptions and missing evidence. A careful review can be very useful without claiming to have tested every possible attack path.
What an authorised penetration test adds
A penetration test uses skilled assessment to explore whether weaknesses can be exploited within a defined engagement. The NCSC’s penetration-testing guidance places it within wider vulnerability management, emphasises experienced testers and explains the importance of scope, reporting and follow-up. It is a way to gain assurance about selected systems at a particular time.
That does not make it a substitute for routine patching or ordinary maintenance. Known urgent issues should not be left exposed simply because a test is booked for a future date. The test should support the organisation’s security process and reveal gaps in that process, with findings assigned for action.
Choose a provider whose skills match the environment and the question. A complex custom application, an online shop and a simple brochure site may require different expertise and effort. This article does not claim that Healy Web Design provides accredited penetration-testing services; specialist requirements should be scoped with an appropriately qualified provider.
Authorisation and scope must be explicit
Identify the domains, applications, environments and accounts included in the engagement. Confirm that the person commissioning the work has authority over them. A business website may depend on shared hosting, external booking platforms or payment services that cannot simply be added to a test without the relevant permission.
Agree what techniques are allowed, what is excluded, when testing will occur and how the team will stop if unexpected harm appears. Include a reachable technical contact and a business decision maker. Testing can have operational effects, so a vague instruction to “try anything” is not an adequate engagement plan.
Document boundaries involving customer data and live transactions. The plan should state how evidence will be collected, protected and shared, and how test accounts or records will be handled afterwards. These arrangements help the team produce useful findings without unnecessary disruption or exposure of information.
Choose access that fits the objective
Some assessments use only information available to an external visitor. Others provide architecture details, source material or authorised test accounts. More information can help a tester spend time on deeper questions rather than rediscovering basic facts. Less information may suit a particular external-perspective scenario, but can also limit coverage.
Ask the provider to explain the trade-off in terms of the decision you need to make. An authenticated customer workflow cannot be fully assessed by a test that never signs in. Conversely, a narrow public-exposure review may not require administrative access. The chosen method should be deliberate and documented.
Do not grant broad access merely because a provider asks for it in a generic checklist. Confirm the purpose, duration and approved recipient through the normal authorisation process. Arrange appropriate temporary test accounts and access removal as part of the engagement, with the system owner involved.
Distinguish production and staging evidence
Staging can reduce certain operational risks and allow controlled test data, but its configuration may differ from production. Firewalls, integrations, permissions, deployment settings and data can all affect results. A report should identify which environment was tested and what differences limit the conclusion.
Production testing may reveal real deployment conditions, but requires careful coordination with the host and business. A busy shop or booking system has different availability concerns from an internal demonstration site. Agree an approach that reflects those consequences rather than treating environment selection as a routine checkbox.
Where both environments are involved, describe the role of each. For example, application behaviour might be explored in staging while a narrower review confirms production configuration. The resulting evidence should remain linked to the environment it actually covers.
Include business logic where it matters
Some important weaknesses concern how a business process is assembled rather than a single outdated component. Permissions, account boundaries, discount rules, workflow transitions and integrations may need skilled contextual review. An automated tool may not know what the business intended to permit.
Give the assessor a clear description of expected roles and outcomes. Which users may see which records? Who may approve a change? What should happen when a booking or order changes state? These expectations help the tester distinguish intended behaviour from a flaw without relying on guesswork.
Keep the scope risk-based. Focus effort on functions with meaningful consequences, such as access to private information or control over transactions. A long checklist of superficial page checks can consume time while the most important workflow remains poorly understood.
Read findings as an action plan
A useful finding identifies the affected target, evidence, likely impact, relevant conditions and a recommended remedy. Severity helps prioritisation, but the business also needs context: what service is involved, what information or operations are at risk and what dependencies affect the fix?
Assign a named remediation owner and a target date. Some findings belong to the host, others to the developer or an external supplier. If the report is merely forwarded to everyone without ownership, important work can remain unresolved while each person assumes another team is handling it.
Retain the reasoning behind accepted limitations or alternative remedies. If the suggested fix cannot be applied immediately, obtain appropriate technical advice and record the temporary approach, its scope and its review date. Do not quietly mark an issue complete because it is inconvenient or falls outside the current contract.
Retest the change that was actually made
After remediation, ask what evidence is needed to confirm the finding has been addressed. A retest should relate to the original issue and the implemented remedy. A developer saying “changed” and a host saying “updated” are useful progress notes, but neither automatically establishes the relevant outcome.
Also check for functional regressions where the remedy affects customer journeys. Security validation and ordinary application testing complement each other. A fix that closes a weakness while breaking enquiries or account access still needs operational attention, with a recovery approach that does not simply restore known exposure.
Keep the retest result with the original report. Record any partial resolution, remaining limitation and further action. This makes the history useful to a future maintainer and prevents a resolved finding from being confused with a new or recurring problem.
Apply the distinctions to PHP2Shell
For this incident, start by obtaining service-specific evidence that the relevant host remediation is active. A public version check alone may not establish vendor-package status. Ask separately whether the exposure history or suspicious observations call for compromise assessment. Functional testing then checks that the application continues to do what customers need.
Also include the additional PHP notice dated 23 October in the host and developer’s current assessment. Do not describe completion of the original fixes as proof that every subsequent issue has been assessed. The information check date in this article is deliberately separate from its scheduled publication date.
A penetration test may be appropriate for wider assurance, but it should be commissioned for a defined purpose rather than used as a ritual response to every headline. The priority is to answer the actual risk question with the right evidence and complete the resulting work.
Build a repeatable review cycle
Maintain an inventory, a route for vendor notices, a patch process and a record of unresolved findings. Decide which changes trigger renewed review: a new payment journey, significant custom development, a hosting migration or a major access-model change may alter the assessment needed.
Review results with the people who can act on them. The business owner needs an understandable account of impact and decisions; the technical owner needs sufficient detail to implement and verify fixes. A report that serves only one audience can leave either the decision or the work stalled.
If you are reviewing how your website is built and supported, our web design services provide a starting point for that discussion. Agree specialist testing separately where needed. No maintenance package, scan or assessment should be described as making a website hack-proof.
Frequently asked questions
Is a vulnerability scan the same as a penetration test?
No. A scan applies defined checks, while a penetration test involves skilled assessment within an authorised scope. Their coverage and outputs differ. Ask what question each service is intended to answer before comparing prices or results.
Can a clean result guarantee future security?
No. Results apply to the tested scope and conditions at a particular time. Software and configuration can change, and tests have limitations. Use findings within an ongoing maintenance and vulnerability-management process.
Can I test a third-party booking platform through my website?
Do not assume your website ownership authorises testing of another supplier’s systems. Define the boundary and obtain the relevant permission through the engagement process before including external services.
Should urgent patching wait for a penetration test?
Not as a general strategy. Ask the responsible technical team to address known urgent exposure under current vendor advice. A later assessment can support assurance and wider improvement without replacing immediate remediation.
What should happen after a high-priority finding?
Assign an owner, assess the actual business context, agree a remedy and verify its implementation. Record temporary measures and outstanding limitations. A report is only useful when its findings lead to accountable action.
What is the difference between retesting and a full new assessment?
A retest checks the relevant remediation against a previous finding. A broader assessment may examine additional scope or changed conditions. Ask the provider to state exactly what its follow-up covers so the conclusion is not overstated.
