Are vendor security incidents (breaches, outages, contract violations) logged, root-caused, and used to refine the programme?
Demonstrate that the organization maintains a complete, up-to-date vendor security incident log with documented root cause analyses and evidence of process improvements derived from incident patterns.
Description
What this control does
This control ensures that security incidents involving third-party vendors—including data breaches, service outages, and contractual security violations—are formally documented in an incident tracking system, subjected to root cause analysis, and systematically reviewed to improve vendor risk management processes. The control establishes a feedback loop where vendor-related incidents trigger updates to vendor assessments, contractual language, security requirements, or monitoring practices. Organizations maintain a vendor incident register that captures incident metadata, impact analysis, vendor response time, remediation actions, and lessons learned, which inform future vendor selection, due diligence criteria, and ongoing monitoring protocols.
Control objective
What auditing this proves
Demonstrate that the organization maintains a complete, up-to-date vendor security incident log with documented root cause analyses and evidence of process improvements derived from incident patterns.
Associated risks
Risks this control addresses
- Repeated vendor breaches exposing customer data through the same attack vectors due to lack of pattern recognition and preventive action
- Undetected systemic vendor security weaknesses leading to cascading failures across multiple customer environments
- Failure to exercise contractual remedies or termination rights following vendor security violations due to inadequate incident documentation
- Regulatory non-compliance and penalties when vendor incidents affecting personal data are not properly tracked and reported to authorities
- Continuation of high-risk vendor relationships without awareness of incident history during contract renewals
- Ineffective vendor risk assessments that fail to incorporate actual incident data, leading to inaccurate risk ratings
- Loss of institutional knowledge regarding vendor security performance when staff turnover occurs without centralized incident records
Testing procedure
How an auditor verifies this control
- Obtain the vendor incident register or tracking system and verify it includes fields for incident type, affected vendor, date, impact severity, root cause, and corrective actions.
- Request the organization's vendor incident management procedure and confirm it defines criteria for what constitutes a reportable vendor security incident, escalation paths, and root cause analysis requirements.
- Select a sample of 10-15 known vendor security incidents from the past 24 months by cross-referencing vendor communications, breach notification emails, service status pages, and internal security team records.
- Verify each sampled incident appears in the vendor incident register with complete metadata including impact assessment, timeline, and vendor response documentation.
- Review root cause analysis reports for at least 5 significant vendor incidents and confirm they identify underlying causes beyond immediate symptoms, include contributing factors, and specify preventive measures.
- Trace at least 3 vendor incidents forward to evidence of programme refinement by identifying corresponding changes to vendor risk assessments, contract templates, SLA requirements, security questionnaires, or monitoring procedures.
- Interview vendor risk management personnel to confirm incident data is reviewed during periodic vendor risk reviews and contract renewal decisions, requesting meeting minutes or decision records as evidence.
- Examine the most recent update to the vendor risk management programme or policy and verify it references incident trends or specific lessons learned from vendor security events.