5 Security Mistakes When Sharing Sensitive Information

A few years ago, a Fortune 500 company's AWS credentials leaked because a developer pasted them into a Slack DM. The message was deleted within minutes. It didn't matter. Slack's search index had already captured it. Three contractors who left the company months ago still had access to the workspace. One of them sold the credentials on a dark web forum.

The cost? $2.3 million in unauthorized cloud usage before the breach was detected.

This isn't an isolated incident. It's a pattern. Teams share sensitive information dozens of times a day — API keys, passwords, contracts, financial records — and they do it in ways that create permanent security exposures.

This guide breaks down the five most common (and most dangerous) security mistakes when sharing sensitive data, explains why they're risky, and shows you safer alternatives.

Mistake #1: Sending Credentials Over Slack or Teams

What Happens

You need to share a database password with a teammate. You open Slack and send it in a direct message. Maybe you add "delete after reading" in parentheses. Your teammate reacts with a thumbs-up. Done.

Here's what actually happened:

1. The password is now stored on Slack's servers indefinitely
2. It's indexed in Slack's search (try searching "password" in your workspace)
3. It's synced to every device where Slack is logged in
4. It's potentially accessible to Slack admins, bots, and integrations
5. Even if you delete the message, it persists in logs and backups
6. Anyone with workspace access can potentially find it via search

Why This Is Dangerous

Persistence: Slack and Teams are built for permanent message history. That's a feature for work conversations. It's a liability for secrets.

Access creep: Over time, your workspace accumulates members:

• Employees who left (but weren't removed promptly)
• Contractors whose access wasn't revoked
• Third-party bots with broad permissions

Any of them can search message history and find credentials shared months ago.

Real-world example: A healthcare startup shared database credentials via Slack. Two years later, during a routine security audit, they discovered the credentials were still searchable. By then, 37 people (including former employees) had access to the workspace. The credentials had never been rotated.

The Safe Alternative

For immediate, one-time credential sharing:

• Use a burn-after-reading tool like Konfidant
• Send a single-use link that expires after access
• The credential is encrypted and deleted after delivery
• No search index, no persistence, no lingering copies

For long-term shared credentials:

• Use a proper secrets manager (1Password, Bitwarden, AWS Secrets Manager)
• Grant access via groups, not individual shares
• Enable MFA and audit logs

Rule: If it's sensitive enough to need a password, it's too sensitive for Slack.

Mistake #2: Emailing Sensitive Files Without Encryption

What Happens

You need to send a signed contract, employee W-2, or financial spreadsheet. You attach it to an email and hit send. Maybe you mark it "confidential" in the subject line.

Here's what actually happened:

1. The email is stored in your Sent folder
2. The email is stored in the recipient's Inbox
3. The email passes through multiple mail servers (yours, the recipient's, any intermediate relays)
4. The email may be backed up by email archival systems
5. If either party uses email forwarding (to personal Gmail, for example), copies exist there too
6. Email attachments are not encrypted at rest on most mail servers

Why This Is Dangerous

Email is designed for persistence, not privacy.

Forwarding: Once you hit send, you lose control. The recipient can forward to anyone. You'll never know.

Breach exposure: Email accounts are prime phishing targets. If the recipient's account is compromised, every email attachment is exposed.

Compliance violations: Emailing unencrypted PII or PHI often violates GDPR, HIPAA, and SOC 2 requirements.

Real-world example: A law firm emailed a settlement agreement with Social Security numbers to opposing counsel. The opposing counsel's paralegal had email forwarding set up to a personal Yahoo account (policy violation, but convenient). Six months later, the Yahoo account was breached via a phishing attack. The settlement agreement, containing PII for 14 plaintiffs, was exposed.

The Safe Alternative

For confidential documents:

• Use end-to-end encrypted file sharing with time-limited access
• Services like Konfidant encrypt files client-side before upload
• Send a secure link (not an attachment)
• Set expiration policies (e.g., delete after 7 days or first download)

For ongoing collaboration:

• Use Google Drive or OneDrive with access controls
• Grant view/edit permissions only to specific people
• Set expiration dates for shared links
• Enable audit logs to track access

For compliance-critical files (PII, PHI):

• Use services with verified encryption and audit trails
• Ensure data residency matches your regulatory requirements (EU for GDPR, etc.)
• Get a Data Processing Agreement (DPA) or Business Associate Agreement (BAA) from your provider

Rule: If you wouldn't want it published on your company blog, don't email it unencrypted.

Mistake #3: Using Public Link Sharing Without Expiration or Access Controls

What Happens

You upload a file to Dropbox or Google Drive and click "Get shareable link." You send the link to your colleague. The file transfer works perfectly.

Here's what actually happened:

1. You created a link that works forever (no expiration)
2. The link has no access controls (anyone with the link can access it)
3. Your colleague can forward the link to anyone
4. If the link is leaked, posted publicly, or indexed by Google, anyone on the internet can access the file
5. You have zero visibility into who accessed the file after the first person

Why This Is Dangerous

No expiration: Links remain active indefinitely. That file you shared for a 2-day project? Still accessible six months later.

No forwarding control: Your recipient forwards the link to a contractor. The contractor forwards it to their team. Now 10 people have access. You don't know any of them.

Accidental leaks: Public links get pasted into the wrong channels:

• Posted in public Slack channels instead of DMs
• Shared in GitHub issues or pull requests
• Accidentally included in email signatures or footers

Real-world example: A startup shared a pre-launch product roadmap via a public Google Drive link. An employee accidentally pasted the link into a public Discord server instead of a private channel. The roadmap was indexed by Google within hours. Competitors found it via search before the employee realized the mistake.

The Safe Alternative

Set expiration dates:

• Most services allow time-limited links (e.g., "expires in 7 days")
• Use the shortest expiration that works for your use case
• For immediate delivery, use single-use links (expire after first download)

Enable access controls:

• Passphrase protection: Require a password to access the file
• Email verification: Require the recipient to confirm their email
• Domain restrictions: Allow only users from specific domains (e.g., @yourcompany.com)

Use private sharing:

• Grant access to specific email addresses instead of creating public links
• Revoke access when the recipient no longer needs it

Monitor access:

• Enable audit logs to see who accessed the file and when
• Set up alerts for unusual access patterns (e.g., file accessed from a new country)

Rule: Every public link should have an expiration date. If it doesn't need to be public, make it private.

Mistake #4: Reusing Credentials Instead of Rotating Them

What Happens

You generate an API key for a third-party integration. You share it with your team. Months later, a contractor needs access. Someone digs up the old API key from Slack or email and sends it to the contractor. The contractor uses it for their project. The project ends. Nobody rotates the key.

Here's what actually happened:

1. The same credential is now known by multiple people across multiple time periods
2. You've lost track of who has it
3. If the credential leaks, you can't determine when or how it leaked
4. The credential has been shared via multiple channels (Slack, email, maybe even a Google Doc)
5. Revoking the key now breaks access for everyone, so it never gets rotated

Why This Is Dangerous

Blast radius grows over time: The more people who have a credential, the higher the chance it leaks.

No audit trail: You can't trace when or how the credential was shared, making incident response difficult.

Key sprawl: Organizations accumulate hundreds of long-lived keys. Nobody remembers what they're for or who has access.

Real-world example: A SaaS company had a production database password shared across 12 team members over 3 years. When they finally ran a security audit, they discovered the password had been pasted into:

• 5 Slack threads
• 3 email threads
• 2 Google Docs
• 1 Notion page
• 1 Jira ticket

Nobody had rotated it because "too many things depend on it." During a breach investigation, they couldn't determine how the attacker obtained the password.

The Safe Alternative

Generate unique, time-limited credentials:

• For temporary access (contractors, one-time tasks), create short-lived credentials that expire automatically
• Use tools that support temporary tokens (AWS STS, OAuth access tokens with refresh limits)

Rotate credentials regularly:

• Set rotation schedules (monthly, quarterly) for long-lived credentials
• Automate rotation where possible (AWS Secrets Manager, HashiCorp Vault)
• Track which credentials are in use and which are stale

Use scoped credentials:

• Instead of sharing admin-level keys, create least-privilege credentials specific to the task
• Revoke access immediately when the task is done

Audit who has what:

• Maintain a registry of active credentials and who has access
• Review quarterly and revoke access for people who left or changed roles

Share credentials once, then destroy the share:

• Use burn-after-reading tools for one-time credential delivery
• Ensures the credential is accessed once, then the share is deleted
• No persistent copies in chat or email

Rule: Every credential share should have a rotation plan. If you can't rotate it, restrict who has access.

Mistake #5: Ignoring Audit Trails and Compliance Requirements

What Happens

You share a file containing customer PII or protected health information (PHI). You send it via whatever's convenient — Slack, email, Dropbox. The recipient downloads it. Done.

Here's what actually happened:

1. You have no record of when the file was shared
2. You have no record of who accessed it
3. You have no record of when it was deleted (if ever)
4. If asked during a compliance audit, you can't prove:
   • The file was delivered securely
   • Access was limited to authorized users
   • The file was deleted after use

Why This Is Dangerous

Compliance violations: Regulations like GDPR, HIPAA, and SOC 2 require audit trails for sensitive data:

• GDPR Article 30: Requires records of processing activities
• HIPAA Security Rule: Requires audit controls and access logs
• SOC 2: Requires monitoring and logging of data access

No incident response capability: If a breach occurs, you can't determine:

• What data was exposed
• When it was accessed
• Who had access

Legal liability: During litigation or regulatory investigations, missing audit trails are red flags. Courts and regulators interpret lack of logs as negligence.

Real-world example: A healthcare provider was fined $4.3 million for HIPAA violations. The violation? They shared patient records via unencrypted email and couldn't produce audit logs showing who accessed the files. The lack of logs made it impossible to determine the scope of the breach, leading to maximum penalties.

The Safe Alternative

Use tools with built-in audit logging:

• Track when files are uploaded, accessed, and deleted
• Log recipient IP addresses and user agents
• Record access attempts (successful and failed)

Enable compliance features:

• Verified deletion: Cryptographic proof that files were deleted
• Immutable logs: Audit trails that can't be tampered with
• Data residency: Store data in regions that match your compliance requirements (EU, US, etc.)

Document your data handling procedures:

• Create policies for how sensitive data should be shared
• Train employees on compliance requirements
• Conduct regular audits to verify adherence

Get the right legal agreements:

• DPA (Data Processing Agreement): Required for GDPR
• BAA (Business Associate Agreement): Required for HIPAA
• Ensure your file sharing service provides these

Rule: If it's regulated data (PII, PHI, financial records), use a service with audit trails. If you can't prove you handled it securely, you didn't.

Bonus Mistake: Assuming Deletion Means Gone

What Happens

You share a sensitive file. Later, you decide to delete it. You click "delete" in your file sharing service. You assume it's gone.

Here's what actually happened:

1. The file is marked as deleted in the UI, but may still exist in:
   • Backups (often retained for 30-90 days)
   • Server caches
   • Recipient downloads (local copies)
2. If the file was shared via email or Slack, deletion doesn't affect copies in recipient inboxes or message history
3. Some services offer "soft delete" (file moved to trash, not actually removed)

Why This Is Dangerous

False sense of security: You think the file is gone, but it's still accessible via backups or recipient copies.

Compliance gaps: GDPR "right to erasure" requires permanent deletion, not just UI removal.

The Safe Alternative

Use services with verified deletion:

• Cryptographic proof that files are permanently destroyed
• Immediate deletion (not soft delete or trash)

Use ephemeral sharing from the start:

• Files that auto-delete after delivery don't require manual deletion
• Expiration policies enforce data minimization automatically

Educate recipients:

• Remind recipients to delete local copies after use
• For maximum security, use passphrase protection or SMS verification to prevent unauthorized downloads

Rule: Don't share files expecting to delete them later. Share them with auto-expiration from the start.

How to Fix These Mistakes Right Now

Immediate Actions (Today)

1. Audit your Slack and email:

   • Search for "password", "key", "secret", "token", "credentials"
   • Rotate any credentials you find
   • Delete the messages (but assume they may still exist in backups)

2. Check your public file shares:

   • Review Dropbox, Google Drive, OneDrive shared links
   • Set expiration dates on active shares
   • Revoke links that are no longer needed

3. Identify your riskiest data:

   • List what you share regularly: credentials, contracts, PII, PHI
   • Flag which items are shared insecurely (Slack, email, public links)

This Week

1. Choose secure sharing tools:

   • Credentials: Burn-after-reading tool (Konfidant) or secrets manager (1Password)
   • Files: Encrypted file sharing with audit logs (Konfidant, Tresorit)

2. Set team policies:

   • Document what should never be shared via Slack or email
   • Define expiration policies (max 7 days for contracts, max 24 hours for credentials)
   • Require access controls (passphrases, email verification)

3. Train your team:

   • Show them how to use the new tools
   • Explain why Slack and email are insecure for sensitive data
   • Make the secure option easier than the insecure one

This Month

1. Rotate all long-lived credentials:

   • API keys, database passwords, service account tokens
   • Set up automated rotation where possible

2. Enable audit logging:

   • Turn on logs for file sharing services
   • Review logs monthly for unusual access patterns

3. Conduct a compliance review:

   • Verify you have DPAs/BAAs for all services handling regulated data
   • Check that data residency matches your requirements
   • Document your data handling procedures for audits

The Bottom Line

Most security breaches don't happen because of sophisticated attacks. They happen because someone pasted a password into Slack. Or emailed an unencrypted file. Or created a public link that never expired.

These mistakes are common, easy to make, and incredibly costly.

The good news? They're also easy to fix. The tools exist. The workflows are straightforward. The only question is whether you'll change the habit before an incident forces you to.

Every time you share sensitive data, you're making a choice:

• Convenience now, or security always?
• Manual cleanup, or automatic expiration?
• Persistent exposure, or ephemeral delivery?

The best teams choose security by default — by using the right tool for the job.

---

Ready to stop making these mistakes? Try Konfidant's secure file sharing →