QSAs have to validate the scope of a PCI assessment. It's one of the biggest areas of contention, but limiting scope is of paramount importance to reducing the complexity of an assessment. One of the ways in which QSA's are encouraged to validate scope is to have the client run a cardholder data (CHD) discovery tool over the entire environment (not just the expected Cardholder Data Environment (CDE)), to discover any unexpected CHD and either bring those people, processes and tools into the scope, or get them excluded and their access to CHD removed.
In my time in enterprise-level support, I was often asked how to reset the master password on various devices after the existing password had been lost for one reason or another.
Some organizations completely ignore important aspects of the backup recovery and validation process. This creates a significant ongoing data security vulnerability.
Something I hear continually is that recent computer science graduates have not even been introduced to the notion of secure coding. They may have been taught to program in half a dozen different languages and styles, but their assignments have never been run through a static code checker to validate that all the best practices have been followed from a security standpoint. I have interacted with many computer engineers happily producing insecure (unsafe) product. Secure Coding 101 may not exist, far less 201.
PCI DSS v3.2, section 10.4 requires all critical assets to be synchronized for time, and recommends using one of the authoritative time sources such as ntp. That requirement, however, only begins to scratch the surface of what controls time in a computing environment.