Compliance & Security Audits

It is worth saying plainly: passing an audit does not make you safe, and being safe does not automatically pass an audit. Compliance is a floor, not a ceiling. We approach it from the security side first, so the work makes you genuinely harder to breach and, as a by-product, produces the evidence the framework wants. A ticked box over a real hole helps no one, and a good assessor can usually tell the difference. Done this way, the audit stops being a tax on the business and starts being a genuine health check you would want anyway.

If you take card payments, PCI DSS 4.0 sets the rules. Requirement 11.4 calls for penetration testing at least annually and after any significant change, covering both the network and the application layer, plus segmentation testing where you rely on it to reduce scope. We run the test to that requirement and document it so your acquirer or QSA accepts it without a back-and-forth.

ISO 27001 is about a working information security management system. Control A.8.8 on technical vulnerabilities and A.8.25 on secure development expect you to find and manage weaknesses, and an auditor will ask for evidence of testing. Our reports slot straight into your ISMS as that evidence, and our gap assessment shows you where the management system itself falls short of the standard.

SOC 2 reports against the trust services criteria, and the security (common) criteria expect vulnerability management and monitoring. For a SaaS company chasing enterprise deals, a clean penetration test is often what the customer’s own security team wants to see before they sign. We produce it in a form that supports your Type I or Type II report.

GDPR Article 32 requires you to test and evaluate the effectiveness of your security measures for personal data, not merely to have them. For financial-sector firms, DORA now mandates regular threat-led testing and tight incident reporting, and NIS2 extends similar duties to a wider set of essential and important entities across Europe. We advise on what these mean for your website and supporting systems in practical, technical terms.

We start by pinning down which standard you answer to, what is in scope, and what your assessor specifically expects. A PCI test of a cardholder environment is scoped differently from an ISO evidence exercise, and getting this right up front is what stops rework later. This is also where we identify whether one test can serve several obligations at once.

Certified engineers test the in-scope systems by hand, the same manual methodology we use for any penetration test, and where the framework calls for it we also assess controls and processes against the standard. Every finding is verified and given a CVSS score, so nothing in the report is a false positive you have to argue about with an auditor.

You receive an executive summary, a technical report with reproduction steps and fixes, and a mapping table that ties each finding to the relevant clause of your framework. The attestation letter states clearly what was tested, by whom, when, and to what standard. That is the document your clients and assessors actually ask for.

A prioritised plan tells your team what to fix first. Once they have, we retest the affected findings at no extra cost and reissue the report, so you can show an auditor not just that issues were found but that they were closed. Demonstrated remediation is often worth more to an assessor than a clean first result.

Frameworks expect you to be able to restore service after an incident, and to have evidence you have tried. Plenty of businesses have backups but have never once tested a restore, which is exactly the gap an auditor probes. We check that the recovery path works, not just that a copy exists.

Old accounts that were never removed, shared admin logins, and permissions far broader than anyone’s job needs are perennial audit failures. Standards want least privilege and a clear joiner-mover-leaver process, and the evidence is easy to produce once the process is real rather than assumed.

An auditor will ask how you find out about vulnerabilities and how quickly you act. Ad-hoc updating is not an answer that survives scrutiny. We help you put a defensible process in place and show, through the test results, that known issues are actually being closed.

If you cannot tell whether you have been breached, you cannot meet the detection expectations that run through every modern framework. We check that the right events are logged, retained, and actually watched, because a log nobody reviews satisfies neither an auditor nor an attacker’s victim.