You Have Inherited an IT Environment. What to Check First.

If you have just taken over a business and nobody has looked at its IT, start with access. Not the servers, not the software, not the old provider's invoices. Access. Departed staff, the previous owner, the nephew who set up the server, the former IT company whose remote access tool is still installed on every machine, and any account that has not signed in for a year but still could. Until you have checked, you do not know who can get into the thing you just bought.

Access is the only item on this list where every day of delay carries real risk, and during a transition it is usually the item nobody owns. The seller has stopped caring, the buyer has not started, and the accounts sit there in between. Everything else on this page can happen inside the first month. Access happens in the first week.

An inherited environment is its own kind of problem, and it is worth being clear about what kind. The business may have been run perfectly well. What you are missing is the decisions. You were not in the room when they were made, the documentation assumes knowledge you do not have, and the people who carried the rest in their heads may already be gone. On settlement day you took ownership of whatever was there, including anything that was already going wrong.

TL;DR: What to remember

• ✅ Week one is access. Work out who can get in, and end the access that should have ended already.
• ✅ Weeks one to two are inventory. You cannot secure equipment and services you do not know you own.
• ✅ Weeks two to four are data and obligations. You may have bought someone else's privacy exposure along with their customer list.
• ✅ Month one to two is a measured position against a framework, so remediation becomes a costed list a board can approve instead of an open question.

Contents

• The first week: end the access that should already have ended
• Weeks one to two: build the inventory nobody handed you
• Weeks two to four: the data you now hold about other people
• Month one to two: turn the unknown into a costed list
• Taking over an environment: first questions

The first week: end the access that should already have ended

Restricting administrative privileges is one of the Australian Signals Directorate's (ASD) eight mitigation strategies, and in an acquisition it is the one that matters immediately, for a simple reason: the population of people with access has just changed, and nobody edited a list to make that happen. The org chart moved. The accounts did not.

1. Find every account that can administer something

Go system by system: the domain, the cloud tenant, network devices, the line-of-business applications, and the management consoles of the security tools themselves. That last one gets skipped, and it should not, because an administrator of the security tooling can quietly switch off everything the other controls depend on. The output you want is a written list of every account with elevated access and a name against each one. Where there is no name, you have found your first job.

2. Deal with the previous owner's access in writing

Accounts belonging to people who have left are straightforward. Accounts belonging to the previous owner personally are not, because you may still need that person for handover, and cutting them off on day one is technically correct and commercially unhelpful. The workable version is a dated, documented arrangement with an end date. What does the damage is the indefinite arrangement nobody wrote down, the one that is still in place two years later because ending it never became anyone's task.

3. Remove the remote access tools you did not put there

Prior providers and contractors leave their agents installed. It is rarely malicious. It is what happens when a relationship ends without a decommissioning step. But every agent that is still active is a path into your environment held by someone who may have no current relationship with you at all, so the task is to establish which are live and remove the ones that should not be. If you do not know what the tool is or who installed it, that is not a reason to leave it. That is the reason to take it out.

4. Rotate shared credentials and switch on multi-factor authentication

Check for shared logins, particularly on anything financial. They survive transitions precisely because nobody wants to be the person who breaks a process, and a sale is the moment they are most dangerous, because the set of people who know the password no longer matches the set of people who work for you. Rotate anything you cannot fully account for, and enforce multi-factor authentication on anything reachable from outside. A password on its own should not be enough to reach your systems from the internet.

Weeks one to two: build the inventory nobody handed you

Acquired environments almost always contain something nobody mentioned. A server in a cupboard, an application maintained by one person, a cloud subscription paid on a personal credit card, a backup that has not run since a hardware change. None of it was hidden from you deliberately. It was simply never written down, and the person who knew has left the building.

5. List every device, server and cloud service, and check vendor support

Mark which items are still supported by their vendor, because unsupported operating systems and applications are one of the most common inherited liabilities: they stop receiving security fixes, and the gap grows every month. ASD's guidance is to prioritise upgrading legacy systems so the Essential Eight can be implemented in full, applying compensating controls while that happens. In plain terms, plan the replacement, and put something around the old system in the meantime rather than pretending it is fine.

6. Test a restore, not the backup schedule

Find the backups and restore something. Not the schedule, not the job log, an actual restore. A green backup log confirms the job ran, and nothing about whether the business comes back from it. An inherited backup you have never restored from is an assumption, and you are about to build your recovery plan on it.

7. Put a name against every piece of software

Identify the software with no owner, and the software whose owner has left. Both categories keep running right up until they fail, and when they fail, the question "who looks after this?" gets answered under pressure instead of on a quiet Tuesday. The fix costs nothing now. It costs plenty later.

8. Establish what the internet can reach

Work out what is actually internet-facing, because that is the surface anyone else can reach without walking through your front door. The inherited environment was shaped by years of "just open it up so this works" decisions, and nobody has ever gone back to close them. This is where the access work and the inventory work meet: an exposed service plus a forgotten account is not two small findings. It is one open door.

Weeks two to four: the data you now hold about other people

You have not only acquired systems. You have acquired personal information about the other business's customers, staff and suppliers, and potentially an incident that already happened and was never identified. Do this work before it becomes urgent, because the version of it that happens after a discovery is faster, more expensive and much less pleasant.

9. Work out whether the Notifiable Data Breach scheme covers the combined business

Under the Notifiable Data Breach (NDB) scheme, an eligible data breach involves unauthorised access to, unauthorised disclosure of, or loss of personal information an organisation holds, where that is likely to result in serious harm and remedial action has not prevented that likely risk. Whether the scheme applies to you turns on entity type. It covers APP entities, which include organisations with an annual turnover of more than $3 million, along with certain categories regardless of size, including organisations providing a health service and holding health information, businesses trading in personal information, credit providers and credit reporting bodies. Here is the part acquirers miss: an acquisition can move a business across that threshold, so obligations that never applied to the business you bought may now apply to the business you have become.

10. Treat any sign of an old compromise as a live matter

If evidence of a prior compromise surfaces during your review, you are now the one who knows about it. Whether an obligation follows depends on the entity, the deal structure and the facts, so get advice on the position rather than filing it as a historical curiosity. What you should not do is nothing, because "we found it and sat on it" is a worse sentence to say later than any answer the advice could give you.

11. Map the third-party arrangements that came with the deal

The acquired business arrives with its own integrations, suppliers and data-sharing arrangements, and nobody has mapped them against yours. This gap is not rare. The Australian Securities and Investments Commission's (ASIC) cyber pulse survey found 44% of participants were not managing third-party or supply chain risks. Every one of those arrangements is a place where someone else's security decisions become your problem, and after an acquisition you hold a set of them you did not choose and have not read.

Month one to two: turn the unknown into a costed list

Once access is controlled and you know what exists, convert the situation into something measurable. "The IT is a mess" cannot be budgeted. A control-by-control position can.

12. Assess the environment against a framework

ASD's Essential Eight assessment guidance produces an outcome for each control using standardised terms, records the evidence behind each finding, and states whether a target maturity level has been met. From an integration standpoint the score matters less than the list underneath it: a sequence of decisions with prices attached, which is the form a board can actually act on. That is the whole move. The inherited unknown becomes a document, and the document becomes a budget.

13. Choose the operating model on purpose

Acquired businesses usually arrive with an incumbent IT provider and an arrangement nobody in the new structure chose. Keep, replace or consolidate is a commercial decision, and it is far easier to make once you know what is actually in place. Worth knowing as you weigh it: inSUPPORT works with Australian businesses of roughly 30 to 300 users and includes remediation in the monthly support fee rather than quoting it back as a separate project, which matters in an integration, where the remediation list is long and known in advance. Whichever direction you go, decide it deliberately, and decide it during the transition, while you still have the standing to ask for things.

Taking over an environment: first questions

How long does all this take?

Access work is days. A meaningful inventory is one to two weeks, depending on how much documentation survived. A framework-based assessment depends on the size and complexity of the environment, which is ASD's own position on assessment timelines. The sequence matters more than the total: with access done first, everything else can proceed without an open door behind it.

Should we do this before completion or after?

As much as due diligence allows, before. Access to systems during diligence is usually limited, so a full technical review is rarely possible, but questions about supported software, backup practice, prior incidents and existing framework obligations can be asked and the answers recorded. What is asked and answered before completion can inform warranties and the deal terms. What is discovered afterwards is harder to allocate, and where it lands depends on the deal structure and what was disclosed, which is a question for your advisers rather than your IT provider.

The acquired business says it had no security problems. Is that reassuring?

It tells you what they observed, not what happened, and the two differ most in the environments with the least monitoring. A business with no logging is not a business with no incidents. It is a business that would not have seen one. Take the statement as good faith and verify it independently anyway.

What if the previous IT provider will not hand things over?

It happens, and it is a contractual matter as much as a technical one. Practically: document what you asked for and when, establish your own independent administrative access to every system you can rather than relying on theirs, and treat any credential you cannot verify as compromised. Waiting patiently for a cooperative handover while the old provider still holds access is the worst of both positions.

Citations

• "Essential Eight assessment process guide", Australian Signals Directorate. The standardised assessment outcomes and evidence requirements referenced above, and the position that assessment approach depends on the size and complexity of a system. cyber.gov.au
• "Part 4: Notifiable Data Breach (NDB) Scheme", Office of the Australian Information Commissioner (updated February 2025). Which entities the scheme covers, including the $3 million turnover threshold and the categories covered regardless of size. oaic.gov.au
• "ASIC calls for greater organisational vigilance to combat cyber threats" (23-300MR, November 2023). Used above for supply chain exposure: 44% of participants in ASIC's survey were not managing third-party or supply chain risk. asic.gov.au

Related Reading

• The Risks of Not Using Managed Services
• How the Essential 8 Maturity Model Benchmarks Cybersecurity
• The 6 Step Cyber Strength System
• One team for IT, compliance and cyber insurance

Content reviewed by Probably Genius for accuracy and relevance.

inSUPPORT provides managed IT and cyber security services. It is not an insurer, insurance broker or underwriter and does not hold an Australian Financial Services Licence. Where cyber insurance forms part of a plan, it is arranged through licensed insurance partners and underwritten by the insurer. Cover is subject to the insurer's assessment, the policy terms and the Product Disclosure Statement and Target Market Determination. This article is general information about IT and security practice, not financial product advice, and it does not take account of your objectives, financial situation or needs.