Background Investigation Suggestions to Improve Process

The FDIC recommends 10 background investigation considerations:

1. Assess how the third party under consideration may pose a risk to your company, not by the title or level of a position, but rather by the level of access to information.
2. Make sure the third party is open and responsive to questioning about the background check process. Trust but verify, as the saying goes.
3. Ask about their background investigation vendors, and then conduct your own due diligence on those firms used by the third parties. Examine the processes and methods used to investigate candidates.
4. Don't hesitate to ask to see background-check forms. We've seen background reports where certain information contained in the report didn't seem right—and it wasn't. Maybe it was a phone number that didn't seem correct, perhaps an area code that doesn't exist. Yes, people actually make up telephone numbers and addresses. It may be worth knowing what type of telephone number was used by the candidate. Is it a temporary, prepaid number? Is it a registered mobile number, a home telephone, or maybe even a business telephone number? Is it the number of a family member, a friend, or other person?
5. Have the third-party firm supply references. And make sure that the references are consistent with your company. For example, if the third party is going to handle regulated data, check out companies that have engaged the third party to manage that type of information. The security and privacy requirements may be industry- or jurisdiction-specific.
6. Check the third-party breach history and the cause of any breaches. Were any breaches linked to failures in the background investigation process?
7. Ask what lessons were learned after any breaches and if those lessons were incorporated into the background analysis process.
8. Are employees ever reinvestigated?
9. What is the reinvestigation frequency and scope?
10. Are reinvestigations triggered by certain life events, or corporate events, such as a merger or acquisition?

The accuracy and effectiveness of background investigations of third-party employees is one of the best defenses against a breach and its consequences. Knowing who has access to your data, and whether they are trustworthy, is a mandatory tenet of strong corporate governance.

Failed background investigations have led to breaches of regulated information, from protected health information to customer financial information. In some cases there were complete breakdowns in the background investigation process, in which convicted felons passed criminal background checks. Almost unbelievably, such failures included company contractors who did not actually exist yet were still able to pass background checks. An enterprising entrepreneur created these identities, giving them names, addresses, cell phone numbers, and even Social Security numbers, and saw to it that each passed a basic background check. Enterprising, yes, but quite illegal, and these “contractors” and their creator were stealing customer financial information.

Who's to blame? As in many breaches of regulated data, as well as intellectual property and trade secrets, there is plenty of blame to go around. Companies often hold third-party vendors accountable only after there has been a breach. These same companies often conduct due diligence on third parties, but too frequently the process of determining the risk associated with any one third party is too costly and time-consuming. Plus, many vendors will simply walk away from companies that press too hard on the issue of security. Many of these third parties, and the companies that contract with them, will meet at the bar of accountability and information protection established by law and implemented by regulation. If a company utilizes hundreds or even thousands of vendors, it becomes difficult to manage them individually, at least until there has been a breach.

Another issue seen frequently is that many executives have long-standing relationships with preferred third parties. “We've been using them for 20 years and there haven't been any problems yet. We'll keep using them.” This is quite common, even when detailed due diligence clearly illustrates that the continued use of the third-party vendor elevates company risk. Sometimes the executive of the company and the vendor worked together previously and feel that loyalty is at stake, even if the corporate risk rises.

What the company executives either don't know or ignore in the hope that nothing bad will happen is that things change. This is especially true in the case of a long-term relationship. Nothing stays the same. Management changes, employees come and go, maybe some work goes overseas, some outsourced to other companies domestically. Regulations, standards, guidelines change, as do the efforts made by vendors to comply with the requirements of change. The financial integrity of the vendor could have changed: It could be near bankruptcy, or it could be the target of civil litigation or even criminal prosecution. When change happens, it's always a good bet to make sure that the change reduces risk, not elevates it.

Here's another thing. Statistics vary about the total percentage of third parties involved in data breaches. Some authorities suggest the number of breaches involving third parties is more than half, some less than half. Actually, the specific number isn't terribly important, but the trend is very important. The trend seems to point to an increase, perhaps because third-party vendors are managing more and more data. But here's another statistic, although not a broadly based one: In every breach investigation conducted by this author a third party has been involved in the breach. Every one. While this is admittedly anecdotal, when examining the entire industry it does illustrate the severity of the problem.

Third-party vendor relationships are typically managed through service level agreements. The problem? Many such agreements are drafted with a specific emphasis on legal enforcement provisions should the vendor fail to meet certain contractual requirements, productivity goals, and mandated regulatory minimum requirements for information protection and breach notification. This applies only to personal information that is subject to various government regulations. For vendors in possession of intellectual property and trade secrets, the last category, information protection and breach notification, may be absent or nonspecific because of no—or limited—obligatory public reporting requirements.

Before contracting with third parties, companies should carefully evaluate the risks of engaging third parties to manage certain kinds of information, who will have access to that information, where the information will reside, how it will be transported, whether it will cross jurisdictional lines, what regulations apply, what is the vendor's breach track record, and more. Many companies conduct extensive due diligence, pressing during the due diligence phase, asking hundreds of questions and demanding satisfactory answers and demonstrations of proof.

It may be helpful to shift from service level agreements to something like a risk-reinforced service level agreement (RRSLA). While many firms do a reasonable job in the due diligence phase, it seems, many do not, and this seems especially true in many smaller and midsize companies. RRLSAs focus on seven specific, detailed assessment points that assist the company in casting a broad net, yet a comprehensive one, over the third-party vendor relationship. In each of the seven points, which are discussed below, a detailed set of requirements is established, and so is documentation and the establishment of frequency of testing.

Companies must require documentation from vendors, demonstrations of proof that vendors have done what they said they were going to do and when they said they were going to do it. It isn't uncommon for companies to sign SLAs with vendors that state that the vendors must agree to specific requirements. Yet the reality is that companies many times do not check up on their third-party vendors, even when the SLA requires compliance with state and federal regulations governing information protection and breach notification requirements.

The result can be that the SLA, after being signed at the beginning of the relationship, is sometimes never looked at again by either party until the time comes to renew the agreement. There can be significant consequences to this. There are cases where (1) the SLA was signed by an employee, not an officer, of the third-party vendor; (2) the vendor was obligated to be compliant with U.S. federal, state, and international data privacy regulations but did not understand that it needed to be compliant; (3) the company never initially requested documentation demonstrating compliance and never did until a breach occurred. The breach in this case was significant. While the data management provider was at fault, there is no question that the company's customers shared in the blame. The customers failed to hold the vendor accountable by conducting effective due diligence, not only prior to signing the agreement but on a regular basis thereafter. Had the customers checked, the security lapses and failure to comply with both government regulatory requirements and contractual obligations would have been evident. It is likely that such due diligence would have reduced the impact of the breach, and perhaps would have prevented it altogether.

Of course, as with any program, there are varying levels of details defining each agreement. Every company must make a decision on how much detail to require. Admittedly, managing an increased flow of documentation isn't necessarily easy, and it can be costly as well. But the point is that today many companies are failing to make informed decisions about what they need to know about their service providers. Every company needs to make informed decisions about what to require, when to require, and how much documentation they need to review. It comes down to the company's appetite for third-party vendor risk.

This can be a difficult balance to achieve, based on innumerable criteria. Not all vendors need to have the same level of scrutiny. The measure of due diligence to be expended depends on what information will be in the possession of the third-party vendor and what services are offered by the vendor.

For personal financial data, the principal federal protective instrument is the Gramm-Leach-Bliley Act of 1999, also known as the Financial Services Modernization Act of 1999. A key component of the act is what is known as the Safeguards Rule. This is important for client companies as well as third-party vendors, because ultimately it is the client company's responsibility to protect the privacy of information. The Safeguards Rule requires companies to develop a written information security plan that describes their program to protect customer information. The plan must be appropriate to the company's size and complexity, the nature and scope of its activities, and the sensitivity of the customer information it handles. As part of its plan, each company must:

• Designate one or more employees to coordinate its information security program;
• Identify and assess the risks to customer information in each relevant area of the company's operation, and evaluate the effectiveness of the current safeguards for controlling those risks;
• Design and implement a safeguards program, and regularly monitor and test it; and
• Select service providers that can maintain appropriate safeguards, make sure the contract requires them to maintain safeguards, and oversee their handling of customer information; and evaluate and adjust the program in light of relevant circumstances, including changes in the firm's business or operations or the results of security testing and monitoring.

Risk-Reinforced Service Level Agreements

While the following is not intended to be a comprehensive instrument for managing third-party vendor risk, it does identify seven key risk issues to consider including in any SLA, turning it into a risk-reinforced service level agreement. These requirements are intentionally vague, allowing each company, based on its size and requirements, to develop its program within the required framework. Every company should develop its own RRSLA based on many individual factors making up its risk profile. Regulatory requirements, type of data at risk, budget, risk tolerance, and other factors will be considered in determining the level of effort that will be placed in the development of the RRSLA. The key is to make sure the third-party vendor is on board with the program. Here are the seven basic elements for consideration:

1. Information security. Information security is not the same as IT security, though the two terms are often used interchangeably. The difference between the two is one of both regulatory language and practical perspective. Under most regulatory guidelines, information security is comprised of technical or logical security, physical security, and administrative security. In a risk-reinforced service level agreement, it is important to make sure that all three types of security are recognized by the vendor. Information security requirements should be formalized and written in easy-to-understand language. Linking requirements to standards, regulations, and guidelines is important. The noteworthy standards and guidelines include the credit card requirement known as PCI DSS, or the Payment Card Industry Data Security Standard. PCI DSS applies to any organization that accepts, acquires, transmits, processes, or stores data that contains payment card information. The National Institute of Standards Technology (NIST), originally developed to help U.S. federal government agencies meet the requirements of the Federal Information Security Management Act (FISMA), is an excellent guideline. Many private-sector organizations use many elements of NIST to manage security operations. Another respected security standard is the International Standards Organization (ISO) 27000 security standard. These are not the only standards and guidelines, but they are valuable resources. Many companies use elements of multiple information security resources in order to more meaningfully manage risk. Some of the best frameworks governing third-party vendors are borrowed from multiple resources.

   Information security is the foundation for managing operational risk, so make this a priority when dealing with vendors and service level agreements. In other words:

   1. Be specific.
   2. Be detailed.
   3. Require regular reporting at reasonable, agreed-upon intervals. Even if the vendor fails to report, at least you have requested such meetings and reporting, which will prove useful in the event you need to deflect risk back to the vendor in the event of a cyber breach.
   4. Require written reporting in the form of documentation that meets regulatory as well as insurer requirements.
   5. Negotiate until satisfaction has been achieved. It is your risk and the company's risk.
   6. If it is impossible to negotiate successfully there may come a point at which it is time to disengage. Perhaps the vendor will give, perhaps not. But the issue is that it is unwise to accept risk beyond the risk tolerance established by the board of directors and the senior management team.
   7. Hold the vendors to the letter of the service level agreement. The key is in making certain that the SLA is tight and reflects the actual risk management goals.
2. Information privacy. A variety of U.S. federal, state, and foreign-country legislation governs the protection and privacy requirements of personal information. There are good resources available for the framework for managing information privacy, which should be reviewed when crafting any third-party vendor service level agreement. The Generally Accepted Privacy Principles (GAPP) represent a good starting point in examining privacy management. GAPP was developed by the American Institute of Certified Public Accounts (AICPA) and the Canadian Institute of Chartered Accountants (CICA). GAPP has a reasonable business definition of privacy. It states, “Privacy is defined in Generally Accepted Privacy Principles as ‘the rights and obligations of individuals and organizations with respect to the collection, use, retention, disclosure and disposal of personal information.’” GAPP establishes general categories of privacy as a frame of reference, which should be factored in:
   • Information on medical or health conditions
   • Financial information
   • Racial or ethnic origin
   • Political opinions
   • Religious or philosophical beliefs
   • Trade union membership
   • Sexual preference
   • Information related to offenses or criminal convictions

   GAPP articulates 10 useful privacy principles, which are essential to any organization and are especially important in developing the third-party vendor service level agreement:

   1. Management. The entity defines, documents, communicates, and assigns accountability for its privacy policies and procedures.
   2. Notice. The entity provides notice about its privacy policies and procedures and identifies the purposes for which personal information is collected, used, retained, and disclosed.
   3. Choice and consent. The entity describes the choices available to the individual and obtains implicit or explicit consent with respect to the collection, use, and disclosure of personal information.
   4. Collection. The entity collects personal information only for the purposes identified in the notice.
   5. Use, retention, and disposal. The entity limits the use of personal information to the purposes identified in the notice and for which the individual has provided implicit or explicit consent. The entity retains personal information for only as long as necessary to fulfill the stated purposes or as required by law or regulation and thereafter appropriately disposes of such information.
   6. Access. The entity provides individuals with access to their personal information for review and update.
   7. Disclosure to third parties. The entity discloses personal information to third parties only for the purposes identified in the notice and with the implicit or explicit consent of the individual.
   8. Security for privacy. The entity protects personal information against unauthorized access (both physical and logical).
   9. Quality. The entity maintains accurate, complete, and relevant personal information for the purposes identified in the notice.
   10. Monitoring and enforcement. The entity monitors compliance with its privacy policies and procedures and has procedures to address privacy-related complaints and disputes.

   Define information privacy for the vendor, and how it must be observed and managed. Information privacy is about how regulated information may be used and by whom. There are a great many variables, especially by country. Information privacy in the European Union, for example, is substantially more restrictive than in the United States. Define personally identifiable information (PII) for all applicable vendors. PII is diversified and includes, generally, the following types of information:

   1. Health care data (PHI, or protected health information)
      1. Names.
      2. All geographical subdivisions smaller than a state, including street address, city, county, precinct, zip code, if the “geographic unit formed by combining all zip codes within the same three initial digits contains more than 20,000 people; and the initial three digits of a zip code for all such geographic units containing 20,000 or fewer people is changed to 000.”
      3. All elements of dates, except year, for dates directly related to an individual, including birth date, admission date, discharge date, date of death; and all ages over 89 and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age 90 or older.
      4. Phone numbers.
      5. Fax numbers.
      6. E-mail addresses.
      7. Social Security numbers.
      8. Medical record numbers.
      9. Health plan beneficiary numbers.
      10. Account numbers.
      11. Certificate/license numbers.
      12. Vehicle identifiers and serial numbers, including license plate numbers.
      13. Device identifiers and serial numbers.
      14. Web uniform resource locators (URLs).
      15. Internet protocol (IP) addresses.
      16. Biometric identifiers, including fingerprints and voice prints.
      17. Full-face photographic images and any comparable images; and
      18. Any other unique identifying number, characteristic, or code.
      19. It should also be noted that there are additional standards and criteria to protect an individual's privacy from what is called reidentification, according to the Committee on Human Research at the University of California. What this means is that any code that is used to replace the identifiers in datasets cannot be derived from any information related to the individual and the master codes, nor can the method to derive the codes be disclosed.
   2. Genetic data
   3. Ethnicity
   4. Criminal proceedings
   5. Geolocation data
   6. Other

   But GAPP is also about unregulated data, including intellectual property and trade secrets, which need to be kept confidential. Information privacy means not only protecting the information from theft, but also protecting it from compromise such as change in the data. So information integrity must be part of the mission to ensure that information is guarded, from inside and outside the vendor environment. Specify what data needs to be protected! Make reference to what data is regulated by law and what must be done to protect that information. Most important, make certain that there is an understanding with the third-party vendor on what the requirement is to treat information in their custody. Included should be information in any digital form, as well as information in paper form. This is no time to be vague or imprecise. Don't let the vendor make any assumptions: Stick to the facts as you define them.

3. Threat and risk analysis. A number of regulations require that companies, and therefore third-party vendors, perform risk assessment. Don't just casually accept any risk assessment conducted by a third-party vendor. Remember that the goal is not just to meet—and have third-party vendors meet—a regulatory requirement. The goal is to protect information and see that others entrusted with that responsibility protect it, too.

   Make it meaningful. Make sure that the analysis of risk is linked to the actual threats facing the company and the third-party vendor. For example, consider the insider threat. What has the vendor done to measure that risk? How carefully have such vendors examined their own background investigation process? What are the actual threats that have been considered in their risk assessment? Have they looked at the full spectrum of likely threats facing them? How have these threats been interpreted in terms of risk? Have they examined the legal, regulatory, financial, and reputation risk arising from an event?

   Determine from where the vendors are receiving threat information. Is it consistent with what is required to actually protect information? Here's an example. Suppose that the vendor has offshore operations and that data is under management there. Then suppose that the country is one with a significant level of corruption, organized crime, narcotics trafficking, social protest, and so on. In instances where there is heightened corruption, fraud, and other criminal activity, there is greater risk. Then consider how technology and culture enhance the threat and the risk to companies. How does the third-party vendor manage its employees and contractors with respect to the use of social media? Does the vendor have a “bring your own device” policy? There's the risk of hiring employees and contractors who may be engaged in illegal and unethical activities, or who are simply careless with the information they post on social media sites and keep on their personal devices. Consider if the principal company factored these concerns into its own risk equation, and then factor this into the third-party vendor risk.

   A word about the social protest threat. Social protest, in most cases, is legal, and even desirable. It is a fundamental precept of a free country. However, many protest groups have the desire and the ability to disrupt the flow of information. It is also well established that hacker groups, and even terrorist groups, try to co-opt some protest groups. So the real issue is not that a region or a country may have active social protest groups, but whether those protests have the ability to interfere or disrupt information management. If so, what mitigation measures have been put in place by the third-party vendor? Have those measures been evaluated and tested? Has the need for change in policies or monitoring been required?

   Another measure of the threat and risk conditions at the third-party vendor is the breach history. While many vendors are reluctant or intractable on the issue of such disclosures, it should be a point for negotiation between parties. But let's define breach. A breach is not only a breach of data that must be reported to state, federal, and foreign-country authorities. Many breaches, for a variety of reasons, are never reported to regulators. For the purposes of negotiation and agreement in a written contract, a breach should also be defined as a breach of security policy and procedure.

   This requires the third-party vendor to disclose not only its breach history regarding regulated data, but also, if specified, any security incidents or breaches involving intellectual property and trade secrets. Making a decision about a third-party vendor, if it is to be handling any type of sensitive information, requires understanding its threat environment and the risk potential. Arriving at a decision about its suitability to handle that information simply cannot be done without understanding the full dimension of its historical risk performance. If the vendor decides that it should refrain from answering these probing questions, then the client company can at least make an informed decision about whether or not to engage a specific vendor.

   There's often a gap between what companies and their third-party vendors believe is important. Understanding the threat and risk environment shouldn't be one of those gap areas. One of the best ways to think through the process of creating a trusted vendor relationship is simply this: Think postbreach, act prebreach. In other words, think about managing the risk from the perspective of a severe data breach. How could the breach have been averted? What steps could have been taken, what policy changes would have prevented the breach? Was it a technology issue? An organizational management issue? Was there a violation of regulation?

4. Regulatory and industry compliance. One of the measures of a third-party vendor's ability to successfully manage information risk is its regulatory and industry standard obligation to do so. Admittedly, the ability to comply with regulatory requirements around security and privacy is an example of mandatory minimum compliance. That may seem like a reasonably low bar. And maybe it is. But there are a few things to consider. First, many regulations are being strengthened, and at just about every level: federal, state, foreign country. This doesn't necessary mean that these regulations will be successful in preventing data breaches, but it does mean that companies will be held to a higher standard and that the mandatory minimum will be enhanced. However, regulation will never rise to the highest level of information protection, and that should also be considered. Second, a mandatory minimum is better than no minimum. Third, it provides a metric of measurement. Fourth, in cases of reported breaches, it is easier to determine how the breach occurred and what was done to mitigate that risk going forward.
5. Internal audit. Negotiate for as much access to the third-party vendor's internal audit reports as possible. These reports can be invaluable in determining how the company audits itself, what it is able to detect and prevent, and what it has not been successful in detecting and preventing. Additionally, require the third party to accept a provision in the service level agreement for audit on demand by the client company. This requirement is especially important in certain foreign countries, where the internal audit process by the third-party vendor may not be as accurate as it may be in other countries. Being able to audit on demand that third party is important because it minimizes the opportunity for the vendor to obfuscate, and maximizes the ability of the client to probe virtually any aspect of the operation. Depending on the size and expanse of the client company, the audits may be conducted by professionals in-country or within the region. Or, alternatively, dispatching a team from corporate headquarters may be an option. It's important to make sure that the third-party vendor understands the language of the client company.
6. Foreign corrupt practices management. As mentioned elsewhere in this book, understanding the potential for corruption is increasingly important. This is, absolutely, an area well understood by the board of directors. A number of nations are cracking down on corruption, but it still exists. Refer to the Transparency International Corruption Perceptions Index when determining the prevalence of corruption in a particular country. While it is not an exact measure, and is based on perception, it is a useful metric in measuring and managing risk.

   Examine the third-party vendor's whistleblower program. Not every company has such a program, but they have proven to be effective tools in managing the risks associated with corruption. Whistleblower programs provide an outlet for employees to alert management of bribery and other corrupt practices. Have the vendor disclose the program details. Minimally, require the vendor to disclose:

   • When did the program go into effect?
   • Who, by title, is ultimately responsible for managing it and overseeing it?
   • Is it anonymous?
   • How is the whistleblower protected?
   • Is the program deployed in multiple jurisdictions?
   • Is each jurisdiction monitored for regulatory changes?
   • How is information conveyed in the program: e-mail, web site, telephone, text message, and so on?
   • What is the use history and frequency?
   • What actions were taken?
   • What was the resolution?

   Increasingly, corruption is a critical element in successfully managing reputation risk. As in the case of data breaches, findings of corruption can have a variety of risk impacts on any company. The business press, in particular, has demonstrated an interest in covering corruption, and is usually aggressive in its coverage.

   It is important to work with legal counsel on this issue. Make sure that the anticorruption program covers every country in which the third party operates. Oftentimes the client company does not verify the details of the third-party anticorruption program or verify any history of corruption in the third party. While larger client enterprises are more likely to have an anticorruption requirement and program to verify the details specific to the third-party vendor, many small and midsize companies lack this critical due diligence effort. Minimally, it is important to at least have the vendor verify in writing:

   • The existence of the vendor's anticorruption program, its mission statement, and its operational framework.
   • Its history of anticorruption measures and any legal or regulatory actions taken against the vendor regarding corruption.
   • Whether there is any pending litigation or regulatory action specific to corruption in any country.
   • If there is pending litigation or regulatory action, whether that will have the potential to in any way imperil the reputation of the client company.
   • The scope beyond vendor verification. Conduct an online search of the media to independently verify, to the extent possible, any information about the company and its relation to any corruption. While it may be less likely that large, reputable vendors may purposefully not disclose any such information, there are some vendors that may be less likely to make such a disclosure. It is also not unheard of for large third-party vendors whose operations span dozens of nations not to possess current knowledge about actions taken in foreign jurisdictions. This is why it is important to actually look at how such programs are monitored on an ongoing basis.
   • Whether the program is an element of the vendor's corporate governance program, and how often it is addressed.
7. Enforcement. In the event the third-party vendor fails to meet the requirements laid out in the service level agreement, it is necessary to have an enforcement program in place. Enforcement should be proportionate to the event. It should be reasonable. Few companies are going to cancel an agreement because its third-party vendor lost a BlackBerry with a few customer names on it. Of course, the circumstances and the profile of the lost identities always play a role in the outcome. However, a major breach of personal information or the loss of highly valuable intellectual property or trade secrets is a different story.

   In one case, an executive signed a lucrative third-party vendor agreement with an old friend. They had worked together previously in another company. An after-the-fact assessment of the third-party vendor's security illustrated a number of crucial deficiencies. The scope and dimension of these deficiencies would clearly lead to a data breach at some point, and maintaining the agreement was not justifiable. It cost the company a substantial amount of money to get out of this contract because there were no real enforcement measures in place.

   The client company should have made provisions in the contract about vendor security as a condition for agreement cancellation. But it wasn't there. Not only was there a difficult business negotiation, but it likely stressed a friendship as well.

   In part, this is a decision that should be discussed in the risk committee of the board of directors as part of an information governance program. Information is valuable. In some companies it is the dominant value. In some companies it is also the prevailing risk. The risk committee of the board, especially if it is well informed, would want to know about which companies are handling its data. Too much detail for the risk committee? In the event of a breach, one that proved costly in regulatory, legal, financial, and reputation risk, who would want to be the bearer of the bad news? The bad news, in addition to the breach, is that it turns out that the third-party vendor managing the data had a flawed history when it comes to managing customer data.

   The first question such a board committee might ask is, “Why didn't we know this about the vendor?” The next question might be, “Who made the decision to use that vendor?” No chief information security officer or chief risk officer, or any executive serving in that line of authority, including the general counsel, wants to be called into the next meeting of the risk committee.

   How will the third party be required to make demonstrations of proof, in writing, as to the assessment of the risk posed by the aforementioned operational environment? Every nation has complementary risks as well as unique risks. It is important to understand these distinctions when making decisions about the use of third-party vendors.

   Vendors can be slow, uncooperative, and even recalcitrant in providing information regarding a cyber breach. Without accurate, timely information from vendors, companies cannot make reasonable judgments relative to the operational risk profile. There is no meaningful management of risk without vendor commitment to accountability.

   Historically, vendors have had superior positioning by using vendor agreements, such as the master service agreements and service level agreements, for example. Vendor agreements will also favor vendors. While some vendors are not open to negotiation, others are. Even if vendors won't budge on terms, it is critical, from a cyber risk management perspective, to put the terms on the table for negotiation. It is important to be able to demonstrate, in writing, that attempts were made to negotiate terms essential to managing cyber risk. If the vendor won't agree, a decision has to be made about whether to move forward with the agreement. Either way, you will have at least addressed the issue. Managing cyber risk isn't always about getting your way. It's about making decisions that have the potential to imperil the organization or protect it.

8. Assign a vendor accountability executive. Get every vendor to designate a single person (who has solid knowledge of the vendor controls) who will work with you and who will have the obligation to convey any information necessary to ongoing cyber risk management. This is important because oftentimes information of value gets siloed or, for whatever reason, doesn't get properly conveyed. While it may be easy to establish this requirement with new vendors, it may be more difficult with existing vendors until contract renewal. Additionally, as part of the planning process, negotiate meeting quarterly with the vendor. Of course, this is not always necessary, but it is for higher-risk vendors. Meetings may be in-person or held as conference calls, subject to preference, venue, and availability. In the event of a Severity-1 breach, the meetings should be held in person when possible unless extraordinary circumstances prevent it.

   If the vendor chronically fails to produce desired documentation, for example, an on-site meeting should be pursued. There should be a formal accounting of the meeting, always in writing. The accountable vendor executive and your cyber risk executive should follow up on all open issues. The meetings are essential for managing issues and outcomes, and having them also conveys the message that you mean business. If you treat the cyber breach lightly, delay responding, and/or don't show up on site, vendors may get the idea that you aren't taking the breach seriously—which may lead them to take it less seriously as well. On-site meetings with vendors are viewed positively by regulators and are consistent with evolving regulatory expectations and insurers.

9. Initiate a master service agreement. The MSA should be issued by the client company, whenever feasible. While this is not always acceptable to vendors, it very often is. Having a vendor issue the MSA often provides the vendor with an advantage. Among other specifics required for inclusion into the MSA, you should specifically designate what the vendor should do in the event of a cyber breach. The vendor often defines what must be done post–cyber breach. That isn't likely to favor your organization. Consider negotiating into the agreement language that addresses the following:
   • Define losses. Losses should be defined as all losses, liabilities, damages, and claims and all related costs and expenses (including reasonable legal fees and disbursements and costs of forensic investigation, litigation, settlement, judgment, interest, and penalties). In the event of a cyber breach, negotiate that the defined losses should be covered by the vendor. This includes legal and breach investigative costs.
   • Security breach response. A lot of companies make a mistake here. You want to be notified by the vendor immediately but not more than 24 hours after the identification of the suspected cyber security incident. Establish that any suspected breach involving a security violation is rated as a Severity-1 event. Any Severity-1 incident requires the vendor, at its own cost and to be initiated immediately, to conduct a root cause analysis of the incident. The root cause analysis procedure should be conducted under the jurisdiction of the office of the general counsel in order to establish and maintain attorney-client privilege with respect to all incident work product. Progress reports of the root cause analysis must be provided on a regular basis. You determine what constitutes “a regular basis.” It is recommended that a formal call and readout of the findings be convened daily between the vendor and the customer. The vendor must, at the conclusion of the root cause analysis procedure, present its findings and conclusions, as well as its remediation plan.

   Require that the report from the vendor should be written for a diverse audience of interested constituents, including management, internal and external legal counsel, corporate customers, and various state and federal regulators, as appropriate. The reason to specify this in any agreement is that some vendors may present only a technical definition of the cyber attack and resulting losses. The greater the definition of the required documentation from vendors, the more useful the reports. The reporting from the vendor must enable you to adequately define the cyber event and the measures needed to manage and remediate the conditions contributing to the cyber breach. The reporting from the vendor should include the following required elements:

   • Executive summary for management.
   • Technical summary.
   • Description of the intrusion or incident.
   • Date(s) of intrusion or incident.
   • Description of compromised data.
   • Description of preliminary mitigation.
   • Define the characteristics of the breach condition.
   • Define forensic investigation requirements.
   • Oversee forensic examination of devices.
   • A description of the technical environment impacted.
   • Presentation of a preliminary risk management and mitigation strategy.
   • Presentation of applicable vendor insurance policies.
   • Establish evidentiary chain of custody regarding breached devices.
   • Presentation of results of vulnerability scans on specified devices.
   • Presentation of vendor status in monitoring the status of any compromised information to determine if illicit use in the gray market had been commenced.
   • Presentation of strategy to monitor the web for any continuing and future brand compromise.

Clouds Fill the Horizon

Embraced as a critical growth strategy by leading U.S. and foreign companies, cloud computing makes a compelling argument in the global economy. The attraction of cloud computing is that companies can expand operations using someone else's technology and at a fraction of the cost of purchasing new technology. Even President Obama is aware of the benefits of migrating electronic medical records into a cloud computing environment as one method of containing out-of-control health care costs. The future of cloud computing seems clear. But does it introduce a different set of risks? A number of emerging risk issues around cloud computing are building like a global storm front. In fact, a 2011 survey conducted by cloud computing vendor IBM indicated that 77 percent of respondents were concerned that cloud computing would increase privacy risk.

Clouds are emerging from virtually every geography, and if clouds currently do not exist in a geography, it seems certain that they will in the next few years. There's a lot at stake; clouds represent a lot of growth and a lot of revenue. Reflecting on the value of the cloud market, the press for market share is already here, and there are diplomatic, political, as well as economic issues in the mix. For example, cloud providers in the European Union charge that cloud providers in the United States should not be used by EU companies. The allegation? That the Uniting and Strengthening America by Providing Appropriate Tools Required to Intercept and Obstruct Terrorism, otherwise known as the USA Patriot Act, gives the United States easy access to personal information stored in U.S. cloud providers. Of course, other nations have low barriers to access to acquire sensitive personal information as well, especially when such information is relative to national security.

It is reasonable to think of clouds as the third-party vendors of the future, where a new generation of providers based in developing nations offer financially competitive storage and data management models. However, there are issues to think about from a cyber risk perspective, and these are questions that must be asked now and in the future. Some of these questions include:

• Who are the owners of the cloud computing organization?
• Are governments with contrary interests involved?
• What is the level of organized crime in that host nation?
• What are the local privacy and data breach laws and regulations?
• What is the level of corruption as evidenced in the Transparency International Corruption Index?
• Is insurance applicable when data is in certain offshore clouds?
• Will it be more difficult to manage and monitor agreement compliance?
• How often should offshore cloud sites be visited and tested for compliance?
• Does the cloud entity use virtual currency? If so, what protections are in place to limit exposure to transnational criminal enterprises?
• Would a cyber war increase information risk because of the geographic location of the cloud operation?
• Would data be more susceptible to a terrorist threat because of its location in a cloud environment in another nation?
• How are background investigations conducted on cloud employees?

This list can be extensive and should reflect the comprehensive questions posed during due diligence of traditional third-party vendors.

Ten top security and privacy executives at an investment conference in New York City were asked this question, “Would you place regulated customer data in the cloud, even if it was encrypted?” One executive from a Japanese firm was the only one who answered that sensitive information would be placed in the cloud. Every other executive answered no, even if the data was encrypted. Their reasoning was simple: No one really knows what level of encryption can be compromised by a government dedicated to breaking it. Data collected over the course of a specified period may not be breakable at the time during which it was acquired. But eventually the data may be broken, and that was a risk the nine security and privacy executives were not willing to accept. The benefit of clouds, in this case, was not worth the risk.

In fairness, though, it must be noted that all third-party vendors, including clouds, are not equal. Some companies will improve their cyber risk exposure by using external vendors, again, including clouds. Why? Because these external organizations will have cyber risk management controls that will prove superior to the client company. Cyber security is expensive, and many companies are not willing or able to invest in the protective mechanisms offered by third-party providers.

Dr. Lothar Determan, a privacy attorney in the Palo Alto, California, office of Baker & McKenzie, writes, “Whether personal data is safer on a system secured by the data controller ‘in-house’ or on an external vendor depends on security measures deployed by each particular organization. Moving data to the cloud can be a bad thing for data security if the vendor is weak on security and careless. It can be a good thing if the vendor brings better technologies to the table and helps the data controller manage access, data retention and data integrity. And it can be neutral if the vendor's cloud system is more secure, but the way the customer uses the system keeps exposing the data (e.g., because the customer does not configure security to properly restrict data to the appropriate users, the customer uses unsecured connections or the customer downloads data from the cloud to unsecured local devices).”³

No one should be under the illusion that such negotiations with traditional third-party or cloud vendors are going to be easy. Some will prove to be productive; others not. But the key consideration is that these negotiations are fundamental to more effectively negotiating agreements that will assist in managing the risks associated with cyber attacks. It is also worth restating that obtaining approvals from vendors is not the only goal. Vendors will give on some issues, and not on others. A lot of factors will be under consideration by vendors. The other goal is to at least attempt to negotiate key elements of the agreements, document all such attempts, and clearly illustrate that all elements of managing cyber risk were addressed. It may not be feasible to change every agreement to your advantage, but it is possible to include in the discussions and negotiations all of the elements pursuant to cyber risk. In the event of a cyber event, you will at least have the documentation needed to defend your prior courses of action and orient the outcome to the extent possible under the restrictions associated with the agreements in place. This alone, deflecting risk, is worth the effort.

A number of risk-related executives have asked the question, “If we know the vendor isn't going to budge, why try to negotiate the point?” The answer is this: You want to be able to demonstrate to the board, to insurers, and to any other interested parties, that the issue was addressed, that the vendor remained unmovable on the point, but that you pushed that agenda. In the confusion and energy that accompany a cyber breach, it is easy to lay blame and to point fingers at who may be at fault. Judgments will likely be made that will linger, as doubt will grow as to whether the correct decisions were made and the appropriate level of due diligence was applied to the vendor that is now associated with the breach. The aftermath of the cyber breach will carry threads of doubt that were raised early on during that stage of confusion. It is important to demonstrate, through the offering of documentation, not only what the vendor was required to do, but also what the vendor had not agreed to do but which you had firmly recommended. Or sometimes failures in negotiation are indications that it is time to move on to another vendor.