Quick context so we start on the same page

• Tell me briefly about your current security team size and who owns day-to-day incident triage Options: No dedicated security staff, 1-2 people, 3-5 people, More than 5 people
• On a typical week, how many security alerts land in your queue across all tools Options: Fewer than 50, 50-250, 250-1,000, More than 1,000, Unsure
• Which teams or roles must be involved before someone can isolate an endpoint or disable an account in your environment Options: IT operations, Application owner, Security lead, CISO or VP IT, OT/production owner, Other
• How soon after a key departure or shift in duties did you notice monitoring or triage coverage drop Options: Immediately (days), Within 1 month, 1-3 months, Longer than 3 months, We have not noticed

Where threats hide in plain sight

• When was the last time an alert turned out to be a confirmed compromise that you did not detect until a downstream failure
• Describe the types of alerts that most often get ignored or filtered out by your team and why
• How many high-priority incidents did your team fully investigate in the last six months Options: None, 1-2, 3-5, 6-12, More than 12, Unsure
• What breaks downstream in operations when an investigation requires taking systems offline
• What single investigation gap would make you halt current operations or escalate to leadership immediately Options: Loss of production visibility, Compromise of domain admin, Ransomware confirmed, OT/PLC compromise, Critical data exfiltration, Other

Where the current setup leaks value and control

• If your central logging and detection tools are producing thousands of events a day, why are true incidents still escaping notice
• In the last 90 days, which log sources produced the most noisy alerts versus the most useful evidence
• Which of these log sources are already sending full logs to a central system Options: Endpoints/EDR, Active Directory and identity, Network devices and firewalls, Cloud workloads and APIs, Email gateway, OT/PLC systems, None of the above
• Who owns log normalization and correlation within your organization Options: Security lead, IT operations, Third-party provider, No single owner, Other
• Would a critical OT segment being unable to forward logs stop a pilot from proceeding Options: Yes, it blocks the pilot, No, we can scope around it, Depends on compensating controls, Unsure

The other options you're weighing and why they look appealing

• What would have to be true about your existing provider or internal team for you to keep them instead of switching
• Which alternatives are you actively evaluating Options: Remain with incumbent managed provider, Build internal SOC, Use alert-forwarding MSSP, Vendor-provided tuning services, Do nothing, Other
• Has anyone on your leadership team proposed solving this internally instead of buying a service Options: Yes, building internal SOC, Yes, increase contractor support, No, external vendor preferred, Unsure
• What deadlines, budgets, or contractual penalties would prevent you from switching providers in the next 60 days
• If a pilot proves faster mean time to contain, what specifically would allow procurement to sign within two weeks

What full protection would look like for operations and finance

• Imagine a service that reduced your time-to-contain by half, what operational difference matters most to your leadership
• Which KPIs will your CFO and IT director use to judge the success of an outsourced detection and response engagement Options: Mean time to contain, Total incidents fully investigated, Onboarding days to full coverage, Cost vs internal build, Business hours disruption incidents, Other
• Select the outcome metrics that matter most Options: Mean time to contain, Alerts investigated per day, False positive rate, Days to onboard full monitoring, Number of custom detections tuned
• Who on your team must sign off that response actions can be executed without prior approval Options: IT director, CISO/security lead, VP operations, Legal/compliance, No single approver
• If we guarantee those KPIs in contract, what internal barrier remains to a full three-year commitment

Can we actually plug in without disrupting production

• Which production systems are off-limits for live investigation or endpoint isolation during business hours Options: Manufacturing control systems/PLC, Inventory systems, Customer-facing systems, Executive endpoints, None are off-limits, Other
• Select the constraints that apply to your environment Options: Maintenance windows only, OT/PLC systems cannot be disturbed, No remote admin to segments, Change board approval required, Data privacy approvals required, None of the above
• Who is the named owner who can approve connector credentials and API access
• Do you have existing agent deployment policies that restrict new software and, if so, what is the typical approval lead time Options: No restrictions, 1-3 business days, 1-2 weeks, More than 2 weeks, Unsure
• If agents cannot be installed on a critical subset of endpoints, would you permit network-based monitoring or would that block the engagement Options: Permit network-based monitoring, That would block the engagement, Allow limited agent deployment after exceptions, Unsure

Ready to test in your environment

• If a 30-day pilot surfaced multiple missed detections, would you be prepared to allow immediate escalation and response by our analysts during the pilot Options: Yes, with pre-agreed playbooks, Yes, with case-by-case approval, No, we require approval before response, Unsure
• Which scope would you want included in a pilot Options: All endpoints, Representative business units, High-risk servers and OT only, Cloud workloads only, Email and identity only
• How quickly can your team provide test accounts, API credentials, and one-week access windows for deployment Options: Immediately, Within 1 week, 1-2 weeks, More than 2 weeks, Not available
• What internal stakeholders must be available during the pilot for tuning and playbook sign-off Options: Security lead, IT operations, Application owners, VP operations, Compliance/legal, Other
• If the pilot meets the agreed detection and containment targets, who has authority to approve moving to full service and on what timeline

What would let you say yes this quarter

• What single contractual guarantee or onboarding promise would make you comfortable signing a three-year service this quarter Options: Response time SLA, Onboarding within agreed days, Right to escalate without extra approvals, Data handling and retention limits, Other
• Which contractual terms are non-negotiable for your legal or procurement teams Options: Response time SLAs, Right to escalate without approvals, Data handling and retention limits, Liability caps, Termination rights, Other
• What budget cycle or approval milestone must align before procurement will sign Options: Current quarter, Next quarter, Next fiscal year, Requires special approval
• If onboarding requires 14 days to full monitoring after contract signature, is that within your target window Options: Yes, No, need faster, No, need longer, Unsure
• Assuming the pilot proves value, what internal objection is most likely to stop procurement from approving the contract

• Solution Experience Session

• Confirm the current state and its cost to your team
• Customer confirms the demonstrated analyst workflow eliminates the backlog of untriaged alerts and reduces time to contain to an acceptable operational level.
• Deliver a proposed 30-day proof-of-value plan with onboarding milestones, resource commitments, and expected timelines to full monitoring.
• Customer confirms the shown detection-to-response actions align with their constraints on production system disruption and escalation rights.
• Run a representative analyst investigation on one of your alerts
• Provide a prioritized list of critical systems, maintenance windows, and named point(s) of contact for deployment and escalation.
• Customer agrees that the identified log sources, visibility gaps, and proposed tuning form an acceptable plan to reach full monitoring during a proof of value.
• Map detection coverage and tuning to your log sources and OT constraints
• Provide sample logs or access details for one representative endpoint, identity provider, and network device to use in the pilot.
• Review response actions, escalation rights, and impact windows
• Produce a tailored detection tuning plan that maps custom rules to your network topology and operational technology constraints.
• Validate the future state with a direct question

• Solution Experience Session
• Solution Experience Deck
• Solution Brief

• meeting
• slides
• document

• Deploy lightweight endpoint agents
• Connect cloud and on‑prem log sources
• Onboard to full 24/7 monitoring
• Dedicated analyst alert monitoring and triage
• Full alert investigation to remediation
• Custom detection rule development and tuning
• Automated and manual endpoint isolation
• Compromised account disablement and recovery
• Threat hunting and IOC sweeps
• Containment and remediation playbook execution
• 30-day proof-of-value monitoring engagement
• Monthly detection updates and operational reporting

Deploy lightweight endpoint agents

• Confirm the total count of endpoints (workstations and servers) to receive the agent Options: Less than 250, 250-1,000, 1,001-5,000, More than 5,000
• Provide the breakdown of operating systems and major versions for endpoints (e.g., Windows Server, Windows 10/11, Linux distributions)
• List any operational technology (OT) devices, programmable logic controllers (PLCs), or manufacturing execution system (MES) hosts where agents are forbidden
• Describe whether local administrator rights are available for agent installation on corporate-owned devices Options: Available centrally, Available for some groups, Not available / require service window
• Specify acceptable rollout windows for agent installation on production systems (e.g., maintenance window hours, weekends) Options: Business hours allowed, After-hours only, Weekend windows only, Specific dates to provide
• Estimate the percentage of endpoints behind restricted network segments or air-gapped environments that will need special deployment methods Options: 0-5%, 6-20%, 21-50%, More than 50%

Connect cloud and on‑prem log sources

• Identify the on-premises servers and appliances that must forward logs (examples: domain controllers, VPN concentrators, perimeter firewalls, file servers)
• Indicate the number of cloud infrastructure accounts or subscriptions to connect for audit logs and workload telemetry Options: 1, 2-3, 4-10, More than 10
• Provide the primary SaaS applications where user and admin activity logs are required (examples: HR system, payroll, CRM, collaboration platform)
• Specify existing log aggregation or Security Information and Event Management (SIEM) configurations we must integrate with Options: Forwarding via syslog, API pulls, Cloud-native logging export, No existing aggregator
• Describe your required minimum log retention window for monitoring and compliance review (days) Options: 30 days, 90 days, 1 year, Custom
• List any network segments, VLANs, or subnets that are out-of-scope for log collection (for example: guest Wi-Fi, OT VLANs)

Onboard to full 24/7 monitoring

• Confirm the target number of calendar days from contract signing to achieve full 24/7 monitoring coverage (this will be used as an acceptance criterion) Options: 7 days, 14 days, 30 days, 60 days
• Provide the named internal owner who will act as our single point of contact for onboarding and access approvals (name and title)
• List systems or business-critical applications that cannot be disrupted during onboarding (for example: production MES, order processing database)
• Specify whether you require a phased onboarding (pilot groups first) or a big-bang rollout to all endpoints and log sources Options: Phased pilot then ramp, Big-bang rollout
• Identify required maintenance windows and blackout dates we must avoid during agent deployment and connector configuration
• State the approvals and artifacts you will provide to validate completed onboarding (examples: connector counts, agent deployment report, baseline alert volume) Options: Agent deployment report, Connector coverage list, Baseline alerts dashboard, Other evidence

Dedicated analyst alert monitoring and triage

• Name the business owner who will approve alert escalation and operational response authorities during incidents
• Describe the analyst coverage model you expect (examples: a single dedicated team per client, limited shared pool, number of analysts per shift) Options: Single dedicated analyst team, Small dedicated team with backups, Shared pooled analysts
• Indicate the hours when you require guaranteed analyst response SLAs for active incidents (examples: 24/7, business hours only) Options: 24/7 response, Business hours only, Business hours with on-call nights/weekends
• Provide any required separation of duties for analysts (for example: split between detection engineering and response actions) Options: No separation required, Separation required — specify in notes
• Identify roles in your organization who should receive elevated incident notifications (examples: IT director, VP operations, on-call engineer)
• Estimate your average acceptable time-to-first-investigation (minutes) for high-severity alerts that require immediate analyst attention Options: 15 minutes, 30 minutes, 60 minutes, Custom

Full alert investigation to remediation

• Specify which remediation actions analysts may take without prior approval (this is a scope acceptance item) Options: Isolate endpoint, Disable user account, Block IP/CIDR, Notify only
• Provide examples of business-critical hosts where containment actions require prior customer approval (examples: production database servers, OT controllers)
• Describe the artifacts you expect after an investigation for handover (examples: timeline of events, IOCs exported, root-cause summary, remediation checklist)
• Indicate required evidence retention for investigation artifacts (forensic images, logs) and any legal hold processes Options: 30 days, 90 days, 1 year, Custom legal hold
• Identify any change control processes we must follow when applying remediation (examples: CAB approval, change ticket number)
• Estimate the typical number of investigative alerts per week that should be escalated to your internal IT team for remediation coordination Options: 0-5, 6-20, 21-50, More than 50

Custom detection rule development and tuning

• Identify the top 3 critical business applications or services whose telemetry requires custom detection tuning (examples: ERP, MES, remote-access gateway)
• Describe known high-noise sources that currently generate false positives we must tune out (examples: backup server activity, antivirus scans)
• Specify required development turnaround for a custom detection rule from request to production testing (days) Options: 2 days, 5 days, 10 days, Custom SLA
• Provide sample log events or a log sample file for the systems that need bespoke detection mapping (for example: application logs, ICS event logs) Options: Attached in portal, Will be provided via secure transfer, Not available
• Indicate whether you require periodic tuning windows where we may adjust thresholds that impact production alerts (examples: weekly tuning, monthly review) Options: Weekly, Bi-weekly, Monthly, Ad-hoc
• State any compliance or industry-specific detection requirements we must implement (examples: NIST control mapping, ISO 27001 detection references)

Automated and manual endpoint isolation

• List the network segments or endpoint groups where automated isolation is permitted (examples: corporate laptops, dev workstations, contractor devices)
• Describe technical constraints on isolation in your environment (examples: air-gapped OT networks, islanded VLANs, jump hosts)
• Provide the expected behavior when an endpoint is isolated (examples: block network egress only, block all network traffic, allow management subnet) Options: Block egress only, Block all traffic except management, Custom configuration specified
• Indicate who in your organization must be notified automatically when isolation occurs (examples: on-call admin, operations manager)
• Specify whether isolation actions require an open change ticket or post-action change documentation for audit purposes Options: Change ticket required, Post-action documentation only, No ticket required for emergencies
• Estimate the percentage of endpoints where isolation could cause unacceptable business impact (for example: payment terminals, manufacturing controllers) Options: 0-5%, 6-20%, 21-50%, More than 50%

Compromised account disablement and recovery

• Identify identity providers and directories to integrate for account disablement (examples: Active Directory (AD), cloud identity service, LDAP)
• Describe your required approval workflow for disabling privileged accounts (for example: manager approval, security lead approval) Options: Immediate disable by analyst, Disable with notification to approver, Disable only after approval
• Provide the expected recovery process after account disablement (examples: temporary unlock by IT, password reset via helpdesk, multi-factor re-enrollment)
• List critical service accounts that must not be disabled without runbook confirmation (examples: backup service accounts, integration service accounts)
• Indicate whether you require automated account disablement for credential-based compromise indicators or manual analyst confirmation first Options: Automated disable on high-fidelity indicator, Manual confirmation required
• Specify any regulatory obligations triggered by account disablement (examples: incident reporting to regulator within X hours)

Threat hunting and IOC sweeps

• Describe the cadence you want for proactive threat hunts (examples: weekly focused hunt, monthly enterprise sweep) Options: Weekly, Bi-weekly, Monthly, Quarterly
• Identify high-value assets or IP ranges that must be prioritized during hunting (examples: SCADA controllers, financial systems, executive endpoints)
• Provide known IOCs (indicators of compromise) or historical incident artifacts we should include in initial sweeps Options: Attached via portal, Will provide on request, None available
• Specify whether hunts should include cloud workload memory and disk artifact analysis or be limited to log-based IOC sweeps Options: Include memory/disk artifacts, Log-based IOC sweeps only, Hybrid approach
• Indicate required reporting from hunting activities (examples: hunt findings dashboard, executive summary, IOC package for SIEM import) Options: Executive summary only, Dashboard and IOC package, Detailed forensic report
• Estimate acceptable elapsed time to complete a focused hunt across your environment (days) Options: 1 day, 3 days, 7 days, Custom SLA

Containment and remediation playbook execution

• Attach or summarize existing incident response playbooks we must map to (examples: ransomware playbook, data exfiltration playbook) Options: Playbooks attached, Will provide during onboarding, No existing playbooks
• Identify the decision authority for invoking a containment playbook (examples: security lead, IT director, operations manager)
• Detail any environment-specific remediation steps that must be included (examples: vendor notification, production rollback, OT safe-shutdown procedures)
• Indicate if there are automation constraints on playbook actions (examples: automation disabled in production, require manual approval before executing scripts) Options: Automation allowed, Automation with approval, No automation in production
• Specify the metrics you require to measure playbook effectiveness (examples: mean time to contain, number of endpoints remediated, business downtime hours)
• Name any third-party responders or managed service teams we must coordinate with during playbook execution (examples: incident response retainer, CERT), if applicable

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

• Subscription Agreement / Order Form
• Master Services Agreement (MSA)
• Statement of Work (Onboarding & Tuning)
• Proof-of-Value Pilot Agreement (30 days)
• Service Level Agreement (SLA) - Response Guarantees & Metrics
• Data Processing Agreement (DPA)
• Active Response Authorization & Escalation Rights
• Onboarding Acceptance & Handover Certificate
• Change Order Agreement
• Operational Technology (OT) Deployment Addendum (conditional)

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

• Schedule any required tuning windows or connector rollouts to address backlog items in the next 60 days.
• Restate acceptance criteria and numeric targets
• Produce a documented pass or fail decision for each numeric acceptance criterion recorded in Proof of Value.
• If any criteria fail, capture a concrete remediation plan with dates for re-evaluation.
• Verify the incumbent monitoring system is decommissioned or formally retained-read-only and that data retention steps are complete.
• Publish the acceptance decision and remediation plan with named signatory detail where required.
• Decommission the incumbent system or document the retained-read-only plan and confirm archive completion.
• Schedule the remediation verification session and metric re-check date if any criteria failed.
• Trend review for core metrics
• Confirm the service continues to meet or improve toward mean time to contain and investigation closure-rate targets recorded in Proof of Value.
• Maintain a prioritized backlog with target dates for the top 5 operational or enhancement items.
• Identify any systemic operational blockers and agree process changes or timelines to resolve them.
• Update and publish the shared backlog with priorities and target completion dates for the next quarter.
• Deliver a monthly metric snapshot showing mean time to contain and investigation closure counts for internal review.
• Re-confirm success criteria and owners
• Confirm agents and connectors are active against the deployment plan and critical log sources are sending data.
• Name owners for each open blocker and agree remediation actions and target dates for initial fixes.
• Agree the date and data scope for the first measurement meeting.
• Publish deployment health summary showing agent coverage and connector status for critical systems.
• Schedule the first tuning window to address the top 3 signal gaps identified during this session.
• Document maintenance and OT constraints that restrict investigative actions and circulate for confirmation.
• Present first-period results
• Determine whether mean time to contain and agent coverage are trending toward targets recorded in Proof of Value.
• Agree a prioritized corrective action list with completion dates to address the top metric gaps.
• Confirm the expected date for the acceptance gate based on correction progress.
• Run and deliver an agent coverage verification report, including remediation plan for offline or unsupported endpoints.
• Implement prioritized detection tuning changes to reduce false positives and record the change log.
• Update the shared metric dashboard with daily refresh and alert thresholds for the acceptance gate.
• Deployment and integration validation
• Backlog review and prioritization
• Root-cause analysis for any gaps
• Present outcome data against each criterion
• Agree corrective actions and timelines
• Document pass/fail per criterion and formal acceptance decision
• Operational blockers and process improvements
• Early adoption and usage signals
• Confirm trajectory to the acceptance gate
• Open blockers and risk items
• Incumbent system wind-down
• Outstanding remediation status
• Agree remediation items and resolution timeline
• Agree immediate remediation actions