When a customer ticket starts your reporting clock

A senior practitioner pushed back on something we posted last week. The point about evidence carrying across frameworks (one access-log row covering ISO A.5.17 and NIS2 Art. 21(2)(i)) was, in their words, the part most teams underestimate. But the failure mode they kept seeing in audit work was different: orgs that fail Art. 23 almost never fail on the report itself — they fail on detection-to-triage latency nobody was measuring.

Then they asked the question that prompted this post: when the upstream signal is a customer ticket rather than a SIEM finding, how do you defend `captured_at` as the regulatory anchor if the ticket sat unread for hours?

Why `captured_at` is right — and why it is not enough on its own

Anchoring the regulator's clock on the upstream signal time is the right call. It is precisely where most tools cheat, stamping app-open time or human-acknowledge time and producing a timeline an assessor will pick apart in five minutes. The signal time is auditable: a SIEM alert carries it, an IDS log carries it, a customer ticket carries it as the inbox-received timestamp.

But "the signal arrived" and "the org was reasonably aware" are not the same fact. The regulator can — and will — ask whether you had a duty to notice the signal sooner than you did. For a SIEM with a 24/7 SOC, the implicit duty makes signal time and awareness time effectively identical. For a customer inbox monitored Monday to Friday during business hours, they are very much not.

The honest defense is three-layered, not one

After the question landed, we shipped the missing layer. Anchoring the Art. 23 clock now rests on three things, not just one timestamp.

1. `detected_at` — the upstream signal time

Immutable, source-attributed, the earliest defensible anchor. Every Raize Orion incident carries a `detected_at` plus a `detection_source` field (SIEM / IDS / connector finding / customer ticket / human report / other) plus the source's own identifier so the chain back to the upstream record is auditable. When the incident was created from a connector finding, the connector's own `captured_at` flows through automatically — the timestamp is the signal time, not a human's login time.

2. A documented monitoring SLA per detection source

This is the layer that was missing until last week. Each org can now document, per (detection source, severity), what its acknowledgement commitment is — and how that commitment is bounded. A SIEM alert at 15 minutes 24/7. A customer inbox at 4 business hours. A critical customer report routed through the on-call rota at 60 minutes regardless of hours. Each row carries a reference to the SOP or rota document so the assessor sees the actual commitment, not a number floating in a database.

Tighter scopes override broader ones. An org can set a baseline 4-business-hour SLA for customer tickets and a tighter 60-minute on-call SLA specifically for critical-severity customer reports, and the platform picks the right one per incident.

3. The actual acknowledged time, with the gap evaluated against the SLA

Every Raize Orion incident now carries three awareness timestamps with source attribution: `detected_at`, `acknowledged_at` (first human eyes), `triaged_at` (severity confirmed, plan in place). The gap between detection and acknowledgement is evaluated live against the documented SLA, with four states:

• within — acknowledged inside the target
• pending — clock running, not yet exceeded
• amber — exceeded the target, but the SLA is business-hours-only and the gap is plausibly explainable (the analyst is expected to add context in the audit trail)
• red — exceeded the target with no documented excuse

An assessor opening a real incident sees the commitment, the actual gap, and any explanation, in one view. There is nothing to reverse-engineer.

The customer-ticket case, worked through

A support ticket lands at 02:14 on a Sunday. The customer described what is in fact a data-handling incident. Nobody opens it until the Monday-morning analyst starts their shift at 09:00. They acknowledge it at 09:15. That is a 31-hour gap.

Without a documented commitment, the regulator gets to draw the worst-case inference: you received an incident report and took 31 hours to notice. Indefensible.

With Raize Orion configured against the org's real policy — customer inbox SLA of 4 business hours, no out-of-hours rota for non-critical tickets — the same 31-hour gap is classified as `amber` rather than `red`. The audit trail captures the documented SLA, the actual acknowledgement, and any analyst note (for example: "ticket arrived during the weekend window outside the inbox SLA; first analyst opened the queue at 09:00 Monday per the documented rota"). The clock is still amber — there is still a real conversation to have about whether 4 business hours is the right SLA for a channel that can receive incident reports — but the data point survives the audit.

If the same org documents a tighter critical-severity rota of 60 minutes 24/7, the platform picks that SLA instead the moment the incident is flagged critical, and the same 31-hour gap snaps back to red. The classification follows the org's own commitment, not the platform's opinion.

Where the latency conversation actually moves

Per-incident defensibility is the audit story. The wider value is the analytics layer above it. Raize Orion now computes per-source SLA breach rates across past incidents — not just "your detection-to-acknowledge p90 is 9.2 hours" but "your customer-channel acknowledge p90 missed your own 4-business-hour commitment on 24% of tickets last quarter."

That second number is the one that survives the board meeting. The first is a metric. The second is a metric against a commitment, which is the only kind of metric a CISO can take to a budget conversation.

Honest scope of what changed

Three pieces shipped to close this gap:

• A `monitoring_slas` table — per-org, per-detection-source, per-severity-scope. Configurable with one click to a sensible baseline; admin-only edit.
• Inline SLA breach evaluation in the Incident Register, surfacing the commitment alongside the timestamp at the point of data entry. The analyst cannot accidentally understate the gap.
• A per-source SLA breach-rate sub-card in the response-time analytics, so the org sees breach concentration by channel — not just an aggregate number.

The append-only audit trail underneath all of this was already in place. So was the awareness pipeline (`detected_at` / `acknowledged_at` / `triaged_at`), the multi-window reporting clock (NIS2 24h / 72h / 1-month + GDPR 72h), the backend cron firing 75% threshold alerts off-hours, and the connector-finding-to-incident bridge that preserves `captured_at` through to the regulatory anchor. The new layer ties them to a documented commitment.

What this does not solve

A platform cannot fix triage maturity. If the org has no detection capability at all — no SIEM, no IDS, no inbox monitoring, just customer tickets that arrive eleven days later through a sales relationship — no monitoring SLA can manufacture an earlier `detected_at`. What Raize Orion does is make the gap visible and defensible. The fix for the gap itself is escalation policy, on-call rotas, and SOPs — not features.

The practitioner who asked the question was right to push on it. Detection-to-triage latency is where Art. 23 actually fails, and it fails silently because nobody was measuring it against a documented commitment. We now measure it against a documented commitment. That is the unlock.

The 10-day trial is at /pricing. Configure your monitoring SLAs in the new Monitoring SLAs section, log a recent incident with the awareness-pipeline timestamps, and see the breach evaluation on a real number.