Should security teams optimise for enforcement or for adoption?

Why enforcement and adoption are not opposites

Security teams usually get better outcomes when they stop treating enforcement and adoption as a binary choice. Enforcement gives the rule teeth, but adoption gives it durability: if users, engineers, and operators cannot follow a control in normal work, the organisation ends up with paper compliance and inconsistent reality. The practical target is a control that is usable by default and enforceable when it matters.

That distinction matters because many controls fail in the gap between policy intent and day-to-day execution. A standard that is too hard to use creates workarounds, shadow processes, and exceptions that quickly become the real operating model. By contrast, controls that fit the workflow are more likely to be applied consistently, which makes later enforcement credible rather than theatrical.

This is why adoption is often the first signal of whether enforcement will succeed. If the control path is obvious, low-friction, and supported by tooling, teams can measure whether the organisation is actually moving toward compliance instead of merely announcing it. If the path is confusing or punitive, exceptions multiply and the control becomes difficult to defend even when leadership wants strict enforcement.

How to think about standards, exceptions, and usability together

The right question is not “which is more important?” but “which one is currently failing?” In mature programmes, adoption is the leading indicator and enforcement is the backstop. If adoption is weak, the control design is usually too burdensome, too vague, or too detached from how work is performed. If adoption is good but enforcement is absent, the programme may look healthy until a high-value case slips through.

Usability is not a soft concern, it is part of control design. Teams that build the exception path into the standard from the start usually get more honest reporting, better telemetry, and a clearer picture of where policy is truly infeasible versus merely inconvenient. That is materially different from allowing uncontrolled exceptions, because documented exceptions can be reviewed, time-bound, and revisited as the environment changes.

For teams operating under formal security or regulatory obligations, this balance also affects defensibility. Frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls and NIST Cybersecurity Framework 2.0 both assume controls are implemented, measured, and improved, not just published. If adoption is poor, the governance story weakens because the organisation cannot demonstrate that controls are operating as intended.

What practitioners should optimise for in practice

Security programmes work best when they optimise for adoption first, then harden enforcement around what has proven workable. That does not mean delaying every rule until everyone is happy; it means starting with a usable standard, validating the real workflow, and then making noncompliance increasingly visible and costly. Controls that are hard to use should be redesigned before they are heavily enforced, unless the risk is so immediate that a strict boundary is unavoidable.

In practice, the strongest pattern is a staged model:

• Define the minimum control standard clearly.
• Make the normal path easy enough that most users choose it.
• Measure exception volume, duration, and repeatability.
• Use exceptions as feedback for refinement, not as permanent policy debt.
• Escalate only where the control is both feasible and materially protective.

That approach is more durable than trying to “force compliance” everywhere, because it separates genuine control gaps from adoption problems. It also gives leadership a better decision basis when they need to choose between a stricter rule and a more usable one. The best programmes make enforcement selective and meaningful, not constant and brittle.

Practitioner Guidance

What to prioritise: Start by identifying which controls are widely bypassed, overridden, or handled through informal exceptions. Those are the controls where adoption is failing and where redesign will usually improve security faster than stricter reminders.

What to verify: Check whether the “enforced” control has a supported path in the real workflow, not just in the policy document. If teams cannot complete the task cleanly, then the organisation is relying on compliance theatre rather than operational control.

Decision rule: If a control is important but routinely avoided, simplify the path before escalating punishment; if a control is easy to use but still bypassed, tighten enforcement and accountability.

Practitioner takeaway: The goal is not maximum enforcement or maximum convenience, it is a control model that people can actually follow and that security can still defend when exceptions must be limited.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?