Hi Maxw,
Security implementation is something that needs some attention. The documentation starts with describing your own organization. You need to know yourself what different roles you want to implement and what segregation of duties needs to be in place. When you then compare your organization with the standard security roles, you will find out that the standard security objects are in many cased too far away from your requirements. You can consider the roles as examples and duties and privileges as Lego blocks. In my experience only a few roles were used from the standard.
Then it starts with creating your own roles. This can be done in Visual Studio or using the Security configuration page. When you have defined your roles, you might already have documented what you needed to achieve and this could be a base for documentation. Otherwise, have a look at the replies above where there are some tips to get it from the meta data. Some of the tips are not helping you correctly; depending if you use the configuration or development approach.
Getting a full document what is possible with a role is in my opinion a utopia. In fact, you should then have a list with all menu items and the permissions. This because when you make changes to standard objects, it might have an Inquiry word in the title, but the effective access is full control. Auditors will be confused with the labels of duties and privileges. Now we have used the word 'documentation' and 'auditors'.
In my opinion, you should have a correct description with possible some additional details if there are important or sensitive access levels in a specific role. Like, in this role, a user can maintain vendor master data, but creation of the bank account is limited as this is part of a finance role.
The auditors will ask questions like who can maintain vendor payment journals, who can approve and post invoices, who can create vendor bank accounts. They want to be sure that there are segregation of duties in place to prevent committing fraud.
The level of information required for your operation to assign security roles or to answer questions from the auditors are different. The first option can be achieved to provide a description per role. For the second part, it will be hard as there is no out of the box inquiry form to analyze on the object level what is the current status in the production environment with both changes in Visual Studio and the configuration option. For this, there are some ISV solutions which can help you answering the questions in detail: appsource.microsoft.com/.../apps
