AEPD Resolution: EXP202406965

Based on Resolution EXP202406965, here is the comprehensive compliance protocol for any organisation that manages customer accounts, authentication systems, or password resets:

1. NEVER Send Passwords Via Email—Full Stop

This is the most fundamental rule established by this case, and it brooks no exceptions.

Legal Reality: The AEPD, citing guidance from Spain's National Cryptologic Centre (CNN-CERT), confirmed that email—even with TLS encryption—is inherently unsuitable for transmitting authentication credentials. This is because:

• Email protocols (SMTP) were designed in 1982 without security considerations
• Messages pass through multiple intermediate servers where administrators can access contents
• Transport-layer encryption (STARTTLS, TLS) only protects the connection between servers, not the message content at rest
• Email accounts are frequent targets of compromise
• Users often access email over insecure networks or devices

Action: Implement an absolute organisational policy: "Authentication credentials (passwords, PINs, security codes, API keys, access tokens) shall NEVER be transmitted via email under any circumstances." Train all IT staff, customer service representatives, and developers on this rule. Configure automated systems to prevent credential transmission via email.

2. Secure Alternatives to Email for Password Distribution

If you cannot use email, what should you use?

Best Practice Methods (In Order of Security):

Option 1: Password Reset Links (Recommended)

• Send an email containing only a time-limited, single-use password reset link
• Link expires within 15-60 minutes
• Upon clicking, user is directed to secure HTTPS page where they create their own new password
• System never knows or transmits the actual password—only the user sees it

Option 2: Secure Customer Portal with Authentication

• User logs into existing secure portal using current credentials
• Within the portal, user can view or reset their password
• Requires multi-factor authentication before displaying sensitive data

Option 3: SMS One-Time Codes (With Caveats)

• Send a temporary numeric code via SMS
• Code is valid for 10-15 minutes only
• User enters code on secure website and then creates permanent password
• Note: SMS is vulnerable to SIM swap attacks, so this should not be the only option for high-security contexts

Option 4: In-Person or Phone Verification

• For highly sensitive accounts, require users to verify identity by phone or in person
• Provide temporary credentials only after confirming identity through multiple factors
• Temporary credentials expire within 24 hours and force immediate password change

What NOT to Do:

• Do NOT email username and password together
• Do NOT email passwords in PDF attachments (PDFs can be forwarded and are not inherently secure)
• Do NOT use "password-protected" email attachments (the password inevitably gets sent separately by email, defeating the purpose)

3. Implement Automated Controls to Prevent Human Error

Free Technologies' "human error" defence failed because they had no systems to prevent such errors.

Technical Safeguards:

Email Content Filtering:

• Configure email gateways to scan outgoing messages for patterns matching passwords, PINs, or credential formats
• Block or quarantine emails containing phrases like "your password is," "username and password," "login credentials"
• Alert security team when potential credential disclosures are detected

Template Lockdown:

• All customer communication templates (password resets, account notifications, etc.) must be reviewed and approved by security team
• Templates should be locked in CRM/email systems to prevent ad-hoc modifications by customer service staff
• Use variable placeholders for personalisation, never allow free-text credential insertion

Developer Code Reviews:

• Any code that sends automated emails must undergo mandatory security review
• Implement automated code scanning to detect email functions that include password variables
• Require senior developer sign-off for any credential-related communications

Action: If Free Technologies had implemented email content filtering, an employee attempting to send the plaintext password would have been automatically blocked and alerted to use the secure password reset link instead.

4. Password Reset Procedures Must Be Secure by Design

Free Technologies unilaterally changed a customer's password without notice and emailed the new password. This is wrong on multiple levels.

Secure Password Reset Protocol:

Step 1: User-Initiated Reset Only

• Password resets should only occur when the user explicitly requests them
• Exception: Security-related forced resets (breach detected, suspicious activity) require advance notice and explanation

Step 2: Multi-Factor Identity Verification

• Before allowing password reset, verify user identity through:
  • Email verification (send code to registered email)
  • SMS verification (send code to registered mobile)
  • Security questions
  • Account-specific knowledge (last invoice amount, recent transaction details)

Step 3: Secure Reset Link Delivery

• Send time-limited (15-30 minute), single-use reset link to verified email/SMS
• Link must be HTTPS with certificate pinning
• Link should include random token (not predictable sequence)

Step 4: User Creates New Password

• User clicks link, lands on secure page, creates their own new password
• System validates password strength (minimum 12 characters, complexity requirements)
• System forces user to confirm password by re-entering

Step 5: Confirmation and Security Notifications

• Send confirmation email: "Your password was successfully reset on [date/time] from IP address [X]. If you did not request this, click here immediately."
• Log the reset event with timestamp, IP address, user agent
• Optional: Temporarily lock account and require additional verification if reset occurs from unusual location or device

Action: NEVER allow customer service staff or administrators to view, create, or transmit passwords on behalf of users. Passwords should be system-generated hashes that only the user ever sees.

5. Two-Factor Authentication (2FA) Is Mandatory for Sensitive Portals

The customer explicitly noted that the portal lacked multi-factor authentication, amplifying the risk of the plaintext password email.

Legal Requirement: Whilst Article 32 GDPR does not explicitly mandate 2FA, the AEPD's ruling makes clear that for portals containing extensive personal and financial data (addresses, DNI numbers, bank details, call logs), username/password alone is inadequate security.

Implement 2FA Immediately For:

• Customer portals containing personal data, financial information, or account management functions
• Administrative backends and employee systems
• Any system accessible from the public internet

2FA Methods (In Order of Security):

1. Hardware Security Keys (FIDO2/WebAuthn)—most secure, phishing-resistant
2. Authenticator Apps (Google Authenticator, Authy, Microsoft Authenticator)—secure, offline-capable
3. SMS Codes—weakest but better than nothing (vulnerable to SIM swap attacks)

Action: Free Technologies should have implemented 2FA before migrating customers to the new portal. The combination of emailed passwords + no 2FA created a perfect storm of vulnerability.

6. The "Human Error" Defence Does Not Work

Free Technologies repeatedly claimed this was a one-time human mistake. The AEPD rejected this entirely.

AEPD Position: Article 32 GDPR requires organisations to implement measures precisely to prevent human error. If your security depends on employees never making mistakes, your security is inadequate.

Organisational Measures Required:

• Written Policies: Documented procedures for password resets, credential management, and secure communications
• Staff Training: Annual mandatory cybersecurity training for all employees with access to customer data
• Access Controls: Restrict who can perform password resets or access authentication systems (principle of least privilege)
• Audit Trails: Log all password resets, credential accesses, and security-related actions with timestamps and user IDs
• Regular Reviews: Quarterly audits of security procedures and incident reports
• Penetration Testing: Annual third-party security assessments

Action: Document your security measures and prove they are actually implemented through training records, access logs, and audit reports. The AEPD will not accept claims of "we have good security" without evidence.

7. The "No Harm" Argument Is Irrelevant

Free Technologies argued that because no unauthorised access occurred, no violation should be found. The AEPD rejected this comprehensively.

Legal Principle: Article 32 GDPR is violated when adequate security measures are absent, regardless of whether a breach is exploited. The law is preventive, not reactive.

Analogy: It's like arguing "I drove drunk but didn't crash, so I shouldn't be fined." The violation is driving whilst impaired (inadequate security), not necessarily causing an accident (actual data breach).

Action: Do not wait until a data breach occurs to implement security measures. The legal obligation is to prevent breaches through proactive security, not merely respond after damage is done.

8. Email Security Measures Are Not Enough

Free Technologies listed various email security technologies (TLS, encryption, access controls) as evidence of compliance. The AEPD was unmoved.

AEPD Analysis: The regulator cited the National Cryptologic Centre's technical guidance explaining that:

• TLS/STARTTLS only encrypts the connection between mail servers, not the message content once it arrives at the destination
• STARTTLS is vulnerable to downgrade attacks where attackers force unencrypted transmission
• S/MIME or PGP encryption (if used) requires both sender and receiver to have compatible systems and exchange keys—rarely practical for mass customer communications
• Even encrypted email passes through intermediate servers where administrators can access decrypted contents

Conclusion: No amount of email security makes it appropriate for transmitting passwords. Use secure password reset links instead.

9. Incident Response Must Be Immediate and Comprehensive

To Free Technologies' credit, they responded within 24 hours of the customer's complaint. However, this was reactive, not proactive.

Proper Incident Response Protocol:

Within 24 Hours:

• Acknowledge the incident internally
• Reset affected customer's password immediately
• Audit logs to determine if credentials were accessed by unauthorized parties
• Notify the customer with apology and explanation

Within 72 Hours:

• Conduct root cause analysis: Why did this happen? Which procedures failed?
• Implement immediate corrective measures
• Assess whether this is a notifiable data breach under Article 33 GDPR (requires notification to AEPD within 72 hours if significant risk to rights and freedoms)

Within 30 Days:

• Update procedures and training materials
• Implement technical controls to prevent recurrence
• Document all actions taken for regulatory compliance records

Action: Free Technologies' response was reasonably quick, which likely reduced the fine. However, their lack of proactive monitoring meant they only discovered the problem when a customer complained.

10. Proportionality and Sanction Calculation

The AEPD imposed a €10,000 fine for a company with €19.5 million annual revenue—approximately 0.05% of turnover.

Why This Amount?

Aggravating Factors:

• Serious negligence (sending passwords in plaintext violates basic security principles known for decades)
• Highly sensitive data category (authentication credentials protecting extensive personal and financial data)
• High-risk sector (telecommunications operators process massive volumes of personal data)

Mitigating Factors:

• Only one customer affected (though the systemic failure could have impacted thousands if not caught)
• Quick remedial action and apology
• No prior violations
• Cooperative with AEPD investigation

Alternative Sanctions Considered:

• Maximum theoretical fine: €389,750 (2% of €19.5M annual turnover under Article 83.4 GDPR)
• Typical range for Article 32 violations: €5,000 - €50,000 for SMEs
• This case: €10,000 (low-to-moderate, reflecting mitigation)

Lessons: The fine was significant enough to be "effective, proportionate, and dissuasive" (Article 83.1 GDPR) but not crippling. However, companies with worse facts (multiple affected customers, prior violations, delayed response, non-cooperation) could face fines 10-20 times higher.

Summary of Business Risk

This case establishes that emailing passwords in plaintext is a per se violation of Article 32 GDPR, regardless of email encryption technologies, lack of actual harm, or claims of "human error." Telecommunications companies and any organisation managing customer portals must implement secure password reset protocols using time-limited links, prohibit credential transmission via email through technical controls, and deploy two-factor authentication for portals containing sensitive personal data. The AEPD's rejection of the "human error" and "no harm" defences signals that Article 32 GDPR imposes strict liability for inadequate security measures—companies cannot escape sanctions by claiming employees made isolated mistakes or that breaches were not exploited. Fines for security violations start at €10,000 for single-customer incidents and scale dramatically with the number of affected individuals and severity of negligence.