Requirement: CREATE_PROJECT Immuta permission

Create a new project

1. Navigate to the Projects tab under Data in the sidebar, and click the New Projects button.

2. Fill out the Basic Information:

   1. Enter a name for your project in the Project Name field.

   2. Opt to complete the Project Description field to help identify your project.

   3. Opt to enter project Documentation to provide context for members.

3. Select the purposes and any policy adjustments:

   1. Choose to select a purpose from the list of purposes or create a new purpose for the project.

   2. To create a new purpose, click Create Purpose and complete the prompts in the modal.

   Note that all purposes added to a project will need to be created or approved by a user with the GOVERNANCE or PROJECT_MANAGEMENT permission. Once purposes have been applied to a project, only these users can add data sources to the project.

4. Add a native workspace configuration: Select your workspace configuration from the Workspace Configuration dropdown menu: Databricks or Snowflake.

   • Databricks: Opt to edit the sub-directory in the Workspace Directory field (this sub-directory auto-populates as the project name) and enter the Workspace Database Name.

   • Snowflake: Name the Workspace Schema. By default, the schema name is based off of the project name, but you can change it here. Your project workspace will exist within this schema under Snowflake under the database configured by the application admin.

     1. Use the dropdown menu to select the Hostname. Projects can only be configured to use one Snowflake host.

     2. Select one or more Warehouses to be available to project members when they are working in the native workspace.

5. Add data sources to the project using the dropdown menu. Data sources can also be added after the project is created.

6. Click Affirm and Create.

Set the project subscription policy

Projects are private by default but can be made public and shared with other users by changing the subscription policies setting. Governors are the only users who can manage subscription policies for projects with purposes.

1. In the project, click the Policies tab.

2. Click Edit Subscription Policy.

3. Select the group of users who will have access:

   • Allow anyone: Selecting this option makes the project visible to everyone. Opt to require manual subscription by selecting the checkbox. This will require the users to manually subscribe to the project to gain access.

   • Allow anyone who asks (and is approved): Selecting this option makes the project visible in search results, but users must request access and be granted permission. This restriction supports multiple approving parties, so project owners can allow more than one approver or users with specified permission types to approve other users who request access to the project.

     1. Click Anyone or An individual selected by user from the first dropdown menu.

        Note: If you choose An individual selected by user, when users request access to a project they will be prompted to identify an approver with the permission specified in the policy.

     2. Select the USER_ADMIN, GOVERNANCE, or AUDIT permission from the subsequent dropdown menu. You can add more than one approving party by selecting + Add Another Approver.

   • Allow users with specific groups/attributes: Selecting this option allows users with the specified groups and attributes to join the project.

     1. Choose whether to build the policy off user groups or user attributes:

        1. is a member of group: Type the group name and select the group.

        2. possesses attribute: Type the attribute and select it. Then select the value from the dropdown menu.

     2. Opt to + Add Another Condition. When adding another condition, choose how the conditions will be required. If you select or, only one of the conditions must apply to a user for them to subscribe to the project. If you select and, all of the conditions must apply.

     3. Opt to allow users who do not meet the restrictions defined in the policy to still be able to discover the project by selecting the Allow Project Discovery checkbox.

     4. Once saved, users with the proper authorizations will be automatically subscribed. Opt to require users to manually subscribe to the project by selecting the Require Manual Subscription checkbox.

   • Allow individually selected users: Selecting this option hides the project from the search results. Project owners must manually add and remove users, and the Private label will appear next to the project name.

4. Click Save to finish your policy.

Add users or groups to the project

1. In the project, click the Members tab.

2. Click the Add Members button.

3. Start typing a user's or group's name in the Add Members modal and select it from the dropdown that appears.

4. Opt to add an expiration to the subscription by entering the number of days until the access will expire.

5. Select the role.

6. Click Add.

Current project members will receive notifications that new users have been added to the project. A similar entry will be posted to the project's activity pane.

Purpose-based access control makes access decisions based on the purpose for which a given user or tool intends to use the data. This method of data access also provides flexibility for you to override policies and grant access to unmasked data to an individual for a very specific reason. Immuta recommends using purposes to create exceptions to global data policies.

There is some up-front work that needs to occur to make this possible.

1. A user with the GOVERNANCE Immuta permission creates legitimate purposes for access to different data types unmasked. As part of creating the purposes, they may want to alter the acknowledgement statement the user must agree to when acting under that purpose.

2. A data owner or governor updates the masking or row-level policies to include those purposes as exceptions to the policy. For example, Mask all columns tagged PII for everyone except users acting under purpose [some legitimate purpose(s)].

3. Users create a project and connect the project to both the policy and the purpose by

   • adding data sources with the policies they want users to be excluded from and

   • adding the purposes to the project

4. However, that project does nothing until the purpose is approved by a user with the PROJECT_MANAGEMENT Immuta permission.

5. Once that approval is complete, the user wanting the exception must acknowledge they will only use the data for that purpose.

6. Using the Immuta UI, the user switches to that project context. Once switched to that project, the approved exceptions occur for the user.

These exceptions can be made temporary by deleting the project once access is no longer needed or un-approving the purpose for the project after the need for access is gone.

Requirement: You must own the project

Equalize the project

1. Navigate to the project.

2. Click the Policies tab.

3. In the Project Equalization section, click the toggle button on the far right to On.

Add a purpose with noise reduction

1. Navigate to the project Overview tab.

2. Click the Add Purposes button in the center of the page.

3. Select the desired purpose(s) from the dropdown menu. The project must have one purpose with noise reduction for policy adjustments to function. Noise reduction is indicated by the policy adjustment amount highlighted in gray. If there is no policy adjustment shown, it is the default, none.

4. Click Save.

5. The purpose will be staged until a user with the GOVERNANCE or PROJECT_MANAGEMENT permission approves and activates it. If you have one of these permissions, the staging will be skipped.

6. After the purpose has been approved, click I Agree to agree to the terms of the purpose.

   Note: All members of the project must agree to the terms of the purpose; if they decline, they will be removed from the project.

Add data sources with k-anonymization policies

1. Navigate to the Policy Adjustment tab.

2. Select the data source from the dropdown menu. You will receive a No Adjustments Available message if there are no columns in the data sources that are associated with adjustable policies.

3. Select the columns from the dropdown menu.

Adjust column weights and percent null

1. In the priority ranking window, give weight from most to least important columns. The higher the weight the more usability will be provided, while still providing de-identification through the other columns.

2. Opt to select Keep Fields in the Clear for specific columns.

3. After assigning the weight and ensuring that the remaining weight is zero, click the Adjust button.

4. Check that the percent NULL is appropriate for your usability. If you are content with the percent NULL, move on to the next step; if you are not satisfied with the percent NULL, repeat the previous steps until satisfied.

5. Click Apply after you have made the acceptable adjustments.

Keep fields in the clear

After you ensure that your data source has two columns with k-anonymization policies applied,

1. Navigate to your project and click the Overview tab.

2. Click Add Purposes and select a purpose with a Noise Reduction and Fields in Clear tags, or create a new purpose with Noise Reduction and Fields in Clear enabled.

3. Click Save, and then click I Agree.

4. Navigate to the Policy Adjustment tab.

5. Select the data source(s) and columns from the subsequent dropdown menus.

6. Select the Keep in the Clear checkbox next to columns to be kept in the clear.

7. Adjust the weight for the remaining columns. The Remaining Weight must equal 0.

8. Click Adjust and then Apply.

The values for the fields you selected will now be visible to users acting under the project.

Requirement: GOVERNANCE or PROJECT_MANAGEMENT Immuta permission

Create a purpose

1. Click Governance and select Purposes in the navigation menu.

2. Click + Add Purpose.

3. Complete the Purpose Name field, and opt to customize the acknowledgement statement or add a description.

4. Click Create.

Create sub-purposes

1. Click Governance and select Purposes in the navigation menu.

2. Open the dropdown menu and click View or Edit in the actions column of the purpose you want to add sub-purposes to.

3. Click Add Sub-Purposes.

4. Enter a name in the Enter nested purpose field in the Sub-Purpose Builder.

5. Click the arrow to the right of the purpose or sub-purpose(s) to continue adding nested purpose fields.

6. Click Save.

A list of sub-purposes will populate at the bottom of the page. You can manage these sub-purposes by clicking Edit in the Actions column at any time.

Add a purpose to an existing project

1. Click Data in the navigation menu and select Projects.

2. Go to the project overview page and click Add Purposes.

3. Select the purpose from the dropdown menu or click Create Purpose.

4. Complete the prompts in the modal and then click Save.

For the purpose to go into effect, it must be approved by a user with the GOVERNANCE or PROJECT_MANAGEMENT Immuta permission.

Customize acknowledgement statements

1. Click Governance and select Purposes in the navigation menu.

2. Open the dropdown menu and click Edit in the Actions column of the purpose you would like to customize.

3. Click Edit above the acknowledgement statement, customize the text, and then click Confirm.

The page displays the updated statement, which now will be used by all projects and purposes. The updated statement will also be used by any new members joining existing projects containing purposes with default statements.

By default, sub-purposes will inherit the acknowledgment statements of their parent purposes. However, you can customize the acknowledgement statement for an individual sub-purpose as well by following the process above.

Manage purpose requests

1. Navigate to your user profile page and click the Requests tab.

2. Approve or deny the purpose request in the actions column.

Delete a purpose

1. Click Governance and select Purposes in the navigation menu.

2. Click the more actions icon in the Actions column of the purpose or sub-purpose you want to delete.

3. Select Delete, and then click Confirm to approve the deletion.

Any project that contained the deleted purpose will be treated as no longer compliant, so the project overview page will display a violation tag. Project owners can remediate the violation by removing the purpose from the project.

Manage project purposes

Requirement: You must own the project or have the GOVERNANCE or PROJECT_MANAGEMENT Immuta permission

Add a purpose to a project

1. Navigate to the Project Overview tab.

2. Click + Add Purposes.

3. Create a new purpose in the modal or select purposes from the dropdown menu.

4. Click Save, and then click I Agree.

Remove a purpose from a project

1. Navigate to the Project Overview tab.

2. Scroll to the purposes section and click Remove.

3. Click I Agree

Enable project equalization

See the Manage project equalization guide.

Enable masked joins

See the Enable masked joins guide.

Manage project documentation

Requirement: CREATE_PROJECT Immuta permission (and you must own the project)

1. Click the Project Overview tab.

2. Click the Edit button in the Documentation section.

3. Document the details of your project in the text box that appears, and then click Save.

Manage project tags

Requirement: CREATE_PROJECT (and you must own the project), GOVERNANCE, or PROJECT_MANAGEMENT Immuta permission

1. Select a project and navigate to the Project Overview tab.

2. Scroll to the Tags section and click the Add Tags button.

3. Begin typing the tag name in the window that appears, and then select the tag from the dropdown menu. A list of chosen tags will populate at the bottom of this window.

4. After selecting all relevant tags, click the Add button.

Remove tags from a project

Requirement: CREATE_PROJECT (and you must own the project), GOVERNANCE, or PROJECT_MANAGEMENT Immuta permission

1. Navigate to the Project Overview tab.

2. Scroll to the Tags section and click on the tag that you want to remove to open its side sheet.

3. Click Remove.

4. Click Confirm to delete the tag.

Disable, enable, or delete a project

Requirements:

• CREATE_PROJECT (and you must own the project), GOVERNANCE, or PROJECT_MANAGEMENT Immuta permission to disable or enable a project

• CREATE_PROJECT Immuta permission to delete a project

Disable a project

1. Click the Data icon and select Projects in the sidebar.

2. Select the My Projects tab.

3. Click the more options icon next to the project and select Disable.

Enable a project

1. Click the Data icon and select Projects in the sidebar.

2. Select the My Projects tab.

3. Click the more options icon next to the project and select Enable.

Delete a project

Deleting a project permanently removes it from Immuta. Projects must first be disabled before they can be deleted.

1. Click the Data icon and select Projects in the sidebar.

2. Select the My Projects tab.

3. Click the more options icon next to the disabled project and select Delete.

4. Click Confirm.

Requirement: You must own the project

Edit a member role

1. On the Members tab, click the Role of the member whose role you want to change.

2. Select a different role: subscribed or owner.

Remove members from a project

1. On the Members tab, click the Deny button next to the user or group you want to remove.

2. Complete the Reasoning field in the window that appears, and then click Submit.

Purpose-based access control is a method of data access control that makes access decisions based on the reason a user or tool intends to use the data, which provides flexibility data governance teams need to build a high-powered, granular access control model. Furthermore, most regulations (like GDPR and HIPAA) include purpose clauses that require sensitive data only be collected and used for precise reasons.

For example, the GDPR’s Purpose Limitation Principle states that “Personal data should only be collected and processed for a legitimate specific purpose.” Furthermore, the regulation claims that the specific purpose “should be expressed in an unambiguous, transparent, and simple manner” in order to be compliant. The goal of this clause is to ensure that sensitive information is not being unnecessarily collected, stored, and exposed to risk by organizations that use it. With purpose-based access control, organizations can exhibit the granular, purpose-based control over data access that ensures compliance with these standards.

Immuta projects allow you to connect purposes to data sources and users to enforce purpose-based access controls on your data.

This getting started guide outlines how to quickly implement purpose-based access controls for your business use case using Immuta projects, purposes, and global data policies.

How-to guides

The how-to guides in this section illustrate how to create and manage projects and purposes.

• : Create a project to group data sources and users.

• : Create a purpose for your project to enforce access restrictions on the project data sources.

• : Redistribute the noise of k-anonymization across multiple columns of a data source within a project to make specific columns more useful for analysis.

• Project management: This section guides project owners, governors, and project managers through managing project settings, data sources, and members.

Reference guides

Concept guide

Requirements:

• If or is enabled, you must own the project.

• If a purpose has been added to and approved for the project, you must have the GOVERNANCE or PROJECT_MANAGEMENT Immuta permission.

• Otherwise, you must be a project member.

Add data sources to a project

1. Navigate to the Project Overview tab.

2. Click the Add Data Sources button.

3. Start typing the name of a data source you'd like to include in the project.

4. Select the data source from the list of auto-completed options in the dropdown menu.

5. Repeat this process to add additional data sources to the list. You can remove them using the more options icon.

6. Opt to re-equalize the project by clicking the toggle on.

7. When complete, click the Save button at the bottom of the list.

Add data sources by purpose

You can automatically add all data sources to a project that contain a Limit usage to purpose policy that matches the purpose of that project.

1. Select a Project, and click the Add Data Sources button.

2. Click Add By Purpose.

3. All data sources matching the project's purpose(s) will populate at the bottom of the dialog. Review this list, and then click Save.

Bulk add data sources to a project

1. Set your current project to be the one you want new data sources in.

2. Navigate to the Data Sources page.

3. Select the checkboxes for the data sources you want in a project.

4. Select the bulk actions more options icon in the top right corner.

5. Click Add To Current Project.

Prerequisites

Project owners can use policy adjustments to increase a data set's utility while retaining the amount of k-anonymization that upholds de-identification requirements. With this feature enabled, users can redistribute the noise across multiple columns of a data source within a project to make specific columns more useful for their analysis. Since these adjustments only occur within the project and do not change the individual data policies, data users must be acting under the project to see the adjustments in the data source.

Policy adjustment example

For example, a policy might mask these data source columns with k-anonymization: Income, Education, EmploymentStatus, Gender, and Location Code. When the analyst examines the data, the percent NULL has been predetermined by Immuta with an equal weight across all of these columns. However, if the analyst's work hinges on the EmploymentStatus column, the project owner can adjust the weights on the policy adjustment tab in the project to make the necessary data (EmploymentStatus) less NULL.

For columns that are already well-disclosed (meaning they already have a low percent null), the same percent null will display even when you drastically change the weight distribution.

Increasing the weight of a column that is already well-disclosed will not change the outcome. Generally, the biggest impact will be seen when you increase the weights of the largest percent null column. (The only exception to this is if that column already has a lot of native nulls in the remote database.)

Keep fields in the clear

This feature provides an option to allow fields in the clear when creating a purpose, permitting specified analysts to bypass k-anonymization in specific circumstances.

When any purpose with the allow fields in the clear property enabled is approved for use within a project, a project member can proceed through the policy adjustment workflow and specify columns to be unmasked.

In today’s world of modern privacy regulations, deciding what a single user can see is not just about who they are, but what they are doing. For example, the same user may not be able to see credit card information normally, but if they are doing fraud detection work, they are allowed to.

This may sound silly because it’s the same person doing the analysis, so why should we make this distinction? This gets into a larger discussion about controls. When most think about controls, we think about data controls - how do we hide enough information (hide rows, mask columns) to lower our risk. There’s a second control called contextual controls; what this amounts to is having a user agree they will only use data for a certain purpose and not step beyond that purpose. Combining contextual controls with data controls is the most effective way to reduce your overall risk.

In addition to the data controls you’ve seen, Immuta is also able to enforce contextual controls through what we term purposes. You are able to assign exceptions to policies, and those exceptions can be the purpose of the analysis in addition to who the user is (and what attributes they have). This is done through Immuta projects; projects contain data sources, have members, and are also protected by policy, but most importantly, projects can also have a purpose which can act as an exception to data policy. Projects can also be a self-service mechanism for users to access data for predetermined purposes without having to involve humans for ad hoc approvals.

Create exceptions to policies

The goal of Immuta is to modernize the management of data policies in organizations. One key aspect of modernization is to remove day-to-day human involvement in policy decision making, which is fragile and subjective. One decision process is how and when to make exceptions to policies.

This decision process could be something like: “because Morgan is analyzing employee attrition and retention, they should be able to see employee satisfaction survey data.” Notice it is not “because Morgan is HR, they should be able to see employee satisfaction survey data.” It’s not who Morgan is, but what Morgan is doing that should allow them heightened access. The purpose for data access drives the policy decision and can be approved objectively because you are not approving who can see data, but what can be done with it. However, if Morgan has to ask permission every time there is a new survey, this becomes a subjective and time-consuming process for the organization.

This is where purposes and purpose-based access control can help. Purposes allow you to define exceptions to rules as the purpose for which the user is acting. The key point here is you can define these purposes ahead of time, before any user actually tries to get an exception. Immuta projects are valuable not just for purpose-based access control, but because of the documentation trail they provide, the collaboration they allow, and the data access process they automate.

Additionally, to ensure that purposes are being used correctly and applied accurately, project purposes must be approved before the purpose is active in a project. That approver will see the lists of tables, the project members, and project documentation and decide if they want to approve it or not. This approval is recorded by Immuta, creating a documentation trail. After a purpose is approved within a project, any changes to the members or data sources will require the purpose to be re-approved, ensuring that the project continues to be compliant to an organization's requirements.

Workflow

Purpose-based access control makes access decisions based on the purpose for which a given user or tool intends to use the data, which reduces risk and aligns with many privacy regulations, such as GDPR and CCPA. This method of data access also provides flexibility for you to override policies and grant access to unmasked data to an individual for a very specific reason, without time-consuming and ad hoc manual approvals.

Immuta recommends using to create exceptions to global data policies.

See this for instructions on how to implement purpose-based access control for your organization.

Immuta projects combine users and data sources under a common purpose. Sometimes this purpose is for a single user to organize their data sources or to control an entire schema of data sources through a single projects screen; however, most often this is an Immuta purpose for which the data has been approved to be used and will restrict access to data and streamline team collaboration.

Project components

• : The users who will create, manage, and use projects.

• : Purposes allow governors to define exceptions to policies based on how a user will use the data.

• Data sources: Projects create an environment within Immuta where the user will , despite their subscription to other data sources.

• Subscription policy: Project users with the appropriate permissions can on a project to control the users who can join.

• Documentation: Project users can create documentation within the Immuta project page, allowing for an easy and consistent trail of communication.

• : Project equalization ensures that the data in the project looks identical to all members, regardless of their level of access to data.

• Workspaces: With equalization enabled, project users can create or workspaces where users can view and write data.

• : Derived data sources are the data sources that come from workspaces. Once they are created, they automatically inherit policies from their parent sources.

• : Within a project, users can join masked columns.

Members

The features and capabilities of each user differ based on the user's role within the project and within Immuta. Roles and their capabilities are outlined below.

Purposes

Data governors and users with the PROJECT_MANAGEMENT permission are responsible for configuring and approving project purposes and acknowledgement statements.

Sub-purposes

For example, if the purpose Research included Marketing, Product, and Onboarding as sub-purposes, a governor could write the following global policy:

Limit usage to purpose(s) Research for everyone on data sources tagged PHI.

This hierarchy allows you to create this as a single purpose instead of creating separate purposes, which must then each be added to policies as they evolve.

Now, any user acting under the purpose or sub-purpose of Research - whether Research.Marketing or Research.Onboarding will meet the criteria of this policy. Consequently, purpose hierarchies eliminate the need for a governor to rewrite these global policies when sub-purposes are added or removed. If new projects with new Research purposes are added, the relevant global policy will automatically be enforced.

Acknowledgement statements

Projects with purposes require owners and subscribers to acknowledge that they will only use the data for those purposes by affirming or rejecting acknowledgement statements. Each purpose has its own acknowledgement statement, and a project with multiple purposes requires users to accept more than one acknowledgement statement. Immuta keeps a record of each project member's response to the acknowledgement statement(s) and records the purpose, the time of the acknowledgement, and the text of the acknowledgement. Purposes can use Immuta's default acknowledgement statement or one customized by a data governor.

If users accept the statement, they become a project member. If they reject the acknowledgement statement, they are denied access to the project.

Project contexts

When users change project contexts, queries reflect users as acting under the purposes of that project, which may allow additional access to data if there are purpose restrictions on the data source(s). This process also allows organizations to track not just whether a specific data source is being used, but why.

Schema projects