Who decides during a managed-service incident?

Rehearse decision authority

A managed-service agreement can identify the support team, set response targets and explain escalation. It may still leave someone unsure whether they can contain a suspected attack when that action would also stop an important service.

For a GCC enterprise relying on an external IT provider, that decision deserves a rehearsal with the people who would make it. Bring the provider's incident lead and your operational decision-maker into the same exercise. Give them a plausible service failure and incomplete evidence. Ask for a decision that would affect operations.

Leave with a decision-and-handover record: the authority to act, the information needed for each decision and the deputy who can take over.

Why rehearse with the provider?

In July 2026, the UK's National Cyber Security Centre published response and recovery guidance that stresses practising response arrangements and testing recovery. Its focus on business-led recovery is useful when technical restoration and operational priorities pull teams in different directions.

• response and recovery guidance

NIST's April 2025 incident-response publication includes suppliers and relevant third parties in incident planning, response and recovery. It also identifies exercises involving third parties as a way to find improvements.

• April 2025 incident-response publication

These are UK and US guidance sources, not GCC legal requirements. The rehearsal below is a proposed management exercise, not an official standard or evidence that a particular organisation can recover.

This article follows our guide to selecting a managed DevSecOps provider. Here, the contract is already in place. The customer and provider are testing how their responsibilities work together during an incident.

• selecting a managed DevSecOps provider

Start with one service and an awkward decision

Choose a service whose disruption has a clear business consequence. Record the service owner, the provider's scope and any separate software vendor before writing the scenario. Keep the discussion within that service's dependencies and operating decisions.

Here is an illustrative scenario for a fictional facilities-maintenance business operating in the Gulf. Its portal receives service requests and passes approved jobs to a dispatch system. A managed provider supports the integration. Dispatch supervisors own the daily work schedule.

The portal is still accepting requests, but some jobs are not appearing in dispatch. At the same time, the provider detects unusual activity involving the integration account. The software vendor's public status page reports normal operation.

The cause is unknown. The unusual activity may be related to the missing jobs, or the two issues may have different causes. The team must consider both availability and security while it investigates.

The provider proposes temporarily disabling the account. That could limit further unauthorised activity, but it would also stop new jobs reaching dispatch. Keeping the account active could preserve service while leaving a suspected exposure unresolved.

Ask the participants to make a decision with the information available. Check the provider's authority to take the proposed action. Where customer approval is required, identify the approver and ask how urgent field work will continue.

All details in this scenario are invented for discussion. They do not describe a Bridges client or establish response-time, recovery or security targets.

Agree who can act before the exercise starts

Name the customer incident lead and a deputy. Give the provider a corresponding lead with a route to someone authorised to commit its response resources. The operational owner should be available to explain the consequences of an interruption and approve the business trade-offs within their remit.

The agreement should already specify any actions the provider may take without further approval, their limits and the required notification. The exercise checks that both teams interpret those terms consistently. It must not silently expand the provider's authority.

The Canadian Centre for Cyber Security's managed-services guidance, last modified in October 2020, highlights the need to coordinate incident plans and clarify responsibilities. Its observation that provider and customer priorities may differ is particularly relevant when a provider supports several affected customers.

• managed-services guidance

Treat this older Canadian guidance as a useful planning reference. Accountability under a particular contract or local law still needs to be established for that organisation.

A small customer team may assign several roles to one person. The exercise should expose the resulting dependency: if that person cannot be reached, which decisions can a deputy make, and which actions remain outside their authority?

Run a focused, 60-minute discussion

The following hour-long format is an editorial proposal. Adapt the duration and participants to the service. Use synthetic records and a controlled discussion; do not disable a production account or send an actual customer alert as part of this tabletop.

Separate confirmed observations from assumptions in a shared record. The vendor's green status page is one piece of information; it does not establish that this customer's end-to-end service is functioning.

Agree who gathers each missing fact and when the next update will occur. Make that update time an exercise decision, not a response promise invented by the facilitator.

If they pause the integration, who activates the agreed manual intake or dispatch process? If they keep it operating while investigating, who accepts that temporary exposure and what would cause the decision to change? The scenario should allow either answer to be challenged against the available evidence and actual authority.

Then make the customer's usual approver unavailable. Observe whether the deputy arrangement works. If no authorised person can be reached, record the gap and the permitted emergency action; do not assume that a support technician can accept the business risk.

They should be able to identify the current service restriction, the evidence behind it, the decision owner and the next action. Include the investigation's unanswered questions. A handover that drops uncertainty can turn a tentative explanation into an accepted cause.

Test the agreed alternative communication route if the usual collaboration service is unavailable. Confirm who is permitted to receive technical evidence and personal information; use synthetic material during the exercise.

“Improve communication” is too vague. “Add the provider's out-of-hours incident lead to the agreed call route, verify it with both deputies and rehearse that contact step again” gives someone work they can complete.

Close with the observed gaps and agreed changes, including the evidence needed to check each change. A general confidence score would leave those details unresolved.

Keep a decision record that survives a handover

The following is a proposed record for the fictional scenario. Replace role names with actual people and authorised deputies in the organisation's working version. Store it in an agreed location accessible during the incident, with appropriate access controls.

A ticket number alone will not tell a replacement responder why an account was disabled or who can authorise a different action. Include the decision's reasoning so that the next responder does not have to reconstruct it from separate chat threads.

For real incidents, the designated legal, privacy and communications teams must establish applicable notification duties and deadlines. These vary with jurisdiction, sector, facts and contractual commitments. This article sets no common UAE, Saudi or GCC reporting deadline.

Separate the tabletop from technical proof

A tabletop can show that nobody knows how to reach the software vendor after hours. It cannot prove that a backup restores correctly, that logs contain the necessary evidence or that a manual dispatch process has enough capacity.

List those technical or operational checks separately. Plan and authorise them with the relevant owners, including safeguards for production systems and personal information. Record what was actually tested and what remains an assumption.

The UK's NCSC provider-selection guidance, published in November 2025 for smaller organisations, recommends clear provider responsibilities and incident-reporting expectations. A rehearsal can expose a gap in those arrangements; changing the contract, access or service scope requires the appropriate approval.

• provider-selection guidance

Recovery also has its own acceptance decision. Restored connectivity does not establish that all work is accounted for. Our post-outage reconciliation guide covers that later problem. Here, the rehearsal should identify who will own the recovery decision and what information they will need.

• post-outage reconciliation guide

Questions to resolve with the provider

Bridges' Managed IT & Cloud Operations, Cybersecurity and Business Continuity & Resilience services are relevant to this work. To discuss a rehearsal, contact Bridges with the service you want to test and the decision that needs clarifying.

• Managed IT & Cloud Operations
• Cybersecurity
• Business Continuity & Resilience
• contact Bridges