Thanks for Misusing My Personal Data!
15 months ago, I bought a house.
During the course of that transaction, I had to disclose personal information to:
- The finance company (two, since we dropped the first one)
- The insurance company
- The title company
I was required by Federal law to disclose information, including my:
- Birthday and date
- Social Security Number
- Full Name
You know, everything you might need to, you know, KNOW in order to steal my identity.
The business purpose for this was ostensibly to:
- Obtain credit information
- Review my financial records and assets
- Report a financial transaction to the IRS
And, it was ostensibly to be used ONLY in the course of doing business.
A year passes…
I get a “Happy Birthday” e-mail from:
- BOTH finance companies, even though I dropped one of them
- The insurance company
In addition, I got an actual birthday card in the mail from the finance company that we ended up using.
Two decades ago, I would have thought “how quaint!” and moved on.
However, in the days of identity theft, YOUR BIRTHDAY is a significant piece of non-public personal data that should be closely guarded.
If I had gotten a birthday card at the beginning of the month with a note that says “Hey, happy birthday this month!” We know it’s your birthday, but we respect your privacy, so we’ve stored a generic representation of your personal data rather than your actual birthday.
The reason storing my ACTUAL BIRTHDAY is NOT ACCEPTABLE, is twofold:
- YOU HAVE NO REASON TO STORE IT. Once you’ve pulled my credit, sold me a house, and reported all of this to the government, there is no legitimate ongoing business need to continue to retain that information.
If your company stores data for which there is no valid, ongoing business purpose, you’re inviting a data breach.
- YOU PROBABLY AREN’T STORING IT SECURELY. Is my birthday in a spreadsheet, stored on your laptop that you take to your house every night, which someone could steal from your house, or even worse, steal from the back seat of your car when you stop to pick up dinner on the way home?
Don’t laugh – I worked for a company where this exact situation happened – a spreadsheet containing personnel records, including social security numbers, was stored un-encrypted on the hard drive of a company-issued laptop that was stolen out of the back of someone’s car while parked in a restaurant parking lot.
So hopefully not on a laptop, but, pursuant to GLBA or FCRA or HIPAA or a number of other laws, we should hope that my birthday is stored on a server that’s encrypted, logically-secured, physically-secured, logged, monitored, audited, sitting behind a firewall, etc. More realistically, it’s stored “in the cloud” in your company’s sales system.
In addition to appearing completely unprofessional, the situation gives rise to the following, UNCOMFORTABLE QUESTIONS:
- What else are you storing without my knowledge and consent?
- Who do you share it with?
- Is it all stored by social security number? I hope not, but that’s how businesses were run 30 years ago.
If WE NEVER DID BUSINESS AT ALL because MY WIFE FIRED YOU, then you have NO LEGITIMATE PURPOSE for storing my data, and ZERO REASONS to send me a birthday e-mail.
You know who you are…
Most data breaches result when companies store data that they don’t need, or store improperly, or both.
- Identify and catalog all systems that store Personally-Identifiable Information (PII) / Non-Public Personal Information (NPPI) / Protected Health Information (PHI) and other sensitive, personal data.
- Make sure these systems are secured properly – the Federal government provides guidance on securing financial and healthcare data.
- Audit the data regularly to make sure you are only storing what is needed for legitimate business purposes. This includes purging old data, as well as ensuring that you are not unnecessarily, permanently storing personal data fields.
- In most cases, a business is only required to retain business records for 3 to 7 years, depending on the type of business. If you have data older than that, you need to delete it!
- If you have data fields that are necessary, say, to perform a credit check, you need to store them temporarily, and then delete them when no longer needed. Those data fields should live only as long as the transaction, and no longer. 3 months to a year would be more than sufficient.
- If you want to store demographic information, or, you know, send birthday cards in a quaint attempt to appear personable, then at least use legitimate techniques to anonymize the data.
- Don’t store the birth year at all (if not needed for demographics)
- If you DO need demographic information, Round the birth year to a multiple of 5
- if y’=y then y’=y’+5
- In your CRM system, set everyone’s birthday to the first of the month. If my birthday is April 22, store 4/1.
Send me a birthday card at the first of the month, and let me know that because you respect my privacy, you DO NOT STORE MY ACTUAL BIRTHDAY.