Guidelines for Low Risk Engagements


What this document is

This document supports the Vendor Security Assessment (VSA) process. It serves as a starting point for low-risk vendor engagements which do not require a full assessment through the VSA process.

In order to keep this document relevant over time, we have refrained from providing detailed guidelines and recommendations and have rather focused on introducing core concepts which vendors can look into and implement according to current security best practices.

This document is designed as a guide for vendors only, and we do not require confirmation that these recommendations have been implemented partially or in full. It further does not override any regulatory requirements that may apply to your business.

What this document is NOT

This document is not a complete guide describing how to secure a company. It is only a collection of current best practices and recommendations. The reader is encouraged to go beyond these guidelines and, if necessary, seek external security consulting to support their security improvement efforts.

Who should read this document

This document should be read by vendors and their IT team in cases where they have not been required to undergo the full standard VSA process.

Access Control

The objective of access control mechanisms is to determine who a user is (authentication) and if the user is allowed to do something (authorization).

Two key concepts of access control are:

  1. Principle of Least Privilege

    The idea of this principle is that a user account is only given the privileges that this user needs to perform their work tasks.

    For example: Sarah works in a small company as a UX researcher and also maintains the server storing their participant database. At times, Sarah needs to install an update on the server for which she needs to be an Administrator. This principle dictates that Sarah’s user account only has the highest privileges (Administrator) when she needs to update the software.
  2. Need-to-Know Principle

    The idea of this principle is that a user account is only given access permissions to content when the user requires this access to perform their work tasks.

    For example: John and Stacy are UX researchers. While John works on a UX study for customer Y, Stacy works on a UX study for Google. This principle dictates that Stacy cannot access the UX study for customer Y, and John cannot access the UX study for Google.


Authentication is usually understood as the process during which a user presents their username and password to be granted access to a service or system.

Important for authentication is that the user has chosen a strong and secure password. See these tips.

However, to prevent being compromised if someone e.g. guesses or steals your password, it is best to use Two-Factor Authentication. This means that the user needs their password and an additional factor in order to authenticate. An example for this is 2-Step Verification for a Google account.

Network Management


Firewalls are used to filter network traffic based on a specified rule set.

A general recommendation is to block all unsolicited incoming traffic. This is traffic which is not a response to a request that originated from your internal network.

What is often forgotten is that outgoing traffic should also be restricted to allow only the traffic which you would expect during normal operation.

If your company has a server which needs to receive requests from the internet (e.g. email server, web server, etc.), then it is a best practice to separate these servers into a DMZ zone.

Network Encryption

Regardless if your network traffic is internal or external (to the internet): You should configure your services and applications to always use secure (encrypted) network protocols, especially if sensitive data is being sent (e.g. passwords, study data, etc.).

Wireless Networks

If your company network contains a wireless (Wi-Fi) network, then your network must be secured from unauthorized access by using WPA2.

Ideally, you would employ WPA2 Enterprise which uses a RADIUS authentication service. However, if WPA2 with a pre-shared key must be used, then follow these rules:

  1. The pre-shared key (also commonly known as the Wi-Fi password) should meet the same criteria as described in the Authentication section above.
  2. The pre-shared key should be changed at least once a year.
  3. The pre-shared key must be changed when an employee who knows the key has left the company.
  4. The pre-shared key must not be shared via email, post-it, or otherwise in plaintext writing.


The network protocol for email sends the message in plaintext by default. However, solutions exist that allow encrypting the emails sent from your mail server. You should enable Opportunistic TLS to ensure email is encrypted in transit.

If you are using a common webmail provider like Gmail or Office365, your provider is already doing this for you.


VPNs can be used to access a company network from remote locations (e.g. from home). VPN access should also be protected with a firewall (see above) and only company-managed devices should be allowed to connect to the VPN.

System Management

We combine the discussion of server and client (workstation or notebook) in one section, as common system-security practices are shared between these two types of systems.


Hardening describes the process of securing a system by reducing the footprint of the system. A general guideline is to remove any unnecessary software, unused user accounts, and unused services.

However, there are different detailed hardening guidelines for each operating system (OS). These can be downloaded from the Center for Internet Security, where they are published as so-called CIS Benchmarks. There are also CIS Benchmarks for commonly used software, and mobile and network devices.

In order to reduce the work effort, it is advised to create a hardened standard build that can then be used for every new server or client that needs to be installed.

Disk / Storage Encryption

Regardless if the system is a server, a workstation, a notebook, or a smartphone, we highly recommend that you make use of the widely available disk/storage encryption features of the OS:

System / Software Updates

It is always possible that a new vulnerability is discovered in the OS you are using and we strongly recommend creating an automated update process for your OS; it should run on a regular basis to keep your systems up to date.

This also concerns software which is installed on top of the OS. Unfortunately, the updates of the OS do not include updates for additional software. We recommend regularly checking for updates or, if possible, signing up to update notifications from the manufacturers.

Scan for Malware

Your systems should be equipped with a malware scanning software like an AntiVirus program that regularly scans the systems for known malicious software that could be running.


In case of a system failure it is important that you can recover the lost data. For that purpose, you should run automated backups on a regular basis.

Your backups...

  • ...should be encrypted.
  • ...should be stored in a secure location (ideally offsite to enable disaster recovery).
  • ...should be access-restricted to a limited number of privileged users.

Keep in mind that your backups contain sensitive data.

Consider also testing your restore process on a regular basis to ensure that the backup was created as intended and that potentially lost data can be restored from the backup source.

Logging / Audit Trails

Logging is important to detect a security intrusion and reconstruct what happened.

All common OSes generate security logs by default, but you should also configure your systems to send logs to a central collection point. This is usually achieved by using rsyslog for Mac and Linux or Windows Event Forwarding for Windows – both can be used to send logs to a SIEM system.

In order to be able to reconstruct security intrusions even after a long period, it is vital to ensure long-term log storage and retention. Many attacks are discovered only months later, and if you have not retained logs from that time, you will probably be unable to determine what the attackers stole or damaged.

Was this helpful?

How can we improve it?

Need more help?

Try these next steps:

Clear search
Close search
Google apps
Main menu
Search Help Center