Quick context: your monitoring snapshot

• Tell me briefly how your security monitoring is currently staffed and covered, including any 24/7 expectations.
• Which types of telemetry do you already forward to a centralized system? Options: Endpoints (EDR), Network flow and perimeter logs, Cloud workload telemetry, Identity and access logs, Application logs, Vulnerability scanner output, None of the above / ad hoc
• When was the last time a board or audit requested documented evidence of continuous monitoring from your team? Options: Within the last month, 1-3 months ago, 3-12 months ago, More than 12 months ago, Never
• Who on your team currently owns day-to-day incident escalation and executive notification? Options: Security operations manager, CISO or head of security, IT operations lead, DevOps lead, Shared responsibility across teams, No designated owner
• Estimate how many security alerts your team receives on an average business day, across all tools. Options: Fewer than 50, 50 to 200, 200 to 1,000, More than 1,000, Unsure
• Describe a recent incident that revealed a visibility gap in your environment and what first tipped you off.

Where the hidden risks live in your environment

• If an adversary were already inside your environment, which asset or system would they touch first and why?
• List the systems or data stores you consider most critical to business continuity and why each is critical.
• Which monitoring gap, if left unaddressed, would most likely create regulatory exposure or invalidate insurance requirements? Options: Identity/privilege monitoring, Cloud configuration drift, Endpoint telemetry gaps, Network segmentation blind spots, Inadequate logging retention, Other
• How often do you discover suspicious activity that you cannot trace to an existing detection rule or known log source? Options: Weekly, Monthly, Quarterly, Rarely, Unsure
• Is there any asset, environment, or data class you will not allow external monitoring or log export for, and would that restriction stop the engagement? Options: Yes, and it would block the engagement, Yes, but we can use an internal proxy/filtered export, No hard restrictions, Unsure

How alerts actually land in your SOC

• What single kind of alert or signature currently causes your team to ignore notifications instead of investigating them?
• How many distinct alerting tools or sources contribute to noise in a typical week? Options: 1-2 sources, 3-5 sources, 6-10 sources, More than 10, Unsure
• Walk me through the last incident your team escalated, who investigated it, and how long the handoff took from detection to containment action.
• Point out the process or tool failure that causes the most false positives in your environment.
• On a scale from 1 to 5, how confident are you that your team detects critical threats under 15 minutes today? Options: 1 - Not confident, 2 - Slightly confident, 3 - Moderately confident, 4 - Mostly confident, 5 - Very confident
• If the managed detection approach cannot reduce false positives by at least 50% versus out-of-box rules, would you still proceed with a proof-of-value? Options: Proceed anyway, Proceed only with strict scope limits, Decline and reassess options, Unsure

Who needs to act and what they must approve

• Name the role that must approve the seller acting on your behalf during an incident and describe any constraints on that approval.
• Who are the internal stakeholders you expect to be looped into incident updates, and which channels do they prefer? Options: Security leadership email, Pager or phone call, Ticketing system, Weekly executive summaries, Slack/MS Teams channel, Other
• Walk me through your current escalation pathway for high-severity incidents, from initial detection to executive notification.
• Do you have a contractual or regulatory requirement for data residency or investigator jurisdiction that would change how incidents are handled? Options: Yes, strict restrictions, Yes, some restrictions, No requirements, Unsure
• What would stop your security leader from authorizing external incident response coordination, and is that a hard blocker or negotiable? Options: Hard blocker, Negotiable with approvals, Not relevant, authorization is expected, Unsure

The other paths you may choose and why

• Under what conditions would you choose to stay with your current monitoring provider rather than change?
• Has anyone proposed building a 24/7 capability internally instead of buying a service, and who championed that option? Options: Yes, security leadership, Yes, IT/operations, No one has proposed internal build, Unsure
• List the external vendors or solution types you have shortlisted or are currently evaluating, including any incumbent you may keep.
• Would retaining the incumbent be acceptable if they matched your desired detection quality and contractual terms? Options: Yes, Only temporarily, No, looking for change regardless, Unsure
• Name the single proof-of-value result that would let you sign within two weeks of a successful trial.

Can we actually turn on your telemetry and meet timelines

• Identify any critical log sources that cannot be shared or integrated within four weeks, and explain why.
• Do your security and IT teams have a documented owner for each integration point, and can we get their contact for scheduling? Options: Yes, owners documented and available, Owners documented but not immediately available, No documented owners, Unsure
• Are any APIs or collection endpoints gated by scheduled change windows or third-party vendor approvals we should plan around? Options: Yes, strict windows, Yes, with flexible windows, No gating, Unsure
• Estimate the number of full time engineers or analysts you can realistically assign to onboarding and tuning in the first 60 days. Options: None, 1, 2-3, 4-6, More than 6
• Is there any compliance, legal review, or procurement approval that must finish before we can access logs, and what is the usual timeline? Options: Yes, >8 weeks, Yes, 4-8 weeks, Yes, <4 weeks, No formal approvals required, Unsure
• Would your policy forbidding direct admin access to a collector block the project, or can an approved intermediary or proxy be used? Options: Block the project, Use approved intermediary, Workaround with filtered export, Unsure

How we'll measure success during a proof-of-value

• State the measurable reduction in mean time to detect or in false positives that would convince you the service is working.
• Select the KPIs you will require in the pilot report. Options: Mean time to detect (MTTD), Mean time to respond (MTTR), False positive rate, True positive validation rate, Number of high-confidence incidents, Time to containment, Quality of incident reports
• Describe the process you will use to verify alert accuracy during the trial, who will sign off, and what evidence will suffice.
• State the escalation SLA for confirmed critical incidents you require during the pilot to continue to a managed service contract. Options: 15 minutes or less, 30 minutes, 1 hour, Same business day, Other
• In the event the pilot shows mean time to detect above your target, will you cancel the trial, extend it, or require corrective milestones, and who makes that call? Options: Cancel the trial, Extend the trial with conditions, Require corrective milestones then decide, Security leadership will decide case-by-case
• Choose the acceptance threshold for false positives you'd consider acceptable after tuning. Options: Less than 10%, 10-25%, 25-50%, More than 50%, No hard threshold, need qualitative review

Decision pace, roadblocks, and next steps

• Identify the single internal approval or resource gap that would block signing even after a successful pilot.
• When is your next budget window for this kind of security spend? Options: Immediately, This quarter, Next quarter, Next fiscal year, Ad hoc / case-by-case
• Please list the person or team responsible for drafting and approving the contract, and any standard contract clauses that typically cause delay.
• Outline your fallback timing or alternative funding path if the budget is not approved this quarter.
• Select one: proceed to a 30-day proof-of-value, delay for internal preparation, or do not move forward at this time. Options: Proceed to 30-day proof-of-value, Delay for internal preparation, Do not move forward
• Choose the stakeholders to invite to the pilot kickoff. Options: CISO or security sponsor, Security operations lead, IT operations/engineer, Cloud platform owner, Compliance or legal, Procurement, Executive sponsor

• Detection & Response Experience

• Confirm the current state and its cost
• You confirm the demonstrated detection and response workflows eliminate the noisy alerts and detection gaps you described.
• Provide sample logs and a diagram of the monitored estate for the two agreed scenarios before the PoV kickoff.
• You accept the proposed success criteria for a 30-day proof of value, including target mean time to detect and false positive reduction targets.
• Agree the priority threat scenarios to test
• Approve the two representative scenarios and the PoV success criteria during this session.
• Run Scenario 1, detection path and timelines
• You agree on the two priority scenarios and the list of sample logs or telemetry needed to run them during the PoV.
• Seller to run a simulated detection exercise using the provided sample logs and deliver an annotated incident timeline before PoV kickoff.
• Run Scenario 2, investigation and response orchestration
• Seller to deliver a proposed PoV timeline and the exact data access checklist within two business days after this meeting.
• Show how per-client tuning reduces false positives
• Designate an internal incident responder and escalation contact for PoV handoffs and confirm their availability for tuning reviews.
• Validate outcomes with the buying team
• Agree next steps for a 30-day proof of value

• Detection & Response Experience
• Detection & Response Experience Deck
• Detection & Response Solution Brief

• meeting
• slides
• document

• Integrate Log and Telemetry Sources
• Deploy and Manage Endpoint Detection Agents
• Configure SIEM Correlation Rules and Parsers
• Client-Specific Detection Rule Tuning
• 24/7 Security Monitoring and Alert Triage
• Threat Hunting and Anomaly Investigation
• Validated Incident Response and Containment Coordination
• Endpoint Containment and Remediation Execution
• Forensic Evidence Collection and Case Packaging
• Vulnerability Scanning and Prioritization
• Cloud Workload and Identity Monitoring
• Integrate Threat Intelligence Sources
• Alert Context Enrichment and Recommended Actions
• Log Retention, Indexing, and Secure Storage

Integrate Log and Telemetry Sources

• Which on-premise log sources should we ingest first (examples: Windows Security event logs, Active Directory domain controllers, perimeter firewall logs)?
• How many cloud accounts or subscriptions produce audit logs to ingest (examples: cloud provider audit trail, object storage access logs)? Options: 1, 2-5, 6-20, More than 20
• Which network telemetry streams do you have available for collection (examples: NetFlow/IPFIX, packet capture on critical segments, perimeter IPS alerts)? Options: NetFlow/IPFIX, Packet capture, Perimeter IDS/IPS alerts, None of the above
• Who owns access to each log source you listed and can provide credentials or a collection endpoint for onboarding?
• Which log formats do your systems emit that will require custom parsing (examples: custom JSON, syslog RFC5424, Windows event XML, application-specific CSV)?
• Are there any contractual or regulatory restrictions on shipping logs offsite (examples: PCI scope, HIPAA ePHI, GDPR transfer restrictions)? Options: Yes, No

Deploy and Manage Endpoint Detection Agents

• Which endpoint operating systems and versions need agent coverage (examples: Windows Server 2016+, Windows 10/11, RHEL 7/8, macOS 10.15+)?
• How many endpoints are in scope for initial rollout by device class (examples: workstations, servers, laptops, privileged jump hosts)? Options: Less than 250, 250-1,000, 1,001-5,000, More than 5,000
• Which existing endpoint security agents or endpoint management tools could conflict with new agent deployment and require a coexistence plan?
• Who on your team will approve agent-side changes and host maintenance windows for agent installation?
• Do you require phased deployment by business unit or a single cutover window for agent rollout? Options: Phased by BU, Single cutover window, Pilot then phased rollout
• Which telemetry from endpoints is mandatory to forward for detection tuning (examples: process start/stop, command line, loaded modules, network connections)?

Configure SIEM Correlation Rules and Parsers

• Which SIEM index names or index patterns should ingested logs map into for your retention and query model?
• How many custom parsers will be required for proprietary applications that emit nonstandard logs? Options: 0, 1-5, 6-20, More than 20
• Which sample log files can you provide for parser development and field mapping (examples: 7 days of Windows event logs, webserver access logs, application debug logs)?
• Who will be the technical reviewer for parser outputs and field mappings during acceptance testing?
• Which correlation use cases are priorities to implement in the SIEM (examples: credential dumping chained to lateral movement, ransomware file encryption patterns, exfiltration over nonstandard ports)?
• Are there existing SIEM parsers or data dictionaries we must preserve or map to during migration? Options: Yes, No

Client-Specific Detection Rule Tuning

• Which of your business-critical applications or services should receive priority rule tuning (examples: payroll database, customer portal, remote access gateway)?
• How many bespoke detection rules do you estimate will be needed to cover environment-specific behaviors? Options: 0-10, 11-25, 26-50, More than 50
• Which known benign behaviors must be whitelisted to reduce false positives (examples: nightly backup account logins, scheduled automated deployer processes, vulnerability scanning service accounts)?
• Who will authorize changes to tuned detection rules and sign off on reduced alert volumes during tuning windows?
• Which MITRE ATTACK tactics or techniques should be mapped to your custom rules for reporting and coverage dashboards?
• Do you have a target reduction in alert volume or false positive rate we should use as a tuning objective (example targets: reduce noisy alerts by 80 percent, achieve fewer than 10 false positives per week for high severity detections)? Options: Yes, specify in next answer, No target, rely on our recommendations

24/7 Security Monitoring and Alert Triage

• Which severity levels must be covered 24/7 with an on-call analyst and which may be handled during business hours (examples: Critical, High, Medium, Low)? Options: Critical and High 24/7; Medium/Low business hours, All severities 24/7, Only Critical 24/7
• Who is the primary contact for triage escalations during after-hours and what are their contact methods for incident handoff?
• Which ticketing project or queue in your ITSM ticketing system should we create triage tickets in and what required fields must be populated?
• How many alerts per day from your environment are tolerable without triggering an SLA escalation during the tuning period? Options: Less than 10, 10-50, 51-200, More than 200
• What acceptance criteria will validate that 24/7 monitoring and triage meet our agreement for mean time to detect and triage (examples: MTTD under 15 minutes for Critical, acknowledged ticket within 30 minutes)?
• Which evidence artifacts should be attached to triage tickets to speed analyst decisions (examples: process command line, binary hash, network connection summary, relevant log excerpt)?

Threat Hunting and Anomaly Investigation

• Which periodic threat hunting campaigns do you want included (examples: quarterly credential misuse sweep, monthly lateral movement hunting, targeted hunt for ransomware indicators)?
• Which data retention window is required to support hunts that look back for 90 days or longer? Options: 30 days, 90 days, 180 days, More than 1 year
• Who will approve high-impact hunt actions such as host quarantines or temporary credential resets discovered during an investigation?
• Which anomaly signals are most valuable to you for proactive hunting (examples: unusual admin logins from new geolocations, mass file read operations, suspicious PowerShell child processes)?
• Which MITRE ATTACK techniques should hunts prioritize based on recent threats to your industry?
• Would you like hunting results packaged as a quarterly threat posture report with IOC lists and recommended mitigations? Options: Yes, No

Validated Incident Response and Containment Coordination

• Which incident severity definitions will we use to trigger coordinated response (examples: Data exfiltration confirmed, ransomware encryption in production, confirmed privileged credential compromise)?
• Who are the authorized incident decision makers for containment actions and executive notifications?
• Which communication channels and escalation trees must be used during an active incident (examples: secure conference bridge, encrypted messaging channel, executive notification list)?
• What acceptance criteria will confirm validated incident response and containment coordination is successful (examples: containment initiated within X minutes of validation, documented runbook executed with signoffs)?
• Which runbook documents or playbook artifacts can you provide to align our containment steps with your internal processes?
• Will we have permission to execute containment actions on critical hosts automatically or must every action be manually approved during incidents? Options: Allow automated containment for Critical incidents, Require manual approval for all containment actions, Allow automated containment with pre-approved list of hosts

Endpoint Containment and Remediation Execution

• Which containment actions are authorized for us to perform on endpoints (examples: network isolation, process kill, user session termination, quarantine file)?
• Which rollback or remediation verification steps must occur after containment (examples: AV scan, integrity check, user credential reset, rebuild from golden image)?
• Which change windows, if any, restrict containment or remediation on production servers?
• Who will approve escalation to rebuild or reimage an endpoint discovered as compromised?
• Do you require containment actions to generate a post-remediation evidence package for your internal forensics team? Options: Yes, No
• Which sandbox or malware analysis environment should we submit suspected binaries to for deeper analysis if needed?

Forensic Evidence Collection and Case Packaging

• Which forensic artifacts are required as part of a case package (examples: full disk image, memory dump, relevant log slices, file metadata and hashes)?
• Who will approve legal hold and chain-of-custody preservation when evidence must be retained for legal review?
• Which file export formats do you require for evidence delivery (examples: E01, raw dd, compressed JSON event export)? Options: E01, Raw dd, Compressed JSON log export, Other
• Within what timeline do you need a first-case package delivered after containment (examples: 24 hours, 48 hours, 7 days)? Options: 24 hours, 48 hours, 7 days
• Which internal teams must be copied on forensic deliverables and case summaries (examples: legal, compliance, HR, executive leadership)?
• Do you require evidence storage under a separate retention policy for potential regulatory review? Options: Yes, No

Vulnerability Scanning and Prioritization

• Which asset groups should be included in authenticated vulnerability scans (examples: production databases, internal web applications, internet-facing servers)?
• How often do you want vulnerability scans run for each asset class (examples: weekly, monthly, quarterly)? Options: Weekly, Monthly, Quarterly, On demand
• Which credential types can be provided to enable authenticated scanning (examples: service account with read privileges, SSH key, domain account)?
• Which prioritization criteria should be used to rank vulnerabilities for remediation (examples: internet exposure, CVSS score above 7, known exploit in the wild, asset business criticality)?
• Do you require vulnerability scan findings to automatically open tickets in your ITSM ticketing system with remediation owners assigned? Options: Yes, No
• Which SLA for vulnerability remediation do you target for critical CVEs after ticket creation (examples: 7 days, 14 days, 30 days)? Options: 7 days, 14 days, 30 days, Custom

• current_state
• decision_readiness
• desired_state
• stakeholders
• gaps
• success_criteria
• stakeholders
• decision_readiness
• current_state
• desired_state
• success_criteria
• gaps
• gaps
• success_criteria
• decision_readiness
• current_state
• decision_readiness
• decision_readiness
• decision_readiness
• decision_readiness

• Master Services Agreement (MSA)
• Statement of Work (SOW)
• Service Level Agreement (SLA)
• Order Form / Subscription Agreement
• Data Processing Agreement (DPA)
• Operational Escalation & Incident Handoff Agreement
• Data Access & Onboarding Authorization
• Change Order Agreement
• Termination & Transition Agreement
• Regulatory Compliance Addendum (conditional)

• Go-live Health Check (weeks 1-4)
• First Measurement Review (weeks 4-10)
• Acceptance Gate Review (around day 90)
• Quarterly Operational Review

• Deliver a quarterly performance summary that includes metric trends, incident highlights, and action status before the next review.
• Prepare a packet of evidence for the acceptance gate, including alert samples, incident reports, and metric dashboards.
• Restate acceptance criteria and numeric targets
• Produce a documented pass/fail decision for each acceptance criterion recorded in the Solution Scope.
• If any criteria failed, agree a remediation plan with owners, dates, and a short verification test to confirm compliance.
• Capture at least three specific lessons learned that will be added to the shared backlog and runbooks.
• Publish the acceptance decision document, including pass/fail results and the named buyer owner, within 48 hours.
• Create remediation tickets for any failed criteria with owners and target resolution dates, and add them to the shared backlog.
• Update incident response playbooks and the stabilization checklist based on lessons learned captured in the meeting.
• Trend review of detection metrics
• Confirm whether false positive rate (%) and mean time to detect for critical threats (minutes) remain within acceptable variance of targets recorded in the Solution Scope.
• Prioritize the shared backlog so the top items are specific with owners and target dates for the next quarter.
• Resolve or reassign any persistent operational issues that threaten SLA adherence or detection quality.
• Publish the prioritized backlog with owners and target completion dates within five business days.
• Schedule targeted tuning sprints for the top two detection rules or telemetry gaps identified in the review.
• Re-confirm success criteria and owners
• Confirm that all planned integrations are active or have owners and clear remediation dates.
• Document and assign owners to any blockers that would prevent meaningful KPI measurement at the first measurement review.
• Agree a timeline for any outstanding onboarding tasks that must complete before day 30.
• Publish the deployment validation checklist with status and owners within 48 hours.
• List and assign remediation tasks for any failed connectors, with target completion dates within two weeks.
• Collect the first 14 days of ingestion logs and analyst workflow notes for the first measurement review.
• Implement the agreed detection tuning changes and document the rule revisions and expected impact.
• Present first measurement data against targets
• Determine whether the false positive rate (%) and mean time to detect for critical threats (minutes) are moving toward the targets recorded in the Solution Scope.
• Agree a prioritized list of corrective actions with owners and firm completion dates before the acceptance gate.
• Confirm data and evidence that will be presented at the acceptance gate to support a pass/fail decision.
• Onboard any missing telemetry sources identified in the root-cause analysis and report ingestion status within two weeks.
• Diagnose gaps and root causes
• Incident and response performance
• Present outcome data for each acceptance criterion
• Deployment and integration validation
• Early adoption signals and usage patterns
• Agree corrective actions and timelines
• Shared backlog and enhancement requests
• Document pass/fail per criterion and acceptance decision
• Confirm readiness timeline for Acceptance Gate
• Blockers and open issues triage
• Agree remediation plan for any failed criteria
• Persistent issues and escalation review
• Confirm next quarter commitments and meeting cadence
• Capture lessons learned for handoff
• Agree immediate remediation actions