Operational Resilience: Using Routing Groups to Automate Response SLAs

In any team there are individuals with specific tasks—wide receiver, goalie, catcher, and so on. The same can apply to your security team. If your organization is large or covers several regions you will of assigned different individuals, groups, or levels, separate elements of the organization’s security plan. For example, a local event might be handled by the nearest operator and a security officer onsite. If the event escalates the security may move ‘up’ a tier and involve the regional office, and in the unlikely event that the threat escalates even further, it may be necessary to involve the global team. None of this should be decided on the fly. Part of building resilience is deciding well ahead of time who is going to be responsible for what in any given scenario.

raise to routing group

To build resilience in your operation you need to address three key issues:

  1. Decide on the parameters for local and centralized monitoring
  2. Time is another factor that can cause an incident to be forwarded upwards. Commonly, SLAs (Service Level Agreements) are drawn up so that if an alarm received by a first-line operator is not responded to within x number of minutes it is rerouted up to a second level operator and so on.
  3. Failover alarms are another issue. In the event that a Security Operations Center becomes overwhelmed with alarms—or in extreme circumstances, needs to be evacuated— the alarms can automatically be rerouted to a central or head office SOC for processing.

Let’s say you do have a local event that becomes a high priority. At what point does the local operator/guard push this through to the regional team. And, later, at what point does the regional team involve management, head office, or other supervisors? It’s important to identify the stages, triggers, or circumstances which will initiate the incident being sent ‘forward’.