CYBERSECURITY | Tutorial: Build a Practical Security Risk Register for Your Website or Digital Business

A website can look professional, work correctly, and attract customers while still having weaknesses that could damage the business behind it.

Someone might gain access to its administrator account. A hosting account could be compromised. A failed backup could make recovery impossible. An outdated plugin could introduce a vulnerability. An employee might accidentally expose confidential information.

The challenge is not simply knowing that these risks exist. It is deciding what needs protection, what could go wrong, how serious the consequences would be, and what to fix first.

In this tutorial, you will build a cybersecurity risk register for a website or small digital business. You will identify important digital assets, describe realistic threat scenarios, score risks, choose safeguards, and create a prioritized action plan.

This is a practical introduction to risk-based cybersecurity. It uses the same general principle found in established frameworks: understand your environment, identify risks, select appropriate controls, and review whether those controls work. The NIST Cybersecurity Framework provides a broader structure for managing cybersecurity risk.

What you will build: A reusable cybersecurity risk register and an action plan.

Tools: Google Sheets or another spreadsheet application.

Level: Beginner to intermediate.

Cost: You can complete the exercise using a free spreadsheet tool.

Prerequisites: Basic spreadsheet skills and a website, application, or fictional digital-business scenario to assess.

1. Understand what a cybersecurity risk register does

A cybersecurity risk register is a structured record of possible security problems, their potential consequences, and the actions planned to reduce them.

It helps answer questions such as:

• What digital assets are important to the business?
• What could happen to each asset?
• How likely is each scenario, given what we currently know?
• What would the consequences be?
• What safeguards already exist?
• What needs to be done next?
• Who is responsible for the action?
• How will we know whether the risk has been reduced?

Without a register, a business might spend money on a sophisticated security product while leaving its most important account unprotected.

A risk register helps direct attention toward the risks that matter most.

Understand four related concepts

Asset: Something valuable that needs protection, such as a domain name, website, customer database, business email account, or backup.

Threat: Something that could cause harm, such as a phishing attacker, malicious software, accidental deletion, or a service outage.

Vulnerability: A weakness that could allow a threat to cause harm, such as an unpatched application or poorly protected administrator account.

Risk: The possibility of harm when a threat exploits a weakness or another failure occurs, considered alongside the likelihood and consequences.

For example:

• Asset: Business email account.
• Threat: An attacker attempts to take over the account.
• Vulnerability: The account lacks an additional authentication factor.
• Consequence: The attacker could impersonate the owner, reset other passwords, or access confidential correspondence.
• Risk response: Strengthen authentication, review recovery settings, and monitor account activity.

The risk is not simply that the account has a password. The concern is the potential business damage if the account is compromised.

2. Choose the system you will assess

Start with one clearly defined system. Do not try to assess every device, account, application, and business process at once.

For this tutorial, imagine a small business with:

• A public website.
• A domain registered with a domain registrar.
• A hosting account.
• An administrator account for the website.
• A business email account.
• Customer enquiry records.
• Backups of the website.
• A contact form.

This is a fictional example, but the same process can be adapted to a Blogger blog, a WordPress website, an online store, a SaaS application, or a small agency.

Write a scope statement before beginning.

For example:

This assessment covers the website, domain registration, hosting, administrator access, business email, customer enquiry information, backups, and the recovery procedures supporting the website.

The scope statement prevents the assessment from becoming an unmanageable investigation into every possible cybersecurity issue.

Identify what is outside the scope

You might exclude the hosting provider's internal infrastructure because you do not control it. You should still record your dependence on the provider and consider its security responsibilities, service commitments, and available recovery options.

Likewise, this exercise does not authorize you to test systems belonging to other people.

Assess systems you own or have explicit permission to assess.

3. Create your risk register

Open a spreadsheet and create a sheet named Risk Register.

Add these headings in row 1:

Column	Heading	Purpose
A	Risk ID	Unique reference for the risk
B	Asset	What needs protection
C	Threat scenario	What could happen and how
D	Vulnerability or condition	What makes the scenario possible
E	Business impact	The possible consequences
F	Likelihood	Estimated likelihood on your chosen scale
G	Impact score	Estimated severity of consequences
H	Risk score	Calculated priority indicator
I	Existing controls	Safeguards already in place
J	Planned action	What you intend to do
K	Owner	Who is responsible
L	Due date	When the action should be completed
M	Status	Current action status
N	Residual risk	Risk remaining after the action

Use one row for each distinct risk scenario.

Do not write vague entries such as “cyberattacks are dangerous.” Describe an event that could actually happen to the system you are assessing.

A useful scenario format is:

Because of [condition], [event] could affect [asset], resulting in [consequence].

For example:

Because administrator access is not protected by multi-factor authentication, an attacker who obtains the password could take over the website and publish malicious content.

That statement is much more actionable than “website security.”

4. Identify the assets that matter most

Create a second sheet named Asset Inventory.

Record the important assets, their purpose, their owner or provider, and the consequences if they are lost or compromised.

Start with these categories.

Identity and access

• Primary business email.
• Website administrator account.
• Domain registrar account.
• Hosting account.
• Accounts with permission to manage payments.
• Recovery email addresses and authentication methods.

Applications and infrastructure

• Domain name and DNS settings.
• Website or application.
• Content management system.
• Plugins, themes, dependencies, and integrations.
• Hosting environment.
• SSL/TLS certificate configuration.

Data

• Customer enquiries.
• Orders and transaction records.
• Business documents.
• Website configuration.
• Application source code.
• Backups and recovery information.

Business operations

• Website availability.
• Online payment processing.
• Customer communication.
• Order fulfilment.
• Ability to restore the website.
• Ability to recover access to critical accounts.

Not every business has every asset. Include only the assets relevant to the system being assessed.

Rank assets by business importance

For each asset, consider:

1. Confidentiality: Would unauthorized disclosure cause harm?
2. Integrity: Would unauthorized changes cause harm?
3. Availability: Would losing access or functionality disrupt operations?

These are three core security objectives.

A public marketing page may not contain confidential information, but its integrity and availability still matter. An attacker who changes the page or makes it unavailable could damage customer trust and interrupt business.

A customer database, by contrast, may require stronger confidentiality protections because it contains information that should not be publicly accessible.

5. Identify realistic threat scenarios

Now examine what could go wrong for each important asset.

Use the following examples as a starting point, adapting them to your actual system.

Asset	Possible scenario	Potential consequence
Business email	Unauthorized access following credential theft	Impersonation, data exposure, or password resets for other accounts
Domain registrar	Account takeover	Unauthorized DNS changes or loss of domain control
Hosting account	Unauthorized administrator access	Website modification, service disruption, or exposure of stored information
Website software	A vulnerable component is exploited	Unauthorized access, data exposure, or malicious changes
Customer data	Incorrect permissions expose records	Privacy harm, loss of trust, or legal and contractual consequences
Backups	Backups are missing, incomplete, or inaccessible	Extended outage or inability to recover data
Contact form	Automated abuse or spam overwhelms the form	Operational disruption and wasted time
Website administration	Excessive permissions are granted to users	Accidental or unauthorized changes beyond what a user needs

These are possible scenarios, not claims that your website is currently vulnerable.

Do not assume a vulnerability exists just because it appears in this table. Investigate the relevant configuration, available evidence, and safeguards before deciding how to score the risk.

Include accidental failures

Cybersecurity risk is not limited to malicious attackers.

A staff member might delete a page, expose a file, misconfigure DNS, or overwrite important data. A hosting service might become unavailable. A backup process might silently stop working.

A useful risk register includes realistic failures as well as deliberate attacks.

6. Score likelihood and impact consistently

You need a simple way to compare risks.

For this exercise, use a three-point scale for likelihood and impact.

Score	Likelihood	Impact
1	Unlikely under current conditions	Limited disruption or easily recoverable loss
2	Plausible	Meaningful disruption, expense, or operational damage
3	More likely or strongly indicated by available evidence	Severe disruption, major loss, or substantial harm

These are illustrative categories, not universal industry standards. Define them in a way that fits your business and apply them consistently.

Calculate a risk score

For this exercise, use:

[ \text{Risk score}=\text{Likelihood}\times\text{Impact} ]

The resulting score ranges from 1 to 9.

For example, if unauthorized access to your business email is rated likelihood 3 and impact 3:

[ 3\times3=9 ]

That gives the scenario a high priority under this simple model.

You can use the following provisional bands:

Score	Priority	Suggested response
1–2	Lower	Maintain appropriate controls and review periodically
3–4	Moderate	Plan a proportionate improvement
6	High	Assign an action and address it promptly
9	Critical priority	Escalate and address urgently

These bands are a practical exercise convention, not a validated prediction of the probability of an incident. A score of 9 does not mean that an attack is certain.

Some risks also require immediate action regardless of their calculated score. A confirmed compromise, exposed secret, or known critical vulnerability affecting an exposed system should not be ignored because a simple formula gives it a low number.

Add the formula in Google Sheets

Suppose likelihood is in column F and impact is in column G.

In H2, enter:

=F2*G2

Fill the formula down the risk register.

To classify the score automatically, you can add a separate priority column and use:

=IF(H2>=9,"Critical",IF(H2>=6,"High",IF(H2>=3,"Moderate","Lower")))

This formula implements the illustrative bands above. It does not independently determine whether your risk assessment is correct.

The quality of the result depends on the evidence and reasoning behind the likelihood and impact ratings.

7. Build a worked example

Consider a small business whose primary email account can reset passwords for its website and domain registrar.

Its risk register might contain the following entry:

Field	Example entry
Risk ID	R-001
Asset	Primary business email
Threat scenario	An attacker takes over the email account
Vulnerability or condition	Authentication and recovery settings have not been reviewed
Business impact	Other accounts may be compromised through password resets
Likelihood	3 — provisional estimate
Impact	3 — severe potential consequences
Risk score	9
Existing controls	Password and account recovery
Planned action	Enable strong additional authentication, review recovery methods, and check active sessions
Owner	Business owner
Status	Not started

The score is provisional. It must be reconsidered after examining the actual account configuration and available evidence.

Why prioritize this account?

Because it may control access to several other assets. Protecting it can reduce risk across the wider business.

This illustrates an important principle: some assets are more important because other assets depend on them.

A domain registrar account, primary email account, or cloud administrator account can become a control point for an entire digital operation.

8. Select safeguards that address the actual risk

A risk response should target the conditions that make the scenario possible or reduce the consequences if it occurs.

For example:

Risk	Potential safeguard
Email account takeover	Use a unique password or passkey, enable strong multi-factor authentication where available, and review recovery settings
Domain account takeover	Protect the registrar account, restrict access, enable available account protections, and review DNS-change notifications
Website compromise	Keep supported software and components updated, restrict administrator access, and remove unused components
Data exposure	Minimize collected information, restrict access, and configure storage and sharing permissions appropriately
Failed recovery	Maintain suitable backups and test whether restoration actually works
Unnecessary privileges	Give each user only the permissions required for their work
Lost administrative access	Maintain a documented, secure account-recovery procedure

For accounts that support it, passkeys or other phishing-resistant authentication methods can provide stronger protection against credential-phishing attacks than passwords alone. The National Institute of Standards and Technology's guidance on multi-factor authentication explains why using more than one authentication factor can make unauthorized access more difficult.

Choose safeguards that fit your actual platform. For example, a Blogger site and a self-hosted WordPress site have different administrative responsibilities.

Do not recommend installing a security plugin on a platform that does not support it.

9. Turn the assessment into a prioritized action plan

A risk register becomes useful when it leads to completed actions.

Create a sheet named Action Plan with these headings:

Heading	What to record
Action ID	Unique task identifier
Risk ID	The risk the action addresses
Action	The specific change to make
Priority	Critical, high, moderate, or lower
Owner	Person responsible
Due date	Target completion date
Verification	Evidence that the action worked
Status	Not started, in progress, blocked, or completed

Avoid writing actions that are too vague to verify.

Weak action:

Improve security.

Better action:

Enable the strongest suitable additional authentication method supported by the primary business email account, review recovery methods, and verify that the configured method works.

Another weak action:

Improve backups.

Better action:

Confirm that a current backup exists, identify where it is stored, and perform a controlled restoration test using a suitable test environment or recovery procedure.

The second version gives you a clear way to establish whether the work has been completed.

Prioritize dependencies

If the business email account can reset access to the domain registrar and hosting account, protect the email account early in the action plan.

If the website holds customer records, data protection and recovery controls may also deserve high priority.

Do not prioritize tasks solely by how easy or interesting they are. Prioritize them by the risk they address, the possible consequences, the evidence available, and any obligations that apply to your business.

10. Decide how to handle each risk

Not every risk requires the same response.

Four common approaches are:

Mitigate: Introduce safeguards that reduce likelihood or impact.

Example: Enable stronger authentication for an important account.

Avoid: Stop the activity that creates the risk.

Example: Remove an unnecessary public-facing feature that creates more risk than business value.

Transfer or share: Arrange for another party to take on some financial or operational consequences.

Example: Consider suitable cyber insurance or contractual allocation of responsibilities, where appropriate. This does not eliminate the underlying risk or all liability.

Accept: Make an informed decision to retain the remaining risk.

Example: A small, low-impact risk may be accepted temporarily if the cost of addressing it is disproportionate and the decision is understood.

Acceptance should not be an excuse for ignoring a serious problem. Record the reason, the person approving the decision, any limitations, and when the decision should be reviewed.

For a small business, some risks may need specialist advice, particularly where regulated data, financial services, sensitive information, or contractual obligations are involved.

11. Measure the remaining risk

After implementing a safeguard, reconsider the original scenario.

This is called assessing residual risk: the risk that remains after the chosen controls are in place.

Suppose the initial estimate for unauthorized email access was:

• Likelihood: 3
• Impact: 3
• Initial score: 9

After enabling a suitable authentication method, reviewing recovery settings, and removing unnecessary access, you might estimate likelihood at 2 while impact remains 3.

The revised score would be:

[ 2\times3=6 ]

This is only an illustrative example. You should not lower a risk score merely because a control was enabled. Consider whether the control is appropriate, whether it was configured correctly, and whether you have evidence that it works.

For instance, a backup is not proven effective merely because a dashboard says that a backup job succeeded. A restoration test provides stronger evidence that the data can actually be recovered.

Likewise, enabling authentication protection does not prove that every possible account-takeover route has been eliminated.

12. Verify the safeguards

For every completed action, record the evidence that supports the completion claim.

Examples include:

• A confirmed account-security setting.
• A successful test login using the configured authentication method.
• A record of a reviewed user-access list.
• A completed software-update record.
• A successful restoration test.
• A documented procedure for reporting suspicious activity.
• A verified alert or notification configuration.

Avoid storing passwords, recovery codes, API keys, or other secrets in the risk register itself. Record the existence and status of the safeguard, not the secret value.

If an action cannot be verified, leave it open or mark it as needing further investigation.

This is the difference between saying that a business intends to be secure and having evidence that specific safeguards are operating as expected.

13. Review the risk register regularly

Cybersecurity risk changes when the business changes.

A new website feature, payment provider, employee, plugin, integration, or cloud service may introduce new risks. A software update may remove one vulnerability while a configuration change introduces another problem.

Review the register when:

• A significant system or service changes.
• A new user receives administrative access.
• A security incident occurs.
• A provider announces a relevant security issue.
• Important data begins to be collected.
• A recovery procedure fails a test.
• A previously accepted risk becomes more serious.

You can also schedule periodic reviews appropriate to the size and complexity of the business.

During a review, ask:

1. Are the assets still accurate?
2. Have new threats or vulnerabilities appeared?
3. Have the safeguards changed?
4. Were planned actions completed?
5. Has new evidence changed the risk assessment?
6. Does the remaining risk need a different response?

A risk register should evolve with the system. It is not a document you complete once and forget.

14. Understand the limits of this exercise

This tutorial provides a practical starting point, not a complete cybersecurity audit or certification.

A spreadsheet cannot establish by itself that a website is secure. Some weaknesses require technical configuration reviews, specialist testing, log analysis, or a deeper assessment of the infrastructure.

For a public website, more advanced work may include:

• Reviewing application and server configuration.
• Checking software dependencies and supported versions.
• Examining access-control design.
• Reviewing data collection, storage, and retention.
• Testing backup restoration and disaster recovery.
• Reviewing incident-response procedures.
• Conducting authorized security testing where appropriate.

The OWASP Web Security Testing Guide provides a more technical framework for assessing web application security.

Use authorized environments and follow the relevant rules of engagement. Do not scan, probe, or attempt to exploit someone else's systems without permission.

If you discover evidence of an active compromise, exposed credentials, or a serious vulnerability, prioritize containment and appropriate incident response rather than waiting for the next scheduled review.

15. Your practical assignment

Create a risk register for your own website, application, or a fictional small digital business.

Include at least six distinct risk scenarios covering relevant assets such as identity and access, infrastructure, data, availability, and recovery.

Complete the following tasks:

• [ ] Define the system and assessment scope.
• [ ] Create an asset inventory.
• [ ] Identify realistic threat scenarios.
• [ ] Record the conditions that could make each scenario possible.
• [ ] Estimate likelihood and impact consistently.
• [ ] Calculate initial risk scores.
• [ ] Record existing safeguards.
• [ ] Prioritize actions.
• [ ] Assign owners and due dates.
• [ ] Define how each action will be verified.
• [ ] Record residual risk after controls are tested.
• [ ] Identify risks that require specialist investigation.

Finally, write a short summary answering these questions:

1. Which risk should be addressed first, and why?
2. Which important asset does the business depend on most?
3. Which safeguard has the strongest evidence that it works?
4. Which risk remains unresolved?
5. What is the next action, and who is responsible for it?

Your goal is not to produce a perfect score. It is to create a defensible, practical plan for reducing the risks that could cause the greatest harm.

What you have learned

You have built a basic cybersecurity risk-management workflow:

Define → Identify → Assess → Prioritize → Treat → Verify → Review.

This approach applies beyond websites. It can support the assessment of business email, cloud systems, online stores, software projects, internal workflows, and other digital assets.

As your technical knowledge grows, you can replace broad estimates with stronger evidence from configuration reviews, vulnerability assessments, monitoring, and authorized security testing.

The central lesson is simple: cybersecurity is not just a collection of tools. It is the ongoing process of understanding what matters, identifying how it could be harmed, choosing proportionate safeguards, and checking whether those safeguards actually work.

Your objective is to make informed security decisions—not merely to accumulate security products or check boxes.

Official references

• NIST Cybersecurity Framework
• NIST: Multi-factor authentication
• OWASP Web Security Testing Guide

Image: TerraLogic