Blog by Divebell

Avatars of Dwight Doscher and Jeremy Mailen behind 'Part 2'

Insider Insights: Mastering Compliance Tech

May 23, 2023

In this second installment of the conversation, Dwight shares practical tips on enabling data teams, deploying privacy tech, what he looks for in solution vendors, the unsolved problems in privacy, and more. You can read the first installment here.


Scoping and Compliance in the Age of Cloud and Remote Work

Jeremy:

Some companies have to follow HIPAA or HITRUST, while others do a version of ISO SOC 2 or PCI. You’ve talked about scoping as an essential part of a successful compliance program. Can you speak about that?

Dwight:

You want to create guardrails that allow the company as much flexibility as possible. I know that statement’s contradictory, but when you have healthcare information, PII, or other sensitive information, you need to enforce the least privilege effectively. Your goal is to limit the impact — by creating security controls that lock down that particular area — rather than force your entire company to be in scope for something like HIPAA or by limiting the number of systems available.

You want to create guardrails that allow the company as much flexibility as possible.

PCI is a complete beast. Limiting the amount of data spread outside your system is best. It means fewer active controls and reduced time spent in auditing. It’s less restrictive and less investment intensive. With the pandemic, remote work became the way to operate. Companies have been taking in credit card information. Now they have to factor in people having access to credit card information and segment those areas where people are working with credit card information. It’s an investment of time, effort, and energy and a hassle for people coming in and out of certain areas. So you want to ensure that data is restricted as much as possible to make everybody’s lives easier.

Yeah. That was a significant change during the pandemic, with everyone adopting cloud tools and, of course, they’re interacting with customers. So now customer information is impacted by shadow IT. There was just an organic growth of the use of these things, and it was productive. People found a way. The ingenuity is always there, but now you have to figure out, well, where did the data go? Before we could say, here are the locked boxes within the company. Now it’s a bit vague. We don’t know where the boundaries are anymore.

That’s why data discovery tools are so critical because they allow you to prove the scope that you’ve established and ensure it doesn’t spread. You can provide evidence of monitoring and access where the data is at any given time, reducing your liability.

When Do You Need Technology Over Processes?

Data discovery tools are certainly a crucial part of understanding the scope. When you think about deploying a tool for data discovery, how do you think about that process in terms of what you will monitor first — the big iron type systems or the collaboration systems? How do you go about boiling that ocean of where to point data discovery at first for scoping?

I can tell you how it was done before data discovery tools came into play. You went around as a consultant or an internal staff, interviewing people about where they were getting data from. Then you checked that against network diagrams and data flow diagrams, assuming that the organization had one in the first place. It was through discussion more than through technological evidence. You can always go back and try to prove things manually, such as checking the headers on a database or parsing the data contained within databases and systems. But it’s very time-consuming and rigorous. Instead, when you have the right tool, you can walk in with and scan the environment to see where the data is, map that back to the network architecture diagram — and you’re done. That’s it! It’s a couple of hours of work versus what is probably two weeks’ worth of work.

When you have the right tool, it’s a couple of hours of work versus perhaps two weeks’ worth!

This is especially true as the scale of data and systems is not getting smaller anytime soon! It quickly outstrips people’s ability to do it manually in most companies.

Companies are increasingly trying to extract value from the data in some way, shape, or form. It is just the natural evolution of sitting on this pile of information and wanting to get to know your customers better. Most companies do not have nefarious intentions toward using customer data. They want to understand how they interact with the system and what they do so that they can deliver their products and services to the customers in the best possible way. You need to keep the information safe and use it effectively to accomplish that.

The problem is that most data programs need specialized individuals, such as data scientists, who are used to working with their tools and within their systems. So you then are looking at database replication, pulling data into various locations, applications, SaaS tools, etc. Unfortunately, these things happen while not desirable, and you want to monitor that data movement as best as possible.

The Ideal Time to Invest in Technology

Companies come in different sizes. Many don’t have the resources for specialists who know about specific tools or can pay for and adopt them in the arc of a company’s growth. When is the right time to implement certain types of technology solutions and have them be a sustainable part of the company? Is there a sweet spot for process versus technology there?

So it goes back to the scoping. If you’re making significant investments in data science and data mining, this should be something that’s just added to the tab of that investment. You’ll have more people who want to use the information differently. It helps to start with tooling that allows you to monitor and force discussions, if necessary, with individuals having to allocate additional resources. It is a proactive way of managing the risk while acknowledging it will happen. And you want to ensure that the scope remains as clear and small as possible so that you can stay out of the way of people doing their jobs. I loved it when I was working at places like Flatiron, and I could say to them, “Help me help you so that I can stay the heck outta your way. Tell me what you’re trying to do, and I will tell you of a way to do that so that I can stay out of your way.”

Maturity & Evolution of Privacy and Cyber Security

Cybersecurity is a mature industry right now. You can slice the products very finely within, let us say, cloud security platforms, wherein you can say one tool might be better at cloud security posture management. Another one might be better at network intrusion. Meanwhile, there has now been tremendous investment in the privacy software space. With that comes a lot of marketing, of course! But are the privacy solutions truly getting there? Or do they still have a long way to go?

It’s been exciting to see the data privacy space move well, and I think that’s probably because it’s an offshoot of cybersecurity type of investment mentalities. The privacy products definitely matured at a faster rate than the initial cyber security tools. In talking with vendors, I see a much more focused approach to the problems and specific tools to address them than I have seen in cybersecurity. The UIs are much more evolved and user-friendly as well. I think that comes from having a different type of end user in mind.

I just need the information and don’t want to write a script to get the data I need.

A UI should be easy enough for anybody to use it. Security tooling prides itself on sometimes being sufficiently complex to make you feel like you’re still doing cool coding stuff while using a tool. And I look at that and just sigh and say, “Hey, I just need this data. I don’t want to write a script to get the data I need.” In data privacy, on the other hand, technology professionals and lawyers are using the tools, so you don’t want to make something too complex to absorb. And that’s made for a much better experience for the end user than cybersecurity.

Yes, I agree that cybersecurity evolved much more slowly than data privacy. As application security lead at Symantec, I got all those security surveys, and nothing wakes you up more than having to fill out yet another 200-question spreadsheet about what security controls you have and your software development life cycle. It really helps to understand what people have to accomplish regarding securing their information. As a startup founder, it has made me much more aware of incorporating feedback from prospects and clients in the final product.


CISO vs. CPO Data Discovery Expectations

Speaking of the varying needs of privacy professionals, both CISOs and CPOs want data discovery. Do you think they’re generally talking about the same capabilities? Or that there’s some difference between what is needed to secure data and what’s required to maintain privacy?

The first ask is always the same at its core: “Where is our data? What and how much of it is there in these different repositories, and which data fields are involved?” They are looking for a quick risk classification for each application.

The first ask always is, ‘Where is our data, what and how much of it is there in various repositories, and which data fields are involved.’

Where you start getting significant differences is when it comes to workflow. Data loss prevention is more of a security function than a privacy function at most companies. I haven’t seen privacy own the technical aspect, scanning, or data loss prevention monitoring. 

Security has much more at stake when it comes to understanding logging and prevention  capabilities and monitoring things such as outflows. The privacy side is looking for that too, but more at an aggregate level than what the security team needs to perform that task operationally.

At Flatiron Health, when I started building out that DLP program, it was clear that privacy really needed those aggregate stats. They needed to know what was going on. They didn’t need to play in the tooling to understand what was happening on an operational basis. They just wanted to see the program’s effectiveness and how we judged it.

Having worked on the data loss prevention side earlier in my career, I know there is a lot of emphasis and technical investment into the prevention piece and integration with all the different ways data can move. But the understanding of the content tends to be less nuanced. For a security person, if it is somebody’s PII or any sensitive data, the instinct is to block that data from going out. But to a privacy person, there are questions such as geographical location and the type of law governing that data.

Privacy Tech and Cross-Team Collaboration

And that leads me to the next question — as companies get bigger, there are more roles, teams, and activities. You’ve probably seen certain hotspots. As a privacy officer, for instance, you could interact a lot with the data science team for example. What are your thoughts on whether the technology to facilitate this helps or hinders teams working with each other?

The key when working across different teams is to always work off with the same data set. That is critical to teams speaking the same language and defining the issue. So having a technology solution or system that services data that both teams are looking at that shows something like scope creep. When data is in different places, pull something up and just say to them, look, you have access to this tool too. We’re both working from this. You can see that there’s data in places it is not supposed to be in areas that look like it’s starting to move towards. One, is this an expected behavior? Two, do we need to have the data here? And then three — how do we arrive at a way that this information is secured appropriately?

The key when working across different teams is always working off with the same data set.

These conversations are impossible if you’re working off different data sets or information that can’t be constantly checked.


Proof Points for Executives and Boards

Jeremy:

When you’re looking to get buy-in from the executives, how does technology help you with the conversation?

Dwight:

It allows you to build dashboards and reports and present digestible segments of information. Presenting to the upper management without a clear visual will result in non-absorption. I firmly believe in technology providing cleaner data to be built into a report quickly, or you can create a report on the platform itself. And pulling the data via API is much easier than manually pulling information. I have to do that across a couple of tools right now. It’s Ineffective and creates a lot of confusion and potential for mistranslation. Having tools that enable you to deliver this data ensures that it is cleaner and more efficient, and it allows you to get closer and closer to live dashboards, which you really need for your executive management at the end of the day.


Unsolved Problems in Privacy Tech

Jeremy:

The data privacy space is certainly evolving faster, but do you see any significant gaps or opportunities? When you look at the landscape, where do you wish the privacy solutions were investing more or making more considerable strides on a couple of key problem areas?

Dwight:

There are two significant areas for data privacy solutions. 

The first one is having a holistic approach to where data is as far as data discovery is concerned. That’s a big challenge there because it’s tough to maintain an up-to-date SaaS inventory. Data privacy solutions that can reach into each type of SaaS tool that could hold sensitive information and extract an understanding of what and how much data is stored there, would be very beneficial.

The second item is workflow related. Integrations with workflow tools that allow communication back and forth between project management tools are crucial. Workflow automation tools are essential to maintain a privacy program. You want to eventually get as hands-off as possible for those repeatable tasks. There is software right now that can help you manage the front end of that, but on the back end, it usually falls short as far as being flexible enough to let a company build a custom process using end-to-end automation.

You want to eventually try to get as hands-off as possible for those repeatable tasks.

And it takes work. Again, you’re dealing with professionals with different backgrounds and training. You want to make it as easy as possible for those non-technical types to be able to build out those automation flows. And that requires more structured integrations. Meanwhile, if you’re appealing to the engineers, you can go with a more open API and allow them additional customization. It’s easy to say that because I don’t have to build that solution, but it’s complicated to get that done for the two polar opposites you’re dealing with.

Jeremy:

You bring up two interesting points here. Regarding UI, yes, It is a challenge when designing a product for different audience types. You don’t know if it will be a security engineer or a privacy person with a legal background. All those people may use your software and have different UI needs and preferences. For instance, the operations professionals want to see some pretty granular event logs. But that will mean little to somebody just thinking about data compliance.

You also talked about integrations and automation. So there is the technology side and the human side. And there’s always going to be a little gap. No matter how much you’ve done right in implementation and first-class integration, there always needs to be a safety valve that lets you out to an automation process outside your product and integrates smoothly and cleanly with that. So it’s simple to manage, and it can do more. That just increases its wingspan.

Advice for Solution Providers

Jeremy:

You’ve worked at companies that have built compliance solutions and been an end-user of these solutions. What do buyers look for when evaluating solution providers, particularly when the vendors are start-ups?

Dwight:

There are four questions that I find asking myself when looking at data privacy solution providers: 

1. Can they back up their claim?
Since working as a solution provider, where I was in charge of implementing solutions, I am more discerning and investigative about delivery. On sales calls, I am more apt to say, “Prove it” or “I need to see a demo.” 

2. Do they respect my time?
I only take demos if I intend to purchase the product. The only times that I take demos on multiple products is when they’re both priced similarly, in which case it comes down to the UI being the determining factor. I know what I’m looking for in a product and come in with specific problems and a good idea of what I want to accomplish. So I am looking for a solution to solve that specific problem.

I look for senior leaders who have actually done what their product is trying to accomplish.

3. Does the Leadership have hands-on experience?
I look for senior leaders who have actually done what their product is trying to accomplish. This is especially true for start-ups. For example, when looking at GRC solutions, I am less interested in who their VC is. It is more relevant to me if one of their core team members is a CISO or was a Director of Compliance someplace. Were they hands-on enough to understand the solution they’re trying to generate?

4. Are they really invested in the solution?
One of the other things that I focus on when I’m purchasing a product now is to ask them, “What are you doing for security?” We have a lot of vendors in the space right now who are looking to take advantage of a hot field more than they are trying to craft sustainable solutions for companies. That question is meant to ascertain their general view of the security field. Is this just a money-making opportunity for them alone, or are these people invested in a solution? A related criterion is my ability to influence the product roadmap, especially when working with start-ups or early-stage companies where their flexibility is much stronger than dealing with an enterprise-level product.

How Can a Vendor Be a Part of Positive Change?

A final question — as you know, Divebell is working in this space, providing solutions for data discovery and data visibility across your landscape that you talked about being so useful for scoping. What advice would you have for us as a vendor?

We’re trying to be a positive part of the community and produce a solution that really makes everyone’s life easier in this space.

I would like to see a pairing between data discovery and inventory management tools. Being able to do a side-by-side of here’s what assets Divebell is looking at, here’s what our inventory is saying exists and ensuring that there’s a match between everything so that there is effective monitoring.

The second item would be workflow. The answer will always be workflow for practitioners, especially if we’re hands-on. The last thing is reporting. I’m building dashboards myself. The ultimate test of these tools is creating an interface that can be absorbed at different levels or creating different interfaces for various levels. The general counsel or CPO can come in and see what the results of those practitioners’ efforts are, and then the CEO can come in and say they would probably even want to know things like how many records we have of clients. It would be something other than what even the CPO wants to see. At the CEO level, they understand how much information we have that may be attributed to marketing efforts or things like that.

And even the age of those records, how fresh is this data? And should we keep all this old data around for people we haven’t talked to in a long time?

Absolutely!

Thank you so much, Dwight, for your insights and the great conversation.

Any opinions expressed here and statements made are not legal advice, nor representations or warranties, and are intended to promote discussion around technology and data protection.

Contact Us