CF Cornerstone Forms Encryption

Staging rollout checklist

Prove the encryption workflow before touching production submissions.

Use this checklist with a developer or site owner before enabling field encryption on a live Cornerstone Forms site. The goal is simple: know which fields will be protected, know where the key is backed up, and know how to verify readback, search, uploads, and updates before production.

Go/no-go rule

Do not encrypt production data until staging can submit, encrypt, decrypt, search, audit, and update using the same forms, roles, and key storage pattern you plan to use live.

Phase 1: Map the form

  1. List each Cornerstone form that stores private or regulated information.
  2. Mark fields that should be encrypted and fields that must remain readable for routing, reports, CRM, email, or payment flows.
  3. Identify file-upload fields that should be protected with the same sensitivity as the related submission.
  4. Decide which roles may decrypt values in wp-admin and whether user-owned mode is required.

Phase 2: Prepare staging

  1. Clone production to staging with realistic forms, roles, and representative non-sensitive test data.
  2. Back up the staging database and uploads before installing the plugin.
  3. Add CS_FORMS_ENCRYPTION_KEY outside WordPress content when possible.
  4. Add a separate CS_FORMS_SEARCH_KEY if encrypted exact-match search will be used.
  5. Store both keys in the same secret-management process you will use for production recovery.

Phase 3: Test one new submission

  1. Install the release ZIP and activate the license under Settings > Encryption License.
  2. Enable Encrypt Field on one low-risk test field first.
  3. Submit the form once and confirm the stored value is encrypted, not plaintext.
  4. Confirm authorized users can decrypt the value and unauthorized users cannot.
  5. If uploads are involved, confirm the protected download URL requires permission and the raw media URL does not expose the file.

Phase 4: Test existing records

  1. Run Batch Encrypt on a small field list and small batch size.
  2. Open several older submissions and confirm decrypted readback is correct.
  3. Test blind search only on fields configured for search-key indexing.
  4. Check the audit log for decrypt, search, file-download, and batch-operation entries.
  5. If another integration needs plaintext first, test delayed encryption before touching production.

Production acceptance table

Check Evidence to keep Go/no-go
Keys backed up Confirmed recovery location for encryption and search keys. No-go if only one person or one machine has the key.
New encrypted submission Staging entry stores encrypted value and decrypts for allowed role. No-go if role checks are unclear.
Existing data batch Small batch encrypts and older submissions read back correctly. No-go if old records cannot be verified.
Uploads Protected file download works only for authorized users. No-go if raw upload URLs expose sensitive files.
Update channel WordPress updater can see the private update metadata with active license. No-go if the license cannot activate.
Rollback plan Known restore point for database, uploads, and key configuration. No-go if backup restore has not been tested.

Rollback plan

  • Stop changing field settings if staging behavior does not match the acceptance table.
  • Restore the latest database and upload backup if a batch operation was run against the wrong field set.
  • Keep the original encryption key available during any rollback or migration.
  • Do not rotate keys while investigating a failed decrypt or search issue.
  • Open a support request with versions, screenshots, and logs with secrets removed. Do not send form entries or keys.

Use this before buying for a client site.

If this checklist surfaces missing backups, unclear roles, or untested integrations, fix those first. The license can wait; production data recovery should not.

Installation guide Security model See pricing