From requirement to observable behavior
“Have monitoring” does not define the expected security outcome. For a closing service, specify which privileged changes must be detected, who receives them, within what window and what action is recorded. Link each requirement to a test and an owner. A console displaying events proves only that those events reached the console. Operational acceptance needs to exercise the chain through to a valid decision or action. Use authorized synthetic stimuli in an appropriate environment; a detection test should not cause an unauthorized production change simply to look more convincing.
Design, implementation and operation
Distinguish three questions: does the selected control address the relevant threat; was it configured as intended; can it work under the required operating conditions? An alert can be well designed and implemented yet fail because it only reaches an unstaffed mailbox. In rehearsal, the 02:00 event is received and classified only at 09:00. If the requirement calls for intervention before the 03:00 batch, the gap is demonstrated. Adding more alerts does not fix staffing coverage. Discuss on-call coverage, authorized automation, scope reduction or schedule changes with the owners.
Evidence that survives handover
Provide RUN with dependency inventory, responsibilities, procedures, required access, failure signals and recovery for the control itself. A runbook should let the operator recognize the issue and execute or escalate the action, including authority limits. Ask someone who did not write it to follow the procedure in rehearsal. Record steps requiring undocumented verbal assistance. The author can correct the guide, but a second attempt should demonstrate that the gap was resolved. Attendance signatures from a training session do not by themselves show that operation became autonomous.
Measure coverage and preserve comparability
Define the population before counting acceptance successes. If there are 20 privileged integrations and only 12 send valid events, observed coverage is 60%, even when all 12 passed testing. The eight without evidence must not disappear from the denominator. If inventory grows, explain the change rather than attributing every metric decline to new failures. Keep implementation status, test outcome and time to action separate. The committee needs to know which critical segment is missing, rather than receiving only an overall average.
Decide on delivery and summarize
In the final case, the project wants to close on Friday, support can operate the control on weekdays and the first critical run occurs on Sunday. Prepare a decision with three concrete options: complete coverage before delivery, restrict scope to a supported window or defer entry into service. Conditional acceptance is viable only when conditions are demonstrated and the authorized owner accepts residual risk. Do not hide on-call and maintenance costs to meet the project budget. A useful handover leaves the service, controls and team able to meet the agreed operating commitment.
The technical test passed, but the deputy cannot revoke the credential in rehearsal. Handover keeps that gap open until access is fixed and the procedure repeated.
Common pitfalls
Green console as completed response; training as autonomy; testing only during project hours; budgets excluding operation; removing unevidenced items from the denominator.
Related topics: Handover to RUN · Control effectiveness
Delivery includes the ability to execute and maintain the control. Every acceptance condition needs evidence, ownership and a response to failure.
Reference: The NIST Cybersecurity Framework 2.0 · CISM current outline before November 3, 2026