A security test can find a weakness in one system while missing a risk elsewhere in the business. For organisations with several offices, cloud platforms and support providers, security penetration testing needs a clear scope that reflects how those systems connect.
A well-planned engagement can show where an attacker might gain access and what to fix first. It offers scoped assurance, not a guarantee that every system is secure. Start by agreeing what will be tested, who can authorise it and how the results will guide remediation.
Key takeaways
- A penetration test assesses agreed systems under agreed conditions, at a particular point in time.
- Scope should name the assets, locations, exclusions, dates and test methods.
- Written permission and rules of engagement help prevent disruption and misunderstandings.
- Findings need clear severity ratings, owners and follow-up actions.
- Multi-country environments need coordinated contacts, access and escalation routes.
What security penetration testing can prove
The National Cyber Security Centre (NCSC) describes penetration testing as a way to identify technical risks arising from software and hardware vulnerabilities. The test can show how weaknesses might be exploited within its agreed boundaries.
However, a report only describes the systems and conditions assessed during the engagement. New software, configuration changes, staff accounts or threats can alter the risk afterwards. Testing should therefore inform a wider security programme, not replace vulnerability management or ongoing monitoring.
A penetration test is not a vulnerability scan
A vulnerability scan checks systems for known weaknesses. A penetration test goes further by attempting to validate whether selected weaknesses can be exploited and what access they could provide.
The activities can complement each other, but they answer different questions. A scan may identify outdated software across a large estate; a focused test can assess whether weaknesses in a particular application expose sensitive functions or data.
Set expectations before work starts
The NCSC outlines five stages: initial engagement, scoping, testing, reporting and follow-up. Treating these as parts of one process makes it easier to turn findings into decisions.
The result is not a pass or fail for the whole organisation. It is evidence about a defined set of assets, tested by agreed methods, during a specific period.
Scope the engagement around your real environment
Scope determines what the testers can examine and what they must leave untouched. The NCSC recommends involving business risk owners, technical staff who know the target and a representative of the testing team.
Record the purpose of the test, target assets, exclusions, timeframe, test types, expected effort and reporting needs. For a distributed organisation, that means checking that the proposed scope reflects the systems staff actually use across locations.
Map assets, owners and dependencies
List domains, applications, APIs, networks, cloud environments and relevant IP ranges. Name the business or team responsible for each asset, including systems managed by suppliers.
A company buying global IT services may have central identity systems, regional networks and locally managed applications. If the scope covers only the head office, it may miss a route into shared systems through a regional office or third-party connection.
Agree access and exclusions
Tell the testers whether they will receive user accounts, technical documentation or other access. State any limits, such as systems that must not be tested or actions that could affect live services.
For APIs, provide the correct endpoints and documentation where available. Tools such as Swagger and Postman can help teams describe or inspect API functionality, but access to documentation does not grant permission to test an endpoint.
Choose test types that match the risks
There is no single test that suits every organisation. Select activities according to the systems in scope, the business concern and the assurance required.
Test applications, networks and APIs
Application testing can examine authentication, access controls and how the software handles data. External network testing focuses on systems reachable from the internet, while internal testing assesses selected assets from within a network.
API testing is useful where applications exchange data or support customer and staff functions. Define endpoints, user roles, data handling limits and any rate restrictions before testing begins.
Assess cloud and configuration risks
Cloud testing needs a precise list of permitted assets and techniques. For example, an AWS configuration review may assess how services are set up, while an application test may examine a system hosted in AWS. These are different activities and need separate scope decisions.
Also distinguish penetration testing from configuration reviews and vulnerability scans. They can support the same security objective, but each has a different purpose and should be described clearly in the statement of work.
Coordinate testing across countries and offices
A group with multinational IT support may use central systems alongside local providers, separate network segments and different support hours. Map these arrangements before testing so the right teams can approve access and respond to alerts.
Businesses relying on worldwide IT support or multi-country IT support should identify local contacts for each in-scope environment. A central security team can coordinate the engagement, while local staff confirm operational windows and report unexpected effects.
Account for local operations and time zones
Agree when active testing can take place and who will be available if a service behaves unexpectedly. This matters when a test could affect a customer-facing service, a warehouse system or a local office outside UK working hours.
An international IT support partner may manage part of the environment, but ownership and permission still need to be clear. Document which organisation controls each asset and who can approve testing on its behalf.
Include suppliers and support providers
IT support for multinational companies often involves several providers with different responsibilities. Tell relevant teams about the agreed test window, escalation route and boundaries, without sharing details more widely than needed.
The same planning applies to IT support for international businesses. When remote IT support teams manage systems in different regions, confirm how they will identify test activity and contact the engagement lead if a service is affected.
Get written authorisation and rules of engagement
Before active testing begins, obtain written permission for every in-scope asset. The agreement should set out target systems, testing dates, permitted techniques, restrictions, stop conditions and escalation contacts.
This is particularly important where a company uses external hosting, cloud services or supplier-managed platforms. Confirm permissions for those assets in advance rather than assuming that access to an account also authorises testing.
A practical plan should say what happens if testers find a serious weakness or trigger an unexpected effect. It should identify who can pause the work, how the team will communicate and how the business will handle urgent findings. Do not begin until the relevant parties understand and approve the rules.
Turn findings into remediation work
A useful report explains what the testers examined, what they found and what the business should do next. The NCSC recommends assigning a severity rating to each issue. Commonly, a rating is considered alongside business impact, exploitability and the affected system’s importance.
Make the report actionable
Ask for enough detail to help technical teams reproduce and understand each finding. The report should identify affected assets, evidence, likely consequences and recommended corrective action, while avoiding unnecessary exposure of sensitive information.
Agree who receives the report and how confidential findings will be handled. A concise executive summary can help decision-makers prioritise investment, while technical detail supports remediation teams.
Track fixes and arrange follow-up
Assign an owner and target date to each agreed action. Prioritise weaknesses according to risk, business impact and the availability of a suitable fix. Do not assume that every finding can be corrected in the same timeframe.
Follow-up testing can check whether selected weaknesses have been addressed. Agree its scope and timing with the provider; there is no universal retest interval that suits every organisation. Continue vulnerability management and monitoring between tests, because the original report cannot account for later changes.
When CHECK applies
The NCSC CHECK scheme is intended for central government, public-sector bodies and UK critical national infrastructure. It is not a universal requirement for every business commissioning a penetration test.
For CHECK engagements, team leaders need at least the UK Cyber Security Council’s Principal Cyber Security Professional (Security Testing) title. Team members need at least the Practitioner title. Both roles require valid SC clearance.
Businesses outside that scope should still assess a provider’s relevant experience, methods, reporting quality and ability to work within the required boundaries. Ask who will perform the test, how the work will be supervised and what deliverables the engagement includes.
Connect testing with wider security controls
Penetration testing is one part of a business security programme. An IT security audit can review broader controls and processes, while vulnerability management helps teams track known weaknesses over time. Monitoring can help identify suspicious activity between scheduled tests.
Zero Through provides IT Security Audit services and Managed SIEM Services for organisations looking to strengthen related controls. Businesses that need broader support can Get IT Support or explore ways to Protect Your Business.
Further blog topics for international security teams
- Securing identity access across regional offices
- Cybersecurity risks in third-party support arrangements
- API security checks for customer-facing platforms
- Cloud configuration risks in multi-region environments
- Building an incident escalation plan for overseas teams
- Protecting privileged accounts across subsidiaries
- Security considerations when opening a new office
- Managing vulnerability fixes across different business units
- Preparing a supplier for a security assessment
- Separating test and live environments safely
- Security monitoring for distributed workforces
- Assessing access controls in business-critical applications
- Planning cyber incident communications across time zones
- Securing remote access to corporate systems
- Data handling rules for penetration testing engagements
- Cybersecurity checks before acquiring another business
- Protecting manufacturing systems connected to corporate IT
- Security risks in retail payment environments
- Cybersecurity planning for law firms with multiple offices
- Access reviews for healthcare technology providers
- Security controls for education organisations with several sites
- How charities can prioritise limited security resources
- Reviewing cloud supplier responsibilities before testing
- Linking security findings to business risk decisions
Frequently asked questions
How often should a business run a penetration test?
There is no single schedule for every organisation. Set a cadence based on risk, system changes, regulatory or contractual needs and the sensitivity of the affected services. Consider testing again after significant changes to an in-scope system.
Does a penetration test guarantee that systems are secure?
No. It provides evidence about agreed assets and test conditions at the time of the engagement. It cannot prove that a system has no weaknesses or account for changes made after testing.
Can a provider test every country or office remotely?
That depends on the assets, permissions, network design and agreed methods. Remote testing may suit some systems, while others need local coordination or specific access. Confirm coverage and exclusions in the scope.
Should we choose a CHECK provider?
CHECK is intended for central government, public-sector bodies and UK critical national infrastructure. Other organisations can assess providers against their own needs, including relevant experience, clear rules of engagement and useful reporting.
Make the test useful beyond the report
The value of a penetration test depends on the decisions made before and after testing. Define the scope carefully, secure written authorisation and give findings clear owners so remediation does not stop at the report.
For a practical review of your organisation’s risks and priorities, Book a Security Review with Zero Through. A well-scoped assessment can help your teams focus effort where it matters, across the systems and locations they rely on.
[…] Security Penetration Testing for Multi-Site Risks […]
Comments are closed.