Add AGENTS.md guidance and expand Security policy library

2026-07-07 16:17:53 +02:00
parent 4ae6607c3d
commit 8d26180b8e
30 changed files with 1468 additions and 30 deletions
@@ -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.
@@ -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.
@@ -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)**  
@@ -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)**  
@@ -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)**  
@@ -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)**  
@@ -166,8 +166,37 @@ Use this section to classify any method you encounter.
 ---
-## 11. References
+## 11. Account Type × TLP Sensitivity — Worked Examples
- NIST SP 800‑63B (Digital Identity Guidelines, 2023 update)  
+Normative minimums are in Policy §§3–4. Governing AAL = **max(account-type minimum, data-sensitivity minimum)**.
- CIS Controls v8.1 (Controls 5 & 6)  
+
- ENISA Guidelines on Identity and Access Management  
+| Scenario | Account Type Min | TLP of Data Touched | Data Min | Governing AAL |
- OWASP Authentication Cheat Sheet  
+|---|---|---|---|---|
 | 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)  
@@ -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
+## 3. Account Type Requirements
- NIST SP 800‑63B (Digital Identity Guidelines, 2023 update)  
+[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.
- CIS Controls v8.1 (Controls 5 & 6)  
+
- ENISA Guidelines on Identity and Access Management  
+| Account Type | Examples | Minimum AAL | MFA / Authenticator | Reauth / Inactivity | Special Controls |
- OWASP Authentication Cheat Sheet  
+|---|---|---|---|---|---|
 | **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)  
@@ -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)**  
@@ -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)**  
@@ -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)**  
@@ -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)**  
@@ -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)**  
@@ -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)**  
@@ -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)**  
@@ -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)**  
@@ -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)**  
@@ -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)**  
@@ -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)**  
+- **[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)**  
+- **[CIS Controls v8.1 (Controls 5 & 6)](https://www.cisecurity.org/controls/v8-1)**  
- **OWASP Authentication Cheat Sheet**  
+- **[OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)**  
@@ -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.
@@ -120,6 +120,7 @@ Apps authenticating against AD or Entra ID must:
 - ✅ Review dormant accounts quarterly (disable after 45 days).  
 - ✅ Require TLS 1.2+ for all endpoints.  
 - ✅ 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)**  
+- **[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)  
+- **[CIS Controls v8.1](https://www.cisecurity.org/controls/v8-1)** (Controls 5 & 6)  
- **Microsoft Security Baselines (Windows, AD, M365)**  
+- **[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**
+- **[OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)**
@@ -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)**  
+- **[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**  
+- **[CIS Controls v8.1, Controls 5 & 6](https://www.cisecurity.org/controls/v8-1)**  
- **OWASP Authentication Cheat Sheet**  
+- **[OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)**  
@@ -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)**  
+- **[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**  
+- **[CIS Controls v8.1, Controls 5 & 6](https://www.cisecurity.org/controls/v8-1)**  
- **Microsoft Security Baselines (M365 & Windows/AD)**  
+- **[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**  
+- **[OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)**  
@@ -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)**  
@@ -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)**  
@@ -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/)**  
@@ -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)**  
@@ -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)**  
@@ -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)**  
@@ -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)**  
@@ -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)**
`@@ -30,4 +30,4 @@ Please ensure that all contributions align with organizational goals and legal r`

	`## Licensing`	`## 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.`