Data Privacy

Ensuring data privacy requires asking the vendor high‐level questions about how they approach data privacy. Focus on yes or no, Boolean‐type questions to ensure clear answers to questions and make quick assessments. For example, “Do you encrypt customer data and at what level?” If your company is a U.S.‐based company that doesn't want to have data in the EU and wants to avoid direct contact with GDPR jurisdiction, for example, you would be concerned about data location. If the data is Personal Health Information (PHI), additional questions are possible, such as “Are you Health Information Trust Alliance (HITRUST) certified?” If they are doing credit card processing, then a question about their Payment Card Industry Data Security Standard (PCI‐DSS) certification is needed.

Cybersecurity

Cybersecurity requires that you first ask a few simple questions to assess if the vendor can meet criteria to require further due diligence. Cybersecurity due diligence can take some time to complete, as the topic's complexity can lead to more communication to settle any risk concerns. If the vendor doesn't meet the criteria, then they wouldn't require a cyber review and can move to the next step. First, you need to know if they have data that requires protection. This level of protection depends on your data classifications, and the key is deciding the level at which your company requires the data to be protected outside its own network. KC Enterprises, for example, declared that its top three tiers of data classifications, by policy, require protection.

Because the intake process should be quick, getting all the information and performing an honest appraisal of data can be challenging. Who is performing the assessment of the data elements that, by themselves, may be fine but in combination add up to personal identifiable information (PII)? The data privacy regulations that nearly all of us are now subject to, no matter where we live in the world, are often not very easy to understand. This needs to be done by an expert or via some level of investigation by someone with the skills to perform the proper due diligence.

The next dilemma in many typical third‐party due diligence efforts revolves around checklists. Due to the number of vendors and people involved in an onboarding process, much of the work can be accomplished using a series of checklists to ensure due diligence is performed, such as ensuring that certain tasks are completed and that milestones are achieved. However, security itself isn't a checklist—it's an ongoing activity. Active security departments may deploy checklists to ensure that certain process upgrade tasks are accomplished, but cybersecurity and information security require something besides checklists. They require conversations between a business and its vendors.

The IRQ contains checklist items to help determine the level of risk for the vendor and a new service/product. However, when certain risk criteria are triggered, it should initiate a conversation with the vendor. While it may not require an actual phone call, it could instigate a process (manually or through your workflow tool of choice) where an email or conference call takes place to attain more detail on a subject. Although some important reasons exist to ask more in‐depth questions, quick dives into details with a vendor are helpful during these early stages.

First, you'll want to make sure the vendor can adhere to critical security controls at this early stage, or you must warn your business sponsor (i.e., the leader in the organization who is pushing this new service or product) of the new service/product that it presents unwarranted risk. KC Enterprises requires data to be encrypted because it is restricted and up to one million customer records will be processed by the vendor. A very early discussion occurred between KC and its vendors about how they need their data encrypted and that policy dictates that customer data must not leave the United States. If the vendor, in this example, can't meet these conditions, it requires a much earlier discussion with the business about the risk and possible alternate vendors.

The Q&A process between a vendor and a business can occur via a variety of avenues. If multiple risk domains are involved during intake, then a conference call should take place among the vendor subject‐matter experts (SMEs), business sponsor, and relevant SMEs from the internal risk domains. The challenge is getting everyone on a single call, but if that's possible, it will generally lead to better outcomes because all the risk domains can see the entire risk landscape for the vendor at the same time, which can lead to a holistic look at the risk for this broader team. It should be a “gating” activity in most organizations, meaning that all the risk domains (i.e., everyone involved) must approve the vendor for the next step based upon predefined criteria. During this activity, all questions from those at risk can be answered satisfactorily, or the vendor could be denied if any predefined, non‐negotiable, standard, or policy items cannot be met.

Amount of Data

If data is going to be shared, ask a follow‐up question on the amount expected to be shared and have vendors list the exact data elements. The data types and amounts correlate directly to how much quantitative risk a company is taking on. For example, if the firm values PII records at $200 per record (for direct costs to consumers harmed, not including reputational costs) and the record count is in the millions, that should set off another set of due diligence steps in the next intake round. Similarly, if the data count is very low, and assuming your risk threshold is $1 million in cyberliability insurance, anything under 5,000 records is covered. From a cybersecurity professional perspective and common sense, you would not want to set your risk threshold right at your insurance limit of $1 million. By being conservative and starting at 1,000 records or less, your due diligence can be lessened due to your lower record count and lower risk.

Country Risk and Locations

Another common cybersecurity concern during this intake process that should be covered on the IRQ is location. Are there any offshore concerns that the company might have on items besides data location? Many firms have outsourced development and support, just as KC Enterprises has done. While it's not a deal‐breaker, company sponsors should ask in what countries these activities are performed and that the vendor lists these countries up front. If a vendor develops software in a country listed as problematic for computer crimes, then it should be red flagged so your business knows it needs to have a conversation about it before proceeding.

Connectivity

If a vendor and business sponsor check the IRQ checkbox that the service or product requires connectivity, a series of questions must be asked to initially assess that risk:

1. Is the connection leased‐line or via the internet?
2. How is access taking place, both physically and logically?
3. Who is the maker of the connectivity hardware?
4. What encryption level are their screening questions?
5. If the third‐party's personnel will connect directly to the company, how is that planned to happen?

If a vendor says you must do something not on this list, that's something of concern already. Virtual Desktop Infrastructure (VDI) connections need infrastructure and must be learned early on as well.

Data Transfer

Whether connectivity is static or intermittent, some key questions like the following must be asked to understand if any additional due diligence is required: If data is uploaded/downloaded, what type of secure file transfer protocol (SFTP) do they use? How does the vendor support an access control mechanism that meets your standards in cases such as an SFTP server upload/download? Again, these are just screening questions, so they should be focused on your security for how your data is moved.

Data Location

It's very common for business sponsors and vendors to have a cloud‐based solution. As we've discussed, for this book “cloud” means anything not located in your own company's premises (i.e., from a server closet to your own data centers). This includes Cloud Service Providers (CSPs; e.g., Google, AWS, Azure), co‐location providers, or a vendor‐owned data center. If the IRQ's checkbox is checked for a cloud‐based solution, you should determine early where that data will go. All of these solutions have different security risks. For example, if a vendor is using a CSP, then the physical security of the data center is very low risk. These companies run first‐class, top‐tier data centers that would put Fort Knox to shame. In fact, you'll never get one of them to allow you a physical walk‐through unless you can pull some serious strings.

If the vendor replies they have their own data centers, then it might set off a different security review. Traditionally, data centers are very expensive and can be challenging to maintain at acceptable levels over time as standards evolve and mature. A vendor data center that is 10 years old might be a concern given changes in the standards and tools during that time frame.

Service‐Level Agreement or Recovery Time Objective

Service‐level agreements (SLAs) and Recovery Time Objectives (RTOs) require the business sponsor and vendor to collaborate productively. The business sponsors should ask what the expected business RTO is (i.e., how long a product/service can be down in hours before it must be restored) and compare their requirements with the vendor's answer to see where they can meet. The goal of follow‐up due diligence, depending on any mismatch, is to ensure that these items are discussed and corrected early. In addition, legal implications could be added to SLAs in the contracts if requirements are not met.

Fourth Parties

Questions about what third parties this third‐party vendor will use to provide your product/service should also be triggered by IRQ checklists. Are parts of or all of the product developed outside your home country? Information about the access that these fourth parties need to your data, in addition to the third party's answer, will let your company know if Cybersecurity needs to perform any further due diligence.

Software Security

While not enough software security questions are on the IRQs I've seen, given the high risk posed by third‐party software, you should ask the following questions to determine what next due‐diligence steps would be: Do you have a secure development lifecycle? Do you perform penetration testing against both your enterprise and product?

The intake questions to determine inherent risk is focused on finding alerts that would require further due diligence. The risk‐based approach suggested earlier determines the level of risk (i.e., number of records, data type, and criticality to business operations), where the IRQ process is more conversational to ensure there is as much transparency as possible, and that all questions and risks are addressed with more attention. Anything under that threshold would still need to be covered by an IRQ, but it can be more menu‐driven than a conversation. Ideally, such a conversation can take place with all vendors. But if resources aren't sufficient, then the risk‐based approach to engage with vendors viewed as high risk is appropriate. In cases where the menu‐driven format is followed, ensure that examples are used to clarify what data is expected. Use drop‐down menus to limit data variance on replies. Another way to handle the complexity of an IRQ is to provide examples of what PII consists of, as many third parties do not sufficiently understand this concept.

KC Enterprises Intake/Inherent Risk Cybersecurity Questionnaire

KC Enterprises sends out an IRQ to its vendors for their input. Again, the IRQ questionnaire is used to give those performing the cybersecurity due diligence a window into what risks this vendor product/service poses for follow‐up due diligence. It often requires that some additional meetings are held to gain clarity, depending on the complexity of the service/product and how clear the answers are from the third party.

The following example is KC Enterprises' IRQ. Note that this is a summary of the subjects covered in the questionnaire. You can find the full question set online at www.wiley.com/go/cybersecurityand3prisk.

• Data Security: Assess if the vendor will have confidential data, can they encrypt, and can your firm perform security assessments on the vendor?
• Data Volume: How much data will determine potential quantitative risk?
• Data Location: Is the data going to be at the vendor data center, at a co‐location facility, or at a Cloud Service Provider (CSP)?
• Fourth Parties: Find out who the vendor uses to provide the service to your organization for any additional risk.
• Connectivity: If the vendor requires a connection, this needs to be understood for the risk.

As KC Enterprises' Cybersecurity team reviews each response from the vendor, decisions can be made about whether more or less due diligence is required. As discussed in the section titled “Cybersecurity Third‐Party Intake” later, we will take up the work performed from the IRQ for that next due diligence step.

Cybersecurity in Request for Proposals

Request for Proposals (RFPs) are frequently done for larger projects or investments, but far too often the cybersecurity key elements do not get added into them. More importantly, a single list of questions cannot often be used because the RFPs are dependent on the type of service or product the business is seeking to evaluate for selection. However, collaboration between any internal teams, which are managing vendor sourcing or how evaluations are performed, along with the cybersecurity team, can help avoid the pitfalls that usually occur. Such late pitfalls occurring in a vendor's decision produce the appearance that Cybersecurity is once again slowing business down or interfering in operations. Some questions and easy evaluation tools can be incorporated in the RFP's cybersecurity items. While some of them are similar to the IRQ's questions, these are geared to allow Cybersecurity teams to provide feedback to the business at this time.

Next, we'll review a sample of 10 cybersecurity topics sent out on the vendor's questionnaire. This questionnaire starts off as a checklist, but it should not end as such. The expectation is that the vendors all submit their replies to these cybersecurity topics (and likely other topics such as business operations, financials, etc.), which is followed by some type of meeting where the answers are reviewed and clarified. The following 10 RFP topics also include good follow‐up questions that can be part of the discussion with the vendors as part of the RFP evaluation.

Data Location

The questionnaire includes data location so that vendors submitting for the RFP can detail where the company's data will be located (CSP, a co‐location, a vendor data center), or if it will be on‐site at your company's location. These answers are weighed differently because the risk is different for each. For example, if a vendor states your data will be stored at your company's location, the answer is given a higher weight and achieves the best score. Should a vendor answer that they are using a CSP, you should discuss with them how they plan to manage the shared security model with the CSP. Questions must be asked about their alternate sites, no matter what type of data center, to ensure there's a fail‐over solution.

Development

This questionnaire section focuses on where a vendor's development is done and if they have a secure development lifecycle. Concerns may surround the development done in some locations, depending on a country's risk. Finding that out in the RFP is an important sorting tool, in addition to whether or not they have a secure development lifecycle. Follow‐up discussions can explore what parts of development are done where, and what access developers have to production data, if any; and if developers anonymize data in lower environments (i.e., the test or development environments). On the secure development front, it is ideal to have vendors walk through it at a high level so you can inquire about how they manage open source software.

Identity and Access Management

Identity and access management (IAM) ranges from how the vendor manages identities in their enterprise to how access management is done for the products or services. Do they accept a Single Sign‐On (SSO) type that your developers can support? How often do they perform access reviews and what are their password complexity requirements? As vendors answer the initial RFP, there should be more information provided on the implementation of any access controls with the vendor and the company to ensure it is a secure design.

Encryption

While this may seem repetitive of the many other questions coming from cybersecurity, it's because it is very important. Asking a potential vendor questions about encryption at this stage in an RFP will save your company a ton of pain instead of waiting to discuss it before contract signing. Be specific and ask what level of encryption vendors deploy on the products and ask about all three stages of at‐rest, in‐motion, and in‐use. The time spent with the third parties discussing encryption ensures that there are no surprises, and that the vendors can meet your company's encryption standards. Because encryption is vital to data protection, if a potential vendor can't meet your company standard, they should never become a candidate for a contract. If a vendor cannot encrypt your valuable data, you should walk away.

As mentioned, encryption questions should cover the data encryption's state (i.e., in‐transit, at‐rest, in‐use). Too often the questionnaire asks about encryption in a generic form, only to discover later that the vendor thought only “at rest” was of concern. There are, in fact, methods of encryption that are considered out‐of‐date or deprecated. SHA‐1 is fine for some functions, but not others, and 3DES is still acceptable, but updated encryption algorithms have taken their place. It's a must to catch this detail during intake via the questionnaire.

Intrusion Detection/Prevention System

Both IDS/IPS are valuable tools on the RFP that alert a vendor about suspicious activity and prevent it from becoming a breach or security incident. Asking questions about this and the other cybersecurity defenses are a way to understand if a vendor is following the common cybersecurity principle of defense in depth. Vendors should have not just one, but many defensive products deployed to effectively defend a modern network. Once your company is communicating with vendors, ask about the type of IDS or IPS they use (e.g., host‐ or network‐based).

Antivirus and Malware

The RFP should cover whether vendors use antivirus and malware products, what they are, and how often scans are performed. You must ask the following: Do you have a vulnerability management program and how it is managed? What type of antivirus and malware protection do you use and how often are the signatures updated?

Data Segregation

Often not asked about, data segregation is involved in discovering risk. If your data is going to be in the cloud, it's crucial to know if it's segregated from other customer data. Some companies will have customer data comingled and have a customer ID that identifies which data belongs to which customer. If you do not inquire about data segregation, it often will go undiscovered. Ideally, a vendor places your data in its own area, with its own encryption key. As discussions take place around encryption, the data segregation is a common follow‐up subject, and it is ideal to find out how vendors will protect your data from other customers.

Data Loss Prevention

While you would think Data Loss Prevention (DLP) would seem obvious, a lot of companies still have not deployed a DLP solution. As indicated in the IDS/IPS topic, the fact that they'd have a DLP indicates they are thinking about the defense in depth. Often, IDS/IPS are deployed as a suite of products that include a DLP product (among others). Great follow‐up questions should focus on how they classify data, and if they have a data classification system tied to their DLP to prevent data from email loss. Because data is the primary target, having DLP is a key defense.

Notification

Questions focusing on notification should cover how long it will take a vendor to notify your company of a suspected breach, and it's often a contentious piece of contract negotiations and operational conduct. A suspected or confirmed breach often is a hot topic discussed between a vendor and customer, along with 24‐ or 48‐hour notice. Notification is important, and you must discover early which potential vendor is best positioned to meet your company's expectations. Nail down how they will notify your company if and when they suspect or have confirmed breaches, and how fast they will notify you.

Security Audits

It's best to determine early in the RFP which potential third parties will allow you to perform your due diligence. Whether your company requires on‐site, remote, periodic, or annual security assessments is also something to establish now. If a vendor says they will not allow the firm to perform the level of due diligence that is required based upon risk, then the vendor should not be hired. If the opportunity arises, inquire what level of security assessment they will allow and if they charge. Some firms will charge for the time to help your firm perform its due diligence. This information is good to know up front before the bill arrives.

Once the initial questions are answered, the Cybersecurity SME assigned to the RFP should review the answers to determine if there are any immediate flags. Feedback about the responses that miss key security controls need to be given to the business sponsors early. Likewise, if there are respondents that do a great job and provide all the right answers, then you should note them as a great candidate in your feedback. However, don't stop there when reviewing their survey answers.

Whether your company has 2 or 15 RFP candidates, the time spent with the ones that pass the first review is valuable. Often, time spent on a phone call with the vendors' cybersecurity SMEs will produce a holistic picture of how they approach security. Again, security isn't a checklist but an ongoing process. Such discussions can add more context to the RFP feedback from cybersecurity to the business sponsors. The feedback must focus on the security concerns or benefits of the product/service and avoid business value.

One other benefit of cybersecurity involvement in this important intake process is data movement on the next steps. For example, as the due diligence data is collected with the RFP, or as the final vendor is selected, that information can be passed along to the IRQ questions. This will cut down on the time spent by both internal resources and the vendor. RFP questions are very similar to the IRQ, and you can find a sample at www.wiley.com/go/cybersecurityand3prisk.

An RFP cybersecurity questionnaire should not exceed 10–20 questions on an initial screening. As vendors are scored and some are eliminated, hopefully, due to inability to meet some conditions and lower scores, you should engage with the remaining contestants for deeper dives on the subjects.

Data Security Intake Due Diligence

This section's driver is the vendor answering “yes” to the Data Security question: Yes, they will be storing, accessing, or processing customer or employee protected data. This section is broken down into subsections for easier digestion. As we get into each of the subsections, we will assume the role of KC Enterprises' Cybersecurity team to pose sample questions. The sections covered on this form are:

• Security Policy: Questions at this level are designed to determine the level of maturity of the vendor's cybersecurity program and policies. The maturity of a security program will often drive how well they secure data and network connections.
• Security Incident Management: Security Incident Management, or how a firm deals with threats, speaks to its preparedness for the inevitable: a suspected breach. Because the vendor is going to have sensitive data, it is important to determine their readiness for this activity and questions at this level should reflect it.
• Application Security: Also called Secure Development (or Design) Lifecycle (SDLC), application security is applicable if the vendor is providing the software, whether it is in the cloud, on a mobile device, or an internal application. On the internal application, there needs to be some risk‐based decisions made because not every application running internally poses enough risk to evaluate. For example, while due diligence on normal office applications (such as Word or Excel) might not meet the threshold, software that moves money or provides critical infrastructure support could. Design your questions, if internal, to assess even more due diligence that might be needed.
• Access Management: Access Management domain questions should focus on determining if vendors have sufficient controls to ensure only authorized personnel gain access to appropriate resources. This includes both the enterprise of the vendor and the product.
• Mobile Security: Many applications and services are deployed or available over mobile devices. Special questions should focus on these types so that your company can understand a vendor's mobile security risk.
• Network and Systems Security: Networks and systems are the core of transport and storage for data. Querying a vendor about how they approach network and systems security can identify any risks to be remediated prior to production going live.
• Offshore Security: Some vendor engagement requires an offshore component. Whether it's business process outsourcing (BPO) or customer support, some security controls are required to ensure data and connectivity security. Questions in this area should help your company understand the risks of a vendor's offshore security.
• Encryption: Although encryption crosses the paths of other areas, it does require attention. Here, the concentration is to ensure that a vendor meets the standards set by your company.

Data Center Security  The Data Center Security section in KC Enterprises’ questionnaire has some portions that are applicable based upon the type of cloud deployment involved. Be sure to ask only those questions appropriate to the subject as this is an area where attention can become more focused due to its complexity.

• Vendor‐Owned Data Centers:
  • Provide the address of all data centers in scope.
    • Primary data center
    • Secondary data center
    • Others
• Describe the age and any upgrade/maintenance done since established.
• Are data center personnel full‐time personnel, contractors, or managed by another third party?
• Are any data center personnel members of an organized union?
  • Yes or No
  • If yes, provide their association details.
  • Have there ever been any worker unrest or strikes?
• Are there restrictions on customer security assessments of the data center?
• How far from corporate headquarters are these data centers?
• Is there an active plan to retire any or all of the data centers?
• Do you have appropriate certifications for the physical security of the premises?

Personnel Security  Some important Human Resources (HR) cybersecurity steps must be taken to ensure that a third party is performing the correct due care and due diligence. Too often, it's an insider threat or a rogue employee that leads to an incident. The Personnel Security section in the questionnaire should cover the following:

• Are all personnel (i.e., full‐time, part‐time, contractors) required to accept and sign an Acceptable Use Policy or Agreement?
• Are all personnel (i.e., full‐time, part‐time, contractors) required to accept and sign a Code of Ethics?
• Are all personnel (i.e., full‐time, part‐time, contractors) required to accept and sign a Non‐Disclosure Agreement (NDA)?
• Are all personnel (i.e., full‐time, part‐time, contractors) required to undergo a background check prior to hire?
  • If yes:
    • What items are checked on background?
    • How often are background checks rerun for any personnel?
    • Does your company policy require forced PTO for personnel who work in Finance or other high‐risk areas?
    • Is there a termination policy that clearly describes behaviors that can result in job loss?
    • Are all personnel (i.e., full‐time, part‐time, contractors) required to undergo annual security awareness and training?

Connectivity Security  As the IRQ is completed and vendors answer that a connection with KC Enterprises is required, you must inquire about the following security controls on network connections:

• Which data centers or offices will the vendor require being connected?
• Is there an existing connection with the vendor?
• What hardware is the vendor supplying for both ends of the connectivity?
• What is the vendor's patch management policy and how does the connection hardware fit into that process?
• Does the vendor agree to share with KC's Cybersecurity team the version of its software running on any hardware used in the connection at least twice a year?
• What level of encryption is used for the connection?
• Are there any out‐of‐band devices needed for the management or recovery of the hardware?
• Yes or No
• If yes, please describe the hardening done for such devices.

Supplier Management Security  This questionnaire section is a great opportunity to discover if your third party is one of those companies that does not sufficiently manage its own third parties. The questions should focus on the following areas of biggest risk:

• Do you have a vendor management program?
• Yes or No
• If yes:
  • Is there a tiering system for vendors based upon risk?
  • How is due diligence performed on the vendor's cybersecurity risk?
  • How often does your company perform on‐site security assessments of critical vendors? How many critical vendors does this include?
  • Have any of your third parties reported a security breach in the last three years?
  • Who are the key vendors and products used to perform the service or deliver the product to KC Enterprises?
  • Please provide the vendor's names and what services they provide in the delivery of product.
  • Have there been any disaster recovery tabletop exercises run on an outage at a key vendor for this product?

Next Steps

Risk‐based triggers  Any due diligence program should take a risk‐based approach, meaning focus of the work and attention increases as the risk increases for the vendor. One way to do this is to assign risk based upon cyberliability insurance limits and payouts. KC Enterprises' cyberliability insurance requirement from vendors is $1 million. Any deal where the quantitative analysis places the risk at 90 percent of that insurance level (in case there are times where we have a vendor with more than $1 M), means that the vendor must go through additional analysis. This analysis can be from a complex quantitative analysis model or simple math. KC values PII records of customers at $200 per record. This value is based upon internal calculations done to hire an excess amount of lawyers and an outside PR firm to put out a brave message, to pay for free access to credit viewing and protection to customers affected, and to fire the CISO and look for a new one. (Did I mention hiring more lawyers? They're expensive.)

Low‐Risk Vendors  At this point, the math necessary is straightforward, but a calculator is still nice to use. The threshold for low‐risk vendors is $900,000, with $200 per record, and the trigger for additional scrutiny is 4,500 records. While that might sound very low as thresholds go, keep in mind this is just a threshold to do something: What is the “something to do” above and below the threshold is the important question. Below this threshold, vendors receive a remote questionnaire that asks them the additional due diligence questions in an online form (ideal) or in a locked spreadsheet (keeps the answers from varying too much from them). As the responses come in, staff can review them and look for flags that require follow‐up, either via email, direct call, or conference call.

The risk of these low‐risk vendors allows KC's due diligence teams to focus on more in‐depth reviews of vendors with higher risk. Process the low‐risk vendors and keep an eye out for the following flags in the system that set off cybersecurity alarms:

• Are there any red flags on encryption questions (i.e., vendors who do not meet a minimum standard)?
• Are the offshore resource policies meeting KC's standards?
• Does the firm have a defense‐in‐depth strategy as seen by the responses?
• Would a phone call or follow‐up meeting clarify any risk concerns?

Above this low‐risk category can be another threshold or two, depending on typical vendor record counts and resource capabilities weighed against the risk of a breach because due diligence missed a key risk. No pressure. The risk‐based approach allows for flexibility, but the rule‐of‐thumb would be to increase the level of hands‐on deep dives as the record count gets higher or connectivity gets less secure (e.g., a vendor needs to traverse the network with discovery nodes, which might be a concern given what has been seen in SolarWinds).

Moderate‐Risk Vendors  Moderate risk at KC Enterprises is considered as any vendor with more than 45,000 records. This value is based upon KC's own cyberliability insurance with the same insurance carrier with which it has business insurance: at $10 million. The same threshold is built‐in here, where 90 percent of $200 per record is 45,000 PII records. Anything between 4,501 and 45,000 records gets this additional scrutiny. In this risk level, the following should occur:

• The third party is required to complete the IRQ. Once triggered, then the Intake Questions are expanded to include more questions on data security and the ability to perform more due diligence (i.e., on‐site assessments).
• The vendor is required to schedule appropriate subject‐matter experts (SMEs) for two one‐hour video conference sessions. These two sessions will include time for an initial session of information gathering, in addition to some questions and answers. Undoubtedly, on this first call, not all the answers will be ready as the initial discovery is performed. The second call is available in case the initial call does not produce all the answers.
• Vendors at this risk level must agree to three non‐negotiable cybersecurity conditions:
  • Encryption: All data must be encrypted at a minimum of AES‐256 or equivalent at‐rest, in‐transit, and in‐use.
  • Right to On‐site Security Assessment: These assessments will be two‐day on‐site visits by our Cybersecurity team to perform on‐site physical validation of security controls.
  • MFA for Privileged Access: Any systems that store, process, or transmit KC data must require MFA or a Privileged Access Manager (PAM) to manage escalated accounts.
  • These non‐negotiables have only two ways to become negotiable:
• If the vendor agrees to take on additional cyberliability insurance to cover the risk, in addition, the vendor must ensure the insurance is exclusive to KC Enterprises.

  Or

• The business sponsor must present a Risk Acceptance (RA) memo explaining the risk, with recommendations from Cybersecurity Third‐Party Risk leadership. The RA must get approval from the company's CISO, the executive owner for the business unit, and the business sponsor.
• The results of a Risk Acceptance must be stored and searchable. An RA doesn't make the risk go away; it must follow that vendor like a “scarlet R” (for Risk!) until it is closed, to discourage it as a practice and so no one loses sight of the risk.
• This RA will be stored in the system of record on the vendor. It will also be logged in the system of record on the vendor as an open “finding”—an identified risk at the vendor—that is not closed until it's confirmed. Meaning, every time the third party has a due diligence engagement, whether remote or on‐site assessment, the KC cybersecurity assessors will ask if the finding has been closed.
• An RA quantitative risk estimate will be added to the KC Cybersecurity Risk Register (discussed later), which is a way for the company leadership to view the risk that they have taken on in total.

High‐Risk Vendors  High‐risk vendors at KC Enterprises consist of any vendor with a record count above 45,001 or a vendor with a connection. KC added the connection to this risk category due to a concern of lateral movement. A connection to the network to a cybersecurity professional is like what an open wound is to a doctor. It can be managed with some disinfectant and a band‐aid, but the wound is still a threat that can infect the body from the outside. So, if a vendor has only five PII records but has a connection to the KC network, then it is automatically placed in the high‐risk category.

At this category level, a vendor is subject to the same scrutiny as the moderate‐risk vendors and also to the following additional steps:

• The vendor must agree to the following connectivity audits on any hardware used:
  • The third party must physically validate that the software running on the hardware is at a patch level where there are no critical security patches (i.e., zero‐day critical as defined by the hardware vendor).
  • Access controls for hardware must meet KC's security standards for third parties.
  • These non‐negotiables have only two ways to become negotiable:
    • If the vendor agrees to take on additional cyberliability insurance to cover the risk. In addition, the vendor must ensure the insurance is exclusive to KC Enterprises.

    Or

    • In this level, RA becomes more politically expensive for the sponsor. This is intentional by KC's leadership, because they don't want this behavior to happen unless the price of the behavior is outweighed by the whole firm taking this level of risk. The business sponsor must present an RA memo explaining the risk, with recommendation from Cybersecurity Third‐Party Risk leadership. This RA must be approved by only the CEO and get reported to the KC Board Risk Committee as well as the Cybersecurity Risk Register.
    • Storing the results of a Risk Acceptance so they can be reported. An RA doesn't make the risk go away; it must follow that vendor like a “scarlet R” until it is closed, to discourage it as a practice and so no one loses sight of the risk:
      • This RA will be stored in the system of record on the vendor. It will also be logged in the vendor record as an open “finding”—an identified risk at the vendor—that is not closed until it's confirmed. Meaning, every time the third party has a due diligence engagement, whether remote or on‐site assessment, the KC cybersecurity assessors will ask if the finding has been closed.
      • An RA quantitative risk estimate will be added to the KC Cybersecurity Risk Register (discussed later), which is a way for the company leadership to view the risk that they have taken on in total.

These vendors and the risk levels help not only with intake due diligence but help KC cybersecurity teams to focus on resources in the Ongoing, On‐site, and Continuous Monitoring teams. Because of the high risk and the high oversight, this threshold is a difficult decision for KC to make, which determined that a service model needed to be established for the line of business vendors based upon their risk level.

Ways to Become More Efficient

You can improve the efficiency of these due diligence efforts by leveraging any vendor that has certain certifications or third‐party confirmed frameworks implemented. Following are some examples of widely recognized certifications that can be used:

• Health Information Trust Alliance (HITRUST) is an organization that represents and is governed by the healthcare industry. It offers three different levels of certification for its Common Security Framework (CSF): self‐assessment, CSF validated, and CSF‐certified. A CSF‐certified vendor that is going to be handling PHI data can skip much of the due diligence efforts if they can confirm that their certification is still valid.
• Federal Risk and Authorization Management Program (FedRAMP) is a government program that provides a standard approach to cloud security assessments. There are three levels of FedRAMP: low, medium, and high. Depending upon a company's risk appetite, it could declare that if a vendor is FedRAMP medium‐certified, then they can skip much of the cloud due diligence.
• To become certified by the Cloud Security Alliance Security Trust Assurance and Risk (CSA STAR) program requires a rigorous third‐party independent assessment of the vendor's cloud security. If they can demonstrate that the certification is still valid, it offers the ability to avoid cloud due diligence.

There are other similar certification programs that could be used to leverage the work the vendor has performed in achieving this level of certification and to lower the amount of due diligence required.

Systems and Organization Controls Reports

Systems and Organization Controls (SOC) reports are common reports requested or required from vendors, as they are mandated by SSAE 16 and SSAE 18. This requirement stems largely from the Sarbanes‐Oxley Act (SOX) that made public companies responsible for effective system controls on their financials. Ensuring this control requires that public companies obtain a SOC report to ensure that vendors don't impact their compliance negatively.

A SOC report is performed by a certified public accountant (CPA) from the American Institute of Certified Public Accountants (AICPA) and is a compilation of controls to confirm they are present and audited. There have been a number of versions, such as SAS 70 that was superseded by SSAE 16 in May 2011. In May of 2017, the SSAE 18 mandated a series of upgrades to the quality of SOC reports.

Various types of SOC reports are available: SOC1, SOC2, and SOC3. In addition, there are also different types of each of them: Type 1 or Type II. A SOC1 report is focused on the internal controls on financial reporting. This report is an output from an audit of the accounting and financial controls. Note, these reports are not applicable for a cybersecurity evaluation. A SOC2 report is the one most often used by an information technology vendor. The SOC2 is not an upgrade nor does it provide more details than a SOC1. It is an audit of the controls of the vendor for one or more of the following Trust Service Criteria (TSC):

• Security
• Confidentiality
• Privacy
• Processing Integrity
• Availability

The SOC2 is designed to provide a metric of a vendor's ability to adhere to privacy, confidentiality, availability, and security of its IT services. The different types of SOC2 reports (i.e., Type I and Type II) are vastly different in scope. Type I confirms that the controls exist. However, a Type II affirms that the controls are in place and that they work. It's an important distinction and is why a SOC2 Type II often represents an improved view of how a vendor is performing at protecting your data.

A SOC3 is not an upgrade of a SOC2 report. It is a summary of a SOC2 Type II, so it is not as detailed as either type of SOC2 statements. It is primarily intended to be used too as a seal of approval that can be shared publicly (on the company website or in literature). Because it is not as detailed, it cannot be used for cybersecurity due diligence efforts.

There are four sections to a SOC2 Type II report:

• Report from the Auditor: The auditor discusses the audit engagement (i.e., what was audited, duration, and scope). They list anything they have found, good or bad. Most opinions will be one of these four:
  • Unqualified: Great result, good‐to‐go
  • Qualified: Good but not great, need some things fixed or remediated
  • Adverse: Not good, a failing grade
  • Disclaimer of Opinion: Bad, equivalent of not just getting an “F” but getting kicked out of school
• Management Assertion: Management responds to some of the audit findings as well as the period, scope, and time of the engagement.
• Description of System: An important section because it describes the structure of a company, services offered, in addition to its IT systems and controls.
• Matrix of Criteria and Testing: This is usually a listing or matrix of the criteria, controls, and testing, along with results.

When reviewing the SOC2 Type II report, there are several key items to pay attention to ensure that it is relevant:

• Type I or Type II: For a SOC2 report to be considered sufficient for cybersecurity due diligence, the auditing and testing must be done at a Type II level where the effectiveness of the controls is evaluated.
• Coverage: Does the report cover the services and/or products the company has contracted the vendor for or are there pieces missing?
• Criteria: There are five Trust Services Criteria: privacy, security, data integrity, availability, and confidentiality. Does the report cover all five?
• Sub‐contractors: Is the report inclusive of the vendors' third parties used to provide the service?
• Exceptions: If the report has any material exceptions, these need to be reviewed for impact to the risk due diligence.
• Date: Check at the date of the examination to see if it is old enough to be considered stale. It should be no older than one year from when the Intake process takes place, and ideally it should be less than nine months, given that the Intake process for a vendor can take a lot of time from start to production implementation.

SOC2 Type II reports are a valid way to have vendors attest to an independent assessment of IT controls. It cannot be a substitute for performing due diligence and risk evaluations. These are point‐in‐time audits that do not provide ongoing assurance that the vendor is adhering to security controls. The reports are a requirement of public companies to lower their risk of SOX issues or findings. However, they are not ideal for cybersecurity due diligence as described in this text.

Chargebacks

This can be a difficult topic for cybersecurity to discuss with business leadership. However, this model is a largely accepted practice for IT services rendered to lines of business. It is a common way to ensure that business includes the true cost of the ownership of the size of their business. In this case, the requirements for due diligence levels are clearly articulated by KC Third‐Party Risk Management and Cybersecurity. The thresholds were established principles and had been working, but management was concerned that the business was taking on a lot more moderate‐ and high‐risk vendors that required more resources.

The lines of business leadership, TPRM, and cybersecurity leadership agreed to a cost model based upon the risk category of the vendor engagement. Pricing was not an actual cost as it passed hands from a department to cybersecurity and TPRM for the resource cost, but the line of business “funded” the cybersecurity resource as part of the project for the duration of the intake review process. Resources can be fully funded and cybersecurity and TPRM can collaborate with each line of business, as part of each fiscal year's planning to establish expected staffing levels based upon funded projects in the upcoming year that would require due diligence. This isn't an exact science, as not all projects may not know if they require a connection or data classification levels or because projects are sometimes added mid‐year. Because it's not a science, the three teams work it out in budgeting per the normal prioritization process.

This risk‐based approach to how a project is funded, and thus resourced, has some side benefits. First, it provides a “cost” to business on projects with vendors that raised the risk levels at KC Enterprises, so the cost was added into the calculus when weighing options of doing something outsourced or in‐house on internal resources and systems. Second, it bridged the gap of friction that is often had between business and cybersecurity overdue diligence efforts. This exercise of establishing vendor risk classifications, based upon quantitative values to having business fund the resources required for the due diligence, was an education for all three teams. Cybersecurity learned business operations and needs, TPRM learned the expected input coming in the upcoming year, while the business learned of the “cost” of cybersecurity due diligence by viewing the activity level required at each level.

Go‐Live Production Reviews

Prior to any go‐live production, a new vendor service must meet and go through all the due diligence that is required to complete a gate review. At KC, these reviews depend on the vendor risk level. On the low‐risk side, vendors are required to have closed any high‐level risk findings during the Intake process. All lower‐risk cybersecurity items can be risk accepted by the business sponsor and the approval of the Cybersecurity Risk Advisor or their delegate.

Moderate‐ and high‐risk vendors must have an increasing level of go‐live preapprovals. On the moderate‐ and high‐risk vendor side, they also must close all high‐risk findings prior to go‐live; and all moderate‐risk findings must have a remediation date of no more than one year from go‐live or earlier, depending on agreement with a third party prior to production.

Connectivity Cyber Reviews

Because connections to the corporate network carry a risk, KC requires some additional steps before any line is turned on live. Once the connection is established, changes are hard to make. In addition, if there is a security gap, it could go undetected for a long time, depending on scanning and patch management. The history had shown Cybersecurity teams that these connections can be “forgotten” by the vendors; but because the vendors managed the hardware and were the only ones with access, this meant it could be a challenge once installed to correct bad behaviors of vendors.

Connectivity Cyber Reviews involve Cyber Third‐Party Risk reviewing a few key items prior:

• Vendors must confirm hardware and patch level at time of deployment.
• Vendors must confirm that the encryption of the connectivity is per design approval.
• KC Security Architecture must have completed a high‐level design of the connectivity with approvals from relevant network connectivity policy. At present time, this is the Enterprise Architecture Council that has all relevant stakeholders across Information Technology and Cybersecurity departments.
• There are no open high risk findings or risk acceptances that directly impact the security of the connection with the vendors.

Once these four processes are confirmed completed, then cybersecurity has performed its approval at the connectivity.

Connectivity Lifecycle  One often overlooked item is connecting the vendor contract with the life of the connectivity. If there is no process to let the network connectivity and security teams know that a contract has been terminated, KC found that equipment often stayed connected. They took corrective steps to connect their workflow tool used for the network service management connected to the vendor management software. The workflow between the two programs meant that if a vendor's contract was being terminated, a flag drove a workflow. If that vendor had a checkmark for “Connection,” then it sent a nightly batch file to the workflow in the service management tool. It wasn't magic, but at that point, the appropriate personnel were notified of the need to investigate and coordinate with the vendor management team on when to shut the connection down. Also, the equipment had be returned to the vendor or otherwise inform KC of how to dispose of it.

Final Intake Steps  Once the go‐live production steps have been completed, the systems of records must be updated and owners for the data be assigned. Based upon risk, the vendor then goes into the next phase: Ongoing Due Diligence. This phase will decide how often a third party will require periodic assessments and where in the Continuous Monitoring program it fits. It is likely there will be multiple services from single vendors, so there are ways to speed the whole process up as well, by leveraging existing artifacts and due diligence records (that are not too stale) to lower the activity level required for a vendor to repeatedly refill out the same data.

KC Enterprises also establishes a vendor portal that is leveraged for communication. After the service or product is in production use, the cybersecurity team can communicate directly with the vendor contacts. For high‐risk and moderate‐risk third parties, the cybersecurity Incident Response teams are linked, and the cyber teams have designated points of contact. Through this secure portal, the vendor can be sent surveys or questions to fill in online to lower the risk of data leakage. One future feature request at the firm is to integrate a calendar schedule function that is tied to the firm's risk. The vendor would see, based upon their KC risk profile, that they are expected to have an on‐site assessment performed at certain periods. For example, a high‐risk vendor might get an on‐site assessment every other year, so in an “off” year it would not appear as a vendor requirement on their portal in that calendar year.

Inside Look: Ticketmaster and Fourth Parties

In June 2018, Ticketmaster publicly acknowledged that it found malware in its customer chat function, hosted by third‐party Inbenta Technologies. The data that the malicious code was leaking included names, addresses, emails, telephone numbers, payment card data, and Ticketmaster login credentials. The malware ran for nearly a year, from September 2017 until June 2018. Ticketmaster's use of a third‐party chat hosting company isn't unique. The cybercriminal gang, Magecart, was behind the attack—a group known for payment skimmers injected into vulnerable website components. Worse was news that as early as February 2018, a number of major banks told Ticketmaster about a large amount of fraud and they failed to take any action. This lack of action caused the U.K. privacy watchdog Information Commissioner's Office (ICO) to fine them over $1.65 million.

This breach is also an excellent way to explain fourth‐party risk. In this case, many U.K. venue operators found out what it was like to be affected by a fourth party; one they were unlikely to know about given most operations do not bother to find out their third‐party's vendors. Let's say you operated a small music venue in Liverpool. It's likely you didn't do your own ticketing, and had contracted Ticketmaster to perform that service for concerts. Suddenly customers are calling upset about fraudulent charges on their cards after they booked a concert at your place. Good customer service dictates you let them vent but politely remind them they book with Ticketmaster. Your next call made is to the Ticketmaster account representative to find out what is going on. In June 2018, they inform of the breach and how it happened. Likely none of the theater and music operators in the U.K. ever heard of Inbeta Technologies. Yet, they had unhappy customers regardless.

Later chapters will discuss ways to test software from third parties for vulnerabilities and secure development. Another avenue of concern is how Ticketmaster performs its own vendor due diligence on software vendors it uses; what fourth‐party questions the venue operators were asking Ticketmaster; and if Ticketmaster uses another third party or parties to provide its own service, and if so, what pieces they are performing.