IT And Cybersecurity Risk Management

IT risk means the possibility that a problem involving technology could prevent your business from reaching a goal. The goal might involve serving customers, collecting payment, paying staff, protecting private information, or meeting a promise made to a customer. Cybersecurity risk means the part of IT risk connected to attacks, unauthorized access, harmful software, stolen information, or deliberate misuse.

A risk is not the same as a problem that already happened. If your card reader has stopped working, that is an incident. The risk is that it may stop again during a busy Saturday. If an employee already clicked a harmful link, that is an incident. The risk is that the same account may still allow an attacker to enter. This difference matters because risk management helps you act before damage grows, while incident response helps you handle an event already underway.

The Plain-Risk Compass uses three questions:

1. What could happen? State the event in clear terms. “A customer’s payment information could be exposed through the online booking account” gives you something you can check. “Cybersecurity is weak” does not. 2. How likely is it? Estimate the chance using evidence such as past failures, missing updates, shared passwords, or the number of people with access. Use a simple scale: low, medium, or high. 3. What would it affect? Describe the impact if the event happens. Consider lost sales, recovery costs, privacy harm, missed deadlines, damaged trust, or safety problems. Again, use low, medium, or high. 4. What do we not know? Record uncertainty. You may not know whether old accounts still work, whether backups can restore files, or whether a software provider protects your data properly.

Likelihood describes chance, not certainty. A high-likelihood risk may involve a repeated warning, such as a payment computer crashing every few weeks. A low-likelihood risk may involve a rare event, such as a fire destroying the only computer that stores appointment records. Do not call a risk “low” just because it has never happened. A locked door that you never test may still fail.

Impact describes the result, not the drama of the event. A short internet outage may have low impact if staff can write orders down and enter them later. The same outage may have high impact for an online-only business that cannot accept orders or answer customers. To estimate impact, ask what stops, who feels the effect, how long the disruption lasts, and what it costs to recover.

Uncertainty tells you how dependable your estimate is. You might rate likelihood as medium and uncertainty as high because you have no record of failed login attempts and do not know which former workers still have access. That does not make the risk unimportant. It tells you to gather information before making a confident decision. The basic description might read: “An old staff account could still access the booking system; likelihood medium, impact high, uncertainty high.”

The key takeaway is simple: describe the event first, then judge its chance, its effect, and the gaps in your knowledge. That sequence keeps guesses from hiding inside vague labels.

Applying the Compass to a Booking System

Consider a small fitness studio that uses an online booking system for classes, customer contact details, and monthly payments. The owner wants to decide whether to spend a Saturday reviewing access and backup arrangements.

Use these steps:

1. Name the business goal. The studio needs to accept bookings, protect customer information, and collect monthly payments. This matters because the same technical weakness can have different importance depending on the goal it threatens. 2. Describe one possible event. The studio writes: “A former instructor could sign in to the booking system and view or change customer records.” The sentence names the person’s possible access and the affected information. 3. Rate likelihood. The owner finds three instructor accounts, one belonging to someone who left six months ago. The system shows no recent access review. The owner rates likelihood as medium, not high, because the account may be disabled but no one has checked. 4. Rate impact. Unauthorized access could expose names, email addresses, attendance records, and payment-related details. The studio could face customer complaints, account recovery work, and lost trust. It rates impact high. 5. Rate uncertainty. The owner does not know whether the former instructor’s account still works or whether the system records sign-in activity. The owner rates uncertainty high. 6. Choose an information-gathering action. The owner contacts the software provider, asks for a current user list, requests sign-in records for the last 30 days, and confirms whether the system supports multi-factor authentication, which requires a second proof of identity after the password. 7. Reduce the risk. The owner disables unused accounts, gives each current instructor an individual account, turns on multi-factor authentication, and changes the administrator password. These actions reduce the chance of unauthorized access and make future reviews easier. 8. Check the result. The owner tests a disabled account, confirms that current users can sign in, saves the provider’s response, and schedules another access review in 30 days. The expected outcome is a complete user list, no active former-staff accounts, and a record showing that the new controls work.

The owner should not combine every concern into one label such as “booking system risk.” A separate risk might involve a failed payment integration, and another might involve the provider losing stored records. Each event needs its own likelihood, impact, and uncertainty because the right action may differ.

Quick checklist

• Write one possible event in a single sentence. - Identify the business goal that the event could interrupt. - Rate likelihood as low, medium, or high. - Rate impact as low, medium, or high. - Record what remains unknown. - Gather evidence before raising or lowering a rating. - Choose an action that reduces the chance, reduces the damage, or improves your knowledge. - Test the action and record the result. - Set a review date, especially after staff, software, or suppliers change.

A useful risk note might look like this:

| Risk description | Likelihood | Impact | Uncertainty | Next action | |---|---|---|---|---| | Former instructor may access customer records | Medium | High | High | Disable old accounts and review sign-in records | | Booking provider may become unavailable for one hour | Medium | Medium | Medium | Confirm phone booking backup and provider support process |

The practical result is not a perfect prediction. It is a clear decision based on what you know today, with a plan to improve the decision when new evidence appears.

Mistakes That Distort Risk Decisions

Treating every risk as a technical problem

A business may describe a concern as “the system is vulnerable” and immediately look for a software product. That skips the business effect. The real concern may involve missed appointments, unpaid invoices, or exposed customer details. Without naming the effect, the business cannot judge whether the cost of a fix makes sense.

Do this: Write the event and the business result: “A stolen password could let someone change bank details on supplier invoices.”

Not this: “We need better security.”

Then rate likelihood, impact, and uncertainty. The clearer sentence points toward useful actions such as individual accounts, multi-factor authentication, payment-change verification, and staff training.

Confusing likelihood with impact

A rare event can cause severe damage, while a common event can cause only minor inconvenience. A stolen administrator password may be less common than a printer failure, but its impact could be far greater. Do not lower the priority of a risk because its likelihood is low when the possible damage is high.

Do this: Rate the two dimensions separately. Ask, “How often could this happen?” and “What would happen if it did?”

Not this: Use one overall feeling such as “it seems serious.”

If evidence remains weak, record high uncertainty. That label explains why you need a check rather than pretending that the risk has a reliable rating.

Assuming “unknown” means “safe”

Many businesses treat a lack of complaints as proof that systems work. A backup may appear successful while failing to restore a usable file. An old account may remain active without anyone noticing. A supplier may claim to protect information without explaining how it handles access or recovery.

Do this: Turn uncertainty into a specific question or test. Restore one file from a backup, review the active-user list, or ask the software provider how it removes former users.

Not this: Mark the risk low because no one has reported a problem.

The test should produce an observable result. For example, “The restored file opened correctly on the office laptop” gives stronger evidence than “Backups seem fine.”

Using a rating without a review date

Likelihood and impact change when the business changes. A new online payment feature, a staff departure, a move to cloud software, or a busy seasonal period can alter the risk quickly. A rating from last year may no longer describe today’s situation.

Do this: Record the date, evidence, owner, and next review. Review the risk after a major technology or staffing change and at a regular interval, such as every 30 days for high-impact access risks.

Not this: Keep an old risk list unchanged because nothing has gone wrong.

A useful risk record remains open to correction. The goal is not to sound certain. The goal is to make the next decision clearer, safer, and easier to explain. Once every concern has a plain description and a place on the Plain-Risk Compass, IT and cybersecurity risk stops being a cloud of technical terms and becomes a set of manageable choices.

End of chapter one. 39 more chapters in the full book.