Never collect Social Security numbers over email
A few weeks back we read through the rental application flow on the website of a property management company we talked with. The application was thorough: dozens of fields, income history, references, a photo of your driver's license. And your Social Security number. On submit, the form bundled all of it into an email and sent it to the office inbox.
Nobody builds that on purpose. A form plugin defaults to email delivery, fields pile up over the years, and one day the default is carrying the most sensitive number a person has. We see the same shape on small business sites all over. This one just had the highest stakes.
Why email is the wrong container
Email is a photocopier, not a filing cabinet. Every message makes copies, and you can never collect them back. Count the copies from one application: the applicant's sent folder, the office inbox, every forward to a screening service or a co-owner, the backups both mail providers keep, and the phone of every employee with that inbox synced. Deleting the email from your inbox deletes one copy of many.
Now add the part email skips entirely: access control. Anyone who can open that inbox can read every application ever received. One phished password leaks every applicant's Social Security number and license photo, going back years.
This is not hypothetical. Small business email accounts get broken into constantly, usually through a reused password or a fake login page. The attacker does not need to know your industry. They search the mailbox for attachments and 9-digit numbers, take what they find, and leave.
What the safe shape looks like
An application form should post over HTTPS (the padlock in the browser, meaning the connection is encrypted on its way to the server) into a system built to hold sensitive records. Built to hold means three things. Accounts decide who can open an application. Old applications can be deleted, and the data sits in one place instead of scattering across mailboxes.
If a full system is out of budget, the minimum bar is a dedicated secure upload instead of an email attachment. Better still, many tenant screening services host the application on their own platform, and you can send applicants straight there. The best place to store a Social Security number is nowhere. The second best is one system with a lock on it.
Your web person does not have to build any of this from scratch. Form tools that store submissions behind a login already exist, and the screening platforms already solved the rest.
What to ask your web person
One question does most of the work: when someone submits this form, where does the data go, and who can read it? If the answer includes the word inbox, and the form collects Social Security numbers, birthdates, or ID photos, stop taking submissions until that changes. This is not a rebuild. Moving a form off email delivery is closer to a day of work.
Two follow-ups worth asking. Does every page on the site force HTTPS? And how long do old applications stick around, and can we wipe one on request?
If you take applications on your website, ask the first question this week. Your applicants trusted you with the one number they can never change. Treat it that way.