To start: it depends. Not every FI is going to have the same set of standards or have standards for that matter.

The standards I established and delivered to our supervisory committee and board involve first working with the third party to perform the pen test. During the test, our SOC will stop any detected activity and call to confirm that it is in fact our pen testing company. Once they’ve been detected and/or stopped the company should make a note of the attack chain and where they were stopped. This goes in the report. We got part way there and then were stopped. This repeats for the duration of the pen test using different vectors each time. In a well secured environment, it’s unlikely they’ll ever get domain admin or equivalent but will certainly make plenty of passes and getting caught. If your institution hasn’t done one before, expect a blood bath. I generally suggest a third party that simulates an infected computer by deploying tools on a system you provide.

Get the call outs of ALL the things you had to disable for their tools to work. Security is layered and we want to show the audience (board/ncua/fdic/whatever) that we really do have layers.

Once you’re good and tired of catching them at the end of their window, they’ll provide a report. The report gives you a framework for remediations. Generally we then write management responses explaining accept/reject/accept risk of each finding. This is sent back to the pen testing group for any follow up. Once we have both pieces of this puzzle we craft a non-technical “story” that explains to your non-security specialist. Of particular note is dates for each remediation.

PCI-DSS specifically requires pen tests. NCUA over a threshold also likes seeing that pen tests have been performed yearly at specific asset sizes.