General (apply for every part of the security audit)

• system documentation: presenting the system functions, test cases
• goals of the security audit (customers' point of view)

Penetration testing

• access to the test installation
• user accounts to test it
• root access to server on which the application runs (to test the environment, configurations, dependencies, libraries, etc.) 
• if applicable, if there are any limitations put on days or hours of work (especially if a production service is tested)
• if applicable, if invasive tests may be run (especially if a production service is tested)
• contact information to a person responsible for the tested installation

Source code review

• information on the programming language
• information, which part of the source code is written by the team (does not include external modules, libraries etc. which usually, but not always, are considered as trusted)
• the number of lines of the source code (e.g. measured in KLOCs - thousands (Kilos) Lines Of Code; the information is required with respect to the part of the source code written by the team)
• suggestions which functionality is assumed as the most critical one by the SDT (NOT from security point of view!)
• access to the source code repository or a copy of the source code (the latter may be better for automated analysis; if the repository provides an option to download the whole package, there is actually no difference)
• software documentation, if applicable (if the code is really well commented it may be enough, but separate, general documentation is always welcome)
• if possible, access to the running instance of the application (to generate Candidate Points and easily validate initial source code findings) or information that allows to run the testbed themselves by the auditors team (e.g. virtual machine image).
• contact information for the SDT to be able to ask for particular issues appearing during the review