Stop collecting what you can't protect
Picture a feed store with a contact form on the website that asks for full name, phone, email, date of birth, and driver's license number. The form was copied from a template five years ago. The fields were never changed. Every submission goes to an inbox and gets copied into a spreadsheet. The spreadsheet is saved in a shared folder. The folder is backed up to a cloud service. No one ever looks at the birthday field. No one uses the license number. But the data is now in four places: the email inbox, the sent folder of every person who was copied, the spreadsheet, and every backup snapshot going back three years.
The store does not need a customer's date of birth to answer a question about feed prices. It does not need a license number to schedule a delivery. But once that data is submitted, it becomes the store's responsibility to protect it. If the email account is compromised, the attacker gets the spreadsheet. If the backup service is breached, the data is exposed. If an employee leaves and keeps access to the shared folder, they still have every customer record. The store is now liable for protecting information it never needed in the first place.
Where submitted data actually goes
Most contact forms send submissions to an email address. That email sits in an inbox until someone reads it. If the email account forwards to another address, the data is copied again. If the recipient replies and includes the original message, the data stays in the sent folder. If the email client is set to save a copy on the server and a copy on the local device, the data is in both places. Each copy is a place the data can leak.
Some forms save submissions to a database on the web host. The database is backed up daily or weekly. Each backup contains every submission. If the backup is stored on the same server, an attacker who compromises the hosting account gets the live data and every historical snapshot. If the backup is downloaded to a local computer, the data moves again. If that computer is not encrypted, the data is readable by anyone who gets the device.
Other forms send submissions to a third party service like Google Forms or Typeform. The service stores the data on its servers. You log in to view responses. The data stays there until you delete it. Most people never delete it. The service's terms of use explain what the company can do with the data. Most people never read the terms. You are trusting the service to protect information you collected but do not control.
What to ask for and what to skip
Before you add a field to a form, decide whether you will use the data and whether you can protect it. If you are not going to use it, do not ask for it. If you cannot secure it, do not collect it. A contact form for general inquiries needs a name, an email address or phone number, and a message field. It does not need a street address unless you are scheduling a site visit. It does not need a birthday unless you are verifying age for a legal requirement. It does not need a driver's license number ever.
Payment forms are different. If you are processing a credit card transaction, the payment processor needs the card number, expiration date, and security code. But that data should go directly to the processor, not to your server. A properly configured payment form sends card details to the processor's system and returns a token to your site. The token is useless to an attacker. Your server never sees the full card number, so you never have to protect it. If your order form saves full card numbers in a database or sends them in an email, the form is configured incorrectly and you are holding data you are not equipped to secure.
The same principle applies to Social Security numbers, account numbers, and passwords. If you do not have a system designed to encrypt and protect that data, do not ask for it. If a form template includes a field you do not need, delete the field. If a customer insists on sending sensitive information, tell them not to. The safest record is the one you never kept.
Where this sits in what RedCyfer does
When I build or audit a website, I review every form and every field. If a field is not necessary, I remove it. If a form sends data to an inbox, I make sure the inbox is protected with MFA and that old messages are archived or deleted on a schedule. If a form saves to a database, I check where the backups go and who has access. If a payment form is involved, I verify that card data goes to the processor and never touches the hosting server. The goal is to collect only what you need and to make sure what you collect does not become a liability.