Cyber Security Assessment: Types and How to Run One

Reviewed October 2026.

What an assessment is

An assessment is a structured look at how well security matches a reference point. The reference might be a baseline such as Cyber Essentials, a framework such as the NCSC's Cyber Assessment Framework (CAF) or ISO 27001, or the risks the organisation has identified for itself. The result is a ranked set of findings, with decisions about what to do next.

An assessment is not an audit. An assessment asks how secure you are and what to improve. An audit asks whether you meet stated criteria, and checks the evidence that you do. The audit guide sets the two side by side.

For UK organisations that handle personal data there is also a legal reason to assess. UK GDPR requires a process for regularly testing, assessing and evaluating the effectiveness of security measures. The ICO points out that it does not say what kind of testing or how often: that depends on the organisation and the data it processes.

The main kinds

Kind	What happens	Who does it	What it tells you
Self-assessment	The organisation answers a structured set of questions against a baseline or framework	Internal staff, sometimes with an adviser	Where you stand and what is missing, as far as the answers are accurate
Automated external check	Software reads public configuration: DNS, email records, TLS, HTTP headers and exposed services	A tool, run by you or a provider	How you look from the internet, repeatably and at low cost
Vulnerability assessment	Scanners test systems inside and outside the network for known vulnerabilities and misconfigurations, and someone triages the results	Security staff or a provider	Known weaknesses across many systems, in order of priority
Penetration test	Qualified testers try to breach the system within an agreed scope, as an attacker would	Specialist testers	Whether weaknesses can be exploited, and how well your own processes find them
Risk assessment	The organisation identifies, analyses and prioritises risks to its objectives and decides how to treat them	Risk owners, with technical input	What matters most and what to do about it

Self-assessment

A self-assessment is the cheapest place to start. Cyber Essentials begins with one: the scheme publishes its question set and a free readiness tool, and the answers you submit for certification are signed off by a board member or equivalent before an assessor marks them. The CAF works in a similar way for organisations that run essential services, and supports both internal assessments and oversight by regulators.

A self-assessment is only as accurate as the people answering it. Answer from evidence, not memory: if you say every device receives its updates within a set time, find the record that shows it.

Automated external check

An automated external check looks at what anyone on the internet can see: DNS, email authentication, certificates and TLS, HTTP headers, disclosed software and which services answer. It is quick, repeatable and low-impact, so it suits running after every change. The NCSC describes tools in this category, external attack surface management, as giving you at least the same view of your online systems as an attacker has.

It cannot see inside the network, read a policy or judge whether a finding matters to your business. Ironfang's External Security Check is this kind of check: it reads public configuration and makes one connection attempt to each of a fixed list of ports. It does not exploit anything, log in or test how an application behaves.

Vulnerability assessment

A vulnerability assessment uses scanners to find known weaknesses: missing patches, unsupported software, default or weak passwords, weak cryptography and exposed services. Scans run from outside and inside the network, and scans that log in can check things an unauthenticated scan cannot. The NCSC recommends scanning infrastructure at least once a month and straight after fixing a critical issue, and scanning applications whenever they change.

Scanners report what they find, false positives included. The assessment is the work around the scan: confirming results, rating them in the context of your systems and deciding what to fix first.

Risk assessment

A risk assessment starts from the organisation rather than its systems: what it needs to achieve, what could stop it, how likely that is and how much harm it would do. The other kinds feed into it. A scan finding becomes a risk once you know which asset it affects and what that asset supports.

The NCSC notes that a baseline such as Cyber Essentials covers the risks it was designed for, so organisations with particular needs should assess their own risks as well. The ISO 27001 risk assessment guide describes one structured way to do it.

Vulnerability assessment and penetration testing

The two are often confused, and sometimes sold as each other. The difference is whether anyone tries to exploit what is found.

Aspect	Vulnerability assessment	Penetration test
Question	Which known weaknesses do our systems have?	Can someone get in, and how far?
Method	Mostly automated scanning, then triage by people	Manual testing by people, with an attacker's tools and techniques
Coverage	Broad: many systems, common issues	Deep: a defined scope, including complex issues tools miss
How often	Regularly; the NCSC suggests at least monthly for infrastructure	Periodically; a year or more between tests is common, so it cannot be your only check
Result	A prioritised list of vulnerabilities	Weaknesses that were exploited, their impact, and an opinion on your own vulnerability management
Effect on systems	Low, although scans can trigger security alerts	Higher; testers take care, but unexpected effects cannot be ruled out

The NCSC defines penetration testing as a way of gaining assurance in a system's security by attempting to breach it with the tools and techniques an adversary might use. It is clear about the role a test should play: it checks that your own vulnerability assessment and management work, much as a financial audit checks the finance team's processes. Ideally the testers find nothing you did not already know about.

Two things follow. Assess vulnerabilities regularly first, so a test is not spent finding missing patches a scanner would have caught. And treat a test as a point in time: it shows the system was not vulnerable to known issues on the day it was tested, nothing more.

Commissioning a penetration test

Scope it with the right people: the risk owners, technical staff who know the system and the test team. Agree the technical boundaries, the type of test, the time available and any systems that need special handling.
Share your latest vulnerability assessment with the testers, so the test can confirm or challenge it.
Decide how much the testers are told. Open-box testing gives them full information. Closed-box testing gives them none and models an outside attacker more closely, but issues may go unfound in the time available.
For web applications, the OWASP Web Security Testing Guide is a widely used reference for what a test should cover.
Use qualified, experienced testers. The NCSC's CHECK scheme is for government, the wider public sector and critical national infrastructure; other organisations can follow the NCSC's guidance on commissioning a test.
Expect a report that lists each issue with its level of risk and a way to fix it, and gives an opinion on your own vulnerability assessment.
Make the decisions yourselves. Testers rate issues without knowing your business in full, and the NCSC is clear that deciding on risk and fixes is your responsibility.

How to run an assessment

Whatever the kind, the steps are much the same.

Set the purpose. A customer questionnaire, preparation for Cyber Essentials, an incident, a board request and a regulator each call for a different depth and a different kind of evidence.
Write down the scope: which parts of the organisation, which systems, sites, domains and suppliers, and what is out of scope and why.
Choose the reference: the Cyber Essentials requirements, the CAF, ISO 27001, the NCSC's 10 Steps to Cyber Security, or your own policies.
Gather what you already have: the asset list, the risk register, network diagrams, earlier findings and how they were closed.
Collect evidence, using the right kind of assessment for each question: scans for configuration, interviews and records for process.
Rate the findings in context. The NCSC's example: a remote code execution flaw may be more serious on an internet-facing system than on an internal one. Say what your severity labels mean.
Decide what to do about each finding, give it an owner and a date, and record the risks you accept.
Fix, then check the fix. Run the check that found the issue again and keep the result.
Repeat on a schedule, and whenever something significant changes.

Evidence an assessment needs

Every assessment draws on two kinds of evidence. Automated checks produce the first quickly. Only the organisation can produce the second.

Ironfang can check

DNS configuration, including dangling CNAMEs, CAA and DNSSEC.
SPF, DKIM at common selectors and DMARC for each domain.
TLS certificates, expiry, protocol versions and cipher suites.
HTTP security headers, cookies, security.txt and disclosed software, with versions that look unsupported marked as potential.
For a verified domain, whether any of 21 common service ports accept a connection.
Each finding with its evidence, severity and fix, and a recheck that records when it was fixed.

The organisation must establish

The scope, the asset list and the owner of each asset.
Policies, and who agreed them.
Risk assessments and treatment decisions.
Access reviews, joiners and leavers, and administrator accounts.
Updates for laptops, servers and phones inside the network.
Training, incident response plans and the results of exercises.
Assurance from suppliers who run systems for you.

Website security checker Check a domain's DNS, email authentication, TLS, security headers and public technology in one pass.
Exposed services checker Check your domain for databases, remote desktop and other services open to the internet, once it is verified.
End-of-life software checker See whether a site advertises software versions that no longer receive security fixes.
Email security checker Check MX, SPF, DMARC and DKIM together, and the protection of a domain that sends no mail.

Common mistakes

Treating a scan as a penetration test, or a penetration test as a complete assessment.
Reading a clean result as proof of security. A check covers only what it looked at, when it looked.
Assessing without a written scope, so nobody can say afterwards what was covered.
Leaving findings without an owner or a date.
Assessing once a year and assuming nothing changed in between.
Assessing for compliance alone. The NCSC warns that meeting a standard can coexist with weak security.

Sources

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