In summary, Reflex functions as follows:

Create a Response Plan

A senior information security team member, known as the Orchestrator, either imports an existing Word-based incident response plan or creates one within the application. The component of the system used to build the plan is called the Builder.

Main Screen of the Reflex Builder

The Orchestrator is typically an experienced team member, but plans can also be created externally by other organizations and shared as templates.

If the user clicks import, the standard file import dialog will be displayed. A Word document that has added specific styles will be imported and compiled into a plan. The feature dialog will then be displayed, where the user can add rules and features. A user can also select new, in which case the feature dialog will appear empty, and the user can then create a plan line by line.

An important aside should be mentioned here: the architect of this system previously wrote one of the first artificial intelligence systems in the late 1980s and early 1990s. It was part of a commercial product called Floater.

Unlike modern AI, this system was not based on pre-programmed decision-making. Instead, the end user taught the system their personal preferences for responding to different situations. The designer called this approach “Real Intelligence” (RI) because it aimed to align with user intent rather than pre-defined automation.

Although there is no shared code between Floater and Reflex, the underlying decision-making framework in Reflex is based on the RI technology. The Orchestrator defines custom decision logic, meaning the experience level of the Orchestrator can significantly impact how the system operates.

Reflex is structured as an interactive “to-do list” executed step-by-step. Each line in the list represents a specific task in the incident response plan.

The Orchestrator can assign additional features to each task, creating a customized mobile-based application that is deployed to designated team members when an incident is declared.

Notice that on the following line there is a small link icon.

When viewing a Reflex plan, you may notice a small link icon next to certain items. This icon indicates that the Orchestrator has linked the item to either an external PDF document or a website.

Historically, attempts to use PDFs on mobile devices during incident response have often failed. The reason is simple: PDFs are designed for desktop monitors, where large screens make it easier to navigate complex information. On a mobile phone, however, a PDF containing a detailed sequence of events can become overwhelming and difficult to manage.

One of Reflex’s most valued features is its readability on mobile devices. However, there are situations where having access to a full document—or even an entire book—can be beneficial. Reflex accommodates this by allowing users to link to any PDF document. Linked PDFs are stored locally on the mobile device and are transferred at the same time as the plan. Reflex includes a built-in PDF reader, enabling users to open and view files directly within the app. While PDFs may be cumbersome on small screens, they can be useful on tablets or larger smartphones.

The ability to link and store PDFs has been leveraged for many other applications beyond incident response. For example, a company can create a Reflex plan that serves as an index to a library of documents. Each line in the plan can function as a label or link to a full policy document. By downloading the plan to a mobile device, a user gains instant access to a complete library of policies, all stored locally for offline use.

This feature has also been proposed for field technicians. Imagine a technician arriving at a job site and needing a reference manual to diagnose an issue. Instead of carrying physical books, they can store a digital library of manuals on their mobile device. If a specific manual is missing, someone at the office can send it directly to the technician’s device, regardless of location. This capability extends beyond information security and highlights the flexibility of Reflex’s technology.

For simplicity, I will not describe the other important features of Reflex here. My objective is just to provide an overview. So, assume that after the Features have been added the plan is compiled and stored on a server.

Declaring an Incident

An incident has been detected, and it is time to activate an incident response plan. The incident can be declared in two ways: The builder can be used to activate an incident response, or a team member with administrative credentials can activate an incident remotely from his or her mobile device.

The following is a photo of what the user will see on his or her mobile device. It is a complete, self-contained custom app designed to handle the type of incident that was declared.

As discussed above, each task in the Reflex system follows a master/slave model by default:

1. When a user clicks on a task, a detailed explanation is displayed.
2. The Orchestrator can attach PDF files or web resources.
3. If a PDF file is included, it is sent to the mobile device upon incident declaration.

Since messaging protocols limit file sizes (commonly 256 KB), Reflex uses a proprietary system that transfers large files through small message packets. This allows secure, efficient file distribution—a feature that will be covered later in this document.

Reflex allows response plans to be as simple or complex as needed. A plan can be a basic step-by-step checklist or a multi-layered response strategy.

A key differentiator of Reflex is its real-time, collaborative nature:

• Apps are distributed only to designated team members.
• When a team member completes a task, a checkmark is instantly reflected on all devices.
• The Orchestrator can restrict user actions to ensure correct task order (e.g., tasks cannot be marked complete unless prerequisites are fulfilled).

Once all tasks are completed, the incident is closed. Reflex automatically compiles a full record of the incident, including:

• Task completion times
• Delays
• Decision-making patterns

These logs can later be used for review, audit, or AI-driven response optimization.

Describing Reflex in a single use case is challenging. While it excels in Incident Response, it is equally powerful for any time-sensitive, mission-critical process.

For example, Reflex has been successfully implemented in Business Continuity Planning (BCP) and has been described as the “killer app” for BCP.

Since Reflex is mobile-first, it is fully adaptable to remote teams:

• Team members can be anywhere—only those with physical server access need to be on-site.
• Reflex aligns with the post-COVID reality of remote workforces.
• Reflex simplifies compliance—ensuring that required annual incident response testing is conducted, tracked, and documented.

Many companies claim that incident response can be outsourced, but this is misleading. Security principles dictate that only privileged personnel can execute response actions—external consultants cannot directly intervene.

Reflex changes this model:

• A third-party consultant can use Reflex to develop plans and act as a virtual project manager during incidents.
• Reflex enables real-time coordination between external experts and internal teams.
• Large consulting firms (IBM, AT&T, Verizon) could increase security sales by a quarter billion dollars.
• It also empowers smaller, specialized security firms.

One of the most important aspects of Reflex is that it addresses the weakest link in cybersecurity:

• Nonprofits and small businesses often lack the budget for security teams or enterprise tools.
• Reflex is offered for free to these organizations.
• A community-driven ecosystem will provide template plans and expert guidance.

By making enterprise-grade security accessible, Reflex closes the cybersecurity gap for under-resourced organizations.

Reflex is not just an incident response tool—it is a paradigm shift in crisis management, business continuity, and collaborative security operations.