Allow refresh of lower environment from production when using a HSM We currently use an Oracle Wallet for Transparent Data Encryption of certain critical columns and are migrating to a HSM for compliance reasons.  Our issue is how to handle encryption on the development systems that get refreshed frequently from the production system.  These refreshes are completely automated and rely on image file backups of our production system.  The development systems use the same Oracle Wallet and the refresh process handles manipulating the data in the sensitive columns so that the data does not have to be encrypted, however, we leave the columns encrypted so we can get similar behavior to production.  Here are some options I am aware of.


Have the development systems use the same HSM Partition as production.  This would be the most obvious solutions, but Oracle does not recommend it and this could potentially allow development to affect production.
Drop encrypted columns or drop them and add them back.  - This would be relatively fast, but leaves the columns empty, preventing processes that use the data from being tested.  It also changes the column order, which could be problematic.
Upgrade to 12c and use the reverse migrate command to move back to a wallet from an HSM. - Same problem as #1, albeit for a shorter time, but also requires an upgrade which we cannot do.  As I understand it, this functionality is not available in 11g.
Drop/recreate the encrypted columns and populate them using queries from production as part of the data manipulation part of the refresh.
Drop the tables and import them from an export of production.  Rather time consuming.


Are there other options I am missing or things that would make one of these options more desirable?
A method we found to be viable was to convert production to use the HSM and then clone the partition containing the key for production to development.  This needs to be repeated with each clone of the database and then a post clone step can modify the key for the lower environment using normal key change processes.