Buying SOC support: coverage, authority and evidence

State what is missing from today’s service

Start by describing your current support model and the problem you want to solve. You may have no dedicated security team, an internal team that needs additional hours, or a provider whose handoffs need improvement. These situations do not require the same proposal. List the tools and approximate environments already in use, then identify the missing capability: collection, detection design, investigation, coordination or response. Keep replacement as a deliberate procurement choice. Buying another dashboard rarely resolves an ownership gap between the people who already receive the evidence.

Use coverage as a precise term

A proposal should distinguish hours of availability, technology coverage, supported locations and the types of work performed. A person answering a telephone is not necessarily an analyst investigating every signal. Equally, a monitored endpoint population may exclude some servers or cloud accounts. Require a coverage schedule and a statement of exclusions. Describe your desired hours without representing them as an existing supplier commitment. Ask who provides the service, including any delivery partners, and which responsibilities remain with your own team when an event falls outside the agreed boundary.

Agree the authority to act

Separate detection, triage, escalation and containment in the responsibility table. Define who decides whether to suspend an account, isolate a device or change access to an important service. Some decisions may be pre-authorised within specific conditions; others may need a named business owner. Explain how the process works if the primary contact is unavailable. Require an alternative communication route and a record of important decisions. The goal is an executable agreement, not a promise that an external provider can make every business decision during an uncertain incident.

Compare useful evidence rather than alert totals

Ask how the provider demonstrates that agreed sources are healthy, cases are investigated and unresolved issues reach the right owner. Useful measures can include source coverage, missed handoffs, case quality, outstanding decisions and the time between defined process events. Every measure needs a definition and a source. A falling alert count may reflect successful tuning or lost evidence, so it is not a sufficient outcome by itself. Require service reviews to explain changes and exceptions, with actions that have accountable owners and review dates.

Validate the operating model safely

Before accepting the service, use an agreed benign scenario to walk through evidence arrival, triage, escalation and response authorisation. Record where access, context or availability prevents the expected handoff. Technical tests can provide additional evidence, but they need their own authorisation and boundaries. Do not assume a broad monitoring contract permits testing every connected system or supplier. Our guide to co-managed security responsibilities expands the handoffs between an internal team, MSP and security provider.

Technical validation can complement a service programme when it has a separate purpose and authorisation. Our related guides explain network and identity assessment scope and verification of remediation outcomes. Use that work to answer a defined assurance question, then assign the resulting actions to the service owners. These publications are part of the same Atlant Security portfolio.

Ask for a proposal that can be compared

Use the services RFP builder to record your platforms, current support, desired coverage and constraints. It produces a proposed shortlist with reasons, followed by an optional AI-assisted draft for your review. Unknown facts remain questions for the proposal. You can amend the draft and submit it to our team with your NDA or existing RFP. Do not include passwords, detailed production identifiers or confidential incident evidence. The tool does not activate a service or agree contractual terms.