An alert appears in the security operations center. It reports a suspicious sign-in from an unusual location, involving an account that matters. The analyst opens it and reviews the information provided by the detection.
Then the guidance stops.
The analyst still has to decide what to investigate, which events might be relevant and what would make the activity genuinely suspicious. They need to consider legitimate explanations, look for related activity and decide whether the alert should be escalated or closed.
The detection has found the signal, but it hasn’t explained how to investigate it. That gap is what a runbook is designed to fill. A runbook is an investigation guide attached to a detection rule. It records why the detection exists, the legitimate activity that might trigger it and the questions that should be answered before reaching a verdict. In other words, the detection points to something that deserves attention, while the runbook helps the analyst or agent understand what it means.
The SIEM industry has spent years improving detection engineering through better telemetry, stronger rules and more precise logic. Sekoia has been part of that work. Yet even a well-designed detection often ends just as the real investigation begins.
Detection is only the start
A detection is an instruction to pay attention. It is not a complete investigation method.
Take the suspicious sign-in example. The rule may have identified an unusual country, an unfamiliar device or an IP address that has not previously been associated with the user. That gives the SOC a useful place to start, but it does not establish that an account has been compromised.
The user might be travelling. The IP address could belong to the company’s VPN. The device may be new but legitimate. On the other hand, the account might have elevated privileges, the same IP address may have attempted to access several other accounts, or suspicious activity may have followed the sign-in.
An experienced analyst will usually know where to look next. They may review recent authentication activity, check the user’s privileges, inspect events from the same IP address and look at what happened on the endpoint after the login. Much of that process comes from experience rather than from the detection itself.
This becomes a problem when every analyst has to reconstruct the investigation path independently. The same alert can be handled differently depending on who is working, how much experience they have and what they happen to remember. Questions that have already been answered dozens of times are asked again from scratch. A detection without any follow-up guidance leaves an important part of the work unfinished.
What a runbook adds
The term “runbook” can make the idea sound more technical than it is. In practice, it is a way to keep the knowledge needed for an investigation close to the detection that created it.
In Sekoia, a runbook contains three main elements. The detection rationale explains why the rule exists and what it is intended to identify. Legitimate scenarios describe the benign activity that could produce the same signal. Investigation questions guide the agent through the evidence it should collect and assess.
For a suspicious sign-in, the runbook might explain that the detection is looking for possible account compromise. It could note that corporate VPNs and employee travel are common legitimate explanations. It might then direct the investigation towards the user’s privileges, other activity from the IP address, recent authentication history and actions performed after the sign-in.
This is different from an automation playbook. A playbook carries out a sequence of actions, such as enriching an observable, notifying a team or triggering a response in another tool. A runbook guides the reasoning that comes before a verdict. The two can support the same investigation, but they do different jobs.
The runbook does not remove the need for judgment, nor does it force every alert through an identical process. It gives the investigation a useful starting point so that the analyst or agent does not have to begin with a blank page.
Making detection knowledge usable
Most SOCs already have much of the knowledge that belongs in a runbook. The difficulty is finding it when an alert arrives. Some of it lives in the memory of senior analysts. Other parts are scattered across internal documentation, detection notes, old cases and conversations between colleagues. Sometimes the investigation method is understood by the people who designed the rule but has never been written down.
This separation between the detection and the knowledge behind it creates unnecessary work. The rule produces an alert, but the analyst must search elsewhere to understand why it matters and how it should be handled.
A runbook brings those pieces together. It gives the investigator the reasoning behind the detection, points out situations that can produce false positives and identifies the questions most likely to change the verdict.
That knowledge becomes available at the moment it is needed. An analyst opening the alert can see not only what matched, but also what the detection was trying to uncover. They can understand which evidence would strengthen the case, which context might weaken it and what should be examined next.
The investigation can still change direction as new evidence appears. The value of the runbook is not that it predicts every possible path. It is that it captures what the team already knows and makes that knowledge reusable.
A shared way of investigating
Runbooks also make investigations more consistent across a team.
A new analyst can begin with the same rationale and questions as a more experienced colleague. When a case changes hands, the next person can understand the approach that was followed instead of reconstructing it from a few notes. An MSSP can establish a common investigation method across customers while still accounting for the details of each environment.
Consistency does not mean treating every organization in the same way. Context still matters. A service account running scripts at three in the morning may be entirely normal in one environment and highly unusual in another. An external IP address may belong to a trusted provider, a VPN gateway or an attacker. The runbook provides the detection-specific method. Knowledge about the customer or organization helps apply it correctly.
That same structure is useful when an AI agent performs the investigation. An agent cannot do much with a label such as “suspicious sign-in” on its own. It needs to know why the behavior matters, what legitimate activity might resemble it and which evidence should affect its conclusion.
In Sekoia, the Elevate agent uses the runbook associated with the detection rule to guide its analysis. It works through the investigation questions, gathers evidence as findings and uses those findings to reach a verdict. If the alert raises an additional issue, the agent can add further questions as it investigates.
The analyst can then review the evidence behind the conclusion rather than being presented with an unexplained answer. They can see what the agent examined, which queries or actions produced the findings and how those findings influenced the verdict.
This makes the investigation easier to trust and easier to challenge when necessary. It also means that the same body of knowledge can support both human analysts and AI agents instead of creating separate methods for each.
Capturing the intent behind a rule
Detection rules are good at describing logic. They are less suited to explaining intent.
A rule may identify a sequence of events associated with credential theft. Its logic defines the technical conditions that must be met before an alert is created. It cannot easily express everything the rule’s author knows about the behavior, the threat or the environment in which the alert will be investigated.
The runbook provides that missing context. It can explain why the sequence matters, what an attacker may be trying to achieve and which legitimate administrative activity could look similar. It can also point the investigation towards the surrounding events that help distinguish one explanation from another.
This keeps the purpose of the detection connected to its technical implementation. Instead of seeing only that a pattern matched, the investigator can understand what the rule was designed to uncover.
It also gives teams a practical way to improve their investigation process. When an analyst discovers a recurring false positive, it can be added to the legitimate scenarios. When threat intelligence changes the understanding of a technique, the rationale can be updated. If a case reveals a useful new line of enquiry, the investigation questions can be revised.
The knowledge gained from one alert then improves the handling of the next one.
A higher standard for detection engineering
Detection engineering has traditionally treated the rule as the finished product. Once it has been written, tested and deployed, the work is considered complete.
In practice, the usefulness of a detection depends heavily on what happens after it fires. A precise rule can still create significant work if the analyst has no clear way to investigate the resulting alert. The problem has not been solved; it has simply moved into the analyst’s queue.
Pairing a rule with a runbook sets a higher standard. It means that a new detection arrives with enough operational knowledge to be investigated properly. The rule identifies the behavior, while the runbook preserves the reasoning needed to assess it.
This changes what a detection team delivers. Instead of producing an isolated alert, it produces the beginning of a repeatable investigation. That is particularly important when SOCs are being asked to handle more alerts with limited analyst capacity. Improving detection quality remains essential, but it is only one part of the problem. Teams also need to reduce the amount of reasoning that is repeatedly reconstructed after each alert arrives.
Creating the runbook alongside the rule makes that investigation knowledge part of detection engineering from the beginning.
Turning expertise into part of the platform
The strongest security teams have always relied on habits that are difficult to see in the detection itself. Experienced analysts know which events are worth checking, which benign patterns appear regularly and how activity in one part of the environment might connect to activity elsewhere.
They also know that this knowledge is rarely fixed. Environments change, new false positives appear and attackers adapt their behavior. The investigation method has to evolve with them.
Runbooks provide a place for that expertise to accumulate.
Sekoia generates a runbook for every detection rule, including custom rules. Analysts can then adjust the rationale, legitimate scenarios and investigation questions to reflect what they know about the threat and their own environment.
If an investigation uncovers a better question, it can be added. If a false-positive pattern becomes familiar, it can be documented. As the organization’s infrastructure or risk profile changes, the runbook can change with it.
Over time, the detection becomes more useful because the knowledge around it becomes richer. What began as the experience of one analyst becomes part of the investigation process available to the whole team.
The question every detection should answer
Detection engineering has become very good at identifying behavior that may be suspicious. The natural next question is what the SOC should do with that information.
Runbooks bring that question into the detection itself. They give analysts and agents a shared understanding of why the alert exists, what might legitimately explain it and which evidence should be collected before deciding what happened.
A detection finds the signal. A runbook helps the SOC understand it.
Every detection should have both.
