Watch our exclusive FoRG webinar: An Introduction to SQL Data Catalog

• 
  Thank you to everyone who joined us on Monday for our live webinar on SQL Data Catalog.
  
  Don't worry if you couldn't attend, as you can watch the recording on-demand, simply follow the below link.
  
  Watch the FoRG webinar: An introduction to SQL Data Catalog
  
  If you have any questions about the product, please let us know either by commenting below or emailing friends@red-gate.com
  
  We strongly encourage you to try out SQL Data Catalog yourself and feedback any thoughts or suggestions. We very much value your opinions and we'd love to hear what you think about our new offering. To claim your complimentary FoRG license, please email me. 
  
  Cheers,
  
  Roseanna

  Roseanna October 09, 2019 12:52

  - 0 +
• 
  Hi Roseanna
  
  I watched the webinar and I can see that the product helps you tag or curate your data pretty quickly.
  
  I can see that masking your sensitive data in lower environments is one important use case that this tool makes easier but I was wondering what some of the other use cases could be?
  
  i.e.  once you have completed the cataloging exercise, what are some of the questions that can be answered? 
  
  When might you want to tag something as 'Confidential GDPR' as opposed to just 'Confidential'?  Have you got a taxonomy that you have applied at Redgate that you could share?
  
  The product is probably not aimed at someone like myself as I have never been involved in the privacy or compliance side of things but its something I would like to understand a bit further in the future.
  
  cheers,
  Ben
  
  

  ben_b October 16, 2019 13:48

  - 0 +
• 
  Hi @ben_b thank you for your message - glad to hear the Webinar was helpful!
  
  Typically we see the 2 main use cases for SQL Data Catalog being 1) The masking of lower environments as you stated and 2) Informing other business decisions about data. This could be anything from putting auditors minds to rest that we know where all of our sensitive data is to deciding whether or not to give people access to certain systems - it could also be useful in some kind of impact assessment if we were to evaluate our readiness for data breaches and our response times.
  
  I've also heard of companies both using this to a) Catch new columns/Tables that are added by developers and ensure they stay on top of the classification workflow and b) Use it for reporting purposes to data governance teams i.e. who owns the data, where is it being used etc.
  
  I guess the point is that whilst the initial Cataloging requirement can be satisfied, it's actually the ongoing consumption of that Catalog that drives the real value!
  
  As for the differentiation between Confidential and Confidential GDPR, this is primarily the Microsoft specific sensitivity labels that come out of the box with SQL Server 2016+, but like I mentioned in the webinar, with Data Catalog these can be extended to reflect your own business-agreed taxonomy so someone could use "Confidential - POPI" if they're in South Africa, or can add their own Categories and tags like "Treatment Intent" or "Retention Period", but the point is it really has to be agreed up front so that everyone is tackling the classification from the same angle.
  
  We actually package up an example taxonomy out of the box with Data Catalog, which represents an amalgamation of categories and tags that we have seen many of our Early Access Users adopt into their own taxonomies.
  
  I hope some of this information helps? Let me know if you have any additional questions!
  
  Thank you very much!
  Chris

  PlantBasedSQL October 17, 2019 07:30

  - 0 +
• 
  thanks a lot for this Chris, very helpful

  ben_b October 17, 2019 08:24

  - 0 +
• 
  In the US, we have GDPR-like regulations emerging on a state by state basis.  California is first, but 22 other states are in motion now too.  Which means we could end up with 50+ different regulations (+ depends on what the federal government, DC, Puerto Rico and Guam do) to contend with.  That's a lot to track manually, but a tool like this will help a lot.

  
  

  One of the big complications is what is personally-identifiable information.  Under current regulations, your name alone is not PII, and your phone number alone is not PII, but together they are PII.  That's hard to do with simple table scanning, but I think I'd add a label of "partial PII", and have a Powershell script which analyzes the results of a scan for these two elements, and then recategorizes them as PII.

  
  

  In my line of work, we also have use-by-source concerns.  An oversimplified example is as a mortgage company, we deal with a lot of real estate agents, and we need to make sure we have both the correct licensing information as well as the correct contact information.  We buy the licensing data from one source, and the only permissable use is for license verification.  We'd also like to market to real estate agents to remind them that we offer great customer service.  For this, we need to buy another list of data which doesn't guarantee (or even have license data at all).  I can categorize data in different tables or databases with a use policy in a way which is documented with the other classifications, in one place.
  

  rjdudley October 17, 2019 13:49

  - 0 +

Add comment

Please sign in to leave a comment.