Cyber Security Basics: Risk, Controls and Evidence

Reviewed October 2026.

The terms at a glance

Six words carry most of the meaning in security guidance. The definitions here follow the NCSC's risk management guidance, in plain terms.

Term	Meaning	Example
Asset	Anything the organisation values and needs to protect: information, systems, services, devices, accounts and the suppliers it relies on.	The customer database, the website, the domain name.
Threat	Someone who could cause harm on purpose. A hazard is an event that causes harm without intent, such as a flood or a power cut.	A criminal group sending phishing emails.
Vulnerability	A weakness a threat could exploit or a hazard could affect. It can be technical, procedural, physical or about people.	An unpatched server. An account left active after someone leaves.
Risk	The possibility of something bad happening, judged by how likely it is and how much harm it would do.	Customer data stolen through an unpatched server.
Control	A measure that reduces a risk.	Applying updates within a set time. Multi-factor authentication.
Evidence	Records and observations that show a control is in place and working.	An update report. Notes of an access review.

Assets

Security starts with knowing what you have. The NCSC puts it as knowing what data and systems you manage, and what business need each one supports. Incidents often begin with something nobody was tracking: a service that missed its updates, a cloud storage account left open, a document filed in the wrong place.

An asset list does not have to be elaborate. For each item, record:

What it is and where it runs.
Who owns it: the person who decides how it is used and protected.
What it supports, and what would happen if it were unavailable, altered or exposed.
Who supplies or maintains it, if that is not you.
When its software stops receiving security updates.

Include what lives outside your own network: cloud services, software you rent, your website host and your domain names. They belong to your risk even when someone else runs them. The external attack surface guide covers the internet-facing part of the list.

Threats

A threat is a person or group that could cause harm deliberately. The NCSC looks at a threat through four parts: capability (skills and resources), intent (what they want to achieve), motivation (why they want it) and opportunity (the access or weakness that lets them act).

Most organisations are not attacked because someone chose them. Criminals scan the whole internet for weaknesses they already know how to use and exploit them wherever they turn up, often soon after a vulnerability is made public. A small business with an exposed, unpatched service is found the same way as a large one.

Hazards matter too. Fire, flood, hardware failure and a supplier going out of business can cause the same loss as an attack, and the same controls, such as backups you have tested, help with both.

Vulnerabilities

A vulnerability is any weakness a threat can exploit or a hazard can affect. The NCSC is explicit that vulnerabilities are not only technical: weak procedures, poor physical security and gaps in personnel security count as well.

Technical: software without its security updates, a default password, a database reachable from the internet, a domain with no DMARC policy.
Procedural: nobody removes access when staff leave, or backups are taken but never restored as a test.
Physical: a server cupboard left open, laptops left in cars.
People: staff who have never been shown how to report a suspicious email.

The NCSC notes that most incidents come from attackers exploiting vulnerabilities that have already been publicly disclosed. Keeping software updated, and knowing which systems cannot be updated, is one of the most effective things an organisation can do.

Controls

A control is a measure that reduces risk. The NCSC groups controls into four kinds, and most good protection uses all of them.

Kind	What it covers	Examples
Procedural	Policies, processes and guidelines	A joiners and leavers process, an update schedule, an incident response plan
Physical	Buildings, equipment and the people in them	Locked server rooms, controlled entry
Personnel	The people who have authorised access	Vetting, training, a clear way to report problems
Technical	Measures built into the systems	Firewalls, secure configuration, access control, malware protection, updates

Controls should be proportionate to the risk, usable, and should not get in the way of the work. A control people route around protects nothing.

For most organisations a baseline is the right starting point. Cyber Essentials sets five technical controls aimed at the most common internet-based attacks. The NCSC is clear that a baseline covers the risks it was designed for, not every risk a particular organisation has.

Risk

The NCSC's working definition of cyber risk is simple: the possibility of something bad happening. To judge a risk, combine its parts: a threat or hazard, a vulnerability it could use, how likely that is, and the impact on the organisation if it happens.

Impact is wider than lost data. A risk can end in systems that stop working or become unsafe, money lost, a contract lost, harm to reputation or, at worst, the business failing.

If you score risks as high, medium and low, say what each label means. Two people reading "medium" differently is a common source of poor decisions.

Deciding what to do

For each significant risk, someone with the authority to do so decides how to handle it. There are four options:

Reduce it with a control.
Accept it and carry on, knowingly.
Transfer it, for example through insurance or a contract.
Avoid it by stopping or changing the activity.

No set of controls removes all risk. What is left over, the residual risk, should be understood and accepted by the people accountable for it. Record the decision, who made it and when it will be reviewed, and revisit it when something significant changes: a new system, a new supplier, a change in how a service is used or in the threats you face.

Evidence and monitoring

Having controls is not the same as knowing they work. The NCSC calls that confidence assurance, and points out that many assurance activities are snapshots: a test, an audit or a scan describes one moment. Confidence has to be kept up as systems, threats and people change.

Evidence comes in two forms:

Records the organisation keeps: the asset list, risk decisions, policies and who agreed them, access reviews, training records, incident reports and notes of each review.
Technical observations: configuration, update status, logs, and the results of scans and tests, each with the date it was taken.

Monitoring turns those observations into something continuous. Logs are the foundation: they let you work out what happened after an incident, and security monitoring analyses them to spot one while it is happening. The NCSC recommends keeping your most important logs for at least six months, because incidents can take months to come to light.

Configuration needs watching from outside as well. Certificates approach expiry, DNS records outlive the services they pointed at, and settings change during migrations. A check that runs again after each change, and keeps its results, shows when something drifted and when it was put right.

What an external check sees

Much of an organisation's security can only be seen from inside. An external check looks at what anyone on the internet can observe about your domains and services. That view is useful because attackers start from the same place, but it is partial.

Visible from outside	Known only inside
DNS records, and whether SPF, DKIM and DMARC are published	Who can change DNS, and whether the registrar account uses two-step verification
The TLS certificate, its expiry and the protocol versions a server accepts	Who renews certificates, and what happens when they are away
HTTP security headers, cookie attributes and the software versions a site discloses	Whether internal servers and laptops have their updates
Which common service ports answer on a host	Who has administrator access, and whether it is reviewed
Names that appear in public certificate transparency logs	Policies, training, risk decisions, backups and incident plans

The two sides of the evidence

Ironfang can check

Public DNS configuration: address records, nameservers, CAA, DNSSEC and dangling CNAMEs.
Email authentication records: SPF, DKIM at common selectors and DMARC.
TLS: certificate trust, expiry and hostname coverage, protocol versions and cipher suites.
HTTP security headers, cookie attributes, security.txt and disclosed technologies.
For a verified domain, whether any of 21 common service ports accept a connection.
Hostnames listed in certificate transparency logs, for you to review.

The organisation must establish

What the organisation owns, and who is responsible for each part.
Which risks it faces and what it decided to do about them.
Policies and processes, and records showing they are followed.
Training, access reviews, backups and incident response.
Everything that is not reachable from the internet.

A clean external result means the checks that ran found nothing on the hosts they could reach. It does not show that an organisation is secure, compliant or ready for certification.

Website security checker Check a domain's DNS, email authentication, TLS, security headers and public technology in one pass.
Email security checker Check MX, SPF, DMARC and DKIM together, and the protection of a domain that sends no mail.
DNS security checker Check a domain's address records, nameserver redundancy, CAA, DNSSEC and dangling CNAMEs.
SSL/TLS checker Check a site's HTTPS, certificate, expiry, TLS versions and weak cipher suites.

Where to start

List your assets, including domains, cloud services and suppliers, and name an owner for each.
Decide which matter most: what would hurt the organisation most if it were lost, altered or unavailable.
Apply a baseline. The UK Government recommends Cyber Essentials as the minimum standard for organisations of all sizes; the requirements guide explains its five controls.
Check what you expose to the internet and remove what should not be there. The External Security Check does this for a domain you verify.
Record the risks you accept, with an owner and a review date.
Review when something changes, and on a regular schedule in between.

Sources

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