How should security teams launch a human risk program in the first 90 days?

Why This Matters for Security Teams

A first 90-day human risk program is less about launching awareness content and more about proving that people-related controls can reduce measurable business risk. The common mistake is to start with training completion or phishing clicks as the goal, then discover those metrics do not map cleanly to incidents, privilege misuse, or policy exceptions. A better starting point is to define the risk scenario, the population in scope, and the decision the programme is meant to improve, then anchor that work to the NIST Cybersecurity Framework 2.0.

This matters because human risk is often a control gap, not just a behaviour gap. Weak identity hygiene, overbroad access, poor escalation paths, and inconsistent response to suspicious activity all create conditions where one mistake becomes an incident. A credible 90-day programme should therefore connect people-facing interventions to access governance, incident patterns, and business criticality. Security teams that fail to do this usually end up optimising for visible activity rather than risk reduction. In practice, many security teams encounter the real failure only after a risky approval, credential misuse, or policy exception has already been exploited, rather than through intentional measurement.

How It Works in Practice

The first 90 days should run like a contained security project with clear ownership, a limited scope, and explicit success criteria. Start by selecting one or two risk scenarios that matter to the business, such as credential theft, unsafe approval behaviour, or misuse of privileged access. Then define the baseline across three lenses: behaviour, identity and access, and threat exposure. That baseline should answer what users do, what access they have, and which attack patterns are most likely to reach them.

Practically, the programme should include:

• a sponsor who can make policy and resourcing decisions
• a privacy review to ensure data collection is proportionate and documented
• an agreed metric set that is stable enough to compare over time
• a short list of interventions, such as role-based coaching, just-in-time prompts, or targeted policy changes
• a review cadence that compares outcomes with the baseline before expanding scope

For measurement and control design, teams can map the work to NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where monitoring, awareness, access enforcement, and privacy requirements overlap. That helps avoid a common weakness in human risk efforts, where data is collected without a clear control objective or retention rule. Behavioural data should be used to improve interventions, not to create a surveillance culture.

Good teams also distinguish between leading indicators and outcome measures. A drop in risky clicks may be useful, but only if it correlates with reduced exposure, faster reporting, fewer unsafe approvals, or better adherence to access policy. If the pilot changes behaviour but not risk, it needs redesign. These controls tend to break down when telemetry is fragmented across email, IAM, ticketing, and endpoint tools because attribution becomes too weak to support credible decisions.

Common Variations and Edge Cases

Tighter human risk measurement often increases privacy, legal, and change-management overhead, requiring organisations to balance early visibility against trust and operational friction. Current guidance suggests this tradeoff should be resolved up front, not after employees react to the programme.

Some environments need a different emphasis. In regulated sectors, the first 90 days may focus more on auditability, role clarity, and exception handling than on behaviour nudges. In high-privilege environments, identity and access controls may matter more than broad workforce awareness, because the highest-risk failures often involve approvals, entitlement creep, or misuse of admin paths. In distributed or contractor-heavy organisations, the programme may also need separate baselines for workers with different access models.

There is no universal standard for the “right” metric set. Best practice is evolving toward a small number of metrics that are interpretable, repeatable, and tied to a specific risk decision. If a team cannot explain how a metric changes an action, it is probably not a useful metric. Human risk programmes also fail when leaders expect immediate cultural change; the first 90 days should validate whether the control model works, not claim that the entire workforce has changed.

Where the programme touches identity, the strongest outcomes usually come from pairing human risk signals with access governance, rather than treating behaviour in isolation. That is where a human risk effort becomes a security programme instead of a communications campaign.

Related resources from NHI Mgmt Group

• How should security teams turn cybersecurity awareness month into a year-round human risk program?
• How should security teams implement PKI in the first 90 days of a rollout?
• How should security teams reduce risk from overprivileged non-human identities?
• How should security teams reduce the risk from leaked non-human credentials?