What is the difference between a locked baseline policy and ordinary editable authorization rules?

A locked baseline policy is created to stay fixed, so critical access rules cannot be casually altered once established. Ordinary editable rules can be modified as teams add roles, resources, or environment-specific exceptions. The distinction matters because the baseline preserves authorization integrity, while editable rules provide flexibility around that core control.

Why a locked baseline is different from editable authorization rules

A locked baseline policy is the part of an authorization model that should not drift every time a team adds a role, exception, or temporary exception path. Editable rules are the flexible layer around that core, where administrators can adjust access for new services, environments, or business needs without redefining the underlying access model. The practical distinction is stability versus agility.

That split matters because authorization mistakes are rarely about having too few rules, they are usually about rules changing too freely. A fixed baseline gives you a dependable reference point for what must always be true, while editable rules absorb the day-to-day variation that comes from real operations.

It is helpful to think of the locked baseline as the control plane for intent, and the editable rules as the operational layer for exceptions and expansion. When the baseline is treated as mutable, teams often end up normalising exceptions into permanent access paths, which gradually weakens the original design.

What the baseline preserves, and what editable rules are allowed to do

The baseline should preserve the non-negotiable access boundaries: who can reach sensitive resources, which duties must remain separated, and what minimum privilege must always apply. In practice, that is the layer you want protected from casual edits, because it encodes the security assumptions the rest of the model depends on.

Editable rules exist to express context. They let teams add new application roles, map new resources, or create environment-specific allowances without forcing a redesign of the whole policy set. That is why they are useful in large systems: they support change, but they should not be used to overwrite the control logic that keeps the authorisation model coherent.

A locked baseline gives you consistency across teams and environments.
Editable rules let you adapt to new resources, business units, and operational exceptions.
The safest pattern is to keep the core rule fixed and move variation into the surrounding policy layer.

In many organisations, this separation is what keeps authorisation understandable. Once the same rule set is expected to handle both core security decisions and ad hoc business exceptions, it becomes difficult to tell which access is intentional and which access only survived because nobody wanted to break an application.

Risk and Threat Considerations

A locked baseline reduces the risk of accidental privilege expansion, while editable rules introduce the possibility of silent drift if changes are not reviewed carefully. The main threat is not usually a dramatic policy failure, but a slow accumulation of exceptions that makes excessive access look normal.

Failure mechanism: teams edit ordinary rules to satisfy operational pressure, then reuse those exceptions as precedent until the baseline no longer reflects the original security intent. Over time, this can erode least privilege and make authorisation reviews less meaningful.

Impact: access becomes harder to reason about, privileged paths multiply, and a future compromise or misconfiguration can affect more resources than the original design allowed. In a large estate, that creates broader exposure and weaker accountability.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC-4 — Access Permissions Management	Supports keeping core access rules controlled and least privilege intact.
Recommendation — Apply PR.AC-4 to keep baseline access permissions tightly governed and reviewed.
CIS Controls v8	6.1 — Establish an Access Control Management Process	Applies because the question is about how access rules are governed and changed.
Recommendation — Use CIS 6.1 to define which authorization rules are fixed and which can be changed.
OWASP Non-Human Identity Top 10	NHI-06 — Secrets and Credential Management	Relevant because durable authorization baselines often protect privileged non-human access paths.
	NHI-07 — Least Privilege and Access Governance	Directly supports distinguishing fixed baseline authorization from flexible exceptions.
	NHI-10 — Lifecycle Management and Offboarding	Relevant where editable rules create lingering access that should be retired or revoked.
Recommendation — Use NHI-06 to keep privileged access paths stable and prevent ad hoc rule drift. Apply NHI-07 to keep the least-privilege baseline fixed and exception rules narrowly scoped. Use NHI-10 to remove stale editable access rules before they become permanent exposure.

Practitioner Guidance

What to prioritise: lock the rules that define the security boundary, then allow change only in the smaller set of rules that describe business variation. If a proposed edit changes who should fundamentally be trusted, it belongs in the baseline review path rather than the ordinary change path.

What to verify: confirm that editable rules cannot bypass the baseline through wildcard access, inherited privilege, or environment crossover. The control is only sound if reviewers can still explain which rule is authoritative when the two layers appear to conflict.

Common mistake: treating every exception as harmless because it is documented. Documentation does not stop policy drift, and a well-documented exception can still become an enduring access weakness if it is never re-evaluated.

Practitioner takeaway: the goal is not to freeze all authorisation change, it is to freeze the rules that define trust so operational flexibility cannot quietly rewrite the security model.