Genetec: Response Architecture (Part 4)

Engineering overview

Genetec Mission Control and Managed Incident Response

The incident is closed. Can you say exactly how your team responded?

The same situation at a facility can be handled in two very different ways – depending on who happens to be on shift that night.

An experienced operator will pull up the right camera, check the adjacent area, dispatch a response team, notify the supervisor, and document the outcome. A less experienced operator may make a call first, then start looking for the right cameras, and miss one of the required steps – not through negligence, but because at three in the morning, under pressure, people fall back on memory.

Formally, the incident is closed in both cases. In practice, these represent two very different levels of organizational response – and the difference between them is captured nowhere.

For a security leader, this is the core source of inconsistency. Detection has long been standardized: sensors, cameras, and analytics perform consistently across shifts. Response has not. Its quality still depends on the experience of the individual operator, while accountability for the outcome rests with the security organization as a whole.

First: One Situation Instead of Five Alerts

Before we talk about response, we first need to remove something that gets in the way.

At a large facility, a single event rarely generates just one alert. A door event may be accompanied by motion detected on camera, an alarm system signal, and an analytics alert. The operator receives five separate alerts and has to determine that they all represent the same situation.

Mission Control does this according to predefined rules: related events are grouped into a single incident – an entity with its own priority, owner, procedure, and deadline. The number of alerts no longer equals the number of situations that require a decision.

This is a necessary condition, but it does not yet solve the problem of inconsistent response. Grouping events does not ensure that the right actions will follow.

Where Monitoring Ends and Management Begins

The transition happens at a specific point: when the procedure stops being a document and becomes part of the process itself.

In most organizations, the response procedure exists separately from the system – in a policy document, in printed instructions posted at the operator’s station, or in the head of an experienced employee. When an incident occurs, the operator has to recall it.

In Mission Control, the procedure guides incident handling step by step, with each next step determined by the response to the previous one. This is not simply an electronic version of a written procedure: a comment can be required for a step, and if a step is allowed to be skipped, the operator must provide a reason.

For a security leader, the difference is simple. Before, they could know that the procedure had been approved. Now, they can know that it was followed – and, where there were deviations, why.

Time as Part of the Procedure, Not Just a Reporting Metric

The second layer of the same idea is not about the sequence of actions, but about whether they happen on time.

For each incident type, a maximum response time and resolution time can be defined. Each individual procedure step can have its own completion deadline. If a deadline is missed, the system records it as an event and notifies the appropriate people: the supervisor of the responsible team, the team itself, or both.

The key here is not the notification, but what happens next. These events are recorded in the incident activity log and can be used as filtering criteria when generating reports. In other words, “a delay during the verification step” stops being an impression and becomes data that can be analyzed.

It is worth being clear about what this is not. This is about process observability, not measuring how fast individual operators work. The data shows where the procedure stalls or takes longer than expected. Whether the cause lies with the operator, the training, the way a particular step is defined, or a lack of resources is for the organization to determine – not the system.

This leads to a simple formula that captures the idea:

A procedure tells you what needs to be done. A managed process shows you whether it was done, when – and what happened next.

Automation with a Deliberate Boundary

The next question inevitably follows: if the system guides the response through the procedure, how far should automation be allowed to go?

For a security leader, automation is not the goal in itself. What matters is that the boundary between system action and human judgment is deliberately defined – and remains under control.

In Mission Control, that boundary is defined at a very specific level.

In other words, the decision about which steps no longer require human involvement is made separately for each step, incrementally, rather than as part of the decision to deploy the system itself.

This also addresses a common concern about complexity for staff: the procedure initially guides the operator through the response, and automation is introduced only for those steps where the organization is already confident that the outcome is predictable.

The other side of that boundary is responsibility for what happens next. An incident can be forwarded to additional participants while retaining its current owner, or transferred to someone else – in which case ownership changes as well. The question of “who is responsible right now?” has an answer in the system, rather than relying on a verbal understanding.

The same principle applies to routing: the incident goes to the people responsible for that area on that shift, with a predefined backup in place.

When a situation requires several teams to respond at the same time, it can be broken down into related parts: each team follows its own procedure, the security leader retains visibility across the entire situation, and the overall situation is considered resolved only when all of its parts have been completed.

One example from the manufacturer’s documentation is a fire on an airport apron, where the fire response team and the security team work in parallel, following different procedures.

It is also worth noting that an incident here does not have to be an emergency. It can also be a planned task that requires oversight – from equipment maintenance to verifying that security patrols have been completed. The same discipline around procedures and deadlines applies to day-to-day operations, not just to rare events.

What Can Be Reconstructed After an Incident Is Closed

For a security leader, some of the most important work begins after the situation has been resolved.

After a serious incident, there are usually video recordings, logs from multiple systems, calls, messages, and the recollections of those involved. What is usually missing is a single, coherent record of how the response unfolded.

There is an important rule here that is worth understanding precisely.

An override is possible, but it requires specific authorization – making it a deliberate exception that is also captured in the record.

This is the mechanical link between the procedure and the outcome. “The procedure was completed” stops being a statement in a report and becomes a condition for moving the incident forward.

Once an incident is closed, it can no longer be edited, but all of its information remains in the system. Together with records of missed deadlines, this makes it possible to reconstruct not only what happened, but how the organization responded: when the incident was taken into work, which required actions were completed, and where the process was delayed. When multiple teams were involved in the response, each team’s work can be reviewed separately.

For a security leader, this closes one of the most difficult gaps after an incident: knowing what happened, but being unable to reconstruct precisely how the organization responded.

Three Questions to Answer Before Configuration Begins

Everything described above has one important characteristic: it does not come with the license.

The system can guide the procedure, track deadlines, and record the outcome only after the organization has defined what it considers the correct response. That is why the design process begins with three questions – and none of them are technical.

1. Which situations does the security team consider incidents rather than simply events?
2. Where is the boundary between human judgment and system action – and which specific steps is the organization prepared to automate?
3. What needs to remain reconstructable and measurable after an incident is closed?

Design order

The operational process comes first, followed by the incident model, response logic, and acceptable boundaries for automation. Only then is the system configured to reflect what has already been defined.

Reversing that order gives you a working configuration – but an unmanaged process.