Romania's data-protection authority has fined Gerocossen SRL 26,236.50 lei, equivalent to EUR 5,000, after a cyberattack led to unauthorized disclosure of or access to identification and contact data. The company notified the incident under GDPR Article 33. The regulator's investigation, completed in July 2026, concluded that appropriate technical and organizational measures had not been implemented for the risk presented by the processing.
The most useful part of the decision is not the size of the fine. The National Supervisory Authority for Personal Data Processing, ANSPDCP, ordered a concrete control: monitor and log access to the relevant IT infrastructure, retain those access logs for at least 30 days and introduce a backup process for them.
What the regulator confirmed
ANSPDCP says an attack against Gerocossen's IT infrastructure resulted in unauthorized disclosure of or access to personal data. The categories named publicly are identification and contact data. The authority found an infringement of GDPR Article 32(1)(b) and 32(2), provisions concerned with confidentiality, integrity and evaluating risks from accidental or unlawful loss, alteration, disclosure or access.
The decision does not publish the number of affected people, the precise data fields, the initial access method, the duration of access or whether all exposed records were exfiltrated. It also does not make EUR 5,000 a standard price for a breach. GDPR penalties depend on the facts of each case, and an attack by itself does not automatically prove that an organization failed Article 32.
Retention has two different jobs
Security teams often hear two instructions that sound contradictory: keep enough evidence to investigate an incident, and minimize the sensitive information they store. The Gerocossen corrective order shows why both can be true. Access logs are evidence about activity. Customer data, passwords, recovery codes and API keys are the material an attacker wants.
A useful access record can identify the account, event, time, source, destination and result without copying the plaintext secret that authorized the action. The retention period for those records should follow legal, security and operational requirements. The secret itself should follow a much shorter lifecycle and should not be duplicated into tickets, chat transcripts, email threads or general-purpose logs.
Log custody, not secret values
A secure transfer workflow needs enough evidence to answer who authorized the handoff, who received it and whether the value was opened or revoked. It should not turn that audit trail into a second database of credentials.
- Classify the value before sending it. A customer address, temporary password and root recovery key need different approval and expiry rules.
- Verify the recipient. Do not use possession of an email address or chat account as the only identity check for high-impact access.
- Keep plaintext out of persistent systems. Tickets and incident rooms should reference a controlled transfer, not contain the secret itself.
- Record metadata deliberately. Log the request, approver, sender, recipient, timestamps and final disposition without logging the value.
- Protect the logs. Restrict read access, detect tampering, back them up and define a justified retention period.
- Expire and revoke. Remove unopened transfers when the task changes, and rotate any credential that may have been exposed.
- Delete redundant source data. Do not preserve exports and attachments merely because the immediate workflow has ended.
Data minimization reduces both impact and investigation noise
The fewer unnecessary copies an organization holds, the smaller the dataset that can be exposed and the clearer the incident scope can become. This does not mean deleting every log. It means separating records needed for accountability from sensitive content that accumulated through convenience.
Teams should be able to explain why each sensitive field exists, which system is its source of truth, who can access it, when it expires and how deletion is verified across backups and vendors. A mailbox or support queue should not become an unofficial archive simply because it was the easiest way to move data.
Where Secretus fits
Secretus can reduce persistent plaintext copies when a team needs to hand off a password, recovery code, API key or small sensitive note. A one-time link and short expiry limit the lifetime of the delivery copy, while the operational record can document custody without storing the value in the conversation history.
Using Secretus does not by itself satisfy GDPR Article 32, determine a lawful retention period or replace access monitoring, backups and incident response. It is one delivery control inside a broader program. The organization remains responsible for the recipient, endpoint, access policy, surrounding metadata and any copy made after decryption.
What remains unknown
ANSPDCP has not published the affected-person count, complete field list, attack vector, dwell time, notification scope or evidence showing how the data was accessed. Those details should remain unknown unless Gerocossen or the authority releases further information.