The Connection Between Cybersecurity and Business Process Management – How Many Processes Can You Automate? Why?

The Connection Between Cybersecurity And Business Process Management PART 2.jpg

This episode of At The Edge is made possible by the generosity of our sponsor, Edgescan.

Part 2 of a 3-part series. Read Part 1 here.

By Sean Martin, host of At The Edge

Sean Martin is joined by Ryan Duguid, Chief Evangelist at Nintex, for a conversation connecting cybersecurity with business process management.

In this 3-part series, Sean and Ryan discuss how regardless of the level of formality surrounding business processes, these operational elements are critical to define and determine how well a company can and will run. Most of the time, people think about business processes in terms of reducing waste and driving up efficiencies. Today, however, Ryan and Sean get to talk about some additional value points to help keep things from “going off the rails.”

So just what do cybersecurity and business process management have to do with each other? Read the Q&A below to find out.


Sean Martin: You mentioned quite a few companies that are providing services, and in most of the cases that you described, they are cloud-based applications. You provision them and as you use them, you start to input your own data. But parallel to that, a lot of companies also use services in the form of people. So, circling back to the onboarding of an employee, many companies also onboard partners—whether it’s channel partners or service providers that are bringing people to the game, where access to systems and data is also being brought in.

Any thoughts or experiences on the partner piece that you'd like to share?

Ryan Duguid: The partner piece is an easy place to start. Many of our customers are channeled through an organization. Nintex itself, for example, has approximately 1,700 partners worldwide, and through products and services those partners get access to licenses, marketing materials, and confidential road maps. There has to be coordination across all of this.

If a partnership ends, we have to remove their access to that information. We don't want them having road maps if they're no longer doing business with us. If you're Oracle, SAP, or Microsoft—where the size of those ecosystems is massive—the ability to manage the traditional content and information rights management becomes a key concern.


SM: So how do companies approach this when you're working with them? I'm thinking primarily in the context of roles and responsibilities and defining who has access to what, when they can use it, and how to manage that scope. Even more specifically, in the context of the risk that they might be exposing themselves to.

RD: When it comes to the process piece, one of the problems is that a lot of organizations tend to focus on a very small set of the core strategic processes: the processes at the heart of the business and the things that bring in the revenue and help them grow. While focusing on that, they often ignore everything else. If you think of those processes as being your engine, a lot of companies forget to put oil in the engine, which is not a good thing.

One of the things that we like to encourage our customers to think about is to take a more holistic view, and to map out everything that's going on with the organization. Having done that, they can begin to understand where they're most exposed or where the best benefits can come from.

It's not uncommon for us to see customers with two, three, even four thousand processes automated on our platform. You need to figure out what order to tackle those in. You can look at expense management, top-line growth, or risk and compliance.

To give you an idea of the profile customer that cares most about risk and compliance, the pharmaceutical sector is the best place to look. The financial services industry is also a typical vertical where we see people starting with risk and compliance because that's where things are most exposed. With pharmaceuticals, it is about critical IP risk. There’s a lot of auditing for how things are done and when they're done. What materials (IP) are shared as part of all of that?

We like to encourage people to step back and look at where the big wins are and move forward from that point by describing what happens. This helps make sure everybody understands. If nothing more, you need to be able to report to relevant stakeholders or interested parties that this is how you do things, and you can guarantee you do it this way every time because it's orchestrated by technology.

The challenge is that a lot of people immediately jump to automation, and that’s a problem. Before going there, you need to make sure the right people are doing things the right way at the right time. Once you get that under control, you can then start to look for the automation benefits.

What's critical is that organizations need to look at the people and their activities to make sure they understand what's happening, know it's happening in some fashion, and that it's all audited—when the activity started, finished, what the outcomes were, and when decisions were made. This needs to be done before worrying about automation.

One of the big problems of the industry right now is this obsession about automation. There's no point automating a bad process or something you don't fully understand. Make sure you understand it first and move from there.


SM: So what are some examples of things that people have automated that are putting their company at risk—a process that you've seen where you just go “Oh my, what’s going on?”

RD: I think the interesting thing tends to be the lack of process. It can be as simple as field service work. The organization provides warm bodies who go out into the world and fix problems. They could be sophisticated problems like dealing with wind turbines and generators all the way down to repairing a refrigerator. 

So how do you manage the process and make sure it's the right person with the right skills responding to the right issue at the right time? How do you schedule appropriate downtime with the customer?  

If the service takes place at a residence, you need to know when it's going to happen and if the customer can be at home at that time. For a commercial location, you identify when you’re going and how to make sure the technician follows standard operating procedures.

And that can go all the way back to how you onboarded, trained and certified that person. You need to make sure you’ve got the right person on the job so when you actually send them onsite, they know the problems they’re going to encounter.

When field personnel turn up on a job site, the first thing they have to do is identify all the risks. Then they have to log all the risks. It used to be done on paper but is now done on a tablet with electronic forms. Having identified the risks, you need to plan to mitigate all those risks. If you’re working on a piece of equipment, there are padlocks you have to put on to make sure the equipment does not fall into the wrong hands. You then have to make sure that you unwind everything as you leave the site and remove the padlocks. You also have to make sure it's safe for the operator to come back on site. Then, how do you load everything you’ve done into the core systems that you’re using to manage that facility with that piece of equipment?

It's surprising how many service organizations leave stuff like this to chance. They have to hope the field personnel turn up, do the assessment, and handle the equipment in the right way.

I've seen plenty examples where that’s not the case. As a personal example, I visited a diamond mine for the first time while working for a previous company. While there, someone decided that they would take the guard off their mining equipment. Why? Because they wanted to put in a bigger disc in than it was designed for, so they could get more work done at faster rate. The disc shattered, and it didn't end well for them. That sort of thing shouldn't happen, and that was probably someone who hadn't been taken through the appropriate safety training and briefing.


SM: That's a completely different analogy to shadow IT than I imagined. Is that equivalent to Slack being used in engineering without permission from or knowledge of its existence in the IT department? Hopefully not. I sure hope nobody is fatally wounded due to some shadow IT scenario.

RD: Shadow IT is a funny thing. In the white-collar world, it’s probably less of a health and safety risk, but potentially a bigger financial risk in terms of the theft of intellectual property and compromised systems. But if you look at the cost of some of the data breaches, and if you think about shadow IT, most companies now agree it’s OK to for employees to bring their own devices. You can either let it be the Wild West, or you can try to apply a modicum of control. You don’t want to be too oppressive because people will then try to avoid things.

Here’s a great example: most R&D organizations know how to clearly define policies around the use of third-party, open source software. Let’s say you find a great project on GitHub that you want to incorporate into your system. If you let someone do that and discover it's the wrong open source license, and later on you sell your company, you've got a big liability you have to deal with.

Or you can have a nice, lightweight process that's very standard. We encourage people to deploy it. It has a nice form and sits on your Internet. It will ask you a series of questions such as the type of open source license you will use, the number of purchase requests being made, your location, the number of contributors, how long the project has been going for, and where's it going be used.

And then you send in that information. That gets reviewed by your team manager. If they approve, it gets reviewed by the chief architect and then the CTO. If the CTO says it looks good, you get a legal check on the license type.

The good thing about this is that you then maintain at any point in time the ability to let anyone go look at a table and see what you are using and where your exposure is. And when someone finally decides to take that component out, you can just flag that this needs to be removed. Then it will go to the appropriate process to unwind that.


SM: That's a fantastic example of enabling an employee to do the right thing, helping guide them along the way to providing information, and then advising them on the audit trail that can be followed once a decision is made. Let’s talk about that a bit more. When most companies look at workflow management, orchestration and automation, they're approaching it from an efficiency perspective. How do can they make their people work better and faster?

Which, if you look at it in the context of the CIA information triad of security Confidentiality, Integrity and Availability—the speed and information being available, systems being available, and processes being available for employees are a big part of it. But we often forget about the integrity and the confidentiality. And then between those two, most people think of confidentiality as just privacy when they're talking about customers and intellectual property or customer data when they're thinking about data theft. But then most fail to think about integrity. The point I'm bringing up is essentially the integrity of data and human error.

Stay tuned for Part 3 of this 3-part series: The Connection Between Cybersecurity And Business Process Management – Don’t Forget About The Human Element


Want to comment on this article? Use Twitter. You can tweet to Ryan (@PvtRD), Sean (@sean_martin), and their companies Nintex (@Nintex) and ITSPmagazine (@ITSPmagazine). Use the hashtag #BPMsecurity to connect this thread together!

About Ryan Duguid

Ryan Duguid is vice president of products at Nintex, where he is responsible for setting product and platform vision, driving continuous innovation, and delivering technology to help everyday people solve their process problems. Ryan joined Nintex from Microsoft where he was responsible for the content management business in the SharePoint Product Group.

More About Ryan