Hosting a website for Russian users: data localisation and provider requirements

In short. If your website collects personal data from people in Russia, Russian law requires that the primary database — where that data is first recorded and stored — sits on servers inside Russia. A contact form, a sign-up or a customer account is enough to trigger it. A brochure site with no forms and no tracking is out of scope, but that is rarer than owners assume.

Disclaimer. This is an engineering guide, not legal advice. Data protection rules and hosting regulation change, and enforcement practice is clarified by the regulator over time. Verify current wording of the law at pravo.gov.ru and regulator materials at rkn.gov.ru, and take legal counsel on anything ambiguous.

Why a Russian audience changes where your data must live

Most data protection regimes attach obligations to the people whose data you process, not to the country your company is registered in. GDPR does this through its territorial scope: offering goods or services to people in the EU pulls you in even if you have no EU entity. Russian law works on a similar logic, but adds a requirement GDPR does not have — a data residency rule.

The practical difference matters. Under GDPR you may transfer personal data outside the EEA provided you have a valid transfer mechanism: an adequacy decision, standard contractual clauses, binding corporate rules, plus a transfer impact assessment where relevant. There is no requirement that a copy stays in Europe. The Russian rule is stronger in one specific respect: recording, systematisation, accumulation, storage, updating and retrieval of personal data belonging to Russian citizens must be performed using databases located in Russia. Transfers abroad are then treated separately and are not banned as such — but the first write has to land locally.

So the mental model is: GDPR asks "under what conditions may data leave?"; the Russian rule asks "where did the data land first?" Both questions can apply to the same website at the same time, and answering one does not answer the other.

Who counts as a data operator — and why almost every site is one

The Russian term is "operator of personal data", roughly equivalent to a controller under GDPR: the party that decides why and how personal data is processed. That is the site owner or the business behind the site — not the developer and not the hosting provider. Providers and agencies are typically processors acting on instructions fixed in a contract.

You become an operator through very ordinary features:

• a contact or callback form capturing a name and a phone number;
• account registration, log-in, social sign-in;
• checkout with a delivery address;
• a newsletter subscription;
• a support chat where users identify themselves;
• file uploads such as documents, photos or CVs;
• reviews and comments tied to an account;
• analytics and advertising pixels that collect device identifiers and behaviour.

Special categories — health, biometrics used for identification, and similar — carry a stricter regime. If your product handles those for Russian users, moving a server is the least of the work; treat it as a dedicated compliance project rather than a hosting decision.

Three duties people keep merging into one

1. Localisation of the primary database — data on Russian citizens is written and stored in databases inside Russia.
2. Notification of the regulator that you process personal data — a standalone obligation that migrating a server does not satisfy.
3. Organisational and technical measures — a published processing policy, valid consents, access control, retention limits, a named person responsible for processing, access logging.

A common state of affairs: the server has been moved, but no notification was filed and the privacy policy describes an architecture that no longer exists. Those are three separate findings in any review, not one.

What data localisation actually requires

Read the statutory verbs as one engineering statement: the primary store must be in Russia. That is where a field value must arrive when the user presses submit. Everything downstream is a transfer, governed by its own rules.

This gives you a test you can apply to an architecture diagram in seconds: where does the first POST from the browser go? If the browser submits directly to a foreign CRM domain, a form-builder SaaS or an email platform, the first write happened abroad — and a web server in Moscow does not fix it, because the data never passed through it.

The first-hop rule. Personal data must land in your database in Russia first, and only then flow anywhere else within declared purposes and consents. "Browser → foreign service → maybe our system later" breaks the requirement at the very first step.

The corollary is equally important: foreign services are not automatically forbidden. You can keep an external email platform, an analytics vendor or a helpdesk abroad — that is a cross-border transfer with its own conditions on legal basis, consent form, contractual commitments from the recipient, and a clear inventory of which fields actually leave. Conflating "not allowed" with "allowed under conditions" is the single most expensive mistake in these projects.

The hosting provider registry and what it means for you

Russia maintains a state registry of hosting providers, administered by Roskomnadzor. Organisations that supply computing capacity for publishing information online are expected to be listed in order to operate legally in the market. For a site owner this is not paperwork trivia — it is a continuity question. A platform outside the regulated perimeter is a platform whose service may stop for reasons you cannot influence and cannot appeal.

What follows practically:

• Verify the provider's status yourself. The list is published by the regulator; it is not something to take on a sales manager's word.
• Look at the legal entity in the contract, not the brand on the website. Frequently one company sells the service while capacity is rented from another; the registry names a specific organisation.
• Distinguish a reseller from the infrastructure owner. Resellers can be perfectly honest, but the chain of responsibility during an incident is longer and you have fewer levers.
• Do not confuse the registry with certification. Being listed as a hosting provider and operating a segment certified for a given protection level are different things; ask about the second separately if your system needs it.

Watch for the inverse trap too: a platform marketed as "Russian hosting" that bills through a foreign entity and racks hardware abroad while announcing Russian IP ranges. For marketing that is a server in Russia; for regulation it is not. This is verifiable from the command line, and the section below shows how.

Where foreign-owned sites usually break the rule

Forms posting straight into a SaaS

Form builders, chat widgets and CRM widgets install as a single script tag and ship field values to their own domain, bypassing your backend entirely. The fix is to move the receiver: the form posts to your own endpoint, that endpoint writes a row into the database in Russia, and a background job syncs the necessary fields outward. You also stop depending on a third-party widget being up — if it is down, the lead is still captured.

The email platform as the system of record

"Leave your email" flows often end up with the subscriber list living only inside a foreign sending platform. That makes the primary store foreign. The correct shape is a subscribers table of your own inside Russia as the source of truth, with the external platform as a delivery channel synced on a schedule and stripped of fields it does not need.

Analytics and advertising pixels

The question is not whether a tag is installed, but what it carries. A visitor identifier and event names are one thing; an email address, a phone number or an order reference leaking through event parameters is another — and hand-written conversion goals do this constantly. Inspect the network requests on your thank-you page: that is where contact fields most often end up inside a URL.

Logging and error tracking

Frontend error trackers happily accept everything: URLs with tokens in query strings, request bodies, user emails attached to error context. That is a transfer too. At minimum, scrub sensitive fields on the sending side and know which country the log store physically sits in.

Backups

A database backup is a copy of the same personal data. If dumps go to a foreign object storage bucket, the residency question returns in a less visible form. Ask your provider where backups are kept, and audit your own backup jobs — not just the production server.

CDNs and reverse proxies in front of your site

Putting a foreign CDN or reverse proxy in front of the origin creates three distinct problems. TLS terminates on a third-party node outside the country, so the proxy operator can technically see request contents including form submissions. The origin address becomes hidden, so "where is the server" stops being obvious even to you — and reconstructing that during an inspection is too late. And availability becomes dependent on someone else's routing, which for Russian users has been unreliable in practice.

There is also a signalling effect: proxies are frequently used to hide exactly what someone does not want seen, so the configuration itself draws attention. The trade-offs of that specific setup are covered in the piece on using Cloudflare in Russia, including what to use instead of an external caching layer.

Prove residency at the origin. If a proxy sits in front of your site, "the server is in Russia" must be demonstrated by the origin address, not by whatever the browser resolves. Keep a current map: domain → CDN/proxy → origin → database → backups, with the country marked at every hop.

Logs, IP addresses and cookies

Whether an IP address is personal data is answered by context, not in the abstract. GDPR case law treats IP addresses as personal data where the holder can plausibly link them to an individual, and the Russian approach lands in a similar place: an IP stored next to a user id, an order number or a session identifier lets you tie actions to a person. Cookie identifiers and device fingerprints behave the same way.

The engineering consequence: web server logs are a dataset with a retention period and access rules, not technical debris. Minimum hygiene looks like this:

# nginx: truncate the client address in the access log
# IPv4 -> zero the last octet, IPv6 -> keep the leading prefix only
map $remote_addr $ip_anon {
    ~^(?P<pfx4>\d+\.\d+\.\d+)\.\d+$   $pfx4.0;
    ~^(?P<pfx6>[^:]+:[^:]+):          $pfx6::;
    default                            0.0.0.0;
}

log_format privacy '$ip_anon - [$time_local] "$request" '
                   '$status $body_bytes_sent "$http_referer"';

access_log /var/log/nginx/access.log privacy;

# retention: 14 days instead of "forever"
# /etc/logrotate.d/nginx-privacy
/var/log/nginx/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1 $(cat /var/run/nginx.pid)
    endscript
}

If you genuinely need full addresses for fraud detection or incident response, that is a legitimate purpose — but it has to be declared and time-boxed. "Keep everything forever in case it is useful" is not a purpose.

When you do not need hosting in Russia

The obligation does not arise if you do not process personal data of Russian citizens. In practice that means a static brochure site: service descriptions, company contacts, no forms, no registration, no chat, no comments, no cart, and no third-party scripts that collect visitor identifiers. It happens — but sooner or later a lead form or an analytics tag is added, and the status changes without anyone making a decision about it.

There is a second, non-legal reason to host locally anyway: latency and reachability for Russian users. That is a network-metrics argument rather than a compliance one, and it is covered in the guide on how to choose a hosting provider.

Scenarios and the minimum you must do

Site scenario	Personal data of Russian users collected?	Localisation obligation?	Minimum action
Brochure site: no forms, no analytics, no comments	No	No	Record this conclusion and re-check it every time a block is added to the site
Landing page with a lead or callback form	Yes — name, phone, email	Yes	Receive the form on your own backend in Russia, store it there, publish a policy and consent, file the regulator notification
Online store with checkout	Yes — contacts, delivery address, order history	Yes	Everything above, plus control over transfers to carriers and payment providers and defined order retention
SaaS with user accounts	Yes — accounts, user content, activity logs	Yes	Primary database and backups in Russia, staff access control, access logging, processor contracts with vendors
Foreign site targeting a Russian audience (Russian language, rouble prices, delivery to Russia)	Yes	Yes — targeting the audience is the decisive signal	Carve out a Russian processing segment: database for Russian users in Russia, everything else handled as cross-border transfer
Brochure site with third-party analytics and pixels	Indirectly — identifiers and behaviour	Grey zone — assess what is actually collected	Inventory every external script, remove what is not needed, add a consent banner and a policy

What to check with a provider before you migrate

This is a conversation with support and legal, not with sales. A good provider answers in writing and quickly; evasive answers are themselves a result.

• Legal entity and contract. Who exactly is the counterparty, is it a Russian legal entity, is there a data processing instruction listing the actions performed and the protective measures.
• Presence in the hosting provider registry. Confirmed against the regulator's data, not against a badge on a marketing page.
• Data centre locations. Named facilities and cities rather than "Tier III data centres". Whether capacity is owned or rented, and from whom.
• Certifications and protection levels. Whether you need them depends on your data class; ask specifically which certified segment exists and for what system class.
• Backup location. Country, retention, encryption, who has access, how restores are tested.
• Handling of official requests. How the provider notifies you about requests concerning your account, within what timeframe, who signs the responses.
• SLA. Not only an availability percentage, but the definition of downtime, how it is measured and by whom.
• Migration and exit. Ability to export data and images, deletion timelines after termination, lock-in in the control panel.
• Engineering reality. Uplinks, inbound DDoS protection, IPMI/console access, and how fast tickets are answered at three in the morning.

Major Russian platforms — Selectel among them — publish their data centre list and corporate details openly, which is the first thing to read before comparing price plans. The choice between shared hosting, a VPS and a dedicated server is a separate decision, covered in the comparison of shared hosting, VPS and dedicated servers; a broader survey of platforms is in the hosting provider overview.

How to check your current setup

Establish the facts before changing anything. Half of these migrations start from a wrong assumption about where the server actually is.

With enterno.io tools

• IP lookup — where the server is physically located, which autonomous system owns the address, which provider announces it. Check both the public address and the origin if a proxy is in front.
• WHOIS — registrar and domain ownership, renewal dates, name servers. A foreign registrar with Russian hosting is not a violation, but it is a failure point worth knowing about.
• Blocking check — whether the domain or IP appears in access restriction registries. This matters most on shared hosting, where you share an address with neighbours.
• Personal data readiness check — whether the pages carry a processing policy, consent on forms, a cookie banner and working footer links.
• Cookie flags and the banner — whether Secure, HttpOnly and SameSite are set, and whether tracking cookies are written before consent.

From the command line

# 1. What the domain resolves to
dig +short example.com A
dig +short www.example.com A

# 2. Who owns that address: network, country, organisation
whois 203.0.113.10 | grep -Ei 'netname|country|org-name|descr|origin'

# 3. Path to the server — which networks the traffic crosses
traceroute -n -w 2 -q 1 example.com

# 4. Is there an external proxy or CDN in front of the origin
curl -sSI https://example.com | grep -Ei 'server:|via:|x-cache|x-served-by|cf-ray'

Then inventory where the site sends data. Do it from the source, not from memory:

# every external host the frontend talks to
grep -rEoh 'https?://[A-Za-z0-9._-]+' . \
  --include='*.html' --include='*.js' --include='*.php' --include='*.tpl' \
  | sed -E 's#https?://##' | sort -u

# where forms post and which outbound calls exist
grep -rEn 'action="https?://|fetch\(|XMLHttpRequest|axios\.(get|post)' . \
  --include='*.html' --include='*.js' --include='*.php'

The output of the first command is your real recipient list. Compare it against your privacy policy: policies typically name three vendors while the code calls eleven.

Bringing a site into compliance, in order

Sequence matters. Documents written before the inventory produce a policy that describes a system nobody built.

1. Data inventory. Which fields are collected, on which pages, where they land, how long they are kept, who can read them.
2. Recipient inventory. A complete list of external services taken from the codebase.
3. Primary database in Russia. All forms land on your own backend; external integrations become post-write synchronisation.
4. Backups in Russia. Verify the physical location of the backup store and that dumps are encrypted.
5. Regulator notification. A separate obligation that migrating a server does not discharge.
6. Processing policy. Published, reachable from every page, describing real purposes, real fields, real recipients and real retention.
7. Consents. A separate, non-pre-ticked checkbox with a clear purpose statement; the consent event is logged with a timestamp and the text version.
8. Cookie banner. Tracking scripts do not load before consent, and the choice is stored and respected.
9. Access control. Which employees and contractors can see personal data, whether access is logged, whether accounts are revoked on departure.
10. Retention. Defined per category, with a deletion mechanism that actually runs.
11. Named responsible person. Formally appointed and aware of the role.
12. Monitoring. Continuous checks so regressions surface — for example when a developer restores a third-party widget that was removed.

The public-facing half of that list can be checked automatically: the personal data compliance check finds a missing policy, forms without consent and tracking that fires before the banner. Deeper walkthroughs are in the guides on checking 152-FZ compliance and on writing a privacy policy for a website.

Why grey solutions are a bad bet

• They are trivially verifiable. Where a browser sends form data is visible in developer tools in under a minute. This is not hidden information.
• Documents that contradict the architecture make things worse. A policy describing a system you do not operate records that you knew the requirement existed.
• Liability is real. Administrative liability applies to personal data violations, and the sanctions have been revised upward over time — check the current version of the code rather than figures quoted in older articles.
• They are operationally fragile. Proxy-based workarounds break the first time the intermediary changes something, and you fix them while the site is already down.
• Address-level blocking hurts everyone on the platform. If a resource falls under access restrictions, recovery takes time; what to do in that situation is covered in the guide for owners of blocked sites.

Do not economise on separating environments. If the business is international, designing the Russian segment as its own contour with its own database and its own backups is cheaper up front than carving Russian users out of a shared table later, under deadline pressure.

After the migration: what to monitor

• availability and response times measured from inside Russia — degradation after a migration is common;
• TLS certificate validity and chain correctness on the new server;
• DNS resolution: whether stale A records persist on some resolvers after the IP change;
• new outbound requests appearing on pages — a signal that a third-party widget came back;
• presence of the domain or IP in access restriction registries.

Turning that into a continuous process with alerting is covered in the guide to website monitoring and Russian compliance. For one-off checks use monitoring, the DNS checker and HTTP header analysis.

Frequently asked questions

Do I need Russian hosting if my site only has a contact form?

Yes, if the form collects a name, phone number, email or anything else that identifies a person. Volume is irrelevant: one form makes you an operator exactly as a hundred-thousand-user product does. Scale changes the depth of security measures, not the existence of the obligation.

Can I keep using a foreign analytics vendor and email platform?

They are not automatically prohibited, but they are cross-border transfers: you need a legal basis, appropriate consent, an inventory of the fields that leave, and contractual commitments from the recipient. The condition that decides it is that the first write must occur in a database inside Russia, with the external vendor receiving data afterwards.

How does this differ from GDPR in practice?

GDPR regulates the conditions of transfer but does not demand that a copy stay in the EEA. The Russian rule adds a residency requirement for the primary database while leaving transfers possible under conditions. If you already run a GDPR programme, most of the documentation and access-control work carries over — the new work is architectural: where the first write lands, and where backups live.

Is an IP address personal data?

It depends on context. On its own, in a general access log, it is a grey area; stored next to a user id, an order number or a session it lets you link actions to a person, and should be treated as personal data: bounded retention, restricted access, truncation where feasible.

Does a VPS in Russia help if the database is in a foreign cloud?

No. The requirement covers the database, not the web server. If the application runs on a Russian VPS while the managed database service sits abroad, the first write happens outside the country. What must move is the store itself, including replicas and backups.

We are a foreign company with a Russian-language site. Where do we start?

Assess the targeting signals: language, currency, delivery to Russia, advertising on Russian platforms, Russian-speaking support. If the signals are there, the pragmatic route is to carve out a Russian processing contour with its own database, rather than to argue that the audience arrived by accident.

Checklist

• Established whether the site processes personal data of Russian users, with the field list written down.
• Primary database located in Russia; the physical location of the server and of the origin behind any proxy verified.
• Forms post to your own endpoint rather than directly into external services.
• Complete recipient list compiled from the codebase, not from memory.
• Backups stored in Russia, encrypted, with restores tested.
• Provider: Russian legal entity, registry status verified, data centre locations known.
• Written answers obtained on SLA, handling of official requests and exit conditions.
• Regulator notification filed.
• Processing policy published and matching the real architecture and real recipients.
• Consent captured with a separate, non-pre-ticked checkbox and logged with timestamp and text version.
• Cookie banner blocks tracking before consent; Secure, HttpOnly and SameSite flags set.
• Retention periods defined, deletion mechanism working, logs rotated.
• A responsible person for processing formally appointed.
• Monitoring in place for availability, TLS, DNS and new outbound requests on pages.