What this covers
- Penetration testing of web applications, APIs, internal networks, and wireless
- Security audits covering configuration, access rights, patching, and backups — including whether those backups actually restore
- Compliance readiness for Cyber Essentials, ISO 27001, and SOC 2, focused on the technical evidence rather than the paperwork alone
- Hardening work that closes what the testing found, prioritised by what a real attacker would reach first
- Incident response when something has already happened: containment, understanding what was accessed, and getting you running again
- Phishing simulation and staff awareness sessions, because email remains the most common way in
How we approach it
Testing is agreed in writing first — what is in scope, what is explicitly out, when it runs, and who to call if something breaks. No production system gets tested without your written authorisation.
Reports come in two halves. A short summary a non-technical director can read and make a decision from, and a technical section with reproduction steps and specific remediation for the engineers who will fix it. Findings are ranked by what could realistically be exploited in your environment — a critical-rated issue on a system nobody can reach matters less than a medium on your login page, and we say so.
We can then do the remediation, or support your own team while they do it, and retest afterwards to confirm the fixes hold. A report nobody acts on has not made you any safer, which is why the fix stage is part of the offer rather than a separate conversation.
Tools we use for this
The platforms we reach for on this kind of work. The right choice depends on what you already run, and we will tell you when your existing tooling is the better answer.
- Kali Linux
- Parrot Security
- Burp Suite
- Metasploit
- Wireshark
- Hashcat
- Nessus
- Trivy
- VirusTotal
- OWASP
- Snyk
- Snort
- Graylog
- OpenSearch
- Splunk
- CrowdStrike
- Microsoft Defender
- Palo Alto Networks
- Bitdefender
- Kaspersky
- Okta
- HashiCorp Vault
- OpenSSL
Common questions
Will a penetration test break our systems?
Testing is scoped to avoid it, and anything genuinely disruptive is agreed with you beforehand or run against a staging copy instead. You get a named contact reachable throughout, and testing stops immediately if you ask it to.
How often should we be tested?
Annually as a baseline, and again after any significant change — a new application, a migration, or a major integration. Organisations handling payment or health data usually need a defined cycle, and your compliance framework will specify it.
We think we have been breached. Can you help today?
Get in touch and say so plainly in the message. Incident work is handled ahead of everything else, and the first priority is containing the situation and preserving evidence before anything gets cleaned up — deleting the wrong thing early makes the investigation much harder.
Do you help with compliance certification itself?
We prepare the technical side: controls, evidence, and remediation of the gaps that would otherwise fail an assessment. The certification audit itself is carried out by an accredited body, and we work alongside whichever one you appoint.
Talk to us about cybersecurity
Tell us what you are trying to achieve and we will tell you honestly whether we are the right fit. We reply within 1 - 2 business days.
Start a conversation →