RGBvision RGBvision
Back
152-fzcrm

Consent Log Under 152-FZ: Proving What a Customer Agreed To

Under Russia's personal data law, the company must prove it obtained consent. How to store document versions and consents so you have evidence years later.

Published: 2026-08-13

A checkbox in a form shows that a customer agreed, but not to what or when. Under 152-FZ, Russia's personal data law, the burden of proving consent lies with the company, and a year from now the question will be specific: which text the person saw, on what day, through which channel, and whether they withdrew consent later. Two things answer it: versioned documents and a log that only accepts new entries.

What the law says

Consent is governed by Article 9 of 152-FZ. Four rules matter for a consent log.

  • Form. Consent may be given in any form that allows the fact of obtaining it to be confirmed, unless a federal law requires otherwise (Part 1, Article 9). It must be specific, substantive, informed, conscious and unambiguous, and since September 1, 2025 it must be drawn up separately from other documents. We covered what that changed for forms and bots in our article on separate consent.
  • Representatives. If consent is given by the data subject's representative, the operator checks the representative's authority (Part 1, Article 9).
  • Burden of proof. The operator must prove that consent was obtained. If data is processed without consent on another legal basis — Clauses 2–11 of Part 1 of Article 6, Part 2 of Article 10 or Part 2 of Article 11 — the operator must prove that basis exists (Part 3, Article 9).
  • Withdrawal. The data subject may withdraw consent (Part 2, Article 9). After that, the operator has no more than 30 days from the date the withdrawal is received to stop processing and, if the data is no longer needed for the purposes of processing, destroy it; the exceptions are listed in the same rule (Part 5, Article 21).

Written form is mandatory in cases set by federal law (Part 4, Article 9) — for example, for health data and other special categories (Clause 1, Part 2, Article 10) and for biometrics (Part 1, Article 11). Consent in the form of an electronic document signed with an electronic signature in accordance with federal law is equivalent to a hand-signed paper one (also Part 4). Which signature to use in your case is a question for your lawyer.

Part 4 of Article 9 lists nine items a written consent must contain:

  1. The data subject's full name, address and identity document details.
  2. The same for the representative, plus details of the document confirming their authority, if a representative gives consent.
  3. The operator's name and address.
  4. The purpose of processing.
  5. The list of personal data.
  6. The name and address of anyone processing the data on the operator's behalf, if applicable.
  7. The list of actions with the data and a general description of processing methods.
  8. How long the consent is valid and how to withdraw it, unless federal law provides otherwise.
  9. The data subject's signature.

The law does not mention a "consent log" or say how one should work. A log is a practical way to meet Part 3 of Article 9: collect the evidence up front instead of searching for it when asked.

Why a "consent: yes" field in the CRM is not enough

The most common setup is a flag on the customer record. It only answers whether consent exists right now. It cannot answer the questions that come up in an inspection or a dispute:

QuestionWhere the log answers it
Which text the person agreed toA link to the document version, not the document
WhenEntry date and time set by the system
Through which channelWebsite, customer account, app, paper
Who gave consent — the person or a representativeA flag and a link to the representative's details
Whether consent is valid nowThe latest entry for this customer and consent type
When the withdrawal arrivedA separate withdrawal entry with date and channel

A flag is also easy to overwrite. A manager unticks it and ticks it again, and the history is gone. As evidence, that is not enough: the record has a date, but nothing backs it up.

Document versions

Website texts change: the lawyer refines the purpose, a new processor is added, the policy is rewritten. If the old version is not kept, a year later you cannot show what a customer who signed up before the change agreed to.

What works in practice:

  • Every document is versioned. The offer, the processing policy and each consent are separate documents with their own history.
  • A published version is never edited. Any change, even a typo fix, becomes a new version with an effective date. The old one stays available at a permanent address.
  • The full text is stored. Not a link to a web page, but the version's text in the database: pages change or disappear.
  • Entries point to a version. The log stores "processing consent, version 4", not "processing consent".

When a new consent version is released, the system should show who agreed to the older ones. Whether to ask anyone for consent again is a decision for your lawyer, but without versions you cannot even ask the question.

An append-only log

The key property of the log is that entries are never changed after the fact. Every event is a new row: consent given, consent withdrawn, consent given to a new version. Withdrawal does not delete the consent entry; it adds a withdrawal entry. The customer's current status is derived from the latest entry.

How to build it:

  • the application can only insert rows into the log, not update or delete them — this is enforced at the database level;
  • the server sets the date and time, not the browser or a staff member;
  • mistakes are fixed with a correcting entry that records the reason and the author, and the original entry stays;
  • administrator actions on documents and the log are logged too.

The log itself contains personal data, so only a small group should have access to it. Customer databases remain a traded commodity: according to SBA, in the first half of 2026 the number of posts offering databases on underground forums and Telegram channels grew from 23,800 to 38,100. The fewer unnecessary fields the log holds, the less harm a leak does.

Consent as a condition of access

A log is only useful if other systems rely on it. That is how we built a consent service for a network of kids' centers, which processes data of children and parents. Documents are versioned, the log allows no retroactive changes, and the website and customer account record consents through an API. The service is integrated with the CRM and the access control system: a customer's entry depends on having the required consents.

This removes a typical problem where the consent flag exists in one system and is missing in another. There is one source, and other systems ask it for the status. Which consents are part of the access rule is decided by the company and its lawyer; the system only enforces that rule.

A log needs an unambiguous customer for every entry. If each branch keeps its own database, the same person ends up in the log several times. We solved the single customer base problem for service chains in our own product, Aphorio: online booking, the customer base and branches run in one system. The consent log remains a separate task, and its design does not depend on which business system you use.

What this means for business

A consent log matters most where there are many data collection points and sensitive data: children's services, clinics, fitness, education. Consents are collected on the website, in the app, at the front desk and on paper, and questions about them may come years later.

If your consents today are a CRM flag and website text with no history, that is not a disaster, but evidence will have to be pieced together from logs and correspondence. It is cheaper to build the log into your next CRM update than to reconstruct history after a request.

Self-check list

  1. Each type of processing has a defined legal basis — consent or another basis under Article 6 — and it is documented.
  2. The offer, the policy and each consent have versions with an effective date and the full text.
  3. A published version cannot be edited, only replaced by a new one.
  4. Every log entry points to a specific document version.
  5. Log entries cannot be changed or deleted; corrections are made with new entries only.
  6. A withdrawal is a separate entry with the date it was received, which starts the clock under Part 5 of Article 21.
  7. If a representative gave consent, the entry shows who they are and on what authority they act.
  8. The CRM, customer account and other systems read consent status from one source rather than keeping their own copies.

These are system design recommendations, not legal advice: agree consent texts and legal bases with your lawyer.

Sources