Safeguarding Sensitive Data

[MUSIC PLAYING] So let's say we do that, right, and say, look, Mike, all I can tell you is make sure when you're migrating your data that there are rules, that data is curated on you know what's sensitive, what's not sensitive. You really need to know what policy applies to what data. After that, you guys can go nuts. No, absolutely. It all starts with understanding what is sensitive data because again, there's lots of different types of sensitive data. Some may be personally identifiable data. Some might be healthcare data. Some might be your own internal IP. I would say that-- That's all that information is contained in the model, right? If someone has-- Identity. So yeah, so the modeling process would be if you're not clear on that data, and there's a couple of ways to look at it. If you're talking to your business people, they will know whether that data is sensitive. And through the modeling process, you would want to document that. Again, it's all about knowing up front and planning, facilitating, planning, making sure there's no surprises. So you would-- the data modeling process is an excellent place if you've got greenfield data that you've never had in your business before to document that that data is sensitive, why it's sensitive. And then that will be their guide to should we encrypt it, what do we do? Do we mask it? All these different things now-- And way upstream, and because the rest of the stuff, encryption, access controls, that's downstream. The modeling is upstream. And that, that is so, so important. Would that be a fair analogy? Well, that's what drives that downstream work. How would to encrypt something if you didn't know it was sensitive? OK, OK. Cool. All right. But-- Is there anything further upstream or-- Well, data modeling, there will be some capabilities if you're leveraging things that are enabled by the database. So if you're leveraging some mechanisms that protect data, encrypt data, do things within the database, then the data model can help with that. And because, again, your physical model will be specific to that database and will support the different capabilities than it has. If not, the documentation will then allow you to leverage that. But when you think about your security folks, your governance folks, your GRC folks in the organization, they all want clarity up front of what data is at risk. Because sensitive data, by definition, is data that's at risk, of nefarious-- people trying to steal it, trying to lock it down, all sorts of different things. They want clarity into that. They want to understand both pre-breach and post-breach, obviously, pre for planning. Post-breach. They want to be able to quickly go to a data model and say, OK, this data was stolen. They can quickly go there and say, Holy cow that's got some really important stuff and this is going to be bad. Or they're going to say, OK, we're all right here because we did the right things and they may have stolen some data, but it may be encrypted, or it may not be associated. And I'm thinking with the database, migration is where you're going to have these meetings. They're going to want to know who has access to this information while you do the migration. Yeah, they want to make sure that the protections are not lost through the process of migration. OK, cool. Thank you Danny. Much appreciated, Yeah, I'll be in touch again. Thank you again.