An organisation-specific baseline is the set of normal behaviours, relationships, and sequences that represent expected activity in a given environment. It is more useful than generic rules because it reflects how that business actually authenticates, communicates, and responds.
What Makes an Organisation-Specific Baseline Different
An organisation-specific baseline is not a generic policy template, it is the expected pattern of normal activity for one environment. It becomes useful because it reflects the systems, users, workflows, and exceptions that are actually present, rather than assuming a universal “normal.”
This matters because baseline quality depends on context. A finance workload, an engineering platform, and a customer portal may all have different authentication patterns, data flows, and response times, so a baseline must be built from observed behaviour and operational knowledge, not from a one-size-fits-all checklist.
What an Organisation-Specific Baseline Covers
A practical baseline usually captures normal source and destination relationships, typical process or service sequences, expected authentication methods, ordinary data access patterns, and normal administrative actions. It may also include time-of-day patterns, seasonal changes, and approved maintenance windows when those are part of routine operations.
The baseline is strongest when it describes relationships, not just individual events. For example, a login may be normal on its own, but the same login followed by an unusual host, unexpected privilege use, or a new data path may fall outside the expected sequence and deserve attention.
Because the baseline is specific to one organisation, it should evolve as the environment evolves. New applications, cloud migrations, mergers, and workflow changes can all make a previously valid “normal” pattern obsolete if the baseline is not refreshed.
How Baselines Support Detection and Analysis
Baselines are most valuable in detection engineering, triage, and investigation. They help analysts separate ordinary variation from meaningful deviation, which reduces alert noise and makes outliers easier to prioritise. In that sense, the baseline is a reference model for CIS Benchmarks-style hardening and for operational monitoring alike, because both depend on knowing what “expected” looks like.
They are also useful for understanding whether a change is benign or suspicious. If a backup job, service account, or admin workflow is part of the known pattern, then its activity can be interpreted in context instead of being treated as an isolated anomaly.
Well-built baselines improve investigation quality by giving analysts a sharper question: not merely “did something happen?” but “does this fit the known behaviour of this environment, this team, and this system?”
Limits, Drift, and False Confidence
Baselines are only as good as the data and judgement used to create them. If they are built too early, too narrowly, or from incomplete telemetry, they can miss important activity and make abnormal behaviour look ordinary. If they are too loose, they stop being useful because nearly everything fits.
Baseline drift is a common problem. Over time, repeated exceptions, tool changes, new integrations, and seasonal spikes can quietly rewrite the definition of normal. A baseline that is never reviewed may become a record of yesterday’s environment rather than a reliable control for today’s.
The other risk is overtrust. A baseline does not prove that activity is safe, it only says the activity resembles what has been seen before. Attackers can sometimes hide inside familiar behaviour, especially when they reuse normal accounts, approved tools, or routine communication paths.
Risk and Threat Considerations
Organisation-specific baselines can create blind spots when they are incomplete, stale, or built around noisy exceptions. If defenders treat “known normal” as equivalent to safe, unusual but legitimate changes may be ignored, while attacker activity that blends into routine patterns may be missed.
Failure mechanism: Weak baselines fail through drift, missing telemetry, and overbroad exception handling, which makes anomalous access, unusual sequence changes, or suspicious communication patterns harder to distinguish from ordinary business activity.
Impact: The result can be delayed detection, poor triage, and missed investigation opportunities, especially when compromise uses familiar accounts, approved services, or expected business workflows as cover.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Organisation-specific baselines reflect expected secure configurations and normal system states. |
| Recommendation — Use baselines to compare systems against approved secure configurations and flag drift. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | This term directly describes configuration baselines for a specific environment. |
| CM-6 — Configuration Settings | Baselines depend on defined expected settings and deviations from those settings. | |
| Recommendation — Establish and maintain environment-specific baselines as the approved reference state. Define and monitor configuration settings against the organisation's expected baseline. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to find potential cybersecurity events | Baselines improve monitoring by defining normal patterns for detection. |
| Recommendation — Compare monitored behaviour to the baseline to surface meaningful deviations. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Organisation-specific baselines are a configuration-management reference for expected state. |
| Recommendation — Maintain approved baselines and manage deviations through formal configuration control. | ||
Practitioner Guidance
Why practitioners should care: A baseline should be treated as an operational reference, not a static policy artifact. The most useful baselines are tied to specific systems, business processes, and ownership models so that analysts know what has actually been observed, approved, and maintained.
What to watch for: Repeated exceptions, unexplained drift, and baselines that are updated only after incidents are signs that the reference model is no longer trustworthy. When the environment changes, the baseline should change with it, or detection quality will degrade.
Practitioner takeaway: Build baselines from real production behaviour, review them on a defined cadence, and validate that the “normal” they encode still matches how the organisation operates.
Related resources from NHI Mgmt Group
- Why do organisation-specific behavioural baselines matter for detection?
- How do organisations decide whether to use organisation-specific feature flags in a B2B application?
- Why does compliance with SSL/TLS baseline requirements improve an organisation's ability to respond to cryptographic change?
- What are the signs that an organisation’s identity security baseline is not enough to stop account takeover?