Foundation Security: Forge-Native, Zero Egress, Cloud Fortified
Foundation is built entirely on Atlassian Forge, so your Jira data never leaves Atlassian's cloud. No external servers, no third-party data processing. Foundation inherits Atlassian's SOC 2 Type II, ISO 27001, and PCI-DSS certifications by default.
What does “Forge-native” mean for security?
“Forge-native” is a specific technical claim: Foundation's backend functions, database, key-value store, and event handlers all run inside Atlassian's own cloud infrastructure — the same platform that runs Jira itself. We do not operate application servers, databases, queues, caches, CDNs, or logging pipelines outside Atlassian. When you install Foundation, no data flows to any infrastructure we control.
That differs sharply from the older Atlassian Connect framework, which hosts the vendor's UI and business logic on the vendor's own servers — every page load and API call routes through vendor-operated infrastructure. Forge moves the entire app into Atlassian's cloud: the Forge runtime provisions serverless functions, Forge SQL provides the database, Forge KVS provides the key-value store, and Forge UI Kit plus Custom UI render the frontend inside an Atlassian-controlled iframe. The trust surface is Atlassian's, not ours.
Where does my Jira data live when I use Foundation?
Every piece of data Foundation stores — cached Jira issues, Lens configurations, hierarchy trees, column settings, user preferences, ACL entries, generator definitions — sits inside your Atlassian tenant, in the region Atlassian assigned to your Jira site, on Forge SQL and Forge KVS. It is logically and physically isolated from every other tenant's Foundation installation. There is no shared multi-tenant database, because Forge provisions a dedicated storage environment per installation.
Data leaves Atlassian's cloud only if the app explicitly requests an external.fetch Forge permission to call out to a named domain, and Foundation requests none. Our manifest's external fetch permission block is empty. You can verify this yourself by reading Foundation's manifest in the Forge admin view after install, or by asking us for the manifest pre-install.
How does Foundation differ from Connect-framework apps like Structure and BigPicture?
Structure by Tempo and BigPicture by Appfire are both built on Atlassian Connect. Under Connect, the vendor hosts an application server (AWS, GCP, or a colocation facility) that receives installation lifecycle events, serves the app's iframes to Jira users, and makes Jira API calls on the app's behalf. Jira data flows to the vendor's infrastructure on every request — it has to, because the vendor's code is running there.
Forge inverts that. Foundation's code runs inside Atlassian's cloud. When a Jira user opens a Lens, Foundation's function executes on Atlassian infrastructure, reads from Forge SQL (also on Atlassian infrastructure), and renders the result in a Custom UI iframe served by Atlassian. No byte of Jira data transits humanr.ai servers — because we have none involved in the data plane.
Practical implications for enterprise IT review: with Connect, your vendor security review has to cover the vendor's hosting, incident response, and sub-processors. With Forge, the review reduces to “does the app's manifest request reasonable scopes, and does it request external fetch?” See Foundation vs. Structure for side-by-side detail.
What certifications does Foundation inherit from Atlassian?
Because Foundation runs entirely on Atlassian's Forge platform inside Jira Cloud, it inherits the security posture of the underlying Atlassian services. That inheritance is not marketing language — it is how Forge is architected, and it's how Atlassian describes the program in its own Trust Center.
The inherited certifications and attestations include SOC 2 Type II (Atlassian's recurring audit of security, availability, processing integrity, confidentiality, and privacy), ISO 27001 / ISO 27018 (information security and cloud PII), PCI-DSS (for payment flows Atlassian handles — Foundation does not process payment data), and FedRAMP Moderate (for Atlassian Government Cloud, where applicable). See the Atlassian Trust Center for the current report list and the underlying audit opinions. Foundation's own letter of attestation maps each control onto Foundation's data-handling scope.
Is Foundation Cloud Fortified?
Foundation is pursuing Cloud Fortified certification — Atlassian's highest app-trust tier, awarded to apps that meet enhanced reliability, security, and support standards beyond the Marketplace baseline. Forge apps have a structurally easier path to Cloud Fortified than Connect apps because several requirements (data residency, zero-egress runtime, scope enforcement) are enforced at the platform layer and inherited automatically.
Cloud Fortified adds independent requirements on top of the Atlassian platform baseline: a public security program, an incident-response SLA, a published availability SLO, and time-bounded support response commitments. We are implementing each of these ahead of the Marketplace launch and plan to list with the Cloud Fortified badge. Until the audit completes, we are transparent about status — this page will be updated the day certification is granted, not before. See the Atlassian Cloud Fortified program page for the full criteria.
What permissions does Foundation request?
Foundation's Forge manifest declares a tightly scoped permission set, visible to any Jira admin in the install flow and auditable post-install. The permissions fall into three groups.
Jira scopes: read:jira-work, read:jira-user, write:jira-work — required to read issues for Lens rendering, look up user details for the assignee picker, and write back inline edits. Forge storage: storage:app — required for the issue cache, Lens metadata, and user preferences in Forge SQL and KVS. Product events: the free avi:jira:created:issue, avi:jira:updated:issue, and avi:jira:deleted:issue triggers, which keep the issue cache fresh without polling.
What Foundation does not request: external.fetch (we make zero outbound HTTP calls to external domains), admin-level Jira scopes beyond what the app needs, and no Confluence, Bitbucket, or Trello scopes at all.
How does Foundation handle data residency?
Foundation follows your Atlassian tenant's data residency configuration automatically. If your Jira Cloud site is pinned to the EU region, Foundation's Forge SQL and KVS storage for your installation lives in the EU. If your site is pinned to the US, Foundation's storage lives in the US. This is not a per-app configuration we choose — it is enforced by the Forge platform based on your Jira site's residency, which Atlassian administers.
There is no mechanism by which Foundation could store your data outside the region Atlassian has assigned to your tenant, because Foundation has no external storage and the Forge runtime respects tenant residency by default. For customers in Atlassian Government Cloud, Foundation follows the same residency constraints that apply to Jira itself. Data residency questions that apply to Jira Cloud broadly are answered on the Atlassian Trust Center; no separate vendor review is needed.
What about GDPR, HIPAA, and data subject requests?
GDPR: Foundation acts as a data processor under the GDPR for the limited Jira metadata it caches. Atlassian is the primary controller/processor for Jira Cloud itself and publishes a comprehensive GDPR resource center. Foundation's DPA aligns with Atlassian's and covers the narrow incremental data we process. Data subject requests (access, rectification, erasure) are served by deleting the subject's data from Jira itself — Foundation's cache follows via the standard avi:jira:deleted:issue event.
HIPAA: Foundation does not ship a HIPAA-specific variant. Atlassian Cloud has a HIPAA-eligible configuration under a BAA; Foundation's Forge-native architecture means that any HIPAA-eligible Jira tenant can run Foundation within the same boundary, but confirm with your Atlassian account team before processing PHI. Data subject requests: submit via Jira's standard user-deletion flow; Foundation responds automatically through the deletion event pipeline.
How Foundation's security works
Foundation's data path is short and auditable. A Jira user opens a Lens. The browser requests the Custom UI iframe from Atlassian. The iframe calls a Foundation resolver function, which executes inside Atlassian's Forge runtime. The function reads hierarchy metadata from Forge SQL, cross-checks Jira browse permissions for the current user via the Jira REST API (authenticated by Forge with a short-lived per-request token), and returns the visible rows. Nothing traverses humanr.ai infrastructure.
Writes follow the same path in reverse: a cell edit invokes a Foundation resolver, which calls Jira's REST API on behalf of the user, updates the issue cache, and fires a Forge Realtime event to other open Lens tabs. All network calls are Atlassian-to-Atlassian inside the Forge boundary. The manifest, the scopes, and the Forge platform guarantees are how we substantiate the “zero egress” claim — not a promise, an architecture. Read the full Forge security model for the platform-level detail.
Frequently asked questions
Can our security team audit Foundation?
Yes. Foundation's manifest is public inside every installation — any Jira admin can review the exact Forge scopes Foundation requests, the product events it subscribes to, and the external URLs it would be permitted to fetch (currently none). Our security documentation pack includes a scopes inventory, a data-flow diagram, a DPA template, and a pointer to Atlassian's underlying SOC 2 Type II and ISO 27001 reports, which Foundation inherits through Forge. Request the pack at [email protected] and we ship it within two business days. Because Foundation has no external servers to harden, the audit scope is narrower than a typical SaaS review.
Where's your data processing agreement?
Foundation's DPA is published on the Marketplace listing and linked from the install flow. It incorporates Atlassian's own DPA by reference for the subprocessor relationship (Atlassian hosts all Foundation data inside your tenant's region), and covers the narrow set of data Foundation processes: Jira issue metadata cached in Forge SQL, Lens configurations, user preferences, and audit logs. There are no other subprocessors — no CDN, no analytics provider, no external AI service that sees your Jira data. If your legal team needs a redlined DPA, email [email protected].
Can I restrict Foundation's scopes?
Partially. Forge scopes are declared in the app's manifest and granted at install time — you accept them as a set, not individually, which is how every Forge app works. What you can control: which users have access to Foundation (Jira admin controls the install), which projects a specific Lens covers (per-Lens configuration), and who can view or edit each Lens (Foundation's per-Lens ACL on top of Jira's own browse permission). Foundation respects Jira's permission scheme on every read and write, so a user who lacks Jira browse on a project never sees those issues in a Lens.
What happens to my data if I uninstall?
When a Jira admin uninstalls Foundation, Atlassian fires the Forge lifecycle event that instructs the app to delete installation-scoped storage — Forge SQL tables, KVS entries, cached Jira issues, Lens definitions, and user preferences. Atlassian then tears down the installation environment. Your underlying Jira issues are not affected because Foundation never owned them; it only cached copies for read performance. Within 90 days of uninstall, the Forge installation environment and all its data are fully removed per Atlassian's platform guarantees.
Do you store credentials?
No third-party credentials, ever. Foundation is a Forge app, so all Jira API calls are authenticated by Forge itself using short-lived tokens that Atlassian issues per request — Foundation doesn't see, store, or rotate them. The one exception is migration: if you're importing from Structure Cloud or BigPicture Cloud, you paste an API token from those vendors into the Import wizard. That token is used for the duration of the import job and then deleted from Forge KVS — it is never written to logs, never exfiltrated, and never retained after the job completes.
Can you provide a SOC 2 report?
Foundation itself is not SOC 2 audited separately — it inherits the SOC 2 Type II audit that Atlassian runs on the Forge platform and Jira Cloud infrastructure on which Foundation runs. We provide a letter of attestation that maps Foundation's data handling onto the Atlassian SOC 2 scope, plus Atlassian's own public SOC 2 report (available under NDA from the Atlassian Trust center). For enterprise buyers requiring an independent SOC 2 on Foundation's own code, that audit is on our 2027 roadmap contingent on install-base growth.
Related
- Foundation vs. Structure — Forge vs. Connect in detail
- Foundation vs. BigPicture
- About Foundation
- Privacy policy