152-FZ compliance: where personal data protection breaks down
A typical 152-FZ compliance audit starts not with documents but with infrastructure — and there it finds the same thing.
Access logs are written, but without retention periods and without protection against editing: a record can be changed or deleted, and there is no way to prove who read the database and when.
Rights to databases are granted to broad groups — “temporarily,” “for debugging” — and remain in effect for years.
Backups are stored in the same storage as production data, often without encryption, and data encryption keys are next to the data itself: recovery is convenient, but encryption stops protecting anything.
Any data leak in such a scheme is not investigated — there is no way to confirm whether someone read a backup.
The reason is usually the same: infrastructure grows faster than policies. Access is granted for a task and not revoked, logs are enabled without rotation, backups are put where it is faster, and keys where they are easier to retrieve during an incident. Access control and personal data protection remain at the level of verbal agreements.
What auditors check is not the existence of a policy but reproducibility: whether the immutability of the log for the required period can be proven, whether a backup can be restored without access to the production environment, whether access is revoked on the day an employee leaves.
We explain how this is addressed — from the role model and encryption to retention periods and key control.
What a well-built data protection perimeter delivers in practice
Compliance with 152-FZ is not a folder of policies but properties of the infrastructure that are verified in numbers. Below is what exactly changes when the data protection perimeter is assembled.
Encryption: where the leak channel is closed
Data is encrypted in three states: on disk, in backups, and in transit between services.
Keys are stored in a separate vault with rotation, services—not people—get access to them by role; the share of data under encryption is brought to 100%, and a database copy that ends up where it should not be remains a useless set of blocks.
Logging: what the evidence base is built from
Access events, permission changes, and operations with personal data are written to an immutable log: subject, time, object, result.
Log retention is set by policy, not by whether someone manually cleaned a disk — a query for a specific person or period is assembled in minutes, and log volume grows predictably.
Access control is described by roles and confirmed by regular reconciliation: a report on who has which rights is assembled in hours instead of weeks of manually going through systems.
Recovery after a failure follows a tested scenario — service restoration time is measured in tens of minutes, and the failure class “a backup exists but cannot be restored” is eliminated after drills on a separate environment.
Encryption and storage modes: comparing approaches
The choice of encryption mode determines not the strength of the algorithm but the trust boundary: where the key is stored and who is allowed to access it. Below are four options to choose between when processing personal data.
| Option | When it fits | Limitations |
|---|---|---|
| Application-side encryption | Data goes to external storage or a shared database | The key lives in the service: a code error exposes data, and searching by fields becomes more complex |
| Disk encryption | Protection of media and backups | While the system is running, reads are transparent — rights and logs remain the boundary |
| Dedicated key vault | Rotation, roles, and an audit trail for every operation | A call on the read path: unavailability of the key service stops processing |
| Separate environment for sensitive data | Residency and a narrow circle of administrators are required | Two environments, two sets of updates, separate accounts |
Where to store keys and who manages them
Keys are not kept in a repository, environment variables, or next to the data itself. The master key is stored in a dedicated vault, the service receives a short-lived key for the duration of an operation, rotation follows a schedule, and every issuance is logged.
Key management rights are separated from data processing rights: a support engineer cannot export the master key.
Separating data by sensitivity levels
Sensitivity level determines the encryption mode, retention period, and access scope.
Anonymized analytics remain in the shared environment, personal data — in application-side encrypted storage, and the most sensitive datasets are moved to a separate environment with residency in the required territory. This way the mode is tightened selectively, without rebuilding the entire storage.
Implementing 152-FZ compliance: stages of engineering work
The work sequence is structured so that each step relies on the previous one: without a data map, access control and logging remain a formality. That is why we start with inventory and finish by verifying that the measures actually work, not merely are described in documents.
Inventory: data and flow map
We assemble a register: which categories of personal data are processed, in which systems they reside, through which services they are transmitted, and who has access and on what basis.
The result is a flow diagram with points of recording, reading, and export to external services, indicating retention periods for each dataset.
- Data and flow inventory — register of systems, data categories, and transfer points.
- Placement diagram and encryption — where data physically resides, encryption at rest and in transit, and key handling procedures.
- Access control — roles based on least privilege, separate service accounts, and access revocation upon termination.
- Logging setup — personal data access events to a separate storage protected against editing and deletion.
- Recovery scenario verification — training deployment from a backup to a clean environment according to an individual calculation. Incident response procedure — who does what and by when during an incident, to whom and how they report; transfer of documentation to your team.
Verification: how we make sure the measures work
We verify through actions, not paperwork: we run deletion of a specific person’s data and check that it disappeared from all systems; we try to gain access outside the assigned role and make sure the denial is recorded in the log; we restore a copy and verify integrity. A failed scenario means the measure has not yet been implemented.
Access policies, encryption schemes, and logging procedures
Procedures are what remains with the customer after implementation: not a configured server but written procedures by which an auditor sees that access, encryption, and logging are managed rather than having formed spontaneously.
Below is the set of artifacts that we hand over as part of the project: each one covers its own clause of 152-FZ and GDPR.
Access matrix and service accounts
- Role and permission matrix: which employees and contractors have access to which systems and data — with justification for each role.
- Access policy: single sign-on, two-factor authentication, least-privilege rights, and the procedure for approval and revocation when a role changes or an employee leaves.
- Service accounts: for each one — owner, purpose, lifetime, secret storage in a secure vault, and prohibition of password login.
- Personal data flow diagram and encryption key storage policy: where data resides, where it is processed, who can use a key, and how often it is rotated.
Logs: composition, retention periods, protection against modification
- Log rules and retention periods: the list of events that must be recorded, retention period, and rotation procedure.
- Protection against modification: append-only storage, separate read and write permissions, integrity control, and moving logs to a separate environment.
- Incident response procedure: detection, classification, deadlines for notifying the regulator and data subjects, root cause analysis, and correction of access rights.
We coordinate the set with your information security department and bring it into a form suitable for internal audit.
Case study: closed audit findings on personal data protection
The customer is a service with personal data of tens of thousands of users. Before a scheduled regulator audit, internal audit found a discrepancy between the access policy and how rights were granted in practice.
The implementation case began with an inventory of accounts, not with purchasing new security tools.
What it was before: bottlenecks
Accounts were created manually in different systems, rights accumulated along with role changes: some administrators retained full access after moving to another team.
The access report took two weeks to assemble — exports from several systems were consolidated in a spreadsheet, and by the time it was approved, it was partially outdated.
Backups were not encrypted everywhere: some copies with personal data resided in shared storage, access to which was broader than the circle of authorized persons. Logs were kept, but not consolidated in one place, so it was impossible to reconstruct who read a specific record.
What it became after: measurable shifts
Accounts were moved to Keycloak as a single source of roles: we grant rights per role and for a limited term, not “just in case.” Excessive rights were reduced for 68% of accounts, and closing access upon termination or transfer takes hours instead of weeks.
The access report is assembled in 10 minutes with a single export — you can see who has which rights and on what basis.
Backup protection is covered by source-side encryption, keys are moved to a separate vault, and access logs are consolidated in a shared environment with immutable retention period.
The audit was passed without findings on access and backup protection; a planned list of improvements remains, which we close through the normal support process.
What to do if the infrastructure is already deployed?
There is no need to rebuild a working environment entirely: most 152-FZ requirements are covered by an overlay.
Encryption of channels and media, role separation, logging of personal data operations, and their retention procedure are enabled on top of existing services, without rewriting applications.
Phased implementation begins with inventory: where data physically resides, which services and external exchanges access it, and who has direct access to the DBMS and backups.
Then priority is by risk — first, storage with the largest volume of records and external integrations are isolated.
In parts, you will have to change the authentication scheme, network segmentation, and key handling. A transition period helps here: the new environment is raised alongside the old one, services are migrated in groups, and legacy accounts live until rights are fully transferred.
Secrets and key rotation are handled by HashiCorp Vault — services gain access through short-lived credentials instead of static connection strings in configuration, and a leaked settings file no longer opens the database.
Minimization of changes is achieved because applications remain untouched: the access layer changes, so the transition happens without stopping services.
Sessions are not reset, rights are granted in groups, and every change is recorded in the log — the auditor sees who gained access, when, and to which records.
Technical doubts: encryption, logs, access
Before starting a 152-FZ project, the same questions come up: will services have to be rewritten, where keys are stored, what to do with data outside the perimeter, and how to maintain compliance during changes. Below are answers so you can compare them with your architecture.
Will services have to be rewritten?
No. Compliance is built in layers around the application: storage and channel encryption, access control, logging. Logic only needs to be rewritten where personal data ends up in logs or cache in clear text.
Who owns the keys?
Keys remain in your environment: we configure their management but do not become the holder. Rotation on a schedule and separation of roles — no single person can decrypt and grant access. We document responsibility boundaries in writing, including contractor verification.
What to do with data outside the perimeter?
Backups, exports, external integrations, work laptops — the most common leak point. For each one we determine: whether it is needed, whether the data can be anonymized, where it is stored, and when it is deleted.
How to maintain compliance during changes?
Compliance is a process, not a one-time audit. The infrastructure is described as configuration, so access rules, encryption, and log retention periods are applied to new services automatically, and changes are verified before rollout.
Let's discuss the task: what to send for a perimeter assessment
To come back with a work estimate and implementation plan rather than general wording, we need a minimum set of source data.
The more precise the inputs, the fewer assumptions in the estimate and the more realistic the stage timelines: changes in the middle of a project are more expensive than half an hour spent reviewing the diagram at the start.
- Diagram of services and data flows: where records are stored, where copies and exports go, whether there are backup sites and transfer outside the perimeter.
- List of processed data and categories of data subjects: ordinary personal data, special categories, anonymized datasets — this determines the scope of encryption and how consents are handled.
- Current access policies and role model: how rights are granted, who has elevated privileges, and whether shared accounts without personal accountability remain.
- Log composition: which events are already recorded, where they are stored, how long they are retained, and whether they are protected against retroactive modification.
- Requirements of auditors or internal audit: an order, a list of findings, a questionnaire — we set stage priorities based on them.
- Constraints: maintenance windows, release freezes, and requirements for data placement in the country.
A complete package is not required at the start — send what you have, including drafts and exports in any form. We suggest a call on the task: during the conversation we will review the gaps and agree on what to collect additionally.
Based on the results, we will come back with a work estimate, implementation plan, and stage timelines.