--- title: "Sensitive Data in Forms: What Not to Ask For" slug: sensitive-form-data-handling description: "Health details, ID numbers and card numbers in a form field become copies in inboxes and exports. What to stop collecting, and how to handle the rest." publishedAt: "2026-10-20" author: "Instaform Team" tags: ["forms", "compliance", "guide"] locale: en --- The failure is rarely the form itself. It is the clinic intake form that asks people to describe their symptoms, arriving as a plain email into a shared inbox that four receptionists have open, and being forwarded twice before anyone reads it. Nothing in that chain was malicious. The form collected data that raised the stakes, and the plumbing behind it was built for questions about opening hours. ## The categories that change the rules Some data is treated differently in most jurisdictions and needs a stronger justification than "it seemed useful". Health and medical information, biometrics, racial or ethnic origin, religious belief, trade union membership, sexual orientation and political opinion sit in the strictest tier under GDPR-style regimes. A second group is not formally special but behaves like it: national identifiers, passport and licence numbers, bank details, criminal record information, immigration status, and anything at all about a child. The practical effect is identical. If a field falls into either group, the answer to "can we just keep it in the submissions table?" is no by default. ## The first control is the field itself Every other control is downstream of whether the data exists at all. A dietary requirements field on an event form is a health field in a costume, because "coeliac" and "nut allergy" are both answers people will give and both are special category data. You can usually get the operational outcome without the category. Replace "any medical conditions or dietary requirements?" with a set of meal options and one box for "anything we need to know on the day", and most people give you the logistics without the diagnosis. The same trick applies elsewhere. You rarely need a date of birth; you need to know whether someone is over eighteen. You rarely need a full national insurance or social security number at enquiry stage; you need it at onboarding, from a system built for it. ## Ask later, and out of band Sequence is a control in its own right. A form's job at first contact is to establish whether there is a job to do, not to complete the file. For anything in the strict tier, collect at the point of need, in the system that needs it, with the shortest retention you can defend. An identity document that verifies someone should be checked and deleted, not filed. A [job application form](/templates/job-application-form) should collect skills and experience, with right-to-work documents requested after an offer rather than from all ninety applicants. Never collect payment card numbers in a form field. No configuration makes that fine. A card number in a text field pulls your form tool, your inbox, your exports and your backups into PCI scope at once. Use a payment processor's hosted field or a payment link. ## Notification emails are the biggest leak Most form tools default to sending the whole submission in the notification. That single default turns every recipient's mailbox into an uncontrolled copy of your most sensitive records, replicated across their phone, their laptop and their provider's archive. Change it. The notification should say that a submission arrived, name the form, and link to it. The data stays in one place with access control in front of it, and revoking someone's access then actually revokes something. The same applies to forwarding rules and shared mailboxes, which are how submissions keep escaping long after you stopped mailing them out. ## Uploads carry more than you asked for A file upload field is the widest input on your form. Photographs carry EXIF data including GPS coordinates and device identifiers. Office documents carry author names, revision history and sometimes deleted text that is still recoverable. A CV routinely contains a date of birth, a home address, a photograph and a nationality you never asked for and now hold. Restrict extensions and size, store uploads on the same retention clock as the record, and verify that deleting the record deletes the file. Orphaned files in object storage are one of the most common findings whenever anyone actually looks. ## Free text collects what you did not ask for "Is there anything else we should know?" is the field that turns a general enquiry form into a health record. People disclose. On a [complaint form](/templates/complaint-form) they will name colleagues; on a support form they will paste passwords and screenshots containing other customers' details. You cannot prevent it entirely, but labelling helps: "Please don't include medical details, card numbers or passwords here. We'll ask separately if we need them." Ten words of help text removes a surprising share of the problem. Then treat free text as sensitive by default for retention and access, because you cannot promise what is inside it. ## What good looks like Fewer fields. Later collection. One copy of the data. Notifications that carry a link rather than the answers. Uploads on the same clock as the record. Free text you assume is worse than you hoped. In Instaform a submission becomes a record you open rather than an email you receive, which is what makes the rest workable: access is granted per person, deleting the record removes its uploads, and the notification never becomes the copy that outlives everything else. If your intake sits in the strict tier by default, [Instaform for healthcare](/for/healthcare) covers that setup specifically.