Taking over organically grown IT infrastructure

An audit of organically grown IT runs in three steps: first you record what's actually there – devices, software, access, contracts – then you assess which risk comes from which part, and only after that do you remediate in a sensible order. The mistake that costs the most time is starting remediation before it's even clear what's hanging off the network. Rebuild first and discover what you missed along the way, and you end up building twice.

What gets inventoried during an IT infrastructure audit?

It starts with a complete record of every active device on the network: switches, firewalls, access points, servers, workstations, printers, cameras and anything else with an IP address. Then comes the software side – which systems are running, on which version, under which licences, and who actually looks after them. Just as important as the technology is access: who has administrative rights to which systems, which passwords are still lying around from former employment relationships, which remote access channels are set up and used by whom. And finally the contractual side: maintenance contracts, licence terms, domain and certificate ownership – things nobody misses until a domain lapses or a certificate suddenly goes invalid.

• Every active network device with location, manufacturer, model and current firmware version
• Every piece of software in use, with version, licence status and the person responsible
• Every administrative access channel, including leftover accounts from former staff or external providers
• Contracts, domains, certificates and their terms, in one central place accessible to more than one person

How do you deal with undocumented systems?

Almost every organically grown infrastructure has devices or systems with no documentation left – set up by someone who left the company long ago, or built as a stopgap that nobody ever touched again. The safe approach is not to switch such a system off or change it right away, but to observe it first: what network traffic does it generate, which other devices does it talk to, who accesses it and how often. Only once it's clear what a system actually does can you safely decide whether to replace, document, or shut it down. Blindly switching off an unknown system on a production day can do more damage than the risk the system itself poses.

• Observe unknown systems first (network traffic, access patterns) before changing or switching them off
• For every device, clarify: is it still needed, by whom, and for exactly what
• Document the outcome of the review, even if the answer is "unclear, keep watching"
• Only switch systems off outside critical operating hours, and with a way to roll back

How is the risk of individual systems assessed?

Not every gap is equally urgent. A central set of criteria helps set the order: how exposed is the system – does it sit directly on the internet, or only on the internal network? How critical is it for ongoing operations – does an outage halt production, or only a minor function? And how easy would it be to exploit – an outdated system with known, publicly documented vulnerabilities is more urgent than one with only theoretical risk. These three questions usually make it clear on their own what needs tackling first and what can wait until the more pressing items are done.

In what order should organically grown infrastructure be remediated?

After the audit and risk assessment, remediation typically follows this order: clean up access first, because it costs the least effort and lowers the biggest risk fastest – lock old accounts, change default passwords, restrict remote access to what's actually needed. Next come exposed systems with direct internet access, since they offer the largest attack window. Only after that come structural topics such as network segmentation, replacing outdated hardware, and building up ongoing documentation that stays current rather than going stale again the day after the takeover.

1. 01Clean up administrative access: lock old accounts, renew passwords, restrict remote access
2. 02Secure or replace exposed systems reachable directly from the internet
3. 03Segment the network to limit the spread of any potential incident
4. 04Replace outdated hardware and software on a planned basis, prioritised by criticality
5. 05Establish ongoing documentation that's maintained with every change

Who should carry out the infrastructure audit?

Organically grown infrastructure is most fully captured when someone from outside looks at it, without preconceptions carried over from how it was built. Someone who was part of that history tends to overlook what has since become taken for granted, even when it really shouldn't be. That doesn't mean internal knowledge isn't needed – quite the opposite: whoever knows the business best knows what's genuinely critical and what merely grew that way historically but has long since become unnecessary. The best audit combines both: an outside, unbiased look at the technology with internal knowledge of how the business actually runs.

How long does an audit take, and who should be informed beforehand?

How long an audit takes depends heavily on the size and documentation state of the existing infrastructure – a well-documented site can be captured in a few days, while a network that has grown over years with no documentation at all can take considerably longer, especially where individual systems first need to be observed to work out what they're for. It matters to inform staff beforehand about why someone is suddenly checking devices, capturing network traffic, or asking for access credentials – without that context, it quickly starts to look like an inspection, and exactly the people who carry the most knowledge about how the systems grew become less forthcoming with what they know. A short, open heads-up in advance saves both sides unnecessary friction.