how to reconcile audits and agile development ?

According to recommendations recently emitted by the Swiss working group for IT government audit (Swiss chapter of ISACA, international Information Systems Audit and Control Association), every important IT project in Swiss government should have at least 10 documents ready for the auditor (among about a hundred kinds of documents defined by the Swiss project management method Hermes ) :

1. Feasibility study
2. Specifications
3. Cost effectiveness analysis
4. Integration into the IT environment
5. Requirements
6. Concept for an internal control system (ICS)
7. System architecture
8. Tests (test plan and documentation)
9. Acceptance by the user
10. Final assessment

The recommendations explicitly insist that this list also applies to "new so-called 'agile' development methods".

For our Perl project at Geneva courts of law, this means that we must produce such documents to be ready for occasional auditors. The problem is, that the Hermes method was mainly inspired by good old waterfall development methods on mainframe computers, and some of the documents listed above just do not make much sense in our context; so instead of helping to better structure and organize the project, they just represent an additional burden.

For example, some parts of the application start in an exploratory way, without formal specifications, and are progressively shaped into working functionalities; tests are not planned in a document, but written in a galaxy of test files; etc.

I guess that the pressure for formal deliverables in project management is probably stronger in government than in private companies, but nevertheless people doing big Perl projects in any context probably also have at least some of such constraints. Any testimonies on that ?