Does SOC 2 require an employee handbook?

No. No criterion names one. CC2.2 expects the company to communicate security responsibilities to its people, and CC1.4 expects it to develop their competence, so the auditor will ask how people learn the rules that apply to them and may ask employees about them. Policies, training and signed acknowledgments are the usual evidence. A short handbook makes the communication part easier to do and easier to show, because people actually read it.

Can the handbook replace the policies?

No. It restates the rules from the policies that apply to everyone, in plain language, and points back to each policy statement. The policies stay the full text with owners, procedures and exceptions. If a rule in the handbook ever reads differently from its policy, fix one of them: the handbook should never require something the policy does not, or leave out something the policy requires of everyone.

Why is every rule followed by a reference like (P04 4.5)?

So each rule can be traced. P04 4.5 means statement 4.5 of policy P04, the Authentication and Password Policy. The Markdown version ends with a table that quotes the policy text behind every rule. The handbook never adds a rule the policies do not contain: when a policy has no statement on a topic, that rule is left out.

Does signing the handbook replace the policy acknowledgment?

No. The acknowledgment page at the end confirms that the person received and read the handbook. Your Information Security Policy asks everyone to acknowledge it and the Acceptable Use Policy in writing, and the policy acknowledgment form is the record for that. Many teams collect both at onboarding, on the same day as the security awareness training.

Who should get the engineering section?

Anyone who writes code, changes infrastructure or deploys to production, including contractors. It is marked as engineers only, so everyone else can skip it. It is not on the 10 rules page.

What does the Audit Kit version add?

The free handbook is built from the policy template text rendered from your answers. In the Audit Kit, the policies are tailored to your tools and team first, and people/security-handbook.docx and people/security-handbook.md are built from those tailored statements, with the generation date and intake reference in the footer.

Is anything uploaded?

No. The generator keeps your answers in this browser's local storage, the policies are rendered here, and the Word and Markdown files are built on your device. With no saved answers the page shows the sample company, Northwind Cloud Inc.

Employee security handbook template

Updated 23 October 2026

Nobody reads 22 policies. This handbook gives everyone the rules that apply to them in a few pages of plain language: the 10 rules on one page, then accounts, devices, data, AI tools, remote work, incidents, vendors, engineering changes and leaving. Every rule cites the policy statement it comes from. Built in your browser from your own policies, as Word or Markdown; nothing is uploaded and there is no signup.

This is the sample company, Northwind Cloud Inc. The rules quote its generated policies, not yours. Answer the generator questions and come back: the handbook is then built from the policies written from your answers.

Download the employee security handbook

10 sections and 52 rules for Northwind Cloud Inc, with the 10 rules on one page at the front and an acknowledgment page at the end. Word for printing and signing, Markdown for a wiki or Notion. Built in your browser; nothing is uploaded and there is no signup.

The 10 rules

The one-page summary at the front of the handbook. The reference after each rule is the policy and statement it comes from.

1.If you see or suspect a security incident, you must report it to security@northwindcloud.example within one hour of discovery. (P13 4.1)
2.Use multi-factor authentication on every work account. There is no exception for seniority. (P04 4.2)
3.Your accounts are yours alone. Never share passwords, session cookies, multi-factor codes or hardware keys, and never sign in as someone else. (P02 4.2)
4.Generate and store every work password in 1Password. Never keep passwords in your browser, spreadsheets, notes, chat or email. (P04 4.5)
5.Keep customer data and Confidential or Restricted information inside approved systems. Never copy it to personal email, personal cloud storage, removable media, screenshots, chat messages or unapproved tools. (P02 4.5)
6.Never put customer data, secrets, personal data or unreleased source code into an AI tool unless the Security Owner has confirmed in writing that the tool's data handling terms allow it. (P02 4.6)
7.Reach production systems, source code and customer data only from a company-managed device. (P02 4.4)
8.Check any unexpected request for money, credentials or data through a second channel before you act on it. (P02 4.10)
9.Do not give a vendor company data, system access or a connection to company accounts until the Security Owner has added it to the vendor inventory and cleared it. Free, trial and personal-account services count too. (P16 4.2)
10.On public or untrusted networks, such as hotels, airports and cafes, reach production systems, admin consoles or customer data only through the company VPN or identity-aware proxy. (P21 4.8)

The sections

Open a section to see its rules and the policy statement behind each one.

1. Your accounts and passwords7 rules
How you sign in to Northwind Cloud Inc systems and look after your credentials.
- Company sign-in (identity provider): Okta.
- Password manager: 1Password.
- Multi-factor authentication: required on every workforce account.
- 1.1 Use multi-factor authentication on every work account. There is no exception for seniority.
  P04 Authentication and Password Policy, statement 4.2: “Multi-factor authentication is mandatory for every workforce account at Northwind Cloud Inc, without exception for seniority.”
- 1.2 Never approve a sign-in prompt you did not start. Report an unexpected prompt to security@northwindcloud.example.
  P02 Acceptable Use Policy, statement 4.3: “Personnel never approve an authentication prompt they did not initiate; an unexpected prompt is reported to security@northwindcloud.example.”
- 1.3 Your accounts are yours alone. Never share passwords, session cookies, multi-factor codes or hardware keys, and never sign in as someone else.
  P02 Acceptable Use Policy, statement 4.2: “Personnel never share passwords, session cookies, multi-factor codes or hardware keys, never sign in as another person, and never create accounts outside the Access Control Policy process.”
- 1.4 Generate and store every work password in 1Password. Never keep passwords in your browser, spreadsheets, notes, chat or email.
  P04 Authentication and Password Policy, statement 4.5: “All work credentials are generated and stored in 1Password, provisioned for every person at onboarding. Passwords are not stored in browsers, spreadsheets, notes, chat or email, and the password manager's master password is a strong, unique passphrase protected by multi-factor authentication.”
- 1.5 Any password you choose yourself is at least 14 characters long.
  P04 Authentication and Password Policy, statement 4.4: “Passwords chosen by people are at least 14 characters, with no maximum below 64 and no mandatory character-class rules.”
- 1.6 Never reuse a work password on another system or for anything personal.
  P04 Authentication and Password Policy, statement 4.6: “Work passwords are never reused across systems or as personal passwords.”
- 1.7 You do not change passwords on a schedule. Change one immediately if you suspect it is compromised or it appears in a breach.
  P04 Authentication and Password Policy, statement 4.4: “Passwords are not rotated on a fixed schedule; they are changed immediately when compromise is suspected, when they appear in a breach, or when a person who knew a shared secret leaves.”
2. Your devices6 rules
The laptop and phone you use for Northwind Cloud Inc work, and what must stay switched on.
- Device management tool: Kandji.
- Who issues and collects devices: [Fill in: name or team].
- 2.1 Your company device is enrolled in Kandji before you receive it. Never remove the enrollment.
  P19 Endpoint and Workstation Security Policy, statement 4.3: “Every company endpoint is enrolled in Kandji before it is issued, and enrollment may not be removed by the user.”
- 2.2 Reach production systems, source code and customer data only from a company-managed device.
  P02 Acceptable Use Policy, statement 4.4: “Production systems, source code and customer data are accessed only from company-managed devices running a supported operating system with full-disk encryption, screen lock and automatic updates enabled and enrolled in Kandji.”
- 2.3 Keep full-disk encryption turned on.
  P19 Endpoint and Workstation Security Policy, statement 4.4: “Full-disk encryption (FileVault on macOS, BitLocker on Windows, LUKS on Linux and platform encryption on mobile devices) is enabled on every endpoint, with recovery keys escrowed in Kandji rather than held only by the user.”
- 2.4 Your device must lock automatically after no more than 10 minutes of inactivity.
  P19 Endpoint and Workstation Security Policy, statement 4.5: “Endpoints lock automatically after no more than 10 minutes of inactivity and require a password, passphrase or biometric to unlock.”
- 2.5 Let operating system and browser updates install automatically. Critical and high security updates go on within 7 days of release.
  P19 Endpoint and Workstation Security Policy, statement 4.6: “Operating system and browser updates install automatically. Security updates rated critical or high are applied within 7 days of release and all other security updates within 30 days.”
- 2.6 Install software only from official vendor sources or the approved list, keep it updated, and never disable or tamper with security software, disk encryption or other security controls.
  P02 Acceptable Use Policy, statement 4.8: “Personnel install software only from official vendor sources or the approved list, keep it updated, and never disable or tamper with endpoint protection, disk encryption, logging agents, Kandji management profiles or other security controls.”
3. Handling data7 rules
How Northwind Cloud Inc classifies information, and where customer data may and may not go.
- Northwind Cloud Inc handles personal data (PII) for its customers.
- 3.1 Information has four levels: Public, Internal, Confidential and Restricted.
  P06 Data Classification and Handling Policy, statement 4.1: “Northwind Cloud Inc classifies information into four levels. Public is approved for release to anyone. Internal is routine business information whose disclosure would cause limited harm. Confidential is information whose disclosure would harm Northwind Cloud Inc, its personnel or its partners, such as financial records, contracts, personnel data, source code and security configurations. Restricted is information whose disclosure would seriously harm customers or Northwind Cloud Inc or breach a legal or contractual obligation, including all customer data processed by Northwind, all PII data, credentials and encryption keys, and security incident details.”
- 3.2 Treat as Restricted: all customer data processed by Northwind, all PII data, credentials and encryption keys, and security incident details.
  P06 Data Classification and Handling Policy, statement 4.1: “Restricted is information whose disclosure would seriously harm customers or Northwind Cloud Inc or breach a legal or contractual obligation, including all customer data processed by Northwind, all PII data, credentials and encryption keys, and security incident details.”
- 3.3 If someone asks to see, correct or delete their personal data, pass the request to the Security Owner within one business day.
  P06 Data Classification and Handling Policy, statement 4.8: “Requests from individuals to access, correct or delete their data are routed to the Security Owner within one business day.”
- 3.4 When you are not sure of the level, use the higher one until the Security Owner decides.
  P06 Data Classification and Handling Policy, statement 4.2: “The person who creates or first receives information classifies it; where unclear, the higher level applies until the Security Owner decides.”
- 3.5 Keep customer data and Confidential or Restricted information inside approved systems. Never copy it to personal email, personal cloud storage, removable media, screenshots, chat messages or unapproved tools.
  P02 Acceptable Use Policy, statement 4.5: “Customer data and Confidential or Restricted information, as defined in the Data Classification and Handling Policy, stay inside approved systems and are never copied to personal email, personal cloud storage, removable media, screenshots, chat messages or unapproved tools.”
- 3.6 Do not keep customer data or production datasets on your device. If a task needs a local copy, keep the minimum, only for that task, and delete it when you finish.
  P19 Endpoint and Workstation Security Policy, statement 4.10: “Customer data and production datasets are not stored on endpoints. Where a task requires a local copy, it is limited to the minimum data needed, kept only for the duration of the task and deleted when the task is complete.”
- 3.7 Share Confidential or Restricted information outside the company only with a party under a signed confidentiality agreement, through approved channels, with the minimum content needed and the information owner's approval.
  P06 Data Classification and Handling Policy, statement 4.7: “Confidential and Restricted information is shared externally only with a party under a signed agreement with confidentiality terms, through approved channels with encryption and access control, with the minimum content required, and with the information owner's approval.”
4. Using AI tools2 rules
AI assistants, code generation tools and similar services, including AI features inside tools you already use.
- Approved AI tools: [Fill in: where the approved tool list is kept, and who adds tools to it].
- 4.1 Use AI assistants, code generation tools and similar services only if they are on the approved tool list.
  P02 Acceptable Use Policy, statement 4.6: “AI assistants, code generation tools and similar services are used only if they are on the approved tool list.”
- 4.2 Never put customer data, secrets, personal data or unreleased source code into an AI tool unless the Security Owner has confirmed in writing that the tool's data handling terms allow it.
  P02 Acceptable Use Policy, statement 4.6: “Customer data, secrets, personal data and unreleased source code are not entered into any AI tool unless the Security Owner has confirmed in writing that its data handling terms permit it.”
5. Working remotely and traveling6 rules
Working from home, coworking spaces, cafes and while you travel.
- Work model: Remote.
- 5.1 Away from the office, keep your screen out of view of others, lock your device when you step away, do not discuss Confidential information in public, and reach internal systems only through the company-approved connection method.
  P02 Acceptable Use Policy, statement 4.11: “When working away from a company office, personnel keep screens out of the view of others, lock devices when stepping away, avoid discussing Confidential information in public, and reach internal systems only through the company-approved connectivity method.”
- 5.2 Never leave a company device unattended in a public place, in a vehicle or in an unsecured shared space.
  P21 Physical and Remote Work Security Policy, statement 4.5: “Company devices are never left unattended in public places, in vehicles or in unsecured shared spaces.”
- 5.3 At home, work where household members and visitors cannot see your screen, and use headphones for calls others could overhear. Nobody else uses your company device.
  P21 Physical and Remote Work Security Policy, statement 4.6: “Personnel working from home maintain a workspace where screens cannot be observed by household members or visitors during work involving company or customer information, and use headphones for calls where others could overhear. Company devices are used only by the person they are assigned to.”
- 5.4 Protect your home Wi-Fi with WPA2 or WPA3 and a strong, non-default password. Change the router's admin password from the factory default and keep its firmware up to date.
  P21 Physical and Remote Work Security Policy, statement 4.7: “Home networks used for work are protected with WPA2 or WPA3 encryption and a strong, non-default Wi-Fi password; the router's administrative password is changed from the factory default and its firmware is kept up to date.”
- 5.5 On public or untrusted networks, such as hotels, airports and cafes, reach production systems, admin consoles or customer data only through the company VPN or identity-aware proxy.
  P21 Physical and Remote Work Security Policy, statement 4.8: “On public or untrusted networks (hotels, airports, cafés, coworking spaces) personnel do not access production systems, administrative consoles or customer data unless the connection goes through the company VPN or an identity-aware proxy that encrypts all traffic and verifies the device.”
- 5.6 Before you travel to a country with an elevated risk of device search, seizure or surveillance, talk to the Security Owner. If border officials or anyone else take your device out of your control, report it to security@northwindcloud.example; it is treated as compromised.
  P21 Physical and Remote Work Security Policy, statement 4.10: “Before travel to countries with an elevated risk of device search, seizure or surveillance, personnel consult the Security Owner, who may issue a travel device with minimal data and require credentials to be rotated on return. A device taken out of the traveler's control by border officials or anyone else is reported to security@northwindcloud.example and treated as compromised.”
6. Spotting and reporting incidents5 rules
A security incident is anything that may put company or customer data or systems at risk. When in doubt, report it.
- Report to: security@northwindcloud.example.
- Security Owner: Dana Whitfield, CTO.
- 6.1 If you see or suspect a security incident, you must report it to security@northwindcloud.example within one hour of discovery.
  P13 Incident Response Policy, statement 4.1: “Anyone who observes or suspects a security incident must report it to security@northwindcloud.example within one hour of discovery.”
- 6.2 Report lost or stolen devices, suspected malware, phishing attempts and accidental data exposure to security@northwindcloud.example as soon as you discover them, and in any case within one hour.
  P02 Acceptable Use Policy, statement 4.13: “Lost or stolen devices, suspected malware, phishing attempts, accidental data exposure and any other suspected security event are reported to security@northwindcloud.example as soon as they are discovered and in any case within one hour, as the Incident Response Policy requires.”
- 6.3 You are never penalized for reporting in good faith, even if you caused the problem.
  P13 Incident Response Policy, statement 4.1: “Good-faith reports are never penalized, even where the reporter caused the incident.”
- 6.4 Check any unexpected request for money, credentials or data through a second channel before you act on it.
  P02 Acceptable Use Policy, statement 4.10: “Personnel verify unexpected requests for money, credentials or data through a second channel before acting, do not auto-forward company mail to external addresses, and share documents externally only through approved systems with the narrowest audience that gets the job done.”
- 6.5 Do not confirm, deny or speculate about an incident with anyone outside the company. Only Executive Management, or its designate, speaks to customers, the press, regulators or the public.
  P13 Incident Response Policy, statement 4.7: “Only Executive Management, or their designate for the incident, communicates about it with customers, the press, regulators, law enforcement or the public; personnel must not confirm, deny or speculate about incidents with third parties.”
7. Using third-party tools and vendors4 rules
Any outside service, app, extension or free trial that touches company accounts or data.
- Vendors already in use include Supabase, Stripe, Datadog and Slack.
- Where the approved vendor and tool list is kept: [Fill in: location].
- 7.1 Do not give a vendor company data, system access or a connection to company accounts until the Security Owner has added it to the vendor inventory and cleared it. Free, trial and personal-account services count too.
  P16 Vendor and Third-Party Risk Management Policy, statement 4.2: “No vendor receives Northwind Cloud Inc data, system access or a connection to Northwind Cloud Inc accounts until it is in the inventory, tiered by the Security Owner and cleared through the due diligence for its tier. Free, trial and personal-account services follow the same rule.”
- 7.2 Do not connect third-party apps, browser extensions or AI services to company accounts, or paste confidential or customer data into them, unless the service is an approved vendor cleared for that data.
  P16 Vendor and Third-Party Risk Management Policy, statement 4.12: “Personnel may not connect third-party applications, browser extensions or artificial-intelligence services to Northwind Cloud Inc accounts, or paste confidential or customer data into them, unless the service is an approved vendor whose tier permits that data.”
- 7.3 Get approval before you buy any SaaS subscription or service. Services paid for on a personal card or expensed without approval are not allowed.
  P05 Asset Management Policy, statement 4.7: “SaaS subscriptions and services are approved under the Acceptable Use Policy before purchase, recorded in the register with their owner, the data classification they hold and their renewal date, and provisioned through Okta where supported. Services paid for on personal cards or expensed without approval are not permitted.”
- 7.4 Ask the Security Owner before you install a browser extension that can read page content.
  P19 Endpoint and Workstation Security Policy, statement 4.8: “Software is installed only from official vendor sources or app stores, and browser extensions with access to page content require Security Owner approval.”
8. Code and production changesengineers only7 rules
For engineers and anyone else who writes code, changes infrastructure or deploys. Everyone else can skip this section.
- Source control: GitHub. Deployment pipeline: GitHub Actions.
- 8.1 Make every change through a pull or merge request in GitHub.
  P09 Change Management Policy, statement 4.2: “Every change is made through a pull or merge request in GitHub.”
- 8.2 Never approve your own change.
  P09 Change Management Policy, statement 4.9: “The author of a change never approves it, and self-approval is disabled in GitHub.”
- 8.3 Never edit code or configuration directly on servers, in containers or in cloud consoles, except under the emergency procedure, and bring any emergency change back into source control afterward.
  P09 Change Management Policy, statement 4.1: “Editing code or configuration directly on servers, in containers or in cloud consoles is prohibited except under the emergency procedure in 5.6, and any such change is reconciled into GitHub afterward.”
- 8.4 Deploy to production only through GitHub Actions. Never deploy to production with your personal credentials.
  P09 Change Management Policy, statement 4.6: “Production deployments are performed only by GitHub Actions using dedicated service identities scoped to the target environment. Personal credentials never deploy to production, and the deployment record captures who triggered it, the commit deployed and the outcome.”
- 8.5 Never write secrets such as API keys, tokens, private keys or database passwords into source code, tickets, chat, documents or wikis. Keep them in the approved secrets manager, and never bypass secret scanning.
  P02 Acceptable Use Policy, statement 4.7: “Secrets such as API keys, tokens, private keys and database passwords are never written into source code, tickets, chat, documents or wikis. They live in the secrets manager approved by Engineering, and secret scanning in GitHub is never bypassed.”
- 8.6 Never copy production customer data into development, staging, test or analytics environments. Where you need realistic data, use synthetic data or data anonymized through a process the Security Owner has approved.
  P06 Data Classification and Handling Policy, statement 4.6: “Production customer data is not copied into development, staging, test or analytics environments. Where realistic data is needed, Engineering uses synthetic data or data irreversibly anonymized through a process approved by the Security Owner.”
- 8.7 Review code generated by AI assistants or copied from external sources to the same standard as code a person wrote.
  P10 Secure Software Development Policy, statement 4.12: “Code generated by AI assistants or copied from external sources is reviewed to the same standard as human-written code, and secrets, customer data and unreleased proprietary code are never submitted to unapproved AI tools or external services.”
9. Changing roles and leaving4 rules
What happens to your access, devices and data when your role changes or your engagement ends.
- Who collects returned devices, and how to ship them: [Fill in: name or team, and the shipping process].
- 9.1 When you change role, team or manager, your access is reviewed against the new role within five business days, and access you no longer need is removed.
  P18 Human Resources Security Policy, statement 4.5: “When a person changes role, team or manager, their access is reviewed against the new role's profile within five business days. Access no longer required is removed rather than accumulated; a role change never grants access by default.”
- 9.2 When you leave, your accounts are disabled and your sessions ended before the end of your last working day.
  P18 Human Resources Security Policy, statement 4.6: “When an engagement ends, the Okta account is disabled and sessions revoked before the end of the last working day (immediately for involuntary departures or leave pending investigation), and all remaining access is removed within one business day, as set out in the Access Control Policy.”
- 9.3 Return every company device on or before your last working day.
  P18 Human Resources Security Policy, statement 4.7: “Company devices are returned on or before the last working day.”
- 9.4 Do not keep company or customer data in personal email, personal cloud storage, personal devices or removable media.
  P07 Data Retention and Disposal Policy, statement 4.11: “Personnel may not keep company or customer data in personal email, personal cloud storage, personal devices or removable media.”
10. Where the full policies are and who to ask4 rules
This handbook summarizes the rules in Northwind Cloud Inc's security policies that apply to you. The policies themselves are the full text.
- The full policy set: [Fill in: where the full policies are published, for example the company wiki].
- Questions about any rule or policy: Dana Whitfield, CTO, the Security Owner.
- 10.1 If you cannot follow a policy, ask for a documented exception first. Going around a policy without one is a violation.
  P01 Information Security Policy, statement 4.13: “Deviations from any policy require a documented exception under section 6; undocumented deviations are policy violations.”
- 10.2 Acknowledge the Information Security Policy and the Acceptable Use Policy in writing when you join, at each annual review and after each material revision.
  P01 Information Security Policy, statement 4.6: “All personnel acknowledge this policy and the Acceptable Use Policy in writing at hire, at each annual review and after each material revision.”
- 10.3 Complete security awareness training within 30 days of starting and at least every 12 months after that.
  P18 Human Resources Security Policy, statement 4.4: “All personnel complete security awareness training within 30 days of starting and at least every 12 months thereafter.”
- 10.4 Violations are handled through a formal disciplinary process. Sanctions range from retraining to termination of employment or contract.
  P18 Human Resources Security Policy, statement 4.11: “Violations of security policy are handled through a formal disciplinary process that is proportionate, documented and consistent. Sanctions range from retraining to termination of employment or contract and, where the law requires, referral to authorities.”

Why a handbook

CC2.2 asks whether the company communicates security responsibilities to the people who carry them out, and CC1.4 whether it develops their competence. An auditor checks this through what you can show and sometimes by asking employees directly. Policies are written for owners and auditors; most people never open them. A short handbook that a new hire reads in one sitting, signs and can search later is the practical way to make sure people know the rules, and it gives you one document to point to.

How it fits with the policies, the training and the acknowledgment

Document	What it is for	Who uses it
The 22 policies	The full rules, owners, procedures and exceptions. The source of truth the auditor tests against.	Policy owners, the Security Owner, the auditor
This handbook	A short reference to the rules that apply to everyone, each one citing its policy statement.	Every employee and contractor
Security awareness training	Teaches the same rules once a year and at onboarding, with a quiz and a completion record.	Every employee and contractor
Policy acknowledgment form	The signed record that a person received and agreed to the policies.	People Operations keeps it as evidence

The security awareness training pack teaches the same rules and records who completed it; the handbook is what people keep and look things up in afterward. The policy acknowledgment guide covers the signed form and what to keep. The handbook’s own acknowledgment page is a lighter sign-off that the person received it, and does not replace the policy acknowledgment.

How the handbook is built

From section 4 of your policies. Each rule is a plain-language, second-person version of a policy statement, such as the Acceptable Use Policy for accounts and data, the Endpoint and Workstation Security Policy for devices and the Incident Response Policy for reporting. A rule appears only when its statement is in the policy, so the handbook never asks for more than the policies do.
Traceable. Each rule ends with its policy id and statement number. The Markdown version adds a table quoting the policy text behind every rule, word for word or cut at a clause boundary.
From your answers. If you said multi-factor authentication is not yet on every account, the handbook says it is being rolled out and never says it is required everywhere. Without a device management tool, the device rules describe the written baseline and the quarterly check instead.
Placeholders where the answers stop. Where the policies are published, who collects devices and where the approved tool list lives are left as [Fill in: ...] for you to complete.

What your generator answers change

Section	Changes with
Your accounts and passwords	multi-factor authentication answer (in place everywhere, or still being rolled out), password manager, identity provider
Your devices	device management tool, or the written baseline and quarterly check when there is none
Handling data	data types: health data and payment data each add a rule, personal data adds the rule on requests from individuals
Working remotely and traveling	work model (remote, hybrid or office)
Spotting and reporting incidents	incident contact, and the reporting deadline in your Incident Response Policy
Using third-party tools and vendors	vendor list
Code and production changes	source control and CI/CD pipeline
Who to ask, and the acknowledgment	Security Owner, company name, policy effective date

Rolling it out

Replace every [Fill in: ...] and read each rule against how your team actually works. If a rule is wrong, change the policy as well.
Have the Security Owner approve it and put it next to the policies, in your wiki or shared drive.
Send it to everyone, and add it to onboarding before a new hire gets system access.
Collect the signed acknowledgment page and keep it with the training and policy acknowledgment records.
Rebuild it after each policy review, so the handbook and the policies never drift apart.

Free template and Audit Kit

The downloads on this page are built from the policy template text, rendered from your answers. The Audit Kit includes the same handbook in a people/ folder, built from your tailored policies instead, so each rule cites the statement written around your actual tools and team. More free documents are on the templates page.

Start in the generator, then come back here to download your handbook.

Frequently asked questions

Does SOC 2 require an employee handbook?: No. No criterion names one. CC2.2 expects the company to communicate security responsibilities to its people, and CC1.4 expects it to develop their competence, so the auditor will ask how people learn the rules that apply to them and may ask employees about them. Policies, training and signed acknowledgments are the usual evidence. A short handbook makes the communication part easier to do and easier to show, because people actually read it.
Can the handbook replace the policies?: No. It restates the rules from the policies that apply to everyone, in plain language, and points back to each policy statement. The policies stay the full text with owners, procedures and exceptions. If a rule in the handbook ever reads differently from its policy, fix one of them: the handbook should never require something the policy does not, or leave out something the policy requires of everyone.
Why is every rule followed by a reference like (P04 4.5)?: So each rule can be traced. P04 4.5 means statement 4.5 of policy P04, the Authentication and Password Policy. The Markdown version ends with a table that quotes the policy text behind every rule. The handbook never adds a rule the policies do not contain: when a policy has no statement on a topic, that rule is left out.
Does signing the handbook replace the policy acknowledgment?: No. The acknowledgment page at the end confirms that the person received and read the handbook. Your Information Security Policy asks everyone to acknowledge it and the Acceptable Use Policy in writing, and the policy acknowledgment form is the record for that. Many teams collect both at onboarding, on the same day as the security awareness training.
Who should get the engineering section?: Anyone who writes code, changes infrastructure or deploys to production, including contractors. It is marked as engineers only, so everyone else can skip it. It is not on the 10 rules page.
What does the Audit Kit version add?: The free handbook is built from the policy template text rendered from your answers. In the Audit Kit, the policies are tailored to your tools and team first, and people/security-handbook.docx and people/security-handbook.md are built from those tailored statements, with the generation date and intake reference in the footer.
Is anything uploaded?: No. The generator keeps your answers in this browser's local storage, the policies are rendered here, and the Word and Markdown files are built on your device. With no saved answers the page shows the sample company, Northwind Cloud Inc.

Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.