Security

Our apps are Forge apps. We have tried to be specific rather than reassuring.

This page explains what that means in practice across our Atlassian Marketplace apps: where your data lives, what each app accesses, how responsibilities are split, and what the apps deliberately do not do.

Architecture

Where your data lives

01

Runs entirely on Forge

No third-party servers, no external databases, no processors in the runtime path. When you deploy a schema, API calls go from the Forge runtime directly to your Jira Cloud instance's Assets API. Nothing leaves the Atlassian Cloud boundary.

02

Tenancy isolation

Each Forge invocation runs in a per-tenant context enforced by Atlassian's platform. LaunchPad cannot read, write, or enumerate data from any tenant other than the one invoking it. Your data residency inherits your Jira Cloud region.

03

Additive only

Deployment creates new schemas, object types, and attributes in your Assets workspace. LaunchPad does not modify existing schemas, cannot delete data it did not create, and never retains copies outside the Forge runtime's execution context.

Permissions

What each app accesses

Every app we publish uses Forge's scoped permission model. At install time, the Atlassian admin reviews and approves the exact scopes the app requests. A normal Jira user can only perform actions their existing Jira permissions already allow; the apps do not elevate privileges. The exact scopes differ per app.

LaunchPad

Requests
  • Read and write access to Assets object schemas, object types, reference types, and attributes
  • Read access to Jira projects, to populate and validate schema selections
  • App user context, used to attribute deployment actions to LaunchPad in your audit trail
Does not request
  • Access to user email addresses or personal profile data
  • Access to issue content, comments, or attachments
  • Access to Confluence content, calendars, or any other Atlassian product surface
  • Access to external systems outside your Jira Cloud tenant

Second Chance

Requests
  • Read access to the summary and description of the request being viewed, to extract keywords
  • Read access to the knowledge base articles the viewing user is already entitled to see, to match and rank suggestions
  • Read access to Jira user context, plus the ability to set a per-project readiness flag that controls where the panel appears
  • App storage within your own tenant, for per-project settings, a 24-hour coverage cache, feedback events, and sampled metrics
Does not request
  • Access to ticket comments, attachments, or any request field other than summary and description
  • Access to user email addresses or personal profile data for profiling
  • Access to any external (non-Atlassian) service, large language model, or AI API
  • Access to systems outside your Jira Cloud tenant
Data handling

Data handling in detail

Data processed
LaunchPad: JSM Assets schema definitions (object type names, attribute configurations, reference types, and optional sample data for seeding). Second Chance: the summary and description of the request being viewed (read transiently to extract keywords, not stored) plus the knowledge base articles the viewing user is entitled to see.
Data residency
All processing occurs within Atlassian Forge infrastructure, hosted on AWS regions used by Atlassian. The apps do not transfer customer operational data outside the Forge platform.
Data portability
LaunchPad: schemas and data it creates remain in the customer's JSM Assets instance after uninstall and are not locked into the app. Second Chance: it creates no Jira data; all app storage (settings, coverage cache, feedback events, metrics) is purged from Forge storage on uninstall.
Storage encryption
Forge Storage is encrypted at rest with AES 256 and in transit with TLS 1.2 or later, managed by the Atlassian platform.
Privacy by design
The apps minimise data collection, process only the limited data required to operate, respect tenant boundaries enforced by Forge, and default to the most privacy-preserving configuration.
External calls
The only external endpoint the apps communicate with is api.atlassian.com for Atlassian API operations. No third-party services, large language models, or AI APIs. The apps never request Atlassian user passwords, API tokens, or personal credentials. Authentication is handled entirely through Atlassian Forge app authentication.
Logging & metrics
Application logs do not contain request or knowledge base content. Operational logs and stored records may include technical identifiers such as Atlassian Account ID strictly for audit and debugging. Lightweight, sampled operational metrics are stored in Forge storage in the customer's own tenant, never transmitted externally, and removed on uninstall.
Shared responsibility

Shared responsibility model

Following the CSA Shared Security Responsibility Model (SSRM). This is who owns what, specifically.

Infrastructure and data centre
Atlassian
Physical security, network, compute, OS hardening, time synchronisation
Encryption & key management
Atlassian
AES-256 at rest, TLS 1.2+ in transit, key lifecycle management
Authentication & SSO
Atlassian
User authentication, SSO integration, session management
Backup & disaster recovery
Atlassian
Platform-level backups, availability SLAs, failover
Permission scoping
Shared
Atlassian enforces Forge scopes; app declares minimum required permissions
API security
Shared
Forge authentication framework plus app-level permission scoping and input validation
Logging & monitoring
Shared
Forge platform logging plus app-level structured logging for operations audit
Data minimisation
Shared
Platform level encryption plus app level data minimisation and privacy by design
Application security (SDLC)
LT.Solutions
Secure development lifecycle, code reviews, automated testing, deployment via Forge CLI
Dependency management
LT.Solutions
npm audit, Dependabot/Snyk scanning, SBOM via package-lock.json
Change management
LT.Solutions
Git version control, pull-request reviews, CI/CD pipeline, Forge deployment controls
Incident response
LT.Solutions
Defined procedures, Jira tracking, breach notification within 72 hours
Governance and compliance
LT.Solutions
Policy reviews, regulatory mapping, GDPR & UK DPA 2018 compliance
Compliance posture

Compliance posture.

Our compliance story splits cleanly into two layers. We prefer to be specific about what we do rather than gesture at certification badges.

Atlassian layer: inherited

The Forge runtime inherits Atlassian Cloud's attestations. These cover infrastructure, encryption, tenancy isolation, data residency, availability, and incident response at the platform level.

  • SOC 2 Type II
  • ISO 27001
  • ISO 27018 (cloud-specific privacy)
  • PCI DSS attestation (where relevant)
  • CSA STAR certification
Vendor layer: our responsibility

Our apps do not hold their own SOC 2 or ISO 27001 attestation. Let's Talk Solutions is a small vendor and we have not undertaken that certification effort; doing so would materially increase the price and benefit very few customers. What we control at the application layer is documented on this page and in the security and Forge architecture doc.

Framework-by-framework.

SOC 2 Type II
Inherited from Atlassian at the runtime layer. We do not hold our own report. Auditors have accepted this pattern for other Forge apps.
ISO 27001
Inherited from Atlassian at the runtime layer. Same position as SOC 2.
DORA (EU ICT risk)
Your DORA posture depends on how Atlassian is classified in your ICT third party register. Our apps should be assessed as part of your fourth party inventory. We can provide a supporting attestation letter.
GDPR & UK DPA 2018
Each app processes only limited data: LaunchPad the data you load into Assets, Second Chance the request summary, description, and knowledge base content within your tenant, plus support correspondence and billing metadata. Data-subject rights requests for content held in Jira go to your Jira admin; for support and billing, contact us.
HIPAA
Atlassian offers HIPAA-eligible Cloud tenancies. We do not sign Business Associate Agreements directly. If your HIPAA posture is via Atlassian's BAA, the apps sit inside the same controls. If you require a separate BAA from us, contact before deploying.
Vulnerability and incident response

Vulnerability and incident response.

Targets, not contractual guarantees. Customers on a paid support plan have targets defined in their agreement, which take precedence.

Dependency triage: CVSS

Dependencies are scanned with npm audit, Dependabot, and Snyk. Triage and remediation are handled by severity:

Critical
24 hours
High
72 hours
Medium
2 weeks
Low
Next release
Incident response: reported issues

From the moment a security issue lands at security@lt.solutions.

Acknowledgement
1 business day
Triage & severity
2 business days
Critical fix target
5 business days
Non-critical fix
Next scheduled release
CSA CAIQ (LaunchPad + Second Chance)

CSA CAIQ self-assessment.

Cloud Security Alliance CAIQ v4.1 completed in full and now covering both LaunchPad and Second Chance. 283 controls, zero “No”s. Take the PDF straight into a pre-sales review. Both apps run on the same Forge-native architecture and inherit the same Atlassian platform controls described above.

185
Controls answered Yes
98
Not applicable (CSP-managed)
0
Controls answered No
17
Security domains covered

Domain coverage

Application & Interface Security13 Yes
Audit & Assurance5 Yes : 3 NA
Business Continuity Mgmt6 Yes : 13 NA
Change Control & Configuration12 Yes
Cryptography & Key Mgmt4 Yes : 19 NA
Data Security & Privacy19 Yes : 5 NA
Datacenter Security28 NA
Governance, Risk & Compliance10 Yes
Human Resources7 Yes : 13 NA
Identity & Access Mgmt19 Yes
Infrastructure Security8 Yes : 7 NA
Interoperability & Portability8 Yes
Logging & Monitoring12 Yes : 7 NA
Security Incident Mgmt16 Yes
Supply Chain Mgmt19 Yes
Threat & Vulnerability Mgmt14 Yes : 1 NA
Universal Endpoint Mgmt13 Yes : 2 NA
Download the CAIQ assessmentCSA CAIQ v4.1.0 : 283 controls : June 2026
What our apps do not do

What our apps do not do.

Clear scope boundaries for procurement and security review.

  • Our apps do not call any external (non-Atlassian) service at runtime, and use no large language model or AI API.
  • Our apps do not store your operational data outside the Forge runtime.
  • Our apps do not share your data with third parties for marketing, analytics, or any other purpose.
  • Our apps do not train machine-learning models on your data.
  • Our apps do not currently hold their own SOC 2 or ISO 27001 attestation. They inherit Atlassian's runtime controls and document their own application controls on this page.
  • Our apps do not provide on-premises or data residency locked deployments outside what Atlassian Cloud offers.
Data protection

Data protection roles.

Data controller
The customer organisation that installs the app. The controller determines the purposes and means of processing data within its Jira instance.
Data processor
Atlassian, as the operator of the Forge platform and Jira Service Management infrastructure on which the app executes.
Sub-processor
Each app operates as a sub-processor under Atlassian's data-processing framework. It processes data only within Atlassian-managed infrastructure and solely for the purposes initiated by the customer.
Security contact

Security contact

Vulnerability reports, procurement questions about the CAIQ, and anything else security-shaped go to security@lt.solutions. Data-protection and privacy enquiries go to privacy@lt.solutions or see the privacy policy.

For the full architecture and procurement-reviewer FAQ, read the security & Forge architecture document.

Last reviewed : June 2026

Start with a scan.

Install LaunchPad from the Atlassian Marketplace, and the read-only scan is the first thing it runs, or book a walkthrough with LTS first. Either way you see what it finds before you change anything.

Get LaunchPad on the MarketplaceBook a walkthrough
Available on Atlassian Marketplace·Built on Atlassian Forge·No customer data export by LaunchPad.