# SOC 2 Policy Templates

*A starter pack of 15 core information-security policies for a SOC 2 program. Provided free by soc2-auditors.com. Editable starting templates, not legal advice — replace every [bracketed placeholder] with your real practice.*

There is no AICPA-mandated policy list; this is the near-universal core. Add situational policies (Privacy, Confidentiality, Processing Integrity, Availability, SDLC, Physical/Datacenter, Remote Access) based on your scope.

---

## 1. Information Security Policy

**Owner:** [role] · **Version:** 1.0 · **Effective:** [date] · **Next review:** [date + 1 year]  
**Maps to Trust Services Criteria:** CC1.1, CC1.2, CC2.2, CC5.3

### Purpose

Establish [Company]'s overall commitment to protecting the confidentiality, integrity, and availability of information, and to serve as the umbrella under which all other security policies sit.

### Scope

All employees, contractors, and third parties who access [Company] information or systems, and all information assets the company owns or processes.

### Policy statements

1. Management is committed to protecting information assets and provides the resources needed to operate the security program.
2. The security program is owned by [the CISO / Head of Security], who is accountable for its design, operation, and this policy.
3. Security objectives are aligned to business objectives and to the SOC 2 Trust Services Criteria the company has elected.
4. All personnel must comply with this policy and the supporting policies it references; violations are handled under the Enforcement section.
5. This policy and its supporting policies are reviewed at least annually and after any material change to the business or its systems.

### Roles and responsibilities

- Executive management — approves this policy and funds the program.
- CISO / Head of Security — owns and maintains the security program.
- All personnel — comply with security policies and complete required training.

### Enforcement

Violations of the Information Security Policy may result in disciplinary action up to and including termination, and, where applicable, legal action. Suspected violations should be reported to [Security].

### Exceptions

Any exception to the Information Security Policy must be requested in writing, risk-assessed, and approved by [the CISO / Head of Security]. Approved exceptions are documented and reviewed at least annually.

### Review and maintenance

This policy is reviewed and approved at least annually, and after any material change to the business or its systems, by [the CISO / Head of Security].

### Revision history

| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0 | [date] | [name] | Initial version |

### Acknowledgment

I acknowledge that I have read and agree to comply with this policy. Name: ______  Signature: ______  Date: ______

---

## 2. Access Control Policy

**Owner:** [role] · **Version:** 1.0 · **Effective:** [date] · **Next review:** [date + 1 year]  
**Maps to Trust Services Criteria:** CC6.1, CC6.2, CC6.3

### Purpose

Ensure access to [Company] systems and data is granted on a least-privilege basis, reviewed regularly, and removed promptly when no longer required.

### Scope

All information systems, applications, and infrastructure, and all users (employees, contractors, service accounts) that access them.

### Policy statements

1. Access is granted on the principle of least privilege and, where practical, through predefined roles rather than individual grants.
2. Every user is assigned a unique account; shared or generic accounts are prohibited except where technically unavoidable and formally approved.
3. New access requires the approval of the relevant resource or data owner, recorded through the access-request process, before it is provisioned.
4. Access is reviewed at least quarterly by system owners, and any access no longer required is revoked.
5. Access is removed within [five] business days of an employee or contractor leaving or changing roles, tracked through the offboarding process.
6. Privileged and administrative access is restricted to named individuals, justified, and logged.

### Roles and responsibilities

- Resource/data owners — approve and review access to their systems.
- IT / Security — provision, deprovision, and audit access.
- Managers — initiate onboarding and offboarding requests promptly.

### Enforcement

Violations of the Access Control Policy may result in disciplinary action up to and including termination, and, where applicable, legal action. Suspected violations should be reported to [Security].

### Exceptions

Any exception to the Access Control Policy must be requested in writing, risk-assessed, and approved by [the CISO / Head of Security]. Approved exceptions are documented and reviewed at least annually.

### Review and maintenance

This policy is reviewed and approved at least annually, and after any material change to the business or its systems, by [the CISO / Head of Security].

### Revision history

| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0 | [date] | [name] | Initial version |

### Acknowledgment

I acknowledge that I have read and agree to comply with this policy. Name: ______  Signature: ______  Date: ______

---

## 3. Password and Authentication Policy

**Owner:** [role] · **Version:** 1.0 · **Effective:** [date] · **Next review:** [date + 1 year]  
**Maps to Trust Services Criteria:** CC6.1

### Purpose

Define minimum standards for authentication credentials so that access to [Company] systems is protected against unauthorized use.

### Scope

All accounts used to access [Company] systems, including employee, contractor, and service accounts.

### Policy statements

1. Passwords must meet minimum length and complexity requirements of at least [12] characters and be unique to [Company] systems.
2. Multi-factor authentication (MFA) is required for all remote access, administrative access, email, and the identity provider.
3. Passwords must not be shared, written down in plaintext, or reused across systems; a company-approved password manager is provided.
4. Where [Company] controls credential storage, passwords are stored using a strong, salted one-way hash and never in plaintext.
5. Default vendor credentials must be changed before a system is placed into production.
6. Accounts are locked after [ten] consecutive failed authentication attempts.

### Roles and responsibilities

- IT / Security — configure and enforce authentication controls.
- All personnel — protect their credentials and use MFA and the password manager.

### Enforcement

Violations of the Password and Authentication Policy may result in disciplinary action up to and including termination, and, where applicable, legal action. Suspected violations should be reported to [Security].

### Exceptions

Any exception to the Password and Authentication Policy must be requested in writing, risk-assessed, and approved by [the CISO / Head of Security]. Approved exceptions are documented and reviewed at least annually.

### Review and maintenance

This policy is reviewed and approved at least annually, and after any material change to the business or its systems, by [the CISO / Head of Security].

### Revision history

| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0 | [date] | [name] | Initial version |

### Acknowledgment

I acknowledge that I have read and agree to comply with this policy. Name: ______  Signature: ______  Date: ______

---

## 4. Change Management Policy

**Owner:** [role] · **Version:** 1.0 · **Effective:** [date] · **Next review:** [date + 1 year]  
**Maps to Trust Services Criteria:** CC8.1

### Purpose

Ensure changes to [Company] production systems are requested, reviewed, tested, approved, and documented before deployment.

### Scope

All changes to production systems, applications, infrastructure, and configurations.

### Policy statements

1. Changes to production must be recorded as a change request that captures the change, its purpose, and its risk.
2. Changes are peer-reviewed and require approval from an authorized reviewer before being merged or deployed.
3. Development, test, and production environments are separated, and changes are tested before reaching production.
4. Each change includes a rollback or remediation plan in case of failure.
5. Emergency changes may bypass the standard sequence but must be documented and reviewed retrospectively within [two] business days.
6. A record of changes is retained to support audit and troubleshooting.

### Roles and responsibilities

- Engineers — raise, test, and document changes.
- Reviewers/approvers — review and authorize changes before deployment.
- Engineering leadership — own the change process.

### Enforcement

Violations of the Change Management Policy may result in disciplinary action up to and including termination, and, where applicable, legal action. Suspected violations should be reported to [Security].

### Exceptions

Any exception to the Change Management Policy must be requested in writing, risk-assessed, and approved by [the CISO / Head of Security]. Approved exceptions are documented and reviewed at least annually.

### Review and maintenance

This policy is reviewed and approved at least annually, and after any material change to the business or its systems, by [the CISO / Head of Security].

### Revision history

| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0 | [date] | [name] | Initial version |

### Acknowledgment

I acknowledge that I have read and agree to comply with this policy. Name: ______  Signature: ______  Date: ______

---

## 5. Risk Assessment and Management Policy

**Owner:** [role] · **Version:** 1.0 · **Effective:** [date] · **Next review:** [date + 1 year]  
**Maps to Trust Services Criteria:** CC3.1, CC3.2, CC9.1

### Purpose

Establish how [Company] identifies, analyzes, treats, and monitors risks to its information and systems.

### Scope

All information assets, systems, processes, and third parties that could affect [Company]'s security objectives.

### Policy statements

1. A formal risk assessment is performed at least annually and when significant changes to the business or its systems occur.
2. Risks are documented in a risk register and scored by likelihood and impact using a consistent methodology.
3. Each risk is assigned an owner and a treatment decision: mitigate, transfer, accept, or avoid.
4. Mitigation plans are tracked to completion and reviewed by management.
5. The risk assessment considers fraud, vendor, and business-disruption risks in addition to technical threats.

### Roles and responsibilities

- Risk owner / Security — facilitates the assessment and maintains the register.
- Management — reviews results and approves treatment decisions.
- Risk owners — execute mitigation for their risks.

### Enforcement

Violations of the Risk Assessment and Management Policy may result in disciplinary action up to and including termination, and, where applicable, legal action. Suspected violations should be reported to [Security].

### Exceptions

Any exception to the Risk Assessment and Management Policy must be requested in writing, risk-assessed, and approved by [the CISO / Head of Security]. Approved exceptions are documented and reviewed at least annually.

### Review and maintenance

This policy is reviewed and approved at least annually, and after any material change to the business or its systems, by [the CISO / Head of Security].

### Revision history

| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0 | [date] | [name] | Initial version |

### Acknowledgment

I acknowledge that I have read and agree to comply with this policy. Name: ______  Signature: ______  Date: ______

---

## 6. Incident Response Policy

**Owner:** [role] · **Version:** 1.0 · **Effective:** [date] · **Next review:** [date + 1 year]  
**Maps to Trust Services Criteria:** CC7.3, CC7.4, CC7.5

### Purpose

Define how [Company] detects, reports, responds to, contains, and learns from security incidents.

### Scope

All suspected or confirmed security events affecting [Company] systems, data, or personnel.

### Policy statements

1. Personnel must report suspected security incidents immediately, and no later than [24] hours after discovery, through the defined channel.
2. Incidents are triaged and assigned a severity that determines response time and escalation.
3. The incident response team follows defined steps to contain, eradicate, and recover from incidents, preserving evidence throughout.
4. Affected customers, regulators, and other parties are notified in line with contractual and legal breach-notification requirements.
5. A post-incident review is conducted after significant incidents to capture root cause and corrective actions.
6. The incident response plan is tested at least annually through a tabletop exercise or a real incident retrospective.

### Roles and responsibilities

- Incident lead / Security Manager — coordinates response.
- All personnel — report incidents promptly.
- Management/Legal — handle external notification decisions.

### Enforcement

Violations of the Incident Response Policy may result in disciplinary action up to and including termination, and, where applicable, legal action. Suspected violations should be reported to [Security].

### Exceptions

Any exception to the Incident Response Policy must be requested in writing, risk-assessed, and approved by [the CISO / Head of Security]. Approved exceptions are documented and reviewed at least annually.

### Review and maintenance

This policy is reviewed and approved at least annually, and after any material change to the business or its systems, by [the CISO / Head of Security].

### Revision history

| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0 | [date] | [name] | Initial version |

### Acknowledgment

I acknowledge that I have read and agree to comply with this policy. Name: ______  Signature: ______  Date: ______

---

## 7. Vendor and Third-Party Management Policy

**Owner:** [role] · **Version:** 1.0 · **Effective:** [date] · **Next review:** [date + 1 year]  
**Maps to Trust Services Criteria:** CC9.2

### Purpose

Manage the security risk introduced by vendors and subservice organizations that access or process [Company] data.

### Scope

All third-party vendors, subprocessors, and service providers with access to [Company] systems or data.

### Policy statements

1. A vendor inventory is maintained that records each vendor, the data it accesses, and its risk tier.
2. Before onboarding, critical vendors undergo security due diligence, such as review of their SOC 2 report or a security questionnaire.
3. Contracts with vendors that handle sensitive data include appropriate security and data-processing terms.
4. Critical vendors are re-reviewed at least annually or when their risk profile changes.
5. Vendor access is removed promptly when a relationship ends.

### Roles and responsibilities

- Vendor owner — sponsors and monitors each vendor relationship.
- Security — performs due diligence and maintains the inventory.
- Legal/Procurement — ensures contractual terms are in place.

### Enforcement

Violations of the Vendor and Third-Party Management Policy may result in disciplinary action up to and including termination, and, where applicable, legal action. Suspected violations should be reported to [Security].

### Exceptions

Any exception to the Vendor and Third-Party Management Policy must be requested in writing, risk-assessed, and approved by [the CISO / Head of Security]. Approved exceptions are documented and reviewed at least annually.

### Review and maintenance

This policy is reviewed and approved at least annually, and after any material change to the business or its systems, by [the CISO / Head of Security].

### Revision history

| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0 | [date] | [name] | Initial version |

### Acknowledgment

I acknowledge that I have read and agree to comply with this policy. Name: ______  Signature: ______  Date: ______

---

## 8. Business Continuity and Disaster Recovery Policy

**Owner:** [role] · **Version:** 1.0 · **Effective:** [date] · **Next review:** [date + 1 year]  
**Maps to Trust Services Criteria:** CC7.5, A1.2, A1.3

### Purpose

Ensure [Company] can maintain critical operations during a disruption and recover systems and data after a disaster.

### Scope

Critical business processes, systems, and the data required to operate them.

### Policy statements

1. Critical business functions are identified along with their recovery time objectives (RTO) and recovery point objectives (RPO).
2. Data is backed up on a defined schedule, encrypted, and stored so that a single failure cannot destroy both primary and backup copies.
3. Backup restoration and disaster-recovery procedures are tested at least annually, and results are documented.
4. A communication plan defines how personnel and customers are informed during a disruption.
5. Roles and responsibilities for continuity and recovery are assigned and kept current.

### Roles and responsibilities

- Continuity owner — maintains and tests the plan.
- IT/Engineering — operate backups and recovery.
- Management — declare disruptions and authorize recovery.

### Enforcement

Violations of the Business Continuity and Disaster Recovery Policy may result in disciplinary action up to and including termination, and, where applicable, legal action. Suspected violations should be reported to [Security].

### Exceptions

Any exception to the Business Continuity and Disaster Recovery Policy must be requested in writing, risk-assessed, and approved by [the CISO / Head of Security]. Approved exceptions are documented and reviewed at least annually.

### Review and maintenance

This policy is reviewed and approved at least annually, and after any material change to the business or its systems, by [the CISO / Head of Security].

### Revision history

| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0 | [date] | [name] | Initial version |

### Acknowledgment

I acknowledge that I have read and agree to comply with this policy. Name: ______  Signature: ______  Date: ______

---

## 9. Data Classification Policy

**Owner:** [role] · **Version:** 1.0 · **Effective:** [date] · **Next review:** [date + 1 year]  
**Maps to Trust Services Criteria:** CC3.2, CC6.1

### Purpose

Define how [Company] classifies data by sensitivity so that protection is applied in proportion to risk.

### Scope

All data created, received, stored, or processed by [Company].

### Policy statements

1. Data is classified into defined tiers, for example Public, Internal, Confidential, and Restricted.
2. Handling, storage, transmission, and disposal requirements are defined for each classification tier.
3. Data owners are responsible for classifying their data and ensuring it is handled accordingly.
4. Confidential and Restricted data must be encrypted in transit and at rest.
5. Classification is considered when granting access, so that more sensitive data receives tighter controls.

### Roles and responsibilities

- Data owners — classify and steward their data.
- All personnel — handle data per its classification.
- Security — defines the scheme and handling rules.

### Enforcement

Violations of the Data Classification Policy may result in disciplinary action up to and including termination, and, where applicable, legal action. Suspected violations should be reported to [Security].

### Exceptions

Any exception to the Data Classification Policy must be requested in writing, risk-assessed, and approved by [the CISO / Head of Security]. Approved exceptions are documented and reviewed at least annually.

### Review and maintenance

This policy is reviewed and approved at least annually, and after any material change to the business or its systems, by [the CISO / Head of Security].

### Revision history

| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0 | [date] | [name] | Initial version |

### Acknowledgment

I acknowledge that I have read and agree to comply with this policy. Name: ______  Signature: ______  Date: ______

---

## 10. Data Retention and Disposal Policy

**Owner:** [role] · **Version:** 1.0 · **Effective:** [date] · **Next review:** [date + 1 year]  
**Maps to Trust Services Criteria:** CC6.5

### Purpose

Define how long [Company] retains data and how it is securely disposed of when no longer required.

### Scope

All data and the media and systems on which it is stored.

### Policy statements

1. Retention periods are defined by data type based on business need and legal or regulatory requirements.
2. Data that has reached the end of its retention period is securely disposed of unless subject to a legal hold.
3. Disposal uses methods appropriate to the media, such as cryptographic erasure, secure deletion, or physical destruction.
4. Logical and physical protections over data are discontinued only through this controlled disposal process.
5. Evidence of secure disposal is retained where practical.

### Roles and responsibilities

- Data owners — apply retention schedules.
- IT/Security — perform and evidence secure disposal.
- Legal — manage retention requirements and legal holds.

### Enforcement

Violations of the Data Retention and Disposal Policy may result in disciplinary action up to and including termination, and, where applicable, legal action. Suspected violations should be reported to [Security].

### Exceptions

Any exception to the Data Retention and Disposal Policy must be requested in writing, risk-assessed, and approved by [the CISO / Head of Security]. Approved exceptions are documented and reviewed at least annually.

### Review and maintenance

This policy is reviewed and approved at least annually, and after any material change to the business or its systems, by [the CISO / Head of Security].

### Revision history

| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0 | [date] | [name] | Initial version |

### Acknowledgment

I acknowledge that I have read and agree to comply with this policy. Name: ______  Signature: ______  Date: ______

---

## 11. Encryption and Cryptography Policy

**Owner:** [role] · **Version:** 1.0 · **Effective:** [date] · **Next review:** [date + 1 year]  
**Maps to Trust Services Criteria:** CC6.1, CC6.7

### Purpose

Define where and how [Company] uses encryption to protect data in transit and at rest.

### Scope

All systems that store or transmit Confidential or Restricted data, and the cryptographic keys that protect it.

### Policy statements

1. Data in transit over public or untrusted networks is encrypted using current TLS versions and strong cipher suites.
2. Confidential and Restricted data at rest is encrypted using industry-standard algorithms and key lengths.
3. Deprecated or weak algorithms and protocols must not be used.
4. Cryptographic keys are stored securely, access to them is restricted, and they are rotated on a defined schedule.
5. Exceptions to encryption requirements must be formally approved and risk-assessed.

### Roles and responsibilities

- Engineering/Security — implement and maintain encryption and key management.
- Security — approves algorithms and reviews exceptions.

### Enforcement

Violations of the Encryption and Cryptography Policy may result in disciplinary action up to and including termination, and, where applicable, legal action. Suspected violations should be reported to [Security].

### Exceptions

Any exception to the Encryption and Cryptography Policy must be requested in writing, risk-assessed, and approved by [the CISO / Head of Security]. Approved exceptions are documented and reviewed at least annually.

### Review and maintenance

This policy is reviewed and approved at least annually, and after any material change to the business or its systems, by [the CISO / Head of Security].

### Revision history

| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0 | [date] | [name] | Initial version |

### Acknowledgment

I acknowledge that I have read and agree to comply with this policy. Name: ______  Signature: ______  Date: ______

---

## 12. Logging and Monitoring Policy

**Owner:** [role] · **Version:** 1.0 · **Effective:** [date] · **Next review:** [date + 1 year]  
**Maps to Trust Services Criteria:** CC7.1, CC7.2

### Purpose

Define what [Company] logs, how logs are protected and retained, and how they are monitored to detect issues.

### Scope

Production systems, security-relevant applications, and the infrastructure that supports them.

### Policy statements

1. Security-relevant events, including authentication, access changes, and administrative actions, are logged.
2. Logs are centralized, protected against tampering, and retained for at least [one year] or as required by contract.
3. System clocks are synchronized to a common time source so that events can be correlated.
4. Alerts are configured for defined security conditions and are reviewed and actioned by [Security].
5. Monitoring coverage is reviewed periodically to confirm it still reflects the environment.

### Roles and responsibilities

- Security/Engineering — configure logging, alerting, and retention.
- Security — review alerts and investigate anomalies.

### Enforcement

Violations of the Logging and Monitoring Policy may result in disciplinary action up to and including termination, and, where applicable, legal action. Suspected violations should be reported to [Security].

### Exceptions

Any exception to the Logging and Monitoring Policy must be requested in writing, risk-assessed, and approved by [the CISO / Head of Security]. Approved exceptions are documented and reviewed at least annually.

### Review and maintenance

This policy is reviewed and approved at least annually, and after any material change to the business or its systems, by [the CISO / Head of Security].

### Revision history

| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0 | [date] | [name] | Initial version |

### Acknowledgment

I acknowledge that I have read and agree to comply with this policy. Name: ______  Signature: ______  Date: ______

---

## 13. Acceptable Use Policy

**Owner:** [role] · **Version:** 1.0 · **Effective:** [date] · **Next review:** [date + 1 year]  
**Maps to Trust Services Criteria:** CC1.1, CC6.7

### Purpose

Define the acceptable use of [Company] systems, networks, devices, and data by personnel.

### Scope

All employees, contractors, and others who use [Company] systems or devices.

### Policy statements

1. Company systems and data are used for legitimate business purposes and in compliance with law and company policy.
2. Users must protect their devices and credentials, lock unattended screens, and not disable security controls.
3. Only sanctioned services and approved removable media may be used to store or transfer company data.
4. Personnel are notified that use of company systems may be monitored to the extent permitted by law.
5. Personal use, if permitted, must not interfere with work or introduce undue risk.

### Roles and responsibilities

- All personnel — use systems responsibly and comply with this policy.
- Security — defines acceptable use and monitors for violations.

### Enforcement

Violations of the Acceptable Use Policy may result in disciplinary action up to and including termination, and, where applicable, legal action. Suspected violations should be reported to [Security].

### Exceptions

Any exception to the Acceptable Use Policy must be requested in writing, risk-assessed, and approved by [the CISO / Head of Security]. Approved exceptions are documented and reviewed at least annually.

### Review and maintenance

This policy is reviewed and approved at least annually, and after any material change to the business or its systems, by [the CISO / Head of Security].

### Revision history

| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0 | [date] | [name] | Initial version |

### Acknowledgment

I acknowledge that I have read and agree to comply with this policy. Name: ______  Signature: ______  Date: ______

---

## 14. Vulnerability Management Policy

**Owner:** [role] · **Version:** 1.0 · **Effective:** [date] · **Next review:** [date + 1 year]  
**Maps to Trust Services Criteria:** CC4.1, CC7.1

### Purpose

Ensure vulnerabilities in [Company] systems are identified, prioritized, and remediated in a timely manner.

### Scope

Production systems, applications, endpoints, and supporting infrastructure.

### Policy statements

1. Vulnerability scanning is performed on a defined schedule against production systems and endpoints.
2. Identified vulnerabilities are prioritized by severity and remediated within defined SLAs, for example critical within [30] days.
3. A penetration test is performed at least annually, and findings are tracked to remediation.
4. Operating systems and software are patched on a defined cadence.
5. Remediation is tracked to closure and reported to management.

### Roles and responsibilities

- Security — runs scanning and coordinates the pen test.
- Engineering/IT — remediate and patch within SLA.
- Management — reviews remediation status.

### Enforcement

Violations of the Vulnerability Management Policy may result in disciplinary action up to and including termination, and, where applicable, legal action. Suspected violations should be reported to [Security].

### Exceptions

Any exception to the Vulnerability Management Policy must be requested in writing, risk-assessed, and approved by [the CISO / Head of Security]. Approved exceptions are documented and reviewed at least annually.

### Review and maintenance

This policy is reviewed and approved at least annually, and after any material change to the business or its systems, by [the CISO / Head of Security].

### Revision history

| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0 | [date] | [name] | Initial version |

### Acknowledgment

I acknowledge that I have read and agree to comply with this policy. Name: ______  Signature: ______  Date: ______

---

## 15. Human Resources Security Policy

**Owner:** [role] · **Version:** 1.0 · **Effective:** [date] · **Next review:** [date + 1 year]  
**Maps to Trust Services Criteria:** CC1.4

### Purpose

Embed security across the employment lifecycle, from hiring through termination.

### Scope

All employees and contractors of [Company].

### Policy statements

1. Background checks are performed on new hires where legally permitted and appropriate to the role.
2. Personnel sign confidentiality or non-disclosure agreements before accessing sensitive data.
3. Security awareness training is completed by new hires and refreshed at least annually and when policies change.
4. A disciplinary process addresses violations of security policy.
5. Onboarding and offboarding follow the Access Control Policy so that access is granted and removed appropriately.

### Roles and responsibilities

- People/HR — run checks, agreements, training, and offboarding.
- Security — defines training and requirements.
- Managers — ensure their reports complete training.

### Enforcement

Violations of the Human Resources Security Policy may result in disciplinary action up to and including termination, and, where applicable, legal action. Suspected violations should be reported to [Security].

### Exceptions

Any exception to the Human Resources Security Policy must be requested in writing, risk-assessed, and approved by [the CISO / Head of Security]. Approved exceptions are documented and reviewed at least annually.

### Review and maintenance

This policy is reviewed and approved at least annually, and after any material change to the business or its systems, by [the CISO / Head of Security].

### Revision history

| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0 | [date] | [name] | Initial version |

### Acknowledgment

I acknowledge that I have read and agree to comply with this policy. Name: ______  Signature: ______  Date: ______
