Gathering Requirements

Where the Disconnect Happens

As an IT director, I've had a lot of other departments come to me and say, we just bought this software, it's going to revolutionize the way we do business, it's going to change everything. And then you implement it and it doesn't do that at all. So where is the disconnect here? A lot of times I find it's because they didn't do the proper gathering of the requirements and needs assessment. Is this product actually going to meet our needs? Do we even know what our needs are? There's this initial step that often gets bypassed, and we need to make sure that this happens. Otherwise we're going to spend a lot of time and resources and money on software, services or hardware that's really not going to do the job.

All too often I see employees get sold on a product and jump straight to signing a contract, and by the time they start including the cybersecurity program into the loop, it's already in the onboarding process. They're already onboarding this product, whatever it is, whether it's hardware or software or services, and this is way too late in the game. Are they going to meet our security needs? Is it really going to meet the needs of the company? Is it going to meet the needs of whoever chose this product or services? It's too far along in the process, and they skip this gathering requirements phase.

It's a really important part, especially when you're talking about products and services that are going to require a lot of time and energy to implement. Those are very costly programs, and we need to be included very early on in this process.

The Needs Assessment

A proper needs assessment is really going to analyze what it is that we're trying to accomplish out of this. If we do a proper needs assessment, we'll also be able to assess things later on: whether we've accomplished the goal, and whether we should continue with whatever products and services that we have purchased. So we're going to want to start out with a proper needs assessment.

How do we do that? We ask people. We just start doing interviews of what we're trying to accomplish. What is it that we're trying to meet? What are the requirements for whatever product that we're rolling out?

Security Requirements

We're also going to want to establish what our security requirements are of whatever products and services that we're purchasing. For instance, maybe it's some sort of cloud service provider that we're assessing. Is this going to meet our needs when we might have very sensitive data up in there that we want to make sure confidentiality is going to be at the level that we require? We're going to assess what the requirement is for confidentiality, for integrity and for availability. It might be extremely high. It might have PII information of our customers in there, and we need to make sure that we are guarding against all of this. But it also might be low. It might be just the simple little program that we're using where we're not really storing much data at all, and in that case maybe our requirements are very low from a security perspective. But we're going to have to determine what level we are going to assess this vendor at.

After all, we've spent so much time looking at all of our different processes and all of our different functions that we have. If we go through all of this point of protecting our internal assets, but we turn some of those over to this other vendor and now it exposes us, that's going to be problematic. It is a weak link, and we're only as strong as our weakest link. If that link breaks, then it's going to expose the rest of the company to this risk.

Requirements to Look At

What are some of the requirements that we might look at? There are going to be a lot of different requirements. Just to name a few: what is the legal and regulatory compliance of the data that we're handing over to them, or the services that we're handing over to them? Or, if we're purchasing the product and it's going to be on our site, how secure is that product from a legal and regulatory compliance standpoint?

We also have to think about change management. If we have this change management process but then they don't, is that going to be problematic? Or what are the incident reporting requirements? Let's say we're handing over our PII information to a company, but they don't necessarily report breaches to us. Then how are we going to fulfill our needs of reporting breaches to our customers?

There are also some geographical considerations. I've had customers that are in one country and they require us not to expose our data to other countries, so we have an obligation not to store data in other countries. That might seem far-fetched at first, but in this global world that we have here, I could really turn up services anywhere just like that, real easily, and so I need to consider those geographical considerations.

But it goes beyond just that. It also is the times that we work. For instance, if I bring a vendor on that I have to coordinate with and do a lot of one-on-one communication with: I'm in the United States, so if I were to choose somebody in, let's say, Brazil, then we're in a similar type of time zone and coordinating might be a lot easier. But if I choose somebody over in bellus, and I'm having people over there and I need to coordinate with people over there, then it becomes a time zone issue, because they are a very different time zone than where I'm at, and so coordination becomes an issue.

There's also the idea of support availability. It could be the time zone thing that I just mentioned, or what other type of support are they providing us.

Technical Considerations

There are also a lot of technical considerations. Once again, this isn't an exhaustive list, but just some things that we should think about as we're assessing this. What is the technical testing they do, or what is the technical testing that we want to perform to make sure that this vendor is going to meet our needs? Do they have the proper network segmentation? Things like PCI DSS require us to have a certain amount of network segmentation, and whatever company that we're onboarding, do they have it at that level? We've got to think about transmission control, or shared credentials, or device and technical configurations. What are the requirements for our business, and what are the requirements that we are going to put on whatever vendor we're using? That's going to vary and change depending on what kind of agreement it is, what type of services that they're providing, what type of products they're providing.

Vendor Viability

There's also this term vendor viability, and this is just the idea of how stable this vendor is going to be. Are we going into an agreement that's going to spend six months setting up and getting all situated, and we're going to spend a ton of time and money setting it up, and then what happens if they go out of business? Are they making the right decisions? Are they secure enough with their financial position? Maybe they have some staff turnover, maybe there's some sort of financial risk, and maybe there's some sort of a risk that they actually get purchased. That's what merger and acquisition is: maybe that company gets purchased and it's going to possibly change our relationship. So we have to look at what the vendor viability is, how this is set up, how our relationship is going to go, and what's going to happen if they go out of business. That is one actual consideration with all of this as well.

How Much Time to Spend Gathering Requirements

The requirements are going to vary greatly depending on what kind of organization we are, depending on what kind of vendor that we're communicating with and talking with, and depending on what kind of services that we're expecting from them or products that we're expecting from them. Because of this, that's where we just open this up for a lot of discussion to determine what is going to be our target with this and what is going to be our requirements that we are going to judge everything else on.

How much time we spend in gathering what these requirements are is really going to vary, and I find that the two ways that it's really going to vary are, number one, financially: how much we're putting into this, how much time and resources and money is actually going into this relationship that we're setting up and creating. But then also, what is the sensitivity of the data and services that we're going to be putting into this? Really, that's the security requirements of this when you boil it down. By understanding those two aspects, we'll understand better what the requirements are and what we're trying to target.