# Cold Bore Ballistics LLC — Information Security Policy
# Classification: Confidential

---

## 1. Purpose

This policy establishes Cold Bore Ballistics LLC's commitment to protecting the confidentiality, integrity, and availability of its information assets. It defines the principles, responsibilities, and governance structure that apply to all security-related activity at CBB.

This is the master policy. All subordinate security policies derive their authority from this document and must be consistent with it.

---

## 2. Scope

This policy applies to:

- All information assets owned, controlled, or processed by CBB, regardless of where they are stored or transmitted
- All individuals who access CBB systems or data, including employees, contractors, and AI-assisted tooling operating under CBB credentials
- All systems, services, and vendors that store, process, or transmit CBB data

---

## 3. Guiding Principles

CBB's security program is built on four principles:

1. **Least privilege.** Every person, system, and integration receives only the access required to perform its stated function. Access is never granted speculatively.
2. **Defense in depth.** No single control is relied upon exclusively. Controls are layered so that the failure of one does not expose the organization.
3. **Explicit over implicit.** Access, consent, and approval must be documented and deliberate. Assumed or inherited access is not acceptable.
4. **Security enables acquisition.** A clean, auditable, and consistently enforced security posture is a material asset during technical due diligence. Undocumented controls and policy gaps are red flags that reduce company value.

---

## 4. Framework Alignment

CBB's security program is aligned to the **NIST Cybersecurity Framework (CSF) 2.0**. The five core functions — Identify, Protect, Detect, Respond, Recover — provide the organizing structure for this policy suite.

CBB does not hold a SOC 2 or ISO 27001 certification at this time. Alignment to NIST CSF is a deliberate choice appropriate to CBB's current scale and acquisition trajectory. Certification will be evaluated as the company grows and as customer or partner requirements demand it.

---

## 5. Policy Hierarchy

This master policy is supported by a suite of subordinate policies. Each subordinate policy governs a specific domain. In the event of a conflict between this policy and a subordinate policy, this policy takes precedence.

| Policy | Domain | NIST CSF Function(s) |
|---|---|---|
| `Access_Control_Policy.md` | Identity, MFA, least privilege, offboarding | Protect |
| `Data_Classification_Policy.md` | Data tiers, handling rules, retention | Protect |
| `Credential_and_Secret_Management_Policy.md` | Key Vault, secrets, rotation | Protect |
| `Vendor_and_Third_Party_Policy.md` | Vendor security review, risk register | Identify / Protect |
| `Incident_Response_Policy.md` | Incident definition, response, post-incident review | Respond / Recover |
| `Acceptable_Use_Policy.md` | Devices, accounts, AI tools, personal vs. work | Protect |
| `Entra_App_Registration_Policy.md` | Entra ID app registration governance | Protect |

All policies are stored in `OneDrive/CBB_Corporate/03_-_Confidential/Security/`, with the exception of `Entra_App_Registration_Policy.md`, which lives at `OneDrive/CBB_Corporate/03_-_Confidential/Infrastructure/M365/Entra_App_Registration_Policy.md`.

---

## 6. Roles and Responsibilities

### 6.1 Global Administrator

Currently: `jschwefel@coldboreballisticsllc.com`

Responsible for:

- Owning and maintaining this policy and all subordinate policies
- Approving exceptions to any policy in this suite
- Approving new app registrations, vendor onboarding, and access grants requiring elevated privilege
- Conducting or delegating annual policy reviews
- Acting as the primary incident response authority

### 6.2 Future employees and contractors

Upon engagement, every employee and contractor must:

- Acknowledge this policy and all subordinate policies in writing before being granted system access
- Complete any required security onboarding before accessing confidential or restricted data
- Report suspected security incidents immediately to the Global Administrator

### 6.3 AI-assisted tooling

AI agents and automation operating under CBB credentials (e.g., Claude Code operating under `claude-code-*` app registrations) are subject to the same access controls as human operators. Credentials issued to AI tooling must follow the same least-privilege and single-purpose requirements as credentials issued to humans.

---

## 7. Data Classification

CBB uses a four-tier classification system aligned to the OneDrive directory structure. Full handling rules are defined in `Data_Classification_Policy.md`. The tiers are:

| Tier | Label | Examples |
|---|---|---|
| 1 | Public | Marketing materials, public documentation, `dope-format` spec |
| 2 | General | Internal communications, non-sensitive process docs |
| 3 | Confidential | Infrastructure docs, financial records, legal templates, this policy suite |
| 4 | Highly Confidential | Engine internals, DOPE-Blend™ methodology, the SPEC |

Default classification for any document whose tier is unclear: **Confidential**.

---

## 8. Access Control

Full requirements are defined in `Access_Control_Policy.md`. Key requirements:

- Multi-factor authentication is required for all CBB accounts without exception
- Shared credentials are prohibited
- Access must be revoked within 24 hours of an employee or contractor offboarding
- Break-glass accounts (`admin@coldboreballistics.onmicrosoft.com`) are for emergency use only and must never be used for day-to-day operations
- App registrations and service accounts follow `Entra_App_Registration_Policy.md`

---

## 9. Credential and Secret Management

Full requirements are defined in `Credential_and_Secret_Management_Policy.md`. Key requirements:

- All secrets, API keys, certificates, and credentials must be stored in Azure Key Vault
- Plaintext secrets outside Key Vault are a policy violation
- Secrets are never committed to version control, shared via Slack or email, or stored in documentation
- Client certificates are preferred over client secrets for confidential client app registrations

---

## 10. Vendor and Third-Party Risk

Full requirements are defined in `Vendor_and_Third_Party_Policy.md`. Key requirements:

- Any new vendor or tool that accesses confidential or PII data requires a written Security Review before use
- The Security Review template is at `OneDrive/CBB_Corporate/03_-_Confidential/Infrastructure/Security_Review_Template.md`
- All active vendors are tracked in the **"CBB Risk Register" SharePoint List** on the Cold Bore Ballistics team site (`coldboreballistics.sharepoint.com/sites/ColdBoreBallistics`)
- Vendor access must be revoked upon offboarding

---

## 11. Incident Response

Full requirements are defined in `Incident_Response_Policy.md`. A security incident includes but is not limited to:

- Unauthorized access to any CBB system, account, or data
- Loss or theft of a device with access to CBB systems
- Credential exposure (committed to a repo, sent via unencrypted channel, etc.)
- Misuse of an app registration or service account beyond its authorized scope
- Discovery of malware or unauthorized software on a CBB device

All suspected incidents must be reported to the Global Administrator immediately. Incidents are not closed until a post-incident review has been documented.

---

## 12. Acceptable Use

Full requirements are defined in `Acceptable_Use_Policy.md`. Key requirements:

- CBB work must be conducted using CBB accounts (`@coldboreballisticsllc.com`) — never personal accounts
- Personal recovery credentials (`jason.schwefel78@gmail.com`) must never be used for CBB services
- CBB data must not be stored on personal devices without explicit approval
- AI tools operating under CBB credentials must follow all policies in this suite

---

## 13. Policy Exceptions

Exceptions to any policy in this suite must be:

1. Requested in writing with a stated business justification
2. Approved in writing by the Global Administrator
3. Time-bounded — no open-ended exceptions
4. Documented in the relevant policy's document control block

No exception may be self-approved unless no other qualified individual is employed by or contracted to CBB at the time of approval.

---

## 14. Review Cadence

This policy and all subordinate policies are reviewed in full:

- Every 12 months from the date of last full review
- Immediately following any security incident
- Immediately following a significant change to CBB's technology stack or vendor relationships
- Prior to any acquisition due diligence process

---

## 15. Enforcement

Violations of this policy or any subordinate policy may result in:

- Immediate revocation of access
- Termination of employment or contractor engagement
- Legal action where warranted

CBB operates under Wisconsin law. Nothing in this policy limits CBB's rights under applicable law.

---

## Document Control

| Field | Value |
|---|---|
| **Document owner** | `jschwefel@coldboreballisticsllc.com` |
| **Classification** | Confidential (`03_-_Confidential/`) |
| **Location** | `OneDrive/CBB_Corporate/03_-_Confidential/Security/CBB_Information_Security_Policy.md` |
| **Cross-references** | All subordinate policies listed in §5; "CBB Risk Register" SharePoint List; `Security_Review_Template.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 | — | — | Fixed jurisdiction error §15 "Illinois"→"Wisconsin" (CBB is a WI LLC). Repointed vendor risk register §10 + cross-ref to the **"CBB Risk Register" SharePoint List** (`coldboreballistics.sharepoint.com/sites/ColdBoreBallistics`) — the register is a SharePoint List, not a file; the prior `Process/CBB_Risk_Register.xlsx` path and the interim `Vendor_Risk_Register.md` were both incorrect. Added ™ to first use of DOPE-Blend (§7). Removed non-standard `# Last Updated` header line (per TECHNICAL_DOCUMENTATION_GUIDE §7). |
