# Incident Response Policy
# Cold Bore Ballistics LLC — Internal Reference
# Classification: Confidential

Subordinate to: `CBB_Information_Security_Policy.md` §11

---

## 1. Purpose and Scope

This policy defines what constitutes a security incident at CBB, how incidents are reported and responded to, and what post-incident obligations exist. It applies to all individuals with access to CBB systems and all automated or AI-assisted tooling operating under CBB credentials.

---

## 2. What Constitutes a Security Incident

A security incident is any event that threatens the confidentiality, integrity, or availability of CBB information assets. This includes but is not limited to:

- Unauthorized access to any CBB account, system, or data — including access by a CBB-credentialed tool beyond its authorized scope
- Loss or theft of any device with access to CBB systems or data
- Credential exposure: a secret, API key, password, or certificate appearing in version control, a communication channel, a document, or any other unauthorized location
- Misuse of an app registration or service account beyond its authorized scope (e.g., the `claude-code-calendar` registration being used for SharePoint operations)
- Discovery of malware, unauthorized software, or an unauthorized process on a CBB-managed device or system
- A vendor disclosing a breach that may have exposed CBB data
- Accidental disclosure of Confidential or Highly Confidential data to an unauthorized party

When in doubt, treat the event as an incident and report it. False positives are acceptable; unreported incidents are not.

---

## 3. Severity Levels

| Severity | Definition | Examples |
|---|---|---|
| **Critical** | Active or confirmed unauthorized access to Highly Confidential data, or active system compromise | SPEC exposure; Key Vault breach; confirmed unauthorized account access |
| **High** | Confirmed credential exposure or unauthorized access to Confidential data | Secret committed to a repo; unauthorized Atlassian or M365 access |
| **Medium** | Suspected exposure or policy violation without confirmed unauthorized access | App registration scope violation; lost device without confirmed access |
| **Low** | Policy violation with no material risk of data exposure | MFA bypass attempt blocked; minor acceptable use violation |

---

## 4. Reporting

All suspected incidents must be reported to the Global Administrator (`jschwefel@coldboreballisticsllc.com`) **immediately** upon discovery — do not wait to investigate or confirm before reporting.

At CBB's current scale, the Global Administrator is also the incident responder. As the organization grows and additional personnel are engaged, this policy will be updated to define an incident response team.

---

## 5. Response Procedure

### 5.1 Containment (immediate)

The first priority is to stop the bleeding. Actions depend on the incident type:

- **Credential exposure:** Rotate the credential immediately. See `Credential_and_Secret_Management_Policy.md` §6. Do not wait to assess scope before rotating.
- **Unauthorized account access:** Revoke sessions immediately via Entra admin center. Disable the account if the vector is unclear.
- **Lost or stolen device:** Remotely wipe via M365 device management if the device is enrolled. Revoke sessions for all accounts accessible from the device.
- **App registration scope violation:** Disable the registration immediately. Assess what actions were taken under it. Create a new, correctly scoped registration for the legitimate use case.
- **Vendor breach:** Revoke the vendor's credentials and assess what data may have been exposed before re-engaging.

### 5.2 Assessment

After containment, assess:

1. What data or systems were accessed or exposed?
2. What is the classification tier of the affected data?
3. Was any Highly Confidential data (SPEC, engine internals, DOPE-Blend™ methodology) exposed?
4. Is there any ongoing unauthorized access, or has it been fully contained?
5. What was the root cause?

### 5.3 Notification

CBB does not currently have customers with data stored on CBB systems. If that changes, this section must be updated to include customer notification obligations under applicable law (Wisconsin law; any additional jurisdictions where customers reside).

For incidents involving a vendor breach, notify the vendor's security team using the contact information in the vendor's Security Review document.

### 5.4 Recovery

After containment and assessment:

1. Restore normal operations using known-good credentials and configurations.
2. Confirm that the root cause has been remediated — not just the immediate symptom.
3. Verify that no unauthorized access persists.

### 5.5 Post-Incident Review

Every incident, regardless of severity, requires a written post-incident review before it is closed. The review must document:

- Incident timeline (discovery, containment, recovery)
- Root cause
- Actions taken
- Whether any data was exposed and what its classification tier was
- What policy or control failed, and whether that policy or control needs to be updated
- Any follow-up actions with owners and due dates

Post-incident reviews are stored at:

`OneDrive/CBB_Corporate/03_-_Confidential/Security/Incidents/YYYY-MM-DD_<brief-description>.md`

An incident is not closed until the post-incident review is written and the Global Administrator has confirmed all follow-up actions are tracked.

---

## 6. Incident Log

All incidents are tracked in the post-incident review documents at:

`OneDrive/CBB_Corporate/03_-_Confidential/Security/Incidents/`

**Known incidents as of 2026-06-07:**

| Date | Severity | Description | Status |
|---|---|---|---|
| 2026-06-07 | Medium | `claude-code-calendar` app registration used for SharePoint operations, crossing authorization boundaries | Resolved — `claude-code-sharepoint` created; `Entra_App_Registration_Policy.md` written |

---

## Document Control

| Field | Value |
|---|---|
| **Document owner** | `jschwefel@coldboreballisticsllc.com` |
| **Classification** | Confidential (03_-_Confidential/) |
| **Location** | `OneDrive/CBB_Corporate/03_-_Confidential/Security/Incident_Response_Policy.md` |
| **Cross-references** | `CBB_Information_Security_Policy.md`; `Credential_and_Secret_Management_Policy.md`; `Entra_App_Registration_Policy.md`; `Access_Control_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 | — | — | Fixed jurisdiction error §5.3 "Illinois law"→"Wisconsin law" (CBB is a WI LLC). Added ™ to first use of DOPE-Blend (§5.2). Removed non-standard `# Last Updated` header line (per TECHNICAL_DOCUMENTATION_GUIDE §7). |
