Cyber security testing helps UK organisations find weaknesses, check whether controls work and verify fixes. A security lead should own the work, with service owners and testers involved from the start. Allow time to agree scope, run checks safely and retest fixes; the duration depends on the systems involved. The task matters: 43 per cent of UK businesses and 28 per cent of charities identified a breach or attack in the previous 12 months, according to a UK government survey.
- Outcome: Produce a scoped record of tested controls, prioritised findings, owners and evidence that fixes have been verified.
- Owner: A security lead coordinates the work; service owners approve access, operational safeguards and decisions about risk.
- Steps: Set objectives and scope, establish a baseline, run authorised tests, review findings and retest the fixes.
- Framework: Use the UK General Data Protection Regulation and any applicable Cyber Essentials or sector requirements to shape the plan.
- Common mistake: Treating a penetration test as the whole programme instead of maintaining vulnerability discovery and remediation between tests.
📋 Plan cyber security testing around decisions
Start cyber security testing by deciding which risk decision the results must support. That choice determines the systems, methods and people involved. A UK organisation might need to check exposed services, validate a recent change or assess whether controls protect personal data. Write the question down before choosing a tool or booking a tester.
The National Cyber Security Centre (NCSC) distinguishes ongoing vulnerability management from penetration testing. A penetration test attempts to breach systems using techniques comparable to an adversary’s, but it gives assurance only over what was tested at that point in time. It is not the main way to discover every vulnerability. Automated scanners can run hundreds or thousands of checks faster than manual testing, according to NCSC scanning guidance.
- Name the decision: what would a pass, a failure or an uncertain result change for the organisation?
- Identify a security lead, each service owner and the person who accepts residual risk. Agree who can pause testing.
- List the business services, data and technical components relevant to the decision. Mark gaps in ownership or inventory for follow-up.
- Select methods that answer the question, such as configuration review, vulnerability scanning, control checks or a scoped penetration test.
Under the UK General Data Protection Regulation (UK GDPR), Article 32(1)(d) calls for a process to regularly test and evaluate security measures where appropriate. That requirement supports a risk-based plan, not a universal testing interval or an automatic need for a penetration test. Use a cyber risk assessment to decide what deserves attention first, then record why other assets fall outside this round of testing. See UK GDPR Article 32.
Key Takeaway
Choose the risk decision before the testing method. A test that cannot inform a decision is hard to scope or act on.
🧩 Scope cyber security testing and get permission
Define the test boundary and obtain written permission before anyone probes a system. Scope protects live services, makes results meaningful and prevents testers from reaching assets the organisation does not control. Record the included assets, exclusions, permitted techniques, testing contacts and a way to stop immediately if operations are affected.
Ask service owners to confirm dependencies, including suppliers, shared infrastructure and environments that resemble production. An internet-facing application may connect to payment services or customer records that require separate approval. Where a supplier owns an asset, obtain the relevant permission rather than assuming your contract covers testing. For Cyber Essentials Plus, the organisation and assessor must agree the scope boundary before testing starts, according to the NCSC test specification.
- Create an asset list with owners, environments, addresses and interfaces. Check it against service records, not just scanner output.
- Agree written rules covering accounts, test data, access hours, techniques, evidence handling and the named person who can halt activity.
- Set operational safeguards with service owners. Decide how to handle a performance change, unexpected access or a suspected live incident.
- Approve a change and communications plan where needed. Tell monitoring and support teams what authorised activity could look like.
Cyber Essentials and Cyber Essentials Plus can provide useful scope prompts, but their boundaries should not hide connected services that matter to the business. New Cyber Essentials applications follow requirements version 3.3, effective from 27 April 2026, according to the NCSC requirements page. Our Cyber Essentials Plus requirements guide helps teams prepare for that assessment. Keep the agreed boundary with the test record so nobody mistakes a narrow pass for organisation-wide assurance.
✅ Establish a baseline and choose the right tests
Check what is already known before running new tests. A current asset list, patch records, configuration standards and earlier findings give testers a baseline. Without one, a scan can generate duplicate work while an apparently clean result conceals an untested system. Match each method to a specific uncertainty rather than buying every test available.
The NCSC describes vulnerability scanning as an automated way to detect weaknesses associated with patching, hardening and software development. Scans can run on a schedule, on demand or after a new build or server deployment. Use them to support continuing discovery, then investigate findings before deciding what to fix. A penetration test adds a different question: can someone exploit weaknesses within the agreed boundary? See NCSC scanning guidance.
- Compare the asset list with what administrators and service owners can confirm. Investigate unknown or unmanaged systems before treating coverage as settled.
- Review previous findings and open fixes. Identify changes since the last assessment, including new services, access routes and suppliers.
- Choose automated checks for broad, repeatable coverage and manual testing where the risk depends on context or chains of weaknesses.
- Map each selected test to an owner and a decision. Record what the method cannot establish, especially where access is restricted.
UK Government Security recommends multiple methods rather than reliance on one process, with vulnerability discovery continuing through design, development and deployment. Senior owners should understand which tests run and use the results in risk decisions. An existing cyber security assessment can help organise the wider control review around the technical results. Keep the baseline and method choices with the plan; both explain why the work was appropriate. See UK Government Security guidance.
Key Takeaway
Use repeatable checks for breadth and scoped manual testing for questions those checks cannot answer.
⚙️ Run the tests safely and record what happened
Run only the agreed tests, monitor the service and record deviations as they happen. Authorised testing can still affect availability or expose sensitive data. Begin with lower-risk checks, confirm that monitoring works and stop when activity falls outside the approved boundary. The service owner, not the tester alone, should decide whether a live system can tolerate further probing.
Production testing is possible when the scope, safeguards and approvals match the risk. Consider a non-production environment for disruptive techniques, but check whether it represents the live configuration closely enough to answer the question. The Bank of England describes CBEST as targeted testing in live corporate environments for key financial institutions. That programme does not mean every organisation needs the same approach. See the Bank of England CBEST thematic.
- Confirm the approved scope, contacts and stop conditions immediately before starting. Check that service monitoring and incident contacts are available.
- Run the agreed automated checks and validate results. Record which assets responded, which did not and any access limitations.
- Carry out authorised manual tests where they answer the plan’s questions. Avoid collecting more personal or sensitive data than needed.
- Log actions, observations and interruptions. Pause for service degradation, unexpected access or an asset outside scope, then seek direction.
A specialist adds value when a test requires careful manual validation, independent challenge or experience with a complex production service. Our penetration testing service can support that work within an agreed scope. For Cyber Essentials Plus, an independent assessor checks compliance with the scheme’s technical requirements; the specified checks are not interchangeable with an open-ended penetration test. See the NCSC test specification.
📌 Review findings and turn them into decisions
Validate each finding, assign an owner and decide what happens next. A raw scanner export is not a useful testing report. Decision-makers need to know which service is affected, how the weakness was demonstrated, what limits the conclusion and what action would reduce risk. Separate confirmed issues from possible issues that need more investigation.
Prioritise findings using exposure, plausible harm, affected data and the controls already in place. Agree remediation with service owners so a technical fix does not break the service it protects. Where a fix cannot proceed, document the reason, compensating measures, decision owner and review point. The Information Commissioner’s Office (ICO) expects organisations to test whether security measures work and make needed improvements. See the ICO data security guide.
- Ask testers to show reproducible evidence for each confirmed finding, using the minimum sensitive data needed to support it.
- Record the affected asset, scope limitation, likely consequence, recommended action and person responsible for the decision.
- Agree which fixes proceed, which need further investigation and which risks require formal acceptance. Set review dates internally.
- Give senior owners a concise account of coverage, unresolved risks and decisions needed. Keep technical detail available to implementers.
The Financial Conduct Authority (FCA) expects in-scope firms to test whether important business services can remain within their impact tolerances. Its 31 March 2025 mapping and testing deadline has passed, so a current report should support continuing decisions rather than present old compliance activity as finished work. See FCA operational resilience guidance. For teams preparing an independent scheme assessment, our Cyber Essentials Plus service addresses a different, defined set of checks.
🔑 Retest fixes and keep a cyber security testing record
Retest a reported weakness after the fix is applied and keep evidence of the result. A closed ticket shows that somebody changed something; it does not show that the weakness is gone. Repeat the relevant check against the affected system, confirm the service still works and record any remaining limitation or risk.
Build the next round of cyber security testing around changes and exposure, not just a calendar reminder. New deployments, changed access, major configuration work and unresolved findings can justify another check. UK Government Security calls for vulnerability discovery throughout the service life cycle. The NCSC also cautions that penetration testing gives assurance only for tested components at the time of the engagement. See UK Government Security guidance and NCSC penetration testing guidance.
- Confirm the fix is present on the affected asset, then repeat the original check under authorised conditions.
- Test for an unintended service effect and review whether related assets share the same weakness.
- Mark the finding verified, still open or unable to verify. Record the reason rather than treating silence as a pass.
- Set the next review trigger and give owners a record they can use when systems or risks change.
| Step | What good looks like | Evidence to keep |
|---|---|---|
| Plan | A named decision, owner and selected methods | Objectives and approved test plan |
| Scope | Assets, exclusions and stop conditions agreed | Written permission and boundary |
| Baseline | Known assets and open findings checked | Inventory and prior findings |
| Test | Approved checks run with service monitoring | Test log and validated observations |
| Decide | Findings assigned and risk decisions recorded | Report, owners and action record |
| Retest | Fixes verified and remaining gaps visible | Retest results and review triggers |
Keep the plan, permission, test record, report and retest evidence together so the next reviewer can see both coverage and gaps. The NCSC Cyber Assessment Framework (CAF) can help some organisations structure broader assurance; version 4.0 was released on 4 August 2025, according to the NCSC framework changelog. A framework informs the review, but it does not replace evidence that a specific fix worked.
❓ Frequently asked questions
How long does cyber security testing take?
Cyber security testing takes as long as the approved scope, access, validation and retesting require. A narrow control check and a penetration test of several connected services are different pieces of work. Ask the owner to allow time for permissions, service safeguards and review of findings, not just the time a tester spends running checks.
Who should own cyber security testing?
A security lead should coordinate cyber security testing, but service owners must approve what happens to their systems. Testers perform the agreed checks, operations staff watch for service effects and a named decision-maker accepts or escalates remaining risk. Keep these roles explicit even when one person holds several of them.
What tools are needed for cyber security testing?
The tools depend on the question. An asset inventory, approved scanning tool, configuration records, monitoring and a secure way to store findings often support the work. Manual testing may need specialist tools, but permission and a sound test plan matter more than a long tool list. Use methods the team can run and interpret safely.
How often should a UK business carry out cyber security testing?
Set a risk-based schedule and add tests when systems or exposure change. UK GDPR Article 32(1)(d) calls for regular effectiveness testing where appropriate but does not prescribe a universal interval; see UK GDPR Article 32. Review the schedule after new deployments, material changes and unresolved findings rather than relying on an annual appointment alone.
What should we do if a test fails or disrupts a service?
Stop the affected activity, contact the agreed service owner and follow the operational or incident procedure. Preserve the test log and describe what happened before changing scope or resuming. If a control fails without disruption, validate the finding, assign an owner and agree a fix or documented risk decision. Retest before marking it resolved.
What is the difference between a vulnerability scan and a penetration test?
A vulnerability scan automates checks for known weaknesses across assets in scope. A penetration test uses authorised techniques to assess whether security can be breached within an agreed boundary. The NCSC treats a penetration test as assurance over vulnerability management, not a replacement for continuing discovery; see NCSC penetration testing guidance.
Does Cyber Essentials Plus include penetration testing?
Cyber Essentials Plus involves independent tests against the scheme’s technical requirements, but it is not the same as a general penetration test. Its specification covers defined control checks, including vulnerability and patching assessments. Choose a separate, scoped penetration test if the decision you need to make falls outside those checks; see the NCSC test specification.
Contact Us
