# Data Classification & Handling Policy

**Document owner:** [Owner/Role]  
**Approved by:** [Steering Committee / CISO]  
**Effective date:** [YYYY-MM-DD]  
**Review cadence:** [Annually]

---

## 1. Purpose & Scope
This policy defines how [Organization] classifies information and the handling requirements — storage, transmission, sharing, and destruction — attached to each classification level. It applies to all information created, received, or processed by employees, contractors, vendors, and systems, in any format (digital, physical, verbal).

This policy is the **canonical source** for the classification scheme referenced elsewhere in this repository (e.g., [Authentication Policy §4](authentication_policy.md)).

---

## 2. Roles & Responsibilities
- **Data Owner:** Business role accountable for a given data set; assigns initial classification and approves declassification.  
- **Data Custodian:** IT/system owner responsible for implementing technical handling controls (encryption, access control, DLP) for data at rest under their care.  
- **All Users:** Must label data they create per §3.2 and handle data per its assigned level.

---

## 3. Policy Statements

### 3.1 Classification Scheme
[Organization] classifies information using the [FIRST.org Traffic Light Protocol (TLP) 2.0](https://www.first.org/tlp/):

| Level | Meaning | Default Applies To |
|---|---|---|
| **TLP:CLEAR** | Disclosure not limited (public) | Marketing materials, published docs |
| **TLP:GREEN** | Limited disclosure, community-wide (all staff) | Internal wikis, general process docs |
| **TLP:AMBER** | Limited disclosure, organization + need-to-know | Financials, HR records, customer data |
| **TLP:AMBER+STRICT** | Limited disclosure, named individuals/org only, no further sharing | M&A material, active investigations, source code for kill-chain systems |
| **TLP:RED** | Named recipients only | Credentials, incident forensics, active exploit details, PKI root material |

Default level when unlabeled: **TLP:AMBER**. Silence is not TLP:CLEAR — undated/unlabeled data **must not** be treated as public.

### 3.2 Labeling Requirements
- Documents and datasets **must** carry a visible or metadata label at creation (e.g., document header, sensitivity label in M365, object tag in cloud storage).  
- Systems **must** default new content to the classification of the workspace/repository it lives in unless overridden.  
- Labels **must** be reviewed at any material change to content sensitivity.

### 3.3 Handling Requirements by Level

| Control | CLEAR | GREEN | AMBER | AMBER+STRICT | RED |
|---|---|---|---|---|---|
| Encryption at rest | Optional | Recommended | **Required** | **Required** | **Required** + key access logged |
| Encryption in transit | Optional | **Required** (TLS 1.2+) | **Required** | **Required** | **Required**, no email |
| Internal sharing | Unrestricted | All staff | Need-to-know | Named individuals only | Named individuals only, approval logged |
| External sharing | Unrestricted | With NDA | Contractual DLP clause required | Prohibited without CISO approval | Prohibited |
| Storage location | Any approved system | Any approved system | Approved systems with access logging | Restricted storage, MFA-gated (see [Authentication Policy §4](authentication_policy.md)) | Vaulted / HSM-backed where applicable |
| Printing | Unrestricted | Unrestricted | Discouraged, must not leave premises unattended | Prohibited unless logged and approved | Prohibited |
| Destruction | Standard deletion | Standard deletion | Secure delete/wipe | Secure delete/wipe + logged | Cryptographic erasure or physical destruction, logged |

### 3.4 Reclassification & Declassification
- Only the **Data Owner** may lower a classification level.  
- Declassification **must** be documented with rationale and date.  
- Data **must** be reviewed for reclassification when it becomes stale (e.g., an incident report moves from RED to AMBER once resolved and disclosed internally).

### 3.5 Mishandling & Incident Reporting
- Any suspected mishandling (e.g., AMBER+STRICT data emailed externally) **must** be reported to Security immediately and treated as a security incident.

### 3.6 Enforcement
- Violations **may** result in disciplinary action or revocation of access.  
- System owners **must** remediate non-compliant storage/sharing configurations or document a CISO-approved exception.

---

## 4. Antifragility Alignment
This policy is built to the five pillars of the organization's internal **Antifragile Enterprise Manifest**.

| Pillar | Applied In | How |
|---|---|---|
| **1. Structural Decoupling** | §3.3 | Classification is stored as portable metadata/labels, not locked into one vendor's proprietary DLP format |
| **2. Optionality Preservation** | §3.3 | External sharing requires contractual DLP/export clauses — data can move without losing its protection |
| **3. Stress-to-Signal Conversion** | §3.5 | Every mishandling incident is treated as a security incident, feeding structural fixes (see [Authentication Policy §2.12](authentication_policy.md)) |
| **4. Sovereign Intelligence** | §2 | Named Data Owner and Custodian per data set — classification accountability isn't tribal knowledge |
| **5. Asymmetric Payoff Design (Barbell)** | §3.3 | Paranoid controls (HSM, cryptographic erasure, logged approval) concentrated at RED/AMBER+STRICT; CLEAR/GREEN stay lightweight — nothing moderate in the middle |

---

## 5. References
- **[FIRST.org Traffic Light Protocol (TLP) 2.0](https://www.first.org/tlp/)**  
- **[NIST SP 800-60 Vol. 1 Rev. 1, Guide for Mapping Types of Information to Security Categories](https://csrc.nist.gov/pubs/sp/800/60/v1/r1/final)**  
- **[ISO/IEC 27001:2022](https://www.iso.org/standard/27001)**