A zero RPO is a matter of putting a data protection solution in place that has data captured on the production storage in parallel with another storage system located in a secure facility suitable distance away, usually within 25 miles or so. These are commonplace in banks, where transactions simply can NOT be lost, because a second or two can mean millions of dollars lost. In banking, RTO's tens toward zero RTO as well, and those solutions have been around for years.
So, to test, I would imagine it's possible to simulate a disruption at a specified time by stopping the production feed for a few minutes, check the data at the failover site to see if the data captured equals the stop point, then fail back to the production environment. Yes, this would have to be done during a "slow period, like a weekend night preceded by a DO NOT LOG ON message to all users. But this is the only way to know if the chosen architecture actually does what it's supposed to do. If it doesn't, the test is a success because you found a vulnerability still exists that needs fixing.
You mention your Corporate Office and auditors are looking at "test execution steps that demonstrate the RPO objectives..." The solution design does that, NOT the test plan. In testing, you execute THE PLAN, which, in this case, is an automated failover of data capture and either an automated (if zero RTO) or manual (if RTO is greater than a few minutes) failover of processing. In a zero/zero solution, no one does anything, the infrastructure and programming do it. And that's how you test it.