Acceptable Use Policy Template: Rules for Systems, Accounts and Data

Most security incidents that start with a user involve something the organisation never clearly said was forbidden: a shared password, a token pasted into a public repository, company data synced to a personal cloud drive, or an unapproved browser extension. An acceptable use policy (AUP) is the document every user signs that turns those expectations into rules they can follow and that HR can enforce. This template covers accounts and credentials, email and messaging, internet and cloud services, devices and software, data handling, social media, personal use, monitoring, and the extra duties of privileged users and owners of service accounts and automation. AI tool use is handled by a separate policy. Have employment counsel and your DPO review it before adoption.

How to use this template

• Replace text in square brackets, such as [Organisation], [IT service desk] and [12 months], with your own names and values.
• "Must" and "must not" are mandatory. "Should" is a recommended practice where a documented exception may be justified.
• Keep the AUP short enough that people read it. Put technical settings (password length, approved tool lists, DLP rules) in standards it references, so the AUP does not need re-signing every time a setting changes.
• Use of generative AI tools and AI agents is covered by the AI Acceptable Use Policy Template. Reference it in section 4.6 rather than duplicating its rules.
• Place this policy beneath your top-level policy. See the Information Security Policy Template.
• Monitoring wording (section 5) has employment and data protection consequences in every jurisdiction. Do not adopt it without legal review.

1. Purpose

This policy sets out the rules for using [Organisation] information, systems, accounts, devices and services. It exists to protect [Organisation], its customers and its people from harm caused by misuse, whether deliberate or careless, and to make clear what users may do, what they must not do, and what [Organisation] may monitor.

2. Scope

1. This policy applies to all employees, contractors, temporary staff, interns, volunteers and third-party personnel ("users") who are given access to [Organisation] information or systems.
2. It applies to all [Organisation] systems and services, including corporate devices, networks, email, collaboration and messaging tools, cloud and SaaS applications, source code repositories and development platforms, and to personal devices and accounts when they are used for [Organisation] work.
3. It applies to the creation and use of non-human identities (service accounts, API keys, tokens, bots, scripts and integrations) by users. Each one must have a named human owner who is accountable for its use under this policy.

3. Roles and responsibilities

4. Policy statements

4.1 General principles

1. [Organisation] systems are provided for business purposes. Limited personal use is permitted under section 4.8.
2. Users must only access information and systems they are authorised to use, and only for the purpose for which access was granted. Having technical access to data does not mean being authorised to use it.
3. Users must not attempt to bypass, disable or test security controls, including endpoint protection, web filtering, MFA, logging and data loss prevention, unless authorised in writing as part of an approved security test.

4.2 Accounts, passwords and authentication

1. Accounts are issued to individuals. Users must not share their accounts, passwords, MFA codes, passkeys or hardware security keys with anyone, including colleagues, managers and IT staff. [IT service desk] will never ask for a password or MFA code.
2. Passwords must meet the [Password Standard] and must not be reused from any personal account. Users should use [approved password manager].
3. Users must not approve an MFA prompt they did not initiate, and must report unexpected prompts to [security operations] at once.
4. Credentials for systems, including API keys, access tokens, private keys and connection strings, must be stored only in [approved secrets manager]. They must never be placed in source code, configuration committed to a repository, tickets, wikis, chat messages, email or AI prompts.

4.3 Email, messaging and collaboration

1. Business communication must use [approved email and messaging tools]. Users must not conduct [Organisation] business through personal email or unapproved messaging apps.
2. Users must not automatically forward [Organisation] email to personal or external accounts.
3. Users must treat unexpected requests for payment, bank detail changes, credentials, gift cards or urgent data transfers as suspicious and verify them through a known, separate channel before acting.

4.4 Internet, cloud and external services

1. [Organisation] data must only be stored in or shared through services listed in [approved services list]. Users must not upload [Organisation] data to personal cloud storage, file transfer sites or unapproved SaaS applications.
2. Users must not use anonymising proxies or personal VPNs to bypass web filtering, and must not grant third-party applications access to [Organisation] accounts (for example through "Sign in with" or OAuth consent screens) unless the application is approved.
3. Users must not publish [Organisation] code, configuration or data to public repositories, paste sites or forums without approval under [open source contribution procedure].

4.5 Devices and software

1. Users must only install software from [approved software catalogue]. Browser extensions, plug-ins and developer packages are software and are covered by this rule.
2. Users must not disable, uninstall or tamper with security software, encryption, update mechanisms or device management agents.
3. Personal devices may access [Organisation] data only if enrolled under the [BYOD policy]. See the BYOD Policy Template.
4. Users must not connect unknown removable media or devices to [Organisation] equipment, and must use only [encrypted, approved removable media] for [Organisation] data.
5. Devices must be locked when unattended. Lost or stolen devices must be reported to [IT service desk] within [1 hour] of discovery.

4.6 Data handling and AI tools

1. Users must handle information according to its classification and the handling rules in the [Data Classification Policy]. See the Data Classification Policy Template.
2. Users must not copy [Organisation] data to personal devices, accounts or removable media except as permitted by that policy.
3. Use of generative AI tools, AI coding assistants and AI agents must follow the [AI Acceptable Use Policy]. No data classified above [Public] may be entered into an AI service that is not approved for that classification.

4.7 Social media and public statements

1. Users must not post non-public [Organisation] information on social media, public websites or forums, including photographs that show screens, badges, whiteboards or office layouts.

4.8 Personal use

1. Occasional personal use of [Organisation] devices and internet access is permitted if it is lawful, does not interfere with work and does not breach this policy. Personal use is monitored in the same way as business use (section 5).

4.9 Additional rules for privileged users

1. Administrative tasks must be carried out with a separate privileged account, issued through [PAM solution], never with an everyday account, and privileged accounts must not be used for email or browsing.
2. Privileged users must not grant themselves or others access, create accounts or change logging without an approved change or ticket.
3. Emergency (break glass) accounts may be used only under the [break glass procedure], and every use must be reported within [24 hours].

4.10 Service accounts, scripts and automation

1. Users must not create service accounts, API keys, personal access tokens, bots or integrations against [Organisation] systems except through [request process]. Each must be registered with a named owner, a purpose and an expiry or review date.
2. Non-human identities must be granted only the permissions their purpose needs, and must not be used for interactive logins by people.
3. When a user changes role or leaves, ownership of every non-human identity they own must be transferred or the identity disabled. See the NHI Policy Template.

4.11 Prohibited activities

In addition to the rules above, users must not:

1. Access, or attempt to access, systems, accounts or data without authorisation, or exceed the access they have been given.
2. Scan, probe or exploit networks or systems, or run security testing tools, unless authorised under [security testing procedure].
3. Use [Organisation] systems to harass, bully or discriminate, or to access, store or send unlawful or sexually explicit material.

4.12 Reporting

1. Users must report suspected security incidents, lost devices, exposed credentials and breaches of this policy to [security operations contact] as soon as they become aware of them.
2. Users who report a mistake they made promptly will not be disciplined for the mistake itself, except where it was deliberate, malicious or repeated after warning.

5. Monitoring and privacy

1. [Organisation] monitors the use of its systems to protect security, detect misuse and meet legal obligations. Monitoring may include [email gateway and DLP events, web proxy logs, endpoint security telemetry, sign-in and access logs, and file sharing activity].
2. Monitoring is carried out in line with [privacy notice for workers] and applicable data protection and employment law. [Organisation] will complete a data protection impact assessment before introducing new monitoring that is likely to be high risk.
3. Access to monitoring data is limited to [named roles]. Content of individual communications will be reviewed only for a specific investigation authorised by [HR Director and CISO], unless required for automated security filtering.
4. [Organisation] does not use covert monitoring except in exceptional circumstances authorised by [authority], in line with legal advice.

6. Exceptions

1. Exceptions must be requested through [exception register] with the business reason, the risk, compensating controls and an end date.
2. Exceptions are approved by [CISO] and expire after no more than [12 months].

7. Compliance and enforcement

1. Breaches of this policy may lead to withdrawal of access and action under [disciplinary procedure], up to and including dismissal or termination of contract. Unlawful activity may be reported to the authorities.
2. [Security operations] reports quarterly to [CISO] on the measures in the implementation guidance.

8. Acknowledgement

1. Users must acknowledge this policy before they are given access, and re-acknowledge it [annually] and after each major revision. Access may be suspended until acknowledgement is recorded.
2. Acknowledgement text: "I have read and understood the [Organisation] Acceptable Use Policy, version [x], and I agree to follow it. I understand that my use of [Organisation] systems is monitored as described in section 5."

9. Review and approval

Implementation guidance

Where the design choices come from

• Signed rules of behaviour: NIST SP 800-53 Rev. 5 control PL-4 Rules of Behavior requires rules describing users' responsibilities, a documented acknowledgement before access is authorised, periodic review, and re-acknowledgement when the rules change. Its guidance suggests different rules for privileged and general users, which section 4.9 provides. PL-4(1) adds restrictions on social media, posting organisational information publicly, and using organisational identifiers on external sites, reflected in sections 4.4 and 4.7.
• Access agreements: PS-6 Access Agreements treats acceptable use agreements as a type of access agreement, which is why section 8 makes acknowledgement a condition of access rather than a training formality.
• Monitoring transparency: the UK ICO guidance on monitoring workers expects employers to be open about monitoring and to assess its impact. The ICO notes that this guidance is under review following the Data (Use and Access) Act, so check the current version before finalising section 5.

Rollout

1. Collect existing rules (onboarding packs, IT guidelines, code of conduct) and remove contradictions.
2. Agree sections 5 and 7 with HR, legal and the DPO, and consult works councils or employee representatives where your jurisdiction requires it.
3. Publish the approved software, services and AI tool lists the policy points to. A rule against unapproved tools without a list of approved ones is not enforceable.
4. Build acknowledgement into the joiner workflow and gate account activation on it, then run a re-acknowledgement campaign for existing staff with a deadline.
5. Configure the technical controls that back the rules (auto-forwarding blocks, OAuth app consent restrictions, secret scanning on repositories, web filtering) in monitor mode first, review results for [30 days], then enforce.

Measures

• Acknowledgement coverage: percentage of active users with a current acknowledgement (target [100%] within [30 days] of a revision).
• Shadow IT and OAuth grants: number of unapproved SaaS applications and third-party OAuth grants found per quarter.
• Exposed credentials: secrets detected in repositories, tickets and chat per quarter, and median time to revoke.
• Unowned non-human identities: service accounts and tokens with no current owner.

Failure patterns this policy is written to prevent

• Credentials published by an individual: in the Home Depot token exposure, a GitHub access token tied to one employee was published and remained valid for more than a year, with access to hundreds of private repositories. Sections 4.2, 4.4 and 4.10 make storing and publishing credentials outside approved tools an explicit breach and require an owner and expiry for every token.
• Rules without controls: forbidding auto-forwarding or unapproved OAuth apps while leaving both technically possible invites routine breaches.
• Punishing reporting: if people are disciplined for reporting their own mistakes, they stop reporting. Section 4.12 separates honest error from misconduct.

Framework mapping

Sources for the design choices

• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• NIST: Cybersecurity Framework 2.0
• ICO: Employment practices and data protection, monitoring workers
• ISO: ISO/IEC 27001:2022 Information security management systems, Requirements

Related NHI Mgmt Group resources: AI Acceptable Use Policy Template · Information Security Policy Template · Security Awareness and Human Risk Management Guide · Shadow AI Policy Template