It is my understanding that the finding reported by the security team is valid. Lets walk through the scenario they likely reported as I too have seen this on manual application assessments.
Take for example the login page of an application, or better yet, a credit card application form. After all of the form fields are filled out and the 'Submit' button clicked, the client sends that sensitive data in a POST request to the server. If the server response is a '200 OK' the browser will keep the POST data in browser memory allowing for replay attacks. As stated in an earlier response, one could hit the 'back' button, then 'Forward', and then 'Refresh' in which the browser will resend the sensitive POST data again. You will often receive a pop-up message from your browser letting you know that it is about to resend data previously sent.
The same data is sent via a POST request to the server. This time, the server responds back with some 300-type status code, likely a 302 redirect which sends the client to whatever the next page is. The client browser however having received a 300-type response does NOT maintain or cache the POST'ed data in browser memory. You CANNOT repeat the back, forward, refresh experiment and hope to see the previously POST'ed data replayed. This is all dependent on the server response.
You can test this for yourself if you have access to a local proxy such as Burp.
Set up the browser to point to your proxy. Access the vulnerable web page.
Fill out the fields, hit submit, and look at the request that was send in your proxy tool. You should see the various form fields containing sensitive data in the data section of the POST request. Assuming the server response was a '200 OK' move to the next step. On the browser, hit the back button, then forward, then refresh. You should get the pop up message from your browser alerting you its about to resend previously sent data. Hit OK. Now look at that last request in your proxy tool. It will have resent the POST request and the same sensitive data from earlier. NOW, try this same experiment on a website that returns 302 redirects to POST'ed data. You will NOT be able to get the browser to replay the posted data.
So, whats the risk or threat you may ask? First and foremost are replay attacks.
Your biggest concern should be malware. Your second biggest threat vector would be a shared device. The concern is that either malware or a person with access to the device could 'replay' the request and then be able to see the sensitive data that was sent in the POST request. Malware will just read the data straight out of browser memory. A person would have to use a tool to see the POST request again.
***A few caveats:
*Using Autocomplete=off only prevents data from being stored in form field storage containers. It is independent of and has no bearing on this issue. I would suggest however ensuring that any form fields accepting sensitive information should have autocomplete set to 'off'. Malware frequently looks for and reads saved form field data as it usually contains juicy info.
**Using cache-control headers also has no bearing on this issue as that is for pages that are cached to disk (temp internet directories). Again, you should utilize cache-control directives and prevent sensitive data from being stored in clear text on your system.
*** '200 OK' response on data POST'ed in a json request is a non-issue. Its about the only scenario off the top of my head that I can think of where you can't perform the replay attack when the server responds back with a '200 OK'.
Hope this helps. I'm sure its not listed as a high rated vulnerability due to the limitations of the attack vector. Its just 1 of countless layers in the security onion though!