The response to this would be enough to write a book, in fact many books have already been written on this subject... If you're focused on performing a penetration test to immediately assess your risk you will fail. Your first focus when it comes to this type of "risk assessment" is to determine what your risks are. After you've concluded what those risks are, you begin at the 50k foot view and determine the weights of those risks. After all the paper pushing and math is done, then you'd perform a penetration test where it's needed.
Imagine for a moment you have 3 networks (/24's). One is production, one is devel and one is internal. What is your first priority here? Obviously the forward facing network (production) is most important. Allocate your priorities. The risk of having a vulnerable version of IIS on an internal server is far lower than having it on the outside.
You calculate your risks based on your business objectives. What do you need to do, how do you need to do it, what's defensible, what comes secondhand. Performing a full blown penetration test in my example network would be overkill. I'd perform a focused technical (non social engineering) test on my external network and go from there. Using something like GFI + OSSIM on the internal and development network would give me great results I could act on. Lowering the costs (time) to perform a full blown test. With the monies save, I could use it where its needed.
If I had to reduce vulnerabilities, my first goal would be my entrypoint. I'd focus most of my resources there and use compensating controls (GFI + OSSIM maybe even metasploit (using autopwn)) internally. However, focusing my resources means focusing on the systems that matter. (Bread and butter)