Service
Compliance-Driven Penetration Testing
Penetration testing scoped and reported for SOC 2, PCI DSS, ISO 27001 and HIPAA.
Frameworks ask whether a control exists. Testing establishes whether it works. This is penetration testing scoped around the framework you are being assessed against, SOC 2, PCI DSS, ISO 27001 or HIPAA, and reported so the evidence can go to your assessor without translation. We test to support your audit. We are not an assessor, auditor or certifying body, and we do not issue certificates or reports on compliance: that judgement belongs to your auditor.
How this works
Start from the control, not the checklist
Each control in scope is read for what it is actually trying to prevent, and a test is designed against that. A requirement for access review is tested by attempting access that a review should have removed, rather than by inspecting the review calendar.
Evidence in the form an assessor accepts
Findings are recorded with the artefacts an audit needs: what was tested, when, from what position, what the result was, and what changed afterwards. The point is that your assessor can rely on it directly rather than asking you to re-explain it.
What each framework asks for
PCI DSS sets out penetration testing directly in Requirement 11.4, including internal and external testing, retesting of fixes, and segmentation testing where segmentation reduces scope. ISO 27001 expects technical vulnerabilities to be identified and managed under Annex A control 8.8. The HIPAA Security Rule requires periodic technical evaluation under 164.308(a)(8). SOC 2 does not name penetration testing, but auditors commonly accept it as evidence under the monitoring criteria. The scope is set from what your framework and your assessor expect, not from a generic checklist.
Gaps stated as gaps
Where a control is absent or ineffective, that is written plainly with what would close it. A report that reads as though everything passed is worth nothing to you and is usually the reason a second opinion was commissioned.
What we look for
- Access controls that exist in policy and not in configuration
- Privileged accounts outside the review process, including service accounts and break-glass credentials
- Logging and monitoring that satisfies a control on paper but retains nothing usable
- Encryption requirements met in transit and quietly unmet at rest, or the reverse
- Change management that is followed for planned work and bypassed for urgent work
- Third-party and vendor access that no longer matches the contract that authorised it
What you get
- Test results mapped to the specific control identifiers your framework uses
- Evidence artefacts an assessor can rely on without re-testing
- Gaps described with the change that would close each one
- A technical report alongside the mapped output, because the underlying findings are worth having regardless of the audit
What this does not include
- Certification or attestation: we are not an assessor, auditor, QSA or certifying body, and that relationship stays separate for good reason
- Writing your policies, though gaps in them are reported where testing exposes one
- Ongoing compliance monitoring
- Any assurance that an assessor will reach the same conclusion, since that is their judgement to make
Questions people ask
- Which frameworks do you work against?
- SOC 2, PCI DSS, ISO 27001 and HIPAA. They share most of their technical requirements, and findings are mapped to whichever identifiers your programme uses. The testing underneath is largely the same work; what changes is the scope each framework expects and the evidence your assessor wants to see.
- Can this replace our auditor?
- No, and it should not. We are not an auditor or a certifying body. Your auditor attests; we produce the technical evidence they attest against, and find the places where a control passes inspection and fails in practice.
- We already passed. Why test?
- Passing establishes that a control was documented and sampled. It does not establish that it stops the thing it was written for. The gap between those two is where most post-certification incidents live.