From Alert Queue to Incident List: What Living Security’s Open HRM Framework 2.0 Actually Changes

SeaPRwire – One phishing message, one link click, one unusual login. Each of the three, on its own, is an ordinary alert that a security team might triage, document and close. Read as a sequence, they sketch an account takeover in progress, with a window to intervene before the attacker gets anywhere. Living Security’s new framework release is organized around exactly that gap between the signals a team already collects and the incident those signals add up to.

HRM Framework 2.0, announced October 29 by the Austin-based Human Risk Management vendor, is an open resource published at humanriskmanagement.com under a Creative Commons Attribution 4.0 license. It organizes human and AI agent risk around 10 breach scenarios and provides a structure for identifying exposure, choosing interventions and measuring progress. It maps to the NIST Cybersecurity Framework and MITRE ATT&CK, and it is available to security teams, vendors and researchers with attribution. There is no charge and no gate.

Ashley Rose, the company’s CEO and co-founder, frames the framework around a single question: what incident are we trying to prevent? The framing matters because most security tooling hands teams signals sorted by the product that generated them — one queue from the email gateway, another from identity, a third from the endpoint. Those signals arrive organized by vendor, not by the incident they might belong to. A framework that starts from the incident and works backwards is a workflow inversion, at least on paper. Whether the ten scenarios actually change which interventions teams pick is the work the framework has to do.

The mechanics are straightforward. The framework connects signals across risk domains to cohorts of people or agents with shared exposure, and to activity sequences that suggest where risk is heading. Interventions are mapped to the underlying risk: risky behavior calls for coaching or training, while exposure tied to permissions calls for a change to security controls. A maturity model and self-assessment let teams score their ability to identify emerging risk, anticipate incidents and act before impact, then prioritize what to improve.

Alongside the framework, Living Security is incorporating it into the Living Security Platform, mapping the breach scenarios to platform signals, cohorts and playbooks. The stated goal is a chain that runs from identifying a scenario to understanding who is exposed, selecting an intervention and tracking how risk changes afterward. “The framework gives teams a way to connect the risk they see to the action they take,” said Chris Poirel, Head of Data Science at Living Security. “We’re building that approach into the platform so practitioners can use the same structure to understand exposure, guide their response and measure how risk changes afterward.”

The split between the open artifact and the commercial product deserves a plain reading. The framework costs nothing, carries a recognized license and aligns to two widely used reference models, which makes it easy for practitioners to adopt and easy for other vendors to build on. The platform is the revenue, and the framework now doubles as its organizing schema. Publishing open frameworks to establish category vocabulary is a familiar playbook in enterprise security, and there is nothing hidden about it here: the scenarios, the cohorts, the sequences and the intervention mapping are all public. What the company sells is the automation of that structure against live customer data.

The AI agent portion is the part with the least settled ground. As agents gain access to business systems and sensitive data, the framework brings agent activity and human accountability into the same view of workforce risk. That is the right abstraction — an agent acts through a human’s identity, under a human’s decisions, and its exposure is inseparable from its owner’s. The announcement, however, does not describe how agent activity is collected, how an agent’s exposure is measured, or how accountability gets assigned when an agent does the touching. The hard questions are the ones an HRM framework will eventually have to answer: which agent touched what, who owns it, and what happens to its access when that person leaves the company. Version 2.0 names the problem; the mechanics remain open.

The self-assessment and maturity model give teams a way to locate themselves on the framework today. That is useful for a security team planning a year of work, and it is also useful for a vendor qualifying leads. Both things can be true.

Where the framework proves itself or doesn’t is narrow and specific. A team that runs the self-assessment, picks a scenario, and selects an intervention ends up either doing something it would not have done from its existing alert queue, or doing the same thing with new labels attached. Everything else — the license, the mappings, the ten scenarios — is scaffolding around that one outcome.