Author: Tom Hinkel

As author of the Compliance Guru website, Hinkel shares easy to digest information security tidbits with financial institutions across the country. With almost twenty years’ experience, Hinkel’s areas of expertise spans the entire spectrum of information technology. He is also the VP of Compliance Services at Safe Systems, a community banking tech company, where he ensures that their services incorporate the appropriate financial industry regulations and best practices.
23 Jul 2014
Hot Topics Tom Hinkel 0 comment

Cybersecurity – Part 2

In Part 1 I discussed the increasing regulatory focus on cybersecurity, and what to expect in the short term.  In this post I want to dissect the individual elements of cybersecurity, and list what you’ll need to do to demonstrate compliance on each one going forward. So here are the required elements of a cybersecurity program, followed by what you need to do:

  • Governance – risk management and oversight
  • Threat intelligence and collaboration – Internal & External Resources
  • Third -party service provider and vendor risk management
  • Incident response and resilience

1.     Governance – risk management and oversight

Nothing new about this one, virtually all FFIEC IT Handbooks list proper governance as the first and most important item necessary for compliance, and governance begins at the top.  In fact a recent FFIEC webinar was titled “Executive Leadership of Cybersecurity: What Today’s CEO Needs to Know About the Threats They Don’t See.”  But governance involves more than just management oversight.  The IT Handbook defines it this way:

“Governance is achieved through the management structure, assignment of responsibilities and authority, establishment of policies, standards and procedures, allocation of resources, monitoring, and accountability.”

 What you need to do:

  •  Update & Test your Policies, Procedures and Practices.  Verify that cyber threats are specifically included in your information security, incident response, and business continuity policies.
  • Assess your Cybersecurity Risk (Risk = Threat times Vulnerability minus Controls).  When selecting controls, remember that there are three categories; preventive, detective, and responsive/corrective.  Preventive controls are always best, but given the increasing reliance on third-parties for data processing and storage, they may not be optimal.  Focus instead on detective and responsive controls.  Also, make sure your assessment accounts for any actual events affecting you or your vendors.  Document both:
    • Inherent cybersecurity risk exposure – risk level prior to application of mitigating controls
    • Residual cybersecurity risk exposure – risk remaining after application of controls
  • Adjust your Policies, Procedures and Practices as needed based on the risk assessment results.
  • Use your IT Steering Committee (or equivalent) to manage the process.
  • Provide periodic Board updates.

2.     Threat intelligence and collaboration – Internal & External Resources

This element reflects both the complexity and the pervasiveness of the  cybersecurity problem, and (unlike governance) is a particular challenge to smaller institutions (<1B).  According to a study conducted in May of this year by the New York State Department of Financial Services, the information security frameworks of small institutions lagged behind larger institutions in two key areas: oversight over third party service providers (more on that later), and membership in an information-sharing organization.

What you need to do:

Regulators expect all financial institutions to identify and monitor cyber-threats to their organization, and to the financial sector as a whole.  Make sure this “real-world” information is factored into your risk assessment.  Some information sharing resources include:

3.     Third -party service provider and vendor risk management

For the vast majority of outsourced financial institutions, managing cybersecurity comes down to managing the risk originating at third-party providers and other unaffiliated third-parties. As the Chairman of the FFIEC, Thomas J Curry, recently stated:

“One area of ongoing concern is the increasing reliance on third parties..The OCC has long considered bank oversight of third parties to be an important part of a bank’s overall risk management capability.”

Smaller institutions may be even more at risk, because they tend to rely more on third-parties, and (as I pointed out earlier) tend to lag behind larger institutions when it comes to vendor management.  This is mostly because of available internal resources.  Larger institutions may conduct their own compliance audits, while smaller institutions may rely more on external resources, such as SOC reports and FFIEC Reports of Examination (ROE).  And once the reports are received, interpreting them to determine if they indeed address your concerns can be an even bigger challenge.

What you need to do:

Regardless of size, all institutions should  employ basic vendor management best practices to understand and control third-party risk.  Pay particular attention to the following:

  • Pre-contract Planning & Due Diligence – in addition to reviewing the SOC reports and ROE’s, determine if the vendor had any significant recent security events.
  • Contracts – they should define if and how you’ll be notified in the event of a security event involving you or your customer’s data, and who is responsible for customer notification.  They should also include a “right-to-audit” clause, giving you the right to conduct audits at the service provider if necessary.
  • Ongoing Monitoring – in addition to updated SOC reports, financials, and ROE’s, don’t forget to take advantage of vendor forums and user groups.  As the FFIEC statement stressed:

“…financial institutions that utilize third party service providers should check with their provider about the existence of user groups that also could be valuable sources of information.”

  • Termination/Disengagement – management should understand what happens to their data at the end of the relationship.

4.     Incident response and resilience

Incident response has been mentioned in all regulatory statements about cybersecurity, and for good reason.  Regardless of whether it originates internally or externally, a security incident is a virtual certainty.  And regulators know that although vendor oversight does provide some measure of assurance, you have very little actual control over specific vendor-based preventive controls.  So detective and corrective/responsive controls must compensate.

What you need to do:

Make sure your incident response program (IRP) has been updated to accommodate a response to a cybersecurity event.  As I stated in Part 1, your existing policies should already do this if they are impact-based instead of threat-based.  “Cyber” simply refers to the source or nature of the threat.  The impact of a cybersecurity event is generally the same as any other adverse event; information is compromised or business is interrupted.  However, all IRP’s should contain certain elements:

  • The incident response team members
  • A method for classifying the severity of the incident
  • A response based on severity, to include internal escalation, and external notification.
  • Periodic testing and Board reporting

Regarding testing, the FFIEC considers it so important they refer to it as one of the primary take-aways from their recent webinar, encouraging all institutions to consider:

How often is my institution testing its plans to respond to a cyber attack? Do these tests include our key internal and external stakeholders?

 In summary, review the requirements for cybersecurity, and compare them with your current policies, procedures and practices.  Hopefully you’ve already incorporated many (if not most) of these elements into your program, and very little adjustment needs to be made.  But either way, be prepared to discuss what you are doing, and how you are doing it, with the regulators…they WILL be asking you.

10 Jul 2014
Hot Topics Tom Hinkel 0 comment

Cybersecurity – Part 1

Cybersecurity has gotten a lot of attention from regulators lately, and with assessments already underway it promises to be a regulatory focus for the foreseeable future.  But exactly what are they expecting from you, and how does that differ from what you may be doing already?  More importantly, how should you demonstrate that you are cybersecurity compliant?

First of all it’s important to understand that, at least initially, regulators  will be data gathering only.  They may offer verbal feedback, but don’t expect any written examination findings or recommendation at this time.  What they will be doing is assessing the overall posture of cybersecurity.  It would appear that the regulators are following the NIST cybersecurity framework that came out earlier this year in response to the Presidential Executive Order that came out in February of 2013.  The  NIST framework provides a common mechanism for organizations to:

  1. Describe their current cybersecurity posture;
  2. Describe their target state for cybersecurity;
  3. Identify and prioritize opportunities for improvement within the context of a continuous and repeatable process;
  4. Assess progress toward the target state; and
  5. Communicate among internal and external stakeholders about cybersecurity risk.

It would appear that financial regulators are currently on step 1; gathering information in order to describe the current state of cybersecurity across the financial industry.  Of course once the current state has been established, I expect that the “target state” for cybersecurity (step #2) will involve additional regulatory expectations.

So what do you need to do now?  Well, if you’ve kept your information security, business continuity, and vendor management policies and procedures up-to-date, probably not much.  Cybersecurity is simply a subset of each of those existing policies.  In most cases, ‘cyber’ refers to either the source or nature of the attack or the vulnerability.  Your InfoSec  policies (including incident response) should already address this, and so should your business continuity plan.  In other words, you should already have procedures in place to secure customer and confidential data and recovery critical business processes regardless of  the source or nature of the threat.  Your policies should all be impact-based, not threat-based.

Your risk assessments, however, may need to be adjusted if they don’t specifically account for cyber threats.  For example, critical vendors should be assessed for their exposure to, and protection from, cyber threats…with your controls adjusted accordingly (i.e. audit reports, PEN tests, etc.).  Your BCP risk assessment should account for the impact and probability of cyber, as well as traditional, fraud, theft and blackmail.  All that said, regulators will likely be looking for specific references to ‘cyber’, so it won’t hurt to make sure your policies include the term as well.

For me, the biggest takeaway from the flurry of cybersecurity activity (the 2013 Presidential Directive, the 2013 FFIEC working group, the 2014 NIST Cybersecurity Framework, the recent FFIEC statements on ATM Hacking and Heartbleed and DDoS attacks, as well as the recent FDIC’s C-level cybersecurity webinar) is this; for the vast majority of outsourced financial institutions, cybersecurity readiness means A). managing your vendors, and B). having a proven plan in place to detect and recover if a cyber-attack occurs.  

According to the FDIC, here are the required elements of a cybersecurity risk management program …notice the last two:

  • Governance – risk management and oversight
  • Threat intelligence and collaboration – Internal & External Resources
  • Third -party service provider and vendor risk management
  • Incident response and resilience

I’ve covered vendor management and incident response before.  In Part 2 I’ll break down each of the four elements in greater detail, and tell you what you’ll need to do to demonstrate compliance.

02 Jun 2014
Ask the Guru Tom Hinkel 1 Comment

Ask the Guru: The Vendor Report of Examination (ROE)

Hey Guru
Where in the handbook does it state the Bank should request exam reports on vendors from their regulatory body?

Although there is no formal FFIEC written requirement for obtaining the service provider’s regulatory examination report (report of examination, or ROE), it is mentioned as a best practice in the FFIEC 2012 TSP Handbook:

 The Agencies distribute to serviced financial institutions, either automatically or upon request, the Open section of a TSP ROE. Reports are automatically distributed when the TSP receives a composite URSIT rating of 4 or 5. A serviced financial institution can request a copy of the ROE from the institution’s primary regulator and must demonstrate that it had a valid and current contract with the TSP as of the date of the examination.

However there have been a couple of recent developments that have, in my opinion, increased the ROE from a best practice to a requirement.  First, in 2012 the head of IT risk at the FDIC (and co-author of many of the IT handbooks) Don Saxinger, said in an ABA Telephone Briefing that:

“The No. 1 issue (in FDIC IT examinations in which bank ratings were downgraded) that a lot of examiners told me was the banks are not requesting copies of the exams of their service providers. We do examine service providers. It would be a very good monitoring and continued due diligence practice to see what the regulators are saying about your service providers.”

Second, at the end of last year the Federal Reserve issued their “Guidance on Managing Outsourcing Risk”.  In it they state:

If the service provider delivers information technology services, the financial institution can request the FFIEC Technology Service Provider examination report from its primary federal regulator.

 So when  regulators say “…it would be good monitoring…” and “…you can request…”, what they are really saying is that you better have a pretty good reason if you _don’t_ do it!  Again, you’ll automatically get a copy of the ROE if the vendor scores a 4 or 5, but what these recent events tell me is that this is a de facto requirement and that you shouldn’t wait to hear from the regulator…or the vendor.

So add this to your list of vendor controls.  Reach out to your critical, high-risk vendors and ask if they’ve had a regulatory examination.  If they say yes, call your primary federal examiner and request a copy.  (ROE’s have 2 sections; confidential and open.  The only copy you are allowed to see is the open section.)  Finally, review the report to see if it contains any information that may require additional action on your part.

09 Apr 2014
Hot Topics Tom Hinkel 0 comment

FDIC Re-issues Service Provider Guidance

Originally released in 2001, the FDIC recently re-issued 3 publications related to managing outsourced relationships:

  • Effective Practices for Selecting a Service Provider
  • Tools to Manage Technology Providers’ Performance Risk: Service Level Agreements
  • Techniques for Managing Multiple Service Providers

What struck me about this re-release, and the fact that they were released without modification of any kind, suggests that not only have expectations changed very little over the past 12 years, but also (and more significantly) that regulators expect that you are already adhering to them.  But are you?

First of all, this guidance (and indeed the guidance released last year by the OCC and the Federal Reserve) makes it clear that there is no meaningful distinction between service provider, vendor, subcontractor, and outsourcer…they are all the same as far as regulatory expectations are concerned.

SO just in case the realities of your vendor management activities have fallen short of those expectations, here are just a few things regulators expect:

  • The vendor management process actually starts before the vendor becomes a vendor, indeed it begins even prior to identifying prospective vendors.  It actually starts when management identifies the need for outsourcing, and identifies how outsourcing will support the institutions objectives and strategic plans.
  • Even when only one provider has been identified, you must still evaluate their expertise, technical controls, financial condition and management.
  • Although not a strict requirement, an RFP, RFQ and/or RFI can greatly contribute to the selection process by making sure the deliverables match your expectations.
  • If an RFP was used to solicit proposals, those documents can be incorporated into the contract.
  • The contract remains the single most important vendor management control, and regulators believe the Service Level Agreement (SLA) is a key component in a structuring a successful outsourcing contract.

One final thought on this re-release; between this and the OCC and Federal Reserve issuing updated guidance on outsourcing late last year, and the fact that almost all of the recent updates to FFIEC IT Examination Handbooks dealt either directly or indirectly with vendor management, all lead me to believe even more strongly than ever that this will be a regulator hot-button in the immediate (and foreseeable) future.

01 Apr 2014
From the Field Tom Hinkel 0 comment

Say What You Do…But Do What You Say

Feedback from recent regulatory examinations indicates a potentially troublesome trend; regulators are actually reading your policies.  Traditionally, regulatory findings are concentrated in policy weaknesses.  Either polices don’t exist (social media and mobile banking for example), or they do exist but need “expansion”.  (“Expansion” is a vague and often used-term in examination findings to indicate a shortcoming of some sort.  Either the policy isn’t broad enough or detailed enough or doesn’t conform to current guidance.)

These problems are relatively easy to fix; draft the policy or expand it or enhance it, run it by the Board, and move on.  But every time you add a policy, or expand an existing one, you obligate yourself.  You say you’ll do something a certain way, or with a particular group, or with a specific frequency.   And this is where many recent exam findings have occurred.  Examiners are reading through your policies, and identifying deviations between your policies and procedures and your actual documented practices.

This is nothing new, I originally wrote about it back in 2011.  What is new however is the depth and breadth of the scrutiny.  What used to be primarily limited to Board reporting and testing and auditing, now seems to include almost any instance of “will” or “shall”.  Here is an example of the scope of this challenge.  The following is a short excerpt from the beginning of a typical information security program.*  I’ve highlighted all the areas that obligate the institution in some way or another:

This overall Information Security Program is critical to the safety and soundness of Sample National Bank. Therefore, the Board of Directors shall approve this written Information Security Program. The Board of Directors designates the Information Security Officer to develop, implement, and maintain the Program. Senior management in each functional area of Sample National Bank will be responsible for day-to-day monitoring of compliance with this Program. Any perceived breaches of security or potential risks to non-public information will be reported immediately to the Information Security Officer.

The Information Security Committee will coordinate an independent audit/examination for section 501b GLBA compliance on an annual basis. The independent audit/review will focus especially on areas that were identified as high or moderate risk during the risk assessment process that was coordinated by the Information Security Officer and the Information Security Committee.

Regular testing of key controls, systems, and procedures shall take place as necessary depending on the complexity of the process/system involved. Due to the critical need for independence between those who are responsible for operating a process/system and those who conduct or review the testing, the internal auditor/compliance officer or his/her designee shall be responsible for the review of all testing methodology and results.

So in this short three paragraph, 1/2 page excerpt I count no fewer than nine instances where the institution has obligated themselves to do something:

  1. The Board will approve the program,
  2. The Board will designate the ISO to manage the program,
  3. Senior management in each department will do the day-to-day compliance monitoring,
  4. Breaches of NPI will be reported to the ISO,
  5. There will be an annual GLBA audit,
  6. The audit will be risk-based,
  7. Regular testing will occur,
  8. Testing will be risk-based, and
  9. Internal audit will review all testing.

The policy goes on for another 15 pages, and a quick search for every instance of “will” or “shall” turns up 40 potential opportunities for actual practices to deviate from policies…and all this is in just one policy.

What can you do to avoid this policy vs. practice mismatch?  Use the opportunity of your next policy update to take an inventory of everything you are promising to do, and how you’re supposed to be doing it.  Start with a quick search of all occurrences of “will” or “shall”.  If you’re not doing it, or can’t prove you’re doing it, take it out of your policy.  You may get written up for a policy deficiency, but that’s easy to fix and better than having a finding that “…management states that they are doing <xx>, but examiners could find no documentation that it was being done.”  A “failure to follow policies” is an oversight weakness finding that speaks poorly of management, and often invites further scrutiny into other policy vs. practice deviations.

Of course there is a difference between not doing something, and not being able to prove you’re doing something, but it’s a difference without a distinction as far as the regulators are concerned.  If you can’t prove it, you’re not doing it.  So say what you’ll do, but make sure you can back that up with the meeting minutes, reports, checklists, test results, and other documentation to demonstrate that you’re doing what you say.

[poll id=”8″]

*Thanks to Jackie Marshall at Gladiator Technologies for the use of their InfoSec policy template verbiage.

22 Jan 2014
From the Field Tom Hinkel 0 comment

Windows XP and Electronic Banking

The FFIEC has previously issued a statement on Windows XP and the regulatory expectations for both financial institutions and TSP’s beyond April 8th, but so far the regulators have not weighed in on the implications to e-banking and RDC customers.  According to some estimates, as many as 30-40% of your business customers may still be using Windows XP.  Since Microsoft will discontinue support for WinXP after April 8th of this year, leaving these devices potentially exposed, what is your obligation to your high-risk Internet banking and RDC customers?  What do the regulators expect of you in this situation and better yet, what do your customers expect of you?  Would knowingly allowing your e-banking and RDC software to run on potentially insecure systems be considered “commercially reasonable” security?

According to the FFIEC E-Banking Handbook, financial institutions have an obligation to understand and manage the risks of the electronic banking environment, which includes the customer location.  Similarly, Remote Deposit Capture guidance makes it clear that institutions are required to understand how the risks of using the customer’s systems to engage in RDC impacts your legal, compliance, and operational risks.  That is why most institutions include site visits to the customer location as a part of the customer suitability process prior to approving them for RDC or commercial banking software.  But if your on-site assessment indicated the customer was using an insecure operating system, would you even allow your software to be installed?

Again, examiners may not be looking for this specifically (although I know of at least one auditor that has added it to their IT controls scope of work).  However I recommend that you at least make the effort to reach out to your high risk e-banking and RDC customers and remind them that according to the terms of their contract, you share responsibility for creating and maintaining a secure computing environment for electronic banking.  And then extend your awareness effort to ALL electronic banking customers.

UPDATE – Here is what Microsoft has to say about this.  You may want to reference this in your communications with customers:

Unsupported and unpatched environments are vulnerable to security risks. This may result in an officially recognized control failure by an internal or external audit body, leading to suspension of certifications, and/or public notification of the organization’s inability to maintain its systems and customer information.

© 2025 UFS Tech. All rights reserved. Compliance Guru is a registered trademark of UFS Tech. Privacy Policy