Common IT audit findings: five examples from practice
Five anonymised findings from our IT audits: backups, accounts and access, outdated systems and failure plans, with what we recommended for each.
The most common IT audit findings concern the basics: backups, accounts and access, system versions and a plan for failures. That is where we find the problems that raise the risk most. Below are five findings from our audits, anonymised so that the organisations cannot be identified. For each one, we say what we found and what we recommended. At the end there is a list of questions for your own review.
Our IT infrastructure audit page sets out the full scope and what the report contains.
Backups that could be deleted
What we found: an external service provider ran the backups, but the repositories had no retention lock. A person with administrator rights could delete them, and so could an attacker who took over that person’s account. The contract gave the client no right to check the configuration or the results of restore tests.
What we recommended: repositories with a retention lock, meaning backups that cannot be changed or deleted for the whole retention period. We also recommended an off-site copy, separate permissions and a contract clause giving the client the right to check the configuration and restore test results. We set up backups as part of our business software services.
An after-hours incident with nobody to make the call
What we found: the security monitoring team worked around the clock. After business hours, however, it was not clear whom they should call and who could decide to cut off an infected system. In practice, a night-time alarm would have waited until morning.
What we recommended: an escalation procedure outside business hours, naming the people who make decisions. The monitoring team should receive a contact list and a list of the most important systems with priorities. Our article on threat monitoring and incident response explains how the process should work.
Passwords in documentation and accounts left by former suppliers
What we found: credentials written down in internal company documentation. An account of the previous supplier was still active in the network management console. Some admin panels did not require a second sign-in factor.
What we recommended: a review of the documentation for passwords and moving them to a password vault. We also recommended disabling former suppliers’ accounts, enabling multi-factor authentication (MFA) on every panel and reviewing a register of external access every quarter. Sign-in configuration in Microsoft 365 is covered on our Microsoft 365 security page, and the next steps in our guide on how to enable MFA in Microsoft 365.
Outdated systems and firewall rules left by the previous supplier
What we found: servers running systems past the end of vendor support, with no plan to retire them. Some firewalls ran software for which the manufacturer had announced a critical vulnerability. The firewalls also kept rules left by the previous supplier, including unused ones.
What we recommended: a plan to retire outdated systems. If a system cannot be switched off quickly, it needs a documented exception with a risk owner, network isolation and a deadline. The firewalls need updating, the rules tidying up and device management from the internet restricted. We describe this kind of work on FortiGate firewalls on our Fortinet page.
No failure plan and no protected power in the server room
What we found: the organisation had no business continuity plan and no agreed recovery times. Nobody had tested restoring from backup. The server room at head office had no uninterruptible power supply (UPS) and no temperature or flood sensors.
What we recommended: start with a list of systems ranked by importance. For each one, set the acceptable downtime (RTO, recovery time objective) and the acceptable data loss (RPO, recovery point objective). Then test restoring a selected server and one business system. The server room needs a UPS and sensors. Our article on the 3-2-1 backup rule explains how to set up backups that pass a restore test.
Checklist for your own review
| Area | Question |
|---|---|
| Backups | Can backups be deleted before the end of the retention period, and when was one last restored? |
| Incidents | Who decides to cut off a system outside business hours, and does the monitoring team have their number? |
| Accounts and passwords | Is the documentation free of passwords, and are former suppliers’ accounts disabled? |
| Sign-in | Do all admin panels require MFA? |
| Systems | Is any server or firewall past the end of support or affected by a known critical vulnerability? |
| Failure plan | Do you know the acceptable downtime of your most important systems? |
| Server room | Does the server room have a UPS and temperature sensors? |
What to do with the results
If you answer “I don’t know” to several questions, consider an audit. We quote an audit individually after a conversation about your infrastructure, and the report ranks problems by risk and urgency.
Most of these problems do not build up when someone looks after the infrastructure regularly. That is what we do as part of our managed IT services. Write to us to agree the audit scope; you get the price before work begins.
