December brings more to our days than images of bright lights, holiday cheer, family gatherings, and for some, maybe a sprinkling of snow. In our work-realm of business and cyber risk management, it’s a time for reflection, refinement, and preparation for the year to come. Unless your business is retail or related, and you’re panting your way to the gift giving finish line, this is a great time to look back for a moment and answer some questions about your cyber risk management program, and your risk processes overall. For example:
- What has worked quite well in the past year?
- What has not, and why?
- What unique challenges do you anticipate for 2022?
- Are there processes that bear attention and refinements
- Are there gaps in what you do that should be addressed?
- Are you aligned to your firm’s business goals and strategy for 2022?
It can be useful to get some input from your stakeholders and key users. Their perceptions, insights, and priorities may offer other perspectives for you to consider. The information you provide to inform decisions and direct actions only realizes its full value if it’s readily available and comprehensible for them. Also include your support resources, in IT, staff education, contributing departments, and management. And if there’re gaps in the program from their perspectives, it’ll be made clear from their feedback. Just including your primary audiences in your review process incorporates them into shared program ownership, which is important of itself.
Features and Processes
Improving your GRC program’s usefulness requires consideration of both. Basically, what and how, and also when. Tailoring here is not so different than tailoring of good clothing (confession: I’m the grandson of a master tailor). You examine fit, identify areas that need alteration, determine what that adjustment needs to be, examine the resources available to employ, decide what you can do to create the best “fit” result, size and mark your adjustments, and execute from there. The first two steps are accomplished through review and feedback. Those help you identify which changes would refine your program to a more perfect “fit” for your business.
Next, consider what’s missing or imperfect. The content here generally falls into two categories, features and processes. For your GRC, features would likely include modules you might want to add, like third party risk management (TPRM), (or activate if you’ve not yet made use of them), or interfaces to other data, internal or external, extended security provisions, even changes to labels and language to reflect norms and culture within your firm. Processes may relate to risk assessment methods, workflows, communications, training practices, even alterations to authentication and permission granting.
Answer these simple questions: “what do we need to know that we cannot today?”, and “How can we get that information?”. Armed with those answers you can evaluate whether you need to adjust a configuration or setting in what you already use, need to integrate a data source that already exists somewhere else within your infrastructure, or in fact, you need to acquire something that will enable you to do what you cannot. This is not just a cost saving exercise. It’s also a design and maintenance management practice to keep your infrastructure as straightforward and contained as possible. Security plays a role here too. Internal data feeds are easier to validate, manage, and secure. Configuration management is a more straightforward approach too, helping to assure your software maintenance path remains relatively linear. Adding modules to your GRC is also a great way to extend functionality, when it’s represented through features designed for that specific purpose. Modules likely will open doors for opportunity to do more than you may need at this moment, but present greater flexibility and resources to continue to refine and extend your capabilities as they continue to evolve. They are also a “hedge” against any perceived desire to insert custom code into your platform as a way to get that information or perform a required process.
I’ve often spoken out against custom code unless your vendor commits to incorporating and supporting it in subsequent releases. (This is sometimes called an advanced feature by some). Many of the biggest maintenance and performance issues I’ve seen have their root cause in some piece of unsupported custom code interfering with a future product release. It’s something to avoid if at all possible. Instead, explore your available configuration settings and work with your vendor to seek a supportable solution. Also keep in mind that custom code is not always the same as customization. Many vendors offer you options (configuration capabilities) and allow you to create custom fields, and to rename existing fields to use language and conventions consistent within your own company’s and industry’s culture. All those changes are consistent with the “no custom code” approach mentioned above. Also, when you do change field names, look for functions that support global changes, so you maintain consistency across panels, modules, and processes. That will keep user training much easier and adoption more rapid.
Often times, for control or regulatory purposes, or just to further tailor a system to do things “your way,” how you get somewhere is of equal importance to arriving where you were headed. One obvious place to start is with workflow configurations. Have you identified any process bottlenecks from your risk assessments, vendor assessments or onboarding processes (if you have some TPRM functions incorporated within your platform), or compliance management? If so this is the time of year to review feedback from participants and stakeholders, to address those concerns by making adjustment to step sequence, escalation paths, timing, routing, and reporting. If you don’t have a dashboard or some other means for a risk program manager to identify workflow issues and intervene when needed, consider setting up something to make those situations easier to identify. In like manner, you could address any other process workflows in any other areas.
Consider the interfaces your program employs to incorporate data from other sources, i.e., suppliers and partners, regulatory and compliance reviews, internal and external audits, industry data stores (like Dun & Bradstreet), or any others you may use. Have you had any timeliness or interface issues? Is maintenance of these interfaces straightforward? Automated? Do you have clear escalation practices in place if there is a problem? Are these practices documented so backup staff can implement them if necessary? Add these to your review checklist too.
Some other processes to review and tune are end user training, risk assessment, TPRM onboarding, and subject matter expert (SME) reviews wherever they occur. Consider what seemed to be easily grasped by your GRC’s end users, and what required frequent post training support. Also, keep your training aligned with any adjustments made to your processes, features, interfaces, or security provisions. Alterations to user training may have positive impacts upon the performance and experience in those other processes. It’s a good time to examine your risk scoring methods to assure they are clear, make sense for your line of business, and provide a level of clarity and specificity useful to managing the risks under review.
Security is somehow often left behind in these review practices. It shouldn’t be. Your GRC holds a lot of potentially sensitive, and perhaps proprietary data—content you and your partners, clients, customers and stakeholders would not be pleased to openly share. So, are your authentication methods current? How are you segregating and assigning permissions? Do you employ a role based security model? Have you or are you integrating a single sign on (SSO) means of enabling access? How are you administering this? How do you terminate access when the situation merits? Are you using a hosted or cloud based solution? How are you ensuring security there is in line with your needs? Do your processes generate the audit trails and documentation you need to meet regulator’s requirements? Again, tailoring and tuning some of these processes as you look forward to 2022 will add efficiency and strength to your risk management program.
Some think there can never be too much reporting. I disagree. There is always room for specific targeted reporting that answers important business questions. The rest is just confusing and disruptive volume…noise. Needing or wanting to know “everything” just means you don’t know what’s important. If a report, dashboard, or other information device doesn’t answer this question, consider discontinuing it: “As a result of knowing this information I can and will now take ____ action.” If the report doesn’t answer a clear business question that leads to a decision to act or not in a specific manner, what value does it provide? Proof you could produce the report? So? I’ve seen many businesses buried in reporting while actionable information starved. Don’t become one of these. The practice wastes money, time, and drains valuable resources best applied to other aspects of your program.
Also, look over your access, publication, and distribution processes for the information reporting you create. Does everyone with current access need it? How difficult is it to access if entitled? Do you push reports out to people or post them securely and enable access? Are they produced in formats that support repurposing where and when it might be wanted? Can recipients create their own ad hoc queries? Or drill into or restrict the scope of distributed information?
Last, are the reports free of jargon, clear and easy to understand, and do they provide meaningful, actionable information within the context of your business? Have you asked your key audiences and stakeholders if they might want new, or additional information, in different forms, or in different frequencies? This is a good time to gather such input and plan for any adjustments in the coming year. Don’t hesitate to challenge requests with that key question. It helps avoid what’s referred to as “report creep”.
Alignment To Your Mission
Annual goals change, missions are less volatile. Was your risk program aligned with either? Both? How does the configuration and capability of your GRC contribute to your risk program’s support of your company’s mission and goals? One approach you may consider is to list your company’s mission and key goals for the coming year. Then list, based upon your 2021 efforts in cyber and IT risk management, the key risks you determine pose the greatest threats to accomplishing those goals and staying true to the mission. Look at the array. Are there areas where your program has identified risks that are not well addressed, do not have methods and resources to monitor, evaluate, prevent or remediate those threats, should they materialize? There are your “hot spots” for 2022! Would you need assets, features, processes or some combination of them to improve your program’s alignment? This kind of analysis positions requests for resources in the context of the business, bypassing the argument of “professional polishing” of a good program for its own sake. The value of your risk program is in its contribution to your business’ mission and success. This is a way to illustrate where you are, how you contribute (beyond the obvious “keep us safe”), where and why you want to refine the program from its current state.
There will always be new challenges, unexpected events, and situations that are completely outside your control you will need to respond to in useful ways. Nobody saw a pandemic coming. Nobody forecasted the “great resignation”, and by sometime very soon there will be additional events or situations to add to that list. Looking forward, assessing risk potential, monitoring the trends of malicious behavior by threat actors inside and outside your company is what cyber risk management is all about. But with careful planning, thoughtful maintenance and refinement of tools, processes and practices, and a critical look to emerging new methods such as AI based monitoring and assessment, digital twins, careful third party management, and automated detection tools, you will position your cyber and IT risk management programs to serve your company, its investors, client and customers well into tomorrow. With a little tailoring, your fit and performance will suit you well, and continue to mature and improve with age.
About the Author:
Simon Goldstein is an accomplished senior executive blending both technology and business expertise to formulate, impact, and achieve corporate strategies. A retired senior manager of Accenture’s IT Security and Risk Management practice, he has achieved results through the creation of customer value, business growth, and collaboration. An experienced change agent with primary experience in financial, technology, and retail industries, he’s led efforts to achieve ISO2700x certification and HIPAA compliance, as well as held credentials of CRISC, CISM, CISA.