Real salaries, real bank details, working email, live integrations and A ROUTE TO THE OUTSIDE WORLD. EVERY ONE OF THOSE HAS CAUSED A REAL INCIDENT.
Module 6 Lesson 5 lists what a clone carries; this is the same list stated as a prohibition, because the clone is where a test environment gets all of it.
WORKING EMAIL IS FIRST BECAUSE IT REACHES CUSTOMERS AND CANNOT BE RECALLED. A test batch sends real invoices to real addresses — and the damage is not technical, it is a client's customers receiving something untrue and their support desk taking the calls. Disable it at the system level rather than trusting a setting somebody can change.
LIVE INTEGRATIONS ARE SECOND AND WORSE IN ONE RESPECT: THEY WRITE. A database link that still resolves to production, an interface directory shared with a bank, a service another system calls. A test on that environment can corrupt the production it was supposed to protect, and nobody looks for it because the test environment appears to be working perfectly.
REAL SALARIES AND BANK DETAILS ARE THIRD, AND THEY ARE THE ONE WITH NO INCIDENT ATTACHED — WHICH IS WHY THEY SURVIVE. Nothing breaks. The data simply sits on a system with weaker access, weaker passwords, and more people able to reach it. The incident, when it comes, is a disclosure rather than an outage.
AND A ROUTE TO THE OUTSIDE WORLD IS THE ONE THAT MAKES ALL THE OTHERS WORSE. Module 15 Lesson 8's finding: a test environment reachable from the internet, with production's data and none of production's protections.
THE COMMON PROPERTY IS THAT NONE OF THESE IS ADDED DELIBERATELY. They are INHERITED, by a clone, from a system where all five were correct. So the defence is a checklist applied every time a clone is made — Module 6 Lesson 6, before anybody is let in — rather than a policy about what test environments should be like.
AND THE LAST DEFENCE IS TO MAKE THE ENVIRONMENT OBVIOUSLY NOT PRODUCTION. Every incident in this list begins with somebody believing they were somewhere else.