How to build the vendor list
The first step is the most laborious: finding out which vendors there actually are. Good sources are the accounts payable list from accounting, the contracts in purchasing, the list of software subscriptions and the record of processing activities. Also ask the business departments, because many cloud services are booked directly there.
Not every vendor is relevant to information security. The canteen and the office supplies dealer rarely belong in the assessment. What matters is whether a vendor has access to your data, systems or premises, or whether its failure would affect your own service. Cloud services, IT service providers, hosting, payroll and software almost always belong in it.
In Sightadel you create each relevant vendor with name, category and country. The category helps with filtering and comparing similar vendors. The country matters when personal data is processed outside the EU. You do not need to type out existing lists, because Sightadel supports import from Excel files.
Plan the list as a living register. New vendors come in through purchasing, old ones drop out. Decide who reports new vendors before a contract is signed.
Assessing risk traceably
Assessing a vendor starts with the question of what it does for you. This gives the inherent risk, that is, the risk without taking safeguards into account. A payroll bureau that processes salary and health data has a higher inherent risk than a print shop that prints flyers.
The risk drivers make the assessment traceable. They show which data categories the vendor processes, such as special categories under Art. 9 GDPR, financial and payment data or authentication data, and which security features are missing, such as multi-factor authentication or encryption of data at rest and in transit.
Mitigations reduce the risk. This can be a contractual provision, proof from the vendor such as a certificate, or a technical measure on your side. Each measure is applied and either approved or rejected. The result is the residual risk, and the history shows how many points each measure achieved.
Sign-off is important. A residual risk that nobody has accepted is just a number. Decide who may accept which residual risk, and record exceptions with a justification.
What auditors and supervisors look for
When it comes to vendor management, the auditor checks three things. First, whether you know which vendors are critical. A complete list with categories and risk classification is the proof of this. Second, whether security requirements are agreed contractually, for example in the data processing agreement or in a security annex to the contract. Third, whether you review vendors regularly and not just once when the contract is signed.
In practice, the auditor picks a few vendors and asks: how was this vendor assessed? What evidence is there? When was the last review? What happens if it fails? The risk analysis in Sightadel answers the first three questions with rating, drivers, measures and history. You link the vendor's contracts, certificates and audit reports as evidence.
For financial entities under DORA, the supervisory authority comes into play as well. It expects a complete register of information and particular diligence with service providers that support critical or important functions. Exit strategies are also part of this. The assessment per vendor is a basis for this but does not replace the other DORA obligations.
Common mistakes in vendor management
The most common mistake is a one-off assessment. A vendor is checked when the contract is signed and never again. Yet services, subcontractors and the security situation change. Review important vendors at least once a year and additionally when the service, the contract or the data processed changes. In Sightadel you start this with “Review assessment”.
A second mistake is the same effort for everyone. If you check every vendor with the same extensive questionnaire, you get no answers or poor ones. Align the depth of the review with the inherent risk. For critical vendors it is worth looking at certificates and audit reports; for non-critical ones a brief classification is enough.
Third, vendors' certificates are not read. An ISO 27001 certificate only helps if its scope covers the service you use. Check this and file the certificate as evidence with a validity date.
Fourth, the possibility of failure is overlooked. Besides confidentiality, what matters is what happens if a vendor stops delivering. For critical vendors, record how you would proceed in that case.
