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 the current Marketplace release, the manifest contains no external:fetch:backend permission: code execution, customer-data storage, and processing occur within Forge, with no DailyMind-operated external app server or database. Planned AI-assisted curation is not enabled in that release. Its exact data flow, processor/retention terms, and Marketplace/privacy disclosures must be approved and published before it is released; see the planned AI-assisted curation documentation. (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 entirely within the Atlassian Forge platform. 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 Confluence pages, write to Entity Store, manage UI modules).
• Stateless compute — Forge functions are stateless. No in-memory state persists between invocations.

3. Data Residency

All application data is stored in the Forge Entity Store, which resides in the customer’s Atlassian cloud region. Data residency is determined by the customer’s Atlassian instance configuration — not by the application vendor.

• Storage location — customer’s Atlassian cloud region (as configured by the customer’s Atlassian administrator).
• 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.
• Cross-border transfers — no customer data leaves the Atlassian platform. There are no cross-border data transfers initiated by the application.

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, passwords, API keys, or shared secrets are used or stored.
• 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 satisfies 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

The current Marketplace release uses a single sub-processor. It has no additional third-party services, analytics providers, CDNs, or external infrastructure involved in processing app data. Planned AI-assisted curation is not enabled in that release; its processor/data-flow assessment and disclosures are a pre-release gate.

No other sub-processors are used by the current Marketplace release. It does not integrate with external APIs, analytics platforms, error tracking services, or content delivery networks for app data. AI-assisted curation is not enabled in that release; affected customers will receive the required disclosures before any approved release, consistent with 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 security@teamkit.dev.
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: security@teamkit.dev

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 security@teamkit.dev.