GDPR, Data Residency, Logging: Best Practices for Data Protection and Compliance in Forge Apps

Atlassian Forge is a secure way to develop extensions for Jira, Confluence, and similar products. The platform handles many tasks that previously required tedious manual effort—from hosting and function isolation to clearly defined permissions. However, even though Forge automatically fulfills many standards, it does not relieve app vendors and companies of their own data protection responsibilities.

Especially the GDPR (General Data Protection Regulation), Data Residency requirements, and responsible logging play a central role. This article shows what really matters in practice and how your team can develop Forge apps that are not only technically first-rate but also audit-proof.

Why Data Protection is Particularly Relevant for Forge

Forge brings a unique characteristic: App code runs in an isolated runtime environment (sandbox) and only has access to systems that have been explicitly approved. For apps using only Forge Hosted Storage, all data remains within the Atlassian ecosystem. Apps that use Forge Remote or external fetch calls can send data to declared external domains. Nevertheless, the app often processes personal data: Jira issue content, Confluence comments, user names, and metadata.

This automatically brings the GDPR into focus: Who sees the data, where is it stored, who can access it, and how long may it be retained?

Data Protection Starts with the Question: Which Data Does the App Truly Need?

The first step towards GDPR-compliant Forge apps is relatively simple: data minimization. Many apps fetch unnecessarily large amounts of information from Jira or Confluence, often purely for convenience or because it seems technically easier.

The better way is a very deliberate approach to data. Before implementing a function, the following questions should be answered:

Which data does the app actually need?
Does this data need to be stored, or is temporary processing at runtime sufficient?
Can the scope of functionality be designed to require less personal information?

This approach not only makes the app more privacy-friendly but also streamlines the architecture and reduces potential attack surfaces.

Transparency Creates Trust and is Mandatory

A Forge app almost always works with personal data. Therefore, companies and users expect it to be clearly recognizable what data is processed and for what purpose.

A comprehensible and easily accessible privacy policy helps to create the necessary transparency. It should specifically and clearly address these questions:

What data does the app access?
What is this data used for?
Where is it stored?
How long is it retained?
What rights do users have?

Such a policy should be available both in the Marketplace listing and in the app documentation. Transparency helps reduce inquiries and can speed up approval processes with customers.

Data Residency: Why the Storage Location is Crucial

For many European companies, data retention within the EU is not just a wish but a firm prerequisite. Atlassian supports Data Residency for Forge apps.

However, it is important to understand that not every Forge component automatically runs in the region desired by the customer. App teams should therefore carefully check the following points:

Does the app itself work completely Data Residency compliant?
Which data components (storage, caches, temporary files, logs) are located in which region?
Are external services involved that are hosted outside the EU?

A common misconception is the assumption that the customer’s Data Residency setting automatically transfers to all data of the installed apps. This is not always the case. Openness about the actual storage locations of all components creates clarity and avoids later conflicts.

Logging: Helpful for Development Teams, Risky for Personal Data

Logs are an often-underestimated part of the data protection strategy. In practice, logs often contain more personal information than the development team is aware of. And this is precisely where compliance risks quickly arise.

Privacy-friendly logging consistently avoids personal content. Instead of logging comment texts, issue titles, or email addresses, technical indications such as IDs, status codes, or generic error messages are sufficient in many scenarios. A good practice is to strictly separate logging: technical information goes into the log, but no content from Jira or Confluence and no user identities, unless strictly necessary.

The duration of log retention is also important. Forge retains developer console logs for 30 days; this is not configurable. If your team needs logs beyond that window, they must be exported and stored externally, for example via the App Logs Export API. Either way, keeping logs lean and free of personal data reduces compliance risk.

Logs should help solve problems in case of an error but not become a data protection risk.

Defining Documentation and Responsibilities Clearly

A Forge app is legally considered data processing. This means that the responsibilities between Atlassian and the app vendor must be clearly described. Customers want to understand what data Atlassian stores, what data the app vendor processes, and what role the app vendor plays in the GDPR model. According to the Forge DPA, the typical chain is: Customer (controller) → App vendor (controller or processor) → Atlassian (processor/sub-processor).

Many data protection inquiries arise precisely when these delineations are unclear. Clean, understandable documentation provides a remedy and often even accelerates internal security audits on the customer side.

The Deletion Concept: Obligations for Uninstallation and Data Subject Rights

Last but not least: A central pillar of the GDPR is the “Right to Erasure”, also known as the “right to be forgotten.” For app vendors, this means that a clear and documented deletion concept must exist.

Upon Uninstallation: When a customer uninstalls the app, the app team must ensure that all stored personal data that is no longer required for the provision of the service is deleted. Note: Forge currently provides lifecycle events for installation and upgrade, but not for uninstallation. A preUninstall module has been proposed but is not yet generally available. For apps using Forge Remote or external storage, teams should plan an alternative cleanup strategy (e.g., periodic reconciliation) until an uninstall event is available.
Data Subject Rights: The deletion concept must also regulate how requests from individual users exercising their right to erasure or rectification are handled.

The transparent description of this process – who deletes what data and when – creates not only compliance but also trust among enterprise customers who value a controlled approach to their data.

Data Protection is Not an Obstacle, but a Quality Feature

Forge already provides a strong security foundation and relieves development teams of many tasks. But not all of them. Those who take data protection seriously create apps that are reliable, trustworthy, and successful in the long run. Teams that additionally pursue the principles of the GDPR, the enterprise requirements for data retention, and conscious logging elevate the quality of their apps.

Experience shows: Enterprise customers, in particular, are more likely to choose apps whose data protection is transparent and traceable. And for development teams, this means: Data protection is not bureaucratic ballast but a competitive advantage.

Is your team planning a move to Forge? Do you want to modernize your app strategy? Our experienced Atlassian development teams can support you with architecture, development, and certification. And we can get you unstuck if you’ve started the vibe-coding journey on Forge.