An AUP focuses on how employees and other users may use company technology, data, and networks. A broader security policy covers the organization’s overall security framework, including risk management, incident response, access control, and physical security. The AUP is one user-facing control within a larger governance structure.
Why This Matters for Security Teams
An acceptable use policy, or AUP, is often treated as a lightweight employee handbook item, but it has real control value because it sets behavioural boundaries for people using corporate systems. A broader security policy is different in scope and intent: it establishes the organisation’s security governance, risk posture, and control expectations across technology, operations, and people. The difference matters because confusion between the two leads to weak ownership, inconsistent enforcement, and policy sprawl.
Practitioners should think of the AUP as one user-facing expression of a wider governance model, not the model itself. The broader policy stack usually defines access control, incident reporting, data handling, remote work requirements, logging, and exception management. The AUP then translates some of those requirements into plain-language expectations for end users. That relationship aligns well with the NIST Cybersecurity Framework 2.0, where governance, protection, and response obligations need to be mapped into practical operating rules.
In practice, many security teams encounter AUP gaps only after misuse, shadow IT, or an incident has already occurred, rather than through intentional policy design.
How It Works in Practice
A well-structured security policy usually sits at the top of the policy hierarchy. It states what the organisation is trying to protect, who is accountable, and which control domains apply. Supporting standards and procedures then describe how controls are implemented, while the AUP tells users what is permitted, prohibited, and reportable in day-to-day use.
For example, a broader security policy may require encryption, access reviews, logging, and secure remote access. The AUP would then prohibit sharing credentials, installing unapproved software, using personal cloud storage for company data, or bypassing security tools. In other words, the AUP operationalises policy intent for the human end user, while the security policy defines the control environment.
This distinction is useful for audit and enforcement. If a user violates an AUP clause, the response may involve disciplinary action or account restriction. If a control in the security policy is missing or ineffective, the issue is governance failure, not just user misconduct. A mature program usually maps both documents to control frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls, so policy language can be traced to specific safeguards.
- AUP: user behaviour, device use, data handling, and internet or network use.
- Security policy: enterprise control objectives, risk management, roles, and enforcement.
- Standards and procedures: technical and operational instructions that support both.
Where identity is involved, the AUP may reference credential sharing, MFA use, or acceptable access methods, but the actual identity and access rules belong in the broader security policy set. These controls tend to break down when organisations publish a generic AUP without assigning control owners, because the document becomes unenforceable and disconnected from the technical environment.
Common Variations and Edge Cases
Tighter policy language often increases training and enforcement overhead, requiring organisations to balance clarity against usability. That tradeoff becomes more visible when the workforce includes contractors, third parties, remote staff, or machine identities that do not fit a standard employee AUP.
Best practice is evolving around whether AI tools, personal devices, and cloud services should be handled inside the AUP or in separate usage standards. There is no universal standard for this yet, but current guidance suggests keeping the AUP concise and user-centred, while placing technical control requirements in supporting policies and standards. That reduces ambiguity and makes updates easier when threats or tools change.
Special cases often create the most confusion. If an organisation has a separate data classification policy, privacy policy, or remote access standard, the AUP should reference those documents rather than duplicate them. If the business operates in a regulated sector, the broader security policy may also need alignment with industry obligations, while the AUP stays focused on conduct. Clear cross-referencing is usually better than trying to make one document do every job.
For organisations that use non-human identities, service accounts, or agentic systems, the AUP should not be the primary control instrument. Those identities need separate governance, because user behaviour rules do not adequately address secrets handling, privilege scope, or tool access. The practical rule is simple: if the question is “what may a person do with company systems,” the AUP may apply; if the question is “how does the organisation secure itself,” the broader security policy should lead.
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 governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.PO-1 | Policy governance is central to distinguishing user rules from enterprise security policy. |
| NIST SP 800-53 Rev 5 | PL-4 | This control covers rules of behaviour, which maps closely to an AUP. |
Define policy hierarchy and ownership so the AUP supports, not replaces, security governance.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
