Some rollouts aim to tackle this sort of problem by testing new systems with production data, generally imported from existing databases. This can ensure that data errors are corrected before rollout — but production data is valuable stuff containing a lot of confidential and proprietary information, and it needs to be guarded with the same care as it would in actual production.
 

In May of 2016, Chris Vickery, risk analyst at UpGuard, discovered a publicly exposed database that appeared to be Pacific Gas and Electric's asset management system, containing details for over 47,000 PG&E computers, virtual machines, servers, and other devices — completely open to viewing, without username or password required. While PG&E initially denied that this was production data, Vickery says that it was, and was exposed as a result of an ERP rollout: a third-party vendor was given live PG&E data in order to fill a "demo" database and test how it would react in real production practice. They then failed to supply any of the protection a real production database would need.

(Source: Josh Fruhlinger, Peter Sayer, and Thomas Wailgum. "16 famous ERP disasters, dustups and disappointments," CIO, March 20, 2020, https://www.cio.com/article/278677/enterprise-resource-planning-10-famous-erp- disasters-dustups-and-disappointments.html)

Required
Describe the technique that can be used to protect a real production database in the testing of the new system.