Most “IT policy checklist” articles give you a name and a one-line definition, then move on. That’s fine if you already know what an acceptable use policy is. It’s not much use if you’re the person who has to write one, get it approved by three other departments, and then actually get people to read it.
Summary
Organisations typically need around 20 IT policies to cover technology use, data protection, day-to-day operations and governance. These fall into four groups: security and access, data and information, operations and productivity, and governance and compliance. The policies that fail aren’t usually missing content - they’re the ones nobody has read, because there’s no reliable way to track who has and hasn’t seen them.
Contents
- Security & access policies
- Data & information policies
- Operations & productivity policies
- Governance & compliance policies
- What makes IT policies hard to manage in practice?
- How do you actually keep 20+ policies under control?
- FAQs
Before the list: a policy that exists in a folder somewhere isn’t a policy that’s working. Every section below covers what to include and why it matters, but the harder problem - for most of the organisations we talk to - isn’t drafting the policy. It’s proving anyone read it. If you want the full picture of how a policy moves from draft to retirement, our guide to policy lifecycle management covers every stage.
Security & access policies
These are the policies that stop a single compromised laptop or password becoming a company-wide incident. NCSC’s own guidance now advises against forcing regular password expiry - it turns out mandatory monthly changes make security worse, not better, because people just write down or reuse predictable variations. If your password policy still enforces 30-day expiry, it’s not being extra cautious. It’s following outdated advice.
Cybersecurity policy
What it covers
The organisation’s overall approach to protecting digital assets - training, incident reporting, response procedures, and technical controls.
Why it matters
Verizon’s 2026 Data Breach Investigations Report found the human element was present in 62% of breaches, up from 60% the year before - and that’s despite most organisations having some form of cybersecurity awareness in place. A policy that isn’t actually read doesn’t move that number.
What to include
Scope and ownership, a RACI matrix for the different stakeholders involved (legal, IT, HR), training expectations, incident reporting steps, and a review cycle. Read our complete guide to cybersecurity policies for a full breakdown.
Access control policy
What it covers
Who gets access to what, on what basis, and how that access is reviewed and removed.
Why it matters
Access creep - where people accumulate permissions over years of role changes and nobody ever takes them away - is one of the most common findings in an access review, and one of the easiest for an auditor to flag.
What to include
Role-based access principles, joiner/mover/leaver processes, privileged account handling, and a scheduled access review (quarterly for sensitive systems, annually as a baseline).
Reviewing your policy library?
Our free guide, Effective policy management and compliance best practices, covers everything from version control to attestation - no form required.
Password and authentication policy
What it covers
How employees create, store and reset credentials, and where multi-factor authentication is mandatory.
Why it matters
This is the policy most likely to be based on advice that’s now over a decade out of date. Length and uniqueness matter more than complexity; forced periodic changes push people toward weaker, more predictable passwords.
What to include
Minimum password length (not complexity rules), MFA requirements for privileged and remote access, guidance on password managers, and a compromise-triggered (not calendar-triggered) reset policy.
Network security policy
What it covers
How the organisation’s network is segmented, monitored and protected against unauthorised access.
Why it matters
As office and remote environments blend, network boundaries have got harder to define, which makes explicit policy more important, not less.
What to include
Firewall and segmentation standards, Wi-Fi security requirements, VPN mandates for remote connections, and monitoring/logging expectations.
BYOD policy
What it covers
The rules for using personal devices to access company systems and data.
Why it matters
BYOD is common because it’s convenient and cheap - but "convenient" and "secure by default" aren’t the same thing, and a policy is what closes that gap.
What to include
BYOD is common because it’s convenient and cheap - but "convenient" and "secure by default" aren’t the same thing, and a policy is what closes that gap.
Mobile device management (MDM) policy
What it covers
How company-owned mobile devices are provisioned, secured and monitored.
Why it matters
MDM and BYOD policies get confused constantly - they’re solving different problems (company-owned control vs. personal-device access), and conflating them is a common source of gaps.
What to include
Enrolment requirements, encryption and passcode standards, app restrictions, and the process for lost or stolen devices.
Managing IT policies across your organisation?
Once you’re past five or six policies with different owners and review cycles, spreadsheets and shared drives stop being a system. See how Xoralia works - a central policy library, automated workflows, employee attestation and compliance reporting, all inside SharePoint and Teams.
Data & information policies
Data privacy policy
What it covers
How personal data is collected, processed, stored and shared, in line with data protection law.
Why it matters
Enforcement isn’t slowing down. GDPR fines have passed €7.1 billion cumulatively since 2018, with around €1.2 billion issued in 2025 alone, according to the DLA Piper GDPR Fines and Data Breach Survey (January 2026). Non-compliance with general processing principles - not just breaches - accounts for a large share of that total.
What to include
Lawful basis for processing, data subject rights procedures, breach notification timelines, and international transfer safeguards.
Not every role needs to see every version of a privacy policy. Different teams often need different versions depending on what data they handle and where they’re based - audience targeting means employees only see the policy content relevant to their role and location, rather than one generic document that half-applies to everyone.
Information security policy
What it covers
The organisation’s broader approach to protecting information assets - overlapping with, but wider than, cybersecurity specifically.
Why it matters
In regulated industries - financial services especially - being able to show who has acknowledged the information security policy, and when, is often what an auditor asks for first.
What to include
Data classification, handling requirements by classification level, security control ownership, and a documented audit trail.
Having reporting and an audit trail that shows exactly who has and hasn’t attested is the difference between an audit that takes an afternoon and one that takes a week chasing spreadsheets.
Data retention policy
What it covers
How long different categories of data are kept, and how they’re disposed of once no longer needed.
Why it matters
"Might need it someday" is not a legal basis for retention, and regulators have said so explicitly in recent enforcement decisions. Retention schedules need to be specific, not indefinite - a particular pressure point for healthcare organisations managing patient data under HIPAA-style obligations alongside GDPR.
What to include
Retention periods by data category, secure disposal procedures, and documented exceptions for legal holds.
Data back-up policy
What it covers
What gets backed up, how often, and how recovery is tested.
Why it matters
A back-up policy that’s never been tested against an actual recovery scenario isn’t a back-up policy - it’s an assumption.
What to include
Backup frequency by data criticality, retention of backup copies, and a scheduled recovery test (not just a backup completion check).
Operations & productivity policies
Acceptable use policy
What it covers
What employees can and can’t do with company-owned technology - covering professional conduct, data handling and general use.
Why it matters
This is usually the first policy an employee signs, often during onboarding, which makes it the policy with the widest reach and the highest stakes if nobody can prove it was actually read.
What to include
Permitted and prohibited uses, consequences for breach, and coverage of company devices, accounts and networks. Most organisations also need supplementary acceptable use policies for specific systems - a generic one rarely covers everything.
Attestation for a policy like this is where the gap between “we sent it” and “they read it” tends to show up. Our attestation feature automates the chase and keeps a record of who’s confirmed and who hasn’t. Our five steps to enhance workplace policy compliance goes into more detail on making attestation stick beyond just this one policy.
Remote access policy
What it covers
The rules for accessing company systems from outside the office - VPN use, device requirements, and data handling expectations.
Why it matters
Remote access moved from "nice to have" to "core operational requirement" years ago, but a lot of the policies covering it were written for occasional, not routine, remote work.
What to include
Approved connection methods, device security baseline, and data-handling restrictions for remote sessions.
Equipment ordering policy
What it covers
How employees request and receive IT hardware, and who approves it.
Why it matters
Without a defined process, equipment requests end up as email threads with no audit trail - and no easy way to track what’s been issued to whom.
What to include
Approval thresholds, standard equipment tiers by role, and asset tracking requirements.
"What tool to use when" policy
What it covers
Guidance on which approved tools to use for which task - file sharing, communication, collaboration.
Why it matters
This is one of the least glamorous policies on this list and one of the most useful, because it’s what stops shadow IT before it starts. If people don’t know which tool is sanctioned, they’ll pick whichever one is fastest to sign up for.
What to include
Approved tools by use case, and the process for requesting evaluation of a new one.
Disaster recovery policy
What it covers
How the organisation responds to and recovers from major IT disruptions - outages, ransomware, natural disasters affecting infrastructure.
Why it matters
Disaster recovery and back-up policies get bundled together constantly, but recovery is about restoring operations, not just restoring data - they need separate, coordinated plans.
What to include
Recovery time objectives, escalation and communication procedures, and a defined testing schedule.
Governance & compliance policies
Vendor standards policy
What it covers
The security, compliance and technical requirements a new vendor or application must meet before adoption.
Why it matters
A vendor that fails on security is a problem the organisation inherits, not the vendor’s alone - which is why the review needs to happen before the contract, not after an incident. It’s a particular pressure point for government and public sector bodies, where procurement rules add another layer of scrutiny on top of security review.
What to include
Security and compliance criteria, data residency requirements, and a defined review and sign-off process.
IT onboarding policy
What it covers
The process for setting up a new starter - accounts, devices, system access, and relevant M365 group membership.
Why it matters
Onboarding is where IT, HR and the line manager’s responsibilities overlap, and gaps here are usually gaps in handoff, not gaps in intent. A central policy library that automatically assigns the right policies to a new starter’s group membership removes a lot of that handoff risk - new employees get the policies relevant to their role the moment they’re added to the system, without HR chasing anyone.
What to include
Role-based access templates, device provisioning steps, and a clear owner for each stage of the process.
AI use and governance policy
What it covers
What employees can and can’t do with AI tools - what data can be shared with them, disclosure requirements, and approval processes for new tools.
Why it matters
This is the policy on this list changing fastest, and most organisations are behind. ISACA’s 2026 AI Pulse Poll of 3,400 digital trust professionals found 90% believe employees are using AI tools at work, yet only 38% of organisations have a formal, comprehensive AI policy - up from 28% the year before - and 25% have no AI policy at all. If you have fewer than 50 employees and no dedicated compliance function, you probably don’t need a 20-page AI governance framework. You do need one page that says plainly what can and can’t be pasted into a public AI tool, because that’s the gap causing most of the actual risk right now.
What to include
Permitted and prohibited AI tools, data classification rules for what can be shared with them, disclosure requirements for AI-assisted work, and a review cycle - this is not a "write once" policy.
Reviewing an AI policy every 12 months isn’t frequent enough anymore. Automated workflows that flag a policy for re-review on a shorter cycle, and reach employees the moment it’s updated, matter more here than almost anywhere else on this list.
Application-specific policies
What it covers
Policies governing the acceptable use of specific systems - a CRM, an ERP, a specific SaaS tool with its own risk profile.
Why it matters
A generic acceptable use policy rarely covers the specific risks of, say, a system holding customer financial data. Some tools need their own rules.
What to include
Tool-specific access and handling rules, sitting alongside (not replacing) the general acceptable use policy.
Environmental policy
What it covers
The organisation’s approach to reducing the environmental impact of its technology operations - hardware disposal, supplier standards, energy use.
Why it matters
77% of ISACA’s survey respondents said they consider the environmental concerns associated with using AI within their organisation - this isn’t a niche concern anymore, even if formal policy hasn’t caught up with the sentiment yet.
What to include
E-waste disposal standards, supplier environmental credentials, and any emissions reporting commitments.
Xoralia gave us the structure to ensure our workforce has easy and effortless access to the latest up-to-date policies and procedures."
Adam Lythgoe, IT manager, LifeArc
LifeArc operates in a strictly regulated sector where compliance and information security are critical - which is exactly the environment where the gap between “policy exists” and “policy is proven to have been read” matters most. Start a free trial or book a demo to see how Xoralia can help your team manage policies, track compliance, and reduce administrative burden.
What makes IT policies hard to manage in practice?
Here’s a scenario every IT and compliance team recognises: a policy update goes out to 2,000 people. Three weeks later, leadership asks how many have read it. The honest answer is a shrug, because the only record is an email send log and a folder full of Word documents with no way to tell who opened, let alone understood, any of them.
A few patterns come up repeatedly when organisations try to manage 20 policies without a system built for it:
- Version confusion. Someone finds an old copy of a policy on a shared drive and follows outdated guidance, because there was never one authoritative source.
- Attestation without evidence. People are asked to confirm they’ve read a policy, but there’s no audit trail proving it - which is a problem the moment a regulator or auditor asks for one.
- Review cycles that quietly lapse. A policy owner leaves, and the next scheduled review just doesn’t happen, because nothing was tracking that it was due.
- Policies nobody can find. If finding the right policy takes longer than reading it, most people won’t bother.
Oxford University Innovation’s experience before they fixed this covered all four patterns in one go: policies spread across legacy systems, shared drives and email; different teams keeping their own versions and creating duplication; and policy owners with no consistent way to manage reviews and no visibility into who had actually read what.
How do you actually keep 20+ policies under control?
Once an organisation has 15-20 active policies, each with its own review cycle and audience, spreadsheets and shared drives stop being a system and start being a liability. There are three broad approaches, and which one fits depends more on what’s already in your technology stack than on budget alone.
| Approach | Best fit | Where it struggles |
|---|---|---|
| Manual / native SharePoint | Small organisations with a handful of policies and low regulatory exposure | No built-in attestation tracking, audit trail, or automated review reminders - all of it has to be built or done by hand |
| Dedicated policy management platform built on Microsoft 365 (e.g. Xoralia) | Organisations already standardised on Microsoft 365 that need attestation, audit trails and audience targeting without adopting a separate system | Less suited to organisations wanting a single tool that also covers risk, incident management and training in one integrated suite |
| Broader GRC suite (NAVEX One PolicyTech, ConvergePoint) | Larger enterprises that want policy management as one module inside a wider governance, risk and compliance platform | More setup and configuration overhead; Microsoft 365 integration is often shallower than a platform built natively for it |
None of these is universally right. An organisation with five policies and no regulatory pressure doesn’t need a dedicated platform. One with 20+ policies across multiple regulated teams usually reaches a point where manual tracking becomes the actual risk, not the policies themselves.
Xoralia is built by Content Formula, a Microsoft 365 consultancy that’s been delivering intranet and compliance work since 2005 - which is also why we can be candid about when native SharePoint is genuinely enough and when it isn’t.
Frequently asked questions
What IT policies are required by law?
How often should IT policies be reviewed?
Who is responsible for IT policy management?
What’s the difference between HR software and policy management software?
About the author
Dan Hawtrey
CEO and product lead
Dan Hawtrey is CEO of Content Formula and the driving force behind Xoralia, a policy management platform built natively on Microsoft 365. Dan writes regularly on policy management, compliance, and the evolving role of AI in how organisations manage knowledge. His articles are grounded in real conversations with the companies and teams using Xoralia day to day.