What is a Policy?
A Policy is a set of instructions (or "Rules") that are executed when a user submits a request to retrieve or delete their data (the user makes a "Privacy Request"). Each Rule contains an "execution strategy":
action_type: The action this Rule performs, either
access(retrieve data) or
storage_destination: If the
access, this is the key of a
StorageConfigobject that defines where the data is uploaded. Currently, Amazon S3 buckets and local filesystem storage are supported. See Configuring Storage for more information.
masking_strategy: If the
erasure, this is the key of a Masking object that defines how the erasure is implemented. See Configuring Masking Strategies for a list of available strategies.
In addition to specifying an execution strategy, a Rule contains one or more Data Categories, or "Targets", to which the rule applies. Putting it all together, we have:
1 2 3
This is reflected in the API paths that create these elements:
Each operation takes an array of objects, so you can create more than one at a time.
A note about
The PATCH requests perform the equivalent of a
create_or_update operation. This means that any existing objects sent to this endpoint will:
- be updated,
- any non-existing objects will be created, AND
- any objects existing that are not specified in the request will not be deleted
Create a Policy
Let's say you want to make a Policy that contains rules about a user's email address. You would start by first creating a Policy object:
1 2 3 4 5 6 7
||User-friendly name for your Policy.|
||Unique key by which to reference the Policy.|
||Optional. A Data Rights Protocol action to associate to this policy.|
||A data subject access request. Should be used with an
||A data subject erasure request. Should be used with an
Add an Access Rule to a Policy
The policy creation operation returns a Policy key, which we'll use to add a Rule:
1 2 3 4 5 6 7 8
storage_key must identify an existing StorageConfig object.
Finally, we use the Rule key to add a Target:
1 2 3 4 5 6 7
Rule.action_type: Which action is this
access: A data subject access request. A user would like to access their own data from within the fidesops identity graph. Fidesops must look these fields up and return it to them. Fidesops will return these to a
erasure: A data subject erasure request (also known in some legislation as the Right to be Forgotten). A user would like to erase their own data currently stored in the fidesops identity graph. Fidesops must look these fields up and either erase them entirely, or apply a
Rule.storage_destination: Where fidesops will upload the returned data for an
accessaction. Currently, Amazon S3 buckets and local filesystem storage are supported.
Rule.masking_strategy: How to erase data in the Identity Graph that applies to this
Rule. See Configuring Masking Strategies for a full list of supported strategies and their respective configurations.
Add an Erasure Rule to a Policy
The simple access policy we've created above, will simply pull all data of category
user.contact.email, but in the event of an erasure request, we might also want to mask this information.
1 2 3 4 5 6 7 8 9 10 11 12 13
1 2 3 4 5
user_email_address_polcy, will now do the following:
- Return all data inside the Identity Graph with a data category that matches (or is nested under)
- Mask all data inside the Identity Graph with a data category that matches
user.contact.email with a the
SHA-512 hashing function.
When a Policy Rule erases data, it erases the entire branch given by the Target. For example, if we created an
erasure rule with a Target of
user.contact, all of the information within the
contact node -- including
user.contact.email -- would be erased.
It's illegal to erase the same data twice within a Policy, so you should take care when you add Targets to a Rule. For example, you can't add
And lastly, access rules will always run before erasure rules.
Fidesops ships with two default Policies:
download (for access requests) and
delete (for erasure requests).
download Policy is configured to retrieve
user data and upload to a local storage location.
delete Policy is set up to mask
user data with the string:
These auto-generated Policies are intended for use in a test environment. In production deployments, you should configure separate Policies with proper storage destinations that target and process the appropriate fields.