AD6.6 Coordinating with Your Managed SOC

Pre-incident setup

Establish these coordination items with your managed SOC BEFORE the first incident — not during one:

Escalation contact. Get the specific escalation email, phone number, and ticket portal URL. Test the escalation channel: send a test email to verify it reaches the right team. Store these contacts in your escalation contact sheet (AD5.10).

Shared incident reference. Agree on using the Defender portal incident ID as the shared reference number. When you escalate, include the incident ID so the SOC can pull up the same incident in their portal view. "Incident ID 12345 — confirmed credential compromise for r.williams" gives them everything they need to start investigating.

Response SLAs. Know your SOC's response times: Critical/High severity — typically 15-30 minutes to first response. Medium — typically 1-4 hours. Understand what "first response" means — it's usually acknowledgment and initial triage, not full investigation and containment.

Shared portal access. Confirm that the managed SOC has read access to your Defender portal and sign-in logs. If they have their own portal view (common for multi-tenant managed SOCs), confirm that they can see the same incidents you see. If they can't, you'll need to forward screenshots or exports — which is slower and less effective.

Communication channel during incidents. Agree on the active communication method during an incident: email thread, Teams channel, or phone bridge. Email is fine for low/medium incidents. High-severity incidents need real-time communication — a Teams call or phone bridge where both parties can share updates as investigation progresses.

During an active incident

When escalating to the managed SOC, provide the handoff template from AD5.10:

1. Incident ID: The Defender portal incident number
2. Summary: One sentence describing the incident
3. Affected user(s): UPN(s)
4. Timeline: When the compromise started, when you discovered it
5. Actions taken: What you've already done (sessions revoked, password reset, rules removed)
6. What you need: What you're asking the SOC to do (deeper investigation, 24/7 monitoring, scope assessment)

After the handoff, stay available for questions. The SOC will ask business context questions you can answer and they can't: "Is r.williams normally active at 02:00?" "Does r.williams have access to financial systems?" "Are there other users in the same department who might be compromised?"

Don't take containment actions without coordinating with the SOC once they're engaged. If you revoke sessions while the SOC is investigating the active session, you destroy evidence they're analysing. Agree on who's executing containment: typically you execute (you have the admin credentials) while they direct (they have the investigation context).

Practical SOC coordination scenarios

Scenario 1: Simple credential compromise. You confirm an AiTM compromise during the Monday review. You execute AD6.2 (revoke, reset, MFA, persistence). The incident is contained within 15 minutes. You email the SOC: "Incident ID 12345 — compromised account for r.williams. Contained at 09:25. Please confirm no additional compromised users from the same phishing campaign. No further action needed from your side unless you find additional scope." The SOC reviews, confirms no additional users, and closes on their end. Total SOC interaction: 1 email, 1 response. This is the typical coordination — low-touch, efficient.

Scenario 2: Multi-user BEC. Your Monday review reveals 3 users compromised by the same AiTM campaign. You contain all 3 (revoke + reset), but the investigation scope is beyond a single IT admin. You call the SOC: "Incident ID 12345 — 3 confirmed compromises from the same phishing campaign. I've contained all 3 accounts. I need you to: (1) determine how many other users received the phishing email, (2) check if any additional users clicked but haven't been detected yet, (3) review the phishing infrastructure (sender domain, hosting) for threat intelligence." The SOC takes the investigation lead. You handle user communication, management notification, and finance team warning (BEC-specific steps). You reconvene at end of day for a status update.

Scenario 3: After-hours ransomware indicators. The SOC calls you at 03:00: "We're seeing indicators of ransomware on your file server — VSS deletion and unusual service creation. We've isolated the device from MDE. Need you to confirm: is this a production file server? Who has admin access? Is there a recent backup?" You provide the business context they need, confirm the server isolation is acceptable (production impact: file shares unavailable until morning), and agree to reconvene at 09:00 for investigation and recovery planning. The SOC monitors overnight; you get back to sleep knowing containment is in place.

What to do if you don't have a managed SOC

If your organization doesn't have a managed SOC, your escalation path is shorter: you → your manager → external IR (if contracted) → emergency IR procurement (if not contracted).

For incidents you can handle yourself (single compromised account, phishing click response), the procedures in AD6.2-AD6.4 are your complete playbook. You don't need a SOC for routine incidents.

For incidents beyond your capability (ransomware, multi-user compromise, sophisticated attacker with persistent access), escalate to your manager immediately with the recommendation: "This incident requires professional incident response services. I recommend we engage [IR provider] for emergency response. Estimated cost: £5,000-£15,000 depending on scope. The alternative is attempting to respond internally, which risks incomplete eradication and re-compromise."

If your organization doesn't have an IR retainer and needs emergency IR services, contact providers directly. In the UK, NCSC maintains a list of assured providers: ncsc.gov.uk/section/products-services/incident-response. Note that emergency engagement (without a pre-existing retainer) typically costs 2-3x the retainer rate and takes longer to mobilise. Document this gap in your quarterly report as a risk: "No managed SOC or IR retainer — recommend evaluation for next budget cycle."

Reviewing your managed SOC's service quarterly

If you have a managed SOC, schedule a quarterly service review (most contracts include this). Use the review to:

Review incident metrics. How many alerts did the SOC process for your tenant? How many were escalated to you? What was the average response time? Compare these to their SLA commitments. If the SOC processed 200 alerts and escalated 5, the ratio tells you they're filtering effectively. If they processed 200 and escalated 50, they may be over-escalating (passing too much back to you) — discuss tuning with their team.

Discuss false positive patterns. Share the FP patterns you've identified in your Monday reviews. If you consistently classify "impossible travel" for traveling executives as FP, the SOC should know this context so they don't escalate it every time. Provide them with a list of known travellers or a process for checking user calendars before escalating travel-related alerts.

Update the shared context document. Create a brief document the SOC can reference: key users (CEO, finance director — high-priority for escalation), known travel patterns, legitimate service principals, expected after-hours activity, and your escalation preferences (email for medium, phone call for high). Update this document quarterly as your environment changes.

Evaluate service quality. Ask yourself: did the SOC add value this quarter? Did they catch anything your Monday review would have missed? Did their response times meet SLA? If the answer is consistently "they add little beyond what my own monitoring catches," either the service needs improvement or your own monitoring is mature enough that you might consider reallocating the SOC budget to other security investments.

Evaluating whether you need a managed SOC

If you're currently operating without a managed SOC, here's the practical evaluation:

You need a managed SOC if: Your environment has 500+ users (alert volume exceeds what weekly reviews can handle), you have high-value data or regulatory obligations that require 24/7 monitoring, you've had multiple incidents that were detected too late because they happened outside business hours, or your organization can't absorb the risk of weekend/holiday detection gaps.

You can operate without a managed SOC if: Your environment has under 300 users, your E3 controls are well-configured (AD1-AD4), your Monday review and alert notifications provide adequate detection speed, and your after-hours risk tolerance is acceptable (the SOC is a 24/7 safety net — without it, after-hours detection depends on your alert notifications and willingness to respond).

Cost context: Managed SOC services for an M365-only environment typically cost £2,000-£5,000/month depending on scope. For a 200-user organization, that's £10-£25 per user per month — significant for a small business. Compare this to the cost of a single BEC incident (average loss: £25,000-£50,000 for SMBs) and the probability of an after-hours incident going undetected without SOC coverage. If the expected annual loss from undetected after-hours incidents exceeds the annual SOC cost, the investment is justified.

Include this analysis in your quarterly report if you're recommending SOC coverage: "After-hours detection gap: [X] incidents in the last quarter occurred outside business hours. Without managed SOC coverage, detection delay averages [Y] hours. Recommendation: evaluate managed SOC at £[Z]/month to provide 24/7 coverage. ROI analysis: cost of SOC vs expected annual loss from delayed detection."