The Governance Program That Survived Every Audit and Failed One Incident

The governance program had a perfect audit record. No significant findings in four consecutive external audits. Internal audit consistently rated the security program as mature.

RCDr. Richard Chingombe · Founder, Verisq·5 min read·Practitioner perspective, not legal advice

Board reporting showed steady progress. The program had been built, it had been maintained, and it had been assessed by people who knew what they were doing. When the significant incident occurred, the program failed the test that audits had not administered: the test of actual operation under adverse conditions. The detection did not catch the intrusion for three weeks. The response did not produce a contained incident — it produced an extended event. The recovery took longer than the BCP had ever contemplated. The audit record was perfect. The incident was not.

What Audits Test and What Incidents Test

The divergence between audit performance and incident performance is not mysterious. Audits test whether governance programs are designed and documented correctly. They assess whether controls exist, whether evidence of their operation can be produced, and whether the organization can demonstrate that it has followed the required governance processes. These are necessary assessments. They are not sufficient assurance that the governance program will perform well when an actual adversary applies actual pressure.

Incidents test different things. They test whether the response plan produces actual decisions when the primary contacts are unavailable and the situation is ambiguous. They test whether the detection capability identifies attacks that are designed to evade detection, not attacks that match the detection rules configured for the test environment. They test whether the organization can execute its recovery procedures with the data it actually has, the tools it actually has, and the people who are actually available — not the idealized version that the BCP documents describe.

The audit tests the governance program against its own documentation. The incident tests it against an adversary. These are genuinely different tests that require genuinely different preparation. A program optimized for audit performance is not automatically optimized for incident performance.

The Four Places Where the Program Failed

Detection That Was Calibrated for Compliance, Not for Threats

The detection program had been designed to demonstrate monitoring coverage for the audit — to show that logging was enabled, that alerts were configured, and that a review process existed. The detection rules that had been implemented were the standard rules that came with the SIEM, tuned to reduce false positives to a level that the security team could manage. The attacker's techniques were not in the standard rule set. The attacker spent three weeks in the environment before the detection was triggered by a mistake the attacker made, not by the detection capability that had been assessed as adequate.

Response That Had Been Planned but Not Practiced

The incident response plan was comprehensive and well-written. The people named in the plan were mostly still in their roles. The escalation paths were documented. What had not happened in the three years since the plan was written was a realistic exercise under adverse conditions: with primary contacts unavailable, with the communication infrastructure partially down, with the scope of the incident still unclear and expanding. The plan worked for the clean version of the incident. The actual incident was not clean.

Recovery That Required Data That Wasn't There

The recovery process for the affected systems required forensic analysis of the attack path before restoration could begin — to ensure that the same vulnerability that had been exploited was not present in the restored environment. The forensic analysis required logs from systems that had not been included in the log retention program because they were outside the compliance scope. The logs did not exist. The forensic analysis was limited. The recovery timeline extended beyond the BCP's recovery time objective because the information needed to recover safely was not available.

Communication That Created Its Own Problems

The incident communication plan had been designed to satisfy regulatory notification requirements and to manage the organization's public communication. It had not been designed for the internal communication during an extended multi-week incident — who received updates, at what frequency, through what channels, and with what level of operational detail appropriate for each audience. The communication during the incident was improvised. Different stakeholders received different information at different times. The confusion about the incident's scope and status created additional organizational disruption.

See how your own vendors measure up.Security and privacy posture for any vendor, from the outside, free.
Check a vendor's scorecard

Building Programs That Perform Under Pressure

The governance programs that perform well under incident conditions share a characteristic that audit-optimized programs do not have: they are tested against adverse conditions rather than against the conditions that produce favorable audit results. Detection rules are tested against adversarial techniques through red team exercises, not only against the threat patterns that reduce false positives in normal operations. Response plans are exercised with primary contacts unavailable and communication infrastructure degraded. Recovery procedures are tested with incomplete information and time pressure.

This testing is uncomfortable because it reveals gaps that the audit record does not show. The organization that tests its detection capability against adversarial techniques and finds that the techniques evade its detection has discovered something important that the audit did not reveal. The discovery is an investment — it is cheaper to address the gap in a test than in an actual incident.

The governance program that balances audit performance with incident performance is built differently from the one optimized for either alone. It maintains the documentation and evidence quality that audits require, and it maintains the operational capability that incidents reveal. Both are required. The program that has only the first will pass audits and fail incidents. The program that has both will do both.

Test the governance program under the conditions it will actually face. The audit result is the floor. The incident result is the ceiling. Build toward the ceiling.

The perfect audit record is a necessary achievement. It is not sufficient assurance. Build the incident performance capability alongside the audit compliance capability.

Enterprise practitioner perspective. Not legal advice. Part of the Deep Trust Governance Series by Verisq. Get the free weekly Breach Digest.