evaluating third party cyber risk

by Michael Werneburg
on 2017.08.31

You are here:
Risk topics
» Risk topics blog
April, 2018

March, 2018
· the planning fallacy

February, 2018
· Valentine's day vm backup plan

November, 2017
· the unsafe workplace and the body's response

October, 2017
· ISACA article is live

September, 2017
· published
· the Equifax breach
· Tracking Vulnerability Fixes to Production

August, 2017
· evaluating third party cyber risk

July, 2017
· getting it wrong with R
· de-identifying health information
· that's a lot of tracking!

June, 2017
· gaming Google news
· privacy in this day and age
· another record breach
· writing an industry standard
· ISACA article accepted

May, 2017
· Covey time-management quadrants
· safe harbor de-identification of health data
· an ISACA article

April, 2017
· my guide on managing third party risk
· PMP for five years
· metrics that matter
· 720 reads in 48 hours
· I lost my job

March, 2017
· farewell, SIRA board
· the message and the medium
· an interesting take on consulting


The Investment Industry Association of Canada has issued new guidance on evaluating cyber security readiness in third parties. I had the honor of contributing to that process, and thought I'd explain that contribution in an unofficial capacity.

The approach I chose was to look at cyber security in context of:

1. The impact of the relationship between the wealth management firm and its vendor(s).


2. As a question of vendor capability.

risk in the relationship

Without understanding the nature of the data share, you're wasting your time evaluating a vendor's stance. It's vital to understand the nature of the data being shared, the purpose of that sharing.

Understanding the extent of the data share allows you to understand the risk inherent. Understanding the purpose of the share allows you to set the minimum viable share.

the minimum viable data share

The minimum viable data share should always be the target—nothing more should be shared, due to the inherent risk of the vendor compromising your data.

For example, if sharing a client's name and birth date (the classic "tomb stone" data set), you can expose your client to identity theft. It's important to evaluate the need to share the full name and birth date. If the vendor's producing printed annual statements, you likely need the real name but might be able to do without the birth date. If the vendor's providing you with internally reporting, you likely don't need the full name. If they're performing a calculation on the birth date such as evaluating investments against a "time horizon" such as retirement date, you likely don't need to share the actual birth date. By not needlessly sharing both name and birth date, you're protecting your clients' privacy. And by doing that, you're reducing your own potential liability despite sharing data.

the damage done

When I say "nothing more should be shared" I mean in light of the potential loss incurred to the firm or its clientele. When dealing with extensive databases of personally identifying information, breaches can attract client class action lawsuits, regulatory fines, and lawsuits from attorneys general. They also require forensics and remediation costs. While this sounds complex, there are calculators online that allow for ballpark estimation of the cost of a breach. Even insurance carriers now offer these calculators.

Once you understand the magnitude of the problem—and I've seen the numbers climb into hundreds of millions of dollars—you have a very good idea of context. A data breach can end a firm.

I was asked by IIAC to provide twenty question on evaluating a vendor's cyber capability. Instead, I started with the above standpoint, and provided some preliminary questions:

  1. What are the potential liabilities inherent in the relationship?
  2. What is the service being provided?
  3. What are the regulatory requirements?

vendor capability

There are many standards that put a vendor through a checklist to appraise the vendor's capabilities in cyber security. While those checklists do an exhaustive view of exploring the vendor's technical capabilities, I think they go too far in that direction while missing the larger picture of the vendor.

That larger vendor looks a lot more like an assessment of the vendor from a "business" standpoint. Here are some important considerations:

Armed with these answers, it is easier to understand the big picture.

related questions

Continuing to provide IIAC with twenty questions in evaluating the vendor's capabilities:
  1. Who is the service provider?
  2. What is the history of this service?
  3. What is the degree of cyber capability?
  4. What is the vendor's breach response plan?
  5. What are the vendor's hiring and retention practices?
  6. What are your internal policies?
  7. What is your cyber governance strategy?

finally: some cyber questions

These questions have been getting progressively closer to the typical cyber security evaluation. Rather than attempt to reinvent the wheel, my final set of questions were cribbed from the "Critical Security Controls" created by the Center for Internet Security for the SANS Institute. These controls are ordered by the estimated degree of effectiveness.
  1. Does the vendor have an inventory of authorized and unauthorized devices?
  2. Does the vendor have an inventory of authorized and unauthorized software?
  3. Does the vendor deploy secure configurations for hardware and software?
  4. Does the vendor deploy continuous vulnerability assessment and remediation?
  5. Does the vendor deploy controlled use of administrative privileges?
  6. Does the vendor maintain, monitor, and analyze audit logs?
  7. Are email and web browser protections in place?
  8. Has the vendor deployed malware defenses?
  9. Is the vendor limiting and controlling use of network ports, protocols, and services?

I have provided some elaboration on each of my twenty questions, with an explanation of the question and guidance on interpreting the results, as well as citing references. That can all be found here. Additionally, I have a deeper exploration of the subject of third party risk, here.

big list