The platform is certified. Your configuration of it is not.

The question is slightly the wrong shape, and the distinction matters. A platform is not compliant on your behalf — it provides controls that let you build a compliant process. FormAssembly supports HIPAA obligations for organizations handling protected health information and will enter into a business associate agreement, but those controls sit on specific plan tiers, the agreement has to actually be executed, and how you configure access, masking and retention is your responsibility rather than the vendor's. Most compliance failures we see are configuration failures on a properly certified platform, not platform failures.

It depends on which obligation applies, and FormAssembly renamed its tiers — Essentials, Team, Enterprise and Government — so older comparison articles cite names that no longer match. Broadly: identity-provider management for respondent single sign-on sits at Team and above, HIPAA and GLBA controls together with secure file scanning sit at Enterprise, and the FedRAMP-authorized High-Impact environment is the Government plan. FedRAMP in particular is scoped to that environment rather than being a property of the product generally, which is a common and expensive misunderstanding. We confirm current tier definitions with FormAssembly during scoping rather than quoting from memory.

FormAssembly publishes SOC 2 Type II audit results and PCI DSS compliance, and supports organizations working to HIPAA, GDPR, FERPA, GLBA, 21 CFR Part 11, ISO 27001, CCPA, TX-RAMP and Section 508 obligations, with a FedRAMP High-Impact authorized environment available on the Government plan. The vendor maintains a trust centre where the current documentation can be requested, and that is where your security reviewer should go — certifications and their scope change, so we point to the source rather than restating a list that will age.

By authenticating respondents rather than relying on an unguessable URL. Forms can require authentication through SAML, CAS or LDAP, so only people your identity provider recognises can open them — and identity-provider management lets that be configured once and reused across forms rather than set up per form. This is separate from the single sign-on your own staff use to reach the platform. Conflating the two is common, and it means public forms sometimes carry data that should have required a login.

Four things that are configuration rather than paperwork. Collect only what you need, so the form itself enforces minimisation. Capture consent in a way you can later evidence, with the wording and the timestamp retained. Set retention so data is deleted when its purpose ends instead of accumulating indefinitely. And make subject-access and erasure requests answerable, which means knowing every place a submission's data reached — including the systems your connectors send it to. That last one is where most organizations discover their retention policy only covers the CRM.

In our experience: who can access which forms and responses, and when that was last reviewed; how respondents are authenticated where the data warrants it; what the retention period is and evidence that deletion actually happens; where submission data travels, including every connector destination; and the record of who saw or changed a response. Most of that exists in a well-configured instance but has never been assembled. Producing it under audit pressure is considerably harder than setting it up beforehand, which is the main argument for doing this work before you need it.

Yes, and that is how most of these engagements start. We audit the plan tier against your actual obligations, review permissions and access history, check which forms collect regulated data and whether they are authenticated, look at retention and masking configuration, and trace where connectors send data — which is the step that most often finds regulated fields arriving somewhere nobody intended. You get the findings and a prioritised remediation list whether or not you continue with us.