How should organisations design security controls so they still work when people bypass the intended process?

Organisations should assume bypass will happen and design controls around real behaviour, not ideal behaviour. That means building governance into the full process, including business requirements, policies, procedures, reporting, auditing, and control ownership. A control is only effective if it still protects the system when someone ignores the intended path or makes an exception for convenience.

Design controls for the way work really happens

The safest control is not the one that assumes perfect compliance, it is the one that still holds when an operator takes a shortcut, an approver is unavailable, or a business team invokes an exception. That means designing for the actual path of work, including manual workarounds, delegated approvals, and emergency handling, so the control does not disappear the moment someone stops following the ideal process.

That design starts with defining the control objective in business terms, then mapping every place that objective can be bypassed, weakened, or deferred. If the control only exists in a single system step, it is fragile; if it is reinforced by policy, ownership, logging, review, and escalation, it is much harder to sidestep without leaving evidence.

Strong controls therefore combine preventive and detective elements. A preventive gate can slow or block the action, but a detective check should still surface the exception, because process bypass is often rationalised as convenience rather than treated as a control failure. Controls should assume exception paths will be used, not treated as rare accidents.

Build governance into the whole workflow, not just the approval step

When organisations design around the happy path alone, control effectiveness collapses in the gap between policy and practice. Governance needs to sit across the full workflow: business requirements should state what must be controlled, policies should define the rule, procedures should make the rule executable, reporting should show when it is bent, auditing should confirm it is operating, and ownership should be explicit enough that someone is accountable when the process is bypassed.

This is why control ownership matters as much as the control itself. If no team owns exceptions, nobody measures them. If no one is responsible for review, shortcuts become normal. If the business can override a control without visibility, the organisation has not designed a resilient control, it has designed a preference.

Good design also distinguishes between legitimate exception handling and uncontrolled bypass. A true exception should be time-bound, documented, reviewable, and tied to an accountable approver. A convenience bypass should be treated as a failure of control design, because the moment an exception becomes routine, the control is no longer the control.

Make bypass visible, bounded, and expensive to normalise

Controls work better when bypass creates friction and evidence. That does not mean every exception must be denied, but it does mean the organisation should be able to see who bypassed the intended path, why, what was approved, and what compensating checks were applied. Visibility turns informal workarounds into governed events instead of invisible drift.

Where a process is especially exposed, organisations should look for layered control patterns such as dual approval, independent review, periodic recertification, and audit trails that cannot be altered by the same team that created the exception. Those measures do not eliminate bypass, but they reduce the chance that bypass becomes an unobserved control gap.

At scale, the main failure mode is normalisation. If dozens of teams use the bypass path, the exception stops being an exception and becomes the operating model. That is the point at which the organisation should redesign the control, not simply remind people to comply.

Standards & Framework Alignment

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

NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	CA-7 — Continuous Monitoring	Control bypass needs ongoing visibility to confirm controls still operate in practice.
	AU-6 — Audit Record Review, Analysis, and Reporting	Exceptions and workarounds must be reviewable through logs and reports.
	PM-9 — Risk Management Strategy	Designing for real behaviour requires a strategy that anticipates control failure and exceptions.
Recommendation — Monitor control performance and exception use continuously so bypass patterns are detected quickly. Review audit data for override paths, exception approvals, and skipped workflow steps. Embed exception handling and control-bypass assumptions into the organisation's risk strategy.
ISO/IEC 27001:2022	A.5.15 — Access control	Access controls must still enforce policy when users try to take a shortcut or use an exception.
Recommendation — Define access rules so bypass paths still preserve intended restrictions and approvals.
CIS Controls v8	CIS-5 — Account Management	Bypass often appears where ownership and approval paths are weak or informal.
Recommendation — Assign clear account and control ownership so exceptions cannot be used without accountability.

Practitioner Guidance

What to prioritise: Start with the controls whose failure creates the largest blast radius, then identify the most common shortcuts and exception routes. The controls that matter most are the ones people can actually avoid under pressure, not the ones that only fail in theory.

What to verify: Test whether the control still protects the asset when the approval is delayed, the workflow is skipped, or the request is processed manually. If the answer depends on perfect process adherence, the control is not yet resilient.

Common mistake: Teams often harden the formal procedure and assume behaviour will follow. In practice, resilient design treats bypass as a predictable operating condition and builds review, evidence, and accountability into the exception path itself.

Practitioner takeaway: A control is mature only when it remains effective under convenience, pressure, and exception handling, because those are the conditions under which real organisations actually operate.