blog-image

How to Conduct a Holistic IT Audit: Scope, Sequence, and the Seams Between Domains

Most IT audits test every domain and nothing between them.

Access control gets audited, change management gets audited, and backups get audited. Each domain has an owner, a checklist and a section in the report. Then a leaver keeps their account for four months, because removing it needed HR and IT to agree something neither team was audited on.

That gap is not an oversight by the auditor, it is the shape of the audit. Work gets divided by domain, so evidence gets gathered by domain, and the space between two domains belongs to nobody. In a large estate, that space is where control is actually lost.

This is what holistic should mean. Not a longer checklist and not more domains, but an audit designed to cover the joins. So this page answers how to conduct an IT audit that covers the joins: how to scope the audit universe, which domains to test, the four seams that matter most, the five phases of running it, and the practices that decide whether any of it changes anything. If you want the case for auditing at all, our post on makes it, and this page assumes you are past that. At 4Labs Technologies we scope and run these with enterprise clients, and the hard part is never the testing.

Stay Ahead With 4Labs

Get expert insights, security briefings, and the latest innovations in your inbox.

Name

Email

Phone Number

Your Message

Our Services

Digital Marketing

Staff Augmentation

IT Infrastructure

Software Development

Web & App Development

Industries

Cryptocurrency and Blockchain

Banking, Financial Services, and Insurance (BFSI)

Lending and FinTech

Energy and Utilities

Automotive and Manufacturing

E-commerce and Retail

Case Studies

Financial Services Test Automation

AI-Driven Customer Risk Profiling

Elevating Mobile Performance

Jewelry Client Transformation

AI Underwriting Revolution

Advanced Cybersecurity Solutions

Eyewear Retailer Transformation

Revolutionizing Manufacturing Operations

Offshore Development Excellence

Company

About Us

Careers

Let's Connect

Business Referral

Engagement Model

Partnership Programs

Resources

Blogs

iso_icon2

Copyright © 2026 4Labs Technologies. All Rights Reserved.

Privacy Policy

Terms & Conditions

Accessibility

What Makes an IT Audit Holistic

The word gets used as a synonym for long. It should mean something structural.

Domain-by-Domain Auditing and What It Leaves Untested

The standard IT audit scope is a list of domains. Identity, infrastructure, change, data, resilience and vendors, and each gets a section, a set of tests and a conclusion.

This is efficient and it is how audits get staffed, because each domain has people who understand it. It also has a predictable blind spot. When a control depends on two domains cooperating, each side is tested on their half and neither is tested on the join.

Two symptoms tell you this is happening in your estate. The first is a report where every section concludes satisfactory and an incident happens anyway. The second is a finding that nobody accepts, because it belongs to a process that crosses two teams and each believes the other owns it.

A holistic audit adds one question to every domain: what does this control depend on that sits outside this domain? That question produces a different test, and often a different finding.

The Seams Are the Point, Not the Page Count

An audit that covers twelve domains instead of six is not more holistic. It is only longer, and length is not coverage.

What makes it holistic is the audit universe being drawn as a whole before it is divided, so the joins are visible when the work is split up. Draw the map first and the seams appear as lines between boxes, but divide the work first and the lines vanish, because nobody owns a line.

The practical difference is small and it changes the outcome. In a domain-first audit, the identity team is asked to show quarterly access reviews. In a holistic audit, they are asked to show the reviews and then asked where the list of current employees comes from, who maintains it, and what happens when somebody moves department. The second question is where the real answer is.

Four seams matter most in a large estate, and each gets its own section later on this page.

Internal IT Audit, External Audit, and Who Runs Which

Two different exercises get called the same thing, and mixing them wastes a quarter.

An internal IT audit is run by or for the organisation, to find out what is true. It can be scoped freely, it can go wherever the risk is, and its output is a list of things to fix. Nobody outside needs to accept it.

An external or certification audit is run by an independent party against a defined standard. The scope is set by the standard rather than by your risk, and the output has a status: pass, qualified, or a set of nonconformities.

A holistic audit is an internal exercise. It is the one you run to know your estate, and it is the one that makes the external audit uneventful. Running it against a certification scope defeats the purpose, because the standard decides what matters rather than your risk.

Where both exist, sequence them. Internal first, remediate, then external, because the reverse order means paying an external firm to find what you could have found yourself.

Scope the Audit Universe Before You Plan Anything

IT audit planning starts one step earlier than most guides say. Before the plan, you need to know what exists.

Start With the Asset and System Inventory

Every audit is bounded by the asset inventory it was scoped against. Anything missing from that list was not audited, and nobody will notice, because the report says nothing about what it did not see.

In a large estate the inventory is always incomplete. The configuration database was accurate when it was built, and since then departments have bought tools on cards, a subsidiary arrived with its own estate, two systems were decommissioned on paper and left running, and somebody stood up an environment for a project that ended.

So build the list from more than one source and compare. Identity provider applications, expense and procurement records, network discovery, DNS records, cloud billing, and the list the service desk supports. Where two sources disagree, that disagreement is a finding before the audit has started.

One question settles the quality of your inventory: can somebody name the owner of every system on it? Not the team, but a person. Systems with no named owner are where audits find the worst conditions, because nobody has looked at them in years.

Rank by Risk, Not by What Is Easy to Test

With a list in hand, rank it. A risk assessment here is a sorting exercise rather than a formal methodology.

Rank by what the system holds and what it can do. Regulated or personal data, money movement, production availability, and access to other systems. A low-value application with credentials into a core platform ranks higher than its own importance suggests, and that pattern is missed constantly.

The ranking is what you defend when scope gets cut, and scope always gets cut. When somebody asks you to drop a third of the audit, the ranking makes that a decision rather than an argument.

Resist ranking by testability. The systems that are easy to test are the ones already well managed, with logs, documentation and a responsive owner. The ones that are hard to test are hard because nobody owns them, which is the reason they need testing.

Pick One Control Framework and Map the Others to It

Most enterprises carry several obligations at once. A control framework gives you a single structure to test against, and the rest map onto it.

Pick one as the spine, because it matters less which one than that there is one. Then map the other obligations to those controls, so each obligation points at a control rather than at its own separate test.

Without this, the estate ends up with four overlapping control sets, and the same access review gets tested four times by four teams asking for the same evidence in four formats. That is the tax an enterprise pays for never choosing a spine.

Test Once, Satisfy Several Reports

This is the largest saving available in enterprise audit, and it goes by the name control rationalisation.

The method is plain: list the controls you test, list the obligations you answer to, and draw the lines. Where one control satisfies four requirements, test it once and produce evidence once, with the mapping written down so each report can cite it.

What makes it work is agreeing the evidence format in advance with everybody who will ask for it. The same access review, in the same format, accepted by all four. That agreement takes a meeting and saves a quarter of a year of duplicated fieldwork.

What it does not do is reduce the controls themselves. Rationalisation removes duplicated testing, not coverage, and anybody presenting it as a way to test less has misunderstood it.

Write Down What Is Out of Scope, and Who Agreed

The out-of-scope list is the most useful page in the whole audit, and it is usually missing.

Everything you decided not to test is a risk somebody is carrying without knowing. Writing it down turns a silent gap into a decision with a name against it. That is the same discipline that makes a software testing plan worth writing, and it works the same way here.

Be specific. Subsidiary systems in the Asia region are out of scope for this cycle is useful. Some legacy systems excluded is not, because nobody can act on it.

Get it agreed by whoever would be accountable if something went wrong in the excluded area. If that person will not agree, you have found the first real finding, and you have found it before spending a day on fieldwork.

The Domains a Holistic IT Audit Covers

Seven domains carry most of the risk. Treat this as an IT audit checklist at the level of what to test, not a list of tick boxes.

Identity and Access Management

Identity and access management is where audits start, because it decides what every other control is worth.

Test the joiner, mover and leaver process end to end rather than the access list. Sample people who joined, moved and left in the period, then trace what happened to their access and how long it took. The list tells you the state today. The trace tells you whether the process works.

Privileged access gets its own pass. Who holds administrator rights, why, when it was last reviewed, and whether privileged sessions are logged separately from ordinary ones. Shared administrator accounts are a finding on their own, because nothing done through one can be traced to a person.

Also test the exceptions. Every estate has accounts that break the rules for a reason: service accounts, break-glass access, the contractor with production rights. The finding is never that they exist. It is that nobody reviews them.

Infrastructure and Cloud

The infrastructure domain covers servers, networks, endpoints and cloud infrastructure, and the last of those has changed what this section means.

On-premises, the questions are hardening, patching, network segmentation and physical access, while in cloud they become configuration, identity policy, public exposure and cost of the same mistake at scale, since one misconfigured storage bucket does what a misconfigured file server could never do.

Test for the things nobody meant to leave: environments spun up for a project and never removed, snapshots holding production data in a test account, and services reachable from the internet that nobody intended to expose.

Where the estate spans both, audit both halves to the same standard. Our post on cloud versus on-premises infrastructure covers how the trade-off gets decided, and the audit point is that whichever you choose, the weaker half sets your real posture.

Change and Release

Change management testing is a sample of production changes and a check that each was requested, approved, tested and recorded.

The emergency change is where teams lose it. Something broke at night, somebody fixed it, and no record exists, so look for a defined emergency path with retrospective approval, because banning emergency changes produces undocumented ones rather than fewer ones.

Test evidence is the second gap. A change that was tested but left no record is, to an audit, a change that was not tested. Our post on security testing in the development lifecycle covers how to make that evidence a by-product of the work.

In estates that release frequently, do not judge the process by its ceremony. A pipeline with automated gates and a full audit trail is stronger than a change advisory board that meets weekly and rubber-stamps.

Data Governance and Retention

Data governance answers three questions: what data you hold, where it is, and how long you keep it.

Most enterprises fail the second. Data spreads into reporting tools, spreadsheets, test environments and inboxes, and none of those copies appears on the map. Test by following one sensitive record through the estate and listing everywhere it lands.

Retention is where the audit gets uncomfortable. Policy says one thing, platforms default to another, and backups hold data long after the live system deleted it. Where a regulation gives people a right to have data removed, test whether removal actually reaches the copies.

Classification only matters if it drives something. A scheme with four labels that changes no access rule and no retention period is documentation, not a control.

Resilience: Backup, Recovery and Continuity

This domain gets audited on paper more than any other. Business continuity and disaster recovery plans exist everywhere and get tested almost nowhere.

The test is not whether backups run. It is whether a restore was performed, by whom, how long it took, and what went wrong. A restore test with no problems recorded reads as a test that was not really run.

Ask what the business believes the recovery time is, then compare it with what the plan says. Those two numbers are different in most organisations, and nobody discovers it until the day it matters.

Test the dependencies too. A recovery plan that assumes the identity provider is available, or that a key person answers the phone, has a single point of failure written into it.

Third Parties and What They Run for You

Third-party risk is now a large share of the estate, and most inventories do not show it.

Start with the list: every supplier who holds your data or runs a process for you. Build it from procurement records and expense data rather than from memory, because memory produces the suppliers people like.

For each significant one, test whether an assessment exists, when it was last done, and what the contract says about incidents, data return and right of audit. Those clauses are agreed at contract time or not at all.

The question auditors ask least and should ask most: what would happen if this supplier stopped tomorrow? Concentration risk hides here, because three critical services often turn out to run on one provider.

People, Process and Shadow IT

The last domain is the one that is hardest to sample and produces the most surprising findings.

Shadow IT is not a policy failure. It is a signal that the sanctioned tool was too slow or did not exist, and the finding should record both the tool and the reason. Find it through expense records, browser telemetry where you have it, and asking teams what they use rather than what they are allowed to use.

Test awareness by outcome rather than by completion rate. Everybody completed the training is a statistic. What people do with an unexpected request for credentials is the control.

Also test the human dependencies. Where one person is the only one who can perform a control, that is a finding regardless of how good they are, and it is the finding most likely to be argued with.

The Seams Between Domains, Where Enterprise Risk Hides

This is the section no competing page has. Four seams, each one a control that two teams half own. Information security in a large estate fails here more often than it fails inside any single domain.

HR to IT: the Joiner, Mover and Leaver Seam

The most common seam, and the one that produces the most findings across the whole programme.

Account creation and removal depend on HR telling IT that something happened. Audit the identity domain and you test whether accounts match the list. Audit HR and you test whether records are accurate. Neither test covers the handover, which is where it breaks.

Test it directly. Take ten people who left in the period and measure the time between their last working day and their access being removed. Then take five who changed department and check whether the old rights were revoked. Identity and access management is only as good as the trigger that feeds it.

The repair is structural rather than procedural. Tie account changes to an event that already gets recorded reliably, which is usually payroll, rather than to somebody remembering to send an email. A process that depends on nobody forgetting will be a finding every year.

Infrastructure to Application: Who Owns the Middle

The infrastructure team owns the server. The application team owns the code. Between them sit the runtime, the libraries, the configuration and the certificates, and ownership there is usually assumed rather than assigned.

This is why expired certificates take down production at organisations with mature change management. The certificate belonged to the middle. Both teams believed it was monitored.

Test by picking one production service and asking, separately, who patches the runtime, who renews the certificate, who owns the configuration, and who is paged when it breaks. Compare the answers. Where they differ, you have found the seam.

The question generalises: for each layer of a running service, who is accountable? Any layer where two teams name each other is untested and unowned.

Security to Recovery: the Restore Nobody Tested Under Attack

Disaster recovery plans assume a clean failure. Hardware dies, a site goes dark, and you restore.

Ransomware breaks that assumption. The backups may be encrypted too, the restore target may still be compromised, and the identity system you need to log in with may be the thing that was attacked. A recovery tested against a disk failure proves nothing about a recovery under attack.

This seam exists because security and resilience are different teams with different plans. Security exercises an incident and resilience exercises a restore, and nobody exercises an incident that requires a restore.

Test it as one scenario. Walk through a compromise that reaches the backup environment and ask who decides the estate is clean enough to restore into, and how they would know. That conversation exposes more than either team's own exercise.

You to Your Vendor: the Shared Responsibility Seam

Every cloud and managed service runs on a shared responsibility split. The provider secures some layers, you secure the rest, and the boundary is written in a document most customers read once.

The seam appears when both sides assume the other holds a control. Backups of data inside a SaaS platform are the classic case: the provider protects the platform, the customer often assumes that includes their data, and neither is taking a recoverable copy.

Test it by naming controls rather than layers. For each significant service, write down who runs backups, who reviews access, who patches, who monitors, and who would detect an incident. Then confirm both sides agree. Third-party risk assessments rarely ask this, because they ask about the supplier's certifications rather than about the split.

Where an answer is the provider does that, ask for the evidence. A certification report says the provider has controls. It does not say your data is backed up in a way you can restore.

How to Run the Audit: the Five Phases

The IT audit process runs in five phases. The first two decide the quality of the other three, and they are the two most often rushed.

Phase One, Planning and Agreeing the Scope

Planning turns the ranked universe into a scope statement somebody has signed.

The statement names what is in, what is out, which period is covered, which framework is the spine, who the audit contacts are in each team, and when fieldwork happens. That last item is not administration. Fieldwork during a month-end close or a release freeze produces poor evidence and irritated people.

Agree the evidence formats now rather than during fieldwork. Asking for an access review in a particular form three weeks in advance gets a clean file. Asking during fieldwork gets a screenshot.

One question worth asking every stakeholder at this stage: what would you most like this audit to look at? The answers are better than a risk register, because people know where their own estate is weak.

Phase Two, Walkthroughs Before Any Testing

A walkthrough is a conversation with the person who performs a control, in which they show you how it actually works.

Skipping this is the most common mistake in the IT audit phases, and it costs the whole cycle. Test against documentation and you test a control that may not exist. The walkthrough finds the drift between the written process and the real one, and the drift is almost always in the documentation's favour.

Three questions carry it. What exactly do you do. Show me the last time you did it. What happens if you are away that week. The third one exposes single-person dependencies that no document mentions.

Walkthroughs also fix your sampling. Once you know how a control really runs, you know which population to sample from, and you stop asking for evidence that was never produced.

Phase Three, Fieldwork, Sampling and Evidence

Fieldwork is control testing against the population the walkthrough identified.

Sampling should be defensible rather than large. State how the sample was chosen, cover the whole period rather than the convenient end of it, and include the awkward cases: the emergency change, the contractor, the system with no owner. An audit that samples only the tidy parts reports a tidy estate.

Audit evidence has to show the control operating over the period, name who performed it, carry a date, and come from a system rather than from somebody's recollection. Evidence that fails is a screenshot of today, a ticket marked done with no output, and an email saying the work is complete.

Raise exceptions as you find them rather than saving them for the report. The team gets a chance to produce evidence you could not find, and you avoid a report full of findings caused by looking in the wrong place.

Phase Four, a Report Somebody Will Act On

The IT audit report is read by three audiences: the team who has to fix things, the executive who has to fund it, and possibly a committee that sees only the summary.

Write for all three. A finding names the control, what was tested, what was observed, the risk in business terms, and what would close it. Rate it so the deadline follows from the rating rather than from negotiation.

The summary is the part most people read. It should say what the estate is like, not how many findings there were. Access controls are well run inside each system and the process that feeds them is not tells an executive something. Fourteen findings, three high tells them nothing they can act on.

Our post on common IT audit findings covers what happens to each finding after this point, including how to write the management response.

Phase Five, Follow-Up, the One Everybody Drops

Remediation tracking is the phase that decides whether the audit was worth running, and it is the phase with no owner.

The pattern is familiar. The report lands, the team fixes things, the audit team moves to the next engagement, and nobody checks. Twelve months later the same finding appears, rated higher because it is now a repeat.

Do three things. Check evidence at the deadline rather than accepting a status update. Where a date moves twice, escalate rather than reschedule, because a date that moves twice is an ownership problem. And carry every open finding into the next audit's scope automatically, so no finding quietly expires.

The follow-up is also where you learn whether your findings were any good. A finding that cannot be closed, or that the team argues with for months, was usually written about a symptom rather than a cause.

IT Audit Best Practices That Change the Outcome

Four IT audit best practices. Each one is cheap, and each one changes what the next audit finds.

Audit What You Do, Not What the Policy Says

Policy is a statement of intent. The audit trail is a record of what happened. Test the second.

This matters in both directions. A policy stricter than practice produces findings against a standard you set yourself, and a policy looser than practice hides good work behind a weak commitment. Where they differ, the honest fix is sometimes to change the policy rather than the practice.

The reflex to build: for every claim in a document, ask what artefact proves it, and where that artefact lives. If the answer is nowhere, the control is an intention.

Keep the Audit Universe Alive Between Audits

The audit universe decays the day it is built. New systems arrive, suppliers change, environments appear.

Keeping it current is a small standing job rather than an annual project. Tie it to events that already happen: a new supplier contract, a new environment, an acquisition, a system decommissioned. Each one updates the map at the moment somebody knows about it.

The payoff is that the next audit starts from something real instead of a month of discovery. It also makes the scope argument shorter, because everybody is looking at the same list.

Bring the Business Into Scoping Early

Audits scoped by IT alone test what IT controls. That is not the same as what the organisation depends on.

Ask business stakeholders one question: which systems would stop you working this week if they failed? The answers rarely match the IT priority list, and where they differ, the difference is the finding.

Early involvement also buys cooperation later. A department that helped set the scope provides evidence. A department that was audited without warning provides delays.

Carry Last Year's Findings Into This Year's Scope

Every open finding from the previous cycle goes into the next scope automatically, and every closed one gets a spot check.

The spot check is the part people skip, and it is where repeat findings get caught early. A control that was fixed and then stopped running looks identical to a control that was never fixed, and only a check tells you which you have.

This single habit converts an audit from an annual event into a cycle. Findings stop being a list that resets, and the estate stops presenting the same three weaknesses every year with different dates against them.

Quick Answers on Holistic IT Audits

Short answers to the questions people type first, each one standing alone.

What Is a Holistic IT Audit?

A holistic IT audit examines the whole technology estate as one system rather than as a set of separate domains. It covers identity and access, infrastructure and cloud, change, data, resilience, third parties and people, and it adds the controls that sit between those domains, such as the handover between HR and IT or the split of responsibility between an organisation and its cloud provider. The difference from an ordinary IT audit is not length. It is that the joins between domains are scoped and tested rather than assumed.

How Do You Conduct an IT Audit, Step by Step?

Build an inventory of systems and suppliers, rank it by risk, choose one control framework as the spine and map other obligations to it, then agree a written scope including what is out. After that the audit runs in five phases: planning and scope agreement, walkthroughs with the people who perform each control, fieldwork with defensible sampling and dated evidence, a report written for the team and the executive, and follow-up that checks evidence at each remediation deadline.

What Should an IT Audit Cover?

At minimum: identity and access management including privileged accounts, infrastructure and cloud configuration, change and release, data governance and retention, backup and disaster recovery with a tested restore, third-party and vendor risk, and the human side including shadow IT. A holistic audit adds the seams between those areas, because controls that depend on two teams cooperating are the ones no single domain owner is tested on.

How Often Should an Enterprise Run an IT Audit?

Most large organisations run a full internal cycle annually and test high-risk areas more often, but the calendar matters less than the triggers. Re-audit a domain when something material changes: a migration, an acquisition, a new critical supplier, a significant incident, or a change of ownership in a team that runs key controls. Between cycles, spot-check the controls that produced findings last time rather than waiting a year to discover they stopped running.

What Is the Difference Between an Internal and an External IT Audit?

An internal IT audit is run by or for the organisation to find out what is true, and its scope follows your own risk. An external or certification audit is run by an independent party against a defined standard, and its scope follows that standard rather than your priorities. Sequence them internal first, remediate, then external, so the independent audit confirms a position you already understand instead of discovering it for you.