IT Handover Checklist When the Only Administrator Leaves

An IT handover checklist is the difference between inheriting an operating system and inheriting a rumor. When the only administrator leaves, the immediate risk is not that the company has no tools. It is that nobody can say which systems matter, who owns each one, what renews next month, which accounts are privileged, where the evidence lives, or what process only worked because one person remembered it.

This checklist is written for the uncomfortable version of that situation: a lean company where one administrator, IT manager, MSP contact, or technical founder held most of the operating knowledge. Maybe they are leaving on good terms and you have two weeks. Maybe they already left and you have access to old spreadsheets, shared drives, finance records, and a stack of “ask Jamie” comments that no longer help.

The goal is not to create perfect documentation. The goal is to create a usable handover record that a new IT owner can operate from this week, improve next month, and show to leadership without pretending the unknowns are solved.

Quick answer: what an IT handover should preserve

A useful IT handover should preserve seven things. If you need the broader evidence framing behind this, start with what IT governance evidence means and then use the checklist below as the operating version.

If those seven areas are at least visible, the new IT owner has a map. If they are missing, the first month is archaeology.

The real problem is not documentation. It is operational memory.

Most handover checklists focus on folders, passwords, and diagrams. Those matter, but they are not the whole problem. In lean IT teams, the most important facts often live in a person's habits:

• which vendor must be chased before the official renewal date;
• which admin account is only used when the SSO integration breaks;
• which SaaS tool finance pays for but IT supports;
• which shared mailbox belongs to a process, not a person;
• which laptop was returned but never marked spare;
• which access review was “done” but never signed off;
• which spreadsheet looks complete but stopped being updated six months ago.

That knowledge is operational memory. It is useful while the person is present and fragile the moment they leave. A handover checklist should turn that memory into records: dated, scoped, owned, and specific enough that another person can continue the routine.

Do not confuse that with writing a novel about the IT environment. A 70-page document that nobody can maintain is another form of risk. The stronger move is a small set of registers and checklists that answer repeated questions: what exists, who owns it, when it renews, who has access, what was reviewed, and what remains open.

First 24 hours: stabilize before you document everything

If the administrator already left, resist the urge to clean everything at once. The first day is about stabilizing control and reducing blind spots.

Start with five checks.

1. Confirm authorized admin access. Identify who has approved access to identity, email, finance, domain/hosting, core SaaS, MDM or endpoint tools, password manager, ticketing, and backups. Do this through the company's approved process. Do not ask for personal passwords, shared credentials, or secrets in chat.
2. Freeze risky informal changes. Tell managers and vendors that IT ownership is changing and that new subscriptions, access changes, or cancellations should route through one named owner until the handover is complete.
3. List critical systems first. Email, identity, finance, payroll, customer support, CRM, website, hosting, domains, backups, security tools, and the password manager should come before nice-to-have software.
4. Find the next deadlines. Renewals, certificate/domain expiries, vendor notice deadlines, insurance/security questionnaire dates, audits, client reviews, and staff departures create time pressure.
5. Record unknowns openly. A handover record that says “unknown owner” or “renewal date not confirmed” is more honest than a clean table with blank fields hidden from view.

This is also the point to set the tone with leadership. A useful message is: “We are not claiming everything is clean today. We are building the operating record so we know what is owned, what is unknown, and what needs decision before it becomes an incident.”

The systems catalog: the spine of the handover

The handover starts to become usable when systems are named consistently. A systems catalog does not need to be complicated. For each system, record:

• system name;
• business purpose;
• category, such as identity, finance, HR, support, website, backup, security, communications, developer tooling, or client platform;
• business owner;
• technical owner;
• criticality;
• lifecycle status: active, retiring, retired, or unknown;
• admin URL or support URL;
• vendor/provider;
• recovery or support contact note;
• whether the system belongs in access reviews;
• last reviewed date.

The catalog prevents a common failure: the new IT owner starts with accounts, assets, and vendors but cannot tell which records refer to the same system. “Google,” “Workspace,” “Gmail,” and “Email” become four labels for one platform. “CRM,” “Salesforce,” and “Sales” drift apart. A catalog gives the team one naming backbone.

The catalog also exposes decision work. A critical system with no business owner is not just a documentation gap. It is a management problem. A retired system still included in access reviews is stale process. A system with no technical owner is a future incident waiting for the next support ticket.

Privileged access: make the exceptions impossible to ignore

When a sole administrator leaves, privileged access is the highest-trust part of the handover. Do not treat it as a simple list of usernames. A useful privileged-access handover should answer:

• Which systems have admin, owner, super-admin, billing-admin, or break-glass roles?
• Which named people hold those roles today?
• Which accounts are shared, service, vendor, contractor, or emergency accounts?
• Which privileged accounts belonged to the departing administrator?
• Which accounts were removed, changed, transferred, or retained?
• Who reviewed the privileged-access list and when?
• What still requires action in the underlying systems?

The important distinction: a handover record does not remove access. The operational change happens in the source system — the identity provider, SaaS admin console, hosting account, vendor portal, or password manager. The handover record proves what was checked, what was decided, and what remains open.

For a lean team, the minimum acceptable output is a dated privileged-access review table with four decision states: keep, change, remove, or action required. Anything marked action required needs an owner and date. “We'll look at it later” is not a state.

Vendors and renewals: the quiet handover risk

Surprise renewals are one of the most common ways a bad handover becomes expensive. The outgoing administrator may know which tools auto-renew, which vendors require 60 days' notice, which contracts finance owns, and which account is billed to a card in a founder's name. If that knowledge is not transferred, the new IT owner inherits a calendar full of traps.

For every recurring vendor or subscription, record:

• vendor and service name;
• business purpose;
• business owner;
• technical owner;
• renewal date;
• notice deadline;
• auto-renewal state;
• current cost or cost reference, where appropriate;
• payment or finance owner;
• contract/account location reference, not the contract text pasted everywhere;
• decision status: renew, cancel, downgrade, review, undecided;
• decision note;
• last reviewed date;
• next action.

The key is the notice deadline. A renewal date tells you when the vendor charges or the term changes. The notice deadline tells you when the decision must be made. In a handover, the notice deadline is usually the more urgent field.

Treat unknown renewal records as work, not clutter. A subscription with no owner and a renewal date within 90 days belongs at the top of the queue. A high-cost tool with auto-renewal enabled and no decision note is not “fine.” It is a decision that has not happened yet. The deeper field pattern is covered in the SaaS renewal tracker template and the renewal date vs notice deadline guide.

People, accounts, and leavers: rebuild the current population

A handover record is weak if the people list is stale. Before running access reviews or assigning assets, confirm the population:

• active employees;
• contractors;
• service providers or vendors with accounts;
• people marked offboarding;
• people marked left;
• shared or service accounts with responsible owners;
• accounts with unknown owner.

This is where many inherited IT environments show their age. A current HR list says who works here, but it may not say which systems they can access. A SaaS export says who has an account, but it may not say whether the person still works here. A spreadsheet says someone owns a tool, but it may not show whether they left last quarter.

The handover job is to connect those facts. If a person is marked left, their accounts and assets should become visible follow-up. If a contractor has an end date, their access should not drift past it. If a shared account has no named responsible owner, give it one before the next review cycle.

For the account-side routine, pair this with account ownership tracking. For the leaver evidence layer, use the employee offboarding evidence checklist so the handover records what changed rather than only who remembered it.

Avoid turning this into HR documentation. Record the fields needed for IT governance: name, work identifier, role/team, status, start/end dates where relevant, account identifiers, account status, and notes required for access or asset follow-up. Do not copy performance notes, compensation, personal reasons for departure, or private HR detail into the IT handover.

Assets: answer “what do they have?” without a hunt

When the only administrator leaves, asset records are often scattered across purchase invoices, device-management tools, spreadsheets, shipping emails, and someone's memory. The handover should produce a working asset register, not a perfect CMDB.

For hardware, capture:

• asset tag or identifier;
• serial or service tag;
• asset type;
• assigned person or responsible owner;
• department;
• location/site or remote custody label;
• status: active, spare, repair, retired, lost, or unknown;
• purchase date or invoice reference where available;
• last reviewed date;
• short exception note.

For software assets, capture:

• software name;
• vendor;
• owner;
• license type;
• license status: active, expired, replaced, unassigned, or cancelled;
• renewal date where relevant;
• safe key reference: key present yes/no and a masked hint only;
• linked hardware or assigned person where useful.

The fastest useful asset handover is not “find every detail.” It is “make the high-risk gaps visible.” Devices assigned to people who left, active assets with no owner, lost items with no note, and software licenses with no renewal date are the records that deserve attention first. For the asset-side cleanup path, use how to rebuild an IT asset inventory when records are missing or stale. If the handover includes a leaver's laptops, phones, monitors, or software seats, run the employee equipment return checklist alongside the asset cleanup.

Access review evidence: preserve the process, not just today's export

A current access export is not the same as access review evidence. An export shows a point-in-time list of users and permissions. It usually does not show who reviewed it, what decisions were made, what exceptions were found, or whether anything changed afterward.

During handover, ask for:

• last completed access review date;
• review period and cadence;
• systems in scope;
• systems out of scope;
• reviewer or approver;
• population reviewed;
• decisions recorded: keep, change, remove, action required;
• open exceptions;
• next due date;
• exported report or fixed evidence artifact.

If no completed review exists, do not backfill one as if it happened. Start a new review from the current state and document the gap honestly: “No prior completed access review evidence was retained. Current register rebuilt from exports and reviewed from this date forward.” That is much stronger than creating retroactive paperwork nobody can defend.

Questions to ask the outgoing administrator

If the outgoing administrator is still available, use the time well. Do not spend the whole meeting on tool tours. Ask questions that reveal hidden operating rules:

1. Which systems would break the business if they were unavailable tomorrow?
2. Which vendors require notice before renewal or cancellation?
3. Which admin accounts are used only during incidents?
4. Which shared or service accounts exist, and who is responsible for them?
5. Which systems are being retired but still have accounts or data?
6. Which tools are paid by finance but supported by IT?
7. Which laptops, phones, or spares are assigned informally?
8. Which recurring report, audit, customer questionnaire, or management review is coming next?
9. Which spreadsheets are authoritative, and which are old copies?
10. What would you check first if you were me next Monday?

The last question is often the most valuable. Experienced administrators know where the bodies are buried. The handover should capture those risks as visible follow-up, not as hallway advice.

A 30-day rescue plan for the new IT owner

If the handover is already messy, use a staged plan.

Days 1-3: control and deadlines. Confirm authorized admin access, lock down ownership of changes, find critical systems, list urgent renewals and departures, and identify privileged access.

Days 4-10: build the operating map. Create the systems catalog, import or draft vendor/renewal records, rebuild active people and leavers, and list hardware/software assets from the highest-confidence sources.

Days 11-20: work exceptions. Prioritize ownerless systems, privileged access, leaver accounts, upcoming renewals, missing notice deadlines, lost/unknown assets, and critical systems with no reviewer.

Days 21-30: produce the first evidence artifact. Summarize what is known, what is unknown, what changed, and what remains open. Leadership does not need a heroic cleanup story. They need a clear operating picture.

A plain report might say: “We identified 42 systems, 11 critical systems, 8 owner gaps, 6 renewal decisions due within 90 days, 3 leaver-linked account exceptions, and 14 asset records needing owner/location cleanup. Owners and dates have been assigned for the first remediation pass.” That is credible because it names the mess instead of hiding it.

What not to put in the handover record

A handover file can become dangerous if it turns into a dumping ground. Keep these out:

• passwords;
• recovery codes;
• API keys;
• full product keys;
• OAuth secrets;
• payment-card numbers;
• private HR details;
• employee activity or productivity notes;
• email, document, chat, or file content;
• legal conclusions about contracts or compliance.

Use references instead: password-manager item name, finance file reference, vendor portal URL, contract location label, or support contact. The record should tell the new owner where to act, not expose the sensitive material itself.

How CertPilot fits, with the right boundaries

CertPilot can support this kind of handover because its live Phase A product is built around checks, registers, and evidence reports. A lean team can maintain a Systems Catalog, Renewals & Vendor Register, People & Accounts register, Assets Register, Access Reviews, and on-demand evidence reports from the same operating record.

That makes it useful after the first rescue pass: the handover stops being a one-off document and becomes a maintained routine. The new IT owner can keep systems named, renewals owned, assets assigned, leavers visible, access reviews completed, and management summaries exportable.

The boundaries matter. CertPilot does not discover SaaS automatically, sync Google Workspace or Microsoft 365 today, perform offboarding, remove access, manage devices, ship equipment, store secrets, certify compliance, or guarantee audit outcomes. It records the evidence your team maintains and packages it for operational and management review.

In short

• An IT handover checklist should transfer operating control, not just documents.
• The seven core areas are systems, privileged access, vendors/renewals, people/accounts, assets, access review evidence, and report history.
• Unknowns should be visible and owned, not hidden in a clean-looking spreadsheet.
• The first 30 days should stabilize access, build the map, work exceptions, and produce a dated evidence summary.
• Keep secrets, personal HR detail, and activity data out of the handover record.
• CertPilot can help maintain the registers and reports after the handover, but it does not automate discovery, deprovisioning, device control, or compliance certification.

Frequently Asked Questions

What should an IT handover include when the only administrator leaves?

It should include the systems catalog, privileged-access list, vendor and renewal records, people and account status, hardware and software assets, access review evidence, report history, urgent deadlines, and open risks. The most useful handover is not the longest document; it is the record that lets the next owner operate without guessing.

Should passwords be included in an IT handover checklist?

No. Passwords, API keys, recovery codes, OAuth secrets, and full product keys should not be pasted into the handover record. The checklist should reference the approved password manager, vault item, vendor portal, or secure storage location. The sensitive value stays in the system designed to protect it.

What if the administrator already left and there is no handover?

Start with stabilization: confirm authorized admin access, list critical systems, find upcoming deadlines, identify privileged accounts, and record unknowns. Then rebuild the systems, renewal, people/account, asset, and access-review records from finance exports, admin consoles, existing spreadsheets, tickets, and manager interviews. Do not pretend a historical review happened if no evidence exists.

How long should the handover take?

A clean handover may be possible in two weeks if the outgoing administrator is available. A messy inherited environment should be treated as a 30-day rescue project: first control and deadlines, then the operating map, then exceptions, then the first management-ready evidence summary.

Is an IT handover the same as an access review?

No. An access review is one part of the handover. The handover transfers operating knowledge across systems, vendors, renewals, assets, people, accounts, and evidence history. Access review evidence proves who reviewed access, when, what was decided, and what remains open.

Can CertPilot automatically discover everything for the handover?

No. CertPilot is manual-first for these registers today. Your team enters or imports records and runs the review process. CertPilot helps keep the operating evidence structured and reportable; it does not discover SaaS, sync directories, remove access, monitor employees, control devices, or certify compliance.