SOC Renewal: Test the Alert Route After One Owner Leaves
A managed SOC can detect the right event in five minutes and still fail your company.
The analyst opens a critical case. The platform sends an email to a former employee. The phone tree calls an old number. The shared security mailbox has six members, but nobody is accountable for answering it after hours. By the time a current owner sees the alert, the response target on the monthly report still looks fine.
That is not a detection problem. It is a routing problem, and routing belongs in the renewal decision.
Before you renew a managed SOC, MSSP, or monitoring service, test whether a serious alert can move from the provider’s queue to a current person inside your company who understands the situation and has authority to act. Then remove one owner from the path and run the test again.
If the handoff breaks when one person changes roles, takes vacation, or leaves the company, the service is not ready for another term without correction.
The dashboard does not prove the handoff
SOC renewal reviews tend to focus on coverage, alert volume, investigation time, and response time. Those matter. We covered the broader evidence packet in our MDR renewal guide.
This test is narrower. It asks whether the provider can reliably reach the right customer owner when a case needs a decision.
Pull the signed agreement, service description, severity definitions, notification commitments, escalation matrix, portal role export, current employee directory, and records from several important cases. Compare them line by line.
Do not accept “24/7 notification” as a complete answer. You need to know:
- Which event starts the notification clock
- Which severity levels trigger a call, text, email, portal case, or another channel
- Which role receives the first contact
- How long the provider waits before escalating
- Who receives the second and third attempt
- Who may approve containment or business disruption
- What the provider does when nobody responds
- How both parties record that the handoff occurred
The provider may have followed its process perfectly. That process can still be wrong for your current organization.
Replace names with operating roles
A contact list built around people ages badly. A routing design built around roles is easier to maintain.
Your primary route might point to the on-call security lead. The backup might be the incident commander. A separate business approver may be required before taking a revenue system offline. Each role should have a current person, a backup, working contact methods, portal access, and documented authority.
That last part matters. Reaching someone who cannot approve the next action is only a partial handoff.
Build a small routing record for each serious alert class:
| Alert class | Primary owner | Backup owner | Required authority | First channel | Backup channel | No-response action |
|---|---|---|---|---|---|---|
| Suspected account takeover | On-call security lead | IT operations lead | Disable account and revoke sessions | Phone | Secure portal | Escalate to incident commander |
| Malware on a managed endpoint | On-call security lead | Endpoint owner | Isolate endpoint | Phone | Text or secure portal | Follow approved containment rule |
| Threat involving a critical production system | Incident commander | Executive technology sponsor | Approve service disruption | Phone | Alternate phone | Invoke executive escalation path |
Those are examples, not a model to copy blindly. Your routes need to match your systems, risk, staffing, insurance process, legal requirements, and provider scope.
A shared mailbox can stay in the design as a record or secondary path. It should not be the only owner for a critical decision.
Test the route after a real ownership change
The cleanest renewal test uses a change that already happened.
Pick an employee who left the company, moved to another role, stopped carrying on-call responsibility, or changed contact information during the current term. Trace what happened across every place the SOC uses customer information:
- The provider’s escalation matrix
- Portal users and role assignments
- Phone and text notification settings
- Distribution lists and shared mailboxes
- Response playbooks and approval tables
- Internal incident plans and on-call records
- Account-team notes or support contacts that may operate outside the formal workflow
Record when the internal change occurred, when the provider was told, when each system was updated, and who verified the final route.
If one update fixed the portal but not the call tree, the work was not complete. If the provider depends on your company to report every personnel change, your internal process needs an owner and a deadline. If the provider accepted the change but never tested it, the renewal record is still missing evidence.
This is why a screenshot of the current contact page is not enough. It shows the route now. It does not prove that ownership changes are controlled.
Run three alert tests
Do not wait for a real attack to test the routing design. Ask the provider to run controlled notification tests that do not create confusion with live incidents.
Use three cases:
A high-severity alert during business hours
Confirm that the primary owner receives enough context to understand the alert, the required decision, the case location, and the deadline. Record each channel used and the time of acknowledgment.
A high-severity alert after hours
Use the real on-call path. Do not warn the individual about the exact minute if that would make the test meaningless. Make sure everyone knows a controlled exercise is scheduled and that the message clearly says it is a test.
The same alert with the primary owner unavailable
This is the ownership-change test. Disable the primary route for the exercise or instruct the person not to respond. Watch the provider move to the backup owner and then to the no-response action.
The goal is not to create a clever tabletop. The goal is to produce a simple timeline:
- Alert created
- Severity assigned
- First notification sent
- Backup path started
- Current owner acknowledged
- Decision authority confirmed
- Case updated
- Test closed and gaps assigned
One successful email does not pass the test. The route passes when the right person receives the right context through the expected channel and can take the next required action.
Check the provider’s side too
Customer contacts are only half of the route.
Your team also needs a dependable way to escalate into the provider. An account manager is not necessarily an incident contact. A general support queue may not be the right path for a critical case. A named analyst may be unavailable when you need help.
Confirm the SOC’s operations number, secure case path, management escalation, after-hours process, and backup method if its primary portal or communications platform is unavailable. Test one customer-initiated escalation and require the provider to acknowledge it through the agreed workflow.
The same ownership rule applies: the path should lead to an operating role, not depend on one helpful person.
Put maintenance into the renewal terms
NIST SP 800-61 Revision 3 treats third-party incident response as a shared responsibility model. It says transferred responsibilities should be defined in the contract, including information flows, coordination, authority to act, and restrictions on the provider.
The same publication recommends established incident-coordination procedures that define what must be reported to whom and at what times. It also says procedures can be tested periodically and that exercises coordinated with suppliers can reveal improvements and prepare the parties for future incidents.
That guidance should show up in the operating record, not as a citation nobody uses.
For the next term, document:
- Who owns the customer escalation matrix
- Which personnel changes require an update
- How quickly each party must make the change
- Which systems and documents must be updated
- How the completed update is verified
- How often notification routes are tested
- Which failed tests require remediation
- Whether missed routes or stale contacts affect service reporting
Do not assume the SLA covers this. Read the exact measurement language. A provider may measure time to send a notification, not time to reach a valid owner or receive an acknowledgment.
If notification continuity matters to the purchase, define the evidence you expect before signing.
Make one of four renewal decisions
The result should lead to a buying decision.
Renew when current and backup routes work, authority is clear, maintenance has an owner, and the evidence supports the service claim.
Renew with written correction when the provider still fits but stale contacts, weak backup routes, unclear authority, or missing tests need named deliverables and due dates.
Use a short bridge or run a competitive review when the renewal deadline is close and the provider cannot show a dependable handoff. Compare how alternatives manage portal roles, after-hours escalation, customer contact changes, testing, and case evidence.
Do not renew as proposed when a critical route repeatedly fails, the provider will not expose the process, or the contract measures activity without protecting the handoff your team depends on.
The cheapest fix may be a better internal ownership process. It may be a provider workflow change. It may be a different service. Find that out before the renewal date removes your leverage.
Test the call, not the contact list
A managed SOC is supposed to add response capacity when your team needs it. That value disappears if the alert stops at a stale address, a former employee, or a current employee who cannot approve the next move.
Trace one ownership change. Run three notification tests. Verify both directions. Put maintenance and evidence into the renewal record.
If your managed SOC agreement is approaching renewal, request a Contract and Spend Risk Review. Bring the agreement, escalation matrix, portal access list, recent alert evidence, and renewal proposal. Catch Advisors will help you test the handoff and decide what needs to change before you sign.