Service
Compliance Audits
Security testing mapped to the control frameworks your auditors are asking about.
Frameworks ask whether a control exists. Testing establishes whether it works. Both matter, and they are usually bought separately, which is how organisations end up certified against a control that has never been exercised. This is technical testing whose output is written so it can be handed to an assessor without translation.
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.
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: an auditor issues that, and it is a separate relationship 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?
- The common ones share most of their technical requirements, and the mapping is done to whichever identifiers your programme uses. The testing underneath is largely the same work; what changes is how it is labelled and which evidence an assessor expects.
- Can this replace our auditor?
- No, and it should not. An auditor attests. This produces the technical evidence they attest against, and finds 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.