The typical compromise (see what I did there?) when a customer or Federal Government auditor wants to run scans of any sort on your private network is to agree on tools (to be provided by the auditing group if you don't already have them) running an agreed configuration/profile/whatever against an agreed limited scope target list (typically a VLAN or set of VLANs unless that entire network is devoted to just that one customer, which is sometimes the case, though less so these days with public/private/hybrid clouds being all the rage). When it comes to web application and database testing, you'll typically agree on a non-production target list that's a mirror of the production system (with appropriate verification of the two being a mirror outside the automated testing) so as to avoid impacting the production systems. When it comes time to run the tests, over-the-admins'-shoulder monitoring ensures the proper tools with the proper configurations hitting the proper targets is being done and that the output is being handed over unaltered.
Seen this done in plenty of places and 99% of the time, the auditing group is fine with it because at the end of the day, it's getting them exactly what they want; just in a slightly more red-tape riddled way. Meanwhile, the group being audited has the assurance that nothing is running wild all over their network unsupervised. If you don't have anything to hide, you're typically fine with this approach. If you aren't fine with this approach, something else is going on behind the scenes and most of the time that'll be something you're trying to hide.