Picture this: your SOC 2 auditor asks when you last reviewed your offboarding checklist. You check with HR. HR checks with IT. Nobody’s sure whose job it actually is. That’s exactly the gap an HR security policy is designed to close.
An HR security policy is a formal document that defines the security responsibilities tied to every stage of the employment lifecycle: from background checks before someone joins, to access revocation the day they leave. It governs who can access what, what training employees must complete, how contractors are managed, and what happens when things go wrong. Ownership sits jointly with HR and your security lead, because the process spans both functions.
Frameworks that require it or expect it:
- SOC 2 (CC1.4, CC6.2): access management tied to employment lifecycle
- ISO 27001 (Annex A.6, A.7): pre-employment screening, terms of employment, disciplinary process, termination
- HIPAA (§164.308(a)(3)): workforce security, clearance procedures, termination
- GDPR (Articles 32, 88): security measures for employee data processing, breach notification obligations
By the end of this, you’ll know exactly what an HR security policy needs to cover, have a free template you can use immediately, and understand what auditors actually look for when they review it.
Here’s what I’ll cover:
- What an HR security policy is and how it differs from a general HR policy
- What it needs to include, with a free inline template
- How to map it to SOC 2, ISO 27001, HIPAA, and GDPR
- What auditors want to see as evidence
- Common mistakes that create real compliance gaps
- How to right-size it for your company’s stage
What Is an HR Security Policy?
An HR security policy is a formal document that specifies the information security requirements tied to every phase of the employment relationship. It’s not your leave policy. It’s not your code of conduct. It’s specifically about how people interact with your systems and data: who gets access, when, and under what conditions.
The confusion comes from the name. “HR policy” sounds like it lives entirely in the HR team. But an HR security policy is owned jointly by HR and your security function, because it spans both.
HR manages the lifecycle events (someone starts, changes roles, leaves). Security manages the access controls that must respond to each of those events. When those two functions aren’t aligned on a shared document, access lingers, training falls through the cracks, and your next audit will find it.
You’ll also hear it called a human resources security policy or a personnel security policy. Same thing, different labels depending on the framework you’re working to.
What Does an HR Security Policy Cover?
The scope is the full employment lifecycle:
- Pre-employment: background check requirements, reference verification, role-specific screening
- Onboarding: security training timelines, NDA and acceptable use sign-off, access provisioning process
- During employment: annual training obligations, policy acknowledgement, incident reporting, access review cadence
- Offboarding: access revocation timelines, asset return, data handling for departing employees
- Contractors and third parties: NDA requirements, access restrictions, offboarding scope
HR Security Policy vs. General HR Policy
A general HR policy covers employment law, compensation, leave, and workplace conduct. It’s written and owned by HR, often with legal input.
An HR security policy covers information security obligations, data handling, and access controls. It’s written jointly by HR and Security (or your CISO), and updated independently of your HR policies.
Keep them separate. When they’re combined, the security requirements tend to get buried, the wrong people own them, and they don’t get reviewed at the right cadence.
Why Human Resources Is Your Biggest Security Risk
Here’s a scenario I’ve seen play out more than once: an engineer hands in their notice, finishes out their two weeks, and their accounts are still active a month later. Not because anyone was careless, but because nobody had defined whose job it was to revoke access or when exactly it needed to happen.
The Verizon Data Breach Investigations Report has shown for years running that the human element is involved in the majority of security incidents. And the HR function sits at the centre of that: it’s where people enter your organisation, gain access to your systems, change roles, and eventually leave. Every one of those transitions is a potential access control failure.
Three scenarios that come up repeatedly:
- A departing employee whose access isn’t revoked for two weeks. They don’t do anything malicious. But the access was there. An auditor will ask why.
- A contractor who signs no NDA and retains access to a staging environment long after the engagement ends. The contractor moves on; the credentials don’t.
- An employee who clicks a phishing link because nobody ever ran a proper security training session.
All three are HR process failures, not just security failures.
The reason ad hoc processes don’t scale is simple: what works at five people breaks completely at fifty. By then you’ve got multiple systems, multiple teams, contractors in and out, and no shared rulebook. A written HR security policy defines expectations before the situation arises, so you’re not inventing the process in the middle of an offboarding or an audit.
Which Companies Need an HR Security Policy?
The short answer: any company where employees have access to sensitive customer, financial, or business data. An HR security policy for employees sets clear obligations from day one, so there’s no ambiguity about what’s expected of anyone on the team.
More specifically:
- SaaS companies pursuing SOC 2 Type II: auditors check for this at every engagement. CC6.2 requires that access is managed tied to employment status. Without a written policy, you’ll be explaining yourself.
- Companies pursuing ISO 27001 certification: Annex A.7 is a required control set. It’s not optional.
- Healthcare organisations and vendors under HIPAA: §164.308(a)(3) mandates workforce security procedures, including clearance and termination processes.
- Any company handling EU personal data under GDPR: Article 32 requires appropriate security measures, which includes how you manage people with access to personal data.
- B2B companies selling into enterprise: procurement teams and security questionnaires ask for it. Not having one creates friction in deals.
Do Small Startups Need an HR Security Policy?
Yes. Even a five-person company needs defined rules for access provisioning and offboarding.
I know that sounds like overhead when you’re small. But a SOC 2 or ISO 27001 auditor doesn’t grade on a curve for company size. They ask whether the policy exists and whether it was followed. A two-page lightweight policy covers you. Nothing doesn’t.
What Your HR Security Policy Should Actually Cover
An effective HR security policy spans everything from the moment a candidate is screened to the moment an ex-employee’s last account is closed. Here’s what each section needs to address.
| Policy Section | What to Include |
|---|---|
| Purpose | Why the policy exists; which security risk and compliance obligations it addresses |
| Scope | Who it applies to (employees, contractors, interns, third-party vendors); in/out of scope categories |
| Roles and Responsibilities | Policy owner, HR, CISO, managers, IT — each with named responsibilities |
| Screening | Background check requirements by role; criminal record checks where permitted; third-party screening for privileged access |
| Competence and Performance Assessment | Skills assessment at hire; annual performance review with security policy adherence as a criterion |
| Terms and Conditions of Employment | NDA, AUP, policy acknowledgement, security training — all required before access is provisioned |
| Management Responsibilities | Policy distribution and availability; compliance monitoring; security obligations factored into performance reviews |
| Information Security Awareness, Education and Training | Security awareness training at hire and annually; role-specific training for privileged users; tracking of completion |
| Termination Process | Access revocation SLAs (same-day for terminations); asset return; post-departure confidentiality obligations |
| Disciplinary Process | Progressive disciplinary process for violations, up to and including termination |
| Exceptions | Formal exception request process: documented reason, alternative control, expiry date, named risk owner |
| Violations and Enforcement | Reporting channel; consequences including immediate access suspension and termination |
| Policy Review | Annual review cadence; out-of-cycle review triggers; re-acknowledgement required on material changes |
HR Data Security Policy Requirements
A subset worth calling out explicitly: HR data security policy requirements govern how you handle the employee data itself, not just how employees handle company data.
Employee PII, compensation records, performance data, and health information are all sensitive. They need their own controls:
- Storage: HR systems should be access-controlled and audited, not sitting in shared drives accessible to anyone with a company account
- Access: HR data accessible only to HR, legal, and named individuals with a legitimate need
- Retention: align with GDPR’s right to erasure and HIPAA’s retention requirements where applicable
- Logging: access to HR systems should be logged and reviewed periodically, the same way you’d treat access to production databases
Free HR Security Policy Template
Use this hr security policy sample as your starting point. Customise the scope, screening requirements, timelines, and role names to match your context. Have your legal counsel and security lead review it before rollout.
HR Security Policy
Policy Owner: [CISO / HR Director] Effective Date: [Date] Last Reviewed: [Date] Next Review Date: [Date + 12 months] Approved By: [Name, Title] Version: 1.0
1. Purpose
To ensure that employees and contractors meet security requirements, understand their responsibilities, and are suitable for their roles. This policy governs the security obligations that apply across the full employment lifecycle at [Company Name]: from pre-employment screening through to termination and offboarding.
2. Scope
This policy applies to all employees of [Company Name], consultants, contractors, and other third-party entities with access to [Company Name] production networks and system resources.
| Category | In Scope |
|---|---|
| Full-time employees | Yes |
| Part-time employees | Yes |
| Contractors and consultants | Yes |
| Interns | Yes |
| Third-party vendors with system access | Yes |
| Customers | No |
3. Roles and Responsibilities
| Role | Responsibility |
|---|---|
| HR Director / People Lead | Manages employment lifecycle events; communicates policy to new hires; initiates and tracks offboarding |
| CISO / Security Lead | Owns policy content; maintains access provisioning and revocation procedures; reviews policy annually |
| Managers | Approve access requests; initiate offboarding promptly when a direct report departs |
| IT / Engineering | Provisions and revokes access; maintains access logs; implements technical controls |
| All employees and contractors | Comply with this policy; complete required training; report suspected incidents |
4. Screening
Background verification checks on [Company Name] personnel shall be carried out in accordance with relevant laws and regulations, proportional to business requirements, data classification, and perceived risks. Criminal history checks may be included unless prohibited by local statute.
All third parties with privileged or administrative access to [Company Name] production systems must undergo a background check or provide evidence of an acceptable background, based on their level of access and associated risk.
| Requirement | Standard Roles | Privileged / Sensitive Roles |
|---|---|---|
| Identity verification | Yes | Yes |
| Reference verification (minimum 2) | Yes | Yes |
| Criminal record check | Where legally permitted | Yes |
| Credit / financial check | No | Where role involves financial data or systems |
| Completion timing | Before access provisioned | Before access provisioned |
5. Competence and Performance Assessment
Skills and competence of employees and contractors shall be assessed by HR staff and hiring managers. Required skills may align with the Information Security Roles and Responsibilities Policy. Evaluations may include reference checks, relevant certifications, or technical assessments.
All [Company Name] employees will have an annual performance review evaluating job performance, policy adherence, code of conduct, and role-specific objectives. Adherence to this HR security policy is included as a standard evaluation criterion.
6. Terms and Conditions of Employment
Company policies, security roles, and responsibilities must be communicated at hire. All employees and contractors must formally acknowledge their security responsibilities before system access is provisioned.
Required at onboarding:
- Sign a Non-Disclosure Agreement (NDA) or confidentiality agreement
- Sign an Acceptable Use Policy (AUP) or equivalent
- Acknowledge this HR Security Policy
- Complete mandatory security awareness training (initial module, within first 5 business days)
Contractual agreements must state the employee’s or contractor’s responsibilities for information security. All personnel must comply with [Company Name]’s information security policies at all times.
7. Management Responsibilities
Management shall ensure:
- Security policies are reviewed annually, distributed to all relevant personnel, and available for reference at all times
- Employees and contractors are aware of and comply with their information security responsibilities
- Information security responsibilities are communicated via job descriptions and onboarding materials
- Compliance with security policies is considered during performance evaluations
- Incentive structures and duty assignments account for potential fraud pressures and conflicts of interest
8. Information Security Awareness, Education and Training
All [Company Name] employees and third parties with administrative or privileged technical access to [Company Name] production systems must complete security awareness training at hire and annually thereafter.
| Requirement | Audience | Frequency |
|---|---|---|
| Security awareness training (general) | All employees and contractors | At hire, then annually |
| Role-specific security training | Engineering, IT, privileged users | At hire, then annually |
| Policy acknowledgement | All employees and contractors | At hire; on material policy updates |
| Professional development / certifications | Security leads and managers | Ongoing |
Management tracks training completion. Personnel must be aware of security and data privacy policies. Security leaders and managers must maintain relevant professional development and stay current on emerging threats.
9. Termination Process
Employee and contractor termination and offboarding shall ensure prompt revocation of physical and logical access to company assets in line with the SLAs below. All company-issued equipment must be returned. Any security or confidentiality agreements that remain valid post-termination must be communicated to the departing individual upon departure.
| Step | Timing | Owner |
|---|---|---|
| Access revocation (all systems, email, VPN, SaaS) | Same business day for terminations; within 1 business day for resignations | IT / Security |
| Device and asset return | At or before last day | HR / IT |
| Data export by departing employee | Not permitted without prior written approval | Security |
| Exit security briefing | Remind departing employee of ongoing NDA and confidentiality obligations | HR |
| Access revocation confirmation | IT confirms in writing that all access has been removed | IT |
For contractor offboarding: access is revoked immediately on completion of the engagement or at the contracted end date, whichever is sooner.
10. Disciplinary Process
Employees and third parties who violate [Company Name] information security policies are subject to the [Company Name] progressive disciplinary process, up to and including termination of employment or contract.
Significant violations include:
- Sharing credentials or provisioning unauthorised access to another person
- Exporting or transferring company data without authorisation
- Failing to report a known security incident
- Deliberate circumvention of access controls or security tools
Violations involving legal obligations (for example, data protection laws) may be referred to relevant regulatory or legal authorities.
11. Exceptions
Requests for an exception to this policy must be submitted to [CISO / HR Director] for approval. Each request must document:
- The nature of the exception and the business reason
- An alternative control that mitigates the associated risk
- An expiry date (maximum 90 days unless formally renewed)
- A named risk owner accountable for the exception
Exceptions are reviewed at each annual policy review cycle and revoked if the justification no longer applies.
12. Violations and Enforcement
Any known violations of this policy should be reported to [CISO / security@company.com]. Violations can result in immediate withdrawal or suspension of system privileges and disciplinary action up to and including termination of employment or contract.
13. Policy Review
This policy is reviewed annually. It is also reviewed following:
- A significant organisational change (restructure, acquisition, major headcount change)
- A security incident involving a personnel process
- A material change to any framework this policy supports (SOC 2, ISO 27001, HIPAA, GDPR)
All employees will be notified of material changes and required to re-acknowledge the updated policy.
Revision History
| Version | Date | Author | Summary of Changes |
|---|---|---|---|
| 1.0 | [Date] | [Author] | Initial version |
How to Write and Roll Out an HR Security Policy
A policy that exists on paper but isn’t followed is worse than having nothing. It shows up in audits as a control failure: you had a policy, the control didn’t operate, and now you have a finding. The goal isn’t just to write the document. It’s to make the process real.
Here’s how to do it:
- Assign joint ownership. Nominate a named owner from HR and one from Security. Both need to be accountable, not just listed.
- Audit your current HR processes. Where does access provisioning actually happen today? What does offboarding look like in practice? Map the reality before you write the ideal.
- Draft the policy. Use the template in Section 6 as your base. Customise the scope, timelines, and role names for your context.
- Get sign-off from HR, Legal, and an executive stakeholder. The policy needs to be approved at the right level, not just written by one person.
- Distribute to all employees and require dated acknowledgement. Not an email to the team. A tracked sign-off.
- Integrate with onboarding and offboarding checklists. The policy only works if it triggers action at the right moment.
- Map to compliance controls. Document which controls this policy satisfies for SOC 2, ISO 27001, HIPAA, or GDPR. Your auditor will ask.
- Start collecting evidence. Sign-off logs, training completion records, access provisioning and revocation tickets. You need these before the audit, not during it.
- Set a calendar reminder for annual review. Update after any significant org change, not just annually.
HR Security Policy Best Practices for Rollout
Write it in plain language. A policy employees can’t understand won’t be followed. If you need a legal review, do it after the plain-language draft, not before.
Make acknowledgement trackable. “I sent a Slack message” is not a record. Use a GRC tool, a signed form, or an onboarding checklist with a sign-off step.
Integrate with your HRIS. Offboarding triggers should fire automatically when a departure is logged, not when someone remembers to email IT.
Test your own offboarding process. Provision a test account and verify it gets revoked on schedule. You’d be surprised how often it doesn’t.
HR Security Policy Mapping: SOC 2, ISO 27001, HIPAA, and GDPR
If you’re pursuing a certification or framework alignment, here’s how your HR security policy maps to the specific requirements.
| Framework | Controls | What Your HR Security Policy Must Address |
|---|---|---|
| SOC 2 | CC1.4 (COSO), CC6.2 | Pre-employment background checks; security training; access provisioning tied to employment; offboarding access revocation |
| ISO 27001 | Annex A.6 (Org security), Annex A.7 (HR security) | Screening prior to employment; terms of employment; security education and training; disciplinary process; responsibilities at termination |
| HIPAA | §164.308(a)(3) Workforce Security | Authorisation and supervision; workforce clearance procedures; termination procedures |
| GDPR | Articles 32, 88 | Security measures for employee data processing; data protection obligations for employees handling personal data; breach notification obligations |
Does SOC 2 Require an HR Security Policy?
Yes. CC6.2 requires that logical access is managed tied to employment status: provisioned at onboarding, updated on role change, revoked on departure.
In a SOC 2 Type II audit, your auditor will check for three things: evidence that access was provisioned at onboarding with approval, evidence that access was revoked at offboarding within your stated SLA, and records showing security training was completed. Without a written policy and the evidence to back it up, you can’t demonstrate the control is operating consistently.
ISO 27001 Annex A.7: Human Resource Security
Annex A.7 covers human resource security in three phases, and each phase must be governed by a documented, approved policy.
Prior to employment: screening requirements, and terms and conditions of employment that set out security responsibilities. ISO 27001 Annex A.7 covers this in detail.
During employment: management responsibilities for enforcing the policy, security awareness and training requirements, disciplinary process for violations.
Termination or change of employment: responsibilities on termination, return of assets, removal of access rights.
An ISO auditor will ask to see the policy, evidence that it’s been communicated and acknowledged, and operational records that show each phase is actually being followed.
What Auditors Want to See in Your HR Security Records
Writing the policy is step one. Collecting the evidence that it’s working is step two, and it’s what most teams underinvest in until they’re three weeks from an audit.
| Record Type | Example |
|---|---|
| Employee policy acknowledgements | Signed or electronically confirmed AUP and HR security policy, with date and employee name |
| Security training completion | LMS export or sign-off sheet; includes date of completion and training version |
| Background check log | Confirmation that a check was completed for each in-scope employee; outcome on file (not the full report) |
| Onboarding access provisioning records | IT ticket or log entry showing access granted, approved by manager, dated |
| Offboarding access revocation records | IT ticket or log showing all access removed; timestamp; confirmation from IT |
| Annual policy review record | Version history with approver name and date; change log |
| Contractor NDA log | Signed NDAs on file; date signed; contractor name |
| Access review records | Quarterly or annual access review output showing who reviewed and what was confirmed or removed |
The most common gap is offboarding evidence. Companies revoke access (sometimes) but don’t keep a timestamped record of when and who confirmed it. That record is what your auditor is asking for.
HR Security Policy Mistakes That Create Real Compliance Gaps
These aren’t edge cases. They show up in audit findings regularly.
No offboarding SLA. The policy says access will be revoked “promptly.” Promptly means nothing to an auditor. Define it: same business day for terminations, within one business day for resignations. Without a number, there’s no control to test.
Training with no records. The company runs a security awareness session. Nobody kept attendance. Nobody logged completion. An auditor asks for training records for the last 12 months and you can’t produce them. The training happened, but there’s no proof.
Contractors excluded from scope. The policy says it applies to employees. The contractor with admin access to your production database is not an employee. This is a common gap that auditors notice because it’s obvious once you look at the access logs.
NDAs signed but not tracked. Agreements get collected during onboarding and filed in someone’s inbox. No log, no central record, no way to produce them on demand. If an auditor asks for a signed NDA for a specific contractor, you shouldn’t have to go searching through email.
Policy never updated. Version 1.0 from three years ago. No evidence of annual review. No change log. This fails the ISO 27001 requirement for continual improvement and tells an auditor the policy isn’t actively managed.
HR and IT in silos. HR logs the departure in the HRIS. Nobody tells IT. Access revocation happens two weeks later when someone notices. This is a process failure, not a technical one, and it’s exactly what a written policy with defined responsibilities is meant to prevent.
Tailoring Your HR Security Policy to Your Company’s Growth Stage
The same policy doesn’t fit a 10-person startup and a 200-person company. Here’s how to right-size it.
Startups (1-15 employees)
Keep it simple. A two-page policy covering the essentials is fine: access provisioning, offboarding checklist, training sign-off, NDA. You don’t need formal workflows or tiered approval chains at this stage.
Use a shared checklist (Notion, Linear, a GRC tool) as your offboarding trigger. Make acknowledgement trackable via a simple signed form or GRC e-signature. The goal is to have something written, approved, and followed. Not something elaborate.
Growing Companies (15-100 employees)
Formalise the process. Integrate with your HRIS so offboarding triggers automatically. Move to ticketed access requests with named approvers. Background check requirements become more important as you handle more sensitive data.
Start distinguishing access tiers: engineering with production access, finance, admin, executive. Each tier should have its own provisioning and review cadence.
Larger Enterprises (100+ employees)
At this scale, a single HR security policy may not be enough. You may need separate policies for employees, contractors, third-party vendors, and privileged users.
Automated provisioning and deprovisioning workflows, integrated with the HRIS, become necessary rather than nice-to-have. Quarterly access reviews are a standard control. A separate Privileged Access Management (PAM) policy should govern elevated accounts.
Managing Your HR Security Policy with ComplyJet
The administrative overhead of maintaining an HR security policy, collecting evidence, chasing acknowledgements, and keeping everything audit-ready is real. It’s also the part that tends to slip when teams are busy.
ComplyJet handles the admin so HR and security aren’t chasing paper:
- AI-assisted policy drafting: get a policy tailored to your specific frameworks in minutes, not days
- Employee acknowledgement tracking: log who signed, when, and which version, with a full audit trail
- Onboarding and offboarding checklists: integrated with the policy so the right actions happen at the right time
- Compliance control mapping: map your HR security policy to SOC 2, ISO 27001, HIPAA, and GDPR automatically
- Evidence collection: store training records, access logs, and review history in one place
- Review reminders and version history: annual reviews don’t fall through the cracks, and every change is logged
FAQs
HR security policy definition
An HR security policy is a formal document that defines the information security requirements tied to the employment lifecycle: pre-employment screening, onboarding, security responsibilities during employment, and offboarding. It governs who gets access to what systems, what training employees must complete, and what happens when someone leaves. Ownership sits jointly with HR and your security function, because the process spans both.
What should an HR security policy include?
A complete HR security policy covers: purpose and scope, pre-employment screening requirements, security onboarding obligations (training, NDA, acceptable use sign-off), ongoing responsibilities during employment, access management (least privilege, access reviews), offboarding procedures with defined timelines, contractor and third-party requirements, disciplinary action for violations, and a review cadence. The template in Section 6 covers all of these.
Who is responsible for the HR security policy?
Joint ownership: HR manages the employment lifecycle events (start dates, role changes, departures), and Information Security owns the security controls and access management requirements. Both need to be accountable. A policy owned by HR alone tends to miss security controls; a policy owned by Security alone tends not to get operationalised into actual HR processes.
Is an HR security policy required for SOC 2 compliance?
Yes. CC6.2 requires that logical access is managed tied to employment status: provisioned at onboarding, updated at role changes, revoked at offboarding. In a Type II audit, your auditor will test whether that control is operating consistently over the audit period, not just whether the policy exists.
How do you implement an HR security policy?
Start by assigning joint ownership between HR and Security. Audit your current HR processes, then draft the policy. Get sign-off from HR, Legal, and an executive stakeholder. Distribute to all staff and collect tracked acknowledgements. Integrate the policy into your onboarding and offboarding checklists. Map it to your compliance controls, start collecting evidence, and schedule an annual review.
What is the difference between an HR policy and a security policy?
An HR policy covers employment terms, benefits, conduct, and legal obligations around employment. An HR security policy specifically covers information security: how employees handle data and systems, what access they get, what training they must complete, and what happens to their access when they leave. Best practice is to keep them separate so the security policy can be owned and updated independently by the security team.
How often should an HR security policy be reviewed?
At minimum annually. Beyond that, review it after any significant organisational change (restructure, acquisition, major headcount change), after a security incident involving a personnel process, or when there’s a material change to a framework the policy supports. “We review annually” satisfies ISO 27001 and SOC 2. “We haven’t reviewed it in three years” does not.
Can a small startup get away without an HR security policy?
Not really. Even a five-person company should have a documented offboarding process and access provisioning rule. SOC 2 and ISO 27001 auditors don’t waive this requirement for small companies. A two-page lightweight policy that’s actually followed is far better than nothing, and far better than a 20-page policy that isn’t.
Related Policies
- Data Classification Policy: defines how sensitive HR data is classified and handled
- BYOD Policy: addresses personal device use, which intersects with HR onboarding and offboarding requirements






