Understand how to build an information protection policy

Who can do this?
Role: Organization admin, Guard Detect admin
Atlassian Cloud: Atlassian Guard Premium
Atlassian Government Cloud: Available

Information protection policies give you a rules-based way to detect sensitive data in Jira and Confluence, so you can take action automatically or manually.

This empowers you to delegate certain policies to run from detection to redaction autonomously, once you’re confident the matches found meet your requirements.

Every policy is configured to suit a specific criteria with a certain focus. This means many policies can run in parallel without the risk of diluting audit logs or confusing the chosen action.

What is an information protection policy?


Understand how a policy is set up

When you set up a policy, you’ll need to:

  • Choose your scope.

  • Set your conditions.

  • Decide how to respond.

These are the core components of a policy. Even though the scope, conditions, and the way you control a policy may differ, they will always contain these core steps.

Once these aspects of your policy are set up, you’ll have the choice to save the policy as a draft, in a monitored state, or activate. Switch states at any time.

Choose your scope

The first decision to make when setting up an information protection policy is where you’d like it to apply. Your options are:

  • Your whole organization. This will include all sites and apps associated with your organization.

  • Specific sites only. This will include all apps set up for your chosen site.

  • Certain apps, like Jira or Confluence.

You can also choose if there are certain locations where the policy does not apply, and add those locations as an exclusion.

Set your conditions

This is the criteria you’d want your policy to detect.

First, choose how the condition operates, then what’s being detected. What can be detected is predefined to include common, sensitive information like credit card numbers, IP addresses, and passwords. The detections are also categorized into related groups, so you can choose to look for any financial, credential, or identity related data, for example. The detections list is ever evolving.

To make this step precise, you can set a count and confidence criteria. Say the minimum count was set to 3 and the confidence level High. This means the condition is only met if the detection is made three or more times, with high confidence.

If you want to get a little more nuanced, you can add multiple conditions to one policy. This works with AND/OR logic. You can also choose to add a conditions group, which allows you to add multiple findings under one condition. Again, this works with an AND/OR logic, where the first set of conditions will be assessed against any proceeding conditions or condition groups.

For example, you could create a condition that detects credit card AND IBAN numbers, or credit card OR IBAN numbers. This creates a safety net to ensure what your policy is looking for has a higher chance of being detected.

Which fields are scanned?

Information security policies scan text fields across a variety of content objects. They do not currently scan attachments.

View the full list of detections

Decide how to respond

This is when you determine what happens if a policy finds a match. There are two options:

  • Create a violation for an admin to review.

  • Automatically redact the information, without review.

Create a violation for review

If a policy finds a match (the conditions are met), a violation is created for review and resolution.

Best for when you’re just starting out, unsure of the best configuration, or must adhere to particular governance practices that require human review.

Read about how to review and resolve policy violations

Automatically redact matching information

If a policy finds a match (the conditions are met), the sensitive information is automatically redacted, without review, though it will be available in the audit log.

Best for highly sensitive information that doesn’t require human review and policies that have been monitored and proven consistently effective.

Keep in mind automatic redaction removes content without admin review, and can only be restored through the Guard Detect API within 30 days.

After 30 days, the original content is permanently deleted and can't be recovered. Test the policy in monitoring mode before activating automatic redaction.

Get to know how automatic redaction works

Still need help?

The Atlassian Community is here for you.