Ask the Guru – Page 3 – Compliance Guru

19 Oct 2016

Ask the Guru Holly Hooks 1 Comment

Ask the Guru: “The Cybersecurity Assessment Tool… Do we have to?”

Hey Guru!

Management is asking why we have to complete the FFIEC Cybersecurity Assessment Tool when it is voluntary. They feel it is too much work if it is not mandatory. I think it is still needed even though it is voluntary. Is there any documentation as to why it is still necessary for OCC banks to complete the Assessment?

The FFIEC issued a press release October 17, 2016, on the Cybersecurity Assessment Tool titled Frequently Asked Questions. This reiterated that the assessment is voluntary and an institution can choose to use either this assessment tool, or an alternate framework, to evaluate inherent cybersecurity risk and control maturity.

Since the tool was originally released in 2015, all the regulatory agencies have announced plans to incorporate the assessment into their examination procedures:

OCC Bulletin 2015-31 states “The OCC will implement the Assessment as part of the bank examination process over time to benchmark and assess bank cybersecurity efforts. While use of the Assessment is optional for financial institutions, OCC examiners will use the Assessment to supplement exam work to gain a more complete understanding of an institution’s inherent risk, risk management practices, and controls related to cybersecurity.”
Federal Reserve SR 15-9 states “Beginning in late 2015 or early 2016, the Federal Reserve plans to utilize the assessment tool as part of our examination process when evaluating financial institutions’ cybersecurity preparedness in information technology and safety and soundness examinations and inspections.”
FDIC FIL-28-2015 states “FDIC examiners will discuss the Cybersecurity Assessment Tool with institution management during examinations to ensure awareness and assist with answers to any questions.”
NCUA states “FFIEC’s cybersecurity assessment tool is provided to help them assess their level of preparedness, and NCUA examiners will use the tool as a guide for assessing cybersecurity risks in credit unions. Credit unions may choose whatever approach they feel appropriate to conduct their individual assessments, but the assessment tool would still be a useful guide.”

Even though the FFIEC format is officially voluntary, the institution still has to evaluate inherent risk and cybersecurity preparedness in some way. Therefore, unless you already have a robust assessment program in place, we strongly encourage all institutions to adopt the FFIEC Cybersecurity Assessment Tool format since this is what the examiners will use.

NOTE: The FAQ also made it clear that the FFIEC does not intend to offer an automated version of the tool. To address this, we have developed a full-featured cybersecurity service (RADAR) that includes an automated assessment, plus a gap analysis / action plan, cyber-incident response test, and several other components.

13 Oct 2015

Ask the Guru Tom Hinkel 2 Comments

Ask the Guru: Cybersecurity “Risk Appetite”

Hey Guru
I saw multiple references to the term “risk appetite” in the FFIEC Cybersecurity Assessment Tool. What exactly is risk appetite, and how can I address this in my institution? They just released Management Handbook contains 10 new references to “risk appetite”, including a requirement that the Board has defined the institution’s risk appetite and it’s risk tolerance levels.

There are 6 references to “risk appetite” in the FFIEC cybersecurity tool, and although it is not a new concept in risk management, this is a term I have not seen in regulatory guidance before outside of lending and credit practices. Here are all references in context:

The institution has a cyber risk appetite statement approved by the board or an appropriate board committee.
The board or board committee approved cyber risk appetite statement is part of the enterprise-wide risk appetite statement.
The risk appetite is informed by the institution’s role in critical infrastructure.
The independent audit function regularly reviews management’s cyber risk appetite statement.
The independent audit function regularly reviews the institution’s cyber risk appetite statement in comparison to assessment results and incorporates gaps into the audit strategy.
Threat intelligence is viewed within the context of the institution’s risk profile and risk appetite to prioritize mitigating actions in anticipation of threats.

Risk tolerance is pretty well documented in current guidance, and although there are subtle differences between the terms, I see risk tolerance and risk appetite as largely synonymous for most institutions. Here is a good working definition of risk appetite:

The amount of risk that an enterprise is willing to pursue and accept in order to achieve the goals and objectives of their strategic plan.

How should you address cybersecurity risk appetite? You probably already have both inherent and residual risk assessed in your cybersecurity risk assessment, and have identified each as either “High”, “Medium”, or “Low”. Risk “appetite” is simply a decision by management that the residual risk level is acceptable. In other words, management is willing to accept the remaining risk as the cost of achieving its objectives.

For example, you’ve identified a vendor as having high inherent risk, and applied the necessary controls to reduce the risk as much as you can. The remaining (residual) risk is deemed by management to be either acceptable or unacceptable based on their risk tolerance. So if you use a “High”, “Medium” and “Low” designation for residual risk, a value of “Low” or even “Medium” can be deemed acceptable if it is within the risk appetite of the institution.

Establishing your risk appetite for cybersecurity can be accomplished using either a qualitative or quantitative approach. A quantitative approach requires an analysis of specific financial loss connected to a cybersecurity event. While this is a valid way to document risk, it can be a challenge for all but the largest institutions.

Most institutions prefer a qualitative approach, which uses a scale (i.e. 1 – 10, or H, M, and L) to rank the impact of a cyber event on reputation risk, strategic risk, regulatory/legal risk and/or operational risk. Management can then determine the level of acceptable risk in each risk category. For example, you may decide you have a very low (1-3) tolerance for risks in the reputation category, but you may be willing to accept a higher level (3-5) in the operational area.

Dispelling 5 IT Outsourcing Myths within Financial Institutions

Learn why some of the most commonly believed “facts” about IT outsourcing for banks are actually myths.

Once you’ve established your risk appetite, the easiest way to document it is to add a “Risk Appetite” column to your existing cybersecurity risk assessment (ideally just after “Residual Risk”), where you designate remaining risk as either acceptable or unacceptable.

You might also want to amend your Information Security Policy to add a risk appetite statement. Something like this:

“The Board has established specific strategic goals and objectives as defined in its strategic plan. To increase the probability of achieving these goals, the Board has established acceptable risk tolerances within its risk appetite. The board periodically reviews the risk appetite and associated tolerances, and may adjust them to adapt to changing economic conditions and/or strategic goals.”

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.

03 Dec 2013

Ask the Guru, From the Field Tom Hinkel 2 Comments

Ask the Guru: The IT Audit “Scope”

Hey Guru
Our examiner is asking about the “scope” of our IT audits. What is she referring to, and how do we define a reasonable scope?

Audit results are one of the first things examiners want to see, and the “scope” of the audit is very important to examiners. In fact, the term is used 74 times in the FFIEC Audit Handbook! Scope generally refers to the depth and breadth of the audit, which is in turn determined by the objectives or what the audit is designed to accomplish. The two broad objectives for any audit are control adequacy and control effectiveness*. Control adequacy means that the controls you have in place (policies, procedures and practices) address all reasonably identifiable risks. These audits are sometimes referred to as policy (and sometimes ITGC, or IT general controls) audits. Although the standards used for these audits may differ (more on that later), the scope of these audits should ultimately address the requirements outlined in the 11 IT Examination Handbooks.

Once control adequacy is established, the next thing the examiners want to know is “OK the controls exist, but do the controls work?”, i.e. are they effective? Are they indeed controlling the risks the way they were designed to? Those types of audits are more commonly (and accurately) described as tests or assessments, usually referred to as penetration (PEN) tests, or vulnerability assessments (VA). They may either be internal, external, or (preferably) both.

Sequentially, the audits must be conducted in that order. In other words, you must first establish adequacy before you test for effectiveness. It really doesn’t make sense to test controls that don’t directly address your risks. In fact although an auditor will sometime combine the 2 audits into a single engagement, I encourage folks to separate them so that any deficiencies in control adequacy can be corrected prior to the PEN testing.

One more thing to consider is the standard by which the auditor will conduct their audit, sometime referred to as their “work program”. These are the guidelines the auditor will use to guide the project and conduct the audit. While there are several industry established IT standards out there…COBIT, ITIL, COSO, ISO 27001, SAS 94, NIST, etc., there is no one single accepted standard. The fact is most auditors use a customized hybrid work program, and the vast majority are perfectly acceptable to the examiners. However at some point in your evaluation process with a new auditor you should ask them why they prefer one standard over another. Whatever their preference, make sure that somewhere in their scope-of-work document they make reference to the FFIEC examination guidelines. This assures that they are familiar with the unique regulatory requirements of financial institutions.

Regarding cost, there are often wide disparities between seemingly similar engagements, and it’s easy to see why. In order to make a side-by-side comparison you’ll need to know a few things: Is the audit focused on control adequacy or control effectiveness (or both)? If both, are they willing to break the engagement into 2 parts? What is the audit standard they’ll be using, and why? What methods will they use to test your controls; inquiry or inspection and sampling? Are vulnerability assessments internal or external (or both)? What are the certifications of the auditors and how much experience do they have with financial institutions? Finally, if the examiners have questions or concerns about the auditor’s methodology, or if examiner findings seem to conflict with audit results, will the auditor work with you to respond to the examiner?

In summary, the scope of the audit is defined as either:

To assess and determine the adequacy (or design and operation) of our controls
To assess and determine the effectiveness of our controls
All of the above

So the examiner will want to know the scope, but it’s to your benefit for you to understand it too because examiners will often use the results of your audits to shape and possibly reduce* the scope of their examination!

* Some audits will break the first objective into two sections; design (are they designed properly), and operation (are they in place and operational).
** FFIEC IT Examination Handbook, Audit, Page 8

20 Aug 2013

Ask the Guru, From the Field Tom Hinkel 2 Comments

Ask the Guru: Vendor vs. Service Provider

Hey Guru
I recently had an FDIC examiner tell me that we needed to make a better distinction between a vendor and a service provider. His point seemed to be that by lumping them together in our vendor management program we were “over-analyzing” them. He suggested that we should be focused instead only on those few key providers that pose the greatest risk of identity theft. Our approach has always been to assess each and every vendor. Is this a new approach?

I don’t think so, although I think I know where the examiner is coming from on the vendor vs. service provider distinction. First of all, let’s understand what is meant by a “service provider”. The traditional definition of a service provider was one who provided services subject to the Bank Service Company Act (BSCA), which dates back to 1962. As defined in Section 3 of the Act, these services include:

“…check and deposit sorting and posting, computation and posting of interest and other credits and charges, preparation and mailing of checks, statements, notices, and similar items, or any other clerical, bookkeeping, accounting, statistical, or similar functions performed for a depository institution.”

But lately the definition has expanded way beyond the BSCA, and today almost anything you can outsource can conceivably be provided by a “service provider”. In fact according to the FDIC, the products and services provided can vary widely:

“…core processing; information and transaction processing and settlement activities that support banking functions such as lending, deposit-taking, funds transfer, fiduciary, or trading activities; Internet-related services; security monitoring; systems development and maintenance; aggregation services; digital certification services, and call centers.”

Furthermore, in a 2010 interview with BankInfoSecurity, Don Saxinger (Team Lead – IT and Operations Risk at FDIC) said this regarding what constitutes a service provider:

“We are not always so sure ourselves, to be quite honest…but, in general, I would look at it from a banking function perspective. If this is a function of the bank, where somebody is performing some service for you that is a banking function or a decision-making function, including your operations and your technology and you have outsourced it, then yes, that would be a technology service that is (BSCA) reportable.”

Finally, the Federal Reserve defines a service provider as:

“… any party, whether affiliated or not, that is permitted access to a financial institution’s customer information through the provision of services directly to the institution. For example, a processor that directly obtains, processes, stores, or transmits customer information on an institution’s behalf is its service provider. Similarly, an attorney, accountant, or consultant who performs services for a financial institution and has access to customer information is a service provider for the institution.”

And in their Guidance on Managing Outsourcing Risk…

“Service providers is broadly defined to include all entities that have entered into a contractural relationship with a financial insitiution to provide business functions or activities”

So access to customer information seems to be the common thread, not necessarily the services provided. Clearly the regulators have an expanded view of a “service provider”, and so should you. Keep doing what you’re doing. Run all providers through the same risk-ranking formula, and go from there!

One last thought…don’t get confused by different terms. According the the FDIC as far back as 2001, other terms synonymous with “service providers” include vendors, subcontractors, external service provider (ESPs) and outsourcers.

← Previous 1 23