Set clear behavioural expectations, but make the secure path the easiest path. Employees should know what to report, how to handle devices, and when to escalate suspicious activity, while the organisation provides the tools, recovery options, and legal clarity needed to act consistently. Shared responsibility only works when policy and support are both real.
What shared responsibility should actually mean here
Balanced responsibility is not “every employee secures everything” and it is not “security handles all mistakes after the fact.” The better model is shared accountability with role clarity: staff are responsible for following a small set of observable behaviours, and the organisation is responsible for making those behaviours practical, consistent, and supportable. That includes clear reporting paths, usable controls, and a response process that does not punish early disclosure.
In practice, this balance works when the organisation defines the few actions employees must take every time, then removes friction from doing them correctly. If people need to improvise to report an incident, protect a device, or ask for help, the policy may exist on paper but the operating model has already failed.
The secure path should be the default path. That usually means visible reporting channels, pre-approved recovery steps, and simple guidance for high-frequency situations such as lost devices, suspicious messages, and accidental policy violations. Where the expected action is rare, high-stakes, or hard to judge, the organisation should make escalation easier than self-judgment.
Where employee responsibility ends and organisational support begins
Employees should own the actions they can reasonably see and influence: report anomalies, protect assigned devices, avoid sharing secrets, and escalate when something feels wrong. The organisation owns the conditions that make those actions reliable: training, endpoint controls, backup and recovery, incident triage, and legal or HR clarity around acceptable reporting and response.
This division matters because accountability breaks down when the burden shifts too far toward the individual. If someone is expected to recognise a compromise, contain it, preserve evidence, and decide whether it is a policy breach or a security incident, the result is usually delay. A well-designed process makes the first step obvious and the next step supported.
Support also means reducing ambiguity. Employees should not have to guess whether they are allowed to forward a suspicious email, isolate a device, or use an approved recovery channel. Clear permissions and predefined playbooks create faster action than broad reminders to “be vigilant.”
For secure behaviour to stick, the organisation should treat convenience as a control objective, not an afterthought. If the approved route is slower than the unsafe one, people will work around it. Good support makes the safe action the easiest, fastest, and least embarrassing option.
How to make expectations enforceable without turning them into blame
Enforcement should focus on repeatable behaviour and risk reduction, not punishment for every mistake. The right standard is whether the organisation gave people a realistic way to comply and whether the employee used or ignored that path. That distinction matters because support failures often masquerade as user failures.
One practical test is whether a reasonable employee could follow the policy under normal working pressure. If the answer is no, the control is too abstract to rely on. Policies that depend on perfect memory, perfect judgement, or perfect timing do not scale well in daily operations.
Another test is whether the organisation can demonstrate that reporting, escalation, and recovery are actually usable. A hotline no one answers, a form no one monitors, or a recovery process that takes days all weaken the responsibility model. The support function must be real enough that employees trust it before they need it.
Well-run shared responsibility also reduces uncertainty during incidents. A fast, documented escalation path helps preserve evidence, contain exposure, and keep managers, IT, security, and legal aligned. Where those paths are missing, people improvise, and improvisation is where avoidable risk accumulates.
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.OC-01 — Organizational Context | Shared responsibility depends on clear role expectations and operating context. |
| PR.AT-01 — Awareness and Training | Employees must know how to report, escalate, and handle devices safely. | |
| RS.CO-02 — Incident Reporting | The question centres on making suspicious activity reporting clear and usable. | |
| Recommendation — Define employee and organisation responsibilities in the cybersecurity operating model. Train staff on reporting, escalation, and safe device handling. Establish a simple incident reporting path employees can use quickly. | ||
| NIST SP 800-53 Rev 5 | AT-2 — Awareness Training | Employees need role-appropriate security behaviour expectations and support. |
| IR-6 — Incident Reporting | Employee escalation of suspicious activity is a core control expectation here. | |
| PL-4 — Rules of Behavior | Clear behavioural expectations are central to balancing responsibility and support. | |
| Recommendation — Provide role-based awareness training for reporting and escalation. Implement a clear process for timely incident reporting and escalation. Publish rules of behaviour that define required employee actions. | ||
| ISO/IEC 27001:2022 | A.5.10 — Acceptable use of information and other associated assets | The topic concerns clear employee behaviour expectations and practical support. |
| A.5.24 — Information security incident management planning and preparation | Employees need a realistic path to report and escalate suspicious activity. | |
| Recommendation — Set acceptable-use expectations that employees can follow consistently. Prepare incident reporting and escalation paths that staff can use easily. | ||
Practitioner Guidance
What to prioritise: Define the small number of employee actions that matter most, then design support around those actions first. Reporting, device handling, and escalation should be simpler than any workaround.
What to verify: Test whether an employee can complete the secure action in one pass, with one approved channel, without needing tribal knowledge. If they cannot, the responsibility model is not operational yet.
Decision rule: If a task can create material exposure, make the safe path default and the exception path explicit. If you cannot explain who owns the exception, the policy is too vague to enforce.
What practitioners underestimate: People rarely fail because they reject security; they fail because the organisation made the correct behaviour harder than the risky one. Shared responsibility only works when the system is designed for ordinary users under ordinary pressure.
Practitioner takeaway: Balance is achieved when employees are accountable for noticing and escalating, while the organisation is accountable for making secure action easy, fast, and unambiguous.
Related resources from NHI Mgmt Group
- How should organisations balance security with employee productivity in identity controls?
- How do organisations balance employee application choice with security and compliance requirements?
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities at scale?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org