See Guidance ISO/TR 14969:2004 explanation or clarification for section 8.5.2 and 8.5.3.
If product related issues, you could look at other sources of quality data, e.g. complaints, service calls, field returns, replacement part shipments, besides the usual nonconforming material records.
If supplier caused product related issues, above mentioned data sources usually are the first ones to be looked at.
Depends on the degree of the problems, you could also look up engineering change requests and number of subsequent ECOs on same or similar issues. For example, if the issue originally is a specific component in a subassembly, you could also run a NCR, ECR, complaint, service calls data (for examples) to see if anyone has complained or raised issues about the subassembly that may be caused by the component.
If the issue is process related, you could add a re-audit to the internal audit schedule for that particular process. You could wait a couple months and then pull some samples of the records to evaluate if the fixes were indeed effective.
I use several methods:
before the corrective action is implemented I verify that the root cause was identified. does the original analysis makes sense? I look at the data to ensure that the analysis adn conclusion was logical. If the origical defect/failure was variation based I require hypothesis testing to prove that the root cause was determined (turn it on and off); if error based, I look at the objective evidence and why-why (Apollo method) that led us to the root error (and condition if applicable). Sometimes we can use the hypothesis approach here as well to turn it on and off.
Once I am satisfied that the root has been determined I look for evidence that the selected correctivea ction will actually work: again a hypothesis test works here OR simple logic if error based - what level of mistake proofing is proposed. However, I also look for the controls that will be applied (if the mistake proofing is not at the highest level.
Then I approve the corrective action.
THEN I audit the implementation to ensure that the corrective action (and any applicable controls) were implemented and are beign followed. I do this at least twice: shortly after the reported implementation date to verify implementation and a few weeks/months later to validate that it is sustainable in real life. It also becomes part of our interanl audits, 5S, or Six Sigma audits as applicable for long term sustainability.
Then I VALIDATE: does the defect/failure occur again? of course teh time frame for this is dependent on the natural frequency of occurence of the original problem.