Where your data lives, and why it matters legally

This picks up from a server you can already reach over SSH.

Yes, it can matter legally where your server lives if you are a UK business processing personal data. Keeping customer data on a UK server usually avoids the UK GDPR rules on restricted transfers. Hosting in the US counts as a restricted transfer and you need a lawful transfer mechanism before you put personal data there.

This guide is general information, not legal advice.

Before you start

• What counts: UK GDPR applies to personal data. Pseudonymised data is still personal data. Only data that has been truly anonymised falls outside the UK GDPR.
• Transfers are broader than you think: a restricted transfer happens if an organisation outside the UK can access personal data on your systems. That includes overseas remote support or administration, not only where the server sits.
• Adequacy is easiest when it fits: the UK has adequacy regulations for the US through the UK Extension to the EU‑US Data Privacy Framework, known as the UK‑US Data Bridge. It covers transfers to US organisations that are DPF‑certified and have opted into the UK Extension. It does not cover everyone in the US.
• If adequacy does not fit, use safeguards: the UK International Data Transfer Agreement (IDTA) or the UK Addendum to the EU Standard Contractual Clauses, plus a transfer risk assessment. The ICO now calls this the data protection test in UK law, although its guidance still uses TRA in places.
• Sector rules can be stricter: NHS guidance expects UK, EEA or an adequate country unless extra approvals and controls are in place. Financial services firms must meet FCA and PRA outsourcing and operational resilience expectations, which include clear data location and third‑party risk management.
• Migrations carry risk: deleting or rebuilding a live VPS before you have completed and verified a full migration can permanently destroy data and take sites or email offline. Build the target server first, copy and verify data, update DNS, then decommission.
• Hostworld context: using our London VPS keeps data in the UK. Using our New York VPS to hold UK customer personal data is a restricted transfer to the US, so you need adequacy or safeguards in place.

Step 1: Decide where your data should live right now

Choose the location that fits your compliance posture and paperwork appetite.

• If you want to avoid international transfer paperwork, use our UK location. See our London VPS.
• If you have a clear reason to host in the US, plan your lawful transfer route first, then build. For US hosting, either ensure the US recipient is covered by the UK‑US Data Bridge, or put the IDTA or UK Addendum in place and complete the transfer risk assessment or data protection test.

Step 2: Inventory what personal data you hold and who can access it

List the categories of personal data you process, where each set lives, and who can access it, including support providers and contractors in other countries. Do not forget backups, monitoring and out‑of‑hours support. This gives you a clear view of whether any overseas organisation can access data on your systems.

You will need to know which public IP your VPS is using. That address is shown against the VPS in Virtualizor, reached from your Hostworld client area, and looking it up there involves no third party.

You can also check from the terminal, with one caveat worth naming in an article about limiting data exposure: the command below queries ipinfo.io, an external lookup service that is nothing to do with Hostworld, so that service will see the request coming from your server's IP address. If you would rather not do that, take the address from Virtualizor and skip to Step 3.

These commands install curl and jq:

• AlmaLinux 9: this installs curl and jq using DNF.

sudo dnf install -y curl jq

• Ubuntu 24.04: this updates package lists then installs curl and jq using APT.

sudo apt update && sudo apt install -y curl jq

Now query your current public IP and a summary of where it is registered. This helps validate where your traffic exits.

• Both OS: this fetches JSON from the external service and filters useful fields.

curl -s https://ipinfo.io/json | jq -r '.ip, .city, .region, .country, .org'

You should see the IP address, location and network. This is not a legal opinion about residency, but it is a practical check while you map data flows.

Step 3: Confirm whether your current setup triggers transfer rules

If your VPS is in the UK and no overseas organisation can access it, you generally avoid restricted transfer rules. If your VPS is in the US, or if any overseas team can access the data on your VPS, this is a restricted transfer under UK GDPR.

To get more context about the network holder, use whois. Install whois if you do not have it.

• AlmaLinux 9: the whois client is not in the base or AppStream repositories, so this first enables the EPEL repository, then installs whois from it.

sudo dnf install -y epel-release
sudo dnf install -y whois

• Ubuntu 24.04: this installs the whois client package.

sudo apt update && sudo apt install -y whois

Now run whois against your server's public IP, the one you took from Virtualizor or from Step 2. This queries the public registry and returns the registry and organisation that holds the IP space. Replace 203.0.113.10 with your own address.

• Both OS: this looks up the IP you give it.

whois 203.0.113.10

Use this information to validate the location you think you are using. Remember, even UK‑hosted systems can trigger restricted transfers if, for example, a support partner in another country has administrative access.

Step 4: If hosting in the US, choose and document your lawful transfer route

You have two main options for ongoing hosting in the US.

Option A: Rely on adequacy via the UK‑US Data Bridge

• Scope: only transfers to US organisations that are certified to the Data Privacy Framework and have opted into the UK Extension are covered.
• What to do: identify the US recipient organisation that will receive or access the data, verify its DPF certification and that it opted into the UK Extension, then record this in your documentation.
• Remember: the UK’s adequacy regulations are independent of the EU’s. Coverage under EU rules does not automatically cover the UK position.

Option B: Use the IDTA or the UK Addendum to the EU SCCs, and assess risk

• Pick your contract: either the standalone UK International Data Transfer Agreement, or the UK Addendum to the EU Standard Contractual Clauses. The old pre‑2021 EU SCCs are no longer valid for UK transfers.
• Complete your assessment: the ICO expects a risk assessment. UK law now calls this the data protection test, and ICO guidance still refers to TRA in places. For US transfers, you can rely on the UK government analysis published by the ICO to help complete it.
• Record the outcome: keep the signed clauses, your TRA or data protection test and your rationale.

Do not use exceptions for ongoing hosting

Article 49 exceptions, like explicit consent or necessity for a contract, are for specific, occasional, non‑repetitive transfers. They are not a fit for day‑to‑day hosting or backups. If you can put a safeguard in place, you should not rely on an exception.

Step 5: Put Article 28 contracts in place with your processors

If you host with a provider, that provider is a processor under UK GDPR. You need a controller–processor contract with the required Article 28 terms, and you should do proportionate due diligence. Processors must flow down obligations to any sub‑processors, for example a data‑centre operator or an out‑of‑hours support company based overseas.

• Check the contract names the subject matter, duration, nature, purpose, type of data and categories of data subjects.
• Ensure the processor only acts on your written instructions and has clear rules for sub‑processors.
• Check security obligations, assistance with data subject rights, breach notification and deletion or return of data on exit.

If you need our help understanding how your Hostworld service is structured, please open a support ticket.

Step 6: Update your privacy notice and your records

Transparency matters. If you host outside the UK, tell people in your privacy notice where their data is processed and under what safeguard. Update your Record of Processing Activities under Article 30 to reflect the location, recipients and safeguards. The ICO provides templates and expects you to keep the ROPA current.

Step 7: Control and log remote access from abroad

Limiting who can access your VPS from outside the UK reduces your exposure to unnecessary restricted transfers. The most direct control is to restrict SSH to known administrative IP addresses. Take great care here. If you block your own access you will lock yourself out. Work in a maintenance window and have out‑of‑band access ready through Virtualizor’s VNC console.

AlmaLinux 9: allow SSH only from your admin IPs with firewalld

This adds an allow rule for your admin IP and reloads the firewall so the rule takes effect. Replace 203.0.113.10 with your static admin IP. Add one allow rule per admin IP you need.

sudo firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='203.0.113.10/32' port port='22' protocol='tcp' accept"
sudo firewall-cmd --reload

This lists the rich rules that are currently loaded, so you can confirm your allow rule was accepted and is actually there.

sudo firewall-cmd --list-rich-rules

Now open a second SSH session from an admin IP and check it connects. Do not skip this. Only once you have a working session on the new rule should you remove the broad SSH allow. These commands remove the general SSH service allow and reload the firewall.

sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reload

Ubuntu 24.04: allow SSH only from your admin IPs with UFW

This allows SSH from your admin IP, then denies general SSH. If UFW is not enabled, enable it after you add your allow rules. Replace 203.0.113.10 with your static admin IP. Add one allow per admin IP you need.

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw deny 22/tcp
sudo ufw status verbose
# If UFW is disabled, enable it only once you have added all required allow rules:
# sudo ufw enable

Keep a record of who can access what, including any overseas administrators. That record feeds your transfer assessment and your ROPA.

Step 8: If you are changing region, plan the migration to avoid downtime

If you are moving from the US to the UK to reduce paperwork, or the other way for business reasons, plan the sequence carefully.

1. Order and provision the target VPS. Order the new VPS in the required region from our site. VPS management itself happens in Virtualizor through our client area. Do not delete the old VPS yet.
2. Copy data and test. Copy your data across and test the new server privately before any DNS change. Use your backup tool, or the rsync and database steps set out below. Do that copy once, in this step.
3. Cut over DNS in a controlled window. Update DNS to point to the new IP. For domains hosted elsewhere, change A and AAAA records. For sites on our cPanel hosting, use our nameservers: ns1.serverworld.uk, ns2.serverworld.uk, ns3.serverworld.uk and ns4.serverworld.uk. Wait for TTLs to expire.
4. Decommission the old VPS when logs confirm traffic has moved. Keep a final backup in case you need to roll back.

The rest of this section is the detail for step 2 above, for a command‑line copy of web content. Stop your web server briefly at cutover to avoid a moving target, then rsync the content. Replace NEW_SERVER_IP with the target VPS address.

Stop and start web services safely

• AlmaLinux 9: these commands stop and start Apache httpd. Use nginx if that is your stack.

sudo systemctl stop httpd
# After rsync and DNS cutover:
sudo systemctl start httpd

• Ubuntu 24.04: these commands stop and start Apache2. Use nginx if that is your stack.

sudo systemctl stop apache2
# After rsync and DNS cutover:
sudo systemctl start apache2

Copy files with rsync

rsync connects to the target over SSH, so the source server needs to be able to log in to the target first. If you have not set up key‑based SSH between the two servers, the command will stop at a password prompt, or fail outright if the target refuses password logins for that user. Set up a key from the source to the target before you run this, for example with ssh-copy-id, or use an account that can log in and adjust the destination path to suit.

This rsync command preserves permissions, hard links, ACLs and extended attributes, shows progress and copies your web root. Adjust paths to your setup. Run it from the source VPS.

sudo rsync -aHAX --info=progress2 /var/www/ root@NEW_SERVER_IP:/var/www/

For databases, use logical dumps and restores in a maintenance window. For example, with MariaDB or MySQL you would use mysqldump on the source and import on the target. Test restores before you change DNS.

If any part of this plan worries you, please open a support ticket. We will help you sequence the move so you do not lose data.

Step 9: Check sector‑specific rules if you handle regulated data

• NHS and social care: hosting in the UK, EEA or an adequate country is the baseline. Off‑shoring beyond this typically needs senior approval and extra controls.
• Financial services: ensure your outsourcing and operational resilience approach covers data location, exit plans and third‑party risk. Be ready to evidence it.

Step 10: Keep proof and review on a schedule

Keep your signed transfer mechanism, your TRA or data protection test, your processor contracts and your updated ROPA together. When the ICO updates guidance, review your position. Guidance was refreshed on 15 January 2026 and on 30 July 2026, and it clarifies the UK’s position on adequacy and terminology under the Data (Use and Access) Act 2025.

What next

• If you want to avoid transfer paperwork, move to our UK location. See our London VPS and plan your migration using the steps above.
• For command‑line help with common VPS tasks, browse our VPS guides.
• If you need tailored advice on how to apply this to your Hostworld service, please open a support ticket.