IT security audit – what does it cover?
An IT security audit is a structured assessment of how an organisation protects systems, data and processes — from infrastructure to procedures. It does not have to be a yearly statutory obligation for every company, but in practice it is often the best way to check whether security measures actually work, rather than merely existing on paper.
Below I describe the typical scope, process and outcome of an audit. If you are interested in working together, see the IT security audit offer. If you are comparing methods, pentest vs audit is a separate, complementary topic.
Contents
- What an IT security audit is
- What the audit covers
- Infrastructure and network
- Systems, servers, configuration
- Cloud and identity (Entra ID)
- Web application and API
- IT/OT
- Procedures, access, backups, continuity
- Audit vs pentest, scan, code review, compliance audit
- Step-by-step process
- Data and documents needed
- What the report contains
- Prioritising recommendations
- Time and pricing — what it depends on
- When an audit is worth doing
- Audit after an incident
- Audit required under KSC
- FAQ
What an IT security audit is
An IT security audit is not a single scan or a one-off hacking test. It is an assessment process: which assets and services are critical, which controls should protect them, whether those controls are actually implemented, whether they work in practice, and where the gaps are against an agreed baseline (e.g. internal policy, ISO 27001, client requirements or preparation for regulation).
An audit can be internal (the organisation's own team) or external (an independent provider). In both cases a useful outcome is a list of findings with justification, risk rating and recommendations — not a generic "improve your security" statement.
What the audit covers
Scope always follows from the contract and the company's context. A typical IT security audit covers these layers:
- technical — network, servers, workstations, cloud, applications, backups,
- organisational — policies, roles, training, access management,
- process — incidents, change management, offboarding, business continuity,
- evidentiary — does what is documented match what actually happens.
An audit does not have to cover everything at once. It often starts with a critical area (e.g. identity + servers + a client-facing application) and expands in later cycles.
Infrastructure and network
Here the auditor analyses network architecture: segmentation, firewall rules, VPN, Wi-Fi, internet-facing exposure, DNS and basic monitoring. The goal is to check that critical systems are not reachable more broadly than necessary, and that rules are justified rather than "left open temporarily for three years."
This also covers edge devices, guest access points, remote access for employees and vendors, and router/switch configuration. The point is not to tick a checklist, but to assess whether the architecture actually limits the blast radius of an incident.
Systems, servers, configuration
The review covers physical and virtual servers, operating systems, hardening, patching, local accounts, listening services, network shares and password policies. The auditor checks whether production servers run on default settings, whether there are forgotten service accounts, and whether patch management has an owner.
In hybrid environments it matters to distinguish what is maintained locally versus by a provider — and who is responsible for which part of the configuration.
Cloud and identity (Entra ID)
In many companies the key security control point is the identity directory — most often Microsoft Entra ID (formerly Azure AD). The audit typically covers:
- password policies and MFA,
- privileged accounts and admin roles,
- app registrations and API permissions,
- Conditional Access,
- sign-in logging and alerts,
- integration with Microsoft 365 / SharePoint / Teams.
In public cloud (Azure, AWS, GCP) subscription configuration is also reviewed: IAM, storage, networking, logging, encryption and environment separation. A common mistake is treating the cloud as "magic," while configuration responsibility actually sits with the customer under the shared-responsibility model.
Web application and API
If a company runs its own application or API, the audit typically covers authentication, authorisation, sessions, input validation, error handling, secrets, HTTPS configuration, security headers, event logging and environment separation. This does not replace a full application penetration test, but it lets you assess architecture and baseline hygiene.
Combined with an audit, penetration testing of selected systems is often worthwhile — especially when the application is publicly exposed or processes sensitive data.
IT/OT
In manufacturing, logistics or energy, the audit may cover the IT/OT boundary: industrial networks, PLCs, SCADA, operator workstations, isolation rules from the office network, and update procedures for devices that cannot be "patched on a Friday evening." OT scope needs its own plan — intervening without understanding the production process can be risky.
Procedures, access, backups, continuity
The organisational layer can matter as much as the servers. The auditor typically checks:
- user onboarding and offboarding,
- granting and revoking permissions,
- password policies and MFA,
- incident response procedures,
- backups and restore testing,
- business continuity plans, or the lack of them,
- change management and exceptions.
This is often where the gap shows up: the procedure says one thing, while shared accounts, no MFA on mail, or a backup that has never been tested say something else.
Audit vs pentest, scan, code review, compliance audit
These are different, often complementary tools:
| Method | What it does | What it usually does not replace |
|---|---|---|
| IT security audit | Assessment of technical and organisational controls, gaps against a baseline | Actively exploiting vulnerabilities in production |
| Penetration test | Simulated attack on a chosen target | A full review of policies and backups |
| Vulnerability scan | Automated detection of known weaknesses | Assessment of processes and business logic |
| Code review | Source-code analysis | Network configuration or HR procedures |
| Compliance audit | Verification against a regulation/standard | An in-depth exploit test of an application |
More on the differences between pentest and audit: separate article.
Step-by-step process
A typical external audit looks like this:
- Kick-off — objectives, scope, exclusions, contacts, timing.
- Gathering materials — diagrams, policies, system lists, read access.
- Interviews — IT, security, process owners, sometimes HR or compliance.
- Technical review — configurations, log samples, read-only tests, possibly scans.
- Gap analysis — comparing the current state with the target model or checklist.
- Draft report — verifying findings with the client.
- Final report — findings, risk, recommendations, priorities.
- Optional retest — confirming that selected findings were closed.
A good audit minimises disruption to operations — but it does require time from people on the client side.
Data and documents needed
Before starting, it helps to prepare:
- a list of critical systems and services,
- a network diagram (even a sketch),
- security policies and procedures,
- a list of privileged accounts,
- information about backups and the last restore test,
- a register of exceptions to policies,
- contracts with key IT vendors,
- results of previous audits or scans (if any).
The better the input material, the less time the auditor spends "hunting for the truth" instead of assessing risk.
What the report contains
An IT security audit report usually includes:
- an executive summary written for decision-makers,
- a description of scope and methodology,
- a map of assets / areas covered by the audit,
- a list of findings with evidence,
- a risk rating (e.g. critical / high / medium / low),
- remediation recommendations,
- a suggested action timeline,
- a reference to the relevant standard or internal policy.
A good report does not just say "enable MFA" — it explains why, what the risk actually is, and what the first step should be.
Prioritising recommendations
Not every gap needs immediate action. Sensible prioritisation considers:
- impact on business continuity and data,
- ease of exploitation by an attacker,
- effort required to fix,
- dependencies (e.g. MFA before exposing an app to the internet),
- contractual or regulatory requirements.
In practice, you first close items that combine high risk with a reasonable fix cost — shared admin accounts, a backup with no restore test, critical systems missing updates.
Time and pricing — what it depends on
Audit time and cost depend on many factors — there is no universal price table:
- number of locations (one office vs a network of branches),
- number and type of systems (servers, cloud, in-house applications),
- scope (IT only vs IT/OT, or only selected areas),
- quality of documentation (ready vs recreated during the audit),
- share of cloud and Entra ID vs an entirely on-premises environment,
- an OT component — needs more planning,
- number of interviews and availability of people,
- type of report (short vs full, language, audience),
- retest after fixes are implemented.
A quote without a short discovery call and a defined scope is usually misleading. It is better to agree on the goal (e.g. "before certification," "after an incident," "preparing for KSC") and match the depth of the audit to it.
When an audit is worth doing
An audit makes sense, among other situations, when:
- the organisation or infrastructure is growing,
- you are rolling out a new ERP, a client-facing application, or a cloud migration,
- you are preparing for certification or a large client's requirements,
- there has not been an independent assessment in years,
- leadership asks "are we secure" and expects facts, not assumptions,
- you are planning to implement KSC / NIS2 requirements.
It does not have to be "once a year for every company" — but after major changes or growing risk it is worth returning to an assessment.
Audit after an incident
After an incident (ransomware, data leak, account takeover) an audit has a different goal than a routine one: establishing the entry vector, the scope of compromise, what else needs isolating, and which controls failed. It is often combined with forensic analysis and a recovery plan.
Speed matters here, but so does careful documentation — both for your own learnings and for a potential conversation with an insurer, a client or an authority.
Audit required under KSC
This is a separate context from a voluntary "for good order" audit. The National Cybersecurity System (KSC) Act introduces, among other things, a mandatory audit for key entities — at least once every 3 years.
Key distinctions (legal status: July 2026):
- A key entity that was previously not an operator of essential services (OUK) must complete its first audit by 3 April 2028.
- Existing OUK operators continue their 3-year audit cycle under the previous rules.
- An important entity has no fixed 3-year cycle in the Act, but the authority may order an audit.
An audit in the KSC sense concerns the information security management system (ISMS) and related controls — it is not automatically the same as a narrow technical audit of a single application. Preparation combines documentation, processes and technical verification. More on getting started in practice: NIS2 in practice and the KSC hub.
Penalties for non-compliance under the KSC regime apply from 3 April 2028 — it is worth confirming the details of entity qualification with legal counsel.
FAQ
Does every company have to run an IT security audit every year?
No — a universal yearly statutory obligation does not apply to every organisation. Exceptions include contractual, sector, certification or regulatory requirements (e.g. KSC for a key entity). A voluntary periodic audit still tends to be a sensible idea.
Does an audit replace a pentest?
No. An audit assesses the broad picture of controls; a pentest actively tests whether an attack on a chosen target is possible. Many projects combine both — with a clearly defined scope for each.
Is a vulnerability scan the same as an audit?
A scan is a tooling component. An audit interprets the results in the context of architecture, processes and business risk.
How long does an audit take?
From a few days (narrow scope, small company) to many weeks (multiple locations, OT, full documentation). Kick-off and the availability of people on the client side strongly affect the timeline.
Does an audit guarantee compliance with KSC or GDPR?
No — an audit identifies gaps and recommendations. Confirming regulatory compliance depends on the full scope of requirements and the entity's qualification. GDPR requires appropriate measures and an evaluation of their effectiveness — it does not have to be called an "IT security audit" (more on GDPR).
Do all recommendations need to be implemented right after the audit?
No — prioritisation is part of the audit's value. Implement first what genuinely reduces risk within the horizon the organisation accepts.
---
Want to discuss the scope of an audit for your infrastructure? See the IT security audit offer or reach out via contact.