Verifying Compliance


Prove You Protected the Right Data, the Right Way

Challenges

 

More data privacy laws -- like those tabbed across this section -- in the US, Europe, and other international jurisdictions are passing and being enforced. CISOs and data governance teams responsible for safeguarding data at risk must also prove they located and protected that data in the right places, and in the right ways.

 

Data Loss Prevention (DLP) systems and data masking software can discover and de-identify Personally Identifiable Information (PII). How well do they document their search results, and actual masking procedures? How easy is it to locate and modify specific protections if something needs to be redone, or done differently? How can the risk of re-identification based on quasi-identifying data be measured and mitigated?

 

And, for database activity, including and especially queries, it's helpful to have an audit trail available to know what data was accessed, by whom, when, and where.

 

Solutions

For detection control, review the field-level protections specified in the self-documenting, human-readable job scripts, mapping diagramsSI, or configuration files used in the IRI FieldShield and IRI DarkShield data masking products, or the IRI Voracity data management platform.

For proof of what ran, log all jobs to the query-ready XML audit file. In the case of FieldShield, the audit trail contains the job script, which shows the protection technique(s) applied to each field in each table or file processed. Voracity mapping diagrams show the same changes quickly with orange connectors and the visual representations of the jobs are good images to share.

The log also contains other job metadata, like the:

  • protection library function(s) used
  • encryption keys or de-IDcodes
  • input and output tables or files
  • user who ran the job
  • job start and end times
  • number of records processed

 

 

For prevention control, you can review your jobs to validate a developer’s protections of output fields prior to execution.

For example, masking the SSN field in a payroll feed is a matter of connecting to your sources (or existing jobs) and clicking through a new job wizard or modifying existing parameters in a dialog or script. Some of the functions you can apply (ad hoc or as a rule), are:

  • encryption and decryption
  • anonymizationvia pseudonymization
  • data masking
  • de-identificationand re-identification
  • field redaction