GDPR and Password Sharing — What You Need to Know

The General Data Protection Regulation is often discussed in the context of cookie banners and privacy policies. But GDPR has sharp teeth when it comes to how organisations protect data internally — and credential sharing is one of the areas where many organisations unknowingly fall short.

If your organisation processes personal data and you share credentials to systems that contain that data, GDPR applies directly to how you share those credentials. This page explains what the regulation requires, where organisations commonly fail, and what practical steps you can take to stay compliant. If you first want the fundamentals beyond compliance, start with the complete guide to secure password sharing.

---

Why Credentials Fall Under GDPR

Credentials — usernames and passwords — are not personal data in themselves. But they provide access to personal data. Under GDPR, the obligation to protect personal data extends to protecting the means of accessing it.

Article 32 of the GDPR requires controllers and processors to implement "appropriate technical and organisational measures" to ensure a level of security appropriate to the risk. These measures must account for:

• The state of the art in available technology
• The cost of implementation
• The nature, scope, context, and purposes of processing
• The risks to the rights and freedoms of natural persons

When the "state of the art" includes purpose-built, encrypted, one-time credential sharing tools that cost almost nothing to use, sending a password in plain text over email becomes very difficult to justify as an "appropriate technical measure."

---

Technical Requirements Under Article 32

The regulation specifies four categories of appropriate technical measures in Article 32(1). Each has direct implications for credential sharing:

a) Pseudonymisation and Encryption

Credentials in transit should be encrypted. Sending a password over unencrypted channels — plain-text email, unencrypted chat, SMS — is a straightforward technical failure. At minimum, credentials should be encrypted in transit and at rest.

Stronger implementations — like end-to-end encryption where only the recipient can decrypt the credential — go further and provide stronger compliance evidence.

b) Ongoing Confidentiality, Integrity, and Availability

Systems that contain personal data must maintain ongoing confidentiality. Credentials shared via persistent channels (email threads, chat history, shared documents) undermine confidentiality because they create durable records that can be accessed long after the sharing was intended.

A one-time encrypted link, by contrast, becomes worthless after use. There is no persistent record of the credential value in any inbox, log, or chat archive.

c) Restoration of Availability and Access

This requirement focuses on resilience, but it also highlights the need for controlled access management. If credentials are shared informally and poorly tracked, restoring controlled access after an incident becomes extremely difficult.

d) Regular Testing and Evaluation

GDPR requires ongoing assessment of security measures. Organisations that audit their credential handling practices are better positioned to demonstrate compliance than those that treat it as a one-time checkbox.

---

Organisational Measures: What GDPR Expects

Beyond technical controls, GDPR expects procedural discipline. The supervisory authorities across EU member states have consistently found that security failures stem as much from poor process as from technical gaps.

Written Credential Sharing Policy

You should have a documented policy that specifies:

• Which systems require credentials to be shared securely
• Which methods are approved for sharing credentials
• What to do when a credential is suspected compromised
• Who is responsible for access management

Without a written policy, demonstrating "appropriate organisational measures" to a data protection authority is very difficult. A practical starting point is this guide to writing an SOP for secure password sharing.

Access Control and the Principle of Least Privilege

GDPR's accountability principle (Article 5(2)) requires you to be able to demonstrate that only people with a legitimate need have access to personal data. This means:

• Credentials to personal data systems should not be shared more broadly than necessary
• Shared credentials should be rotated after use or changed when a person's access needs to change
• Access logs should be maintained where possible

Data Processor Agreements

If you share credentials with third parties — contractors, sub-processors, integration partners — Article 28 requires a Data Processing Agreement (DPA). Part of what that agreement should govern is how credentials are handled. If your DPA does not address credential sharing, it is incomplete. This cuts both ways for service providers such as IT companies and hosting companies, which routinely hold credentials to dozens of client systems.

Breach Response Readiness

Under Article 33, you have 72 hours to notify your supervisory authority of a personal data breach once you become aware of it. If credentials were shared in ways that leave no audit trail, determining what was exposed and who had access in the event of a breach becomes extremely difficult — and your breach notification will be correspondingly vague and unsatisfying to regulators.

---

Common Compliance Failures in Credential Sharing

The following scenarios represent typical patterns that supervisory authorities have cited in enforcement actions and guidance documents:

Scenario 1: Email archives as credential stores A company emails database credentials to a contractor. Two years later, the contractor's email account is compromised. The attacker searches for "password" in the inbox and finds dozens of valid credentials. The company has no way of knowing which systems are now at risk.

Scenario 2: Shared spreadsheets with team passwords A support team maintains a shared Google Sheet with login credentials for client systems. One team member's Google account is compromised. The attacker exports the sheet. The company cannot determine when the exposure started, cannot easily identify which clients are affected, and cannot notify them accurately within 72 hours.

Scenario 3: Chat logs as credential archives An IT company pastes a server password into a Slack channel for a colleague. The credential is never removed. A year later, Slack's eDiscovery is used in a legal dispute, and the credential is visible in the export.

In each case, the root failure is using the wrong tool — a tool designed for general communication rather than secure credential transmission.

---

The One-Time Link Approach and GDPR Compliance

One-time encrypted sharing links address the core GDPR concerns around credential sharing:

---

Practical GDPR Compliance Checklist for Credential Sharing

Use this checklist to assess your current practices:

• [ ] We have a documented policy for sharing credentials to systems that contain personal data
• [ ] We use encrypted, one-time channels for sharing credentials (not plain-text email or chat)
• [ ] Credentials to personal data systems are not stored in shared documents, spreadsheets, or persistent chat channels
• [ ] We rotate credentials after they have been shared with temporary or external parties
• [ ] We have Data Processing Agreements in place with all third parties who receive credentials to our systems
• [ ] We maintain logs of who has access to which systems
• [ ] We have a breach response procedure that includes identifying which credentials may have been exposed
• [ ] Our security practices are reviewed at least annually

For a broader version that covers multiple frameworks, see the compliance checklist for password sharing.

---

Fines and Enforcement: The Real Stakes

GDPR fines are tiered. Violations of Article 32 (security of processing) fall under the lower tier but can still reach €10 million or 2% of global annual turnover — whichever is higher. For most organisations, the practical risk is not a fine in isolation but the investigation that accompanies it: audits, remediation requirements, reputational damage, and client notification obligations.

The Dutch Autoriteit Persoonsgegevens, the German Datenschutzbehörden, and the Irish Data Protection Commission have all published guidance indicating that weak credential management is a security failure. Sending passwords via plain-text email has been explicitly cited as an inadequate measure.

---

Where PassTransfer Fits

PassTransfer is built around the properties that GDPR's Article 32 points toward: encryption, one-time access, automatic deletion, and no persistent storage of plaintext credentials. Credentials are encrypted before storage, served once, and then deleted.

For organisations that handle personal data as part of their work — which is almost every business — using PassTransfer for credential sharing is a practical, low-cost step toward demonstrable compliance.

PassTransfer Pro extends this with branded subdomains, making credential sharing look professional and trustworthy to clients and partners. A custom subdomain at your own domain signals that you take security seriously — which is exactly the message you want to send to clients whose data you are responsible for protecting.

---

Summary

GDPR does not just regulate what data you collect and how long you keep it. It governs how you protect access to that data — including how you share the credentials that provide that access. Plain-text email, chat, and shared documents fail the test. Encrypted, one-time credential sharing tools pass it.

The compliance path is clear: establish a written policy, use the right tools, maintain audit readiness, and review your practices regularly. The cost of doing this correctly is low. The cost of a breach and a subsequent Article 32 investigation is not.

If your organisation also falls under the NIS2 directive, its access-management requirements complement GDPR's data protection rules — see NIS2 and secure password sharing for that side of the picture.