Designing a Hosting Risk Register: How to Map, Prioritise and Treat Infrastructure Risks with Your Provider

Who This Guide Is For And Why A Hosting Risk Register Matters

A hosting risk register is not about predicting every possible problem. It is about making the important risks visible, deciding how much you are willing to tolerate, and agreeing in advance who will do what when something does go wrong.

This guide is for people who look after websites, web applications or online services, but who are not full time infrastructure engineers. You might be:

• Running an ecommerce site such as WooCommerce and worried about lost orders if hosting fails
• Responsible for a membership platform, booking system or internal portal
• Involved in compliance or governance, and being asked awkward questions about uptime and data protection
• Planning a migration and wanting fewer surprises next time something breaks

The aim is to connect business reality to hosting decisions, so you can talk about risk in plain English with both your team and your hosting provider.

Typical situations where a risk register becomes necessary

Organisations usually feel the need for a hosting risk register after one of these triggers:

• A painful incident such as a prolonged outage, lost data or a security scare
• Growth where the website or platform now carries real revenue or operational importance
• Board or client pressure to show that risks are being managed, not left to “IT” in general
• Compliance requirements, for example PCI DSS, ISO 27001 or sector regulators
• A major change such as replatforming, moving to cloud or adopting a new provider

In all these cases, a structured risk register helps you move from “We hope it stays up” to “We understand key risks and have decided how to handle them”.

What a hosting risk register actually is in plain English

A hosting risk register is simply a list of things that could go wrong with the infrastructure and services that keep your site or application running, along with:

• How likely each issue is
• How serious the impact would be in business terms
• What you are doing about it now
• Who is responsible for prevention and response
• What you plan to improve over time

It is usually a spreadsheet or table, not a complicated tool. What matters is that you use it to have clear conversations with your hosting provider and internal stakeholders.

How it differs from a general IT risk log or a simple uptime SLA

You may already have a general IT risk log. Hosting risks often get buried inside that, with vague entries like “website outage” or “security breach”. A dedicated hosting risk register is more specific. It looks at concrete failure modes such as “DNS misconfiguration” or “database server full” and maps these to architecture and operational choices.

It is also very different from a simple uptime SLA. An SLA describes how your provider will credit you if they miss a target. It does not list the actual ways services can fail, nor how long recovery might take, nor what data you might lose. For a deeper look at uptime guarantees, you may find this article on evaluating hosting uptime guarantees useful.

A hosting risk register fills that gap between technical detail and contractual promises.

Step 1: Define What You Are Protecting And What ‘Failure’ Looks Like

Map critical services, not just servers

Start by ignoring servers and thinking in terms of services:

• “Customers can browse products and place orders”
• “Staff can log into the admin area to manage content and orders”
• “API clients can submit and retrieve data”

Each of these sits on top of multiple technical pieces. For a typical WordPress or WooCommerce site that might include:

• DNS records at your domain registrar
• Web server and PHP runtime
• Database server
• File storage for media and code
• SSL certificate service

List the services first, then note which components they depend on. The risk register will later attach risks to these components, but always with the service impact in mind.

Clarify business impact: revenue, reputation, compliance and operations

For each service, ask four questions:

• Revenue: If this stops for an hour, what do we lose? For a day?
• Reputation: Who notices, and what might they think or say?
• Compliance: Could this lead to a breach of contract, regulation or policy?
• Operations: What workarounds do staff need to keep going?

Write these in your own language. For example:

• “If checkouts fail on Black Friday for 30 minutes, we could lose around £20k in sales.”
• “If the staff portal is offline for half a day, we can manage with spreadsheets.”
• “If customer data is lost, we may need to report to the ICO and notify affected users.”

This framing will help you make sensible trade offs later. Not every service needs the same level of resilience.

Set realistic availability and recovery objectives (RTO, RPO) in plain English

Two common terms in continuity planning are:

• Recovery Time Objective (RTO): How long you can tolerate a service being down before it must be restored.
• Recovery Point Objective (RPO): How much data you can afford to lose in time terms, for example “no more than 15 minutes of orders”.

Translate these into simple statements and record them in your register:

• “If the site goes down, we can tolerate up to 1 hour outage during normal days, but only 10 minutes during major campaigns.”
• “We can accept losing up to 1 hour of order data in a worst case scenario.”

Later, you can compare these objectives against what your hosting platform, architecture and backup schedule can actually deliver. Any gap between “want” and “can” is itself a risk entry.

Step 2: Identify Hosting And Infrastructure Risks Across The Stack

Now you know what you are protecting and how sensitive it is, you can systematically identify risks across the hosting stack. A layered view helps:

• Physical and data centre
• Network and DNS
• Servers and operating systems
• Application and third party services
• People and process

The existing article on why websites go down lists many common failure modes that you can convert directly into risk entries.

Physical and data centre level risks

These are mostly in your provider’s hands, but they belong in your register because they affect your availability and RTO. Examples:

• Power failure beyond UPS or generator capacity
• Cooling failure leading to hardware shutdown
• Hardware failures such as disks or network switches
• Major incidents affecting an entire facility

Typical register entry:

“Loss of primary data centre causing several hours of downtime for production site. Impact: High. Owner: provider (infrastructure), us (business continuity and communication). Current controls: provider redundancy and SLAs; our status page and communication plan.”

Network, DNS and connectivity risks

These often explain why “the server is fine but the site is down”. Key risks include:

• DNS misconfiguration or expired records
• Registrar or DNS provider outage
• DDoS or abusive traffic saturating network connections
• Routing issues between regions or ISPs

If you rely on a content delivery and protection layer like the G7 Acceleration Network, you should record both its benefits and the risk that a misconfiguration there could affect traffic flow. The network can also filter abusive traffic before it reaches your application servers, which may reduce some availability risks.

Server, virtualisation and operating system risks

At this layer, think about the virtual or physical machines your applications run on:

• Single points of failure on a single server
• Host or hypervisor failures affecting all virtual machines on that node
• Kernel or OS updates that require reboots
• Resource exhaustion such as CPU, RAM or disk full

Risks and controls look very different depending on whether you are on basic shared hosting, a VPS, or virtual dedicated servers that isolate your resources. Note in the register what you are actually using and how that affects likelihood and impact.

Application level risks: WordPress, WooCommerce and third party services

Here you focus on how your specific application behaves:

• WordPress plugins or themes causing fatal errors after updates
• WooCommerce extensions that introduce performance bottlenecks at checkout
• Misbehaving cron jobs or scheduled tasks
• Dependencies on third party APIs such as payment gateways or shipping providers

For each, describe:

• What breaks when the component fails
• Who detects it and how
• How you roll back, patch or work around the issue

People and process risks: access, updates and change control

Many serious incidents are triggered by well meaning changes. Typical human and process risks:

• Wrong DNS record edited or domain accidentally transferred
• Production configuration changed directly without testing
• Critical accounts with weak passwords or too many people sharing logins
• Lack of documented recovery steps or on call contacts

It may feel uncomfortable to write these down, but they are some of the easiest to reduce with sensible controls and, in some cases, managed services.

Step 3: Map Ownership Using Shared Responsibility

Why shared responsibility matters for risk registers

Most hosting today uses some form of shared responsibility. The provider takes on certain layers such as physical security and core infrastructure, while you remain responsible for your application, data and some security choices.

Your risk register should make these boundaries explicit. For each risk, you are asking: “Is this mainly on us, on the provider, or genuinely shared?” The article What ‘Shared Responsibility’ Really Means in Hosting offers a deeper breakdown you can adapt.

Translating ‘managed’, ‘unmanaged’ and shared hosting into risk owners

Terminology varies, but broadly:

• Shared hosting: The provider manages the platform, but you manage your application and content. You have limited control over architecture.
• Unmanaged VPS or server: You or your IT partner manage the operating system and above. The provider looks after power, hardware and network.
• Managed hosting or managed VPS: The provider takes on more day to day operational tasks such as monitoring, patching and backups.

In your register, each risk entry can include a short owner note such as “Provider infrastructure”, “Customer application”, or “Shared; provider monitors, we approve changes”. This clarifies who will act when something happens.

Using a simple RACI-style view for hosting risks

A light touch RACI model works well:

• Responsible: Who actually does the work
• Accountable: Who ultimately owns the risk and its treatment
• Consulted: Who gives input before decisions
• Informed: Who needs to know about incidents or changes

You do not need this for every minor entry, but for major risks such as “Loss of production database” it is helpful to be explicit. The article What ‘Managed’ Really Covers provides example RACI tables you can adapt directly into the ownership column of your risk register.

Step 4: Score And Prioritise Risks In A Way Non‑Engineers Understand

Likelihood vs impact: keeping the scale simple

Risk scoring does not need to be scientific. A simple scale works well:

• Likelihood: Low, Medium, High
• Impact: Low, Medium, High

You can convert these to numbers if you like (for example 1 to 3) and multiply to get a rough priority. More important than the exact number is that the people responsible for budget and architecture understand what “High impact” means in their world.

Examples: comparing a one hour outage vs silent data corruption

Consider these two risks:

• One hour outage during a quiet period: Customers see an error page. You lose some orders but can recover quickly.
• Silent data corruption: Orders appear to complete but are not stored correctly. You discover the issue days later.

The outage might be High likelihood, Medium impact. The corruption might be Low likelihood, High impact. Even though the second is less likely, you may decide to invest more in controls such as better monitoring, database replicas or more frequent backups because trust and reconciliation effort are at stake.

Linking risk scores to budget and architecture decisions

Once you have a first pass of scores, you can group risks like this:

• High impact / Medium or High likelihood: Consider architectural changes or managed services to reduce or share the risk.
• High impact / Low likelihood: Focus on good backups, disaster recovery and communication plans.
• Medium impact / High likelihood: Often procedural fixes or configuration changes will significantly reduce frequency.

This is where you might decide, for example, that checkouts justify moving from a single shared server to a more resilient setup, while a low traffic blog can remain on a simpler platform.

Step 5: Choose Treatments: Avoid, Reduce, Transfer Or Accept

Common hosting risk treatments in practice

Each risk entry should have a chosen treatment strategy:

• Avoid: Change your approach so the risk does not exist, for example removing a fragile plugin.
• Reduce: Add controls to lower likelihood or impact, such as rate limiting or automatic failover.
• Transfer: Move some responsibility elsewhere, such as using managed services or insurance.
• Accept: Document that the risk is tolerable, usually after improvement costs are compared against impact.

Where hosting architecture changes reduce risk

Architecture is one of your strongest levers to reduce risk. Examples:

• Moving from a single shared server to a VPS or virtual dedicated server to reduce noisy neighbour and resource contention issues.
• Adding a staging environment so updates are tested before hitting production.
• Using a content acceleration and protection layer, such as the G7 Acceleration Network, to cache content, optimise images and filter abusive traffic before it reaches your origin.

Each of these should be visible in the register as a control that reduces the likelihood or impact score for specific risks.

What insurance, SLAs and contracts really transfer (and what they do not)

It is important to be realistic about “transferring” risk via contracts:

• SLAs may return a portion of fees after prolonged downtime, but they do not recover lost sales or reputational damage.
• Cyber insurance may help with recovery costs after a breach, but it does not remove your obligations to customers or regulators.
• Managed hosting contracts transfer operational responsibility, but you still own your data and governance duties.

Record these distinctions in your risk register so stakeholders understand that “we have an SLA” is not a complete answer in itself.

Concrete Examples: Turning Real Hosting Problems Into Register Entries

Example 1: Payment gateway timeouts on WooCommerce checkouts

Risk: Payment gateway API slows or fails, leading to abandoned carts or duplicate charges.

• Impact: High, direct revenue loss and customer frustration.
• Likelihood: Medium, especially at peak times.
• Owner: Shared between you (integration and retry logic) and the gateway.
• Treatment: Reduce via monitoring, clear timeout handling, and communication templates; accept some residual risk.

Example 2: DNS misconfiguration or registrar outage

Risk: Domain stops resolving to the correct servers, making all services unreachable.

• Impact: High for public sites and email.
• Likelihood: Low to Medium, depending on controls.
• Owner: Mainly you or whoever manages DNS; provider may assist in troubleshooting.
• Treatment: Reduce through change control, access restrictions and using reputable DNS providers with redundancy.

Example 3: Security incident vs full data breach

Risk A: Security incident such as a compromised plugin that can be contained quickly.

Risk B: Full data breach where customer data is extracted.

• Impact: Incident may be Medium; breach is High with regulatory and reputational consequences.
• Controls: Regular updates, Web Application Firewall, strong access controls, and web hosting security features from your provider.

Treat them separately in the register: one focusing on early detection and quick patching, the other on encryption, least privilege access and incident response planning.

Example 4: Capacity and traffic spikes during campaigns or peak days

Risk: Planned marketing campaigns or seasonal peaks drive more traffic than your infrastructure can comfortably handle.

• Impact: High potential revenue and brand impact.
• Likelihood: Medium, highly predictable if linked to campaigns.
• Treatment: Reduce via load testing, scaling plans, caching, and use of an acceleration layer that offloads static and optimised assets to a global edge.

Note which controls are architectural, which are provider managed and which rely on your internal planning.

Linking Your Risk Register To Hosting Choices And Architecture

Single server vs multi server vs high availability for different risk profiles

Your risk register should directly influence how ambitious your architecture needs to be:

• Single server: Simple and cost effective, but many risks converge on one point of failure. Suitable for low criticality sites.
• Multi server: Separate web and database servers, or multiple web servers behind a load balancer, reduce some risks and enable maintenance with less downtime.
• High availability: Redundant components and automatic failover. More complex and costly, justified where downtime impact is clearly high.

Use the register to articulate why a particular service needs (or does not need) to move to a more resilient design.

When shared hosting, VPS or virtual dedicated servers fit your risk appetite

You can think of hosting tiers in terms of risk appetite and control:

• Shared hosting: Lower cost, less control, more shared risk. Often acceptable for low revenue or informational sites.
• VPS: Greater control over configuration and isolation, with more operational responsibility on your side.
• Virtual dedicated servers: Dedicated resources and stronger isolation, useful where noisy neighbours or performance unpredictability are rated as significant risks.

Your register becomes the justification document for why a particular application should sit on one tier or another.

How managed platforms and WAF / acceleration layers change the risk picture

Managed platforms and services such as WAFs and global acceleration networks can:

• Reduce operational risks by having specialists handle monitoring, patching and tuning.
• Lower availability risks from traffic spikes by caching, compressing and optimising content such as images, which the G7 Acceleration Network does by converting to modern formats like AVIF and WebP and often cutting image sizes by more than 60 percent.
• Filter abusive or malicious traffic before it hits your origin servers.

At the same time, you add a new component that must be configured and monitored correctly. These trade offs should be visible in your risk register.

Backups, Redundancy And Disaster Recovery: Where They Sit In Your Register

The difference between backups, redundancy and failover in risk terms

Many teams bundle these together, but they address different risks:

• Backups protect against data loss and corruption.
• Redundancy (for example multiple servers) reduces unplanned downtime when one component fails.
• Failover defines how traffic is redirected to another system when something breaks.

Your register should track risks separately for each. The article Backups vs Redundancy offers a clear explanation that many teams use as a reference.

How to record RPO and RTO as explicit risks, not vague wishes

If you state “We need RPO of 15 minutes and RTO of 1 hour” but your backups run nightly and your provider’s realistic recovery time is several hours, you have a risk.

Create entries such as:

• “Current backup schedule means potential loss of up to 24 hours of data (RPO 24h vs objective 1h). Treatment: improve backup frequency or accept increased RPO.”
• “Current recovery approach means outage could last 4 hours (RTO 4h vs objective 1h). Treatment: move database to highly available setup or explicitly adjust objective.”

Working with your provider on realistic disaster recovery plans

Your provider can usually help you translate risk entries into a practical plan that aligns with your architecture and budget. The guide From Backups to Business Continuity walks through that process.

In your register, cross reference the disaster recovery plan so that auditors, management and technical staff can see how the pieces connect.

Governance, Compliance And PCI: When Your Register Needs Extra Detail

When PCI DSS, ISO 27001 or regulators start asking for evidence

If you handle cardholder data or operate in regulated sectors, your risk register will often become a formal artefact. Standards such as PCI DSS or ISO 27001 expect you to show that you identify, assess and treat risks in a structured way.

For card data specifically, you may look at PCI conscious hosting options where elements of network segmentation, logging and platform hardening are supported by the provider. Your register should list which hosting controls contribute to compliance, and which remain your responsibility.

Documenting controls that live with your host vs your own team

For each compliance relevant risk, note:

• Which technical control is provided by the hosting platform
• Which procedural control is managed by your organisation
• Where evidence lives (logs, reports, change records)

This saves a great deal of time when auditors or clients ask, “How do you know that this control is operating?”

Using the register as a living document for audits and board reporting

Used well, your hosting risk register can feed:

• Board summaries such as “Top 5 infrastructure risks and our planned treatments”
• Audit responses that point to concrete controls and test results
• Vendor due diligence packs for your own customers

Keep the language clear and non technical where possible so that non engineers can see the logic behind your hosting choices.

How To Maintain Your Hosting Risk Register Over Time

Triggers to review: big updates, new features, incidents and migrations

Your register should not sit untouched for years. Common triggers for review include:

• Major application updates or new features
• Significant traffic or usage changes
• Incidents or near misses that reveal gaps
• Hosting migrations or architecture changes

When one of these happens, take 30 minutes to ask: “Does this introduce new risks, or change the likelihood and impact of existing ones?”

Practical meeting rhythm with your hosting provider

For many SMEs, a quarterly or twice yearly review with the hosting provider is enough. A typical agenda:

• Review of any incidents since the last meeting
• Changes you or the provider have made that affect risk
• Top 5 risks you would like to reduce and possible treatments
• Any compliance or audit questions coming up

This creates a rhythm where your register becomes a shared working document rather than an internal spreadsheet that the provider never sees.

What ‘good enough’ looks like for SMEs without a full risk team

You do not need a formal risk department to get value from this approach. For many organisations, “good enough” means:

• A simple, maintained register for your main sites and applications
• Clear ownership for major risks and incidents
• Documented, realistic RTO and RPO that match your architecture
• Regular check ins with your hosting provider, especially before and after big changes

Where risks and required controls become complex or high impact, that is usually the point to consider managed hosting or enterprise services to reduce operational load and avoid subtle mistakes.

Summary: Turning Hosting Risk From Vague Worry Into Clear Decisions

A hosting risk register is ultimately a communication tool. It helps you:

• Connect business impact to technical realities
• Clarify who owns which risks under a shared responsibility model
• Prioritise improvements in architecture, process and managed services
• Demonstrate to boards, clients and auditors that you are managing infrastructure risk purposefully

You will never eliminate every risk, and you do not need to. What you can do is deliberately choose which risks to accept, and which justify investment in better design, stronger processes or managed platforms that take more of the operational burden off your team.

If you would like a second pair of eyes on your draft register or want to explore whether shared, VPS, managed or virtual dedicated servers best match your risk appetite, you are welcome to talk to G7Cloud about your current architecture and options.