The contact-form gap almost every practice site has

Open your practice site and look at the contact page. There is a message box on it. Somebody, probably years ago, added a free-text field labeled “How can we help?” or “Reason for visit,” and nobody has thought about it since.

That field is the most common exposure we find. Not a hacked server, not a stolen laptop. A box you invited patients to type into.

The box does exactly what you asked it to

It was meant for office hours and parking questions. But a patient with a problem writes about the problem. “I’ve had a lump under my jaw for three weeks and I’d like it looked at.”, “My son needs an ADHD evaluation.”, “I want to talk about coming off my antidepressant.” The moment that text is attached to a name, a phone number, or an email address, it is protected health information, and it is moving through your website.

Nobody designed this. It is the default behavior of ordinary website tools that were never built with healthcare in mind.

Follow the data, not the form

The form is not really the exposure. The path behind it is. On a typical practice site, one submission touches more systems than most owners expect:

• The web server that receives the submission, and the plugin or form service that handles it.
• A database table on that same host, where most form plugins quietly keep a copy of every message by default.
• An outbound notification email, usually ordinary SMTP, sent to whichever inbox the office was using the year the site launched.
• A third-party form, chat, or scheduling vendor, if the field is embedded, which now holds the message on its own servers.
• Any analytics, session-recording, or advertising script loaded on that page, which can see the page a patient was on and sometimes what was typed into it.
• Backups. Every one of the above, copied on a schedule, kept for as long as the host keeps them.

Each of those is a place patient data comes to rest on infrastructure that was never chosen for the job, that nobody agreed in writing to protect, and that nobody is watching. That is the gap. It is quiet, it is boring, and it is almost everywhere.

The things that look like a fix, and are not

• An SSL certificate. It protects the data in transit and says nothing about where the data lands or who can read it once it does.
• A disclaimer asking patients not to send health information. They will anyway, and a notice is not a safeguard.
• Deleting the emails. The copy in the plugin database, the copy at the vendor, and the copies in backups are all still there.
• “Our host says they’re HIPAA compliant.” Hosting can be one part of a compliant setup. No host makes an application compliant, and a marketing page is not a signed agreement.

None of these are dishonest answers. They are what a competent general web agency reasonably believes, because outside healthcare they would be enough.

What actually closes it

You cannot stop a patient from typing protected information into a field. So we assume they will, every time, and we build the path so that it does not matter:

• The submission never posts to your website’s server. It goes directly to a platform covered by a signed business associate agreement.
• Nothing is stored on the host. No plugin table, no local copy, no attachment sitting in a public folder.
• Notifications carry no content. Your team gets a “new message, sign in to read it” ping, not the patient’s words sitting in an inbox.
• The page holding the form runs no third-party script that can watch what is typed into it.
• Access is controlled and logged, so you can answer “who read this, and when” if you are ever asked to.

Notice what that list is not. It is not a stronger lock on the box. It is the removal of the box. A website that never holds patient data has no patient data to leak, and that is a far easier thing to defend than a website that holds it carefully.

The question is not “is our contact form secure.” It is “where does what a patient types actually go, and who has signed for it.”

How to check yours this week

• Submit a test message through your own form, with obviously fictional health details in it.
• Then find every place that message landed: the inbox, the plugin dashboard, the vendor portal, the database.
• For each one, name the company that runs it and check whether a business associate agreement is actually signed.
• Open the page source of the form page and look for analytics and advertising scripts.
• Write down what you found. That list is your exposure, and most practices have never made it.

If you would rather not do that yourself, it is exactly what our free liability audit does. We work against your live site, follow the data, and hand you the paths in writing. Finding a gap does not mean anyone did anything wrong. These get installed by default, by tools that never warned you.