As companies evolve and their exponentially expanding requirements need to be satisfied, third parties and vendors come more and more into play. The reasons for this are justified. As more companies become reliant on Information Technologies and Professional Services, they need to procure the best products, which requires, in some instances, deep knowledge of certain subjects.
Some organizations have begun to outsource complete units if they do not align with the company’s subject matter expertise, and the required services are provided in a much better fashion due to the fact that the vendor is an actual subject matter expert.
With this change in approach and the exchange of information on the rise, more and more organizations are building Vendor Management departments and hiring (sometimes outsourcing) contract lawyers to establish NDA (Non-Disclosure Agreement) documents and taking other precautions to be on the safe side. But wait! Aren’t we missing something within the big picture? Isn’t the devil in the details?
Sure it is! While the contract and NDA might protect the organization itself legally, it isn’t a measure of how much you will be protecting your information. Worst case, lost, leaked or inappropriately managed data can cost you your reputation and hefty fines.
In order to protect your data and reputation, establishing a vendor security management procedure and policy is paramount. The approach should include a rigid Vendor Management Lifecycle that, beside the essential management, handles contracts and NDA, as well as an audit that should be based on an Information Security Management framework (for example, ISO 27001:2013). The most recent ISO 27001 version has already included suppliers in its content.
Essentially, you should identify the assets to be shared, conduct an audit, including a risk assessment, based on the asset list within the scope of the chosen Information Security Management framework and assess whether it is viable to work with the chosen third party. If the relationship continues with the third party, an appropriate remediation plan within the risk appetite of your organization should be established.
Now, having essentially established a kick-off comes the real work. From this point, your organization will want to continuously monitor the vendor according to your risk appetite. This means if you have a remediation plan agreed upon and in progress, it should definitely not be limited toward a follow-up, a re-audit and/or re-assessment of the whole system if required.
In order to elaborate a bit on the topic, I would like to break down the issues a little bit:
This is probably the trickiest part when establishing control. The asset list should definitely not be exhaustible or rigid as assets provided or accessed by the external service provider may vary. However, it is always a good idea to identify with your business lines the essential data that your organization relies on. These should be kept as fixed assets as they will continually come up. In addition to the data being shared, the hardware it’s kept on, the software that will process it (do not just think of it as analytic software; the operating system should be considered as well) and the environments in which it will be kept need to be considered. They should all be included within the asset list to provide the auditing party an overview of the system.
Audit & Assess
Now that you have the list of assets, it’s time to put your third party to the test. Trust is good; control is better! After successfully completing the audit mission, a risk assessment that includes the asset list and the audit findings must be compiled and presented to stakeholders.
If any deficiencies are found, and the stakeholders are still willing to work together, they should establish a remediation plan for the discovered deficiencies (which should be included in the prior mentioned risk assessment report).
With all of the data being gathered from the vendor security assessment, a list of assets that are being shared throughout the third party universe should also be created. This byproduct might come in handy from time to time.
This should provide a high-level overview on what should be included in the Vendor Management lifecycle. Remember, you’re only as strong as your weakest link.
Tolga Yilmaz has extensive IT experience focused in recent years on Information Security. He was responsible mainly for design, conception, risk assessment and vulnerability testing of in-House and acquired applications, infrastructure penetration testing, cyber security governance and social engineering tests prior to joining CSC in Central & Eastern Europe, Italy & Turkey as Global Account Security Manager. He has extensive knowledge of the Banking and Finance sector and has governance experience with the COBIT (mainly v4.1, to some extent with v5), PCI Standards, SOX, OWASP, BRSA, ISO 27001 Information Security, ISO 22301 Business Continuity models/frameworks on regulatory and corporate basis.