Information Security Risk Assessment — How to Map Risks Before They Become Incidents

When building or maintaining a small system, I'm often tempted to immediately look for tools: installing a new firewall, turning on a scanner, or adding access rules. All of that is useful, but there is one question that should come first: which parts need to be protected most? Without those answers, security easily turns into a collection of crowded, but not always relevant, features.

This is where information security risk assessment comes in handy. This process is not a bulky document that is only suitable for large companies or auditor materials. For freelancers, small teams, website managers, even home server owners, it's a simple way to spot potential problems before they actually demand attention at an inconvenient hour.

Understanding risks, not just gaps

Security gaps and risks are often used interchangeably, even though they are not the same. A gap is a weakness, for example an admin password that is reused or an application that has not been updated. Risk is the possibility of that weakness being exploited and the impact it will have on the things we care about.

Imagine a house with unlocked windows. The window is a gap. The risks will differ between an empty warehouse and a space where important documents are stored. The location of the house, who can access the area, and the value of the items inside determine priorities. In digital systems, the way of thinking is similar.

Practically, risk can be recorded using the following simple formula:

Risiko = kemungkinan kejadian x dampak kejadian

The numbers in the formula do not have to be very precise. The low, medium, and high scales are enough to start with. The goal is not to predict the future perfectly, but rather to make security decisions more reasonable and explainable.

Start with the assets that really matter

A common initial mistake is to immediately create a list of attacks. It's better to start from assets, namely something whose value we want to protect. The asset is not always a server. Customer data, email accounts, domains, code repositories, backup configurations, laptop devices, and service reputation are also assets.

I usually divide it using three questions that are close to CIA principles: should the data remain confidential (confidentiality), remain accurate (integrity), and remain available when needed (availability)? A customer contact database may be high on confidentiality. A static profile page may not be very confidential, but its availability is still important if it is a business entry point.

Make a short inventory and don't try to record everything at once. For example, a small website might start with the following five assets:

• Website database and user data.
• Domain registrar and DNS accounts.
• CMS administrator account and hosting.
• Recoverable backup.
• Code repository and configuration files.

This inventory is often eye-opening. Many people are very focused on protecting the server, but forget that taking over a registrar account can redirect the domain to another location without touching the server at all.

Link assets to threats and weaknesses

Once you know what is of value, ask what could happen and why it might happen. A threat is the source of an event, such as phishing, ransomware, misconfiguration, or device failure. A vulnerability is a condition that allows a threat to succeed, such as missing MFA, a backup that was never tested, or an open administration port to the internet.

Don't stop at external threats. Disk failures, incorrectly deleting files, API tokens accidentally entering public repositories, and updates that break configurations are also worth noting. Information security risks are not just stories of masked attackers; Often it comes from everyday processes that have not been fenced off.

The simple table format makes this relationship easy to read:

Assess likelihood and impact without getting bogged down in numbers

For each scenario, rate the likelihood and impact from 1 to 3. Low likelihood means special conditions are needed or existing controls are strong. High probability means it happens easily or has already happened. Low impacts may only interrupt work briefly; high impact may result in data loss, recovery costs, privacy violations, or loss of user trust.

Multiply the two values. A score of 6 to 9 can be the first priority, 3 to 4 is in the repair queue, while 1 to 2 is enough to be monitored. This method is indeed simple, but its simplicity makes it possible to use it consistently. A small spreadsheet is more useful than a framework that is very complete but never complete.

Most importantly, write the reasons behind the value. Two people can give different scores, and a discussion of the reasons is much more valuable than debating whether the score should be a 6 or an 8. In the context of an audit or certification, a record of the reasons also shows that the decision was made based on context, not guesswork.

Select treatment for each risk

High risk does not always mean having to buy expensive solutions. There are four basic options: reduce, avoid, transfer, or accept the risk. Reducing means adding controls, such as MFA, regular updates, encryption, or off-site backups. Avoid means stopping activities that are too risky, for example no longer exposing the admin panel to the internet.

Transferring risk can be done through third party services, contracts, or insurance, although responsibility for the data still does not disappear. Accepting the risk is a valid choice if the impact is small and the costs of mitigating it are not worth it. However, this acceptance must be conscious and recorded, not because we forget to check.

For the registrar account example above, the most impactful action is usually simple:

1. Gunakan password unik dari password manager.
2. Aktifkan MFA dengan authenticator atau security key.
3. Simpan recovery code di tempat aman.
4. Aktifkan notifikasi perubahan DNS dan kontak akun.

These four steps do not make the risk zero, but they reduce the likelihood of a takeover drastically. That's the goal of good controls: proportional to asset value and easy to maintain.

Make risk assessment a habit

Risk assessment is not a one-time task. The system changes when we add applications, create new accounts, move hosting, or receive new data. Schedule short reviews every three or six months, and then also do them after major changes or small incidents. Small incidents are often a cheap wake-up call before expensive problems arise.

Keep a risk register in a place that responsible people can access, complete with action owners and review dates. No need to wait for a formal format like ISO 27001 to get started. In fact, the habit of recording assets, priority reasons, and proof of improvement is a foundation that will make it easier if one day compliance needs become more serious.

Closing

Information security is not about covering all possibilities, because that is not realistic. It's more like preparing a house before the rainy season: we check the roof, clean the gutters, and store important items in safe places because we know which parts are most vulnerable. Risk assessment helps us do the same thing in digital systems.

Start with the most important assets, create three to five risk scenarios, then complete the single action with the biggest impact this week. After that, repeat periodically. If you have a simple way to map risks on a project or home server, share it in the comments so we can learn from each other.