Jump to Section:
Watch the video. # Note that this is the same video as displayed from the landing page.
Executive Summary
Reflex turns your written incident-response plan into a one-off mobile application custom-built for the situation at hand. In the Builder, an Orchestrator lays out the steps, picks the people with the right skills, and sets the order in which each group should be activated.
With a single click, Reflex compiles those choices—tasks, rules, contacts, and reference files—into a secure “mini-app” designed only for that organisation and only for that type of incident (malware, ransomware, data leak, etc.).
When an incident is declared, Reflex’s delivery system pushes the correct mini-app to every responder’s phone—no app-store download, no manual setup. Each participant sees their assigned tasks, linked PDFs, and a built-in messaging channel that keeps company data separate. When the last task is completed, the mini-app wipes itself and archives a full log for audit and improvement.
For a deeper, visual walk-through of how Reflex builds these apps and why each design choice matters, watch the short videos on the landing page or read the material below.
The Builder
The “Builder” is a Windows-based application that creates the mobile applications. When using the Builder, the objective is to create a Reflex. Think of a Reflex as a container that stores all the information needed to handle a situation—or in the parlance of incident response, an incident.
Handling an incident involves much more than just a plan. A plan requires people to do, in real life, what is listed in the plan. While handling the incident, there are some people who perform the tasks and others who might perform the tasks and lead the effort.
While working through a plan, there are some steps that require previous steps to be completed first. While handling an incident, there may also be other documentation, such as manuals, that are consulted.
A Reflex contains a plan, a set of rules, additional documentation and a list of people who will work on mitigating the situation. When an incident is declared, the Reflex becomes a mobile application that is sent to the incident handlers listed inside the Reflex.
Each Reflex is specific to a particular type of incident. So, for example, a malware incident will involve the malware response plan, rules about handling malware, and a list of people who will act as incident handlers. Another type of incident will have a plan specific to it, as well as a staff dedicated to it.
However, the platform allows the individual manager to decide exactly how granular this approach should be. For example, a small company might assign the entire team to a Reflex. It may also just have one plan with many sub-plans.
Assembling the shift Reflex
A person known as an Orchestrator assembles all the information into the Reflex. It’s then compiled into a mobile application, which gets sent out to staff members when an incident is declared.
On the main screen of the Builder, there’s basically an address book of everyone on the team — not just the information security group — everyone that participates in handling incidents. It could
be other groups, for example, IT, Human Resources, Legal. It’s basically a list of all resources for handling different types of incidents.
There is an important distinction between this list and who actually participates in a particular type of incident. One big problem many groups have is activating too many people when only a specific subset is needed. For example, during a malware incident, there’s no reason to activate everyone. All people are listed as resources, but later, you group and assign them to specific types of incidents.
Frequently, when an incident is declared, you’re not sure what type of incident it is. Reflex allows you to declare a small group for first responders. These people can further evaluate the incident and determine its actual type. Then you activate the appropriate group to handle that incident. This approach saves an enormous amount of time and resources.
Creating a Plan
Plans can be created by importing an existing document or building one from scratch inside the Builder. Each line in the plan grid represents a task. Clicking a line displays more details. Reflex has its own editor, and on mobile devices, each document appears as a line in the Reflex mobile document management system. An orchestrator may choose to preload all documents before an incident is declared. In that case, incident handlers could work through the incident even when there was no connectivity.
On the right side of the plan grid, there are rule options the Orchestrator can assign. A plan item can also be linked to a text,
PDF, HTML or Excel document. It can even be linked to a webpage.
What a “Group” Means in Reflex
One of the most important—but not immediately obvious—innovations in Reflex is the concept of a Group. While a Reflex group does refer to a collection of people, its meaning is very different from what you might expect.
In most organizations, for example, there’s an information security group—a permanent team made up of technical staff, access administrators, and subject matter experts. These individuals often become the default incident response team, but
here’s the problem: when an incident occurs, does everyone in that group need to stop what they’re doing and respond?
This question came into focus for me over a decade ago during a conversation with the incident manager for the state of New York. He told me that when an incident is declared, they start a call—and a thousand people might join. But only a few are actually relevant to the specific problem. The rest? He didn’t even know if they still worked there. But because he couldn’t tell in advance, everyone was put on alert.
This kind of inefficiency is common. In many organizations, the entire security group gets pulled into every incident—even if most of them have nothing to contribute.
In Reflex, a Group is something different.
A Reflex Group is a targeted team, assembled specifically to handle a certain type of incident. It pulls from the larger pool of available staff—not just from information security, but from any department needed for that incident. For example:
- A malware group might include IT admins and security engineers.
- A data breach group could also include legal and PR personnel—since the response may involve public disclosures or legal reviews.
Each group is linked to specific tasks in the response plan. Legal might be responsible for reviewing language in a public statement. PR might need to issue that statement. Everyone in the group has a role—and those outside the group can continue their normal work.
Activating a Group
Group Activation and First Responders
Another key Reflex concept is activation order. When a Reflex is activated, it is sent only to the mobile devices of the relevant Group members.
This allows for faster, more focused responses—especially when paired with a First Responder group. First responders are a small, trusted team that gets activated for any incident type.
Why? Because the first report is often wrong.
Someone might report malware, but it’s actually a system outage or a physical breach. If you immediately activate the full malware team based on a bad assessment, you waste time and resources.
Instead, Reflex lets the orchestrator activate first responders who verify what’s really happening. If the initial assessment was correct, Reflex then activates the appropriate incident-specific group. If not, the first responders cancel the incident and declare the correct one.
This structure avoids unnecessary disruption and ensures that the right people respond, at the right time, for the right reason.
Incident Types
Reflex: Beyond Information Security
Reflex was originally designed as a tool for information security. However, after receiving feedback from a group of non-security professionals, we’ve begun describing it as a situation management tool. For the purposes of this website, I’ll continue to speak primarily in the context of information security, but in this section, I want to point out that the Reflex model is applicable to any organization—including government, nonprofits, and businesses of all types—anywhere there are groups of people who must be prepared to respond to a situation.
For example, in the context of an elementary school, an “incident” could be a fire, active shooter, or flood. Anywhere people gather, incidents can occur—and Reflex can be used to prepare and manage those responses.
Back to Information Security
In Reflex, we include a set of predefined incident types. These are not just names—they include detailed information about what is required to handle each one effectively. These definitions are part of a community-maintained resource, but orchestrators
can edit or delete any of them, or add their own company-specific incident types.
To be clear: you don’t need to use Reflex’s advanced AI features to build or use a Reflex. Many orchestrators create responses without involving AI at all. But in the interest of completeness, I want to describe a powerful capability that is available to those who want it.
Quantifying Skills with AI
One of the patents filed for Reflex involves the ability to quantify the skills of an incident responder. This means individuals can be assigned specific skills—though for simplicity, I won’t define those in detail here.
Each incident definition also contains a list of required skills—the skills needed to successfully mitigate that particular type of incident. Using this system, Reflex’s AI can:
Compare the available skills to the required skills in the incident definition.
- Review the groups assigned to the Reflex.
- Compile a list of all participants from those groups.
- Summarize the skills assigned to each participant.
- Compare the available skills to the required skills in the incident definition.
With this comparison, the AI can determine whether the team is fully prepared to handle the incident—before it happens. This insight is incredibly powerful. If gaps are found, the orchestrator can take proactive steps: hire new staff or contract with third parties to fill those needs in advance.
Incident definitions can also include people from other departments—not just information security. As previously mentioned, the Reflex address book can include individuals from across the organization.
Creating a Mobile Application
Everything described so far comes together in the creation of a defined Reflex. When the orchestrator selects the “Analyze” button, Reflex’s AI reviews all known resource availability and incident requirements. It then identifies whether any critical requirements are missing.
This system can assist the Chief Information Security Officer
(CISO) in unexpected ways. For example, in any organization, employees may leave at any time—either voluntarily or involuntarily.
In a typical voluntary departure, the CISO or manager would simply follow the standard offboarding process—removing the individual from the organization’s systems and updating internal records. If that manager also uses Reflex, they would remove the person from the Reflex address book as well. In most systems, that’s where it ends.
But with Reflex, it’s different.
When a user is removed from the system, Reflex immediately
analyzes every group and defined Reflex to assess the impact of that departure. The AI flags any gaps created by the missing person and generates a report detailing the consequences.
In the case of a potential involuntary exit, Reflex offers a particularly valuable feature: the ability to simulate the deletion of an individual before making it official. This hypothetical removal allows the manager to preview exactly what would be affected—groups that would become incomplete, incidents that could no longer be fully handled, or required skills that would be missing.
This gives the manager a chance to reflect on the decision and prepare alternative staffing before committing to the change.