AL Refs: VSE01, GOV28
Purpose
The Vendor Management Policy applies to all material vendors. This includes where private or confidential data is used in conjunction with the services, or where there is a business dependency on the service provider. The purpose of this policy is to ensure these vendor relationships are effectively assessed and managed to mitigate the risk of data security breaches or business continuity failures based on the reliance on these third-party providers.
Example Vendor Management Policy
Responsibilities
Policy Owner
The Chief Operating Officer is responsible for maintaining, revising and monitoring this policy document and application in practice. This includes ensuring that all material vendors are assessed under this policy and logged in the Vendor Register. Instances of non-compliance should be identified and reported to the Senior Leadership Team.
Vendor Approver & Owner
Responsible for assessing and approving the vendor prior to onboarding. Maintaining ongoing ownership of the vendor and performing periodic review and revision of the vendor management process as applicable to each vendor assigned.
All Staff
Following this policy to limit the use of vendors to only those that are approved. Raising formal requests for new vendor services, performing or supporting the assessment process.
Vendor Approval
All new third-party services should be assessed to determine; (a) if they are a material vendor subject to this policy, (b) whether the business case and risk assessment supports onboarding the vendor, and (c) to ensure all material vendor activity is centrally managed to avoid duplication, inappropriate use of vendors, and excessive information security or business continuity risks. The Vendor Risk and Approval form should be used.
Vendor Register
The Vendor Register is used to put this policy into practice with the listing of material vendors. It tracks the activities of assessment, approvals and ongoing monitoring and management of these vendors. The vendor register tracks:
Management owner: Each vendor relationship is assigned an accountable owner with responsibility for ensuring that vendor has been appropriately assessed, risk mitigation plans associated with using the vendor are carried out effectively, and that ongoing review and management of the vendor is effective.
Information security risk: Based on the data used in conjunction with the services, the inherent risk level of the security of that vendor. For example, if the vendor processes and stores a large volume of customer confidential data, this would be a high inherent risk rating. In contrast, if the vendor does not collect or store any data of AssuranceLab or its customers, or the data is not considered confidential or sensitive, the risk rating may be low.
Business dependency risk: Based on the nature of services provided and how those are used by AssuranceLab this is the level of impact of a service failure by the vendor. For example, if the service provider is a technology platform directly supporting the availability or functionality of AssuranceLab’s AuditPro and it would not be easy to substitute at short notice, this would be a high risk. In contrast if the service is a “nice-to-have” and there are readily available alternatives, it may be a low risk.
Vendor risk: Based on various indicators of the service providers risk, including their past performance, reputation, size, certifications to industry standards like SOC 2, ISO 27001, the functionality provided that supports security and resilience of the service. For example, AWS, Microsoft and Google may be considered a low risk. In contrast a small off-shore development company in the Philippines may be considered a higher risk.
Certifications: Includes any tangible verifications and certifications of the vendors capabilities, information security and resilience. The best practices include SOC 1, SOC 2, ISO 27001, PCI-DSS, NIST and other global and leading information security standards. These should be reviewed as part of assessing the vendor risk initially and in the periodic review of each vendor.
Multi-factor authentication: Whether multi-factor authentication is available and enforced for AssuranceLab employees. This should be tracked and revisited over time if it is not initially available or enforced, for all vendors with a material information security risk.
Risk mitigation strategy: Based on the assessment of information security, business dependency, the vendor risk and any other mitigations of that risk, it should be determined whether a risk mitigation strategy is required. This may involve restricting the use of sensitive data with the vendor, identifying an alternate backup provider, or proactive monitoring and closer management of the vendor.
Service agreement: The link to the online terms of service or agreement, the intranet link, or the location and holder of the service agreement with the vendor should be recorded for review or reference as required.
Review history: Each vendor should be reviewed at least annually to revise the above areas and adjust as required. This should also include a review of any certifications identified to ensure they “passed” their certifications, identify any issues raised and demonstrate compliance on behalf of customers that rely on AssuranceLab to manage these vendors on their behalf.