Think of 'insiders' when drafting and implementing security policies

By following a few simple steps, the risk of vendor personnel using customer systems can be greatly diminished.

employees technology planning data [Computerworld, January-February 2017 - HR IT]
Thinkstock

To build upon my previous articles about security threats posed by vendors, today we focus on a very specific and frequently overlooked element of vendor risk mitigation: vendor personnel working within customer facilities and using customer systems. 

Most businesses today have security policies and procedures in place with regard to their own personnel.  Some even expressly extend those policies and procedures to their agents, contractors and vendors.  Few, however, take the time to truly address the issue of ensuring vendor personnel are actually presented with and bound by those policies and procedures while performing services for the customer.  Fewer still include specific language in their vendor agreements that make this important concept clear.

Below, I discuss some key issues about this risk, real-world examples of this risk playing out and I also provide example language for how this risk can be better mitigated in vendor contracts.  In addition, while this post focuses on vendor personnel, don’t forget temporary workers and contingent workforce personnel.  They should also be considered in mitigating this risk.

Almost every business has a range of vendors and vendor personnel on site at their facilities, rendering services on an ongoing basis.  In some instances, those personnel may be on site for weeks or even months using the customer’s systems, sitting in customer-furnished offices and walking around customer facilities.  As such, those personnel should be appropriately trained by customer staff and bound by the same security policies and procedures as the customer’s own personnel.

One of the key areas for risk mitigation is ensuring the vendor personnel are bound by the customer’s technology use (or similarly named policy) which governs an individual’s access to and use of the customer’s networks, computers, mobile devices, storage media, etc.  Among other things, these policies make clear how and to what extent an individual may use the customer’s systems, their responsibilities to secure those systems and their privacy expectations with regard to information created, stored, accessed or transmitted through those systems.  Every business should have a policy of this kind and it should apply to every user of that business’ systems, regardless of whether that user is an employee, temporary worker or the employee of a third-party vendor.

Here are two real-world examples of how this risk can play out:

  1. In the first case, a company hired a nationally recognized consulting firm to perform a large professional services project. Vendor personnel were issued company-furnished e-mail accounts.  During the course of that project, the customer came to believe the consultant was over-billing for its services.  The customer investigated by, among other things, looking at the consultant’s use of the e-mail accounts it had provided.  The customer quickly discovered consultant personnel were working on unrelated matters for other businesses and double-billing their time.  When the customer sued for damages, the consultant defended, saying that the customer had no right to review the very e-mail accounts it had furnished to the consultant.  That is, the review violated the privacy rights of the consultant.  If the vendor had been bound by the customer’s standard technology use policy, this privacy dispute would have been avoided.
  2. As another example, a technology company engaged a quality-assurance vendor to provide input regarding code under development by the customer. As part of the services, a vendor employee worked on-site at the customer for several months.  Without the customer’s knowledge or authorization, the vendor employee uploaded almost the entirety of the customer’s highly proprietary code-base to their personal cloud storage account.  This resulted in the customer losing control over its most valuable asset (i.e., its source code).  While the customer should have had controls in place to prevent the upload of such large files in the first place, its primary failure was not ensuring the vendor employee was properly trained and bound by the customer’s technology policy, which expressly prohibited movement of source code outside the customer’s firewall.

To mitigate these and the many other risks that flow from vendor use of customer technology systems, consider a three-prong approach:

1. Update vendor contracting practices

In situations where vendor personnel will be on site at customer facilities and systems, language should be added to the vendor contract, making clear that system use and access will be controlled and subject to the customer’s generally applicable security policies and procedures.  The following is an example of such language (this is strictly an example and is not to be used in a contract):

In performing this Agreement, Contractor may receive access to Customer’s networks, computers, and electronic communications systems (“Systems”), including but not limited to voicemail, email, customer databases, and internet and intranet systems.  Such Systems are intended for legitimate business use related to Customer’s business and the performance of the Agreement for Customer’s benefit.  Contractor acknowledges that Contractor does not have any expectation of privacy as between Contractor and Customer in the use of or access to Customer’s Systems.  Contractor understands and agrees that Contractor personnel accessing or using the Systems will be required to accept and be bound by the same policies and procedures governing Customer’s own employee’s use of those Systems.  Customer reserves the right, for business purposes, to monitor, review, audit, intercept, access, archive and/or disclose materials sent over, received by or from, or stored in any of its electronic Systems.  Contractor further agrees that Contractor will use all appropriate security, such as, for example, encryption and passwords, to protect Customer’s Confidential Information from unauthorized disclosure (internally or externally) and that the use of such security does not give rise to any privacy rights in the communication as between Contractor and Customer.  Customer reserves the right to override any security passwords to obtain access to voicemail, email, computer (and software or other applications) and/or computer disks on Customer’s Systems.  Contractor also acknowledges that Customer reserves the right, for any business purposes, to search all work areas (for example, offices, cubicles, desks, drawers, cabinets, computers, computer disks and files) and all personal items brought onto Customer property or used to access Customer Systems.

2. Provide policies to vendor personnel

Ensure vendor personnel receive and are given clear instructions to review the customer’s relevant security policies and procedures.   All too often, these critical policies are provided in a mass of other information at the start of the engagement and are never actually drawn to the attention of the personnel and certainly never read.  The vendor personnel should be required to acknowledge in writing that they have received, read, and understand the policies.

3. Train vendor personnel

Training does not have to be expansive, but most vendor personnel should be provided at least basic training regarding the customer’s security controls and procedures.

By following these simple steps, the risk of vendor personnel using customer systems can be greatly diminished.  They should be considered in every engagement in which vendor personnel will have access to those systems.

[Disclaimer: The information on this blog or article is provided without any warranty or guarantee, does not provide legal advice to the reader, and does not create an attorney-client relationship with the reader. Any opinions expressed in this blog or article are those only of the author and do not necessarily reflect the views of the author’s law firm or any of the author’s or the law firm’s clients. In some jurisdictions, the contents of this blog or article may be considered Attorney Advertising.]

This article is published as part of the IDG Contributor Network. Want to Join?

NEW! Download the Winter 2018 issue of Security Smart