by I'm sure I'm not alone in asking vendors to help us comply with our security rules. Clients bring in new tools that are unable to follow the security rules. In some cases, the clients aren't really at fault. The clients don't really have an in depth understanding of the security policy, or may not know them well enough to check each rule. Vendors rarely even know what our policy is. Giving the vendor the full policy may not be permissible, and even if it is, often it includes rules that the vendor doesn't care about.
What seems to work well is to produce a summary of the security policy aimed at vendors. The policy should only contain the policies that the vendor or product tester would need to know.
To create this document, take a full dump of the security policy. Look at each rule. Does it apply to vendors? If no, then skip and move on. If yes, then what exactly does the vendor need to know to help you comply? For example, if the rule is to display a specific fixed banner prior to authentication (a warning banner), then don't tell the vendor what exact text is to be displayed, tell the vendor that they need to support displaying an arbitrary warning banner prior to authentication.
Create the document as a checklist. For every no answer, give a space for people to give an explanation.
When certifying a new product, then have the product evaluator go through that checklist for the new product. Then security becomes a consideration on the product evaluation. If there are security policy concerns, they will be listed and your management will have the information needed to decide how much risk they really are taking on with the product, how much to push the vendor to provide an update or fix.
Now you have a document you can give to vendors to keep in mind so that their future version of their product can at least try and consider your security policy. If they refuse, you have an objective tool to measure their non-compliance and present to management.