Add AGENTS.md guidance and expand Security policy library

AGENTS.md

@@ -0,0 +1,87 @@
+# Agent Guidance: Organizational Policies Repository
+
+## Project Overview
+
+This repository is **not a software project**. It is a documentation repository that serves as the single source of truth for official organizational policies. All content is written in Markdown and version-controlled with Git.
+
+- **Repository root:** `/Users/avedelphina/Local/policies`
+- **Primary language:** English (all documents and metadata are in English)
+- **Content format:** Markdown (`.md`)
+- **Version control:** Git
+- **License / confidentiality:** All content is confidential and for internal organizational use only. All rights reserved.
+
+The repository currently contains one policy category:
+
+- **`Security/`** — Information security, authentication, password, and identity-management policies and implementation guidance.
+
+No application code, build artifacts, package managers, or runtime environments are present.
+
+## Repository Structure
+
+```
+.
+├── README.md                                    # Human-facing project description and contribution guidelines
+├── .gitignore                                   # Ignores .DS_Store only
+└── Security/
+    ├── authentication_guidance.md               # Practical hardening guidance for authentication
+    ├── authentication_policy.md                 # Normative authentication policy (AALs, MFA, session management)
+    ├── password_guidance_generic.md             # System-agnostic password implementation guidance
+    ├── password_guidance_m365_ad.md             # Microsoft 365 / AD password guidance (marked as Draft)
+    ├── password_policy_generic.md               # System-agnostic password and authenticator policy
+    └── password_policy_m365_ad.md               # Microsoft 365 / AD password and authenticator policy
+```
+
+## Technology Stack
+
+- **Markup:** GitHub-flavored Markdown
+- **Tooling:** Plain text editors and Git; no compilers, interpreters, linters, or package managers are configured
+- **No build system:** There is no `pyproject.toml`, `package.json`, `Cargo.toml`, `Makefile`, `setup.py`, CI/CD configuration, or equivalent
+- **No runtime architecture:** This repository produces human-readable policy documents, not an executable application or service
+
+## Document Conventions
+
+When editing or adding policy documents, follow the conventions already established in the existing files:
+
+1. **Header metadata block** — Begin each policy or guidance document with:
+   ```markdown
+   **Document owner:** [Owner/Role]
+   **Approved by:** [Steering Committee / CISO]
+   **Effective date:** [YYYY-MM-DD]
+   **Review cadence:** [Annually]
+   ```
+2. **Section numbering** — Use decimal heading numbers (`## 1. …`, `### 2.1 …`) for policy documents; guidance documents may use either decimal or bracketed numbers (`## 1) …`).
+3. **Organization placeholder** — Use `[Organization]` where the company name should appear.
+4. **Normative language** — Policy documents use RFC-style keywords such as **must**, **shall**, **should**, **may**, and **prohibited**. Guidance documents use **should**, **recommend**, and **consider**.
+5. **References** — Cite authoritative sources in a final `## References` section. Commonly referenced standards include:
+   - NIST SP 800-63B (Digital Identity Guidelines)
+   - CIS Controls v8.1
+   - ENISA Digital Identity and Data Protection guidance
+   - OWASP Authentication Cheat Sheet
+   - Microsoft Security Baselines for Windows / M365 / AD
+6. **Tables and checklists** — Use Markdown tables for matrix requirements (e.g., account type × AAL, TLP sensitivity × AAL) and emoji checkboxes (`✅`) for hardening checklists.
+7. **Draft status** — If a document is not yet approved, append `(Draft)` to its title.
+
+## Build and Test Commands
+
+There are no build, test, or deploy commands for this repository. Changes are validated through:
+
+- Markdown rendering preview
+- Manual editorial and legal/policy review
+- Pull-request review by the policy management team
+
+## Contribution and Review Workflow
+
+1. Create a feature branch for any change.
+2. Edit or add Markdown policy documents using the conventions above.
+3. Open a pull request describing the proposed updates.
+4. The policy management team reviews and merges approved changes.
+
+All contributions must align with organizational goals and legal requirements. Do not commit generated build artifacts, temporary files, or `.DS_Store` files.
+
+## Security Considerations
+
+- The repository content itself defines security requirements; treat the files as sensitive organizational records.
+- Do not embed secrets, credentials, or private individual data in any Markdown file.
+- Keep placeholder fields (`[Owner/Role]`, `[YYYY-MM-DD]`, `[Organization]`) until they are formally populated by the policy owner.
+- Maintain consistency across related policies. For example, password length requirements (15 characters single-factor, 8 characters with MFA, 64-character maximum) and MFA baselines should remain aligned between the Authentication Policy, Password Policy (generic), and Password Policy (M365 + AD).
+- Any exception to policy requirements must be documented with compensating controls, CISO approval, and a review date not exceeding 12 months.

README.md

@@ -30,4 +30,4 @@ Please ensure that all contributions align with organizational goals and legal r
 
 ## Licensing
 
-All content in this repository is licensed under the MIT license.
+All content in this repository is confidential and for internal organizational use only. All rights reserved.

Security/acceptable_use_guidance.md

@@ -0,0 +1,33 @@
+# Acceptable Use Guidance
+
+**Document owner:** [Owner/Role]  
+**Approved by:** [Steering Committee / CISO]  
+**Effective date:** [YYYY-MM-DD]  
+**Review cadence:** [Annually]
+
+---
+
+## 1. Purpose & Scope
+Implementation guidance for the [Acceptable Use Policy](acceptable_use_policy.md). Applies to all staff and to managers handling exceptions.
+
+---
+
+## 2. Shadow IT / Shadow AI — Practical Detection
+- Monitor SaaS discovery via CASB/SSO login patterns (unsanctioned app sign-ins via "Login with Google/Microsoft" are the easiest signal).  
+- Common shadow-AI entry point: pasting internal docs/code into a public chatbot for "just a quick summary" — treat this as the default failure mode to educate against, not an edge case.  
+- Provide an approved, low-friction AI tool option so staff aren't forced into shadow use to get work done — a policy with no sanctioned alternative just pushes usage underground.
+
+## 3. Approval Fast-Path
+- Low-risk tools (no data beyond TLP:CLEAR/GREEN touches the tool): lightweight self-service approval with automatic logging.  
+- Any tool touching TLP:AMBER+: security review required before use, checking for a no-train/no-retain data processing clause.
+
+## 4. Onboarding Checklist
+✅ New hires acknowledge this policy before systems access is granted.  
+✅ Approved SaaS/AI tool list published and easy to find (not buried in a wiki no one reads).  
+✅ Reporting channel for suspected phishing/shadow IT is one click away, not a multi-step process.
+
+---
+
+## 5. References
+- **[ISO/IEC 27001:2022](https://www.iso.org/standard/27001)**  
+- **[CIS Controls v8.1](https://www.cisecurity.org/controls/v8-1)**  

Security/acceptable_use_policy.md

@@ -0,0 +1,61 @@
+# Acceptable Use Policy
+
+**Document owner:** [Owner/Role]  
+**Approved by:** [Steering Committee / CISO]  
+**Effective date:** [YYYY-MM-DD]  
+**Review cadence:** [Annually]
+
+---
+
+## 1. Purpose & Scope
+This policy defines acceptable use of [Organization] systems, accounts, and data by all employees, contractors, and vendors with access to those systems.
+
+---
+
+## 2. Policy Statements
+
+### 2.1 General Use
+- Systems and accounts **must** be used primarily for authorized business purposes.  
+- Incidental personal use is permitted where it does not interfere with duties, consume disproportionate resources, or violate this policy.
+
+### 2.2 Prohibited Activities
+- Unauthorized access to systems or data outside one's role (see [Access Control Policy §3.1](access_control_policy.md)).  
+- Disabling, bypassing, or circumventing security controls (MFA, endpoint protection, logging) without a documented exception.  
+- Sharing credentials or allowing account use by another person, including "temporary" sharing for convenience.  
+- Illegal activity, harassment, or use that damages [Organization]'s reputation.
+
+### 2.3 Email & Communication
+- Business email **must not** be used for unrelated personal accounts of consequence (banking, unrelated business ventures).  
+- Suspected phishing **must** be reported, not just deleted.
+
+### 2.4 Cloud Services & Shadow IT
+- New SaaS tools, including AI/LLM tools, **must** be approved before use with company data — unsanctioned tools create the "knowledge/AI leak" risk described in the organization's Antifragile Enterprise Manifest (Pillar 4: Sovereign Intelligence): data and reasoning sent to an unapproved third party is cognition the organization no longer controls.  
+- Approved AI tools **must** be used per any organization-specific data handling addendum; TLP:AMBER+STRICT/RED data (per [Data Classification Policy](data_classification_policy.md)) **must not** be submitted to a cloud AI service without verified contractual no-train/no-retain terms.
+
+### 2.5 Personal & BYOD Devices
+- Personal devices accessing company data **must** meet minimum security baseline (screen lock, encryption, current OS) — full BYOD/MDM requirements are covered in a dedicated device management policy where one exists.
+
+### 2.6 Monitoring Notice
+- [Organization] **may** monitor system and account usage as permitted by applicable law, for security and operational purposes. Users **should** have no expectation of privacy in company systems beyond what law requires.
+
+### 2.7 Enforcement
+- Violations **may** result in disciplinary action, up to and including termination of access or employment.
+
+---
+
+## 3. 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** | §2.4 | Approval gate on new SaaS/AI tools prevents unmapped, unmanaged dependencies from silently accumulating |
+| **2. Optionality Preservation** | §2.4 | Requiring no-train/no-retain terms before sending sensitive data to a vendor preserves control over that data later |
+| **3. Stress-to-Signal Conversion** | §2.3 | Reported phishing (not just deleted) becomes signal that feeds security awareness and control updates |
+| **4. Sovereign Intelligence** | §2.4 | This is the pillar's most direct policy expression: shadow AI/cloud use is exactly the "AI leak" the manifest warns about |
+| **5. Asymmetric Payoff Design (Barbell)** | §2.4 | Extra scrutiny concentrated on AMBER+STRICT/RED data reaching AI tools; low-sensitivity personal use stays lightly governed |
+
+---
+
+## 4. References
+- **[ISO/IEC 27001:2022](https://www.iso.org/standard/27001)**  
+- **[CIS Controls v8.1](https://www.cisecurity.org/controls/v8-1)**  

Security/access_control_guidance.md

@@ -0,0 +1,43 @@
+# Access Control & Least Privilege Guidance
+
+**Document owner:** [Owner/Role]  
+**Approved by:** [Steering Committee / CISO]  
+**Effective date:** [YYYY-MM-DD]  
+**Review cadence:** [Annually]
+
+---
+
+## 1. Purpose & Scope
+Implementation guidance for the [Access Control & Least Privilege Policy](access_control_policy.md). Applies to IT/IAM, managers, and system/data owners.
+
+---
+
+## 2. Role Design — How To
+- Start from job function, not from current access ("what does a Support Engineer need" not "what does Alice currently have" — the latter just codifies drift).  
+- Use Entra ID/Azure AD groups or equivalent RBAC roles; avoid direct resource ACLs for anything beyond a one-off, time-bound exception.  
+- Keep the number of distinct roles small — role sprawl is as bad as ad hoc grants; if two roles differ by one permission, question whether they should be one role with a scoped exception.
+
+## 3. Joiner-Mover-Leaver — Practical Flow
+1. **Joiner:** HR system triggers IAM provisioning workflow on start date; access live day 1, not requested ad hoc by the new hire's manager over chat.  
+2. **Mover:** Role change in HR system triggers automatic review — old role's access **removed**, not left "just in case."  
+3. **Leaver:** Termination in HR system triggers same-day deprovisioning; involuntary terminations trigger immediate (not end-of-day) revocation, coordinated with the immediate manager.
+
+## 4. Access Review — Worked Example
+| Account Type | Reviewer | What to Check |
+|---|---|---|
+| Privileged/Admin | Access Owner + manager | Still needed? Still least-privilege scoped? Any dormant admin sessions? |
+| Standard User | Manager | Role still matches job function? Any accumulated ad hoc grants to fold into role or revoke? |
+| Service Account | System owner | Still in use? Rotation current per [Secrets & Key Management Policy](secrets_management_policy.md)? |
+
+## 5. Checklist
+✅ Joiner-mover-leaver automated from HR system, not manual ticket-only.  
+✅ Privileged access reviewed quarterly, standard semi-annually.  
+✅ Separation-of-duties matrix documented for finance/production-deploy roles.  
+✅ Dormant accounts flagged per [Password Policy §2.11](password_policy_generic.md) (45-day inactivity).  
+✅ Ad hoc/direct grants logged and swept into the next access review.
+
+---
+
+## 6. References
+- **[NIST SP 800-53 Rev. 5 (AC family)](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)**  
+- **[CIS Controls v8.1](https://www.cisecurity.org/controls/v8-1)**  

Security/access_control_policy.md

@@ -0,0 +1,78 @@
+# Access Control & Least Privilege Policy
+
+**Document owner:** [Owner/Role]  
+**Approved by:** [Steering Committee / CISO]  
+**Effective date:** [YYYY-MM-DD]  
+**Review cadence:** [Annually]
+
+---
+
+## 1. Purpose & Scope
+This policy establishes mandatory requirements for granting, reviewing, and revoking access to [Organization] systems and data, based on least privilege and need-to-know. It applies to all employees, contractors, vendors, and service accounts, and complements the account types defined in [Authentication Policy §3](authentication_policy.md).
+
+---
+
+## 2. Roles & Responsibilities
+- **Access Owner (system/data owner):** Approves access requests and grants for their system.  
+- **Manager:** Approves role-appropriate access for direct reports; initiates leaver/mover requests.  
+- **IT/IAM:** Provisions, reviews, and revokes access per this policy.
+
+---
+
+## 3. Policy Statements
+
+### 3.1 Least Privilege & Need-to-Know
+- Access **must** be granted at the minimum level required for a person's role.  
+- Standing access to TLP:AMBER+STRICT/RED data (per [Data Classification Policy](data_classification_policy.md)) **must** be justified and time-bound where feasible; prefer just-in-time elevation.
+
+### 3.2 Role-Based Access Control
+- Access **must** be granted through defined roles mapped to job function, not ad hoc individual grants.  
+- Direct/ad hoc grants outside a defined role **must** be logged, time-bound, and reviewed at next access review.  
+- Role definitions **must** be documented and owned (see [Authentication Policy §2.14](authentication_policy.md)).
+
+### 3.3 Joiner-Mover-Leaver Lifecycle
+- **Joiner:** Access provisioned per role on or after start date; no standing access before identity verification completes.  
+- **Mover:** Access **must** be updated within **5 business days** of a role change; prior role's access **must** be removed, not just supplemented.  
+- **Leaver:** Access **must** be revoked within **24 hours** of termination (immediately for involuntary termination), consistent with [Vendor Risk Management Policy §3.6](vendor_risk_management_policy.md) for third parties.
+
+### 3.4 Separation of Duties
+- Conflicting duties (e.g., payment initiation and approval, code deployment and production access approval) **must not** be held by the same individual without a documented compensating control.  
+- A separation-of-duties conflict matrix **must** be maintained for financial and production-critical systems.
+
+### 3.5 Periodic Access Reviews
+| Account Type (per Authentication Policy §3) | Review Cadence |
+|---|---|
+| Privileged/Admin | Quarterly |
+| Standard User | Semi-annually |
+| Third-party/Vendor | Per contract term, minimum annually |
+| Service/Machine | Annually, plus on owner change |
+
+- Reviews **must** be performed by the Access Owner, not solely by IT.  
+- Unreviewed access past the cadence **must** be treated as a finding and escalated.
+
+### 3.6 Emergency / Break-Glass Access
+- Governed by [Authentication Policy §3](authentication_policy.md) (Break-glass account type) and [§2.13](authentication_policy.md) (drills).
+
+### 3.7 Enforcement
+- Violations **may** result in disciplinary action or revocation of access.  
+- Systems unable to support role-based provisioning or timely revocation **must** be remediated or formally excepted with CISO approval.
+
+---
+
+## 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.2 | Role definitions are documented independent of any single IAM vendor's proprietary grouping model |
+| **2. Optionality Preservation** | §3.1 | Just-in-time elevation preferred over standing access — preserves the option to say no without an offboarding project |
+| **3. Stress-to-Signal Conversion** | §3.5 | Unreviewed access past cadence is a tracked finding, not silence |
+| **4. Sovereign Intelligence** | §3.2 | Roles and SoD matrix documented and owned, not held as tribal "ask Dave" knowledge |
+| **5. Asymmetric Payoff Design (Barbell)** | §3.5 | Quarterly review concentrated on privileged accounts; standard users get a lighter semi-annual cadence |
+
+---
+
+## 5. References
+- **[NIST SP 800-53 Rev. 5, Security and Privacy Controls (AC family)](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)**  
+- **[CIS Controls v8.1 (Controls 5 & 6)](https://www.cisecurity.org/controls/v8-1)**  
+- **[ISO/IEC 27001:2022](https://www.iso.org/standard/27001)**  

Security/authentication_guidance.md

@@ -166,8 +166,37 @@ Use this section to classify any method you encounter.
 
 ---
 
-## 11. References
-- NIST SP 800‑63B (Digital Identity Guidelines, 2023 update)  
-- CIS Controls v8.1 (Controls 5 & 6)  
-- ENISA Guidelines on Identity and Access Management  
-- OWASP Authentication Cheat Sheet  
+## 11. Account Type × TLP Sensitivity — Worked Examples
+Normative minimums are in Policy §§3–4. Governing AAL = **max(account-type minimum, data-sensitivity minimum)**.
+
+| Scenario | Account Type Min | TLP of Data Touched | Data Min | Governing AAL |
+|---|---|---|---|---|
+| Helpdesk agent reading public knowledge base | Standard User → AAL2 | TLP:CLEAR → AAL1 | — | **AAL2** (account floor wins) |
+| Finance analyst opening internal budget doc | Standard User → AAL2 | TLP:GREEN → AAL2 | — | **AAL2** |
+| HR admin accessing employee PII export | Privileged/Admin → AAL3 | TLP:AMBER → AAL2 (AAL3 for admin) | — | **AAL3** |
+| Domain admin managing DCs | Privileged/Admin → AAL3 | TLP:AMBER+STRICT → AAL3 | — | **AAL3**, no OOB |
+| SOC analyst pulling active incident IOCs shared by a partner | Standard User → AAL2 | TLP:RED → AAL3 | — | **AAL3** (data floor wins over account floor) |
+| CI/CD pipeline pulling build artifacts | Service/Machine → N/A | TLP:GREEN → AAL2 | — | Not applicable — no interactive auth; use managed identity/certificate per §3 |
+| Vendor support engineer troubleshooting a ticket | Third-party → AAL2 | TLP:AMBER → AAL2 | — | **AAL2**, time-bound |
+| On-call engineer invoking break-glass domain admin during MFA outage | Break-glass → AAL2 min | TLP:AMBER+STRICT → AAL3 | — | **AAL3 preferred**, but checkout proceeds at AAL2 minimum with mandatory post-incident review — see §3 |
+
+**Rule of thumb:** never let a low-sensitivity account type "borrow down" the AAL required by high-sensitivity data, and never let low-sensitivity data waive the AAL an account type otherwise requires (e.g., admin accounts stay AAL3 even reading TLP:CLEAR content).
+
+---
+
+## 12. Antifragility — Practical Playbook
+Concrete moves per pillar (policy clauses in parens):
+
+- **Structural Decoupling (§2.6, §2.11):** Keep a written runbook for authenticating users if the IdP is down — e.g., break-glass local admin + offline MFA seed backup. Test it, don't just write it. Maintain a live doc: "if we had to leave [IdP vendor] in 90 days, here's the plan" — even if you never execute it.
+- **Optionality Preservation (§2.4):** Don't let "MFA" mean "one app from one vendor." A FIDO2 key **and** a TOTP app satisfies §2.4 even if the authenticator app vendor has an outage. Enrollment flow should force both before granting access.
+- **Stress-to-Signal Conversion (§2.12, §2.13):** Log every MFA fatigue/push-bombing attempt as an incident, not noise — recurring pattern with no policy change is a finding. Break-glass drill format: non-prod first, read-only check before destructive, one account before many, written abort trigger ("if X happens, stop and roll back") agreed before starting.
+- **Sovereign Intelligence (§2.14):** One-page "if the IdP admin got hit by a bus" doc: where Conditional Access rules live, who has break-glass credentials, how MFA vendor is configured. Named owner, reviewed at least yearly.
+- **Asymmetric Payoff / Barbell (§2.1, §3):** Resist the urge to apply AAL2.5-ish "extra effort" everywhere. Kill-chain systems (IdP, PKI root, backup infra, break-glass vault) get AAL3 + extra scrutiny, full stop. Everything else gets the AAL2 baseline and no more — spending moderate effort broadly instead of concentrating it on kill-chain nodes is the failure mode this pillar exists to prevent.
+
+---
+
+## 13. References
+- [NIST SP 800‑63B (Digital Identity Guidelines, 2023 update)](https://pages.nist.gov/800-63-3/sp800-63b.html)  
+- [CIS Controls v8.1 (Controls 5 & 6)](https://www.cisecurity.org/controls/v8-1)  
+- [ENISA Digital Identity and Data Protection](https://www.enisa.europa.eu/topics/digital-identity-and-data-protection)  
+- [OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)  

Security/authentication_policy.md

@@ -30,6 +30,7 @@ This policy supports GDPR principles of **data protection by design** and **acco
   - **AAL1:** Single‑factor authentication. Permitted only for low‑sensitivity internal apps or offline scenarios.  
   - **AAL2:** Multi‑factor authentication combining two categories (e.g., password + OTP app, push, QR code OOB). Required for employee logins, SaaS, and external‑facing systems.  
   - **AAL3:** High‑assurance, hardware‑backed MFA (e.g., FIDO2, smartcards). Required for privileged/admin access, production, and regulated data systems.  
+- **Kill‑chain tier:** Systems whose compromise would be existential — the IdP itself, PKI/CA roots, backup and recovery infrastructure, the break‑glass vault — **must** be AAL3 with no exceptions. Protection is concentrated disproportionately here (barbell principle); do not spend equivalent effort hardening low‑value systems at the other end.  
 
 ### 2.2 Memorized Secrets (Passwords)
 - **Length:**  
@@ -55,6 +56,7 @@ This policy supports GDPR principles of **data protection by design** and **acco
 - **Allowed:** FIDO2/WebAuthn keys; smartcards with PIN; authenticator apps (TOTP, push, **QR‑code sign‑in**); device‑bound biometrics (unlock only).  
 - **Fallback only:** SMS/voice OTPs.  
 - **Prohibited:** Email OTP; KBA/security questions.  
+- **Vendor diversity:** Each user **must** enroll **≥2 MFA methods spanning at least two independent implementations** (e.g., a FIDO2 hardware key plus an authenticator app from a different vendor than the primary IdP's own). A single MFA vendor outage or compromise **must not** remove all of a user's factors.  
 
 ### 2.5 Out‑of‑Band (OOB) Methods
 - OOB authenticators **must** use **encrypted, device‑bound** channels (e.g., push or QR‑code flows) and **must** implement rate‑limiting.  
@@ -63,6 +65,7 @@ This policy supports GDPR principles of **data protection by design** and **acco
 ### 2.6 Central vs. Local Authentication
 - **Central IdP/SSO** **must** be the default for enterprise access.  
 - **Local authentication** (device‑only) may be used for **pre‑boot**, **offline**, or **recovery**, but **must** meet the applicable AAL and other requirements in this policy.  
+- **Graceful degradation:** The central IdP **must** have a documented, tested fallback authentication path for outage scenarios. An IdP with no fallback is a single point of failure for the entire organization; the fallback **must** be exercised at least annually.  
 
 ### 2.7 BitLocker Pre‑Boot Authentication
 - **TPM only:** AAL1; not acceptable for sensitive systems.  
@@ -84,10 +87,67 @@ This policy supports GDPR principles of **data protection by design** and **acco
 - Violations **may** result in disciplinary action or revocation of access.  
 - Non‑compliant systems **must** be remediated or formally excepted with CISO approval.  
 
+### 2.11 Vendor Exit Readiness
+- [Organization] **must** maintain a documented, current migration path off its primary IdP/MFA vendor, executable within **90 days** without loss of authentication capability.  
+- This path **must** be reviewed **annually** and after any material change to the IdP/MFA vendor relationship.  
+
+### 2.12 Incident‑Driven Structural Learning
+- Every MFA bypass, credential‑stuffing event exceeding threshold, break‑glass invocation, or IdP outage **must** trigger a **blameless post‑mortem** producing **at least one structural change** (policy, architecture, or control) within **30 days**.  
+- Structural findings **must** be tracked to closure; recurring root causes without a structural fix are a policy violation in themselves.  
+
+### 2.13 Break‑Glass Drills
+- Break‑glass procedures **must** be exercised at least **quarterly**, in a non‑production or scoped environment first, with a **pre‑agreed abort condition** and **bounded blast radius**.  
+- Untested break‑glass access **is treated as broken access** — an unexercised emergency path is a liability, not a control.  
+
+### 2.14 Ownership & Documentation
+- Authentication architecture — IdP configuration, Conditional Access/policy rules, break‑glass procedure, MFA vendor configuration — **must** be documented in **owned, version‑controlled form** with a **named accountable owner**.  
+- This knowledge **must not** exist solely as tribal knowledge held by one individual; loss of that individual **must not** mean loss of the organization's ability to operate or rebuild its authentication systems.  
+
 ---
 
-## 3. References
-- NIST SP 800‑63B (Digital Identity Guidelines, 2023 update)  
-- CIS Controls v8.1 (Controls 5 & 6)  
-- ENISA Guidelines on Identity and Access Management  
-- OWASP Authentication Cheat Sheet  
+## 3. Account Type Requirements
+[Organization] recognizes the account types below. Each carries a **minimum** AAL; where an account also accesses data at a given TLP sensitivity (§4), the **higher** of the two minimums applies.
+
+| Account Type | Examples | Minimum AAL | MFA / Authenticator | Reauth / Inactivity | Special Controls |
+|---|---|---|---|---|---|
+| **Standard User** | Employee, contractor daily-use account | AAL2 | Password + TOTP/push/FIDO2 | ≤24h / ≤1h | Standard joiner/mover/leaver process |
+| **Privileged / Admin** | Domain admin, cloud admin, DBA, security admin | AAL3 | FIDO2/WebAuthn or smart‑card; no OOB | ≤12h / ≤15min | Separate from daily-use account; JIT/PIM elevation; fully logged |
+| **Service / Machine / API** | Automation, CI/CD, application-to-application | N/A (non-interactive) | Certificate, managed identity, or vaulted key | N/A | No interactive login; automated rotation; no shared use across services |
+| **Break-glass / Emergency** | Emergency domain admin, DR access | AAL2 minimum, AAL3 preferred | Vaulted credential, MFA required at checkout | Time-bound, single-use | Sealed in PAM vault; real-time alert on checkout; mandatory post-use audit and credential rotation |
+| **Third-party / Vendor** | MSP, external support, auditor with standing access | AAL2 (AAL3 if privileged or TLP:AMBER+STRICT/RED data) | Federated SSO preferred; MFA mandatory | Per role, per §2.9 | Time-bound access; contractually mandated MFA; offboarding SLA ≤ 24h from contract end |
+| **Guest / External Collaborator** | Partner, contractor without standing access | AAL2 | Federated identity or authenticator app | Session-bound to engagement | Requires internal sponsor; no standing/persistent access |
+| **Shared / Generic / System** | Legacy shared logins, kiosk accounts | **Prohibited** unless individually attributable | N/A | N/A | Requires documented exception, compensating controls, and CISO approval per §4 (Exceptions) |
+
+---
+
+## 4. Data Sensitivity Classification (TLP)
+[Organization] classifies information using the [FIRST.org Traffic Light Protocol (TLP) 2.0](https://www.first.org/tlp/) — full scheme and handling requirements defined in the [Data Classification & Handling Policy](data_classification_policy.md), the canonical source. Systems and accounts **must** meet the minimum AAL for the most sensitive TLP-classified data they can access; where this exceeds the account type's minimum in §3, the **higher** value governs.
+
+| TLP Level | Meaning | Minimum AAL | Additional Controls |
+|---|---|---|---|
+| **TLP:CLEAR** | Disclosure not limited (public) | AAL1 (org default AAL2 baseline per §2.1 still applies to logins) | None beyond baseline |
+| **TLP:GREEN** | Limited disclosure, community-wide | AAL2 | Standard MFA |
+| **TLP:AMBER** | Limited disclosure, organization + need-to-know | AAL2 (AAL3 for privileged/admin access) | Access logged; least privilege |
+| **TLP:AMBER+STRICT** | Limited disclosure, organization only, no further sharing | AAL3 | Phishing-resistant MFA mandatory; no OOB; quarterly access review |
+| **TLP:RED** | Named recipients only | AAL3 | Phishing-resistant MFA mandatory; no OOB; per-access approval; full audit trail; break-glass accounts excluded from standing access |
+
+---
+
+## 5. Antifragility Alignment
+This policy is built to the five pillars of the organization's internal **Antifragile Enterprise Manifest**. Traceability from pillar to clause:
+
+| Pillar | Applied In | How |
+|---|---|---|
+| **1. Structural Decoupling** | §2.6, §2.11 | Documented IdP fallback path; 90-day vendor exit readiness — no single IdP/MFA vendor can hold the org hostage |
+| **2. Optionality Preservation** | §2.4, §2.9 | ≥2 MFA methods from independent implementations per user; ≥2 methods enrolled preserves the right to authenticate if one path fails |
+| **3. Stress-to-Signal Conversion** | §2.12, §2.13 | Every MFA bypass/outage/break-glass event forces a structural fix within 30 days; break-glass drilled quarterly with bounded blast radius and abort condition |
+| **4. Sovereign Intelligence** | §2.14 | IdP config, Conditional Access rules, break-glass procedure documented and owned — not tribal knowledge held by one admin |
+| **5. Asymmetric Payoff Design (Barbell)** | §2.1 (kill-chain tier), §3 (Account Type table) | Paranoid AAL3 concentrated on kill-chain systems (IdP, PKI roots, backup infra, break-glass vault) and privileged accounts; standard AAL2 baseline elsewhere — nothing moderate in the middle |
+
+---
+
+## 6. References
+- [NIST SP 800‑63B (Digital Identity Guidelines, 2023 update)](https://pages.nist.gov/800-63-3/sp800-63b.html)  
+- [CIS Controls v8.1 (Controls 5 & 6)](https://www.cisecurity.org/controls/v8-1)  
+- [ENISA Digital Identity and Data Protection](https://www.enisa.europa.eu/topics/digital-identity-and-data-protection)  
+- [OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)  

Security/business_continuity_dr_guidance.md

@@ -0,0 +1,37 @@
+# Business Continuity & Disaster Recovery Guidance
+
+**Document owner:** [Owner/Role]  
+**Approved by:** [Steering Committee / CISO]  
+**Effective date:** [YYYY-MM-DD]  
+**Review cadence:** [Annually]
+
+---
+
+## 1. Purpose & Scope
+Implementation guidance for the [Business Continuity & Disaster Recovery Policy](business_continuity_dr_policy.md). Applies to IT, system owners, and business continuity coordinators.
+
+---
+
+## 2. BIA — Practical Approach
+- Interview each business unit: "if this system is down for 4 hours / 24 hours / a week, what breaks?"  
+- Convert answers into RTO/RPO, then map to the tier table in policy §2.2 — don't let every system owner claim "critical," that defeats the tiering.
+
+## 3. Backup — 3-2-1-1 Pattern
+- **3** copies of data, **2** different media/storage types, **1** offsite, **1** offline/immutable — the extra "1" beyond the classic 3-2-1 is specifically to survive ransomware that targets connected backup systems.
+
+## 4. Greenfield Rebuild — What "Tested" Means
+- Not: "we have Terraform files somewhere."  
+- Yes: a scheduled exercise (can be non-production) that actually runs the documented rebuild process end-to-end and records how long it took and what broke in the documentation.  
+- Treat gaps found during the exercise as findings, feeding [Authentication Policy §2.12](authentication_policy.md) structural learning.
+
+## 5. DR Test Checklist
+✅ Full failover test run annually for kill-chain/critical systems, with results documented.  
+✅ Backup restoration spot-tested quarterly for kill-chain systems.  
+✅ Break-glass access confirmed to work if the primary IdP is the thing that's down (test this specifically — it's the scenario people forget).  
+✅ Greenfield rebuild capability exercised at least once every 5 years, findings tracked.
+
+---
+
+## 6. References
+- **[NIST SP 800-34 Rev. 1](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final)**  
+- **[ISO 22301:2019](https://www.iso.org/standard/75106.html)**  

Security/business_continuity_dr_policy.md

@@ -0,0 +1,63 @@
+# Business Continuity & Disaster Recovery Policy
+
+**Document owner:** [Owner/Role]  
+**Approved by:** [Steering Committee / CISO]  
+**Effective date:** [YYYY-MM-DD]  
+**Review cadence:** [Annually]
+
+---
+
+## 1. Purpose & Scope
+This policy establishes mandatory requirements for [Organization]'s ability to recover from disruption — outages, ransomware, natural disaster, or vendor failure. It applies to all systems, with the tightest requirements applied to kill-chain systems defined in [Authentication Policy §2.1](authentication_policy.md).
+
+---
+
+## 2. Policy Statements
+
+### 2.1 Business Impact Analysis (BIA)
+- A BIA **must** be conducted at least annually, identifying critical processes, dependencies, and acceptable downtime.
+
+### 2.2 Recovery Objectives by Tier
+| Tier | RTO (Recovery Time) | RPO (Recovery Point / max data loss) |
+|---|---|---|
+| Kill-chain (IdP, PKI, backup infra, break-glass vault) | ≤ 4 hours | ≤ 15 minutes |
+| Critical business systems | ≤ 24 hours | ≤ 4 hours |
+| Standard systems | ≤ 72 hours | ≤ 24 hours |
+| Low-priority systems | Best effort | Best effort |
+
+### 2.3 Backup Requirements
+- Backups **must** be encrypted (per [Secrets & Key Management Policy §2.3](secrets_management_policy.md)) and include at least one copy that is offline or immutable (air-gapped or WORM), unreachable by a compromised production credential.  
+- Backup restoration **must** be tested at least quarterly for kill-chain systems, annually for others.
+
+### 2.4 DR Testing
+- A full failover test **must** be conducted at least **annually** for kill-chain and critical systems.  
+- Tests **must** follow the calibrated-dose principle: bounded blast radius, non-production first where feasible, pre-agreed abort condition — consistent with [Authentication Policy §2.13](authentication_policy.md) and [Incident Response Policy §3.6](incident_response_policy.md).
+
+### 2.5 Break-Glass & Emergency Access During DR
+- DR procedures **must** account for break-glass account availability when the primary IdP is part of the outage — see [Authentication Policy §3](authentication_policy.md) and [§2.6](authentication_policy.md) (graceful degradation).
+
+### 2.6 Greenfield Rebuild Capability
+- [Organization] **must** maintain the documented, version-controlled capability to rebuild its environment from scratch — not merely restore from backup — at least once every **five years**, or on demand after a compromise where restoring from backup risks reintroducing the compromised state.  
+- This capability **must** be exercised, not just claimed on paper; an untested greenfield rebuild plan is treated the same as untested break-glass access.
+
+### 2.7 Enforcement
+- Systems without a current BIA, tested backup, or documented RTO/RPO **must** be remediated or formally excepted with CISO approval.
+
+---
+
+## 3. 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** | §2.6 | Greenfield rebuild capability is the ultimate expression of decoupling — the org can leave its own compromised/legacy state behind entirely |
+| **2. Optionality Preservation** | §2.3 | Offline/immutable backup copy preserves the option to recover even if the primary environment (and its credentials) is fully compromised |
+| **3. Stress-to-Signal Conversion** | §2.4 | DR tests are dosed exercises, not annual theater — findings feed structural fixes per [Authentication Policy §2.12](authentication_policy.md) |
+| **4. Sovereign Intelligence** | §2.6 | Rebuild capability requires documented, owned architecture knowledge — the antidote to "only Dave knows how this works" |
+| **5. Asymmetric Payoff Design (Barbell)** | §2.2 | 4-hour RTO concentrated on kill-chain systems; low-priority systems get best-effort — no moderate RTO spread evenly across everything |
+
+---
+
+## 4. References
+- **[NIST SP 800-34 Rev. 1, Contingency Planning Guide](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final)**  
+- **[ISO 22301:2019, Business Continuity Management Systems](https://www.iso.org/standard/75106.html)**  

Security/data_classification_guidance.md

@@ -0,0 +1,46 @@
+# Data Classification & Handling Guidance
+
+**Document owner:** [Owner/Role]  
+**Approved by:** [Steering Committee / CISO]  
+**Effective date:** [YYYY-MM-DD]  
+**Review cadence:** [Annually]
+
+---
+
+## 1. Purpose & Scope
+Implementation guidance for the [Data Classification & Handling Policy](data_classification_policy.md). Applies to IT, data owners, and system owners implementing labeling and handling controls.
+
+---
+
+## 2. Labeling — How To
+
+- **M365/Entra:** Use Microsoft Purview sensitivity labels mapped 1:1 to TLP levels (CLEAR/GREEN/AMBER/AMBER+STRICT/RED). Auto-apply default label per site/library; require justification to downgrade.  
+- **Cloud storage (S3/Blob/GCS):** Use bucket/object tags (`classification=TLP-AMBER`) enforced by policy-as-code (bucket policy or Conditional Access) rather than convention alone.  
+- **Code repositories:** Classification lives in the repo's README/CODEOWNERS metadata, not per-file — a repo touching RED material (e.g., PKI root config) is RED end-to-end.  
+- **Physical documents:** Header/footer stamp with TLP marking; RED documents numbered and logged at checkout.
+
+## 3. Worked Examples
+
+| Data | Classification | Why |
+|---|---|---|
+| Published blog post | TLP:CLEAR | Meant for public consumption |
+| Internal engineering wiki | TLP:GREEN | All staff, not for external release |
+| Customer contract | TLP:AMBER | Need-to-know within org |
+| Pending acquisition terms | TLP:AMBER+STRICT | Named individuals, market-moving if leaked |
+| Break-glass credentials, PKI root passphrase | TLP:RED | Compromise is existential — see [Authentication Policy §2.1 kill-chain tier](authentication_policy.md) |
+| Active incident forensics (mid-investigation) | TLP:RED → reclassify to TLP:AMBER once resolved | Protects investigation in progress; declassify per §3.4 once closed |
+
+## 4. DLP & Technical Enforcement Checklist
+✅ Sensitivity labels configured and auto-applied by default location.  
+✅ DLP policy blocks external email/share for AMBER+STRICT and RED labels.  
+✅ Encryption at rest enabled for all AMBER and above (see [Password Policy §2.7](password_policy_generic.md) for algorithm standards).  
+✅ Access logging enabled for AMBER+STRICT/RED storage locations.  
+✅ Quarterly review of unlabeled/default-classified content for drift.  
+✅ Printing/physical controls documented for RED material, if applicable.
+
+---
+
+## 5. References
+- **[FIRST.org Traffic Light Protocol (TLP) 2.0](https://www.first.org/tlp/)**  
+- **[NIST SP 800-60 Vol. 1 Rev. 1](https://csrc.nist.gov/pubs/sp/800/60/v1/r1/final)**  
+- **[ISO/IEC 27001:2022](https://www.iso.org/standard/27001)**  

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)**  

Security/data_retention_disposal_guidance.md

@@ -0,0 +1,43 @@
+# Data Retention & Disposal Guidance
+
+**Document owner:** [Owner/Role]  
+**Approved by:** [Steering Committee / CISO]  
+**Effective date:** [YYYY-MM-DD]  
+**Review cadence:** [Annually]
+
+---
+
+## 1. Purpose & Scope
+Implementation guidance for the [Data Retention & Disposal Policy](data_retention_disposal_policy.md). Applies to IT, data owners, and Legal.
+
+---
+
+## 2. Automating Retention
+- Use lifecycle policies native to the storage platform (M365 retention labels, S3 lifecycle rules, database TTL/partition-drop jobs) rather than relying on manual deletion — manual processes are the reason retention schedules drift into indefinite retention.  
+- Tag data at creation with its retention class so lifecycle rules can act on it automatically.
+
+## 3. Sanitization Method by Media
+| Media | Method |
+|---|---|
+| Cloud storage object | Cryptographic erasure (delete the key) or platform secure-delete API |
+| Local SSD/HDD (AMBER+ data) | Cryptographic erasure preferred; full-disk overwrite if unencrypted |
+| Physical media (RED data) | Physical destruction (shred/degauss), logged |
+| Backup tapes/snapshots | Expire per retention schedule; confirm deletion propagates, don't assume |
+
+## 4. Right-to-Erasure Workflow
+1. Verify requester identity.  
+2. Check for legal hold — if present, inform requester of the exception per §2.5 of the policy.  
+3. Delete from primary systems, then trigger backup propagation (or document why not, e.g., immutable backup within its retention window).  
+4. Confirm and log completion within the statutory window.
+
+## 5. Checklist
+✅ Retention schedule (policy §2.1) mapped to actual system lifecycle rules, not just written down.  
+✅ Legal hold process tested at least once with a mock hold.  
+✅ Backup deletion propagation verified, not assumed.  
+✅ Disposal of AMBER+STRICT/RED data logged with method and authorizer.
+
+---
+
+## 6. References
+- **[NIST SP 800-88 Rev. 2](https://csrc.nist.gov/pubs/sp/800/88/r2/final)**  
+- **[ISO/IEC 27001:2022](https://www.iso.org/standard/27001)**  

Security/data_retention_disposal_policy.md

@@ -0,0 +1,66 @@
+# Data Retention & Disposal Policy
+
+**Document owner:** [Owner/Role]  
+**Approved by:** [Steering Committee / CISO]  
+**Effective date:** [YYYY-MM-DD]  
+**Review cadence:** [Annually]
+
+---
+
+## 1. Purpose & Scope
+This policy establishes mandatory requirements for how long [Organization] retains data and how it is disposed of at end of life. It applies to all data classified under the [Data Classification & Handling Policy](data_classification_policy.md), and supports GDPR principles of storage limitation and the right to erasure (Art. 17).
+
+---
+
+## 2. Policy Statements
+
+### 2.1 Retention Schedule
+| Data Category | Classification | Retention Period |
+|---|---|---|
+| Financial records | TLP:AMBER | 7 years (statutory) |
+| Employee HR records | TLP:AMBER | Duration of employment + 6 years |
+| Customer personal data | TLP:AMBER | Duration of relationship + 2 years, or per contract |
+| Security/audit logs | TLP:AMBER | Per [Logging, Monitoring & Retention Policy §2.3](logging_monitoring_policy.md) |
+| Incident forensics | TLP:RED → AMBER on closure | 3 years from closure |
+| Marketing/public content | TLP:CLEAR | Business need, no mandated minimum |
+
+Retention periods **must not** exceed what is necessary for the stated business or legal purpose — indefinite retention is a violation of this policy, not a safe default.
+
+### 2.2 Legal Hold
+- Data subject to litigation, investigation, or regulatory hold **must** be preserved regardless of the schedule in §2.1 until the hold is lifted by Legal.
+
+### 2.3 Disposal & Destruction
+- Disposal method **must** match the classification level per [Data Classification Policy §3.3](data_classification_policy.md):  
+  - TLP:CLEAR/GREEN: standard deletion.  
+  - TLP:AMBER and above: secure delete/wipe or cryptographic erasure.  
+  - Physical media holding TLP:AMBER+STRICT/RED data: sanitized per [NIST SP 800-88](https://csrc.nist.gov/pubs/sp/800/88/r2/final) or physically destroyed.  
+- Disposal of AMBER+STRICT/RED data **must** be logged (what, when, method, who authorized).
+
+### 2.4 Backup Alignment
+- Backup retention **must not** silently extend the retention of data otherwise scheduled for deletion; deletion requests (including right-to-erasure) **must** propagate to backups within a defined window (**≤90 days**) or be documented as a technical exception.
+
+### 2.5 Right to Erasure
+- Verified erasure requests **must** be fulfilled within the statutory window (GDPR: without undue delay, within 1 month, extendable to 3).  
+- Exceptions (legal hold, legitimate business need) **must** be documented and communicated to the requester where required by law.
+
+### 2.6 Enforcement
+- Data retained past its scheduled disposal date without a documented legal hold or exception **must** be treated as a policy violation and remediated.
+
+---
+
+## 3. 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** | §2.4 | Deletion propagating to backups prevents "the vendor's backup system" from becoming a hidden place data outlives its intended lifecycle |
+| **2. Optionality Preservation** | §2.1 | Disciplined retention avoids the illusion of value in hoarded data that later becomes a liability with no offsetting benefit |
+| **3. Stress-to-Signal Conversion** | §2.6 | Data found past its disposal date is a tracked finding, not a shrug |
+| **4. Sovereign Intelligence** | §2.3 | Disposal of sensitive data is logged and owned — auditable proof, not an assumption |
+| **5. Asymmetric Payoff Design (Barbell)** | §2.3 | Cryptographic erasure/physical destruction concentrated on AMBER+STRICT/RED; CLEAR/GREEN gets standard deletion — no moderate process applied to everything |
+
+---
+
+## 4. References
+- **[NIST SP 800-88 Rev. 2, Guidelines for Media Sanitization](https://csrc.nist.gov/pubs/sp/800/88/r2/final)**  
+- **[ISO/IEC 27001:2022](https://www.iso.org/standard/27001)**  

Security/incident_response_guidance.md

@@ -0,0 +1,45 @@
+# Incident Response Guidance
+
+**Document owner:** [Owner/Role]  
+**Approved by:** [Steering Committee / CISO]  
+**Effective date:** [YYYY-MM-DD]  
+**Review cadence:** [Annually]
+
+---
+
+## 1. Purpose & Scope
+Implementation guidance for the [Incident Response Policy](incident_response_policy.md). Applies to the IR team and all staff as first reporters.
+
+---
+
+## 2. Severity Triage — Quick Reference
+| Question | If Yes |
+|---|---|
+| Kill-chain system involved (IdP, PKI, backup, break-glass)? | SEV1 |
+| TLP:AMBER+STRICT/RED data confirmed exposed? | SEV1/SEV2 |
+| Contained to one endpoint, no lateral movement seen? | SEV3 |
+| Just an anomaly, nothing confirmed yet? | SEV4, investigate before downgrading further |
+
+## 3. Post-Mortem Template (Blameless)
+1. Timeline — what happened, when, who/what detected it.  
+2. Root cause — technical, not "human error" as a final answer; ask what let the human error matter.  
+3. What worked — don't only harvest failures.  
+4. Structural change — the mandatory output per policy §3.5. Must be a policy, architecture, or control change, not just "we'll be more careful."  
+5. Owner and due date for the structural change.
+
+## 4. Tabletop Exercise — Calibrated Dose Checklist
+✅ Scope defined and bounded before starting (which systems, which team).  
+✅ Abort condition agreed in advance ("if X happens, we stop and debrief").  
+✅ Non-production/simulated scenario before ever touching production for the first run of a new scenario type.  
+✅ Findings captured and fed into the post-mortem template above, even for a successful exercise.
+
+## 5. Notification Timeline Cheat Sheet
+- T+1h: internal report and triage.  
+- T+72h: GDPR breach notification assessment complete (notify if required).  
+- Ongoing: customer/partner notification per contract, coordinated through Legal — don't let engineering notify unilaterally.
+
+---
+
+## 6. References
+- **[NIST SP 800-61 Rev. 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final)**  
+- **[ENISA Digital Identity and Data Protection](https://www.enisa.europa.eu/topics/digital-identity-and-data-protection)**  

Security/incident_response_policy.md

@@ -0,0 +1,75 @@
+# Incident Response Policy
+
+**Document owner:** [Owner/Role]  
+**Approved by:** [Steering Committee / CISO]  
+**Effective date:** [YYYY-MM-DD]  
+**Review cadence:** [Annually]
+
+---
+
+## 1. Purpose & Scope
+This policy establishes mandatory requirements for detecting, responding to, and learning from security incidents at [Organization]. It applies to all employees, contractors, vendors, and systems.
+
+---
+
+## 2. Roles & Responsibilities
+- **Incident Response Lead:** Owns the response, coordinates the IR team, declares severity.  
+- **IR Team:** Technical responders (security, IT, relevant system owners).  
+- **Communications/Legal:** Owns external notification and regulatory reporting.  
+- **All Users:** Must report suspected incidents immediately via the designated channel.
+
+---
+
+## 3. Policy Statements
+
+### 3.1 Incident Classification
+| Severity | Criteria | Example |
+|---|---|---|
+| **SEV1 (Critical)** | Kill-chain system compromise, confirmed breach of TLP:RED data, ransomware | Domain admin credential compromise |
+| **SEV2 (High)** | Confirmed unauthorized access to TLP:AMBER+STRICT data, significant service outage | Break-glass account misuse |
+| **SEV3 (Medium)** | Contained incident, limited scope, no confirmed data loss | Isolated phishing click, malware on one endpoint |
+| **SEV4 (Low)** | Suspicious activity requiring investigation, no confirmed impact | Failed login anomaly |
+
+Incident details **must** be handled at the TLP level of the data involved (per [Data Classification Policy](data_classification_policy.md)) — most active investigations default to **TLP:RED**.
+
+### 3.2 Detection & Reporting
+- Suspected incidents **must** be reported within **1 hour** of discovery via the designated channel.  
+- Automated alerts from [Logging, Monitoring & Retention Policy §2.4](logging_monitoring_policy.md) feed directly into triage.
+
+### 3.3 Response Lifecycle
+[Organization] follows the NIST incident response lifecycle: **Preparation → Detection & Analysis → Containment, Eradication & Recovery → Post-Incident Activity.**
+- Containment decisions **must** balance evidence preservation against stopping active damage; kill-chain systems favor immediate isolation.
+
+### 3.4 Notification Requirements
+- Regulatory breach notification (e.g., GDPR Art. 33) **must** be assessed within **72 hours** of becoming aware of a personal data breach.  
+- Affected customers/partners **must** be notified per contractual and legal obligations, coordinated through Legal/Communications.
+
+### 3.5 Structural Post-Mortem Mandate
+- Every SEV1/SEV2 incident **must** produce a blameless post-mortem with **at least one structural change** (policy, architecture, or control) within **30 days**, per [Authentication Policy §2.12](authentication_policy.md).  
+- Findings **must** be tracked to closure; a recurring root cause without a structural fix is itself a policy violation.
+
+### 3.6 Exercises
+- Tabletop exercises **must** be run at least **semi-annually**.  
+- Exercises **must** follow the calibrated-dose principle: non-production before production scope, a bounded blast radius, and a pre-agreed abort condition — see [Authentication Policy §2.13](authentication_policy.md) for the same principle applied to break-glass drills.
+
+### 3.7 Enforcement
+- Failure to report a known incident **may** result in disciplinary action.
+
+---
+
+## 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 | Containment favors isolating the affected system over hoping the blast radius stays small on its own |
+| **2. Optionality Preservation** | §3.3 | Evidence preservation vs. containment is a deliberate trade-off, not a forced default that removes options later |
+| **3. Stress-to-Signal Conversion** | §3.5, §3.6 | This is the pillar's home policy: every SEV1/2 forces a structural fix; drills are dosed, bounded, and abortable |
+| **4. Sovereign Intelligence** | §2 | Named IR Lead and team; incident knowledge captured in post-mortems, not lost when responders move on |
+| **5. Asymmetric Payoff Design (Barbell)** | §3.1 | Severity tiers concentrate response urgency and TLP:RED confidentiality on kill-chain/critical incidents |
+
+---
+
+## 5. References
+- **[NIST SP 800-61 Rev. 3, Incident Response Recommendations (CSF 2.0 Profile)](https://csrc.nist.gov/pubs/sp/800/61/r3/final)**  
+- **[ENISA Digital Identity and Data Protection](https://www.enisa.europa.eu/topics/digital-identity-and-data-protection)**  

Security/logging_monitoring_guidance.md

@@ -0,0 +1,42 @@
+# Logging, Monitoring & Retention Guidance
+
+**Document owner:** [Owner/Role]  
+**Approved by:** [Steering Committee / CISO]  
+**Effective date:** [YYYY-MM-DD]  
+**Review cadence:** [Annually]
+
+---
+
+## 1. Purpose & Scope
+Implementation guidance for the [Logging, Monitoring & Retention Policy](logging_monitoring_policy.md). Applies to IT, security operations, and system owners.
+
+---
+
+## 2. Log Source Priority Checklist
+Wire these up first — they're the ones an attacker needs to touch:
+1. IdP/authentication logs (sign-in, MFA, admin role changes).  
+2. PKI/CA and backup infrastructure access logs.  
+3. Secret manager retrieval logs.  
+4. Privileged/admin action logs (EDR, cloud audit logs, AD/Entra audit logs).  
+5. Everything else, as capacity allows.
+
+## 3. Retention Tiering — Practical Setup
+- Hot/searchable tier: 90 days, fast query for active investigation.  
+- Warm/archived tier: remainder of retention period (per policy §2.3 table), cheaper storage, slower retrieval, still admissible for audits.  
+- Kill-chain system logs: consider a separate, stricter-access archive so a compromised SIEM admin account can't touch the evidence of its own misuse.
+
+## 4. Alert Tuning
+- Start narrow (break-glass checkout, kill-chain admin actions) and expand — broad noisy alerting trains responders to ignore alerts, which defeats the point.  
+- Review false-positive rate monthly for the first quarter after any new alert rule; quarterly thereafter.
+
+## 5. Checklist
+✅ Centralized log shipping configured for all kill-chain and privileged systems.  
+✅ Logs are append-only/WORM where the platform supports it.  
+✅ Real-time alert on break-glass checkout, verified with a test invocation.  
+✅ Retention schedule matches the table in policy §2.3, reviewed against [Data Retention & Disposal Policy](data_retention_disposal_policy.md) for personal-data-bearing logs.
+
+---
+
+## 6. References
+- **[NIST SP 800-92, Guide to Computer Security Log Management](https://csrc.nist.gov/pubs/sp/800/92/final)**  
+- **[CIS Controls v8.1 (Control 8)](https://www.cisecurity.org/controls/v8-1)**  

Security/logging_monitoring_policy.md

@@ -0,0 +1,68 @@
+# Logging, Monitoring & Retention Policy
+
+**Document owner:** [Owner/Role]  
+**Approved by:** [Steering Committee / CISO]  
+**Effective date:** [YYYY-MM-DD]  
+**Review cadence:** [Annually]
+
+---
+
+## 1. Purpose & Scope
+This policy establishes mandatory requirements for security-relevant logging, centralized monitoring, and log retention across [Organization] systems. It applies to all systems that authenticate users, process TLP:AMBER or above data, or sit in the kill-chain tier defined in [Authentication Policy §2.1](authentication_policy.md).
+
+---
+
+## 2. Policy Statements
+
+### 2.1 What Must Be Logged
+- Authentication events (success, failure, MFA resets, break-glass invocation).  
+- Administrative/privileged actions (permission changes, configuration changes to IdP/PKI/backup systems).  
+- Access to TLP:AMBER+STRICT/RED data (per [Data Classification Policy §3.3](data_classification_policy.md)).  
+- Secret retrieval events (per [Secrets & Key Management Policy §2.4](secrets_management_policy.md)).  
+- System/network security events (firewall denies, IDS/IPS alerts, endpoint detections).
+
+### 2.2 Log Protection
+- Logs **must** be shipped to a centralized, access-restricted store (SIEM or equivalent) separate from the systems that generate them.  
+- Logs **must** be tamper-evident (append-only/WORM where the platform supports it); local-only logs are not sufficient for kill-chain systems.  
+- Access to raw logs **must** follow least privilege (per [Access Control Policy §3.1](access_control_policy.md)).
+
+### 2.3 Retention Periods
+| Log Type | Minimum Retention |
+|---|---|
+| Authentication & MFA events | 1 year |
+| Privileged/admin action logs | 2 years |
+| Kill-chain system logs (IdP, PKI, backup, break-glass) | 3 years |
+| Standard application/security logs | 1 year |
+| Network/firewall logs | 90 days online, 1 year archived |
+
+Retention **must not** exceed the schedule defined in the (forthcoming) Data Retention & Disposal Policy for logs containing personal data.
+
+### 2.4 Monitoring & Alerting
+- Real-time alerting **must** be configured for: break-glass checkout, kill-chain system access, MFA resets, and privileged role changes.  
+- Alert thresholds **must** be reviewed at least annually to reduce false-positive fatigue without silencing genuine signal.
+
+### 2.5 Log Review Cadence
+- Automated alerting is primary; manual review of aggregate trends **must** occur at least monthly for kill-chain systems.
+
+### 2.6 Enforcement
+- Systems that cannot ship logs to the central store **must** be remediated or formally excepted with CISO approval and a compensating control.
+
+---
+
+## 3. 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** | §2.2 | Logs shipped off-system to a store independent of the generating platform — a compromised host can't erase its own evidence |
+| **2. Optionality Preservation** | §2.2 | Centralized store in standard formats avoids lock-in to one SIEM vendor's proprietary log format |
+| **3. Stress-to-Signal Conversion** | §2.1, §2.4 | Instrumenting kill-chain and privileged events is the raw material for the structural post-mortems required in [Authentication Policy §2.12](authentication_policy.md) |
+| **4. Sovereign Intelligence** | §2.5 | Log review findings are tracked and owned, not left as raw data no one reads |
+| **5. Asymmetric Payoff Design (Barbell)** | §2.3 | 3-year retention and real-time alerting concentrated on kill-chain systems; standard logs get the lean 1-year baseline |
+
+---
+
+## 4. References
+- **[NIST SP 800-92, Guide to Computer Security Log Management](https://csrc.nist.gov/pubs/sp/800/92/final)**  
+- **[CIS Controls v8.1 (Control 8)](https://www.cisecurity.org/controls/v8-1)**  
+- **[ISO/IEC 27001:2022](https://www.iso.org/standard/27001)**  

Security/password_guidance_generic.md

@@ -41,7 +41,7 @@ It applies to IT, IAM administrators, and system owners.
 
 ### 2.5 Multi-Factor Authentication (MFA)
 - Require MFA for:  
-  - All external-facing logins.  
+  - All employee logins, SaaS, and external-facing systems (AAL2 baseline).  
   - Administrative access.  
   - Remote access (VPN, SSH, RDP, portals).  
   - Systems handling **sensitive or regulated data**.  
@@ -58,7 +58,7 @@ It applies to IT, IAM administrators, and system owners.
 - Store passwords using:  
   - **Argon2id (preferred)**, or  
   - **bcrypt** / **PBKDF2** with high work factor.  
-- Use **unique salts** (≥32 bits) per credential.  
+- Use **unique salts** (≥128 bits) per credential.  
 - Consider adding a server-side **“pepper”** stored securely (HSM/TEE).
 
 ### 2.8 Resets & Recovery
@@ -103,10 +103,11 @@ Applications authenticating users **must**:
 ✅ Require password manager compatibility (paste/show-password).  
 ✅ Review and disable legacy authentication protocols (e.g., plain text FTP/POP/IMAP, NTLMv1).  
 ✅ Audit password changes, resets, and lockout events.  
+✅ Split-knowledge/dual-control on kill-chain secrets (PKI root, backup keys, break-glass vault) per §2.13 — nothing moderate applied broadly instead.  
 
 ---
 
 ## 4) References
-- **NIST SP 800-63B, Digital Identity Guidelines (2023 update)**  
-- **CIS Controls v8.1 (Controls 5 & 6)**  
-- **OWASP Authentication Cheat Sheet**  
+- **[NIST SP 800-63B, Digital Identity Guidelines (2023 update)](https://pages.nist.gov/800-63-3/sp800-63b.html)**  
+- **[CIS Controls v8.1 (Controls 5 & 6)](https://www.cisecurity.org/controls/v8-1)**  
+- **[OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)**  

Security/password_guidance_m365_ad.md

@@ -64,7 +64,7 @@ This policy defines requirements for passwords and related authenticator handlin
 
 ## 6) Storage & transmission
 - All AD/M365 authentication happens over **TLS**.  
-- Passwords stored as **salted, hashed verifiers** (NTLMv2/Kerberos with AES).  
+- Prefer **Kerberos (AES)** over NTLM: the NTLM/NT hash is **unsalted**, a known pass-the-hash weakness — disabling NTLMv1/LM does not fix this, it only removes the weakest variants.  
 - Domain controllers must disable **NTLMv1** and LM hashes.  
 - Use **Argon2id/bcrypt** if custom apps store passwords.
 
@@ -119,7 +119,8 @@ Apps authenticating against AD or Entra ID must:
 - ✅ Disable **legacy auth protocols** (POP, IMAP, SMTP Basic, NTLMv1).  
 - ✅ Review dormant accounts quarterly (disable after 45 days).  
 - ✅ Require TLS 1.2+ for all endpoints.  
-- ✅ Audit password changes and lockout events.
+- ✅ Audit password changes and lockout events.  
+- ✅ Split-knowledge/dual-control on Enterprise Admin break-glass, AD FS/Entra Connect secrets, PKI root per §2.13 — concentrate protection there, not spread thin everywhere.
 
 ---
 
@@ -129,8 +130,8 @@ Apps authenticating against AD or Entra ID must:
 ---
 
 ## 14) References
-- **NIST SP 800-63B, Digital Identity Guidelines (2023 update)**  
-- **CIS Controls v8.1** (Controls 5 & 6)  
-- **Microsoft Security Baselines (Windows, AD, M365)**  
-- **OWASP Authentication Cheat Sheet**
+- **[NIST SP 800-63B, Digital Identity Guidelines (2023 update)](https://pages.nist.gov/800-63-3/sp800-63b.html)**  
+- **[CIS Controls v8.1](https://www.cisecurity.org/controls/v8-1)** (Controls 5 & 6)  
+- **[Microsoft Security Baselines (Windows, AD, M365)](https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/windows-security-configuration-framework/windows-security-baselines)**  
+- **[OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)**
 

Security/password_policy_generic.md

@@ -22,6 +22,7 @@ This policy establishes mandatory requirements for password creation, management
 ### 2.2 Complexity
 - Passwords **must not** be subject to composition rules requiring upper/lowercase, numbers, or symbols.  
 - Passwords **must** be screened against a blocklist of weak, common, or compromised passwords.  
+- Passwords **must not** match the user's current password or any of the last **5** passwords (where technically supported).  
 
 ### 2.3 Expiration
 - Passwords **shall not** expire on a scheduled basis.  
@@ -34,6 +35,7 @@ This policy establishes mandatory requirements for password creation, management
 
 ### 2.5 Multi-Factor Authentication (MFA)
 - MFA **must** be enforced for:  
+  - All employee, SaaS, and external-facing logins (per Authentication Policy AAL2 baseline)  
   - Remote access  
   - Administrative access  
   - Access to sensitive data or critical systems  
@@ -76,6 +78,11 @@ Applications authenticating users:
 - **Must** allow paste/autofill and must not truncate passwords.  
 - **Must** store verifiers using modern password hashing methods.
 
+### 2.13 Kill-Chain Credential Protection (Barbell Principle)
+- Credentials that gate existential systems — PKI/CA root passphrases, backup encryption keys, break-glass vault master credentials, HSM activation secrets — **must** receive protection disproportionate to ordinary accounts: **split-knowledge / dual control** (no single person holds the complete secret), physical or HSM-backed storage, and access logged with real-time alerting.  
+- Do **not** spread equivalent extra effort across low-value accounts — moderate protection applied broadly buys neither real security for what matters nor economy for what doesn't. Concentrate paranoia on the kill-chain few; keep the baseline (§2.1–§2.12) lean everywhere else.  
+- Full requirements and rotation cadence: see [Secrets & Key Management Policy §2.5](secrets_management_policy.md) — canonical source for this control.
+
 ---
 
 ## 3) Enforcement
@@ -91,6 +98,6 @@ Applications authenticating users:
 ---
 
 ## 5) References
-- **NIST SP 800-63B, Digital Identity Guidelines (2023 update)**  
-- **CIS Controls v8.1, Controls 5 & 6**  
-- **OWASP Authentication Cheat Sheet**  
+- **[NIST SP 800-63B, Digital Identity Guidelines (2023 update)](https://pages.nist.gov/800-63-3/sp800-63b.html)**  
+- **[CIS Controls v8.1, Controls 5 & 6](https://www.cisecurity.org/controls/v8-1)**  
+- **[OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)**  

Security/password_policy_m365_ad.md

@@ -22,6 +22,7 @@ This policy establishes mandatory requirements for password creation, management
 ### 2.2 Complexity
 - Passwords **must not** be subject to complexity rules requiring upper/lowercase, numbers, or symbols.  
 - Passwords **shall** be screened against a blocklist of weak, common, and compromised passwords using **Azure AD Password Protection**.  
+- Passwords **must not** match the user's current password or any of the last **5** passwords (where technically supported).  
 
 ### 2.3 Expiration
 - Passwords **shall not** expire on a scheduled basis.  
@@ -47,7 +48,7 @@ This policy establishes mandatory requirements for password creation, management
 
 ### 2.7 Storage & Transmission
 - Passwords **must** only be transmitted over encrypted channels (TLS 1.2+).  
-- AD and M365 **must** store passwords as salted and hashed verifiers.  
+- AD and M365 authentication **must** rely on Kerberos (AES) rather than NTLM where possible; the legacy NT hash used by NTLM is **unsalted** and vulnerable to pass-the-hash attacks, so NTLM use **should** be minimized even with NTLMv1/LM disabled.  
 - NTLMv1 and LAN Manager (LM) hashes **must** be disabled.  
 - Custom applications **must** use Argon2id, bcrypt, or PBKDF2 for password storage.
 
@@ -78,6 +79,11 @@ Applications authenticating against AD or Entra ID:
 - **Must** allow paste/autofill and must not truncate passwords.  
 - **Must** store verifiers using modern password hashing methods if not federated.
 
+### 2.13 Kill-Chain Credential Protection (Barbell Principle)
+- Credentials gating existential systems — Enterprise Admin/Domain Admin break-glass credentials, AD FS/Entra Connect service account secrets, PKI/CA root passphrases (if operating internal PKI), Bitlocker/backup recovery key escrow master access — **must** receive protection disproportionate to ordinary accounts: **split-knowledge / dual control**, HSM or sealed-vault storage, and real-time alerting on access.  
+- Do **not** spread equivalent extra effort across low-value accounts — concentrate paranoia on this small kill-chain set; keep the AAL2 baseline (§2.1–§2.12) lean everywhere else.  
+- Full requirements and rotation cadence: see [Secrets & Key Management Policy §2.5](secrets_management_policy.md) — canonical source for this control.
+
 ---
 
 ## 3) Enforcement
@@ -93,7 +99,7 @@ Applications authenticating against AD or Entra ID:
 ---
 
 ## 5) References
-- **NIST SP 800-63B, Digital Identity Guidelines (2023 update)**  
-- **CIS Controls v8.1, Controls 5 & 6**  
-- **Microsoft Security Baselines (M365 & Windows/AD)**  
-- **OWASP Authentication Cheat Sheet**  
+- **[NIST SP 800-63B, Digital Identity Guidelines (2023 update)](https://pages.nist.gov/800-63-3/sp800-63b.html)**  
+- **[CIS Controls v8.1, Controls 5 & 6](https://www.cisecurity.org/controls/v8-1)**  
+- **[Microsoft Security Baselines (M365 & Windows/AD)](https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/windows-security-configuration-framework/windows-security-baselines)**  
+- **[OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)**  

Security/secrets_management_guidance.md

@@ -0,0 +1,40 @@
+# Secrets & Key Management Guidance
+
+**Document owner:** [Owner/Role]  
+**Approved by:** [Steering Committee / CISO]  
+**Effective date:** [YYYY-MM-DD]  
+**Review cadence:** [Annually]
+
+---
+
+## 1. Purpose & Scope
+Implementation guidance for the [Secrets & Key Management Policy](secrets_management_policy.md). Applies to engineering, IT/IAM, and system owners.
+
+---
+
+## 2. Approved Tooling Patterns
+- **Cloud-native:** Azure Key Vault, AWS Secrets Manager/KMS, GCP Secret Manager — prefer platform-native over a bolted-on third party where the platform is already the trust boundary.  
+- **Self-hosted/hybrid:** HashiCorp Vault with auto-unseal via cloud KMS.  
+- **CI/CD:** Secrets injected at runtime via OIDC federation (no long-lived cloud credentials stored in the CI system) — see [OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html).
+
+## 3. Split-Knowledge — How To (Kill-Chain Secrets)
+Practical patterns for §2.5:
+- **Shamir's Secret Sharing** (e.g., via HSM or `ssss`) to split a root key across ≥3 custodians with a quorum (e.g., 2-of-3) to reconstruct.  
+- Two named custodians each hold half a passphrase; both required to unseal.  
+- HSM-native M-of-N key ceremony (common for PKI root CA generation) — documented, witnessed, and recorded.
+
+## 4. Secret Scanning
+- Enable pre-commit and CI-time secret scanning (e.g., gitleaks, trufflehog, or platform-native scanning) on every repository.  
+- A detected secret **must** be rotated immediately, even if the commit is reverted — git history retains it.
+
+## 5. Rotation Automation Checklist
+✅ Service account secrets rotate automatically every ≤90 days, no manual step.  
+✅ TLS certificates auto-renew (ACME/cert-manager or equivalent) with alerting on renewal failure.  
+✅ Kill-chain secrets have a calendar-enforced annual rotation with two-person sign-off.  
+✅ Secret manager audit log retained and reviewed — see also [Password Guidance §2.2](password_guidance_generic.md) for blocklist/rotation cadence context.
+
+---
+
+## 6. References
+- **[NIST SP 800-57 Part 1 Rev. 5](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final)**  
+- **[OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html)**  

Security/secrets_management_policy.md

@@ -0,0 +1,84 @@
+# Secrets & Key Management Policy
+
+**Document owner:** [Owner/Role]  
+**Approved by:** [Steering Committee / CISO]  
+**Effective date:** [YYYY-MM-DD]  
+**Review cadence:** [Annually]
+
+---
+
+## 1. Purpose & Scope
+This policy establishes mandatory requirements for the generation, storage, access, rotation, and retirement of secrets and cryptographic keys — API keys, service credentials, TLS certificates, encryption keys, and signing keys — across [Organization] systems. It applies to all employees, contractors, and systems that create or consume secrets.
+
+This policy is the **canonical source** for cryptographic algorithm/parameter standards and kill-chain secret handling referenced elsewhere in this repository (e.g., [Password Policy §2.13](password_policy_generic.md), [Password Policy (M365/AD) §2.13](password_policy_m365_ad.md)).
+
+---
+
+## 2. Policy Statements
+
+### 2.1 Secret Inventory & Ownership
+- Every secret **must** have a named owner and a documented purpose.  
+- An inventory of active secrets **must** be maintained in the approved secret manager; secrets with no identifiable owner **must** be rotated and reassigned or retired within 30 days of discovery.
+
+### 2.2 Storage
+- Secrets **must** be stored only in an approved secret manager, key vault, or HSM.  
+- Secrets **must not** be stored in source code, config files committed to version control, tickets, chat messages, or shared documents.  
+- Any secret found outside an approved store **must** be treated as compromised: rotated immediately, not just relocated.
+
+### 2.3 Cryptographic Standards
+| Purpose | Approved | Minimum Parameters |
+|---|---|---|
+| Password hashing | Argon2id (preferred), bcrypt, PBKDF2 | Argon2id: memory ≥19 MiB, iterations ≥2; per-credential unique salt ≥128 bits |
+| Symmetric encryption at rest | AES-256-GCM | Unique IV/nonce per operation |
+| Transport encryption | TLS 1.2 minimum, TLS 1.3 preferred | Modern cipher suites only; disable TLS 1.0/1.1 |
+| Asymmetric keys | RSA ≥3072-bit, ECDSA P-256 or higher | — |
+| Signing | Ed25519 or ECDSA P-256+ | — |
+| Legacy/weak algorithms (MD5, SHA-1 for integrity, DES/3DES, RC4, NTLMv1) | **Prohibited** for new use; existing use tracked as a remediation item | — |
+
+### 2.4 Access Control
+- Access to secrets **must** follow least privilege and, where supported, just-in-time elevation.  
+- All secret retrieval **must** be logged (who, what, when).  
+- Human access to production secrets **should** be exceptional and time-bound; services **must** authenticate via managed identity/certificate rather than a retrieved static secret where the platform supports it.
+
+### 2.5 Kill-Chain Secrets (Barbell Principle)
+Secrets gating existential systems — PKI/CA root passphrases, backup/DR encryption master keys, break-glass vault master credentials, HSM activation secrets — **must** receive protection disproportionate to ordinary secrets:
+- **Split-knowledge / dual control**: no single person holds the complete secret.  
+- Physical or HSM-backed storage, not a general-purpose secret manager.  
+- Real-time alerting on access; access requires a second approver.  
+- Do **not** spread equivalent extra effort across low-value secrets — concentrate paranoia here; keep §2.2–§2.4 lean everywhere else.
+
+### 2.6 Rotation & Expiry
+| Secret Type | Rotation Cadence |
+|---|---|
+| Human-facing passwords | Incident-driven only (no scheduled expiry, per [Password Policy §2.3](password_policy_generic.md)) |
+| Service account secrets / API keys | Automated, ≤90 days |
+| TLS certificates | Before expiry, automated renewal preferred |
+| Kill-chain secrets (§2.5) | Annually, or immediately after any custodian change |
+| Any secret suspected compromised | Immediately |
+
+### 2.7 Secret Compromise Response
+- A suspected or confirmed secret compromise **must** trigger immediate rotation, revocation of derived sessions/tokens, and a structural post-mortem per [Authentication Policy §2.12](authentication_policy.md).
+
+### 2.8 Enforcement
+- Violations **may** result in disciplinary action or revocation of access.  
+- Secrets discovered in version control history **must** be rotated even after removal from the current commit — history does not un-leak a secret.
+
+---
+
+## 3. 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** | §2.4 | Services authenticate via managed identity/certificate rather than a portable static secret where possible — removes a class of dependency entirely |
+| **2. Optionality Preservation** | §2.3 | Standardized, non-proprietary algorithms (AES, Argon2id, ECDSA) avoid lock-in to a single vendor's crypto scheme |
+| **3. Stress-to-Signal Conversion** | §2.7 | Every compromised secret forces a structural post-mortem, not just a quiet rotation |
+| **4. Sovereign Intelligence** | §2.1 | Named owner per secret; inventory is owned and current, not tribal knowledge of "whoever set it up" |
+| **5. Asymmetric Payoff Design (Barbell)** | §2.5 | Split-knowledge/HSM concentrated on kill-chain secrets; ordinary secrets get the lean baseline — nothing moderate spread everywhere |
+
+---
+
+## 4. References
+- **[NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final)**  
+- **[OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html)**  
+- **[OWASP Cryptographic Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html)**  

Security/secure_sdlc_guidance.md

@@ -0,0 +1,41 @@
+# Secure SDLC Guidance
+
+**Document owner:** [Owner/Role]  
+**Approved by:** [Steering Committee / CISO]  
+**Effective date:** [YYYY-MM-DD]  
+**Review cadence:** [Annually]
+
+---
+
+## 1. Purpose & Scope
+Implementation guidance for the [Secure Software Development Lifecycle Policy](secure_sdlc_policy.md). Applies to engineering teams.
+
+---
+
+## 2. Tooling Patterns
+- **SAST:** run in CI on every PR, not just nightly — catch it before merge, not after.  
+- **Dependency scanning:** Dependabot/Renovate + a vulnerability scanner (e.g., Snyk, Trivy, `npm audit`/`pip-audit`) gated in CI.  
+- **SBOM:** generate via CycloneDX or SPDX tooling as a build artifact, not a one-off manual exercise.  
+- **Secret scanning:** pre-commit hook + CI-time scan — see [Secrets & Key Management Guidance §4](secrets_management_guidance.md).
+
+## 3. ASVS Level — How to Decide
+- Level 1: internal tools, low sensitivity, no kill-chain adjacency.  
+- Level 2: anything externally exposed, anything touching TLP:AMBER+ data, anything adjacent to a kill-chain system per [Authentication Policy §2.1](authentication_policy.md).  
+- Level 3: reserve for the kill-chain systems themselves (IdP, PKI, payment processing) — not the default; apply deliberately.
+
+## 4. Threat Modeling — Lightweight Version
+- STRIDE walkthrough in a design doc before build starts for anything hitting ASVS Level 2+.  
+- Doesn't need a dedicated meeting for every feature — fold it into design review for qualifying systems only.
+
+## 5. Checklist
+✅ SAST + dependency scan gates block merge on new critical/high findings.  
+✅ SBOM generated per production build.  
+✅ Threat model documented for kill-chain-adjacent systems before build.  
+✅ Pen test scheduled annually for externally exposed production apps.  
+✅ No hardcoded secrets — verified by scanner, not just code review.
+
+---
+
+## 6. References
+- **[NIST SP 800-218 (SSDF)](https://csrc.nist.gov/pubs/sp/800/218/final)**  
+- **[OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/)**  

Security/secure_sdlc_policy.md

@@ -0,0 +1,60 @@
+# Secure Software Development Lifecycle (SDLC) Policy
+
+**Document owner:** [Owner/Role]  
+**Approved by:** [Steering Committee / CISO]  
+**Effective date:** [YYYY-MM-DD]  
+**Review cadence:** [Annually]
+
+---
+
+## 1. Purpose & Scope
+This policy establishes mandatory secure development requirements for software built or materially customized by [Organization]. It applies to all engineering teams and to third-party developers per the [Vendor & Third-Party Risk Management Policy](vendor_risk_management_policy.md).
+
+---
+
+## 2. Policy Statements
+
+### 2.1 Secure Design & Threat Modeling
+- New systems handling TLP:AMBER+STRICT/RED data or touching kill-chain infrastructure (per [Authentication Policy §2.1](authentication_policy.md)) **must** undergo threat modeling before implementation begins.
+
+### 2.2 Secure Coding Standards
+- Applications **must** meet [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/) Level 1 minimum; kill-chain-adjacent and externally exposed applications **must** meet Level 2.  
+- Authentication implementations **must** conform to [Authentication Policy](authentication_policy.md) and [OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html).
+
+### 2.3 Dependency & Supply Chain Security
+- A Software Bill of Materials (SBOM) **must** be generated for production applications.  
+- Dependencies **must** be scanned for known vulnerabilities on every build; findings follow the SLA in [Vulnerability & Patch Management Policy §2.2](vulnerability_patch_management_policy.md).  
+- Dependency pinning **must** be used; automatic unpinned upgrades to production are prohibited.
+
+### 2.4 Code Review & Analysis
+- All production code changes **must** be peer reviewed before merge.  
+- Static analysis (SAST) **must** run on every build; dynamic analysis (DAST) **must** run at least before each production release for externally exposed applications.
+
+### 2.5 Secrets in Code
+- Secrets **must not** be committed to source control — see [Secrets & Key Management Policy §2.2](secrets_management_policy.md) and its secret-scanning guidance.
+
+### 2.6 Penetration Testing
+- Kill-chain-adjacent and externally exposed production applications **must** undergo penetration testing at least annually and after material architecture change.
+
+### 2.7 Enforcement
+- Production deployment **must not** proceed without passing SAST and dependency scanning gates, absent a documented, time-bound CISO exception.
+
+---
+
+## 3. 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** | §2.3 | SBOM and pinned dependencies make the hidden coupling graph of third-party code visible and controllable |
+| **2. Optionality Preservation** | §2.2 | Following an open standard (ASVS) rather than a single vendor's proprietary security checklist keeps the standard portable |
+| **3. Stress-to-Signal Conversion** | §2.4 | SAST/DAST findings and pen test results feed the same structural-fix process as any other incident |
+| **4. Sovereign Intelligence** | §2.1 | Threat models are documented artifacts, not a conversation that evaporates after the design meeting |
+| **5. Asymmetric Payoff Design (Barbell)** | §2.2, §2.6 | ASVS Level 2 and mandatory pen testing concentrated on kill-chain-adjacent/external apps; internal low-risk tools stay at Level 1 |
+
+---
+
+## 4. References
+- **[NIST SP 800-218, Secure Software Development Framework (SSDF)](https://csrc.nist.gov/pubs/sp/800/218/final)**  
+- **[OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/)**  
+- **[OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)**  

Security/vendor_risk_management_guidance.md

@@ -0,0 +1,44 @@
+# Vendor & Third-Party Risk Management Guidance
+
+**Document owner:** [Owner/Role]  
+**Approved by:** [Steering Committee / CISO]  
+**Effective date:** [YYYY-MM-DD]  
+**Review cadence:** [Annually]
+
+---
+
+## 1. Purpose & Scope
+Implementation guidance for the [Vendor & Third-Party Risk Management Policy](vendor_risk_management_policy.md). Applies to Procurement, Vendor Owners, and Security reviewing onboarding requests.
+
+---
+
+## 2. Tiering — Quick Decision Tree
+1. Does the vendor touch TLP:RED or TLP:AMBER+STRICT data, or sit on the kill-chain (per Authentication Policy §2.1)? → **Critical**.  
+2. Does it touch TLP:AMBER data or run a significant business function? → **High**.  
+3. Does it touch only TLP:GREEN data or have limited, non-privileged system access? → **Medium**.  
+4. No system access, TLP:CLEAR only? → **Low**.
+
+## 3. Due Diligence — Practical Checklist
+- Request SOC 2 Type II (or ISO 27001 cert) — check the **report period**, not just that one exists; a report older than 12 months is effectively expired.  
+- For Critical vendors without a SOC 2 (common with smaller/newer vendors): require a completed security questionnaire (CAIQ or equivalent) plus a call with their security lead.  
+- Cyber insurance: confirm coverage amount is proportionate to potential exposure, not just that a certificate exists.
+
+## 4. Concentration Risk — Worked Example
+| Vendor | Function | Alternative Exists? | Exit Plan Status |
+|---|---|---|---|
+| Cloud IdP | Authentication for all staff | No (single IdP by design) | **Required**: documented break-glass + 90-day migration runbook — see [Authentication Policy §2.11](authentication_policy.md) |
+| Payroll processor | Payroll | Yes (2 alternatives evaluated) | Lower priority — market has substitutes |
+| Single MSP running all endpoint management | Device security | No | **Required**: document in-house fallback capability or dual-MSP readiness |
+
+## 5. Offboarding Checklist
+✅ Access revoked within 24h of termination.  
+✅ API keys/service accounts rotated or deleted.  
+✅ Data return or destruction certificate received and filed.  
+✅ Federated trust (SSO app registration, SAML/OIDC config) removed from IdP.  
+✅ Vendor Owner confirms no shared inbox/shared credential remains active.
+
+---
+
+## 6. References
+- **[NIST SP 800-161 Rev. 1](https://csrc.nist.gov/pubs/sp/800/161/r1/final)**  
+- **[ISO/IEC 27001:2022](https://www.iso.org/standard/27001)**  

Security/vendor_risk_management_policy.md

@@ -0,0 +1,91 @@
+# Vendor & Third-Party Risk Management Policy
+
+**Document owner:** [Owner/Role]  
+**Approved by:** [Steering Committee / CISO]  
+**Effective date:** [YYYY-MM-DD]  
+**Review cadence:** [Annually]
+
+---
+
+## 1. Purpose & Scope
+This policy establishes mandatory requirements for assessing, onboarding, monitoring, and offboarding third parties (vendors, suppliers, MSPs, SaaS providers) that access [Organization] systems or data. It applies to all business units engaging third parties, and to Third-party/Vendor accounts defined in [Authentication Policy §3](authentication_policy.md).
+
+---
+
+## 2. Roles & Responsibilities
+- **Vendor Owner (business sponsor):** Accountable for the relationship, ensures due diligence is completed before onboarding, tracks reassessment dates.  
+- **Security/CISO:** Defines tiering criteria, reviews due diligence evidence, approves exceptions.  
+- **Procurement/Legal:** Ensures contractual requirements (§3.3) are included before signature.
+
+---
+
+## 3. Policy Statements
+
+### 3.1 Vendor Tiering
+Every vendor **must** be tiered at onboarding, based on the highest TLP level of data accessed (per [Data Classification Policy](data_classification_policy.md)) and business criticality:
+
+| Tier | Criteria | Example |
+|---|---|---|
+| **Critical** | Accesses TLP:AMBER+STRICT/RED data, or is a single point of failure for a revenue-critical or kill-chain function (per [Authentication Policy §2.1](authentication_policy.md)) | Cloud IdP, payroll processor, core SaaS platform |
+| **High** | Accesses TLP:AMBER data, or supports a significant business function | CRM vendor, MSP with standing admin access |
+| **Medium** | Accesses TLP:GREEN data or limited system access | Marketing tools, non-privileged SaaS |
+| **Low** | Accesses only TLP:CLEAR data, no system access | Public-facing content vendors |
+
+### 3.2 Due Diligence Requirements
+
+| Tier | Required Before Onboarding |
+|---|---|
+| Critical | Security questionnaire; current SOC 2 Type II or ISO 27001 certificate; penetration test summary (last 12 months); cyber insurance evidence; documented exit/migration plan |
+| High | Security questionnaire; SOC 2/ISO 27001 or equivalent attestation |
+| Medium | Security questionnaire (lightweight) |
+| Low | None required beyond standard procurement terms |
+
+### 3.3 Contractual Requirements
+For **Critical** and **High** tier vendors, contracts **must** include:
+- Data protection / processing terms (GDPR Art. 28 or equivalent where applicable).  
+- Breach notification **within 72 hours** of vendor becoming aware.  
+- Right-to-audit or right to receive independent audit reports.  
+- **Data export and exit clauses** as primary terms — format, timeline (≤30 days from request), and any de-provisioning assistance. Absence of an exit clause is a contract blocker for Critical tier.  
+- No unilateral change to data residency or subprocessors without notice.
+
+### 3.4 Ongoing Monitoring & Reassessment
+- **Critical:** Reassessed annually; SOC 2/ISO certificate currency checked continuously (expiry alert).  
+- **High:** Reassessed every 18 months.  
+- **Medium/Low:** Reassessed at renewal or every 3 years, whichever is sooner.  
+- Any material vendor incident (breach, outage >4h, ownership change) triggers an out-of-cycle reassessment.
+
+### 3.5 Concentration Risk / Single-Vendor Dependency
+- Vendor Owners **must** flag any Critical-tier vendor for which no viable alternative or fallback exists.  
+- For each flagged dependency, a documented exit/migration path **must** exist and be executable within **90 days** (aligned with [Authentication Policy §2.11](authentication_policy.md)).  
+- Concentration risk **must** be reviewed at least annually as part of the kill-chain mapping exercise.
+
+### 3.6 Offboarding
+- On contract termination, vendor access **must** be revoked within **24 hours**.  
+- Data return or certified destruction **must** be confirmed in writing within the contractual exit window.  
+- Any shared credentials, API keys, or federated trust relationships **must** be rotated or removed.
+
+### 3.7 Vendor-Involved Incidents
+- Vendor-caused or vendor-affecting incidents **must** be handled per the incident-driven structural learning process in [Authentication Policy §2.12](authentication_policy.md) — a structural change (contract amendment, control, or vendor replacement) is required within 30 days of root cause confirmation.
+
+### 3.8 Enforcement
+- Onboarding without completed due diligence **must not** proceed. Exceptions require documented CISO approval with compensating controls and a review date ≤ 6 months out.
+
+---
+
+## 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.5 | Concentration-risk flagging forces mapping of hidden single points of failure; 90-day exit path required for each |
+| **2. Optionality Preservation** | §3.3 | Data export/exit clauses are primary contract terms, not afterthoughts — preserves the right to leave |
+| **3. Stress-to-Signal Conversion** | §3.7 | Vendor incidents force a structural change within 30 days, not just a post-mortem doc nobody reads |
+| **4. Sovereign Intelligence** | §2 | Named Vendor Owner per relationship; due diligence evidence retained and owned, not scattered across inboxes |
+| **5. Asymmetric Payoff Design (Barbell)** | §3.1–§3.2 | Heavy diligence and contractual rigor concentrated on Critical tier; Low tier gets minimal friction — no moderate process applied uniformly |
+
+---
+
+## 5. References
+- **[NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management](https://csrc.nist.gov/pubs/sp/800/161/r1/final)**  
+- **[ISO/IEC 27001:2022](https://www.iso.org/standard/27001)**  
+- **[ENISA Digital Identity and Data Protection](https://www.enisa.europa.eu/topics/digital-identity-and-data-protection)**  

Security/vulnerability_patch_management_guidance.md

@@ -0,0 +1,39 @@
+# Vulnerability & Patch Management Guidance
+
+**Document owner:** [Owner/Role]  
+**Approved by:** [Steering Committee / CISO]  
+**Effective date:** [YYYY-MM-DD]  
+**Review cadence:** [Annually]
+
+---
+
+## 1. Purpose & Scope
+Implementation guidance for the [Vulnerability & Patch Management Policy](vulnerability_patch_management_policy.md). Applies to IT, security operations, and system owners.
+
+---
+
+## 2. Prioritization — Practical Order
+1. Check the finding against the [CISA KEV catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) first — actively exploited beats a higher CVSS score that's theoretical.  
+2. Cross-reference against kill-chain asset inventory (per [Authentication Policy §2.1](authentication_policy.md)) — same CVE on a kill-chain system jumps the queue.  
+3. Then fall back to CVSS-based SLA table in policy §2.2.
+
+## 3. Patch Testing Before Rollout
+- Kill-chain and production-critical systems: patch in a staging/canary group first, even under an accelerated SLA — an emergency patch that breaks production is not a win.  
+- Low-priority systems: standard maintenance window testing is sufficient.
+
+## 4. Exception Tracking
+- Every SLA exception needs: system, CVE, compensating control (e.g., network isolation, WAF rule), owner, and review date ≤90 days out.  
+- Review the exception list monthly — an exception with no progress after two review cycles escalates to CISO.
+
+## 5. Checklist
+✅ Weekly external / monthly internal scanning running and reviewed.  
+✅ KEV catalog checked against current open findings weekly.  
+✅ Kill-chain systems on continuous scanning where tooling allows.  
+✅ Exception list reviewed monthly, none open past 90 days without CISO sign-off.  
+✅ Emergency patch process tested at least once — don't discover the process during a real zero-day.
+
+---
+
+## 6. References
+- **[NIST SP 800-40 Rev. 4](https://csrc.nist.gov/pubs/sp/800/40/r4/final)**  
+- **[CISA KEV Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)**  

Security/vulnerability_patch_management_policy.md

@@ -0,0 +1,62 @@
+# Vulnerability & Patch Management Policy
+
+**Document owner:** [Owner/Role]  
+**Approved by:** [Steering Committee / CISO]  
+**Effective date:** [YYYY-MM-DD]  
+**Review cadence:** [Annually]
+
+---
+
+## 1. Purpose & Scope
+This policy establishes mandatory requirements for identifying, prioritizing, and remediating vulnerabilities across [Organization]'s IT, cloud, and OT/IoT assets. It applies to all systems, including those managed by third parties per the [Vendor & Third-Party Risk Management Policy](vendor_risk_management_policy.md).
+
+---
+
+## 2. Policy Statements
+
+### 2.1 Vulnerability Scanning
+- Internet-facing assets **must** be scanned at least **weekly**; internal assets **must** be scanned at least **monthly**.  
+- Authenticated scanning **should** be used where supported for accuracy.  
+- Kill-chain systems (per [Authentication Policy §2.1](authentication_policy.md)) **must** be scanned continuously where tooling supports it.
+
+### 2.2 Patch SLA by Severity
+| Severity | SLA |
+|---|---|
+| **CISA KEV-listed** (actively exploited) | ≤ 15 days, kill-chain systems ≤ 72 hours |
+| **Critical (CVSS ≥9.0)** | ≤ 15 days |
+| **High (CVSS 7.0–8.9)** | ≤ 30 days |
+| **Medium (CVSS 4.0–6.9)** | ≤ 90 days |
+| **Low (CVSS <4.0)** | Next scheduled maintenance window |
+
+### 2.3 Emergency Patching
+- A confirmed zero-day or actively exploited vulnerability affecting a kill-chain system **must** trigger emergency change process — patch or compensating control (e.g., network isolation) within the SLA above regardless of standard change windows.
+
+### 2.4 Exceptions
+- Missed SLAs **must** be documented with compensating controls and CISO approval, with a review date not exceeding 90 days.  
+- Unpatchable legacy systems **must** be isolated (network segmentation) as a compensating control, not left exposed by default.
+
+### 2.5 Kill-Chain Priority (Barbell Principle)
+- Vulnerability remediation effort **must** be concentrated disproportionately on kill-chain systems and internet-facing assets; low-criticality internal systems on the standard SLA table do not warrant equivalent urgency.
+
+### 2.6 Enforcement
+- Repeated SLA misses without an approved exception **must** be escalated to the CISO and tracked as a recurring finding per [Authentication Policy §2.12](authentication_policy.md) structural learning process.
+
+---
+
+## 3. 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** | §2.4 | Network isolation as a compensating control means one unpatchable legacy system doesn't become a standing risk to everything else |
+| **2. Optionality Preservation** | §2.4 | Isolation preserves the option to keep a legacy system running without accepting its full risk |
+| **3. Stress-to-Signal Conversion** | §2.6 | Repeated SLA misses feed the structural post-mortem process rather than becoming permanent exceptions |
+| **4. Sovereign Intelligence** | §2.4 | Exceptions and compensating controls documented and owned, with a forced review date |
+| **5. Asymmetric Payoff Design (Barbell)** | §2.2, §2.5 | Tight SLA (≤72h) concentrated on kill-chain + KEV-listed vulnerabilities; low severity gets the lean next-cycle treatment |
+
+---
+
+## 4. References
+- **[NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning](https://csrc.nist.gov/pubs/sp/800/40/r4/final)**  
+- **[CISA Known Exploited Vulnerabilities (KEV) Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)**  
+- **[CIS Controls v8.1 (Control 7)](https://www.cisecurity.org/controls/v8-1)**