How GIG Gulf Rehearsed Cyber Incident Response

Bruno Fonseca sponsored a preparation programme that put executives and technical teams through separate exercises. The work that followed turned what they learned into instructions staff could use under pressure.

A technical team notices signs that a service may have been compromised. It wants to contain the problem quickly. The business owner for that service wants to know which customers will lose access if it is taken offline. The communications team needs to know what it can say while the facts are still changing. Those decisions happen on different clocks, and each depends on information someone else has. An exercise gives a security leader a chance to see whether the people involved can make those decisions together before they have to do it for real.

At insurer GIG Gulf, Bruno Fonseca sponsored a programme that included crisis management training, separate tabletop exercises for executives and technical teams, and the development of business continuity and incident response playbooks. Cyber Management Alliance, which delivered the engagement, identifies Fonseca as the security and operational excellence leader who sponsored the work, Rahul Banga as the information security manager who led technical planning and execution, and Saba Hameed as the resilience manager who helped align the work with operating frameworks. GIG Gulf separately identified Fonseca as its regional chief security officer and head of operational excellence at a Dubai event. The supplier’s account describes an internal programme but gives no firm-by-firm or country-by-country exercise breakdown. Cyber Management Alliance’s published case study, GIG Gulf’s account of its Dubai digital summit

Give technical teams and executives different work

The two exercises served different purposes. The supplier describes the technical session as testing how staff would handle simulated threats and work across teams. The executive session put leaders through scenarios designed to test decisions and communication. Fonseca’s published comments describe the technical session as bringing technical depth together with strategic thinking. Banga described the resulting incident response playbooks as tailored to the organisation and used in day-to-day security operations. Those assessments come from named practitioners in a supplier-published account. The case study gives no before-and-after measurements or record of how the organisation subsequently handled a live incident. Detailed case study with comments from Fonseca and Banga

An executive group needs to decide how much disruption the business can accept while investigators establish what happened. A technical group needs to gather and interpret evidence, develop containment options and establish what each option would interrupt. One group may start with a list of affected systems. The other needs that list translated into the services customers and employees can still use. A useful exercise shows whether the technical team can make that translation before executives need to choose.

Consider an illustrative scenario for a UAE insurer. Staff can still receive claims, but an important document service becomes unavailable. Some submissions are visible and others have an unknown status. The technical team can give a current view of the affected service and propose ways to limit further disruption. Operations can estimate which customer journeys are interrupted and whether an alternate route can absorb urgent work. The incident lead can then ask an executive to authorise a limited fallback and record when that decision should be reviewed. This scenario illustrates the handoff. The programme’s private exercise details were not disclosed.

A tabletop is especially valuable when the information changes. If the next update says the alternate route is itself unreliable, the executive team has to reconsider the earlier decision. The facilitator can observe whether people know who can make that call and how the new decision reaches staff already following the old one. It is possible to get the first answer right and still leave the business responding to an outdated instruction.

Turn exercise observations into instructions

The supplier says GIG Gulf developed playbooks using lessons from the exercises. It describes those documents as setting out roles, escalation paths and actions. The public account leaves the underlying process gaps and procedures undisclosed. A team can still learn from the sequence. An exercise shows what people actually need to decide. A playbook can preserve the information required to make that decision the next time.

The useful level of detail depends on who opens the document. A technical responder may need the conditions under which they can request isolation and the information they must capture first. A business continuity lead needs the affected services, the people who can approve temporary arrangements and the conditions for ending them. An executive needs the impact, the options, who recommends each option and when the facts will be reviewed. A playbook that gives every role the same long sequence can make it difficult to find the action relevant to the moment.

One exercise observation might be that the response team could identify the affected system but could not explain which customer work had stopped. A follow-up could assign someone to keep a map of customer tasks and the systems each relies on. The next rehearsal should check whether the incident lead can retrieve that map and use it to brief the decision-maker. Merely adding a line to a document gives little evidence that the change works.

The same logic applies to communication. A message suitable for staff who need to stop using a service will differ from an update for customers waiting on a submission. An exercise can test whether each message identifies what the recipient should do, what is known about the situation and when another update is expected. A useful draft can acknowledge uncertainty while giving people a practical next step. The team should also establish who has authority to issue that message if the usual approver is unavailable.

What a separate DIFC exercise makes visible

In 2023, the Dubai Financial Services Authority published a report on an industry-level exercise for authorised firms in the Dubai International Financial Centre. Seventeen firms participated, according to the report prepared by exercise facilitator Control Risks. Its scenario used simulated developments, including mock reports and calls, to require participants to reassess the situation and communicate. That is a separate project from GIG Gulf’s programme. It shows how a facilitator can make an exercise test a series of decisions instead of asking participants to discuss a static scenario. DFSA’s publication announcement, Control Risks’ post-exercise report for the DFSA

The report says 14 of the 17 firms were graded excellent or proficient on the incident response protocols they demonstrated. Three were graded developing on that measure. The facilitators drew on checkpoint responses, record-keeping and feedback from role players. They also noted that smaller firms tended to provide less information about their responses and that participants identified communication, stakeholder prioritisation and faster decision-making as areas worth developing. These were exercise observations, with different levels of information available from different firms.

That distinction changes how a security leader should design the debrief. Ask people to say where they felt confident, then compare their account with the decisions and messages recorded during the session. A group may feel that communications went smoothly because it agreed on the content of an update. The timeline can show that the group spent most of the exercise working out who could approve it. Those two observations can both be true, and they point to a specific question for the next rehearsal.

DIFC’s separate Instagram reel shows business participants at a district event.

An event video can show people gathered in a room. The exercise report is what establishes who the simulation was for, how the scenario progressed and what it was designed to test. The same distinction is useful inside an organisation. A calendar entry and a photograph show that people attended. A decision log shows whether they could identify the owner of an action, explain what they knew at the time and revise their instructions when the situation changed.

In a scenario with uncertain recovery, a team may learn more from a decision that goes wrong than from a quick consensus. Ask observers to record the facts available when the choice was made and the reason for it. That lets the review distinguish between an understandable decision made with incomplete information and a gap in authority, evidence or coordination. It also allows a second exercise to repeat the same decision under slightly different conditions.

Give the follow-up work an owner

A security leader can judge the quality of preparation by what survives after the exercise. Start with the few findings that could most affect the response. Give each one a specific owner, a deadline and a test that shows whether the proposed fix works. If a communications route was unavailable in the scenario, test the alternate route. If nobody could reach the person authorised to pause a service, check whether a named delegate knows how to act and can obtain enough information to do it. Reopening the same exercise with a different shift can show whether a fix became part of normal operations.

The business side matters during recovery as much as during escalation. A restored service may accept new transactions while leaving earlier work unresolved. In the illustrative claims scenario, operations may need to reconcile submissions received before the outage and those collected through the fallback process. A recovery exercise should therefore end with business confirmation that people can complete their work and that outstanding cases have owners. A technical health check can establish that the service is available. Only the business workflow can show what remains in the queue.

There is also a practical distinction between writing findings for a broad audience and preserving the details responders need. A summary can tell executives that an escalation decision took too long and assign a fix. An operational record can retain the specific roles and tools used under appropriate access controls. Keeping those records separate helps the team share the lesson without circulating details that are useful only to the responders.

GIG Gulf’s public case gives Fonseca’s programme a traceable sequence. Leaders and responders practised different decisions, and the supplier says lessons from those exercises informed playbooks for staff. The strongest evidence a company can build on top of that sequence is a repeat test. Someone should be able to show that the people on duty can get the right information, authorise a proportionate response and explain how customers will keep receiving service while the incident is resolved.