Background checks for IT hires: what to run and why

Think about what your IT hire touches on day one: the password vault, the domain admin account, email for the whole company, the backups, the payroll system's database. Most employees can hurt you in one lane. An IT person with privileged access can hurt you in all of them at once, quietly, with the logs edited afterward. That's why background checks on IT hires aren't HR box-checking. They're access control. Standard caveat, once: we staff IT people, we're not lawyers, and screening laws vary by state and city. Have counsel or your background check provider confirm what's legal where you hire.

Checks that actually matter for privileged access

Run these on anyone getting admin rights, and use a proper consumer reporting agency, not a $19.99 instant-search website. Cheap database searches miss records and return wrong-person matches, and neither failure is one you want on the person holding your passwords.

• Identity verification. Confirm the person is who they say they are, with SSN trace to surface the counties and names to actually search. This sounds basic. It has stopped being basic: fully fabricated candidates, including remote hires who aren't the person who interviewed, are now a real problem in IT hiring. For remote roles, verify identity on camera against a government ID at some point before day one.
• County criminal searches in the places they've actually lived, plus a national database search as a pointer. What you care about for IT roles specifically: fraud, theft, and computer crimes. A ten-year-old possession charge tells you nothing about whether someone should hold domain admin. A wire fraud conviction does.
• Employment verification. Did they actually hold the jobs on the resume, with roughly those dates and titles? Resume inflation is rampant in IT because titles are unverifiable at a glance. You're not calling for opinions, you're confirming facts.
• Reference calls, done for real. Talk to a former manager or senior colleague and ask specifically: did this person have privileged access, and would you give it to them again? That second question gets honest pauses that generic reference questions never do.
• Credit check, but only where it fits. For roles with direct access to financial systems or payment data, a credit check can be relevant, and some compliance frameworks expect it. Several states restrict employment credit checks, so confirm legality first. For a help desk tech, skip it. It's theater at that level.

What's theater

Some checks feel rigorous and prove nothing. Degree verification for a 15-year infrastructure veteran tells you less than one hands-on screening exercise. Trawling personal social media mostly generates bias risk, not signal. And no background check verifies technical competence at all: a spotless record and a real diploma are fully compatible with not being able to do the job. Check the person's history for trustworthiness, and check their skills separately, with techs who can tell.

The other theater trap is treating the check as a substitute for controls. A clean background is a snapshot of the past. Least-privilege access, separate admin accounts, logging that the admin can't erase, and MFA everywhere protect you from the future, including from good people having bad years. Run the checks and build the controls.

Consent and consistency

Two rules keep you out of legal trouble, and they're both federal law under the Fair Credit Reporting Act when a background check company is involved. First, consent: you must disclose the check in a standalone document and get written authorization before running it. Burying it in the application doesn't count. If the results might cost the candidate the job, there's a required two-step adverse action process: give them the report and a chance to respond before you finalize the decision. Records are wrong more often than people think, and the person you almost rejected over someone else's record with a similar name will be glad you followed it.

Second, consistency: run the same checks for the same role, every time. Screening one candidate harder because of a hunch, a name, or an accent is how discrimination claims get written. Define the check package per role tier before you post the job: basic package for standard roles, enhanced package for privileged access, and then apply it mechanically. Also honor ban-the-box timing where it applies: many states and cities restrict when in the process you can ask about criminal history, which in practice means check late, after a conditional offer.

Same logic applies to contractors, by the way. If a staffing firm is placing a tech into a privileged role at your company, ask what screening their people get, and get it in writing. "They're not our employee" won't matter to you when it's your data.

How to know you've got it right

A sane IT screening program fits on one page: which checks run for which access tier, a compliant consent form, a consistent process, and a real screening provider behind it. Candidates get told up front, results come back in a few days, and nobody with domain admin skipped the process because the hire was urgent. That last one is the failure mode we see most: the check that gets waived is always for the emergency hire, and the emergency hire is exactly the one nobody vetted any other way either. Decide your process when calm. Follow it when rushed.