The teams that design and enforce the policy should own the risk when controls are unrealistic or poorly supported. If a requirement is hard to follow, the problem is often the design, the rollout, or the lack of assistance, not the user alone. Accountability should include policy makers, managers, and support teams, especially when compliance depends on their decisions.
When policy is hard to follow, who owns the risk?
Risk ownership should sit with the teams that chose the control design, approved the rollout, and are responsible for support. If remote work policy is difficult to follow in practice, that is usually a control design and enablement problem as much as a user behaviour problem. Accountability should track where the decision and the constraint came from.
Why difficult remote work policies create shared accountability
A policy that depends on perfect user behaviour, unclear steps, or tools people cannot reliably use creates predictable failure. In remote work, that can mean inconsistent VPN use, weak device hygiene, unsupported exceptions, or people bypassing controls to get work done. The risk comes from the gap between stated requirements and operational reality.
Good ownership separates policy intent from policy execution. Security, IT, HR, and business management all influence whether a requirement is usable, measurable, and enforceable. If a control only works when staff absorb the friction without support, the organisation has pushed risk downward instead of managing it.
What good ownership looks like in practice
Effective ownership assigns the risk to the function that can change the underlying condition. That usually means the policy owner, the control owner, and the operational support team must share accountability for usability, communication, exceptions, and remediation. End users still have responsibilities, but they should not carry the whole burden when the system is unrealistic.
A practical test is whether the organisation can explain why the control is difficult, who approved that difficulty, and what support exists to make compliance realistic. If no one can answer those questions, the policy is being treated as a rule instead of a managed security control.
- Policy owners should own the design choice.
- Control owners should own enforceability and monitoring.
- Support teams should own enablement, documentation, and exception handling.
- Managers should own adoption in their teams when compliance depends on workflow changes.
Risk and Threat Considerations
When remote work controls are hard to follow, the main risk is not just non-compliance, it is predictable workarounds that weaken security and obscure accountability. People will route around friction, especially when the control blocks urgent work or lacks practical support.
Failure mechanism: Unusable policy design, weak rollout, or poor tooling drives shadow exceptions, inconsistent enforcement, and avoidable exposure across endpoints, access paths, and data handling.
Impact: The organisation gets a false sense of control while real behaviour drifts, making incidents harder to detect, investigate, and attribute to the right decision owners.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Remote-work policy ownership is a risk governance decision. |
| GV.RR-01 — Roles, Responsibilities, and Authorities | The question is about who should own accountability for difficult-to-follow controls. | |
| Recommendation — Assign risk ownership to the control owner and review whether the policy is feasible to operate. Define who owns policy design, enforcement, exceptions, and support. | ||
| NIST SP 800-53 Rev 5 | AC-1 — Access Control Policy and Procedures | Remote-work rules are an access-control policy matter when they govern work access. |
| AC-7 — Unsuccessful Logon Attempts | Difficult controls often surface in authentication and access enforcement behaviour. | |
| Recommendation — Document who approves, maintains, and enforces the remote-work control. Monitor failed access and usability friction to identify controls that drive workarounds. | ||
| ISO/IEC 27001:2022 | A.5.1 — Policies for information security | The issue concerns policy ownership when security requirements are impractical. |
| Recommendation — Review policy ownership and update controls that cannot be followed consistently. | ||
Practitioner Guidance
What to verify: Check whether the policy can be followed by default in the tools people actually use, not only in the ideal process document. If users need repeated exceptions to do ordinary work, the control is misaligned with the operating model.
Decision rule: If the friction is systemic, treat it as a control-design and ownership issue first, then assess user compliance. If the friction is isolated, handle it as a local exception with clear expiry and review.
Practitioner takeaway: The right question is not whether users complied perfectly, but whether the organisation designed a control that people could follow without routinely creating new risk.
Related resources from NHI Mgmt Group
- How should organisations secure remote work without making security policies too hard for employees to follow?
- Why do non-human identities create compliance risk even when policies exist?
- How should security teams reduce OT remote access risk without blocking maintenance work?
- How should security teams reduce remote-work identity risk for employees using home offices?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
