PD incidents

Definition

PD incident

any breach of confidentiality, integrity and/or availability of PD during automated and/or non-automated processing

Typical examples

hacking of a user account

hacking of an IT system or PD database

improper destruction of PD on a device

improper destruction of a document with PD

lost device with PD

lost document with PD

misdirected e-mail with PD

unauthorised access to PD

unauthorised copying of PD

unauthorised publication of PD

• Feature
• Incident, Art. 21(3.1) of Law 152-FZ
• Computer incident, Art. 19(12) of Law 152-FZ
• Leak, Art. 13.11(12)-(18) of the CAO

• Action
• transfer: provision, dissemination, access
• transfer: provision, dissemination, access
• transfer: provision, dissemination, access

• Scope
• PD
• PD
• information including PD and/or identifiers in a PDIS

• Nature
• unlawful or accidental
• unlawful
• unlawful

• Cause or consequence
• infringed data subjects' rights
• resulted from a computer attack
• resulted from the operator's action or inaction

• Whom to notify
• Roskomnadzor
• FSB via GosSOPKA
• no separate duty

Consequence: one event can be at once an incident for Roskomnadzor, a computer incident for GosSOPKA and a leak under the CAO, so classify it under all three definitions

vs

Incident

Is an incident

PD database open to an unlimited group of persons through unlawful or accidental transfer of PD (RKN Order No. 187 of 14.11.2022)

unauthorised access to a PD database by an external user

unauthorised access due to system software vulnerabilities

unlawful copying of a PD database

a copy of a PD database, current or previously compromised, is available online

received a threat to disclose a PD database

Not an incident

Is not an incident

unauthorised access to a PD database by an internal user without copying

internal user accidentally destroys a PD database

suspicious activity of a system user

1

Operator's admission

the operator itself confirms the incident in a notice or inspection

2

Match with the PDIS

the leak matches the data of the system Roskomnadzor examines: specific values, set of fields

3

Circumstances

details show the data belong to the operator: its name is given or its line of business implies such data

4

Screenshots

the data match screenshots provided by the operator or obtained by the regulator during an inspection

5

Related resource

the data are posted on a resource tied to the operator, e.g. its own website

Practical takeaway: denying a leak when even some signs match only worsens the operator's position at inspection and in court

• 1
• Did you have a leak?

no - grab popcorn and watch

• 2
• Was the leak in the media?

no - popcorn again

• 3
• Yes - pick an excuse

several are fine, then popcorn again

• Not ours, the contractor's
• The data is stale and irrelevant
• It repeats last year's leak

• It is a provocation by competitors
• Not PD: it is depersonalised
• A press release won't object

In fact: a processor does not relieve the operator of liability, a repeat leak draws a turnover-based fine, and depersonalised data remain PD

• Admission and communication
• own confirmation and communication with those affected [Yandex, VkusVill]

• Own admission
• leak confirmed by the company itself [DNS]

• Admission via the press
• leak confirmed through the media [Sportmaster, CDEK, Whoosh]

• Admission without liability
• leak confirmed with disclaimer of liability [AlfaStrakhovanie]

• Denial
• leak denied, claim of compiled old databases [Sber]

• Active denial
• denial that the leak is theirs and attempts to stop discussion [Geekbrains]

vs

Playing not to lose

Minimising the costs of a leak

limited disclosure and legally vetted wording

focus on notification deadlines and defence at inspection

goal: minimum fine and reputational damage

Playing to win

Making the most of a leak

proactive communication with subjects, partners and the regulator

showing measures taken and investment in protection

goal: keep and strengthen trust, turn the crisis into an argument

Decision: the game is chosen in the first days and sets the tactics, budget and working group

Lawyer

classification, deadlines, stance at inspection, court

Privacy specialist

harm assessment, notifications, contact with the regulator

Business

decisions on resources, compensation and communication

IT and IS

containing the incident, investigation, technical measures

PR

company position for media, clients and partners

Consultant

external expertise and an independent view

Consultant's adviser

narrow expertise for a specific case

• 3 days
• 2 weeks
• 6-8 weeks

Preparing the response plan

Preparing response measures

Detecting the leak

Setting strategy and tactics

Conducting the investigation

Technical and organisational measures

Internal and external communication

Preparing for inspection

Preparing for court

Real duration of a leak's life cycle, guideline

Responding to a PD incident

Unlawful or accidental transfer of PD infringing subjects' rights

detected by operator, Roskomnadzor or another person

RKN Order No. 187: on the incident (24 hours) and on investigation results (72 hours)

Roskomnadzor

portal pd.rkn.gov.ru/incidents/form

Computer incident leading to unlawful transfer of PD

detected by the PDIS operator

FSB Order No. 77: on detection (24 h), on results (72 h) via the RKN portal. State systems from 01.09.2026 under No. 297, CII from 30.01.2026 under No. 547 (3 h for a significant object)

FSB

• RKN portal, if no agreement with NCCCI
• GosSOPKA (CII subjects) or by NCCCI agreement

Disclosure of PD as part of bank secrecy or protected information

detected by a credit or non-credit financial institution

STO BR BFBO-1.5-2023: on detection (24 hours, 3 hours under GOST R 57580.1-2017) and on investigation results (30 days)

Bank of Russia

FinCERT or GosSOPKA, plus the RKN portal

No notice: fine up to ₽3m, Art. 13.11(11) of the CAO; aggravating factor if a turnover-based fine for a leak applies

• incident detected
• 24 hours
• 72 hours

on the incident, within 24 hours

on investigation results, within 72 hours

Incident details

date and time of detection

suspected causes, e.g. unauthorised access by an external user

PD features: categories, subjects, approx. record count, database currency, collection period

suspected harm to subjects' rights

measures taken to remedy the consequences

additional information (source, links to resources) and materials on measures taken

contacts of the person authorised to liaise with Roskomnadzor

Internal investigation results

causes of the incident and harm caused

information system that was accessed

additional measures following the investigation

operator's decision to investigate, with its details

information on persons whose actions caused the incident

Important: the clock starts when the incident is detected by the operator, Roskomnadzor or another interested person

Roskomnadzor incident request

• Operator details
• document appointing the operator's authorised representative

charter of the operator (legal entity)

Internal regulations

operator's PD processing policy

records of preventing, detecting and remedying the effects of PD law violations

documents on legal, organisational and technical PD security measures

PDIS information

PDIS description

name, purpose and location of the database

subject categories, PD list and actions on PD

instructions and functionality documents

software names and versions, component locations

• Support
• technological and information support, incl. contracts with service providers

Tip: a leak usually triggers an administrative investigation (Art. 28.7 of the CAO) and information requested within 3 days (Art. 26.10(2)). The request varies by incident, so prepare the document pack in advance

Nature of the incident

What softens the assessment

Document these factors from day one

Insignificance

small scale in terms of the number of data subjects and identifiers affected

No sensitive data

affected PD exclude special, biometric and other sensitive categories

No vulnerable groups

subjects are not from socially unprotected population groups

Short duration

brief third-party access caused by a technical failure or accident

NDA

unintended access to PD by third parties bound to the operator by confidentiality

Third parties

acts or omissions of processors, or actions of attackers

Attack complexity

highly professional cyberattack, specialised software, sophisticated techniques

About the operator

first incident, operator not held liable before

operator's admission of guilt and remorse

operator's unstable financial position

status as a small or medium enterprise

status as a socially oriented non-profit organisation

About the incident and context

no complaints, claims or suits from subjects over the incident

harm rated medium under para. 2, cl. 2.2, RKN Order No. 178

tense geopolitical situation and rising hacker attacks on Russian companies

Practice: in 2025 commercial courts weighed them when replacing a fine with a warning, but since 2026 magistrates rarely give a warning, and on appeal it is held inadmissible for large leaks

01

Safeguards

implementing necessary and sufficient legal, organisational and technical PD protection measures

02

Conformity assessment

using security tools that have passed conformity assessment in the prescribed manner

03

Monitoring measures

monitoring PD security measures, including at persons engaged in processing

Why it matters: in hacking cases courts require the operator to prove what measures it took, so prepare records of measures before an incident

• 1
• internal investigation or staff inquiry to find the causes

• 2
• timely and proper notification of Roskomnadzor

• 3
• working with Roskomnadzor during an inspection

• 4
• reporting to law enforcement, the FSB and/or NCCCI, recognition of the operator as a victim, opening a criminal case

• 5
• alerting interested persons, including data subjects

Technical measures

restricting access to compromised systems and databases

blocking access to the incident source

changing passwords of users and technical accounts

isolating affected infrastructure components

changing equipment configuration

deleting data to prevent a repeat leak

• 1
• monitoring postings of compromised PD and removing copies

• 2
• strengthening the IS policy and procedures

• 3
• assessing and treating IS risks

• 4
• hiring more specialists and engaging external IS consultants

• 5
• raising awareness and training staff

• 6
• voluntary reimbursement of damage and compensation to data subjects

Technical measures

software audit to find vulnerabilities

limiting network availability of services and components

buying more security tools: WAF, firewalls, IDS

updating software, antivirus databases

regular review of domain accounts

Bonus: in cases found through supervision, voluntary compensation and remedying consequences entitle to the minimum fine under Art. 4.1(3.4-1) of the CAO

Target audience

company position

staff

clients

partners

competitors

the public

media, bloggers, Telegram

Roskomnadzor, prosecutors, law enforcement

Spin doctoring

Pre-spin

preparation before the event

Post-spin

polishing what happened

event

Tornado spin

diverting audience interest elsewhere

Spin control

managing an event slipping out of control

Spin-down

managing an event that has got out of control

slips out of control

Scale and nature

any non-demeaning amount and type of compensation bankrupts at scale

High bar

a compensation threshold too high is immoral, too low is bankrupting

Administration

supporting claimants, complex cases and fraud control are costly and one-off

Reputation

in most scenarios the programme still harms reputation rather than helping

Precedent

the unique situation raises unresolved legal and tax questions

Litigation

out-of-court compensation does not bar recovery of damages in court

Check your data at chk.safe-surf.ru

• 1
• Learn of a compromise

credentials in leaked databases mean they have reached attackers

• 2
• Change passwords in time

attackers do not always use access at once

• 3
• Work on protection

security is an ongoing process, not a one-off setup

A response plan or procedure is a document allocating roles and actions in an incident. Response can involve 15 or more functions, from which a coordinated crisis team is built

Crisis team

• Technology and investigation
• 7

Information security

Infrastructure

IT product team

Support engineers

Data analytics

Situation centre

Security service

• PD, people and communications
• 5

DPO

Customer service

PR

GR

HR

• Decisions and resources
• 4

Top management

Finance

Shareholders, external stakeholders

External consultants

What a plan consists of

• 1
• defined areas of responsibility

• 2
• stakeholders from the business functions involved

• 3
• general response procedure

• 4
• playbooks: instructions with a clear action algorithm for each performer

A good playbook

only relevant items, not a wall of text

in the performer's language

up to date

comprehensive

• What is done
• Output

• 1
• Detection
• the responsible person collects reports at one point from monitoring, staff, public sources and third parties, and appoints an incident manager
• incident classified, analysis and investigation launched

• 2
• Analysis and response
• IS and IT trace compromise points and the event chain, close access, roll back the feature, disable the API method
• consequences reduced, information documented in one place

• 3
• Dump analysis
• IS and IT find screenshots, fragments and files, download them safely and match attributes with company data
• match statistics, dating, characteristics

• 4
• Confirmation
• DPO uses investigation, measures and dump to assess PD, ownership and breach of subjects' rights
• fact confirmed or refuted, or left unconfirmed if information is lacking

• 5
• Notices
• DPO drafts decisions and communications, management approves within the SLA, PR position agreed
• decisions on notifying regulator, counterparties, data subjects, and on compensation

• 6
• Post-analysis
• IS and DPO define organisational measures, technical fixes and changes to unit processes
• tasks with deadlines and owners

• 7
• Closure
• incident manager and DPO compile the status of taken and planned measures, run external communications, document the incident
• a non-operational stage; if gaps appear, the response process is revised

Open question: does the response timer start on detecting the incident (stage 1) or on confirming it (stage 4)? The difference is unclear

step 1

Infrastructure readiness

assess the need for external expertise and support

log collection and storage, deploying security tools

tickets and repositories open to all teams

step 2

Preparation and training

implementers are not the executors

configuring systems and tools

templates where needed

step 3

Testing the plan

table-top exercise

workshop

simulation of a real leak

better not to test on a real incident

Takeaway: a plan without drills stays a document: weak spots are found in training, not during a real leak