Your security dashboard is green. Your scanner ran last night and reported nothing critical. Your last penetration test came back with three medium findings, all since closed. And you still cannot answer the question your board asked, which is whether anyone would notice if something went wrong.
That gap is the role of IT audits in cybersecurity. A scan asks whether your systems have known weaknesses. An audit asks a harder question: who is responsible for this, when was it last checked, and can you prove it.
This page covers what an IT audit is, how it differs from the three things it gets confused with, what audits keep finding, and what happens to the findings afterwards. It is written for the people who commission audits rather than the people who conduct them. If you need the checklist, the preparation steps or the remediation detail, those live on separate pages and are linked where they belong. This one is about why the exercise is worth doing at all, and it sits alongside our cybersecurity consulting services.
What an IT security audit is, and what it is not
An IT security audit is an independent examination of whether your controls exist, work as described, and can be evidenced.
Three words in that sentence are doing the work. Independent, because the person checking is not the person who built it. As described, because the audit compares what you say happens against what the records show happened. Evidenced, because an auditor cannot accept a description, only a record.
That is a narrower thing than most people assume, and it is also more useful than it sounds. An audit does not hunt for attackers, and it does not simulate one. It establishes what is true about your control environment on the days it looked, and it does so in a form somebody else can rely on.
How a cybersecurity audit differs from a scan, a pen test and a certification
Enterprise buyers are usually sold all four, often by the same firm, and the differences matter more than the sales material suggests.
A vulnerability scan is automated and continuous. It checks systems it can reach against a list of known weaknesses. It is cheap, it runs weekly or nightly, and it answers one question well: is anything here a known problem. It cannot tell you whether the system it just scanned is supposed to exist.
A penetration test is a person, or a team, trying to get in. It is scoped, time-boxed and adversarial. It proves that a particular path works, which is powerful, and it proves nothing about the paths nobody tried. A clean pen test means the testers did not succeed in the time they had, on the scope they were given.
A cybersecurity audit examines controls rather than systems. It asks whether access is reviewed, whether changes are approved, whether backups are tested, whether logs are retained, and whether there is evidence for each answer. It covers ground the other two never touch, because much of that ground is procedural rather than technical.
A certification or attestation is an audit with a published standard behind it and a report someone else will accept. The examination is similar. What differs is that the scope is set by the framework rather than by you, and the output is designed to be shown to customers, regulators or insurers.
The practical version: the scan finds the unlocked window, the pen test climbs through it, the audit asks who was supposed to lock it and when anyone last checked, and the certification produces a document your customer's procurement team will accept.
You need more than one of these. They are not substitutes, and a programme that runs only scans has confused coverage with assurance.
Internal and external IT audit: who is asking, and what they need proved
The word audit covers several different requests, and the difference is in who is asking.
Internal audit reports to your own governance function, usually an audit committee. Its job is to give the board an independent view of whether management's description of the control environment is accurate. It can look wherever it decides to look, and its findings stay inside the organisation.
External audit is commissioned by, or on behalf of, somebody outside. A regulator, a customer's procurement team, an insurer, or an acquirer conducting diligence. The scope is set by what they need proved, not by what you find most useful, and the output leaves the building.
These two produce different reports from the same estate, and confusing them is a common and expensive mistake. An internal audit that goes looking for the truth will find more problems than an external audit scoped to one framework. That is the internal audit working correctly, and treating its longer findings list as worse news misreads what happened.
A third case sits between them and is growing fastest: the customer security questionnaire that arrives with a deal attached. It is not formally an audit, it asks audit questions, and it usually lands with whoever answers fastest rather than whoever knows. Where an audit meets a regulatory deadline rather than a commercial one, the mechanics differ again, and we cover those on IT audits and regulatory compliance.
Why an IT audit is a security control, not paperwork
Most organisations file audits under governance and treat them as a cost of doing business. That framing is wrong, and it is why audit findings sit unresolved for months.
An audit is a detective control. It does not prevent anything, in the same way a smoke alarm does not prevent fires. What it does is tell you that something has drifted from the state you believe it is in, before that drift becomes the reason an incident got worse than it needed to be.
And drift is the normal condition of every estate. People join and leave, systems get built for a project that ended, and a firewall rule goes in for a migration that nobody removes. None of this is negligence. It is what happens when an organisation does work, and the only reliable counter is something that periodically compares the real state against the assumed one.
What the tooling cannot see
Security tooling is good at a specific class of problem and blind to another.
A scanner can tell you a server is missing a patch. It cannot tell you that the server supports a product line you discontinued and should have been decommissioned eighteen months ago. Both facts matter, and only one of them is in the tool.
The pattern repeats across the estate. Tooling sees configuration and misses intent. It knows an account has administrative rights and does not know the person left in March. It confirms a backup job completed and cannot confirm anybody has ever restored from it. It reports that logs are being collected and has no view on whether they contain what an investigation would need.
Every one of those gaps is a question about ownership, purpose or process. No tool answers questions of that shape, because the answer lives in people's heads and in records the tool cannot read. The audit's method — ask, then ask for the evidence — is the only one that reaches them.
This is also why audit findings and network security monitoring findings look so different from each other. They are answering different questions.
Where an audit fits in IT risk management
IT risk management runs on a loop: identify what could go wrong, decide how much of it you will tolerate, put controls in place, then check the controls are working.
Most organisations do the first three well enough and the fourth hardly at all. The risk register gets written, and controls get designed and deployed. Then everyone moves on, and two years later nobody can say whether the controls are still doing what they were designed to do.
The audit is that fourth step: it closes the loop, and a loop that does not close is not a management system, it is a document.
There is a second contribution, less obvious and arguably more valuable. An audit produces a defensible record of what you knew and when you knew it. If an incident happens, the difference between an organisation that identified a control gap, rated it, assigned it and was working through it, and one that had no idea, is substantial. It matters to regulators, to insurers, and to the board conversation afterwards.
That is not a reason to commission an audit. It is a reason not to leave its findings sitting in a spreadsheet, which is the subject of a later section.
How the IT audit process actually runs
Four stages, and the first one decides everything that follows. If you want the operational detail on running these well, that sits on our IT audit best practices guide. What follows here is what each stage is for, and where each one tends to go wrong.
Scoping: deciding what is in and what is out
Scope is negotiated, and most people do not realise it is negotiable.
An audit cannot examine everything, so somebody decides what it looks at: which systems, which controls, which period, which locations, which business units. That decision determines what the audit can find, which means it also determines what it cannot find.
This cuts both ways. A scope drawn too narrowly produces a clean report about a small corner of the estate, and a clean report is what most people asked for, which is exactly the problem. A scope drawn too widely produces a shallow look at everything and a findings list too long to act on.
The useful question at scoping is not what should we audit. It is what would we most hate to be wrong about. Scope towards that.
The asset inventory problem
Scoping runs into the same obstacle in almost every organisation: nobody has a complete, current list of what exists.
The configuration database is out of date, and cloud accounts have resources nobody has looked at in a year. There are systems running in one business unit that central IT has never heard of. Somebody is paying for a service on a personal card.
This is not a reason to delay the audit. The incomplete inventory is itself a finding, and usually a significant one, because every other control depends on knowing what you have. You cannot patch, monitor, back up or decommission a system you do not know about.
Start with what you know and let the audit surface the rest, because an audit that waits for a perfect inventory never starts.
Evidence: the request list and why it takes so long
The evidence request list is where audits consume the most internal time, and where most of the frustration lives.
The auditor asks for records, not descriptions. The access review for the last two quarters, signed off. The change tickets for a sample of production changes. The restore test report. The list of leavers and the corresponding account deactivations, with dates.
The reason this takes weeks is rarely that the controls do not work. It is that the evidence was never produced in a form anybody kept. The access review happened in a meeting, the change was discussed and approved on a call, and the restore worked but nobody wrote it down.
An auditor cannot accept any of that, and they are right not to. A control you cannot evidence is indistinguishable from a control you do not have, from the outside. That statement annoys people, and it stays true.
The organisations that find audits painless are the ones whose controls produce records as a by-product of running, rather than as a special effort at audit time. Getting there is mostly a matter of preparation, which we cover in detail on prepare for an IT audit.
Security controls assessment, and what sampling really proves
The auditor now tests the controls, and almost always by sampling.
They will not review every one of last year's changes. They will take twenty-five and check each one against the process. If all twenty-five hold, the control is assessed as effective. If three fail, the control is assessed as not effective, and the finding is about the control rather than about those three changes.
This is worth understanding properly, because it shapes what a clean report means.
A passed sample says the control worked on the instances examined. It does not say the control always works. It says that if the control were broadly broken, a sample of that size would probably have caught it. That is a real and useful statement, and it is weaker than we are fine.
It also means failures are more informative than passes. Three failures out of twenty-five is not a small problem affecting three changes. It is evidence of a process that does not hold, and the correct response is to fix the process rather than the three tickets.
The report, and how findings get rated
The report lists findings, each with a rating, usually on a three or four point scale from critical to low.
The ratings are judgements, not measurements, and they are the part of the report most worth arguing with. An auditor rates against likelihood and impact as they understand your business, and they do not know your business as well as you do. A finding rated medium may be existential for you. One rated high may concern a system being decommissioned next quarter.
So read the ratings as a starting position. Where you disagree, say so during the report review, before the report is final, and record the reasoning. We accept this and here is why is a legitimate management response. We ignored it is not, and six months later those two look identical unless somebody wrote the reasoning down.
The IT audit findings that come back again and again
Five findings show up across organisations of every size and sector. None of them is exotic. All of them are invisible to scanning, and every one is a question about ownership rather than technology. Our page on common IT audit findings goes into remediation detail; here the point is why these five in particular keep recurring.
Access that outlived its purpose
Accounts belonging to people who left. Permissions granted for a project that finished, and administrative rights issued for one afternoon of troubleshooting and never withdrawn.
This is the most common finding in IT audits and the most persistent, because granting access is a fast, helpful act and removing it is a slow, thankless one. Leaver processes catch the obvious cases and miss contractors, service accounts, shared credentials and anyone whose departure went through a different route.
The audit test is simple and uncomfortable. Take the current list of active accounts with elevated privileges. Ask, for each one, who this is and why they have it. In most organisations somebody cannot answer for a meaningful share of the list.
What makes this a security finding rather than a housekeeping one is that dormant privileged accounts are not monitored. Nobody notices unusual activity on an account nobody thinks about.
Systems nobody owns
Every estate has them: a server supporting a discontinued product, a reporting tool a departed team built, a database that something important reads from and nobody can say what.
These systems fall out of every process that depends on an owner. They do not get patched, because patching needs someone to approve downtime, and they do not get monitored meaningfully, because nobody knows what normal looks like. They do not get decommissioned, because nobody will sign off that switching them off is safe.
The finding is almost always asset ownership is not defined, and it sounds administrative, which it is not. An unowned system is one where a compromise would run for a long time before anyone noticed, because nobody is looking. Sorting this out is usually an infrastructure exercise as much as a security one, which is why it lands with IT infrastructure services work as often as with the security team.
Backups that have never been restored
The backup job runs nightly and reports success, and has done so for three years.
Nobody has ever restored from it.
This finding produces more discomfort in the room than any other, because the control looks healthy from every angle until it is tested. A successful backup job means data was written somewhere. It does not mean that data is complete, readable, or recoverable inside a timeframe the business could survive.
The things that go wrong are mundane. A database backed up without its transaction logs, so it restores to an unusable state. An encryption key held only on the system being backed up. A restore that technically works and takes eleven days.
The audit test is the only test that counts: restore something, to a clean environment, and time it. Anything else is a report about a job, not evidence of a capability.
Logging that records the wrong things
Logs are collected, retention is configured, and the volume is enormous. And when an incident happens, the events anyone needs turn out not to be in there.
The usual pattern is that logging was configured for operations rather than for investigation. It captures errors and performance, which is what the platform team needed. It does not capture successful authentications, permission changes, data exports, or administrative actions, which is what an investigation needs, because those are not errors.
Retention is the second half of it. Investigations usually establish that an intrusion began well before anyone noticed. If retention is thirty days and the intrusion began in month three, the logs that would answer the question have already rolled off.
This finding also explains why organisations with a security operations centre still get audit findings on logging. Monitoring what you collect and collecting the right things are different problems.
Third-party access nobody reviews
A vendor was given access to support an implementation. The implementation finished in 2023. The access is still live.
Third-party access accumulates because it is always granted under time pressure, usually for a good reason, and it is never anybody's job to review. The vendor will not tell you they no longer need it. Procurement tracks the contract, not the credentials. Security does not always know the access exists.
The finding is that there is no periodic review of external access, and the risk is straightforward: your control environment now includes theirs, and you have no visibility into it. When a supplier is compromised, the path into your estate is the access you gave them and forgot about.
The list of parties with standing access to your systems is one of the most revealing documents in any audit, largely because so few organisations can produce it on request.
What happens after the report, and where IT audits fail
The audit ends, the report lands, and the organisation exhales. That exhale is where most of the value is lost.
Audits do not fail because the auditors missed things. They fail because the findings never become work. Six months later, a meaningful share of them are still open, and the same finding appears in the next audit with a note that it was raised previously.
There are three reasons for this, and none of them is laziness.
The findings arrive as a list rather than as a plan. A list has no sequence, no owner and no estimate, and nothing gets done from a list.
The findings belong to nobody. A finding about leaver access spans HR, IT and the business unit. Three teams share it, so no single team owns it, and shared ownership resolves to nobody.
And the findings compete with delivery work, badly. Remediation has no launch date and no customer waiting. It loses every prioritisation conversation it enters, quietly and repeatedly.
From finding to remediation plan
The fix is unglamorous: convert the report into a plan before anyone moves on.
Give each finding one named owner, a person rather than a team, a date, and a definition of done that says what evidence will exist when it is closed, because improve access management can never be finished and quarterly privileged access review, with sign-off recorded can.
Then group the findings, because they are not independent. Half a report usually traces to two or three root causes. No asset register explains the unowned systems, the patching gaps and part of the logging problem. Fixing the register closes several findings at once, and the plan should say so rather than tracking them as separate tickets.
Sequence by root cause, not by the auditor's severity rating. The rating tells you what the auditor thought was worst. The root cause tells you what will stop the same findings returning next year.
Residual risk, and deciding what you will live with
You will not fix everything, and pretending otherwise is why remediation plans stall.
Some findings cost more to remediate than the risk justifies, some concern systems being retired, and some require a vendor change already scheduled for next year. Deciding not to act on those is legitimate risk management. Failing to decide is not.
The difference is entirely in the record. An accepted risk has a named accepter at an appropriate level, a stated reason, a review date, and a note of what would change the decision. An ignored finding has a row in a spreadsheet and nothing else.
That record does real work later. It is what turns we knew and we chose into a defensible position, and it is the thing that separates an organisation managing its risk from one that simply has some.
Review accepted risks on the date you set, because circumstances move. The system you were retiring is still running, the compensating control you relied on was decommissioned, and an acceptance nobody revisits becomes a gap nobody noticed.
When an IT audit is the wrong tool
An audit is not the answer to every security question, and commissioning one at the wrong moment wastes months.
If you are in an incident, stop, because an audit examines a steady state. During an active compromise you need investigation and containment, on a different clock entirely. Audit afterwards, when you want to know how it happened and what else looks like that.
If you already know the answer, skip the audit and fix the thing. Organisations sometimes commission an audit to build the case for work everyone agrees is needed. It produces a report saying what the team said a year ago, and costs a quarter. If the obstacle is funding rather than knowledge, an audit is an expensive way to have an argument.
If the question is can someone actually get in, an audit will not tell you: that is a penetration test. Audits assess controls rather than exploitability, and a control environment can be well documented and still have a path through it.
If nothing has been built yet, there is nothing to examine. A control designed last month has no history to sample and no evidence to produce, so let it run first.
And if the previous report's findings are still open, another audit is not the move. It will find the same things, cost the same money, and add a second unresolved list to the first, so close what you have.
The honest summary: an audit is a good instrument for finding out what you do not know about a running estate, and a poor one for everything else. Knowing which situation you are in is worth more than the audit itself.
Role of IT audits in cybersecurity: quick answers
What is the role of IT audits in cybersecurity?
An IT audit independently checks whether security controls exist, work as described, and can be evidenced. It is a detective control: it does not stop an attack, it reveals where the real control environment has drifted from the assumed one. Audits find what scanning cannot, because most of what they examine is about ownership, process and evidence rather than configuration.
How often should an IT audit be performed?
There is no universal interval, and any figure quoted as a standard usually has no source. Cadence follows the drivers: regulatory obligations set their own schedule, customer and insurer requirements set theirs, and internal audit plans are normally annual with a rolling scope. The more useful trigger is change. A migration, an acquisition, a new business line or a significant reorganisation each invalidate parts of the last audit regardless of when it ran.
What is the difference between an IT audit and a penetration test?
A penetration test tries to break in and proves a specific path works. An IT audit examines controls and asks whether they operate consistently and can be evidenced. A pen test can be clean while an audit finds significant gaps, and the reverse also happens. They answer different questions and neither substitutes for the other.
Who should conduct an IT security audit?
Somebody independent of the people who built and run the controls. That can be an internal audit function, provided it reports outside the IT line, or an external party. Independence is the requirement, not who employs them. Where the output has to satisfy a regulator, a customer or an insurer, that party usually specifies who is acceptable.
What are the most common IT audit findings?
Five recur across organisations of every size: access that outlived its purpose, systems with no named owner, backups never tested by restore, logging that captures the wrong events or retains them too briefly, and third-party access nobody reviews. Every one is a question about ownership rather than technology, which is why security tooling does not surface them.
Where to take your next cybersecurity audit
An audit report is easy to commission and hard to act on. The findings are usually correct, the ratings are usually reasonable, and six months later half of them are still open, because nobody owned the remediation and nobody decided which risks the business would accept.
If you are scoping an audit, the most useful hour you can spend is on the question of what you would most hate to be wrong about. If you are holding a report that has not moved in a while, the useful hour is spent grouping the findings by root cause.
Either way, talk to 4Labs Technologies. Bring the findings list, or the scope you are drafting. A conversation about your actual control gaps is worth more than a conversation about audit methodology.
