Experienced DBAs go about this area by checking with their management and find out what is required of them. With PCI, HIPPA, and any other acronym that involves security standards for a particular industry, they each have their own requirements for periodically verifying user access and status. You also include review of the security logs, trace files if captured, and any other logging to ensure no one is attempting unauthorized access with an account that either does or doesn't exist.

It may be up to the application or system owner to review and approve permissions but I can guarantee you most DBAs are going to know who has permissions to the data they are responsible for protecting. I may not be able to tell an auditor why that account is there but I can tell you what it can and can't do at the server level and database level.

Each company/agency is different but most I have been involved with have a security group that are responsible for this type of stuff for the company as a whole, or for each department. They could also just be the middle-man for the external auditors that come in on an annual basis or every certain number of years.

That same group may know or be responsible for gathering the documentation mandated by particular security standards that have to be presented to the auditors. It is not enough to just show them through SSMS an account has certain permissions. I managed database security for servers as a DoD contractor and I did not directly write the documentation but provided the information to the group of individuals that needed it.

With DoD they follow the IASE Security Technical Information Guides (STIGS) that you can find here.