SFJ: Security Hub — Powered by Forge

Smart Forms for Jira now runs primarily on the Atlassian Forge platform, ensuring that core processing, storage, and interaction with Jira occur inside Atlassian’s secure, isolated infrastructure. This strengthens data protection, compliance alignment, and operational reliability.

To support external form sharing and embedding — capabilities not possible inside Forge-only apps — Smart Forms uses a minimal, controlled egress layer designed specifically for rendering public-facing forms. This remote layer renders public-facing form UIs and performs anti-abuse and routing logic (CAPTCHA, rate limiting, submission intake). It does not persist Jira issue content or form responses — those are stored in Forge Storage inside Atlassian (see Where Your Data Lives below).

Forge is Atlassian’s managed platform that provides isolated, secure execution environments for cloud apps.

What are the Benefits for You?

Here’s what this migration means in practice:

✅ Better Security
Forge apps run inside Atlassian’s infrastructure. It means your form definitions and responses are stored and processed inside Atlassian’s environment, which protects your core data and makes it less vulnerable to threats.

✅ Faster and More Reliable
Forge apps load faster and perform better. You’ll notice smoother app behavior and less waiting time.

✅ Clearer Permissions
With Forge, you can quickly check the data the app has access to. This means more transparency and control for you.

✅ More Features Coming Soon
Thanks to Forge, we can introduce and release new features to our customers even faster. With this migration complete, we can bring in more advanced filters, new reports, and custom settings you have requested.

The main features and design of the app will be the same as before. However, using Forge, you can see faster loading times and a more stable and secure experience.

How Forge Improves Security

By operating inside Atlassian’s environment, Smart Forms benefits from:

• Isolated execution in Atlassian-managed sandboxes

• Platform-enforced permissions and OAuth scopes

• Secure secrets management

• Encrypted data storage fully controlled by Atlassian

• Automatic security updates and compliance handling

All sensitive operations (work item creation, field updates, storing responses, form logic) run exclusively within Forge.

Why a Controlled Egress Layer Is Required

Some Smart Forms features rely on public access or external participation, including:

• External sharing links with anonymus submissions

• Embedded forms on websites or Confluence

• External embedded content inside form builder

To support them securely:

• The remote layer renders the public form UI and validates submissions (CAPTCHA, rate limiting).

• It does not persist Jira issue content or form responses — these are stored in Forge Storage.

• Submissions are received by the remote backend over TLS, validated, then written into Atlassian infrastructure (Forge Storage / Jira) for mapping and storage.

• Form response data persists only inside Atlassian (Forge Storage). The remote backend stores operational metadata only — tokens, recipient identifiers, tenant configuration — in a self-hosted MongoDB database on AWS (not an Atlas-managed cluster).

Data Residency & Compliance

• All form definitions, responses, and work item updates are stored within Atlassian’s regional data systems (Forge Storage / Jira).

• External rendering, submission intake, and email notifications are handled by a remote backend and a small set of sub-processors outside Atlassian (see the table below); stored customer form data is not relocated out of Atlassian.

Where Your Data Lives — Sub-processors & Data Storage

Smart Forms stores and processes the large majority of customer data inside Atlassian (Forge Storage and Jira). To deliver public form sharing, embedding, anti-abuse protection, and email notifications, a limited set of sub-processors operate outside Atlassian. The table below lists every party that processes Smart Forms data and what it handles.

Smart Forms uses analytics solely to understand which features are used and how often. Events are tied only to the name of the specific functionality being used (e.g. "form created", "external form opened") and, for segmentation, to the Atlassian site name (a tenant/organization identifier). They do not include any personal data of end users — no user identity, no Jira account IDs, no email addresses — and never include form definitions or form response content. The data cannot be used to identify an individual person or to reconstruct any customer form data.

How this relates to the SaaSJet Privacy Policy

The SaaSJet Privacy Policy applies company-wide. For Smart Forms specifically: core form data and responses are stored inside Atlassian (Forge Storage), while public form rendering, submission intake, notification email, and a small set of operational metadata are handled by the sub-processors above — consistent with the AWS (N. Virginia / Oregon) hosting and the third-party email and analytics processors named in that policy.

Data Retention

Forge Storage (core form data & responses). Data stored in Forge Storage follows Atlassian's Forge hosted-storage data lifecycle without modification. Retention, soft-deletion after uninstall, and disposal are handled entirely by Atlassian under that policy.

Operational metadata (remote backend). The operational metadata held by the SaaSJet remote backend — share/edit tokens, form/issue references, notification-recipient Jira account IDs, and per-tenant web-trigger URLs & configuration — mirrors the same lifecycle rules: it is retained for 28 days after uninstall and then permanently disposed of. Recovery of this data is possible only via a support request to Atlassian, and that request must include support@saasjet.atlassian.net so SaaSJet can authorize and perform the restore. Restore requests are accepted only during the first 21 days; the remaining 7 days are reserved for SaaSJet to process the request before permanent disposal.

Certifications

	Cloud Fortified The Cloud Fortified Apps Program aims to serve our largest customers and those with more business-critical operating requirements for apps. How it works - Cloud Fortified Apps: Stay Safe with SaaSJet What Atlassian Developer says - read more

	Marketplace Security Bug Bounty Program A bug bounty program is one of the most powerful post-production tools to help detect vulnerabilities in applications and services. What Atlassian Developer says - read more

	Security Assessments The term “security assessment” refers to any activity intended to determine, evaluate, or test the security features and controls of Atlassian’s products and services. What Atlassian Help says - read more

	SaaSJet is a Platinum Marketplace Partner What does “Platinum partner” mean? According to annual gross sales ("Purchase Price" in Marketplace reports), a minimum $1M annual gross sales comprised a minimum of 35% from the cloud. How we became a Premium partner - our history of success What Atlassian Developer says - read more

Security

	System and Organization Controls - SOC 2 SOC 2 reports are independent third-party examination reports demonstrating how an organization achieves key compliance controls and objectives. What Atlassian says about Trust Service Criteria (TSC) - read more SaaSJet is SOC 2 Type 2 compliant - read more

	CAIQ-Lite CAIQ Lite is a simplified version of the Consensus Assessments Initiative Questionnaire (CAIQ), which is designed to assess the security posture of cloud service providers. Atlassian requires all Platinum, Gold, and Silver Marketplace Partners to complete the CAIQ-Lite questionnaire, which it then reviews. What Atlassian says about the security of the cloud ecosystem - read more

	Security Contact If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please contact us at security@saasjet.com

Support

	Working hours: Mon-Fri 24hrs GMT+3 Phone: +1 888 396 0501 Book a demo session: click to schedule an online free demo Support portal: click to create a ticket Help: Read the documentation

We understand that data security is of utmost importance to our users. The information below outlines the types of data stored by Smart Forms for Jira, associated security measures, and storage periods, addressing your data privacy concerns.

Changes to Policy

Any significant changes that occur in our data security and retention practices will be communicated on our website.

Read about the SaaSJet Privacy Policy ->

Additional Security Features

CAPTCHA Protection Smart Forms for Jira includes built-in CAPTCHA verification for publicly shared forms, providing protection against:

• Automated bot submissions

• Spam form entries

• Malicious form abuse

Implementation: CAPTCHA verification is available for forms shared with "Anyone with the link" access, ensuring your public-facing forms maintain security without compromising accessibility.

Best Practice: Enable CAPTCHA for customer-facing forms, public surveys, and any forms embedded on external websites to maintain data integrity and prevent abuse.

Architecture & Data Flow

The diagrams below describe how Smart Forms is structured and how data moves through it. They complement the data-handling and sub-processor details above.

System Architecture

The architecture groups every component into four boundaries: the Atlassian Cloud Trust Boundary (Jira Cloud, the Forge frontend, Forge Functions, Forge Storage, and Jira entity properties); the Forge Platform Gateway (bridge routing, Web Trigger ingress, and install/upgrade lifecycle events); the Remote Backend Boundary on AWS (an Express server on AWS App Runner with a self-hosted MongoDB database); and a Third-Party Boundary (Mailgun for email). The defining characteristic is the bidirectional, HMAC-signed HTTPS link between Forge and the remote backend.

Operational Data Flow — external share-form submission

This sequence traces a single external share-form submission end to end. The user submits the public form; the remote Express backend validates CAPTCHA and rate limits, then orchestrates the Atlassian-side work over HMAC-signed Web Trigger callbacks — reading the form definition, creating the Jira issue, writing issue-forms metadata, persisting the submission record in Forge Storage, and resolving recipient email addresses. The notification email is sent via Mailgun concurrently with persistence, and the backend returns a JSON response to the form UI.