Last updated Jun 5, 2025

Forge and SOC 2 compliance

In partnership with Vanta, Atlassian conducted an analysis to determine how we can make it easier for developers to meet SOC 2 requirements. Our Forge platform is SOC 2 certified, and apps built on the Forge developer platform can benefit from inheriting controls to meet 30% of SOC 2 requirements. These controls can help you achieve compliance across the following domains:

Vulnerability management
- Ensuring the Forge platform infrastructure is hardened and providing a secure runtime for apps that prevents bypassing security controls (SOC 2 - CC 6.6)
- Scanning for security misconfiguration vulnerabilities (SOC 2 - CC 7.1)
Access control
- Ensuring that access to the underlying Forge system components and related storage is restricted to authorized users (SOC 2 - CC 6.1 - 6.3)
- Configuring strict password policy and authentication configurations for access to the underlying Forge system components and related storage (SOC 2 - CC 6.1 - 6.3)
Physical security
- Utilizing cloud service providers with strict physical protections, access, and redundancy configurations to provide the Forge system (SOC 2 - CC 6.4, CC 6.5)
Network security
- Using TLS 1.2 or higher to encrypt data in transit (SOC 2 - CC 6.7)
- Configuring network configurations for Forge system components to only allow authorized network connections (SOC 2 - CC 6.6)
Monitoring & Alerting
- Proactively monitor the health of the platform raising alerts in response to degraded performance, security, or abuse events (SOC 2 - CC 7.2, A 1.1)
Data security & availability
- Using AES-256 to encrypt data at rest for data stored within Forge app storage (SOC 2 - CC 6.1)
- Ensuring data stored by Atlassian on behalf of your app (in Forge data storage) is backed up, and can be restored in an incident (SOC 2 - CC 5.3, A 1.1)

SOC 2 control inheritance only applies to data that resides within the Forge boundary.

It is important to note that you should consider the Forge platform as a defined boundary. While data resides within this boundary, it inherits the controls specified above. However, once any data exits this boundary, the inheritance of those controls ceases for that data, and you become responsible for establishing your own controls for the data that has left the boundary.

An example

If you build an app that uses Forge's runtime, hosted storage and has no data egress, you can rely on the SOC 2 control inheritance outlined above.

Let’s say you now update your app to make a call to a third-party API. The SOC 2 control inheritance ends for any data that leaves the Forge platform boundary and is sent to the third-party API. You now become responsible for implementing SOC 2 controls for the data that has left the boundary.

The control domains above are only a subset of the requirements for SOC 2 compliance. Many of the other requirements are based on operations and process needs that are outside the scope of the Forge platform.

Additionally, some control domains include shared responsibilities—for example, while Forge manages the data stored on behalf of your Forge applications, Marketplace Partners are responsible for backing up the code they deploy for the Forge application itself.

Please review the Shared responsibility model for a full list of detailed responsibilities that Marketplace Partners and Atlassian share when using the Forge platform.

Read more about SOC 2 compliance: SOC 2® - SOC for Service Organizations: Trust Services Criteria