Security and data handling

This document outlines the security measures and data handling practices for Portfolio insights. Portfolio insights adheres to Atlassian’s security practices and complies with major data protection regulations, including GDPR and CCPA. For more information, see Atlassian Security Practices.

We cover the following security aspects:

• Data sharing and classification

• Data used when connecting and detecting instances

• Data used for a cloud readiness assessment

• Data used for Instance health insights

• Data residency

Data sharing and classification

Portfolio Insights minimizes customer data exposure, by default focusing on configuration, usage, and technical metadata. To improve results and identification, an optional consent for user-generated content is available, however not required to be able to use Portfolio insights.

Data sharing consent: Basic and extended

When creating the connection to your Data Center instance, you will consent to what data we can collect and transfer to Portfolio insights. The consent is displayed on the Data Center side of the connection and includes two levels.

Categories of data shared

Portfolio insights collects different types of data depending on the feature in use:

Examples of data shared

The table below shows illustrative examples of how specific data types are handled under Basic and Extended data sharing:

Data used when connecting and detecting instances

We use the following data when you connect to Data Center instances or when we detect additional instances based on connections. If you’re using manual upload instead, you can check what data is used in the cloud readiness and instance health sections below.

Connecting to Data Center instances

To connect a Data Center instance, you install the Cloud Companion app, which creates a secure, outbound connection from your Data Center environment to Atlassian Cloud.

Security key generation and usage

When you link an instance, a unique security key is generated to authorize the connection:

• The key is valid for 30 days, after which you’ll need to regenerate it.

• Organization‑level audit logs are available to track connections and actions.

On the cloud side:

• The key is stored as an opaque token.

• It can’t be encoded or decoded and is only validated by security services in the cloud.

• The token does not contain any personally identifiable information (PII).

On the Data Center side:

• The key is stored at rest in your database, encrypted by default using AES/CBC/PKCS5Padding.

• The encryption key is securely stored in your product’s shared home directory.

Security key transmission

• The security key is shown only once during the linking process.

• It must be manually copied from admin.atlassian.com and pasted into the Linked Cloud Organization page in your Data Center instance.

• This manual handoff helps ensure the key isn’t exposed in logs or other system interfaces.

Connection encryption

All data transmitted between your Data Center instance and Atlassian Cloud is encrypted in transit using TLS 1.2+ with Perfect Forward Secrecy (PFS).

Detecting Data Center instances

Portfolio insights detects your Atlassian Data Center instances in two ways: through license and domain information, and through existing app link connections.

License and domain-based detection

We use Atlassian’s license and billing systems to identify Data Center instances associated with your organization and verified domains:

• Scans license data stored in Atlassian’s license management system.

• Matches license information with domains claimed in your organization.

• Identifies Data Center instances associated with those verified domains.

During this process, we don’t store any personally identifiable information (PII). When contact information is needed, it’s fetched in real time from our license and identity systems and not stored by Portfolio insights.

App links detection

We rely only on app link metadata from your existing connections, not the app links or data behind them:

• Uses existing connections to retrieve app link metadata from your instance.

• Collects only non-sensitive metadata, such as URL, product family, server ID, and version.

Data used for a cloud readiness assessment

This section describes what data we collect to create the cloud readiness assessment for your Data Center instances.

What data is collected

When assessing your instances, we collect:

• Jira entities: Depending on consent, either count and IDs (basic consent) or keys and names (extended consent) of entities such as projects, issues, and custom fields, retrieved from your database.

• Instance metadata: Metadata about your Jira instance, such as infrastructure details (for example, hardware specification, network characteristics) and identifiers like Server ID.

• App data: Depending on consent, either count and IDs (basic consent) or keys and names (extended consent) of entities coming from Marketplace or custom apps.

For more detail on the data points we collect, see Assess the scale of your Jira and Confluence instances.

Identifiable data

In the basic consent, we don’t collect any identifiable data, such as usernames or issue keys. All metrics are based on IDs. In extended consent, we may collect user-generated content (issue keys, names), but not personal identifiable information (PII).

How data is collected

When you connect your instance, we run an assessment that takes up to a few hours. In most cases, the assessment will be much faster.

How long the data is stored in cloud

Assessment data used for cloud readiness is stored for up to 2 years, after which it’s automatically deleted.

Manual upload of assessment file

If you’re unable to connect your Data Center instance, you can manually create the assessment file and upload it to Portfolio insights.

Important information:

• If your instance is not connected, the file will use the Basic consent, which includes only ID-based data, without any user-generated content. If your instance is connected, we’ll use the same level as the one in your consent.

For more info, see Collect and upload cloud readiness data manually.

Data used for Instance health insights

This section describes what data we collect for Instance health. You’ll also find details on how the data is transmitted and stored, and how it’s used to generate insights and recommendations.

Data collection

We collect:

1. Instance and node metadata: Product version, base URL, anonymized node identifiers, and Support Entitlement Number (SEN).

2. Performance metrics: JMX metrics on system performance (for example, CPU load, database connection latency, garbage collection time).

3. Guardrails: Counts of performance‑impacting entities such as projects, users, groups, custom fields, spaces, and index size.

4. Other configuration: System events (for example, app enabled or disabled), feature flag configurations, metrics related to Marketplace apps.

For a detailed view of the metrics we collect, refer to our assessment files:

• Jira instance_optimization_metrics.json

• Confluence instance_optimization_metrics.json

These files provides a structured representation of performance metrics and guardrails data.

Each metric entry includes:

• Metric name: The specific metric being tracked.

• Attributes: Key-value pairs representing the metric's data, such as performance indicator values.

• Type: The category of the metric, such as JMX_METRIC for performance metrics or GUARDRAILS for counts, APP_USAGe for apps usage information, SYSTEM_EVENT or  SYSTEM_METRIC for behavioral information

• Timestamp: The time at which the metric was recorded.

• Tags: Additional metric information necessary to provide valuable recommendations (pluginKey for public or Atlassian-owned apps for which the metric is generated).

Collection process

• The Atlassian Troubleshooting and Support Tools (ATST) app collects metrics every 2 minutes.

• Data is aggregated hourly and sent to Atlassian Cloud.

• Data is also saved in the support.zip file, which can be used for manual uploads.

• Guardrails data is also collected hourly.

Data storage

• Data is securely stored in Atlassian Cloud for 2 years, then automatically deleted.

• This retention allows for historical trend analysis and performance comparisons over time.

Data transmission and security

• All data is encrypted in transit using TLS 1.2+ with Perfect Forward Secrecy (PFS).

• A secure token authenticates data sent to Atlassian Cloud.

• We don’t transfer any PII or user-generated content automatically to Atlassian Cloud for connected instances. However, if you manually upload the support.zip file, it may include this data as described below.

Data usage

Collected data is used to:

• Calculate your Optimization score.

• Provide detailed performance insights.

• Generate actionable recommendations.

• Identify performance trends over time.

Manual upload of support.zip

If you’re unable to connect your Data Center instance, you can manually create the support.zip file and upload it to Portfolio insights. We’ll use the results from this file to show Optimization insights.

Important information:

• Before you create the support.zip, you need to update the Atlassian Troubleshooting and Support Tools (ATST) app to the latest version.

• The support.zip may contain personal information such as usernames, email addresses, and IP addresses that are recorded in the logs and diagnostic data. This it a limitation of using the support.zip and doesn’t apply when you connect your instance to Portfolio insights.

For more info, see Collect and upload Instance health data manually.

Privacy and compliance

For more information on how Atlassian accesses, uses, stores or shares data, see the Atlassian Customer Agreement and Privacy Policy.

Data residency

You can control the location of the data that we collect and use in Portfolio insights.

Change the location

To change the location of your data:

1. Go to admin.atlassian.com, and select your organization.

2. inlineExtension

3. In the top right, select … > Manage data residency.

4. Select Change location via request. You’ll be moved to a portal where you can fill out the request details, including your information and a new location.

5. Select Submit to send the request.

When submitted, the Portfolio insights team will review your request and prepare to move the data. Once we start moving the data, Portfolio insights won’t be available – this might take up to a few hours.

Additional change for manual upload of support.zip

The manual upload of support.zip file used for Optimization insights has separate controls for data residency. If you used this manual upload, you need to make an additional data residency change.

To change data residency for support.zip:

1. Go to admin.atlassian.com, and select your organization.

2. Go to Data management > Data residency.

3. Set a new location.

Data stored and the default location

By default, the Portfolio insights data is stored in the Global location.

The data we store is specific to your usage of Portfolio insights, and includes data or metadata related to the following capabilities:

• Detecting Cloud apps and Data Center instances

• Connecting to Data Center instances

• Data collected and used for Instance optimization for Data Center

• Data collected and used for Cloud readiness for Data Center

The details of what we collect are described on the page you’re viewing, please review it for more information.

Portfolio insights doesn’t include any in-scope data from any of your instances, such as content of issues or pages, or details of users.

Available locations

Each location corresponds with one or more AWS regions, which are physical locations around the world where AWS clusters its data centers. Learn more about AWS infrastructure and its role in our cloud hosting infrastructure.

By default, your data is hosted in the Global location, which includes all of our AWS regions. This means that we might move data between AWS regions if needed for performance or other reasons.