How to Run Vulnerability Testing: A 4-Step Practical Guide for Security Teams

Vulnerability testing is a programme that combines continuous automated scanning with periodic targeted validation, using human‑led penetration tests to prove exploitability and business impact. Vulnerability testing is a key part of that picture.

At CyPro, we run continuous scans and schedule targeted penetration tests after major changes, following National Cyber Security Centre (NCSC) guidance. ENISA’s 2025 threat environment analysed several thousand incidents to show how exploited vulnerabilities lead to follow‑on activities and Verizon’s DBIR reports a marked rise in vulnerability exploitation in recent years, which makes proving exploitability through testing more important in the UK and beyond.

• Key: Run vulnerability testing as continuous automated scanning plus targeted penetration tests to prove exploitability and business impact.
• When to test: After major changes, following incidents and on a regular schedule aligned to NCSC guidance.
• Pre-reqs: Obtain formal scope approvals, an accurate asset inventory and Legal or Data Protection Officer sign-off if personal data is involved.
• Cost and time: Treat continuous scanning as an operational cost and plan scoped penetration tests with time and resources matched to the agreed scope.

🧭 What is a vulnerability assessment and how does it differ from vulnerability testing?

A vulnerability assessment inventories and ranks known weaknesses across your estate, while vulnerability testing (sometimes called penetration testing) actively verifies whether those weaknesses can be exploited in practice. An assessment is broad and continuous; testing is targeted and proof-driven.

Where scanning, testing and attack surface reviews sit

Vulnerability scanning uses automated tools to detect known Common Vulnerabilities and Exposures (CVE), missing patches and configuration issues, producing a triage list you can act on. Penetration testing uses human-led techniques and scripted exploits to demonstrate real impact, for example gaining privileged access or extracting data. Attack surface assessment maps externally visible assets, cloud services and third-party integrations so you know what to scan and test next. Run automated scans frequently, perform targeted vulnerability testing after major changes and trigger attack surface reviews when your cloud or supplier footprint changes.

Standards, guidance and evidence to use

The National Cyber Security Centre (NCSC) publishes practical guidance on safe penetration testing and scope, follow the NCSC guidance when you plan tests NCSC. The European Union Agency for Cybersecurity (ENISA) analysed thousands of incidents and shows how exploited vulnerabilities often lead to malware deployment and data loss; use ENISA’s prioritisation advice when you plan testing ENISA threat environment 2025. Verizon’s Data Breach Investigations Report records a sharp rise in vulnerability exploitation, useful for the business case for regular testing Verizon DBIR.

Use the right tool for the job: Run frequent automated vulnerability scanning to keep an accurate asset and findings inventory, schedule targeted penetration and vulnerability testing annually or after major changes and perform attack surface assessments whenever your cloud or supplier footprint changes. Combining all three maps neatly to NIST, MITRE ATT&CK and ISO 27001 requirements and gives evidence you can present to auditors and boards.

🧰 What you need before you start vulnerability testing

Before you run vulnerability testing, gather approvals, inventory and tools so tests are safe, legal and repeatable. At CyPro, we require a signed scope, a named technical contact who can pause tests and an up to date asset list mapped to owners and environments.

Essential items

• Scope and approvals: Written sign-off from the CISO, IT owner and Legal or Data Protection Officer where Personal Data is involved.
• Asset inventory: Authoritative list of IPs, hosts, applications, cloud tenants and OT where relevant, with owners and business criticality.
• Tools and modes: Automated credentialed scanners for broad coverage, authenticated web app scans for apps and a manual testing plan for high risk assets.
• Windows and rollback: Scheduled test windows, a rollback plan and a technical contact reachable 24/7 during tests.
• Record keeping: Approvals log, test ticket in your IT service system and defined success criteria for each test.

National guidance on vulnerability management and penetration testing is available from the National Cyber Security Centre. See the NCSC guidance for scheduling and safe testing practices National Cyber Security Centre (NCSC). Use the National Vulnerability Database for CVE lookups and severity context National Institute of Standards and Technology (NIST) NVD.

Test type	Primary purpose	Frequency	Best for
Automated vulnerability scanning	Find known CVEs and misconfigurations	Continuous or weekly	Large fleets, baseline coverage
Penetration testing	Exploit chains and business impact	Annually or after major change	High risk apps, regulatory proof
Attack surface assessment	Discovery of internet-exposed assets	Quarterly or on demand	Cloud estates, mergers and acquisitions

After these prerequisites you should be able to run safe, repeatable vulnerability testing with clear owners, minimal disruption and a defined path to remediation. If you need help setting scope or choosing tools, see our Vulnerability Scanning service Vulnerability Scanning and our Penetration Testing service Penetration Testing.

📝 Step 1: Define scope, objectives and success criteria

Decide which assets are in scope, which test types are permitted, set measurable success criteria and remediation Service Level Agreements (SLAs) and obtain written authorisation before any vulnerability testing starts.

What to include in the scope

List every asset and environment you will test, including IP ranges, cloud accounts, web applications, APIs, operational technology segments and third‑party hosts. Tie each asset to a named owner, a business impact rating and a contact for test windows. Explicitly state excluded systems such as production payment nodes, research environments or systems subject to UK GDPR data export restrictions and note any regulatory constraints under UK GDPR, NIS2 or PCI DSS that affect testing schedules and data handling.

How to set objectives and success criteria

Define specific, measurable outcomes: For example, reduce exploitable high‑severity findings by 75% within 30 days of report delivery, validate fixes with a re‑scan within 10 business days and keep the median age of essential CVE fixes below 14 days. Use a clear severity mapping based on Common Vulnerability Scoring System (CVSS) or NIST guidance and describe what counts as acceptable residual risk. Use published incident analysis to prioritise tests: Verizon’s 2025 Data Breach Investigations Report highlights rising exploitation of vulnerabilities and third‑party involvement, which should steer your objectives.

Sign‑off, test authorisation and scheduling

Produce a single signed scope document that includes the test plan, business impact assessment, legal approvals, emergency rollback contacts and an agreed escalation path. Schedule tests in defined windows and list maintenance blackout periods, backup owners and forensic preservation steps. Expect three outputs: A signed scope document, formal test authorisation and a calendar of test windows so vulnerability testing runs safely, repeatably and with clear accountability. For practical guidance on attack trends that should influence scope and retest frequency, see Mandiant’s M-Trends report.

🧰 Step 2: Choose tests and tools (scanning, authenticated checks, manual testing)

Select test types by objective: Unauthenticated scanning for internet‑visible issues, authenticated scanning to find missing patches and misconfigurations, credentialed checks for privilege escalation paths and manual testing for business‑logic and chained exploits.

Map test types to objectives

Unauthenticated scans, run from outside your network, answer whether an external attacker can see and exploit exposed services. Authenticated scans, with service or domain credentials, reveal missing patches, insecure services and weak RBAC. Manual testing, led by an experienced tester, finds chained flaws and business‑logic issues automated scanners miss. For regulatory evidence in the UK, combine authenticated checks with a manual verification step to satisfy NCSC guidance and provide forensic trails for the Information Commissioner’s Office (ICO) where data exposure is possible. See ENISA threat environment 2025 for trends showing why mixed approaches matter.

Select specific tools and suppliers

Choose one commercial scanner plus one open tool for validation. Commercial tools handle scale and reporting, open tools let you validate findings cheaply. Recommended choices: Nessus or Qualys for broad coverage, plus OpenVAS or Nuclei for focused checks. For manual testing, shortlist suppliers that use MITRE ATT&CK when mapping exploit chains. If you lack in‑house capability, consider our Cyber Resilience service for ongoing validation or our Cyber Essentials Plus service if you need certification‑grade testing.

Procurement and licensing checklist

Request trial licences, API access for automation and a service‑level definition that includes false positive verification. Allocate at least one admin account with documented scope and a test calendar. Expect procurement and setup to take 2 to 7 days for a typical mid‑market environment.

Use vulnerability testing with a mix of automated authenticated scans and focused manual checks to reduce both noisy false positives and missed chained exploits.

🔎 Step 3: Run scans, validate results and eliminate false positives

Run automated discovery and authenticated scans, then manually validate every high and medium finding to remove false positives, map chained exploits and produce reproducible steps and proof of concept where authorised.

Automated discovery and authenticated scans

Configure authenticated scans against the signed scope with at least two tools: One commercial scanner and one open source. Use agent or credentialed SSH/WinRM access for internal hosts and API keys for cloud services. Run a discovery pass first to confirm inventories, then run authenticated vulnerability scans during the agreed test window.

How to do it: Schedule scans in your scanner (example: Export asset list, import to the scanner, assign credentials to asset groups). For cloud workloads, enable API access and limit scans to non-production tags where possible. Expected outcome: An asset-to-finding matrix showing confirmed credentials, missing assets and initial severity labels.

Common pitfall: Scanning unmanaged assets or production peaks. Fix: Run a discovery sweep, compare against CMDB entries and exclude blackout windows from the scope.

Manual validation and authorised exploitation

Prioritise the scanner output by severity, business impact and exploitability, then validate each finding manually. For web issues, attempt a safe proof of concept. For host findings, confirm vulnerable software versions and check whether mitigating compensating controls (WAF, IPS, app sanitisation) stop exploitation.

How to do it: Triage top 20% of findings first, map each to a CVE and MITRE ATT&CK technique and document reproduction steps with screenshots or logs. Expected outcome: A triaged list with verified true positives, false positives removed and exploitation notes for remediators.

Common pitfall: Treating scanner output as gospel, which causes wasted effort on false positives. Fix: Use authenticated scans, manual checks and attack chaining to find true business risk.

Deliverables, triage and next steps

Produce a final deliverable that contains reproducible steps, impact statements, CVE references and remediation recommendations assigned to owners. Include a short risk rating, a suggested patch or configuration change and a rollback plan for each high-risk fix. After remediation, schedule a re-scan to confirm fixes.

In our experience, combining regular automated scans with focused manual validation reduces noisy alerts and surfaces the chained exploits attackers use in the wild. For managed scanning and continuous validation, consider our Cyber Essentials Plus service and our Cyber Resilience engagements for remediation planning.

Public guidance and threat context: ENISA threat environment 2025 shows how vulnerability exploitation often leads to follow-on malware activity and Verizon’s 2025 DBIR highlights rising exploitation rates that make validation and remediation urgent.

🛠 Step 4: Triage, prioritise and fix vulnerabilities

Triage must assign risk scores, owners and deadlines immediately, using exploitability, business impact and exposure to internet-facing assets to prioritise fixes. Create remediation tickets, set Recovery Time Objectives (RTO) and Retest schedules before work starts.

How to score and prioritise

Use CVSS as a baseline, then adjust for exploit availability, internet exposure and business impact. For example, raise a CVSS 6.5 on a public web server with an active exploit to the top of the queue. Record adjusted score, scoring rationale and target RTO in each ticket. Link the vulnerability to the affected asset and business function so leaders can see potential downtime.

Create remediation tickets and assign owners

Open a ticket per distinct remediation action in your IT ticketing system. Include steps to reproduce, CVE references, required change window and rollback plan. Assign a named owner and a single technical contact. Set the RTO and, where relevant, Recovery Point Objective (RPO). Mark tickets as blocked if you require a vendor patch or maintenance slot.

Implement fixes, retest and change control

Apply fixes in a test environment first, run the same authenticated scans and manual checks used in the initial assessment, then schedule a production change with a documented backout plan. After production change, run a re-scan and manual validation to confirm the fix. If remediation risks production stability, consider compensating controls such as network segmentation or WAF rules until a safe patch window is available.

For evidence on why speed matters, see Verizon’s 2025 Data Breach Investigations Report and the prevalence of vulnerability exploitation in ENISA’s threat environment 2025.

📊 How to measure success and common pitfalls to avoid

Measure success with mean time to remediate (MTTR), exposure days, percentage of high‑risk findings fixed and SLA compliance; common pitfalls are poor scope definition, unmanaged false positives, missing ownership and scanning cadence that is too infrequent.

Key metrics to track

Track MTTR, exposure days, percent high-risk fixed and SLA compliance as your primary success metrics. MTTR should fall each quarter and exposure days should trend down week on week. Use a ticketing system to capture owner, priority and target RTO.

How to measure each metric

Measure MTTR by averaging the time from ticket creation to verified fix across all confirmed vulnerabilities. Measure exposure days by summing days each confirmed publicly exploitable vulnerability remained unpatched. Measure percent high-risk fixed as closed high or essential tickets divided by total high or essential confirmed issues in the reporting period. Measure SLA compliance as the percentage of tickets remediated within agreed RTOs.

Common pitfalls and fixes

Pitfall: Poor scope. Fix: Define asset inventory and include internet-facing, cloud, OT and important third-party assets. Pitfall: Unmanaged false positives. Fix: Validate findings with manual checks and CVE cross-references before ticketing. Pitfall: No ownership. Fix: Assign an owner and RTO for every confirmed finding. Pitfall: Scanning cadence too infrequent. Fix: Scan weekly for internet-facing assets and monthly for internal networks, or after major changes.

Practical reporting and governance

Report these metrics to technical owners and the board using the same definitions each month. Use ENISA threat environment 2025 and the 2025 Verizon DBIR to justify cadence and resourcing. At CyPro, we map findings into tickets and required RTOs so remediation can be tracked reliably. Link remediation tasks back to your cyber resilience plan and, if you need help operationalising this, see our Cyber Resilience service page.

❓ Frequently asked questions