Start human risk program: 90-day launch roadmap

To start human risk program work, treat the launch as an operating decision, not another annual training assignment. Security leaders need a defined risk question, a defensible baseline, a focused pilot, and owners who can turn evidence into action. The best first 90 days create a repeatable cycle of assessment, intervention, measurement, and improvement.

Learn how Living Security can help you start a human risk program

How do you start a human risk program with confidence?

This launch sequence keeps the work practical. It also prevents a common failure mode: choosing a tool or training calendar before deciding what the program must change. Begin with the decisions leaders need to make, the workflows where exposure matters, and the evidence available to guide those decisions.

Human Risk Management (HRM), as defined by Living Security, extends beyond passive awareness activity. It connects people, behavior, access context, and threats so security teams can prioritize support and reduce meaningful exposure. If the organization needs foundational context, link the first mention of Human Risk Management to the existing definition pillar rather than creating a competing introductory article.

A new program should produce four practical outcomes:

• A shared risk view. Bring behavior, identity and access, and threat context into one decision process. Living Security describes analysis across more than 200 behavioral, identity, and threat signals. Use that breadth to identify patterns and risk trajectories, not to create a static list of people.
• Targeted behavior change. Match a risk pattern to an intervention, such as focused coaching, a safer workflow, an access review, or a manager conversation. The intervention should make the safer action easier to understand and follow.
• Clear ownership. Security may sponsor the effort, but identity, privacy, legal, communications, business leaders, and managers all influence whether it works. Document who makes each decision and who reviews sensitive findings.
• Evidence of progress. Select a small set of measures before the pilot begins. Pair activity indicators with changes in exposure, incident patterns, remediation time, and movement in higher-need populations.

These outcomes create a useful launch gate. If the program cannot connect observed risk to an accountable action and a measurable result, the scope is not ready. Start with the business processes, access patterns, threats, and employee workflows that matter most. A people-first foundation builds credibility with the stakeholders whose cooperation determines success.

What should the baseline include before you choose a pilot?

A baseline is not a permanent score assigned to employees. It is a time-bound view of behaviors, access conditions, threats, safeguards, and operational context. It gives leaders a starting point for selecting a pilot and a fair way to judge whether an intervention changed the conditions that create exposure.

Use the following sequence to build a baseline:

1. Set the decision the baseline must support. Define the outcome in operational terms. You might want to reduce risky handling of sensitive data, improve reporting of suspicious messages, or shorten remediation time for exposed identities. Name the decision makers who will use the findings.
2. Inventory three evidence pillars. For behavior, review reporting habits, phishing susceptibility, policy exceptions, security events, and workflows where risky actions occur. For identity and access, document privileged roles, unusual access patterns, dormant accounts, authentication coverage, third-party access, and joiner, mover, and leaver processes. For threat, map recent incidents, active scenarios, exposed systems, and groups most likely to encounter those conditions.
3. Choose repeatable measures. Select measures that can be collected consistently before and during the pilot. Useful starting points include phish-prone percentage, reporting behavior, training completion, incident frequency among higher-need groups, time to remediate, and movement between risk cohorts.
4. Record evidence quality. Note the source, age, owner, definition, and limitations of each data point. A low reporting rate may reflect friction in the reporting process rather than safer behavior. A concentration of incidents in one group may reflect greater exposure to sensitive work rather than intent.
5. Set privacy and governance boundaries. Explain what data is collected, why it is needed, who can access it, how long it is retained, and how it will be used. Prefer aggregated or role-based views when individual detail is unnecessary. Involve privacy, legal, employee relations, and business partners before analysis begins.
6. Use the baseline to select the pilot. Choose a population with meaningful exposure, an engaged business owner, adequate evidence, and a realistic path to intervention. Document the selection rationale so the pilot is understood as a learning environment, not a judgment about a department or individual.

NIST Special Publication 800-50 Revision 1 recommends an ongoing approach to security and privacy learning that supports behavior change and continuous improvement. Read the NIST lifecycle guidance when setting the program's evaluation cadence. The baseline should make change visible without pretending that every organization starts from the same conditions.

How do you select pilot groups and stakeholders?

A pilot should be bounded enough for owners to learn quickly and broad enough to represent real operating conditions. Do not automatically select the entire workforce. Do not choose a single department only because its data is convenient. Instead, use the launch objective and baseline to choose a group with relevant exposure and enough variation to reveal where workflows, access, and behavior interact.

For an enterprise organization, useful selection factors can include access to sensitive systems, business criticality. Recent security events, remote or distributed work, role variety, shift patterns, and the availability of a participating manager. Include a practical comparison group when the program design allows it. Record the criteria before seeing the results, which reduces the temptation to change the definition after the pilot starts.

Give one executive sponsor real authority

An executive sponsor should connect the pilot to business risk, remove obstacles, and protect the work from becoming a side project. The sponsor may be a CISO or another security executive, depending on how decisions are made. Put the sponsor's role in writing. Include the outcomes the pilot will test, the decisions the sponsor owns, the review cadence, and the conditions for scaling.

Create a cross-functional owner group

Security should lead the risk question, but it should not design the program alone. Include security operations, identity and access, privacy, legal, communications, business leaders, and representatives from the pilot groups. Identity partners can explain access dependencies. Privacy and legal partners can set fair-use boundaries. Communications can shape useful rather than punitive messages. Business leaders can identify constraints that a central team may miss.

Assign one accountable program owner and define decision rights. Decide who can approve interventions, who reviews sensitive findings, how data is retained, and how participants can ask questions or report friction. The program should improve conditions and behavior, not create covert surveillance. Use aggregated reporting whenever it can answer the business question. This trust foundation makes the pilot a fair test.

A practical Human Risk Management framework can help stakeholders align on scope, ownership, and the relationship between behavioral change and the broader security program.

Which metrics show that the program is working?

A useful measurement model shows more than whether people completed an assignment. It connects behavior change to security outcomes across behavior, identity and access, and threat. Leaders can then see where exposure is changing, which groups need support, and whether remediation is becoming more efficient.

Use leading and lagging measures together. Leading measures show whether the program is influencing behavior before an incident occurs. Lagging measures show whether that change is reducing harmful outcomes. Neither category is enough on its own.

Measure movement, not just a point in time

Phish-prone percentage can establish a behavioral baseline, while completion indicates whether the intended intervention reached its audience. Pair those measures with incident frequency among higher-need groups. If completion rises but incidents do not improve, the content, timing, audience, or follow-up may need to change. If incidents fall in one cohort, investigate what differentiated it before making a broad claim.

Cohort movement is especially valuable. Track whether people move from higher-need to lower-need groups after targeted support, and examine how long that change lasts. Remediation time adds an operational lens. Measure the interval from identifying a condition that needs attention to completing the appropriate corrective action. Faster remediation can reduce exposure even before long-term behavior change is visible.

Set a cadence that supports decisions

Review leading measures often enough to adjust interventions. A monthly working review may fit the pilot's operating rhythm. Review lagging outcomes over a longer window so normal incident variation does not distort the conclusion. At quarterly leadership reviews, connect trends to reduced exposure, fewer disruptive events, faster response, and less manual effort.

Do not impose a universal target percentage on every organization. A regulated healthcare enterprise, a distributed workforce, and a company recovering from a major incident may begin from very different baselines. Define a starting point, choose a realistic direction of improvement, and document the business decision each metric informs. Living Security's human risk research provides additional context for outcome-oriented measurement, but each organization should validate its own baseline.

What should happen during the first 90 days?

A strong launch separates decisions that make the program workable from activities that can wait. The roadmap below is designed for teams establishing scope, evidence, ownership, and feedback loops before they scale.

1. Days 0 to 30: Set scope, baseline, and governance. Name the business problem. Define what is in scope and what is deferred. Inventory evidence across behavior, identity and access, and threat. Capture current measures, data limitations, owners, and privacy boundaries. Appoint an executive sponsor and one accountable program owner.
2. Days 31 to 60: Run a bounded pilot. Choose a population using pre-defined criteria. Confirm the baseline. Test a small set of interventions matched to observed behaviors and workflows. Coordinate communication with managers and give participants a clear way to ask questions or report friction. Review leading measures and operational effort often enough to adjust the approach.
3. Days 61 to 90: Evaluate and decide. Compare results with the starting baseline. Review behavior measures, incident patterns, remediation time, cohort movement, participant feedback, and the resources required to operate the program. Separate evidence of risk reduction from activity counts. End with an explicit decision to scale, revise and extend the pilot, or stop the approach.

During the first 90 days, keep a decision log. Record the original risk question, pilot criteria, intervention changes, metric definitions, unresolved limitations, and the reason for each major decision. This log helps leaders distinguish a useful learning cycle from a collection of disconnected activities.

Use the Living Security platform overview to understand how a broader risk intelligence approach can support visibility across a distributed workforce. The goal is not to introduce technology for its own sake. It is to create the evidence and operating habits that make the next decision better.

How do you improve and scale the program after launch?

Launch is the beginning of the operating model, not the finish line. Once the pilot produces a baseline and early lessons, move from a project mindset to a repeatable cycle of planning, action, review, and adjustment. NIST describes needs assessment, program design, implementation, and continuous evaluation as connected parts of an ongoing approach.

Build feedback loops into every cycle

Ask managers and participants whether the intervention was understandable, timely, accessible, and relevant to the work. Ask operators whether the process can be run without excessive manual effort. Treat friction as evidence. A confusing reporting path or poorly timed training message can create risk even when completion numbers look healthy.

Use maturity to guide expansion

Do not expand because the calendar says the pilot is over. Expand when the organization can explain what changed, why it changed, how confident it is in the evidence, and who will own the next stage. A Human Risk Management maturity model can help leaders discuss capabilities, governance, measurement, and operating discipline without treating maturity as a label assigned to people.

As the program grows, keep the same core disciplines: define a risk question. Use evidence from multiple sources, match intervention to context, protect privacy, measure outcomes, and communicate decisions clearly. A people-centered program earns durable participation because it helps employees and leaders understand the safer path.

What resources can support a new human risk program?

Most teams do not need to build every capability at once. Start with the questions, data, owners, and workflows already available. Then identify the gaps that prevent the program from making a timely and defensible decision.

• Use an existing security awareness training capability as one input, not as the entire measurement model.
• Review phishing risk and reporting workflows alongside access, identity, threat, and incident context.
• Give executives a concise view of the risk question, baseline, pilot result, limitations, and next decision.
• Keep participant communication focused on purpose, privacy, and the practical actions people can take.

The right approach depends on the organization's size, workforce, threat profile, existing controls, and data quality. For an enterprise team, Living Security positions Human Risk Management as a way to move from reactive training activity toward predictive, measurable risk reduction. The new program should test that promise against the organization's own evidence rather than assume an outcome.

Explore a practical path to launch your human risk program

Frequently Asked Questions

How do you build a human risk program from scratch?

Build it in stages. Define the business risk to reduce, inventory evidence across behavior, identity and access, and threat, establish privacy and ownership rules, choose a bounded pilot, and select repeatable measures. Use the first 90 days to test an intervention and decide whether to scale, revise, or stop based on evidence.

Which metrics should a new program track?

Track a balanced set of leading, operational, and lagging measures. Examples include reporting behavior, completion, cohort movement, intervention effort, time to remediate, incident frequency, and exposure events. Choose measures that answer a decision. Do not rely on a single score or compare an organization with a universal target that ignores its baseline.

Why is a pilot group important?

A pilot limits scope while giving the team a real environment in which to learn. The group should have meaningful exposure, an engaged owner, usable evidence, and a practical path to intervention. A bounded pilot makes it easier to protect privacy, measure change, adjust workflows, and explain what the results do and do not prove.

What should happen during the first 90 days?

Days 0 to 30 should establish scope, baseline, governance, and ownership. Days 31 to 60 should run the pilot and deliver targeted interventions. Days 61 to 90 should compare results with the baseline, review limitations and resources, communicate findings, and make an explicit decision about scaling or revising the program.