Cyber Security Audit: Types and How to Prepare

Reviewed October 2026.

What an audit is

An audit compares evidence with criteria. The criteria are fixed before it starts: a standard such as ISO/IEC 27001, a scheme such as Cyber Essentials, a contract, a regulation or the organisation's own policies. The auditor reads records, interviews people, observes work and samples activity, then reports where practice meets the criteria and where it does not.

Two things set an audit apart. It is objective: auditors do not audit their own work. And it is documented: the plan, the evidence and the findings are recorded, so someone else can follow how each conclusion was reached.

Audits are often described by who carries them out. A first-party audit is the organisation auditing itself, usually called an internal audit. A second-party audit is a customer auditing a supplier. A third-party audit is carried out by an independent body, for certification or for a regulator. ISO 19011 gives guidance on auditing management systems that covers all three, and ISO/IEC 27007 adds guidance specific to information security management systems.

An assessment asks a different question. An assessment asks how secure you are and what to improve; an audit asks whether you meet the criteria and examines the proof. The assessment guide covers that side.

Audit types compared

Five activities are regularly called a security audit. They answer different questions and produce different things, and only two of them are audits.

Activity	Carried out by	Checked against	What you get
Internal review	Your own staff	Your policies, or a checklist	A list of gaps and actions. Useful, but not independent
Automated technical check	Software, run by you or a provider	Technical rules for good configuration	Findings about configuration at a point in time. Nothing about policy, process or people
Formal audit	An auditor independent of the area: an internal audit function, a customer or a regulator	A defined standard, contract, regulation or policy	An audit report with findings and nonconformities, based on sampled evidence
Certification audit	A certification body	A certifiable standard or scheme, such as ISO/IEC 27001 or Cyber Essentials	If the requirements are met, a certificate with a stated scope and period
Penetration test	Qualified testers	An agreed scope and rules of engagement	A report on the weaknesses testers could exploit on the days of the test

Internal review

An internal review is the organisation checking itself informally: walking through a checklist, comparing practice with policy, looking for gaps before someone else does. It is quick and useful, and most preparation starts with one. It is not independent, so on its own it carries little weight with a customer or a certification body.

Automated technical check

An automated technical check runs software against systems and compares what it finds with rules for good configuration: whether a domain publishes DMARC, whether a server still accepts TLS 1.0, whether a database port answers from the internet. Its results are precise, dated and repeatable.

It is not an audit. It does not look at policies, processes, records or people, it covers only the hosts it can reach, and it forms no opinion on whether anyone conforms to a standard. Ironfang's External Security Check is a check of this kind. Its results can be technical evidence for an audit, but it is not one, and it does not certify anyone or carry out formal assessments.

Formal audit

A formal audit follows a plan, uses auditors who are independent of the area being audited, and records evidence and findings against fixed criteria. It may be an internal audit, a customer auditing a supplier, or a regulator. ISO/IEC 27001 expects an organisation to audit its own information security management system at planned intervals (clause 9.2). Those internal audits are formal audits even though staff carry them out, provided the auditors are chosen so that the audit stays objective and impartial.

An audit samples. It examines enough evidence to reach a conclusion, not every record, so its findings describe what was seen and say nothing certain about the rest.

Certification audit

A certification audit is a third-party audit by a certification body, leading to a certificate if the organisation meets the requirements. The scope is written on the certificate, and the certificate covers that scope only.

ISO itself does not certify anyone to ISO/IEC 27001. Independent certification bodies do, working to ISO/IEC 17021-1 and, for information security, ISO/IEC 27006-1. Certification starts with an initial audit in two stages; surveillance audits follow while the certificate is current, and a recertification audit renews it. Accreditation is how certification bodies are themselves checked; in the UK, the United Kingdom Accreditation Service (UKAS) is the sole national accreditation body. Accreditation is not compulsory, but ISO advises checking for it when you choose a certification body. See ISO 27001 certification.

Cyber Essentials works differently. You complete a verified self-assessment, which a board member or equivalent signs off and an assessor at a certification body licensed by IASME marks. Certification lasts 12 months. Cyber Essentials Plus adds a technical audit of your systems, covering a representative set of user devices, all internet gateways and all servers with services reachable from the internet. See Cyber Essentials certification.

Penetration test

A penetration test is an attempt by qualified people to breach a system within an agreed scope. The NCSC compares it to a financial audit in one respect: it checks that your own vulnerability management is working. But it tests systems, not a management system, and says nothing about policies, governance or records. A test report is evidence an auditor may look at, not an audit. The assessment guide compares it with vulnerability assessment.

How to prepare for an audit

Confirm the criteria and the scope in writing: which standard or scheme and which version, which parts of the organisation, which sites and systems and, for certification, the scope that will appear on the certificate.
Map each requirement to evidence. A simple table works: the requirement, the evidence that shows you meet it, where that evidence is kept and who owns it.
Gather the documents: policies and who agreed them, the scope statement, the asset list, the risk assessment and treatment decisions and, for ISO/IEC 27001, the Statement of Applicability.
Gather the records that show the documents are followed: access reviews, joiners and leavers, update records, training records, incident logs, supplier reviews, internal audit reports and management review notes.
Collect current technical evidence, each item dated: configuration exports, vulnerability scan results, external check results, and rechecks that show fixes.
Run an internal review or internal audit first. Fix what you can, and for anything you cannot fix before the audit, record a plan with an owner and a date.
Brief the people who will be interviewed. Auditors check that practice matches the documents, so staff should be able to explain what they actually do, not recite a policy.
After the audit, deal with each finding: find the cause, agree a corrective action and an owner, and keep the evidence that it was done.

Where automated technical evidence helps

Automated checks are good at one part of an audit: showing whether a technical control is actually in place on the systems in scope. Their results are precise, dated and repeatable, and a recheck after a fix shows when a problem was closed.

Showing that internet-facing services use current TLS and valid certificates.
Showing that email domains publish SPF and DMARC, and at which policy.
Showing that no unexpected services, such as databases or remote desktop, answer from the internet.
Showing that servers do not advertise unsupported software versions.
Showing that an issue found earlier was fixed, and when.
Finding problems before the auditor does, so they appear in your records as found and fixed rather than as audit findings.

Technical and organisational evidence

Ironfang can check

Public DNS configuration for a domain, including CAA, DNSSEC and dangling CNAMEs.
SPF, DKIM at common selectors and DMARC.
TLS certificates, expiry, protocol versions and cipher suites.
HTTP security headers, cookies and disclosed software versions.
For a verified domain, whether any of 21 common service ports accept a connection.
A dated history of each domain's findings, fixes and rechecks.

The organisation must establish

The scope, and the reasons for any exclusions.
Policies, who agreed them and when they were reviewed.
Risk assessments, treatment decisions and accepted risks.
Roles and responsibilities, and who owns each asset.
Training, access reviews, incident handling and supplier management.
Internal audits, management reviews and corrective actions.
Controls on internal systems and devices that no external check can reach.

Website security checker Check a domain's DNS, email authentication, TLS, security headers and public technology in one pass.
SSL/TLS checker Check a site's HTTPS, certificate, expiry, TLS versions and weak cipher suites.
Email security checker Check MX, SPF, DMARC and DKIM together, and the protection of a domain that sends no mail.
Exposed services checker Check your domain for databases, remote desktop and other services open to the internet, once it is verified.

Where it does not help

Most of what an audit examines is organisational, and no scan can supply it.

A scan cannot show that a policy exists, was agreed or is followed.
It cannot show that risks were assessed, or that the right people made the decisions.
It cannot see internal systems, laptops, phones or cloud accounts that are not reachable from the internet.
It cannot judge whether the scope is right, or whether an exposed service is intended.
A clean result shows that the checks that ran found nothing on the hosts they reached. It does not show conformity with a standard, and it is not a certificate.

Choosing an auditor or certification body

For ISO/IEC 27001, compare several certification bodies, check that they work to the relevant ISO conformity assessment standards, and check their accreditation. UKAS CertCheck lets anyone confirm whether a management system certificate was issued under UKAS accreditation, which also helps when you check a supplier's claim.
For Cyber Essentials, use the official route through IASME, the NCSC's delivery partner, and its list of certification bodies. IASME also runs the search for current Cyber Essentials certificates.
For penetration testing in government, the wider public sector or critical national infrastructure, use a provider assured under the NCSC's CHECK scheme.
Ask how a certification body protects its impartiality, for example if it or a related company has advised you on the same management system.

Sources

Checked on the review date above. Standards and schemes change; the source is the authority.