Before signing with a security operations center provider, ask what they will watch, what they may do without calling you, who the analysts are, where your data goes, how they report, and how you leave. Get the answers in the contract, not only on the sales call. This list is vendor neutral and ranks no one.
What is a SOC service?
A security operations center is the team that watches security signals, investigates alerts and coordinates response. Providers sell it as a service, often called managed detection and response, built on tools they or you own. You are buying people, process and tooling together, so ask about all three.
Scope questions
1. Which data sources will you monitor, and which do you ignore? Ask for the list by name: endpoints, identity, email, cloud, network, applications. Anything outside the list is unwatched, however the proposal reads.
2. Do you bring your own tools or use mine? If the provider uses its own agent, ask about conflicts with existing products. If it uses yours, ask who tunes and maintains rules.
3. What coverage hours do you offer? Round the clock, business hours, or a mix? Which time zone are the analysts in during your night?
Response authority questions
4. What actions may you take without asking me? Isolating a laptop, disabling an account, blocking an address. Settle the boundary in writing, with exceptions for critical systems.
5. What is the time to first action, and what is the time to notify me? Ask for targets in the service levels and how breaches of them are handled. Do not accept "as soon as possible."
6. How do you escalate, and to whom? Names and phone numbers, with a backup. Test the path in the first month.
People questions
7. Who will actually look at my alerts? A dedicated small team, or a shared pool? What is analyst turnover like, in general terms?
8. What is your investigation depth? Do analysts confirm and enrich alerts, or forward them with a label?
Data and legal questions
9. Where is my data stored, who can access it and for how long? Ask about retention, deletion at exit and access by the provider's staff and subcontractors.
10. What assurance can you show? Providers may offer independent audit reports. Ask for the report and read its scope, rather than relying on a logo. Do not assume any certification claim; check it at the source.
Reporting and improvement questions
11. What will I see each month? Incidents handled, alerts closed without action and why, tuning changes, coverage gaps. Ask for a sample report with customer details removed.
12. How do you tune detections to my environment? A constructed concern: a build server runs scripts that look suspicious. Who decides it is normal, and how is that recorded?
Exit questions
13. What do I get if I leave? Case history, rules, logs, runbooks. In what format and by when?
14. What are the renewal and termination terms? Look for automatic renewals and notice periods.
How to compare fairly
Send identical questions to each candidate. Ask for a reference conversation with a customer of similar size. Run a tabletop exercise with a shortlisted provider, using a made up incident, and watch how they handle the call. Score responses as demonstrated, claimed or unclear.
A scope note
A SOC watches live activity. Safeguard focuses on the application and software supply chain side, such as dependencies and builds, and does not replace a SOC. Its inventory can help analysts answer which systems use a component when something goes wrong.
What should the first 30 days look like?
A good provider has an onboarding plan, and you should ask to see it before signing. It usually covers connecting data sources, a baseline period where analysts learn what normal looks like, a tuning review, and a joint test of the escalation path.
Hold the provider to that plan with a checklist. Week one: data sources connected and verified, meaning you can see test events arriving. Week two: contact lists confirmed and a test call made out of hours. Week three: first tuning meeting about noisy alerts. Week four: a review of coverage gaps and an agreed list of response actions.
A constructed warning sign: after a month, the provider has closed most alerts as "benign" without notes. Ask for the reasoning behind a sample. Closing alerts quickly is easy; closing them correctly leaves a record that you could read and agree with.
Also decide who inside your company owns the relationship. A SOC contract with no internal owner drifts, and the first serious incident becomes the test of a process no one has read.
What to do
- Decide the sources and hours you need.
- Write the response boundary you are comfortable with.
- Send the questions above in writing.
- Run a tabletop before signing.
- Put service levels, data handling and exit terms into the contract.
Quick check
What is the most important contract clause with a SOC provider?
The one that defines what the provider may do without asking you and how fast, because it decides the outcome of a real incident.
Should I trust an audit logo?
Read the report and its scope. A logo does not tell you whether your data and services are covered.
Sources
This list reflects general procurement practice. No external standard was fetched for it, so check current requirements from your regulator, insurer or auditor.
Last reviewed: 18 October 2026.
