I've created some reporting and testing tools for Field Encrypt: a Drush command for generating a report, and a Behat custom step definition for testing.
The Drush command looks like this:
$ drush field-encrypt-report
 Field/property              Label        Data type      DB column      Encrypted
 block_content.body.value    Text         string         text           encrypted
 block_content.body.format   Text format  filter_format  varchar_ascii
 block_content.body.summary  Summary      string         text           encrypted
 node.body.value             Text         string         text           encrypted
 node.body.format            Text format  filter_format  varchar_ascii
 node.body.summary           Summary      string         text           encrypted
$ drush field-encrypt-report --format=csv > report.csv
It's great for requirements specification, because you can use it to generate a spreadsheet of all the fields and properties in the system and then just go down the list with the customer and mark which ones should be encrypted. The result can be copy/pasted almost as-is into a Behat scenario, which looks like this:
@api
Feature: Data encryption
  Sensitive data should be encrypted in order to prevent information disclosure
  in case of system breach.
  Scenario: Field configuration
    Then field encryption is configured exactly as follows:
      | block_content.body.value   | encrypted |
      | block_content.body.format  |           |
      | block_content.body.summary | encrypted |
      | node.body.value            | encrypted |
      | node.body.format           |           |
      | node.body.summary          | encrypted |
The scenario tests that the list includes the total list of fields/properties in the system (it's tolerant of different ordering), so it will fail if you add new fields without specifying whether or not they should be encrypted--thus ensuring that you don't forget to make that decision as your application evolves over time.
The Behat step definitions are provided by way of a Contributed Module Subcontext. Disclaimer: I converted by project FeatureContext into a subcontext without testing, so there may be or may not be some massaging necessary to make it work--and I don't know what it looks like to use contributed module subcontexts in practice. That aspect I'm "basically throwing over the wall" here as I'm no longer actively working on it. I hope it's helpful. :)
Needs work
4.0
Code
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.