# Atlassian Security Review
# Classification: Confidential
# Date: 2026-06-09
# Reviewer: Claude Code (drafted); pending Founder approval
# Status: Draft

---

## 1. Vendor / Device Overview

| Field | Value |
|---|---|
| **Name** | Atlassian (Atlassian Pty Ltd / Atlassian, Inc.) |
| **Website** | atlassian.com · trust center: customertrust.atlassian.com |
| **Service / purpose** | Jira Software (issue tracking), Jira Service Management (JSM customer support intake), Confluence (knowledge base) — Atlassian Cloud |
| **CBB use case** | All product development tracking (DOPE/CBB/ESUP projects), company-ops issues, customer support intake, engineering knowledge base (Confluence SCOPE space) |
| **Data tier(s) accessed** | Tier 2–3 — issue contents may reference confidential infrastructure/IP work; **never SPEC/engine internals/DOPE-Blend** (CLAUDE.md prohibits) |
| **Access type** | Atlassian MCP (API token) + admin account; no end-user federation yet |
| **Proposed onboarding date** | Already in production — retrospective review |

---

## 2. Data Exposure Assessment

### 2.1 What CBB data will this vendor / device access?

- Jira issue contents (bugs, features, infrastructure tasks) across DOPE, CBB, ESUP projects
- Confluence KB articles (SCOPE space — customer-facing support content)
- JSM support tickets submitted by customers (may contain customer-provided contact details)
- Repository custom-field mappings (which repos an issue touches)

**Explicitly excluded by policy (CLAUDE.md):** SPEC material, engine internals, DOPE-Blend methodology, and Tier-4 trade secrets are never placed in Jira/Confluence.

### 2.2 Where will CBB data be stored by this vendor?

On Atlassian Cloud infrastructure. Data-residency options exist; reviewer to confirm CBB's tenant region. Encrypted in transit and at rest per Atlassian's security model.

### 2.3 Is any Highly Confidential data (Tier 4) involved?

- [ ] Yes
- [x] **No** — by standing policy, SPEC/engine/DOPE-Blend content never enters Atlassian. Issues reference work without reproducing trade-secret detail.

> **Standing control:** This Tier-4 exclusion is a policy boundary, enforced by author discipline. It is the single most important control for this vendor — a slip would place trade-secret material on a third-party SaaS.

---

## 3. Vendor Security Posture (Software vendors only)

### 3.1 Compliance and certifications

| Standard | Certified? | Notes |
|---|---|---|
| SOC 2 Type II | Yes | Atlassian Cloud SOC 2 Type II; FY26 report (review period Oct 2024–Sep 2025) issuing late-2025 with bridge letters early 2026 |
| ISO 27001 | Yes | ISO/IEC 27001 certified; also ISO 27018 |
| GDPR compliant | Yes | GDPR-compliant DPA available on request; data-subject-rights tooling |
| CCPA compliant | Yes | Addressed in Atlassian privacy program |

> Reviewer to pull the current FY26 SOC 2 Type II report / bridge letter from customertrust.atlassian.com at approval.

### 3.2 Data processing agreement

- [x] A GDPR-compliant DPA is available via Atlassian's request process
- [ ] Not available

> **Condition:** Request and retain Atlassian's GDPR DPA for the CBB tenant.

### 3.3 Breach history

No publicly disclosed material breach of Atlassian Cloud customer data in the past 3 years known at drafting (a 2022 third-party app/"envelope" incident affected some support data, not core cloud tenant data). Reviewer to re-check at approval.

### 3.4 Security documentation

- [x] Trust Center published (customertrust.atlassian.com)
- [x] SOC 2 / ISO reports available under NDA
- [x] Responsible disclosure / bug bounty (Bugcrowd) program

### 3.5 Authentication and access control

- [x] MFA supported (enforce on admin account) — in-tier
- [—] SSO / SAML federation with Entra ID — **deferred (tier-gated, §7)** — requires Atlassian Guard (paid), above the current **Free** plan
- [x] API token scoping — in-tier
- [x] OAuth with defined scopes (MCP integration) — in-tier

---

## 4. Hardware Security Assessment

**N/A** — software/SaaS vendor.

---

## 5. Integration Security

### 5.1 Credential management

- Access is controlled via `admin@coldboreballisticsllc.com`.
- **No Atlassian API credentials are stored in Azure Key Vault** — access is via the Atlassian MCP (API token) and the admin account; the admin password + API token live in the CBB credential store (`OneDrive/CBB_Corporate/03_-_Confidential/`).
- [ ] **Gap:** Atlassian API token is not in Key Vault (unlike Twilio/SendGrid/Namecheap). Consider migrating the API token into `kv-cbb-shared-prod` for consistency with the single-source-of-truth secret model.
- [x] MFA enforced on the admin account *(reviewer to confirm)*.

> **Known constraint (tier-gated, §7):** on the **Free** plan the custom permission scheme cannot be assigned to projects — default Jira permissions apply (all authenticated users broad access). The scheme is staged and activates cleanly on a paid-tier upgrade. At headcount = 1 this is not material today.

### 5.2 Network exposure

Cloud SaaS; no inbound firewall rule or public IP on CBB infrastructure. GitHub-for-Jira integration connects outbound. JSM portal is internet-facing by design (customer intake).

### 5.3 Offboarding plan

Revoke the API token, remove the MCP connection, deactivate or transfer the admin account. Export Jira/Confluence data before offboarding. Workspace transfers via admin console role change.

---

## 6. Risk Summary

Risks are assessed **at the current tier (Atlassian Free)**. Controls requiring a paid tier (custom-permission-scheme assignment, Atlassian Guard SSO, audit log, data residency) are **not** open conditions — they are recorded in §7 (Deferred). Note the in-tier items (Tier-4 exclusion discipline, API-token handling) are credential/process choices, **not** tier-gated, and remain live conditions.

| Risk | Likelihood | Impact | Mitigation (in-tier) |
|---|---|---|---|
| Trade-secret (Tier-4) content accidentally placed in Jira/Confluence | L | H | Standing policy prohibition; author discipline; periodic content audit (in-tier, load-bearing) |
| API token leakage (not in Key Vault) | L | M | Migrate token to Key Vault; rotate; MFA on admin account (in-tier — actionable now) |
| Broad default permissions (Free plan) | M | L | Pre-1.0 single-user; **scheme assignment is tier-gated — deferred, §7**; not material at headcount = 1 |
| Vendor breach of issue/KB data | L | M | SOC 2/ISO vendor; no Tier-4 data present; Tier-2/3 only |

**Overall risk rating:** **Low–Medium** — the Tier-4 exclusion discipline is the load-bearing control and is fully in-tier. The Free-plan permission breadth is a deferred (accepted) tier item, immaterial at single-user headcount.

**Recommendation:** **Approve with conditions** — pending Founder sign-off.

**Conditions (in-tier — actionable now):**
1. Confirm current FY26 SOC 2 Type II / bridge letter at approval.
2. Request and retain the GDPR DPA for the CBB tenant.
3. Confirm MFA enforced on `admin@`.
4. Decision: migrate the Atlassian API token into `kv-cbb-shared-prod` (recommended) or document the exception. *(In-tier — not plan-dependent.)*
5. Add Atlassian to the "CBB Risk Register" SharePoint List (note the deferred items from §7).

---

## 7. Deferred — Pending Tier Move

The following require a **paid Atlassian tier above the current Free plan** and are **deliberately deferred** until CBB moves to that tier. Documented for acquisition visibility; **not** open conditions at the current tier.

| Deferred control | Requires | Why it's wanted | Trigger to activate |
|---|---|---|---|
| **Custom permission scheme assignment** | Standard (or higher) | Replaces broad default permissions with least-privilege project access; scheme already staged | First paid-tier upgrade (or first external collaborator) |
| **Atlassian Guard — SAML SSO / SCIM / enforced 2SV** | Atlassian Guard (paid add-on) | Centralized identity + enforced auth policy | First external hire |
| **Audit log (admin activity)** | Standard/Premium | Tamper-evident record of admin actions for due diligence | First paid-tier upgrade |
| **Data residency controls** | Premium | Pin Jira/Confluence data to a region | If an acquirer/compliance requires it |

> Each item, when triggered, requires its own **cost-impact analysis + Founder approval** before the plan upgrade (CLAUDE.md). Known per existing project notes: the Free-plan API also blocks JSM portal-group automation (manual UI workaround) — same deferral class.

---

## Document Control

| Field | Value |
|---|---|
| **Document owner** | `jschwefel@coldboreballisticsllc.com` |
| **Classification** | Confidential (`03_-_Confidential/`) |
| **Location** | `OneDrive/CBB_Corporate/03_-_Confidential/Infrastructure/Atlassian/Atlassian_Security_Review.md` |
| **Cross-references** | `Atlassian_Architecture_Reference.md`; `Atlassian_Acquisition_Brief.md`; "CBB Risk Register" SharePoint List |
| **Created** | 2026-06-09 |
| **Last updated** | 2026-06-09 |
| **Next full review due** | 2027-06-09 |

---

## Revision Control Block

| Rev | Date | Changed By | Reviewed By | Approved By | Summary |
|-----|------|------------|-------------|-------------|---------|
| DRAFT | 2026-06-09 | Claude Code | — | — | Initial draft. Posture verified against Atlassian Trust Center (SOC 2 Type II FY26 in issuance, ISO 27001/27018, GDPR DPA). Flags API-token-not-in-KeyVault gap and Tier-4 exclusion as load-bearing control. Recommends Approve with conditions. Version number to be assigned by Founder. |
| DRAFT | 2026-06-09 | Claude Code | — | — | **Current plan confirmed = Atlassian Free** (Founder). Reclassified custom-permission-scheme assignment, Atlassian Guard SSO/SCIM, audit log, and data residency from conditions to new **§7 Deferred — Pending Tier Move** (per Founder rule). **Kept** the API-token-to-Key-Vault item and Tier-4 exclusion as in-tier conditions (credential/process choices, not plan features). Risk summary recomputed in-tier. |
