Vendor management
A frequent source of security or privacy issues originates from third party vendors. This is why it is important to properly manage all your vendors and keep track of the related contractual agreements, dependencies and their risks.
Vendor overview
Using our dedicated Vendor module, we give you a central overview on all the essential information related to your vendors. The general concept is that you create dedicated folders where you store all relevant information, with one document representing your vendor (document type "Supplier or subcontractor".
This document you can then link to all other related documents (e.g. data processing agreements, NDAs, terms & conditions, risks, vulnerabilities, ...)
And vendor document can be added to the vendor module by clicking the 3 dots and selecting "Add sas vendor"
Once the vendor is on the list, you can access it from the Vendors module on the left of the screen. A vendor will be visualised as following
- Here you can create a new vendor
- This search screen filters the list of vendors
- This checkbox loads additional risk information (risk document properties and last reading) and adds a color to the different risks. (once this is loaded you can sort on Related risks)
- Here you can configure which columns of the table should be shown and export the list to Excel
- This column shows the Vendor name (clicking on it will open the vendor document)
- This column shows the workbench checklist stage the vendor has been added to (if applicable). You can quickly change its status from this dropdown
- This column shows the vendor responsible (daily ownership), accountable (who takes ownership if a situation occurred), consulted (who can be reached out to for information or informed (those that just need to be informed)
- All tasks related to the vendor are listed here, and details can be viewed by clicking on them
- The data shown in this column is auto-generated based on linked documents to the vendor. On the add/edit vendor screen you can modify which document types are shown in this column). By clicking on one of the supporting assets, the related document will open
- This column lists all documents linked to the vendor, giving you a quick overview on all related items in one place (the document types shown in this column can also be configured by clicking edit)
- This is a free text field that defines the different business requirements of the primary asset (e.g. RTO, RPO, ...). You can find more details on this in the section Business requirements below.
- This column lists all risks related to the vendor. When the checkbox (3) is enabled, you'll see more details of the risks, including a color indication about its importance
Editing vendors is very similar to editing assets as described here
Business requirements
These requirements can be different depending on the management system you are trying to implement. Here we give an example of typical requirements for ISO27001 assets. You will typically need to organize workgroups with the different asset accountable (owners) to fully understand the requirements.
Confidentiality
This defines the level of discretion/privacy that is required for the primary asset (and therefore its supporting assets).
e.g. The personal data may not be accessed by unauthorised users
Integrity
This defines the level of integrity (or accuracy and completeness of data/information/process) that is required for the primary asset (and therefore its supporting assets)
e.g. The databases used for this service must ensure transactional accuracy
Availability
This defines the level of availability (having access when needed) that is required for the primary asset (and therefore its supporting assets)
e.g. The servers serving this process must be able to survive the full outage of 1/3 data centers
Proof
This defines the level of proof (documented evidence) that is required for the primary asset (and therefore its supporting assets)
e.g. The financial regulator requires that we store daily records of all transactions for this process
RTO
The recovery time objective (RTO) is the maximum acceptable time that an application, computer, network, or system can be down after an unexpected incident (disaster, failure, or comparable event) takes place.
e.g. Our SLA requires that this service is again online after 30min, otherwise this will be very costly to our company
RPO
The recovery point objective (RPO) is defined as the maximum amount of data – as measured by time – that can be lost after a recovery from an incident (disaster, failure, or comparable event) before data loss will exceed what is acceptable to an organization.
e.g. If we cannot restore data from at least 24h before the disaster, it will be fatal to our company
Regulatory
These can be specific requirements to the primary asset bound to geography, type of processing, type of data, ...
e.g. All processing of European data subjects is subject to GDPR regulation