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

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.

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.

Data sharing level

詳細

Basic (technical metadata)

Designed to avoid transferring user-generated content and PII. Data sent to Atlassian Cloud consists of technical and operational metadata (for example, IDs and counts). Examples shown on the consent screen include:

  • Infrastructure configuration (e.g. CPU, memory, database metadata)

  • System configuration (e.g. Server ID, SEN, app links)

  • Metadata for projects or spaces, users, and apps (entity IDs only)

Extended (user-generated content)

Allows a limited set of additional fields that can be considered user-generated content to be transferred when this is needed to make insights more precise or easier to interpret. In addition to Basic data, Extended may include:

  • Selected entity keys or names (for example, project keys, space names, or app names) so that risky or important entities can be identified in reports

  • Other configuration items that users create or name, where this materially improves clarity of the insights

Categories of data shared

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

カテゴリー

Contains PII?

Contains user‑generated content?

Primary purpose

インスタンスのメタデータ

Base URLs, product type, license identifiers, version info

いいえ

いいえ

Connect to and detect other Data Center instances

Configuration and usage metadata

Counts of projects, issues, workflows, custom fields

いいえ

No (basic)

Yes (extended)

Cloud readiness assessment and instance health insights

Marketplace apps, custom apps, integrations

Marketplace app identifiers, versions, enabled/disabled state

いいえ

No (basic)

Yes (extended)

Cloud readiness assessment and instance health insights

Operational and performance metrics

JVM metrics, indexing stats, database timings, request metrics

いいえ

いいえ

Instance health scoring and performance insights

Browser and client‑side metrics

Aggregate response times, error rates, RFU‑related timings

いいえ

いいえ

Client and network performance insights

Security configuration metrics

Pass/fail results for security checks, counts of inactive accounts, app update status

いいえ

いいえ

Security insights and recommendations

Examples of data shared

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

データ タイプ

Basic (基本)

Extended

ベース URL

<https://my-jira.com>

<https://my-jira.com>

License SEN number

SEN-10502355

SEN-10502355

Product type and version

Jira Software Data Center, 10.1

Jira Software Data Center, 10.1

Project or issue identifiers

Internal IDs such as 10001, 10002

Keys such as PROJ, ISSUE-1

カスタム フィールド

Technical ID such as customfield_10002

Field name such as Completion date

objectSchema

Internal ID such as 101

Schema name such as Software assets

ユーザ名

Technical identifier such as jirauser_10001

Same; user display names and email addresses are not transferred in automated flows

Confluence space or page identifiers

Internal IDs such as 10001, 10002

Names such as Jira administration space, Get started with Jira

Marketplace アプリ

For publicly available apps: app key, version, and name

Same; app key, version, and name

Custom app

Hashed identifier (for example, 3ecc5748…65d5)

Human‑readable name such as Custom CI integration


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.

セキュリティ キーの生成と使用

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.

セキュリティ キーの送信

  • 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.

接続の暗号化

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.

ライセンスおよびドメインベースの検出

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.

  • ライセンス情報を、組織で申請されているドメインと照合します。

  • 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.

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.

収集されるデータ

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.

特定可能なデータ

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).

データの収集方法

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.

データ収集

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.

  5. Security metrics: Pass or fail results for security checks that evaluate instance configuration against security best practices (for example, whether SSO is enabled, admin accounts are active, or file permissions are correctly set). These are binary outcomes with optional aggregate counts, such as the number of inactive accounts. No PII or user-generated content is included.

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

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

各メトリック エントリには以下が含まれます。

  • メトリック名: 追跡対象の特定のメトリック。

  • 属性: パフォーマンス指標の値など、メトリックのデータを表すキーと値のペア。

  • 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

  • タイムスタンプ: メトリックが記録された日時。

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

収集プロセス

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

  • データは 1 時間ごとに集計され、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 is securely stored in Atlassian Cloud for 2 years, then automatically deleted.

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

データ転送とセキュリティ

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

  • セキュアなトークンが、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.

データの使用

収集されたデータは次の目的で使用されます。

  • Calculate your Optimization score.

  • 詳細なパフォーマンス インサイトを提供する。

  • 実用的な推奨事項を生成する。

  • 時間の経過に伴うパフォーマンス トレンドを特定する。

  • Evaluate your instance's security posture.

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.

プライバシーとコンプライアンス

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


データ レジデンシー

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 health 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.

 場所

AWS リージョン

Not set (Global)

AWS リージョンにあるアトラシアンの全クラウド製品

オーストラリア

オーストラリア (シドニー) リージョンで構成

カナダ

カナダ (中部) リージョンで構成

EU

ヨーロッパ (フランクフルト) およびヨーロッパ (ダブリン) リージョンで構成

ドイツ

ヨーロッパ (フランクフルト) リージョンで構成

インド

アジア太平洋 (ムンバイ) リージョンで構成

日本

アジア太平洋 (東京) リージョンで構成

スイス

ヨーロッパ (チューリッヒ) リージョンで構成

シンガポール

アジア太平洋 (シンガポール) リージョンで構成

韓国

アジア太平洋 (ソウル) リージョンで構成

イギリス

ヨーロッパ (ロンドン) リージョンで構成

米国

米国東部 (北バージニア) および米国西部 (北カリフォルニア) リージョンで構成

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.

さらにヘルプが必要ですか?

アトラシアン コミュニティをご利用ください。