External infrastructure testing
We look at your internet-facing estate the way an attacker would. That covers discovering subdomains and DNS records, identifying open ports and running services, and checking for known vulnerabilities and misconfigurations. You get a clear picture of what is exposed, what it tells an attacker, and what should not be there.
You choose how deep the port scan goes: the most common TCP ports, all 65,535 TCP ports, or all TCP ports plus UDP. Whichever you choose, the report states exactly which ports were examined, so a quick scan is never mistaken for a full one.
Web application assessment
We assess your websites and web applications for security headers, TLS and certificate configuration (expiry, hostname mismatches, untrusted chains, weak signatures and deprecated protocols), cross-origin resource sharing (CORS) policy, exposed files and common vulnerability classes. Each finding comes with evidence and a practical fix.
Web services don’t only run on ports 80 and 443. When the port scan finds a web server on another port, such as an admin panel on 8443 or a development server on 8080, that service is tested as well.
One web server can also host several sites and choose which one to show from the name it is asked for. A staging copy or an admin site may have no public DNS record, yet still answer anyone who asks for it by name. We ask each of your web servers for common names of this kind, such as dev, staging or admin, and report any that bring up a separate site. Each hidden site we find is then tested like any other website: security headers, TLS and certificates, CORS, exposed files and known vulnerabilities. We only try names within your agreed scope, and the report states how many names were tried, because a site with an unusual name could still go unfound.
Manual web application testing
Automated tools find the common problems, but they don’t understand how your application is meant to work. For applications that handle logins, customer data or payments, we also test by hand. That covers authentication and password reset, session handling, access control (for example, whether one user can see another user’s data), input handling and injection, and flaws in the business logic itself. The testing follows the OWASP Top 10 and the OWASP Web Security Testing Guide.
If the testing needs accounts on your application, we’ll agree a secure way to set them up once the scope is signed off.
Exposed files and content discovery
Some of the most damaging exposures are simple ones: a .git folder, a .env file full of credentials, a database dump or a forgotten backup archive left on a web server. We check for these and also search for hidden paths and directories that aren’t linked from your site.
We only report an exposure when the file’s contents confirm it. A status code alone doesn’t count, so a server that answers “200 OK” to every request doesn’t produce false alarms. The evidence records what kind of file was exposed without copying any secrets it contains into the report. Sample and template files, such as a .env.example, are rated lower than the real thing.
Domain and email security
We map your subdomains and DNS records and check how well your domains are protected against email spoofing. SPF and DMARC are judged against how each domain is actually used, so a domain that sends no email and is correctly locked down isn’t flagged, while one that sends email without protection is. We also check your DKIM signing keys for weak, outdated or broken keys. DKIM keys can’t be listed from DNS, so we check the names that common email providers use, plus any you give us, and we won’t tell you DKIM is missing just because we didn’t find a key.
Cloud exposure review
Misconfigured cloud storage and services are one of the most common causes of data exposure. We check for publicly accessible storage and cloud-hosted services from the outside, which is how they are actually found.
Attack-surface monitoring
Your external estate keeps changing: new services go live, certificates expire, and someone opens a port for testing and forgets to close it. With attack-surface monitoring we repeat the assessment on an agreed schedule, such as monthly or quarterly, and compare each run with the last. You see what’s new, what’s changed and what you’ve fixed, without waiting for the next full penetration test.
Each scheduled run is checked automatically against the one before it. If a new issue appears, an existing one becomes more serious, something checked last time could not be checked again, or a run fails, we’re alerted straight away. A missed or failed scan is never mistaken for a clean one. Monitoring only runs within the period you have authorised, and stops automatically when that authorisation ends.
Retesting and progress reports
After remediation, we retest the original findings and give you a comparison report. It shows what’s resolved, what’s changed, what’s new, and anything that could not be retested, so you can show real progress to your board, customers or auditors.
What every engagement includes
Written scope and authorisation before any testing begins, with an agreed end date after which testing stops, and a copy of your permission kept on file. Testing restricted to in-scope targets only. An executive summary with an overall risk rating. Detailed findings with severity, evidence and remediation guidance. An explicit coverage statement naming anything that could not be tested, including which ports were examined. An encrypted report, with the password sent to you separately. Reports in British or American English on request.