Security audit

A security audit is a systematic and thorough evaluation of the security controls protecting a system, network, application or infrastructure, carried out to identify weaknesses, assess whether security policy is being followed, and produce recommendations for improving the overall posture.

It covers a range of ground: network architecture, security policy and procedure, the threats that apply, and whether regulatory obligations are being met.

It is done on a recurring basis rather than once, because both the estate and the threats change, and an audit result is a statement about a moment.

What characterises it

Breadth. An audit examines every relevant part of the environment: networks, systems, applications, policy and process. Breadth is what distinguishes it from a test aimed at one target.

Finding weaknesses. Misconfiguration, missing patches, weak credential handling and anything else that would let something go wrong.

Checking compliance. Whether applicable policy, standards and legal requirements are actually being met, and whether that can be evidenced.

Recommendations. Findings on their own change nothing. The output that matters is what to do, in what order, and why that order.

A worked example

A financial company decides to audit its environment, both to protect client data and to meet sector obligations. The work might run like this.

Policy and procedure review. The auditors examine what exists on paper and whether it matches practice.

Network architecture analysis. A detailed look for weak points: misconfiguration, unnecessary open ports, weaknesses in network devices.

Vulnerability scanning. Tooling identifies known issues: out of date systems, unnecessarily exposed services, weak configuration.

Penetration testing. In some cases, simulated attacks assess whether the environment actually resists intrusion rather than whether it should.

Application review. Where the organisation runs its own applications, those are examined for weaknesses in the code and in the logic.

The result is a report with specific recommendations: tighter access control, better patch management, updated policy, staff training. What decides whether the audit was worth anything is which of those get implemented.

Security audit, compliance, pentesting and retest

Security audit is the umbrella term the buyer uses, and underneath it sit things that are not equivalent. Confusing them is how an organisation ends up with a certificate and an intrusion in the same year.

A compliance audit checks, against an external standard, that a control exists and is documented. It is there to evidence, and it does not prove the control holds.

A penetration test uses attacker technique against an agreed scope and demonstrates each finding by exploiting it. It answers what somebody could actually do, and its value is in the proof: if it was not demonstrated, it was not tested.

Vulnerability scanning is the automated part. It finds what is known and catalogued, and it does not find logic flaws or authorisation flaws, which are most of the serious findings in a modern application.

A retest is the second pass, scoped to the list of findings, that turns a report into evidence that the issues were fixed. Without it nobody knows whether the fix worked.

The sentence that separates the first two is worth having in front of you when comparing quotations: a system can pass an audit and still be exploitable. That distance is exactly what an offensive assessment measures, and it is why several standards ask for evidence that controls are effective and not only that they are present.

Where to read more

NIST SP 800-53, Security and privacy controls: the control catalogue that a large part of audit practice is written against.

OWASP Application Security Verification Standard: a verification standard for web applications, usable as the reference for the application part of an audit.

ISACA: professional resources and certification for information systems audit and control.