A funny thing about human nature is that we really don’t like to spend a great deal of time thinking about what can go wrong. This reflects both the fact that, in general, we do tend to be optimistic about the future and the fact that thinking about bad things is, well, depressing. But sound risk management requires that we take a deliberate, structured approach to considering various types of events to thoughtfully consider how we will respond. Ironically, the process of planning and provisioning is actually very empowering. The more you have assessed different types of risks and built response systems, the more confidence you will have in your sense of preparation, and that is a good thing.

Building incident response programs can seem challenging because there are a million different things that can go wrong and even more ways to respond. The purpose of this piece is to provide some thoughts on building a program that is both efficient and effective.

Understanding Incident Types 

Before moving on to response measures, it is worth thinking about the types of events that we encounter.  There are almost an infinite number of event types, but in reality they tend to fall into one of four buckets. While there is little value in “classifying” an event (which I don’t advocate), through our at least understanding the nature of different types of events we may gain insight into determining the stakeholders and responders. The following four categories may be helpful when thinking through events and their response structures:

• Minor Errors and Incidents – These are small incidents that are generally handled at a departmental level and rarely require the involvement of other departments or outside authorities.  Typically, senior management is not informed of these types of incidents unless they escalate to something larger or are repeated enough to possibly represent a deeper issue.
• Information Technology Events – These incidents involve a discrete piece of technology, typically under the company’s control.  Depending on the scope and impact of the event, these issues may be communicated to staff or management, but most often are managed by the Information Technology Department (IT) without a great deal of other departmental involvement.
• Major Errors and Data Incidents – These would include errors or incidents impacting more than a few customers, that require a cross-disciplinary response (multiple departments typically involved) or any incident involving an unauthorized exposure of confidential information, intentional or otherwise.
• Catastrophic Events (Disasters) – These are large scale events typically beyond the company’s control, such as catastrophic weather events or facility failures.  Disaster scenarios involve departmental business continuity plans and typically involve relocating to alternate facilities or invoking alternate operating procedures. 

The following table describes these categories further, including some examples and related information.

By describing these four buckets we can observe something important. Bucket one represents local events that are generally addressed at a departmental level. Bucket four is the really big stuff, which involves disaster plans, often all hands involvement and some form of crisis management. So when we say “Incident Response Program,” for the most part what we are really referring to are buckets two and three.  These are the types of events that have a moderate level impact, affect more than a few people and need to be addressed promptly so that they don’t become bigger events and require a coordinated effort to resolve. But every event is not the same, and even within these two categories lie a myriad of events that need to be considered. It is worth noting that bucket two and three could actually be combined into one, but since IT incidents are so clearly defined by their type and response process, there is value in considering them independently of other events.

Building an Effective Process 

In developing an Incident Response Program (IRP), the following are some techniques that may be helpful to consider. The key is in planning, preparation, communication and training.

• Designated Incident Response Coordinators – One of the most important factors in a controlled response to any type of incident is to understand who’s in charge. Without a pre-determined coordinator, there can be confusion, duplication of efforts, delays in decision making and even escalation of the event. This is particularly critical for data incidents and major errors where time may be of the essence. A primary and secondary incident response coordinator should be designated and communicated throughout the organization so that people know who to contact if something goes wrong. And while it is possible to have multiple coordinators depending on the type of incident, this strategy should be used with extreme caution, as there may be confusion as who to contact. It is generally better to initially have one point of contact and then have procedures for determining who else should be involved based on the incident itself. There can even be a hand-off of control once a response is underway, but a single point of initial contact is generally best.
• Document Stakeholders and Responders – Depending on the type of incident, there is typically a specific group of people that either need to be notified or engaged as part of the resolution process. They should be identified ahead of time so that when an event happens notifications can be quickly made. This ensures that the right people are engaged or informed as appropriate.
• Develop a Response Process – Have a documented response process that includes templates for assessing an incident, a management report of errors and incidents under management, a post-event analysis form describing final impact, lessons learned and any planned business process improvements.
• Communication and Training – Having a process is good, but if nobody knows what it is the process isn’t worth much. The inclusion of training and education serves two critical purposes: 1) it makes people aware of the process, and therefore better prepared to execute it, and 2) it helps to identify any weaknesses in the process prior to putting it into practice. The important thing to understand about these types of incidents is, unlike major disasters, they will happen so you need to be prepared.
• Document, Document, Document – Memories are incredibly short, and it’s amazing how many details become fuzzy by the next morning’s coffee. Document root causes, impact analysis, response decisions and action steps, etc. This information is not only beneficial should you need to revisit the incident months or years later, but if included as part of a knowledge base, it can be referenced in the event a similar event happens again (which it probably will).

Asking the Right Questions 

When triaging incidents, it is important to identify the scope and severity as quickly as possible so that the appropriate response procedures can be implemented. The following are some good questions to consider as part of the assessment process:

• Is the incident still in process? (e.g., a system breach that may still be active.) If so, focus on stopping the incident before thinking about recovery.
• Is the event confirmed or suspected? Do not act on hearsay; get confirmation before taking next steps.
• Has or will the event impact the customer experience? Understanding how customers are, or could be, affected will be key in determining appropriate response steps.
• How many customers are impacted? An incident impacting 5 customers will look very different than one affecting 5,000 or 50,000.
• Did the event involve a compromise to confidential information (corporate or customer)?  Whether inadvertent or intentional, any exposure of customer information needs to be acted on immediately, not in days or weeks.
• Did the event involve physical injury or possible injury? An incident which threatens people involves a very different process than one involving just money or inconvenience.
• Who is aware of the incident? Part of risk mitigation is in controlling how information is disseminated and when. This goes both ways, in controlling who is deliberately informed and who is deliberately not informed. For instance, who will be responsible for press relations or contacting regulators, when appropriate?
• Is the source internal or external? This may influence how broadly the incident is communicated, particularly if one or more insiders are involved. In that case, you may want time to complete forensic investigations before taking visible actions.

These questions are focused specifically on event scoping. Once you move to root cause analysis, you begin a much broader set of questions about what went wrong, why and what should be done in the future. For now, focus on what is bleeding and how do you stop it.

The critical factors in building an incident response program are in planning ahead for a range of likely events, establishing clear authority, making reasonable provisions for response and facilitating lots of training. The fact is that every dime spent planning and preparing will be more than compensated in reduced cost of the response. Bad things will happen, but your ability to respond does not have to be one of them. Remember, knowledge is power.

For more information about building effective incident response programs as part of your overall risk management strategy, contact Eric Holmquist at Accume Partners at (856) 793-1581 or eholmquist@accumepartners.com or Glenn Hoffman at (203) 803-7345 or ghoffman@accumepartners.com. Visit accumepartners.com

Second, I wanted to let everyone know about a major new chapter that began this week. After several years managing my own risk advisory practice I have enthusiastically accepted the position of Managing Director of Enterprise Risk Management with Accume Partners, a highly respected advisory firm in risk, internal audit and compliance.  Over the last several years I have been approached by a variety of firms interested in having me manage some or all of their risk advisory practice.  While many of these opportunities were intriguing, some with colleagues I deeply respect, none seemed like an exact fit for what I would be looking for. But after several meetings with the CEO of Accume, Mark Lindig, I was so overwhelmingly impressed with his vision, values and strategic plan that I found it an easy decision to accept this position.

I started with the company this past week and am still in the process of getting acclimated. The demand for risk management thought leadership is incredibly high right now and Accume is positioned very well to be the industry leader in best practices. I am extremely excited to bring my skills and expertise to amend the tremendous talent already at Accume and look forward to being able to serve clients with an even broader range of resources.

Please know that new blog posts will be coming shortly and will continue on both ERM Advantage and OpRisk Advantage.  There is still much to be discovered in the field of risk management, and I look forward to continuing to bring insight and inspiration to fellow practitioners in this thing we call risk management.

For more information on Accume Partners click here.

“In preparing for battle I have always found that plans

are useless, but planning is indispensable.”

– Dwight D. Eisenhower

If there is one area of management where I am consistently disappointed it is in the areas of strategic technology planning.  In fact, in over 15 years of advising clients I have only seen a small handful that actually served as viable plans.  When they exist at all, most are short abstracts listing out several planned IT initiatives, sometimes with rough budget estimates, with perhaps a passing reference to the corporate strategic plan, little or no impact analysis and rarely with any degree of detail. But the fact is that a change in technology can have a profound effect not only on corporate capabilities, but on an organization’s operational risk profile as well.  Conversely, a well designed plan not only helps identify and mitigate potential risks, but it provides a blueprint for business improvement and efficient use of resources.

We have to remember, while technology is key to supporting the business, it is not, in and of itself, strategic. It never has been and never will be.  Technology is about capacity – it supports the fulfillment of the strategic objectives and nothing more. It is a tool to be used, but used incorrectly can do just as much to harm to the business as good.  Additionally, technology cannot just bring capacity, it must bring value, because any technology that does not directly support a business process will inhibit one.

The planning process is critical because we need to understand how the technology helps the business as well as how it relates to all of the other technological components. To add in a new piece of technology without fully understanding its purpose or context is like taking an excellent recipe and arbitrarily adding one ingredient. That ingredient may be delicious by itself, but adding it may reduce the whole dish to something inedible.  Doing so may have even created more servings (increased capacity) but destroyed it in the process.

The Plan Structure

There are 4 elements that should be included within every strategic technology plan (STP.) These are:

1. Restating the business objectives – A summary restatement of the overall corporate strategic objectives. This ensures that the STP both complements and is consistent with the larger plan and that all proposed technology can be tied back to a strategic initiative.  (e.g., Targeted email campaigns to specific demographics based on customer preferences and research data.)
2. Restate the functions needed to perform the business objectives – A description of the business functions that are needed to achieve the overall strategic objectives. This should describe the means by which the business objectives will be achieved.  (e.g., A data gathering and analytic function, a marketing development function, an email distribution function, a customer service function, etc.)
3. Define the technology required to perform those functions – An outline of the incremental technology that is required to fully support the functions described above. (e.g., new website front-end, updated back-end CRM database software, new analytic tools, etc.)
4. Define the corporate technology model – While this component is optional, a good technology model provides a type of quasi-mission statement for the organization’s use of technology. It can be used to outline things such as the corporate technology standards (database standards, desktop standards, server types, etc.), technology risk tolerance (bleeding edge, leading edge or proven technology only), risk frameworks, etc. The STP is an excellent place to document the organizational model for technology usage.

Once a decision has been made to implement a given type of technology, there are three areas that must be addressed when considering exactly which technology to purchase and implement.

• What will the technology do for us?
  • What is the benefit that is anticipated?
  • How will it impact the customer experience?
  • Will it save money, increase capacity or both?
  • How will success be defined?
  • Does it truly provide functionality that isn’t in place today?

• What will it costs us?
  • What is the known out-of-pocket cost?
  • What is the implied implementation cost? (This is always understated.)
  • What is the business disruption cost?
  • What are the training and support costs?
  • Is there cost to upgrade other existing technology to be integrated?

• What is the risk?
  • What could go wrong in the implementation?
  • What could go wrong once the technology is implemented?
  • Is there a point of no return within the implementation process?
  • How does this technology integrate with existing or other planned technology?
  • Does the technology create instances of confidential data?
  • Can it provide the capacity that is needed?
  • Is the technology scalable to support growth?
  • Do you have the technical expertise to support it?
  • Where is the technology in its obsolescence lifecycle?
  • How reputable is the vendor?
  • How is the technology rated in the industry?

Most of the points above are fairly intuitive aren’t that difficult to address.  And yet so many plans miss these basic elements.

Finally, the following are some additional thoughts to consider when developing a STP.

• Once a business area has grown attached to the idea of a give piece of technology, they will focus on the benefit. This means that they will emphasize the benefit, are willing to tolerate the cost numbers and often unwilling to discuss the risk analysis. This is human nature. Once we have decided we want something, we will go to great lengths to rationalize why it makes sense. It is the risk manager’s job to make sure that the business understands, and accepts the risk with open eyes.
• For any given technology proposal, there must be a meeting of the minds of both the business area and IT in terms of evaluating the benefit, cost and risk.  This is because the business knows most intimately the business processes (and technology’s impact) and IT knows most intimately the inherent risks involved.  Any assessment done without both sides working together and agreeing on the results will never be completely accurate.
• The details attached to a cost/benefit/risk analysis may be substantial. It is, therefore, not uncommon to have a master STP that outlines the business objectives and related technologies in summary form (for a wide audience) and then have individual IT initiatives covered in more detail within more detailed plans (which could possibly involve a smaller audience.)  This keeps the overall STP from becoming hundreds or even thousands of pages.  As long as senior management has access to the basic benefit, cost and risk data for any proposed initiative.  This strategy involves providing the high-level strategic plan first followed by the more detailed analysis for each initiative.
• All proposed technology must connect back to a strategic initiative and must have a risk assessment. Remove either of these and you’re asking for trouble.

The key thing to remember here is that the real value is not the plan, it is in the planning.  It is the process that forces people to face their assumptions and analyze the real risks in the harsh light of day.

The OpRisk Advantage: Ensuring a deliberate process for asking hard questions about the benefit, cost and risk of any given piece of technology will force the organization into making more informed strategic decisions.  This translates into reduced costs due to failed initiatives, improved customer experience, more engaged staff and significantly higher returns on the technology spend.

For more information about developing world-class strategic technology plans contact Eric Holmquist at Accume Partners at (856) 793-1581 or eholmquist@accumepartners.com. Visit accumepartners.com

Note that this test is different than the Information Security Acid Test, which focuses specifically on the risk of exposure of confidential data, in any form or location. Rather, this test focuses on the business impact of potential technology failures.

In this test there are five program and governance areas described below. Score your organization based on the scale provided, then add up your total score and compare with the analysis at the end of the test.

Governance

The company has an information technology management program built on a sound governance structure including strategic planning, effective communication and proactive management tools.

• A comprehensive strategic technology plan and budget that articulates the technology that will be required to support the company’s strategic objectives.
• Some form of IT Steering Committee with representation from executive management that is charged with the oversight of the strategic IT plan, budget and implementation.
• Strong, collaborative communication between IT and key business areas to ensure that business needs are clearly understood and supported by the right technology solutions.
• Clear policies are established that define both acceptable use and risk mitigation. These policies are communicated and accessible to staff and are matched with suitable internal controls.
• Technology standards have been established to ensure consistent use of technology, compatibility of new technology with existing systems and that no technology will be acquired which cannot be adequately supported.

How would you rate your IT governance?

Management Program

A well developed and documented information technology management program exists that includes:

• Qualified IT management and staff capable of assisting in developing IT strategy, supporting the existing IT infrastructure and leading the process of change management.
• Company staff are provided periodic training in technology standards, acceptable use of company-issued technology and procedures for problem resolution.
• Proactively managing the technology infrastructure so that critical components are not allowed to function beyond their point of obsolescence or reasonable lifespan.
• A formal change management process for both new and updated technology that includes cross-functional involvement, risk assessments, approval stages, acceptance criteria, proactive communication and contingency strategies.
• A management program for third parties that either provide or support key technology infrastructure.

How would you rate your IT management?

Risk Assessment

A comprehensive IT risk assessment structure exists which includes:

• An IT inventory and classification process, which catalogs the technology infrastructure (hardware and software) and includes a classification system for identifying both criticality and risk.
• A comprehensive risk assessment framework covering the business risks of technology failure, including potential threats (internal & external), vulnerabilities & mitigating controls.
• Broad risk awareness, including: Executive & Board level awareness of the overall IT risk profile and mitigation strategies, IT level awareness of business risks (the risk to the business of a technology failure) and business level awareness of technology risks (ways that the technology can possibly fail).
• An assessment of third parties providing or supporting key parts of the technology infrastructure.
• Occasional independent testing of the technology infrastructure, particularly the security and monitoring technologies.
  

How would you rate your IT risk assessment structure?

Monitoring & Protection

The organization has the ability to monitor and protect technology assets from potential threats, including:

• Real-time monitoring of technology-based systemic threats, such as computer malware (e.g., viruses, Trojans, key loggers), spam, cyber-attacks (e.g., denial of service), etc.
• State of the art technology and techniques are used to protect against live threats either with or without user interaction.
• Internal risks are actively monitored and managed, such as suspicious system activity, system degradation, email abuse, unauthorized wifi hotspots, etc.
• IT staff members stay informed of technology trends through ongoing training, involvement in trade associations and user groups, industry literature, technical conferences, etc.
• Mobile technology (laptops, PDAs, etc.) is safeguarded through systemic protections (device encryption, tracking technology, etc.) as well as user policies, procedures, training and an incident response process for when devices are lost.

How would you rate your IT Monitoring & Protection?

Incident Response

A process for responding to unexpected incidents involving technology solutions, including:

• A support center has been established in some form (whether internal or outsourced) to respond to user needs, where requests are captured, prioritized, addressed and resolved in a timely fashion.
• An incident response team has been established to respond to larger IT incidents quickly, with documented, test procedures.
• The business continuity/disaster recovery plan covers all key technology infrastructure with detailed recovery documentation, clear roles & responsibilities and periodic testing.
• Business areas have developed contingency or offline procedures for all technology-dependent processes in the event of a technology failure.
• A process has been developed for post-incident analysis to establish lessons-learned and to take appropriate action to reduce risk as necessary.

How would you rate your Incident Response process?

Summary of ratings:

Total the five scores and use the following to analyze the state of your third party risk management program.

41 – 50 Excellent – Your program has most or all of the key elements in place.  While there are always opportunities for improvement, based on this score you are likely addressing the majority of your information security risk.

31 – 40 Good – While some elements are obviously in place, there are definitely some areas that could be strengthened.  A more detailed analysis of the information security program should highlight where the weaknesses are and provide direction as to how to manage this risk more proactively.

21 – 30 Poor – There are some obvious weaknesses in the program that should be addressed as quickly as possible.  By strengthening the areas described above the institution should be able to reduce its information security risk significantly.

11 – 20 Critical – The program has severe structural challenges, and is allowing the institution to accept a material amount of information security risk. Most of the program is probably managed inconsistently, individually, or not at all. A detailed assessment should be completed as soon as possible and an action plan developed to strengthen all of the elements of information security risk management.

0 – 10 – Extremely Critical:  Simply put, there is no information security program. The institution is accepting a huge amount of risk, whether it realizes it or not. A score of less than 11 is consider extremely critical and means the institution is highly exposed to legal, financial, operational, reputation and regulatory risk related to information security.

The purpose of this analysis is not intended to be exact science or be an indication of compliance with legal or regulatory requirements. It is intended to provide a general barometer as to the health of the information technology management program. For a more detailed analysis, or for expert guidance in improving your IT governance, contact Eric Holmquist at Accume Partners at (856) 793-1581 or eholmquist@accumepartners.com. Visit accumepartners.com

I then show them the graphic to the right. I tell the participants that they must decide whether the color of square A is the same, or different, than the color of square B. (It is definitively one or the other.) I give them a minute to think about this. The longer I wait the more indecision sets in.  (Go ahead, you’re taking this test too. Decide for yourself.) Once they have had a minute to think about this I ask for a show of hands, first the group that thinks that they are the different, then the group that thinks they are the same. I then ask them whether they are willing to bet their paycheck on their decision. Most aren’t.

I then tell them that both squares are, in fact, exactly the same color.  “But, that’s impossible,” you say, “I can see the changing colors across the squares.” I’m very sorry, but you are wrong.

I know you don’t believe me, I’ve done this way too many times. Now you’re confused. Trust me, I don’t take it personally. Go ahead, right now, take a piece of paper, cut out two small holes, hold it up the monitor, see that I am right. Accept that your brain hurts. Yes, the universe is laughing at you. (And possibly your coworkers if they see you holding little pieces of paper up to your monitor.)

I do this exercise to make an important point. Sometimes we see exactly what we want to see, and that is not always the truth.  The fact is that different people perceive risk differently and this is highly problematic when we are trying to assess operational risk for the enterprise.  The way that we address this “perception” issue is by getting down to people’s assumptions, because that is the best way to give us a window into the basis of their perception.

There are a number of ways in which this issue tends to manifest itself. The following outlines some examples of where people’s assumptions will heavily color their perception of risk and then some strategies for getting these assumptions out in the open so that they can be discussed.

• The risk associated with a given process
  • Problem: Generally speaking, the closer someone is to a process, the less that they tend to perceive the risk.  (And even if the reverse is true the same problem exists, a faulty perception just in the other direction.) They often know what can go wrong and they know how to adapt in those circumstances. In addition, the longer a process goes without a problem then the lower the risk is perceived.
  • Strategy: The first step is an honest evaluation about what can go wrong (level 1 assumptions). Sometimes this takes prompting from someone slightly removed from the process (but still familiar with it.) The second step is an honest assessment about the impact of those failures (level 2 assumptions.) Again, as a rule, process owners tend to underestimate the impact of a process failure.  Finally, an honest evaluation of the options available when things do go wrong (level 3 set of assumptions.) As a rule, process owners are almost always overly optimistic about their ability to recover from a failure.  By getting all of these assumptions out in the open and evaluating them with a group of people with different subject matter expertise, you can often neutralize the effect of dangerous assumptions about the degree of risk embedded in a given process.
    

• The risk associated with third parties
  • Problem: The logic for third parties tends to mirror very closely the issues related to a process. Relationship owners almost always underestimates the risk because they tend to focus more on the benefit of the relationship as well as the inconvenience associated with the prospect of having to change third parties.
  • Strategy: Follow the same logic as with process, understand the assumptions about what could go wrong, what would it mean and how would you recover.  Have those assumptions reviewed by a group of subject matter experts (e.g., legal, IT, compliance, BCP, risk management, etc.) Ultimately you need to come to a consensus on the risk associated with key third parties.

• The risk associated with technology
  • Problem: Experience has shown that the perception of the risk associated with any given technology will differ dramatically between IT and the business unit it supports. I have seen this again and again and again.  IT understands the technology but doesn’t always fully understand the business.  The business area fully understands the function, but doesn’t always understand what could go wrong with the technology that supports it (and what the recover path looks like.)
  • Strategy: It is critical that both IT and the business understand each other’s assumptions about how the technology supports the business, what is the likelihood and impact of a failure, what would be the recover path of a failure and (critically) whether that recovery strategy is realistic. Again, experience shows that IT tends to consistently over-estimate its ability to replace technology quickly and the business almost always under-estimates the impact of a failure.
    

• The risk associated with change management
  • Problem: As I have said many times, the seeds of risk are sewn in change.  Once someone sets their sights on some sort of change (e.g., new technology, a new process, new division, new product, etc.) the majority of their focus tends to be “What will this change get me?” They will also give some thought to “How much will this change cost me?” And finally, they may or may not ask the question, “What is the risk?” In truth, if they like the answers to the first two questions, they often aren’t all that motivated to explore the third.
  • Strategy: Simply put, you have to press them. “What are your assumptions?” Assumptions about anticipated functionality, cost, resource requirements (and availability), implementation, conversion, training, operational impact, legal or compliance impact, business disruption, scalability, capacity, integration, etc. For this reason it is critical that risk managers develop standardized templates for business managers to complete in order to help them in documenting their assumptions. Getting these on paper using a standardized process will allow their assumptions (and there are many) to be viewed in the harsh light of day by a range of constituents, hopefully with enough time to validate or challenge those assumptions and the related risks.

I have often said that the risk manager’s best friend is the phrase “What could go wrong?” It’s always the starting point for risk identification and management. The second most valuable question is quite possibly, “What are your assumptions?” Learn to love this question.  You simply can’t ask it enough, because every assumption that you unearth tells you a little bit more about someone’s perception of risk, and gives you the ability to be more honest and transparent about those risks.

OpRisk Advantage: Organizations that make it a deliberate part of their framework to identify people’s assumptions when it comes to assessing operational risk will always find that they have more efficient internal controls as well as fewer surprises. This makes for a stronger organization, more confidence in the risk management program and reduced operating costs.

To learn more about developing world class risk assessment frameworks contact Eric Holmquist at Accume Partners at (856) 793-1581 or eholmquist@accumepartners.com. Visit accumepartners.com

What companies have also realized is that, left unchecked, social media can spell disaster in a heartbeat.  In order to manage the increasing risk of social media it is imperative that companies provide a clear, comprehensive social media policy to its employees spelling out exactly what is acceptable use, and the consequences for inappropriate use.  Having a clear, enforceable policy is critical because the fact is that you can’t criticize someone if you haven’t told them the rules.

The purpose of this article is outline what should be contained in a good social media policy and how best to implement one.

For the policy itself, there are basically three areas that need to be covered:

• Personal use of social media
• Professional use of social media
• Social media used on behalf of the company

The following outlines the primary components that should be included in a social media policy.

• Establish some basic definitions, including:
  • What is “social media”? Provide a definition that establishes social media as user-generated content published to Internet based networking sites, web pages, blogs, bulletin boards, etc.
  • Define one term to cover all electronic devices (computers, PDA’s, tablets, smart phones, etc.) such as “systems,” “technology,” etc.
  • Define what “confidential information” means, capturing things like customer data, employee information, intellectual property, etc.

• Outlining what the risks are, including thing like:
  • The Internal is viral with almost instantaneous replication
  • Once content is on the Internet, it’s there forever (there is no “undo”)
  • The Internet is public, there is no right of privacy even in supposedly “private” sites
  • Confidential customer or corporate information that is disclosed may create a liability for both the employee and the company
  • Posts may reflect negatively on both the company and the individual
  • Posts that reference the company may be considered “advertising,” which would make them subject to numerous laws and regulations
  • Posts may jeopardize certain intellectual property rights
  • Posts may provide information that could be used in social engineering attacks

• Provide guidance for personal use sites, such as Facebook, Twitter, etc.
  • Acknowledge that individuals have a right to use social media, however,
  • Personal use should always be done on personal time and never on bank-issued technology
  • Supervisors should be banned (or at least strongly discouraged) from “friending” subordinates, which can create a number of employee relations issues

• Provide guidance for business use sites (e.g., LinkedIn)
  • Establish whether access is allowed via company issue technology and whether business sites can be utilized during business hours

• Provide guidance for all social media cases (personal or business)
  • Divulging of proprietary or confidential information is strictly forbidden and is subject to both disciplinary action as well as possible criminal prosecution
  • Clear rules should be established for social media communication with customers (strongly discouraged if not outright banned)
  • If employees disclose on their site (personal or professional) that they are an employee, than that site is subject to review and any material deemed inappropriate may be asked to be removed
  • Employees will be held accountable for any statements made on a social media site with regard to the company, their job, their co-workers, management, customers, vendors, regulators, etc.
  • No employee may disable technology on their company-issued technology which is designed to block social media sites
  • No employee may use corporate brand images, logos or other copyrighted or proprietary content without explicit approval
  • Use of company issued technology is subject to monitoring and the employee has no right of privacy

• Provide guidance and oversight for employees intending to use social media on behalf of the company (e.g., blogging for the company, etc.)
  • The company must have a defined approval process, and only documented and approved employees may post to a social media site on behalf of the company
  • Approved staff should be provided with appropriate training and a written “usage” guide
  • The company must have some sort of monitoring process to oversee what is being posted on behalf of the company

• Establish that the above rules are applicable whether or not an employee discloses their identity on the social media site or posts anonymously and will remain in effect even after the individual has left the company

• The policy should provide the contact information for a person to contact internally with questions, concerns, etc.

• Employee acceptance should be established, either by a specific confirmation or with language in the policy stating that a condition of their employment requires compliance

Once a policy is completed it must be communicated clearly to employees and reiterated at least annually, if not more frequently.  Periodic reminders related to the social media policy throughout the year can also help to reinforce it. The policy should also be easily accessible on the company’s Intranet site or employee manual.

Finally, a question that frequently comes up is, who should own the policy? In fact, this particular policy has elements of human resources, corporate compliance, information security and acceptable use of technology.  Generally speaking, who actually owns the policy is probably less important than how well it is written and executed. Nevertheless, it has to be put somewhere. If the organization has a corporate risk group this would be the best place to put the policy. However, if the organization doesn’t, or doesn’t have the risk group own policies, than the next best spot would be under the Information Security Officer. The reality is that the social medial policy is mostly about protecting information flow anyway.

Developing the specific language for the policy will require the input of a number of different constituencies within the organization, but legal will probably provide a good bit of input. However, the corporate lawyers need to understand that this is not a terms and conditions document. It must be simple, straightforward and easily understood by all employees. It cannot be 20 pages of 6 point type if you want it to have any practical application with the staff. The related training document needs to be even more simplified, presented in straightforward language.

The OpRisk Advantage

By developing a clear, comprehensive policy, and ensuring that it is consistently enforced, organizations will go a long way towards avoiding costly, embarrassing and disruptive incidents caused by the malicious or unintentional acts of employees just trying to use social media to communicate with others.

For more information or assistance in developing a social media policy contact Eric Holmquist at Accume Partners at (856) 793-1581 or eholmquist@accumepartners.com. Visit accumepartners.com

All that is left is…(cue ominous music)…the risk people.

The “Risk Group” is a terrible, foreboding place where there is no oxygen and the landscape is littered with the corpses of great ideas. It is a soul-crushing anti-universe where only one word is ever uttered.

“No.”

Do you know this group? Are you this group? If so, you are probably missing opportunities and, more importantly, you are missing the real point of operational risk management.  One of the most dangerous things that you can ever do as a risk manager is become known as the “No” guy.  Because, sooner or later, people will try to figure out ways to maneuver around you.  You will ensure the old adage comes true, “Sometimes it’s better to ask forgiveness than to ask permission.”

Let’s face it, how many initiatives have gone forward because someone did a great job selling it internally to the key stakeholders in the middle of the night (figuratively) who signed off without really understanding the risks?  The fact is that someone understood the risks, but they kept it to themselves while secretly praying that everything went ok. This is not a healthy risk management structure.

When you think about it, the temptation to error on the side of “No” is actually fairly understandable.  For someone working around risk management, it doesn’t take very long at all to develop a pretty good instinct for risk. For many initiatives, once you hear the specifics you can almost immediately rattle of fifteen different ways that this brilliant plan can go sideways.  You simply learn what “risky” looks like and it becomes all too easy to just error on the side of “No.”

But the fact is, ORM is not really about “No.” It’s about “Yes, if…”  Some of those “if’s” may include:

• The proposal is consistent with the company’s strategic vision and plan
• Funding is available
• It doesn’t violate known laws or regulations
• A comprehensive analysis of the real risks involved has been done
• A determination has been made as to whether those risks fall outside of acceptable tolerance
• Additional controls necessary to mitigate some of that risk can be implemented, and finally
• Management is willing to accept the residual risk profile, with open wide eyes

It’s important to understand that, in this sense, operational risk is a bit unusual. Within the other risk disciplines, (credit, market, etc.), once policy has been set there really are a very limited number of things that people can do. The policies establish pretty closely what is acceptable and new initiatives are really not that common. For the few that do come down, the risks are fairly easy to quantify and it doesn’t take a lot of analysis to determine whether a given course of action falls within acceptable tolerance. But operational risk is a bit different. We establish an approximate risk tolerance (since there is no absolute value in ORM) and then within that there are literally millions of possible actions that may or may not be allowed take place. And, believe me, people will try and try and try.

Now the fact that the discipline has matured to where many organizations even have people dedicated to analyzing operational risk is very good. We need people like that.  But what we need is these individuals serving as subject matter experts and guides in the analysis process, not the “risk police.” And while it is true that understanding and assessing operational risk should become more intuitive over time, we can’t make decisions just on that intuition.  When we do, we are basing our decisions on our own risk tolerance instead of the corporate tolerance. In effect, we’d be making it up as we go along. Risk management is always about consensus.

Therefore, in order to build a healthy, collaborative relationship between business owners and risk managers, keep the following points in mind.

• Both tone and oversight from executive management are critical here.  If executive management even implies that risk analysis is optional (or can be done later), then you’ve already failed.  In addition, if management determines that risk managers only seem to know one word (“no”) then they need to step in and redefine roles and responsibilities.
• Once a business owner gets an idea there’s something funny that happens that can make them temporarily blind to the risks. This is normal – part of what makes us human is our ability to rationalize. It usually takes an independent set of eyes to tell us what might go wrong. This is not a burden, it’s a balance. People can only manage the risks that they understand, so awareness is a good thing.
• Honesty and transparency are the most critical aspects of effective risk management. Anything that impacts people’s willingness to be open and accountable will only weaken the program.
• A risk manager’s real value is not in being the big bad parent with a quick “no” trigger finger. His real value is in his ability to help diagnose the potential risk and in thinking through what options are available to reduce that risk to within an acceptable tolerance level.
• Risk managers should do everything they can to be seen as partners in the process.  Trust me, you can lose your seat at the table much faster than you realize and getting it back is really, really hard.
• A template should be developed that business areas can use to facilitate the assessment process.  Even if the template only captures 80% of the risk profile, the rest can be fine-tuned throughout the proposal process. But if the business feels like they have to re-invent the wheel every time they have a new proposal, they will eventually grow tired of the process.
• When evaluating individuals for risk manager positions, never overvalue quantitative ability over interpersonal and communication skills. The fact is the latter is much more important.
• Risk assessments must be done before any proposal is made to management. This is non-negotiable.  Proposals to management should always include: benefit, cost and risk. To only present one side of the equation, even in a straw man, is a very poor management technique.
• To the initiative proposer, you need to realize that just because you think that your initiative will make the company rich or famous or better or stronger does not mean that it does not have risk and you don’t get to bet the company. You need to be willing to accept the reality of the risk just as openly and honestly as you do the potential benefit. Your risk managers are trying to help you do that. Don’t hate them (or worse, avoid them) for it. Instead, use them as a resource.
• Finally, (and this point is absolutely critical), in order to fully assess the risk profile of a proposed change you must have established a meaningful measure of risk tolerance. If you haven’t developed a framework that is sufficient to be able to articulate operational risk in terms of tolerance, than you haven’t developed a risk framework. This may be tough to hear, but you need to hear it.

We have to remember that risk management is about risk acceptance, not risk avoidance. But in order to accept a risk you have to understand it and that requires some teamwork and cooperation.  Once you understand the risk, then you can make informed decisions about risk avoidance, transfer or acceptance.  As we often say, we’re trying to use these tools to create guardrails, not speed bumps.  Once you know the risks, build the right controls and consciously accept the remaining risk, then you are free to move, and move quickly.

The OpRisk Advantage: By building healthy collaborative relationships between business owners and risk managers, organizations can bring products and services to market quicker with more confidence and acceptance of the possible outcomes.  This translates to business resiliency, management confidence and better risk transparency.

For more information about developing an effective risk management program contact Eric Holmquist at Accume Partners at (856) 793-1581 or eholmquist@accumepartners.com. Visit accumepartners.com

I’ve always felt that the nation’s capital provides an intriguing backdrop for a risk conference. As I stood there viewing the Declaration and in awe of its significance, a question occurred to me.  If I were to sit down with one of the signers and ask them simply “What does risk management mean to you?” what would they say?

Here are a group of men that just did something that could very well mean their deaths.  The best case scenario was that they were probably going to war. What possible part of this decision could have been about managing risk?  These were smart men – prominent landowners with successful businesses and material wealth. I’m sure that in managing their own business interests they knew all too well how to make sound decisions taking both opportunity and risk into consideration.

So what was different about this decision? Did they skip the whole risk assessment part, just getting caught up in the moment? Did they assess the risk but ultimately say “Aw, hang it, we’re just going to do it. Give me that quill.”? I don’t think so. I think they knew the risk. I think they knew it intimately. I think that they accepted the risk because what they knew all too well was that the risk of inaction was far greater than the risk of action.

I think as risk managers we sometimes lose sight of this. Yes, it is highly unlikely that any of us will be forced into making life-or-death decisions, but the analysis is still the same.  What is the risk if we do it? What is the risk if we don’t?

This aspect of risk analysis is very difficult and often under-represented. First off, outside of scenario analysis it is impossible to model because a non-event does not create any data. There are no results to analyze – all you can do is speculate.  This technique is about real-world, day-to-day practical risk management.

What are some examples of non-actions that can create risk?

• Delaying a critical system upgrade in order to “squeeze” a little more time out of the existing system or to delay a complicated conversion
• Allowing a system implementation to continue despite a growing awareness that it will be highly unlikely to be successful or meet the intended business objective, just because you’re “almost there”
• Turning a blind eye to an executive that is abusive to his staff or clearly has a drinking or substance abuse problem just because he has been at the company for a long time and for the most part does his job effectively
• Unwillingness or inability to proactively re-assess credit or liquidity policies despite eroding market conditions
• Failing to adequately test key processes, key models, key vendors, etc. even though you suspect there may be problems

These are all areas where an honest assessment of the risks involved would probably indicate that the risk of taking action would in all likelihood be far less than the risk of inaction.  This certainly doesn’t mean that there are scenarios where you literally decide to “bet the bank” despite the risk. But, then again, couldn’t it be argued that our current financial crises was caused, in part, by an industry unwilling to take action in ceasing liberal lending and securitization activity despite the knowedge that the leverage levels were unsustainable?

There are several specific places where these types of analyses need to take place, generally centering on different decision points, such as:

• Strategic Planning – When considering possible new business lines, product offerings, acquisitions or any other changes in strategic direction
• The Competitive Landscape – The fact is, sometimes you do need to keep up with the Joneses
• Regulatory Compliance – In deciding how, and when, to take action in response to new or changing regulatory requirements
• Change Management – Whenever change is being considered, either to systems, people, process, vendors, etc.
• Risk Indicators – When evaluating key risk indicators. Just because it’s “yellow” (or even red) doesn’t mean you have to do something, but it does mean you need to make a decision
• Process Improvement – In the end, the phrase “not broken enough to be fixed” is an incredibly bad management technique
• Other Warning Signs – How you respond to employee complaints, customer complaints, media reports, social media buzz (good or bad), and even the feeling you get just walking the hallways and listening to people talk

During this same trip I also visited the Air and Space Museum by Dulles Airport.  After visiting the control tower exhibit and talking with an actual air traffic controller, I found myself profoundly grateful that risk management to most of us doesn’t involve the potential for loss of life. I don’t need that kind of pressure.   But make no mistake, managing the risk associated with the decisions that we make every day involves more than just the classic “What could go wrong?”  It means, “What could happen if we do, and what could happen if we don’t?” That’s good risk management.

The OpRiskAdvantage: By approximating risk both in the context of a positive decision (what could happen if you make the change) as well as a negative decision (what could happen if you don’t make the change) the organization is seeing a much clearer and more complete picture of the true risk profile. Ironically, by identifying risks associated with inaction, this can actually become part of the project rationalization (in and of itself a risk mitigant.) This is a more mature approach to operational risk than only considering one alternative.

For more information about building an effective risk management program contact Eric Holmquist at Accume Partners at (856) 793-1581 or eholmquist@accumepartners.com. Visit accumepartners.com

In this test there are five program and governance areas described below. Score your organization based on the scale provided, then add up your total score and compare with the analysis at the end of the test.

Governance

An ORM program built on a sound governance structure which includes management awareness and support, clear policies and procedures, defined roles and responsibilities and a risk aware culture.

• The ORM program includes a Board level policy (or is at least incorporated into a Board-level risk management policy) to establish this area as a business priority
• The ORM program involves Board and senior management awareness and involvement, including the ability for the Board to express tolerance for operational risk losses
• The organization has at least one person designated with specific responsibility for the design and implementation of the enterprise wide ORM program and framework
• The organization has staff members in each business and operating unit specifically responsible for operational risk assessment and self-assessments
• The organization has a culture of transparency and accountability around identifying and managing operational risks and controls

How would you rate your ORM governance?

Program

An effective ORM program utilizes a number of proven tools to identify and manage risk.

• The organization has developed and communicated an ORM framework based on industry best practices
• Major processes have been documented in process maps (both departmental & end-to-end) which are used to assess risk, define assumptions and identify process dependencies
• The ORM framework includes 1) a risk assessment methodology which allows (and requires) business and operating units to identify risk, and 2) self-assessments to periodically re-assess risks and controls
• Stakeholders in the various risk disciplines (credit, market, op risk, etc.) work closely together to ensure that boundary issues between different risk types are managed
• Comprehensive staff training is conducted with regard to the ORM program and its objectives, including both risk awareness and the purpose of internal controls (risk alignment, not elimination)

How would you rate your ORM program structure?

Risk Assessment*

A risk assessment framework uses a range of tools and techniques to identify and assess risk.

• Business and operating units take risk assessments seriously and objectively consider the risks to their processes given a range of event scenarios
• The risk assessment thought process is woven into everyday processes, not a periodic exercise
• Business and operating units approach self-assessments transparently and honestly, evaluating the strength of their internal controls and residual risk profiles
• Scenario analysis exercises are coordinated and conducted to assist business and operating units in evaluating their risk assessments and internal controls
• An ORM risk profile is established for the enterprise using a combination of data from risk assessments and self-assessments, and may include other data inputs such as scenario analysis and/or historical loss data (internal, external or both)
  

How would you rate your ORM risk assessment structure?

Change Management

Since the seeds of risk are sewn in change, ORM is the tool used to capture that risk.

• Change is communicated openly and transparently, with minimal “surprises”
• Risk is considered starting at the point of strategy, not at execution (or worse, in production)
• When considering change, (e.g., systems, people, products, business lines, facilities, etc.), multiple disciplines and stakeholders are engaged (e.g., operations, customer service, legal, compliance, IT, HR, information security, marketing, etc.) to gain different impact perspectives
• Prior to major changes, related internal controls are re-evaluated to see if adjustments are needed to manage the related risks, and adjustments are made as appropriate
• Unexpected events (especially operational failures) always include a post-event analysis which identifies lessons learned and a re-evaluation of the related risk assessments and internal controls

How would you rate your change management process?

Monitoring & Reporting

Risk is forever in motion, so the ability to monitor and report on operational risk elements is critical to success.

• Major control failures are tracked and reported to an operational risk committee (or equivalent)
• Key risks are linked to key risk indicators which are monitored to indicate if a metric falls outside of tolerance levels, and deviations are assessed in a timely basis
• Results of “lessons learned” exercises are shared openly and transparently in order to improve operations and reduce risk wherever possible
• Overall ORM program information is reported routinely to a central risk committee comprised of senior and executive management
• ORM reports include an enterprise risk profile, operational risk heat map (where the highest risks exist within the organization), risk trends and an analysis of major risk events

How would you rate your monitoring & reporting?

*Note that the test does not include a provision for capital estimation based on operational risk assessments. This is due to the fact that in the United States a very small percentage of institutions include this as part of their standard operational risk management programs, therefore, this cannot be considered a best practice. Banks that are required, or have opted in for Basel compliance, should add this as a bullet into their analysis.

Summary of ratings:

Total the five scores and use the following to analyze the state of your third party risk management program.

41 – 50 Excellent – Your program has most or all of the key elements in place.  While there are always opportunities for improvement, based on this score you are likely addressing the majority of your operational risk.

31 – 40 Good – While some elements are obviously in place, there are definitely some areas that could be strengthened.  A more detailed analysis of the operational risk program should highlight where the weaknesses are and provide direction as to how to manage this risk more proactively.

21 – 30 Poor – There are some obvious weaknesses in the program that should be addressed as quickly as possible.  By strengthening the areas described above the institution should be able to reduce its operational risk significantly.

11 – 20 Critical – The program has severe structural challenges, and is allowing the institution to accept a material amount of operational risk. Most of the program is probably managed inconsistently, individually, or not at all. A detailed assessment should be completed as soon as possible and an action plan developed to strengthen all of the elements of operational risk management.

0 – 10 – Extremely Critical:  Simply put, there is no operational risk management program. The institution is accepting a huge amount of risk, whether it realizes it or not. A score of less than 11 is consider extremely critical and means the institution is highly exposed to legal, financial, operational, reputation and regulatory risk.

The purpose of this analysis is not intended to be exact science or be an indication of compliance with legal or regulatory requirements. It is intended to provide a general barometer as to the health of the operational risk management program. For a more detailed analysis, or for expert guidance in developing or improving an ORM program, contact Eric Holmquist at Accume Partners at (856) 793-1581 or eholmquist@accumepartners.com. Visit accumepartners.com

Additional Resources

Basel Committee – Sound Practices for the Management and Supervision of Operational Risk

The Risk Management Association – Operational Risk Resources

Incisive Media – Operational Risk & Regulation

If we look at life on this planet, one of the things that is truly fascinating, miraculous even, is nature’s remarkable ability to adapt.  Scientists continue to discover living organisms existing under conditions so extreme that they were once thought impossible to support life.  Humanity has this ability too.  But in our contemporary, environmentally controlled, risk redacted, cubicle enclosed world of buttoned-down existence, we sometimes lose site of the truth of Heraclitus…that everything changes.

This simple, singular truth has profound implications on the world of operational risk management for one very important reason. The vast majority of all risk management tools exist as of a specific point in time, under a very specific set of circumstances. Risk assessments, loss events, risk profiles, risk tolerances, management reports – all exist as of a point in time that will never, ever exist again.  Awesome.

In order to build world class operational risk management systems we have to accept the fact that everything changes, and not always for the better.

• Staff members leave or change jobs, taking with them institutional knowledge, skill sets and relationships forged over time.  They possess knowledge that may be helpful or a threat in their new position (e.g., Jérôme Kerviel, Kweku Adoboli). New staff members take their place, ignorant, untrained, unskilled and uninitiated
• Competitive landscapes change – new competition emerges, old ones fade away, all changing the conditions under which your business competes
• New threats emerge every day – destructive weather, new and more elaborate fraud schemes, new security threats based on increasingly sophisticated technology
• Legal and regulatory changes are never ending, which impact and disrupt how you are allowed or required to conduct business
• Technology must be constantly upgraded and replaced in order to remain competitive

Some of these changes we invoke upon ourselves, some are thrust upon us. Some change is good, some is bad, some, well, it’s hard to tell. But the constant in all of this…is change.  Change can render risk assessments suspect at best, and at worst, irrelevant.  Change marginalizes historical loss data, all of which occurred under a specific set of circumstances which may, or may not, still exist.  Change alters risk profiles, possible taking them above or below tolerance levels. And, even worse, change can introduce whole new risks that were never considered, or provisioned.

But there is good news. If we as operational risk managers look down into our bag of tricks, we see several very important tools that are uniquely and specifically designed to mitigate the impact of this immutable uncertainty.

• First and foremost, a culture of transparency and communication – We have to be able to openly and honestly talk about changes that are happening and how we are prepared to respond to those changes. Willful ignorance to the effects of change is not just a poor management technique, it is downright negligent. Risk managers can be both advocates and liaisons in promoting healthy discussion around change management and incident response.
• Key Risk Indicators (KRIs) – Much maligned, frequently abused and heatedly distrusted, like it or not, KRI’s are a risk manager’s best friend when it come to managing the effects of change, and for one very important reason. KRI’s bring life to risk assessments. All risk assessments are built as of a specific point in time and based on a specific set of assumptions. A good KRI, mapped to a risk and tied to a specific “moving part,” can help the business in monitoring subtle changes that may represent an elevated risk. Just remember, KRI’s only tell you there is smoke, not that there is fire. That is the risk manager’s job to evaluate.
• Incident response teams – A pre-positioned, trained incident response team with carefully documented incident response procedures can be a huge mitigating factor when it comes to unexpected events. (This will be covered in greater detail in a subsequent article.)  The fact that so many organizations don’t have world-class IR teams is unfortunate. The operational risk manager should make it a priority to see that one exists.
• Risk assessments at the point of strategy – The fact is that the seeds of risk are sewn in strategy and if the first time that somebody asks “What is the risk?” is after you move to production, something went tragically wrong. The problem here is that we are all creatures seeking gratification.  Once someone becomes enamored with what their new system or process or vendor is going to get them, they become increasingly less willing to honestly ask what it could cost them (in terms of incremental risk.) This is where risk managers must do their job and help in asking the hard questions.
• Documentation – Remember, documentation makes an organization self-healing. One of best tools for resiliency is to reduce the impact of the loss of institutional knowledge when staff leave or change jobs. Guess what? You don’t have enough documentation, I guarantee it.  A key process that is not documented is a high risk, regardless of what the process owner says.
• World class change management processes – This means that all changes are communicated in the design phase, not implementation. This means that stakeholders are identified and engaged throughout the change process. This means that approval requirements are clearly documented and enforced. And finally, this means that all changes include a risk assessment which is agreed upon just prior to implementation, even in summary form, to show that someone thought through the impact of the proposed change and gave the stakeholders an opportunity to weigh in.
• Finally, learn from your mistakes – This was covered extensively in the recent piece The Most Valuable Information You Aren’t Using, which talks about learning from failure, embracing it even, and asking the hard questions about what happened, what did it mean, and what are we going to do about it. If you aren’t getting stronger due to your mistakes, you’re not managing risk (because you’re probably going to make the same mistakes again.) This is another spectacular area where risk managers can be brokers of learning.

What all of this means for management, and for risk managers, is you have to stop assuming that just because something worked yesterday that it’s going to work tomorrow. That the assumptions that you took to bed with you the night before may have no bearing on reality by the time you’ve finished your morning coffee. Accept that what was a good idea yesterday may be a really bad idea today. And realize that change can happen very fast, or very, very slowly. You have to have mechanisms in place that can both detect and respond to all types of change effectively and expediently.

Remember, change is not the enemy of effective risk management, but it is most certainly the antagonist.  Risk management cannot only be about assessing risk (or worse, just modeling it.)  Risk management is only a useful tool if it helps us deal with the changes we invoke and encounter on a day-to-day basis, creating a business that is both resilient and adaptable.

For more information on developing an effective risk management program contact Eric Holmquist at Accume Partners at (856) 793-1581 or eholmquist@accumepartners.com. Visit accumepartners.com