# Configure DSR Request Policies

## What is DSR request policy? [Permalink for this section](/content/docs/privacy-requests/reference/request-policies#what-is-dsr-request-policy/index.html)

A DSR request policy (separate from a [CI Policy](/content/docs/cli-reference/check/index.html), used for automated policy checks in CI) is a set of instructions, or Rules, that are executed when a user submits a [request](/content/docs/privacy-requests/index.html) to retrieve or delete their data. It describes how to access, mask, or erase data that matches specific data categories in submitted privacy requests.

Each endpoint takes an array of objects to create multiple policies, rules, or targets at one time.

💡

`PATCH` requests perform the equivalent of a `create_or_update` operation. This means that any existing objects sent to this endpoint will be updated, create any non-existing objects, and delete any objects that are not specified in the request.

## Create a Policy [Permalink for this section](/content/docs/privacy-requests/reference/request-policies#create-a-policy/index.html)

To create a new DSR request policy, it must first be defined:

PATCH /api/v1/policy

```
[\
  {\
    "name": "User Email Address",\
    "key": "user_email_address_policy",\
    "drp_action": "access", // optional\
    "execution_timeframe": 7\
  }\
]
```

### Policy attributes [Permalink for this section](/content/docs/privacy-requests/reference/request-policies#policy-attributes/index.html)

| Attribute | Description |
| --- | --- |
| `name` | User-friendly name for your Policy. |
| `key` | Unique key by which to reference the Policy. |
| `drp_action` | _Optional._ A [Data Rights Protocol](/content/docs/privacy-requests/concepts/data-rights-protocol/index.html) action to associate to this policy. Accepted values are `access` (must be used with an [access Rule](/content/docs/privacy-requests/reference/request-policies#add-a-rule/index.html)) or `deletion` (must be used with an [erasure Rule](/content/docs/privacy-requests/reference/request-policies#add-an-erasure-rule/index.html)). |
| `execution_timeframe` | The time in which to fulfill an associated privacy request, in days. |

## Add a Rule [Permalink for this section](/content/docs/privacy-requests/reference/request-policies#add-a-rule/index.html)

The policy creation operation returns a DSR request policy key. This key can be used to add a Rule to the DSR request policy. Rules represent a series of information and actions to take when a privacy request of the corresponding `action_type` is submitted.

The following is an example of an access Rule:

PATCH /api/v1/policy/{policy_key}/rule

```
[\
  {\
    "name": "Access User Email Address",\
    "key": "access_user_email_address_rule",\
    "action_type": "access",\
    "storage_destination_key": "storage_key"\
  }\
]
```

### Rule attributes [Permalink for this section](/content/docs/privacy-requests/reference/request-policies#rule-attributes/index.html)

| Attribute | Description |
| --- | --- |
| `name` | A user-friendly name for the rule. |
| `action_type` | Which action is this `Rule` handling? |
| `action_type.access` | A data subject access request. Matching data will be returned. |
| `action_type.erasure` | A data subject erasure request (or Right to be Forgotten). Matching data will be erased or [masked](/content/docs/privacy-requests/guides/masking-strategies/index.html). |
| `storage_destination` | Where Fides will upload the returned data for an `access` action. See [storage](/content/docs/privacy-requests/guides/storage-destinations/index.html). |
| `masking_strategy` | How to erase data that applies to this `Rule`. See [Configuring Masking Strategies](/content/docs/privacy-requests/guides/masking-strategies/index.html) |

💡

The `storage_key` must identify an existing storage object. Read about [configuring storage](/content/docs/privacy-requests/guides/storage-destinations/index.html) here.

### Add a Rule Target [Permalink for this section](/content/docs/privacy-requests/reference/request-policies#add-a-rule-target/index.html)

A Rule also specifies one or more [Data Categories (opens in a new tab)](https://ethyca.github.io/fideslang/taxonomy/data_categories/), or "Targets", to which the rule applies. Creating a Rule will return a key, which can be used to assign it one or more targets:

PATCH /api/v1/policy/{policy_key}/rule/{rule_key}/target

```
[\
  {\
    "name": "Access User Email Address Target",\
    "key": "access_user_email_address_target",\
    "data_category": "user.contact.email",\
  }\
]
```

| Attribute | Description |
| --- | --- |
| `name` | A user-friendly name for the target. |
| `key` | A unique key to identify the target. |
| `data_category` | The data categories to which the associated rule applies. For example, email addresses under `user.contact.email`. |

### Add an erasure Rule [Permalink for this section](/content/docs/privacy-requests/reference/request-policies#add-an-erasure-rule/index.html)

💡

Access rules will always run before erasure rules.

The access DSR request policy created above will pull all data of category `user.contact.email`. In the event of an erasure request, we might also want to mask this information.

A new `erasure` rule can be added to the same DSR request policy:

PATCH /api/v1/policy/{policy_key}/rule

```
[\
  {\
    "name": "Mask Provided Emails",\
    "key": "mask_provided_emails",\
    "action_type": "erasure",\
    "masking_strategy": {\
      "strategy": "hash",\
      "configuration": {\
        "algorithm": "SHA-512"\
      },\
    },\
  }\
]
```

This will create a Rule to hash an unspecified value with a SHA-512 hash. To add a value to hash, create a new Target for this Rule:

PATCH /api/v1/policy/{policy_key}/rule/{rule_key}

```
  [\
    {\
      "data_category": "user.contact.email",\
    },\
  ]
```

This DSR request policy, `user_email_address_policy`, will now do the following:

- Return all data with a data category that matches (or is nested under) `user.contact`.
- Mask all data with data category that matches `user.contact.email` with a the `SHA-512` hashing function.

#### Erasing data [Permalink for this section](/content/docs/privacy-requests/reference/request-policies#erasing-data/index.html)

When a DSR request policy Rule erases data, it erases the _entire_ branch given by the Target. For example, a `user.contact` Rule, will erase _all_ of the information within the `contact` node, including `user.contact.email`.

It's illegal to erase the same data twice within a DSR request policy. For example, erasing `user.contact` _and_`user.contact.email` is not allowed.

## Default DSR request policies [Permalink for this section](/content/docs/privacy-requests/reference/request-policies#default-dsr-request-policies/index.html)

💡

These auto-generated DSR request policies are intended for use in a test environment. In production deployments, configure separate DSR request policies and storage destinations that target and process the appropriate fields.

Fides ships with two default DSR request policies: `download` (for access requests) and `delete` (for erasure requests).

- The `download` DSR request policy is configured to retrieve `user` data and upload to a local storage location.
- The `delete` DSR request policy is set up to mask `user` data with the string "MASKED".