GDPR/ISO 27001: log and data storage requirements
1) Why it matters
Logs and databases are personal data (IP, cookie-ID, device-ID, user-ID, behavioral events). This means that they are subject to: legality and transparency of processing, limitation of purpose and time, minimization, accuracy, integrity/confidentiality, as well as the rights of subjects (GDPR). ISO 27001 adds management and technical controls: logging policy, monitoring, asset protection, access management, redundancy, cryptography and change management.
2) Legal Basis and Purposes (GDPR)
Logging goals: security, incident investigation, implementation of laws, financial audit, fight against fraud.
Legal grounds:- Legitimate interests - cybersecurity, anti-fraud; do a balance of interest test.
- Legal obligation/contract - accounting, tax reporting, AML/KYC trail.
- Consent - only for analytics/marketing, not for "strictly necessary" security logs.
- Transparency: notify in Privacy Notice, select a separate section about logs/deadlines/categories of recipients.
3) DPIA and risk approach
Conduct DPIA for large-scale behavior monitoring (gaming events, behavioral biometrics, anti-fraud profiles). Describe: goals, scopes, risks, mitigating measures (pseudonymization, access by role, short shelf life, separate storage of keys).
4) Rights of subjects and exceptions
Access/copy: provide information about log categories and periods; Do not expose security signatures.
Correction/limitation/objection: evaluation of request vs need for safety and legal duties.
Deletion: exceptions are allowed if storage is necessary to protect against lawsuits, comply with the law or investigate an incident; Record the decision and the revision period.
5) Retention and minimization
Fix the Retenschen matrix: what, where, why, term, basis, who is the owner, where is alienated.
Principles:- Short deadlines for highly sensitive logs (raw requests with IP/UA, non-aggregated telemetry).
- Aggregation and aliasing for long-term analytics (for example, hash/token instead of IP).
- Automatic deletion/anonymization by timer; prohibition of "perpetual" logs.
- Web server logs (IP, UA, path) - 30-90 days (security/tracing).
- Audit trail of admin actions - 1-3 years (security/compliance).
- Payment transactions (metadata) - 5-10 years (accounting/taxes, local requirements).
- KYC/AML artifacts - by law of jurisdiction (often 5-7 years).
- Antifrod features - 6-24 months. with regular reassessment of necessity.
6) ISO 27001: what is required for logs and monitoring (practice)
Logging and monitoring policy: define events, volumes, levels, responsibilities, storage, analysis, escalations.
Technical controls (logging):- Capture of significant events (authentication/authorization, rights/config changes, data access, critical transactions, admin actions, security errors).
- Time synchronization (NTP, protected source), store time zones and exact labels (milliseconds).
- Integrity protection: WORM stores, immutable indexes, hash chains/signatures, add-only access control.
- Separation of environments and logs (prod/stage/dev), isolation of secrets and PII in logs.
- SIEM/UEBA, event correlation, thresholds and alerts, playbook response.
- Regular log reviews "manually" for critical areas (admin, payments, access to DWH).
- Roles and Responsibilities: Asset Owner, Journal Owner, IS/Compliance Officer, Incident Process.
- Log life cycle: collection → transport (TLS/mTLS) → storage (encryption, storage classes) → analysis → retention/deletion (log the fact of deletion).
7) Data classification and access control
The data classes are Public/Internal/Confidential/Restricted (PII/Finance/KYC).
Masking/Revision Policy: Exclude sensitive fields (PAN, CVV, passwords, tokens).
RBAC/ABAC: minimum required access, separate roles "reading logs" and "management."
Log access logs (metajournals): who, when, what accessed.
8) Cryptography, keys and transport
Transmission encryption: TLS 1. 2+/1. 3, mTLS between agents and collector, certificate validation.
Encryption at rest: disks/object storage, keys in KMS/HSM, key rotation, separate keys for different data classes.
Segmentation: Separate buckets/indexes for PII and for technical logs.
9) Backups, offsite archive and recovery
Backups: schedule, encryption, recovery control (regular DR exercises), overwrite/ransomware protection.
Offsite/multi-region: taking into account the requirements of localization/cross-border transmission (DPA, SCC, adequacy).
Uniform terms: retention in backups should not "zero" the terms of deletions in the sale; automate archive expiration.
10) Transfer to third parties (processors)
DPA with log analytics/cloud/collector providers: roles, sub-processors, storage locations, protection measures, deletion deadlines.
Cross-border transmission: legal mechanisms (SCC, etc.), technical measures (end-to-end encryption, pseudonymization).
Audit and reporting: right to audit, SOC reports/certifications, access logs.
11) About Incidents and Notifications (GDPR)
Detection and fixation: SIEM alerts, incident ticket, freezing of relevant logs (legal hold).
72 hours to notify the regulator in case of significant leakage of personal data; impact assessment, composition of notification, evidence of measures.
Post-mortem: outputs to policy/controls, update reteschen/masking.
12) Typical mistakes and how to avoid them
Log sensitive fields (passwords, tokens, PAN/CVV) → mask at the SDK/wrapper level.
Perpetual technical logs "just in case" → put TTL and anonymization.
Single "super access" to SIEM → separate roles and enable MFA.
Undivided prod/dev logs → post and restrict access.
The lack of a retention matrix and automatic deliters → the risks of GDPR fines and excessive leaks.
Backups without encryption/expiration → "eternal" copies of PII.
13) Retenschen matrix (sample)
14) Logging and storage policy (skeleton)
1. Scope and terms.
2. Log categories and goals.
3. Legal grounds and notice.
4. Classification and minimization.
5. Collection, transport, storage (encryption, integrity, WORM).
6. Access and roles, access auditing.
7. Retention and automatic deletion/anonymization.
8. Transfer to third parties (DPA, SCC).
9. Monitoring, SIEM, alert, reporting.
10. Incidents and notifications (including 72 hours).
11. DR/BCP, backups and recovery.
12. Periodic review (annually/if processes change).
15) Implementation checklist (quick start)
- Take stock of all log sources and PII fields; Enable SDK-level masking.
- Approve the retention matrix and automate TTL/anonymization.
- Configure WORM/immunity for critical logs and hash integrity control.
- mTLS/TLS for agents/collectors; at-rest encryption; keys in KMS, rotation.
- SIEM/UEBA, alerts and playbooks; log access meta logs.
- DPIA for behavioral monitoring/antifraud; LIA для legitimate interests.
- DPA with all processors/clouds; checking the location of data and SCC in cross-border transmission.
- DR exercises for restoring logs and deleting in backups; reporting.
- Update the Privacy Notice (section about logs/deadlines) and internal procedures for processing requests from subjects.
Resume Summary
GDPR requires legality, transparency, minimization and limited timelines, and ISO 27001 requires consistency and provability: policy, roles, technical controls, immutability and monitoring. Form a retention matrix, enter masking and pseudonymization, encrypt transport/storage, use WORM and SIEM, conclude DPA and prepare DPIA - this way the journal trail will remain useful for security and audit, without becoming a source of regulatory and reputational risks.