Compare approaches
What this solves, and what it deliberately does not solve.
Buyers usually compare field-level encryption with doing nothing, relying only on hosting controls, sending forms to a hosted service, or writing custom code. The right answer depends on the form, the data, and the operational process around it.
| Approach | Good for | Tradeoff | Best decision signal |
|---|---|---|---|
| Do nothing | Low-risk forms where stored values do not matter. | Sensitive entries remain readable to anyone with enough database/admin access. | Acceptable only when the submitted data would not create meaningful harm if exposed internally. |
| Hosting/database controls only | Broad infrastructure protection, backups, and access restrictions. | Does not make selected form fields unreadable inside WordPress storage. | Use this anyway, but do not treat it as field-level protection. |
| Hosted form platform | Teams willing to move intake outside WordPress. | Changes the form workflow and sends form processing to another vendor. | Best when outsourcing the whole intake and compliance workflow is acceptable. |
| Custom code | Highly specific workflows with engineering budget. | Requires ongoing maintenance, updater packaging, license gates, and security review. | Best when the workflow is too custom for a focused plugin and you can maintain it. |
| Cornerstone Forms Encryption | Existing Cornerstone Forms sites that need selected fields protected at rest. | Narrow by design: it protects selected stored form data, not every compliance obligation. | Best when you want to keep Cornerstone Forms and reduce plaintext storage exposure now. |
The practical decision
Use this plugin when you want to keep Cornerstone Forms in place, keep submissions on the WordPress site, and reduce plaintext storage exposure for the fields that carry the real risk.
Questions before choosing
- Does the form collect data that should not be readable in post meta or database exports?
- Do existing email, payment, CRM, or reporting flows still need some fields plain?
- Can the site owner safely back up the encryption key outside ordinary support tickets?
- Do staff need exact-match search on protected fields?
- Would moving to a hosted form platform create more operational change than the risk justifies?
Why the narrow scope matters
A broad security promise would be misleading. This plugin focuses on one job: selected Cornerstone Forms data should not remain readable at rest unless an authorized user intentionally decrypts it. Hosting security, account hygiene, consent language, backups, and incident response still remain the site owner's responsibility.
Already using Cornerstone Forms?
If the issue is stored plaintext, start with the security model and the setup checklist. If the issue is the whole intake workflow, compare a hosted form platform first.