Penetration testing after change. Reading time: 4 mins
Your last penetration test assessed a particular environment. Since then, your business may have launched a customer portal, moved an application to the cloud or given a supplier access to support a critical service.
Those changes deserve a fresh look at testing coverage. For IT and security leaders, a useful question is whether the assumptions behind the previous test still match the way the business operates.
The National Cyber Security Centre’s penetration testing guidance explains that testing provides assurance within the assessed scope at the time of the test. That makes the change history a valuable starting point when planning the next assessment.
Start with the changes people depend on
Bring together the previous scope, the current system inventory and the changes made since testing. Ask application owners to help explain what has changed in practice.
A release described as a small feature update might introduce document uploads, a new user role or a connection to another service. A supplier change might create a different route for remote administration. A migration might alter who can manage a cloud environment.
Record the change, its business purpose and the owner. Then ask what new access or data flows it creates. This gives the scoping conversation something concrete to work with and helps identify areas that need closer investigation.
Connect the scope to business consequences
An asset list tells a tester where systems are. Business context helps explain why they matter.
For a financial services business, that conversation might focus on access to customer records or a portal used to submit sensitive information. A legal or accountancy practice might prioritise client document exchange. A manufacturer might want to examine the access supporting order processing, with careful separation from production equipment.
In pharmaceuticals, research information and the availability of supporting systems may shape the discussion. For a technology business, the boundaries between customer accounts could be especially relevant.
These are starting questions for a scoping meeting. The organisation’s actual services and dependencies should determine which scenarios deserve attention.
Write down the questions the test should answer
A useful test objective is specific enough to guide the work and support a decision afterwards.
For example, could a standard customer account access another customer’s information? Could an authorised supplier account reach systems beyond its intended remit? Does a new application integration expose information that the business expects to remain restricted?
Agree which identities, applications and environments are needed to examine those questions. Make exclusions explicit, including any connected systems that cannot be assessed. Record why an exclusion matters and who will decide how to address the remaining uncertainty.
This approach helps avoid carrying forward an old scope simply because it is familiar.
Agree the conditions for testing
Good preparation also covers how testing will happen. CREST’s Guide to Penetration Testing recommends a formal scope agreed by the relevant parties, covering the target environment, authorisation and follow up.
Before work begins, agree permitted activities, timing and the people who can make decisions if an issue arises. Include any supplier permissions and restrictions that affect the assessment. Discuss sensitive systems with their owners and agree how unexpected effects will be handled.
Make sure the testing team understands operational constraints. A busy trading period, a production schedule or an important client deadline may influence the safest approach. Capture those decisions in the engagement plan so that expectations are clear.
Make the findings useful to the people fixing them
Plan the response to findings while planning the test. Decide who will receive urgent issues, who can authorise changes and how remediation will enter the existing work queue.
Ask for enough detail to connect a finding with the affected service and its business impact. Give each agreed action an owner and a target date. Where a fix changes the environment again, consider what evidence will show that it has worked.
Testing works best alongside routine vulnerability management. Use the findings to improve the processes that keep systems secure between assessments.
Bring your change list to Vambrace
Bring the previous scope, the change and one business action it affects. For example, a portal that now lets suppliers upload documents needs a test of that new role and its access. A retest of an earlier finding repeats the original failing action against the corrected version.
If you are preparing a release, reviewing supplier access or checking whether your existing scope still fits, start with a scoping conversation. Bring your previous report and a short summary of what has changed, without sending sensitive technical details through a public enquiry form.
Request a penetration testing scoping conversation with Vambrace
Together, we can discuss the systems you want to assess, the questions you need answered and the next steps for defining an appropriate engagement.