↑

Top 10 Questions to Ask a Managed SOC Provider Before You Sign

Before you sign a managed SOC contract, ask for evidence of what happens when an incident starts. These 10 questions turn provider promises into testable commitments.
An analyst organises incident evidence beside a clock and a clear response handoff path.

Managed SOC procurement checklist. Last reviewed:

A managed security operations centre (SOC) proposal can promise continuous monitoring while leaving difficult decisions with your team. Before signing, establish what the provider will observe, investigate and do, and what your organisation must supply.

These ten questions are an editorial procurement checklist, rather than a provider ranking. Use them in finalist interviews and record the answers in the service schedule. For the broader sourcing process, see CYBORIUM’s managed SOC evaluation guide and MDR provider evaluation guide.

1. Which systems will you monitor on the first day of service?

Ask the provider to mark each required system as included, awaiting integration or excluded. Cover identity, endpoints, email, cloud workloads, network devices and business applications. A product connector in a catalogue does not establish that your configuration supplies the events an analyst needs.

Request a log-source register with an owner, integration method, expected event types and acceptance test for each source. Include how the provider detects a silent connector. ASD’s event logging guidance recommends prioritising valuable logs and centralising them for investigation.

A warning sign is a single statement that all supported sources are covered, with onboarding details deferred until after signature.

2. Who investigates an alert outside Australian business hours?

Have the provider describe a shift covering your actual operating hours, including weekends and public holidays. Establish whether an analyst investigates alerts immediately, whether specialist support is on call, and which activities move to the next business day. Ask how work passes between locations.

Request the staffing model, escalation roster and an anonymised handover record. Have the proposed service team explain how it would handle simultaneous incidents across customers. Names may change; the contracted roles and coverage should remain clear.

A warning sign is an answer about automated monitoring when you asked about human investigation. Record any dependency on your own overnight availability in the responsibility schedule.

3. What can you contain without waiting for our approval?

Walk through actions such as isolating an endpoint, disabling an account or blocking an indicator. Decide which actions need approval and which can proceed under agreed conditions. Consider operational disruption as well as security urgency, particularly for production systems and privileged identities.

Request an action-by-action authority matrix, approval contacts, fallback contacts and reversal steps. Ask the provider to show how the relevant permissions are tested during onboarding. A proposed containment action should identify both the technical operator and the business decision owner.

A warning sign is a broad promise to respond when the contract only commits to emailing an alert. Resolve that gap before comparing service prices.

4. When does each service-level clock start and stop?

A fast acknowledgement says little about when investigation or containment begins. Separate event arrival, alert creation, analyst assessment, customer notification and containment. Specify how severity changes affect the clock and who can authorise a pause.

Request a sample incident timeline with timestamps for these stages, plus the corresponding service-level definitions. Ask whether reports show individual breaches as well as averages. Agree how missing telemetry and customer approval delays are recorded so the same delay cannot disappear between two teams.

A warning sign is one response-time figure with an undefined start point. A provider that cannot explain the measurement cannot give procurement a reliable basis for comparison.

5. How will you prove our detection coverage works?

Ask for detection use cases tied to your systems and plausible attack paths. An identity compromise, suspicious mailbox change and unusual administrator activity need different evidence. Agree what the service should recognise and how that expectation will be tested.

Request an agreed test plan, a redacted test result and the process for fixing a failed detection. Distinguish routine rule updates from engineering work that attracts an additional fee. Schedule tests after material system changes as well as at onboarding, using activities authorised by your team.

A warning sign is a large rule count presented as proof of coverage. Ask instead for the result of a relevant test and the investigation record it produced.

6. What happens when an alert becomes a major incident?

Identify where the SOC service ends and incident response, forensics or recovery services begin. Confirm who leads the response, who preserves evidence, and who coordinates with your IT operations team. Establish how specialist responders become available and what that costs.

Request a joint incident playbook and a tabletop exercise before service acceptance. NIST SP 800-61 Rev. 3 places incident response within wider cybersecurity risk management. Your purchasing decision should connect detection to preparation and recovery. CYBORIUM’s incident response and recovery services guide covers this adjacent scope.

A warning sign is an emergency process that depends on negotiating a new statement of work while an incident is underway.

7. Where will our data and privileged access go?

Ask separately about log storage, backups, support access, analyst locations and subcontractors. An Australian storage region does not answer who can view the data or administer the platform. Identify what sensitive information your logs may contain before agreeing access.

Request a data-flow diagram, subcontractor list and privileged-access design. ASD’s procurement and outsourcing guidance addresses supplier jurisdiction and the protection of data entrusted to providers and subcontractors. Apply the requirements relevant to your organisation through a documented assessment.

A warning sign is a general assurance about local service delivery without a written account of remote access and subcontracting.

8. How is the provider’s own access monitored?

The SOC provider becomes part of your security supply chain. Establish how its accounts are issued, approved, reviewed and removed. Ask what happens if its own administrative environment is compromised and how your organisation will be notified.

Request evidence of multifactor authentication, restricted privileges, account reviews and auditable access records. The joint advisory on MSP security recommends MFA for provider accounts, least privilege and clear contractual responsibility. Ask for the scope and exceptions behind any assurance report offered.

A warning sign is a shared administrator account or a refusal to explain access controls. A certification logo alone does not describe the controls protecting your tenancy.

9. What changes the price over the full contract term?

Give finalists the same assumptions for endpoints, users, log ingestion, retention and growth. Include the cost of onboarding, platform licences, integration maintenance, extra investigations and exit assistance. Establish whether a major incident consumes a separate allowance.

Request a completed pricing workbook and a worked invoice for your expected usage and a higher-volume scenario. Identify caps, minimum commitments, indexation, renewal notice dates and approval rules for additional charges. Your finance team should be able to reproduce the calculation without interpreting a sales presentation.

A warning sign is a low monthly total supported by different volume assumptions from competing proposals. Normalise those assumptions before deciding which offer provides better value.

10. Can we leave with usable records and continuous coverage?

Agree ownership and export rights for logs, case histories, detection configurations and investigation evidence. Ask which formats are available, what extraction costs, and how long access remains available after notice. Plan the overlap with a replacement provider before scheduling disconnection.

Request a sample export, transition schedule and deletion process. ASD’s outsourcing guidance recommends addressing data protection after termination and planning transfers between services. Include the provider’s obligations in your exit schedule, alongside revocation of accounts and credentials.

A warning sign is an assurance that you own the data without a practical way to retrieve it. Test a small export before committing to a long contract.

A short checklist for the signing meeting

For each answer, record the evidence reviewed, the contract reference, the person accountable and any unresolved gap. Carry these items into the final review:

  • An accepted monitoring scope with integration tests.
  • Named operational roles and agreed containment authority.
  • Measurable service levels and a joint incident exercise.
  • A complete pricing model and a tested export.

Use CYBORIUM’s information security in procurement guide to connect these checks to your wider supplier assessment. If the finalist proposals still leave different responsibilities or costs on your side, contact CYBORIUM for help making the offers comparable before you sign.

Share this analysis