Most teams treat sensitive data collection as a risk they need to contain, when in reality, the harder problem is that the definition of “sensitive data” keeps moving. For example, geolocation, government-issued ID numbers, and newer categories of protected health information are all being pulled into state privacy law, which means a form that was compliant two years ago may not be today.
The payoff for getting intake right isn’t just avoiding a breach; it’s faster audits, cleaner records, and data that’s actually ready for the work that comes next.
In a recent FormAssembly webinar, Automating Sensitive Data Collection and Architecting Trustworthy Processes That Scale, the team walked through a specific example of sensitive data collection – a patient-intake build – and then opened the floor to audience questions. Below are seven of the sharpest questions from that session, answered.
How do you architect a single form that satisfies both HIPAA and PCI DSS?
You don’t need to do anything special on the form itself — you need the right plan and the right field types. On a plan that covers HIPAA compliance, that data is stored to meet those rules; credit card fields are handled to meet PCI DSS in parallel.
The key detail: FormAssembly does not store credit card numbers on the back end, which is what lets a payment field stay PCI-compliant. HIPAA data, meanwhile, is encrypted to standard at rest and in transit. So a healthcare team that also processes payments can capture both kinds of sensitive data in one workflow, as long as the account is on the appropriate plan and the credit card field is configured correctly.
How do you decide which fields need to be marked sensitive?
There’s no universal answer to this question. Every field on a FormAssembly form is already encrypted in transit and at rest at baseline. Marking a field as sensitive is a separate, deliberate layer that triggers redaction, access control, and audit visibility on top of that encryption.
Which fields earn that label comes down to what your organization collects and which regulations apply to it. The practical move is to map your fields against the rules you’re actually subject to, then tag accordingly. Setup is quick — you select the field, open its options, choose the data category (PII, PHI, financial), and mark whether it’s first or third party.
With new state privacy laws, how do I know if existing forms are now out of compliance?
Right now, this requires a manual review against your own state and industry rules — there’s no button that certifies an old form against new law. A form built two years ago can fall out of step as definitions expand to include things like driver’s license numbers, geolocation metadata, or newer PHI categories.
However, there are a few things that make that review less painful. FormAssembly’s AI assistant, Fai, can flag whether a form looks like it follows best practices as you build though, as the team was careful to say, Fai is not a lawyer, so its read should always be checked against your compliance team’s standards.
Beyond that, the recommended habit is to label and tag forms in the back end by the data they collect, which turns a regulatory change into a quick search rather than a hunt.
Can you show only the last four digits of a Social Security number after submission?
By default, no — marking a field sensitive redacts the whole value, not part of it. Partial visibility takes one extra step you build yourself.
You can capture the full Social Security number in a field marked sensitive, then add a calculated field that extracts just the last four digits and leave that field unmarked. The full number will stay locked behind redaction, while the last four stay visible for reference.
(Credit card fields are an exception — because the full number is never stored, the last four digits show by default.)
How does automated purge work — does it delete from Salesforce too?
No. Automated purge clears data from FormAssembly only. It never reaches into your Salesforce instance or deletes records there — that stays with your Salesforce team.
The point of purge is data minimization at the intake layer. Once a submission has passed through cleanly and landed in your system of record, you generally don’t want a second copy lingering in the collection tool. Purge settings can delete on successful submission, or on a timeline, so FormAssembly remains a clean pass-through rather than another place sensitive data sits at rest.
How do you handle KYC flows that need a document image, like a driver’s license?
Use a file-upload field, and route the image to wherever it belongs — not necessarily Salesforce. FormAssembly supports document uploads and can associate a file with a Salesforce record, but it can just as easily send that image to a storage system like Box, Dropbox, SharePoint, or Google Drive instead.
This is the same routing logic that runs through the whole platform: data and files don’t have to go to one destination. You can store a driver’s license image in a file-storage service and pass an ID number back so the record and the file stay linked, even when the image itself never touches the Salesforce record.
Where should you start auditing a Salesforce org for sensitive data exposure?
This one crosses into Salesforce administration, so the most useful starting point is your own Salesforce admin and compliance team, paired with your local regulations and the specific data you collect. FormAssembly’s role is the intake side — making it simple to capture data correctly and route it to the right system of record.
That routing is the real lever. Conditional logic lets you decide what actually goes to Salesforce: if you’d rather not store PII or PHI there, send it to a system built for it (like Epic, for instance) and keep Salesforce as your customer source of truth.
Controlling what lands where at intake shrinks the exposure you have to audit later.
A note on AI
Several questions circled the same theme: clean, compliantly collected data makes downstream AI work far easier. The framing throughout stayed grounded — the AI assistant flags and suggests, but humans review, approve, and decide. Getting data right at the point of capture is what keeps those later automations from inheriting risk.
Watch the full webinar
The webinar replay includes the full patient-intake demo — field-level sensitivity tagging, redacted response records, dual Salesforce objects, and the purge settings in action — plus the rest of the live Q&A.