In a SOC 2 report that includes the confidentiality Trust Services Category, some companies and their auditors struggle with the following point of focus under the change management criteria CC8.1: “Protects Confidential Information – The entity protects confidential information during system design, development, testing, implementation and change processes to support the achievement of the entity’s objectives related to confidentiality.” One way this point of focus has been interpreted is that customer data should not be used in test or development environments. And a control that commonly appears in SOC 2 reports to address this point of focus is: “Confidential or sensitive customer data is prohibited by policy from being used or stored in non-production systems or environments.”
So what happens when the confidentiality category is in scope and production data is used in the development or test environment? Does this automatically mean that CC8.1 has not been effectively addressed by controls? The answer fortunately is no. Generally, the risk of using production data in non-production environments can be effectively mitigated by doing the following:
- Scrambling, encrypting or anonymizing the data
- Implementing security controls over the test environment
- Deleting data promptly from non-production environments as soon as it has served its purpose.
The purpose of this paper is to evaluate why some companies use production data in non-production environments and describe ways to minimize the risk associated with this practice.
Using production data for testing
Many organizations have a test or QA environment that is connected to a test/QA data source – the database with test data. Some of these test databases contain fake data that is made up by QA engineers. This fake data is either produced by hand or by self-built scripts. However, this method causes certain problems: many production issues are due to the lack of realistic test data. Dummy data doesn’t contain every data issue present in production, which may result in bad or even useless test results.
Since it is beneficial to keep the test environment as “in sync” as possible with production, many QA teams copy production data to a test environment or the QA data sources to catch more (preferably all) edge cases and issues. When this is done, it is critical that the data copied to the test environment be encrypted, masked or otherwise de-identified.
It is also important that certain key security controls are implemented for the test environment, similar to the production environment. Examples of these controls are patching, vulnerability scanning and logging / monitoring.
Risk of using production data for testing
The main risk associated with using production data in a test environment is a compromise of the test environment leading to information disclosure (made worse if that data is PHI). It can be very risky to just copy production data to a test environment because production data often includes confidential customer information and/or personally identifiable information. When systems contain confidential or personal data, it is critical to keep data protection in mind.
Organizations generally have far less control over a development/test environment so test data gets out of the database in one way or another via screenshots, email, etc. This does not have to be malicious and largely it is not. For the most part, it will be people merely trying to get their job done.
SOC 2 Audit Implications
When companies use production data in non-production environments, auditors generally look at and test the following:
- Is the data encrypted or masked?
- Is the data deleted promptly when it is no longer needed?
- Are there security controls in place to protect the non-production environment such as patching, vulnerability management and logging / monitoring?
Conclusion
The safest course of action is to prohibit production data from being used in non-production environments. However, if it is necessary or more effective to use production data in test or development environments, the risks can be sufficiently mitigated by following the guidance above.
Thanks for reading!