I think the document state what cipher are going to be support based on the level enabled. That' s what your auditor should use for the auditing and they shouldn' t just trust your word but, can validate.
Now on to more......
fwiw & imho, it' s not the cipher-type that should be of any concern, it' s the strength of the key. The auditors should be more concern with the key-length more than the cipher suite imho.
A weak private-key is not going to be any more effective with AES128 or CAMELLIA256.
I myself have wonder just how random the private-keys are within a FGT model XXXX vrs YYYY vrs FortiOs version A.B.C vrs C.D.E . I wonder how random the key generator that' s being used.
Just some food for thought 
When you mention strength of the key I gather you' re referring to the password that the user is using. If this is the case, our requirements are sufficient (min # of char, upper /lowercase, special chars, numbers, etc).No this would be the actual private-key strength, held by the ssl ( server )
When it comes to encryption, obviously we would be more comfortable with 256 bit. FortiNet seems to state that any of the above mentioned suites could be used. Why would they do this? Why not define a standard? I can' t be the first to ask for more info on the encryption type.I think there' s no such thing as one single standard, due to some many different browsers types. e.g The Us Gov has standard or set the standards on AES, but EU and Japan seems to think CAMELLIA is better. ( similar to US vrs UK and feet vrs meters or lb vrs kg ) This is why they list low med high ciphers in order to allow for the differences in browsers. Since in this SSL/TLS word, one single standard has not yet to be defined. Now for the forticlient, I would expect it would always take the highest level cipher that available. Even with a let' s say a HIGH cipher type, 128bit is deemed high depending on the cipher. (e.g) See image file AES128-RSA-SHA is high
