← CISM: manage security, risk, and incidents
14 / 15 · 55 MIN

Operational acceptance of security controls

Prepare evidence that RUN can operate, monitor and recover a security control.

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.

IN PRACTICE

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

Take this idea with you

Delivery includes the ability to execute and maintain the control. Every acceptance condition needs evidence, ownership and a response to failure.

Create account

Reference: The NIST Cybersecurity Framework 2.0 · CISM current outline before November 3, 2026

CISM® is a registered trademark of ISACA. bigsavant.com is an independent preparation platform and is not affiliated with, associated with, sponsored, authorised or endorsed by ISACA. Content and questions are original, are not official exam questions, and completing our tests does not award or guarantee any certification. Names are used only to identify the subject. All other trademarks belong to their respective owners.