Is this enough to pass an audit?

No; auditors test evidence that you follow the policy, and you should have it reviewed by a qualified advisor

Should it describe tools or principles?

Principles and requirements here; tool specifics belong in procedures that can change without re-approval

How often must it be reviewed?

At least once a year and after any major change, with the review recorded in the version history

Security policy starter template

An information security policy skeleton in the SOC 2 and ISO 27001 style, with roles, policy statements, exceptions, review cadence and sign-off

Start with this template →Sign in

Opens on reph with the template ready to start. No account needed; sign in to keep your document.

Use it when

You are preparing for a SOC 2 or ISO 27001 audit, or a customer security questionnaire asks for your written information security policy

Who it's for

OperationsEngineering managerExecutiveFounder

Filled example

The template filled in for a made-up company, so you can see what good looks like.

Carewell Health information security policy

Author: Nadia Okoro · Date: 2026-09-01 · Policy owner: Nadia Okoro, Head of Security · Version: 1.0

This is a starting point, not legal or audit advice. Carewell adapted it to its own practice and had it reviewed by external counsel before the SOC 2 Type I audit.

1. Purpose

Carewell Health builds scheduling software used by 140 outpatient clinics. This policy protects the confidentiality, integrity and availability of Carewell's information and the patient scheduling data our customers entrust to us.

2. Scope

People: all 46 employees and any contractor with access to Carewell systems
Systems: the production platform on AWS, corporate SaaS tools, and company laptops
Data: all customer, patient scheduling, employee and company data
Out of scope: the marketing website, which holds no customer data and is hosted by a vendor

3. Roles and responsibilities

Role	Held by	Responsibilities
Executive sponsor	Tom Ashby, CEO	Approves this policy, funds the security program
Security owner	Nadia Okoro	Maintains the policy, runs quarterly risk reviews, coordinates audits
System owners	Engineering leads	Apply controls and review access to their services
People / HR	Rosa Ventura	Onboarding, offboarding and training records
All personnel	Everyone	Follow this policy, report incidents

4. Policy statements

4.1 Access control

Access follows least privilege and is approved by the system owner in the access request tracker.
Every person has a unique Okta account; shared accounts are prohibited.
Multi-factor authentication is required for Okta, AWS and GitHub.
Access is removed within one business day of departure.
Production access is reviewed quarterly.

4.2 Data classification

Level	Examples	Handling requirements
Public	Blog posts, pricing	None
Internal	Roadmaps, wiki	Approved systems only
Confidential	Customer contracts, employee records	Need-to-know access, encrypted at rest
Restricted	Patient scheduling data	Production only, never exported to laptops

4.3 Encryption

Confidential and Restricted data is encrypted at rest with AES-256 via AWS KMS.
All external traffic uses TLS 1.2 or higher.
KMS keys are managed by the platform team and rotated annually.

4.4 Vendor management

Vendors processing Confidential data are assessed before signature; 18 vendors are currently in the inventory.
The inventory is reviewed every six months.

4.5 Incident response

Suspected incidents are reported in #security-incidents or to security@carewell.example.
Nadia leads the response using the incident runbook; customers are notified within 72 hours of a confirmed breach.

4.6 Acceptable use

Laptops are managed by Kandji with FileVault, screen lock and auto-updates enforced.
Lost devices are reported within 24 hours.

5. Exceptions

ID	Policy statement	Reason	Compensating control	Approved by	Expires
EX-1	4.1 unique accounts	Legacy SMS vendor allows one login	Password in vault, access logged	Nadia Okoro	2026-12-31

6. Enforcement

Violations are handled under the employee handbook's conduct process and may lead to loss of access or disciplinary action.

7. Review cadence

Next scheduled review: September 2027
Triggers for an early review: a new hosting region, an acquisition, or a significant incident

8. Version history

Version	Date	Author	Summary of changes
0.1	2026-08-04	Nadia Okoro	Initial draft
1.0	2026-09-01	Nadia Okoro	Counsel feedback, approved

Review

Review by: 2026-08-29

Reviewer	Role	Status
Nadia Okoro	Security owner	Approved
Tom Ashby	Executive sponsor	Approved
Hartwell LLP	External counsel	Approved with comments

Decision record

Decision	Date	Decided by	Notes
Approve version 1.0	2026-09-01	Tom Ashby	Effective immediately; staff acknowledgment due Sept 15

The template

Show the blank template

Security policy starter

Author: [your name] · Date: [date] · Policy owner: [name] · Version: 0.1 (draft)

This is a starting point, not legal or audit advice. Adapt every statement to what your organization actually does, and have it reviewed by a qualified advisor before relying on it for an audit or a contract.

1. Purpose

Why this policy exists: protect the confidentiality, integrity and availability of information belonging to [workspace], its customers and partners. Two or three sentences.

2. Scope

Who and what it covers: employees, contractors, systems, data, locations. Name anything explicitly excluded.

People:
Systems:
Data:
Out of scope:

3. Roles and responsibilities

Every control needs an owner. Small companies often combine roles; write that down rather than leaving a role empty.

Role	Held by	Responsibilities
Executive sponsor		Approves this policy, funds the security program
Security owner		Maintains the policy, runs risk reviews, coordinates audits
System owners		Apply controls to the systems they own, review access
People / HR		Onboarding and offboarding, training records
All personnel		Follow this policy, report incidents and suspected weaknesses

4. Policy statements

Each statement says what must be true, not how a tool does it. Procedures and runbooks hold the how.

4.1 Access control

Least privilege, unique accounts, MFA, joiner/mover/leaver timing, periodic access reviews.

Access is granted on least privilege and approved by the system owner.
Every person uses a unique account; shared accounts are prohibited unless documented as an exception.
Multi-factor authentication is required for
Access is removed within of a role change or departure.
Access to production and sensitive systems is reviewed every

4.2 Data classification

The levels you use and how each must be handled. Three or four levels is plenty.

Level	Examples	Handling requirements
Public
Internal
Confidential
Restricted

4.3 Encryption

At rest, in transit, and who manages keys.

Data classified Confidential or above is encrypted at rest using
Data in transit over public networks uses TLS 1.2 or higher.
Encryption keys are managed by and rotated

4.4 Vendor management

How third parties that touch your data are assessed before and during the relationship.

Vendors that store or process Confidential data are assessed before contract signature.
Assessments consider security reports (for example SOC 2 or ISO 27001 certificates), data location and subprocessors.
The vendor inventory is reviewed every

4.5 Incident response

How incidents are reported, who leads, and notification duties. Link the runbook.

Anyone who suspects a security incident reports it immediately to
The security owner leads the response following the incident response runbook:
Affected customers and regulators are notified within the timeframes required by contract and law.
Every significant incident gets a post-incident review with tracked actions.

4.6 Acceptable use

What people may and may not do with company systems and data.

Company devices have disk encryption, screen lock and automatic updates enabled.
Company data is stored only in approved systems.
Personnel must not share credentials, disable security controls, or install unapproved software on systems handling Restricted data.
Lost or stolen devices are reported within

5. Exceptions

A policy with no exception process gets ignored instead. Exceptions are time-boxed and recorded.

Requests go to the security owner with the business reason, the risk, any compensating control and an end date. Approved exceptions are logged below and reviewed at every policy review.

ID	Policy statement	Reason	Compensating control	Approved by	Expires

6. Enforcement

What happens on a violation. Keep it proportionate and consistent with your HR policies.

7. Review cadence

At least annually and after significant changes to systems, organization or regulation.

Next scheduled review:
Triggers for an early review:

8. Version history

Version	Date	Author	Summary of changes
0.1	[date]	[your name]	Initial draft

Review

Approval makes this policy effective. Record it here so an auditor can see who approved which version and when.

Review by: [date]

Reviewer	Role	Status
	Security owner	Pending
	Executive sponsor	Pending
	Legal or compliance advisor	Pending

Decision record

Decision	Date	Decided by	Notes

Questions

Is this enough to pass an audit?: No; auditors test evidence that you follow the policy, and you should have it reviewed by a qualified advisor
Should it describe tools or principles?: Principles and requirements here; tool specifics belong in procedures that can change without re-approval
How often must it be reviewed?: At least once a year and after any major change, with the review recorded in the version history

Fill it with your agent

Connect Claude to reph over MCP, then paste this. The draft arrives as suggestions you accept or reject section by section. How to connect Claude.

Find my reph doc "Security policy starter" with search_docs, then read it with read_doc. Draft each statement from our actual practice: identity provider settings, cloud and encryption config, vendor list, incident runbook and onboarding checklist. Mark gaps rather than inventing controls, and never paste secrets or keys. File it with suggest_edit, one replace_section op per section (heading line kept) so each can be accepted alone. Ask each open question (gaps, every owner you had to guess) with add_comment quoting that section's heading line, then call request_review with a one-line summary.

Start with this template →Sign in

Security policy starter template

Use it when

Who it's for

Filled example

Carewell Health information security policy

1. Purpose

2. Scope

3. Roles and responsibilities

4. Policy statements

4.1 Access control

4.2 Data classification

4.3 Encryption

4.4 Vendor management

4.5 Incident response

4.6 Acceptable use

5. Exceptions

6. Enforcement

7. Review cadence

8. Version history

Review

The template

Security policy starter

1. Purpose

2. Scope

3. Roles and responsibilities

4. Policy statements

4.1 Access control

4.2 Data classification

4.3 Encryption

4.4 Vendor management

4.5 Incident response

4.6 Acceptable use

5. Exceptions

6. Enforcement

7. Review cadence

8. Version history

Review

Questions

Fill it with your agent

Related templates

All-hands agenda

Offsite agenda

Project kickoff

RACI matrix

Retrospective

Risk register