Writing good configuration standards is an important job for any IT team. Everybody needs to know how that box was built and a good configuration standard can help you piece the information together at a time of need. Like the time you are on call, and someone is shouting at you down the phone line. Its also great place to document all the hardening / security config that has been done and how everything has been locked down. This is useful for patch management. Patching services that have been disabled or removed in most cases doesn't warrant the reboot!
However - if experience has taught me anything it is that almost everyone hates doing writing technical documentation, especially retrospectively. So if you are retro documenting a build I do feel for you.
However! There are compliance brownie points for you in the PCI DSS world if you have good configuration standards. The PCI DSS expects a build that shows the system to have been hardened consistent with "industry standards", such as Centre for Internet Security (http://www.cisecurity.org/), NIST (http://www.nist.gov/index.html) or SANs (www.sans.org).
My personal favourites have always been the CIS docs, I just prefer the way they are written. They detail everything in a fairly linear manner as well as explain what the changes you are making actually do. Have a look on those sites and you'll get a good feel for what is required to lock down a device if you are relatively new to this.
The next few blog posts will be about the content needed in these config documents in order to a) satisfy the PCI requirements and b) Still be useful.
I'll not go into the details of how you store/manage them, you can do these in Word/Excel/pdf or make use of a wiki (good if you have an environment that changes frequently).
Part two - here -