TraceRiskFunctional AreasInformation Technology

Information Technology

How do I Implement ERM?

What does ERM do, actually?

  1. Defines and assigns Risk Values (i.e., Inherent Risk, Threats, Vulnerabilities, Annual Rates of Occurrence, Annual Loss Expectancy, Risk Appetite, Risk Tolerance, and Audit Frequency) for every Subject to be assessed.
  2. Provides ‘use cases’ that give context to the Subjects to be assessed by risk owners and managers.
  3. Provides Key Risk Indicators (KRIs) which will be rated for Probability and Impact.
  4. Sums up Probability and Impact ratings to reach Residual Risk outcomes and help determine audit frequencies.
  5. Provides “How We Reached Our Conclusion” for explaining current Residual Risk outcomes and offers links your own policies, procedures, forms, memos and other documentation that support Residual Risk outcomes.
  6. Provides an decision making custom reports specifically designed for risk owners and managers, senior management, the Board and your regulators.
  7. Provides a method for performing comprehensive “bottom up” risk assessments and for performing risk assessments on emerging products, services and activities before they are deployed.
  8. Provides flexibility when assigning risk owners and risk managers while maintaining full administrative control and oversight by the Chief Risk Officer.
  9. Includes supplementary policies, procedures, accessories, tools, resources, forms and immediate, one-touch access to relevant regulatory guidance (no need to ever leave the TraceRisk website to do regulatory research).

 

Who should perform the risk assessments?

Most banks today have assigned the responsibility for risk management to a Chief Risk Officer. Typically, he or she will be the “gatekeeper” for managing enterprise risk and overseeing the risk assessment process. But, it’s your bank’s risk owners and risk managers who actively participate in the risk assessment process and the TraceRisk implementer can help the Chief Risk Officer identify who they are.

What will the implementation process look like?

Ideally, assign a risk expert to assist your bank with implementing the solution of choice and maximizing all its capabilities and features. The implementer will be performing risk assessments with your staff and should also furnish the bank with a set of supplementary tools and resources including but not limited to:

  • ERM Policy, Procedures and Committee Charter (editable)
  • Checklist – Addressing Risk Management Shortfalls (for Board of Directors’ use)
  • Report Descriptions and Who Should Get Them (reporting TraceRisk outcomes)
  • “Chief Risk Officer’s Risk Management Report to the Board” template
  • Glossary & Definitions; Illustrations; Tips & Tricks when using TraceRisk

 

What does the Implementer do, exactly?

The Implementer assigned to your bank will ideally decades of enterprise risk management experience and be thoroughly familiar with all aspects of the your chosen solution. This individual will work closely with your risk owners and risk managers to accomplish the following:

  • Identify relevant business objectives before meetings or visitation commences.
  • Conduct an initial on-site meeting with senior management, risk managers and risk owners.
  • Identify the events or conditions that could affect the achievement of objectives.
  • Explain what Key Risk Indicators (KRIs) are and how they are used.
  • Assist risk owners and managers in assessing the likelihood and impact of risks across their assigned risk subjects. (This is the fun stuff)
  • Provide insight and tips on how to use the rich data sets captured on each of the 4 Dimensions of Risk: Subject, Silo, COSO & Risk Inventory. (More fun stuff)
  • Provide detailed guidance on how to succinctly and uniformly write conclusions on risk assessment outcomes (outcomes are called “Residual Risk”) and how to develop risk mitigation plans and techniques.
  • Demonstrate how to quickly produce meaningful reports for the Board, the regulators and Executive Management. The variations of the reports are entirely intended audience driven.
  • Train on use of the “New Product/Service – Risk Analysis”
  • Train on use of the “Risk Response” (for indicating how problematic conditions on higher risk Subjects will be handled).
  • Share Best Practices in all aspects of risk assessment and ERM program development.

When should you get started?

Now is the time to start performing your risk assessments. The FRB, OCC, FDIC and CFPB have issued plenty of guidance on risk management and they expect your bank to have your risk assessments done and ready for their field examiners to review.

Let’s get started so you can see what your bank’s risk profile looks like and get some risk mitigation in place before your next regulatory examination.

TraceRisk Demo Button

Demystifying Risk Assessments

Some banks have an idea, albeit vague, about performing risk assessments. But few have made real progress in planning or actually implementing a Risk Assessment Program. Here is a practical approach that demystifies the process so you can get going!

History

Boards of directors have become increasingly aware of the need to manage the wider range of risks across the banking enterprise. They are looking for ways to meet their fiduciary responsibilities, manage their own personal liability and improve the business. They are asking about, and in some cases, are pushing strongly for a more coordinated and comprehensive process of managing risks − enterprise risk management (ERM), in other words.

At the heart of any ERM program is the risk assessment. And for some banks, the ability to perform a risk assessment poses a significant challenge.

Most bankers are already functioning at full capacity and adding to their workload will not be easy. Moreover, what exactly does ERM work look like? C-level officers are frequently at a loss on how to get started or how to make meaningful progress. They may question how risk assessments will enable them to more effectively manage compliance issues.

A “core risk assessment project” is a practical way to take advantage of what is currently being done in the bank and move forward while managing costs in a tight budgetary environment. The starting point is to identify the effectiveness of risk-related activities the bank has already put into place. Gaps can then be identified and prioritized, leading to significant progress on the journey to a more integrated, efficient and value-driven approach to risk management.

Regulator Expectations

Enterprise risk management has been discussed since before Y2K (remember that?), yet it has been rarely implemented effectively. Professional associations, internal audit groups, bank directors and chief risk officers have been hearing about ERM at conferences and seminars and there is no shortage of articles about ERM in trade publications. However, the discussion has remained largely academic and not actionable. In that light, the regulatory agencies have taken up ERM as a principal focus in their examination process and here’s how the OCC views the issue[1]:

“The OCC expects bank management and the board to oversee all new, expanded, or modified products and services through an effective risk management process. Failure to provide an effective risk management process is an unsafe and unsound banking practice. An effective risk management process includes: (1) performing adequate due diligence prior to introducing the product; (2) developing and implementing controls and processes to ensure risks are properly measured, monitored and controlled; and, (3) developing and implementing appropriate performance monitoring and review systems. The formality of the bank’s risk management process should reflect the size of the bank and the complexity of the product or service offered. Depending on these factors, it may be appropriate for the bank to establish an executive management committee to oversee development and implementation of bank products and services.”

While there is a genuine need for risk management, it is unreasonable to expect senior executives to fully understand the risks, and the interrelationships of the risks that their people are taking, without the use of improved tools and better methods.

Challenges

In many organizations, operational risks are being managed but frequently in haphazard and fragmented ways. Many banks lose sight of the big picture and do not sufficiently link risk management activities to their business strategies. Some risks are being identified and managed, but only with limited coordination. Other key risks are not even on the radar screen. Many activities are restricted to a controls-based approach with individual requirements being managed too narrowly. There is minimal or no coordination to take advantage of the value available in aggregating these risk management activities within an effective overall risk management approach.

The consequences of fragmented approaches can result in substantial reputational exposure and regulatory criticism. The challenge most community banks face is getting beyond the talking stage and understanding what needs to be done, and then getting on with it in a coordinated, uniform manner that does not require “reinventing the wheel” every year.

Let’s look at the benefits of a well established risk assessment program:

  • It establishes the inherent risk for each area under review
  • It establishes thresholds for risk appetite and risk tolerance
  • It establishes the Key Risk Indicators (KRIs) in a way that promotes a broader understanding of risks
  • It provides for measuring the probability of an adverse event or condition and the consequent impact
  • It provides a “residual” risk that establishes an overall risk profile for the bank
  • It puts in place a process to highlight the key risks, set an action plan, and then establish accountability for risk mitigation
  • It provides a consistent, uniform way of looking at risk at three different but connected levels: from a management perspective; from a Board perspective and from a bank examiner’s perspective
  • It enables organizational alignment to manage the risks and control the costs
  • It allows the bank to take on and effectively manage risks that its competitors cannot

Gaps

Risks to banks are categorized in operational, financial reporting and compliance areas – the three objectives of the integrated framework modified by the Committee of Sponsoring Organizations (COSO) in 2013. The illustration below looks complicated, but you needn’t fret about it. Just know that this universal framework has been designed to help foster an understanding of the dimensions of risk for those persons charged with risk program development. We’ll demystify all of this for you as you read further.

COSO’s visual model for ERM resembles a complex Rubik’s Cube®, and it is daunting to many bankers. In addition to the three risk objectives mentioned, there are five stages in the COSO ERM integrated framework representing what is needed to achieve each of the objectives (operational, reporting and compliance).

cosoReading from top to bottom, the five components start with “Control Environment” and conclude with “Monitoring Activities,” and there is a clear sequence of activities; some of the interim stages include “Risk Assessment” and “Risk Response.”

The remaining visible side of the cube outlines different levels of the organization. The categorization starts at the broadest level, the entity (or entire enterprise) and proceeds to a subsidiary level. This element of the model is designed to be tailored to each business line of the bank depending on organizational structure. Judging from the complexity of the COSO ERM model, the accompanying framework and separate risk assessment techniques, implementing ERM using this model as a starting point will not happen in most banks unless they have considerable resources and flawless project management skills.

So, What’s the Solution?

Enterprise risk management is a worthy goal for all banks, regardless of size. Risk management activities need to be tied to strategy and ultimately built into everyday business processes. The following project plan can enable banks to identify and coordinate activities they already have begun, identify risks not adequately managed, close gaps, and move forward. The steps of this plan are: 1) organizing your team; 2) establishing a framework; 3) assessing risks; 4) inventorying current risk-response activities; and, 5) closing the gaps.

 

Leveraging existing knowledge and programs will go a long way to helping reduce the effort in getting started. For example, internal audit, the compliance officer, the IT security officer and your risk officer (if you have one) have probably already conducted some type of risk assessment.

 

Here’s how to do it. . .

 

  • Organize the Effort: Bring resources together to coordinate your activities

 

To start on the right foot, it is important to assemble the right people and agree on timelines and objectives. Organizing requires assembling all the department heads and managers who have responsibilities for risk management activities to oversee the project and guide what will be done, when and by whom. The risk assessment processes need to be built with these stakeholders in mind and designed to suit the needs of the bank. Since the risk assessment is ultimately strategic in nature, it will never succeed without support from the Chief Executive Officer and other C-suite officers. It may be helpful to include the Chief Financial Officer, Chief Operating Officer, Internal Audit Director, Legal Counsel and, of course, the Chief Risk Officer, if you have one, into the process.

 

  • Establish a Framework Around Risk: Develop a model but keep it simple.

 

The risk assessment model should be comprehensive and useful, particularly for smaller banks where investment in risk assessment tools may have limitations. At TraceRisk, we have found that Software-as-aService (SaaS) offers the most cost-effective and readily implementable solution for performing the risk assessments. The approach to get started is one that works from a basic and logical model: Identify – Assess – Mitigate. “Identification” means knowing the key risks (KRIs); the “Assessment” stage involves scoring the probability and impact of events and conditions; and, the “Mitigation” phase means dealing with residual risks (mitigation).

 

A common understanding of some other key terms will be helpful so team members are on the same page when it comes to comprehending risk concepts, performing risk assess-ments and implementing risk management. Here are some of the most common terms:

  • Risk Appetite: The amount of risk that a bank is willing to seek or accept in the pursuit of its long term objectives.
  • Risk Tolerance: The boundaries of risk taking outside of which the bank is not prepared to venture in the pursuit of its long term objectives.
  • Risk Universe: The full range of risks which could impact, either positively or negatively, on the bank’s capabilities.
  • Risk Capacity: The amount and type of risk the bank is able to support in pursuit of its business objectives.
  • Risk Target: The optimal level of risk the bank wants to take in pursuit of a specific business goal.
  • Risk Limit: Thresholds to monitor that actual risk exposure does not deviate too much from the risk target and stays within the bank’s risk tolerance/risk appetite. Exceeding risk limits will typically trigger management action.
  • The Business Context: This includes understanding the state of development of the bank as a business, its size, industry sector, geographical spread and the complexity of the business model.
  • Risk Management Culture: This addresses the extent to which the board (and its relevant committees), management, staff and regulators understand and embrace the risk management systems and processes of the bank.
  • Risk Management Processes: This refers to the extent to which there are processes for identifying, assessing, responding to and reporting on risks and risk responses within the bank.
  • Risk Assessment: This refers to the bank’s identification of inherent risk, the probability of adverse events or conditions, the impact of such events or conditions, the resultant residual risk, an explanation of how risk conclusions were reached and what actions are planned or taken relative to the level of residual risk.
  • Risk Management Systems: This means the extent to which there are appropriate IT and other systems to support the risk management processes.
  • Risk Capacity: The resources, including financial, intangible and human, which a bank is able to deploy in managing risk.
  • Risk Management Maturity: The level of skills, knowledge and attitudes displayed by people in the bank, combined with the level of sophistication of risk management processes and systems in managing risk within the bank.
  • Risk Capability: A function of the risk capacity and risk management maturity which, when taken together, enable a bank to manage risk in the pursuit of its long term objectives.
  • Propensity to Take Risk: The extent to which people in the bank are predisposed to undertaking activities the impact, timing and likelihood of which are unknown, and which is influenced by financial, cultural, performance and ethical considerations.
  • Propensity to Exercise Control: The extent to which people in the bank are predisposed to take steps to change the likelihood, timing or impact of risks, influenced by financial, cultural, performance and ethical considerations.
  • Performing the Actual Risk Assessment: Avoid getting lost in the details. Start off by thinking broadly about risk and then become more detailed.

Most community banks are already doing a good deal of risk management, but the processes and reporting are often isolated, inconsistent and fragmented. Risks related to internal controls over UDAAP for example, are under scrutiny because of Dodd-Frank. ECOA risks are managed centrally in many banks while at others, it is de-centralized. In some banks, Fair Lending risks are never even measured at all! At this point it is important to ascertain how much your bank is already doing to manage risk. Your team will need to interview key people and ask questions in an open-ended way using Key Risk Indicators (KRIs) as guidance (the “Identification” phase).

Likely candidates to interview include the Compliance Officer, the BSA Officer, the Security Officer (physical and IT/Data) the Chief Credit Officer, heads of business units and your marketing officer. Use Key Risk Indicators to establish a dialogue that brings out the reality of compliance risk without suggesting what it should be.

Rather than thinking in narrow terms, start off by thinking about the largest risk your bank faces: not achieving its overall business objectives. These objectives emerge from the strategic direction set at the highest levels of the bank. Then, begin to identify what the top 10 risks at your bank could be and how they affect the bank’s overall strategic objectives. Confining your list to 10 key risks (or 5, or 15, depending on your bank) in this early stage will keep your team focused on the big picture rather than becoming mired in details.

Once you have corralled the top 10 risks, you can break them down by subject, regulation, department or any other criteria that suits your bank or approach so you can begin to assess the specific risks and get closer to the actual “residual risk” levels (the amount of risk left over after mitigation techniques have been applied). This is the “assessment” phase[2].

A good assessment tool will help you identify a universe of 25 to 40 risks per subject (i.e., products, services, functional areas) so you can learn where risks reside throughout the bank and you can assess their significance. Residual risks will not be the same for any two banks. For some banks, the significance of their geographic area poses higher risks than other financial institutions. In other cases, product risk will have higher risk implications. Still others may face bigger risks when it comes to pricing. It is up to the team to collaborate across the bank’s array of products and services to identify, understand and mitigate the residual risks.

Developing strong risk assessments will not require discontinuation of existing risk activities and starting from scratch. Instead, you can build on existing activities that have proven value and transfer the data into a risk assessment analysis model to achieve a more holistic outcome.

  • Identify Gaps and Prioritize: Compare your inventory of current risk responses to the top 10 priorities.

Now that you know the risks that can impede achievement of your bank’s business objectives, along with the risk response activities currently being conducted, you can study the residual risks. Which risks are being adequately managed? Which ones are missing from the radar screen? Where is an initiative already in place that help you to better understand and manage risks?

Once the residual risks by subject have been assessed, the next step is to develop an approach to close the gaps (this is the “mitigation” phase). This begins with prioritizing which gaps have the greatest potential to derail achievement of your bank’s business objectives. Which would require the greatest deployment of human or financial capital? Which ones would demand outside resources? Which ones could be accomplished in the shortest time?

Many elements of your bank’s existing structure may be sufficient and will be retained, but significant gaps will probably be found. These may be in risk management leadership, risk assessment methodology, specific technical skills, common processes or technological capabilities. Internal cultural biases or paradigms may need to be changed as well.

After weighing the urgency and the resources required, you then can develop specific strategies to close the most critical gaps. While keeping the desired end result in mind, each of the strategies can be slotted into an implementation plan, complete with action steps and a timeline. A process will need to be established for ongoing reporting of the progress to mitigate the risks, as well as periodic reassessment of the risks being tracked.

Discuss ways to move forward with members of your team and let members of this group direct you to the appropriate people for answers. Also, be alert for new risks, whether arising from the environment, regulatory changes, competitors or new products. You’ll need to include recommendations to guide the bank to improve ongoing risk assessment processes. Decisions will need to be made on how to best manage a risk and where it should be managed. Will you centralize certain activities, or embed them in specific processes or business units?

Conclusion

Assessing risk is a journey. A well-defined and supported risk assessment project enables the bank to “jump start” the process, rather than delaying moving forward because the concept seems grandiose, costly and unworkable. In fact, delaying further on assessing enterprise risk can very likely lead to regulatory action in the form of a “Matter Requiring Attention” or worse, compelling your bank to develop and implement a risk assessment program within a timeframe set by the regulators. Nobody wants that.

It’s best to take stock of existing risk assessments as well as risk-response activities and build on them right now. At the end of the project, your executive management group, the Board of Directors and your risk assessment team will realize the value of implementing the risk assessment model and continuing the risk management journey.

To learn more or to see how the TraceRisk solution can save you tons of time and dollars, call Derek Yankoff, Chief Design Officer at (877) 711-4824

or email him at derek.yankoff@tracerisk.com

Copyright ©2016 TraceRisk llc All Rights Reserved. TraceRisk and the TraceRisk logo are trademarks of MSBMCo, Inc. in the U.S. and/or other countries. All other trademarks are the property of their respective owners.

[1] OCC Bulletin 2004-20

[2] TraceRisk has this approach built right in on over 75 Subjects and 3000 KRIs.


Cybersecurity Guide!

cybersecurity
Data breaches resulting in the compromise of personally identifiable information affects of thousands of Americans. Intrusions into financial, corporate and government networks are no longer rare or isolated incidents. Complex financial schemes committed by sophisticated cyber criminals against businesses and the public in general are now commonplace. These are just a few examples of crimes perpetrated online over the past year or so, and part of the reason why FBI Director James Comey, testifying before Congress last week, said that “the pervasiveness of the cyber threat is such that the FBI and other intelligence, military, homeland security, and law enforcement agencies across the government view cyber security and cyber attacks as a top priority.” The FBI, according to Comey, targets the most dangerous malicious cyber activity—high-level intrusions by state-sponsored hackers and global cyber syndicates, and the most prolific botnets. And in doing so, we work collaboratively with our domestic and international partners and the private sector.

Financial institutions, regardless of size, are particularly vulnerable to cyber attacks and that’s why it’s so important to assess your risks in this critical area of your operations. To assist you in this effort TraceRisk has developed a Cyber Security Risk Management Guide. Our clients have found it to be very helpful and, just like we do for our ERM clients, we’re making it available to you FREE OF CHARGE! A copy of the Table of Contents is attached so you can see what is covered.

Guide to Developing a Cyber Security and Risk Mitigation Plan
A Community Bank White Paper from TraceRisk™

Table of Contents
Preface
Purpose
Scope
Target Audience
Introduction
Building a Risk Management Program
Appointing Leadership
Establishing a Risk Management Framework
Defining the System
Cyber Asset Identification and Classification
Identifying Critical Cyber Assets (Additional Guidance URLs)
Classifying Cyber Assets
Personally Identifying Information (PII)
Identifying the Electronic Security Perimeter (ESP) Protecting Cyber Assets
Conducting a Vulnerability Assessment (Additional Guidance URLs)
Assessing and Mitigating Risks
Assessing Impact and Risk Levels
Mitigating Risks with Security Controls (Additional Guidance URLs)
Evaluating and Monitoring Control Effectiveness
Addressing People and Policy Risks
Cyber Security Policy
Security Policy Elements
Security Related Roles and Responsibilities
Policy Implementation and Enforcement
Policy Exceptions (Additional Guidance URLs)
Personnel and Training
Security Awareness and Training (Additional Guidance URLs)
Due Diligence in Hiring
Access Privileges
Operational Risks
Perform Periodic Risk Assessment and Mitigation
Enforce Access Control, Monitoring and Logging
Perform Disposal or Redeployment of Assets (Additional Guidance URLs)
Enforce Change Control and Configuration Management
Conduct Vulnerability Assessments (Additional Guidance URLs)
Control, Monitor and Log all Access to Assets
Configuration and Maintenance (Additional Guidance URLs)
Incident Handling (Additional Guidance URLs)
Contingency Planning (Additional Guidance URLs)
Insecure Software Development Life Cycle (SDLC) Risks
Physical Security Risks
Plan and Protection
Monitoring, Logging and Retention
Maintenance and Testing
Third Party Relationships
Addressing Technology Risks
Network Risks
Platform Risks
Application Layer Risks
Communications Systems
Supervisory Control and Data Acquisition (SCADA)
Identifying and Protecting Private Data (Additional Guidance URLs)
Steps in Vulnerability Assessments
Incident Response Planning Items
Disaster Response Planning Items
Glossary and Appendices


Core Compliance

Use Case for Assessing Risk on Outsourced Core Processing

Why assess the risk? Outsourced IT services can contribute to operational risks (also referred to as transaction risks). Operational risk may arise from fraud, error or the inability to deliver products or services, maintain a competitive position or manage information. It exists in each process involved in the delivery of the bank’s products or services. Operational risk not only includes operations and transaction processing, but also areas such as customer service, systems development and support, internal control processes and capacity and contingency planning. Operational risk also may affect other risks such as interest rate, compliance, liquidity, price, strategic or reputation risk.

Who should assess the risks? Information Technology Officer, Data Security Officer, Chief Operating Officer

How to assess the risk: Rate the KRIs to determine if a threat would successfully exploit a vulnerability and to justify expenditures to implement countermeasures to protect the bank’s assets or reputation. Use the “Focus Risk Assessment” tool for in-depth analysis of risks and mitigation techniques.

TraceRisk Demo Button

Assessing Risk on Cybersecurity

Use Case for Assessing Risk on Cybersecurity

Why assess the risk? Banks must create, provision, and operate a formal incident response capability and report all incidents consistent with an incident response policy. Establishing an incident response capability should include the following actions:

  • Creating a cybersecurity incident response policy and plan
  • Developing procedures for performing incident handling and reporting
  • Setting guidelines for communicating with outside parties regarding incidents
  • Selecting a team structure and staffing model
  • Establishing relationships and lines of communication between the incident response team and other groups, both internal (e.g., legal department) and external (e.g., law enforcement agencies)
  • Determining what services the incident response team should provide
  • Staffing and training the incident response team

Banks should reduce the frequency of incidents by effectively securing networks, systems and applications.Preventing problems is often less costly and more effective than reacting to them after they occur. Thus, incident prevention is an important complement to an incident response capability. If security controls are insufficient, high volumes of incidents may occur. This could overwhelm the resources and capacity for response, which would result in delayed or incomplete recovery and possibly more extensive damage and longer periods of service and data unavailability. Incident handling can be performed more effectively if organizations complement their incident response capability with adequate resources to actively maintain the security of networks, systems, and applications. This includes training IT staff on complying with the bank’s security standards and making users aware of policies and procedures regarding appropriate use of networks, systems, and applications.

Banks should document their guidelines for interactions with other organizations regarding incidents. During incident handling, the bank will need to communicate with outside parties, such as other incident response teams, law enforcement, the media, vendors, and victim organizations. Because these communications often need to occur quickly, banks should predetermine communication guidelines so that only the appropriate information is shared with the right parties.

Banks should be generally prepared to handle any incident but should focus on being prepared to handle incidents that use common attack vectors. Incidents can occur in countless ways, so it is not feasible to develop step-by-step instructions for handling every incident. Different types of incidents merit different response strategies. The attack vectors are:

  • External/Removable Media: An attack executed from removable media (e.g., flash drive, CD) or a peripheral device
  • Attrition: An attack that employs brute force methods to compromise, degrade, or destroy systems, networks or services
  • Web: An attack executed from a website or web-based application
  • Email: An attack executed via an email message or attachment
  • Improper Usage: Any incident resulting from violation of a bank’s acceptable usage policies by an authorized user, excluding the above categories
  • Loss or Theft of Equipment: The loss or theft of a computing device or media used by the organization, such as a laptop or smartphone.
  • Other: An attack that does not fit into any of the other categories.

Banks should emphasize the importance of incident detection and analysis throughout the organization. In a bank, millions of possible signs of incidents may occur each day, recorded mainly by logging and computer security software. Automation is needed to perform an initial analysis of the data and select events of interest for human review. Event correlation software can be of great value in automating the analysis process. However, the effectiveness of the process depends on the quality of the data that goes into it. Banks should establish logging standards and procedures to ensure that adequate information is collected by logs and security software and that the data is reviewed regularly.

Banks should create written guidelines for prioritizing incidents. Prioritizing the handling of individual incidents is a critical decision point in the incident response process. Effective information sharing can help an organization identify situations that are of greater severity and demand immediate attention. Incidents should be prioritized based on the relevant factors, such as the functional impact of the incident (e.g., current and likely future negative impact to business functions), the information impact of the incident (e.g., effect on the confidentiality, integrity, and availability of the bank’s information), and the recoverability from the incident (e.g., the time and types of resources that must be spent on recovering from the incident).

Banks should use the lessons learned process to gain value from incidents. After a major incident has been handled, the bank should hold a lessons learned meeting to review the effectiveness of the incident handling process and identify necessary improvements to existing security controls and practices. Lessons learned meetings can also be held periodically for lesser incidents as time and resources permit. The information accumulated from all lessons learned meetings should be used to identify and correct systemic weaknesses and deficiencies in policies and procedures. Follow-up reports generated for each resolved incident can be important not only for evidentiary purposes but also for reference in handling future incidents and in training new team members.

Who should assess the risks? Information Technology Officer, Data Security Officer, Electronic Banking Officer, Operations Administrator, Cash Management/ACH Officer

How to assess the risk: Rate the KRIs to determine if a threat would successfully exploit a vulnerability and to justify expenditures to implement countermeasures to protect the bank’s assets or reputation. Use the “Focus Risk Assessment” tool for in-depth analysis of risks and mitigation techniques.

Schedule a Demo

Cloud Computing – Outsourced

Use Case for Cloud Computing

Important considerations for banks deploying a public cloud computing model includes clearly identifying and mitigating legal, regulatory and reputational risks. The bank’s ability to assess risk may be more complex and difficult in an environment where the cloud computing service provider processes and stores data overseas or comingles the bank’s data with data from other customers that operate under diverse legal and regulatory jurisdictions. The bank should understand the applicability of laws and regulations governing this technology and the bank’s ability to control access to its data.

Who Should Assess the Risk? Chief Technology Officer, Data Security Officer, Chief Information Officer


Assessing Risk on Cybersecurity

Use Case for Assessing Risk on Cybersecurity

Why assess the risk? Banks must create, provision, and operate a formal incident response capability and report all incidents consistent with an incident response policy. Establishing an incident response capability should include the following actions:

  • Creating a cybersecurity incident response policy and plan
  • Developing procedures for performing incident handling and reporting
  • Setting guidelines for communicating with outside parties regarding incidents
  • Selecting a team structure and staffing model
  • Establishing relationships and lines of communication between the incident response team and other groups, both internal (e.g., legal department) and external (e.g., law enforcement agencies)
  • Determining what services the incident response team should provide
  • Staffing and training the incident response team

Banks should reduce the frequency of incidents by effectively securing networks, systems and applications. Preventing problems is often less costly and more effective than reacting to them after they occur. Thus, incident prevention is an important complement to an incident response capability. If security controls are insufficient, high volumes of incidents may occur. This could overwhelm the resources and capacity for response, which would result in delayed or incomplete recovery and possibly more extensive damage and longer periods of service and data unavailability. Incident handling can be performed more effectively if organizations complement their incident response capability with adequate resources to actively maintain the security of networks, systems, and applications. This includes training IT staff on complying with the bank’s security standards and making users aware of policies and procedures regarding appropriate use of networks, systems, and applications.

Banks should document their guidelines for interactions with other organizations regarding incidents. During incident handling, the bank will need to communicate with outside parties, such as other incident response teams, law enforcement, the media, vendors, and victim organizations. Because these communications often need to occur quickly, banks should predetermine communication guidelines so that only the appropriate information is shared with the right parties.

Banks should be generally prepared to handle any incident but should focus on being prepared to handle incidents that use common attack vectors. Incidents can occur in countless ways, so it is not feasible to develop step-by-step instructions for handling every incident. Different types of incidents merit different response strategies. The attack vectors are:

  • External/Removable Media: An attack executed from removable media (e.g., flash drive, CD) or a peripheral device
  • Attrition: An attack that employs brute force methods to compromise, degrade, or destroy systems, networks or services
  • Web: An attack executed from a website or web-based application
  • Email: An attack executed via an email message or attachment
  • Improper Usage: Any incident resulting from violation of a bank’s acceptable usage policies by an authorized user, excluding the above categories
  • Loss or Theft of Equipment: The loss or theft of a computing device or media used by the organization, such as a laptop or smartphone.
  • Other: An attack that does not fit into any of the other categories.

Banks should emphasize the importance of incident detection and analysis throughout the organization. In a bank, millions of possible signs of incidents may occur each day, recorded mainly by logging and computer security software. Automation is needed to perform an initial analysis of the data and select events of interest for human review. Event correlation software can be of great value in automating the analysis process. However, the effectiveness of the process depends on the quality of the data that goes into it. Banks should establish logging standards and procedures to ensure that adequate information is collected by logs and security software and that the data is reviewed regularly.

Banks should create written guidelines for prioritizing incidents. Prioritizing the handling of individual incidents is a critical decision point in the incident response process. Effective information sharing can help an organization identify situations that are of greater severity and demand immediate attention. Incidents should be prioritized based on the relevant factors, such as the functional impact of the incident (e.g., current and likely future negative impact to business functions), the information impact of the incident (e.g., effect on the confidentiality, integrity, and availability of the bank’s information), and the recoverability from the incident (e.g., the time and types of resources that must be spent on recovering from the incident).

Banks should use the lessons learned process to gain value from incidents. After a major incident has been handled, the bank should hold a lessons learned meeting to review the effectiveness of the incident handling process and identify necessary improvements to existing security controls and practices. Lessons learned meetings can also be held periodically for lesser incidents as time and resources permit. The information accumulated from all lessons learned meetings should be used to identify and correct systemic weaknesses and deficiencies in policies and procedures. Follow-up reports generated for each resolved incident can be important not only for evidentiary purposes but also for reference in handling future incidents and in training new team members.

Who should assess the risks? Information Technology Officer, Data Security Officer, Electronic Banking Officer, Operations Administrator, Cash Management/ACH Officer

How to assess the risk: Rate the KRIs to determine if a threat would successfully exploit a vulnerability and to justify expenditures to implement countermeasures to protect the bank’s assets or reputation. Use the “Focus Risk Assessment” tool for in-depth analysis of risks and mitigation techniques.