Security compliance

Security compliance measures an organisation against an external yardstick: a standard such as ISO 27001, a regulation such as NIS2 or DORA, or a scheme with defined categories such as the ENS. The organisation identifies which controls apply, implements them, records how, and presents that evidence to an auditor or supervisory body, often anchored in a document such as a Statement of Applicability that says which controls are in scope and why. The output is a defensible account that the required controls exist and operate. Managing the whole of that effort as a system, rather than a checklist, is what an ISMS does.

The trap is treating the certificate as the goal. Compliance evidences that a control is present; it does not prove the control resists an attacker. A password policy can be documented and enforced and still be defeated by kerberoasting; a firewall can be in scope and audited and still permit the lateral movement that matters. From the offensive side, we routinely compromise estates that hold current certifications, because the audit asked whether a control existed, not whether it worked against a determined adversary. The distance between “we can evidence this control” and “this control stops the attack” is exactly where the real risk sits, and compliance alone does not close it.

Compliance and offensive testing meet at the evidence. Several standards and regulations require proof that controls are effective, not merely present, and a penetration test or red team is how that proof is produced: the assessment demonstrates whether the control actually holds, and the report becomes evidence an auditor accepts. We frame findings against both the technical impact and the compliance obligation they touch, so the client can close the security gap and satisfy the auditor with the same work. This is how testing produces the evidence an auditor accepts.