What's Next?
You'll want to customize the code examples and automation framework I've provided to include the specific security checks you need to run. Develop a set of scriptable checks that meet your security requirements and evaluate your checkpoints against your organization's security plan. Do you have at least one test for each security policy included in the plan? If not, you'll need to design one. And what about the policies themselves? Does your organization's security plan cover every relevant item on Microsoft's SBP Checklist? If not, find out why.
Finally, if the automation framework makes sense to you as an end-of-cycle development-testing tool, consider turning it over to your support team so that they can adapt it to your production servers. An administrator could, for example, schedule a SQL Server Agent job that automatically runs your configuration checks at scheduled intervals during the week. Another option is to run your test tool whenever an unsuccessful login attempt (or other auditable security event) occurs. Or you might simply set a SQL Server alert to fire whenever a login attempt fails, launching the upVerifySecurityConfiguration procedure in the process to verify that your production servers are still running "safe."
Remember to document the practices and procedures you use to design security checks and process test results. As you've seen, configuration checking requires no special tools or expertise beyond a good SQL editor and a basic understanding of database administration and common security checkpoints. But configuration checking is a poor substitute for professional security testing unless you have a test plan (including suitable test cases and reliable test benchmarks), documented test results, and shared bug reports. Automating the entire process is the proverbial icing on the cake, since it not only saves time but also assures you that your database (and server) meet or exceed a baseline security level.