Add AGENTS.md guidance and expand Security policy library

Security/data_classification_policy.md

@@ -0,0 +1,86 @@
+# 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)**