Personal-data minimization in a proxy service
Russian Federal Law 152-FZ ties processing to specific lawful purposes and rejects excessive collection. Collecting everything just in case is inconsistent with that approach.
Key points in one minute
- Every field needs a purpose and retention period.
- Diagnostic data should not automatically become a permanent profile.
- A data map includes logs, SDKs, backups, and administrator exports.
- Every channel should receive its own minimal DTO.
Data map
List registration, contract, payment, login IP, user agent, support, and proxy-action data. Assign a basis and process owner to each.
The map should cover not only database tables but also forms, APIs, logs, receipts, support attachments, analytics, backups, and administrator exports. For each field record source, recipients, purpose, necessity, retention, and deletion system. Interview process owners because debug logs and third-party SDKs often make actual collection broader than documentation.
Purpose separation
Accounting, security, and marketing have different purposes and timelines. Do not reuse data across purposes without checking the basis.
Separate access by role and system. Accounting staff normally do not need proxy-control technical logs, while support engineers do not need full payment details. Marketing attributes should not be derived automatically from security records. Evaluate any new purpose before UI development, with a responsible person checking the applicable basis and document updates under current requirements.
Minimal interfaces
Client APIs should not expose internal tokens, upstream links, or administrative notes. Exports should contain only user-selected fields.
Define explicit DTOs for customers, administrators, the Telegram bot, and official exports instead of returning one complete model. Exclude upstream tokens, secrets, internal notes, and identifiers unnecessary to the recipient by default. Add contract tests with a canary sensitive field and verify that it never appears in responses, CSV, notifications, or errors.
Deletion and anonymization
When purpose ends, delete data or apply approved anonymization. Backups must follow the same lifecycle policy.
The deletion policy should define the event that starts retention: lease closure, contract end, support resolution, or completion of the stated purpose. Use a bounded backup cycle and prevent routine restoration of deleted data into production; if selective deletion is impossible, document isolation until overwrite. Confirm deletion through metrics and an event log without retaining the removed content.
Practical checklist
- 1Create a field-and-purpose register.
- 2Remove just-in-case collection.
- 3Apply retention to backups.
- 4Test actual collection with a canary field.
- 5Define the trigger for every retention period.
Sources and documentation
This material is based on primary, official, and technical sources. The article is an original summary written for this knowledge base.
This material is for general information only. Requirements should be checked against the current law and, when needed, with a qualified specialist. It is not individual legal advice.