Personal data on your website: what GDPR and Russia's 152-FZ require

A website that collects a name, phone number or email processes personal data and must comply with the law: GDPR for users in the European Union, and Russia's Federal Law 152-FZ if you serve Russian users. In practice that means getting valid consent, storing data where the law requires, protecting it and being able to respond to user requests.

Below is how the two regimes differ and what to do on your website. This is a business overview, not legal advice: have a lawyer review your documents.

Which data on a website counts as personal?

Personal data is any information that directly or indirectly relates to an identifiable person. On a website that means not only the fields of a contact form but also much of what is collected automatically.

What usually falls under the law:

• names, phone numbers, emails and addresses from contact, sign-up and checkout forms;
• account data, order history and payment information;
• files users upload — CVs, documents, photos;
• cookies and device identifiers that can single out a person;
• call recordings and support chat transcripts.

If your site has even one form with contact details, your company is a data controller with all the obligations that come with it.

What does GDPR require from a website?

GDPR requires a lawful basis for every processing purpose, transparency about what you do with data, respect for user rights and appropriate security. It applies to a company in any country if it offers goods or services to people in the EU or monitors their behaviour.

What affects a typical website most:

• lawful bases — besides consent, there is contract performance, legitimate interest and others; marketing emails and analytics usually still need consent;
• cookies — non-essential cookies, such as analytics and advertising, may only be set after explicit consent;
• user rights — access, correction, deletion and export in a machine-readable format;
• breaches — notifying the supervisory authority within 72 hours;
• fines — up to €20 million or 4% of worldwide annual turnover, whichever is higher.

How does Russia's 152-FZ differ from GDPR?

Russia's 152-FZ relies more heavily on consent and adds a data localisation rule. Several changes in 2025 tightened it noticeably, so companies serving Russian users should review their setup.

Effective date	What changed	What it means for a website
May 30, 2025	New fines for breaches, turnover-based fines for repeat leaks	A data leak is now a financial risk for businesses of any size
July 1, 2025	Explicit ban on initial collection of Russian citizens' data using foreign databases	Forms and CRMs must write data to databases in Russia first
September 1, 2025	Consent must be a separate document	Consent cannot be buried in terms, contracts or policies

The fines come from Federal Law No. 420-FZ; for a repeat leak the fine is a percentage of revenue capped at 500 million roubles (see the ConsultantPlus summary, in Russian). The separate-consent rule is covered by GARANT.RU. Consents obtained before September 1, 2025 remain valid.

Photo: Unsplash

What should you do on your website to comply?

To comply, a website needs proper documents, a separate consent at each form, the right storage location and technical protection. Most of this is one-off work at launch that then has to be kept up to date.

Documents and forms

1. Publish a privacy policy: which data, why, where and for how long it is stored, and who receives it.
2. A separate, specific consent at each form, with no pre-ticked boxes.
3. A separate consent for marketing emails, not combined with consent to process the enquiry.
4. A cookie banner that does not load analytics before consent — mandatory for EU audiences.
5. Under 152-FZ, a notification to Roskomnadzor, the Russian regulator, about data processing.

The technical side

• Russian users' data lands first in a database hosted in Russia; transfers to foreign services happen only afterwards and under the cross-border transfer rules.
• Encryption in transit (HTTPS) and at rest for sensitive data.
• Access limited to staff who need it, with an audit log.
• Retention periods: enquiries and logs are not kept forever, and deletion is automated.
• A breach procedure: who is responsible and whom to notify, and when.

A schema where each enquiry records exactly what the user consented to and when:

CREATE TABLE lead_consents (
    id          bigserial PRIMARY KEY,
    lead_id     bigint      NOT NULL REFERENCES leads(id),
    purpose     text        NOT NULL,  -- 'processing', 'marketing'
    document    text        NOT NULL,  -- version of the consent text
    granted_at  timestamptz NOT NULL,
    ip          inet
);

Storing the document version matters: in an audit you need to show not just that consent was given but the exact text the user saw.

What should you check with vendors and third-party services?

Check where each vendor and service physically stores data, who can access it and how the transfer is documented. Your contact form, CRM, email service and analytics all process your users' personal data too.

Questions for every service and vendor:

• which country the servers are in and whether you can choose a storage region;
• whether there is a data processing agreement (DPA);
• which of the vendor's staff can access production data;
• how backups work and where they are stored.

Technical safeguards overlap with general application security, which we covered in our piece on the OWASP Top 10.

In short

• Any form with contact details makes your company a data controller.
• GDPR applies if you serve EU users: cookie consent, user rights and 72-hour breach notification.
• In Russia since 2025: turnover-based fines for repeat leaks, separate consent and initial collection only in Russian databases.
• Store the consent version with each enquiry and automate deletion by retention period.
• Check where your CRM, email and analytics services store data, and sign agreements with them.