Are your intake forms putting your clients at risk?

Intake forms are one of the most important pieces of infrastructure on your organization’s website. They’re often the first real interaction someone has with you—the moment a person in a difficult situation decides to share something personal and ask for help.

They’re also, in many organizations, one of the least examined pieces of infrastructure on the site. The form was built when the organization launched, or when someone switched platforms, or when a volunteer with some web skills offered to help. Questions got added over time. Nobody ever went back to ask whether all of them should still be there.

This post is an invitation to do that—to look at your intake forms not just as a functional tool but as a data collection decision, and to think carefully about whether what you’re collecting serves your clients or creates risk for them.

The basic question: do you need this?

Every field on your intake form is a piece of data you’re responsible for. It gets stored somewhere—in your platform’s database, in an email notification, in a spreadsheet someone exported once and forgot about. It can be accessed by people inside your organization, and potentially outside it. It persists until someone deliberately deletes it, which in many organizations means it persists indefinitely.

The principle of data minimization says: only collect what you actually need, for a specific purpose, and only keep it as long as that purpose requires. It sounds simple, but it runs counter to how most forms get built, which is additive—fields get added and rarely removed.

A useful exercise is to go through your intake form field by field and ask two questions: what do we do with this information, and what would happen if we didn’t collect it? If the answer to the first question is “not much” and the answer to the second is “nothing significant,” that field probably shouldn’t be there.

Some of the most common fields worth reconsidering:

Full date of birth. If you need to verify someone is over 18, a checkbox confirmation does that job without creating a record of someone’s exact birthdate. If you need age for service eligibility, an age range works just as well.

Full home address. For many organizations, a general service area or zip code is all that’s actually needed for intake purposes. A full address is sensitive—particularly for someone fleeing an unsafe situation—and storing it creates responsibility.

Demographic details that aren’t tied to service delivery. Race, ethnicity, income level, and household composition are sometimes collected for grant reporting purposes, which is legitimate. But if you’re collecting them by default on every intake form without a clear reporting need, it’s worth asking whether that’s the right place to gather that information, and whether it could be collected separately and anonymously.

Open text fields with no guidance. “Tell us about your situation” sounds welcoming, but it’s an invitation for people to share more than you need—and more than is safe for them to have in a form submission. If you need some context, narrow the question. “What kind of support are you looking for?” gets you what you need without encouraging people to disclose sensitive details upfront.

Who can see what gets submitted

This is a question a lot of organizations haven’t fully answered, and it’s worth sitting with. When someone fills out your intake form, where does that data go?

Most form submissions do at least one of the following: they get stored in your website platform’s backend, they get sent to one or more email addresses as a notification, or they get routed to a CRM or case management system. In many organizations, all three.

Each of those destinations has its own access controls, or should. Some questions worth asking:

Who receives the email notifications when a form is submitted? Is it a personal inbox, a shared inbox, or a role-based address? What happens to those emails—are they archived, deleted after a certain period, or just sitting in someone’s inbox indefinitely?

Who has admin access to your website platform or CRM, and when was that list last reviewed? Former staff or volunteers who still have access to form submissions is a more common problem than most organizations realize.

If your form submissions are being stored in your website platform’s backend—Squarespace, WordPress, or similar—are you periodically exporting and deleting old submissions, or are they accumulating? Many platforms store form submissions indefinitely by default, which means years of client data may be sitting in a database that nobody’s actively managing.

None of this requires a complicated technical solution. It requires a policy—a clear, written answer to “where does this data go, who can see it, and how long do we keep it”—and someone responsible for making sure that policy is actually followed.

How the form itself communicates trust

Beyond what you collect and how you store it, the form itself sends signals to the person filling it out. Those signals matter, especially for people who have reason to be cautious about sharing personal information.

A form that asks for a lot of sensitive information upfront, with no explanation of why it’s needed or what happens to it, can feel extractive—like handing over details to an institution that hasn't earned that trust yet. A form that’s transparent about what you’re collecting and why, that acknowledges the sensitivity of the information, and that tells people what to expect after they submit—that feels different.

Some practical ways to build trust into the form itself:

Add a brief note at the top explaining what the form is for and what happens next. “This form helps us understand your situation so we can match you with the right support. Someone from our team will be in touch within 48 hours.” That one sentence reduces anxiety and sets expectations.

If you collect sensitive information, explain why. “We ask for your zip code so we can connect you with services in your area” is more reassuring than a blank address field.

Include a privacy note near the submit button. It doesn’t need to be long—something like “Your information is kept confidential and shared only with the staff member handling your case” tells people what they need to know.

Be honest about what you can and can’t guarantee. If your organization has mandated reporting obligations, people deserve to know that before they share information that might trigger them.

A note on third-party form tools

If you’re using a third-party form tool—Typeform, JotForm, Google Forms, or similar—it’s worth understanding that those platforms have their own data storage and privacy policies, which may not align with your organization’s values or your clients’ expectations.

Google Forms, in particular, stores submissions in Google’s infrastructure and may use that data in ways that aren’t fully transparent. For organizations serving vulnerable populations, a form tool that stores data on Google’s servers is worth reconsidering. There are alternatives—Tally, Formspree, or native form handling built into your website platform—that give you more control over where submissions go and who can access them.

Where to start

If this post has made you want to look at your intake forms with fresh eyes, start with the simplest version of the audit: open the form yourself, read every field, and ask whether you’d be comfortable explaining to a client exactly why you need that information and what you do with it. If the answer to any field is uncomfortable, that’s a signal.

From there, trace where submissions go—email, platform backend, CRM—and make sure you know who has access at each step. Then set a retention policy, even a simple one, and make sure old submissions are actually being cleared.

It’s not a complicated process. It just requires intentionality—which is something your clients, who trusted you enough to fill out the form in the first place, deserve. If you’d like help thinking through your forms or your broader data handling practices, I’d love to hear from you.