You publish a form. Someone fills it out. Their name, email, maybe a date of birth or a medical condition, lands in a database somewhere.
What happens to it next? Who can see it? How is it stored? What happens if the platform you’re using gets breached?
Most people who build forms never ask these questions until something goes wrong. This post is about asking them before that happens—and knowing what the answers should look like.
There’s a related risk worth distinguishing here: uploading sensitive files to random online tools—PDF compressors, converters, mergers—is a separate but adjacent problem, one we covered in depth in 5 Types of Files You Should Never Process Online. That article is about the risk of handing a file to a tool you don’t control. This one is about the risk of the form platform itself—the software that collects, stores, and manages what your respondents submit.
On this page
Why form data is a target
Forms are one of the highest-density data collection points in any business. A single intake form might capture a name, contact details, insurance information, and a description of a medical problem—all in one submission.
That concentration is exactly what makes forms attractive to attackers, and exactly why the platform collecting and storing that data needs to take security seriously.
The risk isn’t abstract. A misconfigured form can expose submissions to anyone with the right URL. A platform without proper access controls means a disgruntled employee—or an outside attacker who compromises one account—can reach everything. Unencrypted data at rest is recoverable if a storage system is breached.
The good news is that the right security architecture handles all of this. The question is whether the platform you’re using has it.
The security stack that actually matters
Security documentation can be dense. Here’s what the key pieces actually mean for your data.
Encryption in transit and at rest
In transit means data is encrypted as it travels from a user’s browser to a server. This is what TLS (the technology behind HTTPS) provides. TLS 1.2 and TLS 1.3 are the current standards—older versions have known vulnerabilities and shouldn’t be in use.
At rest means data is encrypted when it’s sitting in storage—databases, backups, file systems. The standard is AES-256, a symmetric encryption algorithm used by governments and financial institutions worldwide. Without encryption at rest, a storage breach becomes a data breach. With it, an attacker who gains access to raw storage gets unreadable ciphertext.
Both matter. A platform that encrypts in transit but not at rest leaves a significant gap.
What to look for: TLS 1.2 or 1.3 in transit, AES-256 at rest. Both should be stated explicitly, not implied.
Access controls and the principle of least privilege
Not everyone on a team should be able to see all form submissions. Not every system process should be able to write to every database. The principle of least privilege says: give each person and process only the access they need, nothing more.
In practice, this means:
- Role-based permissions — an analyst can view responses but not edit form logic; an admin can do both
- Multi-factor authentication — credential theft shouldn’t be enough to compromise an account
- Audit logs — a record of who accessed what, and when
Audit logs are particularly important for regulated industries. If you’re handling healthcare data and someone asks which employees accessed a patient’s record, “we don’t know” isn’t an acceptable answer.
What to look for: Configurable roles, MFA enforcement, and tamper-evident access logs.
Infrastructure and network isolation
Reputable form platforms run on cloud infrastructure with production environments isolated from development environments. This matters because a bug introduced during testing shouldn’t be able to reach production data, and a compromise of a development system shouldn’t cascade into production.
Network-level controls—firewalls, Virtual Private Clouds (VPCs), Web Application Firewalls (WAFs)—create additional boundaries. Application servers should sit in private subnets, not directly exposed to the internet.
What to look for: Production/dev isolation, VPC-based network separation, WAF in front of public endpoints.
Backups and redundancy
Data loss is a security issue too. A platform should maintain redundant backups, retain them for a meaningful period (15+ days is a reasonable baseline), and store them in a separate location from primary data. For high-availability requirements, a multi-availability-zone architecture ensures that a failure in one data center doesn’t take the whole service down.
What to look for: Backup retention period, geographic separation, and documented recovery time objectives.
Compliance certifications: what they mean in practice
Certifications aren’t just logos. They represent independent audits of actual security controls by third parties with no stake in the outcome.
SOC 2 Type II
SOC 2 is the American Institute of CPAs’ framework for evaluating how service providers handle customer data. Type II is stricter than Type I: it doesn’t just assess whether controls exist at a moment in time, it tests whether those controls operated effectively over a sustained period—typically six to twelve months.
If a platform has SOC 2 Type II, an independent auditor reviewed their access controls, encryption practices, incident response procedures, and availability commitments, and concluded they worked as claimed. A copy of the report is often available on request or through a vendor’s trust center.
ISO 27001
ISO 27001 is an international standard for information security management systems. It covers how an organization establishes, implements, maintains, and continually improves its security posture—not just a snapshot, but an ongoing program.
ISO 27001:2022 is the current version. Organizations certified to it have had their security management systems independently audited and found conformant with the standard.
ISO 27017 and ISO 27018
These are cloud-specific extensions to ISO 27001. ISO 27017 addresses security controls for cloud services—both for cloud providers and their customers. ISO 27018 focuses on protecting personally identifiable information (PII) in cloud environments.
For businesses storing personal data in cloud-based platforms, these certifications provide meaningful assurance beyond the base ISO 27001 standard.
HIPAA
HIPAA applies to healthcare organizations and their business associates—any third-party that handles protected health information (PHI) on their behalf. For a form platform to be HIPAA-compliant, it must implement specific administrative, technical, and physical safeguards for PHI.
Critically: HIPAA compliance requires a signed Business Associate Agreement (BAA) between your organization and the platform. Without a BAA, using the platform to collect PHI puts your organization at risk of HIPAA violations, regardless of what security controls the platform has in place. The BAA creates a formal, legally binding commitment on both sides.
For a detailed breakdown of who needs HIPAA compliance and what the penalties look like, see our HIPAA compliance guide.
GDPR
GDPR governs how organizations collect, process, and store personal data from EU residents. For form platforms, this means having documented lawful bases for processing, providing data subject rights (access, deletion, portability), and maintaining appropriate security for the data collected.
Questions to ask your form platform
Before trusting a platform with sensitive form data, use this as a starting checklist. The “right answer” column tells you what a credible response looks like.
| Question | Right answer |
|---|---|
| What encryption do you use in transit and at rest? | TLS 1.2/1.3 + AES-256. Both, stated explicitly. |
| Have you completed a SOC 2 Type II audit? | Yes, and the report is available on request or via a trust center. |
| Where is my data stored? Is it isolated from other customers? | Named region (e.g. AWS us-east-1), tenant-level logical isolation. |
| Do you sign BAAs for HIPAA compliance? | Yes — required if you handle any PHI. |
| What is your data retention policy? Can I delete submissions on demand? | Configurable retention window, immediate deletion available. |
| How do you handle security incidents? | Defined SLA for notification (GDPR requires 72 hours), named point of contact. |
| Do your employees have access to my submission data? | Access is restricted, logged, and audited. |
If a vendor can’t answer these clearly, that’s the answer.
Note on PlatoForms: The table above reflects what a credible answer looks like, not necessarily PlatoForms’ current certification status. SOC 2 Type II certification is in progress. For current certification status and available compliance documents, see the Trust Center.
How PlatoForms handles security
PlatoForms is built for organizations that handle sensitive data—healthcare providers, legal practices, financial services, and businesses in regulated industries.
Infrastructure
- Hosted on AWS, data encrypted with TLS 1.2/1.3 in transit and AES-256 at rest, including backups
- Production and development environments fully isolated
- All employee access to customer data is logged, audited, and governed by least-privilege policies
Compliance
- Signs Business Associate Agreements for HIPAA-regulated organizations — see the HIPAA compliance documentation for setup details
- Designed to meet HIPAA Security Rule administrative, technical, and physical safeguard requirements
Account security
- Two-factor authentication available for all team accounts
- Configurable data retention policies — define how long submission data is kept and automate deletion when the period expires
For the full picture—certifications, downloadable compliance documents, and security architecture overview—visit the PlatoForms Trust Center.
If you’re in healthcare and need HIPAA-compliant forms with a signed BAA, see PlatoForms for HIPAA-compliant forms.
If you have specific questions about security for your use case, reach out to us. Security requirements vary by industry and by the sensitivity of the data being collected, and we’re happy to talk through whether PlatoForms is the right fit.
