How to Conduct an IT Security Audit?
.png)
DPO Consulting Joins Grant Thornton
Summary
An IT security audit is a methodical review of the controls protecting an information system, run to measure the gap between actual security and the expected level. It combines technical checks, process review and documentation review.
Why companies commission one has changed. Ten years ago an audit mostly reassured a board. Today it is demanded by an insurer, by an enterprise customer inside a vendor questionnaire, by a regulator under NIS2 or DORA, or by the GDPR, which requires regular testing of the effectiveness of security measures.
An IT security audit is a structured examination, run against a defined scope, that verifies whether the protections in place genuinely cover the risks the organisation faces. It produces a dated, documented and defensible finding, not a general impression.
Three things separate it from a vulnerability scan. It covers a contractually agreed scope, it measures against a reference framework, and it ends in prioritised recommendations. A scan tells you what is open, an audit tells you what is serious and in what order to fix it.
Under the GDPR, Article 32 requires controllers to have a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures. An audit is the most direct way to produce that evidence.
An audit matters because it surfaces what nobody looks at any more. Systems drift, leavers' accounts stay active, patches pile up, a firewall rule opened for a 2021 project was never closed. Four drivers come up repeatedly.
A well run audit in IT security also helps internally, turning a security budget argued over every year into a list of costed risks the board can actually arbitrate.
Security audits are not interchangeable. Each type answers a different question and needs different skills. In France, the ANSSI PASSI framework structures provider qualification around five activities, architecture audit, configuration audit, source code audit, penetration testing, and organisational and physical audit. The ANSSI published version 2.2 of that framework on 29 November 2024, introducing two qualification levels, substantial and high. The table below sets out the types most often requested.
A network audit examines segmentation, filtering rules, remote access and internet exposure. It usually surfaces permissive firewall rules that outlived their purpose, administrative services reachable from outside, and flat segmentation that lets an attacker move freely after a first compromise.
An application audit covers business applications, APIs and code. It combines source code review with application penetration testing, targeting injection flaws, broken authentication, session handling errors and data exposure. For a company shipping its own software, this is the audit with the best ratio of effort to risk avoided.
A cloud audit checks hosted environment configurations, identity and entitlement management, encryption and logging. Most cloud incidents come from misconfiguration rather than provider failure. The shared responsibility boundary between customer and provider has to be checked explicitly, not assumed.
An information security audit is broader than a technical one. It covers governance, data classification, policies, awareness and third-party management, usually against ISO/IEC 27001. It measures maturity, where the others measure exposure.
A compliance audit compares practice against a specific external requirement, a regulation, a framework or a customer contract. It does not hunt for every weakness, it verifies mandated points. Our guide to the cybersecurity compliance audit covers the method and the most frequent gaps.
An infrastructure audit covers servers, endpoints, backups, monitoring and physical access to technical rooms. It overlaps with architecture audit in the PASSI sense, and it is the one that exposes end-of-support systems kept in production for want of a migration budget.
How to do an IT security audit comes down to five stages, from scoping to action plan. The sequence matters as much as the content, because a badly scoped audit produces an unreadable report and recommendations nobody applies. The five stages below are those qualified providers follow.
Scoping fixes the systems in play, the tests permitted, the intervention windows and the points of contact. Too wide a scope dilutes the effort, too narrow a scope leaves the blind spot intact. This is also where the reference framework is agreed, without which findings remain opinions.
The inventory comes first. It lists assets, the data processed, data flows and dependencies on suppliers, then ranks them by business criticality. You cannot protect what you do not know you have, and an incomplete inventory remains the single most common finding by volume. Our cybersecurity risk assessment guide sets out the scoring method.
This phase compares declared controls against the controls actually in place. The auditor reviews configurations, access rights, applied policies and logs. The gap between the written policy and the live configuration is almost always the core of the report.
Testing supplies the evidence. External and internal penetration tests, privilege escalation attempts, verification of backup restores, simulation of an attack scenario. A backup that has never been restored is not a backup, it is an assumption.
The report ranks each finding by risk level, describes the supporting evidence and proposes a realistic fix with an owner and a deadline. A prioritised remediation plan, followed by a re-audit of the critical items, is what turns the exercise into measurable improvement.
Checks cover six domains whatever the size of the organisation. Depth varies, the list does not. A serious IT security audit questionnaire covers governance, identities, systems, data, detection and third parties, then asks for evidence behind every answer.
An audit without a reference framework produces contestable findings. Four frameworks dominate practice and they serve different purposes. ISO/IEC 27001 structures a management system, NIST organises the view by function, the CIS Controls give a concrete action list, SOC 2 answers a customer demand.
ISO/IEC 27001, in its 2022 version, sets the requirements for an information security management system, with a set of controls in Annex A. It is the only one of the four leading to organisational certification by an accredited third party, which makes it the reference when a customer wants external proof. Our analysis of ISO 27001, NIS2 and DORA explains how to run all three without duplicating work.
The NIST Cybersecurity Framework, published as version 2.0 in February 2024, organises security around six functions, Govern, Identify, Protect, Detect, Respond and Recover. Govern is the addition in 2.0. The framework certifies nothing, it provides a grid for positioning maturity and prioritising effort.
The CIS Controls set out 18 groups of safeguards organised into implementation groups, from the most accessible to the most demanding. For a mid-sized business this is the most operational of the four, because it says where to start rather than what to reach.
SOC 2 rests on the AICPA Trust Services Criteria, of which the security criterion is the only mandatory one. A Type II report assesses how controls operated over a period, typically six to twelve months, where a Type I only describes a position at a point in time. It is the standard ask from North American buyers.
The checklist below covers the five domains most often assessed, with the points to check and the evidence expected for each. Use it to run an internal pass before a provider arrives, which mechanically reduces the number of findings.
The inventory has to be complete and current, including cloud assets, mobile devices and software installed outside the official catalogue. Forgotten equipment and unlisted applications are the first entry points attackers use. Our cybersecurity audit checklist expands each control into a fuller list.
The audit checks for a periodic access review, effective deactivation of accounts when people leave, multifactor authentication on remote access and separate handling of privileged accounts. Dormant accounts remain the most frequent finding by volume.
Systems should be hardened to a documented standard and patches applied within deadlines defined by severity. The audit looks at the deadlines actually met, not the published policy, and identifies systems past end of support.
Checks cover data classification, encryption at rest and in transit, key management and retention periods. For personal data this overlaps directly with GDPR obligations and feeds the record of processing activities.
The organisation needs a tested incident procedure, isolated backups and verified restores, with defined recovery objectives. Our guide to cybersecurity incident response sets out what auditors and insurers both expect to see.
Knowing how to do an IT security audit is useless if the organisation is not ready to receive one. Preparation determines the quality of the result. An organisation arriving with no inventory and no documentation wastes auditor time it is paying for. Four actions change the outcome.
A written and applied cyber security policy saves considerable time, because it gives the auditor the internal reference against which reality can be compared.
DPO Consulting has supported European and international organisations on compliance and cybersecurity for more than ten years, with over 50 in-house experts. Engagements cover scope definition, the audit itself, prioritisation of fixes and tracking of remediation, with particular attention to where security and GDPR obligations overlap.
Having a third party carry out an IT security audit remains the fastest way out of internal blind spots. To measure your exposure and build a realistic remediation plan, start with security audit services. Where the security function is missing internally, an outsourced CISO takes on the steering over time. You can also talk to an expert at DPO Consulting to frame the scope before going to tender.
Four findings appear in the large majority of reports, inactive accounts left enabled, missing multifactor authentication on some remote access paths, critical patches applied outside the defined deadline, and backups never tested by restore. None is technically hard, all are failures of follow-through.
Common practice combines a full annual audit, penetration testing on internet-exposed systems at least once a year, and a targeted audit after any major architecture change or significant incident. Contractual or sector requirements can impose a faster cycle.
Cost depends on scope, the number of systems, the type of testing and the level of provider qualification required. It is built in auditor-days, not as a flat fee. An organisational audit on a limited scope and a full application penetration test are not comparable in effort. Always ask for a detailed quote broken down by phase rather than a single figure.
Check the qualification, the scope genuinely covered and the quality of the deliverable. In France, the PASSI qualification issued under the authority of the ANSSI attests that a provider meets a requirements framework across five audit activities. Ask for an anonymised sample report before signing, it is the best indicator of what you will receive.
An audit in IT security includes a scoping phase, information gathering, technical and organisational checks, testing, then a report with prioritised recommendations. The debrief with technical teams and with management is part of the deliverable, without it the report goes nowhere.
The time needed to carry out an IT security audit depends entirely on scope. An organisational audit at a mid-sized company runs to days, a full technical audit with penetration testing across several applications runs to weeks. Allow additional time for the debrief, and far more for remediation than for the audit itself.
Yes, and it often does. Retention periods exceeded, over-broad access to personal data, missing encryption on sensitive databases and transfers to suppliers without proper agreements all show up in technical findings. Those gaps then fall under the GDPR, which is why it pays to pair the technical work with a GDPR compliance audit.
.png)
.svg)
.png)
%20(1).png)
