The word "audit" makes people assume the worst: printouts, an auditor staring at spreadsheets, a verdict you were never going to pass. A security audit is none of those things. It is a review of how your systems are really built, in the places that actually matter, written up so the person who has to fix things understands what to do. This article is about the ground it covers.
We run these for a living, and the good news is the scope is finite. There is a fixed set of areas every real audit looks at, regardless of provider. If you know the list, you can tell a genuine audit from a scanner output, and you can read the report you already have with different eyes.
01 The ground
Network architecture, access, and patch levels
A real audit starts where the attack surface is: how your network is architected and what is exposed. The reviewer maps how the inside connects to the outside, where firewalls sit and what rules they actually enforce, and which services are reachable from the internet at all. This is where the classic findings live: an open port that used to matter, a management interface exposed where it should not be, a development server sitting on the same segment as production.
Right alongside that come access controls and patch levels, two areas that alone explain a large share of what we find. Access controls mean who can reach what, including the accounts nobody remembers. Patch levels mean whether the software in front of the internet is current, because the majority of compromises involving known vulnerabilities trace back to a patch that was never applied. The audit's job is to surface these as facts with their risk attached, not to embarrass anyone for them.
02 Identity, cloud, policy
The three areas companies forget to audit
Three areas quietly do the most damage because they sit outside classic network reviews. The first is identity: how logins work, whether multi-factor authentication is actually on for the accounts that matter, how passwords are handled, and what happens when someone leaves. The second is cloud configuration: storage buckets open to the internet, databases with public access, permissions granted too broadly. Cloud misconfiguration is one of the most common serious findings we see, and it is invisible to anyone only looking at on-premises kit.
The third is policy and compliance, and this is not paperwork for its own sake. The audit checks whether what you have written down matches what is really happening, whether backups are kept offsite and actually tested, whether there is an incident response plan, whether access is reviewed on a schedule. The absence of a policy is itself a finding, because it predicts the thing going wrong in an uncontrolled way.
03 The testing layer
Where the audit hands over to active testing
An audit looks at what is there. A penetration test actively tries to get in using what it finds, the way an attacker would, across applications, APIs, and network infrastructure. The two are complementary, and the audit should reference a recent test, because review alone has an important limit: it can describe a weakness but not prove what an attacker could do with it. The test converts "this looks risky" into "this is how far someone could get."
This is also where the quality difference between providers shows up. A scanner can check for known issues in minutes, but real penetration work is human: understanding your business logic, your user roles, the places where a genuine attacker would look, and then explaining, in plain language, how each finding matters and how to fix it. If the test ends at a list of raw technical names, the work is incomplete.
04 The output
What the report should contain
A security audit lives or dies on the report, because the report is what gets acted on, or doesn't. A genuine audit report has three properties. First, it prioritizes: findings are ranked by real risk to your business, not by number of pages a vendor can bill. Second, it is written in plain language with the owner of each fix named and the sequence spelled out, so someone other than the auditor can execute it. Third, it is defensible: each finding carries enough evidence for your team or a customer to see why it matters.
The oldest criticism of the audit industry is the report that sits in a drawer. Ours always end with a prioritized fix list, and the engagement includes agreement on who fixes what by when. If an audit produces a document nobody reads, the audit did its job poorly, not the reader.
05 The expensive part
What you are actually paying for
This is the honest part. The review itself, the scans, the mapping, is a small fraction of the hours. Most of the cost of a good audit is the manual work: someone with real experience reading your environment, deciding which findings matter to your business, writing remediation steps your team can execute, and explaining it to the people who need to understand it.
That is why a suspiciously cheap audit is rarely a bargain. An automated scan with a report generator can produce a list, but it cannot tell you that the finding in row forty is the one that would actually be exploited, or that two findings combine into a real attack chain. If you would like the numbers side of this, including published price ranges and what moves them, we have written that up separately: what a security audit costs.
06 The afterwork
What happens after the report
The audit is a point in time, and its value depends on the follow-through. The pattern that produces real improvement is: fixes get scheduled against the prioritized list, the highest-risk items get closed first, retesting confirms the fixes actually worked, and an annual re-audit catches the drift back toward old habits. Security decays between audits, which is why companies that treat it as an annual, owned event stay ahead of the ones that treat it as a one-time purchase.
If you want the basics handled well before, or alongside, the deep review, go through our nine-step setup first. And if you would rather not run any of this alone, the security audits and penetration testing page says exactly how we run it. It is review plus testing, prioritized, in plain language, with fixes that have owners.
