Your First 90 Days After You Inherit IT

The environment is yours now

You are the IT department. Your predecessor may have left with three days’ notice and a shared drive full of folders named “old,” or six years of accumulated decisions may still depend on what only you remember.

One Solo IT Director said it plainly: “I’m one person. If I’m sick or on vacation, nothing gets done.”

By day 90, produce a written record another human can operate from. Verify access, restore one system, map privileged accounts to people, calculate vendor decision dates, and list every open claim you are still expected to defend.

Buy no stack from this plan. Write the requirement and test the current state before any purchase enters the decision record.

---

Mark every statement confirmed, tested, or inherited

Nearly everything you have been told about this environment is an inherited claim. Somebody said it, or a document from 2021 says it, and no one has looked since.

That is not a criticism of the people who told you. It is a statement about what you personally have seen. The distinction matters because inherited claims fail at exactly the moment they are load-bearing: during an incident, during an audit, during an insurance claim, and during the week you are out sick.

So every fact you record in the next ninety days carries a status. Six values, and they are not interchangeable.

Status	Meaning	What it takes to earn it
inherited claim	A person or a document asserts it. You have not seen the system say it.	Nothing. This is the default for everything on day one.
confirmed	You personally saw the configuration in the system, and it is dated within the last 30 days.	An export, a screenshot with a timestamp, a console view you opened yourself.
tested	It was exercised and produced a result.	A restore that restored. A failover that failed over. A phone number that a human answered.
unknown	Nobody in the organization can say.	Honesty. Write it down rather than leaving the cell empty.
blocked	You cannot verify it because you lack access, credentials, or a vendor response.	Record what is blocking, who can unblock it, and the date you asked.
owner needed	The thing exists and no named human owns it.	Record it. This status resolves into a name or into a decision to retire the thing.

confirmed and tested are different and the gap between them is where most environments fail. A backup configuration you have looked at is confirmed. A backup you have restored from is tested. Only one of those tells you what will happen on the bad day.

Write the status next to every single line you record. When you hand this to a board, an auditor, a carrier, or your successor, the status column is what makes the document credible, because it shows exactly which parts you stand behind.

---

Four rules before you change the inherited environment

1. Do not change anything you cannot restore. You do not yet know what depends on what. The scheduled task nobody documented is running payroll.

2. Do not buy anything. Not in the first thirty days. Vendors will find you within a week of your title changing on LinkedIn, and the first proposal will arrive before you can evaluate it.

3. Do not promise a date for anything you have not verified. Leadership will ask “are we secure” in week one. The correct answer names what you have confirmed, names what you have not looked at yet, and gives a date for the next update.

4. Write down every claim, with who said it and when. This becomes your inherited-claim register, and it is the most valuable artifact you will produce this quarter.

---

Days 0 to 10: Get access and record what you actually know

This block is about access and facts. It contains no projects, no rollouts, and no purchases. The purpose is to reach a state where you can actually see the environment, and to write down what you were told before you start forgetting who told you.

Verify the accounts only you may need during an incident

Log in yourself. Confirmed means you opened it, not that you were told you have it.

System	Why this one	Status
Identity provider or directory (Entra ID, Active Directory, Google Workspace, Okta)	Everything else hangs off it
Email platform admin	Mail is the primary attack path and the primary recovery path
Endpoint management console	The only way to see what devices actually exist
Backup console	And the credentials to it, which are frequently the same credentials as production, which is a finding
Firewall and edge device	Including the current firmware version and its support status
Domain registrar	The most commonly lost account in a transition. If you lose the registrar you can lose the domain, the mail, and the ability to recover anything.
DNS host, if separate from the registrar
Primary line-of-business system, admin level	The one the business cannot operate without
Cloud tenant billing or subscription owner	Frequently held by a departed founder or an outside accountant
Phone or VoIP system admin	Used in fraud and in recovery, and universally forgotten
Physical access and alarm system, if IT owns it

For each: record how you get in, whether MFA is on it, who else has it, and where the recovery contact points.

Ask who can enter if your account fails

Ask it on day one and record the answer even when the answer is bad.

• Is there an emergency administrative account that does not depend on the identity provider being up?
• Where are its credentials, physically?
• Who can retrieve them, and does that require two people?
• When was it last used or tested?
• Does its second factor live on a device belonging to someone who still works here?

If any answer is unknown, the whole break-glass line is unknown, and it belongs at the top of your day 11 to 30 list. This is one of the very few items that legitimately jumps the queue.

Collect the facts before you open new projects

Item	Where it comes from	Status
Every human and every vendor with administrative access	Directory export plus asking the outsourced provider directly, in writing
The technology spend list	Accounts payable, 13 months, plus card statements
Incident contact list	Cyber carrier claims line, broker, counsel, bank fraud line, outsourced IT after hours, and the mail platform’s support path
The last restore test record	If none exists, write none on record. That is the answer, and it is common.
The last risk assessment, audit response, insurance application, or client security questionnaire	These documents state what your organization has already claimed about this environment, in writing, to a third party
The five systems the business cannot operate without	Ask the business, not IT. The answers differ and the business is right.
Any exception someone mentions in passing	”Oh, that machine can’t have the agent.” Write it down that day.

That fifth row deserves emphasis. Somewhere there is a signed insurance application or a completed customer questionnaire asserting facts about your environment. You have inherited those assertions. Read them in your first ten days, because you are now the person who would have to defend them, and any gap between what was claimed and what is true is a problem you want to find on your own schedule.

Deliver the day 10 access and inherited-claim record

One page. What you have access to, what you do not, the five critical systems, the incident contacts, and a list of every claim you were told with its source. Send it to whoever hired you with a line saying which items are confirmed and which are inherited claim. That sentence sets expectations for the entire ninety days and it protects you later.

---

Days 11 to 30: Test the claims you may have to defend first

You cannot verify everything. Verify in order of what would hurt most if the claim turned out to be false.

1. Restore one thing, for real

Pick something meaningful and restore it. A file share folder, a mailbox, a database, a virtual machine. Time it. Write down what was restored, from which backup, how long it took, and who witnessed it.

This single exercise moves your backup line from inherited claim to tested, and it routinely surfaces three findings at once: the retention is shorter than believed, the restore takes longer than believed, and the backup account uses the same credentials as production.

Ransomware appeared in 44% of breaches in Verizon’s 2025 dataset, which covered 22,052 incidents and 12,195 confirmed breaches. That is a contributed-case dataset rather than a population sample, so read it as directional. The direction is enough to justify one afternoon.

2. Export the MFA enforcement policy, including exclusions

Not a screenshot of your own enrollment. The policy, its scope, and every exclusion, with a count. Exclusions accumulate quietly: a legacy application, a service account, a scanner, the executive who travels, a system that broke once. Each exclusion gets an owner and a reason.

3. Build the privileged access list with human names

Every account holding administrative rights in every system from your day 0 to 10 list, with a named person next to it. Service accounts need an owner too, and they usually do not have one. Your outsourced provider’s technician accounts belong on this list; they are privileged accounts in your environment.

Third-party involvement appeared in 30% of breaches in that same Verizon dataset, with the same limits.

4. First pass at the asset record

You need a device count you believe. Reconcile three sources: the endpoint management console, the identity provider’s registered devices, and the network’s DHCP or ARP table. The three will disagree. The gap is your finding, and you record the number rather than resolving it perfectly. Perfect asset records are a year of work. A believable count with a known margin is achievable in a week.

5. Vendor renewal calendar with decision dates

Pull the term end date and the notice period for every recurring contract, compute the decision date, and put it in a shared calendar with an owner. A missed notice window costs a full year of a decision you no longer control.

6. Write version 1 of the continuity record

Described in full below. Write it badly on day 25. Improve it later. A bad continuity record beats none.

---

Days 31 to 60: exceptions, lifecycle, and the first real conversation

Give every exception an owner, compensating control, and date

Every environment runs on exceptions. The machine that cannot take the agent, the account that cannot have MFA, the vendor with standing remote access, the shared login the front desk needs, the firewall rule opened in 2019 for a project.

An undocumented exception is indistinguishable from a misconfiguration. Documenting it changes nothing technically and changes everything operationally, because it becomes a decision somebody made rather than a gap somebody missed.

Exception	System	Reason it exists	Who approved it	Date	Compensating control	Review date	Status

If you cannot find who approved an exception, record owner needed and take it to leadership as a decision. Some will be accepted, some will be closed within a week once someone with authority actually sees them.

Put every end-of-support date on the decision calendar

Inventory anything running past its support date: operating systems, applications, firewalls, switches, printers, the phone system, the building access controller.

Standard support for Windows 10 ended on October 14, 2025. Microsoft ended technical assistance, software updates, and security fixes on that date. Commercial Extended Security Updates start at US$61 per device for the first year and double in each consecutive year.

The doubling is the part to put in front of finance. It converts a vague “we should upgrade eventually” into a cost curve with known values, which is a conversation a CFO can actually have with you.

Test the incident contacts

Call the numbers. All of them, during business hours, and tell whoever answers that you are verifying the contact. Confirm the after-hours path for your outsourced provider and your carrier’s claims line specifically. A contact list that has never been dialed is an inherited claim about the most time-sensitive thing you own.

While you are there, find out from your broker or counsel which notification obligations may apply to your organization. Timing and applicability differ by regulator, by entity type, and by data type, and this determination belongs to counsel rather than to you. What belongs to you is knowing who makes the call and having their number.

One tabletop, thirty minutes, on paper

Get the decision-makers in a room. One scenario: the accounting system is encrypted at 6am Monday. Walk it verbally. Who declares an incident. Who calls the carrier. Who decides whether to pay. Who talks to clients. Who talks to staff. What happens if you are unreachable.

That last question is the one you are actually there to ask. Watch what happens in the room when it lands.

Give leadership one dated memo with the open decisions

One decision, written properly: the decision requested, the risk in business terms, cost separated into known, unknown, and modeled, two or three real options including a smaller one, one recommendation, and a named owner with a date. Do not lead with fear and do not bring a tool list. If you have a board memo template available, use it.

---

Days 61 to 90: Close unknowns and hand over an operable record

Close the unknowns you can prove before day 90

Return to every unknown and blocked row. Each one gets one of three outcomes: it becomes confirmed or tested, it becomes a written decision to accept it, or it becomes a dated item on the next quarter’s list with a named owner. Nothing stays unknown without a reason and a date attached.

Put an owner and date beside every open decision

Things you cannot decide alone, each with what you need in order to decide.

Open decision	What it affects	What I need to decide it	Who decides	Date needed

This list is how you stop being the bottleneck for choices that were never yours to make.

Show leadership the hours and decisions one person cannot carry

At some point in the first ninety days you will need to say out loud that one person cannot both operate and improve the environment.

Have the conversation with facts rather than with feeling. Bring the hours: what routine operations consumed, what the incidents consumed, what the projects would require. Bring the continuity record and the two-week test result described below, which demonstrates the exposure more effectively than any argument.

Labor market projections exist and they are worth knowing about, with their limits stated plainly. The U.S. Bureau of Labor Statistics projects about 317,700 openings per year across computer and information technology occupations from 2024 through 2034, and 29% growth for information security analysts with about 16,000 openings per year. Those are national projections. They do not prove a vacancy at any specific employer, including yours, and they should never be presented as though they do.

The useful version of this conversation is local: here are my hours, here is what is not getting done, here are three ways to change that, one of which is reducing scope rather than adding headcount.

Assemble the access, test, vendor, exception, and decision records

One document. What was confirmed, what was tested, what remains unknown, the exceptions register, the renewal calendar, the open decisions, and the continuity record. Date it, and set the next review.

You now have something no one here had ninety days ago: a written operating record with a status next to every claim.

---

Check all nine work areas before the day 90 handoff

Reference table. What confirmed looks like for each, so you are not guessing at the bar.

Work area	confirmed looks like	tested looks like
Privileged access	A current export of every admin account with a named human beside each one	Removing one stale admin account and verifying nothing broke
Identity	The MFA enforcement policy with scope and every exclusion, exported and dated	An account in scope actually being challenged for a second factor
Asset record	A device count reconciled across three sources, with the gap stated	A device found in the network that was missing from the console, investigated and resolved
Backup and restore evidence	The backup configuration, retention setting, and deletion protection status, viewed by you	A completed restore with date, contents, elapsed time, and a verifier
Vendor renewals	Term end date, notice period, and computed decision date for every contract	A notice sent successfully by the required method
Incident contacts	A list with names, numbers, and after-hours paths	Every number dialed and answered, with dates
Inherited exceptions	Each exception written down with reason, approver, and compensating control	A review completed, with exceptions closed or formally accepted
Staff continuity	The continuity record exists and is current	Someone else used it to do something real, timed
Open decisions	The list exists with what each decision needs	A decision returned by a named person on a date

---

Build the record another person can operate from

This is the answer to “if I’m sick or on vacation, nothing gets done”. It is one page, or two. It is not a runbook for everything you do, which would take a year to write and would be stale in a month. It is the minimum another competent person needs to keep the organization operating for two weeks without you.

Include contacts, access paths, routines, exceptions, and decision dates

Section	Contents
Call order	For each of: outage, suspected breach or ransomware, the main business system down, payroll or banking problem, building access failure. Who to call first, second, third, with numbers.
Getting in	Where credentials live, the break-glass procedure, who holds the second factor, and what requires two people. Never the credentials themselves.
The five critical systems	Vendor, support contract number, support phone, after-hours path, and one line on what the system does.
Routine work that must happen while I am out	The three or four things with a calendar dependency: a monthly close process, a nightly job somebody checks, a weekly report, a payroll cutoff. What day, how to do it, how to tell it worked.
What must not be done while I am out	The changes that will break something, the vendor who will call and try to close a deal, the system that must not be rebooted during business hours.
Currently broken, and lived with	Known issues and their workarounds, so nobody spends a day rediscovering them.
Next 60 days of renewals	With decision dates and owners, so a window does not close while you are away.
Where this lives	The document must be reachable when the network is down. Print it. Name the physical location. Put a copy where a non-IT person can find it.
Last reviewed	Date and by whom. Review it quarterly and after any significant change.

Ask a second person to operate from the record

Hand it to one person who does not work in IT. Ask them to find the after-hours support number for the mail platform, using only the document. Time them.

If it takes more than two minutes, the document is not finished. If they cannot do it at all, you have learned that in a quiet office rather than at 11pm on a Friday.

Run the same test with a second question three months later: “who do you call first if you think we have been breached.” The correct outcome is that they answer without reading much.

Use the continuity test to expose what only you know

Two reasons, and both are practical.

Continuity failure is a security failure. When the only person who understands the environment is unreachable, decisions get made by people guessing, access gets granted to unblock someone, and an incident that needed a decision in the first hour gets one in the eighth.

And the record itself does most of the work of an audit response, a client security questionnaire, and an insurance application. You are going to be asked for exactly these facts by somebody within a year. Writing them for your own continuity means you write them once.

---

Let a written requirement and failed test trigger the purchase

There is a point where buying something is the right answer. The order matters, and the order is what keeps a vendor from setting your priorities.

1. The requirement is written down, sourced to an obligation, a contract, a carrier form, a control gap you found, or an operational need you can describe in business terms.
2. The current state is tested, not assumed. You know what you have and whether it works.
3. What you already own is checked first. A large share of gaps close with a setting in a platform already paid for. Check the licensing tier before checking the market.
4. Two or three real options exist, including a smaller one and doing nothing.
5. The recommender’s compensation is recorded. Ask in writing whether they earn margin, commission, rebate, partner tier credit, or a referral fee on what they are proposing. A compensated recommendation can be correct. It carries a different burden of proof, and recording the answer is how you apply that burden without arguing about anyone’s motives.
6. The exit cost is known before you sign, including the notice period and the renewal term.

Anything arriving in a different order is somebody else’s plan.

---

Five events to expect before day 90

Someone will tell you “we have MFA.” They mean they personally have MFA. Check the enforcement policy and its exclusions. This is the most consequential inherited claim in most environments.

The backup dashboard will be green and nothing will have been restored. Green means the job ran. Restore something.

A vendor will call in your first two weeks with a proposal. They read the same LinkedIn announcement everyone else did. Take the meeting if you like, and buy nothing for thirty days.

You will find an exception nobody wrote down, and it will be load-bearing. The machine that cannot take the agent runs something the business depends on. Document it, add a compensating control, and put a review date on it.

You will be tempted to be fast. Being fast in month one makes you the only person who knows why anything is the way it is, which is the exact problem you were hired to solve. Write as you go. The writing is the work.

---

Keep the day 90 record current after the quarter ends

This plan is general operational guidance for a solo IT role. It is not legal advice and it does not determine what any regulation, contract, insurance policy, or funder agreement requires of your organization. Notification duties, security program requirements, and record retention obligations vary by regulator, entity type, state, and data type. Where a question touches applicability, counsel decides it. Your job is to know the facts, the owners, and the phone numbers.

Every external figure in this document is sourced to a named publisher through SBK’s source register, with the limits of each dataset stated where they apply. The labor projections are national and prove nothing about your specific employer. The breach figures come from a contributed-case dataset rather than a population sample.

SBK Consulting is a family-run, vendor-neutral IT advisory firm serving the New York, Connecticut, and New Jersey metro area since 2010, with more than 125 years of combined experience and a fully US-based team. Zero vendor partnerships, zero reselling, zero commissions or referral fees, which means we have nothing to sell you at the end of any of these ninety days. We will review a continuity record and a first ten-day list if a second set of eyes is useful. If you work the plan alone and never call, it did what it was built to do.

(718) 407-4169