Daily-snapshot Remediation SLAs

Owner: Security Officer · Approved by leadership · Version 1.0 · Effective 27 May 2026 · Next review 27 May 2027

1. Purpose

This procedure defines the time-bounded service-level agreements (SLAs) by which a failure of the daily security-posture snapshot — or any audit finding raised by one of the other cadence procedures — must move from detection to closure. It connects the snapshot to the ticket tracker and defines the escalation path if an SLA is breached.

Severity classification follows section 3 of the Incident Response Policy.

2. Scope

This procedure governs:

Every failure of a daily security-posture snapshot probe.
Every finding raised by the monthly vulnerability review.
Every finding raised by the quarterly access review.
Every finding raised by the annual technical evaluation.
Every finding raised by an audit under the internal-audit programme.
Every constraint raised by the quarterly capacity-planning review.
Every action raised at the quarterly management review or the annual board review.

A finding whose severity warrants immediate response is handled under the Incident Response Policy. This procedure governs the path to closure once the immediate response phases are complete and where no immediate response was required.

3. Ownership

Accountable owner — the Security Officer owns this procedure, monitors compliance with the SLAs, and approves any extension request.
Per-finding owners — every finding has a named owner accountable for driving it to closure by the recorded deadline.

4. SLA matrix

The deadline below is measured from the timestamp at which the finding was raised (the snapshot failure timestamp, the review minutes date, or the audit report date as applicable) to the timestamp at which closure evidence has been recorded against the finding.

4.1 SEV-1 — Critical

Acknowledge: within 1 hour of detection.
Containment / interim mitigation: within 4 hours of detection.
Root-cause closure: within 7 calendar days of detection.
If root-cause closure cannot be met, an extension must be approved by leadership in writing, and a compensating control must be in place for the duration of the extension.

4.2 SEV-2 — High

Acknowledge: within 4 business hours of detection.
Containment / interim mitigation: within 1 business day of detection.
Root-cause closure: within 30 calendar days of detection.

4.3 SEV-3 — Moderate

Acknowledge: within 1 business day of detection.
Root-cause closure: within 90 calendar days of detection.

4.4 SEV-4 — Low

Acknowledge: at the next review cycle that surfaces the finding.
Root-cause closure: within 180 calendar days of detection, or formally accepted in the risk register with rationale, expiry, and compensating control.

5. Connection to the ticket tracker

Every in-scope finding is recorded as an item in the standard issue tracker at the time of detection.
The tracker item carries: finding identifier, source (snapshot probe / cadence procedure / audit), severity, detection timestamp, deadline derived from §4, owner, current status.
Daily-snapshot failures are created automatically by the snapshot runner so detection and tracker creation are simultaneous.
Findings raised by a cadence procedure or audit are created at the time the signed record is filed.
Closure of a tracker item requires evidence of the fix and, where applicable, a passing re-run of the relevant snapshot probe or DR scenario.

6. Escalation path

An SLA is treated as breached when the deadline passes with the tracker item still open and no approved extension. Escalation proceeds in stages:

Stage 1 — Owner — at 75 % of the deadline elapsed, the owner reviews and either confirms on-track closure, requests an extension, or escalates.
Stage 2 — Security Officer — at SLA breach, the Security Officer is notified automatically, re-assesses severity, and either approves an extension with a compensating control or accepts the finding into the risk register pending closure.
Stage 3 — Leadership — at 50 % beyond the SLA, leadership is notified; the finding is added to the standing agenda of the next quarterly management review.
Stage 4 — Board — any SEV-1 finding that remains open at 100 % beyond the SLA is escalated to the next annual board review as a standing item, with an interim board notification if the operating context warrants.

7. Template — tracker item

Each tracker item created under this procedure uses the following structure. This template is the artefact that an auditor may sample.

Header — finding identifier, source, severity, detection timestamp, derived deadline.
Description — what the finding is, the affected control or component, the evidence reference.
Owner — named owner.
Status — open / contained / closed / accepted, with the most recent status-change timestamp.
Activity log — every action taken against the item, with timestamp and operator.
Closure evidence — reference to the fix, the passing re-run, or the risk-register entry that supersedes the finding.

8. First instance

The inaugural application of this SLA matrix took effect on the effective date of this procedure (27 May 2026). Every open finding identified by the first run of each cadence procedure was loaded into the ticket tracker on that date with its derived deadline. The tracker state at that date is held in the compliance evidence store and available under NDA.

9. Records

Tracker items are retained in the issue-tracker history indefinitely.
SLA-breach notifications and extension approvals are filed against the tracker item.
Accepted findings are recorded in the risk register with the recorded expiry date.

10. Review of this procedure

This procedure is reviewed at least annually and after any material change to the severity model or the ticket tracker. The next scheduled review is 27 May 2027.

11. Related documents

Counter-signed PDF copy available on request to compliance@glassbreak.io.