Acceptable Use Policy Template sixteen sections for scope, credentials, devices, BYOD, AI tool use, monitoring, prohibited acts, and enforcement
A free, copy-ready acceptable use policy (AUP) template. Sixteen structured sections covering policy charter and authority, scope and applicability across user populations, acknowledgement and onboarding mechanics, acceptable use principles and core obligations, account and credential and authentication rules, device and endpoint and BYOD rules, network and remote-access and travel rules, internet and web and social media rules, email and messaging and communication rules, data handling and classification and retention rules, AI and generative AI and machine-learning tool rules, software and application and shadow-IT rules, prohibited acts and security-relevant misconduct, monitoring and privacy and lawful basis, incident reporting and security concern escalation, and enforcement and sanctions and exceptions and document control. Aligned with ISO/IEC 27001 Annex A 5.10 and A 6.2 to A 6.4, SOC 2 CC1.4 and CC2.2, PCI DSS Requirement 12.3, HIPAA 164.308(a)(5), NIST CSF 2.0 GV.PO and PR.AT, NIST SP 800-53 PL-4 and AT-2, CIS Critical Security Controls Control 14, NIS2 Article 21(2)(g), DORA Article 13, and GDPR Article 32.
Carry the AUP evidence chain on one workspace rather than across folders
SecPortal pairs the signed AUP to the workspace document record so the sign-off chain, the annual reconfirmation, the amendment triggers, the framework mapping, and the security findings that touch AUP-relevant misuse all live on one workspace with named-actor activity log. Free plan available.
No credit card required. Free plan available forever.
Sixteen sections that turn the workforce contract into observable user behaviour
An acceptable use policy (AUP) is the workforce-facing rule book that converts the security charter, the technical control library, and the regulatory expectations into named user behaviour every authorised user is bound by as a condition of access. It is not the security policy that names what controls the organisation requires its systems to implement, and it is not the security charter that names who the security programme is and what authority it carries. The AUP sits one level below both and is the document every employee, contractor, intern, board member, and named-account third party reads, signs, and reacknowledges annually.
The sixteen sections below cover the durable shape of an AUP against ISO/IEC 27001 Annex A 5.10 (acceptable use of information and other associated assets), A 6.2 (terms and conditions of employment), A 6.3 (information security awareness, education and training), A 6.4 (disciplinary process), SOC 2 CC1.4 and CC2.2, PCI DSS Requirement 12.3, HIPAA 45 CFR 164.308(a)(5), NIST CSF 2.0 GV.PO and PR.AT, NIST SP 800-53 PL-4 (rules of behavior) and AT-2, CIS Critical Security Controls Control 14, NIS2 Article 21(2)(g), and DORA Article 13. Pair the AUP with the data classification policy template for the data-handling rules per class, the secrets management policy template for the credential lifecycle, the security program charter template for the chartered authority the AUP exercises, and the vulnerability disclosure policy template for the safe-harbour rules the AUP cross-references. Copy the section that fits your stage and paste the rest as the workforce contract matures.
Copy the full AUP template (all sixteen sections) as one block.
1. Policy charter and authority
Open the policy with the firm intent and the named authority. A reviewer reading the first paragraph should know who publishes the rule, which user populations it covers, who signed it, and when it went into effect. ISO/IEC 27001 Clause 5.2 and Annex A 5.10 expect a documented acceptable use rule with named authority. NIST SP 800-53 PL-4 names rules of behavior as a programme expectation. The AUP sits one level below the umbrella information security policy and one level above the specialist policies for credentials, devices, data classification, and AI use. The charter answers the first audit question (what programme exists, who signed it, what authority it carries) before the policy moves into operational rules the workforce has to follow.
Policy title: Acceptable Use Policy
Policy identifier: {{POLICY_IDENTIFIER}}
Policy version: {{POLICY_VERSION}}
Effective date: {{EFFECTIVE_DATE}}
Last review date: {{LAST_REVIEW_DATE}}
Next scheduled review date: {{NEXT_REVIEW_DATE}}
Document classification (per the data classification policy): {{DOCUMENT_CLASSIFICATION}}
Retention period (per the audit evidence retention policy): {{RETENTION_PERIOD}}
Policy purpose paragraph (one paragraph, plain language, business-specific):
{{ORGANISATION_LEGAL_NAME}} publishes this Acceptable Use Policy to {{PLAIN_LANGUAGE_PURPOSE_PARAGRAPH}}. The policy is the workforce-facing rule book that turns the technical security control library and the chartered security programme into observable user behaviour. Every authorised user of the organisation s information systems, accounts, devices, networks, data, and brand is bound by this policy as a condition of access.
Policy objectives (the rule the audit reads against):
- Define the boundary of permitted and prohibited user conduct on organisational information systems.
- Protect customer-entrusted data, regulated data, and intellectual property from unauthorised access, modification, loss, or disclosure that originates from user conduct.
- Reduce the human-factor surface that contributes to security incidents (phishing, credential reuse, shadow-IT, AI-tool misuse, data leakage).
- Provide a defensible contractual basis for the organisation to discipline misuse, suspend access, or terminate the user relationship for serious violations.
- Evidence compliance with the framework controls and regulatory expectations that name acceptable use as a required control.
Policy hierarchy:
- Parent policy: Information Security Policy / Information Security Management System.
- Sibling policies referenced by this policy:
- Data Classification Policy (governs how data is tagged and what handling rules apply per class).
- Secrets Management Policy (governs how credentials are issued, stored, rotated, and revoked).
- Cryptographic Key Management Policy (governs how keys and certificates are handled).
- Vulnerability Management Policy (governs how findings flow through the remediation lifecycle).
- Vulnerability Disclosure Policy (governs how external researchers report vulnerabilities; the AUP names safe-harbour expectations).
- Bring-Your-Own-Device Policy (governs where personal devices may access organisational systems).
- AI and Machine-Learning Use Policy (governs generative AI tool use with organisational data; the AUP names the user-facing summary).
- Email and Communication Policy (governs email content, attachments, distribution).
- Social Media Policy (governs workforce social media activity that references the organisation).
- Records Management and Retention Policy (governs document retention and disposal).
- Privacy and Personal Data Handling Policy (governs personal data the user encounters).
- Disciplinary Procedure (governs the response to policy violations).
- Employment contract or contractor agreement (the underlying legal instrument the policy extends).
Frameworks the policy evidences (map your scope into Section 16):
- ISO/IEC 27001:2022 Annex A 5.10 (acceptable use of information and other associated assets), A 6.2 (terms and conditions of employment), A 6.3 (information security awareness, education and training), A 6.4 (disciplinary process), A 8.1 (user endpoint devices), A 8.2 (privileged access rights).
- SOC 2 Trust Services Criteria CC1.4 (commitment to attracting, developing, and retaining competent individuals), CC2.2 (internally communicated information), CC6.1 (logical and physical access controls), CC6.2 (registration and authorisation of new internal and external users), CC6.6 (security incident response).
- PCI DSS v4.x Requirement 12.3 (usage policies for critical technologies), Requirement 12.6 (security awareness programme).
- HIPAA Security Rule 45 CFR 164.308(a)(5) (security awareness and training), 164.310(d) (device and media controls).
- NIST CSF 2.0 GV.PO (policy and procedures), GV.RR (roles, responsibilities, and authorities), PR.AT (awareness and training), PR.AA (identity management, authentication, and access control).
- NIST SP 800-53 Rev. 5 PL-4 (rules of behavior), AT-2 (literacy training and awareness), AT-3 (role-based training), AC-2 (account management), AC-8 (system use notification), AC-20 (use of external systems), MP-7 (media use).
- CIS Critical Security Controls v8 Control 14 (security awareness and skills training).
- NIS2 Article 21(2)(g) (cybersecurity training and basic cyber hygiene practices), Article 21(2)(i) (human resources security).
- DORA Article 13 (ICT-related awareness programmes and training).
- GDPR Article 32 (security of processing), Article 39 (data protection officer tasks).
- UK Data Protection Act 2018 Section 170 (unlawful obtaining of personal data).
- US Computer Fraud and Abuse Act expectations around authorised access.
- Internal policy: {{INTERNAL_POLICY_REFERENCES}}
Policy custodian (the role that maintains the document between sign-offs):
- Role: {{CUSTODIAN_ROLE}} (typically Chief Information Security Officer or Head of Security).
- Named person at time of publication: {{CUSTODIAN_NAME}}.
Joint owners and approving signatories:
- Chief Information Security Officer (security content owner): {{CISO_NAME_AND_DATE}}.
- Chief People Officer or HR Director (workforce-conduct content owner): {{HR_OWNER_NAME_AND_DATE}}.
- General Counsel or Chief Legal Officer (employment-law and enforceability owner): {{LEGAL_OWNER_NAME_AND_DATE}}.
- Executive sponsor named in the security charter (overall accountable signatory): {{EXECUTIVE_SPONSOR_NAME_AND_DATE}}.
Consultation parties (where applicable):
- Works council or staff representative body (EU operations, France 50+ staff, Germany 5+ staff, others): {{WORKS_COUNCIL_NAME_AND_CONSULTATION_DATE}}.
- Data Protection Officer (organisations subject to GDPR or equivalent): {{DPO_NAME_AND_CONSULTATION_DATE}}.
- Compliance Officer (regulated sectors): {{COMPLIANCE_OFFICER_NAME_AND_CONSULTATION_DATE}}.
- Union representative (where union recognition applies): {{UNION_REPRESENTATIVE_NAME_AND_CONSULTATION_DATE}}.
Version history (each row carries: version, effective date, summary of change, revision trigger, sign-off references):
- v1.0 {{V1_EFFECTIVE_DATE}}: Initial AUP issued under sponsor {{V1_SPONSOR_NAME}}. Trigger: programme founding.
- v{{VN_VERSION}} {{VN_EFFECTIVE_DATE}}: {{VN_CHANGE_SUMMARY}}. Trigger: {{VN_TRIGGER}}.
2. Scope and applicability
Scope is the contested part of the policy at audit and at workforce challenge. Name who the policy applies to, what assets it covers, what work it governs, and which jurisdictions the rules operate inside. Be explicit about exemptions and modified-scope items so the boundary is enforceable rather than implicit. An AUP that lists rules without naming who is bound by them leaves the contract incomplete.
In-scope user populations (every individual in these populations is bound by this policy as a condition of access):
- Full-time and part-time permanent employees.
- Fixed-term and seasonal employees.
- Interns, placement students, and apprentices.
- Contractors and contingent workers engaged through any contracting vehicle.
- Agency workers, temporary workers, and seconded staff from group companies.
- Board members and non-executive directors with information system access.
- Advisors, consultants, and external auditors with named accounts.
- Vendor staff, partner staff, and service provider personnel with named accounts on organisational systems.
- Anyone else who receives a named user account, a guest credential, or any other access credential to an organisational information system.
In-scope information assets (the user behaviour rules cover every interaction with these assets):
- Information systems operated by the organisation (production systems, pre-production systems, internal tools, customer-facing platforms, partner-facing platforms).
- Information systems consumed by the organisation as a service (SaaS platforms, IaaS environments, PaaS environments) where the organisation holds a tenant or workload.
- Identity stores and authentication systems used to access any of the above.
- Endpoint devices (laptops, desktops, mobile phones, tablets, peripheral devices) issued by the organisation.
- Personal devices used to access organisational systems where this is permitted under Section 6 (the BYOD section).
- Networks operated by the organisation (corporate network, guest network, lab network, remote-access concentrators).
- Networks consumed by the organisation as a service that carry organisational data.
- Data created, received, processed, transmitted, or stored on any of the above, regardless of class.
- Communications channels operated or contracted by the organisation (email, messaging, video calling, voice, collaboration platforms, ticketing systems).
- Software and applications installed on organisational systems or used to access organisational data.
- Generative AI and machine-learning tools used to process any organisational data.
- The organisation s brand, logos, intellectual property, and reputation as they may be affected by user conduct.
Out-of-scope or modified-scope items (the boundary the policy explicitly does not cover, or covers under modified rules):
- Personal use of personal devices on personal accounts outside any work context: out of scope.
- Personal communications conducted on personal accounts: out of scope, except where the communication discloses organisational information or violates the prohibited acts in Section 13.
- Personal social media activity that does not reference the organisation, its customers, its partners, or its products: out of scope; activity that references any of these is in scope under Section 8.
- Trade union and works council communications conducted under the protections of the relevant jurisdiction: in scope for system rules but exempt from content monitoring; the monitoring section (Section 14) names the boundary.
- Whistleblowing communications to internal whistleblowing channels or to designated external channels: in scope for system rules but exempt from access monitoring; the monitoring section names the boundary.
- Personal use of organisational systems within the limited personal use allowance named in Section 4: in scope for the prohibited acts (Section 13) but permitted within reasonable limits.
Jurisdictional applicability:
- Primary jurisdiction (the law of the contract): {{PRIMARY_JURISDICTION}}.
- Operating jurisdictions where the workforce is located: {{LIST_OF_OPERATING_JURISDICTIONS}}.
- Where multiple jurisdictions apply to a single user, the strictest applicable rule is the binding rule for that user.
- Where local law overrides a clause of this policy, the local-law rule prevails for users in that jurisdiction, and the local-law variation is captured as a named appendix.
- The works-council and staff-representative obligations of each jurisdiction are respected before this policy is amended in a way that affects users in that jurisdiction.
Relationship to the employment contract:
- This policy is incorporated by reference into the employment contract, the contractor agreement, and any other access agreement.
- A material breach of this policy may constitute a material breach of the underlying access agreement under the disciplinary procedure named in Section 16.
- This policy is not a substitute for the underlying access agreement; where any conflict exists, the higher applicable obligation prevails.
User population modifiers (named user populations bound by additional rules on top of the baseline):
- Privileged access users (named administrators, root users, security analysts with elevated access): bound by the additional rules in the Privileged Access Management addendum.
- Users handling regulated data classes (payment card data, protected health information, personal data under GDPR or equivalent): bound by the additional rules in the data class addendum for the relevant data category.
- Users with access to source code repositories: bound by the additional rules in the Secrets Management Policy.
- Users with access to security findings or scanner output: bound by the additional rules in the Security Findings Confidentiality addendum.
3. Acknowledgement and onboarding mechanics
Acknowledgement is the evidence chain that converts the policy from a document into an enforceable contract. Without a named acknowledgement programme the policy carries no enforcement weight at audit, at employment tribunal, or in court. Capture acknowledgement at onboarding before access is provisioned, refresh annually on the current version, and recapture out-of-cycle on material change. Hold the evidence in the HRIS, the LMS, the policy management platform, or the source the audit reads.
Acknowledgement requirement:
- Every user in scope acknowledges this policy in the form named below before account provisioning, and reacknowledges on the cadence named below.
- No acknowledgement, no account: account provisioning is blocked until the initial acknowledgement is captured.
- Annual recurring acknowledgement is captured against the then-current version.
- Out-of-cycle reacknowledgement is captured on material policy change.
Acknowledgement form:
- Initial acknowledgement at onboarding: electronic acknowledgement through {{ONBOARDING_ACKNOWLEDGEMENT_SYSTEM}} (the HRIS, the LMS, or the policy management platform) before the user account is enabled. The acknowledgement event captures the user identifier, the policy version, the timestamp, and the source system.
- Annual recurring acknowledgement: every {{ANNUAL_CYCLE_DATE_RANGE}}, through {{ANNUAL_ACKNOWLEDGEMENT_SYSTEM}}, paired with annual security awareness training. Failure to acknowledge within {{ANNUAL_REMINDER_WINDOW_DAYS}} days triggers the access-suspension workflow named in Section 16.
- Out-of-cycle reacknowledgement on material change: within {{MATERIAL_CHANGE_WINDOW_DAYS}} days of the effective date of a material amendment, through {{MATERIAL_CHANGE_ACKNOWLEDGEMENT_SYSTEM}}. Failure to acknowledge triggers the access-suspension workflow named in Section 16.
- Role-banded acknowledgement: users entering populations with extended obligations (privileged access, regulated-data handling, security-findings access) acknowledge the relevant addendum before the elevated access is granted.
Acknowledgement evidence (the chain the audit reads):
- The acknowledgement record per user carries: user identifier, policy version, policy version effective date, acknowledgement timestamp, acknowledgement method (electronic click-through, signed PDF, training-system attestation, HRIS workflow), source system, and IP address or session identifier where available.
- The acknowledgement chain is retained for {{ACKNOWLEDGEMENT_RETENTION_PERIOD}} or for the duration of the access relationship plus {{POST_TERMINATION_RETENTION_DAYS}} days, whichever is longer, in line with the audit evidence retention policy.
- The acknowledgement record is reproducible on demand for: audit fieldwork ("show me the user acknowledged version X on or after date Y"), employment tribunal ("show me the user agreed to clause Z before the disputed event"), regulator request ("show me your annual workforce cyber-hygiene training was acknowledged by every active workforce member").
Onboarding sequence (the named order of events that constitute compliant onboarding):
1. Offer accepted and employment contract or contractor agreement signed (HR).
2. User identity verified per the identity verification standard (HR plus Identity team).
3. AUP and the named addendums acknowledged through the policy management system before account provisioning (HR).
4. Mandatory security awareness training completed where the organisation requires onboarding training as a precondition to access (Learning team).
5. Named role-based addendums acknowledged for the user s role band (HR plus Security).
6. User account provisioned through the joiner workflow (IT plus Identity team).
7. Named accesses granted per the role-band entitlement model (IT plus the asset owner).
8. Manager confirmation of named access scope received and recorded (line manager).
Refresh and renewal sequence:
1. Annual training pack updated against the current policy version (Learning team plus Security).
2. Annual cycle launched for the workforce (Learning team).
3. Acknowledgement completion tracked through the policy management system (HR).
4. Non-acknowledgers flagged for line-manager follow-up (HR).
5. Persistent non-acknowledgers (beyond the reminder window) referred for access suspension per Section 16.
6. Material amendment cycle launched on amendment effective date (Security plus HR).
7. Material amendment acknowledgement tracked and enforced through the same workflow.
Exit and de-provisioning interaction:
- Departing users do not need to reacknowledge the policy at exit, but are reminded in the exit interview of the post-termination obligations carried by their employment contract or contractor agreement (confidentiality, non-disparagement, return of organisational data and assets).
- The AUP acknowledgement record is preserved for the post-termination retention window so the audit chain remains intact after the user account is removed.
4. Acceptable use principles and core obligations
The principles section names the durable expectations the policy is built on. Keep the principles short, business-specific, and observable rather than aspirational. Users should be able to read the principles and apply them to a situation the detailed rules do not cover. The principles are also the lens the disciplinary procedure uses when a sanction has to be defended.
Core acceptable use principles (the durable expectations the rest of the policy operationalises):
Principle 1: Use organisational systems for organisational purposes
- Statement: organisational information systems, accounts, devices, networks, and data exist to support the work the organisation does. Use them for that work. Limited personal use within the allowance named below is permitted as a workplace courtesy, not as an entitlement.
- Limited personal use allowance: brief personal use during breaks, between tasks, or outside core working hours, provided the use does not consume material organisational resources, does not interfere with work, does not violate any prohibited act in Section 13, and does not expose the organisation to legal or reputational risk.
Principle 2: Act with the same standards you would in person
- Statement: communications, content, and conduct on organisational systems are subject to the same professional standards as conduct in any other workplace setting. Harassment, discrimination, bullying, and abusive behaviour are not acceptable on any organisational channel.
Principle 3: Protect what is entrusted to you
- Statement: organisational data, customer data, regulated data, and intellectual property are entrusted to authorised users for the work they have to do. Do not access more than your work requires, do not disclose what is not yours to disclose, do not retain after the work is done.
Principle 4: Use the controls the organisation provides
- Statement: the organisation issues credentials, devices, networks, applications, communication channels, and AI tools that meet the security baseline. Use them. Do not work around them with personal accounts, personal devices, personal AI tools, or unsanctioned channels (shadow IT).
Principle 5: Report concerns through the named channels
- Statement: if you suspect a security incident, a policy violation, a phishing attempt, a lost device, a compromised credential, or any other security-relevant event, report it through the channels named in Section 15. Reporting is encouraged, not penalised; concealment is penalised.
Principle 6: The organisation monitors operational use
- Statement: organisational information systems generate operational telemetry that the organisation processes for security, operational, legal, and regulatory purposes. The monitoring framework, the lawful basis, the retention, and the privacy boundary are named in Section 14.
Principle 7: When in doubt, ask
- Statement: this policy is broad but not exhaustive. If a situation is not covered or the right call is unclear, ask your line manager, the security team, the HR team, or the named contact in Section 15 before you act.
Core obligations (the named user-level obligations the policy operationalises):
- I will use organisational systems only for the work the organisation has engaged me to do, within the limited personal use allowance.
- I will protect organisational data, customer data, regulated data, and intellectual property in line with the data classification policy and the handling rules per class.
- I will use the credentials, devices, networks, applications, and AI tools the organisation provides, and will not work around them with unsanctioned alternatives.
- I will follow the rules in this policy and in the specialist policies it references, and will keep my acknowledgement current as the policy is updated.
- I will report security concerns through the named channels promptly and accurately.
- I will cooperate with the organisation s investigation processes when I am asked to.
- I will accept that organisational systems are monitored for security, operational, legal, and regulatory purposes within the framework named in Section 14.
- I will hand back organisational data, accounts, devices, and other assets when my access relationship ends, and will not retain organisational data on personal storage after my access relationship ends.
User attestation block (paired to the acknowledgement event in Section 3):
- I have read this Acceptable Use Policy in version {{POLICY_VERSION}}.
- I understand the core obligations and accept them as a condition of my access to {{ORGANISATION_LEGAL_NAME}} information systems.
- I will refer to the named contacts in Section 15 if I have any question about how this policy applies to me.
5. Account, credential, and authentication rules
The credential section is where most insider misuse and most credential-driven incidents originate. Make the rules specific, enforceable, and aligned with the technical control library the organisation operates. Pair this section to the Secrets Management Policy for workload credentials and the Privileged Access Management addendum for elevated access. Name the multi-factor authentication baseline, the password rules, and the credential-sharing prohibition explicitly.
Account assignment and ownership:
- Every authorised user is issued one named account per system they need access to. Generic, shared, or anonymous accounts are not permitted for human use.
- The named account holder is the only person who may use the account. Account sharing is a prohibited act under Section 13.
- Service accounts and shared functional accounts (where the technical architecture requires them) are issued under the Secrets Management Policy with named human owner, named functional purpose, and lifecycle controls.
Authentication requirements:
- Multi-factor authentication (MFA) is required for every account, except where the system genuinely does not support MFA and an alternative compensating control is documented. The organisation s preferred MFA factors in order of strength are: hardware security keys (FIDO2 or WebAuthn), passkeys, authenticator app one-time passwords, push notifications with number matching, and (as a last resort) SMS one-time passwords. Where the organisation has rolled out passwordless or phishing-resistant MFA, use of fallback factors is restricted to named scenarios.
- Single sign-on (SSO) is the required authentication path where the system integrates with the organisation s identity provider. Bypassing SSO with direct system credentials is permitted only under documented exception.
- Conditional access policies (device posture, network location, identity risk) may apply additional checks on top of MFA. The policies are part of the technical control library; users may not bypass them.
Password rules:
- Where passwords are used (either as a primary factor or as a fallback), they meet the password baseline: minimum length of {{MIN_PASSWORD_LENGTH}} characters, breached-password screening, no enforced periodic rotation (unless the system architecture or a regulatory framework requires it), and storage in the organisation-approved password manager.
- The organisation-approved password manager is {{APPROVED_PASSWORD_MANAGER}}. Users do not store organisational passwords in browsers, text files, spreadsheets, notes apps, chat messages, or any other unmanaged store.
- Personal passwords (used for personal accounts on personal time) are out of scope for this policy. Reused passwords between personal accounts and organisational accounts are prohibited.
Credential handling:
- Credentials of any kind (passwords, API keys, OAuth tokens, personal access tokens, TLS keys, SSH keys, MFA seeds) are confidential to the named account holder.
- Credentials are not shared with colleagues, contractors, family members, support staff, or anyone else, including via screen share, email, chat, voice, paper note, or unmanaged document.
- The IT support team will not ask for a password during a support call; any such request is a phishing indicator and is reported under Section 15.
- Credentials encountered in source code, in tickets, in chat threads, in shared drives, or in any other unmanaged location are reported under Section 15 and treated as a finding under the Secrets Management Policy.
Privileged access:
- Privileged accounts (administrator, root, security analyst with elevated access, infrastructure access with destructive capability) are governed by the Privileged Access Management addendum on top of this section.
- Privileged credentials are not used for routine work; users with privileged access maintain a separate standard account for day-to-day activity and elevate only when the work requires elevated access.
Session and device discipline:
- Lock the screen when leaving a device unattended in any setting (office, home office, coffee shop, hotel, airport).
- Log out at the end of the working day where the system or device requires it.
- Do not leave devices unattended in public spaces (cafes, cars, hotel rooms, airport seating) where they may be stolen, observed, or tampered with.
Account lifecycle:
- Joiner: account provisioned per the onboarding sequence in Section 3.
- Mover: access reviewed and adjusted when role changes; legacy access removed within {{MOVER_REVIEW_WINDOW_DAYS}} days of the role change.
- Leaver: account disabled within {{LEAVER_DISABLE_WINDOW_HOURS}} hours of the access relationship ending; account removed within {{LEAVER_REMOVE_WINDOW_DAYS}} days; access to organisational data on the leaver s personal devices terminated and verified.
6. Device, endpoint, and bring-your-own-device rules
The device section names which devices may access organisational systems and under what conditions. Pick a BYOD posture (no BYOD, BYOD under enrolment, BYOD for low-risk apps only, limited BYOD) and write the section against the chosen posture. Pair to the Mobile Device Management baseline and the endpoint protection rollout. Be specific about what users may install, what they may not install, and how the organisation enforces the baseline.
Organisation-issued device rules:
- The organisation issues devices that meet the technical security baseline (encryption at rest, screen lock, automatic update, endpoint protection, configuration management, central inventory).
- Use the issued device for organisational work; do not use the issued device for activities that conflict with the prohibited acts in Section 13.
- The endpoint protection, configuration management, and inventory agents on the issued device are not removed, disabled, or tampered with. Doing so is a prohibited act under Section 13.
- Operating system updates and security patches are not deferred indefinitely; the device update baseline is held by the IT team and enforced through the technical control library.
- Administrative or root access on issued devices is granted under named exception only, and is recorded against the issued user.
- Lost or stolen issued devices are reported under Section 15 within the timeline named there. The organisation may remotely wipe a lost device.
BYOD posture (the organisation s position on personal devices accessing organisational systems):
- The chosen BYOD posture for this organisation is: {{BYOD_POSTURE_ONE_OF_NO_BYOD_OR_BYOD_UNDER_ENROLMENT_OR_BYOD_LOW_RISK_ONLY_OR_BYOD_LIMITED}}.
[If "no BYOD permitted":]
- Personal devices may not access any organisational system, account, or data. Use the organisation-issued device for all organisational work, including remote work and travel.
[If "BYOD permitted under enrolment":]
- Personal devices may access organisational systems only after enrolment in mobile device management.
- Enrolment establishes the technical baseline: device passcode of minimum {{BYOD_MIN_PASSCODE_LENGTH}} characters, device encryption at rest, OS version at or above the supported baseline, jailbreak or root attestation, automatic update, and container isolation between organisational data and personal data.
- The organisation may remotely wipe the organisational container on a lost, stolen, or compromised personal device. The organisation does not wipe the personal partition of an enrolled personal device.
[If "BYOD permitted for low-risk applications only":]
- Personal devices may access only the named low-risk applications: {{NAMED_LOW_RISK_APPLICATIONS}}. Access to high-risk applications (production systems, customer data systems, payment data systems, regulated data systems, source code repositories) is not permitted from personal devices.
[If "limited BYOD for travel or break-glass":]
- Personal devices may be used to access organisational systems only under named exception (issued device unavailable due to loss, travel beyond issued device capability, or named break-glass scenario). The exception is recorded under Section 16.
Endpoint installation rules:
- Software installation on issued devices is restricted to applications from the organisation s approved catalogue or applications approved through the named exception process.
- Browser extensions are restricted to the approved catalogue; unsanctioned browser extensions that touch organisational data are a prohibited act under Section 13.
- Personal cloud storage clients (personal Dropbox, personal Google Drive, personal OneDrive, personal iCloud) are not installed on issued devices.
- Personal AI tool clients (personal ChatGPT desktop app, personal Claude desktop app, personal Copilot client where it is not the licensed enterprise version) are governed by Section 11.
Removable media and external storage:
- Removable media (USB flash drives, external hard drives, SD cards) are not used to transfer organisational data outside the controls the organisation provides, except under documented exception.
- Where removable media is used under exception, the media is encrypted at the file or device level, the transfer is recorded, and the media is returned or destroyed per the named procedure.
Connection to organisational networks:
- Personal devices that have not met the enrolment baseline do not connect to the organisational corporate network. The guest network is the permitted network for personal devices in a workplace setting.
- Devices belonging to family members, friends, or other visitors do not connect to the organisational corporate network.
Physical security:
- Issued devices are protected against shoulder-surfing in public spaces. Privacy screens are recommended for users who work in shared spaces (cafes, trains, airports, co-working).
- Devices are not left unattended in cars, hotel lobbies, conference venues, or any other setting where they may be stolen.
- At end of the access relationship, issued devices are returned through the named return procedure within {{DEVICE_RETURN_WINDOW_DAYS}} days.
7. Network, remote-access, and travel rules
The network section names how users connect to organisational systems and what protections apply. Cover the corporate network, the guest network, remote work scenarios (home, coffee shop, hotel, airport), travel scenarios (domestic, international, high-risk jurisdictions), and the organisation-provided remote-access stack (VPN, zero-trust network access, conditional access). Make the rules clear enough that a traveller can read them on a plane and act on them on arrival.
Corporate network use:
- The corporate network carries organisational data and is restricted to enrolled organisational devices that meet the technical baseline.
- The guest network is provided for visitors, personal devices, and non-organisational use. Organisational data does not flow over the guest network.
- Network segmentation between the corporate, guest, lab, and production networks is enforced by the technical control library; users do not work around the segmentation.
Remote access stack:
- The organisation-provided remote access is {{REMOTE_ACCESS_STACK_NAME}} (VPN, zero-trust network access, or equivalent).
- Remote connections to organisational systems take place through the named stack. Direct connections to organisational systems outside the stack are not permitted, except where named exception applies (for example, public-facing customer support tools that the organisation operates).
- Public Wi-Fi (coffee shops, airports, hotels, trains) is permitted only when the connection is wrapped through the remote-access stack. Conducting organisational work on raw public Wi-Fi is a prohibited act under Section 13.
- Personal mobile hotspots are permitted under the same conditions as the device baseline (enrolled organisational device, organisation-approved hotspot client, no shared connection with family or friends).
Remote work setting:
- Remote work is permitted under the organisation s remote-work policy. The AUP names the security-side rules: lockable physical workspace where possible, no organisational data displayed where unauthorised observers can read it, no inviting non-workforce members to attend video meetings without prior authorisation, no use of household members or external service providers (cleaners, babysitters, building maintenance) to operate the organisational device.
- Working from a publicly visible setting (cafe, library, train, plane) is permitted; the user takes responsibility for shoulder-surfing prevention, audio confidentiality, and the device-attended discipline named in Section 6.
Domestic travel:
- Domestic travel does not require additional permissions; the device, network, and credential rules apply as normal.
International travel:
- International travel is notified to {{INTERNATIONAL_TRAVEL_NOTIFICATION_CHANNEL}} ahead of departure so the conditional access policies and the device posture rules can reflect the travel.
- Crossing borders with organisational devices follows the named travel-device procedure (which devices may be carried, what data may be carried, how requests for device inspection at border are handled).
- Travel to named high-risk jurisdictions ({{LIST_OF_HIGH_RISK_JURISDICTIONS}}) follows the named travel-device procedure for those jurisdictions (typically a burner device with the minimum necessary access, return procedure on arrival home, no credentials reused after the trip).
Personal use of organisational network:
- Limited personal use of the organisational network is permitted within the personal use allowance in Section 4 and within the prohibited acts in Section 13.
- High-bandwidth personal use (streaming, gaming, peer-to-peer downloads, cryptocurrency mining) on the organisational network is not permitted.
Vendor and partner network use:
- When working on a vendor or partner site under their network, the same device, credential, and remote-access rules apply. Connecting an organisational device to a vendor or partner network without the remote-access stack is permitted only with prior authorisation.
Network monitoring:
- Network telemetry (flow records, DNS queries, web access metadata, security telemetry) is collected per Section 14. Users acknowledge that the corporate network is not a private channel for personal communications; personal communications take place on personal devices and personal networks.
8. Internet, web, and social media rules
The web and social media section is one of the most contested parts of the AUP because it touches free speech, off-duty conduct, and the user s personal brand. Keep the rules narrowly drawn to organisational interests. Cover web browsing on organisational systems, social media activity that references the organisation, and the discipline around posting content that could be attributed to the organisation.
Web browsing on organisational systems:
- Web browsing on organisational systems is permitted for organisational purposes and for limited personal use within the personal use allowance.
- Browsing categories that are blocked by the organisation s web filtering technology (illegal content, adult content, gambling content, malware-hosting sites) are blocked because the underlying activity is incompatible with the workplace; users do not attempt to bypass the filtering.
- Web traffic on organisational systems is logged per Section 14.
Downloads from the internet:
- Downloads from the internet to organisational systems are permitted from reputable sources for organisational purposes.
- Software downloads are governed by Section 12 (the software and application section).
- Documents downloaded from external sources are scanned by the endpoint protection on the device.
Personal social media (off-duty, off-system):
- Personal social media activity conducted on personal accounts, on personal time, on personal devices, that does not reference the organisation, its customers, its partners, its products, or its workforce, is out of scope of this policy.
- The organisation respects the legal protections that apply to personal speech and personal activity in each operating jurisdiction.
Social media activity that references the organisation:
- Workforce members who identify themselves as associated with the organisation on social media (in a bio, in a post, in a profile picture) follow the social media policy.
- Posts that reference the organisation, its customers, its partners, or its products do not disclose confidential or non-public information; do not make commitments that bind the organisation; do not bring the organisation into disrepute; and respect the same professional standards that apply in any other workplace setting.
- Workforce members who hold a public-facing role (executive, spokesperson, designated communicator) may post on behalf of the organisation under the named delegation; other workforce members do not speak for the organisation.
Confidential information online:
- Confidential information is not disclosed on social media, in public forums, in conference talks, in blog posts, in podcasts, or in any other public channel without prior authorisation per the publication-approval workflow named in the communications policy.
- Customer references, customer outcomes, and customer logos are not used in any public channel without explicit named-customer permission.
Brand and reputational care:
- The organisation s brand, logos, trademarks, and design assets are not used in personal channels except as part of the workforce member s professional identity.
- Attacks on individual customers, partners, or workforce members through any public channel are not permitted.
Conduct that crosses from personal into workplace:
- Off-duty conduct on personal channels that is unlawful, that targets workforce members in a manner that constitutes harassment under the workplace harassment policy, or that brings the organisation into serious disrepute, may constitute a workplace matter under the disciplinary procedure.
- The organisation balances workforce freedom of expression with the organisation s legitimate interest in workplace safety and reputational care; close cases are handled under the named procedure with HR and legal involvement.
Engaging with security researchers, regulators, and journalists:
- Workforce members who are approached by security researchers, regulators, or journalists on security-related matters refer the approach to {{SECURITY_PRESS_REFERRAL_CONTACT}} rather than responding individually.
- The Vulnerability Disclosure Policy names the channel for security researchers; the regulatory engagement protocol names the channel for regulators; the press protocol names the channel for journalists.
9. Email, messaging, and communication rules
The email and messaging section covers the daily communication tools that carry most workforce information flow. Cover email use, the rules for forwarding to personal accounts, attachment handling, messaging app use, video calling, voice calling, and the boundary between organisational channels and personal channels. Pair to the Email and Communication Policy for the detailed rules.
Email use:
- Organisational email is used for organisational communications. Limited personal use is permitted within the personal use allowance in Section 4.
- Auto-forwarding organisational email to personal email accounts is not permitted. Where access to organisational email outside the organisational systems is required, the organisation-provided mobile email client and the conditional access policies are used.
- Sending organisational data to personal email accounts (your own or others ) is a prohibited act under Section 13.
- External email recipients are checked before sending; auto-complete errors and reply-all errors are a leading source of data leakage incidents.
Email attachments:
- Email attachments are screened by the organisation s email security stack.
- Sensitive attachments (data classes Confidential or higher per the data classification policy) are sent through the organisation s secure-file-share service rather than as raw email attachments where the data class rules require it.
- Receiving an attachment from an unknown sender is treated cautiously; suspicious attachments are reported under Section 15.
Phishing and social engineering:
- Phishing emails, smishing (SMS phishing) messages, vishing (voice phishing) calls, and pretexting attempts are reported under Section 15 through the reporting button in the email client or the named reporting channel.
- Cooperating with a phishing test (responding, clicking, providing credentials) is treated as a training opportunity, not a disciplinary event. Cooperating with a real phishing attempt that results in a security incident is handled under the incident response procedure.
- Workforce members who report a phishing attempt are not penalised even if they initially interacted with the message before reporting.
Messaging apps and collaboration platforms:
- Organisational communications take place on the named organisational platforms ({{ORGANISATIONAL_MESSAGING_PLATFORMS}}). Workforce members do not conduct material organisational business on personal messaging apps (personal WhatsApp, personal Signal, personal Telegram) except where the named exception applies (for example, on-call escalation when the organisational platform is unavailable).
- Group chats that include external participants are clearly named so workforce members do not inadvertently share confidential information with external participants.
- Disappearing or auto-deleting messages on organisational platforms follow the records retention rules; the organisation does not permit unilateral evasion of records retention through disappearing-message features.
Video and voice calls:
- Video and voice calls on organisational platforms are scheduled and conducted with the same professional discipline as in-person meetings.
- Recording of calls follows the named recording protocol with notice to all participants where required by jurisdictional law.
- Sensitive calls are not conducted in public spaces where they can be overheard; sensitive video meetings are not conducted where the screen can be observed by unauthorised viewers.
Encryption of communications:
- Communications channels operated by the organisation provide encryption at rest and in transit as part of the technical control library.
- Where additional encryption is required by the data class (end-to-end encryption, PGP, S/MIME), the encryption is applied through the organisation-approved tooling; ad-hoc personal encryption tools that bypass the organisation s key management are not permitted.
Records retention:
- Organisational communications on organisational platforms are retained per the records retention policy.
- Workforce members do not delete records to evade records retention or to obstruct investigation. Records subject to legal hold are preserved per the legal hold notice.
10. Data handling, classification, and retention rules
The data section is the user-facing summary of the Data Classification Policy and the Records Retention Policy. Name the data classes the organisation operates, the high-level handling rule per class, and the cross-cutting prohibitions (no copying customer data to personal storage, no removing regulated data from the controlled environment, no retaining data after the access relationship ends).
Data classification (the classes named in the Data Classification Policy):
- Public: information that has been approved for public release. Standard care applies.
- Internal: information for internal organisational use that should not be disclosed outside the organisation without authorisation. Standard care applies.
- Confidential: information whose unauthorised disclosure could harm the organisation, its customers, its partners, or its workforce. Restricted access, restricted handling, restricted storage locations.
- Restricted or Regulated: information subject to regulatory protection (personal data under GDPR or equivalent, payment card data under PCI DSS, protected health information under HIPAA, regulated financial data, classified information where applicable). Strict access controls, strict handling rules, named-system storage only.
Data handling per class:
- Public: may be shared internally and externally without additional control.
- Internal: shared inside the organisation under standard care; external sharing requires the standard external-sharing approval.
- Confidential: shared on a need-to-know basis; external sharing requires explicit named approval; not stored on unmanaged systems; not transmitted through unmanaged channels.
- Restricted or Regulated: handled per the named regulatory regime; not stored or processed outside the named-permitted environments; not transmitted through any channel that has not been approved for the data class; not shared with any party who has not been authorised under the named regulatory regime.
Cross-cutting data prohibitions (prohibited acts under Section 13 in concrete form):
- Copying organisational data to personal storage (personal cloud storage, personal email, personal devices, personal media) is not permitted.
- Storing organisational data on third-party services (free file-sharing services, free note-taking apps, free translation services, free PDF converters, free image hosts) that have not been approved is not permitted.
- Sending organisational data to AI tools that have not been approved under Section 11 is not permitted.
- Removing physical documents containing Confidential or Restricted data from the secured premises without the named procedure is not permitted.
- Disposing of physical documents containing Confidential or Restricted data without the named secure-disposal procedure is not permitted.
- Disposing of electronic media (devices, hard drives, removable media) containing organisational data without the named secure-disposal procedure is not permitted.
Personal data handling (where the workforce member processes personal data):
- Personal data is processed only for the named purpose, on the lawful basis named in the Privacy and Personal Data Handling Policy, with the data minimisation principle observed.
- Workforce members do not access personal data beyond the scope of their work; curiosity browsing of customer records, colleague records, or any other personal data is a serious violation of the Privacy and Personal Data Handling Policy and a prohibited act under Section 13.
- Workforce members report suspected personal data breaches under Section 15 promptly so the organisation can meet the regulatory notification timelines.
Data subject and customer-facing requests:
- Workforce members who receive a data subject access request, a customer access request, a deletion request, a portability request, or a regulator request route the request to {{DATA_SUBJECT_REQUEST_CHANNEL}} rather than responding individually.
Data retention and disposal:
- Organisational data is retained per the records retention policy; workforce members do not retain copies of organisational data beyond the period the organisation has authorised.
- At end of the access relationship, organisational data on the user s devices, accounts, and any other location is returned to the organisation or destroyed under the named return procedure.
Intellectual property:
- Intellectual property created by workforce members in the course of their work is the property of the organisation under the terms of the access agreement.
- Intellectual property from prior employers or prior engagements is not used on organisational work without the prior employer s written authorisation and the organisation s acknowledgement.
11. AI, generative AI, and machine-learning tool rules
The AI section is the part of the AUP most organisations have to add or rewrite in 2025-2026 because the policy library has not kept pace with workforce adoption of generative AI tools. Name the organisation s posture, the approved tool list, the data classes permitted with each tool, and the cross-cutting prohibitions. Pair to the AI and Machine-Learning Use Policy for the detailed rules. Keep this section enforceable and updateable on a faster cadence than the rest of the policy.
Organisation posture on generative AI:
- The organisation operates an explicit posture on generative AI tools: {{AI_POSTURE_ONE_OF_PERMITTED_BROADLY_OR_PERMITTED_WITH_RESTRICTIONS_OR_PERMITTED_LOW_RISK_ONLY_OR_FORBIDDEN}}.
- Approved generative AI tools are listed in the AI and Machine-Learning Use Policy and updated as the tool landscape evolves; the workforce-facing summary is reflected in this section.
Approved AI tool catalogue (the named enterprise-licensed or organisation-approved tools):
- Approved tools: {{LIST_OF_APPROVED_AI_TOOLS_WITH_PERMITTED_DATA_CLASSES}}.
- Permitted data classes per tool: each approved tool names the data classes that may be passed (typically Public and Internal for the broadly approved tools, with named exceptions for tools that the organisation has secured with contractual no-training commitments and named data residency).
- Forbidden data classes for AI tools: Restricted or Regulated data is not passed to any AI tool unless the tool is specifically approved for that data class under a documented contractual arrangement that meets the regulatory regime.
Cross-cutting AI rules:
- Personal AI accounts on personal AI tools are not used to process organisational data. Use the organisation-approved AI tools where they are available.
- AI tools embedded in browser extensions, mobile apps, or desktop clients that have not been approved are not used with organisational data.
- AI tools that train on user prompts by default are not used with any organisational data class above Public unless the organisation has contracted for a no-training commitment.
- AI tool outputs are not treated as authoritative: AI-generated code is reviewed by a human before commit, AI-generated communications are reviewed before send, AI-assisted research is verified before relied on, AI-generated decisions are reviewed before acted on.
- Workforce members do not present AI-generated work as their own original work where the work is required to be original (intellectual property creation, examinations, regulatory filings, certain customer deliverables); the named procedure applies.
- Workforce members do not use AI tools to evade workplace rules (writing reviews as another worker, automating regulated communications without human review, generating content that constitutes harassment of another worker).
AI use with sensitive data classes:
- Customer data: AI tools that have not been approved for customer data may not be used to process customer data. Approved tools for customer data are listed in the AI policy with contractual proof.
- Source code: AI tools that have not been approved for source code may not be used with source code. Approved tools for source code are listed with the no-training commitment proof.
- Security findings, scanner output, or vulnerability details: AI tools that have not been approved for security findings may not be used with security findings; the named approved tools have explicit confidentiality commitments.
- Personal data: AI tools that have not been approved for personal data under GDPR (or the equivalent jurisdiction) may not be used with personal data.
- Payment card data, protected health information, regulated financial data: AI tools are not used with these data classes unless the tool has been specifically approved under the regulatory regime.
AI-generated code and AI-assisted development:
- AI-assisted code generation is permitted for workforce members in development roles using the approved tools.
- All AI-generated code is reviewed by a human before commit; the review verifies correctness, security, and licence compliance.
- AI tools are not used to generate code that processes customer data or regulated data in a way that contradicts the data class rules above.
- AI-generated security-relevant code (authentication, encryption, access control, cryptographic primitives) is reviewed with extra care because AI tools have known failure modes around security primitives.
AI for hiring, performance, and workforce decisions:
- AI tools are not used to make workforce decisions (hiring decisions, performance decisions, disciplinary decisions, termination decisions) without explicit named procedure and human review; the named procedure applies in the jurisdictions where AI hiring tools are regulated (EU AI Act, US state-level AI hiring laws, NYC AI hiring law where applicable).
Cadence of the AI section:
- This section is reviewed more frequently than the rest of the policy because the AI tool landscape evolves rapidly.
- Material updates to the approved tool catalogue or the data class rules trigger out-of-cycle reacknowledgement per Section 3.
12. Software, application, and shadow-IT rules
The software section names what users may install on organisational devices, what cloud applications they may sign up for with organisational accounts, and how the organisation handles shadow IT. Be specific about the approved-catalogue process, the exception path for tools that are not in the catalogue, and the rules around free or trial signups that handle organisational data.
Software installation on organisational devices:
- Software installation on organisational devices is restricted to applications from the organisation s approved catalogue ({{APPROVED_CATALOGUE_LOCATION}}).
- Applications not in the catalogue may be requested through the named exception process ({{EXCEPTION_PROCESS_REFERENCE}}); the exception captures the named use case, the data classes the application would handle, the security review outcome, and the named owner.
- Local administrator rights on organisational devices are granted under named exception only; users with named administrator rights still follow the catalogue and exception rules.
- Pirated, cracked, or unlicensed software is not installed on organisational devices under any circumstance.
Cloud applications (SaaS) signed up for with organisational accounts:
- Cloud applications used for organisational work are procured through the named procurement process ({{PROCUREMENT_REFERENCE}}) so the security review, the data processing agreement, the contractual commitments, and the cost record are in place before the workforce relies on the tool.
- Free signups, trial signups, and self-service signups for cloud applications that handle organisational data are not permitted; the named exception path applies if the work cannot wait for the procurement cycle.
- The organisation s single sign-on integration is the preferred authentication path for organisational cloud applications; standalone username-and-password signups are minimised.
Shadow IT and unsanctioned tools:
- Use of unsanctioned tools to handle organisational data (free PDF converters, free translation services, free note-taking apps, free design tools, free spreadsheet alternatives, free project management trials) is a recognised security and privacy risk.
- Workforce members who feel an unsanctioned tool would meet a genuine work need raise the request through the named procurement or exception channel rather than relying on the unsanctioned tool.
- Discovery of shadow IT is not a disciplinary event in the first instance; the organisation responds by understanding the underlying need and either approving the tool or providing an approved alternative. Persistent shadow IT use after the named alternative is provided is treated under the disciplinary procedure.
Browser extensions:
- Browser extensions on organisational systems are restricted to the approved catalogue.
- Extensions that read or write organisational data (password managers, screenshot tools, productivity extensions, AI assistant extensions) are particularly scrutinised because the extension has page-level access to organisational data.
Open-source and third-party libraries (for workforce members in development roles):
- Open-source libraries and third-party components are managed under the Software Bill of Materials Policy and the Vulnerability Management Policy.
- Workforce members who introduce new open-source components verify the licence, the maintenance posture, and the known vulnerability state per the named procedure.
Personal applications on personal accounts:
- Personal applications on personal accounts on personal devices on personal time are out of scope of this section.
- Personal applications that are then connected to organisational accounts (a personal calendar app integrated into the organisational mail, a personal task manager integrated into organisational chat) bring the personal application into scope; named integrations are approved through the named exception or procurement process.
Decommissioning and uninstallation:
- Applications no longer in active use are uninstalled through the named procedure so the security baseline does not erode.
- At end of access relationship, organisational software licences and accounts associated with the workforce member are recovered or transferred per the named off-boarding procedure.
13. Prohibited acts and security-relevant misconduct
The prohibited acts section is the closing list that converts the principles and rules into specific named acts. Keep the list specific, observable, and enforceable. Group the acts into categories (credential misuse, data misuse, system misuse, conduct misuse, security-evasion misuse, regulatory misuse) so the disciplinary procedure can map the act to a category and a proportionate response.
Credential misuse:
- Sharing your own credentials with any other person.
- Using another person s credentials.
- Bypassing multi-factor authentication, single sign-on, or conditional access controls.
- Storing organisational passwords outside the approved password manager.
- Disclosing credentials to a phishing site, a pretexting caller, or any other unauthorised channel.
- Embedding credentials in source code, configuration files, chat messages, documents, or any other unmanaged location.
Data misuse:
- Accessing organisational data beyond what your work requires (curiosity browsing of customer records, colleague records, payroll data, or any other data you have no work reason to read).
- Copying organisational data to personal storage of any kind.
- Sending organisational data to personal email, personal cloud storage, personal messaging, or personal AI tools.
- Removing physical documents containing Confidential or Restricted data from the secured premises without the named procedure.
- Failing to follow the data class handling rules in Section 10.
- Retaining organisational data after the end of the access relationship.
System misuse:
- Connecting unenrolled personal devices to the corporate network where the BYOD posture forbids it.
- Installing unsanctioned software on organisational devices.
- Removing, disabling, or tampering with endpoint protection, configuration management, inventory, or any other security agent on an organisational device.
- Using unsanctioned cloud applications to handle organisational data.
- Working around web filtering, DLP, or any other technical control.
- High-bandwidth personal use of the organisational network outside the personal use allowance.
- Cryptocurrency mining, peer-to-peer file sharing for personal purposes, or other resource-intensive personal use on organisational systems.
Conduct misuse:
- Harassment, discrimination, bullying, or other abusive behaviour on any organisational channel.
- Posting content on social media that violates Section 8.
- Disclosing confidential information in any public channel without authorisation.
- Speaking publicly on behalf of the organisation without the named delegation.
- Conduct on organisational systems that is unlawful in the jurisdiction the user is operating in.
- Storage of unlawful content (illegal pornography, classified material, content that violates intellectual property law) on any organisational system or device.
Security-evasion misuse:
- Circumventing this policy or any control derived from it.
- Evading monitoring through unsanctioned encryption, anonymisation tools, VPN services that bypass the organisational remote-access stack, or other security-evasion tooling.
- Tampering with audit logs, activity logs, or any other evidence-collection system.
- Coaching another person to violate this policy.
- Concealing a security incident, a policy violation, or a regulatory event.
Regulatory misuse:
- Conduct that places the organisation in breach of a regulatory regime the organisation operates under (GDPR, PCI DSS, HIPAA, SOX, GLBA, regulated-financial-services regimes, sector-specific regimes).
- Conduct that places the organisation in breach of an export control regime (sanctions screening, dual-use export controls, technology transfer controls).
- Insider trading or market abuse conducted using information obtained through organisational access.
AI tool misuse:
- Use of personal AI accounts to process organisational data.
- Use of unapproved AI tools to process organisational data.
- Passing data classes to AI tools that are not approved for the data class.
- Presenting AI-generated work as your own original work where the work is required to be original.
Severity tiering and disciplinary response:
- Each prohibited act maps to one of four severity tiers (minor, moderate, serious, gross misconduct) in the disciplinary procedure ({{DISCIPLINARY_PROCEDURE_REFERENCE}}).
- The disciplinary procedure names the proportionate response per tier (verbal coaching, written warning, training requirement, account suspension, termination, contract termination, legal action, regulatory reporting).
- The severity tier depends on the act, the context, the user s prior record, the user s role, the data classes involved, the consequences for the organisation, and the consequences for any affected third parties.
- Sanctions are applied through the named disciplinary procedure with the named investigation discipline, named decision-maker, and named appeal channel.
14. Monitoring, privacy, and lawful basis
The monitoring section is the part of the AUP most often challenged by workforce representatives and most often read by the regulator. Balance the organisation s legitimate operational need to monitor against the user s privacy expectations and the local jurisdictional rules. Be explicit about what is monitored, the lawful basis, who has access, the retention, and the boundary between monitoring and surveillance.
Monitoring scope (what is monitored on organisational systems):
- Network telemetry (network flow records, DNS queries, web access metadata, network security telemetry).
- Endpoint telemetry (process activity, file access, login events, removable media events, security agent events).
- Email metadata and email content where the email security stack inspects messages for threat detection.
- Messaging metadata on organisational platforms; messaging content where required by records retention or by legal hold.
- Login events and access events to organisational systems.
- Application usage telemetry on organisational systems.
- Identity-side telemetry (sign-in risk, conditional access decisions, MFA events, password reset events).
- Security tool telemetry (vulnerability scans, security findings, security incidents).
- Voice and video recording where the recording is authorised under the named protocol.
- Location telemetry where the device or application provides it and the data is needed for security or operational purposes.
Monitoring purposes (the named operational, security, legal, and regulatory purposes):
- Information security: detect and respond to security incidents, investigate suspected security events, verify compliance with security controls.
- Operational continuity: detect and respond to operational events, plan capacity, optimise performance.
- Legal compliance: respond to legal process (court orders, regulator requests, lawful access requests), preserve records under legal hold, comply with records retention regimes.
- Workforce safety and conduct: respond to suspected misconduct that affects workforce safety, investigate workplace harassment or discrimination, respond to disciplinary matters per the disciplinary procedure.
- Audit and assurance: produce the audit evidence required by the frameworks and the regulators the organisation operates under.
Lawful basis (the legal basis under which monitoring takes place):
- Employment contract or contractor agreement: monitoring is named in the contract as a condition of access.
- Legitimate interest: monitoring necessary for the security and operation of the organisation, balanced against the user s rights and freedoms.
- Legal obligation: monitoring required by law (records retention regimes, regulator-imposed obligations, sectoral cybersecurity requirements).
- Consent: in jurisdictions where consent is the lawful basis for specific monitoring categories, consent is captured separately from the AUP acknowledgement.
Privacy boundary (what the organisation does not monitor):
- Personal communications conducted on personal accounts on personal devices outside the work context.
- Trade union and works council communications conducted under the protections of the relevant jurisdiction.
- Whistleblowing communications to internal whistleblowing channels or to designated external channels.
- Personal time use of organisational systems that falls within the personal use allowance, unless an incident or investigation triggers the named review procedure.
- Workforce member identity attributes that are not relevant to the workplace (sexual orientation, religious belief, political activity, health status), except where the workforce member has opted into a programme that processes the attribute.
Access to monitoring data (the named roles that may access monitoring data):
- Named security analysts and security engineers with named work-area assignment.
- Named IT operations staff for operational telemetry as needed for system administration.
- Named HR staff for monitoring data relevant to an active disciplinary investigation under the named procedure.
- Named legal staff for monitoring data relevant to legal process or legal hold.
- Named privacy staff (Data Protection Officer where applicable) for monitoring data relevant to a privacy review.
- Access is granted on a need-to-know basis, recorded on the access log, and reviewed periodically.
Retention of monitoring data (the named retention windows per class):
- Security telemetry: {{SECURITY_TELEMETRY_RETENTION}}.
- Operational telemetry: {{OPERATIONAL_TELEMETRY_RETENTION}}.
- Email and messaging telemetry: {{EMAIL_MESSAGING_RETENTION}}.
- Endpoint telemetry: {{ENDPOINT_TELEMETRY_RETENTION}}.
- Identity telemetry: {{IDENTITY_TELEMETRY_RETENTION}}.
- Voice and video recordings: {{VOICE_VIDEO_RETENTION}}.
- Beyond the retention windows, monitoring data is disposed under the data disposal procedure or anonymised where the retention serves a continuing operational or regulatory purpose.
User rights (the rights the workforce member retains in respect of monitoring):
- Right to know what is monitored (this section discharges that right at the policy level; specific queries are routed to {{MONITORING_QUERY_CHANNEL}}).
- Right to access personal data about you that is processed for monitoring purposes, subject to the lawful exceptions in your jurisdiction (data subject access request through {{DATA_SUBJECT_REQUEST_CHANNEL}}).
- Right to challenge a monitoring-derived decision through the named appeal channel.
- Right to escalate a privacy concern to the Data Protection Officer (where applicable) or to the data protection authority of your jurisdiction.
Jurisdictional variation:
- The monitoring framework above is the baseline. Where jurisdictional law applies stricter rules (German co-determination, French CNIL guidance, UK Investigatory Powers Act expectations, EU GDPR, US state-level wiretapping rules), the stricter rule applies for users in that jurisdiction.
- Where the organisation operates monitoring tools that affect users in multiple jurisdictions, the strictest applicable rule sets the baseline for the tool s operation.
15. Incident reporting and security concern escalation
The reporting section is the workforce s entry point into the security response system. Make the channels easy to find, easy to use, and protected against retaliation. Name the channels for security incidents, suspected security incidents, policy violations, suspected misconduct, lost devices, suspected phishing, and whistleblowing. Pair to the Incident Response Plan and the Whistleblowing Policy.
What to report:
- Suspected security incident (unauthorised access, data leakage, malware infection, ransomware, account compromise, lost or stolen device, lost or stolen credentials).
- Suspected phishing email, smishing SMS, vishing call, pretexting attempt, or any other social engineering.
- Discovery of credentials, secrets, or sensitive data in an unmanaged location (source code, chat, document, screenshot, email).
- Discovery of vulnerability, misconfiguration, or weakness in an organisational system.
- Suspected violation of this Acceptable Use Policy by any person (including yourself).
- Suspected violation of another workplace policy that has a security dimension.
- Privacy concern affecting personal data the organisation processes.
- Regulatory concern affecting the organisation s position under a regime it operates under.
- Concerns about workplace conduct (harassment, discrimination, bullying) on any organisational channel (routed through the workplace conduct channel, not the security incident channel).
Reporting channels:
- Security incident: {{SECURITY_INCIDENT_REPORTING_CHANNEL}} (typically a named email address, a named ticket queue, a named hotline, and an in-product report button for phishing).
- Phishing: {{PHISHING_REPORT_CHANNEL}} (typically the report button in the email client).
- Privacy concern: {{PRIVACY_REPORT_CHANNEL}} (typically the Data Protection Officer or named privacy team).
- Workplace conduct: {{WORKPLACE_CONDUCT_CHANNEL}} (typically HR or the named ER team).
- Whistleblowing: {{WHISTLEBLOWING_CHANNEL}} (typically a named independent channel with the named external escalation route under the whistleblowing policy).
- Out-of-hours emergency: {{OUT_OF_HOURS_EMERGENCY_CHANNEL}}.
Reporting timeline:
- Suspected security incidents are reported as soon as practicable, and in any case within {{SECURITY_INCIDENT_REPORTING_WINDOW_HOURS}} hours of detection.
- Lost or stolen devices and lost or stolen credentials are reported immediately, within {{LOST_DEVICE_REPORTING_WINDOW_MINUTES}} minutes of discovery, so the organisation can disable the credentials and remotely wipe the device.
- Suspected phishing is reported as soon as practicable; if you have already interacted with the phishing message, the timeline is even tighter so the security team can move quickly.
- Privacy concerns affecting personal data are reported promptly so the organisation can meet the regulatory notification timelines (which can be as tight as 72 hours under GDPR for personal data breaches).
What happens after a report:
- The security team or the relevant team acknowledges the report through the named channel.
- The report is triaged per the incident response procedure.
- The reporter may be asked for additional information; cooperate with the request.
- The reporter is updated on the outcome of the report where appropriate and where the outcome can be shared without compromising the investigation.
Non-retaliation commitment:
- Reporting a suspected security incident, a policy violation, a privacy concern, or a workplace conduct concern in good faith is encouraged.
- The organisation does not retaliate against any workforce member who reports in good faith, including reports that turn out to be unfounded after investigation.
- Retaliation against a reporter is itself a disciplinary matter and a prohibited act under Section 13.
- Workforce members who report through the named whistleblowing channel additionally have the legal protections that apply in their jurisdiction.
Reporting your own mistake:
- If you have made a mistake (clicked a phishing link, sent data to the wrong recipient, lost a device, shared a credential under pressure), report it through the named channel as soon as you realise.
- Self-reporting an honest mistake is treated as a routine response event, not as a disciplinary event.
- Concealing a mistake is treated as a separate and additional violation under the disciplinary procedure.
Reporting suspected violations by colleagues:
- Reports about suspected violations by colleagues are taken seriously, investigated under the disciplinary procedure, and treated confidentially within the limits of the investigation.
- Reporters of suspected violations are protected against retaliation per the non-retaliation commitment above and per the whistleblowing policy.
16. Enforcement, sanctions, exceptions, and document control
The closing section converts the policy into an enforceable rule. Name the enforcement authority, the proportionate sanctions per category of violation, the exception process for users who need a documented departure from a clause, and the document control header that holds the policy together. Pair to the Disciplinary Procedure for the workforce procedural detail.
Enforcement authority:
- The CISO or Head of Security carries the technical enforcement authority (account suspension on security grounds, conditional access tightening on security grounds, security-tool intervention).
- The HR Director or Chief People Officer carries the workforce enforcement authority (disciplinary action, training requirement, contract action, termination).
- The General Counsel or Chief Legal Officer carries the legal enforcement authority (litigation, regulatory notification, criminal referral).
- The Executive Sponsor named in the security charter carries the ultimate enforcement authority on policy-wide matters.
Sanctions framework:
- Minor violation (one-off, low-impact, no malicious intent, no recurring pattern): verbal coaching by line manager, training refresher, named record in the user file.
- Moderate violation (impactful, repeated minor pattern, or moderate carelessness): written warning under the disciplinary procedure, named training requirement, named account-restriction period.
- Serious violation (significant impact, deliberate boundary-crossing, or recurring moderate pattern): final written warning under the disciplinary procedure, named account-suspension period, named role reassignment where applicable, named cost recovery where applicable.
- Gross misconduct (deliberate harm, criminal conduct, deliberate concealment, repeated serious pattern): termination of employment or contract under the disciplinary procedure, civil action where appropriate, criminal referral where appropriate, regulator notification where appropriate.
Investigation discipline:
- Every sanction is preceded by a named investigation under the disciplinary procedure.
- The investigation is conducted by a named investigator who is not the line manager of the user under investigation where avoidable.
- The investigation collects evidence under the named evidence-collection rules, including evidence from monitoring data per Section 14.
- The user under investigation has the opportunity to respond to the evidence before a decision is made, in line with the disciplinary procedure of the jurisdiction.
- The decision is made by a named decision-maker who is independent of the investigator.
- The user under investigation has the named appeal channel.
Exception process:
- A user who needs a documented departure from a clause of this policy raises an exception request through {{EXCEPTION_REQUEST_CHANNEL}}.
- The exception request names the clause, the reason for the departure, the proposed alternative control, and the proposed expiry date.
- Exceptions are approved by the CISO or delegate; high-impact exceptions are escalated to the executive sponsor.
- Exceptions are recorded on the security exception register with named owner, named expiry, and named review cadence.
- Exceptions expire on the named date; renewal requires a fresh review.
External enforcement interactions:
- The organisation cooperates with regulators, law enforcement, and other lawful authorities per the named legal-process procedure.
- Civil litigation involving workforce conduct on organisational systems is handled by the General Counsel.
- Criminal referrals (where workforce conduct may constitute a criminal offence) are made by the General Counsel after the named review.
Document control footer:
- Effective date: {{EFFECTIVE_DATE}}.
- Version: {{POLICY_VERSION}}.
- Last review date: {{LAST_REVIEW_DATE}}.
- Next scheduled review date: {{NEXT_REVIEW_DATE}}.
- Owner roles: CISO ({{CISO_NAME}}), HR Director ({{HR_OWNER_NAME}}), General Counsel ({{LEGAL_OWNER_NAME}}).
- Executive sponsor: {{EXECUTIVE_SPONSOR_NAME}}.
- Approved by (sponsor signature and date): {{SPONSOR_SIGNATURE_AND_DATE}}.
- Approved by (HR signature and date): {{HR_SIGNATURE_AND_DATE}}.
- Approved by (legal signature and date): {{LEGAL_SIGNATURE_AND_DATE}}.
- Custodian: {{CUSTODIAN_ROLE_AND_NAME}}.
- Document identifier and storage location: {{DOCUMENT_IDENTIFIER_AND_STORAGE_LOCATION}}.
- Acknowledgement record location: {{ACKNOWLEDGEMENT_RECORD_LOCATION}}.
- Retention: per the audit evidence retention policy.
Annual reconfirmation block:
- Reconfirmation year: {{RECONFIRMATION_YEAR}}.
- Reconfirmation outcome (one of: reconfirmed without change, reconfirmed with editorial amendments only, reconfirmed with material amendments listed below, full re-sign required): {{RECONFIRMATION_OUTCOME}}.
- Material amendments (where applicable): {{RECONFIRMATION_MATERIAL_AMENDMENTS_LIST}}.
- Reconfirmation signed by sponsor: {{RECONFIRMATION_SPONSOR_SIGNATURE_AND_DATE}}.
Amendment block (used for out-of-cycle amendments):
- Amendment identifier: {{AMENDMENT_IDENTIFIER}}.
- Amendment trigger: {{AMENDMENT_TRIGGER_DESCRIPTION}}.
- Amendment effective date: {{AMENDMENT_EFFECTIVE_DATE}}.
- Amendment description: {{AMENDMENT_DESCRIPTION}}.
- Amendment signed by sponsor: {{AMENDMENT_SPONSOR_SIGNATURE_AND_DATE}}.
- Reacknowledgement window applied: {{REACKNOWLEDGEMENT_WINDOW_DAYS}}.
Closing statement:
- This Acceptable Use Policy is the workforce-facing rule book at {{ORGANISATION_LEGAL_NAME}}. It defines what authorised users are permitted to do with organisational systems, accounts, devices, networks, data, and brand.
- Authorised access to organisational systems is conditioned on the user s acknowledgement of this policy.
- The policy is reviewed annually and amended on the named triggers between scheduled reviews.
- Policies, standards, addendums, and operating procedures derive their workforce-facing rules from this policy; where any subordinate document conflicts with this policy, this policy prevails until the subordinate is realigned.
Seven failure modes the AUP has to design against
An AUP fails the audit read, the workforce read, and the employment-tribunal read in recognisable patterns. Each failure has a structural fix that the template above is designed to enforce. Read this list before you customise the AUP so the customisation does not weaken the discipline that makes the policy enforceable.
The AUP is treated as legalese that nobody reads
A policy written entirely in legal register that the workforce never reads is a policy the workforce cannot follow and the disciplinary procedure struggles to defend. The fix is plain language in the body of the policy, a workforce-facing summary inside the security awareness training, and a short principles section the workforce can recall in a real situation rather than the full sixteen-section policy.
The acknowledgement chain is not held anywhere durable
An AUP signed by the executive but never acknowledged by users carries no enforcement weight at audit, employment tribunal, or court. The fix is the structured acknowledgement programme in Section 3 with the HRIS, the LMS, or the policy management platform holding per-user, per-version, time-stamped evidence reproducible on demand.
The AI section is missing or out of date
Most AUPs predate the workforce adoption of generative AI tools. A policy that does not name a position on AI tools leaves the workforce to invent local rules, which means customer data, source code, and credentials flow into AI tools the organisation has not approved. The fix is the explicit AI section in Section 11 with named approved tools, named permitted data classes, and a faster amendment cadence than the rest of the policy.
The monitoring section reads as one-sided surveillance
A monitoring section that names everything the organisation tracks without naming the privacy boundary, the lawful basis, the retention, and the user rights creates a workforce relations problem and a regulatory exposure. The fix is the six-element structure in Section 14 (scope, purposes, lawful basis, privacy boundary, access roles, retention) plus the named user rights and the named appeal channel.
The BYOD section is silent or aspirational
An AUP that leaves the BYOD position implicit forces every BYOD decision to be defended one at a time and means personal devices end up accessing organisational systems without enrolment. The fix is the explicit BYOD posture choice in Section 6 (no BYOD, BYOD under enrolment, BYOD low-risk only, limited BYOD) with named technical baselines and named exception paths.
The prohibited acts list is generic
A list of vague prohibitions ("no inappropriate use") leaves the disciplinary procedure with no clear act to sanction and leaves the workforce uncertain about where the line is. The fix is the named-act grouping in Section 13 (credential misuse, data misuse, system misuse, conduct misuse, security-evasion misuse, regulatory misuse, AI tool misuse) with specific named acts the disciplinary procedure can map to a severity tier.
The policy is not updated when a new tool, jurisdiction, or threat appears
An AUP that is reviewed only annually misses material change between reviews and becomes a stale artefact the audit reads against the present reality. The fix is the eight named out-of-cycle amendment triggers (new regulatory expectation, new technology adoption, new jurisdiction, threat environment change, control library change, new incident type, new union or works council relationship, audit or regulator finding) with reacknowledgement on material change.
Ten questions the AUP has to answer
A defensible AUP answers each of these ten questions explicitly. Capture the answers in the sections above rather than relying on individual line managers, security analysts, or HR partners to recall them when a real situation arises. The ten questions are the operational floor of an AUP; richer programmes answer more, but the ten below are the durable minimum the workforce, the disciplinary procedure, and the audit read against.
1.Who in your organisation is authorised to sign this policy on behalf of security, HR, legal, and the executive sponsor.
2.Which jurisdictions does your workforce operate inside, and which jurisdictional rules override the baseline rules in this policy.
3.How will you capture the per-user, per-version acknowledgement record for audit, employment tribunal, and regulator reads.
4.Which BYOD posture (no BYOD, BYOD under enrolment, BYOD low-risk only, limited BYOD) reflects the organisation s actual position and technical baseline.
5.Which generative AI tools are on the approved catalogue, with which data classes, and how is the catalogue updated faster than the annual policy cycle.
6.What is your password manager, your single sign-on, your conditional access, and your multi-factor authentication baseline so Section 5 names real controls rather than aspirational ones.
7.What is monitored, on what lawful basis, with what retention, and what is the privacy boundary the workforce can rely on.
8.How does a prohibited act in Section 13 map to a severity tier in the disciplinary procedure, and who decides at each tier.
9.How does a workforce member raise a security concern, a privacy concern, a workplace conduct concern, or a whistleblowing report, and who responds.
10.How does an exception to a clause of this policy get recorded, approved, expired, and reviewed.
How the AUP pairs with SecPortal
The template above is copy-ready as a standalone artefact. SecPortal is not an HRIS, a learning management system, or a policy distribution platform, and does not replace the HR-owned acknowledgement chain or the training delivery system. What SecPortal does is carry the security-side evidence chain that connects the AUP to the rest of the security operating record. The AUP itself can be held as a versioned document through document management with named custodian, named version history, and the named owner roles (CISO, HR director, general counsel, executive sponsor) recorded on the document control header.
The sign-off chain on each version is captured on the activity log with named actor, timestamp, and 30, 90, or 365-day retention by plan, so the audit reads the annual reconfirmation, the out-of-cycle amendment, and the reacknowledgement trigger directly from the workspace record rather than as a separate assertion. Access to the policy and its sensitive addendums is gated by team management role-based access control with the four roles (owner, admin, member, viewer) shaping who can read and amend the document, and protected by multi-factor authentication for the sign-off events on the workspace itself.
The chartered outcomes that reference the AUP read against the compliance tracking feature where ISO 27001 Annex A 5.10, A 6.2, A 6.3, A 6.4, A 8.1, A 8.2, SOC 2 CC1.4 and CC2.2 and CC6.1, PCI DSS Requirement 12.3, HIPAA 164.308(a)(5), NIST CSF 2.0 GV.PO and PR.AT, NIST SP 800-53 PL-4 and AT-2, CIS Critical Security Controls Control 14, NIS2 Article 21(2)(g), and DORA Article 13 mapping reads against the live findings record with CSV export. Security findings that originate from AUP-relevant misuse (credentials in code from forbidden tools detected through code scanning, credential reuse detected through authenticated scanning, shadow-IT exposures detected through external scanning) are recorded against the workspace finding record with the AUP-violation context and the activity-log trail of who decided what when.
Exception-routed departures from the AUP are recorded against finding overrides (where the override expresses the operating-side risk acceptance) and against the vulnerability acceptance and exception management workflow for the wider security-side exception register. The AI report generation workflow drafts the workforce-facing summary of the AUP, the executive summary, and the framework-mapping section from the underlying workspace record so the custodian edits rather than writes from a blank page. The notifications and alerts feature dispatches the annual review trigger and the amendment trigger event to the named owners with the same audit trail.
For the data-handling rules the AUP cross-references, see the data classification policy template. For the credential lifecycle the AUP cross-references, see the secrets management policy template. For the founding constitutive document, see the security program charter template. For the external-researcher safe-harbour rules the AUP cross-references, see the vulnerability disclosure policy template. For the disciplinary discipline that runs the sanctions in Section 16, see the incident response runbook template. For the framework anchors, see the framework pages for ISO 27001, SOC 2, PCI DSS, HIPAA, NIST CSF 2.0, NIST SP 800-53, NIS2, and DORA. SecPortal does not replace the HRIS that holds the per-user acknowledgement chain, the learning management system that delivers the training pack, or the policy management platform that distributes the policy to the workforce. The HR-owned and legal-owned workforce contract sits in those systems; SecPortal carries the security-side evidence chain that connects the AUP to the live security operating record.