Vulnerability Scanning
Every month we scan your web apps, APIs, mobile apps, networks and cloud, a practitioner checks every finding, and you see what’s new, what’s fixed and what’s still open. Part of every penetration test we run, and available on its own.
Book a ConsultationBetween penetration tests, things change
A penetration test tells you how things stood on the days it ran. After that, new vulnerabilities are published in software you already run, configurations drift, a forgotten test server goes live, and a dependency picks up a known flaw. Known vulnerabilities do get used: CISA keeps a catalog of the ones exploited in the wild, and strongly recommends that every organisation prioritise fixing them.
Scanning finds these, but raw scanner output is a poor guide. It includes findings that aren’t real, scores every issue as if your environment didn’t matter, and repeats one root cause across many hosts. FIRST, which maintains CVSS, says a base score measures a vulnerability’s severity and should not be used alone to assess risk.
So a practitioner reviews every finding before you see it: false positives removed, severity adjusted to your context, and a fix your team can act on. Each month’s results are compared with the last, so you see what is new, what you fixed and what is still open — the first month sets the baseline. Monthly is deliberate: PCI DSS sets internal scans at least once every three months as its minimum, and NCSC guidance suggests aiming to scan infrastructure at least once a month.
Web to cloud, in one monthly report
Web applications
Dynamic scanning of your running web applications — signed in, where you give us test accounts — for injection, cross-site scripting, misconfiguration, outdated components and weak transport security. Findings are mapped to OWASP Top 10:2025 categories, so your developers know where each one belongs.
APIs
Your APIs, scanned from the definitions you share, such as an OpenAPI file, for injection, missing authentication, exposed endpoints and misconfiguration, mapped to the OWASP API Security Top 10 2023. Whether one user can reach another user’s data usually takes a tester with more than one account, and the report says when that is the case.
Mobile apps
The current builds of your Android and iOS apps, scanned for insecure data storage, weak cryptography, unsafe network settings and risky use of the platform, together with the APIs they call, where those are yours and in scope. Findings cite stable OWASP MASWE weakness IDs, so they mean the same thing to your developers and your testers.
Networks (external and internal)
Your internet-facing addresses, and your internal network from a point we agree with you: open services, known-vulnerable versions, and DNS, TLS and HTTP header weaknesses. Hosts are scanned with credentials over SSH where they accept them, including Windows hosts running OpenSSH, so we see the software actually installed, not just what a service announces.
Cloud environments
Configuration review of your cloud accounts through a read-only role you create and name in your written authorisation, plus your public cloud endpoints — both kept to the services each provider’s published testing rules let customers test, unless you have the provider’s agreement for more. Those rules say little about configuration review as such, and where they leave a service out, the report says so. Findings point to the setting to change, not just the rule that failed.
A monthly cycle, not a one-off scan
Scope & authorisation
We agree the assets, scan windows, rate limits and contacts, and get written authorisation from the owner of every asset before the first scan.
The first month
Month one is the baseline: a full scan of everything in scope, with every result reviewed. Month two is compared with it, and each month after with the one before.
Monthly scans
The same scope, scanned the same way each month inside the agreed windows, so a change in the results reflects a change in your estate, not in our settings.
Practitioner review
A practitioner reviews every finding: false positives removed, severity adjusted to your context with the original base score kept alongside, and a fix written for your team.
Monthly report
Each month is compared with the last: what is new, what was fixed and what is still open, with the highest-priority items first.
Retest on request
Fixed an urgent finding we flagged? We rescan it to confirm the fix. Other mid-month retests are available on request; otherwise the next monthly scan confirms it.
The starting point of a test, not a substitute for one
Every Product Penetration Testing engagement begins with a scan of what is in scope — passive-only, or limited to what the engagement’s safety rules allow, on live industrial and other safety-critical systems — and the tester checks every result before it reaches the report. The scan clears away the known issues — missing patches, outdated components, weak TLS, exposed services — so the tester’s time goes on what a scanner can’t find.
Plainly, a scanner can’t find business-logic flaws: an order total changed in transit, an approval step skipped, another customer’s record reached by changing a number in a request. Nor can it find chained attacks, where several findings that look minor on their own add up to a breach. Those take a person who understands how your product is meant to work. PCI SSC’s ASV Resource Guide (2024, guidance) draws the same line — a scan identifies weaknesses but does not exploit them — and NCSC guidance (2021) says automated scanning cannot match penetration testing for breadth and depth of coverage.
Authorised, agreed and safe to run
- Written authorisation only — we scan an asset only with written authorisation from whoever owns it, and only the addresses, applications and accounts named in scope
- Agreed windows and rate limits — scans run at the times you set and the request rates we agree, from source addresses we give you in advance, and you can pause them at any time
- No denial-of-service testing — checks that could knock a service over or flood it with traffic are switched off
- Cloud provider policies respected — AWS, Microsoft and Google publish rules for testing on their platforms; we work within them, and if a provider’s terms don’t allow a scan, we tell you instead of running it. SaaS tenants such as Salesforce, Atlassian or Microsoft 365 are outside our standard scope, because their providers’ testing terms differ
- Third-party assets only with their owner’s permission — a site an agency hosts for you, or a CDN or managed host in front of your site, isn’t yours alone to authorise; we scan it only where its owner allows it
- Credentials handled securely — authenticated scans use dedicated accounts that you create and can disable at any time, with only the access the scan needs; we keep them encrypted and use them for nothing else
What the rules expect, and where our service stops
A few rules set a scanning frequency; most leave it to your own risk assessment. Here is what the main ones say, and which of them a monthly service can support. Current as of October 2026.
| Instrument | Status | What it means for scanning |
|---|---|---|
| PCI DSS v4.0.1 Req. 11.3.1, 11.3.1.2, 11.3.1.3, 11.3.2.1 | Binding by contract — an industry standard, not law. v4.0.1 published Jun 2024; authenticated internal scanning in force since 31 Mar 2025 | Internal scans at least once every three months and after any significant change, by qualified people with organisational independence — not necessarily a QSA or ASV. Periodic internal scans are authenticated wherever systems accept credentials. The requirement text lets a non-ASV run external scans after a significant change, though PCI SSC’s SAQ A guidance describes both SAQ A external-scan requirements as ASV scans — if you complete SAQ A, ask your acquirer or assessor. A monthly cycle runs more often than the quarterly minimum; a scan after a significant change is separate, agreed in advance and run when you tell us about the change. Whether your assessor accepts our reports for these requirements is their decision. |
| PCI DSS v4.0.1 Req. 11.3.2 — ASV scans | Binding by contract; PCI SSC FAQ 1604 (guidance, Jun 2026) | Quarterly external scans by a PCI SSC Approved Scanning Vendor, using that vendor’s approved scan solution. verrou is not an ASV. Our scans do not replace ASV scans, and we never issue anything resembling an ASV attestation. Nor is dynamic scanning the automated technical solution that Req. 6.4.2 describes, deployed in front of public-facing web applications to detect and prevent web-based attacks. |
| DORA Art 25(1) RTS (EU) 2024/1774 Art 10 and Art 34 | Binding · DORA has applied since 17 Jan 2025; RTS in force since 15 Jul 2024 | Resilience testing programmes provide for tests such as vulnerability assessments and scans. Under the full framework, scan frequency and scope follow each ICT asset’s classification and risk profile, and financial entities scan ICT assets supporting critical or important functions at least weekly — a monthly cycle alone does not meet that for those assets, so tell us at scoping if DORA applies to you. Procedures also record detected vulnerabilities and monitor and verify their remediation; our new, fixed and still open record is evidence your team can use for that, for the assets we scan. Entities under the simplified framework (Art 34) scan according to classification and risk, with no fixed frequency. |
| NIS2 Implementing Reg (EU) 2024/2690 Annex 6.10.2 and 6.5.2 | Binding · in force since 7 Nov 2024, for the entity types it lists | For in-scope DNS service providers, TLD name registries, cloud computing, data centre, content delivery network, managed and managed security service providers, trust service providers, and providers of online marketplaces, online search engines and social networking services platforms: vulnerability scans where appropriate, at planned intervals, with evidence of the results recorded; vulnerabilities critical to operations addressed without undue delay; and test results documented with the criticality of, and mitigating actions for, each finding. Other NIS2 entities should check their national law. |
| NCSC (UK) — Vulnerability scanning tools and services; Vulnerability management | Guidance · Jan 2021; Feb 2024, reviewed May 2026 | NCSC suggests aiming to scan infrastructure at least once a month, or immediately after applying changes that remediate a critical issue, and running application scanners whenever an application changes — a monthly cycle alone does not do that, so tell us about releases if you want change-triggered scans. It also notes that automated scanning cannot match penetration testing for breadth and depth. Its vulnerability management guidance asks you to verify that a vulnerability fixed by reconfiguration or mitigation is no longer present. |
| NCSC Cyber Assessment Framework 4.0, Principle B4 | Guidance (assessment framework) · Aug 2025 | Lists regular vulnerability assessments, such as penetration tests and vulnerability scans, among the ways to prevent exploitation of known vulnerabilities. At “Achieved”, B4.d has you verify your understanding of your vulnerabilities with third-party testing. |
| Cyber Essentials v3.3 and Cyber Essentials Plus (UK) | Voluntary certification scheme, though under PPN 014 UK central government and NHS bodies require it, or equivalent controls, of suppliers on certain contracts · v3.3 effective 27 Apr 2026; Plus test specification v3.2, Apr 2025 | Cyber Essentials has no scanning requirement, but expects updates to be installed within 14 days of release where they fix vulnerabilities that the vendor rates critical or high risk or that have a CVSS v3 base score of 7 or above, or where the vendor gives no details of the level of vulnerabilities fixed. A monthly scan shows what is still missing; it cannot show that each update landed within 14 days. In Cyber Essentials Plus the certification assessor runs the vulnerability scans: our service is not a Cyber Essentials Plus assessment. |
| NIST SP 800-53 Rev. 5 RA-5 and RA-5(6) | Guidance for private-sector organisations; mandatory for US federal systems · Sept 2020; current Release 5.2.0, Aug 2025 (RA-5 unchanged) | Scan at a frequency you define, analyse the scan reports, and remediate legitimate vulnerabilities within response times you set, based on risk. The optional RA-5(6) enhancement compares the results of multiple scans — the month-on-month comparison in our report. |
| CISA Known Exploited Vulnerabilities catalog BOD 26-04 (US) | Binding on US federal civilian agencies only (BOD 26-04, 10 Jun 2026); guidance for everyone else | CISA strongly recommends that all organisations monitor the KEV catalog and prioritise remediating what is on it. BOD 26-04 replaced BOD 22-01 and binds federal civilian agencies, and contractors only where their contract says so. Findings we match to the KEV list are flagged in our report. |
| FIRST CVSS v4.0 and EPSS | Voluntary · CVSS v4.0 industry standard, Nov 2023; EPSS, a data-driven model, v5 since Jun 2026 | A CVSS base score measures severity and should not be used alone to assess risk; EPSS estimates the probability of exploitation in the wild in the next 30 days; FIRST advises against multiplying the two. We show severity, likelihood and KEV status side by side where a finding has a CVE, keep the base score next to the severity we assign for your environment, and note the EPSS model version each month, because a new model shifts the scores. |
| OWASP Top 10:2025, API Security Top 10 2023, MASVS v2.1.0, MASWE v1.0.0 | Guidance (awareness documents and voluntary standards) · Top 10:2025, final Dec 2025 per the OWASP repository; API Security Top 10 2023, Jun 2023; MASVS v2.1.0, Jan 2024; MASWE v1.0.0, Aug 2026 | We map web and API findings to these categories and cite mobile findings by MASWE weakness ID. A mapping is not a claim of coverage: the Top 10 is an awareness document, and no scanner tests every category — insecure design and business logic need a person. |
| ISO/IEC 27001:2022, Annex A 8.8 | Voluntary certifiable standard · 2022 | Annex A control 8.8 covers the management of technical vulnerabilities. Our monthly reports are test evidence your certification auditor can review; the audit and the certificate are theirs. |
What you get
- Monthly report — what is new, fixed and still open since last month, with a short summary for leadership and engineer-ready detail for the people fixing things
- Urgent findings, sent at once — a known-exploited vulnerability on an internet-facing system or an exposed secret goes to your named contact the day we confirm it, not with the next report; if a scan shows signs of an existing compromise, we stop that scan and call your named contact the same day
- Validated findings with fixes — every finding checked by a practitioner, with the severity for your environment beside the CVSS base score, EPSS likelihood and KEV status where the finding has a CVE, and a concrete fix
- Trend over time — how your open findings move month to month from the baseline, so progress, or drift, is visible
- Retest of fixes — a rescan of each urgent finding once you have fixed it; other retests available between cycles on request, so a fix can be confirmed when it lands, not a month later
- Coverage statement — what was scanned each month, what wasn’t and why
Know what changed since last month.
Scanning starts with an agreed scope and written authorisation from whoever owns each asset. The first conversation is free.
Get in Touch