- Corporate Security
- Governance, Risk and Compliance
- Information Security
Do you have visibility into all the incidents that take place across your organization? While you’re likely aware of the major incidents that cause business disruptions, the seemingly minor incidents could be leading indicators of something more severe, such as:
The challenge is getting all of these incidents captured in a timely manner so that they can be reviewed and managed by the security team. When your security team is already strapped for resources, how do you ensure that all incidents are reported?
This is where the value of an incident submission portal comes into play. By better engaging the business, you can capture incidents without putting more strain on your security resources. Even if you’re unable to address each and every submission, you’re still getting a full picture of all the incidents impacting the business and can prioritize and report on them accordingly.
There are 5 key considerations for launching an incident submission portal.
The first step is to clearly articulate who you are targeting with the portal and the types incidents that you are trying to collect. Is this going to be a tool for employees to report theft? For the public at a university or campus report suspicious behavior? The key in this is to start small. Don’t look to collect every incident from every audience.
In a perfect world, we would always know who was submitting an incident, but there are tradeoffs that need to be balanced as you choose whether or not your portal will be anonymous. A few things to consider:
If your goal is to see everything, then anonymous is the way to go. If you need to go back to people for more information, you should work to credential your users (this can be made straight-forward with employees through SSO connections.)
Once you decide on the type of portal that you are deploying, you can pick a technology that will get you there.
If you are using an Incident Management Software solution, there is more than likely a portal option. Particularly for portals that require credentials (non-anonymous) this will be the easiest and most cost-effective option. Vendor supplied portals also provide the benefit of being directly tied into your incident and investigative system.
Many organizations have an internal intranet that is used to communicate with employees and other stakeholders. Intranet administrators should be able to create a form for incident submission there. Once created, rollout is relatively straightforward if the audience is already using the portal. The major downside is the dependence on the intranet product owners (usually IT) to get the system up and running.
If neither of above is in place, a simple portal can be built on products like Google Sheets or Microsoft SharePoint. Portals should be simple, so it is likely that someone in-house has something that will work. The main drawback to these solutions is that they are disconnected, so added data entry and adoption can be tricky.
Technology is not the make or break for portals. We’ve seen all the above work perfectly well. What matters more is overall user adoption and rollout. There are several best practices that you can employ in your technology choice that will enable you to improve portal adoption.
You don’t want to have to overly train people how to use the portal. There is a natural trade off in technology between simplicity and depth of data. In this case, go for something simple. We recommend keeping the number of fields to around five.
If you can, it’s best to build something dynamic. If different types of incidents require different information, have your user select the type first and then have the form only display what is relevant to that specific type of incident. Asking people to skip irrelevant fields is a common cause of poor-quality data or low completion rates.
While you may be tracking 100 incident categories, you shouldn’t present that to your users. Give them a small list to select from. Or, just give them a text box to describe what happened and have the security team triage it on the admin side. Don’t expect a broad audience to know your nomenclature. If you want them to report a stolen laptop just ask the pertinent details (when, where, what etc.)
It takes more work to code an incident from free form text but if you want the best quality data, this is your best bet. To ensure that the users think of all the relevant details, try using simple language to ask the questions that you would ask if you were to receive a call about the incident:
Once the data is in the portal, your trained security professionals can better code the incidents to meet your reporting requirements.
A perfectly designed portal is rendered useless if no one knows that it’s there. Giving people a separate login to an incident specific portal is unlikely to work. It is best to use existing credentials via something like single sign-on and to have the links be available where people already do their work. A link in the intranet is often best practice. Incident reporting isn’t usually a regular part of a non-security person’s job, so making it available in a place that they can easily access will definitely improve adoption.
Beyond that, you will need to communicate where this is and why it’s important. You will need a good communication plan that includes various ways of telling the team where to find the form and why it’s critical for them to participate.
Getting this right will dramatically increase your situational awareness, but it’s also going to create more work. You will want to try to automate the triage and response process as much as possible. Perhaps, there are incidents that you just want to track and not respond to? You can automate a response to the sender for those types of incidents. Being prepared is important. If you ask people to report more frequently, but they feel that there is no impact because it hasn’t been addressed, they will feel disempowered and stop submitting.
In the long run seeing the full picture will save the business time and money even if it takes more time up front. Data is at the heart of the security profession. Having accurate and timely data drives the situational awareness needed to effectively respond to incidents and threats and provides the fuel for the analytics that help you deploy your resources (guards, cameras, policy etc.) to be the most effective. Portals are a great tool to ensure that you are getting the best quality data from your incidents.
Data is central to the security profession. Its role is to keep organizations safe and resilient. But, in order to do it well, security teams need access to timely and good quality data to ensure that they have the situational awareness required to do their jobs. Part of this is clearly defining how data will be captured, for example in a portal. But, getting the data is only step one. From there, security teams need to categorize and make sense of the data to turn it into actionable intelligence.
To help determine the best path to simplification, we asked members of Resolver’s Incident Management Implementation Team to provide their tips and tricks for getting the most out of security data.
It’s common that some security professionals spend more time cleaning up and correcting the data that was entered than they spend on any other aspect of their job. It’s safe to say report writing is usually the last thing anyone wants to do. In one implementation, Resolver customer’s front-line users had a lot of required fields to fill out, so when it came time to create the report, they did the bare minimum, so they quickly get it done and move on.
There is a high turnover rate in front-line users, and for the most part, security is not their primary function. As such, they are going to receive very little training on how to enter an incident. It’s often faster for users to take raw, but good, quality inputs from users and codify it themselves. To improve the quality of data, keep inputs to a minimum and use more simple language to ask questions about the who, what, where, when, and why, and to implement open narrative fields as much as possible.
Here are a few extra tips:
– Graeme Haggerty, Solution Consultant
This might seem simple, but it comes up often. Security teams capture data in one way, but then translate it into different categories when they report to management. Most often, this happens because the security team is trying to capture a much greater level of detail. While there may be good reasons for this, there is a tradeoff that the team should be aware of. When adding additional levels of granularity, be explicit about the value that this level of detail is going to provide and the anticipated business impact.
When thinking about the data to capture, start by thinking first of what the report will look like. If all 1,000 incidents aren’t going to be reported on (this isn’t a joke – this happens all the time!) then why put 1,000 incident categories into the system? If the data is going to be reported, why track it? Every bit of data entered into the system has a cost in effort and data quality. The more that is tracked and the more detail asked for, the more likely it is that users will make mistakes or skip sections all together.
– Melissa Davis, Solution Consultant
Ensure that alignment with the executive team on the specific definitions within the system. For example, tracking losses and recoveries can be very time consuming. It is extremely valuable data, but if the executive team does not agree with how losses are being measured, buy-in for business decisions will become much more challenging. Spending time to get aligned on what the numbers mean is very important and often overlooked.
– Dale Yushchyshyn, Solution Architect
Corporate security reporting is based on a combination of factors (incident type, severity, location, etc.) Often when we are migrating data from legacy systems we find that multiple factors have been jammed into a single field and that lookups and drop-down lists are overworked. This makes effective reporting nearly impossible.
This is common in legacy solutions because they are not very flexible and often needed to be worked around. Thankfully, this is no long the case for most modern systems. In newer solutions, users should be able to add fields and classifications to keep this separate.
Thinking about or currently implementing a new solution? We highly recommend taking some time to rethink the classification scheme (consultants can help!) to better map data to the desired reporting output.
-Jay Andrada, Solution Consultant
When it comes to security data one thing remains true, the cleaner the data, the more accurate the reporting. Without accurate reporting, security teams will struggle to make data-driven decisions that they are confident in.
Every year our team has a great time at GSX, but this year was extra special.
Last week, ASIS International hosted the 2019 GSX Conference in beautiful Chicago! GSX brings together security professionals from around the world for an amazing week of informative sessions, networking and insightful discussions. We had the pleasure of meeting thousands of people throughout the week at our booth. This year, we sent 29 Resolverites to Chicago so that we could network, speak to customers and potential prospects firsthand, and most importantly learn more about trends in the industry.
The experience on the conference floor was amazing. Every morning when the doors opened at 10:00 a.m. there was an obvious buzz in the air of people looking to learn more about the newest tools and services in the security industry. As busy attendees quickly moved around the show floor, the conversations started flowing.
At the Resolver booth specifically, people were drawn to learn more about what we meant by “Risk and Security Management Software” in the large banner at the front of our booth (accompanied by a smiling member of the Resolver team).
Whenever someone walked up and wanted to know more about who Resolver was and what we did, our team went into full swing. The simple version? Resolver enables security professionals to capture, manage and report on incidents. The reporting is where so much of the value comes in for security teams. We heard from countless people that although they understand that what they are doing every day is impacting the overall business, but they want a concrete, data-backed way to prove that. With Resolver, security teams are able to look at their incident data and measure success. Whether that’s reduced response time or identified areas of risk, without this data, they can’t make decisions that impact the bottom line.
Throughout the conference we were excited about the opportunity to really show off our security solution to attendees. Our security solution is made up of Incident and Investigations Management, Security Risk Management and Security Operations Management software. We got great feedback from current and prospective customers about how they are currently managing incidents and the benefits that they saw from implementing a solution like Resolver to not only automate but streamline their current processes. Several Resolverites (many that were actually present at GSX) are former security professionals and/or ASIS members – so much of what is built into our applications comes from the experience and best practices of actual security professionals.
And this showed. We heard from many of the people that we spoke to that Resolver really understood the inner workings of security teams and what mattered most to help them do their jobs better.
As a leader in security, it’s no wonder why thousands of people come to GSX to participate in the amazing sessions! A few of our Resolverites spent the week participating in the interactive sessions. Here are a few of their key takeaways:
GSX provides so many amazing opportunities to network and meet security professionals from around the world, and this year was no exception. ASIS does a great job of hosting fun events that bring the entire conference together to let loose, enjoy and meet new people. Our team especially enjoyed the 80’s night featuring Rick Springfield!
Perhaps the best part of GSX is getting to engage with our customers. We love hearing what you have to say about Resolver, and learn how you’re leveraging the solution to protect what matters most to your business. We left GSX on a high note. We’re inspired by the conversations we’ve had and can’t wait to show you what else we have in store.
Enterprise Risk Management has taken a foothold in today’s business environment. Since the enactment of the Sarbanes-Oxley Act of 2002 (SOX), public companies have taken steps to strengthen their internal controls over financial reporting and enhance their ability to comply with rules and regulations. For the past two decades, in response to numerous data breaches, accounting and corporate scandals—as well as increased enforcement of Foreign Corrupt Practices Act of 1977 (FCPA) violations by the U.S. Securities and Exchange Commission and Department of Justice—there has been an increase in corporate boards’ awareness and management’s focus on governance and risk management. Many organizations have turned to ERM as a solution.
Not only does an ERM program help minimize risks and reduce the impact and severity of negative events, it also allows companies to become more efficient, make better decisions based on data and create a risk culture. In fact, mature and successful ERM programs have been shown to reduce earnings volatility, strengthen capital position and increase profitability. But not all organizations are aware of what it takes to implement and operate a successful ERM program. Below, we identify what all effective ERM programs have in common, three ways to prove the value of ERM and how technology like Resolver’s enterprise risk management software plays a critical role in the success of an ERM program.
ERM programs that have proved successful typically have several things in common, including buy-in across all departments, resources and money allocated toward the cause, continuous improvement of the program, and measurement of the program’s success.
Sometimes, we see ERM programs initiated at the request of the board, at the request of the CEO, or as a result of something negative that has happened to the organization. Organizations need to have the support, engagement and buy-in from the C-suite and top managers for ERM to be a success. There should be an appointed champion at the executive level that will present ERM program data and performance to the board of directors or the financial risk committee.
In order for ERM to stick, it is all about answering the question “why” and then empowering people, providing them with the tools they need, and giving them the autonomy to own it themselves so it becomes part of the fabric of the business—not something that is imposed, but rather a part of how they get things done. With this approach, that explicit link with the strategy, goals and objectives of the organization may be missing. When something starts up, it is brand new, it is fresh, it is the latest thing on the agenda, so a lot of people jump on it. But after about a year or two, the interest begins to fade. So, getting company-wide buy-in from the start—and keeping all stakeholders engaged and accountable—is one of the most important aspects for a successful, long-term ERM program.
Most risk assessment activity takes place when the executive management team has the time to do it, and that is typically not in the midst of planning and budgeting. Unfortunately, in most organizations, the risk assessment takes place three months after the planning and budgeting is done, which is when teams have time. However, that is not the time you want to do it. Push for risk assessments to occur in the midst of developing upcoming plans and devising a budget. An ERM program cannot survive without allocated resources.
Those who assume the most ownership of an organization’s ERM program have the task of continuous innovation. They should always be thinking, “How can I do things differently?” An ERM program needs to remain fresh. Failing to update and innovate leads to an ineffective ERM program.
What doesn’t get measured, doesn’t get managed. Many organizations with strong, mature ERM programs in place say measurement is key. They try to quantify efforts and have leading indicators around risk and performance to show the variables and the delta between the work they are doing versus if they did nothing at all. Below, we look at ways to measure the value of an ERM program.
Many organizations ask, “How can I quantify or demonstrate the value of a program that is supposed to eliminate or mitigate the bad things from happening in the first place? How do I prove the ROI of something that doesn’t happen?” The following are a few of the most common ways to successfully prove the value of your ERM program.
For example, a global study conducted by EY concluded that companies in the top 20% of risk maturity generated three times the level of the EBITDA (earnings before interest, taxes, depreciation and amortization) as those in the bottom 20%.
Some of the most important metrics used in valuing an ERM program include total cost of risk, annual loss expectancy, risk coverage ratio and reputation quotient. Measuring these—and many other types of risk metrics—becomes a daunting task when relying upon outdated methods of measurement, like spreadsheets.
Attempting to manage company-wide risks with a series of jumbled, complicated spreadsheets is a recipe for disaster. Organizations should have a single technology platform in place to streamline the process of identifying, ranking and addressing risks, among other things. This software can show past mitigated risks, trending data, and the financial benefits of such actions.
Using dedicated software to manage ERM is a necessity in today’s business environment. Effective ERM software should provide management and end-users with the information that they need to understand risk, make data-driven decisions and reduce negative impact. The software must enable risk owners to effortlessly submit risk assessments and share data across the entire enterprise, and align to globally accepted risk management principles and frameworks including ISO 31000, Basel and COSO ERM.
What does the board of directors want to see when it comes to ERM? Most prefer a short, concise list of the top risks, confidence that the ERM program is designed and operating well, and how the program is helping the company achieve its objectives. Your ERM technology should allow users to produce meaningful board-ready reports, gain access to real-time dashboards, promote a risk culture through collaboration, and enable powerful automation. It should also:
With evidence that a company’s financial performance is tightly correlated to the level of integration and coordination across risk, control and compliance functions, many organizations are now actively working to embed a risk culture throughout their business. While the ultimate aim is to fuel better performance and achieve a competitive advantage, many are realizing the wide range of benefits created from an enterprise risk management program, and software is helping them do just that.