Eliminate Production Data in Testing: Tricentis CISO Highlights Security Risks

Post Views: 6

Production data in testing environments remains a widespread issue, according to Erika Dean, CISO at Tricentis, who advocates for its complete removal.

The Persistent Issue of Production Data in Testing

Production data in testing environments remains a widespread issue, according to Erika Dean, CISO at Tricentis, who advocates for its complete removal. In an interview, Dean discussed strategies for eliminating production data from non-production systems and highlighted the importance of alternative testing methods. She detailed how her team identified a prompt injection vulnerability during red-teaming exercises and delayed a product release for a week to address the flaw. Dean also outlined criteria for rejecting AI vendors, emphasizing transparency about data handling and retention policies. Additionally, she provided guidance for small security teams on prioritizing foundational security measures. Dean acknowledged that compliance and governance require less direct involvement compared to other security areas. While compliance remains critical for Tricentis due to customer obligations, she emphasized automation and self-service tools to reduce operational burden. This approach allows her team to focus on enterprise and product security, where technical controls directly mitigate evolving threats. The shift reflects the increasing complexity of attacks leveraging AI to exploit vulnerabilities rapidly.

Strategies for Eliminating Production Data

The use of production data in testing environments persists despite risks. Dean stressed that production data should never be used in QA or development systems, citing historical challenges in load testing for processes requiring unique identifiers like social security numbers or image validation. Even in regulated sectors such as finance and healthcare, data segmentation is often neglected. She recommended alternative testing methods, noting that modern tools now provide viable solutions without compromising security.

Identifying Vulnerabilities Through Red-Teaming

Dean recounted a scenario where her team identified a prompt injection vulnerability in an AI system. During red-teaming, the flaw was detected, prompting a one-week delay in the release to address backend weaknesses. This decision prevented potential data exposure, underscoring the necessity of rigorous security testing before deployment.

Dean emphasized that security should not hinder innovation but must be integrated into development cycles to avoid costly breaches.

AI-Related Risks and Vendor Evaluation

Evaluating AI vendors involves strict criteria, including data residency, retention policies, and architectural transparency. Dean highlighted that vendors unable to clarify where data is stored, how long it is retained, or whether it is used for model training are automatically disqualified. Additionally, unclear vendor ecosystems—such as indirect access to third-party models—pose unacceptable risks. Enterprises must maintain control over data flow and ensure AI implementations align with internal security frameworks.

Foundational Security Measures for Small Teams

For smaller security teams, Dean recommended three foundational steps: establishing a vulnerability management program to identify and prioritize risks, implementing monitoring solutions to detect anomalies, and deploying basic endpoint security measures like encryption and malware detection. She noted that AI can enhance these efforts by automating alert triage and improving efficiency, bridging the gap between limited resources and growing threats.

Broader Cybersecurity Challenges

The conversation also touched on broader cybersecurity challenges, including the risks of unpatched systems and AI-driven supply chain vulnerabilities. Dean’s insights reflect a strategic balance between innovation and security, emphasizing proactive measures to safeguard both organizational and customer assets.