I read some of the back and forth with other folks in the discussion and I have a few suggestions and comments.
SUGGESTION: You're connected through a VPN. Can your design incorporate running Kali from your location across the VPN (other than say running NMAP from different physical locations on the network)? That alleviates having the test system permanently deployed on-site, and making the client responsible for connecting and securing it.
There is nothing "wrong" with using Kali. It's an "easy button" of sorts, and comes with a significant amount of professionally published literature on its responsible use, and is the basis of the OSCP qualification. I would be more likely to run Kali and spend time customizing it as a single source for penetration testing on it's own firewall burb, VLAN, etc. than purpose building 30 different systems and then turning around and having to audit 30 separate systems.
The tools that Kali provides academically increases the attack surface, much in the same way that professionals have been chanting about how longer passwords academically increase the security of login credentials. For someone to use your Kali deployment, you've technically already lost the enterprise before the attacker even finds your deployment. If the person is on the outside, then they would have had to breach nearly every control out there (firewall, VPN, access control, etc.) and move laterally through several systems and networks to reach your Kali deployment - and likely could have just as easily installed the tools themselves. If the person is on the inside with access to Kali, well... Cue Chopin's Funeral March.
Also something to keep in mind, if someone has physical access to the box changing the root password is not hard without signing in. A previous CISO left his KALI machine here with no password given to me. Within 30 seconds I had reset the root password to something of my choosing.
So don't count on authorized users being the only ones to be able to access this box.