Security policy template

Use this security policy template as starter information and a starter cyber security policy for your organisation. It is designed to be copied, edited, reviewed, approved, communicated, and maintained—not treated as a finished compliance artefact.

The template sets organisation-level expectations for protecting systems, data, users, and information assets. It does not, by itself, make an organisation compliant with ISO, SOC 2, HIPAA, PCI DSS, NIST, or any other framework or law.

What this security policy template is for

This is a main information security policy template. It is intended to define:

why the policy exists
who and what it applies to
who owns security responsibilities
how information assets should be protected
how incidents, exceptions, enforcement, and review are handled
which supporting policies or procedures provide more detailed requirements

NIST describes policy content in terms such as purpose, scope, roles and responsibilities, accountable ownership, and organisation-defined review cadence and update triggers in its security policy and procedures control guidance (NIST SP 800-53 Rev. 5.1, PL-1). Use those fields as practical structure, not as a universal legal template.

Security policy template preview

Copy the language below into your own document and replace the placeholders before approval—or before sending it for approval.

1. Policy title and ownership

Policy name: Information Security Policy
Organisation: [Company Name]
Policy owner: [Policy Owner / Role]
Approved by: [Approver / Governance Body]
Effective date: [Date]
Review cadence: [Review Cadence]
Version: [Version Number]

Edit before use: name the accountable owner—or, more precisely, the accountable role—the approving authority, and the review cadence. Avoid generic ownership such as “IT” unless a specific role is accountable.

Review by: security, IT, leadership, and any governance function that approves company-wide policies.

2. Purpose

The purpose of this policy is to define [Company Name]’s expectations for protecting information systems, data, users, and organisational assets from unauthorised access, misuse, loss, disclosure, alteration, or disruption.

Edit before use: align the purpose with your organisation’s risk profile and terminology. If you handle regulated data, reference the relevant data types without claiming compliance from the policy alone.

Review by: security, compliance, legal if regulated data or contractual obligations are referenced.

3. Scope and applicability

This policy applies to all employees, contractors, temporary workers, service providers, and other authorised users who access [Company Name] systems, networks, applications, data, or information assets.

This policy applies to information and systems owned, managed, hosted, or used by [Company Name], including [list key environments, business units, regions, or systems if needed].

Edit before use: decide whether the policy covers contractors, vendors, subsidiaries, cloud environments, personal devices, production systems, customer data, or specific business units—or, more accurately, which of these it covers.

Review by: security, IT, legal, procurement, HR, and business owners where third parties or employees are in scope.

4. Roles and responsibilities

[Company Name] assigns information security responsibilities as follows:

Executive leadership is responsible for supporting the security programme and approving this policy where applicable.

Policy owner is responsible for maintaining this policy, coordinating reviews, and tracking approved changes.

Security or IT team is responsible for implementing and monitoring relevant security controls and procedures.

System and data owners are responsible for protecting the systems and data under their control.

Users are responsible for following this policy and reporting suspected security issues through approved channels.

Third parties must follow applicable security requirements in contracts, agreements, or approved procedures.

Edit before use: replace generic roles with actual job titles or teams—or job titles first, where possible. Do not assign responsibilities to teams that do not have authority or capacity to perform them.

Review by: leadership, security, IT, HR, procurement, and system owners.

5. Information asset protection

[Company Name] will protect information assets using administrative, technical, and operational controls appropriate to the sensitivity, business value, and risk of the asset.

Users must access, use, store, transmit, and dispose of information only in approved ways and only for authorised business purposes.

Edit before use: decide whether to reference a separate data classification, data handling, encryption, retention, or disposal policy.

Review by: security, IT, data owners, compliance, legal where regulated or contractual data obligations apply.

6. Acceptable use reference

Users must use [Company Name] systems, networks, applications, devices, and data in accordance with approved acceptable use requirements. Unauthorised, unlawful, or unsafe use is not permitted.

Edit before use: link or reference your acceptable use policy if one exists. Keep detailed rules—such as prohibited activities, personal use, monitoring notices, and device expectations—in the supporting policy rather than overloading the main policy.

Review by: HR, legal, security, IT.

7. Access management reference

Access to systems and information must be authorised, appropriate to the user’s role, and reviewed according to [Company Name]’s access management procedures. Access must be changed or removed when job responsibilities change or access is no longer required.

Edit before use: reference your access request, approval, review, privileged access, and offboarding procedures.

Review by: security, IT, HR, system owners.

8. Incident reporting reference

Users must promptly report suspected or confirmed security incidents, policy violations, lost or stolen devices, unauthorised access, or unusual system activity to [Incident Reporting Channel].

Edit before use: specify the actual reporting channel, such as a helpdesk queue, security email address, hotline, ticketing workflow, or incident response process.

Review by: security, IT, legal, communications, leadership where escalation may be required.

9. Third-party and vendor security reference

Third parties that access [Company Name] systems, networks, applications, or data must meet applicable security requirements defined in contracts, agreements, risk assessments, or approved third-party procedures.

Edit before use: decide which vendors are in scope and where third-party requirements are documented.

Review by: procurement, legal, security, vendor management, business owners.

10. Exceptions and waivers

Exceptions to this policy must be requested through [Exception Process]. Each request must identify the policy requirement, reason for the exception, affected systems or data, decision-maker, conditions of approval, and review date.

Edit before use: name the process, approver, tracking location, and review expectations. This is a conservative operating approach—or at least a common conservative approach—not a universal framework rule.

Review by: security, compliance, risk owner, legal where exceptions affect legal or contractual obligations.

11. Enforcement and reporting concerns

Suspected violations or concerns must be reported through [Reporting Channel]. Enforcement will be handled according to [Company Name]’s applicable HR, legal, contractual, and governance processes.

Edit before use: avoid unsupported disciplinary wording. Have HR and legal review any language about employee conduct, investigation, sanctions, or contractual remedies.

Review by: HR, legal, leadership, security.

12. Review and maintenance

The policy owner will review this policy according to [Review Cadence] and when material changes occur, including significant business, technology, security, audit, regulatory, or operational changes. Approved updates must be recorded in the version history.

NIST policy guidance supports defining a review cadence and revisiting policy after relevant events such as audit findings, incidents or breaches, or changes to applicable requirements (NIST SP 800-53 Rev. 5.1, PL-1). Do not treat a fixed cadence as a universal legal requirement unless a specific applicable obligation says so.

Edit before use: choose a realistic cadence and define event-based review triggers.

Review by: policy owner, security, compliance, leadership.

13. Approval and version history

Version	Date	Description of change	Approved by
1.0	`[Date]`	Initial approved version	`[Approver]`

Edit before use: record the first approved version and preserve later changes. Version history helps show which policy was in force at a given time.

Review by: policy owner and approving authority.

How to customise the template before approval

Resolve every placeholder before the policy is approved, the policy should name actual owners, approval paths, reporting channels, and review triggers.

Template field	What to decide	Who should review
`[Company Name]`	Legal entity, group company, or business unit covered by the policy	Leadership, legal
`[Policy Owner]`	The role accountable for maintaining the policy	Security, IT, leadership
`[Approver]`	Person or governance body with authority to approve it	Leadership, legal, compliance
Scope language	Users, contractors, vendors, systems, data, regions, and environments covered	Security, IT, HR, legal, procurement
Roles and responsibilities	Which teams actually own implementation, monitoring, review, and reporting	Security, IT, HR, system owners
`[Incident Reporting Channel]`	Where suspected incidents and violations are reported	Security, IT, legal
`[Exception Process]`	How exceptions are requested, approved, tracked, and reviewed	Security, risk, compliance, legal if needed
Enforcement language	How concerns are reported and which HR/legal processes apply	HR, legal
`[Review Cadence]`	Defined review interval and change-triggered review events	Policy owner, security, compliance

Do not leave ownership, approval, reporting, exceptions, or review wording vague. A policy that says “management will review as needed” or “exceptions require approval” without naming the route or decision-maker is difficult to operate.

Approval and rollout checklist

Use this checklist after the template has been edited.

NIST’s Cybersecurity Framework implementation examples include senior-management approval, organisation-wide communication, periodic review, and acknowledgement of policy receipt as possible ways to operationalise cybersecurity policy (NIST CSF 2.0 Implementation Examples, GV.PO). Treat acknowledgement as optional unless your organisation has approved HR and legal wording for it.

How to handle exceptions, enforcement, and review

Exceptions should not sit in email threads or informal chat approvals. Use a documented process that captures:

the requested exception
the affected system, data, team, or third party
the reason the standard requirement cannot be met
the decision-maker
any conditions attached to approval
the review or expiry date
where the decision is recorded

This approach helps stop exceptions turning into undocumented permanent workarounds. It should be approved by the organisation’s security, risk, compliance, and legal stakeholders where appropriate.

For enforcement, keep the policy clear, but don’t make up disciplinary language as you go. State how concerns are reported and refer to the organisation’s applicable HR, legal, contractual, and governance processes.

For review, combine a defined cadence with event-based triggers. Review the policy when material changes occur, such as major system changes, audit findings, significant incidents, new business models, or changes to applicable requirements. The policy owner should maintain approval records and version history.

Supporting policies this template may reference

A main security policy sets governance and expectations. More detailed requirements often belong in separate supporting policies, standards, or procedures. NIST distinguishes between policies and procedures by noting that procedures describe how policies or controls are implemented (NIST SP 800-53 Rev. 5.1, PL-1 discussion).

Depending on your organisation. The main policy may reference separate documents for:

acceptable use
password and authentication requirements
access management
incident response
disaster recovery or business continuity
data classification and handling
vendor or third-party risk
cloud, infrastructure, or application security

Do not list a supporting policy unless someone owns it, maintains it, and can point users to the current approved version.

Compliance and framework considerations

A security policy can support compliance work, but it does not prove that controls are implemented or that a programme meets a particular framework or law. Map the policy to the requirements that apply to your organisation, then verify that your actual controls, evidence, ownership, and operating practices line up with the policy as written.

For HIPAA covered entities and business associates, HHS explains that the Security Rule requires reasonable and appropriate policies and procedures using its flexibility-of-approach provisions (HHS HIPAA Security Series). HIPAA Security Rule documentation must also be available to people responsible for implementing related procedures and reviewed periodically, with updates as needed for relevant environmental or operational changes (HHS HIPAA Audit Protocol, 45 CFR 164.316). That still does not make this template HIPAA-compliant.

For organisations in PCI DSS scope, Requirement 12 includes an overall information security policy that is established, published, maintained, and disseminated to relevant personnel and relevant vendors or business partners. It also calls for annual review, updates for business-objective or environmental-risk changes, and defined security responsibilities (PCI DSS v4.0 SAQ D for Merchants, Requirement 12). Verify the current PCI DSS version and applicability before relying on the wording here.

Download and maintain your security policy template

Use the preview above as the editable base for your security policy. Before publishing it, customise the placeholders, confirm ownership, approve the final version, communicate it to the right audiences, and schedule review.

If you make the template available as a DOCX, PDF, or internal Google Doc, keep the downloadable version aligned with the approved source version. A stale download creates policy confusion.

For teams moving beyond templates, Ciphrix can help operationalise security and compliance policies as maintained work: connected to owners, controls, evidence, exceptions, and review workflows rather than treated as one-off documents.