Chapter 21 — Response system requirements and service objectives

Lesson map

Lesson 21 published. Map, example, EX041.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["21.1 Functional requirements and service objectives"]
  N2["21.2 Objectives for response systems"]
  N3["21.3 Conflicts"]
  N4["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX041"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["21.1 Functional requirements and service objectives"]
  N2["21.2 Objectives for response systems"]
  N3["21.3 Conflicts"]
  N4["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX041"]

[Learning outcomes and connection]
    |
    v
[21.1 Functional requirements and service objectives]
    |
    v
[21.2 Objectives for response systems]
    |
    v
[21.3 Conflicts]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX041]

Learning outcomes and connection

After this chapter you can (1) convert broad response aims into functional requirements and measurable service objectives; (2) define latency, integrity and auditability objectives with measurement methods; (3) detect conflicting objectives and record the decision that resolves them; and (4) write acceptance criteria that a test can pass or fail. It builds on Chapters 5, 16 and 20 and prepares Chapters 29, 44 and 48.

21.1 Functional requirements and service objectives

Functional requirements state what the system does: "the platform shall create a case from an alert, linking the alert's raw event". Service objectives state how well, measured over time: "99% of alerts from tier-1 sources appear in the queue within 5 minutes of event time, measured weekly". The site reliability engineering literature distinguishes service level indicators (the measured quantity), objectives (the target) and agreements (contractual consequences) (Beyer et al., Site Reliability Engineering, ch. 4). A response platform needs objectives for the qualities that matter to decisions, not only for uptime.

21.2 Objectives for response systems

• Latency: event-to-queue, request-to-approver, approval-to-action, action-to-verified-effect. Specify percentiles, not means.
• Completeness: fraction of expected events received per source (requires heartbeats or sequence numbers, Chapter 3).
• Integrity: fraction of evidence items verifiable against the manifest on sampling; zero unverifiable items as an objective with an alarm.
• Auditability: every privileged action has a complete audit record — measured by reconciliation between action logs and audit logs.
• Correctness of action scope: zero actions outside approved scope, verified by negative tests and reconciliation.
• Availability of the response path itself, including during identity-provider outages.

21.3 Conflicts

Objectives conflict. Low event-to-queue latency favours streaming without validation; integrity favours validation and manifests. Rapid containment conflicts with approval gates. Long retention conflicts with privacy minimisation. The engineering task is to make each conflict explicit, quantify it where possible and record the decision and its owner — not to pretend all objectives can be maximised. A conflict table lists pairs, the mechanism of conflict and the resolution (priority, compromise, or a design that relaxes the conflict, such as validating asynchronously while queuing immediately with a "validation pending" flag).

21.4 Worked example (synthetic): an HVSS procurement brief

The brief promises "response in under 15 minutes" and "full forensic evidence for every incident". Rewritten:

Lesson table; scroll horizontally to read all columns →

"Response in under 15 minutes" was split into measurable segments; it conflicts with SO-3's approval gate for multi-host actions, resolved by limiting the 10-minute objective to single targets. "Full forensic evidence for every incident" was unbounded and conflicted with privacy; replaced by SO-4 for raw events and a separate requirement for memory capture on approval.

21.5 Errors and limits

• Means instead of percentiles.
• Objectives without measurement method.
• Hidden conflicts resolved by whoever configures the system.
• Uptime as the only objective.

The HVSS brief commits the first two errors in its promise of "response in under 15 minutes". It does not say whether that is a mean or a percentile, or where the clock starts and stops. SO-1 to SO-3 replace it with percentiles over named segments, each measured from timestamps or workflow audit. The original wording also hid a conflict with the approval gate for multi-host actions, which the rewrite resolves by limiting SO-3 to single targets.

Exercises — chapter 21

EX041 — Write objectives. Objective: measurable objectives. Inputs: aim "notifications to clients must be timely and accurate". Steps: write two objectives with indicator, target, window and measurement source. Expected evidence: two objectives. Rubric: 3 = percentile-based, measurable, accuracy defined (e.g., correction rate); 2 = one weak; 1 = vague; 0 = none.

EX042 — Conflict table. Objective: expose conflicts. Inputs: SO-1 to SO-5 and a privacy requirement "personal data in case records deleted after 180 days unless legal hold". Steps: identify two conflicts, the mechanism and a resolution each. Expected evidence: table. Rubric: 3 = SO-4 vs privacy with legal-hold or pseudonymisation resolution, SO-1 vs validation with asynchronous validation; 2 = one; 1 = vague; 0 = none.

Chapter synthesis

Requirements say what the response system does; service objectives say how well, as measured percentiles over defined windows. Cover latency, completeness, integrity, auditability and scope, expose conflicts and record decisions with owners.