What should a cyber security risk assessment examine beyond technical vulnerabilities?

A cyber security risk assessment should examine how an organisation operates, what could interrupt or compromise that operation, and whether its safeguards would work in realistic circumstances. Technical vulnerability scanning is only one source of evidence; a meaningful assessment also considers business dependency, attack paths, control effectiveness, governance and recovery capability.

Business dependency and critical operations

The assessment should establish which activities are most dependent on technology and what would happen if they became unavailable, inaccurate or exposed. This includes identifying essential applications, communications systems, shared files, customer-facing services and operational technology, together with the dependencies between them. A system that appears low-risk in isolation may be essential because several other services rely on it.

The assessment should also distinguish between different types of harm. A loss of availability, unauthorised change, disclosure of confidential information and fraudulent use of an account may require different safeguards and produce different consequences. This makes the assessment more useful than a simple count of vulnerable devices.

Realistic attack scenarios

Risk should be tested against plausible routes into the organisation rather than considered only as a list of individual weaknesses. Scenarios might include a compromised user account being used to access cloud services, a fraudulent payment request reaching the finance function, ransomware spreading from an endpoint to shared resources, or a trusted external connection being used to reach internal systems.

For each scenario, the assessment should consider the sequence of events, the safeguards that should interrupt it, the evidence that an attack would generate and the decisions required if it continued. This helps reveal combinations of moderate weaknesses that could create a serious overall exposure.

Control effectiveness

The existence of a policy or security product does not prove that a control is effective. The assessment should examine whether controls are correctly configured, consistently applied and appropriate to the organisation’s current systems. Useful evidence may include access reviews, configuration records, audit logs, backup restoration records, staff guidance, security test results and documented exceptions.

It should also identify gaps between documented arrangements and day-to-day practice. For example, a formal access removal process may not cover temporary workers, shared accounts or third-party administrators. Similarly, backups may exist but still be unsuitable if they cannot be restored, are reachable from compromised credentials or do not contain the information the business actually needs.

Accountability and governance

A risk assessment should identify who owns each significant risk and who has authority to approve an exception. It should examine how security decisions are recorded, how competing business requirements are handled and whether accepted risks have a defined rationale and review point.

Governance should cover the whole technology estate, including systems introduced by individual departments, remotely managed services and platforms connected through integrations. Clear ownership is particularly important where responsibility is divided between the organisation and a service provider, because assumptions about who manages a control can leave an exposure unaddressed.

Physical and environmental exposure

Digital risks can be affected by physical conditions. The assessment should consider access to offices, network equipment, server areas, paper records and portable devices, as well as risks from theft, loss, power interruption, fire or water damage. It should establish whether physical safeguards support the technical controls or create an alternative route around them.

Remote and hybrid working arrangements also warrant examination. Relevant questions include how devices are protected away from the office, whether confidential information can be viewed or copied in unsuitable settings, and how lost equipment is reported and managed.

Lifecycle and change risk

Security risk changes when systems, suppliers, locations or working practices change. An assessment should therefore consider new projects, migrations, acquisitions, software integrations and obsolete technology. It should identify unsupported systems, unnecessary services, unreviewed applications and technology that has become difficult to secure or monitor.

Change controls should make security review part of the design and approval process rather than treating it as a separate exercise after implementation. This is especially relevant where a new platform changes data flows, introduces elevated permissions or connects previously separate environments.

Recovery and decision-making

The assessment should examine whether the organisation can make informed decisions during a disruptive event. This includes the availability of reliable contact information, escalation routes, recovery priorities, alternative working arrangements and communication procedures. It should also test whether critical services can be restored in the required order and whether recovery depends on a single individual, device or supplier.

Evidence from exercises and restoration tests is more informative than an untested plan. The assessment should record unresolved assumptions, dependencies and lessons from previous incidents, then link them to specific improvements and responsible owners.

What the final assessment should contain

A useful report should explain the basis for each finding, the affected asset or activity, the relevant scenario, the existing safeguards and the remaining exposure. It should separate urgent weaknesses from longer-term improvements and make clear where further evidence is needed.

It should also record risk ownership, agreed actions, target review points and any formally accepted residual risk. Reassessment should be triggered by material changes such as a new system, major organisational change, a significant incident or the discovery of a new threat. This keeps the assessment connected to the organisation’s real circumstances rather than leaving it as a static technical report.