Assets, threats, and risk

A fictional community hall has a beautiful booking website. The important asset is not merely the computer running it. People rely on correct reservations, private contact details, and a way to open the right room at the right time. Starting with those needs changes the conversation from “buy a security tool” to “protect a useful service.”

Name the thing that matters

An asset can be information, equipment, a service, or a valued relationship. Different assets need different protection. The hall publishes its room prices, so keeping those prices secret is unnecessary. Their integrity matters: incorrect prices can cause disputes. Members’ access needs matter too; a perfectly protected calendar that nobody can use does not serve its purpose.

Write a useful requirement: “The opening volunteer needs today’s confirmed bookings even during a short internet outage.” This identifies a person, a task, and a condition. “The system must be secure” does not tell the designer what success looks like.

Connect a threat to a weakness

A threat is a possible source or circumstance of harm. Here, losing the internet connection is a threat event. Having no alternative way to read the schedule is a weakness. The impact might be delayed classes, missed bookings, and extra calls. These are related concepts, but they are not interchangeable labels for the same thing.

The distinction helps with responsibility. A volunteer making a mistake is not automatically malicious. A supplier outage is not automatically a cyberattack. Security planning considers deliberate actions, accidents, and environmental failures when they affect the service.

Estimate with the context you have

Risk concerns uncertainty about harmful consequences, commonly assessed through likelihood and impact. “High risk” needs an explanation of the scenario, timeframe, assumptions, and rating scale. Multiplying arbitrary labels such as low, medium, and high does not magically produce a measured probability.

Suppose the hall’s connection failed twice last month. That is relevant evidence, but it does not prove that it will fail twice every month. Consider planned repairs, alternative connections, and how busy the hall will be. A ten-minute outage during an empty afternoon differs from the same outage during a large event.

PredictThe hall now prints a daily booking list. Has it eliminated the risk?

It has reduced dependence on the connection. The list can become outdated, expose contact details, or be unavailable to the opening volunteer. Describe these remaining conditions and decide whether the fallback is sufficient for its purpose.

Choose a control with a clear job

A preventive control lowers the chance of a problem. A detective control helps notice it. A recovery measure helps restore useful operation. One measure may serve several jobs. A second connection supports availability; a change log helps explain altered bookings; a tested backup helps recover records. None automatically solves every concern.

Residual risk is what remains with the chosen safeguards. Someone accountable for the service needs to decide whether that remaining risk is acceptable, whether additional protection is worthwhile, and when to review the decision. Keep the reasoning with the decision so a future volunteer can understand it.

Return to the requirement: can people perform the task under the stated conditions? That is a more useful question than counting the number of controls installed.