Last reviewed:
A coverage gap is not a ticket until the team knows what evidence is missing, what fix is possible and who can ship it.
Start by naming what is absent. Is there no log source, no parser, no field mapping, no rule, no triage path or no owner? Each answer leads to different work.
This matters because 'missing T1078.004 coverage' could mean Entra audit logs are not ingested, AWS IAM events are not normalised or the team has a rule but no alert route. One label cannot fix all three.
Turn the gap into one of a few fix types. Telemetry gaps need logging or ingestion work. Logic gaps need Sigma or SIEM rules. Context gaps need asset, identity or exposure data. Workflow gaps need ownership and triage steps.
That split keeps detection engineering from absorbing every cloud security problem. Some gaps belong with platform teams before a detector can be useful.
Rank the queue by attack path, exposure and delivery cost. A gap for internet-facing initial access deserves attention before a niche post-exploitation technique in an isolated lab account.
CloudSigma fits the rule-fix lane once the telemetry is real and the behaviour is specific. DCV fits the review lane by keeping the missing evidence and the fix type visible.
A useful ticket should tell the engineer what to build and how the reviewer will know it worked. If the ticket says only 'improve coverage', it is not ready.
Add the ATT&CK technique, platform, missing evidence, proposed fix, validation check and owner. The ticket can be small; vague work is the expensive part.
technique: T1562.008
platform: AWS
missing_evidence: CloudTrail coverage for GuardDuty disablement path
fix_type: SIEM detection rule
validation: replay known DisableDetector event in test account
owner: detection-engineering