How to mask a Social Security Number

Sometimes, your customers share information in ways they shouldn't. Even if you didn't solicit that information, the impact on your business could be devastating. In this article, we'll look at how to secure (aka redact) a social security number - one of the most sensitive pieces of information for United States customers - from various business applications.

Why it's important to mask a social security number

We talked previously about why it's essential to mask (aka redact) credit card numbers. If anything, masking social security numbers is even more critical.

A social security number is a nine-digit number that uniquely identifies every American citizen or permanent resident. The number itself contains three parts:

• An area number that corresponds to the geographical region where the number is issued
• The group number, which is taken from a pre-defined list
• The serial number, which runs consecutively from 0 to 9999

The consequences of leaking a social security number can be devastating for a customer. With a social security number, thieves can do everything from draining a customer's bank account to filing a fraudulent tax return.  

In legal terms, there is no single data protection law in the United States. However, Federal Trade Commission (FTC) rules and state legislation can levy high penalties for data leaks. For example, the California Consumer Privacy Act (CCPA) forbids disclosing sensitive customer information, including social security numbers. Fines can go up to the entire amount of a customer's financial loss.

The financial loss from not masking (aka redacting) a social security number can go far beyond the loss to a single customer. 92% of customers believe companies must be proactive about protecting their data. A publicized breach could motivate customers to take their business elsewhere.

Ways customers can share a social security number

Customers may inadvertently share a social security number over one or more of these business productivity tools:

• Email
• Customer support ticketing systems (e.g., ZenDesk)
• Cloud drives (such as OneDrive or Google Drive)
• Slack or other messaging applications

Your customer - and even your company's service reps - may feel that some of these tools are secure ways to transmit social security numbers. But doing so is fraught with danger. Not all of these tools are always as secure as they purport to be.

In addition, the more places a social security number is stored, the harder it becomes to control access to that data. Ideally, you're storing social security numbers in a single, secure location. All other references to an SSN should employ tokenization.

Let's look at how to mask (aka redact) a social security number in each case.

✨Email

Suppose a customer is employing a tax preparation service. Once they agree on a price package, they might include sensitive information - such as their social security number - in a follow-up email.

‎You can work to prevent this by educating your customers on the proper means to send such sensitive information. But that doesn't guarantee no one will ever do it.

Suppose you want to mask (aka redact) this social security number from the email automatically. In that case, you can write code that hooks into your email provider's SMTP server or Application Programming Interfaces (APIs) and intercept messages. For example, Google Workspace provides a pub/sub API that supports hooking notifications for mailbox events.

Alternatively, you can delete and purge the email from your system. However, this is a manual process and bound to be error-prone.

✨Customer support ticketing systems

Customers may also be tempted to drop social security numbers into ZenDesk, FreshDesk, or similar customer support ticketing systems. Even your customer service reps may believe this is secure, since these tools use HTTPS for encrypted data transfer.

The problem here is authorization. Not everyone with access to a support ticket is cleared to have access to sensitive customer data. Insider threats are just as dangerous as external threats. Take Amazon Web Services, where a former employee used her credentials to compromise the security of 30 AWS customers.

‎You can use built-in masking (aka redaction) features to mask (aka redact) a social security number from tools like ZenDesk. Also, be sure you're doing everything else possible to lock down and secure access to customer data in your ticketing systems.

Cloud drives (OneDrive, Google Drive)

You might assume that a cloud drive is a safer location for sensitive customer data than email or a support ticket. But misconfigured drive permissions can expose PII. Consider the airline that inadvertently exposed 3TB of sensitive customer data via an open Amazon S3 bucket.

Beyond locking down your cloud storage, you should also monitor and mask (aka redact) social security numbers from any documents. You can use your cloud provider's storage APIs to enumerate and scan files.

✨Slack

The same problems that plague customer support tickets also apply to tools like Slack and other instant messaging apps.

It's not possible to directly edit another user's Slack messages. But you can still redact a social security number by implementing a bot. The bot could block any messages containing social security numbers and repost them with redactions.

Additionally, be sure to secure your company's usage of Slack to limit the possibility of intrusion and data leakage.

✨Mask social security numbers across your enterprise

If attempting to mask (aka redact) a social security number across these diverse business applications sounds like work...well, it is! Unfortunately, many organizations don't have the IT resources to invest in a full-scale redaction strategy.  

That's why Strac does the heavy lifting for you. Strac performs automated redaction (aka masking) of social security numbers and other personally identifiable information across several apps, including Gmail, Slack, ZenDesk, Office365, and 40+ more.

Book a demo today to see it in action!

Learn how to protect SSNs in your SaaS or cloud apps, please book a meeting with us.

Related reading:

• A Comprehensive Guide to Salesforce Data Mask

🌶️ Spicy FAQs on How to Mask (Redact) a Social Security Number

1. If we already encrypt everything, why do we still need SSN redaction?

Encryption protects data from outsiders. It does nothing about the support rep who opens the ticket, the 40 people in the #billing Slack channel, or the contractor with Google Drive access. Most SSN exposure isn't a hacker breaking in — it's a customer pasting nine digits into a channel where dozens of authorized people can read them. Encryption at rest doesn't fix an authorization problem. Redaction does: if the SSN isn't there, it can't be over-shared.

2. Isn't it the customer's fault if they email us their SSN we never asked for?

Legally and reputationally, no. The moment that email lands in your inbox, you're the custodian. The FTC and state regulators don't ask who initiated the transfer — they ask what you did with it once you had it. "We told them not to" is not a compliance control. If your policy is a sentence on a web form, you don't have a policy; you have a hope.

3. Can't we just tell people not to put SSNs in Slack and Zendesk?

You can, and it will work right up until the first anxious customer, the first rushed rep, or the first "just paste it here so I can verify you" moment. Training reduces frequency; it never gets you to zero. And the incidents that hurt are the exceptions, not the average. Any control that depends on every human being careful every time is a control that fails on a schedule.

4. Our ticketing tool has built-in redaction — isn't that enough?

It's a start, and it's usually narrower than people assume. Native redaction typically covers the ticket body, often requires someone to click it manually, and frequently misses attachments, images, historical tickets, and every other app in your stack. Meanwhile the same SSN is sitting in the original email, the Drive folder someone saved the PDF to, and the Slack thread where the ticket got escalated. Per-tool redaction gives you per-tool coverage, and attackers and auditors both look at the whole estate.

5. Why not just build the redaction ourselves with the APIs?

You can. It's genuinely feasible — Gmail has a pub/sub API, Slack has bots, cloud drives have storage APIs. The honest math is that it's not one project, it's one project per app, forever: detection logic that handles formats and false positives, OCR for scanned documents and screenshots, retroactive scanning of everything already sitting there, and maintenance every time a vendor changes an API. Teams that build it usually cover two or three apps well and leave the rest unmonitored — which is the same as leaving them exposed.