A compromised account in one office can give an attacker a route into systems elsewhere. Cyber security penetration testing helps you find out whether that route works before someone exploits it.
For a business spread across countries, the challenge is deciding what to test, who can authorise it and how to fix what the testers find. A useful engagement starts with those decisions, rather than a list of tools.
Key takeaways
- A penetration test checks whether an authorised tester can exploit weaknesses within an agreed scope. A vulnerability assessment looks more broadly for weaknesses that need investigation.
- Test scope should reflect real routes between offices, cloud services, suppliers and customer-facing applications.
- The report matters only if someone owns each finding, fixes it and verifies the result.
What cyber security penetration testing does
The UK National Cyber Security Centre (NCSC) describes penetration testing as an attempt to breach an IT system’s security using techniques and tools similar to an attacker’s. The tester has permission and works within agreed boundaries.
That permission matters. A test might examine whether a stolen employee account could reach sensitive files, or whether an exposed web application allows access to customer data. The aim is to show what an attacker could achieve, not merely to produce a catalogue of possible flaws.
A test gives a view of the systems, access and controls included at that time. It cannot prove that an entire organisation is secure. New deployments, changed permissions and newly discovered vulnerabilities can alter the picture soon afterwards.
Penetration testing versus vulnerability assessment
Finding weaknesses across the estate
A vulnerability assessment identifies potential problems, often using automated scanning alongside configuration and asset reviews. It can cover a broad range of servers and applications regularly. For a company with many locations, that breadth is useful for tracking missing patches and exposed services.
The NCSC says penetration testing supports vulnerability assessment and management. It should not replace them: a limited test is unlikely to find every vulnerability.
Checking whether an attack succeeds
A penetration tester investigates selected weaknesses to establish whether they can be exploited within the agreed rules. They may show that a poorly protected application account can access records beyond its intended permissions, then document the route and its limits.
This provides evidence for prioritising fixes. A scanner finding deserves attention, but a demonstrated route to sensitive data gives the business a clearer basis for deciding what to address first.
Choose the right test for the risk
Decide how much the tester knows
In a black box test, the tester begins with little information, much like an external attacker. A grey box test supplies limited access or knowledge, such as a standard user account. A white box test provides fuller information, potentially including architecture details or source code.
The choice affects time and coverage. For example, grey-box access can help a tester examine what an ordinary employee could reach across connected offices. White-box access can help investigate application controls more thoroughly. Agree the approach against the question you need answered, rather than treating one model as universally stronger.
Name the systems and attack paths
An external network test, internal network test and web application test answer different questions. APIs, mobile apps and cloud environments may also need their own scope. For cloud services, confirm which resources you control and what the provider permits you to test.
For multi-country IT support teams, identity systems and remote access deserve attention because they connect locations. Include relevant supplier connections and the boundaries between subsidiaries where those routes matter. An office omitted from the scope will not appear in the findings.
How a penetration test engagement works
The NCSC describes five broad stages: initial engagement, scoping, testing, reporting and follow-up. Each stage needs a decision from the organisation commissioning the work.
Agree authority, boundaries and timing
During scoping, identify the legal owner of each system and obtain written authorisation. Record the applications, IP ranges, accounts and locations in scope. Also identify exclusions, test windows, emergency contacts and actions that require separate approval.
This is particularly important when international IT services support different subsidiaries. A UK headquarters may use a system owned by another group company or hosted under a supplier contract. Technical access alone does not establish permission to test it.
Agree how testers will handle sensitive data, how they will report a serious finding during the engagement and when they must stop. A clear escalation route prevents a critical exposure sitting in a draft report for weeks.
Test, report and follow up
The testing work depends on scope. A tester may examine exposed services, application access controls and permitted routes between systems. Recognised references include the OWASP Web Security Testing Guide for web applications and the Penetration Testing Execution Standard (PTES). Ask the provider to explain its method in terms of your systems.
A useful report identifies affected assets, evidence, business impact and practical remediation. It should distinguish a demonstrated exploit from a suspected issue. The follow-up then confirms who will make each change and how the team will verify it.
Understand the compliance requirements that apply
PCI DSS sets defined testing obligations
For organisations within scope, PCI DSS v4.0.1 Requirement 11.4 covers penetration testing. Requirements 11.4.2 and 11.4.3 call for internal and external tests at least every 12 months and after significant changes. The testing must come from a qualified, organisationally independent resource, which may be internal or external.
Scope matters as much as frequency. PCI guidance covers the Cardholder Data Environment perimeter and critical systems. Where segmentation reduces PCI scope, the relevant segmentation controls also need testing. Service providers have a six-month segmentation testing requirement under 11.4.6, as well as testing after changes to those controls or methods.
A PCI test that misses an in-scope connection between offices cannot validate that connection merely because the annual test took place.
Requirement 11.4.4 calls for exploitable weaknesses to be corrected and retested. Keep evidence of both activities for your compliance process.
Other obligations need their own review
Avoid copying the PCI timetable into every security programme. UK GDPR calls for security appropriate to risk, rather than prescribing an annual penetration test. If your business also handles US healthcare information, assess HIPAA requirements with the people responsible for that environment rather than assuming a PCI-style cadence applies.
In each case, a test supports a wider programme of assessment, monitoring and remediation.
Scope tests across countries without losing ownership
Map shared services and local exceptions
A multinational business may run central identity and cloud platforms while local offices manage networks or specialist software. Start with an asset and ownership map. Mark which routes cross company boundaries, which systems hold sensitive data and who can approve a test in each location.
This makes global IT support more effective during the engagement. Local IT support services can confirm maintenance windows, while the central security team keeps the scope and findings consistent. Remote IT support providers and other third parties should be involved when their access forms part of the route under test.
Plan around operational limits
Time zones, local contacts and production systems affect testing. An exercise that is safe overnight in London may fall in another office’s busiest hours. Agree incident contacts who can act while testers are working, including who can pause an activity.
For businesses buying worldwide IT support or global IT services, one reporting format helps compare findings across locations. It should still name the owner and affected system precisely. A group-wide risk rating is of little use if nobody knows which local team can change the configuration.
Select a provider and set useful deliverables
Ask prospective providers what they will test, what they will exclude and how they will validate findings. Request a sample report with sensitive details removed. It should show a clear route from evidence to recommended action, without requiring your engineers to guess what happened.
Check experience with the systems in scope, tester independence where required, data handling and retest terms. Compare quotes against the same written scope; a shorter, cheaper exercise may cover fewer applications or offer no verification after fixes.
For UK public-sector buyers, the NCSC directs central government departments and associated agencies to use CHECK companies for relevant systems processing OFFICIAL information and above, excluding STRAP systems. Other buyers should assess whether CHECK is appropriate to their circumstances; it is not a blanket requirement for every UK business.
Cyber security penetration testing is easier to commission when the buyer can state the decisions the report must support. Ask whether findings will identify affected locations, evidence, severity, ownership and a proposed way to confirm the fix.
Turn findings into verified fixes
Assign each finding to someone who can change the affected system. Record the asset, agreed action, target date and any temporary control. Where one weakness appears in several offices, separate the shared cause from the local work needed to resolve it.
Then ask the tester to retest the relevant issue. A closed ticket shows that work was completed; a retest checks whether the original attack route still works. If a full retest is impractical, document what was checked and what uncertainty remains.
Testing also feeds routine vulnerability management. A repeated configuration error may call for a change to build standards, rather than another one-off fix. For organisations providing IT support for multinational companies, that distinction can prevent the same finding returning at the next location.
24 questions for a multi-country security programme
After the initial test, these focused topics can help teams investigate risks that a single engagement may leave open:
- How should subsidiaries approve tests of shared systems?
- Who owns an identity weakness affecting several countries?
- When should an acquisition trigger a security test?
- How can local teams verify group-wide remediation?
- Which supplier connections cross a tested network boundary?
- How should testers handle customer data found during testing?
- What changes require a fresh PCI penetration test?
- Can segmentation still limit access after a merger?
- Which cloud accounts have access across subsidiaries?
- How do API permissions differ between regional deployments?
- What does a stolen remote-worker account expose?
- Which offices depend on the same administrator credentials?
- How should maintenance windows span multiple time zones?
- Who can stop a test outside UK working hours?
- What evidence proves a critical fix was retested?
- When should application releases prompt targeted testing?
- Which findings belong in the central risk register?
- How should incident teams receive urgent test findings?
- Are local exceptions weakening a shared security standard?
- What access remains after a supplier contract ends?
- How can vulnerability management track repeat findings?
- Which production systems need stricter testing limits?
- Does managed monitoring detect the tested attack route?
- What should directors see in a penetration test summary?
These questions are most useful when tied to named systems and owners. For international IT support teams, they also expose gaps between a central policy and what happens in each office.
Frequently asked questions
How often should a business arrange a test?
Set a schedule based on risk, system changes and applicable requirements. PCI DSS has defined annual and change-triggered obligations for relevant in-scope testing. Elsewhere, a major application release, acquisition or change to remote access may justify a targeted test before the next planned exercise.
Can automated testing replace a human tester?
Automated assessment helps find and track potential weaknesses at scale. A human-led penetration test examines selected attack routes and explains what the result means for the business. Use the two together, then verify the fixes.
What should happen after the report arrives?
Prioritise demonstrated attack paths, assign owners and agree deadlines. Record accepted risks rather than leaving findings open without a decision. Retest important fixes and carry recurring issues into the organisation’s ongoing security work.
Make the test count
The risk in a multi-site business often lies in the connections between systems and teams. A well-scoped test examines those routes, then gives each finding a clear owner and a way to verify the fix.
Remediation is the measure that lasts after the testers leave. If your scope or ownership is unclear, book a security review with Zero Through before commissioning the next test.
