05
Security testing finds and proves the weaknesses in your systems. Vulnerability scanning checks everything you expose for known issues. A penetration test goes deeper: an engineer attacks agreed targets, under written rules, to show what an attacker could reach.
Example findings from a scheduled scan
You want to know whether you are an easy target, what to fix first and when it is really fixed, in plain language, without a report nobody reads.
Sound familiar?
You need testing that stands up to an auditor: continuous discovery and signed-in scans for breadth, manual tests to the OWASP WSTG and PTES for depth, findings ranked by exploitability, and re-tests that close them in your tracker.
Sound familiar?
What you can hold the work to, in plain terms.
Domains, subdomains, IP ranges, certificates and cloud accounts discovered and kept current, including the ones nobody remembered.
A penetration test shows which weaknesses chain into real access and what that access exposes, with the evidence to back it.
CVSS v4.0 for severity, EPSS for likelihood, the CISA KEV catalogue for what is exploited today, and your context for what matters most.
Every finding has an owner, a fix and a due date, then a re-test that proves it closed, in a history an auditor can follow.
Testing is a cycle, not a report. Discovery feeds the scans, a penetration test goes deeper where the risk is highest, and every fix is re-tested before it counts as closed.
Six stages repeat on a schedule: discover domains, subdomains, IP ranges, cloud accounts and certificates; test, with scans of exposed services, TLS, headers, known CVEs and configuration, and a penetration test where one is scoped; triage by removing false positives and scoring with CVSS, EPSS and the CISA Known Exploited Vulnerabilities catalogue; report in a findings register and a one-page summary; fix, with an owner and a due date for every finding; re-test, closing with evidence or reopening. Priority combines likelihood and impact: fix first what is exploited in the wild, internet-facing and high impact; schedule what is real but harder to reach; accept or harden the rest with a recorded reason and review date.
The disciplines inside this service, and the detail we work to in each.
01
Everything you have online, found from the outside and kept current: the starting point for every scan and every test.
02
Rate-limited scans on a schedule, from the internet and, where agreed, from inside your network. An engineer reviews every result.
03
External and internal tests of the networks and servers in scope, by an engineer who follows each weakness as far as the rules allow.
04
Manual penetration tests of the web apps and APIs you expose, signed in at every role, to the OWASP Web Security Testing Guide.
05
AWS and Azure accounts checked against the CIS Benchmarks and, in a penetration test, attacked within each provider's published testing rules.
06
The part that turns tool output and test notes into closed risk: every finding confirmed by an engineer and written for the person who has to fix it.
Each answers a different question at a different depth. NIST SP 800-115 draws the same line: finding a weakness is one step, proving it can be exploited is another.
| Type | Question it answers | How it works | Exploitation | How often |
|---|---|---|---|---|
| Vulnerability scanning | Question it answersWhich known weaknesses are exposed right now? | How it worksAutomated checks across everything in scope, each result reviewed by an engineer. | ExploitationNone: a finding is reported, not proven. | How oftenOn a schedule, and after significant changes. |
| Vulnerability assessment | Question it answersHow exposed are we, and what do we fix first? | How it worksSigned-in scans and a configuration review, cloud accounts included, with findings confirmed by hand. | ExploitationNone beyond confirming a finding is real. | How oftenPeriodically, and after structural changes. |
| Penetration test | Question it answersCould someone chain these weaknesses into a breach, and how far would they get? | How it worksManual testing by an engineer on an agreed scope, with and without credentials. | ExploitationYes, far enough to prove impact, within written rules. | How oftenAt least yearly, after significant changes and before a major launch. |
| Red team exercise | Question it answersWould we detect and stop a determined attacker? | How it worksObjective-led, across people, process and technology, with few staff told in advance. | ExploitationYes, towards an agreed objective, as quietly as possible. | How oftenOnce scanning and testing find little that is new. |
We run the first three and will tell you which one you need. Red team exercises are not part of this service.
Every stage ends with a document you keep and a gate you can check.
Targets, test type, timing and rules of engagement agreed in writing, and signed by someone with authority over every system.
Exit gate: Written authorisation for every target, and the provider's testing rules checked for anything hosted.
You receiveSigned scope, rules of engagement and schedule
Scheduled scans, then manual testing where a penetration test is scoped, inside the agreed windows and with a named contact on each side.
Exit gate: Every result reviewed by an engineer, false positives removed, and test accounts and files cleaned up.
You receiveTriaged results, with critical findings reported as soon as confirmed
Findings ranked by real risk, each with evidence and a recommended fix, then walked through with your team.
Exit gate: Every finding has an owner, a fix and a due date.
You receiveReport, findings register and a one-page summary
Fixed findings tested again the same way they were found, and closed with evidence.
Exit gate: Fixed findings verified; anything still open is reopened with a reason.
You receiveClosure evidence
Written down before work starts, so nothing is assumed.
The public frameworks we measure the work against, and the platforms we run it on.
A fixed, small first engagement, then the model that fits the rest.
A first engagement
One full scanning cycle on your public footprint: what is online, what is exposed, what to fix first, and whether a penetration test is worth doing yet.
Fixed price
Defined projects: a website, an assessment, a migration stage
One price for that scope
Time and materials
Ongoing improvement, support and discovery work
Billed for the time used
A vulnerability scan finds known weaknesses; a penetration test proves what they lead to. Scanning is automated, broad and repeatable, and reports what might be exploitable across everything in scope. A penetration test is manual and narrower: an engineer exploits weaknesses, chains them together and shows how far an attacker could get. Most organisations need scanning continuously and a penetration test periodically.
Penetration testing is an authorised attack on your systems, run by an engineer under written rules, to find out which weaknesses can really be exploited and what they would expose. It follows a set method, from scoping and discovery through attack to reporting, and ends with a re-test of what you fixed. It is also called a pen test or pentest.
Scan at least every three months and after any significant change, and run a penetration test at least once a year and after significant change. Those are the PCI DSS minimums, and a sensible floor for any business. Systems that change every week deserve scans as often, and a new application or API should be tested before it launches.
It depends on the scope, so we quote a fixed price once the scope is agreed. The price follows what is in scope: applications and their user roles, API endpoints, IP addresses and cloud accounts, and whether testing is external, internal or both. Recurring scanning is quoted for an agreed set of targets and a schedule.
It should not, and the rules of engagement are written so that it does not. Scans are rate-limited, no denial-of-service test is ever run, and exploitation stops once impact is proven, without deleting or changing your data. Fragile systems are tested in an agreed quiet window or on a staging copy, and a named contact on either side can halt testing at any time.
Written authorisation from someone who owns the systems, a list of targets, a named contact during testing and the access each test needs. Applications and APIs need a test account at each user role, internal networks need a VPN account or a test host, and cloud reviews need a read-only role. All test access is removed at the end.
Usually grey box: the tester gets test accounts and some documentation, so the time goes on finding weaknesses rather than guessing how the system works. Black box, with no inside knowledge, shows only what an anonymous outsider can reach. White box adds source code or architecture diagrams and goes deepest. The choice is written into the scope.
A one-page summary for leadership, then the detail your engineers need. It states the scope, dates and method, then lists each finding with the affected asset, a CVSS v4.0 score, evidence, steps to reproduce, the business impact and a recommended fix. A penetration test report also tells the attack story: how findings chained together. Every finding in it has been confirmed by an engineer.
It supplies evidence for those requests, but it does not make you compliant on its own: your assessor or auditor decides what is enough. Scan records, test reports and re-test results show that weaknesses are found, ranked, fixed and checked on a schedule, which is what these audits ask about. For PCI DSS, the quarterly external scans in requirement 11.3.2 must come from an Approved Scanning Vendor, which we are not; penetration tests under 11.4 can be run by a qualified, independent third party.
Yes. Each fixed finding is tested again the same way it was found, then closed with evidence or reopened with a reason. PCI DSS asks for the same after a penetration test: exploitable findings are corrected, and the testing is repeated to verify the corrections.
Yes, but that test is not independent, and we say so before it is scoped. PCI DSS requires organisational independence of the tester for penetration tests, and other auditors may apply the same logic. Our tests are useful for your own assurance; where an auditor must accept the test as independent, systems we built or run should be tested by another firm.
Findings are treated as sensitive, because they are a map of how to attack you. They go only to the named contacts in the rules of engagement, over encrypted channels, and are deleted after an agreed retention period. Evidence that proves access, such as a screenshot of one record, is kept to the minimum needed and never used for anything else.
Plain-language articles on security testing, with their sources.
Security10 min read
What an eavesdropping attack is, passive vs active eavesdropping, the techniques used on networks, Wi-Fi and calls, and how to detect and prevent them.
Updated
Security8 min read
Snooping is unauthorized access to someone else's data. See the types of snooping attacks, what snooping means in networking and computing, and how to stop it.
Updated
Security18 min read
A DDoS attack floods a service from many machines at once. How botnets, floods and amplification work, how to spot one, and how DDoS protection stops it.
Updated
Security16 min read
A man-in-the-middle attack puts an attacker between you and a service to read or alter traffic. How ARP, Wi-Fi, DNS and AiTM attacks work, and how to stop them.
Updated
Security16 min read
Where cyber defence is heading to 2030: zero trust, passkeys, post-quantum crypto, secure by design, SBOMs, AI, and the NIS2, CRA, SEC and UK rules.
Updated
The same engineers answer for each of these.
Tell us what you run and what is getting in the way. You get a reply within 24 hours.
