Security audit
IT security audit
An IT security audit is a written review of how a company's information systems are designed, configured and operated, carried out against an agreed scope and reported with evidence. It measures the distance between what the organisation believes its systems do and what they actually allow, while the finding is still cheap to fix.
Architecture audit, configuration audit, penetration test
Most of the confusion around this purchase comes from one word standing for three different jobs. They answer different questions, need different evidence, and end in different documents.
Architecture audit
It asks how the system is put together. Which zones exist, what separates the public interface from the internal network, where the data lives, which flows cross a boundary and who is supposed to cross it. The findings are structural: a database reachable from the web tier, an administrator path that skips the jump host, a copy of production on a laptop. Fixing one of them changes a diagram before it changes a line of code.
Configuration audit
It asks how each component is actually set up, compared with a reference: a hardening baseline, the editor's own documentation, or a standard such as the OWASP Application Security Verification Standard for the web layer. This is where drift shows. The setting that was correct at launch and has not been touched since, the account created for a migration and never removed, the logging that stopped when the agent was upgraded.
Penetration test
It asks what an outsider can reach by attacking the running system. It is the only one of the three that attempts exploitation, and it needs its own written scope and authorisation. If your question is whether someone can get in, that is the engagement you want, and it is described on its own page.
The rest of this page is about the first two. The third is the one that gets confused with them most often, because all three are sold as an audit. Penetration testing: what a test covers and what it does not
What an IT security audit covers
A security audit is defined by its scope and by the reference it measures against, not by the tooling. On a small or mid-sized company the work usually sits in six places, and a report that skips one of them describes a smaller system than the one in production.
- The inventory: which machines, applications, domains, cloud accounts and external services actually exist. Shadow IT is the first finding of most audits, and it is usually the one nobody wanted to mention.
- Accounts and access: who can log in where, with which privilege, and whether that privilege is still justified. Shared accounts, dormant administrator access and access that survives a departure belong here.
- The boundary: what is exposed to the internet, which ports answer, which versions of which services are listening, and whether the exposed surface matches the stated architecture.
- Configuration against a baseline: transport encryption, security headers, error output, file permissions, the settings that decide whether a mistake becomes an incident.
- Patching and versions: which components are supported, which are not, and how the organisation finds out about a vulnerability in time to act on it.
- Logging, detection and recovery: what is recorded, who reads it, and whether a restore has ever been tested. An audit that stops at prevention describes half of the problem.
Coverage is agreed in writing before any collection starts. Two companies of the same headcount can need very different scopes, because what sets the effort is the number of moving parts, not the number of employees.
What an IT security audit does not cover
Most disappointment with an audit report comes from what the engagement was never asked to do. These are the usual gaps.
- Exploitation attempts. An audit reads, compares and reports. It does not try to break in, and a finding that says a weakness is probably exploitable is not the same as a demonstrated one.
- Source code review. An audit sees configuration and behaviour. It cannot see the branch nobody deployed, the dependency that is only reachable behind a feature flag, or the logic error that looks correct from outside.
- Social engineering and physical access. Phishing, pretexting and walking into a building are separate exercises with their own authorisation and their own risks for the people involved.
- Certification. An audit produces findings against a reference. It does not make an organisation compliant with a framework, and a report is not an attestation.
- Anything outside the agreed scope. A subsidiary, a legacy application, an environment the client left out of the inventory: untested, whatever the report implies. A provider who will not say plainly what falls outside is telling you something about the report.
The boundary between an audit and a penetration test is the boundary between reading and attempting. Both are useful. Only one of them produces a request that proves the problem.
How an IT security audit runs
The order matters more than the tooling. Each phase produces something the next one consumes, and skipping a phase is how an audit turns into a questionnaire with a score attached.
Scope and inventory
What is included, what is not, who authorises the work and who answers questions during it. Nothing is collected before that document exists: without it, the auditor is guessing at the size of the system and the client is guessing at the size of the bill.
Evidence collection
Read-only collection of configuration, exports of account and permission lists, network diagrams, the service inventory, and the logs the team already keeps. Where a document does not exist, its absence is a finding, not an obstacle.
Comparison against the reference
Each item is compared with the baseline the engagement named: the editor's documentation, a hardening guide, or a standard such as ISO/IEC 27001 for the management side and the OWASP Application Security Verification Standard for the application side. The reference is chosen before the collection, so the audit cannot select the benchmark its findings happen to satisfy.
Prioritisation
Every gap is placed against what the system does. A weak setting on a test environment and the same setting on the payment path do not carry the same urgency, and a report that lists them in the same paragraph pushes the reader to fix the wrong one first.
Reporting and follow-up
What was found, on which system, with the evidence that shows it, and what to do next. The follow-up is where the value lands: a finding that nobody re-checks after the fix is an opinion, not a result.
An audit run this way produces something a reader can act on months later, because every statement points at a system, a setting or a document rather than at an impression.
How often to repeat the audit
The honest answer is that the interval follows change, not the calendar. A company that adds a public service, migrates to a new host, opens a subsidiary or changes its identity provider has changed its exposure, and the previous report describes a system that no longer exists. A company whose systems have not moved can wait longer without taking on much new risk.
The usual rhythm is one full review a year, plus a narrower pass after each significant change. A full review covers the inventory, the architecture and the configuration. The narrow pass checks the part that moved: a new endpoint, a new tenant, a new integration, the accounts that came with it.
Between two audits, what keeps a report current is monitoring: whether the configuration still matches the baseline, whether new hosts appeared, whether an account was created outside the process. An audit that is only repeated every twelve months and never monitored in between measures the company on the day of the visit and says nothing about the other days.
What you receive at the end
The deliverable is a working document for whoever has to act on it, not a certificate for a drawer. Four things make the difference between a report that gets used and one that gets filed.
- An inventory with a scoped status per item: in scope and reviewed, in scope and not reviewed, out of scope and why.
- A gap per item, naming the system, the setting and the reference it was measured against, with the evidence attached or referenced.
- A priority order that follows the impact on this company, not the alphabetical order of a checklist.
- A remediation direction that the team can implement without a second engagement, and a stated way to check that the fix worked.
- A summary written for the person who signs, saying what the audit covered and what it did not.
Anything the auditor could not verify belongs in a separate annex with its reason. A suspicion dressed as a finding costs the team as much time as a real one, and teaches them to distrust the next report.
Who reads it
- Operations reads the inventory and the configuration gaps, because those are the ones it can close.
- The person who owns the application reads the priority order and the remediation direction.
- Whoever decides the budget reads the summary, and needs the scope section more than the findings list.
- An auditor or an insurer reads the method and the references, which is why both are written down rather than implied.
Where the references come from
Four public documents do most of the work, and none of them is ours. ISO/IEC 27001 defines the requirements for an information security management system, which is the frame a company uses to decide who is responsible for what and how the decisions are recorded. The OWASP Application Security Verification Standard gives a checklist of technical requirements for a web application, from authentication to data protection, and it is the reference that turns a vague configuration review into a list of testable statements.
The OWASP Top 10 is an awareness document, not a test plan: it names the risk categories web applications share most often, and it is useful to explain a finding to someone who does not read code. The ANSSI publishes guides aimed at French organisations, including material written for small and mid-sized companies that has no equivalent in most security vendors' documentation.
The NIS2 directive extends cybersecurity obligations to more sectors and to more kinds of entity in the European Union, and it asks the entities it covers to manage risk rather than to buy a product. An audit is one of the ways to answer that obligation. It is not the obligation itself, and no report replaces the decisions the entity has to take.
A reference is chosen before the work starts and named in the report. An audit that picks its benchmark after the findings is measuring the auditor's preferences.
Sources
Every technical statement on this page follows one of these public documents.
- ISO/IEC 27001 — information security management requirements
- OWASP Application Security Verification Standard — the technical requirements a web application is measured against
- OWASP Top 10 — the risk categories web applications share most often
- ANSSI, publications — the French national cybersecurity agency's guides, including the ones written for small companies
- NIS2 directive — the European text that extends cybersecurity obligations to more entities
Where a sentence on this page is not backed by one of these documents, it describes how we work rather than a rule of the trade.
Where to go next
Last updated 19 October 2026