Cybersecurity buying research
“24/7” is a starting question, not a complete response arrangement. Establish which actions the provider may take, which require approval, and what happens when the primary approver is unavailable.
Begin with one consequential decision
Use this fictional question in the renewal meeting: an endpoint appears to require isolation outside normal working hours, and the usual IT lead is unavailable. Who can decide, who can execute, and which document establishes that authority? Keep the scenario deliberately bounded. You are checking responsibility, not assessing whether a real event is malicious or authorising a technical action.
Ask each participant to describe the handoff in ordinary language. If the answer depends on an unnamed person, an assumed permission or a separate paid service, record that dependency. A useful result is a precise unanswered question, not a green status produced by a vague promise.
Walk six stages without skipping approval
Separate detection, investigation, notification, approval, containment and recovery. For every stage, identify the accountable role, the information needed to proceed, the expected communication channel and the supporting clause. This makes it harder for an offer to appear complete because several different activities have been grouped under “response”.
The stages are a document-review structure, not a claim that all incidents unfold in a linear sequence. Actions may overlap and circumstances may change. What matters for procurement is whether the proposed operating arrangement makes decision rights and dependencies explicit enough for the relevant teams to review.
Document the approval boundary
Ask whether permission is pre-authorised, incident-specific or restricted by environment. If it is pre-authorised, locate the conditions and exclusions. If each action needs customer approval, locate the primary and alternate approvers and the process when neither can be reached. Avoid prescribing a universal approval model; the right boundary depends on business consequences and agreed safeguards.
Then ask who owns restoration and rollback after a permitted action. Containing a device and returning a critical service to use are different decisions. The provider, internal IT team, business owner and any specialist responder may have different responsibilities. Document these differences before assuming the managed service includes end-to-end recovery.
Test the wording with a tabletop
Arrange a discussion using role names and synthetic details. Invite the operational owner, alternate approver and supplier contact to explain what each would do using the agreed documents. Do not create live alerts, alter permissions or isolate equipment. If a participant needs information that is not available, capture the missing dependency and assign a follow-up owner.
The exercise is successful when it improves the decision schedule. An unresolved point may require a contract clarification, a contact change, an internal delegation or a different service. Do not describe completion of this discussion as a readiness certification or proof that the arrangement will perform under pressure.
Leave with five written answers
Request a concise confirmation of who investigates overnight, who may approve containment, who executes the authorised action, which systems or actions are excluded, and who owns recovery. Attach the relevant references and carry the unanswered items into your renewal decision queue. Keep the distinction between a documented commitment and an operationally tested process.
NIST’s incident-response publication places response within broader cybersecurity risk management. This checklist translates the supplied buying brief into a narrower commercial review. It does not replace incident procedures, technical assessment or advice from the people responsible for your environment.
Your buyer’s checklist
Turn this into a decision briefSources and assessment boundaries
Demonstration buying questions only. The checklist does not determine technical readiness, interpret law, or authorise containment. For an active incident, use established response arrangements.
Guide prepared 23 October 2026. Source publication and verification details are shown below; this date is not a supplier verification date.
Published 3 April 2025. Background on incorporating response into cybersecurity risk management; does not verify any service or contract.
Advisory AA22-131A, dated 11 May 2022. Located in official-site search on 23 October 2026; direct PDF retrieval was unavailable. Background only, not a supplier evaluation.