compliancerussiadata-protectioncomplianceroskomnadzorlocalizationfederal-law-152-fz

Federal Law 152-FZ compliance: what the 2025 amendments broke and what assessments find

Geert WarmenbolGeert WarmenbolApril 29, 2026
Share:
Federal Law 152-FZ compliance: what the 2025 amendments broke and what assessments find

TL;DR

  • The July 2025 amendments to Federal Law 152-FZ banned initial collection of Russian citizen data on foreign servers entirely. Any form, tracker, or analytics script that sends data to a foreign server before saving it in Russia now violates the law. Roskomnadzor began issuing instructions to affected site owners immediately after July 1, 2025. Google Analytics, Google Tag Manager, reCAPTCHA, and foreign HR platforms were the first casualties.

  • Fines for repeat localization violations now reach 18 million rubles under Law No. 420-FZ (November 2024, effective May 30, 2025). The fine structure has roughly tripled from where it was two years ago. Website blocking remains an additional sanction Roskomnadzor uses actively.

  • The most consistent technical finding in Vulnox 152-FZ assessments is not missing encryption — it is encryption tools that are commercially standard but not FSTEC-certified, meaning the protection level classification fails even though data is encrypted. Scanners that check for encryption presence miss this entirely. (Vulnox assessment data, 2024–2025)

  • Hosting data on Russian servers satisfies the localization requirement under Article 18 but does not satisfy the technical security requirements under Article 19 and FSTEC Order No. 21. These are separate compliance obligations enforced by separate regulators — Roskomnadzor for localization, FSTEC for technical controls. Treating them as one requirement is the single most common planning error in 152-FZ programs.

  • The July 2025 amendment extended localization obligations to processors — not just operators. Foreign SaaS vendors providing HR, CRM, or analytics tools that receive Russian citizen data are now directly in scope. This creates compliance exposure for Russian subsidiaries of international companies using group-wide software platforms.

The morning everything broke

On July 1, 2025, a mid-size Russian e-commerce company woke up to instructions from Roskomnadzor. Their website was using Google Analytics for traffic measurement and a foreign-headquartered CRM that synced customer records to European servers. Both had been in place for years. Both were now in violation of the amended Article 18(5) of Federal Law 152-FZ. They were not alone — Roskomnadzor began issuing mass instructions to site owners across Russia that day, and the pattern was consistent: any tracker, form, or script transmitting personal data to a foreign server before saving it to a Russian database was now prohibited, regardless of what happened to the data afterward.

Turning point:

The July 2025 amendment is not a refinement of an existing localization requirement. It is a structural change in how initial data collection is permitted to work. Previously, operators could use foreign processors provided the primary database was in Russia — the data could touch a foreign system as long as it was stored locally first. The amendment reverses the logic: no personal data of Russian citizens may be collected using a foreign database at any stage, even transiently, even if it is immediately replicated to a Russian server. For companies that had architected their compliance around the older dual-localization interpretation, the July 2025 amendment made their architecture non-compliant overnight.

What the assessments actually surface

Assessment base: Based on 152-FZ compliance assessments conducted by Vulnox in 2024 and 2025, covering Russian-facing operations in e-commerce, SaaS, and retail sectors with employee ranges of 80 to 500, operating personal data information systems at UZ2 and UZ3 protection levels.

Encryption present, certification absent

The most consistent technical finding in Vulnox 152-FZ assessments is not the absence of encryption on personal data. It is the use of commercially standard encryption tools — TLS implementations, database encryption modules, backup encryption — that are not FSTEC or FSB-certified. FSTEC Order No. 21 requires that cryptographic protection tools used in personal data information systems hold current FSTEC or FSB certification appropriate to the system's protection level. Standard OpenSSL implementations, AWS KMS, and common commercial encryption products do not hold that certification. The organization has encryption. The audit fails because the encryption tool is wrong. General-purpose vulnerability scanners test for the presence of encryption, not the certification status of the implementation. This gap is invisible to automated scanning and shows up only in manual assessment against FSTEC Order No. 21 requirements. (Vulnox assessment data, 2024–2025)

Cached personal data outside the classified system boundary

152-FZ compliance work focuses on the formal personal data information system — the databases, application servers, and backup infrastructure that are classified, threat-modeled, and protected under FSTEC Order No. 21. What consistently falls outside that boundary in Vulnox assessments is cached data: Redis instances used for session management and performance caching that contain personal data but were never included in the system classification scope. In multiple engagements with companies operating Russian-facing applications, Vulnox found Redis instances on internal networks with default configuration — no authentication, no encryption, accessible on TCP port 6379 — holding personal data that was in scope for 152-FZ but outside the formal protection boundary. The data is in Russia. The system is unprotected. The classification was done correctly for the database tier and incorrectly assumed it covered the caching tier. (Vulnox assessment data, 2024–2025)

Consent records that exist but cannot be produced on audit timelines

Article 9 consent requirements under 152-FZ are stricter than most organizations implement. Consent must be freely given, specific, informed, unambiguous, and separately obtained for data distribution to third parties. The documentation requirement is ongoing: Roskomnadzor auditors request consent records including date, time, and specific processing purpose, and they can request samples at any time. The pattern Vulnox finds is organizations that have consent flows in place but store consent records in a format — unindexed application logs, raw database tables without query tooling — that makes producing specific consent records on a short audit timeline operationally difficult. The consent was obtained. The evidence is inaccessible when it is needed. (Vulnox assessment data, 2024–2025)

The penalty numbers after the 2025 changes

18 million rubles

The maximum fine for repeat violations of the localization requirement under Law No. 420-FZ (November 2024, effective May 30, 2025). First-time localization violations now carry fines of 1 million to 6 million rubles. The prior maximum for a first offense was approximately 6 million rubles for the most serious violations — the new structure creates a meaningful escalation for organizations that receive an instruction and do not remediate. Roskomnadzor also retains authority to block websites and services entirely, a sanction applied to LinkedIn in 2016 and maintained since. (Law No. 420-FZ, November 2024; Konsu Group analysis, March 2025)

24 hours

The breach notification window to Roskomnadzor under 152-FZ — three times faster than GDPR's 72-hour requirement. Failure to notify within 24 hours carries fines up to 3 million rubles under current penalty schedules. Organizations running dual GDPR and 152-FZ compliance programs need separate breach notification workflows on different timelines, triggered by the same event. (Federal Law 152-FZ Article 21; ITLawCo 152-FZ analysis)

July 1, 2025

The effective date of the amendment prohibiting initial collection of Russian citizen personal data on foreign servers. The amendment was published February 28, 2025, giving Russian-facing operations approximately four months to audit and migrate any foreign analytics, HR, or data collection tools that were receiving data before it was saved to a Russian database. Roskomnadzor began issuing instructions to non-compliant site owners on the first day the amendment took effect. (Federal Law No. 23-FZ, February 2025)

Hosting in Russia is the easy part

Common belief

The default assumption going into a 152-FZ compliance program is that data localization is the hard problem — finding Russian data center infrastructure, migrating databases, rearchitecting backup systems. Once the data is on Russian soil, the reasoning goes, compliance is largely achieved. The technical security requirements are treated as a secondary concern, something to address after localization is confirmed.

What we found

In Vulnox assessments, organizations that self-report as 'compliant with localization' consistently show incomplete FSTEC Order No. 21 implementation. The localization work was done — databases are in Russia, the Roskomnadzor operator registration is current — but the threat model document is absent, the system protection level has never been formally classified, and the technical controls in place use non-certified tools. Localization was treated as the finish line. FSTEC treats it as the starting line. (Vulnox assessment data, 2024–2025)

This is backward. Data localization satisfies one Article 18 requirement and is enforced by one regulator — Roskomnadzor. The technical security requirements in Article 19, enforced through FSTEC Order No. 21 by FSTEC as a separate authority, are an independent compliance obligation that has nothing to do with where the data is physically located. An organization can host perfectly on Russian servers and still fail the FSTEC technical audit because the encryption tools are not FSTEC-certified, the threat model document does not meet the required format, or the system has not been formally classified into one of the four protection levels (UZ1 through UZ4). These are not administrative details — they are the foundation of the technical compliance program, and they cannot be satisfied by server location alone.

How the compliance architecture actually works — three regulators, not one

152-FZ is often described as if it were enforced by a single authority. It is not. Three separate federal bodies have jurisdiction over different aspects of personal data protection, and a compliance program that satisfies one does not automatically satisfy the others.

Roskomnadzor oversees the organizational and notification requirements: operator registration (Article 22), consent validity (Article 9), data subject rights responses (Articles 14–21), data localization (Article 18), cross-border transfer notifications, and breach notification to the authority (Article 21). Roskomnadzor conducts planned and unplanned audits, responds to data subject complaints, and issues blocking orders. The July 2025 amendment and the 2024 fine increases are both Roskomnadzor-enforced changes.

FSTEC governs the technical security of personal data information systems under Order No. 21. FSTEC requires operators to classify their information systems into four protection levels based on data type, data volume, and potential damage to data subjects. Each protection level has specific mandatory technical measures: UZ1 (the highest, for the most sensitive data at the largest scale) requires the most extensive certified controls; UZ4 (the lowest) requires baseline measures. The critical constraint is that encryption and security tools used in these systems must be FSTEC-certified — commercially standard products do not qualify regardless of their technical strength.

FSB governs cryptographic protection specifically, including FSB-licensed encryption tools for communications and storage. For systems handling personal data at higher protection levels, FSB certification of cryptographic tools is a separate requirement from FSTEC certification.

The practical implication is that a 152-FZ compliance audit is three overlapping audits with different evidence sets, different regulators, and different remediation paths. Organizations that map their compliance program to Roskomnadzor requirements alone leave the FSTEC technical controls entirely unaddressed.

Example

One concrete example of how the three-regulator architecture creates gaps: an organization completes Roskomnadzor operator registration, implements consent flows, and migrates databases to Russian data centers. They document this as 152-FZ compliant. A FSTEC inspection finds that the information system classification was never performed — the organization never formally determined whether their system is UZ1, UZ2, UZ3, or UZ4 — and therefore no threat model document exists and no FSTEC Order No. 21 control selection was ever completed. The Roskomnadzor work is legitimate and remains valid. The FSTEC finding is a separate, independent compliance failure that the Roskomnadzor work did not touch.

The protection level determination feeds everything downstream in the FSTEC framework. UZ4 systems require a baseline set of controls; UZ1 systems require the full set including certified intrusion detection, certified antivirus, and certified cryptographic tools. The wrong protection level classification — typically underclassification — means the control set is insufficient for the actual data being processed. FSTEC auditors cross-reference the classification rationale against the actual data types, volumes, and potential damage assessment. Organizations that classified their systems at UZ4 to minimize control requirements but process special categories of data (health, biometric, criminal record) that require UZ1 or UZ2 classification face the most significant remediation work.

What clients say before the assessment versus what is actually going on

  • 'We moved all our databases to a Russian data center two years ago. We're compliant. This assessment should just confirm what we already know.'

    Root cause:

    Localization of the primary databases satisfies Article 18. It does not satisfy Article 19 technical security requirements, FSTEC Order No. 21 protection level classification, or the threat model documentation that FSTEC auditors require. In Vulnox assessments, organizations in this situation typically have Roskomnadzor operator registration current and localization confirmed, while having never completed an information system classification or threat model. The FSTEC work is completely absent — not partially done, not outdated, absent. Moving the databases was the right first step. It was not the last step.

  • 'We got instructions from Roskomnadzor about our website using Google Analytics. We disconnected it. We should be fine now.'

    Root cause:

    Disconnecting Google Analytics addresses the immediate instruction, but the instruction from Roskomnadzor is a symptom of a broader audit of the site's data flows, not just the one analytics tool flagged. Under the July 2025 amendment, any form, field, chatbot, or tracker that sends data to a foreign server before it is saved in Russia violates Article 18(5). Organizations that disconnect one tool and do not audit all other data collection paths — contact forms, chat widgets, third-party payment flows that pass customer data before processing, foreign-hosted CRM integrations — typically remain in violation with different tools after addressing the specific Roskomnadzor instruction. The instruction is the beginning of the audit process, not the end of it.

  • 'We use encrypted databases and enforce TLS everywhere. Our encryption is stronger than what most companies run. We should have no technical security issues.'

    Root cause:

    152-FZ technical security requirements under FSTEC Order No. 21 are not satisfied by encryption strength — they are satisfied by the certification status of the encryption tool. A system using AES-256 with a commercially standard implementation that is not FSTEC or FSB-certified fails the technical requirement. A system using a weaker algorithm with a FSTEC-certified tool passes it. The standard is regulatory, not cryptographic. Organizations that have invested in strong commercial encryption and treat that as FSTEC compliance have built security that is technically superior and legally non-compliant at the same time.

The myth that the compliance work can be done once

The myth

The reality

What organizations consistently miss

Third-party processors are now directly in scope

Prior to July 2025, localization obligations applied to operators. Processors — third parties processing data on the operator's behalf — were required to comply by contract, but the legal obligation sat with the operator. The July 2025 amendment extended localization requirements directly to processors. Foreign SaaS vendors providing HR management, CRM, analytics, or any other service that processes Russian citizen personal data are now independently subject to the localization requirement, not just contractually obligated by the operator's compliance program. Russian subsidiaries of international companies using group-wide software platforms need to audit each tool against the new processor scope. The parent company's GDPR-compliant data processing agreements with those vendors do not substitute for FSTEC and Roskomnadzor compliance.

The 24-hour breach notification requirement requires a pre-built workflow

152-FZ's 24-hour breach notification window to Roskomnadzor is shorter than most incident response timelines are designed to accommodate. Incident detection, scoping, legal review, and regulatory notification in 24 hours requires a pre-built notification workflow — designated responsible person, pre-approved notification template, Roskomnadzor contact details current. Organizations that discover this obligation during a breach, rather than during compliance preparation, routinely miss the window. Missing the 24-hour deadline is a separate violation from the breach itself, carrying additional fines under the current penalty schedule.

Cookies are treated as personal data collection under Roskomnadzor interpretation

Federal Law 152-FZ does not explicitly mention cookies, but Roskomnadzor's enforcement interpretation treats the use of tracking cookies as collection of personal data subject to the law's requirements. This means cookie consent mechanisms on Russian-facing websites must satisfy 152-FZ consent requirements — freely given, specific, informed, unambiguous — not just serve as a GDPR cookie banner. Organizations that have implemented GDPR-compliant cookie consent and assumed it covers 152-FZ may have consent flows that satisfy European requirements but do not produce the consent record format that Roskomnadzor auditors request. The July 2025 localization amendment compounds this: if the cookie scripts transmit data to foreign servers before saving locally, both the consent and the localization requirement are violated simultaneously. (Konsu Group 152-FZ analysis, March 2025)

The assessment and remediation sequence

  1. Step 1

    Map all data flows for personal data of Russian citizens

    Output:

    A complete data flow map distinguishing Russian-located processing from foreign-touching flows, with each tool and service identified by location and processing type.

    Purpose:

    Identify every system, service, and third-party tool that collects, processes, stores, or transmits personal data of Russian citizens — including web analytics, CRM, HR platforms, payment processors, CDN providers, and backup services. Post-July 2025, any tool in this list that is foreign-headquartered and receives data before it is saved to a Russian database is a localization violation.

  2. Step 2

    Audit website and application data collection against the July 2025 amendment

    Output:

    A list of non-compliant collection mechanisms with remediation options: replacement with Russian-equivalent tools, re-architecture to save locally before forwarding, or discontinuation.

    Purpose:

    For every form, field, chat widget, tracker, and analytics script on Russian-facing properties, trace where data goes on submission. If any data reaches a foreign server before being written to a Russian database, the collection mechanism violates Article 18(5) as amended. This step must be repeated every time a new third-party tool is added.

  3. Step 3

    Classify the personal data information system under FSTEC Order No. 21

    Output:

    A formal classification document for each in-scope information system, with rationale for each factor in the protection level determination.

    Purpose:

    Determine the protection level (UZ1 through UZ4) for each information system based on data categories processed, volume, and potential damage to data subjects. This classification drives every downstream FSTEC technical control requirement. Wrong classification — typically UZ4 when the actual data warrants UZ2 — means the entire control set is insufficient.

  4. Step 4

    Build the threat model to FSB-approved methodology

    Output:

    A current threat model document that matches the live system architecture and supports the protection level classification.

    Purpose:

    Document the actual threats applicable to the information system using the FSB-approved threat modeling methodology. The threat model is a required audit artifact — FSTEC auditors will ask for it and verify that it reflects the current system architecture. Threat models that were built for the prior architecture and have not been updated since a cloud migration or service addition are a common audit finding.

  5. Step 5

    Audit the technical control stack for FSTEC and FSB certification status

    Output:

    A control inventory with certification status for each tool, identifying non-certified controls that need replacement or supplementation with certified equivalents.

    Purpose:

    For each technical security control in place — encryption, antivirus, intrusion detection, access control — verify that the specific tool or implementation holds current FSTEC or FSB certification appropriate to the system's protection level. Standard commercial products do not qualify. This step requires checking the current FSTEC and FSB certified products registers, not assuming that encryption presence equals certification compliance.

  6. Step 6

    Verify consent records are auditable on short timelines

    Output:

    A consent record retrieval test: pick five random users, retrieve their consent records including date, time, and purpose within one hour using existing tooling.

    Purpose:

    Roskomnadzor auditors request consent records — date, time, specific processing purpose — on audit timelines that may be short. Confirm that consent records are stored in a format that allows retrieval of specific records by individual and processing purpose within hours, not days. If consent records live in application logs that require engineering effort to query, that is a gap that needs tooling or data migration.

  7. Step 7

    Build the 24-hour breach notification workflow

    Output:

    A breach notification procedure that can produce a Roskomnadzor notification within 24 hours of breach confirmation, with a named responsible person and tested execution.

    Purpose:

    Roskomnadzor notification within 24 hours requires a pre-built process — designated responsible person, approved notification content, current Roskomnadzor notification portal credentials, and legal review incorporated into the timeline rather than blocking it. Test the workflow with a tabletop scenario before a breach requires it.

What comes next

  1. Roskomnadzor's mass website compliance checks triggered by the July 2025 amendment will expand from analytics tools to foreign-hosted form and chat infrastructure within 12 months. The initial wave of instructions targeted obvious violators — Google Analytics, Tag Manager, reCAPTCHA. The next wave will target contact forms, registration flows, and chat widgets that transmit data to foreign servers, because the same legal logic applies and Roskomnadzor has the enforcement precedent from the analytics wave.

    The July 2025 amendment applies to any form, field, or script that sends data to foreign servers before local saving. Roskomnadzor has already established the mass-instruction enforcement pattern. Analytically, the authority has identified the compliance gap, demonstrated it will enforce it, and the same gap exists in a much larger surface area of Russian-facing websites that has not yet been audited.

    Confidence: highIf Roskomnadzor issues a second wave of mass compliance instructions targeting contact form and chat widget integrations with foreign servers by Q2 2026, the prediction is confirmed. The signal to watch is Roskomnadzor's public enforcement announcements and any guidance specifically addressing form and chat data collection via foreign scripts.
  2. The extension of localization obligations to processors in the July 2025 amendment will create a compliance audit market for Russian subsidiaries of international companies needing to certify that their group-wide SaaS tools either comply or are excluded from Russian-citizen data processing. This is not yet a standard service offering in the Russian compliance market, but the legal obligation is now clear and the cost of non-compliance is high enough that legal and compliance teams at international companies with Russian operations will need to produce per-tool compliance determinations.

    Prior to July 2025, the processor localization obligation was contractual, not statutory. International companies could manage it through data processing agreements. The July 2025 amendment makes it a direct statutory obligation on processors, which means each tool needs independent legal analysis, not just a contract clause. International companies with Russian operations using dozens of group-wide SaaS tools face a significant assessment burden.

    Confidence: mediumIf Russian and international law firms begin offering 152-FZ processor compliance assessments as a named service line by Q4 2025, or if any international company publicly discloses migrating group-wide SaaS tools due to the July 2025 processor amendment, the prediction is confirmed.

What the next 18 months looks like for 152-FZ compliance programs

The July 2025 amendments and the November 2024 fine increases are not the end of the legislative activity. The Russian data protection regulatory environment has been in continuous amendment since 2020 and the direction is consistent: stricter localization, broader scope, higher penalties, faster enforcement.

The area of greatest uncertainty for compliance programs right now is how Roskomnadzor will interpret the July 2025 amendment's prohibition on initial collection using foreign databases in the context of multi-cloud and hybrid architectures. The legal text prohibits collection using foreign databases but preserves cross-border transfer after Russian processing is complete. State Duma representatives have at points suggested a stricter reading — effectively a complete ban on cross-border data flows — while the law's text preserves transfer with notification. Organizations that have built data routing architectures that save to Russia first and then sync to foreign systems are currently compliant on the stricter reading, but the interpretive ambiguity has not been resolved by Roskomnadzor guidance as of early 2026.

The other development to watch is FSTEC's ongoing update of certified products registers. The list of FSTEC and FSB-certified encryption and security tools changes as certifications are granted, renewed, or revoked. Organizations that certified their technical control stack two years ago and have not rechecked certification status may be running on tools whose certifications have lapsed. FSTEC does not notify operators when a product's certification status changes — the obligation to maintain certified controls is continuous and the verification responsibility sits with the operator.

For international companies with Russian operations, the practical planning question is no longer whether to invest in a 152-FZ compliance program but whether the compliance program is current against the 2024 and 2025 amendments and whether it covers the FSTEC technical requirements as a distinct track from the Roskomnadzor organizational requirements. The majority of compliance programs Vulnox has assessed do not.

Where to start this week

Pull your website and application data flows and trace what happens to personal data on submission. If any data from Russian users reaches a foreign server before being written to a Russian database, that is a live Roskomnadzor violation under the July 2025 amendment — not a future risk. Do that audit before anything else, because Roskomnadzor is already issuing instructions and the fine structure for repeat violations is now 18 million rubles. If your organization has never completed an FSTEC information system classification and threat model, or completed one more than two years ago before a significant architecture change, that is the second priority. The certification status of your encryption tools determines whether your entire technical control investment counts for the purposes of the compliance that matters.

Further Reading

Frequently Asked Questions

What changed about Russian data localization requirements in July 2025?

Significantly. Federal Law No. 23-FZ (published February 28, 2025, effective July 1, 2025) amended Article 18(5) of 152-FZ to prohibit the initial collection of personal data of Russian citizens using foreign databases entirely. Previously, operators could use foreign processors provided the primary database was in Russia. As of July 1, 2025, any form, field, chatbot, tracker, or analytics script that transmits data to a foreign server before it is saved in Russia violates the law. This triggered mass disconnections from Google Analytics, Google Tag Manager, reCAPTCHA, and foreign HR management systems across Russian-facing websites. Roskomnadzor began issuing instructions to affected site owners immediately after the law took effect. (Federal Law No. 23-FZ, February 2025; Konsu Group analysis, March 2025)

What are the current fines under Federal Law 152-FZ?

The penalty structure was tightened by Law No. 420-FZ (November 2024, effective May 30, 2025). Fines for initial localization violations now range from 1 million to 6 million rubles. Repeat violations reach 6 million to 18 million rubles. Failure to notify Roskomnadzor of a data breach within 24 hours carries fines up to 3 million rubles. Processing personal data without consent or a valid legal basis carries fines up to 6 million rubles for legal entities. Roskomnadzor also retains the authority to block websites and services that fail to comply — a sanction it has applied to major platforms including LinkedIn. (Law No. 420-FZ, November 2024; ITLawCo 152-FZ analysis)

Does hosting data on Russian servers satisfy the 152-FZ localization requirement?

Not by itself, and less so after July 2025. Hosting on Russian servers satisfies the database localization requirement under Article 18 but does not satisfy the technical security requirements under Article 19 and FSTEC Order No. 21. Those require threat modeling, classification of the personal data information system into one of four protection levels (UZ1–UZ4), and implementation of certified technical controls appropriate to that level — including encryption, access controls, intrusion detection, and antivirus tools that are FSTEC or FSB-certified. A server physically located in Russia with standard commercial encryption may still fail an audit because the encryption tools are not certified by the relevant Russian authority. (FSTEC Order No. 21; Selectel 152-FZ technical guidance)

What is the most common technical gap Vulnox finds in 152-FZ assessments?

Two findings appear consistently. First, unencrypted data cached in services like Redis — version 5.0 or earlier exposed on public IPs without authentication, used to cache personal data on TCP port 6379 — where the cache is not included in the scope of the formal information system classification and therefore receives no technical controls under FSTEC Order No. 21. Second, encryption tools that are commercially standard but not FSTEC-certified, meaning they fail the technical requirements for the applicable protection level even though data is encrypted. The encryption exists; the certification of the tool does not. Both findings are invisible to general-purpose vulnerability scanners that check for the presence of encryption, not the certification status of the encryption implementation. (Vulnox assessment data, 2024–2025)

What does a Roskomnadzor audit actually examine?

Roskomnadzor audits combine documentary review with technical verification. On the documentary side: data processing policies and procedures, data flow diagrams, consent records with date, time, and specific purpose, operator registration details, breach notification records, and contracts with data processors. On the technical side: auditors may conduct their own network scans to verify that data is localized within Russia, review application logs for consent tracking mechanisms, and examine system configurations to confirm segmentation and access controls. FSTEC, as a separate authority, examines technical security controls specifically — the threat model document, the information system protection level classification, and evidence that certified tools are implemented at the appropriate level. Organizations that treat these as two separate audits requiring separate preparation are correct to do so. (Roskomnadzor audit guidance; FSTEC Order No. 21)

How does the July 2025 amendment affect companies using foreign SaaS tools for HR or CRM?

Directly and materially. The July 2025 amendment extended localization obligations to data processors — not just operators. Any third-party vendor offering data analytics, HR management, or CRM platforms that receives Russian citizen personal data before it is saved in Russia now violates the localization requirement. This affects foreign-headquartered SaaS tools used by Russian subsidiaries of international companies. The practical options are migrating to a Russian equivalent, configuring a data routing architecture that saves to a Russia-based database before any foreign system receives the data, or discontinuing the tool for Russian-citizen data processing. Roskomnadzor was issuing site instructions immediately after July 1, 2025. (Federal Law No. 23-FZ; Xinhua reporting on amendments, June 2025)

What is the breach notification timeline under 152-FZ?

Organizations must notify Roskomnadzor within 24 hours of discovering a data breach — stricter than GDPR's 72-hour window. The notification must include details about the nature of the breach, the categories of data affected, and the number of individuals involved. Affected individuals must also be notified without undue delay. Failure to notify within 24 hours carries fines up to 3 million rubles under the current penalty schedule. Organizations operating under both GDPR and 152-FZ need separate breach notification workflows for each authority, triggered by the same breach event but on different timelines. (Federal Law 152-FZ Article 21; ITLawCo 152-FZ analysis)

Related Articles

GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard

GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard

GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.

GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong

GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong

GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.

GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard

GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard

GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.

Ready to Secure Your Digital Assets?

Get a comprehensive vulnerability assessment for your website today.