The Common IT Audit Findings That Come Up Most
Eight areas produce most of what lands in an IT audit report. The technical fix for each is usually known. The finding survives because the control has no rhythm and no owner.
Access Control: Joiners, Movers and the Leavers Nobody Removed
The most reported finding in IT audit, across every sector.
Auditors sample the user list and compare it with the people who work there. What they find is familiar: accounts belonging to people who left months ago, accounts belonging to people who moved to another department and kept both sets of rights, and contractor accounts nobody has looked at since the contract ended.
The leaver case is the one that gets written up hardest, because it is the clearest evidence that a process did not run. The mover case is the quieter problem. Rights accumulate, nobody revokes anything, and after three internal moves a person can approve their own work.
What closes it is a user access review that actually happens on a schedule, with the manager of each team confirming their own list, and a record of who confirmed what and when. The technical part is easy. The part that fails is somebody chasing eleven managers for replies every quarter.
If your joiner and leaver process depends on somebody remembering to email IT, the finding will come back. Tie account creation and removal to the event that already gets recorded reliably, which is usually payroll or the HR system.
Privileged Access and the Shared Admin Account
Administrator rights get their own finding because the damage from misuse is different in kind.
Three patterns come up. Too many people hold privileged access, usually because it was granted for a project that ended. Administrator accounts are shared, so nothing can be traced to a person. And privileged activity is not logged separately from ordinary activity, so nobody can review it even in principle.
Least privilege is the principle, and it is easy to state and awkward to apply. Start from what each person needs this month rather than what they were given when they joined. Where somebody needs elevated rights occasionally, grant them for the task and take them back, rather than leaving the rights in place because the request is tedious.
Shared accounts are worth a separate push. Even where the technical platform makes individual accounts difficult, a log of who used the shared account and when, kept at the time, turns an untraceable control into a traceable one.
Segregation of Duties, the Finding Small Teams Always Get
Segregation of duties means the person who makes a change is not the person who approves it, and the person who runs a payment is not the person who sets it up.
In a team of five this is sometimes impossible, and auditors know that. The finding still gets raised, because the risk exists whether or not you can staff around it.
The answer is a compensating control, written down and agreed in advance. Somebody outside the team reviews the log of changes monthly, and a second person approves anything above a threshold. The reviewer does not need to be technical; they need to be able to ask why a change happened and get an answer.
What does not work is arguing that the team is too small. That is the reason the finding exists, not a response to it.
Patch Management: the Gap Between the Policy and the Server
Almost every organisation has a patch management policy, and auditors do not test the policy: they pick servers and ask when each was last patched.
The finding usually reads that critical patches were not applied within the timeframe the policy itself sets. That wording matters, because you wrote the timeframe. A thirty-day policy that the team meets in sixty produces a finding. A sixty-day policy that the team meets in sixty does not, provided sixty is defensible for the risk.
So the first question is whether your policy describes what you actually do, and the second is whether what you do is good enough. Fix the gap in whichever direction is honest, because a policy nobody can meet is a finding generator.
The systems that fail are predictable: the appliance nobody owns, the server with an application that breaks when patched, and the machine that is always in use when the window opens. Name those three in the plan, with an owner each, because generic vulnerability management wording will not close them.
Our post on securing your website against cyber threats covers the external-facing side of the same problem, where the exposure is public and the timeframe should be shorter.
Change Management: Changes That Went Out Unapproved
Change management findings come from a sample of production changes and a check on whether each one was requested, approved, tested and recorded.
The emergency change is where most teams lose it. Something broke at eleven at night, somebody fixed it, and the record was never created. The auditor finds a change with no approval and writes it up.
The fix is not to ban emergency changes. It is to have a defined emergency path with retrospective approval inside a stated window, so that a night-time fix is an allowed route rather than an undocumented one.
The second common gap is testing evidence. The change was tested, the tester remembers testing it, and nothing was written down. Where testing is part of your control, the record of the test is the control operating. Our post on security testing in the development lifecycle covers how to make that evidence a by-product of the work instead of an extra task.
Backup and Disaster Recovery: Backups Nobody Restored
Backup and disaster recovery findings rarely say backups are missing, they say the restore was never tested.
A backup job that reports success proves that a job ran. It does not prove that the data can be recovered, that somebody knows how, or that the recovery fits inside whatever downtime the business can absorb. Those are three separate claims and the audit tests all three.
So the evidence is a restore test: a date, what was restored, how long it took, who did it, and what went wrong. The last item matters more than it looks. A restore test with no problems recorded reads as a test that was not really run.
The second finding in this area is the recovery objective nobody agreed. If the plan says four hours and the business assumed one, the gap is a finding waiting to be written, and it is a conversation rather than a technical job.
Where infrastructure sits across cloud and on-premises, the restore path usually crosses both, and that crossing is where the untested step hides. Our post on cloud versus on-premises infrastructure covers the trade-off, and the audit point is simply that both halves need the same testing.
Logging and Monitoring: Logs Kept, Never Read
Logging and monitoring produces two findings that look similar and are not.
The first is that logs are not collected, or not retained long enough. That is a configuration job with a clear end.
The second is that logs are collected and nobody reviews them. This one is harder, because reviewing everything is impossible and reviewing nothing is a finding. The answer is a defined review: which events, how often, by whom, and what happens when something is found. A short documented review that happens is worth more than a broad one that does not.
Auditors also test whether logs can be altered by the people they record. Administrator activity logged to a system the same administrators control is a weak control, and it gets written up on design rather than on operation.
Retention is the quiet one. Set it to what your policy and your regulator require, then check it, because default retention on many platforms is far shorter than people assume.
Third-Party Risk: the Vendor Nobody Reviewed
Third-party risk findings have become more common as more of the estate sits with suppliers.
The standard finding is that critical vendors were not assessed, or were assessed once at onboarding and never again. Auditors ask for the list of suppliers who hold your data or run your processes, the assessment for each, and the date.
Most organisations fail on the list itself. Nobody holds a complete inventory, because tools get bought by departments and never reach a register. Building that list is the first remediation step, and it usually surfaces work nobody expected.
After the list, the review is proportionate, so a supplier holding customer records needs an assessment, evidence of their own controls, and a contract that says what happens in an incident. A supplier providing office plants does not.
Right of audit, breach notification timelines, and what happens to your data when the contract ends are the clauses auditors look for, and they are agreed at contract time or not at all.
Security Policy: Written, Approved, Unread
Security policy findings come in three flavours, and each has a different fix.
The policy does not exist. Straightforward, and the fix is to write one that describes your organisation rather than copying a template that describes somebody else's.
The policy exists but was never approved, or was approved four years ago by somebody who has left. Findings about governance are cheap to close and embarrassing to leave open, because the fix is a review and a signature.
The policy exists, is current, and nobody has read it, and this is the one that keeps coming back. Evidence here is acknowledgement records with dates, and, where the risk justifies it, evidence that people understood it rather than clicked through it.
One caution worth stating plainly: a policy that promises more than you do is worse than no policy. Auditors test against what you wrote. Every sentence in a security policy is a control you have volunteered to be measured on, so write the version you can evidence.
