Monitoring, Testing, and Assurance
This domain tests how you know controls actually work: what you log, what you test, how you sample, and how you report without overclaiming.
Monitoring
- Centralised logging with NTP time sync, defined retention, and integrity protection.
- SIEM correlation rules mapped to real threats and to MITRE ATT&CK coverage, not to vendor defaults.
- Metrics that matter: MTTD, MTTR, alert precision and false-positive rate, detection coverage per technique.
Testing
- Vulnerability scan: automated, broad, point-in-time, enumerates weaknesses.
- Penetration test: attempts exploit chains and states business impact.
- Red team: objective-based adversary simulation against people, process, and technology.
- SAST reads source, DAST probes a running app, SCA inspects dependencies, secret scanning catches committed credentials.
- Control testing distinguishes design effectiveness (is the control designed to meet the objective) from operating effectiveness (did it actually run over the period), using documented sampling and evidence.
Assurance
SOC 2 Type I covers design at a point in time; Type II covers operating effectiveness over a period. Internal audit must be independent of the function it assesses. Findings are tracked to closure with owners and dates.
Worked example
A SIEM rule fires 500 times a day; 460 alerts come from the authenticated vulnerability scanner. Reasoning: confirm the scanner identity and source, write a scoped suppression that still stores the raw events, document the change, then run a purple-team test proving a real exploit still fires the rule. Track precision before and after. Disabling the rule outright would hide a genuine detection.
Traps
Equating a clean scan with security; treating a Type I report as continuous assurance; leaving rules untuned or silently disabled; scanning production without written authorization; monitoring with no response path.