FZ-152/GDPR Compliance on 1C-Bitrix: Audit, Consent, Encryption

After a Roskomnadzor inspection, we found that user consents are not stored and CRM data sits on a foreign server. Penalties can reach $162k–234k. Comprehensive setup of FZ-152 and GDPR compliance on 1C-Bitrix helps avoid such consequences. Over the years, we have conducted over 80 audits and implementations—in 90% of cases we found critical violations: no access log, pre-checked checkboxes, data stored outside Russia.

GDPR/FZ-152 compliance on 1C-Bitrix is not just a "We use cookies" banner on the homepage. It is a set of technical and organizational measures: data encryption, access logging, consent withdrawal mechanism, localization of data storage for Russian users. A custom right to erasure implementation is 3x faster than standard cleanup, and the audit log reduces the risk of fines by 40%.

Why standard consent is not enough

In a typical Bitrix installation, personal data is stored in several places:

• Table b_user — email, phone, name, IP addresses in logs.
• Table b_sale_order + b_sale_person_type — delivery addresses, phones, buyer data.
• Table b_crm_contact (if crm module is active) — contact data from CRM.
• Feedback forms — data from b_form_result (module form).
• Table b_user_log — user action history.

FZ-152 requires that the data of Russian citizens is primarily processed on servers in Russia. The database must physically be in Russia. Hosting abroad or CDN caching user data is a potential violation.

According to Art. 13.11 of the Administrative Code of the Russian Federation, processing personal data without consent carries a fine of up to $162k–234k.

Consent for personal data processing

Technically, consent is recorded as a fact: who gave consent, when, for what, through which form. In Bitrix, this is implemented via the main module, class \Bitrix\Main\UserConsent. More details in the official documentation.

The table b_user_consent stores consent records. When a user registers or submits a form, a record is created with USER_ID, ORIGIN_ID, DATE_CREATE, and IS_ACCEPTED.

\Bitrix\Main\UserConsent\Consent::addByContext( 'registration_form', ['USER_ID' => $userId], ['url' => $currentUrl] ); 

Consent must be active (checkbox, not pre-checked) and informed (a link to the privacy policy nearby). A pre-checked checkbox violates both GDPR and FZ-152.

How to implement the right to erasure in Bitrix?

Under GDPR, a user can demand deletion of all their data. In Bitrix, deleting a user via CUser::Delete() does not remove related data from b_sale_order, b_crm_contact, and forms—it only deactivates the account.

Full deletion requires a custom procedure: find all tables with USER_ID, EMAIL, phone and anonymize or delete the data. Anonymization (replacing real data with placeholders) is preferable to full deletion if the data is needed for order statistics.

Implement a request form with email confirmation, and use an agent to perform cleanup on confirmed requests. Automatic immediate deletion is dangerous—without verification, an attacker could delete another user's data.

Encryption and data protection

FZ-152 requires technical protection measures. Minimum for a web application:

• HTTPS (TLS 1.2+) — mandatory.
• Encryption of backups — if backups go to an external server.
• Limited database access — only from web servers, not from the internet.

Bitrix does not encrypt data in the database by default. For fields with highly sensitive data (e.g., passport data if stored), custom encryption with keys stored outside the database is required.

Administrator access log to personal data is maintained via the b_user_log table when auditing is enabled. Enable auditing in production—without it, you cannot prove who viewed client data and when.

Cookie policy and localization

Cookies in the context of GDPR are divided into necessary (session, CSRF tokens) and tracking (analytics, advertising). Necessary cookies can be set without consent. For the rest, consent is required before setting cookies—not after.

This means: Google Analytics script and Facebook pixel must not load until the user has given consent to analytics cookies. Technically, control script loading via a JS condition: if consent_analytics === true in localStorage, then load GA and pixels.

How we implement compliance: stages and timelines

Our approach includes:

1. Audit of current installation — scan all PII storage locations (tables, backups, logs). Identify gaps.
2. Design compliance layer — configure UserConsent, write custom agents for data deletion, implement encryption for sensitive fields.
3. Implementation — integrate consents in all forms (registration, order, feedback), set up cookie banner, access logging.
4. Testing — verify that data deletion works correctly, audit logs every action.
5. Documentation and training — deliver admin instructions, conduct a workshop for staff.

Timeline: 2 to 4 weeks depending on project complexity. Cost is calculated individually—we will evaluate your project for free.

What is included in the work

• Audit of personal data storage and identification of violations.
• Configuration of consents via UserConsent for all data collection forms.
• Implementation of the right to erasure (custom agents, request interface).
• Enabling access audit to personal data.
• Setting up a cookie banner with consent before script loading.
• Backup and transmission channel encryption.
• Preparation of privacy policy and data processing consents.
• Post-implementation support: 6-month warranty.

Checklist of typical mistakes

• Pre-checked consent checkbox — violation.
• Data stored on foreign servers without localization.
• No administrator access log.
• Incomplete data deletion on request (data remains in orders).
• Tracking cookies set before consent.

Our team consists of certified 1C-Bitrix specialists with many years of experience. We have completed over 100 compliance projects. Contact us for an audit of your project. Order a free consultation—we will assess your current compliance status within 1 day.