What should a cyber security assessment for a small business include?

A useful small business cyber security assessment is more than a checklist or a scan. It is a structured review of how the organisation prevents, detects, responds to and recovers from cyber threats, supported by evidence and translated into practical actions. The scope should reflect the business’s size, operating model, information handled and reliance on technology.

1. Scope and business context

The assessment should begin by establishing what is being examined and which business activities depend on it. This normally includes:

• Locations, offices, remote-working arrangements and any multi-site operation
• Critical business processes and the technology each process requires
• Information that would cause harm or disruption if it were lost, altered or disclosed
• Key internal responsibilities, outsourced services and technology suppliers
• Relevant legal, contractual, regulatory and insurance requirements

This context prevents the assessment from treating every issue as equally important. A weakness affecting an essential operational system may require a different response from one affecting a low-impact service.

2. An accurate technology and information picture

The assessor should verify what equipment, software, cloud services, accounts, networks and information repositories are actually in use. Records should be compared with technical evidence rather than relying solely on an asset register, as unrecorded devices, forgotten accounts and unauthorised applications can create significant exposure.

The review should also consider where important information is stored, who can access it, how it moves between systems and whether copies are retained by suppliers. This can reveal unmanaged devices, unsupported software, excessive access permissions and services that no longer have a clear owner.

3. Identity and access management

Access controls deserve detailed attention because compromised credentials are frequently used to enter otherwise protected environments. The assessment should examine:

• Whether each person has an individual account rather than shared credentials
• How strong authentication is enforced, particularly for remote access, email and administrative accounts
• Whether multi-factor authentication is used where the risk justifies it
• How access is approved, reviewed, changed and removed when someone changes role or leaves
• Whether users and administrators have more privilege than their duties require
• How passwords, privileged accounts, service accounts and emergency access are managed

The assessment should test the effectiveness of these arrangements through configuration evidence and sample reviews, not simply record that a policy exists.

4. Device, network and cloud configuration

Technical checks should look for weaknesses in the configuration of computers, servers, network equipment, wireless networks, remote access tools and cloud platforms. Areas commonly examined include security updates, unsupported systems, exposed services, encryption, firewall rules, administrator access, secure configuration standards and separation between important parts of the environment.

Where appropriate, vulnerability scanning or targeted technical testing can help identify weaknesses that are not visible from documentation. Testing should be agreed in advance, carefully controlled and proportionate to the organisation’s environment. A scan by itself is not a complete assessment: findings need to be confirmed, prioritised and considered in their business context.

5. Email, web and social engineering exposure

Email security should be reviewed alongside the behaviour it is intended to support. The assessment may examine protection against malicious attachments, deceptive links, impersonation and unauthorised forwarding, as well as the organisation’s domain protection and reporting process.

It should also consider whether staff know how to report a suspicious message and whether the business can investigate a suspected account compromise. If simulated phishing or other exercises are proposed, they should have a clear purpose, appropriate consent and a focus on improving controls rather than blaming individuals.

6. Data protection and resilience

An assessment should examine how sensitive and business-critical information is protected throughout its lifecycle. This includes collection, use, sharing, storage, retention and disposal. It should identify whether access is limited appropriately and whether records can be restored after accidental deletion, equipment failure, ransomware or another disruptive event.

Backup arrangements should be checked for coverage, separation from the main environment, access protection, retention and restoration testing. Merely having a backup product or a record of completed jobs does not demonstrate that recovery will work. Evidence from restoration tests is more meaningful, including whether the restored information is complete and usable.

7. Incident management and recovery arrangements

The assessment should establish whether the organisation can recognise, contain, investigate and recover from an incident. It should examine:

• How staff report suspected security events
• Who has authority to make technical and business decisions
• How evidence is preserved for investigation
• How affected users, suppliers, customers and other relevant parties would be informed
• How services are restored and lessons are recorded afterwards

Plans should account for situations in which normal systems, email or contact lists are unavailable. A short, accessible procedure with clear responsibilities is generally more useful than a document that is comprehensive but impractical to follow.

8. People, suppliers and physical security

Cyber security controls can be undermined by unclear responsibilities or weaknesses outside the organisation’s direct network. The assessment should therefore review staff awareness, joiner and leaver processes, acceptable use arrangements and the handling of removable media or sensitive information.

Supplier and cloud-service arrangements should be considered as well. Relevant questions include what security responsibilities remain with the business, how supplier access is controlled, whether contracts address information handling and incident notification, and what happens if a service is unavailable or replaced.

Physical safeguards may also be relevant, including access to networking equipment, server areas, workstations, printed information and devices taken away from the premises.

9. Evidence, scoring and prioritisation

Each significant observation should be supported by evidence such as configuration records, access reviews, patch information, interview notes, test results or sampled documents. Findings should explain the affected asset or process, the weakness, the plausible threat, the potential business consequence and any existing mitigating controls.

Risk ratings should not be based only on the technical severity of a vulnerability. They should take account of exploitability, exposure, the value or sensitivity of the affected information, operational dependency and the effectiveness of compensating measures. This produces a more useful order of work than a list of unranked technical issues.

10. A practical assessment report and follow-up

The final report should provide an executive summary for decision-makers and enough technical detail for those responsible for implementation. It should normally contain:

• The agreed scope, assumptions and assessment method
• Important strengths as well as weaknesses
• Prioritised findings with clear explanations
• Recommended actions, owners and suggested timeframes
• Dependencies, costs or operational considerations that may affect delivery
• Actions requiring specialist investigation or further testing

The process should not end when the report is issued. The organisation should agree which actions will be completed, retain evidence of changes and reassess important controls after remediation. Repeating targeted reviews when systems, suppliers, risks or business processes change helps keep the assessment relevant rather than treating it as a one-off snapshot.