Contractor security onboarding checklist for small teams: your freelancer is a new hire you forgot to onboard

Small teams onboard external people constantly — a designer for the rebrand, a contractor for the migration sprint, a part-time bookkeeper, a dev shop for the app — and almost never onboard them as security decisions. The employee gets an orientation day; the freelancer gets a Slack invite and the wifi password. Three weeks later that person holds accounts, seats, and secrets that nobody inventoried, and when the engagement ends, half of it stays behind. This checklist is the fifteen-minute version of doing it right: scope the access, route the secrets through the password manager, write the security clause, stamp every grant with an end date, and run the revocation with the same discipline you'd use for a full-time employee offboarding.

1. Before day one: the decision that gates everything else

• Decide what the contractor needs, not what they'll ask for. Write one sentence before any account is created: "Contractor needs read access to the design repo and a Figma seat to ship the new pricing pages." Every account, seat, and secret either serves that sentence or waits until the sentence changes. This is the contractor version of the scoping you already do for a vendor security review — same reflex, smaller scale.
• Create accounts, not credential-sharing. The one-account-everyone-shares pattern (the shared login to the staging box, the agency account on the ad platform) is the root of most contractor mess: no attribution, no revocation, no expiry. Every external person gets their own named account with their own email, and shared systems get handled through shared vaults and groups instead.
• Put the end date in the plan before the work starts. The engagement has a last day; write it down where the access lives — a note next to the grant list, a calendar event, a line in the contract. Access without an end date is how a 2024 migration contractor still has a production read token in 2026.
• Pick the single person who owns the relationship. One internal owner approves every grant and runs the final revocation. When three people each hand the contractor "a few things," nobody knows what the full set is.

2. The accounts (create these, exactly these)

• One identity email, MFA-backed, owned by the contractor but linked to your recovery. The account's email should be the contractor's real working address (not a plus-alias on your domain that dies with their contract), and the underlying account should have MFA turned on before it touches anything. If your plan supports group-based MFA enforcement, put contractors in the same enforcement group as employees — exceptions breed weaker accounts.
• Least-privileged seats only. Contractor tier in Slack (guest, not member), read-only where the tool supports it (repo viewers, analytics viewers, staging viewers), and no billing or admin screens. If the tool's free tier makes you pay per seat, that's a scoping question, not a reason to share your account.
• A shared vault for shared secrets, never a shared password. Tools the contractor genuinely shares (staging credentials, service dashboards) go in a shared collection in your password manager, with the contractor as a named member. You can revoke the membership; you can't revoke a password that was pasted into a chat. This is the same discipline as the secrets rotation checklist — shared secrets are secrets, wherever they land.
• Mark every contractor account at creation time. Same convention as the Slack guest labels: the role note, the engagement name, and the end date go into the account's display name or profile field. Accounts that are visibly "contractor / rebrand / ends Mar 14" get cleaned up; anonymous accounts persist forever.

3. Scope like a vendor, not a teammate

• Split the tool inventory into "grant," "share," and "never." Grant: named accounts with least privilege. Share: read-only exports, screen-share walkthroughs, a PDF of the data they need. Never: the production admin panel, the billing console, the DNS registrar, the email workspace admin. A contractor who says "I just need admin for a second" is telling you they haven't scoped their own work — help them scope it.
• Repo access follows the branch model, not the org model. External people get a fork or a scoped project with read on what they need and write on what they ship, reviewed through PRs. Direct push to your main branch from an outside account is a repository hygiene violation, not a speed optimization.
• Chat access is a channel list, not the org chart. A single-channel guest in the project channel sees what the project needs. A full member sees #leadership, #payroll-oops, and the layoff thread — the same reasoning the Slack checklist applies to single-channel guests, applied before they join instead of after.
• Production is a milestone, not a default. The contractor access ladder: local sandbox → staging → production read → production write, and each step is a decision somebody makes when the work earns it — not a bucket of credentials handed over on day one to save a ticket.

4. The secrets you hand over (and how)

• Everything through the vault, nothing through chat. Credentials, tokens, and config values live in the shared vault collection. Slack DMs, email, and (worst of all) the contract PDF are distribution channels that keep copies forever — a leaked secret in a contract attachment behaves exactly like the chat-leaked keys the API key leak runbook handles.
• Issue per-purpose secrets where the system allows it. A contractor deploy key, a contractor analytics token, a contractor database user. Named credentials can be rotated and revoked individually; the shared production password can only be changed globally — which is why it ends up being changed never.
• Write down what was issued, to whom, and when. The grant log is five lines: secret name, contractor, issued date, expiry date, vault location. This is also your rotation map — at the end of the engagement, the log is the list of things to rotate.
• Rotate on the calendar, not on suspicion. Long engagements get periodic rotations of anything the contractor holds: staging passwords, shared vault contents, any legacy credential they needed once in week two. The rotation cadence you run internally extends to them without drama if the log already exists.

5. The paper trail (cheap now, priceless later)

• One security clause, in every contractor agreement. Plain sentences: access is limited to the listed systems; secrets may not be shared, pasted, or stored outside agreed tools; data may not be copied to personal devices or personal cloud accounts; access is revoked at engagement end; the contractor reports suspected compromise within 24 hours. Ten lines. You don't need a lawyer to draft it; you need it to exist before the dispute.
• Data return and deletion, written down. At the end, the contractor confirms: working files returned, copies deleted (including local copies and personal cloud sync), credentials no longer held. For anything touching customer data this is the same clause a real vendor review demands — contractors are vendors with fewer lawyers.
• An acceptable-use line beats an acceptable-use policy. Contractors don't read your 14-page policy. One paragraph in the engagement message: what systems, what data, what's forbidden, who to call. The 14-page policy can stay for the enterprise deal.
• Re-verify identity channels on day one. The person you're granting access to should be the person you signed the contract with. One video call, one confirmed email domain, and a rule that future credential sharing happens in the vault — not in a reply to a friendly "can you resend the staging password" email that came from a lookalike domain. This is basic phishing hygiene aimed at the grant instead of the inbox.

6. Machines and networks (their laptop is your new office)

• One laptop policy sentence, not a fleet audit. The clause: "Work happens on a machine with current OS updates, a screen lock, and disk encryption. If you can't meet that, ask before accepting the engagement." Full remote-work requirements for a three-week engagement is overkill; "updated, encrypted, locked" is not.
• Route through your perimeter where the data is sensitive. Anything touching production, customer data, or internal repos goes through your VPN or gateway so access logs exist on your side. If you don't have a VPN, at minimum enable tool-level audit logs for every contractor-facing system — "who viewed what when" is the minimum forensic floor.
• Browsers count. The contractor's browser holds your webmail, your staging dashboards, your cloud console. Their extension hygiene is now your login-session risk. The one-line ask: "No extensions with all-site access while working in our systems." You're not auditing their laptop; you're setting the conditions of yours.
• Never grant from your own session. The classic mistake: the founder, logged in as themselves on a call, "quickly adds" the contractor to the billing console because permissions take a ticket. If a grant can't survive your own access-request process, it shouldn't survive the call. The access request checklist applies to contractors verbatim.

7. The audit trail (what your future self needs)

• Keep the grant log with the contract. Contract, grant log, security clause, end date — one folder per engagement. When someone asks "what does the migration contractor still have access to?", the answer takes ninety seconds instead of an afternoon of audit archaeology.
• Calendar the mid-engagement review. Engagements over six weeks get one fifteen-minute check: accounts still needed? secrets still current? end date still correct? scope creep is real, and it enters through permissions.
• Log access on your side too. Every system the contractor touches should produce a log line you can read later: SSO logs, repo audit, workspace member history. If your stack can't log contractor activity at all, that's a finding, not an excuse.
• Treat an ownership change like a new engagement. The dev shop assigns a new person to your account mid-project. That's not a handoff note; that's a fresh grant: new account, new vault membership, and the old person's access is revoked the day their name comes off the project. Account access follows people, not companies.

8. The end date (revocation day is part of onboarding)

• Run the same offboarding you'd run for an employee, in half the time. Deactivate accounts (not delete — audit trails), remove vault membership, remove repo and tool seats, revoke sessions, remove the wifi/network identity, and confirm app or bot tokens they created are also revoked. The offboarding checklist is the master list; this is its contractor pass.
• Rotate everything shared. Any credential that existed in the shared vault, any contractor-named token, and any legacy secret they touched gets rotated on the last day. Shared secrets that "weren't changed because they'd break the CI job" are exactly how ex-contractor access survives a year.
• Get the return confirmation in writing. One email: files returned, copies deleted, accounts surrendered. It takes them two minutes to confirm and gives you the audit line you'll want if the relationship ever turns litigious.
• Check the residue a week later. One pass through your tools searching for the contractor's email address and name. The stragglers — the analytics invite, the board seat, the support-desk agent they created — show up only when you look. This is the same residue hunt the SaaS audit does for orphan subscriptions.

9. Production, sensibly

• If production access is unavoidable, make it boring. Named account, least-privileged role, changes through PRs, deploy windows you choose, and a second pair of eyes for anything destructive. The goal isn't zero contractor production access; it's contractor production access that looks exactly like a junior employee's.
• Pre-agree the break-glass. "If you need production access tonight, message this person and we'll grant it together in ten minutes." Emergency grants happen — the failure is an emergency grant nobody wrote down. Log it like everything else, rotate it like everything else.
• Watch the tokens, not just the logins. Contractors ship code that holds tokens: CI variables, deploy keys, webhook URLs, analytics snippets. When the engagement ends, tokens in CI pipelines die with a rotation — which is why the grant log lists them. A webhook URL pasted into their Zapier account is a live bearer credential nobody's thinking about.
• Aggregate access gets vendor treatment. A dev shop with five staff, a shared CI, and its own secrets vault is no longer a contractor; it's a vendor. That's the moment you run the full vendor security review and stop pretending a checklist for freelancers covers it.

10. When something goes wrong anyway

• Suspected compromise: revoke first, investigate second. End the contractor's sessions and rotate what they held immediately — the first-24-hours rule doesn't care whose account it was.
• Scope creep discovered: revoke to the documented scope the same day, then re-decide what you actually meant to allow. Quiet creep reversed slowly is how six-month "temporary" grants become permanent infrastructure.
• Contractor left with copies: rotate every credential, revoke everything, demand the written deletion confirmation, and document your timeline from the first message. Legal remedies are a lawyer question; containment is your question, and it starts now.
• Not sure what they still hold: assume the worst set. The cost of rotating five secrets is an hour; the cost of a stale contractor credential on a production deploy key is unbounded.

Contractor security in a small team is one page: the scoping sentence, named accounts, vault-routed secrets, the ten-line clause, expiry dates, and a revocation day that actually happens. The Ops Starter Kit ($14) includes the access-audit sheets that turn this into a per-engagement table — account, scope, issued, expiry, owner — and the Automation Starter Pack ($19) automates the expiry checks so grants end when the contract says they end. Launch week: 30% off any paid kit with code HIVE-LAUNCH30 at checkout.