Security Overview

Architecture at a Glance

Collabound has three parts, and it matters where each one runs:

• The Jira app — the Issue Panel and in-Jira pages. Built on Atlassian Forge and executed on Atlassian's infrastructure, inside the Forge sandbox. It reads and updates Jira issues using scoped permissions and calls the Collabound service over TLS.
• The Collabound service and database — the API that enforces workspace, role, and field-level access rules, and the MySQL database behind it. Hosted on Amazon Web Services (AWS) in the United States, operated by Collabound.
• The Collabound Portal — the web application at app.collabound.com that partners and administrators use. Served over HTTPS and talks only to the Collabound service.

The service stores list-level metadata for shared work items (key, summary, status, type, project, sharing state). Descriptions, comments, attachments, and other detail fields are fetched from Jira on demand when an authorized user opens a work item; see Data Storage and Retrieval below.

Authentication & Authorization

Collabound uses industry-standard authentication and authorization mechanisms to protect access to the platform:

• Email and password login — The Collabound Portal uses account registration, email activation, password login, password reset, and account lockout controls for Portal users.
• JWT and rotating refresh tokens — After authentication, Portal sessions are managed using short-lived JSON Web Tokens (JWT) and rotating refresh tokens. Token reuse detection and explicit revocation help protect active sessions.
• Forge app assertions — Communication between the Collabound app in Jira and the Collabound service is authenticated with Forge Invocation Tokens and Collabound app assertion JWTs. Site binding additionally requires a short-lived bind code generated from the Portal.
• Role-Based Access Control (RBAC) — All user actions are governed by workspace-level roles with scoped permissions. Roles determine what a user can view, share, configure, and administer. Permissions are enforced at the API level, ensuring consistent access control regardless of the client interface.

Data in Transit

All communications between Collabound components are encrypted in transit:

• All API calls between the Collabound app in Jira and the Collabound service are transmitted over HTTPS with TLS encryption.
• All requests between the Collabound Portal (web browser) and the Collabound service use HTTPS/TLS.
• Internal service-to-service communication within the Collabound infrastructure is encrypted using TLS.
• Modern TLS versions and cipher suites are enforced. Connections using outdated or insecure protocols are rejected.

Data at Rest

Data stored by Collabound is protected using encryption at rest:

• Database encryption — Collabound uses a MySQL database with encryption at rest enabled. All data stored by Collabound, including shared work item list metadata, workspace details, and user information, is encrypted on disk.
• AWS infrastructure — Collabound is hosted on Amazon Web Services (AWS), leveraging AWS-managed encryption services for storage volumes and database instances.
• Backup encryption — Database backups are also encrypted, ensuring that data remains protected throughout its lifecycle.

Data Storage and Retrieval

Collabound limits stored Jira work item data to the information needed to display shared work item lists, enforce access controls, and support auditability. This includes list-level fields such as issue key, summary, status, issue type name and icon, project name and icon, and sharing state.

Detailed issue content needed for the work item detail page, such as description, attachments, comments, and other non-list fields, is retrieved from Jira in real time through authorized API calls when an authorized user opens the detail view. Collabound does not need to persist a full copy of every Jira issue detail field in order to provide the shared work item detail experience.

Access Control

Collabound enforces strict access control boundaries to prevent unauthorized data access:

• Workspace-level isolation — Each workspace's data is logically isolated. Users can only access data belonging to their own workspace and data explicitly shared with them through active collaborations.
• Role-Based Access Control (RBAC) — Users are assigned roles within their workspace, and each role carries a specific set of permissions. Permissions are scoped to actions such as viewing work items, sharing issues, managing collaborations, configuring templates, and administering the workspace.
• Field-level access control — Shared Content Access Templates provide fine-grained control over which Jira issue fields are visible to partners. Administrators can select exactly which fields (summary, description, status, priority, custom fields, comments, and more) are included in shared content.
• Sharing Permission Templates — Sharing Permission Templates define the rules governing who can initiate shares, with which workspaces, and under what conditions. These templates ensure that sharing is intentional and controlled.

Audit Logging

Collabound maintains a comprehensive audit trail of all security-relevant events to support accountability and compliance:

• Share and revoke actions — Every share and revoke operation is logged, including the user who performed the action, the affected work item, the target workspace, and the timestamp.
• Authentication events — Login attempts, token issuance, and session events are recorded.
• Workspace changes — Modifications to workspace settings, site bindings, collaboration status changes, and template updates are tracked.
• User management — User invitations, role assignments, and account changes are logged.

Audit logs are accessible to workspace administrators through the Collabound Portal, providing full visibility into activity within your workspace.

Atlassian Security

The Collabound Jira integration is built as a Forge app, which provides additional security guarantees from the Atlassian platform:

• Forge runtime — The Jira-side app (Issue Panel and in-Jira pages) runs on Atlassian's managed Forge infrastructure, inside Atlassian's sandboxed environment. It calls the Collabound service on AWS over TLS; no part of the Forge app itself runs on Collabound servers. See Architecture at a Glance for what runs where.
• Atlassian security guidelines — The app is developed in accordance with Atlassian's security requirements for Forge apps, including secure data handling and privacy best practices.
• Scoped permissions — The Forge app requests only the permissions it needs to function. These include read:jira-work and write:jira-work for reading and updating Jira issues, and other scoped permissions required for the Issue Panel and the in-Jira Collabound pages.
• Marketplace review — The app is distributed through the Atlassian Marketplace and undergoes Atlassian's security review process before publication.

Data Retention

Collabound follows clear data retention practices to minimize data exposure:

• Active shares — Shared work item list metadata is retained in the Collabound system while the share is active. List-level data is kept synchronized with the source Jira issue through update events, while detail-page fields are retrieved from Jira when needed.
• Revoked shares — When a share is revoked, the partner immediately loses access to the shared work item. Collabound retains the necessary revocation metadata and history for auditability.
• Collaboration termination — If a collaboration between two workspaces is disconnected, the collaboration is marked as disconnected and associated partner access is removed or revoked so the partner can no longer access shared work through that collaboration.
• Account and workspace deletion — Upon request, access to account or workspace data can be removed and relevant records can be marked for deletion, subject to legal, security, backup, audit, and operational retention requirements. Data that is no longer required will be removed according to applicable retention and purge processes. Contact support to initiate a data deletion request.

Subprocessors

Collabound uses a small number of service providers to operate the Services. Jira work item content is processed only by Atlassian and AWS in the course of normal product use.

• Amazon Web Services (AWS) — hosting, database, storage, logging, and security services, United States.
• Amazon Simple Email Service (AWS SES) — transactional email such as share notifications, invitations, and account messages.
• Atlassian — Jira Cloud, Forge, and Atlassian Marketplace, under Atlassian's own terms.
• Bitbucket Pipelines — build, security scanning, and deployment automation. Does not process Jira content.
• Google Analytics — optional, consent-based measurement of www.collabound.com only. Never receives Jira content, account data, or Portal activity.

The current list is maintained in the Privacy Policy. A Data Processing Addendum (DPA) with standard contractual protections is available on request at support@collabound.com.

Compliance Status

We would rather tell you exactly where we stand than imply more than we have:

• Atlassian Marketplace security review — The Collabound Forge app passed Atlassian's Marketplace security review before publication, and changes to its scopes or permissions go through Atlassian review again.
• Infrastructure certifications — The Collabound service runs on AWS, which maintains SOC 1/2/3, ISO 27001, and related attestations for the underlying infrastructure.
• ISO/IEC 27001 — Shinetech Software Inc., the company that builds and operates Collabound, is ISO/IEC 27001 certified. Collabound is developed and operated under that information security management system. A copy of the certificate is available on request.
• SOC 2 — Collabound does not currently hold a SOC 2 report. We complete customer security questionnaires and are happy to walk your security team through the architecture and controls described on this page.
• Data residency — Service data is stored in the United States. Region-specific hosting is not currently offered; contact us if this is a requirement for your organization.

Vulnerability Disclosure

If you believe you have found a security vulnerability in Collabound, please report it to support@collabound.com with steps to reproduce. We aim to acknowledge reports within two business days and to keep you informed while we investigate and fix confirmed issues. Please give us a reasonable opportunity to remediate before public disclosure, and do not access or modify data that does not belong to you.

Contact

For security questions, questionnaires, DPA requests, or general assistance, contact us at support@collabound.com.