GV-6.2 Contingency processes are in place to handle failures or incidents in third-party data or AI systems deemed to be high-risk
Contingency processes are in place to handle failures or incidents in third-party data or AI systems deemed to be high-risk. For third-party components assessed as high risk there is a worked contingency, a fallback, a r
system holds itEvidence a system already holds
none for this control
periodic reviewEvidence produced at each review
- Test or exercise records demonstrating the contingency works · Document repository
governing documentDocuments that govern the control
- Identification of third-party AI components assessed as high risk · Vendor register / contract repository
- The contingency defined for each, naming the fallback or redundancy · Document repository
- Trigger criteria and the named role that invokes the contingency · Policy repository / GRC workspace
First move
Common gaps auditors find
- Contingency documented as revert to manual with no assessment of whether that is possible
- Never exercised, so the fallback capacity is unverified
- Applies to the primary vendor only while a sub-processor carries the same dependency
Do this for your whole sheet
Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.
Build my evidence sheetGV-6.1 Policies and procedures are in place that address AI risks associated with third-party entities, including risks of infringement of a third party's intellectual property or other rights · MN-1.1 A determination is made as to whether the AI system achieves its intended purpose and stated objectives and whether its development or deployment should proceed