# Security Review Template
# Cold Bore Ballistics LLC — Internal Reference
# Classification: Confidential

---

## How to Use This Template

Copy this file to the appropriate location before filling it out:

- Software vendor / SaaS service: `Infrastructure/<domain>/<Vendor>_Security_Review.md`
- Hardware device: `OneDrive/ScopeDOPE/03_-_Confidential/Hardware/<Device>_Security_Review.md`

Complete all sections. Mark items `N/A` with a brief explanation if they genuinely do not apply. A review with unexplained blanks will not be approved.

Submit to the Global Administrator (`jschwefel@coldboreballisticsllc.com`) for approval before the vendor or device is granted access to CBB systems.

---

# [Vendor / Device Name] Security Review
# Classification: Confidential
# Date: YYYY-MM-DD
# Reviewer: [name]
# Status: Draft / Approved / Rejected

---

## 1. Vendor / Device Overview

| Field | Value |
|---|---|
| **Name** | |
| **Website** | |
| **Service / purpose** | |
| **CBB use case** | |
| **Data tier(s) accessed** | Tier 1 / 2 / 3 / 4 |
| **Access type** | API key / OAuth / credential delegation / hardware protocol / other |
| **Proposed onboarding date** | |

---

## 2. Data Exposure Assessment

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

*List specific data types — e.g., calendar events, SharePoint list contents, email metadata, BLE sensor readings.*

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

*Is data stored on the vendor's servers? In what region? Under what retention policy?*

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

- [ ] Yes — explain why this is necessary and what mitigations are in place
- [ ] No

---

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

### 3.1 Compliance and certifications

| Standard | Certified? | Notes |
|---|---|---|
| SOC 2 Type II | | |
| ISO 27001 | | |
| GDPR compliant | | |
| CCPA compliant | | |

### 3.2 Data processing agreement

- [ ] A Data Processing Agreement (DPA) is available and has been reviewed
- [ ] A DPA is not available — explain: ___

### 3.3 Breach history

*Document any known breaches in the past 3 years. Source: vendor's security page, HaveIBeenPwned, public disclosures.*

### 3.4 Security documentation

- [ ] Vendor publishes a security whitepaper or trust page
- [ ] Vendor publishes a current SOC 2 report (or equivalent)
- [ ] Vendor has a responsible disclosure / bug bounty program

### 3.5 Authentication and access control

- [ ] Vendor supports MFA
- [ ] Vendor supports SSO / SAML federation with Entra ID
- [ ] Vendor supports API key scoping (least-privilege API access)
- [ ] Vendor supports OAuth with defined scopes

---

## 4. Hardware Security Assessment (Hardware / BLE devices only)

### 4.1 Communication protocol

*Document the BLE or other wireless protocol, UUIDs, pairing model, and encryption in use.*

### 4.2 Firmware update mechanism

*How are firmware updates delivered? Are they signed? Is there a rollback mechanism?*

### 4.3 Data transmission security

- [ ] BLE communications are encrypted
- [ ] Device does not transmit CBB data to any external server
- [ ] Pairing is protected against unauthorized bonding

### 4.4 Physical security

*What happens if the device is lost or stolen? Can it expose CBB data?*

---

## 5. Integration Security

### 5.1 Credential management

*What credentials will be issued to this vendor / integration? Where will they be stored?*

- [ ] Credentials will be stored in Azure Key Vault
- [ ] Credentials are scoped to the minimum required permissions
- [ ] Credentials are unique to this integration (not shared with other integrations)

### 5.2 Network exposure

*Does this integration require inbound firewall rules, webhook endpoints, or public IP exposure? Document each.*

### 5.3 Offboarding plan

*How will CBB revoke this vendor's access when the relationship ends? How will CBB data be deleted from vendor systems?*

---

## 6. Risk Summary

| Risk | Likelihood (L/M/H) | Impact (L/M/H) | Mitigation |
|---|---|---|---|
| | | | |
| | | | |

**Overall risk rating:** Low / Medium / High

**Recommendation:** Approve / Reject / Approve with conditions

**Conditions (if any):**

---

## Document Control

| Field | Value |
|---|---|
| **Document owner** | `jschwefel@coldboreballisticsllc.com` |
| **Classification** | Confidential (03_-_Confidential/) |
| **Location** | `OneDrive/CBB_Corporate/03_-_Confidential/Infrastructure/Security_Review_Template.md` |
| **Cross-references** | `Vendor_and_Third_Party_Policy.md`; `CBB_Information_Security_Policy.md` |
| **Created** | 2026-06-07 |
| **Last updated** | 2026-06-09 |
| **Next full review due** | 2027-06-07 |

---

## Revision Control Block

| Rev | Date | Changed By | Reviewed By | Approved By | Summary |
|-----|------|------------|-------------|-------------|---------|
| 0.9 | 2026-06-07 | jschwefel | — | — | Initial release |
| DRAFT | 2026-06-09 | Claude Code | — | — | Removed non-standard `# Last Updated` header line (per TECHNICAL_DOCUMENTATION_GUIDE §7). The in-template `# Date: YYYY-MM-DD` placeholder block is intentional scaffolding and is retained. No content changes. |
