An onboarding security checklist is a single short document that lists every account, device and permission a new person receives, who approved each one, what they were told and signed, and where that record is filed. It works best as one page with four columns: the item, the approver, the date it was granted, and the initials of whoever did the granting. The point is not the length of the list but that the same list gets used for every hire and ends up in a folder you can find later.
This article is general information about process and recordkeeping. It is not legal, employment, compliance or security advice. Anything that touches employment terms, what an employee agrees to as a condition of work, or what may be monitored belongs with an employment attorney and your organization’s HR advisors. Which obligations apply to you varies by organization, industry and jurisdiction, so treat the structure below as a starting shape rather than a requirement.
What belongs on an onboarding security checklist
Keep the checklist to things that are granted, handed over, or acknowledged. Anything else is a different document.
Group the items into four blocks so the list reads quickly:
- Identity. The primary work account, the second factor enrolled on it, and group or role membership.
- Applications. Each system the role needs, named individually rather than as “the usual set.”
- Equipment. Laptop or desktop with its asset tag, phone if issued, badge or key, and any removable storage.
- Acknowledgments. The acceptable use document, the confidentiality terms, and the route for reporting a concern.
Resist the urge to write a checklist for every role at once. Write one for the most common role, use it twice, then copy it and adjust for the next role. A checklist built from two real hires is more accurate than one built from a planning session.
Decide what gets granted on day one
The useful discipline here is deciding in advance what a role gets by default and what has to be asked for separately. Without that split, every new hire becomes a negotiation and the record of why someone has a permission disappears.
Write a short role profile for each job title you hire into. It names the default set: the accounts, the groups, and the applications that come automatically with the role. Everything outside the default set is a separate request with its own approver.
A worked order of operations for the first day looks like this:
- Create the primary work account and require second-factor enrollment before anything else is attached to it.
- Add the person to the role’s default groups rather than granting permissions one at a time, so the grant is reproducible and reviewable later.
- Issue the equipment and write the asset tag on the checklist next to the person’s name.
- Grant the applications in the default set, one line per application.
- Walk through the acknowledgments and capture the signature or the click.
- File the completed sheet and note the date it was completed.
Two habits make this hold up. First, grant through roles and groups wherever the system allows it, because an individual exception is invisible six months later. Second, when someone genuinely needs something outside the default set, record the reason in one sentence on the sheet. That sentence is what makes a later access review possible instead of guesswork.
Who approves each item on the onboarding security checklist
Every item needs a named approver, and the approver should be a role rather than a person, so the process survives turnover. One approver per item is enough. Two approvals on a routine account slow the process without adding anything to the record.
| Item type | Who approves | What gets recorded |
|---|---|---|
| Primary work account | Hiring manager | Approval date, account name |
| Default role groups | Hiring manager | Role profile version used |
| Application in the default set | Hiring manager | Application name, date |
| Application outside the default set | System owner for that application | Reason in one sentence, date |
| Elevated or administrative permission | System owner plus the person’s manager | Reason, date, intended duration |
| Equipment and badge | Whoever holds the inventory | Asset tag, serial, date issued |
The one row that deserves extra care is elevated permissions. If a new person needs administrative rights on day one, write down what they are for and how long they are expected to last. An administrative grant with no stated duration is the item most likely to still be sitting there years later with nobody able to say why.
What the new person is told and signs
Keep this short and in plain sentences. The goal is that the person can describe, on their first afternoon, what they are responsible for and who to contact if something looks wrong.
Cover four things:
- What the equipment and accounts are for, and that they are issued to them individually rather than shared.
- Where the acceptable use document lives and that they are asked to acknowledge it.
- The named route for reporting a security concern, and that reporting early is always the right move.
- Who their manager is for access questions and who the system owners are for the applications they use.
Capture the acknowledgment in whatever form you already use. A signature on a paper page, a typed name in a form, or a dated click in a system are all acceptable records as long as the date and the version of the document are both captured. Version matters more than people expect: an acknowledgment of a document you have since rewritten only tells you what they agreed to then.
Anything in this conversation that shades into employment terms, conduct expectations with consequences attached, or what the organization may look at on an issued device should be drafted with an employment attorney and your HR advisors rather than assembled from a checklist.
The record you keep
One completed sheet per hire, stored where you can retrieve it by name and date. That is the whole requirement.
What makes the record useful later:
- The person’s name, start date, and role profile version.
- One line per granted item, with approver, date, and who performed the grant.
- The asset tags of anything physical that was issued.
- The acknowledgment date and the version of each document acknowledged.
- A completion date and the initials of whoever closed the sheet.
Store the sheets together rather than scattered in individual personnel files, because the questions you will actually ask are cross-cutting: who has access to this application, when was it granted, and on whose approval. A single folder of completed sheets answers those in minutes.
The benefit here is clarity and retrievability, not protection. A good record means you can say what was granted and when, which is what you need when you are reconciling an access list, closing out a departure, or explaining a permission to a customer who asks.
Keeping the onboarding security checklist current
Review the checklist and the role profiles on a fixed cadence, twice a year is a reasonable rhythm, and also whenever one of three things happens: you adopt or retire an application, you create a new role, or a hire exposes a step the sheet did not cover.
The cheapest source of improvement is the hire that just happened. Ask the manager and the new person one question each. The manager: was anything missing on day one. The new person: was anything on your sheet you have never used. The first question finds gaps, the second finds default permissions that should not be defaults.
Keep superseded versions of the checklist rather than overwriting them, and put a version number and a review date on the sheet itself. An undated checklist cannot be matched to the acknowledgments that reference it.
Build the first version from your next hire rather than from scratch. One real completed sheet, with real approvers named and real dates on it, gives you a better template than any amount of planning, and the second hire is where the process starts feeling routine. For a worked one-page template and the companion departure list, see the Free Resources page on this site.