Information Security Policy Template

Many organisations hold a stack of security policies but no single, board-approved statement of what information security means for them, who is accountable for it and how the other policies fit together. This template gives you that top-level information security policy: purpose, scope, objectives, roles, principles, a one-paragraph statement for each policy area with a pointer to the topic-specific policy beneath it, exceptions, enforcement and review. It is written to meet ISO/IEC 27001:2022 clause 5.2 and Annex A control 5.1 and the NIST CSF 2.0 Policy category (GV.PO), and it treats non-human identities and AI agents as subjects of access control in their own right. Replace the text in square brackets, keep the numbered sections, and take it through your normal approval route.

How to use this template

• Replace text in square brackets, such as [Organisation], [Board], [CISO] and [X days], with your own names, roles and values. Delete bracketed options that do not apply.
• "Must" is mandatory. "Should" is expected practice; departing from it needs a recorded reason. Anything that cannot be met goes through section 9 (Exceptions).
• Keep this policy short and stable. Detail that changes often (password lengths, tool names, retention periods) belongs in the topic-specific policies named in section 8. Small organisations can combine several of those into one document, provided each statement keeps an owner and a review date.
• Top management must establish this policy (clause 5.2) and approve it (Annex A 5.1). Record the approval in minutes or a signed version history, because certification auditors ask for it.
• Keep the framework mapping in section 12 in your ISMS records even if you remove it from the published policy.

1. Purpose

This policy sets out [Organisation]'s commitment to protecting the confidentiality, integrity and availability of the information it holds and the systems it relies on. It establishes the objectives and principles that all other security policies, standards and procedures must follow, assigns accountability, and commits [Organisation] to meeting its legal, regulatory and contractual information security obligations and to continually improving its information security management system (ISMS).

2. Scope

This policy applies to:

• People: all employees, directors, contractors, temporary staff and third parties who access [Organisation] information or systems.
• Information: all information created, received, stored, processed or transmitted by or for [Organisation], in any form.
• Technology: all systems, networks, applications, cloud services, endpoints and operational technology owned, leased or used by [Organisation], including those operated by suppliers on its behalf.
• Non-human identities: service accounts, workload identities, API keys, tokens, certificates, OAuth applications and automation accounts.
• AI systems and agents: AI models, assistants and agents that [Organisation] builds, buys or allows staff to use, and any AI agent acting on [Organisation] systems or data.
• Locations: [all sites and remote working / the ISMS scope defined in [ISMS scope document]].

3. Definitions

• Information asset owner: the named manager accountable for an information asset or system, its classification, its access and its risks.
• Non-human identity (NHI): any identity used by software rather than a person to authenticate, such as a service account, API key, token, certificate or workload identity.
• AI agent: software that uses an AI model to decide on and take actions, such as calling tools or APIs, with or without human approval of each step.
• Exception: a time-limited, approved departure from a requirement, with compensating controls.

4. Information security objectives

[Organisation] sets measurable objectives each year through [management review] and tracks them in the ISMS. For [year] they are:

1. Maintain [ISO/IEC 27001 certification / SOC 2 Type 2 attestation / Cyber Essentials Plus] with no major nonconformities.
2. Recover [critical services] within their approved recovery time objectives in tested scenarios.
3. Ensure every human and non-human identity with production access has a named owner and is reviewed at least [quarterly / annually].
4. Remediate [critical] vulnerabilities on internet-facing systems within [X days].
5. Achieve [95%] completion of security awareness training within [30 days] of joining and annually thereafter.

5. Roles and responsibilities

6. Principles

• Risk-based: controls are selected and prioritised from assessed risk using [Organisation]'s risk methodology. Residual risk is accepted only by someone with authority to do so.
• Least privilege: people, services and AI agents receive only the access they need, for only as long as they need it. Standing administrative access is minimised.
• Secure by design and by default: security requirements are set at the start of every project, purchase and change, and systems are deployed with secure configurations.
• Accountability: every asset, identity, risk and exception has a named owner.
• Assume compromise: systems are monitored, logs are kept and incidents are planned for, so breaches are detected and contained quickly.

7. Compliance obligations

[Organisation] records the legal, regulatory and contractual requirements that apply to its information in [legal register]. These include [UK GDPR and the Data Protection Act 2018 / EU GDPR / NIS2 national law / DORA / PCI DSS / customer contract clauses]. Where a requirement is stricter than this policy, the stricter requirement applies.

8. Policy areas

Each statement sets [Organisation]'s position. Detailed requirements sit in the topic-specific policy in brackets, which must be consistent with this policy, have a named owner and be reviewed at least annually.

8.1 Access control and identity, including NHIs and AI agents

Access is granted on business need and least privilege, approved by the asset owner, and reviewed at least [annually; quarterly for privileged access]. Every identity, human or non-human, must be unique, attributable to a named owner and removed when no longer needed. Multi-factor authentication is required for remote, privileged and cloud console access. Service accounts, API keys, tokens and certificates must be inventoried, held only in [approved secrets manager], scoped to least privilege and rotated or expired on a defined schedule, and must never be embedded in code, scripts or shared documents. AI agents must have their own identity, must not use a person's credentials and must not exceed the access of any user they act for. [Access Control Policy; Privileged Access Standard; Non-Human Identity Standard; AI Agent Security Policy]

8.2 Asset management and classification

[Organisation] keeps an inventory of information assets, systems, software, cloud services and identities, each with an owner. Information is classified as [Public, Internal, Confidential, Restricted] and handled accordingly. [Asset Management Policy; Information Classification and Handling Policy]

8.3 Acceptable use

Users must use [Organisation] information and systems for authorised purposes, protect their credentials, not bypass security controls, and use only approved software, cloud services and AI tools. [Acceptable Use Policy]

8.4 Cryptography

Confidential and restricted information must be encrypted in transit and at rest using algorithms approved in [Cryptography Standard]. Keys are generated, stored, rotated and destroyed under documented procedures, with keys for critical systems held in [HSM / cloud key management service]. [Cryptography and Key Management Policy]

8.5 Operations security

Systems are built to approved secure baselines, protected against malware, patched within [timescales by severity], backed up with tested restores, and changed only through [change management]. Security events are logged centrally, protected from tampering, retained for [X months] and monitored. [Operations Security Policy; Vulnerability Management Standard; Logging and Monitoring Standard]

8.6 Communications and network security

Networks are segmented by risk, administrative interfaces are not exposed to the internet, and remote access uses [approved service] with multi-factor authentication. Information sent to external parties uses approved, protected methods. [Network Security Policy; Information Transfer Policy]

8.7 Secure development

Software built or configured by or for [Organisation] follows a secure development life cycle, including threat modelling for significant changes, code review, dependency and secrets scanning, and security testing before release. Non-production environments must not use production credentials. [Secure Development Policy]

8.8 Supplier security

Suppliers that access [Organisation] systems or data, or provide critical services, are risk-tiered and assessed before contract and periodically after. Contracts include security, incident notification, sub-processor and audit terms proportionate to the tier. Supplier access, including OAuth grants and API keys issued to or by suppliers, is inventoried, limited and revoked at contract end. [Supplier Security Policy; Vendor Security Assessment Procedure]

8.9 Incident management

All staff must report suspected incidents and weaknesses immediately. [Organisation] keeps an incident response plan with roles, severity levels, evidence handling and notification decision points, including [72-hour] personal data breach and regulatory deadlines, and tests it at least [annually]. [Incident Response Policy and Plan]

8.10 Business continuity

Information security is maintained during disruption. Critical services have documented recovery time and recovery point objectives, critical backups are protected from tampering and deletion, and plans are tested at least [annually]. [Business Continuity Policy; Disaster Recovery Plan]

8.11 People security

Background checks proportionate to role are completed before access is granted. All staff complete awareness training on joining and [annually], with extra training for privileged users and developers. [People Security Policy; Security Awareness Standard]

8.12 Use of AI

Staff may use only AI tools approved by [AI governance body] and must not enter [Confidential or Restricted] information into unapproved AI services. AI systems built or bought by [Organisation] are risk assessed before use and, where they process personal data, assessed for data protection impact. AI agents that take actions on [Organisation] systems are governed by the AI Agent Security Policy. [Acceptable Use of AI Policy; AI Agent Security Policy]

9. Exceptions

Where a requirement cannot be met, the requester submits an exception through [exceptions process] stating the requirement, business reason, risk, compensating controls and an expiry date of no more than [12 months]. [Security team] assesses the risk; approval sits with [the asset owner for low risk / the CISO for medium risk / the risk committee for high risk]. Exceptions are recorded in the exceptions register, reviewed before expiry and reported to [the security steering group]. An expired exception is a policy breach.

10. Compliance and enforcement

Compliance is monitored through technical controls, access reviews, internal audit and management review. Nonconformities are recorded, root causes analysed and corrective actions tracked to closure. Breaches by staff may lead to action under [disciplinary procedure]. Breaches by suppliers are handled under the contract. [Security team] may suspend non-compliant systems, accounts, integrations or AI agents that present an immediate risk.

11. Approval, communication and review

• Approval: approved by [Board / CEO] on [date]. Changes need the same approval.
• Communication: published on [intranet location], communicated on joining and after each material change, acknowledged in [HR or learning system], and available to customers, auditors and other interested parties [on request / in the trust centre].
• Review: the [CISO] reviews this policy at least annually and after significant changes in the organisation, risks, technology, law or after a major incident, and reports the outcome to management review.
• Version control: owner [name, role]; version [x.y]; approved [date]; next review [date].

12. Framework mapping

13. Source references

1. ISO: ISO/IEC 27001:2022, Information security management systems, Requirements
2. NIST: The NIST Cybersecurity Framework (CSF) 2.0
3. CSF Tools: NIST SP 800-53 Rev. 5 AC-1 Policy and Procedures
4. CSF Tools: NIST SP 800-53 Rev. 5 PM-1 Information Security Program Plan
5. NCSC: Cyber Assessment Framework, Objective A, Managing security risk
6. NIST: AI Risk Management Framework core
7. ISO: ISO/IEC 42001:2023, Artificial intelligence management system
8. TÜV NORD: Navigating ISO 27001 Annex A control 5.1
9. SANS: Security policy templates

Implementation guidance

A policy that promises controls the organisation does not run is an audit finding waiting to happen. Clause 5.2 expects the policy to suit the organisation's purpose, include objectives or a framework for setting them, commit to meeting applicable requirements and to continual improvement, and be documented, communicated and available to interested parties as appropriate. NIST CSF 2.0 adds that policy is "communicated and enforced" (GV.PO-01) and updated as "requirements, threats, technology, and organizational mission" change (GV.PO-02).

1. Start from scope and risk. Confirm the ISMS scope, legal register and top risks first.
2. Inventory existing policies. Map every current policy and standard to the twelve areas in section 8, merge duplicates and name an owner for each. Gaps around service accounts, API keys and AI tools usually show up here.
3. Test each statement. Ask each owner whether the statement is true today. If not, fund the gap with a dated plan or raise a time-limited exception. Do not publish requirements you cannot evidence.
4. Approve and record. Take the policy and the section 4 objectives to the [Board] or CEO and minute the approval. Topic-specific policies are approved by managers with suitable authority.
5. Communicate and capture acknowledgement in the HR or learning system, on joining and after each material change.
6. Measure and review. Feed the metrics below into management review (clause 9.3) and review annually and after major incidents.

Small versus large organisations: a 50-person company can run this policy plus three topic-specific documents (acceptable use; access and operations; incident and continuity) and an exceptions spreadsheet. A large or regulated organisation keeps this policy at board level, delegates topic-specific policies to named executives, and links each statement to controls, evidence and the Statement of Applicability in a GRC platform.

Metrics that show it is working:

• Percentage of staff who acknowledged the current version within [30 days] of joining or of a material change.
• Percentage of topic-specific policies reviewed within their review date.
• Open exceptions, and the number past expiry (target zero).
• Percentage of non-human identities and AI agents with a named owner and a review in the last [period].

Common failure patterns: copying a template that promises controls nobody runs; a policy approved once and never reviewed; no exceptions route, so staff quietly ignore the policy; sub-policies that contradict the top-level one; and access control written only for people, leaving service accounts, integration tokens and AI agents ungoverned. The Cloudflare Thanksgiving breach shows the cost of the last one: credentials left unrotated after a supplier's incident gave an attacker a way in. Each area is covered in more depth in NHI Mgmt Group guides:

• Certification and the Statement of Applicability: ISO 27001 Certification Guide
• Service accounts: Service Account Security Guide
• Owners for every non-human identity: NHI Ownership Guide
• Secrets and API keys: Secrets Management Guide
• The sub-policy for AI agents: Agentic AI Security Policy Template
• Incidents: Incident Response Guide

This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: ISO 27001 Certification Guide · Agentic AI Security Policy Template · NHI Governance Maturity Model · Identity Security Programme Guide