Blog: Information Security

What is Colorado Cybersecurity Regulation (HB 18-1128)?

On January 19, 2018, the General Assembly of the State of Colorado introduced House Bill 18-1128, Concerning Strengthening Protections for Consumer Data Privacy. The regulation was signed into law on May 29, 2018 and goes into effect on September 1, 2018.

The new regulation contains four primary sections:

  1. Disposal of Personal Identifying Information
  2. Protection of Personal Identifying Information
  3. Notification of Security Breach
  4. Security Breaches and Personal Information

The first three sections focus on how a "covered entity" can protect personal identifying information (PII). A "covered entity" is defined as a "person" (e.g., an individual, corporation, business trust, etc.) who maintains, owns, or licenses PII in the course of their business, vocation, or occupation.

Section Four shifts some wording around, but repeats the first three sections, replacing the term "covered entities" with "governmental entities."

Does Colorado HB 18-1128 apply to Banks and Credit Unions?

Yes. While the regulation defines PII a couple different ways, both definitions include things a financial institution would "maintain, own, or license" in the course of normal business (e.g., social security numbers, credit cards, debit cards, account numbers, etc.). If you are a financial institution in the State of Colorado, Colorado HB 18-1128 applies to you.

Are Financial Institutions in Compliance with Colorado HB 18-1128?

Let's break this down by section.

  • Section One: Yes.
    Financial institutions are already subject to GLBA, so the organization should already have a policy in place that defines the secure disposal of paper and electronic documents containing PII.
  • Section Two: Yes.

Again, since financial institutions are already subject to GLBA, the organization should already have reasonable security procedures and practices in place to protect PII from unauthorized access, use, modification, disclosure, or destruction.

  • Section Three: Partially.

Per GLBA, each financial institution should have an incident response policy, program, and/or plan that outlines what the organization should do in the event of a security breach. However, Section Three additionally includes new requirements, specific to the State of Colorado, about classification and notification of a security breach.

For example, Section 3(2)(e) states that if the security breach affected more than 500 Colorado residents, the covered entity must notify the Colorado Attorney General as soon as possible, but no later than 30 days after determining a security breach occurred. This requirement is new and it is specific to Colorado organizations, so it does not likely exist in your current incident response policy, program, and/or plan.

How to Prepare for September 1st

To prepare for the September 1st effective date, it would be beneficial for each financial institution to compare their existing incident response policy with the new requirements in Section Three and make updates, as needed.

We have developed a downloadable PDF called, "Understanding & Preparing for the Colorado Cybersecurity Regulation (HB 18-1128)." This document provides a side-by-side comparison of the regulatory language with our opinion to help you simplify and interpret the regulatory wording. This document will help you understand the regulation, as you prepare your institution for the September 1st deadline.

For Tandem Customers: The resource also provides information about how the requirements of HB 18-1128 are already addressed in Tandem, including recommendations about how you can incorporate the Colorado-specific requirements into your existing information security program.

What is Tandem?

Tandem is an online information security and compliance software designed to increase security and help financial institutions stay in compliance with GLBA and FFIEC guidance. Tandem is now being utilized by financial institutions across the country and helps by saving both time and money without sacrificing information security, cybersecurity, or compliance.


By: (Security+)

How do you know what due diligence documents to gather from each of your vendors? There are many methods available, but some result in more accurate documentation than others. Today, I'm going to review two of the primary methods and discuss the effectiveness of each method.

Method #1: The Bucket Method

I often see, what I will call, the bucket method.

It Goes Something like This

Imagine you have a list of questions you ask about vendor characteristics, and then you classify that vendor based on the number of questions answered as "yes." For example, a vendor should be considered:

  • "Level 1" if two or less are answered as "yes."
  • "Level 2" if three to four are answered as "yes."
  • "Level 3" if five or more are answered as "yes."

Then, you could define the required due diligence based on the level of the vendor, or based on the bucket in which the vendor is grouped. At "Level 1," collect only a service level agreement. At "Level 2," collect a contract, a confidentiality agreement, and financial statements. At "Level 3," collect all document types (e.g., a contract, confidentiality agreement, financial statements, SOC report, examination report, BCP, etc.).

What Happens Now?

This method seems relatively simple to carry out. But in reality, it can create a lot of unnecessary document exceptions, and occasionally miss opportunities to request relevant documents.

  • Unnecessary Document Exceptions in a Bucket Method
    Consider a vendor who is "Level 3." While five characteristics applied to them, several of the required documents are both unnecessary to request, and at some rate, unreasonable. This results in an exception record to explain each case and ultimately, requires more effort from you, as the vendor manager, to oversee the relationship.

  • Missed Opportunities for Requesting Relevant Documents in a Bucket Method
    Consider a vendor who is "Level 2." While only three characteristics applied to the vendor, one of them is very important. If this vendor were to be unavailable for 24 hours, it would be detrimental for our business. We should get their BCP, but we did not because it was not required for "Level 2" vendors.
What This Means for You

The bucket method costs a lot of time and effort even though the labelling process seems quick and simple.

[Learn how to review your 3rd party vendor SOC reports in 15 minutes or less. Plus, download our free SOC review checklist.]

Method #2: The If-Then Method

Instead of the bucket method, consider the more accurate if-then method.

It Goes Something like This

Imagine you have a list of questions you ask about vendor characteristics. You could say that if you answer Question A as "yes," then you should collect a specific type of document related to the effects of that characteristic, Document A. Here are a few examples to consider:

  • If a vendor performs critical functions or provides critical services, then you should get a service level agreement.
  • If a vendor uses subcontractors in the performance of critical functions, then you should get their Third party Due Diligence of Subcontracts.
  • If a vendor stores customer information, then you should get a SOC report.

method for collecting vendor management due diligence documents

What Happens Now?

By using the if-then method, you only gather the documentation that is appropriate to the third party relationship. This method can be continually refined. If you notice you are creating a lot of document exceptions for a specific type of document, revisit the question you are asking that instigates this requirement. Consider what assumptions are being incorrectly made about the characteristic's effects. Update your list to appropriately account for this.

Let's say you thought, "If a vendor stores, transmits, or accesses customer data, then I should get their SOC report." You would quickly find that not every vendor who can access your customer's data is going to have a SOC report, and that the SOC report is quite unnecessary for the service you are receiving. In this case, you could create two separate questions. One question would be about storing customer data, in which you would require a SOC report. Then another about accessing and transmitting customer data, in which you would require a confidentiality agreement, but not a SOC report. Making this adjustment would greatly reduce the number of documented exceptions.

What This Means for You

The if-then method will eliminate unnecessary document requests and ensure pertinent documents are obtained.

In Summary

While both methods provide standardized ways to gather due diligence documentation from vendors, the bucket method can actually cause more problems for your vendor managers.  By using the if-then method, you can manage your vendors based on the services that are being provided to you and easily change your program to meet the developing needs of your environment. Couple this method with the Tandem Vendor Management Software, and increase the efficiency in which you conduct your program. 



Early this year the tech world was rocked with the announcement of two unprecedented vulnerabilities named Meltdown and Spectre.

These two vulnerabilities are a big deal because they are hardware vulnerabilities affecting any device with a silicon chip. This includes microprocessors on workstations and servers, mobile phones, tablets, cloud services, and other platforms.

Understandably there was a rush from three main industries, processor companies, operating system companies, and cloud providers to provide solutions. However, as a result of the urgent response, there were unanticipated update incompatibilities which crashed systems. This created a dilemma for IT professionals. "Do we install updates which may cause our systems to crash?" or "Do we sit-tight and remain vulnerable?"

Even in the weeks of uncertainty, there were calm voices of seasoned reasoning. Their message reminded us that basic security standards remain our first line of defense. No matter how bad an exploit may be, its impact can be limited if:

  • The vulnerability doesn't have access to your systems
  • Operating system or application weaknesses are patched
  • Security software is installed (advanced end-point protection software with artificial intelligence is a game changer)

So how do you do achieve these standards? Here are some fundamental best practices:

  1. Monitor availability of operating system and application updates. Be sure you find and establish good sources to inform you about the patches and updates for your systems and applications. Then, monitor the sources or subscribe to notifications.

  2. Test updates to ensure compatibility. It is best if your update and patching process includes a test environment where non-production systems are updated first in order to test functionality and compatibility. This allows you to postpone or avoid updates which might crash systems or applications.

  3. Apply updates and patches on a regular schedule. As a best practice, you should implement a schedule (at least monthly) to evaluate, test and install updates for systems and critical applications. In this way, your schedule can coincide with schedules of operating system and application vendors (e.g., Microsoft has "Patch Tuesday, the second Tuesday of each month).

  4. Install and maintain security software (e.g., antivirus software, endpoint security software, etc.). If possible, explore and utilize behavior based end-point protection software. This genre of software "watches" system behavior to notice and stop suspicious action.

  5. Prevent malicious code execution. The goal is to keep malicious code out of your network and systems. This is best accomplished with layers of security including Internet filtering, phishing detection, and security awareness training for system users. Security awareness is essential to help prevent users from falling prey to malicious emails.


On September 9th, 2016, the Federal Financial Institutions Examination Council (FFIEC) released a revised Information Security booklet.  This booklet is one of eleven booklets that make up the FFIEC Information Technology Examination Handbook (FFIEC IT Handbook). The IT Handbook is designed to provide information and reference to financial institutions and examiners.  The Information Security booklet specifically “provides guidance to examiners and addresses factors necessary to assess the level of security risks to a financial institution’s information systems.”

To learn more about the new FFIEC Information Security Booklet, join us for a webinar on October 11th at 2:00pm CDT. Register now

To see other webinars offered by CoNetrix, visit our webinars page.

About the FFIEC: The FFIEC was established in 1979 per Title X of the Financial Institutions Regulatory and Interest Rate Control Act of 1978.  The FFIEC is comprised of the Board of Governors of the Federal Reserve System (FRB), the Federal Deposit Insurance Corporation (FDIC), the National Credit Union Administrator (NCUA), the Office of the Comptroller of the Currency (OCC), the State Liaison Committee (SLC), and the Consumer Financial Protection Bureau (CFPB).



On October 1, 2009, President Obama proclaimed October 2009 as National Cyber Security Awareness Month.  This marks the sixth annual National Cyber Security Awareness Month.  The theme for 2009 is "Our Shared Responsibility".  To read the proclamation, visit

The following sites have been created to focus on safe computing practices by the Department of Homeland Security (DHS) and the Federal Trade Commission (FTC): [more]