What breaks when behaviour baselines are missing from insider programmes?

The SOC can still see events, but it cannot tell whether they are normal, risky, or malicious. That leaves teams reacting to volume instead of meaning. Without baselines, low-and-slow activity such as gradual repository cloning, repetitive downloads, or unusual admin use blends into ordinary business noise.

Why This Matters for Security Teams

Behaviour baselines are the reference point that turns telemetry into judgement. In insider programmes, that matters because the challenge is rarely a single loud event. It is usually a sequence: a user, contractor, or service account acting within some permission boundary while gradually shifting away from expected patterns. Without a baseline, the team may still have logs, but it lacks context for prioritisation, escalation, and investigation. That gap weakens detection engineering, alert triage, and case closure quality.

This is especially important where identity and privilege are already noisy. Admin consoles, shared operational access, and automation often create legitimate exceptions that look suspicious in isolation. Baselines help distinguish routine variance from genuine deviation, which is why control frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls place weight on monitoring, auditability, and response readiness rather than simple collection.

In practice, many security teams encounter insider risk only after the activity has already blended into normal operations, rather than through intentional behavioural modelling.

How It Works in Practice

A useful baseline is not just a threshold, and it is not a one-time profiling exercise. It is a contextual profile of what “normal” looks like for a person, role, device, repository, time window, and location. Mature programmes build that profile from identity events, endpoint telemetry, cloud activity, access logs, DLP signals, and privilege use. The goal is to compare behaviour against a moving reference point, then score deviations that matter operationally.

In practice, teams usually apply baselines in layers:

• Identity layer: typical logon times, geographies, MFA patterns, and privilege elevation frequency.
• Data layer: normal repositories, file types, download volume, and exfiltration paths.
• Admin layer: expected commands, ticket correlation, and break-glass usage.
• Peer layer: what is normal for a job family, not just an individual.

This is where the intersection with insider risk and NHI governance becomes relevant. Service accounts, automation tokens, and AI agents can also exhibit “behaviour,” but that behaviour is defined by configuration and execution patterns rather than human routines. Baselines should therefore be tuned separately for human users and non-human identities, otherwise automation can generate false positives or hide abuse inside ordinary machine traffic.

Teams often anchor this work in detection and response guidance from MITRE ATT&CK, then translate it into alert logic, hunt hypotheses, and analyst playbooks. Where machine learning is used, NIST’s AI guidance in NIST AI Risk Management Framework is a useful reminder that model outputs still need governance, validation, and human review. These controls tend to break down when identity data is fragmented across SaaS, on-prem, and cloud systems because no single telemetry source is rich enough to define normal behaviour reliably.

Common Variations and Edge Cases

Tighter behavioural baselining often increases engineering and privacy overhead, requiring organisations to balance better detection against data minimisation, analyst workload, and employee trust. That tradeoff is real, and current guidance suggests there is no universal standard for how granular baselines should be.

For high-change environments such as DevOps, M&A integration, or seasonal operations, baselines can become stale quickly. In those settings, teams should expect more tuning and more deliberate exception handling. Role-based baselines are usually more stable than individual baselines, but they can miss malicious outliers inside a legitimate peer group. Conversely, highly personalised baselines can flag ordinary business travel, incident response, or temporary project work as suspicious.

Edge cases also matter for privileged access. A one-time admin action may be legitimate, but if that access is not tied to a change ticket, break-glass approval, or expected maintenance window, the programme loses confidence in its own exceptions. The same issue appears with non-human identities: a deployment pipeline or AI agent may suddenly perform repetitive access or retrieval activity at a scale that is normal for automation but abnormal for its own recent history. That is why baselines should be built with identity type, purpose, and allowable variance in mind. A baseline strategy breaks down when the organisation treats every account the same, because humans, service principals, and autonomous agents do not share the same behavioural shape.

Related resources from NHI Mgmt Group

• What breaks when insider threat programmes focus only on employee behaviour?
• What breaks when insider-risk programmes only monitor people and not AI agents?
• What breaks when attack path analysis is missing from AppSec programmes?
• What breaks when insider risk programmes focus on alert counts instead of outcomes?