Creating Policies in Plain English with Immuta

Siloed data across companies hinders efficiency and compliance. Data teams tasked with authorizing access to data across these silos may spend weeks, if not months, ensuring data is secure and access is compliant. These manual, time-consuming processes require numerous meetings with software developers and other technical experts.

Immuta, in contrast, accelerates compliance by empowering data engineers to create comprehensive, dynamic policies that protect data without needing to write any custom code. By writing policies in plain English, data teams can easily create policies that dynamically mask data, apply privacy-enhancing technologies like differential privacy, and more – and managing all these policies in one, easy-to-read location.

Within Immuta there are two types of policies: global and local policies. Global policies apply to all data sources across the platform. Local policies, on the other hand, apply to specific data sources. Below is an example of each type of policy within Immuta.

Example Global Masking Policy:

Here, we’ve built an example global policy that masks all personally identifiable information (PII) on all data sources across the platform. The policy is titled “PII Masking” and applies to all data sources that have columns tagged “PII.” Tags can be managed within Immuta or from an external data cataloging tool (like Collibra). This policy will automatically apply to all data sources with this tag.

Note, also, that we’ve specified that this policy should apply to everyone, but we could have created exceptions. For instance, the policy could apply to everyone except members of specific groups that have been given specific authorization to see the raw data directly. An example of when data teams might enact these exceptions in the case of home or auto insurance: Agents may be given access to sensitive personal data like social security number in order to run credit and other background checks, but underwriters, marketers and others in the agency would not be granted access to that data.

Example Local Time-Based Policy: 

Here, we’ve built an example local policy that limits access to the last two years on just a local data source. Like the example above, we’ve specified that this policy should apply to everyone; however, this policy is constructed locally, meaning it will only impact one specific data source. Data engineers using Immuta and Databricks might use a local policy to restrict access to certain data sources, such as when scaling secure data access to hundreds of remote contract researchers.

With Immuta’s dynamic policies that can be written in plain English, it’s easy to break down data silos so that teams can efficiently and securely access data, and data teams aren’t responsible for dozens of manual, risk-prone data access authorization requests. Try it out for yourself by starting a free trial of Immuta today.