Reporting
The SOC report is not administrative overhead — it is the artefact that proves the function works, and the one a supervisory review will read first. This section gives the structure, the metrics with their definitions, and the discipline that gets it out on the same date every month.
Structure
Consolidated from several generations of production templates. Keep the numbering stable across months — the value of a periodic report comes from being comparable to the last one.
The glossary is load-bearing
Event, detection, alert, incident — these are not synonyms, and if the report does not define them, every count in it is arguable. Define them once, in the report, and never change a definition mid-year without saying so in the change history.
KPI catalogue
Targets here are the ones that appear in real service specifications. Treat them as starting positions to negotiate from. What matters more than the number is that the definition and the measurement method were agreed before anyone reported against them.
| Metric | Definition | Unit | Why it matters | Target |
|---|---|---|---|---|
| SOC platform availability | Percentage of time the SOC's own platforms are available, measured with infrastructure monitoring. | % per month | If the platform is down, nothing is detected. This is the floor under every other metric. | 99.5% |
| Sensor and collector availability | Percentage of time all sensors are reachable, and percentage of data collectors reachable. | % (two sub-measures) | Silent collectors create invisible blind spots that read as 'a quiet month'. | 99% / 99% |
| Data ingestion latency | Minutes from event occurrence to initial processing, measured as the difference between storage time and log source time. | minutes | Latency is a hard cap on achievable detection speed. You cannot beat it with better analysts. | 1 minute |
| Metric | Definition | Unit | Why it matters | Target |
|---|---|---|---|---|
| Detection framework coverage | Percentage of the adversary technique framework implemented through correlation rules. | % of framework | The only structural answer to 'what can we actually detect?' — and the one an evaluator asks for. | Set a trajectory, not a number |
| Monitoring coverage | Percentage of devices under monitoring by category, measured by reconciling asset and vulnerability data against what the SIEM actually sees. | % of devices | Coverage gaps are the most common single cause of missed incidents. | 100% |
| Metric | Definition | Unit | Why it matters | Target |
|---|---|---|---|---|
| True positive / false positive ratio | Ratio of true to false positives across the detection library. | % | The direct measure of detection quality — and of how much analyst time is being burned. | Improving trend, reviewed weekly |
| False positive rate per use case | Share of false triggers, measured per detection rule rather than in aggregate. | % per use case | Enables targeted tuning. An aggregate number tells you there is noise, not where it comes from. | Per-rule threshold, then tune or retire |
| New detections promoted | Number of detection rules promoted into production per week, tracked through change requests. | rules per week | Evidence that detection engineering is happening, rather than only monitoring. | 1 per week |
| Events closed without registration | Ratio of events acknowledged and closed with a comment, without an incident being registered or investigated. | % | The guard against click-to-clear behaviour on the console. A rising number is a warning, not an efficiency. | Below an agreed ceiling, reviewed weekly |
| Detection backlog and its age | Queue of detection and automation work items, and how long they have been waiting. | count and days | Shows whether tuning debt is growing. A stable backlog with rising age is worse than a growing one. | Age ceiling per priority |
| Metric | Definition | Unit | Why it matters | Target |
|---|---|---|---|---|
| MTTD — mean time to detect | From the start of the event to the first validated alert. | time | The core detection-capability metric. Notably absent from most client report templates. | Trend down; state the measurement basis |
| MTTA — mean time to acknowledge | Average time from alert to the start of analyst action. | time | Measures whether alerts are actually being picked up, as distinct from being resolved. | Under 15 minutes |
| Incident response time | Time from incident registration to assignment to a named handler. | minutes | The contractual promise to the service recipient — the one they will hold you to. | Under 60 minutes |
| MTTR — mean time to respond | From confirmation of the incident to containment and recovery. | time | Separates response performance from detection performance. Reporting them merged hides which one is failing. | Per severity — e.g. under 4 hours for critical |
| Problem resolution time | Time from registration to the root cause being eliminated and the environment restored to its original state. | hours / days | Distinguishes containment from actual resolution. Containment stops the bleeding; this closes the wound. | Decreasing trend |
| Incidents closed within target | Share of incidents resolved without breaching the agreed response commitments. | % | The single number a service review opens with. | Over 95% |
| Notification timeliness | Share of notifiable incidents for which the authority was informed within the statutory deadline. | % | There is only one acceptable value. A miss here is a regulatory finding, not a performance dip. | 100% |
| Metric | Definition | Unit | Why it matters | Target |
|---|---|---|---|---|
| Lessons-learned implementation speed | Time from the incident to a preventive improvement being created and deployed. | days | The metric that proves post-incident reviews change anything at all. | Agreed ceiling per action priority |
| Hours returned to the organisation | Volume of handled work multiplied by the normative duration each item would have taken the organisation's own staff. | hours per month (and FTE equivalent) | Converts SOC activity into avoided workload. This is the argument that survives a budget round. | Level and month-on-month trend |
| Incident severity and status distribution | Registered incidents grouped by severity, and by resolved / deferred / open — with the cumulative unresolved count since service start. | counts | The cumulative column is the important one. It stops an ageing backlog being hidden by one good month. | Cumulative open and deferred trending to zero |
The metric most SOCs quietly avoid
Mean time to detect is the one that measures the SOC’s actual capability, and it is conspicuously missing from most client-facing report templates — because it needs a defensible “event start” timestamp, which is hard. Report it anyway. A measured, imperfect MTTD beats a perfect MTTR that hides how long the adversary was already inside.
Report response and detection separately
Merging detection and response into one figure hides which half is failing. A SOC that contains in twenty minutes but detects in nine days does not have a good MTTR — it has a visibility problem wearing a response metric as a disguise.
Audiences
The same underlying data, cut differently. A board asked to read a detection-tuning table will stop reading the report entirely — and then stop reading the one that actually mattered.
| Audience | Cadence | What they need to see |
|---|---|---|
| Service recipients / system owners | Monthly | Response times, incidents affecting them, new detections, findings requiring their action |
| SOC performance review | Quarterly | Platform availability, coverage, latency, true/false positive ratio, framework coverage, events closed without registration |
| Cybersecurity manager / CISO | Quarterly | Detection quality, coverage, competencies gained and training completed, escalation quality |
| Executive management | Annual (and after major incidents) | Response times, incident distribution, coverage, staffing and competency, value returned, accepted risks |
| Supervisory authority | Statutory triggers | Incident notifications, investigation reports, monthly aggregate counts of insignificant incidents |
Three things: what changed in our exposure, what we did about it, and what we are asking for. Every number needs a sentence saying whether it is good.
Detection quality, coverage movement, backlog age, and the risks you are carrying because a recommendation was not accepted.
Only what concerns their systems, and only what they can act on. An unactionable finding sent monthly trains people to ignore the report.