Audit, Assurance and Incident Management
What the exam tests
Two linked areas: how assurance is obtained and how incidents are handled. Expect items on audit evidence, report types and coverage periods, and on the correct sequence of incident response steps.
Audit and assurance
- Evidence must be sufficient (quantity) and appropriate (relevance and reliability). Auditor-generated evidence such as observation or recalculation is stronger than a management assertion.
- Findings follow a structure: condition (what is), criteria (what should be), cause, effect or risk, recommendation. A finding without criteria is an opinion.
- Sampling carries sampling risk; a clean sample does not prove the control operated all year.
- SOC reports: SOC 1 covers controls relevant to financial reporting (SSAE 18 / ISAE 3402); SOC 2 covers the trust services criteria (security, availability, processing integrity, confidentiality, privacy); SOC 3 is a general-use summary. Type I is a point-in-time opinion on design; Type II covers design and operating effectiveness over a period. Check the period and request a bridge letter if the report is stale. Complementary user entity controls (CUECs) are the customer's responsibility, not the auditor's.
- ISO/IEC 27001 certifies the management system: Stage 1 readiness and documentation, Stage 2 implementation evidence, then surveillance audits.
Incident management (NIST SP 800-61)
Preparation → detection and analysis → containment, eradication and recovery → post-incident activity. Containment may be short-term (isolate) or long-term (rebuild). Preserve evidence before wiping. The post-incident review feeds lessons learned back into preparation.
Worked example
An analyst sees anomalous outbound traffic. Correct order: confirm and scope (detection and analysis), preserve logs, isolate the host (containment), remove the malware and rebuild (eradication and recovery), then assess whether personal data was involved. Only if it was, and only if the notification threshold is met, does the regulatory clock start - the incident exists before the breach determination.
Traps
- Confusing a security incident with a reportable personal data breach.
- Treating a Type I report as year-long assurance.
- Ignoring CUECs when relying on a vendor's SOC 2.
- Wiping and rebuilding before evidence capture.
- Starting the 72-hour GDPR clock at discovery of the anomaly rather than awareness of a personal data breach.