Onboarding documents: what to include, where each lives

Onboarding documents in two halves — the HR forms your HRIS handles, the role docs your wiki carries, and what makes either set actually get read in week one.

The Editorial Raccoon
A tidy desk set up for a new employee's first day, with a coffee cup, a plant, and a notebook ready to go

TL;DR. Onboarding documents come in two halves. The legal half — offer letter, I-9, W-4, direct deposit, handbook acknowledgement — lives in your HRIS and gets signed once. The role half — who-does-what, the runbook, the glossary, the 90-day expectations, the first-PR walkthrough — lives in your wiki and gets re-opened in week six. Most lists you’ve read are just the legal half; the half that actually decides whether the new hire stays is the other one.

Every list of essential onboarding documents you’ll find online is half a list. The half that’s there is the legal half — the forms a new hire has to sign before payroll can cut a cheque. That half matters. It’s also the easy half: your HRIS already knows what to ask for. The half nobody links is the role half — the documents that answer the questions a new hire actually has on Tuesday, the ones their manager keeps re-explaining because nobody wrote them down. This post covers both, and tells you where each one lives.

What onboarding documents are, in two halves

An onboarding document is anything a new hire reads, signs, or refers to in their first ninety days. That’s the loose definition. The tighter one — the one that makes the rest of this post useful — is that there are two distinct categories with two different homes:

  • Legal / HR documents are the forms and policies the company is required (or strongly advised) to collect. They’re signed once, filed, and rarely re-opened. Examples: the W-4, the I-9, the offer letter, the NDA, the handbook acknowledgement.
  • Role / team documents are the pages the new hire opens in week one and re-opens in week six. They’re never finished and they get edited by the team they describe. Examples: the team’s working agreement, the service runbook, the glossary, the 90-day expectations, the here’s our first-PR walkthrough page.

The mistake most onboarding rollouts make is treating both sets the same way — putting them all in the same shared drive, all in the same PDF stack, all expecting to be signed and filed. The legal half does fine in that shape. The role half goes stale on Tuesday and the new hire never opens it again.

Where each set lives matters as much as what’s in it.

These are the documents a new hire needs before they start (or in the first three business days, in the case of the I-9). Most of them are forms; most of them get signed once. A modern HRIS (Gusto, Rippling, BambooHR, Workday, Justworks) will handle the request-and-collect flow for the whole list below. If you don’t have one, an HR-flavoured folder in your Drive or wiki works — provided the folder is the canonical place and the new hire isn’t being asked to dig through emails.

A complete legal half typically includes:

  • The offer letter. Job title, start date, salary or hourly rate, manager name, any signing bonus, the at-will-employment language (US). Signed before the start date.
  • The employment contract or PIIA. A separate document in some companies, baked into the offer letter in others. Covers IP assignment, confidentiality, non-solicit (where legal).
  • Form I-9 (US only). Verifies eligibility to work in the US. Must be completed within three business days of the start date. The USCIS Form I-9 page is the authoritative source; don’t use a third-party paraphrase.
  • Form W-4 (US only). Tells payroll how much federal income tax to withhold. The IRS Form W-4 page is the source.
  • State tax withholding certificate (US only, where applicable). California’s DE-4, New York’s IT-2104, and so on.
  • Direct-deposit authorisation. Bank account, routing number, often a voided cheque. Signed once.
  • Benefits enrolment forms. Health insurance, dental, vision, 401(k), HSA / FSA, life. Usually due within 30 days of start.
  • Emergency contact information. Two contacts is the norm.
  • Handbook acknowledgement. Signature on a one-page acknowledgement saying the new hire has read the company handbook (the handbook itself is the next section — that’s the bridge into the role half).

Outside the US the legal half is roughly equivalent but the forms change. The UK has the right-to-work check; Canada has the TD1; most EU countries have a local equivalent of the tax form and the social-security registration. The shape holds: legal documents get signed once and filed; an HRIS or HR-folder is the right home.

What the legal half doesn’t do: tell the new hire how to do their job. Don’t expect it to.

The role half: what the wiki carries

This is the half no SEO-listicle ranks for, because it doesn’t fit a 14-item checklist. The role half is the set of pages that answer the questions a new hire is afraid to re-ask their manager about by Thursday of week one. The canonical pieces, drawn from a working internal knowledge base:

  • The team’s working agreement — how the team makes decisions, what done means, when standups happen, what urgent gets to mean. The team charter post walks through what to include and how to keep it from rotting.
  • The org mapwho works on what, who owns what, who to ask about X. A new hire shouldn’t be guessing at this for six weeks. A page with names, areas of ownership, and the names of the slack channels each name watches goes a very long way.
  • The glossary — every acronym the team throws around in the first standup. MTCB, ICP, the staging-staging environment, the Tuesday review. Nobody writes this until the second new hire complains; write it after the first.
  • The service runbooks — for every service the new hire will be on call for. See our how to write a runbook post for the shape. These are the most-opened pages in any on-call rotation; if the runbook is missing, the new hire pages the senior engineer instead.
  • The decision log — the why behind the we don’t use X anymore / we picked Y in 2024 because… questions a new hire will hit in week three. ADRs (architecture decision records) are the canonical form for engineering teams; the same shape works for any team that ever wants to remember a why.
  • The first-PR walkthrough (engineering) / the first-deck walkthrough (sales / marketing) — a literal here is your first task, here is what to do, here is who to ask if something breaks page. The single most load-bearing onboarding document a technical team can write.
  • The 30/60/90-day expectations for the role. Generic templates exist; the useful version is role-specific and written by the manager with the team, not by HR.
  • The handbook itself (the body of it, not the acknowledgement). Values, working norms, time-off policy, expense policy, the we don’t Slack on weekends paragraph that took two years to land. The acknowledgement is HR; the handbook is wiki.

The opinion this post stands behind: an onboarding document is scaffolding for a conversation, not a finished artefact. A role-half page that hasn’t been edited in nine months is a page nobody on the team trusts any more. Half the value of writing the runbook is the manager and the new hire reading it together in week one and correcting the two paragraphs that are now wrong.

What makes onboarding documents get read

The legal half is solved by required-to-progress — the new hire can’t get paid until they sign, so they sign. The role half has no such gate, so it loses by default unless the team builds it some. Five things make role-half documents actually get opened:

  • Named owners on every page. Maintained by Y on the platform team. When that name leaves the company, the page gets routed to a new owner the same day. An ownerless wiki page is a page nobody trusts.
  • Search that finds the right thing on the first try. A page is worth as much as your ability to find it on the Tuesday you need it. Sub-second loads, keyboard-first search, typo-tolerant by default — the internal knowledge base post goes deeper on why this is the load-bearing feature of any team’s wiki.
  • A weekly walk-through with the new hire. Manager and new hire pick five pages together, read them out loud, flag what’s wrong, edit on the spot. Two weeks of this surfaces every page that’s gone stale.
  • A page-tree that matches the question shape. Day 1 / Week 1 / Month 1 / Quarter 1 as the top-level organisation beats all-onboarding-documents-in-one-folder. The new hire doesn’t search for “what should I read today,” they navigate to Day 1 and read the list.
  • Visible recency signals. A last updated 14 months ago badge on a page that should be quarterly is a useful shame. New hires read it; the team feels it; the page gets edited.

What doesn’t work, in our experience:

  • A PDF stack in a shared Drive that needs to be downloaded to read.
  • A wiki page list ordered alphabetically (the new hire doesn’t know the alphabet of your jargon yet).
  • A please read everything in this folder email from HR on the start date.
  • A new-hire buddy whose job is the onboarding documents. The buddy is a complement, not a substitute. If the buddy is the only path to the answer, the docs aren’t doing their job.

How to organise them: a working layout

A layout that we’ve watched work, in a small-to-mid technical team. The legal half stays in the HRIS; everything below lives in the wiki as a page tree.

Onboarding/
├── Before you start
│   ├── Offer letter and contract (linked from HRIS)
│   └── Day 1 logistics — laptop, badge, where to go
├── Day 1
│   ├── First-hour checklist
│   ├── Org map and who-does-what
│   ├── Glossary
│   └── Communication norms (slack channels, time zones)
├── Week 1
│   ├── Tour of the codebase / product / accounts
│   ├── First-PR walkthrough (engineering)
│   ├── First-deck walkthrough (sales / marketing)
│   ├── Team working agreement (linked to /blog/team-charter/)
│   └── Calendar of standing meetings
├── Month 1
│   ├── 30-day expectations (per-role)
│   ├── Service runbooks the new hire owns
│   ├── Decision log highlights
│   └── On-call shadow week
├── Quarter 1
│   ├── 60- and 90-day expectations
│   ├── First retro with the manager
│   └── Onboarding feedback — what was missing, what to fix
└── References
    ├── Handbook (body)
    ├── Benefits cheat-sheet
    └── Glossary (full)

The page tree above is the index. Each leaf is one page, maintained by one named owner, edited by the team that uses it. The page tree itself is the navigation; nobody is expected to search for Week 1 — they click it. The corporation wiki post goes deeper on why hierarchy is the friend of recall.

Raccoon Page is not an HRIS. We don’t collect W-4s, we don’t run payroll, we don’t store Social Security numbers. We’re the wiki the new hire opens on Tuesday morning to remember what MTCB means and the wiki the manager opens on Tuesday afternoon to update it. The HR half of the onboarding stack belongs in a real HRIS; the role half belongs in a wiki built for sub-second loads and keyboard-first search. The split is the post.

Things people actually ask

What are onboarding documents? Anything a new hire reads, signs, or refers to in their first ninety days. They split into a legal half (forms a company collects to comply with employment law and pay people correctly) and a role half (pages the team writes so the new hire can actually do their job). Most lists you’ll find online cover only the legal half.

What onboarding documents are legally required? In the US: Form I-9 (employment eligibility) within three business days of start, Form W-4 (federal withholding), the state withholding certificate where applicable, and any benefits enrolment paperwork the plan administrator requires. Outside the US the equivalents vary by country. The USCIS Form I-9 page is the source for I-9; the IRS Form W-4 page is the source for W-4.

What’s the difference between onboarding documents and an employee handbook? The handbook is one of the documents. It’s the company-wide policy and culture reference. Onboarding documents are the full set: handbook plus tax forms, plus role-specific pages like runbooks, decision logs, and 30/60/90-day expectations. The handbook lives in the wiki; the signed acknowledgement that the new hire read it lives in the HRIS.

Should onboarding documents live in HR software or a wiki? Both, but split by category. Forms that get signed once and filed (offer letter, tax forms, NDA, handbook acknowledgement) belong in HR software — an HRIS handles the collect, sign, file, audit flow. Documents that get edited by the team and re-opened weekly (runbooks, glossaries, working agreements, decision logs) belong in a wiki. Trying to make HR software hold the role half slows it down; trying to make the wiki collect signed I-9s creates a compliance problem.

Who should write onboarding documents? The team that uses them, with the manager as the editor. HR writes the legal half. The role half is written by the people doing the role — the engineer writes the runbook, the AE writes the deck-walkthrough, the manager writes the 30-day plan. A new hire who reads a runbook written by someone who hasn’t been on call in three years can tell.

How long should onboarding documents be? As long as they need to be and not a page longer. A runbook that fits on one screen gets read; one that needs a TOC gets skipped. A handbook can be ten pages if every page is load-bearing; if it’s forty pages with three of them load-bearing, cut the rest. The 30/60/90 day plan should fit on a single page.

How often should onboarding documents be updated? The role half: every time something in them is wrong. Practically, that means once per onboarding cycle (the new hire is the canary; if they had to re-ask a question, the doc was wrong). The legal half: when the law changes, when payroll changes, or when benefits-renewal happens.

Do small teams really need onboarding documents? Yes, but proportionally. A team of three hiring their first employee should have the legal half done correctly (an HRIS or HR provider handles it) and a one-page what to do this week role-half doc. That’s the entire investment. The trigger to invest more is the second hire — when the same questions get asked twice in three months, write them down.


If the role half of your onboarding stack currently lives in a Slack thread and the legal half lives in twelve emails, the wiki side is the half we can help with. Our Free tier is three users, one space, a hundred pages, no card — enough to write the Day 1 page and the first runbook and watch the new hire actually open them on Tuesday morning. The legal forms can stay where they are; we’re not coming for the I-9.

Written by The Editorial Raccoon — house style for Raccoon Page. Numbers and claims pulled from product reality; jokes pulled from the Raccoon Corp canon. No raccoons were quoted in real life.