30-60-90 day plan for IT managers

A new IT manager usually inherits an environment nobody has fully documented: admin accounts shared by people who left, backups that report success but have never been restored, software licenses that auto-renew next month, and a ticket queue whose oldest items predate the last manager. A 30-60-90 day plan for an IT manager has to surface those risks quickly, keep the lights on while it does, and end with a plan the business understands and agrees to fund.

This page is for the operations leader, CFO or CTO writing the plan for an IT manager who runs internal IT: the service desk, end-user devices, identity, network, core business systems and the vendors behind them. For managers of product engineering teams, use the 30-60-90 day plan for engineering managers instead. For the general template, see the 30-60-90 day plan template for new hires.

What makes an IT manager's ramp different

Internal IT is judged mostly by what does not happen: no breach, no lost data, no week where nobody can log in. That makes the first 90 days unusually risk-driven. The new manager cannot fix what they have not found, and the most dangerous gaps, such as an unrestorable backup or an orphaned admin account, are invisible until the day they matter.

So the plan starts with an inventory and verification phase rather than a listening tour alone, and it asks for evidence, not assurances. "Backups are fine" is not a deliverable; a restore of a real system to a test location, timed and written up, is.

The 30-60-90 day plan

30-60-90 day plan — [Name], IT Manager, [company / site]
Reports to: [name]    Start date: [date]    Team: [N] staff, [MSP if any]
Ticketing: [e.g. ServiceNow / Jira Service Management / Freshservice]
Identity: [e.g. Entra ID / Okta / Google Workspace]
Device management: [e.g. Intune / Jamf / other]

DAYS 1-30 — Find out what exists and what is at risk
Goals:
- Transfer admin and break-glass credentials; list every privileged
  account and who holds it; remove or document shared logins
- Build a systems inventory: business applications, servers and
  cloud accounts, network devices, owners, and where each is backed up
- Confirm when each critical backup was last restored, if ever
- Build a vendor and contract calendar: renewal dates, notice
  periods, license counts against actual users
- Pull a service desk baseline: volume by category, first response,
  time to resolve, backlog age
- One-on-one with every team member and with the main business
  users in finance, sales and operations
Deliverables by day 30:
- A risk register ranked by likelihood and impact, top 10 named
- The inventory, contract calendar and service desk baseline
Check-in: day 30

DAYS 31-60 — Close the urgent gaps and own the rhythm
Goals:
- Run a restore test on at least [1-2] critical systems, timed
- Close the top [3] risks that need no new budget (e.g. MFA gaps,
  offboarding steps, orphaned accounts)
- Set or confirm a change process for production systems
- Agree service levels with the business, even simple ones
- Handle any contract renewal in the window with a usage review
Deliverables by day 60:
- Restore test write-up: time to recover and anything that failed
- A one-page monthly IT report the business can read
Check-in: day 60

DAYS 61-90 — Set direction and a budget case
Goals:
- Present a 12-month IT roadmap tied to the risk register
- Write the budget case for the items that need money
- Document an incident response contact list and escalation path
- Make one measurable service desk improvement (e.g. a self-service
  password reset, a new knowledge article set for top ticket types)
Deliverables by day 90:
- Roadmap and budget agreed with your manager
- Service desk improvement measured against the day-30 baseline
Check-in: day 90 — full review against this plan

The day-30 risk register

The risk register is what turns a pile of inventory findings into decisions. Each entry should say what could go wrong, how likely it is, what it would cost the business in time or money, and what fixing it requires. Keep it to plain language, because the people approving the budget for fixes are usually not technical.

What "on track" looks like at each checkpoint

A filled example

Running the service desk while doing all this

The risk work only happens if the queue does not swallow the new manager. Ask them to look at the ticket data by category in the first month: a handful of categories, typically access requests, password resets, new starter setup and a few recurring application problems, often make up a large share of volume. Fixing the cause of one of those categories frees the team for the rest of the plan. If you are adding staff, the help desk technician screening questions and systems administrator screening questions test the troubleshooting and documentation habits this plan relies on.

What the hiring manager owes the new IT manager

• A clean handover of credentials from the previous manager or the provider, including the password vault, domain registrar, DNS, cloud consoles and any hardware warranty portals.
• Contracts and invoices. Finance often knows more about what IT pays for than IT does.
• Permission to report bad news. The day-30 risk register will make the previous setup look worse than people thought. That is the plan working.
• A named decision maker for spending and the budget cycle date, so the day-90 budget case lands when it can actually be funded.

Mistakes that stall a new IT manager

Adapting the plan

• Regulated environments such as healthcare or finance: add the compliance owner to the day-30 meetings and fold audit findings into the risk register, with the compliance team confirming which requirements apply.
• Heavily outsourced IT: the inventory becomes a review of the provider's contract, service levels and reports, and day 60 includes a first service review meeting run by the new manager.
• Multi-site companies: visit every site in the first 60 days; network closets and local workarounds rarely match the documentation.