Security Whitepaper — Vendor Assessment for Procurement Teams

1. Executive Summary

Compliance Glossary for Confluence is a terminology governance application built on Atlassian Forge — Atlassian’s serverless app platform. In production v6, code execution, customer-data storage, and processing occur within Forge, with no DailyMind-operated app server or database. The only external egress is an optional GitHub connector that calls https://api.github.com; it is off until an administrator enables it with a customer-provided GitHub App installation. Because of this egress, v6 is not eligible for Runs on Atlassian. AI-assisted curation (since v5.0) uses Atlassian-hosted Forge LLM, starts only when an administrator selects findings, and creates drafts only; see the AI-assisted curation documentation and the privacy policy. (Scope note: this marketing site, hosted on Cloudflare Pages, uses self-hosted, cookieless analytics — Umami and GoatCounter on vigilcom.dev — and no third-party trackers. The Forge app itself does not load these.)

The vendor is DailyMind LTD (Registration: HE 439959), registered in Cyprus (European Union). DailyMind publishes the application on the Atlassian Marketplace and provides support, but does not host, process, or have access to customer data at rest.

This whitepaper documents the application’s architecture, data handling practices, security controls, and compliance framework alignment to support vendor risk assessments, procurement due diligence, and third-party security reviews.

2. Architecture Overview

The application runs within the Atlassian Forge platform; the optional GitHub connector is its only external egress. The following diagram shows the data flow and isolation boundaries:

Key Architecture Properties

• Sandboxed execution — each installation runs in its own isolated Forge sandbox. No installation can access another’s code or data.
• No vendor infrastructure — DailyMind does not operate servers, databases, CDNs, or any external infrastructure for this application.
• Permission-scoped — the Forge runtime restricts the application to declared permissions only (read-only Confluence scopes, app storage, Atlassian-hosted Forge LLM, personal-data reporting, and backend fetch to https://api.github.com).
• Stateless compute — Forge functions are stateless. No in-memory state persists between invocations.

3. Data Residency

Core records are stored in Forge KVS (Entity Store); enterprise evidence uses Forge SQL and Forge Object Store. Storage location is set by Atlassian’s Forge hosting, not by DailyMind. Production v6 does not claim Atlassian Marketplace data residency support.

• Storage location — Atlassian Forge hosted storage. DailyMind does not select or verify the storage region for each installation.
• Vendor access — DailyMind has no access to customer data at rest. There is no admin console, no analytics pipeline, no telemetry that exposes customer data to the vendor.
• Data deletion on uninstall — all per-installation data in the Forge Entity Store is automatically deleted by Atlassian per Atlassian’s published Forge data lifecycle and Standard Data Retention and Disposal policy (see Atlassian Forge data lifecycle). This aligns with the Data Processing Agreement. For Forge SQL and Object Store records, see the privacy policy.
• Cross-border transfers — when an administrator enables the GitHub connector, the application sends configured repository requests to GitHub (https://api.github.com). Otherwise the application initiates no transfers outside the Atlassian platform.

4. Authentication & Access Control

The application delegates all authentication to the Atlassian platform and enforces role-based access control with a mandatory four-eyes approval workflow.

• Forge authentication — the application authenticates using api.asApp() for system operations and api.asUser() for user-context operations, both provided by the Forge platform. No personal access tokens or passwords are used or stored. If an administrator enables the GitHub connector, its GitHub App private key and webhook secret are kept in Forge Secure Storage; short-lived installation tokens stay in invocation memory.
• No credential storage — the application does not store any user credentials. Authentication is fully delegated to Atlassian’s identity provider.
• Role-based access — administrative actions (managing glossary terms, configuring settings, managing access control lists) are restricted to users with appropriate Confluence permissions or app-level admin roles.
• Four-eyes approval workflow — glossary terms go through a review and approval workflow. A term cannot be approved by the same person who submitted it for review. This is enforced server-side — it cannot be bypassed through the UI. This supports segregation-of-duties control activities commonly required for SOX §404 Internal Control over Financial Reporting (ICFR) assessments under COSO 2013, and supports ISO 27001:2022 Annex A control 5.3.

5. Data Processing Inventory

The following table documents all data categories, whether they are stored, their purpose, and retention period:

6. Sub-Processors

Production v6 uses Atlassian as its sub-processor for app data, including Atlassian-hosted Forge LLM. GitHub is involved only when an administrator enables the connector with the customer’s own GitHub App. No analytics providers, CDNs, or DailyMind-operated infrastructure process app data.

No other sub-processors are used by production v6. It does not integrate with analytics platforms, error tracking services, or content delivery networks for app data. Data flows for GitHub and Forge LLM are described in the privacy policy (§3.4–3.5) and our Data Processing Agreement.

Marketing-website processors (Cloudflare, Inc., Anthropic PBC, Resend, Inc.) are documented in privacy.html; they do not process App data within Atlassian Forge.

7. Encryption

All encryption is managed by the Atlassian platform. The application does not implement its own cryptographic operations.

• At rest — all data in the Forge Entity Store is encrypted at rest using AES-256. Encryption key management is handled entirely by Atlassian’s infrastructure. The application vendor has no access to encryption keys.
• In transit — all communication between the application and the Atlassian platform uses TLS 1.2 or higher. All user-facing interactions are served over HTTPS by the Atlassian platform.
• No vendor-managed keys — the application does not generate, store, or manage any cryptographic keys. All key management is delegated to Atlassian.

8. Incident Response

DailyMind maintains a structured incident response process for security events affecting the application:

1. Detection — security incidents are detected through Atlassian platform monitoring, automated testing, user reports, or vulnerability disclosures to [email protected].
2. Assessment — initial triage and impact assessment within 4 hours of detection. Classification of severity (critical, high, medium, low) and identification of affected installations.
3. Containment — immediate containment actions including, where applicable: emergency patch deployment, feature disablement, or coordinated response with Atlassian’s security team.
4. Notification — affected customer (the controller) notified without undue delay per GDPR Article 33(2), and in any case within 72 hours where feasible, to enable the controller to meet its own Article 33(1) notification deadline. Notification includes: description of the incident, data categories affected, likely consequences, and remediation measures taken.
5. Post-incident review — root cause analysis, remediation verification, process improvement recommendations, and post-incident summary published to affected customers.

Security contact: [email protected]

Vulnerability disclosure: we acknowledge reports within 3 business days and provide an initial assessment within 10 business days. We do not take legal action against researchers who report vulnerabilities in good faith.

For incidents related to the underlying Atlassian Forge platform or infrastructure, Atlassian’s own incident response process applies.

9. Business Continuity

The application’s business continuity posture is strengthened by its dependency on Atlassian’s infrastructure rather than vendor-operated systems.

Source Code & Development

• Source code maintained in a private git repository with automated backups.
• CI/CD pipeline with automated testing (77 tests) and linting before every deployment.
• No single point of failure in the development or deployment process.

Data & Storage

• Forge Entity Store is managed by Atlassian with their own business continuity and disaster recovery (BC/DR) controls.
• Atlassian maintains SOC 2, ISO 27001, and other certifications covering their infrastructure availability. Details at Atlassian’s Trust Center.

Vendor Continuity

• If DailyMind ceases operations: customer data persists on Atlassian infrastructure. The application continues to function as installed. Customers can uninstall at any time, and all data is deleted per Atlassian’s published Forge data lifecycle and Standard Data Retention and Disposal policy (see Atlassian Forge data lifecycle).
• No vendor-hosted infrastructure means no vendor-dependent availability risk. The application’s availability is determined by Atlassian’s platform SLA, not by the vendor’s operational status.

10. Vulnerability Management

The application follows a multi-layered vulnerability management approach combining Atlassian’s platform security with application-level controls.

11. Compliance Framework Mapping

The following table maps application capabilities to specific requirements across regulatory and industry frameworks:

12. Vendor Information

Ready to Proceed?

This whitepaper covers the security and compliance posture of Compliance Glossary for Confluence. For additional questions, contact [email protected].