ISO 27001 Templates: Free Policy Templates for the 2022 Standard

These free ISO 27001 templates cover the policy layer of an information security management system (ISMS) built to ISO/IEC 27001:2022. You get a complete information security policy for Clause 5.2, a full vulnerability management and security testing policy for Annex A 8.8 and 8.29, and outlines for thirteen more topic-specific policies, each mapped to its Annex A controls and to the evidence an auditor samples. Three of the thirteen, access control, backup and acceptable use, now also have full policy text below. Copy the text, replace the bracketed fields, and cut what does not fit. The standard names only one policy as mandatory; the rest follow from your risk assessment and Statement of Applicability.

Invadel is a penetration testing company, not a certification body, and these templates are free to copy, with no form to fill in. We provide the testing your policies commit you to: the scans and penetration tests behind 8.8 and 8.29, described on our ISO 27001 penetration testing page and bundled as vulnerability assessment and penetration testing. Each test below has a published starting price (see our pricing page) and is fixed in writing before work starts. Every penetration test includes a free retest, and every scan a free re-scan of fixed findings.

Which ISO 27001 policies are mandatory

ISO/IEC 27001:2022 is still the current edition, with the climate action Amendment 1:2024 added to Clause 4. It asks for policies in two places:

• Clause 5.2 requires top management to establish one information security policy. It must suit the organization’s purpose, include objectives or a framework for setting them, commit to satisfying applicable requirements and to continual improvement, be documented and communicated internally, and be available to interested parties as appropriate.
• Annex A 5.1 adds topic-specific policies. They and the main policy must be defined, approved by management, published, communicated to and acknowledged by relevant personnel and interested parties, and reviewed at planned intervals and after significant change. Annex A controls are selected through your Statement of Applicability, but nobody credibly excludes 5.1.

The standard never lists which topic-specific policies to write. A few controls name one: access rights (5.18), information access restriction (8.3) and secure authentication (8.5) point to the policy on access control, and information backup (8.13) to the policy on backup. ISO/IEC 27002:2022, the guidance companion, gives examples under 5.1, among them access control, asset management, backup, cryptography, incident management, secure development and management of technical vulnerabilities, and asks under 8.1 for one on user endpoint devices.

Before using any downloaded pack, look for 2013 numbering such as A.9 for access control or A.12.6.1 for vulnerabilities. Certificates against the 2013 edition had to transition by October 31, 2025 under IAF MD 26, so a pack that still cites those numbers predates the standard you are audited against.

The ISO 27001 policy templates at a glance

Use this table to build your policy register. The last column is what auditors typically sample to see whether a policy operates.

Policy	Annex A (2022)	Sections the template needs	What the auditor samples
Information security policy	Clause 5.2, 5.1	Full template below	Approval record, acknowledgements, objectives tracking
Acceptable use	5.10, 5.11, 6.2, 6.3	Template 5 below: permitted and prohibited use, monitoring notice, return of assets, awareness training	Signed acknowledgements and training records for recent hires
Access control	5.15 to 5.18, 8.2, 8.3, 8.5	Template 3 below: least privilege, joiners and leavers, privileged access, MFA, review frequency	Leaver tickets against account deletions, the last access review
Asset management, classification and data handling	5.9, 5.12, 5.13, 5.33, 5.34, 8.10 to 8.12	Inventory ownership, classification levels, labeling, handling rules, retention and deletion, personal data, masking and leakage prevention	Asset inventory against what is actually running, deletion records
Cryptography and key management	8.24	Approved algorithms, encryption at rest and in transit, key rotation	Storage and TLS settings, rotation records
Backup	8.13	Template 4 below: scope, frequency, retention, isolation, restore testing	Restore test records
Incident management	5.24 to 5.28, 6.8	Reporting channel, severity levels, roles, evidence, lessons learned	Incident log, a tabletop exercise record
Supplier and cloud security	5.19 to 5.23	Supplier tiers, due diligence, contract clauses, cloud selection and exit	Supplier register, reviews of critical suppliers
Secure development	8.25 to 8.28, 8.30 to 8.33	Secure coding rules, code review, environment separation, test data	Merged pull requests with review
Vulnerability management and security testing	5.7, 8.8, 8.29	Full template below	Scan cadence, pentest report, retest, fixes on time
Endpoint and remote working	8.1, 8.9, 8.23, 6.7, 7.7, 7.9	Device standards, configuration baselines, disk encryption, screen lock, web filtering, home working	Device management compliance report
Physical security	7.1 to 7.14	Entry control, visitors, secure areas, equipment disposal	Visitor log, disposal certificates
Network security and information transfer	8.20 to 8.22, 5.14	Segmentation, firewall rule review, approved transfer methods	Rule review record, segmentation evidence
Logging and monitoring	8.15 to 8.17	Events logged, retention, log protection, alert review	Retention settings, alert triage records
Business continuity and ICT readiness	5.29, 5.30, 8.14	Recovery objectives, continuity roles, test schedule	The last continuity or failover test

A minimum set for a small company

Auditors check that your policies cover the topics your applicable controls need and that each one is approved, communicated and acknowledged, not how many files you keep. A 30-person SaaS company can run eight: the information security policy; one staff-facing acceptable use, endpoint and remote working policy; access control; asset and data handling; operations security (backup, logging, network, cryptography, change); secure development and vulnerability management; incident management and continuity; and supplier and cloud security. A fully remote company can cover physical security in a short section on home working.

Template 1: information security policy template (Clause 5.2)

Keep the top-level policy to two pages. It sets direction and commitments; the detail belongs in the topic-specific policies.

[Company] Information Security Policy

Owner: [role]. Approved by: [name, title] on [date]. Version: [1.0]. Next review: [date, within 12 months]. Classification: [Public / Internal, shareable on request].

1. Purpose. This policy sets [Company]’s direction for information security and records top management’s commitments for the information security management system (ISMS).

2. Scope. It applies to [the ISMS scope as defined in the scope statement], to all employees and contractors, to [third parties with access to our systems], and to information in any form.

3. Our approach. We protect the confidentiality, integrity and availability of information in line with business needs and the results of risk assessment. We treat risks to the level set by our risk acceptance criteria and record the controls we apply in the Statement of Applicability.

4. Objectives. Management sets measurable information security objectives each year and reviews progress at management review. Current objectives are in [objectives register] and include [for example: fix critical vulnerabilities within the deadline in the vulnerability management policy; complete awareness training within 30 days of joining; test a production restore each quarter].

5. Commitments. Top management commits to satisfy applicable information security requirements, including legal, regulatory and contractual obligations and commitments made to customers, and to continually improve the ISMS.

6. Roles. [CEO] owns this policy and provides resources. [ISMS manager] runs the ISMS and reports on its performance to top management. Risk owners accept residual risk for their areas. Everyone covered follows this policy and the topic-specific policies, and reports security events through [channel].

7. Topic-specific policies. This policy is supported by the topic-specific policies in [policy register], each approved by [role]. If one conflicts with this policy, this policy prevails until the conflict is resolved.

8. Compliance and exceptions. Compliance is reviewed through internal audit and [monitoring]. Exceptions need a documented risk assessment, approval from the risk owner and [ISMS manager], and an expiry date. Violations are handled through the disciplinary process.

9. Communication. This policy is communicated at onboarding and after every change, and acknowledgement is recorded. It is available to interested parties [on request / at URL].

10. Review. Reviewed at least annually and after significant change to the business, threats, legal requirements or the ISMS scope.

Each section answers a requirement an auditor can trace:

Section	Requirement it answers
3. Our approach	Clause 5.2 a), appropriate to the purpose of the organization
4. Objectives	Clause 5.2 b) and Clause 6.2
5. Commitments	Clause 5.2 c) and d)
6. Roles	Clause 5.3 and Annex A 5.2
7. Topic-specific policies	Annex A 5.1
8. Compliance and exceptions	Annex A 5.36 and 6.4
9. Communication	Clause 5.2 f) and g), and acknowledgement under 5.1
10. Review	Annex A 5.1, planned intervals and significant change

Template 2: vulnerability management and security testing policy (8.8 and 8.29)

This policy draws close audit scrutiny because its evidence is technical and dated. Annex A 8.8 (technical vulnerabilities) and 8.29 (security testing in development and acceptance) name no frequency or deadline, so this policy sets them, and the auditor holds you to them.

[Company] Vulnerability Management and Security Testing Policy

Owner: [Head of Security]. Approved by: [name, title] on [date]. Version: [1.0]. Next review: [date].

1. Purpose and scope. This policy sets how [Company] identifies technical vulnerabilities, evaluates exposure and fixes them in time (Annex A 8.8), and builds security testing into development and acceptance (8.29). It covers every system in the ISMS scope: [cloud accounts, customer-facing applications and APIs, corporate network, endpoints].

2. Coverage. The asset inventory defines what is scanned and tested. An in-scope asset missing from the inventory is added and treated as a finding.

3. Vulnerability information. We monitor vendor advisories, the Known Exploited Vulnerabilities (KEV) catalog published by the Cybersecurity and Infrastructure Security Agency (CISA), and [threat intelligence source], which also supports Annex A 5.7.

4. Scanning. Authenticated scans of internal assets run at least [monthly / quarterly], scans of internet-facing assets at least [monthly], and both after significant change. Results are validated before tickets are raised.

5. Penetration testing. An independent penetration test of [the external perimeter, the customer-facing application and API, the internal network or cloud environment] runs at least annually and after significant change, defined as [a new product, a major architecture change, a new cloud account, an acquisition]. Testers are a qualified third party, or internal staff independent of the teams that built the system, working to a scope drawn from the ISMS scope and Statement of Applicability.

6. Security testing in development. Security requirements are defined for each [significant feature]. [Static analysis and dependency scanning] run in the build pipeline. Major changes pass security acceptance testing before release, and new internet-facing applications are penetration tested before go-live.

7. Remediation deadlines. Findings are rated with CVSS and ranked on KEV status, exploit likelihood (EPSS), exposure and business impact. Fix or mitigate within the deadlines in Appendix A: Critical (9.0 to 10.0) [7 days]; High (7.0 to 8.9) [30 days]; Medium (4.0 to 6.9) [90 days]; Low (0.1 to 3.9) [180 days, or accept]. A known exploited vulnerability on an internet-facing system is fixed within [72 hours] regardless of score.

8. Verification. A fix counts only when verified by rescan or retest. Penetration test findings close after the tester confirms the fix.

9. Exceptions. A finding that cannot be fixed in time needs an exception in the risk register with a compensating control, the risk owner’s approval and an expiry date. [CTO] approves exceptions for High and Critical findings.

10. Records and review. Scan reports, test reports, retest results, tickets and exceptions are kept for [three years]. This policy is reviewed at least annually and after any incident caused by a known vulnerability.

The bracketed deadlines are example values, not ISO requirements; the severity bands are the CVSS qualitative rating scale published by FIRST. For comparison, CISA’s BOD 26-04, issued June 10, 2026, gives federal agencies three days, plus forensic triage, for the most dangerous known exploited vulnerabilities. To set your own, see risk-based vulnerability management for tiering deadlines, vulnerability remediation for the workflow that meets them, and penetration testing frequency for cadence. Our vulnerability management process guide covers a program policy outside ISO, and the penetration testing RFP template helps you choose the tester section 5 requires.

Template 3: access control policy

Annex A 5.15 to 5.18, 8.2, 8.3 and 8.5 sit behind this policy, and three of those controls refer to it by name.

[Company] Access Control Policy

Owner: [IT manager]. Approved by: [name, title] on [date]. Version: [1.0]. Next review: [date].

1. Purpose and scope. This policy sets how access to [Company] information and systems is granted, used, reviewed and removed. It covers every account, human or service, on systems in the ISMS scope.

2. Principles. Access is granted on least privilege and need to know, to a named individual, with one identity per person. A shared account needs a documented exception.

3. Joiners, movers and leavers. Access is requested through [ticketing system] and approved by the system owner. On a role change, access no longer needed is removed. On leaving, all access is disabled within [one working day], and immediately for an involuntary exit.

4. Authentication. Multi-factor authentication is required for [remote access, email, cloud consoles and administrator accounts]. Passwords meet [standard] and are kept in [password manager]. Default credentials are changed before a system goes live.

5. Privileged access. Administrator rights are held in separate accounts, granted for [a fixed period], logged, and not used for email or browsing.

6. Access reviews. System owners review user access every [six months] and privileged access every [quarter], and record the result and any removals.

7. Service accounts and keys. Each has a named owner, the minimum permissions it needs and a rotation interval of [period].

8. Exceptions and review. Exceptions follow the information security policy. This policy is reviewed at least annually and after significant change.

The auditor samples leavers and compares exit dates with the dates accounts were disabled, so set the deadline in section 3 to one you already meet.

Template 4: backup policy

Control 8.13 is the one that points to a topic-specific policy on backup, and its evidence is the restore test.

[Company] Backup Policy

Owner: [Head of Engineering]. Approved by: [name, title] on [date]. Version: [1.0]. Next review: [date].

1. Purpose and scope. This policy sets how [Company] backs up information, software and systems so they can be restored after loss or corruption. It covers [production databases, file storage, source code, configuration, and SaaS data such as email and documents].

2. Recovery objectives. Each system in scope has a recovery point objective and a recovery time objective set by its owner and recorded in [register]. Backup frequency is set to meet the recovery point objective.

3. Frequency and retention. [Production databases: daily or continuous. File storage: daily. Configuration: on change.] Backups are kept for [30 days of daily copies and 12 months of monthly copies], subject to legal and contractual retention and deletion requirements.

4. Protection. Backups are encrypted and stored in [a separate account or region] from the systems they protect. At least one copy cannot be altered or deleted with production administrator credentials.

5. Monitoring. Backup jobs are monitored, and a failed job raises a ticket within [one working day].

6. Restore testing. A restore of [a production database and a sample of files] is tested every [quarter], timed against the recovery time objective, and recorded with the result and any corrective action.

7. Responsibilities and review. [Role] operates backups. System owners confirm coverage when a system is added or changed. This policy is reviewed at least annually and after any failed restore.

Keep each restore test record with its date, what was restored, how long it took and who signed it off.

Template 5: acceptable use policy

This is the policy every member of staff reads and acknowledges, so write it for them: short sentences, no control numbers.

[Company] Acceptable Use Policy

Owner: [ISMS manager]. Approved by: [name, title] on [date]. Version: [1.0]. Next review: [date].

1. Purpose and scope. These are the rules for using [Company] information, devices, accounts and networks. They apply to all employees and contractors, on company devices and on personal devices used for work.

2. Acceptable use. Company systems are for business purposes. Limited personal use is allowed where it does not interfere with work, break the law or put information at risk.

3. You must. Lock your screen when you step away. Use the approved password manager and multi-factor authentication. Keep company information in [approved systems]. Install updates when prompted. Report a lost device or a suspected incident to [channel] immediately.

4. You must not. Share accounts or passwords. Install unapproved software. Move company or customer information to personal email, personal storage or unapproved AI tools. Disable security controls. Connect unmanaged devices to [the production network].

5. Monitoring. [Company] monitors its systems and networks for security purposes, as permitted by law. [State what is monitored.]

6. Return of assets. On leaving, or on request, return all devices and information and delete company data from personal devices.

7. Acknowledgement and breaches. Everyone covered acknowledges this policy at onboarding and after each change, and completes awareness training within [30 days] of joining. Breaches are handled through the disciplinary process.

The bracketed periods in Templates 3 to 5 are example values, not ISO requirements. Have section 5 of the acceptable use policy checked against the employee monitoring rules where your staff work.

How to adapt a template so it survives the audit

Auditors audit you against your own documents. A template copied without editing usually fails in one of these ways:

1. It promises what you do not do. A policy requiring quarterly access reviews, with one review on file, earns a nonconformity. Write the cadence you will keep.
2. It names tools and steps. Keep tools, procedures and deadline tables in documents or appendices beneath the policy, so changing a scanner or a deadline does not need management re-approval.
3. No acknowledgement evidence. Annex A 5.1 requires acknowledgement. A signed or click-through record per person is evidence; an all-staff email is weak.
4. It contradicts the Statement of Applicability. No policy should require a control the SoA excludes.
5. No document control. Clauses 7.5.2 and 7.5.3 expect each document to be identified, reviewed and approved, and its changes version-controlled. The header line in each template covers it.
6. It copies the standard. ISO text is copyrighted, and lifted “shall” sentences read as the standard’s requirements rather than your commitments. Paraphrase, as these templates do.

Other free ISO 27001 templates and toolkits

The ISO27k Toolkit from the ISO27k Forum community includes skeleton policies and Statement of Applicability spreadsheets, mostly under a Creative Commons license. The SANS policy template library offers 36 free policies organized by topic rather than by ISO 27001 control; use the table above to assign each to its Annex A controls.

A full pack also needs the documents that are not policies: the ISMS scope statement (Clause 4.3), the risk assessment method (6.1.2), which our security risk assessment guide walks through, the Statement of Applicability and risk treatment plan (6.1.3), the internal audit program (9.2), management review results (9.3) and a corrective action log (10.2). Our ISO 27001 checklist lists every mandatory record.

What it costs to test the controls behind the policies

Template 2 commits you to scanning and penetration testing on a schedule. That is the part Invadel provides, at published starting prices fixed in writing from your scope.

Template 2 section	Test that evidences it	Invadel starting price
Section 4, recurring scans (8.8)	Vulnerability scanning, analyst validated, free re-scan	$1,500 per scan up to 250 devices, $2,500 up to 1,000
Section 5, annual independent test (8.8)	External network or web application penetration test	$4,200 external, $5,200 web app
Section 6, testing before release (8.29)	Web application or API penetration test	$5,200 web app, $4,000 API

Every penetration test includes a free retest and an attestation letter. Compare the vulnerability scanning pricing tiers, total several tests with the cost calculator, or read the sample report your auditor would receive. Templates cut the documentation line, which Drata puts at $5,000 to $15,000 or more when a consultant writes it, depending on how much starts from scratch; our ISO 27001 certification cost guide prices the rest, from audit days to the tests behind 8.8 and 8.29.

Frequently asked questions

Which policies are mandatory for ISO 27001? Only the information security policy in Clause 5.2 is required by name. Annex A 5.1 adds topic-specific policies, and controls 5.18, 8.3, 8.5 and 8.13 refer to access control and backup policies; the rest follow from your risk assessment and Statement of Applicability.

Are free ISO 27001 templates enough to get certified? No. A certification body samples records showing each policy in use: access reviews, restore tests, scan results, acknowledgements. Templates save drafting time; the evidence comes from running the ISMS.

How often should ISO 27001 policies be reviewed? At planned intervals and after significant change. Annual review is the common choice, and whatever interval your policy states is the one the auditor checks.

Can the same policies serve SOC 2? Mostly, yes. Both expect approved, communicated policies over similar control areas, though SOC 2 has no Statement of Applicability. Our comparison of ISO 27001 vs SOC 2 covers the differences, and the SOC 2 controls list shows the criteria your policies would need to cover.

Does ISO 27001 require a penetration testing policy? Not by name. Annex A 8.8 and 8.29 require you to manage technical vulnerabilities and define security testing, and a policy like Template 2 documents both. Our ISO 27001 penetration testing page explains what auditors expect from the test itself.

Are these templates updated for ISO 27001:2022? Yes. They use the 2022 Annex A numbering and the 2022 wording of control 5.1, which names topic-specific policies and requires relevant personnel to acknowledge them. The 2024 climate amendment changed Clause 4, not the policy requirements.

Can I download these ISO 27001 templates as Word files? There is no file to download. The templates are plain text on this page, free to copy with no form: paste them into Word or Google Docs and add your own document header.

How many policies does a small company need for ISO 27001? There is no required number. A 30-person SaaS company can cover its applicable controls with about eight documents by combining related topics, as long as each is approved, communicated and acknowledged.

The short version

ISO 27001 requires one information security policy by name and topic-specific policies chosen through your Statement of Applicability. Start from the five templates above, build the rest from the table, and commit only to what you will do, because the auditor tests your records against your words. When your policy calls for an independent test, scope it against your ISMS boundary at a fixed price through our ISO 27001 penetration testing or VAPT: external network tests from $4,200 and validated scans from $1,500 per scan, retest included, with starting prices on our pricing page.