Information security policy examples every SME can copy today

Ready-made information security policy examples exist for almost every control an SME needs, and the fastest path to compliance is adapting one rather than drafting from a blank page. SANS, NIST and ISO-aligned publishers all offer free or low-cost templates that map directly onto ISO 27001 and GDPR requirements, so the real task is choosing the right six policies and getting an owner's name against each one.

Start with this minimum set before anything else:

• Acceptable use policy
• Access control policy
• Data classification policy
• Incident response policy
• Password and authentication policy
• Backup and disaster recovery policy (recommended as a foundational component)

Pro Tip: Download one template today, strip it to a single page of "must" statements, and assign an owner before the end of the week. A policy with no named owner is the single most common reason auditors flag a control as ineffective.

Everything else, from vendor management to BYOD, can wait until these six are signed off and communicated to staff.

Key Takeaways

Ready-made, ISO- and NIST-mapped policy examples exist for every core control an SME needs, and success depends on assigning owners, enforcing "must" language and reviewing on a fixed schedule.

Table of Contents

• Information security policy examples: the essential types explained
• Copy-ready policy clauses for staff handbooks
• How do you structure an organisation-level security policy?
• How do these policies map to ISO 27001, NIST and GDPR?
• How do you write, approve and roll out a security policy?
• Do you need policies beyond GDPR, such as HIPAA or CCPA?
• Where do security policies fit in wider governance and risk management?
• What SMEs get wrong about writing security policies
• How ShieldIQ turns policy examples into audit-ready documentation
• Where to find authoritative policy templates
• Sources

Information security policy examples: the essential types explained

Every organisation eventually needs a small library of policies, but not all of them carry equal weight in year one. Some protect against the incidents that actually happen to SMEs (phishing, lost laptops, weak passwords); others matter more once you're chasing a specific certification or contract.

The core catalogue looks like this:

• Acceptable use policy — defines what staff can and cannot do with company devices, email, internet access and personal devices during work.
• Access control policy — sets rules for who gets access to which systems, how access is granted, reviewed and revoked, and why least privilege matters.
• Data classification policy — creates a taxonomy (commonly Public, Internal, Confidential, Restricted) so staff know how to label and handle information at each level.
• Incident response policy — outlines detection, reporting, escalation and recovery steps when something goes wrong, plus who leads the response.
• Backup and disaster recovery policy — states backup frequency, retention, testing cadence and recovery time objectives.
• Encryption policy — specifies when data must be encrypted at rest and in transit, and which standards apply.
• Third-party/vendor policy — governs due diligence, contractual security clauses and ongoing monitoring of suppliers.
• Remote work/BYOD policy — covers minimum device security, VPN use and separation of personal from corporate data.
• Password and authentication policy — sets complexity rules, rotation (or lack of it, per current guidance), and multi-factor authentication requirements.
• Change management policy — controls how changes to systems and infrastructure are proposed, tested and approved.

For most SMEs, acceptable use, access control, incident response, data classification and password/authentication are mission-critical from day one. Backup and disaster recovery follows close behind because it's the policy that determines whether a ransomware event is a bad afternoon or a business-ending event. Encryption, vendor management, BYOD and change management tend to matter more once you're pursuing ISO 27001 certification or handling a specific regulated data type.

One scoping note worth settling early: decide whether each policy covers "information security" broadly (people, paper, process) or narrowly "IT security" (systems and networks). Hybrid scope is common in SMEs and works fine, provided the policy says so explicitly rather than leaving readers to guess.

Copy-ready policy clauses for staff handbooks

Long policy documents rarely change behaviour. Short, enforceable sentences do. The clauses below are designed to sit in an employee handbook or onboarding pack exactly as written, each one a declarative "must" statement rather than a vague aspiration.

• Multi-factor authentication: "All staff must enable multi-factor authentication on email, VPN and any system holding customer data. IT is responsible for enforcing this at the system level; line managers are responsible for confirming compliance during onboarding."
• Screen lock: "Devices must lock automatically after five minutes of inactivity and must be locked manually whenever left unattended, including in the office."
• Approved software: "Staff must only install software from the approved list maintained by IT. Requests for new software must go through IT before installation."
• Incident reporting: "Any suspected security incident, including phishing emails, lost devices or unauthorised access, must be reported to the designated security contact within one working day."
• Data handling: "Confidential and Restricted data must not be sent by unencrypted email or stored on personal cloud accounts. Staff who need an exception must request one in writing from their manager."
• Device loss: "Loss or theft of any company device or a personal device used for work must be reported immediately so remote wipe and access revocation can begin."
• BYOD minimums: "Personal devices used to access company email or files must run supported operating system versions, have a passcode enabled and use company-approved mobile device management software."
• Annual training: "All staff must complete security awareness training annually, with new starters completing it within their first 30 days."

Guidance on writing this kind of enforceable, "must" language is consistent across practitioner sources: pair each clause with a named responsible party and a stated consequence, so it's usable in disciplinary processes as well as day-to-day operations, as vCSO.ai's policy template guidance sets out.

Pro Tip: Adjust the tone, not the substance, to fit your organisation's risk appetite. A fintech handling payment data might make MFA non-negotiable with zero exceptions; a small design studio might allow a documented exception process for a legacy tool. The "must" stays; the exception path is where you flex. If your teams already use multi-factor authentication inconsistently, ShieldIQ's guide to rolling out MFA in small organisations walks through the practical steps.

How do you structure an organisation-level security policy?

A master information security policy needs a consistent skeleton, regardless of company size, so auditors and new starters can navigate it without a guided tour. The structure below reflects what appears in most credible templates, including the control-mapped version published by Open Security Architecture, which references more than 70 NIST controls across roughly 20 sections.

Template skeleton:

• Purpose — one paragraph stating why the policy exists and what it protects.
• Scope — who and what systems the policy applies to (staff, contractors, cloud services, physical sites).
• Definitions — plain-language definitions of terms used throughout (confidential data, incident, least privilege).
• Policy statements — the enforceable "must" and "must not" clauses, organised by domain.
• Roles and responsibilities — who owns, approves and enforces the policy.
• Compliance and enforcement — consequences for breach, and how compliance is monitored.
• Exceptions — a formal process for requesting and approving deviations, with a time limit on each exception. Skipping this step is a common cause of audit findings, since assessors expect to see a documented exception register rather than informal workarounds, as Berkeley's exception process guidance notes.
• Review — how often the policy is reviewed and by whom.

Sample clauses for the sections auditors scrutinise most closely:

Access control: "Access to systems containing Confidential or Restricted data must be granted on a least-privilege basis and reviewed quarterly by the system owner."

Incident management: "All confirmed incidents must be logged in the incident register within 24 hours, including root cause, impact and remediation steps."

Data classification: "All company information must be classified as Public, Internal, Confidential or Restricted at the point of creation, with Restricted data requiring encryption at rest and in transit."

Vendor management: "Vendors processing Confidential or Restricted data on the organisation's behalf must sign a data processing agreement and undergo a security review before onboarding."

Every policy document needs a header showing who's accountable for it, which is where most templates fall down in practice:

A version header might read: "Version 2.1, approved by [Executive Name], last reviewed March 2026, next review March 2027." That single line does more for audit readiness than pages of narrative, because it proves the document is a living control rather than a file nobody has opened in three years. For a fuller walkthrough of drafting a policy against ISO 27001 specifically, see ShieldIQ's guide to writing an information security policy.

How do these policies map to ISO 27001, NIST and GDPR?

Auditors don't read policies in isolation; they check whether policy text lines up with the control framework you claim to follow. Mapping matters more than most SMEs expect, because a beautifully written policy that doesn't reference the right control family will still generate audit findings.

• ISO 27001 Annex A groups controls into themes such as organisational, people, physical and technological controls. Your access control policy should map to the Annex A access control theme; your incident response policy maps to the incident management theme.
• NIST control families (from SP 800-53 and the NIST Cybersecurity Framework) sort activities into Identify, Protect, Detect, Respond and Recover. A backup policy sits under Recover; a password policy sits under Protect.
• NIST SP 800-12 explains, in practical terms, how a policy statement should translate into a measurable control and the evidence an auditor expects to see against it, which is the clearest public reference for this kind of mapping, according to NIST's own guidance.

GDPR adds obligations that sit alongside, rather than replace, your ISO/NIST mapping:

• Classification and retention: personal data needs its own retention schedule inside your data classification policy, not a generic "keep everything" default.
• Processors: any vendor handling personal data on your behalf needs a data processing agreement referenced in your vendor policy.
• DPIAs: high-risk processing activities (new systems, large-scale monitoring) trigger a data protection impact assessment, which your change management policy should require as a gating step.

Auditors typically expect three things sitting alongside each policy: an owner sign-off, evidence the policy was communicated to staff (training records, acknowledgement forms), and a log showing the policy has actually been enforced (access reviews, incident tickets, exception approvals). Roughly a third of ISO 27001 non-conformities in practitioner reporting trace back to missing or stale evidence rather than a badly written policy itself, which is why the paperwork around the policy matters as much as the policy text. Organisations preparing for NIS2 obligations face a very similar evidence expectation, since NIS2 auditors also want to see enforcement records, not just documents.

How do you write, approve and roll out a security policy?

Publishing a policy nobody reads solves nothing. The rollout process matters as much as the drafting.

1. Draft the policy using a template as a starting point rather than a blank page, and keep clauses short and enforceable rather than aspirational.
2. Circulate for stakeholder review among IT, HR, legal and at least one line manager who will actually have to enforce it day to day.
3. Get executive approval and sign-off, recorded in the document header with a name and date rather than a generic "management" credit.
4. Communicate and train, using a short session or e-learning module rather than an email attachment nobody opens; new starters should see it within their first month.
5. Enforce consistently, with a documented exceptions process for anyone requesting a deviation, and a defined consequence for breaches that isn't applied selectively.
6. Review on a fixed cycle, annually at minimum, with high-risk policies such as access control and incident response reviewed every six months. Recommended practice treats the review date as a hard commitment, not a soft target, since a stale review date is one of the fastest ways to lose credibility with an auditor, per Harvard's version control guidance.

Before publishing anything, answer four questions: who owns this policy, who can grant exceptions and for how long, how will breaches actually be enforced, and how will you measure whether it's working?

That last question points to KPIs worth tracking from month one: training completion rate (target close to 100% within 30 days of joining), mean time to acknowledge and respond to a reported incident, the percentage of access reviews completed on schedule, and the number of open exceptions past their approved expiry date. None of these require expensive tooling to track in a small organisation, but they do require someone checking a spreadsheet on a fixed schedule. ShieldIQ's guide to security awareness training covers how to structure the training side of this without turning it into a box-ticking exercise.

Do you need policies beyond GDPR, such as HIPAA or CCPA?

GDPR dominates policy discussions for EU-based organisations, but it isn't the only regulation your policy examples might need to reference. Which additional laws apply depends entirely on who your customers are and where your data travels, not on where your office is registered.

If you process health data for US patients or handle data on behalf of a US healthcare provider, HIPAA imposes its own access control, audit logging and breach notification requirements that sit alongside, rather than instead of, your GDPR obligations. An EU SME offering a health-tech platform to American clinics, for instance, may need a policy section addressing HIPAA's minimum necessary access standard even though the company itself sits entirely inside the EU.

Similarly, an EU company serving California-based customers may fall under the CCPA (and its successor, the CPRA), which grants consumers rights around data sale and deletion that don't map exactly onto GDPR's framework. The safest approach for an EU SME with international customers is to build a policy structure flexible enough to add a jurisdiction-specific annex, rather than rewriting the core document every time a new market opens up. Treat this as a scoping exercise during the "scope" section of your master policy: name every jurisdiction where you hold data subjects' information, and note which law governs each.

This is general guidance, not legal advice. Confirm which specific obligations apply to your organisation with a qualified legal adviser, since penalties and exact requirements vary by jurisdiction and by the nature of the data you hold.

Where do security policies fit in wider governance and risk management?

A policy that sits disconnected from your risk register is a document, not a control. The organisations that get the most value from their policies treat them as one output of a broader governance and risk management process, not a standalone compliance exercise.

Practically, that means your risk register should reference which policy addresses each identified risk, and your policy review cycle should be triggered partly by changes in that register, not just by the calendar. If a new supplier introduces a risk your vendor policy doesn't cover, that's a signal to update the policy immediately rather than waiting for the annual review. Equally, incident data should flow back into risk assessment: if incident logs show repeated phishing attempts succeeding despite an acceptable use policy, that's a governance signal that training or technical controls need attention, not just a policy tweak.

Board or senior management oversight matters here too. A policy approved by an executive and reviewed on schedule is evidence of functioning governance; a policy that was signed once in 2022 and never revisited suggests the opposite, regardless of how well written the original document was. For organisations juggling multiple frameworks at once, such as ISO 27001 alongside NIS2 or DORA, this integration work is where the real overhead lives: not in writing the policies, but in keeping the risk register, the policy library and the audit evidence all pointing at the same current state.

What SMEs get wrong about writing security policies

Drafting policies for small organisations exposes the same handful of mistakes repeatedly, and none of them are about writing quality. They're about follow-through.

The most common failure is an undocumented exception. Someone needs a temporary workaround, a manager says yes informally, and six months later that "temporary" exception is permanent and invisible to anyone reviewing the policy. Fix this by building the exceptions register into the template from day one, with an expiry date on every entry, rather than treating exceptions as an afterthought.

The second failure is a policy with no named owner, only a department. "IT owns this" isn't an owner; a person's name is. When nobody's accountable, nobody notices when the review date passes.

The third, and possibly the most damaging in an audit, is a stale review date sitting in a header that was clearly written once and never touched again. Auditors read version headers closely, and a policy dated three years ago with no revision history reads as evidence that the control isn't actually operating, whatever the policy text says.

If you're starting from nothing, prioritise access control, incident response and acceptable use first. Access control addresses the risk of unauthorised access, which drives a large share of breaches in smaller organisations. Incident response determines how quickly you contain damage once something does go wrong. Acceptable use sets baseline expectations that make enforcement possible everywhere else. Everything else, including backup, encryption and vendor management, matters, but these three reduce the largest and most immediate risks fastest.

How ShieldIQ turns policy examples into audit-ready documentation

Copying a good template gets you started, but keeping dozens of policies current, mapped to the right controls and backed by real evidence is where most SMEs lose momentum. ShieldIQ is built for exactly that gap: it uses AI-driven policy drafting to generate a first draft mapped to the frameworks you actually need, whether that's ISO 27001, NIS2, GDPR or DORA, rather than leaving you to manually cross-reference a generic template against 17 different standards.

Most SMEs starting out get the most value from combining ShieldIQ's automated compliance assessment with its policy drafting module: the assessment identifies your gaps first, then the drafting tool produces policy text mapped directly to the controls you're missing, with version tracking and review reminders built in so nothing goes stale for three years unnoticed. For organisations that want hands-on support alongside the platform, ShieldIQ's consulting services cover policy drafting workshops and vCISO support to get you audit-ready faster. Book a policy workshop or start an assessment to see which of your current policies would already pass an audit, and which need work.

Where to find authoritative policy templates

Choosing where to start depends on how much structure you want handed to you versus how much you're prepared to adapt yourself.

• SANS information security policy templates — a free library covering access management, privileged accounts, cloud provider management and incident response; the best starting point for individual, domain-specific policies.
• NIST SP 800-12r1 — explains how policy statements should map to control objectives and audit evidence; use this when you need to justify a mapping decision to an auditor.
• Open Security Architecture's information security policy template — a full, ~20-section master policy referencing over 70 NIST SP 800-53 controls; the strongest choice if you want one comprehensive document rather than several smaller ones.
• ToolkitCafe's ISO 27001-aligned IT security policy template — covers ten security domains and includes worksheets like risk registers and audit schedules, useful if certification is the near-term goal.
• CRFsecure's policy library — curated, topic-specific policies such as privileged account management and cloud service provider management for filling gaps in a master policy.

If you only need one document fast, start with SANS or ToolkitCafe. If you're building toward full ISO 27001 certification and want every control cross-referenced, Open Security Architecture's control-mapped template saves the most rework later. Vendor security pages, such as ClipForge's published security practices, are also worth reviewing as real-world examples of how organisations communicate their controls externally, particularly when drafting your own vendor management or third-party disclosure clauses.

What should a small business's first information security policy cover?

A first policy should cover acceptable use, access control and password/authentication at minimum, since these address the most common causes of breaches in small organisations: weak credentials, unrestricted access and careless use of company systems. Add incident response as a close second so there's a documented process the moment something goes wrong.

How often should information security policies be reviewed?

Most policies need review at least annually, with high-risk areas such as access control and incident response reviewed every six months. The review date belongs in the document header alongside the version number and approver's name, not buried in a separate log nobody checks.

Are free templates from SANS or NIST good enough for ISO 27001 certification?

Free templates from SANS and NIST provide a solid structural foundation and map well to recognised control families, but they typically need tailoring to your specific risk register, org chart and existing evidence before an auditor will accept them as-is. Treat them as a strong starting draft, not a finished, certification-ready document.

What's the difference between an IT security policy and an information security policy?

An IT security policy usually focuses narrowly on systems, networks and technical controls, while an information security policy covers information in any form, including paper records, verbal disclosures and third-party handling. Most SMEs are better served by scoping their master policy as information security and letting IT-specific detail sit in supporting procedures.

Sources

• SANS information security policy templates
• NIST SP 800‑12r1
• Open Security Architecture — information security policy
• Berkeley — information security policy exception process

Recommended

• Blog | ShieldIQ
• Zero Trust Security for SMEs: A Practical Starting Point | ShieldIQ
• How to Write an Information Security Policy (With ISO 27001 in Mind) | ShieldIQ
• KnowBe4 alternatives for SMEs: 2026 shortlist | ShieldIQ