diff --git a/components/cert/ControlCard.tsx b/components/cert/ControlCard.tsx
index 0a3377f7..cc7106ac 100644
--- a/components/cert/ControlCard.tsx
+++ b/components/cert/ControlCard.tsx
@@ -1,6 +1,7 @@
 import { memo, useState } from "react";
 import "./control.css";
 import { Control, ControlData, ControlState } from "./types";
+import { controlToFramework } from "./cert-framework-map";
 
 interface ControlCardProps {
     control: Control;
@@ -99,6 +100,24 @@ export const ControlCard = memo(function ControlCard({
                             </ul>
                         </div>
                     )}
+                    {controlToFramework[control.id] && controlToFramework[control.id].length > 0 && (
+                        <div className="control-framework-refs">
+                            <div className="control-framework-refs-label">📖 Related Framework Guidance</div>
+                            <ul className="control-framework-refs-list">
+                                {controlToFramework[control.id].map((ref, idx) => (
+                                    <li key={idx}>
+                                        <a
+                                            href={ref.header ? `${ref.page}#${ref.header.toLowerCase().replace(/[^\w\s-]/g, '').replace(/\s+/g, '-')}` : ref.page}
+                                            className={`control-framework-ref control-framework-ref-${ref.coverage}`}
+                                        >
+                                            {ref.title || ref.page}
+                                            {ref.header && <span className="control-framework-ref-header"> → {ref.header}</span>}
+                                        </a>
+                                    </li>
+                                ))}
+                            </ul>
+                        </div>
+                    )}
                 </div>
                 <div className="ml-auto pl-3">
                     <button
diff --git a/components/cert/cert-framework-map.ts b/components/cert/cert-framework-map.ts
new file mode 100644
index 00000000..897a9239
--- /dev/null
+++ b/components/cert/cert-framework-map.ts
@@ -0,0 +1,1027 @@
+// AUTO-GENERATED by scripts/build-verified-mapping.mjs — do not edit manually
+// LLM-verified mappings: each ref has been evaluated for substantive baseline coverage
+
+export interface FrameworkRef {
+  page: string;
+  title: string;
+  header: string | null;
+  coverage: 'full' | 'partial';
+}
+
+/** Forward index: cert control ID → verified framework page references */
+export const controlToFramework: Record<string, FrameworkRef[]> = {
+  "di-1.1.1": [],
+  "di-1.1.2": [],
+  "di-1.1.3": [
+    {
+      "page": "/devsecops/integrated-development-environments",
+      "title": "Securing Development Environments | SEAL",
+      "header": null,
+      "coverage": "partial"
+    }
+  ],
+  "di-1.1.4": [
+    {
+      "page": "/devsecops/integrated-development-environments",
+      "title": "Securing Development Environments | SEAL",
+      "header": null,
+      "coverage": "partial"
+    }
+  ],
+  "di-2.1.1": [
+    {
+      "page": "/secure-software-development/secure-code-repositories-version-control",
+      "title": "Secure Code Repositories & Version Control | SEAL",
+      "header": "Best Practices for Secure Code Repositories",
+      "coverage": "partial"
+    }
+  ],
+  "di-2.1.2": [
+    {
+      "page": "/devsecops/continuous-integration-continuous-deployment",
+      "title": "Securing CI/CD Pipelines | SEAL",
+      "header": null,
+      "coverage": "partial"
+    }
+  ],
+  "di-2.1.3": [],
+  "di-2.1.4": [
+    {
+      "page": "/supply-chain/dependency-awareness",
+      "title": "Dependency Awareness",
+      "header": "Best Practices for Dependency Awareness",
+      "coverage": "partial"
+    }
+  ],
+  "di-3.1.1": [
+    {
+      "page": "/devsecops/continuous-integration-continuous-deployment",
+      "title": "Securing CI/CD Pipelines | SEAL",
+      "header": null,
+      "coverage": "partial"
+    }
+  ],
+  "di-3.1.2": [],
+  "di-3.1.3": [
+    {
+      "page": "/devsecops/continuous-integration-continuous-deployment",
+      "title": "Securing CI/CD Pipelines | SEAL",
+      "header": null,
+      "coverage": "partial"
+    },
+    {
+      "page": "/devsecops/security-testing",
+      "title": "Security Testing",
+      "header": null,
+      "coverage": "partial"
+    }
+  ],
+  "di-4.1.1": [
+    {
+      "page": "/security-automation/infrastructure-as-code",
+      "title": "Infrastructure as Code Security | SEAL",
+      "header": null,
+      "coverage": "partial"
+    }
+  ],
+  "di-4.1.2": [
+    {
+      "page": "/secure-software-development/secure-code-repositories-version-control",
+      "title": "Secure Code Repositories & Version Control | SEAL",
+      "header": "Best Practices for Secure Code Repositories",
+      "coverage": "partial"
+    }
+  ],
+  "di-4.1.3": [
+    {
+      "page": "/secure-software-development/secure-code-repositories-version-control",
+      "title": "Secure Code Repositories & Version Control | SEAL",
+      "header": "Secure Version Control Practices",
+      "coverage": "partial"
+    }
+  ],
+  "di-4.1.4": [
+    {
+      "page": "/infrastructure/cloud",
+      "title": "Cloud Infrastructure",
+      "header": "Cloud Infrastructure",
+      "coverage": "partial"
+    }
+  ],
+  "dns-1.1.1": [],
+  "dns-1.1.2": [],
+  "dns-2.1.1": [],
+  "dns-2.1.2": [
+    {
+      "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+      "title": "Registrar Security & Registry Locks | SEAL",
+      "header": "Choosing a Secure Registrar",
+      "coverage": "full"
+    }
+  ],
+  "dns-3.1.1": [
+    {
+      "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+      "title": "Registrar Security & Registry Locks | SEAL",
+      "header": "Access Control Best Practices",
+      "coverage": "partial"
+    }
+  ],
+  "dns-3.1.2": [
+    {
+      "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+      "title": "Registrar Security & Registry Locks | SEAL",
+      "header": "Dedicated Security Contact Email",
+      "coverage": "partial"
+    }
+  ],
+  "dns-3.1.3": [],
+  "dns-4.1.1": [
+    {
+      "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+      "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+      "header": "DNSSEC Implementation",
+      "coverage": "partial"
+    }
+  ],
+  "dns-4.1.2": [
+    {
+      "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+      "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+      "header": "Email Security Configuration",
+      "coverage": "partial"
+    }
+  ],
+  "dns-4.1.3": [
+    {
+      "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+      "title": "Registrar Security & Registry Locks | SEAL",
+      "header": "Registry Lock (EPP Lock)",
+      "coverage": "full"
+    }
+  ],
+  "dns-4.1.4": [],
+  "dns-5.1.1": [
+    {
+      "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+      "title": "DNS Monitoring & Incident Response | SEAL",
+      "header": "DNS Record Monitoring",
+      "coverage": "partial"
+    }
+  ],
+  "dns-5.1.2": [
+    {
+      "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+      "title": "DNS Monitoring & Incident Response | SEAL",
+      "header": "Certificate Transparency Monitoring",
+      "coverage": "full"
+    }
+  ],
+  "dns-5.1.3": [
+    {
+      "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+      "title": "Registrar Security & Registry Locks | SEAL",
+      "header": "Domain Expiration Protection",
+      "coverage": "full"
+    }
+  ],
+  "dns-6.1.1": [
+    {
+      "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+      "title": "DNS Monitoring & Incident Response | SEAL",
+      "header": "Setting Up Alerts",
+      "coverage": "partial"
+    }
+  ],
+  "dns-6.1.2": [
+    {
+      "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+      "title": "DNS Monitoring & Incident Response | SEAL",
+      "header": "Incident Response Plan",
+      "coverage": "partial"
+    }
+  ],
+  "ir-1.1.1": [],
+  "ir-1.1.2": [
+    {
+      "page": "/multisig-for-protocols/emergency-procedures",
+      "title": "Multisig Emergency Procedures | SEAL",
+      "header": "Emergency Contact Information",
+      "coverage": "partial"
+    },
+    {
+      "page": "/incident-management/playbooks/seal-911-war-room-guidelines",
+      "title": "SEAL 911 War Room Guidelines | SEAL",
+      "header": "Key Roles",
+      "coverage": "partial"
+    },
+    {
+      "page": "/wallet-security/secure-multisig-best-practices",
+      "title": "Secure Multisig Best Practices | SEAL",
+      "header": "Communication & Documentation",
+      "coverage": "partial"
+    }
+  ],
+  "ir-2.1.1": [
+    {
+      "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+      "title": "DNS Monitoring & Incident Response | SEAL",
+      "header": "DNS Record Monitoring",
+      "coverage": "partial"
+    },
+    {
+      "page": "/monitoring/guidelines",
+      "title": "On-Chain Monitoring Guidelines",
+      "header": "Best Practices",
+      "coverage": "partial"
+    }
+  ],
+  "ir-2.1.2": [
+    {
+      "page": "/multisig-for-protocols/emergency-procedures",
+      "title": "Multisig Emergency Procedures | SEAL",
+      "header": "Immediate Actions",
+      "coverage": "partial"
+    }
+  ],
+  "ir-2.1.3": [],
+  "ir-3.1.1": [
+    {
+      "page": "/multisig-for-protocols/emergency-procedures",
+      "title": "Multisig Emergency Procedures | SEAL",
+      "header": "Key Compromise",
+      "coverage": "partial"
+    },
+    {
+      "page": "/wallet-security/secure-multisig-best-practices",
+      "title": "Secure Multisig Best Practices | SEAL",
+      "header": "Signer rotation",
+      "coverage": "partial"
+    }
+  ],
+  "ir-3.1.2": [
+    {
+      "page": "/wallet-security/secure-multisig-best-practices",
+      "title": "Secure Multisig Best Practices | SEAL",
+      "header": "Training & Drills",
+      "coverage": "partial"
+    },
+    {
+      "page": "/multisig-for-protocols/setup-and-configuration",
+      "title": "Multisig Setup & Configuration | SEAL",
+      "header": null,
+      "coverage": "partial"
+    }
+  ],
+  "ir-3.1.3": [
+    {
+      "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+      "title": "Backup Signing & Infrastructure | SEAL",
+      "header": "UI Alternatives",
+      "coverage": "partial"
+    },
+    {
+      "page": "/multisig-for-protocols/implementation-checklist",
+      "title": "Multisig Implementation Checklist | SEAL",
+      "header": "Emergency Preparedness",
+      "coverage": "partial"
+    }
+  ],
+  "ir-4.1.1": [
+    {
+      "page": "/multisig-for-protocols/implementation-checklist",
+      "title": "Multisig Implementation Checklist | SEAL",
+      "header": "Documentation & Communication",
+      "coverage": "partial"
+    },
+    {
+      "page": "/multisig-for-protocols/emergency-procedures",
+      "title": "Multisig Emergency Procedures | SEAL",
+      "header": "Emergency Communication Protocols",
+      "coverage": "partial"
+    }
+  ],
+  "ir-4.1.2": [
+    {
+      "page": "/incident-management/communication-strategies",
+      "title": "Incident Communication Strategies | SEAL",
+      "header": "Best Practices",
+      "coverage": "partial"
+    }
+  ],
+  "ir-4.1.3": [
+    {
+      "page": "/incident-management/playbooks/seal-911-war-room-guidelines",
+      "title": "SEAL 911 War Room Guidelines | SEAL",
+      "header": "Communications",
+      "coverage": "partial"
+    },
+    {
+      "page": "/multisig-for-protocols/emergency-procedures",
+      "title": "Multisig Emergency Procedures | SEAL",
+      "header": "Emergency Notification Template",
+      "coverage": "partial"
+    }
+  ],
+  "ir-5.1.1": [
+    {
+      "page": "/multisig-for-protocols/emergency-procedures",
+      "title": "Multisig Emergency Procedures | SEAL",
+      "header": "Emergency Drill Procedures",
+      "coverage": "partial"
+    },
+    {
+      "page": "/incident-management/playbooks/decentralized-ir",
+      "title": "Decentralized Incident Response | SEAL",
+      "header": "Keep It Alive",
+      "coverage": "partial"
+    }
+  ],
+  "ms-1.1.1": [
+    {
+      "page": "/multisig-for-protocols/implementation-checklist",
+      "title": "Multisig Implementation Checklist | SEAL",
+      "header": "For Multisig Administrators",
+      "coverage": "partial"
+    }
+  ],
+  "ms-1.1.2": [
+    {
+      "page": "/wallet-security/secure-multisig-best-practices",
+      "title": "Secure Multisig Best Practices | SEAL",
+      "header": "Communication & Documentation",
+      "coverage": "partial"
+    },
+    {
+      "page": "/multisig-for-protocols/implementation-checklist",
+      "title": "Multisig Implementation Checklist | SEAL",
+      "header": "Documentation & Communication",
+      "coverage": "partial"
+    }
+  ],
+  "ms-2.1.1": [
+    {
+      "page": "/multisig-for-protocols/planning-and-classification",
+      "title": "Multisig Planning & Classification | SEAL",
+      "header": "Classification Process",
+      "coverage": "full"
+    },
+    {
+      "page": "/wallet-security/secure-multisig-best-practices",
+      "title": "Secure Multisig Best Practices | SEAL",
+      "header": "Thresholds & Configuration",
+      "coverage": "full"
+    }
+  ],
+  "ms-2.1.2": [
+    {
+      "page": "/multisig-for-protocols/setup-and-configuration",
+      "title": "Multisig Setup & Configuration | SEAL",
+      "header": "Contract-Level Controls",
+      "coverage": "partial"
+    },
+    {
+      "page": "/wallet-security/secure-multisig-best-practices",
+      "title": "Secure Multisig Best Practices | SEAL",
+      "header": "Contract-Level Security",
+      "coverage": "partial"
+    }
+  ],
+  "ms-2.1.3": [],
+  "ms-2.1.4": [],
+  "ms-3.1.1": [
+    {
+      "page": "/wallet-security/secure-multisig-best-practices",
+      "title": "Secure Multisig Best Practices | SEAL",
+      "header": "Communication & Documentation",
+      "coverage": "partial"
+    },
+    {
+      "page": "/multisig-for-protocols/setup-and-configuration",
+      "title": "Multisig Setup & Configuration | SEAL",
+      "header": "Pre-Launch Checklist",
+      "coverage": "partial"
+    }
+  ],
+  "ms-3.1.2": [
+    {
+      "page": "/wallet-security/secure-multisig-best-practices",
+      "title": "Secure Multisig Best Practices | SEAL",
+      "header": "Thresholds & Configuration",
+      "coverage": "full"
+    }
+  ],
+  "ms-3.1.3": [
+    {
+      "page": "/wallet-security/seed-phrase-management",
+      "title": "Seed Phrase Management",
+      "header": "Secure Storage Practices",
+      "coverage": "full"
+    }
+  ],
+  "ms-3.1.4": [
+    {
+      "page": "/wallet-security/secure-multisig-best-practices",
+      "title": "Secure Multisig Best Practices | SEAL",
+      "header": "Signer rotation",
+      "coverage": "partial"
+    }
+  ],
+  "ms-3.1.5": [
+    {
+      "page": "/multisig-for-protocols/implementation-checklist",
+      "title": "Multisig Implementation Checklist | SEAL",
+      "header": "For Signers",
+      "coverage": "full"
+    }
+  ],
+  "ms-3.1.6": [
+    {
+      "page": "/multisig-for-protocols/implementation-checklist",
+      "title": "Multisig Implementation Checklist | SEAL",
+      "header": "Hardware & Security Setup",
+      "coverage": "full"
+    }
+  ],
+  "ms-3.1.7": [
+    {
+      "page": "/multisig-for-protocols/personal-security-opsec",
+      "title": "Multisig Personal Security (OpSec) | SEAL",
+      "header": "Network Security",
+      "coverage": "full"
+    }
+  ],
+  "ms-3.1.8": [
+    {
+      "page": "/wallet-security/secure-multisig-best-practices",
+      "title": "Secure Multisig Best Practices | SEAL",
+      "header": "Strategic Signer Distribution",
+      "coverage": "full"
+    }
+  ],
+  "ms-4.1.1": [
+    {
+      "page": "/wallet-security/signing-and-verification/secure-multisig-signing-process",
+      "title": "Secure Multisig Signing Process | SEAL",
+      "header": "Phase 1: Signing the Off-Chain Message",
+      "coverage": "full"
+    },
+    {
+      "page": "/wallet-security/secure-multisig-best-practices",
+      "title": "Secure Multisig Best Practices | SEAL",
+      "header": "Operational Best Practices",
+      "coverage": "partial"
+    }
+  ],
+  "ms-4.1.2": [],
+  "ms-4.1.3": [
+    {
+      "page": "/multisig-for-protocols/implementation-checklist",
+      "title": "Multisig Implementation Checklist | SEAL",
+      "header": "Transaction Verification",
+      "coverage": "partial"
+    }
+  ],
+  "ms-4.1.4": [
+    {
+      "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+      "title": "Backup Signing & Infrastructure | SEAL",
+      "header": "UI Alternatives",
+      "coverage": "full"
+    }
+  ],
+  "ms-5.1.1": [
+    {
+      "page": "/multisig-for-protocols/implementation-checklist",
+      "title": "Multisig Implementation Checklist | SEAL",
+      "header": "Documentation & Communication",
+      "coverage": "partial"
+    },
+    {
+      "page": "/multisig-for-protocols/emergency-procedures",
+      "title": "Multisig Emergency Procedures | SEAL",
+      "header": "Communication Account Compromise",
+      "coverage": "partial"
+    }
+  ],
+  "ms-5.1.2": [
+    {
+      "page": "/multisig-for-protocols/implementation-checklist",
+      "title": "Multisig Implementation Checklist | SEAL",
+      "header": "Documentation & Communication",
+      "coverage": "partial"
+    },
+    {
+      "page": "/multisig-for-protocols/emergency-procedures",
+      "title": "Multisig Emergency Procedures | SEAL",
+      "header": "Emergency Contact Information",
+      "coverage": "partial"
+    }
+  ],
+  "ms-6.1.1": [
+    {
+      "page": "/multisig-for-protocols/emergency-procedures",
+      "title": "Multisig Emergency Procedures | SEAL",
+      "header": "Key Compromise",
+      "coverage": "full"
+    }
+  ],
+  "ms-6.1.2": [
+    {
+      "page": "/multisig-for-protocols/planning-and-classification",
+      "title": "Multisig Planning & Classification | SEAL",
+      "header": "Step 2: Operational Assessment",
+      "coverage": "partial"
+    },
+    {
+      "page": "/multisig-for-protocols/emergency-procedures",
+      "title": "Multisig Emergency Procedures | SEAL",
+      "header": "For Emergency Response Multisigs",
+      "coverage": "partial"
+    }
+  ],
+  "ms-6.1.3": [
+    {
+      "page": "/wallet-security/secure-multisig-best-practices",
+      "title": "Secure Multisig Best Practices | SEAL",
+      "header": "Operational Best Practices",
+      "coverage": "partial"
+    },
+    {
+      "page": "/multisig-for-protocols/setup-and-configuration",
+      "title": "Multisig Setup & Configuration | SEAL",
+      "header": "Active Monitoring",
+      "coverage": "partial"
+    }
+  ],
+  "ms-6.1.4": [
+    {
+      "page": "/multisig-for-protocols/implementation-checklist",
+      "title": "Multisig Implementation Checklist | SEAL",
+      "header": "Specialized Training by Use Case",
+      "coverage": "partial"
+    },
+    {
+      "page": "/multisig-for-protocols/emergency-procedures",
+      "title": "Multisig Emergency Procedures | SEAL",
+      "header": "Emergency Drill Procedures",
+      "coverage": "full"
+    }
+  ],
+  "tro-1.1.1": [],
+  "tro-1.1.2": [
+    {
+      "page": "/treasury-operations/registration-documents",
+      "title": "Custodial Account Registration | SEAL",
+      "header": "Registration Template",
+      "coverage": "partial"
+    }
+  ],
+  "tro-1.1.3": [
+    {
+      "page": "/treasury-operations/enhanced-controls",
+      "title": "Enhanced Controls for High-Risk Accounts | SEAL",
+      "header": "MPC for Large Holdings",
+      "coverage": "partial"
+    }
+  ],
+  "tro-1.1.4": [
+    {
+      "page": "/treasury-operations/registration-documents",
+      "title": "Custodial Account Registration | SEAL",
+      "header": "Access Change Template",
+      "coverage": "partial"
+    }
+  ],
+  "tro-2.1.1": [
+    {
+      "page": "/treasury-operations/classification",
+      "title": "Treasury Security Classification | SEAL",
+      "header": null,
+      "coverage": "full"
+    }
+  ],
+  "tro-2.1.2": [],
+  "tro-3.1.1": [
+    {
+      "page": "/treasury-operations/enhanced-controls",
+      "title": "Enhanced Controls for High-Risk Accounts | SEAL",
+      "header": "Access Security",
+      "coverage": "partial"
+    },
+    {
+      "page": "/treasury-operations/registration-documents",
+      "title": "Custodial Account Registration | SEAL",
+      "header": "Security Configuration Template",
+      "coverage": "partial"
+    }
+  ],
+  "tro-3.1.2": [
+    {
+      "page": "/treasury-operations/enhanced-controls",
+      "title": "Enhanced Controls for High-Risk Accounts | SEAL",
+      "header": "Access Security",
+      "coverage": "partial"
+    },
+    {
+      "page": "/wallet-security/seed-phrase-management",
+      "title": "Seed Phrase Management",
+      "header": null,
+      "coverage": "partial"
+    }
+  ],
+  "tro-3.1.3": [
+    {
+      "page": "/treasury-operations/registration-documents",
+      "title": "Custodial Account Registration | SEAL",
+      "header": "Quarterly Review Template",
+      "coverage": "full"
+    }
+  ],
+  "tro-3.1.4": [
+    {
+      "page": "/treasury-operations/enhanced-controls",
+      "title": "Enhanced Controls for High-Risk Accounts | SEAL",
+      "header": "Device Security",
+      "coverage": "partial"
+    },
+    {
+      "page": "/wallet-security/seed-phrase-management",
+      "title": "Seed Phrase Management",
+      "header": "Secure Storage Practices",
+      "coverage": "partial"
+    },
+    {
+      "page": "/multisig-for-protocols/personal-security-opsec",
+      "title": "Multisig Personal Security (OpSec) | SEAL",
+      "header": "Device Security",
+      "coverage": "partial"
+    }
+  ],
+  "tro-4.1.1": [
+    {
+      "page": "/treasury-operations/transaction-verification",
+      "title": "Treasury Transaction Verification | SEAL",
+      "header": "Execution Protocol",
+      "coverage": "partial"
+    }
+  ],
+  "tro-4.1.2": [
+    {
+      "page": "/multisig-for-protocols/implementation-checklist",
+      "title": "Multisig Implementation Checklist | SEAL",
+      "header": "Transaction Verification",
+      "coverage": "partial"
+    }
+  ],
+  "tro-4.1.3": [
+    {
+      "page": "/multisig-for-protocols/emergency-procedures",
+      "title": "Multisig Emergency Procedures | SEAL",
+      "header": "Communication Account Compromise",
+      "coverage": "partial"
+    }
+  ],
+  "tro-5.1.1": [],
+  "tro-5.1.2": [
+    {
+      "page": "/treasury-operations/transaction-verification",
+      "title": "Treasury Transaction Verification | SEAL",
+      "header": "Transaction Parameter Security",
+      "coverage": "partial"
+    }
+  ],
+  "tro-6.1.1": [
+    {
+      "page": "/treasury-operations/enhanced-controls",
+      "title": "Enhanced Controls for High-Risk Accounts | SEAL",
+      "header": "Security Monitoring & Logging",
+      "coverage": "partial"
+    }
+  ],
+  "tro-6.1.2": [
+    {
+      "page": "/multisig-for-protocols/emergency-procedures",
+      "title": "Multisig Emergency Procedures | SEAL",
+      "header": "Emergency Notification Template",
+      "coverage": "full"
+    }
+  ],
+  "tro-7.1.1": [],
+  "tro-7.1.2": [
+    {
+      "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+      "title": "Backup Signing & Infrastructure | SEAL",
+      "header": "UI Alternatives",
+      "coverage": "full"
+    }
+  ],
+  "tro-8.1.1": [
+    {
+      "page": "/treasury-operations/registration-documents",
+      "title": "Custodial Account Registration | SEAL",
+      "header": "Security Configuration Template",
+      "coverage": "partial"
+    }
+  ],
+  "tro-8.1.2": [],
+  "ws-1.1.1": [
+    {
+      "page": "/opsec/core-concepts/security-fundamentals",
+      "title": "Security Fundamentals",
+      "header": "Continuous Visibility",
+      "coverage": "partial"
+    }
+  ],
+  "ws-1.1.2": [],
+  "ws-1.1.3": [
+    {
+      "page": "/opsec/core-concepts/implementation-process",
+      "title": "OpSec Implementation Process | SEAL",
+      "header": "Critical Asset Identification",
+      "coverage": "partial"
+    }
+  ],
+  "ws-1.1.4": [
+    {
+      "page": "/opsec/core-concepts/security-fundamentals",
+      "title": "Security Fundamentals",
+      "header": "Information Flow Control",
+      "coverage": "full"
+    },
+    {
+      "page": "/opsec/core-concepts/implementation-process",
+      "title": "OpSec Implementation Process | SEAL",
+      "header": "Critical Asset Identification",
+      "coverage": "full"
+    }
+  ],
+  "ws-2.1.1": [
+    {
+      "page": "/opsec/travel/guide",
+      "title": "Travel Security Guide",
+      "header": "Secure devices with encryption & updates",
+      "coverage": "partial"
+    },
+    {
+      "page": "/encryption/volume-encryption",
+      "title": "Volume Encryption",
+      "header": null,
+      "coverage": "partial"
+    },
+    {
+      "page": "/encryption/partition-encryption",
+      "title": "Partition Encryption",
+      "header": null,
+      "coverage": "partial"
+    }
+  ],
+  "ws-2.1.2": [
+    {
+      "page": "/opsec/travel/guide",
+      "title": "Travel Security Guide",
+      "header": "Back up and prepare for loss",
+      "coverage": "partial"
+    },
+    {
+      "page": "/opsec/control-domains/physical-environmental",
+      "title": "Physical & Environmental Security",
+      "header": "Physical Security of Critical Assets",
+      "coverage": "partial"
+    }
+  ],
+  "ws-2.1.3": [
+    {
+      "page": "/opsec/travel/guide",
+      "title": "Travel Security Guide",
+      "header": "Inspect and clean your devices",
+      "coverage": "partial"
+    }
+  ],
+  "ws-2.1.4": [
+    {
+      "page": "/opsec/travel/guide",
+      "title": "Travel Security Guide",
+      "header": null,
+      "coverage": "full"
+    },
+    {
+      "page": "/opsec/control-domains/physical-environmental",
+      "title": "Physical & Environmental Security",
+      "header": "Secure Workspace & Travel Security",
+      "coverage": "full"
+    }
+  ],
+  "ws-3.1.1": [
+    {
+      "page": "/guides/account_management/discord",
+      "title": "Discord Security",
+      "header": "Roles",
+      "coverage": "partial"
+    }
+  ],
+  "ws-3.1.2": [
+    {
+      "page": "/opsec/travel/guide",
+      "title": "Travel Security Guide",
+      "header": "Protect Accounts with 2FA redundancy",
+      "coverage": "partial"
+    },
+    {
+      "page": "/opsec/control-domains/technical",
+      "title": "Technical Security Controls",
+      "header": "Two-Factor & Hardware Authentication",
+      "coverage": "partial"
+    },
+    {
+      "page": "/guides/account_management/discord",
+      "title": "Discord Security",
+      "header": "For Individuals - Account Security Checklist",
+      "coverage": "partial"
+    }
+  ],
+  "ws-3.1.3": [
+    {
+      "page": "/guides/account_management/discord",
+      "title": "Discord Security",
+      "header": "Server Settings Checklist",
+      "coverage": "partial"
+    }
+  ],
+  "ws-3.1.4": [
+    {
+      "page": "/opsec/travel/guide",
+      "title": "Travel Security Guide",
+      "header": "Protect Accounts with 2FA redundancy",
+      "coverage": "partial"
+    },
+    {
+      "page": "/awareness/cultivating-a-security-aware-mindset",
+      "title": "Cultivating A Security Aware Mindset | SEAL",
+      "header": "Password Management",
+      "coverage": "partial"
+    },
+    {
+      "page": "/guides/account_management/telegram",
+      "title": "Telegram Security",
+      "header": "Account Security Checklist",
+      "coverage": "partial"
+    }
+  ],
+  "ws-3.1.5": [
+    {
+      "page": "/opsec/core-concepts/security-fundamentals",
+      "title": "Security Fundamentals",
+      "header": "Minimal Access Scopes",
+      "coverage": "partial"
+    },
+    {
+      "page": "/guides/account_management/discord",
+      "title": "Discord Security",
+      "header": "Regular Reviews",
+      "coverage": "partial"
+    }
+  ],
+  "ws-4.1.1": [
+    {
+      "page": "/opsec/travel/guide",
+      "title": "Travel Security Guide",
+      "header": "Minimize digital footprint & social visibility",
+      "coverage": "partial"
+    }
+  ],
+  "ws-4.1.2": [
+    {
+      "page": "/guides/account_management/github",
+      "title": "GitHub Security",
+      "header": "Repository Settings",
+      "coverage": "full"
+    }
+  ],
+  "ws-5.1.1": [
+    {
+      "page": "/opsec/travel/guide",
+      "title": "Travel Security Guide",
+      "header": "Network safety – avoid untrusted Wi-Fi & Bluetooth",
+      "coverage": "partial"
+    },
+    {
+      "page": "/opsec/control-domains/technical",
+      "title": "Technical Security Controls",
+      "header": "Network & Communication Security",
+      "coverage": "partial"
+    }
+  ],
+  "ws-5.1.2": [
+    {
+      "page": "/opsec/travel/guide",
+      "title": "Travel Security Guide",
+      "header": "Plan emergency and incident responses",
+      "coverage": "partial"
+    },
+    {
+      "page": "/guides/account_management/telegram",
+      "title": "Telegram Security",
+      "header": "Use Secret Chats for Enhanced Privacy",
+      "coverage": "partial"
+    },
+    {
+      "page": "/opsec/control-domains/technical",
+      "title": "Technical Security Controls",
+      "header": "Network & Communication Security",
+      "coverage": "partial"
+    }
+  ],
+  "ws-6.1.1": [
+    {
+      "page": "/opsec/control-domains/people",
+      "title": "Personnel Security Controls",
+      "header": "Personnel Security Measures",
+      "coverage": "partial"
+    }
+  ],
+  "ws-6.1.2": [
+    {
+      "page": "/opsec/travel/guide",
+      "title": "Travel Security Guide",
+      "header": "Back up and prepare for loss",
+      "coverage": "partial"
+    },
+    {
+      "page": "/awareness/understanding-threat-vectors",
+      "title": "Understanding Threat Vectors",
+      "header": null,
+      "coverage": "partial"
+    },
+    {
+      "page": "/guides/account_management/discord",
+      "title": "Discord Security",
+      "header": "Regular Reviews",
+      "coverage": "partial"
+    }
+  ],
+  "ws-6.1.3": [
+    {
+      "page": "/awareness/staying-informed-and-continuous-learning",
+      "title": "Staying Informed And Continuous Learning | SEAL",
+      "header": "Comprehensive Security Training Framework",
+      "coverage": "partial"
+    },
+    {
+      "page": "/opsec/control-domains/people",
+      "title": "Personnel Security Controls",
+      "header": "Security Training & Culture",
+      "coverage": "partial"
+    },
+    {
+      "page": "/opsec/appendices/case-studies",
+      "title": "OpSec Case Studies",
+      "header": null,
+      "coverage": "partial"
+    }
+  ],
+  "ws-7.1.1": [
+    {
+      "page": "/opsec/core-concepts/security-fundamentals",
+      "title": "Security Fundamentals",
+      "header": "Continuous Visibility",
+      "coverage": "partial"
+    },
+    {
+      "page": "/opsec/appendices/case-studies",
+      "title": "OpSec Case Studies",
+      "header": "Tabletop Exercises",
+      "coverage": "partial"
+    }
+  ],
+  "ws-7.1.2": [
+    {
+      "page": "/opsec/core-concepts/security-fundamentals",
+      "title": "Security Fundamentals",
+      "header": "Minimal Access Scopes",
+      "coverage": "partial"
+    },
+    {
+      "page": "/opsec/control-domains/people",
+      "title": "Personnel Security Controls",
+      "header": "Insider-Threat Mitigation",
+      "coverage": "partial"
+    }
+  ],
+  "ws-7.1.3": [
+    {
+      "page": "/opsec/core-concepts/security-fundamentals",
+      "title": "Security Fundamentals",
+      "header": "Minimal Access Scopes",
+      "coverage": "partial"
+    },
+    {
+      "page": "/guides/account_management/discord",
+      "title": "Discord Security",
+      "header": "Integrations",
+      "coverage": "partial"
+    }
+  ]
+};
+
+/** Reverse index: framework page path → cert controls that reference it */
diff --git a/components/cert/control.css b/components/cert/control.css
index d39f12e6..cee9415a 100644
--- a/components/cert/control.css
+++ b/components/cert/control.css
@@ -419,15 +419,57 @@
   opacity: 0.6;
 }
 
-/* Responsive Design */
-@media (max-width: 640px) {
-  .cert-actions {
-    flex-direction: column;
-    align-items: stretch;
-  }
+/* Framework References (forward: control → pages) */
+.control-framework-refs {
+  margin-top: 8px;
+  padding: 8px 12px;
+  border-left: 3px solid var(--color-success);
+  background: rgba(16, 185, 129, 0.05);
+  border-radius: 0 6px 6px 0;
+}
 
-  .cert-action-btn {
-    width: 100%;
-    justify-content: center;
-  }
-}
\ No newline at end of file
+:root:not(.dark) .control-framework-refs {
+  background: rgba(16, 185, 129, 0.04);
+}
+
+.control-framework-refs-label {
+  font-size: 12px;
+  font-weight: 600;
+  text-transform: uppercase;
+  letter-spacing: 0.05em;
+  color: var(--color-success);
+  margin-bottom: 4px;
+}
+
+.control-framework-refs-list {
+  list-style: none;
+  padding: 0;
+  margin: 0;
+}
+
+.control-framework-refs-list li {
+  padding: 2px 0;
+}
+
+.control-framework-ref {
+  font-size: 13px;
+  text-decoration: none;
+  color: var(--color-success);
+  transition: opacity 0.2s;
+}
+
+.control-framework-ref:hover {
+  opacity: 0.8;
+  text-decoration: underline;
+}
+
+.control-framework-ref-partial {
+  color: var(--color-partial);
+}
+
+.control-framework-ref-header {
+  font-size: 12px;
+  opacity: 0.7;
+}
+
+/* Cert References (reverse: page → controls) */
diff --git a/docs/gap-analysis.md b/docs/gap-analysis.md
new file mode 100644
index 00000000..c734e1e6
--- /dev/null
+++ b/docs/gap-analysis.md
@@ -0,0 +1,1175 @@
+# SEAL Certs ↔ Frameworks Gap Analysis (Verified)
+
+_Generated 2026-02-16 — LLM-verified coverage assessment_
+
+## Summary
+
+| Metric | Count | % |
+|--------|-------|---|
+| Total controls | 111 | 100% |
+| ✅ Full coverage (≥1 full ref) | 22 | 20% |
+| ⚠️ Partial coverage only | 69 | 62% |
+| ❌ No coverage | 20 | 18% |
+| Gap baselines (total) | 247 | — |
+
+## sfc-devops-infrastructure (0✅ 11⚠️ 4❌)
+
+### ❌ di-1.1.1: DevOps Security Owner
+
+
+**Gaps (1):**
+- ❌ Accountability scope covers policy maintenance, security reviews, access control oversight, pipeline governance, and incident escalation
+
+### ❌ di-1.1.2: DevOps Security Policy
+
+
+**Gaps (3):**
+- ❌ Policy covers environment standards, access controls, deployment procedures, code management, and supply chain security
+- ❌ Accessible to all developers and infrastructure operators
+- ❌ Reviewed at least annually and after significant changes
+
+### ⚠️ di-1.1.3: Development Environment Isolation
+
+🟡 **[/devsecops/integrated-development-environments](/devsecops/integrated-development-environments)**  (partial)
+- Met: See QA notes: Evaluator missed coverage. IDE page states 'Ensure that potential development environments are isolated from production environments' (addresses baseline about production credential isolation). CI/CD 
+
+**Gaps (5):**
+- ❌ Development activities performed in containerized or virtualized environments
+- ❌ Each code repository has its own isolated environment to prevent cross-contamination
+- ❌ Production credentials not accessible from development environments
+- ❌ Separate accounts or profiles for development vs. privileged operations
+- ❌ Code execution sandboxed to prevent host system compromise
+
+### ⚠️ di-1.1.4: Development Tools Approval
+
+🟡 **[/devsecops/integrated-development-environments](/devsecops/integrated-development-environments)**  (partial)
+- Met: Extensions and plugins obtained only from official repositories (mentions 'trusted sources')
+- Missed: Evaluation criteria cover IDEs, extensions, plugins, AI-powered tools, and third-party services; AI tools assessed for data privacy risks; Approved tool list maintained; unapproved tools restricted; Regular reviews of installed tools
+
+**Gaps (4):**
+- ❌ Evaluation criteria cover IDEs, extensions, plugins, AI-powered tools, and third-party services
+- ❌ AI tools assessed for data privacy risks
+- ❌ Approved tool list maintained; unapproved tools restricted
+- ❌ Regular reviews of installed tools to identify unused or unrecognized items
+
+### ⚠️ di-2.1.1: Repository Security
+
+🟡 **[/secure-software-development/secure-code-repositories-version-control](/secure-software-development/secure-code-repositories-version-control)** → Best Practices for Secure Code Repositories (partial)
+- Met: Role-based access control with least-privilege permissions; Branch protection rules enforced on main/production branches; Signed commits required for all code changes; Multi-party code review required for merges; MFA required for all repository members
+- Missed: Repository access reviewed periodically (audit logs mentioned but not periodic access reviews)
+
+**Gaps (1):**
+- ❌ Repository access reviewed periodically
+
+### ⚠️ di-2.1.2: Secret Scanning
+
+🟡 **[/devsecops/continuous-integration-continuous-deployment](/devsecops/continuous-integration-continuous-deployment)**  (partial)
+- Met: CI/CD pipeline checks for leaked credentials (partial: automated scanning); Scanning integrated into CI/CD pipeline
+- Missed: Pre-commit hooks deployed to prevent secrets from being committed; Remediation procedures for discovered secrets (immediate rotation, revocation)
+
+**Gaps (2):**
+- ❌ Pre-commit hooks deployed to prevent secrets from being committed in the first place
+- ❌ Remediation procedures for discovered secrets (immediate rotation, revocation)
+
+### ❌ di-2.1.3: External Contributor Review
+
+
+**Gaps (4):**
+- ❌ Additional approvers required for all external code contributions
+- ❌ Code contributions tracked; unexpected changes flagged
+- ❌ External collaborators restricted to minimum necessary repository permissions
+- ❌ CI/CD pipelines do not automatically execute for external contributor PRs without approval
+
+### ⚠️ di-2.1.4: Dependency and Supply Chain Security
+
+🟡 **[/supply-chain/dependency-awareness](/supply-chain/dependency-awareness)** → Best Practices for Dependency Awareness (partial)
+- Met: Packages obtained from official repositories and trusted sources only; Dependencies scanned for known vulnerabilities before deployment; Regular dependency audits for outdated or vulnerable components
+- Missed: Package names verified against typosquatting patterns before installation; Dependency version pinning enforced to prevent automatic updates; Changelog reviewed for dependency updates to verify expected functionality
+
+**Gaps (3):**
+- ❌ Package names verified against typosquatting patterns before installation
+- ❌ Dependency version pinning enforced to prevent automatic updates to compromised versions
+- ❌ Changelog reviewed for dependency updates to verify expected functionality
+
+### ⚠️ di-3.1.1: Pipeline Security Controls
+
+🟡 **[/devsecops/continuous-integration-continuous-deployment](/devsecops/continuous-integration-continuous-deployment)**  (partial)
+- Met: Builds are deterministic with strict dependency sets; Strict access controls for CI/CD pipelines (partial: limits who can modify)
+- Missed: Pipeline configuration changes require multi-party approval; Separate service accounts with minimal permissions used for pipeline execution; Manual deployment by humans restricted; deployments automated through controlled pipelines; Pipeline and build configurations version-controlled and reviewed
+
+**Gaps (4):**
+- ❌ Pipeline configuration changes require multi-party approval
+- ❌ Separate service accounts with minimal permissions used for pipeline execution
+- ❌ Manual deployment by humans restricted; deployments automated through controlled pipelines
+- ❌ Pipeline and build configurations version-controlled and reviewed
+
+### ❌ di-3.1.2: Secrets Management
+
+
+**Gaps (5):**
+- ❌ Dedicated secrets management system used (not environment variables in plain text)
+- ❌ Secrets never stored in source code or unencrypted configuration files
+- ❌ Production secrets not directly accessible by humans
+- ❌ Pipeline secrets accessible only by service accounts
+- ❌ Secret rotation schedule defined; rotation triggered immediately after suspected compromise
+
+### ⚠️ di-3.1.3: Security Testing Integration
+
+🟡 **[/devsecops/continuous-integration-continuous-deployment](/devsecops/continuous-integration-continuous-deployment)**  (partial)
+- Met: Static analysis and dependency scanning integrated into CI/CD; PR testing must pass before merging (implies review)
+- Missed: Security scan results reviewed before deployment approval (not explicitly stated); Testing and validation performed in staging environments before production deployment
+🟡 **[/devsecops/security-testing](/devsecops/security-testing)**  (partial)
+- Met: SAST tools integrated into CI/CD pipeline
+- Missed: Dependency vulnerability scanning automated in CI/CD (DAST mentioned, not dependency scanning); Security scan results reviewed before deployment approval; Testing and validation performed in staging environments before production
+
+**Gaps (2):**
+- ❌ Security scan results reviewed before deployment approval
+- ❌ Testing and validation performed in staging environments before production deployment
+
+### ⚠️ di-4.1.1: Infrastructure as Code
+
+🟡 **[/security-automation/infrastructure-as-code](/security-automation/infrastructure-as-code)**  (partial)
+- Met: All infrastructure defined and managed through code; IaC security scanning performed before deployment
+- Missed: Infrastructure changes deployed through automated pipelines, no manual steps required; Infrastructure changes require multi-party approval
+
+**Gaps (2):**
+- ❌ Infrastructure changes deployed through automated pipelines, no manual steps required
+- ❌ Infrastructure changes require multi-party approval
+
+### ⚠️ di-4.1.2: Infrastructure Access Controls
+
+🟡 **[/secure-software-development/secure-code-repositories-version-control](/secure-software-development/secure-code-repositories-version-control)** → Best Practices for Secure Code Repositories (partial)
+- Met: Individual accounts with MFA required (for repositories); Role-based access control (minimum necessary permissions); All access activities logged and monitored (audit logs)
+- Missed: Privileged access is time-limited and requires multi-party approval (JIT access); Break-glass accounts established for emergency access; Break-glass usage triggers immediate alerts and requires post-incident review
+
+**Gaps (3):**
+- ❌ Privileged access is time-limited and requires multi-party approval (JIT access)
+- ❌ Break-glass accounts established for emergency access with individual accountability
+- ❌ Break-glass usage triggers immediate alerts to entire team and requires post-incident review
+
+### ⚠️ di-4.1.3: Backup and Disaster Recovery
+
+🟡 **[/secure-software-development/secure-code-repositories-version-control](/secure-software-development/secure-code-repositories-version-control)** → Secure Version Control Practices (partial)
+- Met: Regular backups of code repository; Backups stored independently (secure, offsite location)
+- Missed: Critical systems have automated backup procedures; Disaster recovery plan documented with RTO and RPO defined; Backup and recovery procedures tested regularly
+
+**Gaps (3):**
+- ❌ Critical systems have automated backup procedures (beyond just code repos)
+- ❌ Disaster recovery plan documented with recovery time and recovery point objectives defined
+- ❌ Backup and recovery procedures tested regularly
+
+### ⚠️ di-4.1.4: Cloud Security Monitoring
+
+🟡 **[/infrastructure/cloud](/infrastructure/cloud)** → Cloud Infrastructure (partial)
+- Met: Cloud security configurations monitored (comprehensive logging, monitoring, threat detection); Administrative actions trigger alerts (real-time incident response); Comprehensive logging enabled (AWS CloudTrail, Azure Monitor, Google Cloud Logging)
+- Missed: Cloud provider security notifications subscribed to and promptly reviewed; Multi-cloud strategies considered to reduce single-provider dependency
+
+**Gaps (2):**
+- ❌ Cloud provider security notifications subscribed to and promptly reviewed
+- ❌ Multi-cloud strategies considered to reduce single-provider dependency
+
+## sfc-dns-registrar (4✅ 7⚠️ 5❌)
+
+### ❌ dns-1.1.1: Domain Security Owner
+
+
+**Gaps (1):**
+- ❌ Accountability scope covers policy maintenance, security reviews, renewal management, access control oversight, and incident escalation
+
+### ❌ dns-1.1.2: Domain Inventory and Documentation
+
+
+**Gaps (2):**
+- ❌ Registry includes domain name, ownership, purpose, expiration date, registrar, DNS record configurations, security settings (DNSSEC, CAA), and registrar account configurations
+- ❌ Accessible to relevant team members
+
+### ❌ dns-2.1.1: Domain Classification and Compliance
+
+
+**Gaps (4):**
+- ❌ Classification considers criticality, financial exposure, and operational impact
+- ❌ Domains where users may transact funds or that are external-facing classified at the highest tier
+- ❌ Each classification maps to specific security requirements (DNSSEC, locks, monitoring frequency, access controls)
+- ❌ Compliance verified at least annually through configuration review against documented standards
+
+### ✅ dns-2.1.2: Enterprise Registrar Security Requirements
+
+🟢 **[/infrastructure/domain-and-dns-security/registrar-and-locks](/infrastructure/domain-and-dns-security/registrar-and-locks)** → Choosing a Secure Registrar (full)
+- Met: Registrar supports registry locks (server-level EPP locks); Registrar supports hardware security key MFA (FIDO2/WebAuthn); Registrar has no history of social engineering vulnerabilities; Due diligence includes checking ICANN compliance notices
+
+### ⚠️ dns-3.1.1: Registrar Access Control
+
+🟡 **[/infrastructure/domain-and-dns-security/registrar-and-locks](/infrastructure/domain-and-dns-security/registrar-and-locks)** → Access Control Best Practices (partial)
+- Met: Hardware security key MFA (FIDO2/WebAuthn) required for all accounts; Access reviews conducted at least annually (mentions quarterly)
+- Missed: Documented who is authorized, how access is granted/revoked, and role-based permissions (mentions but doesn't teach HOW to document); Access revoked promptly when no longer needed (not actionably addressed)
+
+**Gaps (2):**
+- ❌ Documented procedures for who is authorized, how access is granted/revoked, and role-based permissions implementation
+- ❌ Prompt access revocation procedures when no longer needed
+
+### ⚠️ dns-3.1.2: Dedicated Domain Security Contact Email
+
+🟡 **[/infrastructure/domain-and-dns-security/registrar-and-locks](/infrastructure/domain-and-dns-security/registrar-and-locks)** → Dedicated Security Contact Email (partial)
+- Met: Hosted on a different domain than any domain it's responsible for; Not a personal email address; Used exclusively for domain security purposes
+- Missed: Alias that notifies multiple people (not explicitly stated)
+
+**Gaps (1):**
+- ❌ Alias that notifies multiple people
+
+### ❌ dns-3.1.3: Change Management for Domain Operations
+
+
+**Gaps (4):**
+- ❌ Covers transfers, deletions, nameserver changes, and DNS record modifications
+- ❌ Relevant team members notified before critical changes
+- ❌ All changes logged
+- ❌ Critical changes verified through out-of-band confirmation with the registrar
+
+### ⚠️ dns-4.1.1: DNS Security Standards
+
+🟡 **[/infrastructure/domain-and-dns-security/dnssec-and-email](/infrastructure/domain-and-dns-security/dnssec-and-email)** → DNSSEC Implementation (partial)
+- Met: DNSSEC enabled and validated on all critical domains; CAA records configured to restrict certificate issuance
+- Missed: TTL policies documented with rationale; Standards applied consistently based on domain classification
+
+**Gaps (2):**
+- ❌ TTL policies documented with rationale
+- ❌ Standards applied consistently based on domain classification
+
+### ⚠️ dns-4.1.2: Email Authentication Standards
+
+🟡 **[/infrastructure/domain-and-dns-security/dnssec-and-email](/infrastructure/domain-and-dns-security/dnssec-and-email)** → Email Security Configuration (partial)
+- Met: SPF, DKIM, and DMARC configured for all domains that send email; DMARC policy set to reject for domains actively sending email; DMARC aggregate reports (rua) monitored and reviewed; MTA-STS configured where supported; Domains that don't send email have SPF/DMARC records that reject all
+
+### ✅ dns-4.1.3: Domain Lock Implementation
+
+🟢 **[/infrastructure/domain-and-dns-security/registrar-and-locks](/infrastructure/domain-and-dns-security/registrar-and-locks)** → Registry Lock (EPP Lock) (full)
+- Met: Registry locks (server-level EPP locks) enabled for critical domains; Transfer locks enabled on all domains; Lock status verified periodically (mentions EPP status codes)
+
+### ❌ dns-4.1.4: TLS Certificate Lifecycle Management
+
+
+**Gaps (4):**
+- ❌ Covers issuance, renewal, and revocation procedures
+- ❌ Certificates tracked with expiration alerts
+- ❌ Automated renewal where possible
+- ❌ Revocation procedures documented for compromised certificates
+
+### ⚠️ dns-5.1.1: Domain and DNS Monitoring
+
+🟡 **[/infrastructure/domain-and-dns-security/monitoring-and-alerting](/infrastructure/domain-and-dns-security/monitoring-and-alerting)** → DNS Record Monitoring (partial)
+- Met: DNS record monitoring covers NS, A/AAAA, MX, TXT/SPF/DMARC, CAA, DNSSEC, TTL changes; Registration monitoring covers lock status, registrar settings, nameserver delegation; Critical alerts trigger immediate investigation; Monitoring infrastructure not dependent on domains being monitored
+- Missed: Alerting and escalation paths documented (mentioned but not detailed HOW to document)
+
+**Gaps (1):**
+- ❌ Detailed guidance on documenting alerting and escalation paths
+
+### ✅ dns-5.1.2: Certificate Transparency Monitoring
+
+🟢 **[/infrastructure/domain-and-dns-security/monitoring-and-alerting](/infrastructure/domain-and-dns-security/monitoring-and-alerting)** → Certificate Transparency Monitoring (full)
+- Met: Subscribed to a CT monitoring service that alerts on new certificate issuance; Alerts reviewed and unauthorized certificates investigated promptly; Wildcard certificates flagged if not expected
+
+### ✅ dns-5.1.3: Domain Expiration Prevention
+
+🟢 **[/infrastructure/domain-and-dns-security/registrar-and-locks](/infrastructure/domain-and-dns-security/registrar-and-locks)** → Domain Expiration Protection (full)
+- Met: Auto-renewal enabled on all domains; Calendar reminders at 90, 60, 30, and 7 days before expiration; Payment methods verified current; Backup person designated for renewal responsibility
+
+### ⚠️ dns-6.1.1: Alerting and Emergency Contacts
+
+🟡 **[/infrastructure/domain-and-dns-security/monitoring-and-alerting](/infrastructure/domain-and-dns-security/monitoring-and-alerting)** → Setting Up Alerts (partial)
+- Met: Alerting system in place to notify stakeholders when potential compromise detected; Communication plan for warning users (status page, social media)
+- Missed: Emergency contacts pre-documented (registrar security, SEAL 911, legal) - partially in overview but not comprehensive
+
+**Gaps (1):**
+- ❌ Comprehensive emergency contact documentation including registrar security team, SEAL 911, and legal counsel
+
+### ⚠️ dns-6.1.2: Domain Incident Response Plan
+
+🟡 **[/infrastructure/domain-and-dns-security/monitoring-and-alerting](/infrastructure/domain-and-dns-security/monitoring-and-alerting)** → Incident Response Plan (partial)
+- Met: Covers registrar account compromise, DNS hijacking, unauthorized transfers; Emergency registry lock activation procedures; Procedures for regaining control of compromised domains; Post-recovery validation (DNS records verified, credentials reset, logs reviewed)
+- Missed: Plan tested at least annually
+
+**Gaps (1):**
+- ❌ Plan tested at least annually (can be combined with broader IR drills)
+
+## sfc-incident-response (0✅ 10⚠️ 2❌)
+
+### ❌ ir-1.1.1: IR Team and Role Assignments
+
+
+**Gaps (6):**
+- ❌ Incident commander (with designated backup) who coordinates response, assigns tasks, and makes time-sensitive decisions
+- ❌ Subject matter experts identified for key domains (smart contracts, infrastructure, security) who can analyze attacks and prepare response strategies
+- ❌ Scribe role defined for real-time incident documentation
+- ❌ Communications personnel designated for public information sharing and record-keeping
+- ❌ Legal support available with procedures for reviewing response actions, whitehat engagement, and public communications
+- ❌ Decision makers defined for high-stakes decisions (system shutdown, public disclosure, fund recovery)
+
+### ⚠️ ir-1.1.2: Stakeholder Coordination and Contacts
+
+🟡 **[/multisig-for-protocols/emergency-procedures](/multisig-for-protocols/emergency-procedures)** → Emergency Contact Information (partial)
+- Met: External expertise contacts (Security team mentioned); Escalation order documented (template includes escalation to Security team)
+- Missed: Internal coordination procedures between technical and operational teams; External protocol contacts for dependencies; Legal counsel and PR contacts; Infrastructure vendor support contacts; Contact list reviewed quarterly
+🟡 **[/incident-management/playbooks/seal-911-war-room-guidelines](/incident-management/playbooks/seal-911-war-room-guidelines)** → Key Roles (partial)
+- Met: Internal coordination procedures (role assignments for Operations, Protocol Lead, Web/Infrastructure Lead, External Communicator); External expertise contacts (SEAL 911, security researchers); Escalation order (implicit in role structure)
+- Missed: External protocol contacts for dependencies; Legal counsel and PR contacts (communications mentioned but not specific contacts); Infrastructure vendor support contacts; Contact list reviewed quarterly
+🟡 **[/wallet-security/secure-multisig-best-practices](/wallet-security/secure-multisig-best-practices)** → Communication & Documentation (partial)
+- Met: Internal coordination (signers must notify multisig participants of incidents)
+- Missed: External protocol contacts; External expertise contacts; Legal counsel and PR contacts; Infrastructure vendor contacts; Contact list reviewed quarterly; Escalation order for P1 incidents
+
+**Gaps (4):**
+- ❌ External protocol contacts for protocols you depend on and protocols that depend on you
+- ❌ Legal counsel and communications/PR contacts with specific documented procedures
+- ❌ Infrastructure vendor support contacts and escalation procedures
+- ❌ Contact list reviewed at least quarterly and after team changes
+
+### ⚠️ ir-2.1.1: Monitoring Coverage
+
+🟡 **[/infrastructure/domain-and-dns-security/monitoring-and-alerting](/infrastructure/domain-and-dns-security/monitoring-and-alerting)** → DNS Record Monitoring (partial)
+- Met: Monitoring coverage for critical systems (DNS/domain infrastructure); Credential exposure detection (mentioned in Certificate Transparency monitoring); Organizational account monitoring (domain/DNS as critical organizational asset); Monitoring coverage documented (what to watch for is documented)
+- Missed: 24/7 monitoring with after-hours procedures; Credential and secret exposure in code repositories and dark web
+🟡 **[/monitoring/guidelines](/monitoring/guidelines)** → Best Practices (partial)
+- Met: Monitoring objectives defined (critical metrics); Monitoring coverage documented (define what to monitor)
+- Missed: 24/7 monitoring capabilities with after-hours procedures; Credential and secret exposure detection; Organizational account monitoring; Known gaps documented
+
+**Gaps (3):**
+- ❌ 24/7 monitoring capabilities with procedures for after-hours alert handling
+- ❌ Credential and secret exposure detection including dark web monitoring, breach database scanning, and secret scanning in code repositories
+- ❌ Organizational account monitoring including social media accounts and websites monitored for unauthorized access or compromise
+
+### ⚠️ ir-2.1.2: Alerting, Paging, and Escalation
+
+🟡 **[/multisig-for-protocols/emergency-procedures](/multisig-for-protocols/emergency-procedures)** → Immediate Actions (partial)
+- Met: Triage and classification procedures (assess scope, escalate); Management notification for high-severity (contact Security team); Escalation paths (Emergency notification template with escalation)
+- Missed: Automated alerting configured; Alerts include embedded triage guidance; Time-based escalation triggers; Redundant paging systems; On-call schedules maintained; Backup procedures when on-call unreachable
+
+**Gaps (6):**
+- ❌ Automated alerting configured for security events and operational issues
+- ❌ Alerts include embedded triage guidance for distinguishing true incidents from false positives
+- ❌ Time-based escalation triggers if initial responder doesn't acknowledge within defined window
+- ❌ Redundant paging systems with documented failover procedures
+- ❌ On-call schedules maintained with adequate coverage for operational needs
+- ❌ Backup procedures when on-call personnel are unreachable
+
+### ❌ ir-2.1.3: Logging Integrity and Retention
+
+
+**Gaps (5):**
+- ❌ Log retention periods defined for security, infrastructure, and cloud provider logs
+- ❌ Retention adequate for forensic analysis (consider regulatory requirements and typical investigation timelines)
+- ❌ Tamper-evident logging for security-relevant events including access logs, alerting system logs, and infrastructure logs
+- ❌ Alerts triggered if logs are altered, deleted, or if monitoring/logging is disabled
+- ❌ Log sources documented — what's captured and where it's stored
+
+### ⚠️ ir-3.1.1: Response Playbooks
+
+🟡 **[/multisig-for-protocols/emergency-procedures](/multisig-for-protocols/emergency-procedures)** → Key Compromise (partial)
+- Met: Playbooks cover key compromise scenario; Initial response actions (stop operations, notify, assess, escalate, document); Key compromise includes procedures for rotating keys; Role-specific responsibilities (First Reporter, team coordination)
+- Missed: Playbooks for protocol exploits, infrastructure failures, access control breaches, supply chain compromises, frontend/DNS compromise; Escalation criteria for leadership engagement, system shutdown, public disclosure, external assistance
+🟡 **[/wallet-security/secure-multisig-best-practices](/wallet-security/secure-multisig-best-practices)** → Signer rotation (partial)
+- Met: Key compromise procedures (signer rotation when compromised); Threshold reviewed after signer replacement
+- Missed: Playbooks for protocol exploits, infrastructure failures, access control breaches, supply chain, frontend/DNS; Initial response actions for each scenario; Role-specific responsibilities; Escalation criteria documented
+
+**Gaps (3):**
+- ❌ Playbooks cover protocol exploits, infrastructure failures, access control breaches, supply chain compromises, and frontend/DNS compromise
+- ❌ Each playbook includes containment, evidence preservation, and stakeholder notification
+- ❌ Escalation criteria documented for when to engage leadership, when to shut down systems, when to make public disclosure, and when to engage external assistance
+
+### ⚠️ ir-3.1.2: Signer Reachability and Coordination
+
+🟡 **[/wallet-security/secure-multisig-best-practices](/wallet-security/secure-multisig-best-practices)** → Training & Drills (partial)
+- Met: Procedures for emergency operations (drills mentioned); Tested quarterly (for emergency multisigs)
+- Missed: Cross-timezone signer availability procedures; Signers integrated into on-call/paging systems; Escalation paths when signers unreachable
+🟡 **[/multisig-for-protocols/setup-and-configuration](/multisig-for-protocols/setup-and-configuration)**  (partial)
+- Missed: Procedures for coordinating multisig operations during incidents; Cross-timezone signer availability; Signers integrated into on-call/paging; Escalation paths for unreachable signers; Tested quarterly
+
+**Gaps (3):**
+- ❌ Procedures for coordinating multisig operations during incidents, including cross-timezone signer availability
+- ❌ Signers integrated into on-call/paging systems
+- ❌ Escalation paths documented for when signers are unreachable
+
+### ⚠️ ir-3.1.3: Emergency Transaction Readiness
+
+🟡 **[/multisig-for-protocols/backup-signing-and-infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)** → UI Alternatives (partial)
+- Met: Backup signing infrastructure (Eternal Safe, Squads Public Client); Alternate signing UI (multiple UI options documented); Backup RPC providers (guidance provided); Alternate block explorer (Blockscout, explorer.solana.com, Solscan); Emergency execution procedures (documented how to use backup systems)
+- Missed: Pre-signed or pre-prepared emergency transactions
+🟡 **[/multisig-for-protocols/implementation-checklist](/multisig-for-protocols/implementation-checklist)** → Emergency Preparedness (partial)
+- Met: Backup signing infrastructure (downloaded backup UIs); Emergency execution procedures (understanding how to sign when primary UI is down)
+- Missed: Pre-signed or pre-prepared emergency transactions
+
+**Gaps (1):**
+- ❌ Pre-signed or pre-prepared emergency transactions for critical protocol functions (pause, freeze, parameter changes) where feasible
+
+### ⚠️ ir-4.1.1: Incident Communication Channels
+
+🟡 **[/multisig-for-protocols/implementation-checklist](/multisig-for-protocols/implementation-checklist)** → Documentation & Communication (partial)
+- Met: Primary and backup communication channels (set up per Communication Setup); Multiple channels on different platforms (tested emergency notification)
+- Missed: Documented access controls and member lists; Documented failover procedures; Procedures for rapidly creating incident-specific channels; Secure communication procedures for sensitive information
+🟡 **[/multisig-for-protocols/emergency-procedures](/multisig-for-protocols/emergency-procedures)** → Emergency Communication Protocols (partial)
+- Met: Multiple communication channels (primary, backup, emergency contacts); Secure communication procedures (need-to-know, secure channels); Procedures for identity verification during incidents
+- Missed: Documented access controls and member lists; Documented failover procedures; Procedures for rapidly creating war room channels
+
+**Gaps (3):**
+- ❌ Dedicated incident communication channels with documented access controls and member lists
+- ❌ Documented failover procedures between primary and backup channels
+- ❌ Procedures for rapidly creating incident-specific channels (war room) when needed
+
+### ⚠️ ir-4.1.2: Internal Status Updates
+
+🟡 **[/incident-management/communication-strategies](/incident-management/communication-strategies)** → Best Practices (partial)
+- Met: Status update cadence defined (regular updates to stakeholders); Format and distribution for internal stakeholders (provide regular updates to employees)
+
+### ⚠️ ir-4.1.3: Public Communication and Information Management
+
+🟡 **[/incident-management/playbooks/seal-911-war-room-guidelines](/incident-management/playbooks/seal-911-war-room-guidelines)** → Communications (partial)
+- Met: Procedures for coordinating communications during and after incidents; Procedures for managing public information flow (monitoring social media); Designated approval flow (External Communicator role)
+- Missed: Pre-approved communication templates for different incident types and severity
+🟡 **[/multisig-for-protocols/emergency-procedures](/multisig-for-protocols/emergency-procedures)** → Emergency Notification Template (partial)
+- Met: Pre-approved communication templates (emergency notification template provided)
+- Missed: Templates for different incident types and severity levels; Procedures for coordinating with protocol users during/after; Procedures for managing misinformation; Designated approval flow before public statements
+
+**Gaps (2):**
+- ❌ Pre-approved communication templates for different incident types and severity levels (only one emergency template provided)
+- ❌ Procedures for managing public information flow and correcting misinformation during active incidents
+
+### ⚠️ ir-5.1.1: IR Drills and Testing
+
+🟡 **[/multisig-for-protocols/emergency-procedures](/multisig-for-protocols/emergency-procedures)** → Emergency Drill Procedures (partial)
+- Met: Drills conducted regularly (quarterly, bi-annually, annually); Tests full pipeline (notification, response time, process verification); Production alerting validated (notification test, response time measurement)
+- Missed: Drills cover different incident types across exercises; Drill documentation with gaps and corrective actions; Corrective actions tracked to completion; Findings incorporated into playbook updates
+🟡 **[/incident-management/playbooks/decentralized-ir](/incident-management/playbooks/decentralized-ir)** → Keep It Alive (partial)
+- Met: Drills conducted regularly (quarterly red team drills); Findings incorporated into updates (iterate on framework during retrospective)
+- Missed: Tests full pipeline from monitoring through recovery; Production alerting validated end-to-end; Drill documentation with participants, response times, gaps; Corrective actions tracked to completion
+
+**Gaps (3):**
+- ❌ Drills cover different incident types across exercises (protocol exploit, infrastructure failure, key compromise, etc.)
+- ❌ Drill documentation includes date, scenario, participants, response times, gaps identified, and corrective actions
+- ❌ Corrective actions tracked to completion with owners and deadlines
+
+## sfc-multisig-ops (11✅ 10⚠️ 3❌)
+
+### ⚠️ ms-1.1.1: Named Multisig Operations Owner
+
+🟡 **[/multisig-for-protocols/implementation-checklist](/multisig-for-protocols/implementation-checklist)** → For Multisig Administrators (partial)
+- Missed: Accountability scope covers policy maintenance, signer onboarding/offboarding, documentation accuracy, periodic reviews, and incident escalation
+
+**Gaps (1):**
+- ❌ Accountability scope covers policy maintenance, signer onboarding/offboarding, documentation accuracy, periodic reviews, and incident escalation - NO page teaches organizations HOW to establish clear accountability with defined scope covering all these areas
+
+### ⚠️ ms-1.1.2: Multisig Registry and Documentation
+
+🟡 **[/wallet-security/secure-multisig-best-practices](/wallet-security/secure-multisig-best-practices)** → Communication & Documentation (partial)
+- Met: Registry includes address, network, threshold, classification, purpose, signer addresses, controlled contracts, on-chain roles, and last review date (mentions documentation of purpose, wallet address, signer addresses)
+- Missed: Updated within 24 hours for security-critical changes, 3 days for routine changes; Accessible to signers and key personnel
+🟡 **[/multisig-for-protocols/implementation-checklist](/multisig-for-protocols/implementation-checklist)** → Documentation & Communication (partial)
+- Missed: Registry includes address, network, threshold, classification, purpose, signer addresses, controlled contracts, on-chain roles, and last review date; Updated within 24 hours for security-critical changes, 3 days for routine changes; Accessible to signers and key personnel
+
+**Gaps (3):**
+- ❌ Updated within 24 hours for security-critical changes, 3 days for routine changes - NO page provides specific update timeline requirements
+- ❌ Accessible to signers and key personnel - NO page substantively teaches access control for registry
+- ❌ Complete registry structure with ALL required fields (network, classification, controlled contracts, on-chain roles, last review date) not fully taught
+
+### ✅ ms-2.1.1: Multisig Classification and Risk-Based Controls
+
+🟢 **[/multisig-for-protocols/planning-and-classification](/multisig-for-protocols/planning-and-classification)** → Classification Process (full)
+- Met: Classification considers impact factors (financial exposure, protocol criticality, reputational risk) and operational needs (response time, coordination complexity); Each classification maps to specific required controls (thresholds, quorum composition, review cadence); Higher-risk classifications require stronger controls (more signers, higher thresholds); Classifications reviewed every 6 months and after significant changes (TVL shifts, new products, protocol upgrades, security incidents)
+- Missed: All multisigs must have at least 3 distinct signers with a signing threshold of 50% or greater; N-of-N configurations should be avoided
+🟢 **[/wallet-security/secure-multisig-best-practices](/wallet-security/secure-multisig-best-practices)** → Thresholds & Configuration (full)
+- Met: All multisigs must have at least 3 distinct signers with a signing threshold of 50% or greater; N-of-N configurations should be avoided; Higher-risk classifications require stronger controls (more signers, higher thresholds)
+- Missed: Classification considers impact factors and operational needs in a formal framework; Each classification maps to specific required controls; Classifications reviewed every 6 months and after significant changes
+
+### ⚠️ ms-2.1.2: Contract-Level Security Controls
+
+🟡 **[/multisig-for-protocols/setup-and-configuration](/multisig-for-protocols/setup-and-configuration)** → Contract-Level Controls (partial)
+- Met: Evaluation covers timelocks, modules, guards, address whitelisting, invariant enforcement, and parameter bounds; Security review required before enabling any module or guard
+- Missed: Controls evaluated for each multisig based on classification; Decisions documented, including rationale for controls not implemented
+🟡 **[/wallet-security/secure-multisig-best-practices](/wallet-security/secure-multisig-best-practices)** → Contract-Level Security (partial)
+- Met: Evaluation covers timelocks, modules, guards, address whitelisting, invariant enforcement, and parameter bounds
+- Missed: Controls evaluated for each multisig based on classification; Security review required before enabling any module or guard; Decisions documented, including rationale for controls not implemented
+
+**Gaps (2):**
+- ❌ Controls evaluated for each multisig based on classification - NO page teaches systematic evaluation process tied to classification levels
+- ❌ Decisions documented, including rationale for controls not implemented - NO page provides documentation requirements for control selection decisions
+
+### ❌ ms-2.1.3: Exception Approval Process
+
+
+**Gaps (2):**
+- ❌ Exceptions require documented justification, expiry date, compensating controls, and remediation plan - NO page teaches exception approval process
+- ❌ Critical-class exceptions require executive or security-lead approval - NO page defines approval authority by classification
+
+### ❌ ms-2.1.4: Wallet Segregation
+
+
+**Gaps (2):**
+- ❌ Segregation considers value, operational needs, and risk tolerance - NO page substantively teaches HOW to determine segregation strategy
+- ❌ Examples include hot/cold separation and treasury distribution across multiple wallets - mentioned in context of travel security in /opsec/travel/guide but NOT as a multisig operational requirement
+
+### ⚠️ ms-3.1.1: Signer Address Verification
+
+🟡 **[/wallet-security/secure-multisig-best-practices](/wallet-security/secure-multisig-best-practices)** → Communication & Documentation (partial)
+- Met: Verification process includes message signing with the signer address, verification via an independent tool, and documented proof of verification
+🟡 **[/multisig-for-protocols/setup-and-configuration](/multisig-for-protocols/setup-and-configuration)** → Pre-Launch Checklist (partial)
+- Missed: Verification process includes message signing with the signer address, verification via an independent tool, and documented proof of verification
+
+### ✅ ms-3.1.2: Signer Key Management Standards
+
+🟢 **[/wallet-security/secure-multisig-best-practices](/wallet-security/secure-multisig-best-practices)** → Thresholds & Configuration (full)
+- Met: Hardware wallets required for all multisig operations; Each signer uses a fresh, dedicated address per multisig, used exclusively for that multisig's operations
+
+### ✅ ms-3.1.3: Seed Phrase Backup and Protection
+
+🟢 **[/wallet-security/seed-phrase-management](/wallet-security/seed-phrase-management)** → Secure Storage Practices (full)
+- Met: Seed phrases never stored digitally, in cloud storage, or photographed; Backups are geographically distributed (disaster resistant); No single point of compromise (theft resistant); Recoverable if one operator is unavailable (operator-loss resistant)
+
+### ⚠️ ms-3.1.4: Signer Lifecycle Management
+
+🟡 **[/wallet-security/secure-multisig-best-practices](/wallet-security/secure-multisig-best-practices)** → Signer rotation (partial)
+- Missed: Offboarded signers removed within 48-72 hours (Emergency-class), 7 days (Critical-class), 14 days (others); Access reviews quarterly, confirming each signer still controls their key
+
+**Gaps (2):**
+- ❌ Offboarded signers removed within 48-72 hours (Emergency-class), 7 days (Critical-class), 14 days (others) - NO page provides specific timeline requirements by classification
+- ❌ Access reviews quarterly, confirming each signer still controls their key - NO page teaches quarterly access review process
+
+### ✅ ms-3.1.5: Signer Training and Assessment
+
+🟢 **[/multisig-for-protocols/implementation-checklist](/multisig-for-protocols/implementation-checklist)** → For Signers (full)
+- Met: Training covers transaction verification, emergency procedures, phishing and social engineering awareness; Practical skills assessment included
+- Missed: Annual refreshers; updates within 30 days of significant procedure changes
+
+**Gaps (1):**
+- ❌ Annual refreshers; updates within 30 days of significant procedure changes - NO page specifies ongoing training cadence requirements
+
+### ✅ ms-3.1.6: Hardware Wallet Standards
+
+🟢 **[/multisig-for-protocols/implementation-checklist](/multisig-for-protocols/implementation-checklist)** → Hardware & Security Setup (full)
+- Met: Wallet capability requirements include adequate display, clear signing support, PIN security, and firmware integrity verification; Procurement through verified supply chains (direct from manufacturer or authorized resellers), with device authenticity verification
+
+### ✅ ms-3.1.7: Secure Signing Environment
+
+🟢 **[/multisig-for-protocols/personal-security-opsec](/multisig-for-protocols/personal-security-opsec)** → Network Security (full)
+- Met: Device security requirements documented and enforced; Dedicated signing devices or network isolation for high-value operations
+
+### ✅ ms-3.1.8: Signer Diversity
+
+🟢 **[/wallet-security/secure-multisig-best-practices](/wallet-security/secure-multisig-best-practices)** → Strategic Signer Distribution (full)
+- Met: Diversity requirements scale with multisig classification (inferred from role diversity, geographical separation, external parties requirements)
+
+### ✅ ms-4.1.1: Transaction Handling Process
+
+🟢 **[/wallet-security/signing-and-verification/secure-multisig-signing-process](/wallet-security/signing-and-verification/secure-multisig-signing-process)** → Phase 1: Signing the Off-Chain Message (full)
+- Met: Process covers initiation, approval, simulation, execution, and confirmation; Each signer independently verifies transaction details (chain ID, target address, calldata, value, nonce, operation type) before signing; Transaction hashes compared across at least two independent interfaces; DELEGATECALL operations to untrusted addresses flagged as high risk
+- Missed: Defines who is authorized to initiate transactions; High-risk transactions require waiting periods where feasible and elevated threshold approval; High-risk thresholds defined based on classification and reviewed periodically; Private transaction submission used when appropriate to prevent front-running or MEV extraction
+🟡 **[/wallet-security/secure-multisig-best-practices](/wallet-security/secure-multisig-best-practices)** → Operational Best Practices (partial)
+- Met: Each signer independently verifies transaction details before signing; Transaction simulation used before signing
+- Missed: Process covers initiation, approval, simulation, execution, and confirmation; Defines who is authorized to initiate transactions; Transaction hashes compared across at least two independent interfaces; DELEGATECALL operations flagged as high risk; High-risk transactions require waiting periods and elevated threshold approval; High-risk thresholds defined based on classification; Private transaction submission used when appropriate
+
+**Gaps (4):**
+- ❌ Defines who is authorized to initiate transactions - NO page teaches authorization framework for transaction initiation
+- ❌ High-risk transactions require waiting periods where feasible and elevated threshold approval - mentioned timelocks in setup but not as operational requirement
+- ❌ High-risk thresholds defined based on classification and reviewed periodically - NO page teaches risk threshold definition process
+- ❌ Private transaction submission used when appropriate to prevent front-running or MEV extraction - NO page teaches when/how to use private RPCs for transaction submission
+
+### ❌ ms-4.1.2: Transaction Audit Trails
+
+
+**Gaps (2):**
+- ❌ Retained for 3 years - NO page specifies retention period
+- ❌ Records include proposer, approvers, verification evidence, timestamps, and issues encountered - NO page teaches comprehensive audit trail documentation requirements
+
+### ⚠️ ms-4.1.3: Tool and Platform Evaluation
+
+🟡 **[/multisig-for-protocols/implementation-checklist](/multisig-for-protocols/implementation-checklist)** → Transaction Verification (partial)
+- Met: Evaluation considers whether tools are open source or audited by 2+ reputable firms (implied by tool recommendations)
+- Missed: Formal process for adopting new tools; Tools have no known critical unpatched vulnerabilities and have established ecosystem adoption
+
+**Gaps (2):**
+- ❌ Formal process for adopting new tools - NO page teaches tool adoption approval process
+- ❌ Tools have no known critical unpatched vulnerabilities and have established ecosystem adoption - mentioned but not taught as evaluation criteria
+
+### ✅ ms-4.1.4: Backup Signing Infrastructure
+
+🟢 **[/multisig-for-protocols/backup-signing-and-infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)** → UI Alternatives (full)
+- Met: Alternate signing UI; 2-3 backup RPC providers; Alternate block explorer
+
+### ⚠️ ms-5.1.1: Secure Communication Procedures
+
+🟡 **[/multisig-for-protocols/implementation-checklist](/multisig-for-protocols/implementation-checklist)** → Documentation & Communication (partial)
+- Met: Dedicated primary and backup channels on different platforms; End-to-end encryption, MFA required, invitation-based membership
+- Missed: Signer identity verified as standard procedure during signing operations (e.g., code words, video call, secondary authenticated channel); Documented procedures for channel compromise including switching to backup channels and out-of-band verification; All signers trained on these procedures; compromise response tested annually
+🟡 **[/multisig-for-protocols/emergency-procedures](/multisig-for-protocols/emergency-procedures)** → Communication Account Compromise (partial)
+- Met: Documented procedures for channel compromise including switching to backup channels and out-of-band verification
+- Missed: Dedicated primary and backup channels on different platforms; End-to-end encryption, MFA required, invitation-based membership; Signer identity verified as standard procedure during signing operations; All signers trained on these procedures; compromise response tested annually
+
+**Gaps (2):**
+- ❌ Signer identity verified as standard procedure during signing operations (e.g., code words, video call, secondary authenticated channel) - mentioned in emergency procedures but NOT as standard operational procedure for ALL signing operations
+- ❌ All signers trained on these procedures; compromise response tested annually - NO page specifies annual testing requirement for communication compromise procedures
+
+### ⚠️ ms-5.1.2: Emergency Contact List
+
+🟡 **[/multisig-for-protocols/implementation-checklist](/multisig-for-protocols/implementation-checklist)** → Documentation & Communication (partial)
+- Missed: Includes protocol security team, external security resources, legal/compliance contacts, and backup contacts for signers; Personal emergency contacts for each signer (e.g., trusted family member, close colleague) for situations where the signer is unreachable through normal channels; Reviewed every 6 months
+🟡 **[/multisig-for-protocols/emergency-procedures](/multisig-for-protocols/emergency-procedures)** → Emergency Contact Information (partial)
+- Met: Includes protocol security team, external security resources, legal/compliance contacts, and backup contacts for signers
+- Missed: Personal emergency contacts for each signer; Reviewed every 6 months
+
+**Gaps (2):**
+- ❌ Personal emergency contacts for each signer (e.g., trusted family member, close colleague) for situations where the signer is unreachable through normal channels - NO page teaches requirement for personal emergency contacts
+- ❌ Reviewed every 6 months - NO page specifies review cadence for emergency contact lists
+
+### ✅ ms-6.1.1: Emergency Playbooks
+
+🟢 **[/multisig-for-protocols/emergency-procedures](/multisig-for-protocols/emergency-procedures)** → Key Compromise (full)
+- Met: Scenarios covered include key compromise, lost access, communication channel compromise, and urgent protocol actions; Each scenario has procedures and escalation paths; Playbooks accessible through at least one backup method independent of the primary documentation platform
+
+### ⚠️ ms-6.1.2: Signer Reachability and Escalation
+
+🟡 **[/multisig-for-protocols/planning-and-classification](/multisig-for-protocols/planning-and-classification)** → Step 2: Operational Assessment (partial)
+- Met: Response times by classification - Emergency less than 2 hours, Time-Sensitive 2-12 hours, Routine 24-48 hours
+- Missed: Paging covers all signers including external parties; Tested quarterly; Escalation paths documented
+🟡 **[/multisig-for-protocols/emergency-procedures](/multisig-for-protocols/emergency-procedures)** → For Emergency Response Multisigs (partial)
+- Met: Escalation paths documented
+- Missed: Response times by classification; Paging covers all signers including external parties; Tested quarterly
+
+**Gaps (2):**
+- ❌ Paging covers all signers including external parties - NO page teaches establishment of paging system for all signers
+- ❌ Tested quarterly - NO page specifies quarterly testing requirement for reachability
+
+### ⚠️ ms-6.1.3: Multisig Monitoring and Alerts
+
+🟡 **[/wallet-security/secure-multisig-best-practices](/wallet-security/secure-multisig-best-practices)** → Operational Best Practices (partial)
+- Met: Monitored events include signer/threshold changes, transfers exceeding thresholds, nonce gaps, interactions with unknown addresses, failed transactions, module/guard changes (partial list mentioned)
+- Missed: Alerting and escalation paths documented; Monitoring infrastructure protected against tampering
+🟡 **[/multisig-for-protocols/setup-and-configuration](/multisig-for-protocols/setup-and-configuration)** → Active Monitoring (partial)
+- Met: Monitored events include proposed transactions, new signatures, and owner changes (partial list)
+- Missed: Monitored events include transfers exceeding thresholds, nonce gaps, interactions with unknown addresses, failed transactions, module/guard changes, low submitter/proposer balances; Alerting and escalation paths documented; Monitoring infrastructure protected against tampering
+
+**Gaps (3):**
+- ❌ Complete list of monitored events (transfers exceeding thresholds, nonce gaps, interactions with unknown addresses, failed transactions, module/guard changes, low submitter/proposer balances) - NO page provides comprehensive monitoring event list
+- ❌ Alerting and escalation paths documented - NO page teaches documentation of alert escalation
+- ❌ Monitoring infrastructure protected against tampering - NO page addresses monitoring system security
+
+### ✅ ms-6.1.4: Emergency Drills and Improvement
+
+🟡 **[/multisig-for-protocols/implementation-checklist](/multisig-for-protocols/implementation-checklist)** → Specialized Training by Use Case (partial)
+- Met: Annual minimum (implied by emergency simulation drills requirement)
+- Missed: After major procedure changes; Documentation includes date, participants, response times, issues identified, and improvements made
+🟢 **[/multisig-for-protocols/emergency-procedures](/multisig-for-protocols/emergency-procedures)** → Emergency Drill Procedures (full)
+- Met: Annual minimum (quarterly for some tests); After major procedure changes (implied); Documentation includes date, participants, response times, issues identified, and improvements made
+
+## sfc-treasury-ops (4✅ 12⚠️ 5❌)
+
+### ❌ tro-1.1.1: Treasury Operations Owner
+
+
+**Gaps (1):**
+- ❌ Accountability scope covers policy upkeep, security reviews, operational hygiene, access control oversight, and incident escalation
+
+### ⚠️ tro-1.1.2: Treasury Registry and Documentation
+
+🟡 **[/treasury-operations/registration-documents](/treasury-operations/registration-documents)** → Registration Template (partial)
+- Met: Registry includes wallet/account address, network/chain, custody provider, custody model, purpose/classification, authorized signers/approvers, controlled contracts or protocols, and last review date; Accessible to authorized treasury personnel
+- Missed: Updated within 24 hours for security-critical changes (signer changes, new wallets), 3 days for routine changes
+
+**Gaps (1):**
+- ❌ Updated within 24 hours for security-critical changes (signer changes, new wallets), 3 days for routine changes
+
+### ⚠️ tro-1.1.3: Custody Architecture Rationale
+
+🟡 **[/treasury-operations/enhanced-controls](/treasury-operations/enhanced-controls)** → MPC for Large Holdings (partial)
+- Met: Custody model documented for each wallet/account (custodial, self-custody, co-managed, MPC, multisig, HSM)
+- Missed: Technology trade-offs understood by the team; Custody architecture reviewed when treasury size, operational needs, or risk profile changes significantly
+
+**Gaps (2):**
+- ❌ Technology trade-offs understood by the team (not necessarily a formal document — could be a brief internal memo)
+- ❌ Custody architecture reviewed when treasury size, operational needs, or risk profile changes significantly
+
+### ⚠️ tro-1.1.4: Treasury Infrastructure Change Management
+
+🟡 **[/treasury-operations/registration-documents](/treasury-operations/registration-documents)** → Access Change Template (partial)
+- Met: Changes require documented approval before implementation; All changes logged with justification and approver
+- Missed: Covers wallet setups, custody configurations, signer/approver permission changes, and protocol integrations; Changes reflected in the treasury registry within defined SLAs; Rollback procedures documented for critical changes
+
+**Gaps (3):**
+- ❌ Covers wallet setups, custody configurations, signer/approver permission changes, and protocol integrations
+- ❌ Changes reflected in the treasury registry within defined SLAs
+- ❌ Rollback procedures documented for critical changes
+
+### ✅ tro-2.1.1: Treasury Wallet Risk Classification
+
+🟢 **[/treasury-operations/classification](/treasury-operations/classification)**  (full)
+- Met: Classification considers financial exposure, operational dependency, and regulatory impact; Impact levels defined (e.g., Low <1%, Medium 1-10%, High 10-25%, Critical >25% of total assets); Operational types defined based on transaction frequency and urgency requirements; Each classification maps to specific controls including approval thresholds, MFA requirements, whitelist delays, and monitoring levels; Classification reviewed when asset values, operational patterns, or risk profile change significantly
+
+### ❌ tro-2.1.2: Fund Allocation Limits and Rebalancing
+
+
+**Gaps (4):**
+- ❌ Maximum allocation defined per wallet, per custody provider, and per chain
+- ❌ Rebalancing triggers documented (e.g., when a wallet exceeds its allocation ceiling or falls below operational minimums)
+- ❌ Allocation limits reviewed periodically and after significant treasury changes
+- ❌ No single wallet or custody account holds more than the organization's defined maximum concentration
+
+### ⚠️ tro-3.1.1: Custody Platform Security Configuration
+
+🟡 **[/treasury-operations/enhanced-controls](/treasury-operations/enhanced-controls)** → Access Security (partial)
+- Met: Transaction policy rules configured: multi-approval workflows, approval thresholds scaled to transaction value, address whitelisting with cooling-off periods, velocity/spending limits; Hardware security key MFA required for all approvers on High and Critical accounts; Session timeouts and re-authentication for sensitive operations; Network restrictions: IP whitelisting, VPN requirements where supported, geographic access restrictions; Separation of duties enforced: initiators cannot approve their own transactions, admins cannot unilaterally execute withdrawals
+- Missed: Platform configurations documented and reviewed at least quarterly
+🟡 **[/treasury-operations/registration-documents](/treasury-operations/registration-documents)** → Security Configuration Template (partial)
+- Met: Transaction policy rules configured: multi-approval workflows, approval thresholds scaled to transaction value, address whitelisting with cooling-off periods, velocity/spending limits; Hardware security key MFA required for all approvers on High and Critical accounts; Session timeouts and re-authentication for sensitive operations; Network restrictions: IP whitelisting, VPN requirements where supported, geographic access restrictions; Separation of duties enforced: initiators cannot approve their own transactions, admins cannot unilaterally execute withdrawals; Platform configurations documented and reviewed at least quarterly
+
+### ⚠️ tro-3.1.2: Credential and Secret Management
+
+🟡 **[/treasury-operations/enhanced-controls](/treasury-operations/enhanced-controls)** → Access Security (partial)
+- Met: Credentials stored in dedicated secret management systems, not in code, documents, or shared drives; Owner and admin credentials isolated from day-to-day operational access
+- Missed: Covers API keys, service accounts, owner/admin credentials, and signing keys; Credential rotation schedule defined and enforced; Access to credentials logged and monitored
+🟡 **[/wallet-security/seed-phrase-management](/wallet-security/seed-phrase-management)**  (partial)
+- Met: Credentials stored in dedicated secret management systems, not in code, documents, or shared drives
+- Missed: Covers API keys, service accounts, owner/admin credentials, and signing keys; Owner and admin credentials isolated from day-to-day operational access; Credential rotation schedule defined and enforced; Access to credentials logged and monitored
+
+**Gaps (2):**
+- ❌ Credential rotation schedule defined and enforced
+- ❌ Access to credentials logged and monitored
+
+### ✅ tro-3.1.3: Access Reviews for Treasury Systems
+
+🟢 **[/treasury-operations/registration-documents](/treasury-operations/registration-documents)** → Quarterly Review Template (full)
+- Met: Access reviews conducted at least quarterly for High/Critical accounts, annually for others; Reviews verify each user still requires their current access level; Access promptly revoked when personnel change roles or leave
+
+### ⚠️ tro-3.1.4: Personnel Operational Security
+
+🟡 **[/treasury-operations/enhanced-controls](/treasury-operations/enhanced-controls)** → Device Security (partial)
+- Met: Device security requirements documented: dedicated devices for custody access, full disk encryption, automatic screen lock; VPN mandatory for all remote treasury platform access; Mobile devices used as second factors have endpoint security monitoring
+- Missed: Signing devices (hardware wallets) securely stored when not in use; Backup materials (seed phrases, recovery keys) stored securely with geographic distribution; Travel security procedures for personnel with signing or custody access capabilities
+🟡 **[/wallet-security/seed-phrase-management](/wallet-security/seed-phrase-management)** → Secure Storage Practices (partial)
+- Met: Backup materials (seed phrases, recovery keys) stored securely with geographic distribution
+- Missed: Device security requirements documented: dedicated devices for custody access, full disk encryption, automatic screen lock; Signing devices (hardware wallets) securely stored when not in use; VPN mandatory for all remote treasury platform access; Travel security procedures for personnel with signing or custody access capabilities; Mobile devices used as second factors have endpoint security monitoring
+🟡 **[/multisig-for-protocols/personal-security-opsec](/multisig-for-protocols/personal-security-opsec)** → Device Security (partial)
+- Met: Device security requirements documented: dedicated devices for custody access, full disk encryption, automatic screen lock; Signing devices (hardware wallets) securely stored when not in use; Backup materials (seed phrases, recovery keys) stored securely with geographic distribution; VPN mandatory for all remote treasury platform access; Travel security procedures for personnel with signing or custody access capabilities; Mobile devices used as second factors have endpoint security monitoring
+
+### ⚠️ tro-4.1.1: Transaction Verification and Execution
+
+🟡 **[/treasury-operations/transaction-verification](/treasury-operations/transaction-verification)** → Execution Protocol (partial)
+- Met: Pre-execution verification includes: recipient address validation, amount verification, network confirmation, and transaction simulation; Test transactions required before sending to new addresses; Address verified through multiple independent sources; never copied from email, chat, or transaction history; Multi-party confirmation required: minimum 2 internal personnel for large transfers; Specific procedures for receiving large incoming transfers (address generation, bidirectional test, sender coordination); High-value transfers (organization-defined threshold) require video call verification with liveness checks; All transaction parameters read aloud and confirmed before execution
+- Missed: Specific procedures for OTC transactions where applicable
+
+**Gaps (1):**
+- ❌ Specific procedures for OTC transactions where applicable
+
+### ⚠️ tro-4.1.2: Signer and Approver Knowledge
+
+🟡 **[/multisig-for-protocols/implementation-checklist](/multisig-for-protocols/implementation-checklist)** → Transaction Verification (partial)
+- Met: Knowledge covers: transaction verification procedures, address validation techniques, social engineering awareness, emergency procedures; Competence demonstrated before authorization (e.g., verifying a test transaction end-to-end)
+- Missed: Knowledge refreshed annually; updated within 30 days of significant procedure changes; Covers custody-platform-specific workflows and policy engine rules
+
+**Gaps (2):**
+- ❌ Knowledge refreshed annually; updated within 30 days of significant procedure changes
+- ❌ Covers custody-platform-specific workflows and policy engine rules
+
+### ⚠️ tro-4.1.3: Secure Communication Procedures
+
+🟡 **[/multisig-for-protocols/emergency-procedures](/multisig-for-protocols/emergency-procedures)** → Communication Account Compromise (partial)
+- Met: Identity verified as standard procedure during signing/approval operations (e.g., code phrases, video call, secondary authenticated channel); Anti-social-engineering protocols: established verification procedures for address changes or unusual requests; Documented procedures for channel compromise including switching to backup channels and out-of-band verification
+- Missed: Dedicated primary and backup channels on different platforms; End-to-end encryption, MFA required, invitation-based membership; All treasury personnel trained on these procedures; compromise response tested annually
+
+**Gaps (3):**
+- ❌ Dedicated primary and backup channels on different platforms
+- ❌ End-to-end encryption, MFA required, invitation-based membership
+- ❌ All treasury personnel trained on these procedures; compromise response tested annually
+
+### ❌ tro-5.1.1: Protocol Evaluation and Exposure Limits
+
+
+**Gaps (4):**
+- ❌ Due diligence process for all protocols before deployment: smart contract audit status, team reputation, TVL history, insurance coverage
+- ❌ Exposure limits defined per protocol, per chain, and per deployment category (DeFi, staking, liquid staking, etc.)
+- ❌ Limits reviewed periodically and after significant market or protocol changes
+- ❌ Risk re-evaluation triggered by: security incidents, major governance proposals, significant TVL changes, new vulnerabilities disclosed
+
+### ⚠️ tro-5.1.2: Position Lifecycle Management
+
+🟡 **[/treasury-operations/transaction-verification](/treasury-operations/transaction-verification)** → Transaction Parameter Security (partial)
+- Met: Entry procedures: smart contract address verification against multiple independent sources, token approval management (minimal approvals, revocation after use)
+- Missed: Emergency withdrawal/exit procedures documented for all active positions; Alternative access methods documented in case primary UIs are unavailable (direct contract interaction, CLI tools, alternative frontends); Unbonding/unstaking timelines understood and factored into liquidity planning
+
+**Gaps (3):**
+- ❌ Emergency withdrawal/exit procedures documented for all active positions
+- ❌ Alternative access methods documented in case primary UIs are unavailable (direct contract interaction, CLI tools, alternative frontends)
+- ❌ Unbonding/unstaking timelines understood and factored into liquidity planning
+
+### ⚠️ tro-6.1.1: Monitoring and Threat Awareness
+
+🟡 **[/treasury-operations/enhanced-controls](/treasury-operations/enhanced-controls)** → Security Monitoring & Logging (partial)
+- Met: Transaction monitoring: unusual amounts, unexpected destinations, failed transactions, policy violations; Account state monitoring: balance changes, configuration modifications, new device enrollments, authentication anomalies; Alerting with defined severity levels and escalation paths; Critical alerts (large unexpected transactions, unauthorized access attempts) trigger immediate investigation
+- Missed: External threat intelligence: protocol vulnerabilities, DeFi/staking risks, relevant security incidents in the ecosystem; Vendor/platform monitoring: custody platform status, infrastructure alerts, service availability; Compliance monitoring: transactions and wallet addresses screened for sanctions and compliance risk; Protocol and position monitoring: deployed protocol health, governance changes, TVL shifts, collateral ratios, reward accrual, liquidation risks; Monitoring system integrity protected — alerts triggered when monitoring configurations are changed, disabled, or degraded
+
+**Gaps (5):**
+- ❌ External threat intelligence: protocol vulnerabilities, DeFi/staking risks, relevant security incidents in the ecosystem
+- ❌ Vendor/platform monitoring: custody platform status, infrastructure alerts, service availability
+- ❌ Compliance monitoring: transactions and wallet addresses screened for sanctions and compliance risk
+- ❌ Protocol and position monitoring: deployed protocol health, governance changes, TVL shifts, collateral ratios, reward accrual, liquidation risks
+- ❌ Monitoring system integrity protected — alerts triggered when monitoring configurations are changed, disabled, or degraded
+
+### ✅ tro-6.1.2: Incident Response Plan
+
+🟢 **[/multisig-for-protocols/emergency-procedures](/multisig-for-protocols/emergency-procedures)** → Emergency Notification Template (full)
+- Met: Severity levels defined with escalation procedures specific to treasury operations; Containment procedures: fund protection actions (emergency freeze, transfer to secure cold storage, policy lockdown); Covers key scenarios: custody platform compromise, unauthorized transaction, signer key compromise, vendor breach; Emergency contacts pre-documented: custody provider security team, SEAL 911, legal counsel
+- Missed: Communication plan for stakeholders; Drills conducted at least annually; after major procedure changes; Drill documentation includes: date, participants, response times, issues identified, improvements made
+
+**Gaps (3):**
+- ❌ Communication plan for stakeholders
+- ❌ Drills conducted at least annually; after major procedure changes
+- ❌ Drill documentation includes: date, participants, response times, issues identified, improvements made
+
+### ❌ tro-7.1.1: Vendor Security Management
+
+
+**Gaps (4):**
+- ❌ Initial due diligence before adoption: security certifications (SOC 2, ISO 27001), audit history, insurance coverage, incident history
+- ❌ Ongoing monitoring: SOC report currency, security incident notifications, service availability tracking
+- ❌ Contractual security requirements verified periodically (at least annually)
+- ❌ Critical vendor changes (ownership, infrastructure, security posture) trigger re-evaluation
+
+### ✅ tro-7.1.2: Backup Infrastructure and Alternate Access
+
+🟢 **[/multisig-for-protocols/backup-signing-and-infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)** → UI Alternatives (full)
+- Met: Alternate access methods for custody platforms documented and tested (e.g., API access, mobile app, secondary UI); Backup RPC providers configured; Procedures for operating treasury if primary custody platform is unavailable; Backup infrastructure tested at least annually
+
+### ⚠️ tro-8.1.1: Financial Recordkeeping and Reconciliation
+
+🟡 **[/treasury-operations/registration-documents](/treasury-operations/registration-documents)** → Security Configuration Template (partial)
+- Met: All treasury transactions recorded with categorization, documentation, and authorization chain
+- Missed: Periodic reconciliation between custody platform records, on-chain balances, and accounting records; Reconciliation frequency scaled to account classification: daily for Active Operations, weekly for Warm Storage, monthly for Cold Vault; Discrepancies investigated and resolved promptly; Treasury reporting procedures documented with defined cadence and audience
+
+**Gaps (4):**
+- ❌ Periodic reconciliation between custody platform records, on-chain balances, and accounting records
+- ❌ Reconciliation frequency scaled to account classification: daily for Active Operations, weekly for Warm Storage, monthly for Cold Vault
+- ❌ Discrepancies investigated and resolved promptly
+- ❌ Treasury reporting procedures documented with defined cadence and audience
+
+### ❌ tro-8.1.2: Insurance Coverage
+
+
+**Gaps (4):**
+- ❌ Coverage scope documented: what's covered (custody theft, hack, insider fraud) and what's excluded
+- ❌ Coverage amounts appropriate relative to assets held
+- ❌ Custody provider's insurance evaluated as part of vendor due diligence
+- ❌ Insurance coverage reviewed at least annually or when treasury size changes significantly
+
+## sfc-workspace-security (3✅ 19⚠️ 1❌)
+
+### ⚠️ ws-1.1.1: Workspace Security Owner
+
+🟡 **[/opsec/core-concepts/security-fundamentals](/opsec/core-concepts/security-fundamentals)** → Continuous Visibility (partial)
+- Met: Accountability touches on establishing clear ownership for monitoring domains
+- Missed: Does not address comprehensive workspace security ownership scope covering policy maintenance, device/account standards, access control oversight, periodic reviews, and incident escalation
+
+**Gaps (1):**
+- ❌ Full accountability scope covering policy maintenance, device and account standards, access control oversight, periodic reviews, and incident escalation - no page provides comprehensive guidance on designating a workspace security owner with this full scope
+
+### ❌ ws-1.1.2: Workspace Security Policy
+
+
+**Gaps (3):**
+- ❌ Policy covering core expectations including device security, account hygiene, credential management, acceptable use, and incident reporting
+- ❌ Written in plain language so all personnel can follow it
+- ❌ Policy reviewed at least annually and after significant changes
+
+### ⚠️ ws-1.1.3: Asset Inventory
+
+🟡 **[/opsec/core-concepts/implementation-process](/opsec/core-concepts/implementation-process)** → Critical Asset Identification (partial)
+- Met: Map and document assets; Asset discovery and classification
+- Missed: Does not specify device inventory tracking (make/model, owner, OS version, encryption status, EDR/MDM enrollment); Does not cover account inventory with ownership; Does not address updates as devices/accounts are provisioned or decommissioned
+
+**Gaps (3):**
+- ❌ Device inventory tracking make/model, owner, OS version, encryption status, and EDR/MDM enrollment
+- ❌ Account inventory covering organizational accounts with defined ownership
+- ❌ Updated as devices/accounts are provisioned or decommissioned
+
+### ✅ ws-1.1.4: System and Data Classification
+
+🟢 **[/opsec/core-concepts/security-fundamentals](/opsec/core-concepts/security-fundamentals)** → Information Flow Control (full)
+- Met: Classification levels defined (Public, Internal, Confidential, Restricted); Classification determines which controls apply; Data handling procedures for each classification level
+🟢 **[/opsec/core-concepts/implementation-process](/opsec/core-concepts/implementation-process)** → Critical Asset Identification (full)
+- Met: Apply practical classification system with clear categories; Classification reviewed when conditions change
+
+### ⚠️ ws-2.1.1: Device Security Standards
+
+🟡 **[/opsec/travel/guide](/opsec/travel/guide)** → Secure devices with encryption & updates (partial)
+- Met: Full disk encryption enabled; Install latest OS and app updates; Strong authentication required (strong password/PIN)
+- Missed: Automatic OS and application patching; Administrative privileges separated from daily-use accounts; Devices procured through verified supply chains; Device compliance verification and monitoring; BYOD policy
+🟡 **[/encryption/volume-encryption](/encryption/volume-encryption)**  (partial)
+- Met: Full disk encryption guidance
+- Missed: OS patching; Authentication; Admin privileges separation; Supply chain; Compliance monitoring; BYOD policy
+🟡 **[/encryption/partition-encryption](/encryption/partition-encryption)**  (partial)
+- Met: Encryption for specific partitions
+- Missed: OS patching; Authentication; Admin privileges separation; Supply chain; Compliance monitoring; BYOD policy
+
+**Gaps (5):**
+- ❌ Automatic OS and application patching enabled or enforced
+- ❌ Administrative privileges separated from daily-use accounts
+- ❌ Devices procured through verified supply chains and verified for integrity upon receipt
+- ❌ Device compliance verified upon provisioning and monitored on an ongoing basis
+- ❌ BYOD policy defining what personal devices can access and security controls required
+
+### ⚠️ ws-2.1.2: Device Lifecycle Management
+
+🟡 **[/opsec/travel/guide](/opsec/travel/guide)** → Back up and prepare for loss (partial)
+- Met: Remote wipe capability mentioned (Find My, MDM); Procedures for lost devices (remote wipe, filing reports)
+- Missed: Documented procedures for credential rotation after loss; Incident escalation procedures; Secure decommissioning with data sanitization and verified destruction
+🟡 **[/opsec/control-domains/physical-environmental](/opsec/control-domains/physical-environmental)** → Physical Security of Critical Assets (partial)
+- Met: Secure disposal procedures for equipment and media
+- Missed: Remote lock and wipe capability; Response procedures for lost/stolen devices; Credential rotation
+
+**Gaps (2):**
+- ❌ Documented procedures for credential rotation after device loss or theft
+- ❌ Incident escalation procedures for lost/stolen devices
+
+### ⚠️ ws-2.1.3: Endpoint Protection
+
+🟡 **[/opsec/travel/guide](/opsec/travel/guide)** → Inspect and clean your devices (partial)
+- Met: Run anti-malware scan; Look for unusual behavior
+- Missed: EDR/MDM deployed on all devices with documented coverage; Alert triage and response procedures; Compliance enforcement actions; Monitoring for malware, unauthorized software, policy violations
+
+**Gaps (4):**
+- ❌ EDR or MDM deployed on all organizational devices with documented coverage
+- ❌ Alert triage and response procedures defined with severity-based escalation
+- ❌ Compliance enforcement actions documented
+- ❌ Monitoring coverage includes detection of malware, unauthorized software, and policy violations
+
+### ✅ ws-2.1.4: Physical and Travel Security
+
+🟢 **[/opsec/travel/guide](/opsec/travel/guide)**  (full)
+- Met: Screen privacy and shoulder-surfing awareness (privacy screen filter, shield keypad); Travel security procedures (pre-travel assessment, secure travel practices, device security); High-risk travel procedures (loaner devices, enhanced controls); USB and charging security (avoid juice jacking, USB data blockers, no unknown USB drives); Devices physically secured (cable locks, room safes, carry-on luggage)
+- Missed: Physical workspace requirements for on-site and remote work not comprehensively covered
+🟢 **[/opsec/control-domains/physical-environmental](/opsec/control-domains/physical-environmental)** → Secure Workspace & Travel Security (full)
+- Met: Physical workspace requirements (physical access controls, clean desk policy); Travel security procedures; Device security during travel; Secure storage options
+
+### ⚠️ ws-3.1.1: Account Lifecycle Management
+
+🟡 **[/guides/account_management/discord](/guides/account_management/discord)** → Roles (partial)
+- Met: Review admin role members and permissions; Remove unnecessary permissions and members
+- Missed: Account creation approval process; Accounts provisioned with minimum necessary permissions systematically; Account modification approval; Account revocation tied to offboarding; Service accounts inventoried with ownership
+
+**Gaps (5):**
+- ❌ Account creation requires documented approval from manager or designated authority
+- ❌ Accounts provisioned with minimum necessary permissions (least privilege)
+- ❌ Modification of account permissions requires documented approval
+- ❌ Account revocation procedures tied to offboarding and role changes
+- ❌ Service accounts and shared credentials inventoried with defined ownership
+
+### ⚠️ ws-3.1.2: Multi-Factor Authentication
+
+🟡 **[/opsec/travel/guide](/opsec/travel/guide)** → Protect Accounts with 2FA redundancy (partial)
+- Met: Plan for 2FA redundancy; Disable SMS for 2FA; Register backup 2FA methods
+- Missed: MFA required for all organizational accounts by default; Hardware security keys required for high-privilege accounts; Exceptions documented with justification and expiry
+🟡 **[/opsec/control-domains/technical](/opsec/control-domains/technical)** → Two-Factor & Hardware Authentication (partial)
+- Met: Multi-factor authentication for all access to sensitive systems; Hardware security keys for high-value accounts; Backup authentication methods and recovery processes; Phishing-resistant MFA (hardware keys)
+- Missed: Exceptions documented with justification, compensating controls, and expiry date not explicitly covered
+🟡 **[/guides/account_management/discord](/guides/account_management/discord)** → For Individuals - Account Security Checklist (partial)
+- Met: 2FA enabled requirement; Require 2FA for moderation
+- Missed: Hardware keys for high-privilege accounts; Phishing-resistant MFA preferred; Exceptions documented; Backup MFA methods
+
+**Gaps (1):**
+- ❌ Exceptions documented with justification, compensating controls, and expiry date
+
+### ⚠️ ws-3.1.3: Organizational Account Security
+
+🟡 **[/guides/account_management/discord](/guides/account_management/discord)** → Server Settings Checklist (partial)
+- Met: Security configuration standards for Discord platform; Ownership verified through admin reviews
+- Missed: Security standards for enterprise platforms broadly; Social media and public-facing accounts; Recovery methods restricted to organizational channels; Periodic review for drift
+
+**Gaps (4):**
+- ❌ Security configuration standards defined and applied for enterprise platforms (Google Workspace, Microsoft 365, collaboration tools)
+- ❌ Social media and public-facing accounts secured with strong authentication and defined ownership
+- ❌ Recovery methods restricted to organizational channels (no personal recovery emails or phone numbers)
+- ❌ Account configurations reviewed periodically for drift or unauthorized changes
+
+### ⚠️ ws-3.1.4: Credential Management Standards
+
+🟡 **[/opsec/travel/guide](/opsec/travel/guide)** → Protect Accounts with 2FA redundancy (partial)
+- Met: Password manager accessible (1Password Travel Mode); Backup codes stored securely
+- Missed: Password manager required for all personnel; Unique strong passwords for every account; Individual accounts required (no sharing); Credential transmission only through encrypted channels; Rotation schedule; Enhanced controls for high-privilege credentials; Service account inventory
+🟡 **[/awareness/cultivating-a-security-aware-mindset](/awareness/cultivating-a-security-aware-mindset)** → Password Management (partial)
+- Met: Strong, unique passwords for each account; Password managers to securely store and generate passwords
+- Missed: No passwords in plain text/documents/browsers requirement; Individual accounts required; Credential transmission security; Rotation schedule; Enhanced controls for high-privilege; Service account inventory
+🟡 **[/guides/account_management/telegram](/guides/account_management/telegram)** → Account Security Checklist (partial)
+- Met: Strong unique password that doesn't get reused
+- Missed: Password manager required; Credential transmission; Rotation schedule; Enhanced controls; Service account inventory
+
+**Gaps (6):**
+- ❌ Password manager required for all personnel; no passwords stored in plain text, documents, or browsers
+- ❌ Individual accounts required for all personnel — no sharing of personal login credentials
+- ❌ Credential transmission only through encrypted channels (password manager sharing features, not email or chat)
+- ❌ Credential rotation schedule defined based on risk; rotation triggered immediately after suspected compromise
+- ❌ Enhanced controls for high-privilege credentials including stricter rotation, separate storage, and logged access
+- ❌ Service account and API key inventory maintained with defined ownership
+
+### ⚠️ ws-3.1.5: Access Reviews
+
+🟡 **[/opsec/core-concepts/security-fundamentals](/opsec/core-concepts/security-fundamentals)** → Minimal Access Scopes (partial)
+- Met: Conduct regular access reviews (quarterly for critical, annually for others); Reviews verify each user still requires current access
+- Missed: Access adjusted within defined timelines when roles change; Unnecessary permissions revoked with documented evidence; Insider threat consideration
+🟡 **[/guides/account_management/discord](/guides/account_management/discord)** → Regular Reviews (partial)
+- Met: Monthly review of role permissions; Quarterly assessment of rules; Track changes and justifications
+- Missed: Access adjusted when employees change roles; Insider threat damage scenarios; Reviews for critical vs standard systems
+
+**Gaps (3):**
+- ❌ Access adjusted within defined timelines when employees change roles
+- ❌ Unnecessary permissions revoked promptly with documented evidence
+- ❌ Insider threat consideration included — for each role, assess what damage could be done with current access
+
+### ⚠️ ws-4.1.1: Software Evaluation and Approval
+
+🟡 **[/opsec/travel/guide](/opsec/travel/guide)** → Minimize digital footprint & social visibility (partial)
+- Met: Privacy-focused tools mentioned (Hide My Email, Tuta, ProtonMail)
+- Missed: Evaluation criteria for software before adoption; Data privacy and leakage risk assessment; Approved software list; Browser extension approval; Dependency management
+
+**Gaps (5):**
+- ❌ Evaluation criteria for all software before adoption (browsers, extensions, IDEs, libraries, AI assistants, SaaS tools)
+- ❌ Data privacy and leakage risks assessed (does the tool send data to third parties?)
+- ❌ Approved software list maintained; unapproved software restricted
+- ❌ Browser extension approval process defined
+- ❌ Dependency management includes version pinning, vulnerability scanning, and update policies
+
+### ✅ ws-4.1.2: Source Code and Repository Security
+
+🟢 **[/guides/account_management/github](/guides/account_management/github)** → Repository Settings (full)
+- Met: Role-based access control (Collaborators and teams); Branch protection rules enforced (require reviews, signed commits); Automated secret scanning enabled (Code security settings); Pre-commit hooks/CI checks (Push protection for secrets); Repository security audited periodically (Sessions, SSH keys, webhooks review)
+
+### ⚠️ ws-5.1.1: Network Security
+
+🟡 **[/opsec/travel/guide](/opsec/travel/guide)** → Network safety – avoid untrusted Wi-Fi & Bluetooth (partial)
+- Met: VPN or cellular connection preferred for sensitive operations; Wi-Fi security standards (disable auto-connect, avoid public Wi-Fi); Cellular or personal hotspot preferred over public Wi-Fi
+- Missed: Network segmentation not covered
+🟡 **[/opsec/control-domains/technical](/opsec/control-domains/technical)** → Network & Communication Security (partial)
+- Met: Network segmentation based on security requirements; Secure remote access solutions (VPN); Network monitoring
+
+### ⚠️ ws-5.1.2: Secure Communications
+
+🟡 **[/opsec/travel/guide](/opsec/travel/guide)** → Plan emergency and incident responses (partial)
+- Met: Fallback plan for communication (safe words, beware deepfakes)
+- Missed: End-to-end encrypted channels used; Identity verification procedures for sensitive requests; Anti-impersonation protocols documented; Email security (SPF, DKIM, DMARC); Procedures for channel compromise
+🟡 **[/guides/account_management/telegram](/guides/account_management/telegram)** → Use Secret Chats for Enhanced Privacy (partial)
+- Met: End-to-end encrypted channels (Secret Chats); Identity verification (compare encryption keys)
+- Missed: Anti-impersonation protocols beyond basic verification; Email security configuration; Procedures for channel compromise
+🟡 **[/opsec/control-domains/technical](/opsec/control-domains/technical)** → Network & Communication Security (partial)
+- Met: Encrypted communications protecting data in transit
+- Missed: Identity verification procedures; Anti-impersonation protocols; Email security (SPF, DKIM, DMARC); Channel compromise procedures
+
+**Gaps (3):**
+- ❌ Anti-impersonation protocols documented (e.g., secondary channel verification, code words, video confirmation)
+- ❌ Email security configured (SPF, DKIM, DMARC) to prevent spoofing
+- ❌ Procedures for channel compromise including switching to backup channels
+
+### ⚠️ ws-6.1.1: Security Onboarding
+
+🟡 **[/opsec/control-domains/people](/opsec/control-domains/people)** → Personnel Security Measures (partial)
+- Met: Pre-employment screening procedures; Security agreements for all team members; Security responsibilities in job descriptions
+- Missed: Security onboarding includes device provisioning, account creation, MFA setup, and initial training; New personnel acknowledge policies before access; Onboarding checklist documented and consistently applied
+
+**Gaps (3):**
+- ❌ Security onboarding includes device provisioning, account creation, MFA setup, and initial security training
+- ❌ New personnel acknowledge security policies before access is granted
+- ❌ Onboarding checklist documented and consistently applied
+
+### ⚠️ ws-6.1.2: Security Offboarding
+
+🟡 **[/opsec/travel/guide](/opsec/travel/guide)** → Back up and prepare for loss (partial)
+- Met: Remote wipe capability for devices
+- Missed: All account access revoked within 24 hours; Credentials rotated for shared systems; Offboarding checklist; Involuntary departures trigger immediate revocation
+🟡 **[/awareness/understanding-threat-vectors](/awareness/understanding-threat-vectors)**  (partial)
+- Met: General awareness of insider threats
+- Missed: Specific offboarding procedures; Account revocation timeline; Credential rotation; Device return and sanitization; Offboarding checklist
+🟡 **[/guides/account_management/discord](/guides/account_management/discord)** → Regular Reviews (partial)
+- Met: Remove unnecessary role members
+- Missed: 24-hour revocation timeline; Device return; Credential rotation; Comprehensive offboarding checklist; Involuntary departure procedures
+
+**Gaps (5):**
+- ❌ All account access revoked within 24 hours of departure
+- ❌ Devices returned and verified for data sanitization
+- ❌ Credentials and secrets rotated for any shared systems the departing person accessed
+- ❌ Offboarding checklist documented covering: account deprovisioning, device return, credential rotation, access to organizational repositories and tools, recovery of company property
+- ❌ Involuntary departures trigger immediate access revocation before notification where feasible
+
+### ⚠️ ws-6.1.3: Security Awareness and Training
+
+🟡 **[/awareness/staying-informed-and-continuous-learning](/awareness/staying-informed-and-continuous-learning)** → Comprehensive Security Training Framework (partial)
+- Met: Training covers phishing, social engineering, device security, credential hygiene, incident reporting; Training content updated annually; Crypto-specific risks covered (fake job offers, malicious extensions, clipboard hijacking, social engineering via DMs)
+- Missed: Phishing simulations conducted quarterly; Follow-up training for those who fail simulations
+🟡 **[/opsec/control-domains/people](/opsec/control-domains/people)** → Security Training & Culture (partial)
+- Met: Comprehensive security awareness program; Role-specific training; Continuous learning about emerging threats
+- Missed: Phishing simulations quarterly; Follow-up training for failures; Crypto-specific risks detail
+🟡 **[/opsec/appendices/case-studies](/opsec/appendices/case-studies)**  (partial)
+- Met: Real-world scenarios for training; Tabletop exercises
+- Missed: Regular phishing simulations; Follow-up training process; Training content update schedule; Crypto-specific risks coverage
+
+**Gaps (2):**
+- ❌ Phishing simulations conducted at least quarterly
+- ❌ Follow-up training required for personnel who fail simulations
+
+### ⚠️ ws-7.1.1: Workspace Security Monitoring and Incident Response
+
+🟡 **[/opsec/core-concepts/security-fundamentals](/opsec/core-concepts/security-fundamentals)** → Continuous Visibility (partial)
+- Met: Multi-layered monitoring strategy; Regular testing cadence; Structured incident management process; Post-incident reviews
+- Missed: Monitoring for workspace-specific threats (account takeovers, unauthorized access, credential leaks, device compromise, data exfiltration); Response procedures for workspace scenarios; Credential leak monitoring
+🟡 **[/opsec/appendices/case-studies](/opsec/appendices/case-studies)** → Tabletop Exercises (partial)
+- Met: Incident response scenarios and procedures; Tabletop exercises for testing
+- Missed: Ongoing monitoring in place; Credential leak monitoring; Documented procedures for specific workspace scenarios
+
+**Gaps (3):**
+- ❌ Monitoring in place for common workspace threats: account takeovers, unauthorized access, credential leaks, device compromise, data exfiltration
+- ❌ Response procedures documented for key scenarios: compromised account, compromised device, data leak, insider threat event
+- ❌ Credential leak monitoring (dark web, breach databases, paste sites, code repositories)
+
+### ⚠️ ws-7.1.2: Insider Threat Assessment
+
+🟡 **[/opsec/core-concepts/security-fundamentals](/opsec/core-concepts/security-fundamentals)** → Minimal Access Scopes (partial)
+- Met: Least-privilege access enforced
+- Missed: Damage scenarios documented for each role; Separation of duties for critical operations; Assessed during access reviews
+🟡 **[/opsec/control-domains/people](/opsec/control-domains/people)** → Insider-Threat Mitigation (partial)
+- Met: Least-privilege access enforced across all systems; Monitoring for critical systems and sensitive data access; Guidelines for identifying concerning behaviors
+- Missed: Damage scenarios documented for each role not explicitly covered; Separation of duties applied for critical operations not detailed
+
+**Gaps (2):**
+- ❌ Damage scenarios documented for each role (what could this person do if compromised or malicious?)
+- ❌ Separation of duties applied for critical operations (no single person can deploy to production, execute large transactions, and manage access controls)
+
+### ⚠️ ws-7.1.3: Third-Party Access Management
+
+🟡 **[/opsec/core-concepts/security-fundamentals](/opsec/core-concepts/security-fundamentals)** → Minimal Access Scopes (partial)
+- Met: Just-in-time access for administrative functions; Time-based restrictions to elevated privileges
+- Missed: Third-party access requires documented approval with scope and expiry; Access limited to minimum necessary systems; Automatic revocation upon contract expiry; Audit trails for third-party access; Vendor security evaluation
+🟡 **[/guides/account_management/discord](/guides/account_management/discord)** → Integrations (partial)
+- Met: Review bot permissions and remove unnecessary; Least privilege for integrations
+- Missed: Documented approval with scope and expiry; Automatic revocation upon contract end; Audit trails; Vendor security evaluation before granting access
+
+**Gaps (5):**
+- ❌ Third-party access requires documented approval with defined scope and expiry date
+- ❌ Access limited to minimum necessary systems and data
+- ❌ Access revoked automatically upon contract expiry or project completion
+- ❌ Audit trails maintained for all third-party access
+- ❌ Third-party vendor security evaluated before granting access (security certifications, incident history)
+
+## Most Referenced Framework Pages
+
+| Page | Controls |
+|------|----------|
+| /multisig-for-protocols/emergency-procedures | 13 |
+| /wallet-security/secure-multisig-best-practices | 12 |
+| /multisig-for-protocols/implementation-checklist | 11 |
+| /opsec/travel/guide | 10 |
+| /opsec/core-concepts/security-fundamentals | 6 |
+| /guides/account_management/discord | 6 |
+| /infrastructure/domain-and-dns-security/registrar-and-locks | 5 |
+| /infrastructure/domain-and-dns-security/monitoring-and-alerting | 5 |
+| /treasury-operations/registration-documents | 5 |
+| /treasury-operations/enhanced-controls | 5 |
+| /multisig-for-protocols/setup-and-configuration | 4 |
+| /secure-software-development/secure-code-repositories-version-control | 3 |
+| /devsecops/continuous-integration-continuous-deployment | 3 |
+| /multisig-for-protocols/backup-signing-and-infrastructure | 3 |
+| /wallet-security/seed-phrase-management | 3 |
+| /opsec/control-domains/technical | 3 |
+| /opsec/control-domains/people | 3 |
+| /devsecops/integrated-development-environments | 2 |
+| /infrastructure/domain-and-dns-security/dnssec-and-email | 2 |
+| /incident-management/playbooks/seal-911-war-room-guidelines | 2 |
diff --git a/docs/pages/certs/index.mdx b/docs/pages/certs/index.mdx
index 9754e4aa..65701348 100644
--- a/docs/pages/certs/index.mdx
+++ b/docs/pages/certs/index.mdx
@@ -21,3 +21,4 @@ title: "Certs"
 - [SFC: Workspace Security](/certs/sfc-workspace-security)
 - [Certification Guidelines](/certs/certification-guidelines)
 - [Contributing to SEAL Certifications](/certs/contributions)
+- [Certified Protocols](/certs/certified-protocols)
diff --git a/docs/pages/config/index.mdx b/docs/pages/config/index.mdx
new file mode 100644
index 00000000..12ece8be
--- /dev/null
+++ b/docs/pages/config/index.mdx
@@ -0,0 +1,15 @@
+---
+title: "Config"
+---
+
+{/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */}
+
+# Config
+
+> _Note:_ This page is auto-generated. Please use the sidebar to explore the docs instead of
+> navigating directory paths directly.
+
+## Pages
+
+- [Template](/config/template)
+- [Using Contributors](/config/using-contributors)
diff --git a/package.json b/package.json
index 1aa2625d..11626dde 100644
--- a/package.json
+++ b/package.json
@@ -8,6 +8,7 @@
     "@types/react": "^19.2.7",
     "@types/react-dom": "^19.2.3",
     "cspell": "^9.4.0",
+    "js-yaml": "^4.1.1",
     "tailwindcss": "4.0.7",
     "vocs": "^1.2.1"
   },
diff --git a/pnpm-lock.yaml b/pnpm-lock.yaml
index 1b522731..475110f5 100644
--- a/pnpm-lock.yaml
+++ b/pnpm-lock.yaml
@@ -48,6 +48,9 @@ importers:
       cspell:
         specifier: ^9.4.0
         version: 9.4.0
+      js-yaml:
+        specifier: ^4.1.1
+        version: 4.1.1
       tailwindcss:
         specifier: 4.0.7
         version: 4.0.7
@@ -1999,6 +2002,9 @@ packages:
   argparse@1.0.10:
     resolution: {integrity: sha512-o5Roy6tNG4SL/FOkCAN6RzjiakZS25RLYFrcMttJqbdd8BWrnA+fGz57iN5Pb06pvBGvl5gQ0B48dJlslXvoTg==}
 
+  argparse@2.0.1:
+    resolution: {integrity: sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==}
+
   aria-hidden@1.2.6:
     resolution: {integrity: sha512-ik3ZgC9dY/lYVVM++OISsaYDeg1tb0VtP5uL3ouh1koGOaUMDPpbFIei4JkFimWUFPn90sbMNMXQAIVOlnYKJA==}
     engines: {node: '>=10'}
@@ -2920,6 +2926,10 @@ packages:
     resolution: {integrity: sha512-PMSmkqxr106Xa156c2M265Z+FTrPl+oxd/rgOQy2tijQeK5TxQ43psO1ZCwhVOSdnn+RzkzlRz/eY4BgJBYVpg==}
     hasBin: true
 
+  js-yaml@4.1.1:
+    resolution: {integrity: sha512-qQKT4zQxXl8lLwBtHMWwaTcGfFOZviOJet3Oy/xmGk2gZH677CJM9EvtfdSkgWcATZhj/55JZ0rmy3myCT5lsA==}
+    hasBin: true
+
   jsesc@3.1.0:
     resolution: {integrity: sha512-/sM3dO2FOzXjKQhJuo0Q173wf2KOo8t4I8vHy6lF9poUp7bKT0/NHE8fPX23PwfhnykfqnC2xRxOnVw5XuGIaA==}
     engines: {node: '>=6'}
@@ -6140,6 +6150,8 @@ snapshots:
     dependencies:
       sprintf-js: 1.0.3
 
+  argparse@2.0.1: {}
+
   aria-hidden@1.2.6:
     dependencies:
       tslib: 2.8.1
@@ -7232,6 +7244,10 @@ snapshots:
       argparse: 1.0.10
       esprima: 4.0.1
 
+  js-yaml@4.1.1:
+    dependencies:
+      argparse: 2.0.1
+
   jsesc@3.1.0: {}
 
   json5@2.2.3: {}
diff --git a/scripts/apply-qa-corrections.mjs b/scripts/apply-qa-corrections.mjs
new file mode 100644
index 00000000..22c9ebe8
--- /dev/null
+++ b/scripts/apply-qa-corrections.mjs
@@ -0,0 +1,85 @@
+#!/usr/bin/env node
+/**
+ * Apply QA corrections to eval results.
+ * For downgraded controls: change coverage from "full" to "partial" or remove refs.
+ * For upgraded controls: change coverage from "partial" to "full".
+ * For false-negatives: add the missing ref.
+ */
+
+import { readFileSync, writeFileSync, readdirSync } from 'fs';
+import { join } from 'path';
+
+const REPO_ROOT = join(import.meta.dirname, '..');
+const EVAL_DIR = join(REPO_ROOT, 'scripts', 'data', 'eval-results');
+const QA_DIR = join(REPO_ROOT, 'scripts', 'data', 'qa-results');
+
+const qaFiles = readdirSync(QA_DIR).filter(f => f.endsWith('.json')).sort();
+
+let totalCorrections = 0;
+
+for (const file of qaFiles) {
+  const certName = file.replace('.json', '');
+  const evalPath = join(EVAL_DIR, file);
+  const evals = JSON.parse(readFileSync(evalPath, 'utf-8'));
+  const qaResults = JSON.parse(readFileSync(join(QA_DIR, file), 'utf-8'));
+  
+  let corrections = 0;
+  
+  for (const qa of qaResults) {
+    if (qa.verdict === 'confirmed') continue;
+    
+    const ctrl = evals.find(c => c.controlId === qa.controlId);
+    if (!ctrl) continue;
+    
+    if (qa.verdict === 'downgraded') {
+      // Downgrade: full→partial, or partial→remove, or remove refs entirely
+      if (qa.qaCoverage === 'none' || qa.qaCoverage === 'no-coverage') {
+        ctrl.refs = [];
+        // Move any baselinesMet to gaps
+        for (const ref of ctrl.refs) {
+          if (ref.baselinesMet) {
+            ctrl.gaps.push(...ref.baselinesMet);
+          }
+        }
+      } else {
+        for (const ref of ctrl.refs) {
+          if (ref.coverage === 'full') {
+            ref.coverage = 'partial';
+          }
+        }
+      }
+      corrections++;
+    } else if (qa.verdict === 'upgraded') {
+      for (const ref of ctrl.refs) {
+        if (ref.coverage === 'partial') {
+          ref.coverage = 'full';
+        }
+      }
+      corrections++;
+    } else if (qa.verdict === 'false-negative') {
+      // QA found coverage that evaluator missed
+      // Add a note but we can't add specific refs without the page details
+      // Mark in gaps that coverage exists
+      if (ctrl.refs.length === 0 && qa.qaCoverage && qa.qaCoverage !== 'none') {
+        // The QA agent identified partial coverage exists
+        // We'll add a placeholder ref based on the QA notes
+        ctrl.refs.push({
+          page: qa.notes.match(/IDE page|CI\/CD page/) ? '/devsecops/integrated-development-environments' : '',
+          header: null,
+          coverage: 'partial',
+          baselinesMet: ['See QA notes: ' + qa.notes.substring(0, 200)],
+          baselinesMissed: [],
+        });
+        // Filter out empty page refs
+        ctrl.refs = ctrl.refs.filter(r => r.page);
+      }
+      corrections++;
+    }
+  }
+  
+  writeFileSync(evalPath, JSON.stringify(evals, null, 2));
+  console.log(`${certName}: ${corrections} corrections applied`);
+  totalCorrections += corrections;
+}
+
+console.log(`\nTotal: ${totalCorrections} corrections applied across all certs`);
diff --git a/scripts/build-final-mapping.mjs b/scripts/build-final-mapping.mjs
new file mode 100644
index 00000000..2f67e401
--- /dev/null
+++ b/scripts/build-final-mapping.mjs
@@ -0,0 +1,214 @@
+#!/usr/bin/env node
+/**
+ * Build the final cert-framework-map.ts from keyword-matched candidates.
+ * 
+ * Takes the raw matched mappings and:
+ * 1. Selects top candidates per control (score > threshold, max 5)
+ * 2. Determines coverage level based on score relative to baseline count
+ * 3. Generates the TypeScript data file for the React components
+ * 4. Generates a gap analysis report
+ */
+
+import { readFileSync, writeFileSync, readdirSync } from 'fs';
+import { join } from 'path';
+
+const REPO_ROOT = join(import.meta.dirname, '..');
+const DATA_DIR = join(REPO_ROOT, 'scripts', 'data');
+const MAPPINGS_DIR = join(DATA_DIR, 'mappings');
+const COMPONENTS_DIR = join(REPO_ROOT, 'components', 'cert');
+
+// Load all mapping files
+const certNames = readdirSync(MAPPINGS_DIR).filter(f => f.endsWith('.json')).sort();
+
+const allMappings = {};
+const forwardIndex = {}; // controlId → [{page, header, coverage}]
+const reverseIndex = {}; // page → [{controlId, certName, header}]
+const gapReport = [];
+
+for (const file of certNames) {
+  const certName = file.replace('.json', '');
+  const controls = JSON.parse(readFileSync(join(MAPPINGS_DIR, file), 'utf-8'));
+  allMappings[certName] = controls;
+  
+  for (const ctrl of controls) {
+    const refs = [];
+    
+    // Select top candidates based on score thresholds
+    // Higher baseline count = need higher score for "full" coverage
+    const scorePerBaseline = ctrl.baselineCount > 0 ? 1 : 0;
+    
+    for (const cand of ctrl.candidates) {
+      if (cand.score < 10) continue;
+      
+      // Determine coverage level
+      // Score thresholds are relative: higher scores = more keyword overlap = more coverage
+      let coverage;
+      const normalizedScore = ctrl.baselineCount > 0 ? cand.score / ctrl.baselineCount : cand.score;
+      
+      if (normalizedScore >= 30) coverage = 'full';
+      else if (normalizedScore >= 10) coverage = 'partial';
+      else continue; // skip low matches
+      
+      // Pick the best matching section header
+      const header = cand.matchedSections.length > 0 ? cand.matchedSections[0] : null;
+      
+      refs.push({
+        page: cand.page,
+        title: cand.title,
+        header,
+        coverage,
+        score: cand.score,
+      });
+      
+      // Build reverse index
+      const key = cand.page;
+      if (!reverseIndex[key]) reverseIndex[key] = [];
+      reverseIndex[key].push({
+        controlId: ctrl.controlId,
+        controlTitle: ctrl.controlTitle,
+        certName,
+        header,
+        coverage,
+      });
+    }
+    
+    // Cap at 5 refs per control
+    const topRefs = refs.slice(0, 5);
+    forwardIndex[ctrl.controlId] = topRefs;
+    
+    // Track gaps
+    if (topRefs.length === 0) {
+      gapReport.push({
+        certName,
+        controlId: ctrl.controlId,
+        controlTitle: ctrl.controlTitle,
+        description: ctrl.description,
+        baselines: ctrl.baselines,
+        gapType: 'no-coverage',
+      });
+    } else if (topRefs.every(r => r.coverage === 'partial')) {
+      gapReport.push({
+        certName,
+        controlId: ctrl.controlId,
+        controlTitle: ctrl.controlTitle,
+        description: ctrl.description,
+        baselines: ctrl.baselines,
+        gapType: 'partial-only',
+        refs: topRefs.map(r => r.page),
+      });
+    }
+  }
+}
+
+// ── Generate TypeScript data file ──────────────────────────────────
+const tsContent = `// AUTO-GENERATED by scripts/build-final-mapping.mjs — do not edit manually
+// Maps cert controls → framework pages (forward) and framework pages → cert controls (reverse)
+
+export interface FrameworkRef {
+  page: string;
+  title: string;
+  header: string | null;
+  coverage: 'full' | 'partial';
+}
+
+export interface CertRef {
+  controlId: string;
+  controlTitle: string;
+  certName: string;
+  header: string | null;
+  coverage: 'full' | 'partial';
+}
+
+/** Forward index: cert control ID → framework page references */
+export const controlToFramework: Record<string, FrameworkRef[]> = ${JSON.stringify(
+  Object.fromEntries(
+    Object.entries(forwardIndex).map(([k, v]) => [
+      k,
+      v.map(({ page, title, header, coverage }) => ({ page, title, header, coverage }))
+    ])
+  ),
+  null,
+  2
+)};
+
+/** Reverse index: framework page path → cert controls that reference it */
+export const frameworkToControls: Record<string, CertRef[]> = ${JSON.stringify(
+  Object.fromEntries(
+    Object.entries(reverseIndex).map(([k, v]) => [
+      k,
+      // Deduplicate by controlId
+      [...new Map(v.map(item => [item.controlId, item])).values()]
+    ])
+  ),
+  null,
+  2
+)};
+`;
+
+writeFileSync(join(COMPONENTS_DIR, 'cert-framework-map.ts'), tsContent);
+
+// ── Generate gap analysis report ───────────────────────────────────
+let report = `# SEAL Certs ↔ Frameworks Gap Analysis\n\n`;
+report += `_Auto-generated ${new Date().toISOString().split('T')[0]}_\n\n`;
+
+// Summary stats
+const totalControls = Object.keys(forwardIndex).length;
+const withFullCoverage = Object.values(forwardIndex).filter(refs => refs.some(r => r.coverage === 'full')).length;
+const withPartialOnly = Object.values(forwardIndex).filter(refs => refs.length > 0 && refs.every(r => r.coverage === 'partial')).length;
+const noCoverage = Object.values(forwardIndex).filter(refs => refs.length === 0).length;
+
+report += `## Summary\n\n`;
+report += `| Metric | Count | % |\n|--------|-------|---|\n`;
+report += `| Total controls | ${totalControls} | 100% |\n`;
+report += `| Full coverage (≥1 full ref) | ${withFullCoverage} | ${Math.round(withFullCoverage/totalControls*100)}% |\n`;
+report += `| Partial coverage only | ${withPartialOnly} | ${Math.round(withPartialOnly/totalControls*100)}% |\n`;
+report += `| No coverage | ${noCoverage} | ${Math.round(noCoverage/totalControls*100)}% |\n\n`;
+
+// Per-cert breakdown
+for (const certName of Object.keys(allMappings)) {
+  const controls = allMappings[certName];
+  report += `## ${certName}\n\n`;
+  
+  for (const ctrl of controls) {
+    const refs = forwardIndex[ctrl.controlId] || [];
+    const icon = refs.some(r => r.coverage === 'full') ? '✅' : refs.length > 0 ? '⚠️' : '❌';
+    report += `### ${icon} ${ctrl.controlId}: ${ctrl.controlTitle}\n\n`;
+    
+    if (refs.length > 0) {
+      report += `| Page | Header | Coverage |\n|------|--------|----------|\n`;
+      for (const ref of refs) {
+        report += `| [${ref.title || ref.page}](${ref.page}) | ${ref.header || '—'} | ${ref.coverage} |\n`;
+      }
+    } else {
+      report += `**No framework coverage found.**\n`;
+    }
+    report += '\n';
+  }
+}
+
+// Reverse index summary — most referenced pages
+report += `## Most Referenced Framework Pages\n\n`;
+const sortedPages = Object.entries(reverseIndex)
+  .map(([page, refs]) => ({ page, count: refs.length, refs }))
+  .sort((a, b) => b.count - a.count)
+  .slice(0, 20);
+
+report += `| Page | Controls Referencing |\n|------|---------------------|\n`;
+for (const { page, count } of sortedPages) {
+  report += `| ${page} | ${count} |\n`;
+}
+report += '\n';
+
+writeFileSync(join(REPO_ROOT, 'docs', 'gap-analysis.md'), report);
+
+// Console summary
+console.log(`\n=== SUMMARY ===`);
+console.log(`Total controls: ${totalControls}`);
+console.log(`Full coverage: ${withFullCoverage} (${Math.round(withFullCoverage/totalControls*100)}%)`);
+console.log(`Partial only: ${withPartialOnly} (${Math.round(withPartialOnly/totalControls*100)}%)`);
+console.log(`No coverage: ${noCoverage} (${Math.round(noCoverage/totalControls*100)}%)`);
+console.log(`\nForward index: ${Object.keys(forwardIndex).length} entries`);
+console.log(`Reverse index: ${Object.keys(reverseIndex).length} pages referenced`);
+console.log(`\nOutput:`);
+console.log(`  ${join(COMPONENTS_DIR, 'cert-framework-map.ts')}`);
+console.log(`  ${join(REPO_ROOT, 'docs', 'gap-analysis.md')}`);
diff --git a/scripts/build-verified-mapping.mjs b/scripts/build-verified-mapping.mjs
new file mode 100644
index 00000000..6eaea6d6
--- /dev/null
+++ b/scripts/build-verified-mapping.mjs
@@ -0,0 +1,178 @@
+#!/usr/bin/env node
+/**
+ * Build the final cert-framework-map.ts from LLM-verified evaluation results.
+ * Uses eval-results/ (not keyword-matched mappings/).
+ */
+
+import { readFileSync, writeFileSync, readdirSync } from 'fs';
+import { join } from 'path';
+
+const REPO_ROOT = join(import.meta.dirname, '..');
+const EVAL_DIR = join(REPO_ROOT, 'scripts', 'data', 'eval-results');
+const COMPONENTS_DIR = join(REPO_ROOT, 'components', 'cert');
+
+const certFiles = readdirSync(EVAL_DIR).filter(f => f.endsWith('.json')).sort();
+
+const forwardIndex = {};
+const reverseIndex = {};
+const allControls = [];
+
+for (const file of certFiles) {
+  const certName = file.replace('.json', '');
+  const controls = JSON.parse(readFileSync(join(EVAL_DIR, file), 'utf-8'));
+  
+  for (const ctrl of controls) {
+    allControls.push({ ...ctrl, certName });
+    
+    // Forward index
+    forwardIndex[ctrl.controlId] = ctrl.refs.map(ref => ({
+      page: ref.page,
+      title: '', // Will be populated from framework-pages.json if available
+      header: ref.header || null,
+      coverage: ref.coverage,
+    }));
+    
+    // Reverse index
+    for (const ref of ctrl.refs) {
+      if (!reverseIndex[ref.page]) reverseIndex[ref.page] = [];
+      reverseIndex[ref.page].push({
+        controlId: ctrl.controlId,
+        controlTitle: ctrl.controlTitle,
+        certName,
+        header: ref.header || null,
+        coverage: ref.coverage,
+      });
+    }
+  }
+}
+
+// Try to populate titles from framework-pages.json
+try {
+  const pages = JSON.parse(readFileSync(join(REPO_ROOT, 'scripts', 'data', 'framework-pages.json'), 'utf-8'));
+  const titleMap = new Map(pages.map(p => [p.path, p.title]));
+  
+  for (const refs of Object.values(forwardIndex)) {
+    for (const ref of refs) {
+      ref.title = titleMap.get(ref.page) || '';
+    }
+  }
+} catch {}
+
+// Generate TypeScript
+const tsContent = `// AUTO-GENERATED by scripts/build-verified-mapping.mjs — do not edit manually
+// LLM-verified mappings: each ref has been evaluated for substantive baseline coverage
+
+export interface FrameworkRef {
+  page: string;
+  title: string;
+  header: string | null;
+  coverage: 'full' | 'partial';
+}
+
+export interface CertRef {
+  controlId: string;
+  controlTitle: string;
+  certName: string;
+  header: string | null;
+  coverage: 'full' | 'partial';
+}
+
+/** Forward index: cert control ID → verified framework page references */
+export const controlToFramework: Record<string, FrameworkRef[]> = ${JSON.stringify(forwardIndex, null, 2)};
+
+/** Reverse index: framework page path → cert controls that reference it */
+export const frameworkToControls: Record<string, CertRef[]> = ${JSON.stringify(
+  Object.fromEntries(
+    Object.entries(reverseIndex).map(([k, v]) => [
+      k,
+      [...new Map(v.map(item => [item.controlId, item])).values()]
+    ])
+  ),
+  null,
+  2
+)};
+`;
+
+writeFileSync(join(COMPONENTS_DIR, 'cert-framework-map.ts'), tsContent);
+
+// Generate gap analysis report
+let report = `# SEAL Certs ↔ Frameworks Gap Analysis (Verified)\n\n`;
+report += `_Generated ${new Date().toISOString().split('T')[0]} — LLM-verified coverage assessment_\n\n`;
+
+const totalControls = allControls.length;
+const withFull = allControls.filter(c => c.refs.some(r => r.coverage === 'full')).length;
+const withPartialOnly = allControls.filter(c => c.refs.length > 0 && c.refs.every(r => r.coverage === 'partial')).length;
+const noCoverage = allControls.filter(c => c.refs.length === 0).length;
+const totalGaps = allControls.reduce((s, c) => s + c.gaps.length, 0);
+
+report += `## Summary\n\n`;
+report += `| Metric | Count | % |\n|--------|-------|---|\n`;
+report += `| Total controls | ${totalControls} | 100% |\n`;
+report += `| ✅ Full coverage (≥1 full ref) | ${withFull} | ${Math.round(withFull/totalControls*100)}% |\n`;
+report += `| ⚠️ Partial coverage only | ${withPartialOnly} | ${Math.round(withPartialOnly/totalControls*100)}% |\n`;
+report += `| ❌ No coverage | ${noCoverage} | ${Math.round(noCoverage/totalControls*100)}% |\n`;
+report += `| Gap baselines (total) | ${totalGaps} | — |\n\n`;
+
+// Per-cert sections
+const certs = {};
+for (const ctrl of allControls) {
+  if (!certs[ctrl.certName]) certs[ctrl.certName] = [];
+  certs[ctrl.certName].push(ctrl);
+}
+
+for (const [certName, controls] of Object.entries(certs)) {
+  const certFull = controls.filter(c => c.refs.some(r => r.coverage === 'full')).length;
+  const certPartial = controls.filter(c => c.refs.length > 0 && c.refs.every(r => r.coverage === 'partial')).length;
+  const certNone = controls.filter(c => c.refs.length === 0).length;
+  
+  report += `## ${certName} (${certFull}✅ ${certPartial}⚠️ ${certNone}❌)\n\n`;
+  
+  for (const ctrl of controls) {
+    const icon = ctrl.refs.some(r => r.coverage === 'full') ? '✅' : ctrl.refs.length > 0 ? '⚠️' : '❌';
+    report += `### ${icon} ${ctrl.controlId}: ${ctrl.controlTitle}\n\n`;
+    
+    if (ctrl.refs.length > 0) {
+      for (const ref of ctrl.refs) {
+        const coverageIcon = ref.coverage === 'full' ? '🟢' : '🟡';
+        report += `${coverageIcon} **[${ref.page}](${ref.page})** ${ref.header ? `→ ${ref.header}` : ''} (${ref.coverage})\n`;
+        if (ref.baselinesMet && ref.baselinesMet.length > 0) {
+          report += `- Met: ${ref.baselinesMet.join('; ')}\n`;
+        }
+        if (ref.baselinesMissed && ref.baselinesMissed.length > 0) {
+          report += `- Missed: ${ref.baselinesMissed.join('; ')}\n`;
+        }
+      }
+    }
+    
+    if (ctrl.gaps.length > 0) {
+      report += `\n**Gaps (${ctrl.gaps.length}):**\n`;
+      for (const gap of ctrl.gaps) {
+        report += `- ❌ ${gap}\n`;
+      }
+    }
+    report += '\n';
+  }
+}
+
+// Reverse index summary
+report += `## Most Referenced Framework Pages\n\n`;
+const sortedPages = Object.entries(reverseIndex)
+  .map(([page, refs]) => ({ page, count: new Set(refs.map(r => r.controlId)).size }))
+  .sort((a, b) => b.count - a.count)
+  .slice(0, 20);
+
+report += `| Page | Controls |\n|------|----------|\n`;
+for (const { page, count } of sortedPages) {
+  report += `| ${page} | ${count} |\n`;
+}
+
+writeFileSync(join(REPO_ROOT, 'docs', 'gap-analysis.md'), report);
+
+console.log(`\n=== VERIFIED RESULTS ===`);
+console.log(`Total: ${totalControls} controls`);
+console.log(`✅ Full: ${withFull} (${Math.round(withFull/totalControls*100)}%)`);
+console.log(`⚠️ Partial: ${withPartialOnly} (${Math.round(withPartialOnly/totalControls*100)}%)`);
+console.log(`❌ None: ${noCoverage} (${Math.round(noCoverage/totalControls*100)}%)`);
+console.log(`Gap baselines: ${totalGaps}`);
+console.log(`\nForward: ${Object.keys(forwardIndex).length} controls`);
+console.log(`Reverse: ${Object.keys(reverseIndex).length} pages`);
diff --git a/scripts/data/cert-controls.json b/scripts/data/cert-controls.json
new file mode 100644
index 00000000..95ddcca4
--- /dev/null
+++ b/scripts/data/cert-controls.json
@@ -0,0 +1,1500 @@
+[
+  {
+    "name": "sfc-devops-infrastructure",
+    "title": "SFC: DevOps & Infrastructure | Security Alliance",
+    "sections": [
+      {
+        "id": "di-1",
+        "title": "Governance & Development Environment",
+        "controls": [
+          {
+            "id": "di-1.1.1",
+            "title": "DevOps Security Owner",
+            "description": "Is there a clearly designated person or team accountable for development and infrastructure security?",
+            "baselines": [
+              "Accountability scope covers policy maintenance, security reviews, access control oversight, pipeline governance, and incident escalation"
+            ]
+          },
+          {
+            "id": "di-1.1.2",
+            "title": "DevOps Security Policy",
+            "description": "Do you maintain documented security policies governing development and infrastructure operations?",
+            "baselines": [
+              "Policy covers environment standards, access controls, deployment procedures, code management, and supply chain security",
+              "Accessible to all developers and infrastructure operators",
+              "Reviewed at least annually and after significant changes (security incidents, technology shifts, organizational restructuring)"
+            ]
+          },
+          {
+            "id": "di-1.1.3",
+            "title": "Development Environment Isolation",
+            "description": "Do you isolate development environments from production systems?",
+            "baselines": [
+              "Development activities performed in containerized or virtualized environments",
+              "Each code repository has its own isolated environment to prevent cross-contamination",
+              "Production credentials not accessible from development environments",
+              "Separate accounts or profiles for development vs. privileged operations (e.g., wallet signing, cloud admin)",
+              "Code execution sandboxed to prevent host system compromise"
+            ]
+          },
+          {
+            "id": "di-1.1.4",
+            "title": "Development Tools Approval",
+            "description": "Do you evaluate and approve development tools before organizational use?",
+            "baselines": [
+              "Evaluation criteria cover IDEs, extensions, plugins, AI-powered tools, and third-party services",
+              "Extensions and plugins obtained only from official repositories",
+              "AI tools assessed for data privacy risks (does the tool send code to third parties for training or analytics?)",
+              "Approved tool list maintained; unapproved tools restricted",
+              "Regular reviews of installed tools to identify unused or unrecognized items"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "di-2",
+        "title": "Source Code & Supply Chain Security",
+        "controls": [
+          {
+            "id": "di-2.1.1",
+            "title": "Repository Security",
+            "description": "Do you enforce security controls on your source code repositories?",
+            "baselines": [
+              "Role-based access control with least-privilege permissions",
+              "Branch protection rules enforced on main/production branches",
+              "Signed commits required for all code changes",
+              "Multi-party code review required for merges to protected branches",
+              "MFA required for all repository members",
+              "Repository access reviewed periodically"
+            ]
+          },
+          {
+            "id": "di-2.1.2",
+            "title": "Secret Scanning",
+            "description": "Do you scan source code for accidentally committed secrets?",
+            "baselines": [
+              "Automated scanning for committed secrets (API keys, private keys, credentials) in all repositories",
+              "Pre-commit hooks deployed to prevent secrets from being committed in the first place",
+              "Remediation procedures for discovered secrets (immediate rotation, revocation)",
+              "Scanning integrated into CI/CD pipeline"
+            ]
+          },
+          {
+            "id": "di-2.1.3",
+            "title": "External Contributor Review",
+            "description": "Do you apply enhanced review for code contributions from external collaborators?",
+            "baselines": [
+              "Additional approvers required for all external code contributions",
+              "Code contributions tracked; unexpected changes flagged (e.g., commit rewrites, unprompted edits)",
+              "External collaborators restricted to minimum necessary repository permissions",
+              "CI/CD pipelines do not automatically execute for external contributor PRs without approval"
+            ]
+          },
+          {
+            "id": "di-2.1.4",
+            "title": "Dependency and Supply Chain Security",
+            "description": "Do you verify and manage dependencies to prevent supply chain attacks?",
+            "baselines": [
+              "Packages obtained from official repositories and trusted sources only",
+              "Package names verified against typosquatting patterns before installation",
+              "Dependencies scanned for known vulnerabilities before deployment",
+              "Dependency version pinning enforced to prevent automatic updates to compromised versions",
+              "Regular dependency audits for outdated or vulnerable components",
+              "Changelog reviewed for dependency updates to verify expected functionality"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "di-3",
+        "title": "CI/CD Pipeline Security",
+        "controls": [
+          {
+            "id": "di-3.1.1",
+            "title": "Pipeline Security Controls",
+            "description": "Do you control who can modify and execute your deployment pipelines?",
+            "baselines": [
+              "Pipeline configuration changes require multi-party approval",
+              "Separate service accounts with minimal permissions used for pipeline execution",
+              "Manual deployment by humans restricted; deployments automated through controlled pipelines",
+              "Pipeline and build configurations version-controlled and reviewed",
+              "Builds are deterministic with strict dependency sets"
+            ]
+          },
+          {
+            "id": "di-3.1.2",
+            "title": "Secrets Management",
+            "description": "Do you securely manage secrets used in pipelines and applications?",
+            "baselines": [
+              "Dedicated secrets management system used (not environment variables in plain text)",
+              "Secrets never stored in source code or unencrypted configuration files",
+              "Production secrets not directly accessible by humans",
+              "Pipeline secrets accessible only by service accounts",
+              "Secret rotation schedule defined; rotation triggered immediately after suspected compromise"
+            ]
+          },
+          {
+            "id": "di-3.1.3",
+            "title": "Security Testing Integration",
+            "description": "Do you integrate security testing into your development and deployment pipelines?",
+            "baselines": [
+              "Static analysis (SAST) tools integrated into CI/CD pipeline",
+              "Dependency vulnerability scanning automated in CI/CD",
+              "Security scan results reviewed before deployment approval",
+              "Testing and validation performed in staging environments before production deployment"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "di-4",
+        "title": "Infrastructure & Cloud Security",
+        "controls": [
+          {
+            "id": "di-4.1.1",
+            "title": "Infrastructure as Code",
+            "description": "Do you manage infrastructure through code with version control and review?",
+            "baselines": [
+              "All infrastructure defined and managed through code (e.g., Terraform, CloudFormation)",
+              "Infrastructure changes deployed through automated pipelines, no manual steps required",
+              "Infrastructure changes require multi-party approval",
+              "IaC security scanning performed before deployment"
+            ]
+          },
+          {
+            "id": "di-4.1.2",
+            "title": "Infrastructure Access Controls",
+            "description": "Do you enforce least-privilege access controls for infrastructure?",
+            "baselines": [
+              "Individual accounts with MFA required; no shared accounts",
+              "Privileged access is time-limited and requires multi-party approval (JIT access)",
+              "Day-to-day operations use minimum necessary permissions (read-only where possible)",
+              "Break-glass accounts established for emergency access with individual accountability",
+              "Break-glass usage triggers immediate alerts to the entire team and requires post-incident review",
+              "All access activities logged and monitored"
+            ]
+          },
+          {
+            "id": "di-4.1.3",
+            "title": "Backup and Disaster Recovery",
+            "description": "Do you maintain backup and disaster recovery procedures with periodic testing?",
+            "baselines": [
+              "Critical systems have automated backup procedures",
+              "Disaster recovery plan documented with recovery time and recovery point objectives defined",
+              "Backup and recovery procedures tested regularly",
+              "Backups stored independently of primary infrastructure"
+            ]
+          },
+          {
+            "id": "di-4.1.4",
+            "title": "Cloud Security Monitoring",
+            "description": "Do you monitor cloud security configurations and respond to provider security notifications?",
+            "baselines": [
+              "Cloud security configurations continuously monitored for drift and unauthorized changes",
+              "Administrative actions trigger alerts",
+              "Cloud provider security notifications subscribed to and promptly reviewed",
+              "Comprehensive logging enabled (e.g., CloudTrail, Azure Monitor, Google Cloud Logging)",
+              "Multi-cloud strategies considered to reduce single-provider dependency"
+            ]
+          }
+        ]
+      }
+    ],
+    "totalControls": 15
+  },
+  {
+    "name": "sfc-dns-registrar",
+    "title": "SFC: DNS Registrar | Security Alliance",
+    "sections": [
+      {
+        "id": "dns-1",
+        "title": "Governance & Domain Management",
+        "controls": [
+          {
+            "id": "dns-1.1.1",
+            "title": "Domain Security Owner",
+            "description": "Is there a clearly designated person or team accountable for domain security?",
+            "baselines": [
+              "Accountability scope covers policy maintenance, security reviews, renewal management, access control oversight, and incident escalation"
+            ]
+          },
+          {
+            "id": "dns-1.1.2",
+            "title": "Domain Inventory and Documentation",
+            "description": "Do you maintain a complete, current record of all your domains and their configurations?",
+            "baselines": [
+              "Registry includes domain name, ownership, purpose, expiration date, registrar, DNS record configurations, security settings (DNSSEC, CAA), and registrar account configurations",
+              "Accessible to relevant team members"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "dns-2",
+        "title": "Risk Assessment & Classification",
+        "controls": [
+          {
+            "id": "dns-2.1.1",
+            "title": "Domain Classification and Compliance",
+            "description": "Do you classify your domains by risk level and verify they meet the security requirements for their classification?",
+            "baselines": [
+              "Classification considers criticality, financial exposure, and operational impact",
+              "Domains where users may transact funds or that are external-facing classified at the highest tier",
+              "Each classification maps to specific security requirements (DNSSEC, locks, monitoring frequency, access controls)",
+              "Compliance verified at least annually through configuration review against documented standards"
+            ]
+          },
+          {
+            "id": "dns-2.1.2",
+            "title": "Enterprise Registrar Security Requirements",
+            "description": "Do you use a registrar with enterprise-grade security for your critical domains?",
+            "baselines": [
+              "Registrar supports registry locks (server-level EPP locks)",
+              "Registrar supports hardware security key MFA (FIDO2/WebAuthn)",
+              "Registrar has no history of social engineering vulnerabilities",
+              "Due diligence includes checking ICANN compliance notices for the registrar"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "dns-3",
+        "title": "Access Control & Authentication",
+        "controls": [
+          {
+            "id": "dns-3.1.1",
+            "title": "Registrar Access Control",
+            "description": "Do you control and secure access to domain registrar and DNS management accounts?",
+            "baselines": [
+              "Documented who is authorized, how access is granted/revoked, and role-based permissions where available",
+              "Hardware security key MFA (FIDO2/WebAuthn) required for all registrar and DNS management accounts",
+              "Access reviews conducted at least annually",
+              "Access revoked promptly when no longer needed"
+            ]
+          },
+          {
+            "id": "dns-3.1.2",
+            "title": "Dedicated Domain Security Contact Email",
+            "description": "Is your domain security contact email independent of the domains it protects?",
+            "baselines": [
+              "Hosted on a different domain than any domain it's responsible for",
+              "Not a personal email address",
+              "Used exclusively for domain security purposes",
+              "Alias that notifies multiple people"
+            ]
+          },
+          {
+            "id": "dns-3.1.3",
+            "title": "Change Management for Domain Operations",
+            "description": "Do you have change management procedures for critical domain operations?",
+            "baselines": [
+              "Covers transfers, deletions, nameserver changes, and DNS record modifications",
+              "Relevant team members notified before critical changes",
+              "All changes logged",
+              "Critical changes verified through out-of-band confirmation with the registrar"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "dns-4",
+        "title": "Technical Security Controls",
+        "controls": [
+          {
+            "id": "dns-4.1.1",
+            "title": "DNS Security Standards",
+            "description": "Do you enforce DNS security standards across all your domains?",
+            "baselines": [
+              "DNSSEC enabled and validated on all critical domains",
+              "CAA records configured to restrict certificate issuance to authorized CAs only",
+              "TTL policies documented with rationale",
+              "Standards applied consistently based on domain classification"
+            ]
+          },
+          {
+            "id": "dns-4.1.2",
+            "title": "Email Authentication Standards",
+            "description": "Do you enforce email authentication standards and monitor for violations?",
+            "baselines": [
+              "SPF, DKIM, and DMARC configured for all domains that send email",
+              "DMARC policy set to reject for domains actively sending email",
+              "DMARC aggregate reports (rua) monitored and reviewed",
+              "MTA-STS configured where supported to enforce encrypted email transport",
+              "Domains that don't send email have SPF/DMARC records that reject all email"
+            ]
+          },
+          {
+            "id": "dns-4.1.3",
+            "title": "Domain Lock Implementation",
+            "description": "Do you use domain locks to prevent unauthorized transfers and changes?",
+            "baselines": [
+              "Registry locks (server-level EPP locks) enabled for all critical domains where supported",
+              "Transfer locks enabled on all domains",
+              "Lock status verified periodically"
+            ]
+          },
+          {
+            "id": "dns-4.1.4",
+            "title": "TLS Certificate Lifecycle Management",
+            "description": "Do you manage the full lifecycle of your TLS certificates?",
+            "baselines": [
+              "Covers issuance, renewal, and revocation procedures",
+              "Certificates tracked with expiration alerts",
+              "Automated renewal where possible",
+              "Revocation procedures documented for compromised certificates"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "dns-5",
+        "title": "Monitoring & Detection",
+        "controls": [
+          {
+            "id": "dns-5.1.1",
+            "title": "Domain and DNS Monitoring",
+            "description": "Do you monitor your domains for unauthorized changes to DNS records, registration status, and security settings?",
+            "baselines": [
+              "DNS record monitoring covers nameserver (NS) changes, A/AAAA changes, MX changes, TXT/SPF/DMARC changes, CAA record removal, DNSSEC status changes, and unexpected TTL drops",
+              "Registration monitoring covers lock status, registrar account settings, and nameserver delegation",
+              "Alerting and escalation paths documented",
+              "Critical alerts (nameserver changes, DNSSEC failure, registrar changes) trigger immediate investigation",
+              "Monitoring infrastructure not dependent on the domains being monitored"
+            ]
+          },
+          {
+            "id": "dns-5.1.2",
+            "title": "Certificate Transparency Monitoring",
+            "description": "Do you monitor Certificate Transparency logs for unauthorized certificates issued for your domains?",
+            "baselines": [
+              "Subscribed to a CT monitoring service that alerts on new certificate issuance",
+              "Alerts reviewed and unauthorized certificates investigated promptly",
+              "Wildcard certificates flagged if not expected"
+            ]
+          },
+          {
+            "id": "dns-5.1.3",
+            "title": "Domain Expiration Prevention",
+            "description": "Do you actively prevent domain expiration?",
+            "baselines": [
+              "Auto-renewal enabled on all domains",
+              "Calendar reminders at 90, 60, 30, and 7 days before expiration",
+              "Payment methods verified current",
+              "Backup person designated for renewal responsibility"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "dns-6",
+        "title": "Incident Response",
+        "controls": [
+          {
+            "id": "dns-6.1.1",
+            "title": "Alerting and Emergency Contacts",
+            "description": "Do you have alerting and emergency contacts in place for domain security incidents?",
+            "baselines": [
+              "Alerting system in place to notify relevant stakeholders when a potential compromise is detected",
+              "Emergency contacts pre-documented including registrar security team, SEAL 911, and legal counsel",
+              "Communication plan for warning users (status page, social media, in-app warnings)"
+            ]
+          },
+          {
+            "id": "dns-6.1.2",
+            "title": "Domain Incident Response Plan",
+            "description": "Do you have an incident response plan for domain hijacking and DNS compromise?",
+            "baselines": [
+              "Covers key scenarios including registrar account compromise, DNS hijacking, and unauthorized transfers",
+              "Emergency registry lock activation procedures",
+              "Procedures for regaining control of compromised domains",
+              "Post-recovery validation including DNS records verified against known-good baseline, all credentials reset, and access logs reviewed",
+              "Plan tested at least annually (can be combined with broader IR drills)"
+            ]
+          }
+        ]
+      }
+    ],
+    "totalControls": 16
+  },
+  {
+    "name": "sfc-incident-response",
+    "title": "SFC: Incident Response | Security Alliance",
+    "sections": [
+      {
+        "id": "ir-1",
+        "title": "Governance & Team Structure",
+        "controls": [
+          {
+            "id": "ir-1.1.1",
+            "title": "IR Team and Role Assignments",
+            "description": "Do you have an incident response team with clearly defined roles and responsibilities?",
+            "baselines": [
+              "Incident commander (with designated backup) who coordinates response, assigns tasks, and makes time-sensitive decisions",
+              "Subject matter experts identified for key domains (smart contracts, infrastructure, security) who can analyze attacks and prepare response strategies",
+              "Scribe role defined for real-time incident documentation",
+              "Communications personnel designated for public information sharing and record-keeping",
+              "Legal support available with procedures for reviewing response actions, whitehat engagement, and public communications",
+              "Decision makers defined for high-stakes decisions (system shutdown, public disclosure, fund recovery)",
+              "Roles, authorities, and escalation measures reviewed at least annually and after protocol changes, team restructuring, or major incidents"
+            ]
+          },
+          {
+            "id": "ir-1.1.2",
+            "title": "Stakeholder Coordination and Contacts",
+            "description": "Do you maintain current contacts and coordination procedures for all parties needed during an incident?",
+            "baselines": [
+              "Internal coordination procedures between technical (devs, auditors) and operational teams (security council, communications)",
+              "External protocol contacts for protocols you depend on and protocols that depend on you",
+              "External expertise contacts including forensics firms, security consultants, SEAL 911, and auditors",
+              "Legal counsel and communications/PR contacts",
+              "Infrastructure vendor support contacts and escalation procedures",
+              "Contact list reviewed at least quarterly and after team changes",
+              "Escalation order documented for P1 incidents (e.g., SEAL 911 → decision makers → security partners → legal)"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "ir-2",
+        "title": "Monitoring, Detection & Alerting",
+        "controls": [
+          {
+            "id": "ir-2.1.1",
+            "title": "Monitoring Coverage",
+            "description": "Do you maintain monitoring coverage for your critical systems, protocols, and external attack surfaces?",
+            "baselines": [
+              "Monitoring covers critical smart contracts, infrastructure, and on-chain activity",
+              "24/7 monitoring capabilities with procedures for after-hours alert handling",
+              "Credential and secret exposure detection including dark web monitoring, breach database scanning, and secret scanning in code repositories",
+              "Organizational account monitoring including social media accounts and websites monitored for unauthorized access or compromise",
+              "Monitoring coverage documented — what's covered, what's not, and known gaps"
+            ]
+          },
+          {
+            "id": "ir-2.1.2",
+            "title": "Alerting, Paging, and Escalation",
+            "description": "Do you have alerting and paging systems that reliably route incidents to available responders?",
+            "baselines": [
+              "Automated alerting configured for security events and operational issues",
+              "Alerts include embedded triage guidance for distinguishing true incidents from false positives",
+              "Triage and classification procedures documented with escalation paths based on severity",
+              "Time-based escalation triggers if initial responder doesn't acknowledge within defined window",
+              "Management notification requirements for high-severity incidents",
+              "Redundant paging systems with documented failover procedures",
+              "On-call schedules maintained with adequate coverage for operational needs",
+              "Backup procedures when on-call personnel are unreachable"
+            ]
+          },
+          {
+            "id": "ir-2.1.3",
+            "title": "Logging Integrity and Retention",
+            "description": "Do you maintain tamper-evident logs with adequate retention for incident investigation?",
+            "baselines": [
+              "Log retention periods defined for security, infrastructure, and cloud provider logs",
+              "Retention adequate for forensic analysis (consider regulatory requirements and typical investigation timelines)",
+              "Tamper-evident logging for security-relevant events including access logs, alerting system logs, and infrastructure logs",
+              "Alerts triggered if logs are altered, deleted, or if monitoring/logging is disabled",
+              "Log sources documented — what's captured and where it's stored"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "ir-3",
+        "title": "Response & Emergency Operations",
+        "controls": [
+          {
+            "id": "ir-3.1.1",
+            "title": "Response Playbooks",
+            "description": "Do you maintain response playbooks for common incident types?",
+            "baselines": [
+              "Playbooks cover key scenarios including protocol exploits, infrastructure failures, access control breaches, key compromise, supply chain compromises, and frontend/DNS compromise",
+              "Each playbook includes initial response actions covering containment, evidence preservation, and stakeholder notification",
+              "Role-specific responsibilities defined for each scenario (who does what — technical, comms, legal)",
+              "Escalation criteria documented for when to engage leadership, when to shut down systems, when to make public disclosure, and when to engage external assistance",
+              "Key compromise playbook includes procedures for rotating keys and replacing compromised signers, with threshold and access reviewed after any signer replacement"
+            ]
+          },
+          {
+            "id": "ir-3.1.2",
+            "title": "Signer Reachability and Coordination",
+            "description": "Can you reach enough signers to execute emergency on-chain actions at any time, including outside business hours?",
+            "baselines": [
+              "Procedures for coordinating multisig operations during incidents, including cross-timezone signer availability",
+              "Signers integrated into on-call/paging systems",
+              "Escalation paths documented for when signers are unreachable",
+              "Tested quarterly"
+            ]
+          },
+          {
+            "id": "ir-3.1.3",
+            "title": "Emergency Transaction Readiness",
+            "description": "Do you have backup signing infrastructure and pre-prepared emergency transactions for critical protocol functions?",
+            "baselines": [
+              "Pre-signed or pre-prepared emergency transactions for critical protocol functions (pause, freeze, parameter changes) where feasible",
+              "Backup signing infrastructure available including alternate signing UI, backup RPC providers, and alternate block explorer",
+              "Emergency execution procedures documented (what to pause/freeze/modify and the process for doing so)"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "ir-4",
+        "title": "Communication & Coordination",
+        "controls": [
+          {
+            "id": "ir-4.1.1",
+            "title": "Incident Communication Channels",
+            "description": "Do you maintain secure, dedicated communication channels for incident response?",
+            "baselines": [
+              "Dedicated incident communication channels with documented access controls and member lists",
+              "Multiple communication channels (primary and backup) on different platforms, with documented failover procedures",
+              "Procedures for rapidly creating incident-specific channels (war room) when needed",
+              "Secure communication procedures for sensitive incident information including need-to-know access and encrypted channels"
+            ]
+          },
+          {
+            "id": "ir-4.1.2",
+            "title": "Internal Status Updates",
+            "description": "Do you have procedures for providing regular status updates to stakeholders during incidents?",
+            "baselines": [
+              "Status update cadence defined by severity level",
+              "Format and distribution lists for internal stakeholders"
+            ]
+          },
+          {
+            "id": "ir-4.1.3",
+            "title": "Public Communication and Information Management",
+            "description": "Do you have procedures for public communication and information management during incidents?",
+            "baselines": [
+              "Pre-approved communication templates for different incident types and severity levels",
+              "Procedures for coordinating communications with protocol users during and after incidents",
+              "Procedures for managing public information flow and correcting misinformation during active incidents",
+              "Designated communications approval flow before public statements are released"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "ir-5",
+        "title": "Testing & Continuous Improvement",
+        "controls": [
+          {
+            "id": "ir-5.1.1",
+            "title": "IR Drills and Testing",
+            "description": "Do you conduct regular incident response drills and evaluate the results?",
+            "baselines": [
+              "Drills conducted at least annually",
+              "Drills cover different incident types across exercises (protocol exploit, infrastructure failure, key compromise, etc.)",
+              "Tests the full pipeline from monitoring through alerting, paging, triage, escalation, team coordination, containment, and recovery",
+              "Production alerting pipeline validated end-to-end from event detection through to responder notification and acknowledgment",
+              "Drill documentation includes date, scenario, participants, response times, gaps identified, and corrective actions",
+              "Corrective actions tracked to completion with owners and deadlines",
+              "Drill findings incorporated into playbook and procedure updates"
+            ]
+          }
+        ]
+      }
+    ],
+    "totalControls": 12
+  },
+  {
+    "name": "sfc-multisig-ops",
+    "title": "SFC: Multisig Operations | Security Alliance",
+    "sections": [
+      {
+        "id": "ms-1",
+        "title": "Governance & Inventory",
+        "controls": [
+          {
+            "id": "ms-1.1.1",
+            "title": "Named Multisig Operations Owner",
+            "description": "Is there a clearly named person or team accountable for multisig operations?",
+            "baselines": [
+              "Accountability scope covers policy maintenance, signer onboarding/offboarding, documentation accuracy, periodic reviews, and incident escalation"
+            ]
+          },
+          {
+            "id": "ms-1.1.2",
+            "title": "Multisig Registry and Documentation",
+            "description": "Do you maintain a complete, accurate, and accessible record of all your multisigs, their configurations, and their signers?",
+            "baselines": [
+              "Registry includes address, network, threshold, classification, purpose, signer addresses, controlled contracts, on-chain roles, and last review date",
+              "Updated within 24 hours for security-critical changes, 3 days for routine changes",
+              "Accessible to signers and key personnel"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "ms-2",
+        "title": "Risk Assessment & Management",
+        "controls": [
+          {
+            "id": "ms-2.1.1",
+            "title": "Multisig Classification and Risk-Based Controls",
+            "description": "Do you classify your multisigs by risk level and apply security controls proportional to each classification?",
+            "baselines": [
+              "Classification considers impact factors (financial exposure, protocol criticality, reputational risk) and operational needs (response time, coordination complexity)",
+              "Each classification maps to specific required controls (thresholds, quorum composition, review cadence)",
+              "All multisigs must have at least 3 distinct signers with a signing threshold of 50% or greater; N-of-N configurations should be avoided",
+              "Higher-risk classifications require stronger controls (more signers, higher thresholds)",
+              "Classifications reviewed every 6 months and after significant changes (TVL shifts, new products, protocol upgrades, security incidents)"
+            ]
+          },
+          {
+            "id": "ms-2.1.2",
+            "title": "Contract-Level Security Controls",
+            "description": "Have you evaluated contract-level security controls that could limit the impact of a multisig compromise?",
+            "baselines": [
+              "Evaluation covers timelocks, modules, guards, address whitelisting, invariant enforcement, and parameter bounds",
+              "Controls evaluated for each multisig based on classification",
+              "Security review required before enabling any module or guard",
+              "Decisions documented, including rationale for controls not implemented"
+            ]
+          },
+          {
+            "id": "ms-2.1.3",
+            "title": "Exception Approval Process",
+            "description": "Do you have a process for approving and tracking exceptions to multisig policies?",
+            "baselines": [
+              "Exceptions require documented justification, expiry date, compensating controls, and remediation plan",
+              "Critical-class exceptions require executive or security-lead approval"
+            ]
+          },
+          {
+            "id": "ms-2.1.4",
+            "title": "Wallet Segregation",
+            "description": "Do you distribute assets across multiple wallets to limit the impact of a single compromise?",
+            "baselines": [
+              "Segregation considers value, operational needs, and risk tolerance",
+              "Examples include hot/cold separation and treasury distribution across multiple wallets"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "ms-3",
+        "title": "Signer Security & Access Control",
+        "controls": [
+          {
+            "id": "ms-3.1.1",
+            "title": "Signer Address Verification",
+            "description": "Do you verify that each signer address on your multisigs belongs to the intended person?",
+            "baselines": [
+              "Verification process includes message signing with the signer address, verification via an independent tool, and documented proof of verification"
+            ]
+          },
+          {
+            "id": "ms-3.1.2",
+            "title": "Signer Key Management Standards",
+            "description": "Do you enforce signer key management standards?",
+            "baselines": [
+              "Hardware wallets required for all multisig operations",
+              "Each signer uses a fresh, dedicated address per multisig, used exclusively for that multisig's operations"
+            ]
+          },
+          {
+            "id": "ms-3.1.3",
+            "title": "Seed Phrase Backup and Protection",
+            "description": "Do you securely back up and protect signer seed phrases and recovery materials?",
+            "baselines": [
+              "Seed phrases never stored digitally, in cloud storage, or photographed",
+              "Backups are geographically distributed (disaster resistant)",
+              "No single point of compromise (theft resistant)",
+              "Recoverable if one operator is unavailable (operator-loss resistant)"
+            ]
+          },
+          {
+            "id": "ms-3.1.4",
+            "title": "Signer Lifecycle Management",
+            "description": "Do you have a defined process for adding, removing, and periodically verifying signers?",
+            "baselines": [
+              "Offboarded signers removed within 48-72 hours (Emergency-class), 7 days (Critical-class), 14 days (others)",
+              "Access reviews quarterly, confirming each signer still controls their key"
+            ]
+          },
+          {
+            "id": "ms-3.1.5",
+            "title": "Signer Training and Assessment",
+            "description": "Are signers trained and assessed on security practices before they are authorized to sign?",
+            "baselines": [
+              "Training covers transaction verification, emergency procedures, phishing and social engineering awareness",
+              "Practical skills assessment included",
+              "Annual refreshers; updates within 30 days of significant procedure changes"
+            ]
+          },
+          {
+            "id": "ms-3.1.6",
+            "title": "Hardware Wallet Standards",
+            "description": "Do you define and enforce hardware wallet standards for multisig operations?",
+            "baselines": [
+              "Wallet capability requirements include adequate display, clear signing support, PIN security, and firmware integrity verification",
+              "Procurement through verified supply chains (direct from manufacturer or authorized resellers), with device authenticity verification"
+            ]
+          },
+          {
+            "id": "ms-3.1.7",
+            "title": "Secure Signing Environment",
+            "description": "Do signers use a secure environment for signing operations?",
+            "baselines": [
+              "Device security requirements documented and enforced",
+              "Dedicated signing devices or network isolation for high-value operations"
+            ]
+          },
+          {
+            "id": "ms-3.1.8",
+            "title": "Signer Diversity",
+            "description": "Are your signers distributed across roles, entities, and geographies to prevent a single event from compromising quorum?",
+            "baselines": [
+              "Diversity requirements scale with multisig classification"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "ms-4",
+        "title": "Operational Procedures",
+        "controls": [
+          {
+            "id": "ms-4.1.1",
+            "title": "Transaction Handling Process",
+            "description": "Do you have a defined, documented process for how transactions are proposed, verified, and executed?",
+            "baselines": [
+              "Process covers initiation, approval, simulation, execution, and confirmation",
+              "Defines who is authorized to initiate transactions",
+              "Each signer independently verifies transaction details (chain ID, target address, calldata, value, nonce, operation type) before signing",
+              "Transaction hashes compared across at least two independent interfaces (e.g., web UI and CLI, or web and mobile app)",
+              "DELEGATECALL operations to untrusted addresses flagged as high risk",
+              "High-risk transactions (large transfers, emergency actions, protocol changes) require waiting periods where feasible and elevated threshold approval",
+              "High-risk thresholds defined based on classification and reviewed periodically",
+              "Private transaction submission used when appropriate to prevent front-running or MEV extraction"
+            ]
+          },
+          {
+            "id": "ms-4.1.2",
+            "title": "Transaction Audit Trails",
+            "description": "Do you keep records of all transaction reviews, approvals, and executions?",
+            "baselines": [
+              "Retained for 3 years",
+              "Records include proposer, approvers, verification evidence, timestamps, and issues encountered"
+            ]
+          },
+          {
+            "id": "ms-4.1.3",
+            "title": "Tool and Platform Evaluation",
+            "description": "Do you vet the tools and platforms used for multisig operations before adoption?",
+            "baselines": [
+              "Evaluation considers whether tools are open source or audited by 2+ reputable firms, have no known critical unpatched vulnerabilities, and have established ecosystem adoption",
+              "Formal process for adopting new tools"
+            ]
+          },
+          {
+            "id": "ms-4.1.4",
+            "title": "Backup Signing Infrastructure",
+            "description": "Do you have backup infrastructure in case your primary signing tools are unavailable?",
+            "baselines": [
+              "Alternate signing UI",
+              "2-3 backup RPC providers",
+              "Alternate block explorer"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "ms-5",
+        "title": "Communication & Coordination",
+        "controls": [
+          {
+            "id": "ms-5.1.1",
+            "title": "Secure Communication Procedures",
+            "description": "Do you have secure communication procedures for multisig operations, including standard identity verification?",
+            "baselines": [
+              "Dedicated primary and backup channels on different platforms",
+              "End-to-end encryption, MFA required, invitation-based membership",
+              "Signer identity verified as standard procedure during signing operations (e.g., code words, video call, secondary authenticated channel)",
+              "Documented procedures for channel compromise including switching to backup channels and out-of-band verification",
+              "All signers trained on these procedures; compromise response tested annually"
+            ]
+          },
+          {
+            "id": "ms-5.1.2",
+            "title": "Emergency Contact List",
+            "description": "Do you maintain a current emergency contact list for all multisig stakeholders?",
+            "baselines": [
+              "Includes protocol security team, external security resources, legal/compliance contacts, and backup contacts for signers",
+              "Personal emergency contacts for each signer (e.g., trusted family member, close colleague) for situations where the signer is unreachable through normal channels",
+              "Reviewed every 6 months"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "ms-6",
+        "title": "Emergency Operations",
+        "controls": [
+          {
+            "id": "ms-6.1.1",
+            "title": "Emergency Playbooks",
+            "description": "Do you have step-by-step emergency playbooks?",
+            "baselines": [
+              "Scenarios covered include key compromise, lost access, communication channel compromise, and urgent protocol actions",
+              "Each scenario has procedures and escalation paths",
+              "Playbooks accessible through at least one backup method independent of the primary documentation platform"
+            ]
+          },
+          {
+            "id": "ms-6.1.2",
+            "title": "Signer Reachability and Escalation",
+            "description": "Can you reach enough signers to meet quorum at any time, including outside business hours?",
+            "baselines": [
+              "Response times by classification - Emergency less than 2 hours, Time-Sensitive 2-12 hours, Routine 24-48 hours",
+              "Paging covers all signers including external parties",
+              "Tested quarterly",
+              "Escalation paths documented"
+            ]
+          },
+          {
+            "id": "ms-6.1.3",
+            "title": "Multisig Monitoring and Alerts",
+            "description": "Do you monitor all multisigs for unauthorized or suspicious activity?",
+            "baselines": [
+              "Monitored events include signer/threshold changes, transfers exceeding thresholds, nonce gaps, interactions with unknown addresses, failed transactions, module/guard changes, and low submitter/proposer balances",
+              "Alerting and escalation paths documented",
+              "Monitoring infrastructure protected against tampering"
+            ]
+          },
+          {
+            "id": "ms-6.1.4",
+            "title": "Emergency Drills and Improvement",
+            "description": "Do you regularly rehearse your emergency procedures and track improvements?",
+            "baselines": [
+              "Annual minimum",
+              "After major procedure changes",
+              "Documentation includes date, participants, response times, issues identified, and improvements made"
+            ]
+          }
+        ]
+      }
+    ],
+    "totalControls": 24
+  },
+  {
+    "name": "sfc-treasury-ops",
+    "title": "SFC: Treasury Operations | Security Alliance",
+    "sections": [
+      {
+        "id": "tro-1",
+        "title": "Governance & Treasury Architecture",
+        "controls": [
+          {
+            "id": "tro-1.1.1",
+            "title": "Treasury Operations Owner",
+            "description": "Is there a clearly designated person or team accountable for treasury operations?",
+            "baselines": [
+              "Accountability scope covers policy upkeep, security reviews, operational hygiene, access control oversight, and incident escalation"
+            ]
+          },
+          {
+            "id": "tro-1.1.2",
+            "title": "Treasury Registry and Documentation",
+            "description": "Do you maintain a complete, current record of all treasury wallets, accounts, and their configurations?",
+            "baselines": [
+              "Registry includes wallet/account address, network/chain, custody provider, custody model, purpose/classification, authorized signers/approvers, controlled contracts or protocols, and last review date",
+              "Updated within 24 hours for security-critical changes (signer changes, new wallets), 3 days for routine changes",
+              "Accessible to authorized treasury personnel"
+            ]
+          },
+          {
+            "id": "tro-1.1.3",
+            "title": "Custody Architecture Rationale",
+            "description": "Do you have documented rationale for your treasury custody architecture?",
+            "baselines": [
+              "Custody model documented for each wallet/account (custodial, self-custody, co-managed, MPC, multisig, HSM)",
+              "Technology trade-offs understood by the team (not necessarily a formal document — could be a brief internal memo)",
+              "Custody architecture reviewed when treasury size, operational needs, or risk profile changes significantly"
+            ]
+          },
+          {
+            "id": "tro-1.1.4",
+            "title": "Treasury Infrastructure Change Management",
+            "description": "Do you have change management procedures for treasury infrastructure modifications?",
+            "baselines": [
+              "Covers wallet setups, custody configurations, signer/approver permission changes, and protocol integrations",
+              "Changes require documented approval before implementation",
+              "All changes logged with justification and approver",
+              "Changes reflected in the treasury registry within defined SLAs",
+              "Rollback procedures documented for critical changes"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "tro-2",
+        "title": "Risk Classification & Fund Allocation",
+        "controls": [
+          {
+            "id": "tro-2.1.1",
+            "title": "Treasury Wallet Risk Classification",
+            "description": "Do you classify your treasury wallets and accounts by risk level and assign security controls accordingly?",
+            "baselines": [
+              "Classification considers financial exposure, operational dependency, and regulatory impact",
+              "Impact levels defined (e.g., Low <1%, Medium 1-10%, High 10-25%, Critical >25% of total assets)",
+              "Operational types defined based on transaction frequency and urgency requirements",
+              "Each classification maps to specific controls including approval thresholds, MFA requirements, whitelist delays, and monitoring levels",
+              "Classification reviewed when asset values, operational patterns, or risk profile change significantly"
+            ]
+          },
+          {
+            "id": "tro-2.1.2",
+            "title": "Fund Allocation Limits and Rebalancing",
+            "description": "Do you enforce fund allocation limits and rebalancing triggers across your treasury?",
+            "baselines": [
+              "Maximum allocation defined per wallet, per custody provider, and per chain",
+              "Rebalancing triggers documented (e.g., when a wallet exceeds its allocation ceiling or falls below operational minimums)",
+              "Allocation limits reviewed periodically and after significant treasury changes",
+              "No single wallet or custody account holds more than the organization's defined maximum concentration"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "tro-3",
+        "title": "Access Control & Platform Security",
+        "controls": [
+          {
+            "id": "tro-3.1.1",
+            "title": "Custody Platform Security Configuration",
+            "description": "Do you configure and maintain security controls on your custody platforms?",
+            "baselines": [
+              "Transaction policy rules configured: multi-approval workflows, approval thresholds scaled to transaction value, address whitelisting with cooling-off periods, velocity/spending limits",
+              "Hardware security key MFA required for all approvers on High and Critical accounts",
+              "Session timeouts and re-authentication for sensitive operations",
+              "Network restrictions: IP whitelisting, VPN requirements where supported, geographic access restrictions",
+              "Separation of duties enforced: initiators cannot approve their own transactions, admins cannot unilaterally execute withdrawals",
+              "Platform configurations documented and reviewed at least quarterly"
+            ]
+          },
+          {
+            "id": "tro-3.1.2",
+            "title": "Credential and Secret Management",
+            "description": "Do you securely manage all credentials and secrets used in treasury operations?",
+            "baselines": [
+              "Covers API keys, service accounts, owner/admin credentials, and signing keys",
+              "Credentials stored in dedicated secret management systems, not in code, documents, or shared drives",
+              "Owner and admin credentials isolated from day-to-day operational access",
+              "Credential rotation schedule defined and enforced",
+              "Access to credentials logged and monitored"
+            ]
+          },
+          {
+            "id": "tro-3.1.3",
+            "title": "Access Reviews for Treasury Systems",
+            "description": "Do you periodically review who has access to treasury systems?",
+            "baselines": [
+              "Access reviews conducted at least quarterly for High/Critical accounts, annually for others",
+              "Reviews verify each user still requires their current access level",
+              "Access promptly revoked when personnel change roles or leave"
+            ]
+          },
+          {
+            "id": "tro-3.1.4",
+            "title": "Personnel Operational Security",
+            "description": "Do you enforce operational security requirements for treasury personnel?",
+            "baselines": [
+              "Device security requirements documented: dedicated devices for custody access, full disk encryption, automatic screen lock",
+              "Signing devices (hardware wallets) securely stored when not in use",
+              "Backup materials (seed phrases, recovery keys) stored securely with geographic distribution",
+              "VPN mandatory for all remote treasury platform access",
+              "Travel security procedures for personnel with signing or custody access capabilities",
+              "Mobile devices used as second factors have endpoint security monitoring"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "tro-4",
+        "title": "Transaction Security",
+        "controls": [
+          {
+            "id": "tro-4.1.1",
+            "title": "Transaction Verification and Execution",
+            "description": "Do you have a defined process for verifying and executing treasury transactions?",
+            "baselines": [
+              "Pre-execution verification includes: recipient address validation, amount verification, network confirmation, and transaction simulation",
+              "Test transactions required before sending to new addresses",
+              "Address verified through multiple independent sources; never copied from email, chat, or transaction history",
+              "Multi-party confirmation required: minimum 2 internal personnel for large transfers",
+              "Specific procedures for receiving large incoming transfers (address generation, bidirectional test, sender coordination)",
+              "Specific procedures for OTC transactions where applicable",
+              "High-value transfers (organization-defined threshold) require video call verification with liveness checks",
+              "All transaction parameters read aloud and confirmed before execution"
+            ]
+          },
+          {
+            "id": "tro-4.1.2",
+            "title": "Signer and Approver Knowledge",
+            "description": "Are treasury signers and approvers knowledgeable in the security practices relevant to their role?",
+            "baselines": [
+              "Knowledge covers: transaction verification procedures, address validation techniques, social engineering awareness, emergency procedures",
+              "Competence demonstrated before authorization (e.g., verifying a test transaction end-to-end)",
+              "Knowledge refreshed annually; updated within 30 days of significant procedure changes",
+              "Covers custody-platform-specific workflows and policy engine rules"
+            ]
+          },
+          {
+            "id": "tro-4.1.3",
+            "title": "Secure Communication Procedures",
+            "description": "Do you have secure communication procedures for treasury operations, including standard identity verification?",
+            "baselines": [
+              "Dedicated primary and backup channels on different platforms",
+              "End-to-end encryption, MFA required, invitation-based membership",
+              "Identity verified as standard procedure during signing/approval operations (e.g., code phrases, video call, secondary authenticated channel)",
+              "Anti-social-engineering protocols: established verification procedures for address changes or unusual requests",
+              "Documented procedures for channel compromise including switching to backup channels and out-of-band verification",
+              "All treasury personnel trained on these procedures; compromise response tested annually"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "tro-5",
+        "title": "Protocol Deployments",
+        "controls": [
+          {
+            "id": "tro-5.1.1",
+            "title": "Protocol Evaluation and Exposure Limits",
+            "description": "Do you evaluate external protocols and enforce exposure limits before deploying treasury funds?",
+            "baselines": [
+              "Due diligence process for all protocols before deployment: smart contract audit status, team reputation, TVL history, insurance coverage",
+              "Exposure limits defined per protocol, per chain, and per deployment category (DeFi, staking, liquid staking, etc.)",
+              "Limits reviewed periodically and after significant market or protocol changes",
+              "Risk re-evaluation triggered by: security incidents, major governance proposals, significant TVL changes, new vulnerabilities disclosed"
+            ]
+          },
+          {
+            "id": "tro-5.1.2",
+            "title": "Position Lifecycle Management",
+            "description": "Do you have procedures for managing the lifecycle of your positions in external protocols?",
+            "baselines": [
+              "Entry procedures: smart contract address verification against multiple independent sources, token approval management (minimal approvals, revocation after use)",
+              "Emergency withdrawal/exit procedures documented for all active positions",
+              "Alternative access methods documented in case primary UIs are unavailable (direct contract interaction, CLI tools, alternative frontends)",
+              "Unbonding/unstaking timelines understood and factored into liquidity planning"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "tro-6",
+        "title": "Monitoring & Incident Response",
+        "controls": [
+          {
+            "id": "tro-6.1.1",
+            "title": "Monitoring and Threat Awareness",
+            "description": "Do you monitor your treasury for anomalous activity, external threats, and operational risks?",
+            "baselines": [
+              "Transaction monitoring: unusual amounts, unexpected destinations, failed transactions, policy violations",
+              "Account state monitoring: balance changes, configuration modifications, new device enrollments, authentication anomalies",
+              "External threat intelligence: protocol vulnerabilities, DeFi/staking risks, relevant security incidents in the ecosystem",
+              "Vendor/platform monitoring: custody platform status, infrastructure alerts, service availability",
+              "Compliance monitoring: transactions and wallet addresses screened for sanctions and compliance risk",
+              "Protocol and position monitoring: deployed protocol health, governance changes, TVL shifts, collateral ratios, reward accrual, liquidation risks",
+              "Alerting with defined severity levels and escalation paths",
+              "Critical alerts (large unexpected transactions, unauthorized access attempts) trigger immediate investigation",
+              "Monitoring system integrity protected — alerts triggered when monitoring configurations are changed, disabled, or degraded"
+            ]
+          },
+          {
+            "id": "tro-6.1.2",
+            "title": "Incident Response Plan",
+            "description": "Do you have an incident response plan for treasury security events, and do you test it?",
+            "baselines": [
+              "Severity levels defined with escalation procedures specific to treasury operations",
+              "Containment procedures: fund protection actions (emergency freeze, transfer to secure cold storage, policy lockdown)",
+              "Covers key scenarios: custody platform compromise, unauthorized transaction, signer key compromise, vendor breach",
+              "Emergency contacts pre-documented: custody provider security team, SEAL 911, legal counsel",
+              "Communication plan for stakeholders",
+              "Drills conducted at least annually; after major procedure changes",
+              "Drill documentation includes: date, participants, response times, issues identified, improvements made"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "tro-7",
+        "title": "Vendor & Infrastructure",
+        "controls": [
+          {
+            "id": "tro-7.1.1",
+            "title": "Vendor Security Management",
+            "description": "Do you evaluate and monitor the security of third-party services used in treasury operations?",
+            "baselines": [
+              "Initial due diligence before adoption: security certifications (SOC 2, ISO 27001), audit history, insurance coverage, incident history",
+              "Ongoing monitoring: SOC report currency, security incident notifications, service availability tracking",
+              "Contractual security requirements verified periodically (at least annually)",
+              "Critical vendor changes (ownership, infrastructure, security posture) trigger re-evaluation"
+            ]
+          },
+          {
+            "id": "tro-7.1.2",
+            "title": "Backup Infrastructure and Alternate Access",
+            "description": "Do you have backup infrastructure and alternate access methods for treasury operations?",
+            "baselines": [
+              "Alternate access methods for custody platforms documented and tested (e.g., API access, mobile app, secondary UI)",
+              "Backup RPC providers configured",
+              "Procedures for operating treasury if primary custody platform is unavailable",
+              "Backup infrastructure tested at least annually"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "tro-8",
+        "title": "Accounting & Reporting",
+        "controls": [
+          {
+            "id": "tro-8.1.1",
+            "title": "Financial Recordkeeping and Reconciliation",
+            "description": "Do you maintain accurate treasury records and conduct periodic reconciliation?",
+            "baselines": [
+              "All treasury transactions recorded with categorization, documentation, and authorization chain",
+              "Periodic reconciliation between custody platform records, on-chain balances, and accounting records",
+              "Reconciliation frequency scaled to account classification: daily for Active Operations, weekly for Warm Storage, monthly for Cold Vault",
+              "Discrepancies investigated and resolved promptly",
+              "Treasury reporting procedures documented with defined cadence and audience"
+            ]
+          },
+          {
+            "id": "tro-8.1.2",
+            "title": "Insurance Coverage",
+            "description": "Do you maintain insurance coverage appropriate for your treasury operations?",
+            "baselines": [
+              "Coverage scope documented: what's covered (custody theft, hack, insider fraud) and what's excluded",
+              "Coverage amounts appropriate relative to assets held",
+              "Custody provider's insurance evaluated as part of vendor due diligence",
+              "Insurance coverage reviewed at least annually or when treasury size changes significantly"
+            ]
+          }
+        ]
+      }
+    ],
+    "totalControls": 21
+  },
+  {
+    "name": "sfc-workspace-security",
+    "title": "SFC: Workspace Security | Security Alliance",
+    "sections": [
+      {
+        "id": "ws-1",
+        "title": "Governance & Inventory",
+        "controls": [
+          {
+            "id": "ws-1.1.1",
+            "title": "Workspace Security Owner",
+            "description": "Is there a clearly designated person or team accountable for workspace security?",
+            "baselines": [
+              "Accountability scope covers policy maintenance, device and account standards, access control oversight, periodic reviews, and incident escalation"
+            ]
+          },
+          {
+            "id": "ws-1.1.2",
+            "title": "Workspace Security Policy",
+            "description": "Do you maintain a workspace security policy that is accessible and understood by all personnel?",
+            "baselines": [
+              "Policy covers core expectations including device security, account hygiene, credential management, acceptable use, and incident reporting",
+              "Written in plain language so all personnel can follow it",
+              "Policy reviewed at least annually and after significant changes (security incidents, technology shifts, organizational restructuring)"
+            ]
+          },
+          {
+            "id": "ws-1.1.3",
+            "title": "Asset Inventory",
+            "description": "Do you maintain an inventory of organizational devices and accounts with defined ownership?",
+            "baselines": [
+              "Scoped to devices and accounts with access to sensitive systems or data",
+              "Device inventory tracks make/model, owner, OS version, encryption status, and EDR/MDM enrollment",
+              "Account inventory covers organizational accounts (eg. email, cloud, social media) with defined ownership",
+              "Updated as devices/accounts are provisioned or decommissioned"
+            ]
+          },
+          {
+            "id": "ws-1.1.4",
+            "title": "System and Data Classification",
+            "description": "Do you classify systems and data by sensitivity to determine appropriate security controls?",
+            "baselines": [
+              "Classification levels defined (e.g., critical, high, standard)",
+              "Classification determines which controls apply (access restrictions, monitoring, encryption, backup requirements)",
+              "Classification reviewed when systems, data sensitivity, or organizational structure change"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "ws-2",
+        "title": "Device Security",
+        "controls": [
+          {
+            "id": "ws-2.1.1",
+            "title": "Device Security Standards",
+            "description": "Do you define and enforce security standards for organizational devices?",
+            "baselines": [
+              "Full disk encryption enabled on all devices",
+              "Automatic OS and application patching enabled or enforced",
+              "Strong authentication required (password/biometric, auto-lock timeouts, lock screens)",
+              "Administrative privileges separated from daily-use accounts",
+              "Devices procured through verified supply chains and verified for integrity upon receipt",
+              "Device compliance verified upon provisioning and monitored on an ongoing basis",
+              "BYOD policy defining what personal devices can access and the security controls required (e.g., MDM enrollment, separate work profiles)"
+            ]
+          },
+          {
+            "id": "ws-2.1.2",
+            "title": "Device Lifecycle Management",
+            "description": "Do you have procedures for device loss, theft, and secure decommissioning?",
+            "baselines": [
+              "Remote lock and wipe capability for all organizational devices",
+              "Documented procedures for responding to lost or stolen devices (notification, remote wipe, credential rotation, incident escalation)",
+              "Secure decommissioning procedures including data sanitization and verified destruction for storage media"
+            ]
+          },
+          {
+            "id": "ws-2.1.3",
+            "title": "Endpoint Protection",
+            "description": "Do you deploy and monitor endpoint protection on organizational devices?",
+            "baselines": [
+              "EDR or MDM deployed on all organizational devices with documented coverage",
+              "Alert triage and response procedures defined with severity-based escalation",
+              "Compliance enforcement actions documented (e.g., quarantine non-compliant devices, block access)",
+              "Monitoring coverage includes detection of malware, unauthorized software, and policy violations"
+            ]
+          },
+          {
+            "id": "ws-2.1.4",
+            "title": "Physical and Travel Security",
+            "description": "Do you maintain physical security requirements for workspaces and travel?",
+            "baselines": [
+              "Physical workspace requirements defined for both on-site and remote work environments",
+              "Screen privacy and shoulder-surfing awareness enforced",
+              "Travel security procedures documented covering device handling, network usage, and border crossings",
+              "High-risk travel procedures defined (loaner devices, enhanced controls, check-in schedules)",
+              "USB and charging security addressed (data blockers, no public USB ports)",
+              "Devices physically secured when not in active use (cable locks, safes, carry-on luggage for travel)"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "ws-3",
+        "title": "Account, Access & Credential Management",
+        "controls": [
+          {
+            "id": "ws-3.1.1",
+            "title": "Account Lifecycle Management",
+            "description": "Do you have procedures for provisioning, modifying, and revoking user accounts?",
+            "baselines": [
+              "Account creation requires documented approval from the account owner's manager or designated authority",
+              "Accounts provisioned with minimum necessary permissions (least privilege)",
+              "Modification of account permissions requires documented approval",
+              "Account revocation procedures tied to offboarding and role changes",
+              "Service accounts and shared credentials inventoried with defined ownership"
+            ]
+          },
+          {
+            "id": "ws-3.1.2",
+            "title": "Multi-Factor Authentication",
+            "description": "Do you enforce multi-factor authentication across organizational accounts?",
+            "baselines": [
+              "MFA required for all organizational accounts by default",
+              "Hardware security keys required for high-privilege and critical accounts (admin, infrastructure, custody)",
+              "Phishing-resistant MFA preferred (FIDO2/WebAuthn, hardware keys) over SMS or TOTP where available",
+              "Exceptions documented with justification, compensating controls, and expiry date",
+              "Backup MFA methods configured for account recovery"
+            ]
+          },
+          {
+            "id": "ws-3.1.3",
+            "title": "Organizational Account Security",
+            "description": "Do you maintain security standards for all organizational accounts, including enterprise platforms and external services?",
+            "baselines": [
+              "Security configuration standards defined and applied for enterprise platforms (Google Workspace, Microsoft 365, collaboration tools)",
+              "Social media and public-facing accounts secured with strong authentication and defined ownership",
+              "Ownership verified and documented for all organizational accounts",
+              "Recovery methods restricted to organizational channels (no personal recovery emails or phone numbers on organizational accounts)",
+              "Account configurations reviewed periodically for drift or unauthorized changes"
+            ]
+          },
+          {
+            "id": "ws-3.1.4",
+            "title": "Credential Management Standards",
+            "description": "Do you enforce credential management standards, including secure storage and individual accountability?",
+            "baselines": [
+              "Password manager required for all personnel; no passwords stored in plain text, documents, or browsers",
+              "Unique, strong passwords for every account (minimum length/complexity standards defined)",
+              "Individual accounts required for all personnel — no sharing of personal login credentials",
+              "When credentials must be provisioned or shared (e.g., service accounts, API keys, onboarding), transmission only through encrypted channels (password manager sharing features, not email or chat)",
+              "Credential rotation schedule defined based on risk; rotation triggered immediately after suspected compromise",
+              "Enhanced controls for high-privilege credentials (admin accounts, service accounts, API keys) including stricter rotation, separate storage, and logged access",
+              "Service account and API key inventory maintained with defined ownership"
+            ]
+          },
+          {
+            "id": "ws-3.1.5",
+            "title": "Access Reviews",
+            "description": "Do you conduct periodic access reviews and promptly adjust permissions when roles change?",
+            "baselines": [
+              "Scheduled access reviews at least quarterly for critical systems, annually for others",
+              "Access adjusted within defined timelines when employees change roles",
+              "Reviews verify each user still requires their current level of access",
+              "Unnecessary permissions revoked promptly with documented evidence",
+              "Insider threat consideration included — for each role, assess what damage could be done with current access"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "ws-4",
+        "title": "Software & Application Security",
+        "controls": [
+          {
+            "id": "ws-4.1.1",
+            "title": "Software Evaluation and Approval",
+            "description": "Do you evaluate and approve software, extensions, and tools before organizational use?",
+            "baselines": [
+              "Evaluation criteria for all software before adoption (browsers, extensions, IDEs, libraries, AI assistants, SaaS tools)",
+              "Data privacy and leakage risks assessed (does the tool send data to third parties for training or analytics?)",
+              "Approved software list maintained; unapproved software restricted",
+              "Browser extension approval process defined",
+              "Dependency management includes version pinning, vulnerability scanning, and update policies"
+            ]
+          },
+          {
+            "id": "ws-4.1.2",
+            "title": "Source Code and Repository Security",
+            "description": "Do you secure source code repositories against unauthorized access and credential exposure?",
+            "baselines": [
+              "Role-based access control with least-privilege permissions",
+              "Branch protection rules enforced on critical branches (require reviews, signed commits)",
+              "Automated secret scanning enabled to detect credentials, API keys, and private keys in code",
+              "Pre-commit hooks or CI checks to prevent secrets from being committed",
+              "Repository security audited periodically (access permissions, configuration, open PRs)"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "ws-5",
+        "title": "Network & Communication",
+        "controls": [
+          {
+            "id": "ws-5.1.1",
+            "title": "Network Security",
+            "description": "Do you enforce secure network access for organizational systems?",
+            "baselines": [
+              "VPN or zero-trust network access required for accessing internal resources remotely",
+              "Wi-Fi security standards defined (no auto-connect, avoid public Wi-Fi for sensitive operations)",
+              "Network segmentation applied where applicable (separate guest networks, development environments)",
+              "Cellular or personal hotspot preferred over public Wi-Fi for sensitive work"
+            ]
+          },
+          {
+            "id": "ws-5.1.2",
+            "title": "Secure Communications",
+            "description": "Do you secure organizational communications and verify identity for sensitive interactions?",
+            "baselines": [
+              "End-to-end encrypted channels used for sensitive communications",
+              "Identity verification procedures established for sensitive requests (e.g., access changes, financial approvals, credential sharing)",
+              "Anti-impersonation protocols documented (e.g., secondary channel verification, code words, video confirmation)",
+              "Email security configured (SPF, DKIM, DMARC) to prevent spoofing",
+              "Procedures for channel compromise including switching to backup channels"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "ws-6",
+        "title": "People & Training",
+        "controls": [
+          {
+            "id": "ws-6.1.1",
+            "title": "Security Onboarding",
+            "description": "Do you verify employee identity and provide security onboarding before granting system access?",
+            "baselines": [
+              "Identity and authorization verified before any access is provisioned",
+              "Background checks or identity verification appropriate to role sensitivity",
+              "Security onboarding includes device provisioning, account creation, MFA setup, and initial security training",
+              "New personnel acknowledge security policies before access is granted",
+              "Onboarding checklist documented and consistently applied"
+            ]
+          },
+          {
+            "id": "ws-6.1.2",
+            "title": "Security Offboarding",
+            "description": "Do you have comprehensive offboarding procedures for departing personnel?",
+            "baselines": [
+              "All account access revoked within 24 hours of departure",
+              "Devices returned and verified for data sanitization",
+              "Credentials and secrets rotated for any shared systems the departing person accessed",
+              "Offboarding checklist documented covering: account deprovisioning, device return, credential rotation, access to organizational repositories and tools, recovery of company property",
+              "Involuntary departures trigger immediate access revocation before notification where feasible"
+            ]
+          },
+          {
+            "id": "ws-6.1.3",
+            "title": "Security Awareness and Training",
+            "description": "Do you maintain a security awareness program with regular training and testing?",
+            "baselines": [
+              "Training covers workspace security topics: phishing, social engineering, device security, credential hygiene, and incident reporting",
+              "Phishing simulations conducted at least quarterly",
+              "Follow-up training required for personnel who fail simulations",
+              "Training content updated annually and after significant threats or procedure changes",
+              "Covers crypto-specific risks: fake job offers, malicious browser extensions, clipboard hijacking, social engineering via DMs"
+            ]
+          }
+        ]
+      },
+      {
+        "id": "ws-7",
+        "title": "Monitoring & Risk Management",
+        "controls": [
+          {
+            "id": "ws-7.1.1",
+            "title": "Workspace Security Monitoring and Incident Response",
+            "description": "Do you detect and respond to workspace security incidents?",
+            "baselines": [
+              "Monitoring in place for common workspace threats: account takeovers, unauthorized access, credential leaks, device compromise, data exfiltration",
+              "Response procedures documented for key scenarios: compromised account, compromised device, data leak, insider threat event",
+              "Escalation paths defined with severity levels",
+              "Credential leak monitoring (dark web, breach databases, paste sites, code repositories)",
+              "Incidents documented with timeline, root cause, actions taken, and lessons learned"
+            ]
+          },
+          {
+            "id": "ws-7.1.2",
+            "title": "Insider Threat Assessment",
+            "description": "Do you assess insider threat risks and enforce least-privilege access for each role?",
+            "baselines": [
+              "Damage scenarios documented for each role (what could this person do if compromised or malicious?)",
+              "Least-privilege access enforced across all systems",
+              "Separation of duties applied for critical operations (e.g., no single person can deploy to production, execute large transactions, and manage access controls)",
+              "Assessed during periodic access reviews"
+            ]
+          },
+          {
+            "id": "ws-7.1.3",
+            "title": "Third-Party Access Management",
+            "description": "Do you manage third-party access with time-limited, purpose-specific permissions?",
+            "baselines": [
+              "Third-party access requires documented approval with defined scope and expiry date",
+              "Access limited to minimum necessary systems and data",
+              "Access revoked automatically upon contract expiry or project completion",
+              "Audit trails maintained for all third-party access",
+              "Third-party vendor security evaluated before granting access (security certifications, incident history)"
+            ]
+          }
+        ]
+      }
+    ],
+    "totalControls": 23
+  }
+]
\ No newline at end of file
diff --git a/scripts/data/eval-briefs/sfc-devops-infrastructure.md b/scripts/data/eval-briefs/sfc-devops-infrastructure.md
new file mode 100644
index 00000000..a027b585
--- /dev/null
+++ b/scripts/data/eval-briefs/sfc-devops-infrastructure.md
@@ -0,0 +1,1715 @@
+# Evaluation Brief: sfc-devops-infrastructure
+
+## TASK
+
+For each control below, evaluate whether the candidate framework pages ACTUALLY meet the baseline requirements.
+A page must SUBSTANTIVELY address the baseline — not just mention related keywords.
+Be strict: if a baseline says "reviewed at least annually" and the page doesn't mention review cadence, that baseline is NOT met.
+
+## CONTROLS (15 total)
+
+### di-1.1.1: DevOps Security Owner
+**Question:** Is there a clearly designated person or team accountable for development and infrastructure security?
+**Baselines (1):**
+  1. Accountability scope covers policy maintenance, security reviews, access control oversight, pipeline governance, and incident escalation
+**Candidate pages:** /infrastructure/domain-and-dns-security/registrar-and-locks, /infrastructure/domain-and-dns-security/monitoring-and-alerting, /secure-software-development/secure-code-repositories-version-control
+
+### di-1.1.2: DevOps Security Policy
+**Question:** Do you maintain documented security policies governing development and infrastructure operations?
+**Baselines (3):**
+  1. Policy covers environment standards, access controls, deployment procedures, code management, and supply chain security
+  2. Accessible to all developers and infrastructure operators
+  3. Reviewed at least annually and after significant changes (security incidents, technology shifts, organizational restructuring)
+**Candidate pages:** /supply-chain/supply-chain-levels-software-artifacts, /infrastructure/domain-and-dns-security/monitoring-and-alerting, /security-testing/unit-testing
+
+### di-1.1.3: Development Environment Isolation
+**Question:** Do you isolate development environments from production systems?
+**Baselines (5):**
+  1. Development activities performed in containerized or virtualized environments
+  2. Each code repository has its own isolated environment to prevent cross-contamination
+  3. Production credentials not accessible from development environments
+  4. Separate accounts or profiles for development vs. privileged operations (e.g., wallet signing, cloud admin)
+  5. Code execution sandboxed to prevent host system compromise
+**Candidate pages:** /devsecops/integrated-development-environments, /secure-software-development/secure-code-repositories-version-control, /devsecops/overview
+
+### di-1.1.4: Development Tools Approval
+**Question:** Do you evaluate and approve development tools before organizational use?
+**Baselines (5):**
+  1. Evaluation criteria cover IDEs, extensions, plugins, AI-powered tools, and third-party services
+  2. Extensions and plugins obtained only from official repositories
+  3. AI tools assessed for data privacy risks (does the tool send code to third parties for training or analytics?)
+  4. Approved tool list maintained; unapproved tools restricted
+  5. Regular reviews of installed tools to identify unused or unrecognized items
+**Candidate pages:** /security-automation/infrastructure-as-code, /devsecops/integrated-development-environments, /infrastructure/domain-and-dns-security/dnssec-and-email
+
+### di-2.1.1: Repository Security
+**Question:** Do you enforce security controls on your source code repositories?
+**Baselines (6):**
+  1. Role-based access control with least-privilege permissions
+  2. Branch protection rules enforced on main/production branches
+  3. Signed commits required for all code changes
+  4. Multi-party code review required for merges to protected branches
+  5. MFA required for all repository members
+  6. Repository access reviewed periodically
+**Candidate pages:** /secure-software-development/secure-code-repositories-version-control, /infrastructure/domain-and-dns-security/registrar-and-locks, /secure-software-development/code-reviews-peer-audits
+
+### di-2.1.2: Secret Scanning
+**Question:** Do you scan source code for accidentally committed secrets?
+**Baselines (4):**
+  1. Automated scanning for committed secrets (API keys, private keys, credentials) in all repositories
+  2. Pre-commit hooks deployed to prevent secrets from being committed in the first place
+  3. Remediation procedures for discovered secrets (immediate rotation, revocation)
+  4. Scanning integrated into CI/CD pipeline
+**Candidate pages:** /infrastructure/domain-and-dns-security/registrar-and-locks, /secure-software-development/secure-code-repositories-version-control, /devsecops/continuous-integration-continuous-deployment
+
+### di-2.1.3: External Contributor Review
+**Question:** Do you apply enhanced review for code contributions from external collaborators?
+**Baselines (4):**
+  1. Additional approvers required for all external code contributions
+  2. Code contributions tracked; unexpected changes flagged (e.g., commit rewrites, unprompted edits)
+  3. External collaborators restricted to minimum necessary repository permissions
+  4. CI/CD pipelines do not automatically execute for external contributor PRs without approval
+**Candidate pages:** /secure-software-development/secure-code-repositories-version-control, /security-testing/unit-testing, /infrastructure/domain-and-dns-security/monitoring-and-alerting
+
+### di-2.1.4: Dependency and Supply Chain Security
+**Question:** Do you verify and manage dependencies to prevent supply chain attacks?
+**Baselines (6):**
+  1. Packages obtained from official repositories and trusted sources only
+  2. Package names verified against typosquatting patterns before installation
+  3. Dependencies scanned for known vulnerabilities before deployment
+  4. Dependency version pinning enforced to prevent automatic updates to compromised versions
+  5. Regular dependency audits for outdated or vulnerable components
+  6. Changelog reviewed for dependency updates to verify expected functionality
+**Candidate pages:** /supply-chain/dependency-awareness, /supply-chain/supply-chain-levels-software-artifacts, /infrastructure/domain-and-dns-security/registrar-and-locks
+
+### di-3.1.1: Pipeline Security Controls
+**Question:** Do you control who can modify and execute your deployment pipelines?
+**Baselines (5):**
+  1. Pipeline configuration changes require multi-party approval
+  2. Separate service accounts with minimal permissions used for pipeline execution
+  3. Manual deployment by humans restricted; deployments automated through controlled pipelines
+  4. Pipeline and build configurations version-controlled and reviewed
+  5. Builds are deterministic with strict dependency sets
+**Candidate pages:** /infrastructure/domain-and-dns-security/registrar-and-locks, /security-automation/infrastructure-as-code, /devsecops/continuous-integration-continuous-deployment
+
+### di-3.1.2: Secrets Management
+**Question:** Do you securely manage secrets used in pipelines and applications?
+**Baselines (5):**
+  1. Dedicated secrets management system used (not environment variables in plain text)
+  2. Secrets never stored in source code or unencrypted configuration files
+  3. Production secrets not directly accessible by humans
+  4. Pipeline secrets accessible only by service accounts
+  5. Secret rotation schedule defined; rotation triggered immediately after suspected compromise
+**Candidate pages:** /infrastructure/domain-and-dns-security/registrar-and-locks, /security-automation/infrastructure-as-code, /security-automation/compliance-checks
+
+### di-3.1.3: Security Testing Integration
+**Question:** Do you integrate security testing into your development and deployment pipelines?
+**Baselines (4):**
+  1. Static analysis (SAST) tools integrated into CI/CD pipeline
+  2. Dependency vulnerability scanning automated in CI/CD
+  3. Security scan results reviewed before deployment approval
+  4. Testing and validation performed in staging environments before production deployment
+**Candidate pages:** /devsecops/overview, /devsecops/continuous-integration-continuous-deployment, /devsecops/security-testing
+
+### di-4.1.1: Infrastructure as Code
+**Question:** Do you manage infrastructure through code with version control and review?
+**Baselines (4):**
+  1. All infrastructure defined and managed through code (e.g., Terraform, CloudFormation)
+  2. Infrastructure changes deployed through automated pipelines, no manual steps required
+  3. Infrastructure changes require multi-party approval
+  4. IaC security scanning performed before deployment
+**Candidate pages:** /security-automation/infrastructure-as-code, /infrastructure/domain-and-dns-security/monitoring-and-alerting, /secure-software-development/secure-code-repositories-version-control
+
+### di-4.1.2: Infrastructure Access Controls
+**Question:** Do you enforce least-privilege access controls for infrastructure?
+**Baselines (6):**
+  1. Individual accounts with MFA required; no shared accounts
+  2. Privileged access is time-limited and requires multi-party approval (JIT access)
+  3. Day-to-day operations use minimum necessary permissions (read-only where possible)
+  4. Break-glass accounts established for emergency access with individual accountability
+  5. Break-glass usage triggers immediate alerts to the entire team and requires post-incident review
+  6. All access activities logged and monitored
+**Candidate pages:** /infrastructure/domain-and-dns-security/monitoring-and-alerting, /infrastructure/domain-and-dns-security/registrar-and-locks, /secure-software-development/secure-code-repositories-version-control
+
+### di-4.1.3: Backup and Disaster Recovery
+**Question:** Do you maintain backup and disaster recovery procedures with periodic testing?
+**Baselines (4):**
+  1. Critical systems have automated backup procedures
+  2. Disaster recovery plan documented with recovery time and recovery point objectives defined
+  3. Backup and recovery procedures tested regularly
+  4. Backups stored independently of primary infrastructure
+**Candidate pages:** /infrastructure/cloud, /secure-software-development/secure-code-repositories-version-control, /infrastructure/domain-and-dns-security/registrar-and-locks
+
+### di-4.1.4: Cloud Security Monitoring
+**Question:** Do you monitor cloud security configurations and respond to provider security notifications?
+**Baselines (5):**
+  1. Cloud security configurations continuously monitored for drift and unauthorized changes
+  2. Administrative actions trigger alerts
+  3. Cloud provider security notifications subscribed to and promptly reviewed
+  4. Comprehensive logging enabled (e.g., CloudTrail, Azure Monitor, Google Cloud Logging)
+  5. Multi-cloud strategies considered to reduce single-provider dependency
+**Candidate pages:** /infrastructure/domain-and-dns-security/monitoring-and-alerting, /infrastructure/domain-and-dns-security/dnssec-and-email, /infrastructure/cloud
+
+---
+
+## FRAMEWORK PAGES (15 unique)
+
+### PAGE: /infrastructure/domain-and-dns-security/registrar-and-locks
+**Title:** Registrar Security & Registry Locks | SEAL
+**Referenced by controls:** di-1.1.1, di-2.1.1, di-2.1.2, di-2.1.4, di-3.1.1, di-3.1.2, di-4.1.2, di-4.1.3
+
+# Registrar Security & Registry Locks
+
+
+
+
+## Choosing a Secure Registrar
+
+Your domain registrar is the company that manages your domain registration with the central registry. This is often the
+weakest link in domain security, as many registrars have poor security practices and are vulnerable to social
+engineering attacks.
+
+### Enterprise-Grade Registrars (Recommended)
+
+These registrars are designed for high-value domains and have security measures that consumer registrars lack:
+
+- **MarkMonitor**: Used by Fortune 500 companies, requires legal documentation for changes, dedicated security team
+- **AWS Route53**: IAM policy integration, CloudTrail logging, uses Amazon Registrar for major TLDs (but check TLD support)
+- **Cloudflare Registrar**: No markup pricing, automatic DNSSEC, built-in DDoS protection, requires Cloudflare services
+
+### Consumer Registrars to Avoid for Critical Domains
+
+These registrars are designed for personal use and lack the security measures needed for Web3 projects:
+
+- **GoDaddy**: History of social engineering vulnerabilities, call center support vulnerable to manipulation
+  - [2020 incident: Employees tricked into compromising cryptocurrency domains](https://threatpost.com/godaddy-employees-tricked-compromise-cryptocurrency/161520/)
+  - [Multiple low-tech, high-impact breaches](https://krebsonsecurity.com/2023/02/when-low-tech-hacks-cause-high-impact-breaches/)
+- **Namecheap**: While better than GoDaddy, still vulnerable to social engineering and lacks enterprise-grade security controls
+- **Consumer-focused services** (Google Domains/Squarespace): Designed for personal use, not enterprise security
+- **Resellers**: Add another layer of complexity and potential attack surface
+
+**Due diligence**: Check [ICANN Compliance Notices](https://www.icann.org/compliance/notices) for registrar
+terminations, breaches, and compliance issues. ICANN has terminated several registrars due to security issues and
+breaches. Review your registrar's compliance history before trusting them with critical domains.
+
+## Registry Lock (EPP Lock)
+
+Registry lock prevents unauthorized transfers at the registry level, not just the registrar. This is the strongest
+protection available for domain security.
+
+**Important distinction**: EPP status codes apply to **registry objects** (transfers, deletes, nameserver sets, contact
+updates), NOT DNS zone edits at your provider's DNS panel. You can still edit A records, MX records, TXT records, etc.
+in your DNS hosting provider's interface even with EPP locks enabled.
+
+**EPP Status Codes** that protect your domain:
+
+- `clientTransferProhibited`: Prevents domain transfers to another registrar
+- `clientUpdateProhibited`: Prevents registry object updates (nameservers, contact information)
+- `clientDeleteProhibited`: Prevents domain deletion
+- `serverTransferProhibited`: Registry-level transfer protection (stronger than client-level)
+- `serverUpdateProhibited`: Registry-level update protection (nameservers, contacts)
+- `serverDeleteProhibited`: Registry-level deletion protection
+
+**How it protects you**: Standard transfer locks only prevent transfers between registrars, but registry locks with full
+EPP protections prevent unauthorized changes to critical registry objects including transfers, deletions, nameserver
+changes, and contact modifications. Server-level locks require manual verification with the registry operator (like
+Verisign for .com domains), making social engineering attacks at the registrar level completely ineffective.
+
+**What EPP locks do NOT block**: DNS record edits (A, AAAA, MX, TXT, etc.) in your DNS provider's panel remain fully
+functional. EPP locks protect registry-level changes, not zone-level DNS record edits.
+
+**Setup**: Contact enterprise registrars for registry-operator level locks. This typically requires additional fees and
+documentation but provides the highest level of security.
+
+## Multi-Factor Authentication
+
+Multi-factor authentication (MFA) adds an extra layer of security beyond just passwords, which are easily compromised
+through phishing or data breaches.
+
+**Strong recommendation**: Use **Hardware Security Keys (FIDO2/WebAuthn)** for registrar accounts. Given the critical
+nature of domain security and the irreversibility of domain hijacks, hardware keys are the ONLY authentication method we
+strongly recommend for Web3 projects.
+
+**Authentication options**:
+
+1. **Hardware Security Keys (YubiKey, Titan, etc.) - STRONGLY RECOMMENDED**
+   - **Immune to phishing**: Cannot be tricked by fake login pages
+   - **No shared secrets**: Private key never leaves the device
+   - **No SIM swap vulnerability**: Physical device required
+   - **FIDO2/WebAuthn standard**: Industry-standard cryptographic authentication
+   - **Why critical for domains**: Domain control = organization control; hardware keys provide the highest assurance
+
+2. **TOTP Applications (Google Authenticator, Authy) - DISCOURAGED**
+   - Vulnerable to phishing through man-in-the-middle attacks
+   - Shared secrets can be compromised during setup
+   - QR codes can be intercepted or screenshotted
+   - Only use as a last resort if registrar doesn't support hardware keys
+   - If forced to use TOTP, ensure registrar has additional protections
+
+3. **SMS 2FA - DO NOT USE**
+   - **Extremely vulnerable to SIM swapping attacks**
+   - SMS can be intercepted via SS7 vulnerabilities
+   - Social engineering attacks target mobile carriers
+   - No cryptographic security
+   - Numerous high-profile compromises via SMS 2FA
+   - **Never use SMS 2FA for domain registrar accounts**
+
+**Action item**: If your registrar only supports SMS or TOTP, consider **migrating to an enterprise registrar**
+(MarkMonitor, AWS Route53 Registrar, Cloudflare Registrar) that supports hardware security keys.
+
+## Dedicated Security Contact Email
+
+Use a dedicated email address for domain security that's completely separate from your main domain and personal accounts.
+
+**Why this matters**: If your main domain is compromised, you need a way to receive security notifications and regain
+control. Using the same domain creates a circular dependency.
+
+```
+❌ admin@yourdomain.com (circular dependency - if domain is hijacked, you lose email access)
+❌ personal@gmail.com (too many attack vectors, likely used across multiple services)
+⚠️ domain-security@protonmail.com (better than gmail, but still a shared service)
+✅ security@yourcompany-domains.com (best - separate domain dedicated to domain management)
+```
+
+As a best practice register a separate domain specifically for domain management (e.g., `yourproject-domains.com` or
+`yourproject-security.com`) with a different registrar than your main domain. This ensures you maintain communication
+channels even if your primary domain is completely compromised.
+
+## Access Control Best Practices
+
+Limit and monitor who has access to your domain registrar account, as each person with access represents a potential
+attack vector.
+
+**Key practices**:
+
+- Document all personnel with registrar access
+- Use role-based access where available
+- Implement approval workflows for critical changes
+- Regular access audits (quarterly minimum)
+
+## WHOIS Privacy Protection
+
+WHOIS records contain personal information about domain owners that is publicly accessible by default, including names,
+addresses, phone numbers, and email addresses.
+
+**Why it matters**: Without WHOIS privacy, your personal information is exposed to:
+
+- Attackers gathering information for social engineering attacks
+- Spammers harvesting contact details
+- Competitors researching your infrastructure
+- Anyone running a simple WHOIS lookup
+
+**Setup**:
+
+- Enable WHOIS privacy/proxy service through your registrar (often free or low-cost)
+- Use company information instead of personal details where privacy isn't available
+- Consider using a separate business entity for domain registration
+- Be aware that some TLDs (.us, .ca) don't allow WHOIS privacy
+
+**Important**: WHOIS privacy doesn't affect your legal ownership - you remain the legitimate owner, the privacy service
+just shields your personal information from public view.
+
+## WHOIS vs RDAP
+
+**RDAP (Registration Data Access Protocol)** is the modern replacement for WHOIS. While WHOIS is still widely used, RDAP
+should be preferred for domain information lookups.
+
+**Why RDAP is better**:
+
+- **Structured data**: JSON-based responses are machine-readable and easier to parse
+- **Standardized**: Consistent format across registries and registrars
+- **Better display**: Modern CLIs and tools display RDAP data in organized, readable formats
+- **More reliable**: Built on RESTful APIs with better authentication and access control
+- **Links to authoritative sources**: Provides direct links to registrar and registry RDAP endpoints
+
+**Using RDAP**:
+
+- **Command-line tools**: Use RDAP CLIs like `rdap` (Rust-based) or `nicinfo` (Ruby-based)
+- **Web tools**: Many registries provide RDAP web interfaces
+- **Example lookup**: `rdap yourdomain.com` displays domain status, EPP codes, nameservers, registrar info, and
+  expiration dates
+
+**Example RDAP output**:
+
+```
+❯ rdap google.com
+2025-10-06T20:36:58.203437Z  INFO rdap: ICANN RDAP 0.0.23 Command Line Interface
+2025-10-06T20:36:58.203497Z  INFO rdap: query type is Domain Lookup for value 'google.com'
+――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
+ • host                       : rdap.verisign.com
+ • Request URI                : https://rdap.verisign.com/com/v1/domain/google.com
+
+――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
+                                   Domain GOOGLE.COM
+
+  ┌────────────────────────────┬─────────────────────────────────────────────────────┐
+  │                     Summary│Domain GOOGLE.COM                                    │
+  │                            │• 292 (Registrar)                                    │
+  │                            │  • Abuse                                            │
+  │                            │• Nameserver NS1.GOOGLE.COM                          │
+  │                            │• Nameserver NS2.GOOGLE.COM                          │
+  │                            │• Nameserver NS3.GOOGLE.COM                          │
+  │                            │• Nameserver NS4.GOOGLE.COM                          │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │        Identifiers         │                                                     │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │                    LDH Name│GOOGLE.COM                                           │
+  │                Unicode Name│                                                     │
+  │                      Handle│2138514_DOMAIN_COM-VRSN                              │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │        Information         │                                                     │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │                      Status│• Client Delete Prohibited                           │
+  │                            │• Client Transfer Prohibited                         │
+  │                            │• Client Update Prohibited                           │
+  │                            │• Server Delete Prohibited                           │
+  │                            │• Server Transfer Prohibited                         │
+  │                            │• Server Update Prohibited                           │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │           Events           │                                                     │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │                Registration│• Mon, 15-Sep-1997 04:00:00 +00:00                   │
+  │                  Expiration│• Thu, 14-Sep-2028 04:00:00 +00:00                   │
+  │                Last Changed│• Mon,  9-Sep-2019 15:39:04 +00:00                   │
+  │Last Update Of RDAP Database│• Mon,  6-Oct-2025 20:36:39 +00:00                   │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │           Links            │                                                     │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │                        Self│• https://rdap.verisign.com/com/v1/domain/GOOGLE.COM │
+  │                     Related│• https://rdap.markmonitor.com/rdap/domain/GOOGLE.COM│
+  └────────────────────────────┴─────────────────────────────────────────────────────┘
+
+                                    292 (Registrar)
+
+                ┌─────────────────┬────────────────────────────────────┐
+                │          Summary│292 (Registrar)                     │
+                │                 │• Abuse                             │
+                ├─────────────────┼────────────────────────────────────┤
+                │   Identifiers   │                                    │
+                ├─────────────────┼────────────────────────────────────┤
+                │           Handle│292                                 │
+                │            Roles│• registrar                         │
+                │IANA Registrar ID│292                                 │
+                ├─────────────────┼────────────────────────────────────┤
+                │     Contact     │                                    │
+                ├─────────────────┼────────────────────────────────────┤
+                │        Full Name│MarkMonitor Inc.                    │
+                ├─────────────────┼────────────────────────────────────┤
+                │      Links      │                                    │
+                ├─────────────────┼────────────────────────────────────┤
+                │            About│• http://www.markmonitor.com        │
+                │                 │• https://rdap.markmonitor.com/rdap/│
+                └─────────────────┴────────────────────────────────────┘
+```
+
+**What RDAP shows**:
+
+- Domain status and EPP lock codes (clientTransferProhibited, serverUpdateProhibited, etc.)
+- Nameserver information
+- Registrar details and abuse contacts
+- Registration, expiration, and last update dates
+- Links to registry and registrar RDAP endpoints
+
+**For security audits**: Use RDAP to verify your domain's EPP status codes, confirm registry locks are active, check
+nameserver configurations, and validate expiration dates. The structured output makes it ideal for automated monitoring
+and compliance checks.
+
+## Domain Expiration Protection
+
+Domain expiration is a critical yet often overlooked security risk. When domains expire, they enter a grace period
+before becoming publicly available, creating an opportunity for attackers to snipe your domain.
+
+**Expiration timeline (typical for gTLDs following ICANN rules)**:
+
+- Day 0: Domain expires (site goes down)
+- Day 1-45: Auto-renew grace period (can renew at normal price)
+- Day 46-75: Redemption period (costs 10x+ to recover)
+- Day 76-80: Pending delete
+- Day 81: Public availability (bot armies compete to register)
+
+**Important**: Grace and redemption periods **differ per TLD**. Generic TLDs (gTLDs like .com, .org, .net) follow ICANN
+rules with the timeline above. Country code TLDs (ccTLDs like .uk, .de, .ca) often have different policies set by their
+respective registries. Always verify your specific TLD's expiration policy with your registrar or registry.
+
+**Protection measures**:
+
+- **Enable auto-renewal** on all critical domains
+- **Set multiple renewal reminders** at 90, 60, 30, and 7 days before expiration
+- **Register domains for maximum period** (up to 10 years for most TLDs)
+- **Use a domain monitoring service** that alerts on upcoming expirations
+- **Document renewal dates** in your security calendar
+- **Ensure payment methods stay current** - expired credit cards are a common cause of accidental expiration
+- **Designate a backup person** responsible for domain renewals
+
+**Pro tip**: Set calendar reminders to check auto-renewal status quarterly - don't assume it's working until you verify.
+
+---
+
+---
+
+### PAGE: /infrastructure/domain-and-dns-security/monitoring-and-alerting
+**Title:** DNS Monitoring & Incident Response | SEAL
+**Referenced by controls:** di-1.1.1, di-1.1.2, di-2.1.3, di-4.1.1, di-4.1.2, di-4.1.4
+
+# Monitoring, Alerts, and Incident Response
+
+
+
+
+## DNS Record Monitoring
+
+DNS record monitoring involves continuously checking your domain's DNS records for unauthorized changes. Attackers often
+modify DNS records to redirect traffic to malicious servers while keeping your site partially functional.
+
+**What to watch for**:
+
+- **Nameserver (NS) record changes**: Attackers change your nameservers to point to their own DNS servers, giving them
+  complete control over all DNS records
+- **Sudden TTL drops**: Very low TTLs *can* indicate preparation for rapid DNS changes during an attack
+  - **Note**: Low TTL is common and legitimate with CDNs and auto-scaling contexts; Cloudflare "Auto" is often 300s
+  - **Context**: Cloudflare allows TTL 30-60s for [unproxied
+    records](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/); this is not inherently malicious
+  - **Monitor for**: *Unexpected* drops from higher values or drops combined with other suspicious activity
+- **CAA record removal or overrides**: Allows any Certificate Authority to issue certificates for your domain
+  - **Note**: Child zones override parent CAA records
+  - **Advanced monitoring**: Watch for parameters like `accounturi` and `validationmethods` which provide finer control
+    over certificate issuance
+- **DNSSEC disabled unexpectedly**: Removes cryptographic protection from DNS responses
+
+**If nameservers remain unchanged, also monitor**:
+
+- **A/AAAA record modifications**: IP address changes could redirect users to malicious sites
+- **MX record modifications**: Email server changes could intercept password reset emails
+- **TXT record changes**: Could affect email security (SPF/DMARC) or domain validation
+
+**Monitoring tools** (continuous change tracking):
+
+- [MXToolbox](https://mxtoolbox.com/) - Comprehensive DNS record monitoring and alerts
+- [HetrixTools](https://hetrixtools.com/) - Free DNS monitoring with email alerts
+- [SecurityTrails](https://securitytrails.com/) - Historical DNS data and change tracking
+
+**Analysis and debugging tools**:
+
+- [DNSViz](https://dnsviz.net/) - DNSSEC chain validation and debugging
+- [DNS Dumpster](https://dnsdumpster.com/) - DNS reconnaissance and record discovery
+
+**GitOps and zone control**:
+
+- [OctoDNS](https://github.com/octodns/octodns) - Infrastructure-as-code for DNS; manage zones via code with auditable,
+  reviewed changes through CI/CD
+- [DNSControl](https://github.com/StackExchange/dnscontrol) - Synchronize DNS across multiple providers; declarative
+  configuration with version control
+
+**Note**: If attackers change your NS records, they control everything. But attackers with DNS panel access might make
+subtle changes without touching NS records to avoid detection, which is why monitoring individual record types remains
+important.
+
+## Certificate Transparency Monitoring
+
+Certificate Transparency (CT) logs are public records of all SSL certificates issued by Certificate Authorities.
+Monitoring these logs helps detect unauthorized certificate issuance.
+
+**Why it matters**: Attackers sometimes obtain fake SSL certificates for legitimate domains to make phishing sites
+appear more credible. CT monitoring helps you detect these certificates before they're used in attacks.
+
+**Setup and tools**:
+
+- [crt.sh](https://crt.sh/) - Search and monitor CT logs for your domain
+- [Cert Spotter](https://sslmate.com/certspotter/) - Free CT monitoring with API access
+- Watch for wildcard certificates if you don't use them (could indicate broader compromise)
+
+## Passive DNS Monitoring
+
+Passive DNS monitoring tracks historical DNS resolution data across the internet, helping you detect brief changes that
+might be missed by periodic checks.
+
+**What it detects**:
+
+- **Brief record changes**: Attackers often make quick changes to avoid detection
+- **Geographic anomalies**: DNS records resolving to unexpected countries or regions
+- **Suspicious hosting provider changes**: Sudden switches to hosting providers known for malicious activity
+
+**Tools for passive DNS**:
+
+- [PassiveTotal (RiskIQ)](https://community.riskiq.com/) - Comprehensive passive DNS database
+- [Mnemonic Passive DNS](https://passivedns.mnemonic.no/) - Free passive DNS lookup
+- [SecurityTrails](https://securitytrails.com/) - Historical DNS and WHOIS data
+
+## Setting Up Alerts
+
+### Critical Alerts (Immediate Response Required)
+
+1. **Registrar Changed**
+
+   - **What it monitors**: Changes to your domain's registrar
+   - **Why it's critical**: Indicates potential domain hijacking or unauthorized transfer
+   - **Response**: Immediate verification and potential incident response activation
+
+2. **Nameserver Changed**
+
+   - **What it monitors**: Changes to nameserver records
+   - **Why it's critical**: Attackers often change nameservers to redirect traffic to malicious servers
+   - **Response**: Verify legitimacy, check if you initiated the change
+
+3. **DNSSEC Broken**
+
+   - **What it monitors**: DNSSEC validation failures or disabled DNSSEC
+   - **Why it's critical**: DNS responses can be tampered with, leading to man-in-the-middle attacks
+   - **Response**: Investigate signing issues, check for configuration changes
+
+4. **CAA Records Removed or Overridden**
+
+   - **What it monitors**: Removal of Certificate Authority Authorization records or child zone overrides
+   - **Why it's critical**: Allows any CA to issue certificates for your domain, enabling SSL certificate attacks
+   - **Response**: Restore CAA records immediately, investigate who removed them
+   - **Note**: Child zones override parent CAA; parameters like `accounturi` and `validationmethods` can provide finer control
+
+5. **Unexpected TTL Drops**
+
+   - **What it monitors**: Sudden TTL drops from higher values
+   - **Why it's important**: Can indicate preparation for rapid DNS changes (attack preparation)
+   - **Context**: Low TTL (30-300s) is normal for CDNs and auto-scaling; Cloudflare allows 30-60s for [unproxied records](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/)
+   - **Response**: Investigate *unexpected* drops or drops combined with other suspicious activity; verify if legitimate
+     infrastructure changes
+
+### High Priority Alerts (When NS Unchanged)
+
+1. **A Record Changed**
+
+   - **What it monitors**: IP redirects without NS changes
+   - **Why it's important**: Could redirect users to malicious servers
+   - **Response**: Verify the new IP address is legitimate and expected
+
+2. **MX Record Changed**
+
+   - **What it monitors**: Changes to mail server configurations
+   - **Why it's important**: Could intercept emails, including password reset messages
+   - **Response**: Verify mail server changes are authorized
+
+3. **DMARC Policy Weakened**
+
+   - **What it monitors**: Changes from "reject" to "quarantine" or "none"
+   - **Why it's important**: Weaker policies allow more spoofed emails to reach users
+   - **Response**: Investigate why policy was weakened, restore if unauthorized
+
+4. **Unexpected Certificate Issued**
+
+   - **What it monitors**: New SSL certificates issued for your domain
+   - **Why it's important**: Could indicate certificate-based attacks or unauthorized issuance
+   - **Response**: Verify the certificate was requested by your team, revoke if unauthorized
+
+## Incident Response Plan
+
+### Immediate Response
+
+1. **Verify the compromise** - Check DNS records via multiple resolvers
+2. **Access registrar account** - Attempt login, check for lockout
+3. **Contact registrar security team** - Use pre-documented emergency contacts
+4. **Document everything** - Screenshot all current settings
+
+### Containment
+
+1. **Invoke registry lock** if available
+2. **Update NS records** if you maintain access
+3. **Warn users** via social media/status page
+4. **Contact law enforcement** if significant theft occurred
+
+### Recovery
+
+1. **Regain control** through registrar security procedures
+2. **Audit all DNS records** against known-good baseline
+3. **Reset all credentials** for registrar and DNS hosting
+4. **Review access logs** to understand attack vector
+
+### Post-Incident
+
+1. **Conduct thorough investigation**
+2. **Update security measures** based on lessons learned
+3. **Consider legal action** if appropriate
+4. **Publish transparency report** to rebuild trust
+
+---
+
+---
+
+### PAGE: /secure-software-development/secure-code-repositories-version-control
+**Title:** Secure Code Repositories & Version Control | SEAL
+**Referenced by controls:** di-1.1.1, di-1.1.3, di-2.1.1, di-2.1.2, di-2.1.3, di-4.1.1, di-4.1.2, di-4.1.3
+
+# Secure Code Repositories and Version Control
+
+
+
+
+Managing secure code repositories and having version control practices helps protect your project from unauthorized
+access and ensuring the integrity of your project.
+
+## Best Practices for Secure Code Repositories
+
+1. **Access Control**
+   - Implement strict access controls to limit who can view, modify, and commit code.
+   - Use role-based access control (RBAC) to grant permissions based on the user's role within the organization.
+
+2. **Multi-Factor Authentication (MFA)**
+   - Require MFA for all users accessing the code repository to add an extra layer of security.
+   - Use hardware tokens or authentication apps for stronger security.
+
+3. **Branch Protection**
+   - Enable branch protection rules to prevent unauthorized changes to critical branches such as main/master.
+   - Require code reviews and approvals by another person before changes can be merged into the main/master branch.
+
+4. **Audit Logs**
+   - Enable audit logging to track all activities within the repository.
+   - Regularly review logs to detect any suspicious activities or unauthorized access attempts.
+
+## Secure Version Control Practices
+
+1. **Commit Signing**
+   - Require developers to sign their commits with GPG keys to verify the authenticity of the code changes.
+   - Enforce commit signing policies in the version control system.
+
+2. **Regular Backups**
+   - Regularly back up the code repository to prevent data loss.
+   - Store backups in a secure, offsite location.
+
+3. **Continuous Integration/Continuous Deployment (CI/CD)**
+   - Integrate security checks into the CI/CD pipeline to automatically scan code for vulnerabilities.
+   - Ensure that only tested and approved code is deployed to production.
+
+---
+
+---
+
+### PAGE: /supply-chain/supply-chain-levels-software-artifacts
+**Title:** Supply Chain Levels Software Artifacts | SEAL
+**Referenced by controls:** di-1.1.2, di-2.1.4
+
+# Supply Chain Levels for Software Artifacts
+
+
+
+
+Supply chain levels for software artifacts provide a framework for categorizing and securing software components based
+on their risk levels. This approach helps projects prioritize their security efforts towards software components with
+the highest risk levels.
+
+## Framework for Supply Chain Levels
+
+1. **Level 1: Critical Artifacts**
+   - These artifacts are essential to the core functionality of the software and pose a high risk if compromised.
+   - Examples: Core libraries.
+
+2. **Level 2: High-Risk Artifacts**
+   - Artifacts that are important but not critical. Their compromise could lead to significant security issues.
+   - Examples: Middleware, database connectors, oracles, authentication modules.
+
+3. **Level 3: Moderate-Risk Artifacts**
+   - Artifacts that are used frequently but have a lower risk profile. Their compromise could cause inconvenience but
+   not catastrophic failure.
+   - Examples: User interface libraries, utility functions, data processing modules.
+
+4. **Level 4: Low-Risk Artifacts**
+   - Artifacts that have minimal impact on security if compromised.
+   - Examples: Logging libraries, test utilities.
+
+## Best Practices for Securing Supply Chain Levels
+
+1. **Critical Artifacts**
+   - Implement strict access controls and require code reviews for all changes.
+   - Use robust security testing, including static and dynamic analysis.
+   - Monitor continuously for vulnerabilities and apply patches promptly.
+
+2. **High-Risk Artifacts**
+   - Enforce strong access controls and conduct regular security assessments.
+   - Perform regular updates and vulnerability scans.
+   - Implement automated security testing in CI/CD pipelines.
+
+3. **Moderate-Risk Artifacts**
+   - Apply standard security practices, including access controls and regular updates.
+   - Use automated tools to scan for vulnerabilities periodically.
+   - Ensure that dependencies are from trusted sources.
+
+4. **Low-Risk Artifacts**
+   - Follow basic security hygiene, such as using trusted sources and applying updates.
+   - Perform occasional security reviews and audits.
+
+---
+
+---
+
+### PAGE: /security-testing/unit-testing
+**Title:** Unit Testing
+**Referenced by controls:** di-1.1.2, di-2.1.3
+
+# Unit Testing
+
+
+
+
+Unit testing is the foundation of smart contract security testing. While fuzz tests can find edge cases and integration
+tests verify system interactions, unit tests ensure that individual functions behave correctly under expected
+conditions. Every smart contract should have comprehensive unit test coverage before moving to more advanced testing
+methodologies.
+
+## Overview
+
+Unit testing involves testing individual components or functions of your codebase in isolation. In smart contract
+development, this means testing each function with known inputs to verify expected outputs and state changes.
+
+**Why Unit Tests Matter for Security:**
+
+- Catch basic logic errors before they become vulnerabilities
+- Ensure access controls work as expected
+- Verify arithmetic operations don't have overflow/underflow issues
+- Document expected behavior for auditors and future developers
+- Provide a safety net when refactoring code
+
+## The Foundation of Security Testing
+
+As mentioned in your security testing strategy, unit testing should **always** be implemented with high code coverage.
+Think of unit tests as your first line of defense against bugs that could become security vulnerabilities.
+
+```solidity
+// Example: Simple token contract
+contract SimpleToken {
+    mapping(address => uint256) public balances;
+    uint256 public totalSupply;
+
+    function transfer(address to, uint256 amount) public {
+        require(balances[msg.sender] >= amount, "Insufficient balance");
+        require(to != address(0), "Cannot transfer to zero address");
+
+        balances[msg.sender] -= amount;
+        balances[to] += amount;
+    }
+}
+```
+
+## Writing Effective Unit Tests
+
+### Basic Unit Test Structure
+
+Here's how you'd test the transfer function above using Foundry:
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.0;
+
+
+
+
+contract SimpleTokenTest is Test {
+    SimpleToken token;
+    address alice = address(0x1);
+    address bob = address(0x2);
+
+    function setUp() public {
+        token = new SimpleToken();
+        // Give Alice some initial balance
+        vm.store(
+            address(token), 
+            keccak256(abi.encode(alice, 0)), // balances[alice] slot
+            bytes32(uint256(1000))
+        );
+        token.setTotalSupply(1000);
+    }
+
+    function testTransferSuccess() public {
+        vm.prank(alice);
+        token.transfer(bob, 100);
+
+        assertEq(token.balances(alice), 900);
+        assertEq(token.balances(bob), 100);
+    }
+
+    function testTransferFailsInsufficientBalance() public {
+        vm.prank(alice);
+        vm.expectRevert("Insufficient balance");
+        token.transfer(bob, 2000); // More than Alice has
+    }
+
+    function testTransferFailsZeroAddress() public {
+        vm.prank(alice);
+        vm.expectRevert("Cannot transfer to zero address");
+        token.transfer(address(0), 100);
+    }
+}
+```
+
+### Security-Focused Test Cases
+
+For each function, you should test:
+
+1. **Happy Path**: Normal expected usage
+2. **Edge Cases**: Boundary conditions (zero values, maximum values)
+3. **Access Control**: Who can and cannot call the function
+4. **Failure Cases**: Invalid inputs that should revert
+5. **State Changes**: Verify all expected state modifications occur
+
+### From Unit Test to Fuzz Test
+
+You can easily convert a unit test to a fuzz test:
+
+```solidity
+// Unit test
+function testTransferAmount() public {
+    uint256 amount = 100;
+    vm.prank(alice);
+    token.transfer(bob, amount);
+    assertEq(token.balances(bob), amount);
+}
+
+// Fuzz test version
+function testTransferAmountFuzz(uint256 amount) public {
+    amount = bound(amount, 0, 1000); // Bound to valid range
+    vm.prank(alice);
+    token.transfer(bob, amount);
+    assertEq(token.balances(bob), amount);
+}
+```
+
+## Mocking External Dependencies
+
+Unit tests should test your contract logic in isolation. When your contracts depend on external systems like oracles,
+other protocols, or complex state, you should mock these dependencies to create predictable, fast, and controlled test
+conditions.
+
+### Why Mock in Unit Tests?
+
+**Problems with real external dependencies in unit tests:**
+
+- **Slow**: Network calls and complex state slow down tests
+- **Unpredictable**: External state changes make tests non-deterministic
+- **Expensive**: RPC calls cost money and hit rate limits
+- **Complex**: Hard to test edge cases with real systems
+
+**Benefits of mocking:**
+
+- **Fast**: No network calls or complex state
+- **Predictable**: You control exactly what the mock returns
+- **Comprehensive**: Easy to test all edge cases and failure scenarios
+- **Isolated**: Test only YOUR contract logic, not external systems
+
+### Example Mock
+
+For example, if you are interacting with an ERC20 that has very odd functionality, an easier way to test working with it
+would be to make a mock of that contract.
+
+```solidity
+// SPDX-License-Identifier: UNLICENSED
+pragma solidity ^0.8.0;
+
+
+
+contract MockERC20 is ERC20 {
+    constructor(string memory name, string memory symbol)
+    ERC20(name, symbol) {}
+
+    function mint(address account, uint amount) external {
+        _mint(account, amount);
+    }
+}
+```
+
+Then, use that mock in your tests:
+
+```solidity
+
+contract MyContractTest is Test {
+    MockERC20 mockToken;
+
+    function setUp() public {
+        mockToken = new MockERC20("Mock Token", "MTK");
+        mockToken.mint(address(this), 1000); // Mint some tokens for testing
+    }
+}
+```
+
+### When NOT to Mock
+
+**Don't mock when:**
+
+- Testing the integration between YOUR contracts
+- The external dependency is simple and deterministic
+- You're specifically testing the interaction with the external system
+
+## Best Practices
+
+### 1. Achieve High Code Coverage
+
+Aim for 90%+ line coverage and 100% branch coverage on critical functions:
+
+```bash
+# Run coverage with Foundry
+forge coverage
+```
+
+### 2. Test All Access Controls
+
+```solidity
+function testOnlyOwnerCanMint() public {
+    vm.prank(alice); // Alice is not owner
+    vm.expectRevert("Ownable: caller is not the owner");
+    token.mint(alice, 100);
+
+    vm.prank(owner);
+    token.mint(alice, 100); // Should succeed
+    assertEq(token.balances(alice), 100);
+}
+```
+
+### 3. Test Arithmetic Operations
+
+```solidity
+function testNoOverflowOnMint() public {
+    // Set total supply to near max uint256
+    uint256 nearMaxSupply = type(uint256).max - 100;
+    token.setTotalSupply(nearMaxSupply);
+
+    vm.prank(owner);
+    vm.expectRevert(); // Should revert on overflow
+    token.mint(alice, 200);
+}
+```
+
+### 4. Use Descriptive Test Names
+
+```solidity
+function testTransferFailsWhenRecipientIsZeroAddress() public {
+    // Clear what this test does
+}
+
+function testMintIncreasesTotalSupplyAndRecipientBalance() public {
+    // Tests multiple related behaviors
+}
+```
+
+### 5. Arrange, Act, Assert Pattern
+
+```solidity
+function testTransfer() public {
+    // Arrange
+    uint256 initialBalance = 1000;
+    uint256 transferAmount = 100;
+
+    // Act
+    vm.prank(alice);
+    token.transfer(bob, transferAmount);
+
+    // Assert
+    assertEq(token.balances(alice), initialBalance - transferAmount);
+    assertEq(token.balances(bob), transferAmount);
+}
+```
+
+## Common Smart Contract Tools and Frameworks
+
+- [Foundry (Solidity)](https://github.com/foundry-rs/foundry):
+- [Hardhat (Solidity)](https://hardhat.org/)
+- [Moccasin (Vyper)](https://github.com/Cyfrin/moccasin)
+- [Anchor (Rust)](https://www.anchor-lang.com/docs)
+
+## References
+
+This document incorporates knowledge from:
+
+- [Cyfrin Updraft Security Testing Curriculum](https://updraft.cyfrin.io)
+
+---
+
+---
+
+### PAGE: /devsecops/integrated-development-environments
+**Title:** Securing Development Environments | SEAL
+**Referenced by controls:** di-1.1.3, di-1.1.4
+
+# Integrated Development Environments (IDEs)
+
+
+
+
+Integrated Development Environments (IDEs) are essential tools for developers, but they also need to be secured.
+Consider implementing the following best practices:
+
+1. Ensure IDEs are configured securely, with plugins and extensions only installed from trusted sources. Some IDEs have
+  features that allow for automated execution of files in folders. Use restricted mode if you don't fully trust a project.
+2. Keep IDEs and their plugins/extensions up-to-date to protect against vulnerabilities.
+3. Integrate static code analysis tools within the IDE to catch security issues early in the development process.
+4. Configure IDEs to follow the principle of least privilege, limiting access to sensitive information and systems.
+5. Ensure that potential development environments are isolated from production environments.
+
+---
+
+---
+
+### PAGE: /devsecops/overview
+**Title:** DevSecOps
+**Referenced by controls:** di-1.1.3, di-3.1.3
+
+# DevSecOps
+
+
+
+
+Traditionally, rapid development and deployment is often prioritized at the expense of security considerations. This is
+generally speaking no different in web3, but it is important to take integrity, confidentiality, and availability into
+consideration too. To effectively address this without compromising on rapid development and deployment, it is essential
+to integrate security into the process, which is where devsecops comes into play. By implementing devsecops, projects
+can not only deploy faster, but also be more secure.
+
+When operating in a devsecops mindset, projects prioritizes automation and collaboration between the development,
+operations and security teams.
+
+Some of the key areas to consider are:
+
+1. Integrate security measures early in the development process, such as by utilizing security tools such as fuzzing,
+  static and dynamic analysis tools in your CI/CD process, to identify and mitigate vulnerabilities before they turn into
+  critical issues.
+2. Implement automated security testing and monitoring.
+3. Development, Operations and Security teams should be aligned and work closely together.
+
+---
+
+---
+
+### PAGE: /security-automation/infrastructure-as-code
+**Title:** Infrastructure as Code Security | SEAL
+**Referenced by controls:** di-1.1.4, di-3.1.1, di-3.1.2, di-4.1.1
+
+# Infrastructure as Code
+
+
+
+
+Infrastructure as Code (IaC) is the managing and provisioning computing infrastructure through machine-readable
+definition files, rather than manual  configuration or interactive configuration tools. Automating security within IaC
+helps ensure that infrastructure is configured securely and consistently.
+
+## Benefits of Automating Security in IaC
+
+1. **Consistency**
+   - Ensures that infrastructure is provisioned and configured consistently across environments.
+   - Reduces the risk of configuration drift and security misconfigurations.
+
+2. **Scalability**
+   - Enables scalable deployment of secure infrastructure.
+   - Simplifies management of large-scale environments.
+
+3. **Version Control**
+   - Treats infrastructure configurations as code, allowing version control and change tracking.
+   - Facilitates rollback to previous configurations if issues arise.
+
+## Best Practices for Secure IaC
+
+1. **Use Trusted Modules**
+   - Use trusted and verified modules or templates for infrastructure provisioning.
+   - Avoid using unverified or outdated modules that may contain vulnerabilities.
+
+2. **Implement Least Privilege**
+   - Ensure that infrastructure components have the minimum necessary permissions.
+   - Use role-based access control (RBAC) to manage permissions.
+
+3. **Automate Security Scans**
+   - Integrate security scanning tools into the IaC pipeline to automatically detect and remediate vulnerabilities.
+   - Use tools like Checkov, tfsec, and Terrascan to scan Terraform configurations for security issues.
+
+4. **Encrypt Sensitive Data**
+   - Encrypt sensitive data at rest and in transit within the infrastructure.
+   - Use managed encryption services provided by cloud providers.
+
+5. **Regularly Update IaC Templates**
+   - Keep IaC templates and modules up to date with the latest security patches and best practices.
+   - Regularly review and update configurations to address new security threats.
+
+## Tools for Automating Security in IaC
+
+1. **Terraform**
+   - A widely used IaC tool that allows for the automated provisioning of infrastructure across various cloud providers.
+   - Supports integration with security scanning tools like tfsec and Checkov.
+
+2. **AWS CloudFormation**
+   - An IaC service provided by AWS for modeling and setting up AWS resources.
+   - Supports AWS Config rules for automated compliance checks.
+
+3. **Azure Resource Manager (ARM) Templates**
+   - IaC templates for deploying and managing Azure resources.
+   - Integrates with Azure Policy for enforcing security policies.
+
+4. **Ansible**
+   - An open-source automation tool for configuration management and application deployment.
+   - Supports security roles and playbooks for automating security configurations.
+
+---
+
+---
+
+### PAGE: /infrastructure/domain-and-dns-security/dnssec-and-email
+**Title:** DNSSEC, CAA, SMTP DANE and Email Security | SEAL
+**Referenced by controls:** di-1.1.4, di-4.1.4
+
+# DNSSEC, CAA, SMTP DANE and Email Security
+
+
+
+
+## DNSSEC Implementation
+
+DNSSEC (DNS Security Extensions) provides cryptographic authentication of DNS responses, preventing attackers from
+redirecting your users to malicious sites by tampering with DNS queries. Think of it as a digital signature that proves
+the DNS response came from the legitimate source.
+
+**How it protects you**: Without DNSSEC, attackers can intercept DNS queries and return fake IP addresses, redirecting
+users to malicious sites that look identical to yours. DNSSEC prevents this by cryptographically signing all DNS
+responses. While most client devices and many recursive resolvers do not perform DNSSEC validation on general DNS
+queries, DNSSEC is sometimes required and often preferred as a foundational component for security-sensitive internet
+protocols and features such as SMTP DANE, SSHFP, and CAA.
+
+**Preconditions**:
+
+- Domain is using the provider's nameservers
+- Registrar supports DS records
+- If registrar supports CDS/CDNSKEY auto-publish, enable that if offered
+
+**Practical setup**:
+
+1) **Enable signing at DNS provider**
+   - Turn on DNSSEC in the zone settings
+   - Provider generates KSK (Key Signing Key) and ZSK (Zone Signing Key), signs the zone, and shows DS parameters:
+     - **Key Tag**: Unique identifier for the key
+     - **Algorithm**: Common options:
+       - `13` (ECDSAP256SHA256) - Recommended
+       - `8` (RSASHA256)
+       - `15` (ECDSAP384SHA384)
+     - **Digest Type**:
+       - `2` (SHA-256) - Recommended for widest compatibility
+       - `4` (SHA-384)
+     - **Digest**: Hex string of the hash
+
+2) **Publish DS at registrar**
+   - Create a DS record with the exact four fields above
+   - Prefer Algorithm `13` (ECDSAP256SHA256) with Digest Type `2` (SHA-256) where supported
+   - If both digest types 2 and 4 are offered, pick 2 for the widest compatibility
+
+   Example registrar DS template:
+
+   ```
+   Owner: yourdomain.tld
+   Key Tag: 2371
+   Algorithm: 13
+   Digest Type: 2
+   Digest: 5C9F3E7B3F...A1C7
+   ```
+
+3) **Verify validation**
+   - Wait for registrar DS propagation (can take minutes to hours)
+   - Verify from a validating resolver using command-line tools:
+     - `dig +dnssec example.com A` (check for AD flag in response)
+     - `kdig +dnssec example.com A` (Knot DNS tool)
+     - `drill -D example.com A` (LDNS tool)
+   - For detailed analysis, use web tools:
+     - [Verisign DNSSEC Analyzer](https://dnssec-analyzer.verisignlabs.com/yourdomain.org)
+     - [DNSViz](https://dnsviz.net/d/yourdomain.org/analyze/)
+
+4) **Monitor validation and changes**
+   - Set up alerts for DS record changes at the registrar
+   - Monitor DNSSEC validation status regularly
+   - Watch for DNSKEY rollovers and ensure they complete successfully
+
+**Security notes**:
+
+- DNSSEC authenticates data; it does **not** encrypt queries. Use DoT (DNS over TLS) or DoH (DNS over HTTPS) for
+  transport privacy if needed.
+- Harden registrar accounts, protect transfer locks, and monitor for DS changes; DS removal downgrades protection.
+- A hijacked registrar account can remove DS records, eliminating DNSSEC protection
+- Add alerts on registrar activity to detect unauthorized changes
+
+## CAA Records
+
+Certificate Authority Authorization (CAA) records specify which Certificate Authorities (CAs) are allowed to issue SSL
+certificates for your domain. This prevents unauthorized certificate issuance, which attackers could use to create fake
+SSL certificates for your domain.
+
+**How it protects you**: Without CAA records, any Certificate Authority can issue SSL certificates for your domain.
+Attackers could potentially obtain fake certificates and use them in sophisticated phishing attacks that appear to have
+valid SSL encryption.
+A well behaved CA not explicitly permitted via CAA records will deny certificate requests for that domain. \
+While CA compromises are rare, history shows they do happen — and in such cases, attackers could potentially bypass
+or ignore CAA entirely. \
+Notable incidents include:
+
+- [DigiNotar (2011)](https://en.wikipedia.org/wiki/DigiNotar)
+- [Comodo (2011)](https://www.theregister.com/2011/03/28/comodo_gate_hacker_breaks_cover/) \
+Honorable mention, where it’s unclear whether CAA would have prevented the issue:
+- [Symantec Mis‑Issuance (2015–2017)](https://groups.google.com/a/chromium.org/g/blink-dev/c/eUAKwjihhBs/m/rpxMXjZHCQAJ)
+
+Before setting CAA records, identify which CA issued your current certificate:
+
+- **Command line**: `openssl s_client -connect yourdomain.com:443 -servername yourdomain.com | openssl x509 -noout -issuer`
+- **Web tools**: [SSL Labs Server Test](https://www.ssllabs.com/ssltest/) provides comprehensive certificate analysis
+  including issuer information
+- **Browser**: Click the padlock icon → Certificate details → Issuer information
+
+**Setup process**: Add CAA records to your DNS zone. Most DNS providers allow you to add these through their web interface:
+
+With the issuers full name in hand we now need to map it to the "Issuer Domain Name".
+There is no centralized repository mapping public CA's to their issuer domain names but they are generally easily found with
+a simple search for f.x. "Let's Encrypt CAA". \
+The Common CA Database also provides a
+[comprehensive collection to reference](https://ccadb.org/resources).
+
+```
+# Allow only specific CAs to issue certificates
+example.com. CAA 0 issue "letsencrypt.org"
+example.com. CAA 0 issue "digicert.com"
+
+# Send violation reports when unauthorized CAs attempt issuance
+example.com. CAA 0 iodef "mailto:security@example.com"
+
+# Control wildcard certificate issuance separately
+example.com. CAA 0 issuewild "letsencrypt.org"
+
+# Completely disable all certificate issuance (useful for non-web domains)
+example.com. CAA 0 issue ";"
+```
+
+## SMTP DANE
+
+DNS-based Authentication of Named Entities (DANE) is an email security protocol that relies on TLSA DNS
+records secured via DNSSEC. The TLSA record contains information on the MX and the certificate in use,
+allowing a secure connection to be made using that certificate.
+This prevents both MiTM and downgrade attacks. \
+DANE requires DNSSEC to be enabled on your domain - without it, TLSA records can be spoofed and offer no security benefit.
+
+If no record is found, SMTP DANE supporting clients will fall back to their usual connection flow.
+
+*While traditional PKI relies on trusted CAs, DANE allows domain owners to specify their own certificates,
+relying instead on DNSSEC to authenticate the certificate.*
+
+**Current industry support**: Of the major providers, Microsoft is the only one that currently supports
+SMTP DANE since its [RFC](https://datatracker.ietf.org/doc/html/rfc7672) was published in 2015. Notable
+smaller implementers include Comcast, Protonmail, Cisco, Fastmail, Posteo and Mailbox.org.
+
+**Implementation**: For those interested, a simple step-by-step tutorial can be found here for
+[Exchange Online](https://learn.microsoft.com/en-us/purview/how-smtp-dane-works#inbound-smtp-dane-with-dnssec).
+And for the brave, the Dutch Internet Standards Platform has published
+[detailed documentation](https://github.com/internetstandards/toolbox-wiki/blob/main/DANE-for-SMTP-how-to.md#reliable-certificate-rollover)
+on various aspects of supporting SMTP DANE on a self-hosted MX like postfix.
+
+**Example TLSA Record**:
+
+smtpdane.mx.microsoft. TLSA 900 "3 1 1 c495d9e40f7e625be22f83cc64305182ab0fe74232de30db8b218d09650cb0ea"
+
+- _25._tcp.smtpdane.mx.microsoft. → Host + port (SMTP uses 25/TCP)
+- TLSA → Record type for DANE
+- 900 → TTL in seconds
+- 3 1 1 →
+
+  - Usage 3 = Bind to end-entity cert
+  - Selector 1 = Public key info
+  - Match 1 = SHA-256 hash
+- Hex string → Hash of the MX certificate's public key
+
+**Further reading**:
+
+- [Microsoft SMTP DANE](https://learn.microsoft.com/en-us/purview/how-smtp-dane-works)
+- [RFC 7672](https://datatracker.ietf.org/doc/html/rfc7672)
+- [Google Cloud DNSSEC](https://docs.cloud.google.com/dns/docs/dnssec-advanced#tlsa) (only general docs, no
+  Google Mail support as of writing)
+
+## Email Security Configuration
+
+Email security records protect against email spoofing and phishing attacks. When your domain is compromised, attackers
+often change email settings to intercept password reset emails and other sensitive communications.
+
+### SPF (Sender Policy Framework)
+
+SPF records specify which mail servers are authorized to send emails on behalf of your domain. This prevents attackers
+from spoofing your domain in phishing emails.
+
+**How it protects you**: Without SPF, anyone can send emails claiming to be from your domain. Attackers use this for
+sophisticated phishing campaigns that appear to come from your legitimate email address.
+
+This is particularly dangerous as attackers can impersonate executives or team members to target your own organization
+and users - imagine receiving a "urgent wire transfer" request from your CFO's email address, or your users getting a
+"mandatory wallet update" from your official support email.
+
+**Setup**: Add an SPF record to your DNS zone:
+
+```
+example.com. TXT "v=spf1 include:_spf.google.com ~all"
+```
+
+### DKIM (DomainKeys Identified Mail)
+
+DKIM adds a digital signature to your emails, allowing receiving servers to verify that emails actually came from your
+domain and haven't been tampered with.
+
+**How it protects you**: DKIM signatures prove email authenticity and integrity, making it much harder for attackers to
+successfully spoof your domain in phishing campaigns.
+
+**Setup**: Configure with your email provider and publish public keys in DNS (your email provider will provide the
+specific records).
+
+### MTA-STS (Mail Transfer Agent Strict Transport Security)
+
+MTA-STS enforces encrypted connections between mail servers, preventing man-in-the-middle attacks on email transmission.
+
+**How it protects you**: Without MTA-STS, emails can be intercepted in transit. This is especially critical for password
+reset emails and other sensitive communications.
+
+**Deployment steps**:
+
+1) **Create the MTA-STS policy file**
+
+   Host a plain text file at: `https://mta-sts.<domain>/.well-known/mta-sts.txt`
+
+   Policy file structure:
+
+   ```
+   version: STSv1
+   mode: testing
+   mx: smtp.example.com
+   mx: alt1.smtp.example.com
+   max_age: 86400
+   ```
+
+   **Mode options**:
+
+   - `testing` - Monitor TLS failures but don't block mail (recommended to start)
+   - `enforce` - Require TLS for mail delivery
+   - `none` - Disable policy
+
+   **Important**: List all your MX servers. Ensure they have valid TLS certificates matching their hostnames.
+
+2) **Host the policy file over HTTPS**
+
+   The file must be:
+   - Publicly accessible at the exact path
+   - Served over HTTPS with a valid certificate
+   - Available 24/7 (use reliable hosting)
+
+3) **Publish DNS TXT record**
+
+   Create a TXT record at `_mta-sts.<domain>`:
+
+   ```
+   _mta-sts.example.com. TXT "v=STSv1; id=20250101000000"
+   ```
+
+   The `id` value (often a timestamp or version) signals mail servers to fetch the latest policy. Update it whenever you
+   change the policy file.
+
+4) **Testing and enforcement**
+   - Start with `mode: testing` to monitor without blocking
+   - Collect and review TLS failure reports
+   - Once confident, change to `mode: enforce`
+   - Update the `id` in DNS TXT record after policy changes
+
+**Provider-specific tips**:
+
+- **Google Workspace**: Manage MX in Admin console; host policy yourself; add TXT via DNS
+- **Cloudflare**: Host policy on Workers/Pages; manage TXT in DNS; HTTPS auto via Cloudflare SSL
+- **Amazon SES**: Host on S3 or CloudFront; manage TXT in Route 53; ensure domains are verified
+
+**Security notes**:
+
+- `max_age` determines how long mail servers cache the policy (86400 = 1 day)
+- All MX servers must support TLS with valid certificates
+- Monitor policy file availability - if unreachable, mail delivery may fail in enforce mode
+
+### DMARC (Domain-based Message Authentication)
+
+DMARC builds on SPF and DKIM to provide policy enforcement for email authentication. It tells receiving mail servers
+what to do with emails that fail authentication checks.
+
+**How it protects you**: DMARC prevents email spoofing by instructing receiving servers to reject or quarantine emails
+that fail authentication, protecting your users from phishing attacks.
+Without it, emails breaking SPF/DKIM may still be delivered by some providers (like Gmail, Outlook), often to the
+inbox or spam folder, sometimes with a warning banner (e.g., "This message may not be from…")
+DMARC also enables aggregate (rua) and forensic (ruf) reporting, giving domain owners visibility into who is sending
+email on their behalf - legitimate or otherwise.
+
+**Setup**: Add a DMARC record to your DNS zone:
+
+**Baseline example (aggregate reports only)**:
+
+```
+_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
+```
+
+**Report types**:
+
+- **`rua=`** (Aggregate reports): Daily summaries of authentication results. This is the baseline and widely supported.
+- **`ruf=`** (Failure reports): Real-time forensic reports for individual failures. Not recommended as they are:
+  - Not widely supported by mail providers
+  - Raise privacy concerns (contain message content/headers)
+  - May not deliver reliably
+  - Often unnecessary for monitoring purposes
+
+**Recommendation**: Start with aggregate reports only (`rua=`). They provide sufficient visibility into authentication
+issues without the privacy and reliability concerns of failure reports.
+
+---
+
+---
+
+### PAGE: /secure-software-development/code-reviews-peer-audits
+**Title:** Code Reviews & Peer Audits
+**Referenced by controls:** di-2.1.1
+
+# Code Reviews and Peer Audits
+
+
+
+
+Code reviews and peer audits help identifying and mitigating security vulnerabilities in software. They involve
+systematically examining code to ensure it adheres to the security standards and best practices of the project.
+
+## Best Practices for Code Reviews
+
+1. **Regular Reviews**
+   - Conduct code reviews regularly to identify and fix security vulnerabilities early in the development process.
+   - Integrate code reviews into the development workflow to make them a routine part of the process.
+
+2. **Review Checklists**
+   - Use review checklists to ensure that all security aspects are covered during the review.
+   - Checklists should include common security issues such as input validation, error handling, and authentication.
+
+3. **Automated Tools**
+   - Use automated code analysis tools to assist in identifying potential security vulnerabilities.
+   - Tools like SonarQube, Checkmarx, and Snyk can help in detecting issues that might be missed during manual reviews.
+
+4. **Peer Audits**
+   - Encourage peer audits where team members review each other's code.
+   - Peer audits provide a fresh perspective and can help identify issues that the original developer might overlook.
+
+## Conducting Effective Code Reviews
+
+1. **Focus on Security**
+   - Prioritize security issues during code reviews.
+   - Ensure that code follows secure coding standards and guidelines.
+
+2. **Collaborative Approach**
+   - Foster a collaborative environment where reviewers and developers work together to improve code quality.
+   - Provide constructive feedback and encourage open communication.
+
+3. **Document Findings**
+   - Document all findings from code reviews and track their resolution.
+   - Use issue tracking systems to manage identified vulnerabilities and ensure they are addressed.
+
+4. **Continuous Improvement**
+   - Continuously improve the code review process based on feedback and lessons learned.
+   - Regularly update review checklists and practices to keep up with evolving security threats.
+
+---
+
+---
+
+### PAGE: /devsecops/continuous-integration-continuous-deployment
+**Title:** Securing CI/CD Pipelines | SEAL
+**Referenced by controls:** di-2.1.2, di-3.1.1, di-3.1.3
+
+# Continuous Integration and Continuous Deployment (CI/CD)
+
+
+
+
+Continuous Integration and Continuous Deployment are there to ensure good code quality and create rapid and secure
+deployments. Some best practices are:
+
+1. Ensure every PR undergoes CI testing (e.g., GitHub Actions) that must pass before merging. CI tests should at least
+  include unit tests, integration tests, and checks for known vulnerabilities in dependencies.
+2. The CI/CD pipeline should check for misconfigurations and leaked credentials.
+3. Produce deterministic builds with a strict set of dependencies and/or a build container that can reliably produce the
+  same results on different machines.
+4. Integrate security scanning tools to detect vulnerabilities in code and dependencies during the CI process.
+5. Use isolated environments for building and testing to prevent contamination between different stages of the pipeline.
+6. Implement strict access controls for CI/CD pipelines to limit who can modify the pipeline configurations.
+
+---
+
+---
+
+### PAGE: /supply-chain/dependency-awareness
+**Title:** Dependency Awareness
+**Referenced by controls:** di-2.1.4
+
+# Dependency Awareness
+
+
+
+
+Dependency awareness is the practice of understanding and managing all the external libraries, frameworks, and
+components that a software project relies on. Dependencies can introduce vulnerabilities and risks, which means it's
+important to keep track of them and ensure they are secure.
+
+## Importance of Dependency Awareness
+
+1. **Security Risks**
+   - Dependencies can contain vulnerabilities that may be exploited by threat actors.
+
+2. **Compliance**
+   - Ensuring that dependencies comply with licensing and regulatory requirements is essential to avoid legal issues.
+
+3. **Maintainability**
+   - Understanding dependencies and their impact on the project will help understand if it's possible to update a
+   dependency used by your application.
+
+## Best Practices for Dependency Awareness
+
+1. **Use Dependency Management Tools**
+   - Leverage tools that can automatically track and manage dependencies. Examples include:
+     - **Web2:**
+       - **Snyk:** Monitors and fixes vulnerabilities in dependencies.
+       - **Dependabot:** Automatically updates dependencies in GitHub projects.
+     - **Solidity:**
+       - **Ethlint:** Analyzes and lints Solidity code, including dependencies.
+       - **MythX:** Scans for vulnerabilities in smart contract dependencies.
+
+2. **Regularly Update Dependencies**
+   - Regularly update dependencies to the latest secure versions after verifying them.
+
+3. **Monitor for Vulnerabilities**
+   - Continuously monitor dependencies for known vulnerabilities using tools like Snyk, npm audit, and GitHub Security
+   Alerts.
+
+4. **Audit Dependencies**
+   - Perform regular audits of dependencies to ensure they are necessary and secure. Remove unused or outdated
+   dependencies.
+
+5. **Use Trusted Sources**
+   - Only use dependencies from trusted and reputable sources. Avoid using unverified or poorly maintained libraries.
+
+---
+
+---
+
+### PAGE: /security-automation/compliance-checks
+**Title:** Automated Compliance Checks
+**Referenced by controls:** di-3.1.2
+
+# Compliance Checks
+
+
+
+
+Automating compliance checks helps projects ensure that they adhere to security policies, standards, and potential
+regulatory requirements consistently. Automated compliance tools can continuously monitor, assess, and report on the
+compliance status of systems and applications.
+
+## Benefits of Automated Compliance Checks
+
+1. **Continuous Monitoring**
+   - Automated tools provide continuous monitoring of systems to ensure ongoing compliance.
+   - Reduces the risk of non-compliance due to configuration drift or changes.
+
+2. **Efficiency**
+   - Automates repetitive compliance tasks, freeing up security teams to focus on more strategic activities.
+   - Speeds up the compliance assessment process.
+
+3. **Accuracy**
+   - Reduces human error in compliance assessments.
+   - Provides consistent and repeatable compliance checks.
+
+## Tools for Automated Compliance Checks
+
+1. **AWS Config**
+   - A service that continuously monitors and records AWS resource configurations and allows automated compliance checks
+   based on predefined rules.
+   - Pros: Deep integration with AWS services, customizable rules.
+   - Cons: Limited to AWS environments.
+
+2. **Azure Policy**
+   - A service that enables the creation, assignment, and management of policies to enforce organizational standards and
+   assess compliance at-scale.
+   - Pros: Integrated with Azure services, supports custom policies.
+   - Cons: Limited to Azure environments.
+
+3. **HashiCorp Sentinel**
+   - A policy-as-code framework for defining and enforcing policies across infrastructure as code and cloud
+   environments.
+   - Pros: Flexible and extensible, integrates with Terraform and other HashiCorp tools.
+   - Cons: Requires knowledge of policy language.
+
+4. **OpenSCAP**
+   - An open-source tool for implementing and enforcing security policies and compliance checks.
+   - Pros: Supports various compliance frameworks (e.g., NIST, CIS), open-source.
+   - Cons: Requires configuration and management.
+
+## Best Practices
+
+1. Integrate compliance checks into the CI/CD pipeline to ensure that code changes and deployments comply with security
+policies.
+
+---
+
+---
+
+### PAGE: /devsecops/security-testing
+**Title:** Security Testing
+**Referenced by controls:** di-3.1.3
+
+# Security Testing
+
+
+
+
+Security testing is a crucial part of the DevSecOps process, as it helps identify vulnerabilities early on so that they
+can be taken care of before they become an issue in production.
+
+1. Integrate SAST tools into the CI/CD pipeline to analyze source code for vulnerabilities.
+2. Use DAST tools to test running applications for security issues.
+3. Combine SAST and DAST approaches with IAST tools for comprehensive security testing.
+4. Implement fuzz testing to discover security vulnerabilities by inputting random data.
+
+---
+
+---
+
+### PAGE: /infrastructure/cloud
+**Title:** Cloud Infrastructure
+**Referenced by controls:** di-4.1.3, di-4.1.4
+
+# Cloud Infrastructure
+
+
+
+
+Securing your cloud infrastructure could be considered as important as securing your decentralized application, as a lot
+of users will be interacting with your dapp through the cloud provider. Some best practices to consider are:
+
+1. Implement strict access controls and identity management to ensure that only authorized individuals can interact with
+cloud resources. Use role-based access control (RBAC) and multi-factor authentication (MFA).
+2. Encrypt data both in transit and at rest. Use managed encryption keys or bring your own keys (BYOK) for enhanced
+security.
+3. Configure virtual private clouds (VPCs), implement firewalls, and monitor network traffic to protect against
+unauthorized access and threats.
+4. Set up comprehensive logging, monitoring, and threat detection systems to identify and respond to security incidents
+in real-time. Use services like AWS CloudTrail, Azure Monitor, and Google Cloud Logging.
+5. Implement high availability, data backup, and disaster recovery plans to protect against service disruptions. Use
+automated fail-over and replication strategies.
+6. Ensure compliance with regulatory requirements (e.g., GDPR, MiCA).
+
+## Cloud Provider Hardening Guides
+
+All cloud providers have hardening guides that provide step-by-step instructions and best practices for securing cloud
+infrastructure:
+
+- **AWS**: [Security, Identity, and Compliance](https://aws.amazon.com/architecture/security-identity-compliance/)
+- **Azure**:
+[Best Practices and Patterns](https://learn.microsoft.com/en-us/azure/security/fundamentals/best-practices-and-patterns)
+- **GCP**: [Security Best Practices](https://cloud.google.com/security/best-practices)
+
+## Open Source Tools
+
+To aid with vulnerability detection and compliance, you could consider using the following open-source tools:
+
+- **CloudSploit**: [CloudSploit](https://github.com/aquasecurity/cloudsploit)
+- **Prowler**: [Prowler](https://github.com/prowler-cloud/prowler)
+- **S3Scanner (AWS)**: [S3Scanner](https://github.com/sa7mon/S3Scanner)
+- **Zeus (AWS)**: [Zeus](https://github.com/DenizParlak/Zeus)
+
+---
+
+---
+
diff --git a/scripts/data/eval-briefs/sfc-dns-registrar.md b/scripts/data/eval-briefs/sfc-dns-registrar.md
new file mode 100644
index 00000000..fedc9017
--- /dev/null
+++ b/scripts/data/eval-briefs/sfc-dns-registrar.md
@@ -0,0 +1,2099 @@
+# Evaluation Brief: sfc-dns-registrar
+
+## TASK
+
+For each control below, evaluate whether the candidate framework pages ACTUALLY meet the baseline requirements.
+A page must SUBSTANTIVELY address the baseline — not just mention related keywords.
+Be strict: if a baseline says "reviewed at least annually" and the page doesn't mention review cadence, that baseline is NOT met.
+
+## CONTROLS (16 total)
+
+### dns-1.1.1: Domain Security Owner
+**Question:** Is there a clearly designated person or team accountable for domain security?
+**Baselines (1):**
+  1. Accountability scope covers policy maintenance, security reviews, renewal management, access control oversight, and incident escalation
+**Candidate pages:** /opsec/core-concepts/security-fundamentals, /opsec/principles/principles, /infrastructure/domain-and-dns-security/registrar-and-locks
+
+### dns-1.1.2: Domain Inventory and Documentation
+**Question:** Do you maintain a complete, current record of all your domains and their configurations?
+**Baselines (2):**
+  1. Registry includes domain name, ownership, purpose, expiration date, registrar, DNS record configurations, security settings (DNSSEC, CAA), and registrar account configurations
+  2. Accessible to relevant team members
+**Candidate pages:** /infrastructure/domain-and-dns-security/registrar-and-locks, /infrastructure/domain-and-dns-security/dnssec-and-email, /infrastructure/domain-and-dns-security/monitoring-and-alerting
+
+### dns-2.1.1: Domain Classification and Compliance
+**Question:** Do you classify your domains by risk level and verify they meet the security requirements for their classification?
+**Baselines (4):**
+  1. Classification considers criticality, financial exposure, and operational impact
+  2. Domains where users may transact funds or that are external-facing classified at the highest tier
+  3. Each classification maps to specific security requirements (DNSSEC, locks, monitoring frequency, access controls)
+  4. Compliance verified at least annually through configuration review against documented standards
+**Candidate pages:** /infrastructure/domain-and-dns-security/dnssec-and-email, /infrastructure/domain-and-dns-security/monitoring-and-alerting, /opsec/core-concepts/security-fundamentals
+
+### dns-2.1.2: Enterprise Registrar Security Requirements
+**Question:** Do you use a registrar with enterprise-grade security for your critical domains?
+**Baselines (4):**
+  1. Registrar supports registry locks (server-level EPP locks)
+  2. Registrar supports hardware security key MFA (FIDO2/WebAuthn)
+  3. Registrar has no history of social engineering vulnerabilities
+  4. Due diligence includes checking ICANN compliance notices for the registrar
+**Candidate pages:** /infrastructure/domain-and-dns-security/registrar-and-locks, /infrastructure/domain-and-dns-security/dnssec-and-email, /infrastructure/domain-and-dns-security/monitoring-and-alerting
+
+### dns-3.1.1: Registrar Access Control
+**Question:** Do you control and secure access to domain registrar and DNS management accounts?
+**Baselines (4):**
+  1. Documented who is authorized, how access is granted/revoked, and role-based permissions where available
+  2. Hardware security key MFA (FIDO2/WebAuthn) required for all registrar and DNS management accounts
+  3. Access reviews conducted at least annually
+  4. Access revoked promptly when no longer needed
+**Candidate pages:** /infrastructure/domain-and-dns-security/registrar-and-locks, /infrastructure/domain-and-dns-security/monitoring-and-alerting, /infrastructure/domain-and-dns-security/dnssec-and-email
+
+### dns-3.1.2: Dedicated Domain Security Contact Email
+**Question:** Is your domain security contact email independent of the domains it protects?
+**Baselines (4):**
+  1. Hosted on a different domain than any domain it's responsible for
+  2. Not a personal email address
+  3. Used exclusively for domain security purposes
+  4. Alias that notifies multiple people
+**Candidate pages:** /infrastructure/domain-and-dns-security/registrar-and-locks, /infrastructure/domain-and-dns-security/dnssec-and-email, /opsec/travel/guide
+
+### dns-3.1.3: Change Management for Domain Operations
+**Question:** Do you have change management procedures for critical domain operations?
+**Baselines (4):**
+  1. Covers transfers, deletions, nameserver changes, and DNS record modifications
+  2. Relevant team members notified before critical changes
+  3. All changes logged
+  4. Critical changes verified through out-of-band confirmation with the registrar
+**Candidate pages:** /infrastructure/domain-and-dns-security/registrar-and-locks, /infrastructure/domain-and-dns-security/monitoring-and-alerting, /infrastructure/domain-and-dns-security/dnssec-and-email
+
+### dns-4.1.1: DNS Security Standards
+**Question:** Do you enforce DNS security standards across all your domains?
+**Baselines (4):**
+  1. DNSSEC enabled and validated on all critical domains
+  2. CAA records configured to restrict certificate issuance to authorized CAs only
+  3. TTL policies documented with rationale
+  4. Standards applied consistently based on domain classification
+**Candidate pages:** /infrastructure/domain-and-dns-security/dnssec-and-email, /infrastructure/domain-and-dns-security/monitoring-and-alerting, /infrastructure/domain-and-dns-security/overview
+
+### dns-4.1.2: Email Authentication Standards
+**Question:** Do you enforce email authentication standards and monitor for violations?
+**Baselines (5):**
+  1. SPF, DKIM, and DMARC configured for all domains that send email
+  2. DMARC policy set to reject for domains actively sending email
+  3. DMARC aggregate reports (rua) monitored and reviewed
+  4. MTA-STS configured where supported to enforce encrypted email transport
+  5. Domains that don't send email have SPF/DMARC records that reject all email
+**Candidate pages:** /infrastructure/domain-and-dns-security/dnssec-and-email, /infrastructure/domain-and-dns-security/monitoring-and-alerting, /opsec/google/overview
+
+### dns-4.1.3: Domain Lock Implementation
+**Question:** Do you use domain locks to prevent unauthorized transfers and changes?
+**Baselines (3):**
+  1. Registry locks (server-level EPP locks) enabled for all critical domains where supported
+  2. Transfer locks enabled on all domains
+  3. Lock status verified periodically
+**Candidate pages:** /infrastructure/domain-and-dns-security/registrar-and-locks, /opsec/travel/guide, /infrastructure/domain-and-dns-security/dnssec-and-email
+
+### dns-4.1.4: TLS Certificate Lifecycle Management
+**Question:** Do you manage the full lifecycle of your TLS certificates?
+**Baselines (4):**
+  1. Covers issuance, renewal, and revocation procedures
+  2. Certificates tracked with expiration alerts
+  3. Automated renewal where possible
+  4. Revocation procedures documented for compromised certificates
+**Candidate pages:** /infrastructure/domain-and-dns-security/monitoring-and-alerting, /infrastructure/domain-and-dns-security/dnssec-and-email, /infrastructure/domain-and-dns-security/registrar-and-locks
+
+### dns-5.1.1: Domain and DNS Monitoring
+**Question:** Do you monitor your domains for unauthorized changes to DNS records, registration status, and security settings?
+**Baselines (5):**
+  1. DNS record monitoring covers nameserver (NS) changes, A/AAAA changes, MX changes, TXT/SPF/DMARC changes, CAA record removal, DNSSEC status changes, and unexpected TTL drops
+  2. Registration monitoring covers lock status, registrar account settings, and nameserver delegation
+  3. Alerting and escalation paths documented
+  4. Critical alerts (nameserver changes, DNSSEC failure, registrar changes) trigger immediate investigation
+  5. Monitoring infrastructure not dependent on the domains being monitored
+**Candidate pages:** /infrastructure/domain-and-dns-security/dnssec-and-email, /infrastructure/domain-and-dns-security/monitoring-and-alerting, /infrastructure/domain-and-dns-security/registrar-and-locks
+
+### dns-5.1.2: Certificate Transparency Monitoring
+**Question:** Do you monitor Certificate Transparency logs for unauthorized certificates issued for your domains?
+**Baselines (3):**
+  1. Subscribed to a CT monitoring service that alerts on new certificate issuance
+  2. Alerts reviewed and unauthorized certificates investigated promptly
+  3. Wildcard certificates flagged if not expected
+**Candidate pages:** /infrastructure/domain-and-dns-security/monitoring-and-alerting, /opsec/core-concepts/security-fundamentals, /infrastructure/domain-and-dns-security/dnssec-and-email
+
+### dns-5.1.3: Domain Expiration Prevention
+**Question:** Do you actively prevent domain expiration?
+**Baselines (4):**
+  1. Auto-renewal enabled on all domains
+  2. Calendar reminders at 90, 60, 30, and 7 days before expiration
+  3. Payment methods verified current
+  4. Backup person designated for renewal responsibility
+**Candidate pages:** /opsec/travel/guide, /opsec/control-domains/technical, /infrastructure/domain-and-dns-security/registrar-and-locks
+
+### dns-6.1.1: Alerting and Emergency Contacts
+**Question:** Do you have alerting and emergency contacts in place for domain security incidents?
+**Baselines (3):**
+  1. Alerting system in place to notify relevant stakeholders when a potential compromise is detected
+  2. Emergency contacts pre-documented including registrar security team, SEAL 911, and legal counsel
+  3. Communication plan for warning users (status page, social media, in-app warnings)
+**Candidate pages:** /infrastructure/domain-and-dns-security/registrar-and-locks, /opsec/travel/guide, /infrastructure/domain-and-dns-security/monitoring-and-alerting
+
+### dns-6.1.2: Domain Incident Response Plan
+**Question:** Do you have an incident response plan for domain hijacking and DNS compromise?
+**Baselines (5):**
+  1. Covers key scenarios including registrar account compromise, DNS hijacking, and unauthorized transfers
+  2. Emergency registry lock activation procedures
+  3. Procedures for regaining control of compromised domains
+  4. Post-recovery validation including DNS records verified against known-good baseline, all credentials reset, and access logs reviewed
+  5. Plan tested at least annually (can be combined with broader IR drills)
+**Candidate pages:** /infrastructure/domain-and-dns-security/registrar-and-locks, /infrastructure/domain-and-dns-security/monitoring-and-alerting, /opsec/travel/guide
+
+---
+
+## FRAMEWORK PAGES (9 unique)
+
+### PAGE: /opsec/core-concepts/security-fundamentals
+**Title:** Security Fundamentals
+**Referenced by controls:** dns-1.1.1, dns-2.1.1, dns-5.1.2
+
+# Security Fundamentals
+
+
+
+
+> 🔑 **Key Takeaway**: Effective security operations are built on five practical fundamentals: layered protective
+> measures, minimized access scopes, controlled information flows, system isolation, and continuous visibility — working
+> together to secure critical assets in dynamic environments.
+
+## Relationship to Implementation Process
+
+This document outlines the foundational security approaches that should be embedded throughout your organization's
+operations. They complement the practical
+[Operational Implementation Process](/opsec/core-concepts/implementation-process),
+which defines specific action steps:
+
+- These fundamentals establish **enduring approaches** that shape your security architecture
+- The implementation process provides a **sequential workflow** for security teams to follow
+
+While these fundamentals provide the security principles that should be consistently applied across your environment,
+the implementation process offers a structured methodology for putting security into practice. Both elements must work
+in concert - these fundamentals guide your overall approach, while the implementation process provides the tactical
+roadmap.
+
+For organizations just beginning their security journey, start with the
+[Operational Implementation Process](/opsec/core-concepts/implementation-process) for concrete steps.
+
+The ultimate goal is to prevent unauthorized access to systems and information that could cause operational, financial,
+or reputational harm if compromised.
+
+> **Practical Example: Web3 Organization**
+>
+> Consider a Web3 project managing a DeFi protocol with a treasury of $10M in assets. Practical security fundamentals in
+> action include:
+>
+> - **Layered protection**: Hardware security modules for key storage, multi-signature requirements (3-of-5) for
+> transactions, automated monitoring for unusual patterns, and regular third-party security audits
+> - **Minimal access scopes**: Deployment keys accessible only to specific DevOps team members, with different
+> permission levels strictly enforced between development, staging, and production environments
+> - **Information flow control**: Private keys for multi-signature wallets distributed among trusted team members based
+> on role, with sensitive incident response procedures restricted to the security team
+> - **System isolation**: Clear separation between development environments and production systems, with treasury
+> management isolated from day-to-day operations
+> - **Continuous visibility**: Real-time monitoring systems tracking transaction patterns, weekly security reviews, and
+> quarterly penetration tests with findings addressed in prioritized sprints
+
+## 1. Layered Protection
+
+Implement multiple overlapping security controls so that if one mechanism fails, others will continue to protect your
+assets.
+
+> **🔗 Related Framework:** This approach is reinforced in frameworks like [Infrastructure](/infrastructure/overview)
+> with [Zero-Trust Principles](/infrastructure/zero-trust-principles) and
+> [Network Security](/infrastructure/network-security).
+
+### Practical Application
+
+1. Implement multiple defensive mechanisms that protect against the same risks using different methods
+   - Example: Protect admin interfaces using network ACLs, MFA, time-limited access windows, and anomaly detection
+2. Deploy protection at each layer of your technology stack
+   - Network layer: Firewalls, network segmentation, DDoS protection
+   - Host layer: Endpoint protection, host-based IDS, secure configuration
+   - Application layer: Input validation, output encoding, API security
+   - Data layer: Encryption, access controls, data loss prevention
+3. Identify and eliminate single points of failure in your security architecture
+   - Map defense coverage to ensure overlapping protections
+   - Document security dependencies and create contingency plans
+4. Test defensive layers regularly through realistic scenarios
+   - Conduct tabletop exercises focused on specific defensive failures
+   - Use red team exercises to validate defense-in-depth effectiveness
+5. Maintain a continuous improvement cycle for each defensive layer
+   - Review and update security controls after incidents or near-misses
+   - Track industry developments to identify emerging defensive tactics
+
+## 2. Minimal Access Scopes
+
+Grant users, systems, and processes only the specific permissions they need to perform their required functions and
+nothing more.
+
+> **🔗 Related Framework:** For detailed implementation, see [Identity and Access Management](/iam/overview) and
+> [Role-Based Access Control](/iam/role-based-access-control).
+
+### Practical Application
+
+1. Implement a structured permission model that starts with zero access
+   - Default deny: Require explicit permission grants for all access
+   - Document justification for each permission granted
+   - Create standardized role templates for common job functions
+2. Establish automated processes for access lifecycle management
+   - Onboarding: Provision minimal initial access based on role
+   - Role changes: Adjust permissions when responsibilities change
+   - Offboarding: Remove all access immediately upon departure
+3. Apply time-based restrictions to elevated privileges
+   - Use just-in-time access for administrative functions
+   - Implement automatic session termination after periods of inactivity
+   - Require re-authentication for sensitive operations
+4. Conduct regular access reviews with verification
+   - Quarterly: Review all privileged accounts and service accounts
+   - Semi-annually: Audit all standard user accounts and group memberships
+   - Use automated tools to identify inactive or excessive permissions
+5. Implement technical controls to enforce minimal access
+   - Application permissions: API scopes, feature flags, entitlement checks
+   - Infrastructure permissions: IAM policies, network ACLs, resource policies
+   - Database permissions: Row-level security, column-level controls
+
+## 3. Information Flow Control
+
+Ensure sensitive information is only accessible to those with a legitimate need to know, with restrictions on how that
+information can be shared and used.
+
+{/* > **🔗 Related Framework:** This approach is supported by practices in [Data
+Protection](/opsec/old/data-protection/overview) and aspects of [Privacy](/privacy/overview). */}
+
+### Practical Application
+
+1. Implement a practical data classification system with clear handling requirements
+   - Public: Information approved for general distribution
+   - Internal: Business information for employee use only
+   - Confidential: Sensitive information requiring specific protections
+   - Restricted: Critical information with strictly controlled access
+2. Define and enforce data handling procedures for each classification level
+   - Storage requirements: Where information can be stored
+   - Transmission rules: How information can be sent/shared
+   - Processing restrictions: How information can be used
+   - Retention limits: How long information should be kept
+3. Deploy technical controls to enforce information flow policies
+   - Data loss prevention tools to monitor and block unauthorized sharing
+   - Encryption for data at rest and in transit based on sensitivity
+   - Information rights management for persistent protection
+4. Establish secure channels for different types of communication
+   - High-sensitivity: End-to-end encrypted messaging with disappearing messages
+   - Medium-sensitivity: Encrypted collaboration platforms with access controls
+   - Low-sensitivity: Standard business communication tools
+5. Train users on practical information handling procedures
+   - Provide clear guidelines with concrete examples
+   - Use realistic scenarios in training materials
+   - Conduct periodic verification checks
+
+## 4. System Isolation
+
+Segment systems and networks into isolated zones to contain security breaches and limit lateral movement.
+
+### Practical Application
+
+1. Implement network segmentation based on security requirements
+   - Create security zones with consistent trust levels
+   - Implement strict traffic control between zones
+   - Document and regularly review allowed communication paths
+2. Establish environment separation with controlled boundaries
+   - Maintain distinct development, testing, staging, and production environments
+   - Implement one-way data flows from higher to lower environments
+   - Control code promotion processes between environments
+3. Isolate high-value systems with enhanced protection
+   - Place critical infrastructure on dedicated hardware
+   - Example: Run blockchain nodes on dedicated hardware isolated from general workstations
+   - Implement jump servers or privileged access workstations for administrative access
+4. Apply micro-segmentation where appropriate
+   - Container isolation: Enforce pod security policies and network policies
+   - Application segmentation: Implement service meshes with mutual TLS
+   - Process isolation: Use containerization, virtualization, or sandboxing
+5. Monitor and enforce boundary controls
+   - Implement egress filtering to control outbound connections
+   - Deploy internal firewalls between segments
+   - Use network monitoring to detect unauthorized communication attempts
+
+## 5. Continuous Visibility
+
+Maintain ongoing awareness of your security posture through active monitoring, testing, and continuous improvement.
+
+> **🔗 Related Framework:** For implementation details, see the [Monitoring](/monitoring/overview) framework, including
+> [Guidelines](/monitoring/guidelines) and [Thresholds](/monitoring/thresholds). Also relevant is
+> [Incident Management](/incident-management/overview) for response to detected issues.
+
+### Practical Application
+
+1. Implement a multi-layered monitoring strategy
+   - System monitoring: Performance, availability, and system integrity
+   - Security monitoring: Threat detection, anomaly identification, and correlation
+   - Compliance monitoring: Policy enforcement and regulatory requirements
+   - Establish clear ownership for each monitoring domain
+2. Define actionable metrics tied to security objectives
+   - Leading indicators: Metrics that help predict future issues
+   - Example: Percentage of systems with current patches
+   - Lagging indicators: Metrics that measure past performance
+   - Example: Mean time to detect and respond to incidents
+3. Establish a regular testing cadence to validate security controls
+   - Vulnerability scanning: Weekly automated scans
+   - Penetration testing: Quarterly focused tests on critical systems
+   - Red team exercises: Annual comprehensive assessments
+4. Implement a structured incident management process
+   - Define clear incident response procedures with specific roles
+   - Conduct regular tabletop exercises to practice response
+   - Perform thorough post-incident reviews focused on improvement
+   - Create feedback loops to security controls based on incidents
+5. Maintain an active threat intelligence program
+   - Collect intelligence relevant to your specific environment
+   - Analyze and contextualize threats for your organization
+   - Disseminate actionable intelligence to appropriate teams
+   - Use threat intelligence to drive security improvements
+
+---
+
+---
+
+### PAGE: /opsec/principles/principles
+**Title:** OpSec Core Principles
+**Referenced by controls:** dns-1.1.1
+
+# Operational Security Principles
+
+
+
+
+> 🔑 **Key Takeaway**: Effective OpSec relies on five core principles: layered defenses, minimal access rights,
+> need-to-know information sharing, system compartmentalization, and continuous monitoring—all working together to
+> protect sensitive information from adversaries.
+
+The goal is to prevent adversaries from gaining access to information that could be harmful if disclosed or compromised.
+
+> **Practical Example: Web3 Organization**
+>
+> Consider a Web3 project managing a DeFi protocol with a treasury of $10M in assets. Proper operational security would
+> involve:
+>
+> - **Multiple security layers**: Hardware wallets for cold storage, multi-signature requirements for transactions,
+> regular security audits, and continuous monitoring
+> - **Access control**: Only specific team members have access to deployment keys, with different permission levels for
+> development, testing, and production environments
+> - **Compartmentalized information**: Private keys for multi-signature wallets are distributed among trusted team
+> members with no single person having access to all keys, and sensitive incident response procedures are only shared
+> with the security team
+> - **Regular threat assessment**: The team conducts quarterly reviews of potential attack vectors, from smart contract
+> vulnerabilities to [social engineering](/awareness/understanding-threat-vectors) attempts targeting team members
+
+## 1. Defense in Depth
+
+Defense in Depth is the practice of layering security controls throughout your systems and processes, so that if one
+control fails, others will provide protection.
+
+> **🔗 Related Framework:** This principle is applied across multiple frameworks including
+> [Infrastructure](/infrastructure/overview) with [Zero-Trust Principles](/infrastructure/zero-trust-principles) and
+> [Network Security](/infrastructure/network-security).
+
+### Implementation
+
+1. Deploy multiple security controls that address the same risk in different ways
+2. Implement security at various layers: physical, technical, administrative, and human
+3. Ensure no single point of failure exists in your security architecture
+4. Review the effectiveness of security layers regularly to identify gaps
+5. Foster a [security-aware mindset](/awareness/cultivating-a-security-aware-mindset) across all team members
+
+## 2. Principle of Least Privilege
+
+The Principle of Least Privilege dictates that users, systems, and processes should have only the minimum access rights
+necessary to perform their functions.
+
+> **🔗 Related Framework:** For comprehensive implementation, see [Identity and Access Management](/iam/overview) and
+> [Role-Based Access Control](/iam/role-based-access-control).
+
+### Implementation
+
+1. Grant the minimum level of access required for users to perform their duties
+2. Review and adjust access rights when roles change
+3. Implement role-based access control (RBAC) to standardize permissions
+4. Use time-limited and just-in-time access for administrative privileges
+5. Regularly audit access rights to identify and remove excessive permissions
+6. Establish a thorough offboarding process to immediately revoke access when team members leave
+7. Remove credentials for deactivated accounts, as these can become security liabilities even when dormant
+
+## 3. Need-to-Know Basis
+
+Information should only be shared with individuals who require that information to perform their duties.
+
+> **🔗 Related Framework:** This principle is supported by practices in [Data
+> Protection](/opsec/old/data-protection/overview) and aspects of [Privacy](/privacy/overview).
+
+### Implementation
+
+1. Classify information based on sensitivity and restrict access accordingly
+2. Compartmentalize sensitive information to limit exposure in case of a breach
+3. Implement clear data handling and sharing policies
+4. Train team members on proper handling and sharing of sensitive information through regular [security
+training]
+{/*TODO: "/awareness/security-training" is this link this: /awareness/cultivating-a-security-aware-mindset ? */}
+5. Use secure communication channels for sensitive information
+
+## 4. Compartmentalization
+
+Dividing information and systems into isolated segments to limit the impact of a breach.
+
+### Implementation
+
+1. Segment networks and systems based on functionality and sensitivity
+2. Isolate critical assets from general-purpose systems
+3. Separate development, testing, and production environments
+4. Use separate accounts and access methods for different security domains
+5. Implement firewalls and access controls between segments
+
+## 5. Continuous Monitoring and Improvement
+
+Security is not a one-time implementation but a continuous process of monitoring, evaluating, and improving.
+
+> **🔗 Related Framework:** For implementation details, see the [Monitoring](/monitoring/overview) framework, including
+> [Guidelines](/monitoring/guidelines) and [Thresholds](/monitoring/thresholds). Also relevant is
+> [Incident Management](/incident-management/overview) for response to detected issues.
+
+### Implementation
+
+1. Establish security metrics to measure the effectiveness of controls
+2. Implement monitoring systems to detect security events and anomalies
+3. Conduct regular security assessments and penetration tests
+4. Learn from security incidents and near-misses
+5. Update security controls based on new threats, vulnerabilities, and technologies
+6. Ensure team members are
+[staying informed and continuously learning](/awareness/staying-informed-and-continuous-learning)
+about evolving security threats
+7. Utilize available [security resources](/awareness/resources-and-further-reading) to keep your security practices
+current
+
+---
+
+---
+
+### PAGE: /infrastructure/domain-and-dns-security/registrar-and-locks
+**Title:** Registrar Security & Registry Locks | SEAL
+**Referenced by controls:** dns-1.1.1, dns-1.1.2, dns-2.1.2, dns-3.1.1, dns-3.1.2, dns-3.1.3, dns-4.1.3, dns-4.1.4, dns-5.1.1, dns-5.1.3, dns-6.1.1, dns-6.1.2
+
+# Registrar Security & Registry Locks
+
+
+
+
+## Choosing a Secure Registrar
+
+Your domain registrar is the company that manages your domain registration with the central registry. This is often the
+weakest link in domain security, as many registrars have poor security practices and are vulnerable to social
+engineering attacks.
+
+### Enterprise-Grade Registrars (Recommended)
+
+These registrars are designed for high-value domains and have security measures that consumer registrars lack:
+
+- **MarkMonitor**: Used by Fortune 500 companies, requires legal documentation for changes, dedicated security team
+- **AWS Route53**: IAM policy integration, CloudTrail logging, uses Amazon Registrar for major TLDs (but check TLD support)
+- **Cloudflare Registrar**: No markup pricing, automatic DNSSEC, built-in DDoS protection, requires Cloudflare services
+
+### Consumer Registrars to Avoid for Critical Domains
+
+These registrars are designed for personal use and lack the security measures needed for Web3 projects:
+
+- **GoDaddy**: History of social engineering vulnerabilities, call center support vulnerable to manipulation
+  - [2020 incident: Employees tricked into compromising cryptocurrency domains](https://threatpost.com/godaddy-employees-tricked-compromise-cryptocurrency/161520/)
+  - [Multiple low-tech, high-impact breaches](https://krebsonsecurity.com/2023/02/when-low-tech-hacks-cause-high-impact-breaches/)
+- **Namecheap**: While better than GoDaddy, still vulnerable to social engineering and lacks enterprise-grade security controls
+- **Consumer-focused services** (Google Domains/Squarespace): Designed for personal use, not enterprise security
+- **Resellers**: Add another layer of complexity and potential attack surface
+
+**Due diligence**: Check [ICANN Compliance Notices](https://www.icann.org/compliance/notices) for registrar
+terminations, breaches, and compliance issues. ICANN has terminated several registrars due to security issues and
+breaches. Review your registrar's compliance history before trusting them with critical domains.
+
+## Registry Lock (EPP Lock)
+
+Registry lock prevents unauthorized transfers at the registry level, not just the registrar. This is the strongest
+protection available for domain security.
+
+**Important distinction**: EPP status codes apply to **registry objects** (transfers, deletes, nameserver sets, contact
+updates), NOT DNS zone edits at your provider's DNS panel. You can still edit A records, MX records, TXT records, etc.
+in your DNS hosting provider's interface even with EPP locks enabled.
+
+**EPP Status Codes** that protect your domain:
+
+- `clientTransferProhibited`: Prevents domain transfers to another registrar
+- `clientUpdateProhibited`: Prevents registry object updates (nameservers, contact information)
+- `clientDeleteProhibited`: Prevents domain deletion
+- `serverTransferProhibited`: Registry-level transfer protection (stronger than client-level)
+- `serverUpdateProhibited`: Registry-level update protection (nameservers, contacts)
+- `serverDeleteProhibited`: Registry-level deletion protection
+
+**How it protects you**: Standard transfer locks only prevent transfers between registrars, but registry locks with full
+EPP protections prevent unauthorized changes to critical registry objects including transfers, deletions, nameserver
+changes, and contact modifications. Server-level locks require manual verification with the registry operator (like
+Verisign for .com domains), making social engineering attacks at the registrar level completely ineffective.
+
+**What EPP locks do NOT block**: DNS record edits (A, AAAA, MX, TXT, etc.) in your DNS provider's panel remain fully
+functional. EPP locks protect registry-level changes, not zone-level DNS record edits.
+
+**Setup**: Contact enterprise registrars for registry-operator level locks. This typically requires additional fees and
+documentation but provides the highest level of security.
+
+## Multi-Factor Authentication
+
+Multi-factor authentication (MFA) adds an extra layer of security beyond just passwords, which are easily compromised
+through phishing or data breaches.
+
+**Strong recommendation**: Use **Hardware Security Keys (FIDO2/WebAuthn)** for registrar accounts. Given the critical
+nature of domain security and the irreversibility of domain hijacks, hardware keys are the ONLY authentication method we
+strongly recommend for Web3 projects.
+
+**Authentication options**:
+
+1. **Hardware Security Keys (YubiKey, Titan, etc.) - STRONGLY RECOMMENDED**
+   - **Immune to phishing**: Cannot be tricked by fake login pages
+   - **No shared secrets**: Private key never leaves the device
+   - **No SIM swap vulnerability**: Physical device required
+   - **FIDO2/WebAuthn standard**: Industry-standard cryptographic authentication
+   - **Why critical for domains**: Domain control = organization control; hardware keys provide the highest assurance
+
+2. **TOTP Applications (Google Authenticator, Authy) - DISCOURAGED**
+   - Vulnerable to phishing through man-in-the-middle attacks
+   - Shared secrets can be compromised during setup
+   - QR codes can be intercepted or screenshotted
+   - Only use as a last resort if registrar doesn't support hardware keys
+   - If forced to use TOTP, ensure registrar has additional protections
+
+3. **SMS 2FA - DO NOT USE**
+   - **Extremely vulnerable to SIM swapping attacks**
+   - SMS can be intercepted via SS7 vulnerabilities
+   - Social engineering attacks target mobile carriers
+   - No cryptographic security
+   - Numerous high-profile compromises via SMS 2FA
+   - **Never use SMS 2FA for domain registrar accounts**
+
+**Action item**: If your registrar only supports SMS or TOTP, consider **migrating to an enterprise registrar**
+(MarkMonitor, AWS Route53 Registrar, Cloudflare Registrar) that supports hardware security keys.
+
+## Dedicated Security Contact Email
+
+Use a dedicated email address for domain security that's completely separate from your main domain and personal accounts.
+
+**Why this matters**: If your main domain is compromised, you need a way to receive security notifications and regain
+control. Using the same domain creates a circular dependency.
+
+```
+❌ admin@yourdomain.com (circular dependency - if domain is hijacked, you lose email access)
+❌ personal@gmail.com (too many attack vectors, likely used across multiple services)
+⚠️ domain-security@protonmail.com (better than gmail, but still a shared service)
+✅ security@yourcompany-domains.com (best - separate domain dedicated to domain management)
+```
+
+As a best practice register a separate domain specifically for domain management (e.g., `yourproject-domains.com` or
+`yourproject-security.com`) with a different registrar than your main domain. This ensures you maintain communication
+channels even if your primary domain is completely compromised.
+
+## Access Control Best Practices
+
+Limit and monitor who has access to your domain registrar account, as each person with access represents a potential
+attack vector.
+
+**Key practices**:
+
+- Document all personnel with registrar access
+- Use role-based access where available
+- Implement approval workflows for critical changes
+- Regular access audits (quarterly minimum)
+
+## WHOIS Privacy Protection
+
+WHOIS records contain personal information about domain owners that is publicly accessible by default, including names,
+addresses, phone numbers, and email addresses.
+
+**Why it matters**: Without WHOIS privacy, your personal information is exposed to:
+
+- Attackers gathering information for social engineering attacks
+- Spammers harvesting contact details
+- Competitors researching your infrastructure
+- Anyone running a simple WHOIS lookup
+
+**Setup**:
+
+- Enable WHOIS privacy/proxy service through your registrar (often free or low-cost)
+- Use company information instead of personal details where privacy isn't available
+- Consider using a separate business entity for domain registration
+- Be aware that some TLDs (.us, .ca) don't allow WHOIS privacy
+
+**Important**: WHOIS privacy doesn't affect your legal ownership - you remain the legitimate owner, the privacy service
+just shields your personal information from public view.
+
+## WHOIS vs RDAP
+
+**RDAP (Registration Data Access Protocol)** is the modern replacement for WHOIS. While WHOIS is still widely used, RDAP
+should be preferred for domain information lookups.
+
+**Why RDAP is better**:
+
+- **Structured data**: JSON-based responses are machine-readable and easier to parse
+- **Standardized**: Consistent format across registries and registrars
+- **Better display**: Modern CLIs and tools display RDAP data in organized, readable formats
+- **More reliable**: Built on RESTful APIs with better authentication and access control
+- **Links to authoritative sources**: Provides direct links to registrar and registry RDAP endpoints
+
+**Using RDAP**:
+
+- **Command-line tools**: Use RDAP CLIs like `rdap` (Rust-based) or `nicinfo` (Ruby-based)
+- **Web tools**: Many registries provide RDAP web interfaces
+- **Example lookup**: `rdap yourdomain.com` displays domain status, EPP codes, nameservers, registrar info, and
+  expiration dates
+
+**Example RDAP output**:
+
+```
+❯ rdap google.com
+2025-10-06T20:36:58.203437Z  INFO rdap: ICANN RDAP 0.0.23 Command Line Interface
+2025-10-06T20:36:58.203497Z  INFO rdap: query type is Domain Lookup for value 'google.com'
+――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
+ • host                       : rdap.verisign.com
+ • Request URI                : https://rdap.verisign.com/com/v1/domain/google.com
+
+――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
+                                   Domain GOOGLE.COM
+
+  ┌────────────────────────────┬─────────────────────────────────────────────────────┐
+  │                     Summary│Domain GOOGLE.COM                                    │
+  │                            │• 292 (Registrar)                                    │
+  │                            │  • Abuse                                            │
+  │                            │• Nameserver NS1.GOOGLE.COM                          │
+  │                            │• Nameserver NS2.GOOGLE.COM                          │
+  │                            │• Nameserver NS3.GOOGLE.COM                          │
+  │                            │• Nameserver NS4.GOOGLE.COM                          │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │        Identifiers         │                                                     │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │                    LDH Name│GOOGLE.COM                                           │
+  │                Unicode Name│                                                     │
+  │                      Handle│2138514_DOMAIN_COM-VRSN                              │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │        Information         │                                                     │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │                      Status│• Client Delete Prohibited                           │
+  │                            │• Client Transfer Prohibited                         │
+  │                            │• Client Update Prohibited                           │
+  │                            │• Server Delete Prohibited                           │
+  │                            │• Server Transfer Prohibited                         │
+  │                            │• Server Update Prohibited                           │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │           Events           │                                                     │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │                Registration│• Mon, 15-Sep-1997 04:00:00 +00:00                   │
+  │                  Expiration│• Thu, 14-Sep-2028 04:00:00 +00:00                   │
+  │                Last Changed│• Mon,  9-Sep-2019 15:39:04 +00:00                   │
+  │Last Update Of RDAP Database│• Mon,  6-Oct-2025 20:36:39 +00:00                   │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │           Links            │                                                     │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │                        Self│• https://rdap.verisign.com/com/v1/domain/GOOGLE.COM │
+  │                     Related│• https://rdap.markmonitor.com/rdap/domain/GOOGLE.COM│
+  └────────────────────────────┴─────────────────────────────────────────────────────┘
+
+                                    292 (Registrar)
+
+                ┌─────────────────┬────────────────────────────────────┐
+                │          Summary│292 (Registrar)                     │
+                │                 │• Abuse                             │
+                ├─────────────────┼────────────────────────────────────┤
+                │   Identifiers   │                                    │
+                ├─────────────────┼────────────────────────────────────┤
+                │           Handle│292                                 │
+                │            Roles│• registrar                         │
+                │IANA Registrar ID│292                                 │
+                ├─────────────────┼────────────────────────────────────┤
+                │     Contact     │                                    │
+                ├─────────────────┼────────────────────────────────────┤
+                │        Full Name│MarkMonitor Inc.                    │
+                ├─────────────────┼────────────────────────────────────┤
+                │      Links      │                                    │
+                ├─────────────────┼────────────────────────────────────┤
+                │            About│• http://www.markmonitor.com        │
+                │                 │• https://rdap.markmonitor.com/rdap/│
+                └─────────────────┴────────────────────────────────────┘
+```
+
+**What RDAP shows**:
+
+- Domain status and EPP lock codes (clientTransferProhibited, serverUpdateProhibited, etc.)
+- Nameserver information
+- Registrar details and abuse contacts
+- Registration, expiration, and last update dates
+- Links to registry and registrar RDAP endpoints
+
+**For security audits**: Use RDAP to verify your domain's EPP status codes, confirm registry locks are active, check
+nameserver configurations, and validate expiration dates. The structured output makes it ideal for automated monitoring
+and compliance checks.
+
+## Domain Expiration Protection
+
+Domain expiration is a critical yet often overlooked security risk. When domains expire, they enter a grace period
+before becoming publicly available, creating an opportunity for attackers to snipe your domain.
+
+**Expiration timeline (typical for gTLDs following ICANN rules)**:
+
+- Day 0: Domain expires (site goes down)
+- Day 1-45: Auto-renew grace period (can renew at normal price)
+- Day 46-75: Redemption period (costs 10x+ to recover)
+- Day 76-80: Pending delete
+- Day 81: Public availability (bot armies compete to register)
+
+**Important**: Grace and redemption periods **differ per TLD**. Generic TLDs (gTLDs like .com, .org, .net) follow ICANN
+rules with the timeline above. Country code TLDs (ccTLDs like .uk, .de, .ca) often have different policies set by their
+respective registries. Always verify your specific TLD's expiration policy with your registrar or registry.
+
+**Protection measures**:
+
+- **Enable auto-renewal** on all critical domains
+- **Set multiple renewal reminders** at 90, 60, 30, and 7 days before expiration
+- **Register domains for maximum period** (up to 10 years for most TLDs)
+- **Use a domain monitoring service** that alerts on upcoming expirations
+- **Document renewal dates** in your security calendar
+- **Ensure payment methods stay current** - expired credit cards are a common cause of accidental expiration
+- **Designate a backup person** responsible for domain renewals
+
+**Pro tip**: Set calendar reminders to check auto-renewal status quarterly - don't assume it's working until you verify.
+
+---
+
+---
+
+### PAGE: /infrastructure/domain-and-dns-security/dnssec-and-email
+**Title:** DNSSEC, CAA, SMTP DANE and Email Security | SEAL
+**Referenced by controls:** dns-1.1.2, dns-2.1.1, dns-2.1.2, dns-3.1.1, dns-3.1.2, dns-3.1.3, dns-4.1.1, dns-4.1.2, dns-4.1.3, dns-4.1.4, dns-5.1.1, dns-5.1.2
+
+# DNSSEC, CAA, SMTP DANE and Email Security
+
+
+
+
+## DNSSEC Implementation
+
+DNSSEC (DNS Security Extensions) provides cryptographic authentication of DNS responses, preventing attackers from
+redirecting your users to malicious sites by tampering with DNS queries. Think of it as a digital signature that proves
+the DNS response came from the legitimate source.
+
+**How it protects you**: Without DNSSEC, attackers can intercept DNS queries and return fake IP addresses, redirecting
+users to malicious sites that look identical to yours. DNSSEC prevents this by cryptographically signing all DNS
+responses. While most client devices and many recursive resolvers do not perform DNSSEC validation on general DNS
+queries, DNSSEC is sometimes required and often preferred as a foundational component for security-sensitive internet
+protocols and features such as SMTP DANE, SSHFP, and CAA.
+
+**Preconditions**:
+
+- Domain is using the provider's nameservers
+- Registrar supports DS records
+- If registrar supports CDS/CDNSKEY auto-publish, enable that if offered
+
+**Practical setup**:
+
+1) **Enable signing at DNS provider**
+   - Turn on DNSSEC in the zone settings
+   - Provider generates KSK (Key Signing Key) and ZSK (Zone Signing Key), signs the zone, and shows DS parameters:
+     - **Key Tag**: Unique identifier for the key
+     - **Algorithm**: Common options:
+       - `13` (ECDSAP256SHA256) - Recommended
+       - `8` (RSASHA256)
+       - `15` (ECDSAP384SHA384)
+     - **Digest Type**:
+       - `2` (SHA-256) - Recommended for widest compatibility
+       - `4` (SHA-384)
+     - **Digest**: Hex string of the hash
+
+2) **Publish DS at registrar**
+   - Create a DS record with the exact four fields above
+   - Prefer Algorithm `13` (ECDSAP256SHA256) with Digest Type `2` (SHA-256) where supported
+   - If both digest types 2 and 4 are offered, pick 2 for the widest compatibility
+
+   Example registrar DS template:
+
+   ```
+   Owner: yourdomain.tld
+   Key Tag: 2371
+   Algorithm: 13
+   Digest Type: 2
+   Digest: 5C9F3E7B3F...A1C7
+   ```
+
+3) **Verify validation**
+   - Wait for registrar DS propagation (can take minutes to hours)
+   - Verify from a validating resolver using command-line tools:
+     - `dig +dnssec example.com A` (check for AD flag in response)
+     - `kdig +dnssec example.com A` (Knot DNS tool)
+     - `drill -D example.com A` (LDNS tool)
+   - For detailed analysis, use web tools:
+     - [Verisign DNSSEC Analyzer](https://dnssec-analyzer.verisignlabs.com/yourdomain.org)
+     - [DNSViz](https://dnsviz.net/d/yourdomain.org/analyze/)
+
+4) **Monitor validation and changes**
+   - Set up alerts for DS record changes at the registrar
+   - Monitor DNSSEC validation status regularly
+   - Watch for DNSKEY rollovers and ensure they complete successfully
+
+**Security notes**:
+
+- DNSSEC authenticates data; it does **not** encrypt queries. Use DoT (DNS over TLS) or DoH (DNS over HTTPS) for
+  transport privacy if needed.
+- Harden registrar accounts, protect transfer locks, and monitor for DS changes; DS removal downgrades protection.
+- A hijacked registrar account can remove DS records, eliminating DNSSEC protection
+- Add alerts on registrar activity to detect unauthorized changes
+
+## CAA Records
+
+Certificate Authority Authorization (CAA) records specify which Certificate Authorities (CAs) are allowed to issue SSL
+certificates for your domain. This prevents unauthorized certificate issuance, which attackers could use to create fake
+SSL certificates for your domain.
+
+**How it protects you**: Without CAA records, any Certificate Authority can issue SSL certificates for your domain.
+Attackers could potentially obtain fake certificates and use them in sophisticated phishing attacks that appear to have
+valid SSL encryption.
+A well behaved CA not explicitly permitted via CAA records will deny certificate requests for that domain. \
+While CA compromises are rare, history shows they do happen — and in such cases, attackers could potentially bypass
+or ignore CAA entirely. \
+Notable incidents include:
+
+- [DigiNotar (2011)](https://en.wikipedia.org/wiki/DigiNotar)
+- [Comodo (2011)](https://www.theregister.com/2011/03/28/comodo_gate_hacker_breaks_cover/) \
+Honorable mention, where it’s unclear whether CAA would have prevented the issue:
+- [Symantec Mis‑Issuance (2015–2017)](https://groups.google.com/a/chromium.org/g/blink-dev/c/eUAKwjihhBs/m/rpxMXjZHCQAJ)
+
+Before setting CAA records, identify which CA issued your current certificate:
+
+- **Command line**: `openssl s_client -connect yourdomain.com:443 -servername yourdomain.com | openssl x509 -noout -issuer`
+- **Web tools**: [SSL Labs Server Test](https://www.ssllabs.com/ssltest/) provides comprehensive certificate analysis
+  including issuer information
+- **Browser**: Click the padlock icon → Certificate details → Issuer information
+
+**Setup process**: Add CAA records to your DNS zone. Most DNS providers allow you to add these through their web interface:
+
+With the issuers full name in hand we now need to map it to the "Issuer Domain Name".
+There is no centralized repository mapping public CA's to their issuer domain names but they are generally easily found with
+a simple search for f.x. "Let's Encrypt CAA". \
+The Common CA Database also provides a
+[comprehensive collection to reference](https://ccadb.org/resources).
+
+```
+# Allow only specific CAs to issue certificates
+example.com. CAA 0 issue "letsencrypt.org"
+example.com. CAA 0 issue "digicert.com"
+
+# Send violation reports when unauthorized CAs attempt issuance
+example.com. CAA 0 iodef "mailto:security@example.com"
+
+# Control wildcard certificate issuance separately
+example.com. CAA 0 issuewild "letsencrypt.org"
+
+# Completely disable all certificate issuance (useful for non-web domains)
+example.com. CAA 0 issue ";"
+```
+
+## SMTP DANE
+
+DNS-based Authentication of Named Entities (DANE) is an email security protocol that relies on TLSA DNS
+records secured via DNSSEC. The TLSA record contains information on the MX and the certificate in use,
+allowing a secure connection to be made using that certificate.
+This prevents both MiTM and downgrade attacks. \
+DANE requires DNSSEC to be enabled on your domain - without it, TLSA records can be spoofed and offer no security benefit.
+
+If no record is found, SMTP DANE supporting clients will fall back to their usual connection flow.
+
+*While traditional PKI relies on trusted CAs, DANE allows domain owners to specify their own certificates,
+relying instead on DNSSEC to authenticate the certificate.*
+
+**Current industry support**: Of the major providers, Microsoft is the only one that currently supports
+SMTP DANE since its [RFC](https://datatracker.ietf.org/doc/html/rfc7672) was published in 2015. Notable
+smaller implementers include Comcast, Protonmail, Cisco, Fastmail, Posteo and Mailbox.org.
+
+**Implementation**: For those interested, a simple step-by-step tutorial can be found here for
+[Exchange Online](https://learn.microsoft.com/en-us/purview/how-smtp-dane-works#inbound-smtp-dane-with-dnssec).
+And for the brave, the Dutch Internet Standards Platform has published
+[detailed documentation](https://github.com/internetstandards/toolbox-wiki/blob/main/DANE-for-SMTP-how-to.md#reliable-certificate-rollover)
+on various aspects of supporting SMTP DANE on a self-hosted MX like postfix.
+
+**Example TLSA Record**:
+
+smtpdane.mx.microsoft. TLSA 900 "3 1 1 c495d9e40f7e625be22f83cc64305182ab0fe74232de30db8b218d09650cb0ea"
+
+- _25._tcp.smtpdane.mx.microsoft. → Host + port (SMTP uses 25/TCP)
+- TLSA → Record type for DANE
+- 900 → TTL in seconds
+- 3 1 1 →
+
+  - Usage 3 = Bind to end-entity cert
+  - Selector 1 = Public key info
+  - Match 1 = SHA-256 hash
+- Hex string → Hash of the MX certificate's public key
+
+**Further reading**:
+
+- [Microsoft SMTP DANE](https://learn.microsoft.com/en-us/purview/how-smtp-dane-works)
+- [RFC 7672](https://datatracker.ietf.org/doc/html/rfc7672)
+- [Google Cloud DNSSEC](https://docs.cloud.google.com/dns/docs/dnssec-advanced#tlsa) (only general docs, no
+  Google Mail support as of writing)
+
+## Email Security Configuration
+
+Email security records protect against email spoofing and phishing attacks. When your domain is compromised, attackers
+often change email settings to intercept password reset emails and other sensitive communications.
+
+### SPF (Sender Policy Framework)
+
+SPF records specify which mail servers are authorized to send emails on behalf of your domain. This prevents attackers
+from spoofing your domain in phishing emails.
+
+**How it protects you**: Without SPF, anyone can send emails claiming to be from your domain. Attackers use this for
+sophisticated phishing campaigns that appear to come from your legitimate email address.
+
+This is particularly dangerous as attackers can impersonate executives or team members to target your own organization
+and users - imagine receiving a "urgent wire transfer" request from your CFO's email address, or your users getting a
+"mandatory wallet update" from your official support email.
+
+**Setup**: Add an SPF record to your DNS zone:
+
+```
+example.com. TXT "v=spf1 include:_spf.google.com ~all"
+```
+
+### DKIM (DomainKeys Identified Mail)
+
+DKIM adds a digital signature to your emails, allowing receiving servers to verify that emails actually came from your
+domain and haven't been tampered with.
+
+**How it protects you**: DKIM signatures prove email authenticity and integrity, making it much harder for attackers to
+successfully spoof your domain in phishing campaigns.
+
+**Setup**: Configure with your email provider and publish public keys in DNS (your email provider will provide the
+specific records).
+
+### MTA-STS (Mail Transfer Agent Strict Transport Security)
+
+MTA-STS enforces encrypted connections between mail servers, preventing man-in-the-middle attacks on email transmission.
+
+**How it protects you**: Without MTA-STS, emails can be intercepted in transit. This is especially critical for password
+reset emails and other sensitive communications.
+
+**Deployment steps**:
+
+1) **Create the MTA-STS policy file**
+
+   Host a plain text file at: `https://mta-sts.<domain>/.well-known/mta-sts.txt`
+
+   Policy file structure:
+
+   ```
+   version: STSv1
+   mode: testing
+   mx: smtp.example.com
+   mx: alt1.smtp.example.com
+   max_age: 86400
+   ```
+
+   **Mode options**:
+
+   - `testing` - Monitor TLS failures but don't block mail (recommended to start)
+   - `enforce` - Require TLS for mail delivery
+   - `none` - Disable policy
+
+   **Important**: List all your MX servers. Ensure they have valid TLS certificates matching their hostnames.
+
+2) **Host the policy file over HTTPS**
+
+   The file must be:
+   - Publicly accessible at the exact path
+   - Served over HTTPS with a valid certificate
+   - Available 24/7 (use reliable hosting)
+
+3) **Publish DNS TXT record**
+
+   Create a TXT record at `_mta-sts.<domain>`:
+
+   ```
+   _mta-sts.example.com. TXT "v=STSv1; id=20250101000000"
+   ```
+
+   The `id` value (often a timestamp or version) signals mail servers to fetch the latest policy. Update it whenever you
+   change the policy file.
+
+4) **Testing and enforcement**
+   - Start with `mode: testing` to monitor without blocking
+   - Collect and review TLS failure reports
+   - Once confident, change to `mode: enforce`
+   - Update the `id` in DNS TXT record after policy changes
+
+**Provider-specific tips**:
+
+- **Google Workspace**: Manage MX in Admin console; host policy yourself; add TXT via DNS
+- **Cloudflare**: Host policy on Workers/Pages; manage TXT in DNS; HTTPS auto via Cloudflare SSL
+- **Amazon SES**: Host on S3 or CloudFront; manage TXT in Route 53; ensure domains are verified
+
+**Security notes**:
+
+- `max_age` determines how long mail servers cache the policy (86400 = 1 day)
+- All MX servers must support TLS with valid certificates
+- Monitor policy file availability - if unreachable, mail delivery may fail in enforce mode
+
+### DMARC (Domain-based Message Authentication)
+
+DMARC builds on SPF and DKIM to provide policy enforcement for email authentication. It tells receiving mail servers
+what to do with emails that fail authentication checks.
+
+**How it protects you**: DMARC prevents email spoofing by instructing receiving servers to reject or quarantine emails
+that fail authentication, protecting your users from phishing attacks.
+Without it, emails breaking SPF/DKIM may still be delivered by some providers (like Gmail, Outlook), often to the
+inbox or spam folder, sometimes with a warning banner (e.g., "This message may not be from…")
+DMARC also enables aggregate (rua) and forensic (ruf) reporting, giving domain owners visibility into who is sending
+email on their behalf - legitimate or otherwise.
+
+**Setup**: Add a DMARC record to your DNS zone:
+
+**Baseline example (aggregate reports only)**:
+
+```
+_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
+```
+
+**Report types**:
+
+- **`rua=`** (Aggregate reports): Daily summaries of authentication results. This is the baseline and widely supported.
+- **`ruf=`** (Failure reports): Real-time forensic reports for individual failures. Not recommended as they are:
+  - Not widely supported by mail providers
+  - Raise privacy concerns (contain message content/headers)
+  - May not deliver reliably
+  - Often unnecessary for monitoring purposes
+
+**Recommendation**: Start with aggregate reports only (`rua=`). They provide sufficient visibility into authentication
+issues without the privacy and reliability concerns of failure reports.
+
+---
+
+---
+
+### PAGE: /infrastructure/domain-and-dns-security/monitoring-and-alerting
+**Title:** DNS Monitoring & Incident Response | SEAL
+**Referenced by controls:** dns-1.1.2, dns-2.1.1, dns-2.1.2, dns-3.1.1, dns-3.1.3, dns-4.1.1, dns-4.1.2, dns-4.1.4, dns-5.1.1, dns-5.1.2, dns-6.1.1, dns-6.1.2
+
+# Monitoring, Alerts, and Incident Response
+
+
+
+
+## DNS Record Monitoring
+
+DNS record monitoring involves continuously checking your domain's DNS records for unauthorized changes. Attackers often
+modify DNS records to redirect traffic to malicious servers while keeping your site partially functional.
+
+**What to watch for**:
+
+- **Nameserver (NS) record changes**: Attackers change your nameservers to point to their own DNS servers, giving them
+  complete control over all DNS records
+- **Sudden TTL drops**: Very low TTLs *can* indicate preparation for rapid DNS changes during an attack
+  - **Note**: Low TTL is common and legitimate with CDNs and auto-scaling contexts; Cloudflare "Auto" is often 300s
+  - **Context**: Cloudflare allows TTL 30-60s for [unproxied
+    records](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/); this is not inherently malicious
+  - **Monitor for**: *Unexpected* drops from higher values or drops combined with other suspicious activity
+- **CAA record removal or overrides**: Allows any Certificate Authority to issue certificates for your domain
+  - **Note**: Child zones override parent CAA records
+  - **Advanced monitoring**: Watch for parameters like `accounturi` and `validationmethods` which provide finer control
+    over certificate issuance
+- **DNSSEC disabled unexpectedly**: Removes cryptographic protection from DNS responses
+
+**If nameservers remain unchanged, also monitor**:
+
+- **A/AAAA record modifications**: IP address changes could redirect users to malicious sites
+- **MX record modifications**: Email server changes could intercept password reset emails
+- **TXT record changes**: Could affect email security (SPF/DMARC) or domain validation
+
+**Monitoring tools** (continuous change tracking):
+
+- [MXToolbox](https://mxtoolbox.com/) - Comprehensive DNS record monitoring and alerts
+- [HetrixTools](https://hetrixtools.com/) - Free DNS monitoring with email alerts
+- [SecurityTrails](https://securitytrails.com/) - Historical DNS data and change tracking
+
+**Analysis and debugging tools**:
+
+- [DNSViz](https://dnsviz.net/) - DNSSEC chain validation and debugging
+- [DNS Dumpster](https://dnsdumpster.com/) - DNS reconnaissance and record discovery
+
+**GitOps and zone control**:
+
+- [OctoDNS](https://github.com/octodns/octodns) - Infrastructure-as-code for DNS; manage zones via code with auditable,
+  reviewed changes through CI/CD
+- [DNSControl](https://github.com/StackExchange/dnscontrol) - Synchronize DNS across multiple providers; declarative
+  configuration with version control
+
+**Note**: If attackers change your NS records, they control everything. But attackers with DNS panel access might make
+subtle changes without touching NS records to avoid detection, which is why monitoring individual record types remains
+important.
+
+## Certificate Transparency Monitoring
+
+Certificate Transparency (CT) logs are public records of all SSL certificates issued by Certificate Authorities.
+Monitoring these logs helps detect unauthorized certificate issuance.
+
+**Why it matters**: Attackers sometimes obtain fake SSL certificates for legitimate domains to make phishing sites
+appear more credible. CT monitoring helps you detect these certificates before they're used in attacks.
+
+**Setup and tools**:
+
+- [crt.sh](https://crt.sh/) - Search and monitor CT logs for your domain
+- [Cert Spotter](https://sslmate.com/certspotter/) - Free CT monitoring with API access
+- Watch for wildcard certificates if you don't use them (could indicate broader compromise)
+
+## Passive DNS Monitoring
+
+Passive DNS monitoring tracks historical DNS resolution data across the internet, helping you detect brief changes that
+might be missed by periodic checks.
+
+**What it detects**:
+
+- **Brief record changes**: Attackers often make quick changes to avoid detection
+- **Geographic anomalies**: DNS records resolving to unexpected countries or regions
+- **Suspicious hosting provider changes**: Sudden switches to hosting providers known for malicious activity
+
+**Tools for passive DNS**:
+
+- [PassiveTotal (RiskIQ)](https://community.riskiq.com/) - Comprehensive passive DNS database
+- [Mnemonic Passive DNS](https://passivedns.mnemonic.no/) - Free passive DNS lookup
+- [SecurityTrails](https://securitytrails.com/) - Historical DNS and WHOIS data
+
+## Setting Up Alerts
+
+### Critical Alerts (Immediate Response Required)
+
+1. **Registrar Changed**
+
+   - **What it monitors**: Changes to your domain's registrar
+   - **Why it's critical**: Indicates potential domain hijacking or unauthorized transfer
+   - **Response**: Immediate verification and potential incident response activation
+
+2. **Nameserver Changed**
+
+   - **What it monitors**: Changes to nameserver records
+   - **Why it's critical**: Attackers often change nameservers to redirect traffic to malicious servers
+   - **Response**: Verify legitimacy, check if you initiated the change
+
+3. **DNSSEC Broken**
+
+   - **What it monitors**: DNSSEC validation failures or disabled DNSSEC
+   - **Why it's critical**: DNS responses can be tampered with, leading to man-in-the-middle attacks
+   - **Response**: Investigate signing issues, check for configuration changes
+
+4. **CAA Records Removed or Overridden**
+
+   - **What it monitors**: Removal of Certificate Authority Authorization records or child zone overrides
+   - **Why it's critical**: Allows any CA to issue certificates for your domain, enabling SSL certificate attacks
+   - **Response**: Restore CAA records immediately, investigate who removed them
+   - **Note**: Child zones override parent CAA; parameters like `accounturi` and `validationmethods` can provide finer control
+
+5. **Unexpected TTL Drops**
+
+   - **What it monitors**: Sudden TTL drops from higher values
+   - **Why it's important**: Can indicate preparation for rapid DNS changes (attack preparation)
+   - **Context**: Low TTL (30-300s) is normal for CDNs and auto-scaling; Cloudflare allows 30-60s for [unproxied records](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/)
+   - **Response**: Investigate *unexpected* drops or drops combined with other suspicious activity; verify if legitimate
+     infrastructure changes
+
+### High Priority Alerts (When NS Unchanged)
+
+1. **A Record Changed**
+
+   - **What it monitors**: IP redirects without NS changes
+   - **Why it's important**: Could redirect users to malicious servers
+   - **Response**: Verify the new IP address is legitimate and expected
+
+2. **MX Record Changed**
+
+   - **What it monitors**: Changes to mail server configurations
+   - **Why it's important**: Could intercept emails, including password reset messages
+   - **Response**: Verify mail server changes are authorized
+
+3. **DMARC Policy Weakened**
+
+   - **What it monitors**: Changes from "reject" to "quarantine" or "none"
+   - **Why it's important**: Weaker policies allow more spoofed emails to reach users
+   - **Response**: Investigate why policy was weakened, restore if unauthorized
+
+4. **Unexpected Certificate Issued**
+
+   - **What it monitors**: New SSL certificates issued for your domain
+   - **Why it's important**: Could indicate certificate-based attacks or unauthorized issuance
+   - **Response**: Verify the certificate was requested by your team, revoke if unauthorized
+
+## Incident Response Plan
+
+### Immediate Response
+
+1. **Verify the compromise** - Check DNS records via multiple resolvers
+2. **Access registrar account** - Attempt login, check for lockout
+3. **Contact registrar security team** - Use pre-documented emergency contacts
+4. **Document everything** - Screenshot all current settings
+
+### Containment
+
+1. **Invoke registry lock** if available
+2. **Update NS records** if you maintain access
+3. **Warn users** via social media/status page
+4. **Contact law enforcement** if significant theft occurred
+
+### Recovery
+
+1. **Regain control** through registrar security procedures
+2. **Audit all DNS records** against known-good baseline
+3. **Reset all credentials** for registrar and DNS hosting
+4. **Review access logs** to understand attack vector
+
+### Post-Incident
+
+1. **Conduct thorough investigation**
+2. **Update security measures** based on lessons learned
+3. **Consider legal action** if appropriate
+4. **Publish transparency report** to rebuild trust
+
+---
+
+---
+
+### PAGE: /opsec/travel/guide
+**Title:** Travel Security Guide
+**Referenced by controls:** dns-3.1.2, dns-4.1.3, dns-5.1.3, dns-6.1.1, dns-6.1.2
+
+# Personal security travel guide — full
+
+
+
+
+Travel introduces unique security risks to your digital assets and sensitive information. Proper preparation before,
+vigilance during, and careful review after travel creates a comprehensive defense strategy that balances security
+with practical usability.
+
+When we travel, our normal security routines are disrupted, and we face elevated risks from physical theft, digital
+surveillance, border inspections, and social engineering. Web3 professionals face additional challenges when traveling
+with crypto assets or access to treasury funds. The resources in this guide provide practical guidance for maintaining
+operational security while traveling.
+
+> 🔑 Key Takeaway: Minimize data exposure by carrying only essential devices with full-disk encryption and updated
+> software. Secure accounts with backup 2FA methods, avoid biometrics at borders, use trusted networks with VPNs, and
+> never leave devices unattended. Guard against USB attacks, shoulder surfing, and hidden cameras. For crypto, use
+> strong passphrases and never travel with seed phrases. Upon returning, scan devices for malware and consider resetting
+> high-risk devices.
+
+{/* separator */}
+
+> ❗ This is not, by any means, an extensive guide on this subject or expected to be followed at its core. Its intention
+> is to guide and provide hints as to where to apply security. This will vary depending on case to case, or, in other
+> words, the risks you expose yourself to, by specifically traveling.
+
+This guide is categorized into four sections:
+
+1. **Before traveling:** All the things you could do before you depart, such as hardening some devices or making sure
+you have a backup of the data you’ll be traveling with, even letting know someone you’ll be calling in case of an
+emergency and how to identify you. This does not necessarily mean that if you’re reading this while traveling you cannot
+do anything from that list, only that it might be more challenging to execute depending on your context.
+2. **While traveling:** All the things you have to pay attention to or take care of while on the move. Is it necessary
+to connect to that conference’s WiFi? Have you checked if there is a camera that might be recording your keystrokes?
+Leaving your computer unattended or just running whatever software your hackathon teammate asks you to download in order
+for your promising project to win.
+3. **Returning home:** Not in the literal sense of it, but directed toward all the things you have to do after your
+travels. From updating your processes based on experience to wiping exposed devices before rejoining them to your
+networks.
+4. **Additional information for high-profile targets:** If you are a high-profile target, you’ll evidently realize that
+some of these initial suggestions fall short within your threat model. This section provides a hint toward profiles like
+yours.
+
+## Before traveling
+
+> 💡**Remove or securely store** any data, devices, printed files, and documents **you don’t absolutely need on the
+> trip**. The less sensitive information and fewer critical assets you carry, the lower the risk and impact if loss,
+> theft, or inspection occurs. Minimize your digital and physical footprint by leaving backups and originals securely at
+> home or in trusted locations, and encrypt what must travel with you. This principle applies to laptops, phones,
+> hardware wallets, paper backups, and any portable storage media.
+
+### **Perform a quick threat model**
+
+Even if you are already traveling, take 5 minutes to map out your risks. Identify **what assets** you're carrying
+(laptops, phones, hardware wallets, seed phrases, account access), **who might target them** (thieves, cybercriminals,
+border agents, etc.), and **how attacks might happen** (device theft, tampering, malware, coercion). For each threat,
+plan a mitigation. For example, if you're carrying a hardware wallet, a threat is pickpocketing – mitigation could be
+keeping it attached to yourself (just don't use ledger's necklace visibly) and securing it with a secure PIN/passphrase
+(no patterns, not repeated across devices).
+
+This exercise keeps security measures proportionate to your situation.
+
+### **Secure devices with encryption & updates**
+
+Enable full-disk encryption on all devices (laptops, phones, tablets) to protect data if lost or stolen. Most modern
+OSes have this by default (e.g. BitLocker for Windows, FileVault for MacOS, LUKS for Linux,or Android/iOS encryption –
+just ensure a strong password/PIN is set).
+
+Use popular devices like iPhones and Pixels. Install the latest OS and app updates since these patch security
+vulnerabilities. This does not mean that using the latest versions is the safest take, but usually there's a balanced
+trade-off when they got security patches. You can also consider to install — only trustworthy — mobile security
+applications, which try to add a layer of control and also reminds you of important security updates.
+
+**Note:** On iOS, due to sandboxing, apps can't scan the entire OS for malware, so many security apps focus on VPN,
+phishing web protection, breach alerts, etc.
+
+If you must bring high-risk confidential data, consider encrypting those files individually using tools like VeraCrypt,
+FileVault, BitLocker, LUKS/dm-crypt, and more.
+
+### **Back up and prepare for loss**
+
+Back up your devices before travel (and ensure cloud backups like iCloud/Google are up to date). This way, if a device
+is lost or confiscated, you won’t lose important information. Record device details (make, model, serial numbers, IMEI
+for phones) and keep that list separate – it will help in filing reports or remote-wipe commands.
+
+If your company uses Mobile Device Management (MDM) on phones or laptops, verify the device is enrolled and you know how
+to trigger a remote wipe or “lost mode.” Test “Find My” or equivalent device-finding services so you can use them if
+needed. Pack chargers and cables so you won’t need to borrow unknown ones (which could be malicious).
+
+### **Protect Accounts with 2FA redundancy**
+
+Plan for how you'll access accounts that use two-factor authentication if your main device is unavailable. For
+authenticator apps (TOTP codes), **export backup codes** for your important accounts and keep them **securely** in
+services like 1Password or NordPass (you can check passwordmanager.com for more information on which one to pick).
+Alternatively, consider storing them elsewhere physically. If your 2FA is tied to a phone number (SMS or voice),
+**disable SMS for 2FA**. For technologies that are unfortunately dependent on phone numbers, use a separate line
+(not your personal one) from services like Google Voice, Burner App or SLYFONE. Transfer your number to an eSIM since
+[they are harder to physically steal or swap than a physical SIM](https://support.apple.com/en-ca/118227#:~:text=Use%20eSIM%20while%20traveling%20internationally,obtain%2C%20carry%2C%20and%20swap).
+
+Ensure your password manager is accessible – many like 1Password have a *Travel Mode* that removes sensitive vaults from
+your device while you travel (you can restore them later). This limits exposure if your
+[device is searched or seized](https://www.schneier.com/blog/archives/2025/04/cell-phone-opsec-for-border-crossings.html).
+
+You can also register a backup or alternative 2FA method, like a secondary phone (the device) or a PIN-protected
+hardware key to be used as a passkey. Be responsible with the use of software passkeys, particularly in situations
+where you are using a password manager to store both your passwords and passkeys, as this creates a single point of
+failure.
+
+### **Secure your wallets and keys**
+
+**Hardware wallets (e.g. Ledger, Trezor):** Update the firmware and test the device before you leave, don't do this
+while traveling. **Do NOT bring any written seed phrases** under any circumstance – seed backups are unencrypted keys
+that are far easier to steal or copy than a hardware device. Leave seed backups in a secure place, travel only with
+your hardware wallet if necessary. Enable all security features on the device (set a strong PIN, and use a BIP39
+passphrase for
+example, if supported) so that even if the device is stolen, the amount of required information to access your crypto,
+is high. Carry hardware wallets and security keys **in your carry-on or under your sight**, not in checked luggage, to
+avoid loss or tampering.
+
+**Yubikeys and 2FA tokens:** Bring them to protect logins and make sure they're enabled on your
+critical accounts. Keep them on your person or in a separate bag from your laptop/phone so that a thief or snoop can't
+easily steal both at once. If you have a **spare hardware wallet or Yubikey**, you might leave one at home as a backup
+in case the one you carry is lost. Add, when possible, an extra layer of security to the token, such as a PIN code.
+
+### **Lock down phones**
+
+On your smartphone, take advantage of security settings **before** you travel. Set a strong passcode (not just a 4-digit
+PIN or pattern). Consider **disabling Touch ID/Face ID** if you might face situations where someone could force-unlock
+your device using your biometrics – in many jurisdictions, authorities can compel a fingerprint or face scan more easily
+than a memorized password
+[.](https://www.schneier.com/blog/archives/2025/04/cell-phone-opsec-for-border-crossings.html#:~:text=deactivate%20biometric%20security%20and%20require,10%20failed%20PIN%20unlock%20attempts)
+At a minimum, know how to quickly and
+[**temporarily disable biometrics**](https://news.ycombinator.com/item?id=43630624);
+for example, on an iPhone,
+[holding the side button and a volume button will trigger an emergency mode that requires the passcode to unlock](https://www.themacguys.com/essential-travel-security-tips-for-apple-devices/).
+On Android, use *Lockdown* mode if available (which only temporarily disables biometrics and is different
+from iOS Lockdown Mode).
+
+If you have an iPhone, enable **Lockdown Mode** (extreme protection on iOS) even if you are not at
+[high risk or traveling to a high-threat region](https://www.themacguys.com/essential-travel-security-tips-for-apple-devices/#:~:text=This%20mode%20is%20ideal%20when,or%20dealing%20with%20sensitive%20data)
+ – but be aware [it restricts many features](https://support.apple.com/en-gb/105120), though totally worth it.
+
+Disabling or restricting USB debugging on Android and using iOS USB restricted mode helps prevent unauthorized physical
+USB access and reduces risks from malicious cables or compromised charging stations.
+
+If your phone is managed by work (MDM), inform your IT team of your travel so they can assist with any location-based
+security policies and ensure you have the latest security profile. Finally, consider using a **dedicated eSIM/local
+SIM** for travel data. This can protect your primary phone number (you can keep your main line on eSIM and turn it off,
+while using a local data eSIM for mobile internet) and avoids physical SIM issues.
+
+**Configure additional phone protections:** On iOS devices, disable Control Center and Notification Center access from
+the lock screen (Settings > Face ID & Passcode) to prevent thieves from seeing notifications or enabling Airplane Mode
+without unlocking. Disable USB accessory connections when locked to prevent unauthorized connections. For device
+recovery, ensure Find My iPhone is enabled with "Send Last Location" and "Find Network" options activated so tracking
+continues even if the device is powered off.
+
+On Android, similar protections can be configured: disable notifications on lock screen (Settings > Notifications > On
+lock screen > Don't show notifications), and enable "Find My Device" with all location services.
+
+**Pay special attention apps security**: many financial apps default to PIN verification instead of biometrics, which
+means a thief who has your phone and knows your PIN could potentially access your financial accounts even if they can't
+bypass Face ID/Touch ID. Use unique PINs for banking apps that differ from your device PIN, or where possible, configure
+these apps to require biometric verification for every login.
+
+### **Minimize digital footprint & social visibility**
+
+It's not just cyber threats – **operational security** matters. **Avoid announcing your travel plans publicly**
+[on social media](https://blackcloak.io/social-media-and-travel-be-careful-of-what-you-share/) and be careful
+with real-time updates. Posts about being away from home can signal to criminals that you (and possibly valuable
+devices or even your house) are vulnerable. Consider sharing trip photos and crypto conference highlights **after**
+you return or only with trusted contacts. Ensure your social media privacy settings are tightened so strangers can't
+see your travel posts.
+
+When registering for events, use privacy-focused tools like iOS's **Hide My Email** or create burner emails through
+providers like Tuta. ProtonMail has had some controversy lately, but could still be a good alternative. If you don't
+need to keep the inbox at all, just create a throwaway mail, there are plenty of options out there. Avoid giving out
+personal details unnecessarily during registration—use minimal, generic info to reduce your digital footprint.
+
+**Discretion** is key: if possible,
+[don't advertise that you work in crypto](https://www.unchained.com/blog/7-tips-traveling-bitcoin#:~:text=,or%20clothing%20with%20bitcoin%20logos)
+or carry cryptocurrency. For example, **remove or cover any crypto stickers on laptops or bags**, and avoid wearing
+company swag or Bitcoin/Ethereum logos while in transit. These can be neon signs attracting thieves or unwanted
+attention ("I have valuable data or wallets!"). If asked about your work or luggage by curious strangers, have a
+**cover story** (e.g. "I work in finance/IT")
+rather than "I manage a crypto fund". High-profile team members might travel under pseudonyms
+or at least not list their company on luggage tags to stay low-profile. Also, be wary that you might be traveling with
+someone with these characteristics, so don't give them away.
+
+### **Plan emergency and incident responses**
+
+Before departure, know what you'll do if something goes wrong. Have a **fallback plan** in case of device loss: who will
+you notify & how (have safe words and beware of deepfakes or impersonations); how will you revoke access to sensitive
+accounts; and how will you continue working (e.g., a backup laptop or a colleague who can step in).
+
+If traveling to
+[countries with strict tech](https://www.perplexity.ai/search/countries-that-list-cryptopgra-bBSItefPSUi7HP2lTNekjA) or
+[encryption laws](https://it.cornell.edu/security-and-policy/travel-internationally-technology#:~:text=Some%20countries%20have%20restrictions%20on,Consider%20requesting%20a%20loaner%20laptop)
+(e.g., China, Russia, UAE), devices like VPNs, encrypted messaging apps (Signal, or Telegram with Secret Chats only),
+hardware wallets (Ledger, Trezor), Yubikeys, or encryption software (VeraCrypt, BitLocker) may be flagged by border
+authorities. Research local laws beforehand. Consider carrying a travel letter from your organization explaining the
+professional need for these tools, or use sanitized loaner devices to avoid issues at border controls.
+
+Share your itinerary and contact information with a trusted peer so they can assist or monitor for any issues.
+
+Finally, schedule critical work (especially high-value transactions) for **before or after** your trip if possible, so
+you’re not forced to do ultra-sensitive actions on the road. Criminals usually play with the “time-sensitive factor,”
+trying to trick you into doing something quick and urgent, by committing something reckless.
+
+## While traveling
+
+### **Network safety – avoid untrusted Wi-Fi & Bluetooth**
+
+Treat **every network as potentially hostile**. Whenever possible, use a **cellular connection or a personal hotspot**
+instead of public Wi-Fi – your mobile data is encrypted and safer than an open café or hotel network. If you must use
+public Wi-Fi (hotel, airport, conference), verify the network name with staff and
+[**disable auto-connect**](https://www.cisa.gov/sites/default/files/publications/Cybersecurity%20While%20Traveling.pdf)
+features so your devices don't join networks without prompting you.
+
+**Turn off Wi-Fi and Bluetooth** on your phone and laptop when you're not using them; this reduces the risk of
+unsolicited connections or Bluetooth-based attacks. Also, disable any device-to-device sharing like **AirDrop** or
+**Nearby Share**
+[to prevent strangers from sending you files](https://www.cypherock.com/blogs/post-safe-vacation-tips-while-traveling-with-crypto#:~:text=Switch%20off%20any%20shared%20networks).
+
+**Use a trustworthy VPN** for an extra layer of encryption for your internet traffic, although in most cases by using an
+updated device, safe hardcoded DNS records, and ensuring SSL while browsing (enforce HTTPS-only-modes or adding
+“http://*” to your uBlock list, might be enough. A reputable, non-logging VPN (or your company’s VPN) helps protect
+against snooping on public networks, especially if you’re handling highly sensitive work and using several communication
+channels.
+
+Using a personal portable router combined with a trusted VPN adds a strong layer of security when connecting to public
+Wi-Fi networks. This setup creates a private, encrypted tunnel between your devices and the internet, minimizing
+exposure to malicious actors on shared networks. Whenever possible, prefer mobile data over Wi-Fi, as cellular networks
+provide better encryption and isolation by default. If you must use Wi-Fi, disable automatic connections and ensure you
+connect only to verified, trusted networks to reduce risk.
+
+### **Device handling – keep them close and protected**
+
+Never leave your devices (laptops, phones, hardware wallets) **unattended or unsecured** in public. Keep them on your
+person or within sight whenever possible. In a conference or cafe, use a cable lock for your laptop if you must step
+away briefly, take it with you or get someone you trust to watch it over for you.
+
+In hotels/Airbnbs, **use the room safe** for small devices when you're out. These safes can easily be opened by an experienced
+thief or rogue/malicious staff. Consider a portable travel safe/bag you can lock to a fixed object. A
+[**portable door lock**](https://www.travelandleisure.com/sabre-portable-door-lock-review-7643179#:~:text=schedule%20and%20explore%20fascinating%20destinations,star%20ratings%20at%20Amazon)
+or door jammer for your room can add an extra barrier against intruders (useful in rentals without chain locks). This
+simple gadget prevents anyone (even with a key) from opening your door while you're inside, giving you peace of mind at
+night. When out and about, be mindful of pickpockets – use bags that zip and consider a subtle anti-theft backpack for
+expensive gadgets or important assets.
+
+For hardware wallets or Yubikeys, a good practice is to **separate them** from the device they authenticate: e.g. don't
+carry your Yubikey on the same keychain as your laptop bag key; keep it hidden on you. And, of course, **keep devices
+powered off** or locked when not in use –
+[enable short auto-lock timeouts](https://www.cisa.gov/sites/default/files/publications/Cybersecurity%20While%20Traveling.pdf#:~:text=%E2%80%A2%20%20%20%20,Some%20devices%20will)
+on your phone/laptop so they aren't unlocked if
+snatched[.](https://www.cisa.gov/sites/default/files/publications/Cybersecurity%20While%20Traveling.pdf#:~:text=%E2%80%A2%20%20%20%20,Some%20devices%20will)
+
+### **Beware of public USB charging**
+
+Avoid plug-and-play charging stations at airports or malls. The risk of
+["**juice jacking**"](https://www.cypherock.com/blogs/post-safe-vacation-tips-while-traveling-with-crypto?srsltid=AfmBOopuzAsUtNwqCqfUBteTEyH4MOTvIaRhoXoIUyNHH8Yv5XzILrSr#:~:text=Stay%20away%20from%20Public%20charger,stations),
+although small,
+is that a malicious charging kiosk or cable can inject malware or siphon data when you connect via USB. Depending on
+your profile risk, you might encounter technologies that mimic different kind of cables and accessories with the same
+purpose. These exist out of the box, and have been widely used by red-teamers and pentesters (re OMG cable).
+
+Stick to using your own charger plugged into a power outlet, or use a **USB data blocker** (a little adapter that
+only passes power, not data). Similarly, do not plug unknown USB drives into your laptop – if someone hands you
+a free USB stick at an event, assume it could be a trap.
+[**USBGuard**](https://github.com/USBGuard/usbguard#:~:text=USBGuard%20is%20a%20software%20framework,may%20interact%20with%20the%20system)
+software (for Linux) or equivalent can be used to restrict USB device access on your computer, allowing only
+whitelisted devices. This tool can prevent an unknown USB from automatically tampering with your system by requiring
+authorization for new devices. At a minimum, disable any "USB autorun" features and consider locking down ports if your
+OS allows.
+
+### **Screen privacy and social engineering**
+
+Practice situational awareness when working in public spaces.
+[**Shoulder surfing**](https://www.trio.so/blog/shoulder-surfing-in-computer-security)
+is a real threat – someone nearby could be
+watching you enter passwords or PIN codes. Use a **privacy screen filter** on your laptop or phone to narrow the viewing
+angle. This makes it much harder for anyone not directly in front of your screen to read it. Sit with your back to a
+wall when possible, and shield the keypad with your body or hand when typing sensitive info.
+
+In crowded conferences or airports, be cautious if someone you don't know strikes up conversation — might be trying to
+distract you or talk about crypto; scammers might engage you to glean info or even attempt to get you to unlock your
+device. **Don't log in to critical accounts in front of others** – you never know who's looking.
+
+Also be mindful of **phishing attempts**: traveling users are prime targets for fake "urgent" emails or messages.
+Double-check any unusual prompts before entering credentials, especially if you're on
+[untrusted Wi-Fi](https://www.cisa.gov/sites/default/files/publications/Cybersecurity%20While%20Traveling.pdf#:~:text=banking%2C%20or%20sensitive%20work%2C%20using,using%20a%20public%20wireless%20network)
+(use your VPN and look for HTTPS).
+
+### **Maintain OpSec in public**
+
+While traveling, **blend in and stay discreet**. Refrain from discussing sensitive matters in public areas where
+eavesdropping is possible, or directly sharing things like where you are staying to people you don't know. Even hotel
+lobbies or rideshares might not be secure for private discussions.
+
+When meeting people, don't give your phone to others to type down their socials, and remember to disable default options
+like Telegram's sharing phone number when adding a contact.
+
+Remember that **hidden cameras or microphones** could exist in unfamiliar environments. It's rare but not unheard of,
+especially in
+[Airbnbs or rented spaces](https://www.washingtonpost.com/travel/2024/05/22/hidden-cameras-airnbnb-rental-properties/#:~:text=On%20the%20kitchen%20table%2C%20he,activate%20the%20camera%20tucked%20inside)
+– malicious hosts have hidden cameras in items like smoke detectors, clock radios, or USB chargers
+[.](https://www.washingtonpost.com/travel/2024/05/22/hidden-cameras-airnbnb-rental-properties/#:~:text=On%20the%20kitchen%20table%2C%20he,activate%20the%20camera%20tucked%20inside)
+Give your accommodations a scan: look for odd or
+[extra devices plugged in](https://www.washingtonpost.com/travel/2024/05/22/hidden-cameras-airnbnb-rental-properties/)
+(especially facing beds or desks) and cover or unplug them if suspicious. You can also play ambient noise (or use a
+noise generator app) during confidential conversations to thwart any listening devices.
+
+**Keep a low profile**: as mentioned,
+[don't flaunt crypto wealth or gear.](https://www.unchained.com/blog/7-tips-traveling-bitcoin#:~:text=,or%20clothing%20with%20bitcoin%20logos)
+For example, if attending a blockchain conference, consider using an alias on your name badge that doesn't explicitly
+say your company or title, and don't display that badge outside the venue. When moving around, secure your laptop in a
+nondescript sleeve or bag (instead of one with a well-known conference brand). The goal is to avoid drawing the
+attention of both petty thieves and more organized attackers by limiting the signals that you're a high-value crypto
+target.
+
+Don't rely on security through obscurity. Going "stealth" doesn't make you immune to attacks. The suggestions in
+this section are meant to complement, not replace, the other security measures.
+
+### **Traveling with high-value crypto or duties**
+
+If you *must* make crypto transactions or access sensitive systems while on the road, do so with caution. Use trusted
+hardware and networks: e.g. if you need to send a transaction, use your hardware wallet on your own laptop (never a
+shared computer), on a secured connection.
+
+Be aware of **surveillance at events** – attackers have been known to watch for people handling sensitive info. If you
+need to access a seed or enter a recovery phrase, do it in a private, secure setting (never over public Wi-Fi or in view
+of anyone, including cameras). Consider that
+[**everyone knows you own crypto at a crypto event**](https://www.unchained.com/blog/7-tips-traveling-bitcoin#:~:text=If%20you%27re%20traveling%20to%20an,in%20your%20belongings%20while%20traveling),
+so your threat profile is
+elevated[.](https://www.unchained.com/blog/7-tips-traveling-bitcoin#:~:text=If%20you%27re%20traveling%20to%20an,in%20your%20belongings%20while%20traveling)
+Adjust your security: for instance, **enable a passphrase or a pin on any single-signature wallet** you carry so that
+even if someone obtains your hardware wallet, they can't access funds without that passphrase. For large amounts, rely
+on multi-sigs, verifying payloads before signing – you might carry one key on you and leave another key(s) with trusted
+parties so no single person has all
+signing power while traveling. In short, treat any on-trip crypto operations with more care than you would in the
+office or at home.
+
+### While presenting or doing public appearances
+
+One often overlooked risk is the exposure caused by presenting or hosting technical workshops in public. Without
+properly hardening or isolating your computer before setting up, you may unintentionally expose network services to
+hostile environments or reveal sensitive information on-screen. Always prepare a clean, minimal environment and verify
+no confidential data or open ports are accessible before connecting to unfamiliar networks or projecting your screen.
+
+### **Physical safety and common sense**
+
+Operational security also has a physical aspect. **Trust your instincts** and normal travel safety rules: stick to
+well-lit and populated areas if carrying devices at night, don’t let strangers “shoulder surf” your ATM or credit card
+PIN (check for skimmers, fake interfaces), and keep your travel documents secure since identity theft can be as damaging
+as device theft.
+
+Use hotel lockers at conferences if provided (for example, some events offer secure charging lockers – use them rather
+than leaving devices out only).
+
+Beware of the classic “evil maid” scenario in hotels (where someone might tamper with your laptop in your room): using
+tamper-evident tape or seals on your laptop case can help detect this, though it’s mostly a concern for high-risk
+targets. If you have tamper-evident stickers or tamper-evident bags, you can seal your device in them overnight – any
+attempt to open or remove the device will leave a visible trace. While not foolproof against a determined adversary, it
+raises the bar and can deter casual snooping.
+
+Petty thieves may look beyond obvious valuables. Simply locking items in a dorm safe or hiding them at home might deter
+casual theft, but savvy criminals often search inside books, behind electrical outlets, or within patterns on walls or
+furniture to find hidden stashes. Consider unconventional hiding spots and avoid predictable storage methods. Layer your
+physical security measures with tamper-evident seals or discreet decoy containers to raise the effort required for
+unauthorized access.
+
+Above all, maintain an **alert posture**: be aware of who’s around when you’re working, and if something feels off (like
+someone persistently hovering or a device acting strangely), don’t ignore it. You can always relocate, power down your
+device, or otherwise cut off exposure at the first sign of trouble.
+
+## Returning home
+
+### **Secure your accounts and passwords**
+
+Once you're back, if you suspect that any account credentials you used while abroad *might* have been exposed
+(especially if you had to log in over a hotel or conference Wi-Fi), address the issue. Change the passwords for any
+accounts you accessed unsafely during the trip – but if you don't feel is necessary, sometimes you pose a greater risk
+at doing so.
+
+Do this from a *trusted* device/network (ideally wait till you're on your home or office network, not the airport
+Wi-Fi). Use this opportunity to upgrade weak passwords and ensure 2FA is still working on those accounts. Check your
+email filters and crypto account settings for any unauthorized changes (attackers sometimes add forwarding rules or new
+withdrawal addresses if they did get access).
+
+Essentially, **rotate secrets** that may have been used under less-secure conditions.
+
+### **Inspect and clean your devices**
+
+After traveling, give your devices a thorough once-over. Run a reputable anti-malware scan on laptops and phones. Look
+for any unusual apps, processes, or device behavior (for example, unusual battery drain could indicate malware).
+
+If you were in a high-risk environment or your device was out of your control at any point, consider wiping the device
+and restoring it from your pre-trip backup (or factory-resetting a phone)
+[to ensure it's clean](https://architectsecurity.org/2017/10/mobile-device-security-for-international-travelers-part-3-how-to-clean-up-your-mobile-devices-after-international-travel/#:~:text=Assume%2C%20whether%20correct%20or%20not%2C,and%20must%20be%20rebuilt%20anew)[.](https://architectsecurity.org/2017/10/mobile-device-security-for-international-travelers-part-3-how-to-clean-up-your-mobile-devices-after-international-travel/#:~:text=The%20goal%20after%20travel%20is,to%20a%20%E2%80%9Cknown%20good%E2%80%9D%20state)
+This is especially recommended for "burner" devices used on the trip – you can safely restore your data onto your main
+device and decommission the travel device.
+
+[... truncated ...]
+
+---
+
+### PAGE: /infrastructure/domain-and-dns-security/overview
+**Title:** Domain & DNS Security | SEAL
+**Referenced by controls:** dns-4.1.1
+
+# Domain & DNS Security — Overview
+
+
+
+
+DNS (Domain Name System) is the backbone of the internet, translating domain names into IP addresses. In Web3, domain
+security is particularly critical as compromised domains can lead to irreversible financial losses through wallet
+drainers and phishing attacks. Unlike traditional web applications where stolen funds can sometimes be recovered,
+blockchain transactions are permanent.
+
+Moreover, DNS controls your email infrastructure through MX records - once compromised, attackers gain the keys to your
+entire organization through password resets and intercepted communications, making domain security a matter of both
+financial and operational survival.
+
+## Web3-Specific Considerations
+
+### Why Domain Security is Critical in Web3
+
+Domain security is exponentially more critical in Web3 compared to traditional web applications due to the unique
+characteristics of blockchain technology:
+
+- **Irreversible transactions**: Unlike traditional banking where stolen funds can sometimes be recovered, blockchain
+  transactions are permanent. Once funds are stolen through a domain hijack, they're gone forever.
+- **Direct wallet interactions**: Users connect their wallets directly to your domain, giving attackers immediate access
+  to user funds without needing to compromise individual accounts.
+- **Reputation damage**: One domain hijack incident can permanently destroy protocol trust, as users lose confidence in
+  the project's security practices.
+
+## Historical Context
+
+### Notable Domain Security Incidents
+
+Domain hijacking has impacted numerous Web3 projects:
+
+- **[Curve Finance (2025)](https://news.curve.finance/curve-domain-incident/)**: Domain hijacking at the registrar
+  level, unrelated to any breach of Curve's infrastructure.
+- **[Puffer Finance
+  (2024)](https://www.kucoin.com/news/articles/the-trojan-horse-of-web3-puffer-finance-attack-exposes-centralized-vulnerabilities)**:
+  DNS hijack exploited centralized infrastructure vulnerabilities
+- **[Compound Finance (2024)](https://www.bitget.com/news/detail/12560604092919)**: Domain takeover attempt prevented by
+  registry lock
+- **[Galxe (2023)](https://help.galxe.com/en/articles/8452958-october-6th-dns-security-incident-statement-guide)**: DNS
+  hijack resulted in over 1,100 wallets drained for $270k
+- **[Curve Finance (2022)](https://rekt.news/curve-finance-rekt)**: DNS hijacking led to $575k in stolen funds through
+  frontend compromise
+
+These incidents highlight the critical importance of proper domain security measures and the recurring nature of these attacks.
+
+## References and Resources
+
+### Incident Response Contacts
+
+- [SEAL Alliance TG Bot](https://t.me/seal_911_bot) - Web3 emergency response team
+- Your registrar's security team (document contact info)
+- Local FBI/law enforcement cybercrime division
+
+### Standards and Best Practices
+
+- [NIST Special Publication 800-81-2](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-81-2.pdf) -
+  Secure Domain Name System Deployment Guide
+- [ICANN DNSSEC Resources](https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en)
+- [RFC 8461](https://datatracker.ietf.org/doc/html/rfc8461) - MTA-STS specification
+- [RFC 7489](https://datatracker.ietf.org/doc/html/rfc7489) - DMARC specification
+- [DNS Security in Web3: Attacks & Monitoring Setup
+  Explained](https://web3secnews.substack.com/p/the-hidden-dns-threats-that-could) - Comprehensive Web3 DNS security
+  guide
+
+---
+
+---
+
+### PAGE: /opsec/google/overview
+**Title:** Google Workspace Security
+**Referenced by controls:** dns-4.1.2
+
+# Google Security
+
+
+
+
+## Summary
+
+> 🔑 **Key Takeaway:** Enhance your Google account security by implementing robust 2FA, eliminating redundant recovery
+> options, and diligently overseeing third-party access.
+
+**Google** provides a wide range of services—from email to file storage. Safeguarding your Google account is among the
+most critical steps you can take to protect your personal and professional data. Below are simple yet effective measures
+to improve your Google account security.
+
+---
+
+## For Individuals
+
+These settings apply to your personal Google account. All team members and admins should configure these on their own accounts.
+
+>This section does not include Google Suite or more advanced security configurations. For that, refer to the Operational
+> Security Framework, under [Google Suite Security](/opsec/old/cloud-third-party/g-suite-security).
+
+### Account Security Checklist
+
+- [Google Security Settings](https://myaccount.google.com/security):
+    - [ ]  Settings > Security > Skip passwords when possible > **Enabled**
+        - *Skipping password entry allows you to renew logins in public places without having to type out your password or store it in your clipboard*
+    - [ ]  Settings > Security > Recovery email > **Enabled**
+    - [ ]  Settings > Security > [Recovery phone](https://myaccount.google.com/signinoptions/rescuephone) > **Disabled**
+        - By default, Google allows account recovery using phone numbers and emails. Attackers can exploit these if they compromise your phone or email.
+        - **Optional**: If you're confident you won't need standard recovery processes, also remove [Recovery Email](https://myaccount.google.com/recovery/email)
+    - [ ]  Settings > Security > Third-party apps with account access > Remove all unnecessary
+        - Some apps request extensive permissions (e.g., full inbox or file access). Regularly review these to minimize risks.
+    - [ ]  Settings > Security > [Your devices](https://myaccount.google.com/device-activity) > Log out from all unnecessary devices
+        - Keeping track of active sessions helps you detect unauthorized access.
+    - [ ]  Security > Enhanced Safe Browsing > **Enabled**
+- [2-Step Verification](https://myaccount.google.com/signinoptions/two-step-verification):
+    - Properly setting up two-factor authentication (2FA) is one of the most crucial steps you can take. Disable SMS 2FA to avoid SIM swaps, and instead use an authenticator app or a hardware security key (preferred).
+    - [ ]  Enable any, but passkeys or authenticator recommended. You can also continue using **Google prompts**.
+    - [ ]  Disable "Voice or text message" if enabled
+    - [ ]  Remove any App passwords
+    - [ ]  Store Backup Codes offline in a secure place
+- [Google Connections](https://myaccount.google.com/connections):
+    - [ ]  Review each connected app's permissions; remove if unnecessary or excessive
+- [Google Profile](https://myaccount.google.com/profile):
+    - Publicly visible personal info can aid attackers in impersonating you.
+    - [ ]  Check Visibility: If any info is set to "Anyone," switch it to private if unnecessary
+    - [ ]  **Birthday:** Consider making it private
+
+---
+
+### Extended Security Settings
+
+For a comprehensive security review, follow these steps from [Google Security](https://myaccount.google.com/security):
+
+- [ ]  "Your connection to third-party apps & Services" > Revoke all applications that should not be connected
+- [ ]  "Log out of all unknown devices"
+- [ ]  "Turn off" skip password when possible (below previous step)
+- [ ]  "How you sign in with Google" > Set up your 2FA or Security Key
+- [ ]  Ensure you do not have a recovery phone setup. No SMS 2FA or phone number on your account at all.
+- [ ]  Change your password after completing these steps
+- [ ]  Note down your backup codes
+
+> If using Google Authenticator as a 2FA app on your phone, disconnect it from the cloud, as backup codes are then stored
+> in the google cloud associated to email. Use it without an account and ensure backup codes are written down offline.
+
+---
+
+### Advanced Protection Program
+
+For those who are public figures or need heightened security, Google's **Advanced Protection Program** is worth
+considering. It requires the use of security keys, limits access to unverified apps, and makes the process of account
+recovery more challenging.
+
+- [ ]  [Enroll in Advanced Protection Program](https://myaccount.google.com/advanced-protection/landing)
+
+---
+
+### Best Practices & Ongoing Maintenance
+
+- [ ]  **Review Security Alerts:** Pay attention to any email or phone notifications from Google regarding unusual sign-ins or account changes.
+- [ ]  **Perform a Security Checkup:** Regularly visit [Google's Security Checkup](https://myaccount.google.com/security-checkup) to identify potential issues and resolve them.
+- [ ]  **Consider** using identity **monitoring** apps like [Push Security](pushsecurity.com).
+
+---
+
+## For Team Members
+
+These guidelines apply to team members who use Google Workspace but don't have administrative access.
+
+Team members should:
+- Ensure their individual account settings are configured according to the checklist above
+- Pay attention to any email or phone notifications from Google regarding unusual sign-ins or account changes
+- Regularly visit [Google's Security Checkup](https://myaccount.google.com/security-checkup) to identify potential issues and resolve them
+
+---
+
+## For Admins
+
+These settings and practices apply to Google Workspace administrators with elevated privileges.
+
+### Admin Settings (Workspace Configuration)
+
+#### Rules and Notifications
+
+- [Rules](https://admin.google.com/ac/ax) > Enable notifications for security events
+    - [ ]  "User's password changed"
+    - [ ]  "Suspicious login"
+    - [ ]  "User granted Admin privilege"
+    - [ ]  "User's Admin privilege revoked"
+    - [ ]  "Primary admin changed"
+    - [ ]  "Leaked password"
+    - [ ]  "Device compromised" [[1]](#1-security-alerts)
+
+#### Security Settings
+
+- [ ]  Security > Overview > Less Secure Apps > **Disable access to less secure apps**
+- [ ]  Security > Authentication > 2-Step Verification > **Allow users to turn on 2-Step Verification**
+    - [ ]  Enforcement > **On**
+        - [ ]  Methods > **Any except verification codes via text, phone call** or **Only security key** [[2]](#2-2fa-enrollment)
+- Security > Authentication > Account Recovery >
+    - [ ]  Super admin account recovery > **On** (if fewer than 3 super admins on account)
+    - [ ]  User account recovery > **On**
+- [ ]  Security > Authentication > Password Management > **Enforce strong password**
+    - [ ]  Length > Minimum length > At least **12**
+- [ ]  Security > Access and data control > Google Cloud session control > Reauthentication policy > **Require reauthentication**
+    - [ ]  Exempt Trusted apps > **Off**
+    - [ ]  Reauthentication frequency > **16**
+
+#### Apps and Data Control
+
+- [ ]  Apps > Google Workspace > Drive and Docs > Sharing options >
+    - [ ]  Sharing outside of organization > **OFF** or **ALLOWLISTED DOMAINS**
+        - [ ]  Allow users in organization to receive files from users or shared drives outside of organization/allowlisted domains > **Off**
+        - [ ]  When sharing outside of organization is allowed, users in organization can make files and published web content visible to anyone with the link > **Off**
+    - [ ]  Distributing content outside of organization > **No one**
+- [ ]  Apps > Google Workspace > Settings for Google Chat > Service Settings > **OFF for everyone**
+
+#### Gmail Security
+
+- Apps > Google Workspace > Settings for Gmail >
+    - [ ]  Authenticate email > Set up **DKIM** with your DNS provider
+    - **Safety >**
+        - [ ]  Attachments > **Enable** all protections and set to quarantine
+        - [ ]  IMAP [view time protections](https://support.google.com/a/answer/10036904?sjid=9191352966703497335-NC) > **Enabled**
+        - [ ]  Links and external images > **Enable** all
+        - [ ]  Spoofing and authentication > **Enable** all and set to quarantine
+            - [ ]  **Protect against any unauthenticated emails** can be set to **Keep email in inbox and show warning** in order to prevent blocking external emails
+
+#### Email Authentication
+
+- **SPF & DMARC**
+    - Follow these guides to confirm and/or set up SPF and DMARC:
+        - https://support.google.com/a/answer/33786?hl=en&sjid=5876544508252018851-NC#spf-already-setup
+        - https://support.google.com/a/answer/2466580?hl=en#dmarc-step2
+
+#### Optional Enhancement
+
+- Enroll in the [Advanced Protection Program](https://landing.google.com/advancedprotection/) for high-risk users or your entire organization
+
+---
+
+### Notes
+
+#### [1] Security Alerts
+
+Other alerts should be enabled by default, but it is recommended to go through the list and enable any others that would indicate concerns.
+
+#### [2] 2FA Enrollment
+
+You can confirm user enrollment status at Directory > Users, under the **2-step verification enrollment** and **Advanced Protection Program enrollment** columns.
+
+---
+
+---
+
+### PAGE: /opsec/control-domains/technical
+**Title:** Technical Security Controls
+**Referenced by controls:** dns-5.1.3
+
+# Technical & Digital Controls
+
+
+
+
+Technical controls form the backbone of operational security, protecting systems, networks, and data from digital
+threats. This section outlines key technical controls that should be implemented as part of a comprehensive security
+program.
+
+## Device Hardening
+
+Securing devices by minimizing attack surfaces and implementing defensive configurations.
+
+### Key Components
+
+1. **Secure Configuration Baselines**: Standardized secure configurations for different device types
+2. **Endpoint Protection**: Anti-malware, application control, and other protective tools
+3. **OS Hardening**: Removing unnecessary services and securing operating systems
+4. **Patch Management**: Keeping systems updated with security patches
+5. **Local Firewall**: Controlling network connections at the device level
+
+### Implementation Steps
+
+1. Develop secure configuration baselines for each device type
+2. Implement endpoint protection solutions on all devices
+3. Remove or disable unnecessary services, applications, and features
+4. Establish an effective patch management process
+5. Configure local firewalls with appropriate rules
+6. Regularly scan for compliance with security baselines
+
+### Web3-Specific Considerations
+
+1. **Development Environments**: Securing environments used for smart contract development
+2. **Cold Storage Systems**: Hardening systems used for cryptocurrency key management
+3. **Transaction Signing Devices**: Enhanced security for devices used to sign transactions
+4. **Node Operation**: Specialized hardening for blockchain node infrastructure
+5. **Testing Environments**: Securing environments used for contract testing and simulation
+
+## Network & Communication Security
+
+Protecting data in transit and securing network infrastructure against attacks.
+
+### Key Components
+
+1. **Network Segmentation**: Dividing networks into security zones
+2. **Encrypted Communications**: Protecting data transmitted over networks
+3. **Secure Remote Access**: VPN and other secure access solutions
+4. **Network Monitoring**: Detecting suspicious network activity
+5. **Perimeter Security**: Firewalls, intrusion prevention, and other boundary protections
+
+### Implementation Steps
+
+1. Implement network segmentation based on security requirements
+2. Deploy encryption for all sensitive communications
+3. Establish secure remote access solutions with strong authentication
+4. Implement network monitoring and traffic analysis
+5. Deploy and properly configure perimeter security controls
+6. Regularly test network security through vulnerability assessments and penetration testing
+
+### Web3-Specific Considerations
+
+1. **Node Communication**: Securing blockchain node communications
+2. **API Security**: Protecting interfaces to blockchain services
+3. **RPC Endpoint Protection**: Securing remote procedure call endpoints
+4. **P2P Network Security**: Addressing risks in peer-to-peer networks
+5. **MEV Protection**: Mitigating risks related to maximal extractable value
+
+## Encrypted Storage & Backups
+
+Protecting data at rest through encryption and secure backup strategies.
+
+### Key Components
+
+1. **Full-Disk Encryption**: Encrypting entire storage devices
+2. **File-Level Encryption**: Protecting individual sensitive files
+3. **Key Management**: Securely managing encryption keys
+4. **Secure Backups**: Protecting backup data through encryption and access controls
+5. **Recovery Testing**: Verifying the ability to restore from backups
+
+### Implementation Steps
+
+1. Implement full-disk encryption on all devices storing sensitive data
+2. Deploy file-level encryption for particularly sensitive information
+3. Establish secure key management processes with appropriate access controls
+4. Implement encrypted and access-controlled backup solutions
+5. Regularly test backup recovery processes
+6. Store backup media securely with appropriate physical protections
+
+### Web3-Specific Considerations
+
+1. **Seed Phrase Backups**: Secure storage of wallet recovery information
+2. **Multi-Location Backups**: Distributing backup data to prevent single points of failure
+3. **Cold Storage Backups**: Offline backup strategies for critical keys
+4. **Smart Contract Backups**: Preserving contract source code and deployment parameters
+5. **Social Recovery Options**: Implementing secure social recovery systems for critical keys
+
+## Two-Factor & Hardware Authentication
+
+Strengthening authentication through multiple factors and hardware-based solutions.
+
+### Key Components
+
+1. **Multi-Factor Authentication**: Requiring multiple verification methods
+2. **Hardware Security Keys**: Physical devices for authentication
+3. **Biometric Authentication**: Using biological characteristics for verification
+4. **Time-Based One-Time Passwords**: Temporary codes for authentication
+5. **Single Sign-On Integration**: Centralizing and securing authentication
+
+### Implementation Steps
+
+1. Implement multi-factor authentication for all access to sensitive systems
+2. Deploy hardware security keys for high-value accounts and systems
+3. Establish backup authentication methods and recovery processes
+4. Integrate MFA with single sign-on solutions where appropriate
+5. Train users on proper use of authentication tools
+6. Regularly audit authentication configurations and access
+
+### Web3-Specific Considerations
+
+1. **Hardware Wallets**: Using dedicated devices for cryptocurrency transactions
+2. **Multi-Signature Setups**: Requiring multiple approvals for critical transactions
+3. **Air-Gapped Signing**: Using offline devices for transaction signing
+4. **Social Recovery**: Implementing secure key recovery through trusted contacts
+5. **DApp Authentication**: Securing connections to decentralized applications
+
+## Cryptocurrency-Specific Controls
+
+Technical controls specifically designed to address the unique security challenges of cryptocurrency operations.
+
+### Key Components
+
+1. **Wallet Security**: Technical measures to secure cryptocurrency wallets
+2. **Transaction Verification**: Processes to verify transaction details before signing
+3. **Key Management**: Secure generation, storage, and use of cryptographic keys
+4. **Blockchain Monitoring**: Tracking on-chain activity for anomalies
+5. **Smart Contract Security**: Technical controls for secure contract interaction
+
+### Implementation Steps
+
+1. Implement appropriate wallet solutions based on security requirements
+2. Establish transaction verification procedures with multiple checks
+3. Deploy secure key management practices and technologies
+4. Implement monitoring for blockchain transactions and activities
+5. Develop secure processes for smart contract interaction
+6. Regularly review and update cryptocurrency security controls
+
+### Web3-Specific Best Practices
+
+1. **Cold Storage**: Using offline systems for storing significant assets
+2. **Multi-Signature Wallets**: Requiring multiple approvals for transactions
+3. **Transaction Simulation**: Testing transactions before execution
+4. **Gas Limit Setting**: Controlling transaction costs and preventing attacks
+5. **Contract Interaction Verification**: Verifying contract behavior before approval
+
+Effective technical and digital controls provide a strong foundation for operational security. By implementing
+comprehensive device, network, data, and authentication protections, organizations can significantly reduce their attack
+surface and better protect their digital assets.
+
+---
+
+---
+
diff --git a/scripts/data/eval-briefs/sfc-incident-response.md b/scripts/data/eval-briefs/sfc-incident-response.md
new file mode 100644
index 00000000..dae3d3d1
--- /dev/null
+++ b/scripts/data/eval-briefs/sfc-incident-response.md
@@ -0,0 +1,2650 @@
+# Evaluation Brief: sfc-incident-response
+
+## TASK
+
+For each control below, evaluate whether the candidate framework pages ACTUALLY meet the baseline requirements.
+A page must SUBSTANTIVELY address the baseline — not just mention related keywords.
+Be strict: if a baseline says "reviewed at least annually" and the page doesn't mention review cadence, that baseline is NOT met.
+
+## CONTROLS (12 total)
+
+### ir-1.1.1: IR Team and Role Assignments
+**Question:** Do you have an incident response team with clearly defined roles and responsibilities?
+**Baselines (7):**
+  1. Incident commander (with designated backup) who coordinates response, assigns tasks, and makes time-sensitive decisions
+  2. Subject matter experts identified for key domains (smart contracts, infrastructure, security) who can analyze attacks and prepare response strategies
+  3. Scribe role defined for real-time incident documentation
+  4. Communications personnel designated for public information sharing and record-keeping
+  5. Legal support available with procedures for reviewing response actions, whitehat engagement, and public communications
+  6. Decision makers defined for high-stakes decisions (system shutdown, public disclosure, fund recovery)
+  7. Roles, authorities, and escalation measures reviewed at least annually and after protocol changes, team restructuring, or major incidents
+**Candidate pages:** /multisig-for-protocols/implementation-checklist, /multisig-for-protocols/emergency-procedures, /multisig-for-protocols/backup-signing-and-infrastructure
+
+### ir-1.1.2: Stakeholder Coordination and Contacts
+**Question:** Do you maintain current contacts and coordination procedures for all parties needed during an incident?
+**Baselines (7):**
+  1. Internal coordination procedures between technical (devs, auditors) and operational teams (security council, communications)
+  2. External protocol contacts for protocols you depend on and protocols that depend on you
+  3. External expertise contacts including forensics firms, security consultants, SEAL 911, and auditors
+  4. Legal counsel and communications/PR contacts
+  5. Infrastructure vendor support contacts and escalation procedures
+  6. Contact list reviewed at least quarterly and after team changes
+  7. Escalation order documented for P1 incidents (e.g., SEAL 911 → decision makers → security partners → legal)
+**Candidate pages:** /multisig-for-protocols/emergency-procedures, /incident-management/playbooks/seal-911-war-room-guidelines, /wallet-security/secure-multisig-best-practices
+
+### ir-2.1.1: Monitoring Coverage
+**Question:** Do you maintain monitoring coverage for your critical systems, protocols, and external attack surfaces?
+**Baselines (5):**
+  1. Monitoring covers critical smart contracts, infrastructure, and on-chain activity
+  2. 24/7 monitoring capabilities with procedures for after-hours alert handling
+  3. Credential and secret exposure detection including dark web monitoring, breach database scanning, and secret scanning in code repositories
+  4. Organizational account monitoring including social media accounts and websites monitored for unauthorized access or compromise
+  5. Monitoring coverage documented — what's covered, what's not, and known gaps
+**Candidate pages:** /infrastructure/domain-and-dns-security/monitoring-and-alerting, /incident-management/playbooks/seal-911-war-room-guidelines, /monitoring/guidelines
+
+### ir-2.1.2: Alerting, Paging, and Escalation
+**Question:** Do you have alerting and paging systems that reliably route incidents to available responders?
+**Baselines (8):**
+  1. Automated alerting configured for security events and operational issues
+  2. Alerts include embedded triage guidance for distinguishing true incidents from false positives
+  3. Triage and classification procedures documented with escalation paths based on severity
+  4. Time-based escalation triggers if initial responder doesn't acknowledge within defined window
+  5. Management notification requirements for high-severity incidents
+  6. Redundant paging systems with documented failover procedures
+  7. On-call schedules maintained with adequate coverage for operational needs
+  8. Backup procedures when on-call personnel are unreachable
+**Candidate pages:** /multisig-for-protocols/implementation-checklist, /multisig-for-protocols/backup-signing-and-infrastructure, /multisig-for-protocols/emergency-procedures
+
+### ir-2.1.3: Logging Integrity and Retention
+**Question:** Do you maintain tamper-evident logs with adequate retention for incident investigation?
+**Baselines (5):**
+  1. Log retention periods defined for security, infrastructure, and cloud provider logs
+  2. Retention adequate for forensic analysis (consider regulatory requirements and typical investigation timelines)
+  3. Tamper-evident logging for security-relevant events including access logs, alerting system logs, and infrastructure logs
+  4. Alerts triggered if logs are altered, deleted, or if monitoring/logging is disabled
+  5. Log sources documented — what's captured and where it's stored
+**Candidate pages:** /infrastructure/domain-and-dns-security/monitoring-and-alerting, /incident-management/playbooks/seal-911-war-room-guidelines, /governance/compliance-regulatory-requirements
+
+### ir-3.1.1: Response Playbooks
+**Question:** Do you maintain response playbooks for common incident types?
+**Baselines (5):**
+  1. Playbooks cover key scenarios including protocol exploits, infrastructure failures, access control breaches, key compromise, supply chain compromises, and frontend/DNS compromise
+  2. Each playbook includes initial response actions covering containment, evidence preservation, and stakeholder notification
+  3. Role-specific responsibilities defined for each scenario (who does what — technical, comms, legal)
+  4. Escalation criteria documented for when to engage leadership, when to shut down systems, when to make public disclosure, and when to engage external assistance
+  5. Key compromise playbook includes procedures for rotating keys and replacing compromised signers, with threshold and access reviewed after any signer replacement
+**Candidate pages:** /wallet-security/secure-multisig-best-practices, /multisig-for-protocols/emergency-procedures, /multisig-for-protocols/setup-and-configuration
+
+### ir-3.1.2: Signer Reachability and Coordination
+**Question:** Can you reach enough signers to execute emergency on-chain actions at any time, including outside business hours?
+**Baselines (4):**
+  1. Procedures for coordinating multisig operations during incidents, including cross-timezone signer availability
+  2. Signers integrated into on-call/paging systems
+  3. Escalation paths documented for when signers are unreachable
+  4. Tested quarterly
+**Candidate pages:** /wallet-security/secure-multisig-best-practices, /multisig-for-protocols/implementation-checklist, /multisig-for-protocols/setup-and-configuration
+
+### ir-3.1.3: Emergency Transaction Readiness
+**Question:** Do you have backup signing infrastructure and pre-prepared emergency transactions for critical protocol functions?
+**Baselines (3):**
+  1. Pre-signed or pre-prepared emergency transactions for critical protocol functions (pause, freeze, parameter changes) where feasible
+  2. Backup signing infrastructure available including alternate signing UI, backup RPC providers, and alternate block explorer
+  3. Emergency execution procedures documented (what to pause/freeze/modify and the process for doing so)
+**Candidate pages:** /multisig-for-protocols/backup-signing-and-infrastructure, /multisig-for-protocols/implementation-checklist, /wallet-security/seed-phrase-management
+
+### ir-4.1.1: Incident Communication Channels
+**Question:** Do you maintain secure, dedicated communication channels for incident response?
+**Baselines (4):**
+  1. Dedicated incident communication channels with documented access controls and member lists
+  2. Multiple communication channels (primary and backup) on different platforms, with documented failover procedures
+  3. Procedures for rapidly creating incident-specific channels (war room) when needed
+  4. Secure communication procedures for sensitive incident information including need-to-know access and encrypted channels
+**Candidate pages:** /multisig-for-protocols/implementation-checklist, /multisig-for-protocols/emergency-procedures, /multisig-for-protocols/backup-signing-and-infrastructure
+
+### ir-4.1.2: Internal Status Updates
+**Question:** Do you have procedures for providing regular status updates to stakeholders during incidents?
+**Baselines (2):**
+  1. Status update cadence defined by severity level
+  2. Format and distribution lists for internal stakeholders
+**Candidate pages:** /infrastructure/domain-and-dns-security/registrar-and-locks, /incident-management/communication-strategies, /multisig-for-protocols/personal-security-opsec
+
+### ir-4.1.3: Public Communication and Information Management
+**Question:** Do you have procedures for public communication and information management during incidents?
+**Baselines (4):**
+  1. Pre-approved communication templates for different incident types and severity levels
+  2. Procedures for coordinating communications with protocol users during and after incidents
+  3. Procedures for managing public information flow and correcting misinformation during active incidents
+  4. Designated communications approval flow before public statements are released
+**Candidate pages:** /incident-management/playbooks/seal-911-war-room-guidelines, /multisig-for-protocols/emergency-procedures, /multisig-for-protocols/implementation-checklist
+
+### ir-5.1.1: IR Drills and Testing
+**Question:** Do you conduct regular incident response drills and evaluate the results?
+**Baselines (7):**
+  1. Drills conducted at least annually
+  2. Drills cover different incident types across exercises (protocol exploit, infrastructure failure, key compromise, etc.)
+  3. Tests the full pipeline from monitoring through alerting, paging, triage, escalation, team coordination, containment, and recovery
+  4. Production alerting pipeline validated end-to-end from event detection through to responder notification and acknowledgment
+  5. Drill documentation includes date, scenario, participants, response times, gaps identified, and corrective actions
+  6. Corrective actions tracked to completion with owners and deadlines
+  7. Drill findings incorporated into playbook and procedure updates
+**Candidate pages:** /incident-management/playbooks/decentralized-ir, /multisig-for-protocols/emergency-procedures, /infrastructure/domain-and-dns-security/monitoring-and-alerting
+
+---
+
+## FRAMEWORK PAGES (14 unique)
+
+### PAGE: /multisig-for-protocols/implementation-checklist
+**Title:** Multisig Implementation Checklist | SEAL
+**Referenced by controls:** ir-1.1.1, ir-2.1.2, ir-3.1.2, ir-3.1.3, ir-4.1.1, ir-4.1.3
+
+# Implementation Checklist
+
+
+
+
+This checklist ensures all multisig participants have the knowledge and skills necessary for secure operations. Complete
+all applicable sections before beginning multisig operations.
+
+## For Multisig Administrators
+
+### Planning & Setup
+
+- [ ] I have classified my multisig using the impact and operational framework from [Planning & Classification](/multisig-for-protocols/planning-and-classification)
+- [ ] I have selected appropriate thresholds based on the classification guidance
+- [ ] I have identified and verified all signers for the multisig
+- [ ] I have deployed the multisig with correct configuration
+- [ ] I have set up required modules (eg. allowance module to rescue assets)
+
+### Documentation & Communication
+
+- [ ] I have classified and documented the new multisig using templates from [Registration & Documentation](/multisig-for-protocols/registration-and-documentation)
+- [ ] I have set up primary and backup communication channels per [Communication Setup](/multisig-for-protocols/communication-setup)
+- [ ] I have tested emergency notification procedures
+- [ ] I have documented emergency contact information
+
+### Ongoing Management
+
+- [ ] I have established procedures for regular reviews and updates per [Registration & Documentation](/multisig-for-protocols/registration-and-documentation)
+- [ ] I have set up backup infrastructure and tested alternative UIs per [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)
+- [ ] I have verified all signers have completed training requirements
+- [ ] I understand signer rotation procedures for my multisig type
+
+## For Signers
+
+### Hardware & Security Setup
+
+- [ ] I have purchased recommended hardware wallet from authorized source per [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds)
+- [ ] I have set up my hardware wallet with proper firmware and PIN
+- [ ] I have created and tested backup hardware wallet with same seed
+- [ ] I have stored my seed phrase securely using approved methods from [Seed Phrase Management](/wallet-security/seed-phrase-management)
+- [ ] I have created dedicated accounts for each multisig I'm signing for
+
+### Operational Readiness
+
+- [ ] I have joined multisig communication channels (primary and backup) per [Communication Setup](/multisig-for-protocols/communication-setup)
+- [ ] I have verified my signer address using the required signature process from [Joining a Multisig](/multisig-for-protocols/joining-a-multisig)
+- [ ] I understand my multisig's classification and response time requirements
+- [ ] I have completed a test transaction with the multisig team
+
+### Transaction Verification
+
+- [ ] I can use approved verification tools (Safe CLI Utils, OpenZeppelin SafeUtils for EVM) from [Tools & Resources →
+  Transaction Verification](/wallet-security/tools-&-resources#transaction-verification)
+- [ ] I understand how to verify transaction hashes before signing
+- [ ] I can decode and verify transaction details (amounts, recipients, contract calls)
+- [ ] I have practiced verifying both simple transfers and complex transactions
+
+### Emergency Preparedness
+
+- [ ] I have downloaded backup UIs (Eternal Safe for EVM, Squads public client for Solana) per [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)
+- [ ] I know how to sign transactions when primary UI is down per [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)
+- [ ] I understand emergency procedures for key compromise and communication failures per [Emergency Procedures](/multisig-for-protocols/emergency-procedures)
+- [ ] I have tested backup communication methods with my team
+- [ ] I know who to contact for security incidents and emergencies per [Incident Reporting](/multisig-for-protocols/incident-reporting)
+
+### Personal Security
+
+- [ ] I have enabled 2FA on all accounts with approved methods (YubiKey preferred) per [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec)
+- [ ] I use dedicated devices or accounts for multisig operations when required
+- [ ] I have implemented travel security procedures appropriate for my risk level
+- [ ] I understand incident reporting procedures for security concerns
+
+### Compliance
+
+- [ ] I have read and understand all sections of this security framework
+- [ ] I understand my specific role requirements based on multisig classification
+- [ ] I know how to properly offboard when leaving a multisig role per [Offboarding](/multisig-for-protocols/offboarding)
+- [ ] I commit to following these security procedures and reporting any deviations
+
+## Specialized Training by Use Case
+
+### Emergency Response Multisigs
+
+Additional requirements from [Use Case Specific Requirements](/multisig-for-protocols/use-case-specific-requirements):
+
+- [ ] I understand 24/7 availability requirements
+- [ ] I have participated in emergency simulation drills
+- [ ] I know how to respond to emergency paging
+- [ ] I understand streamlined verification procedures for emergencies
+
+### Treasury Multisigs
+
+- [ ] I understand allowance module configuration and purpose
+- [ ] I know governance rescue procedures
+- [ ] I understand financial reporting requirements
+
+### Smart Contract Control Multisigs
+
+- [ ] I understand timelock configuration per [Use Case Specific Requirements → Timelock Configuration](/multisig-for-protocols/use-case-specific-requirements#timelock-configuration)
+- [ ] I know how to verify staged transactions
+- [ ] I understand higher threshold requirements for upgrades
+
+## Practical Skills Assessment
+
+### Transaction Verification (EVM)
+
+- [ ] I can successfully verify a Safe transaction hash using CLI tools
+- [ ] I can decode transaction calldata and identify recipients and amounts
+- [ ] I can identify risky transaction types and warnings
+- [ ] I can verify nested Safe transactions if applicable
+
+### Transaction Verification (Solana)
+
+- [ ] I can analyze Solana transaction instruction data
+- [ ] I can convert hex values to decimal for amount verification
+- [ ] I can identify different transaction types (SOL transfer, token transfer, config changes)
+
+### Emergency Procedures
+
+- [ ] I can access backup UIs and complete a transaction
+- [ ] I can contact team via backup communication channels
+- [ ] I know how to report key compromise immediately
+- [ ] I can execute identity verification procedures if needed
+
+### Tool Proficiency
+
+- [ ] I am comfortable using my hardware wallet for signing
+- [ ] I can navigate backup block explorers
+- [ ] I can use alternative RPC endpoints
+- [ ] I understand how to manually simulate transactions
+
+## Documentation Review
+
+### Required Reading Completed
+
+- [ ] [Secure Multisig Best Practices](/wallet-security/secure-multisig-best-practices) - Core requirements for all multisigs
+- [ ] [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds) - Device security requirements
+- [ ] [Seed Phrase Management](/wallet-security/seed-phrase-management) - Key protection procedures
+- [ ] [Safe Multisig: Step-by-Step
+Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification) - Signing procedures
+- [ ] [Emergency Procedures](/multisig-for-protocols/emergency-procedures) - Crisis response protocols
+- [ ] [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec) - Account and device security
+
+### Role-Specific Documentation
+
+**For Administrators:**
+
+- [ ] [Planning & Classification](/multisig-for-protocols/planning-and-classification)
+- [ ] [Setup & Configuration](/multisig-for-protocols/setup-and-configuration)
+- [ ] [Registration & Documentation](/multisig-for-protocols/registration-and-documentation)
+- [ ] [Communication Setup](/multisig-for-protocols/communication-setup)
+- [ ] [Registration & Documentation](/multisig-for-protocols/registration-and-documentation)
+
+**For Specialized Use Cases:**
+
+- [ ] [Use Case Specific Requirements](/multisig-for-protocols/use-case-specific-requirements)
+- [ ] [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)
+- [ ] [Use Case Specific Requirements → Timelock Configuration](/multisig-for-protocols/use-case-specific-requirements#timelock-configuration)
+  (if applicable)
+
+## Certification and Acknowledgment
+
+### Training Completion
+
+- [ ] I have completed all applicable training requirements
+- [ ] I have successfully demonstrated practical skills
+- [ ] I understand the security implications of my role
+- [ ] I acknowledge my responsibilities as a multisig participant
+
+### Ongoing Commitment
+
+- [ ] I commit to following all security procedures outlined in this framework
+- [ ] I will report any security incidents or concerns promptly
+- [ ] I will participate in regular training updates and refreshers
+- [ ] I will maintain the required level of security for my role
+
+### Trainer Verification (if applicable)
+
+**For organizations requiring formal training:**
+
+Trainer: _________________ Date: _________________
+
+Trainee has demonstrated competency in:
+
+- [ ] Transaction verification procedures
+- [ ] Emergency response protocols
+- [ ] Security best practices
+- [ ] Role-specific requirements
+
+**Signature:** _________________
+
+## Refresher Training Schedule
+
+### Regular Updates
+
+- **Monthly**: Review emergency procedures and contact information
+- **Quarterly**: Practice backup system usage and emergency drills
+- **Annually**: Complete full framework review and updates
+- **As needed**: Training on new tools, procedures, or threats
+
+### Trigger Events
+
+Additional training required after:
+
+- Framework updates or changes
+- Security incidents affecting the team
+- New tool adoption
+- Role changes or additional responsibilities
+
+## Related Documents
+
+All documents in this framework serve as training materials. Refer to individual documents for detailed procedures and
+requirements specific to your role.
+
+---
+
+### PAGE: /multisig-for-protocols/emergency-procedures
+**Title:** Multisig Emergency Procedures | SEAL
+**Referenced by controls:** ir-1.1.1, ir-1.1.2, ir-2.1.2, ir-3.1.1, ir-4.1.1, ir-4.1.3, ir-5.1.1
+
+# Emergency Procedures
+
+
+
+
+When security incidents occur, quick and decisive action is critical. This page covers procedures for key compromise,
+lost access, and communication breaches.
+
+## Key Compromise
+
+### Immediate Actions (Within 30 Minutes)
+
+1. **Stop operations** - Halt all non-emergency transactions
+2. **Notify team** - Alert via all communication channels using emergency notification template
+3. **Assess scope** - Determine which keys may be compromised
+4. **Escalate** - Contact Security team immediately
+5. **Document** - Record timeline and details
+
+### Recovery Process
+
+1. **Isolate** - Quarantine potentially compromised devices
+2. **New hardware setup** - Set up fresh wallet with new seed following [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds)
+3. **Coordinate replacement** - Plan signer replacement transaction with team
+4. **Execute replacement** - Replace compromised signer on multisig, following steps for signer rotation in [Secure
+   Multisig Best Practices](/wallet-security/secure-multisig-best-practices)
+5. **Verify security** - Confirm new setup before resuming operations
+
+## Lost Key Access
+
+### Immediate Steps
+
+1. **Try backup device first** if available
+2. **Contact team immediately** via backup communication channels
+3. **Do not panic** - Lost access doesn't mean compromised keys
+4. **Document the situation** - Record what happened and when
+
+### Identity Verification Process
+
+Since you can't sign with your key, verify identity through alternative methods:
+
+- **Video call** with other signers
+- **Authentication** via verified social media account
+- **Other pre-arranged verification methods**
+
+### Replacement Coordination
+
+1. **Generate new hardware wallet** following standard setup procedures in [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds)
+2. **Verify new address** through identity verification process above
+3. **Coordinate timing** with other signers for replacement transaction
+4. **Execute replacement** once team confirms identity
+5. **Update documentation** with new signer information
+
+## Communication Account Compromise
+
+### If Telegram/Signal/Discord Gets Taken Over
+
+#### Immediate Actions
+
+1. **Assume all recent messages are suspect** - Don't trust recent communication
+2. **Use backup channels** to alert team about compromise
+3. **Change passwords** and enable additional security on compromised account
+
+#### Team Verification Process
+
+**For the compromised person:**
+
+- Use alternative contact methods (email, phone, other platforms)
+- Verify identity through video call or pre-arranged methods
+- Provide proof of the compromise (screenshots, platform confirmation)
+
+**For other team members:**
+
+- Verify all recent requests from compromised account
+- Cancel any pending transactions initiated via compromised communication
+- Require additional verification for any future requests until resolved
+
+#### Recovery Steps
+
+1. **Regain account control** through platform recovery processes
+2. **Enable maximum security** (2FA, security keys, session management)
+3. **Review recent message history** for unauthorized communications
+4. **Alert team** when account is secured and verified clean
+5. **Resume normal operations** only after team confirms account security
+
+## Emergency Notification Template
+
+Use this template for security incidents or key compromises:
+
+```
+Subject: [URGENT] Multisig Security Incident - [Multisig Name]
+
+Immediate details:
+- Multisig address: [ADDRESS]
+- Classification: [Impact Level / Operational Type]
+- Incident type: [Key Compromise / Communication Failure / System Issue]
+- Time of discovery: [TIMESTAMP]
+- Reporting signer: [NAME/HANDLE]
+
+Situation summary: [Brief description of what happened and current status]
+
+Immediate actions taken:
+□ Stopped non-emergency operations
+□ Isolated affected systems
+□ Notified team members
+□ [Other actions]
+
+Next steps required:
+□ Security team assessment
+□ Key rotation process
+□ Emergency transaction execution
+□ [Other actions]
+
+Current multisig status:
+- Available signers: [X/Y]
+- Communication status: [Operational/Compromised]
+- Operational capability: [Full/Limited/Suspended]
+```
+
+## Emergency Communication Protocols
+
+### Multi-Channel Notification
+
+- **Primary channel**: Alert via main communication channel
+- **Backup channels**: Simultaneously notify via backup platforms
+- **Emergency contacts**: Use emergency contact procedures if established
+
+### Identity Verification
+
+- **Code words**: Use pre-established verification phrases
+- **Multiple confirmations**: Verify through multiple channels
+- **Video verification**: Use video calls for critical confirmations
+
+### Information Sharing
+
+- **Need-to-know basis**: Share only essential information
+- **Secure channels only**: Use most secure available communication
+- **Documentation**: Record all emergency communications
+
+## Operational Emergency Procedures
+
+### For Emergency Response Multisigs
+
+#### Rapid Response Protocol
+
+1. **Immediate assessment** - Determine scope and urgency
+2. **Signer activation** - Contact threshold number of signers
+3. **Streamlined verification** - Use minimal verification appropriate for risk level
+4. **Execute response** - Implement emergency measures
+5. **Post-action review** - Document and assess response effectiveness
+
+#### 24/7 Availability
+
+- **Geographic distribution** - Ensure coverage across time zones
+- **Backup signers** - Have additional signers available for activation
+- **Communication redundancy** - Multiple ways to reach each signer
+
+### Emergency Drill Procedures
+
+#### Regular Testing Schedule
+
+- **Quarterly**: Communication system tests
+- **Bi-annually**: Emergency paging system tests
+- **Annually**: Full emergency simulation with all signers
+
+#### Drill Components
+
+1. **Notification test** - Verify all signers receive alerts
+2. **Response time measurement** - Track time to threshold signatures
+3. **Process verification** - Ensure procedures work under pressure
+4. **Documentation review** - Update procedures based on drill results
+
+## Recovery and Post-Incident
+
+### Immediate Recovery
+
+1. **Restore operations** - Resume normal operations once threat is mitigated
+2. **Monitor for issues** - Watch for any residual security concerns
+3. **Update security measures** - Implement additional controls if needed
+
+### Post-Incident Analysis
+
+1. **Root cause analysis** - Determine how incident occurred
+2. **Process improvement** - Update procedures to prevent recurrence
+3. **Team debriefing** - Gather lessons learned from all participants
+4. **Documentation updates** - Revise emergency procedures based on experience
+
+### Communication
+
+1. **Team notification** - Inform team when incident is resolved
+2. **Stakeholder updates** - Notify relevant parties as appropriate
+3. **Documentation** - Complete incident report for future reference
+
+## Emergency Contact Information
+
+### Security Team Contact
+
+- **Email**: [Security team email]
+- **Emergency escalation**: [24/7 emergency contact if available]
+- **Communication**: Use subject line format from emergency notification template
+
+### Internal Escalation
+
+- **Protocol leadership**: [Contact information]
+- **Technical team**: [Emergency technical contact]
+- **Legal/compliance**: [If regulatory notification required]
+
+## Related Documents
+
+- [Incident Reporting](/multisig-for-protocols/incident-reporting) - Formal incident reporting procedures
+- [Communication Setup](/multisig-for-protocols/communication-setup) - Backup communication channels
+- [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds) - Device replacement procedures
+- [Seed Phrase Management](/wallet-security/seed-phrase-management) - Key recovery procedures
+- [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec) - Account security measures
+
+---
+
+### PAGE: /multisig-for-protocols/backup-signing-and-infrastructure
+**Title:** Backup Signing & Infrastructure | SEAL
+**Referenced by controls:** ir-1.1.1, ir-2.1.2, ir-3.1.3, ir-4.1.1
+
+TagList,
+  AttributionList,
+  TagProvider,
+  TagFilter,
+  ContributeFooter,
+} from "../../../components";
+
+
+
+
+# Backup Signing & Infrastructure
+
+
+
+
+If the default interfaces for either Safe or Squads are down or suspected of being compromised, these alternatives
+enable continued critical signing operations. As a signer, you should familiarize yourself with these tools and practice
+signing transactions with your team.
+
+## UI Alternatives
+
+### EVM Networks
+
+**Eternal Safe - Decentralized fork of Safe\{Wallet\}**
+
+- GitHub: [https://github.com/eternalsafe/wallet](https://github.com/eternalsafe/wallet)
+- Hosted (IPFS): [https://eternalsafe.eth.limo](https://eternalsafe.eth.limo) (requires bring your own RPC)
+- Local: Can be downloaded and run locally
+
+Note: Local/alternative UIs may not be actively maintained. Treat them as emergency options and perform extra
+verification. Please DYOR.
+
+### Solana
+
+**Squads Public Client - Open source Squads V4 interface: **
+
+- GitHub: [https://github.com/Squads-Protocol/public-v4-client](https://github.com/Squads-Protocol/public-v4-client)
+- Features: Verifiable build, self-hostable with Docker, IPFS distribution
+- Local: Can be built and run locally
+
+### Mobile (Safe)
+
+**Safe Mobile Apps: **
+
+- GitHub: [https://github.com/safe-global/safe-wallet-monorepo/tree/dev/apps/mobile](https://github.com/safe-global/safe-wallet-monorepo/tree/dev/apps/mobile)
+- App Store: [https://apps.apple.com/us/app/safe-mobile/id6748754793](https://apps.apple.com/us/app/safe-mobile/id6748754793)
+- Play Store: [https://play.google.com/store/apps/details?id=global.safe.mobileapp](https://play.google.com/store/apps/details?id=global.safe.mobileapp)
+
+## RPC Backup Options
+
+### Basic guidance:
+
+- Multiple providers: Set up accounts with 2-3 different RPC services
+  - eg. Alchemy, Infura, Chainstack, Quicknode, Tenderly
+- Avoid correlation: Choose providers that don't share infrastructure, if that information is available
+- Private RPCs preferred: Public RPC URLs are typically not sufficient for reliable operation
+
+### Administrator responsibilities
+
+Ensure signer preparedness:
+
+- Provide access to offline UI tools listed above
+- Verify signers have practiced using backup interfaces
+- Test backup RPCs during non-emergency periods
+- Document procedures for switching to backup infrastructure
+
+## Block Explorer Backup Options
+
+### EVM Networks
+
+Etherscan provides the default block explorer for nearly all EVM chains. In the event that Etherscan is compromised or
+goes down, it is important to have backup options that can be used for monitoring and investigating transactions.
+
+**Blockscout - Open source Etherscan alternative: **
+
+- [https://www.blockscout.com/](https://www.blockscout.com/)
+- Available for all EVM networks
+- Can also be [self-hosted](https://github.com/blockscout/blockscout), although it requires significant time to run full
+  node and index
+
+More explorers: A broader list of network explorers is maintained here: [https://explorer.swiss-knife.xyz/](https://explorer.swiss-knife.xyz/)
+
+### Solana Networks
+
+Both explorer.solana.com and Solscan are reliable options for Solana transaction exploration and decoding.
+
+**explorer.solana.com** - [https://explorer.solana.com/](https://explorer.solana.com/)
+
+- Can be [self-hosted](https://github.com/solana-foundation/explorer) using open source code
+
+**Solscan** - [https://solscan.io/](https://solscan.io/)
+
+## Preparation
+
+**It is recommended to download dependencies ahead of time and store them in a secure location** so they are easily
+accessible during emergencies.
+
+## EVM Networks
+
+### Eternal Safe - Decentralized fork of Safe\{Wallet\}
+
+#### Access Options
+
+- **GitHub**: [https://github.com/eternalsafe/wallet](https://github.com/eternalsafe/wallet)
+- **Hosted (IPFS)**: [https://eternalsafe.eth.limo](https://eternalsafe.eth.limo) (requires bring your own RPC)
+- **Local**: Can be downloaded and run locally
+
+#### Setup
+
+1. Select network and enter an RPC URL
+   <div align="center">
+     <img
+       src="https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/eternal-safe-network-selection.png"
+       alt="Eternal Safe network selection"
+       style={{ height: "400px" }}
+     />
+     <p>
+       <em>
+         Eternal Safe network selection screen: choose your network and enter an
+         RPC URL
+       </em>
+     </p>
+   </div>
+2. Enter Safe address and load
+   ![Eternal Safe address entry](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/eternal-safe-address-entry.png)
+3. Eternal Safe will automatically detect Ether balances but not ERC20 tokens. They can be added manually
+   ![Eternal Safe token configuration](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/eternal-safe-token-configuration.png)
+
+#### Transaction Verification
+
+**Critical**: It is still essential to verify hashes and calldata from Eternal Safe. Follow the verification steps in
+[Safe Multisig: Step-by-Step Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification).
+
+#### Smart Link System
+
+Once a transaction has been signed by one signer, a **Smart Link** is created which can be forwarded to the next signer
+to add their signature. The transactions do not go to any centralized backend.
+
+**Example Smart Link:**
+
+```
+Please sign this Eternal Safe transaction for the Safe: base:0xA79C6968E3c75aE4eF388370d1f142720D498fEC.
+Current confirmations: 1 of 2.
+https://eternalsafe.eth.limo/transactions/tx/?safe=base:0xA79C6968E3c75aE4eF388370d1f142720D498fEC&tx=eyJzaWduYXR1cmVzIjp7ImRhdGFUeXBlIjoiTWFwIiwidmFsdWUiOltbIjB4NDBiYjMyZjA4NjJkMjI3ODEzYzg2ZmQ4M2E3YjNjOWRiOTA3NGUyYSIseyJzaWduZXIiOiIweDQwYkIzMkYwODYyRDIyNzgxM2M4NkZEODNBN0IzYzlkYjkwNzRFMkEiLCJkYXRhIjoiMHgwZDMxZTZjODIxZjBhMGZlM2M5NmNlZWY4ZDNhM2JhZmU3YmZmZTliODQ0ZWNkYzBkYWNmNzc0MzFkODQ0NjU4MTgwZjUwNmZlMjZiZjMzOTQwY2VhOTJiMzlhNDNjODRkMDRhNThiMGY1ODQ2NzhlNzE0YTllMWJkMzE0NTg5ZjFiIn1dXX0sImRhdGEiOnsiZGF0YSI6IjB4IiwiYmFzZUdhcyI6IjAiLCJnYXNQcmljZSI6IjAiLCJzYWZlVHhHYXMiOiIwIiwiZ2FzVG9rZW4iOiIweDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAiLCJub25jZSI6NCwicmVmdW5kUmVjZWl2ZXIiOiIweDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAiLCJ2YWx1ZSI6IjEwMDAwMDAwMDAwMDAwMDAiLCJ0byI6IjB4RTBiY2ZlNWUzMEFCYTBCNDZmMTNCMEMyNENiQzQ3MERDQTNlYjg2NSIsIm9wZXJhdGlvbiI6MH19
+```
+
+#### Execution
+
+Once all signatures are collected, execute the transaction. **Note**: Prior to execution you can manually simulate using
+Tenderly by entering the transaction data, but an automatic simulation link will not be available.
+
+## Solana
+
+### Squads Public Client - Open source Squads V4 interface
+
+#### Access Options
+
+- **GitHub**: [https://github.com/Squads-Protocol/public-v4-client](https://github.com/Squads-Protocol/public-v4-client)
+- **Hosted**: [https://backup.app.squads.so/](https://backup.app.squads.so/)
+- **Features**: Verifiable build, self-hostable with Docker, IPFS distribution
+- **Local**: Can be built and run locally
+
+#### Setup
+
+1. If running locally, follow setup instructions in [https://github.com/Squads-Protocol/public-v4-client](https://github.com/Squads-Protocol/public-v4-client)
+ and access via `http://localhost:8080`
+2. Enter RPC URL in settings
+   ![Squads RPC configuration](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/squads-rpc-configuration.png)
+3. Enter multisig address in the **lower** text box (Search for Multisig Config) and select the detected Multisig Config
+   ![Squads multisig selection](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/squads-multisig-selection.png)
+
+#### Transaction Operations
+
+1. Create, approve, or execute transactions. _Smart Links_ are not needed for Solana as all transactions are on chain
+   and accessible via the RPC without an API
+   ![Squads transaction interface](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/squads-transaction-interface.png)
+
+## Security Considerations
+
+### Enhanced Verification
+
+When using backup systems:
+
+- **Extra caution required**: Be more thorough with verification procedures
+- **Multiple verification methods**: Use additional tools to cross-check transaction details
+- **Team confirmation**: Verify with other signers before proceeding with critical transactions
+- **Documentation**: Record use of backup systems and any issues encountered
+
+### Risk Assessment
+
+- **Delay non-critical operations**: Consider postponing non-urgent transactions until primary systems recover
+- **Emergency operations only**: For critical emergency responses, proceed with enhanced verification
+- **Communication**: Keep team informed about system status and verification procedures
+
+## Testing and Preparation
+
+### Regular Practice
+
+- **Monthly testing**: Practice using backup interfaces during normal operations
+- **Team coordination**: Ensure all signers can operate backup systems
+- **Process documentation**: Update procedures based on practice sessions
+
+### Emergency Drills
+
+- **Simulated outages**: Practice coordinating with backup systems during drills
+- **Communication testing**: Verify backup communication channels work with backup UIs
+- **Time measurement**: Track how long backup system activation takes
+
+## Troubleshooting
+
+### Common Issues
+
+- **RPC connectivity**: Switch to alternative RPC providers if connection fails
+- **Transaction loading**: Refresh or try different network endpoints
+- **Signature verification**: Use multiple verification tools when in doubt
+
+### Support Resources
+
+- **GitHub documentation**: Refer to project documentation for technical issues
+- **Team assistance**: Coordinate with other signers for problem-solving
+- **Alternative tools**: Have multiple backup options available
+
+## Related Documents
+
+- [Safe Multisig: Step-by-Step
+Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification) - Verification procedures
+- [Emergency Procedures](/multisig-for-protocols/emergency-procedures) - General emergency response
+- [Communication Setup](/multisig-for-protocols/communication-setup) - Backup communication during outages
+
+---
+
+### PAGE: /incident-management/playbooks/seal-911-war-room-guidelines
+**Title:** SEAL 911 War Room Guidelines | SEAL
+**Referenced by controls:** ir-1.1.2, ir-2.1.1, ir-2.1.3, ir-4.1.3
+
+# SEAL 911
+
+
+
+
+SEAL 911 is a project designed to give users, developers, and even other security researchers an accessible method to
+contact a small group of highly trusted security researchers. The group can be reached via the [Telegram
+bot](https://t.me/seal_911_bot).
+
+Members of SEAL 911 follow a strict
+[CODE OF CONDUCT](https://github.com/security-alliance/seal-911/blob/main/CODE_OF_CONDUCT.md).
+
+When interacting with SEAL 911, ensure that you give as much information as possible in order to avoid double work by
+the security researchers.
+
+## Crisis Handbook - Smart Contract Hack | [Google Doc](https://docs.google.com/document/d/1DaAiuGFkMEMMiIuvqhePL5aDFGHJ9Ya6D04rdaldqC0/edit#heading=h.c4h2beeflqpo)
+
+### Actions Checklist
+
+### Perform Immediately
+
+- [ ] Notify SEAL 911 Bot of the incident. Use this message template to get started.
+- [ ] Create a War Room with audio and share the invite link with trusted individuals.
+- [ ] Duplicate this document to allow collaboration and share the link in the War Room.
+- [ ] Review the Advice to Keep in Mind section.
+
+### Perform in Parallel by Role
+
+1. **Assign Key Roles to War Room Members**:
+   - [ ] Assign members to specific roles.
+
+2. **Analysis**:
+   - [ ] Scope the impact of the attack.
+   - [ ] Gather Transactions Involved.
+   - [ ] Gather Affected Addresses.
+   - [ ] Record Funds Movement.
+   - [ ] Gather Attacker Information.
+   - [ ] Investigate the issue and update the Issue Description.
+   - [ ] Propose workable solutions.
+
+3. **Protocol actions**:
+   - [ ] Take immediate corrective/preventative actions to prevent further loss of funds.
+   - [ ] Pause contracts if possible.
+   - [ ] Execute pre-made defensive scripts.
+   - [ ] Prioritize proposed solutions.
+   - [ ] Validate and execute the solution.
+   - [ ] Prepare monitoring alerts for situations that require future actions.
+
+4. **Web actions**:
+   - [ ] Disable deposits and/or withdrawals as needed in the web UI.
+   - [ ] Enable front-end IP or Address blacklisting.
+   - [ ] Create front-end for any user actions necessary (approval revoking, fund migrating, etc.).
+
+5. **Communications**:
+   - [ ] Identify social platforms that communications on the incident must be sent to.
+   - [ ] Prepare messages for incident communication internally and externally.
+   - [ ] Gather security contacts for any potentially affected downstream protocols (bridges, lending protocols).
+   - [ ] Notify block explorers (like Etherscan) for attacker address labeling.
+   - [ ] Continuously monitor social media for users providing additional information that aids whitehat efforts.
+   - [ ] Monitor War Room efforts and maintain the Event Timeline.
+
+### After all of the above is complete, consider Post Incident Actions
+
+## Information Gathering
+
+Information will primarily be shared and acted upon in the War Room. As time allows, consolidate intel in the below
+section to achieve the following:
+
+- Accurately scope the incident impact.
+- Inform new War Room members and third parties efficiently.
+- Aid external communication.
+
+This is the chief duty of the Scribe.
+
+### Issue Description
+
+The issue involves an unauthorized transfer of funds from the protocol's treasury contract due to a vulnerability in the
+contract's access control mechanism. The attacker exploited this vulnerability to initiate multiple transfers,
+siphoning funds to an external wallet.
+
+### Events Timeline
+
+Record events to construct an overall timeline of the incident. Events worth recording:
+
+- First notice of the incident
+- War room creation
+- External communications
+- Attack transactions
+- Transactions performed by the team
+
+Record times in UTC. Use a UTC Time Converter.
+
+| Date-Time (UTC) | Event Description | Notes |
+| --- | --- | --- |
+| 2024-08-23 12:45 | First notice of the unauthorized transfer | Alert received via monitoring system |
+| 2024-08-23 12:50 | War room created | Initial members invited |
+| 2024-08-23 13:05 | Notified SEAL 911 Bot | Incident report submitted |
+| 2024-08-23 13:15 | Attack transaction identified | Transaction hash: 0x123456789abc |
+| 2024-08-23 13:20 | Contracts paused | Prevented further fund transfers |
+| 2024-08-23 13:30 | External communication initiated | First update sent via Twitter |
+
+### Transactions Involved
+
+Record all transactions related to the incident.
+
+| Transaction Link | Notes |
+| --- | --- |
+| [0x123456789abcdef...](https://etherscan.io/tx/0x123456789abcdef) | Initial exploit transaction |
+| [0xabcdef123456789...](https://etherscan.io/tx/0xabcdef123456789) | Attacker moving funds to mixer |
+| [0xfedcba987654321...](https://etherscan.io/tx/0xfedcba987654321) | Defensive move by the team |
+
+### Affected Addresses
+
+Record affected addresses related to the incident (protocol contracts, bridges, users, etc.).
+
+| Address Link | Status | Notes |
+| --- | --- | --- |
+| [0x1111222233334444...](https://etherscan.io/address/0x11112222) | At Risk | User wallet, interacted with exploit |
+| [0x5555666677778888...](https://etherscan.io/address/0x55556666) | Impacted | Protocol treasury address |
+| [0x99990000aaaabbbb...](https://etherscan.io/address/0x99990000) | Paused | Lending protocol contract |
+| [0xaaaabbbbccccdddd...](https://etherscan.io/address/0xaaaabbbb) | Saved | Bridge contract, funds secured |
+| [0xddddeeeeffff0000...](https://etherscan.io/address/0xddddeeee) | Needs Review | User wallet, unusual activity noted |
+| [0x2222333344445555...](https://etherscan.io/address/0x22223333) | Uncertain | User wallet, pending analysis |
+
+### Funds Movement
+
+Record funds movement to gather the impact of the incident and organize recovery efforts.
+
+- Original address that held the funds
+- Transaction that moved the funds
+- Assets and amounts the funds are comprised of
+- Destination the funds moved to (Contract, CEX, Bridge, Mixer)
+- Recovery Status of the funds
+
+Use Phalcon Tx Explorer to aid in recording funds movement.
+
+| Origin | Transaction Link | Amount / Asset | Destination | Recovery Status | Notes |
+| --- | --- | --- | --- | --- | --- |
+| [0x5555666677778888...](https://etherscan.io/address/0x5555) | [0xabcdef123456789...](https://etherscan.io/tx/0xabcdef) | 1000 ETH | [Mixer address](https://etherscan.io/address/0x12) | Needs Review | Funds moved to Tornado Cash |
+| [0x99990000aaaabbbb...](https://etherscan.io/address/0x9999) | [0x9876543210fedcba...](https://etherscan.io/tx/0x987654) | 500,000 DAI | [CEX address](https://etherscan.io/address/0x34) | In Progress | Funds transferred to centralized exchange |
+| [0xaaaabbbbccccdddd...](https://etherscan.io/address/0xaaaa) | [0x123456789abcdef...](https://etherscan.io/tx/0x123456) | 200 BTC | [Contract address](https://etherscan.io/address/0x56) | Recovered | Funds recovered via multisig |
+| [0xddddeeeeffff0000...](https://etherscan.io/address/0xdddd) | [0xfedcba987654321...](https://etherscan.io/tx/0xfedcba) | 50,000 USDC | [Bridge address](https://etherscan.io/address/0x78) | Uncertain | Funds possibly moved cross-chain |
+
+### Attacker Information
+
+Gather attacker information to aid legal efforts and fund recovery.
+
+| Address Link | Funded By | Notes |
+| --- | --- | --- |
+| [0xabcdefabcdefabcd...](https://etherscan.io/address/0xabcdefab) | Tornado Cash | Initial funding from Tornado Cash mixer |
+| [0x123456789abcdef...](https://etherscan.io/address/0x12345678) | CEX | Received funds from centralized exchange |
+| [0xfedcba987654321...](https://etherscan.io/address/0xfedcba98) | Unknown | No prior activity, potentially new wallet |
+
+## Post Incident Actions
+
+1. Confirm the incident has been resolved.
+2. Create monitoring alerts for situations requiring future actions.
+3. Prepare scripts to perform any actions related to monitoring events in the future.
+4. Consider creating additional defensive scripts (pause/upgrade) to use for future situations.
+5. Schedule a Post Mortem write-up.
+6. Post the write-up to relevant social media.
+
+## Appendix
+
+### Advice to Keep in Mind
+
+- Limit the War Room occupancy. Be careful not to invite too many people during the early stages. Sensitive information
+is being shared; be wary.
+- Make it clear to War Room members not to publicize information without the protocol’s consent.
+- Do not speak to the press/news/publications.
+
+### Key Roles
+
+- **Operations**: Initiates War Room, assigns roles, distributes tasks, herds multisig participants.
+  - *Person Responsible*
+- **Scribe**: Consolidates gathered information for efficiency in knowledge-sharing.
+  - *Person Responsible*
+- **Strategy Lead**: Prioritizes actions, considers trade-offs of decisions.
+  - *Person Responsible*
+- **Protocol Lead**: Responsible for smart-contract actions (pausing, upgrading, etc.).
+  - *Person Responsible*
+- **Web/Infrastructure Lead**: Responsible for updating the front-end, managing servers.
+  - *Person Responsible*
+- **External Communicator**: Social media and user communications.
+  - *Person Responsible*
+
+### Suggested Tools and Platforms
+
+| Name | Type | Notes |
+| --- | --- | --- |
+| Discord | Platform | A familiar platform for web3 collaboration. Spin up a server quickly using our [recommended template](https://discord.new/CkADqy5aWsAH). Tips: New users must be granted the `approved` role before they can view chats. Upon creation, grant yourself the `approved` role and share an invite link with trusted members. |
+| Telegram | Platform | A familiar platform for web3 collaboration. Tips: Upon New Group creation, enable chat history as visible to new members. To do this: Info -> Edit -> Chat History For New Members -> Visible |
+| Google Hangouts | Platform | |
+| Phalcon Tx Explorer | Tx Analysis | |
+| Openchain Trace Explorer | Tx Analysis | |
+| Tenderly Tx Explorer | Tx Analysis, Debugging | Some features require login. |
+| Tenderly Alerts | Monitoring | Monitor addresses, on-chain actions, etc. Requires login. |
+| MetaSleuth | Monitoring | Monitor fund movement. 50 address limit. Requires login (premium feature). |
+| Github / Gist | Code Sharing | Create a private repo or secret gists and share the link with War Room participants only. |
+| CodeShare | Code Sharing | Sessions expire after 24 hours. |
+| HackMD | Code Sharing | Private notes become published after ~48 hours. Be very careful with sensitive information! |
+
+### SEAL Message Template
+
+Fill out with relevant information and send to SEAL 911 Bot.
+
+```plaintext
+Protocol: [Protocol Name]
+Attack Tx(s): [Transaction Hash(es)]
+Funds at Risk: [Estimated Amount in USD or Token]
+
+[Brief Description of the incident]
+```
+
+---
+
+---
+
+### PAGE: /wallet-security/secure-multisig-best-practices
+**Title:** Secure Multisig Best Practices | SEAL
+**Referenced by controls:** ir-1.1.2, ir-3.1.1, ir-3.1.2
+
+# Secure Multisig Best Practices
+
+
+
+
+> Guidance for designing, operating, and auditing high-assurance multisigs. Use this as your single source for baseline
+> rules, setup guidance, and daily operations.
+
+## Who This Is For
+
+Advanced technical users, developers, Decentralized Autonomous Organizations (DAOs), and organizations responsible for
+managing protocol treasuries, smart contract ownership, or significant personal/collective assets.
+
+## Primary Goal
+
+The primary objective is to eliminate single points of failure and establish robust, distributed control over high-value
+assets and critical smart contract functions.
+
+## Core Concept: M-of-N Scheme
+
+A multisignature (multisig) wallet is a smart contract that requires a predefined minimum number of approvals `M` from a
+total set of authorized signers `N` to execute a transaction. This is known as an `M-of-N` scheme (e.g., 2-of-3,
+3-of-5).
+
+By distributing signing authority, a multisig ensures that the compromise of a single private key is insufficient to
+authorize the movement of funds or execute a privileged action.
+
+## General Rules
+
+### Thresholds & Configuration
+
+- Minimum of 3 signers
+- 50% signing threshold
+- 7+ signers for multisigs holding 1M+ in assets (USD equivalent)
+- Please see Classification Matrix in
+  [Planning & Classification](/multisig-for-protocols/planning-and-classification#step-3-classification-matrix)
+  for more information on threshold selection.
+- All signers must use hardware wallets
+- Multisigs managing assets on behalf of a DAO should set unlimited allowance with primary DAO agent
+- Signers on multisigs with critical protocol configuration or security roles are discouraged from using their
+addresses for other purposes. They should create a brand new wallet for that purpose instead.
+- All signing wallets should be monitored for any activity that is not directly related to multi-sig operations.
+- No multisigs should use modules/guards except those mentioned in
+[Setup & Configuration → Modules & Guards](/multisig-for-protocols/setup-and-configuration#modules--guards)
+unless clear justification and security review is provided
+- Threshold exceptions can be made for multisigs that are used in frequent operations but are highly constrained
+by smart contracts. For example, rate setting operations with tight bounds and a backup recovery mechanism to
+replace the multisig.
+
+#### Threshold Selection
+
+Avoid `N-of-N` schemes, as the loss of a single key would result in a permanent loss of access to all funds.
+
+#### Strategic Signer Distribution
+
+The security of a multisig depends entirely on the operational security (OpSec) of its individual signer keys. Storing
+multiple signer keys on the same device or in the same physical location negates the security benefits. Effective
+distribution strategies include:
+
+- Using different hardware wallet models and manufacturers.
+- Maintaining geographical separation for devices holding signer keys.
+- Assigning signer keys to different trusted individuals within an organization.
+- Using diverse client software to interact with the multisig to mitigate single-point-of-failure risks from a software
+vulnerability.
+
+#### Signer Composition Requirements
+
+- **Role Diversity**: Signers should be diverse individuals to reduce risk of multiple compromised accounts - a
+mix of executives, developers, and operational roles is recommended
+- **Technical Expertise**: Include a high number of competent, well-vetted technical signers that will understand full
+transaction details and effects in your signing quorum
+- **External Parties**: Multi-sigs managing high value wallets and contracts should have at least 1 additional required
+signer that is external to the organization (such as a security partner or trusted advisor)
+
+### Communication & Documentation
+
+- In the event of loss of access to keys or potential compromise of keys or communication channels, the signer must
+  immediately notify the other multisig participants and email your security contact - [Incident
+  Reporting](/multisig-for-protocols/incident-reporting)
+- Signers should use dedicated communication channels for multisig operations and maintain backup ways of reaching other
+  signers
+- All multisigs should be documented in the protocol documenting its purpose, general operating rules, multisig wallet
+  address, and list of signer addresses
+- Signers should verify their addresses by signing a message stating their affiliation and the multisig they intend to
+  join (entity affiliation is ok)
+
+#### Out-of-Band Verification for Admin Changes
+
+Any critical administrative action, such as adding or replacing a signer, must be verified through multiple, independent
+communication channels (e.g., a video call and a signed message) to prevent social engineering attacks.
+
+### Signer rotation
+
+- Signers can be rotated, but detailed documentation should be maintained
+- Any changes to signer composition should be documented in the protocol documentation
+- Any signer change should not reduce the number of signers or decrease the threshold unless clear justification is
+  given and documented
+
+#### Updating signer addresses
+
+If the original key is accessible:
+
+- The signer proves ownership of a new address by signing a message with their existing address.
+- The signer must follow the steps in
+[Signer Verification process](/multisig-for-protocols/registration-and-documentation#signer-verification-process)
+
+If the original key is lost:
+
+- The signer must verify their identity to the other signers through alternative methods such as:
+  - Authentication via a verified social media account.
+  - A video call with other signers for confirmation.
+  - Other sufficient methods.
+
+### Training & Drills
+
+- All signers should complete training as outlined in the
+[Implementation Checklist](/multisig-for-protocols/implementation-checklist)
+- For multisigs that perform emergency operations like pausing, teams should have processes to regularly conduct drills
+  to ensure operational readiness and signer availability
+
+## Setup Best Practices
+
+See General Rules above for thresholds and signer distribution guidance.
+
+- **Practice on Testnet:** Before deploying on mainnet, thoroughly practice wallet creation, transaction signing, and
+owner management on a test network.
+
+- **Timelocks:** Enforce a mandatory delay between the approval of a transaction and its execution. This provides a
+critical window for the community or team to detect and react to malicious proposals.
+
+- **Veto Quorum:** Establish a smaller veto group separate from the confirmation quorum to review and confirm
+transaction legitimacy. Organizations can establish veto quorums to bypass time-locks in case of emergency.
+The standard quorum plus two additional signers should be required to bypass.
+
+- **Role-Based Access Control (RBAC):** Implement modules that grant specific, limited permissions to certain addresses
+(e.g., a "pauser" or "executor" role) without making them full owners, adhering to the principle of least privilege.
+
+- **Disaster Recovery Plan:** Establish a clear, documented process for what to do when a signer is compromised, the
+multi-signature UI is down, or other emergencies arise. These should be done at regular intervals.
+
+## Operational Best Practices
+
+- **Signer Key Revocation and Replacement:** A  feature of multisigs is the ability to add, remove, or replace signer
+keys. If a signer's key is compromised or lost, it can be revoked and replaced with a new, secure key through a
+transaction approved by the remaining owners, preserving the integrity of the wallet's assets without needing to migrate
+funds.
+
+- **Secure Signing Environment:** For maximum security, all signing activities should be performed on a dedicated,
+air-gapped, or hardened device running a secure OS. Using a primary work laptop significantly increases the risk of
+malware interference.
+
+- **Independent Transaction Verification:**  Before signing, always verify the raw transaction data (target address,
+function call, parameters) to ensure it matches the intended operation.
+
+- **Out-of-Band Verification for Admin Changes:** Any critical administrative action, such as adding or replacing a
+signer, must be verified through multiple, independent communication channels (e.g., a video call and a signed message)
+to prevent social engineering attacks.
+
+- **Active Monitoring:** Implement monitoring and alerting systems to be immediately notified of any on-chain activity
+related to the multisig, including proposed transactions, new signatures, and owner changes (e.g., using tools like
+[Safe Watcher](https://github.com/Gearbox-protocol/safe-watcher) ).
+
+- **Documented Procedures:** Maintain clear, secure, and accessible documentation for all multisig procedures, including
+  transaction creation, signing, and emergency recovery plans.
+- **General Signing Guidelines:** Use hardware wallets, dedicated signing profiles, and re-verify before execution.
+  Require a "how to check" guide and communicate status after signing (e.g., "checked, signed, X more required"). Last
+  signer executes when applicable.
+
+## Contract-Level Security
+
+- **Invariant Enforcement:** Design contracts to enforce invariants and expected state changes such as token balance
+changes, ownership and administration, and proxy implementation addresses. Ensure contracts automatically revert
+transactions if any invariant is violated.
+
+- **Address Whitelisting:** Approved smart contract and wallet addresses must be added to a whitelist that is enforced
+at the contract-level. Interactions with all other addresses should be denied and revert the transaction. Updating the
+whitelist should require an extra signer in addition to the standard transaction approval quorum.
+
+For detailed configuration guidance, see
+[Setup & Configuration → Contract-Level Controls](/multisig-for-protocols/setup-and-configuration#contract-level-controls).
+
+## Acknowledgements
+
+Some ideas were borrowed from the [EF's multisig SOP notes](https://notes.ethereum.org/@fredrik/multisig-sop) and
+[Manifold Finance multisig best practices](https://hackmd.io/@manifoldx/multisig-best-practices).
+
+---
+
+---
+
+### PAGE: /infrastructure/domain-and-dns-security/monitoring-and-alerting
+**Title:** DNS Monitoring & Incident Response | SEAL
+**Referenced by controls:** ir-2.1.1, ir-2.1.3, ir-5.1.1
+
+# Monitoring, Alerts, and Incident Response
+
+
+
+
+## DNS Record Monitoring
+
+DNS record monitoring involves continuously checking your domain's DNS records for unauthorized changes. Attackers often
+modify DNS records to redirect traffic to malicious servers while keeping your site partially functional.
+
+**What to watch for**:
+
+- **Nameserver (NS) record changes**: Attackers change your nameservers to point to their own DNS servers, giving them
+  complete control over all DNS records
+- **Sudden TTL drops**: Very low TTLs *can* indicate preparation for rapid DNS changes during an attack
+  - **Note**: Low TTL is common and legitimate with CDNs and auto-scaling contexts; Cloudflare "Auto" is often 300s
+  - **Context**: Cloudflare allows TTL 30-60s for [unproxied
+    records](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/); this is not inherently malicious
+  - **Monitor for**: *Unexpected* drops from higher values or drops combined with other suspicious activity
+- **CAA record removal or overrides**: Allows any Certificate Authority to issue certificates for your domain
+  - **Note**: Child zones override parent CAA records
+  - **Advanced monitoring**: Watch for parameters like `accounturi` and `validationmethods` which provide finer control
+    over certificate issuance
+- **DNSSEC disabled unexpectedly**: Removes cryptographic protection from DNS responses
+
+**If nameservers remain unchanged, also monitor**:
+
+- **A/AAAA record modifications**: IP address changes could redirect users to malicious sites
+- **MX record modifications**: Email server changes could intercept password reset emails
+- **TXT record changes**: Could affect email security (SPF/DMARC) or domain validation
+
+**Monitoring tools** (continuous change tracking):
+
+- [MXToolbox](https://mxtoolbox.com/) - Comprehensive DNS record monitoring and alerts
+- [HetrixTools](https://hetrixtools.com/) - Free DNS monitoring with email alerts
+- [SecurityTrails](https://securitytrails.com/) - Historical DNS data and change tracking
+
+**Analysis and debugging tools**:
+
+- [DNSViz](https://dnsviz.net/) - DNSSEC chain validation and debugging
+- [DNS Dumpster](https://dnsdumpster.com/) - DNS reconnaissance and record discovery
+
+**GitOps and zone control**:
+
+- [OctoDNS](https://github.com/octodns/octodns) - Infrastructure-as-code for DNS; manage zones via code with auditable,
+  reviewed changes through CI/CD
+- [DNSControl](https://github.com/StackExchange/dnscontrol) - Synchronize DNS across multiple providers; declarative
+  configuration with version control
+
+**Note**: If attackers change your NS records, they control everything. But attackers with DNS panel access might make
+subtle changes without touching NS records to avoid detection, which is why monitoring individual record types remains
+important.
+
+## Certificate Transparency Monitoring
+
+Certificate Transparency (CT) logs are public records of all SSL certificates issued by Certificate Authorities.
+Monitoring these logs helps detect unauthorized certificate issuance.
+
+**Why it matters**: Attackers sometimes obtain fake SSL certificates for legitimate domains to make phishing sites
+appear more credible. CT monitoring helps you detect these certificates before they're used in attacks.
+
+**Setup and tools**:
+
+- [crt.sh](https://crt.sh/) - Search and monitor CT logs for your domain
+- [Cert Spotter](https://sslmate.com/certspotter/) - Free CT monitoring with API access
+- Watch for wildcard certificates if you don't use them (could indicate broader compromise)
+
+## Passive DNS Monitoring
+
+Passive DNS monitoring tracks historical DNS resolution data across the internet, helping you detect brief changes that
+might be missed by periodic checks.
+
+**What it detects**:
+
+- **Brief record changes**: Attackers often make quick changes to avoid detection
+- **Geographic anomalies**: DNS records resolving to unexpected countries or regions
+- **Suspicious hosting provider changes**: Sudden switches to hosting providers known for malicious activity
+
+**Tools for passive DNS**:
+
+- [PassiveTotal (RiskIQ)](https://community.riskiq.com/) - Comprehensive passive DNS database
+- [Mnemonic Passive DNS](https://passivedns.mnemonic.no/) - Free passive DNS lookup
+- [SecurityTrails](https://securitytrails.com/) - Historical DNS and WHOIS data
+
+## Setting Up Alerts
+
+### Critical Alerts (Immediate Response Required)
+
+1. **Registrar Changed**
+
+   - **What it monitors**: Changes to your domain's registrar
+   - **Why it's critical**: Indicates potential domain hijacking or unauthorized transfer
+   - **Response**: Immediate verification and potential incident response activation
+
+2. **Nameserver Changed**
+
+   - **What it monitors**: Changes to nameserver records
+   - **Why it's critical**: Attackers often change nameservers to redirect traffic to malicious servers
+   - **Response**: Verify legitimacy, check if you initiated the change
+
+3. **DNSSEC Broken**
+
+   - **What it monitors**: DNSSEC validation failures or disabled DNSSEC
+   - **Why it's critical**: DNS responses can be tampered with, leading to man-in-the-middle attacks
+   - **Response**: Investigate signing issues, check for configuration changes
+
+4. **CAA Records Removed or Overridden**
+
+   - **What it monitors**: Removal of Certificate Authority Authorization records or child zone overrides
+   - **Why it's critical**: Allows any CA to issue certificates for your domain, enabling SSL certificate attacks
+   - **Response**: Restore CAA records immediately, investigate who removed them
+   - **Note**: Child zones override parent CAA; parameters like `accounturi` and `validationmethods` can provide finer control
+
+5. **Unexpected TTL Drops**
+
+   - **What it monitors**: Sudden TTL drops from higher values
+   - **Why it's important**: Can indicate preparation for rapid DNS changes (attack preparation)
+   - **Context**: Low TTL (30-300s) is normal for CDNs and auto-scaling; Cloudflare allows 30-60s for [unproxied records](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/)
+   - **Response**: Investigate *unexpected* drops or drops combined with other suspicious activity; verify if legitimate
+     infrastructure changes
+
+### High Priority Alerts (When NS Unchanged)
+
+1. **A Record Changed**
+
+   - **What it monitors**: IP redirects without NS changes
+   - **Why it's important**: Could redirect users to malicious servers
+   - **Response**: Verify the new IP address is legitimate and expected
+
+2. **MX Record Changed**
+
+   - **What it monitors**: Changes to mail server configurations
+   - **Why it's important**: Could intercept emails, including password reset messages
+   - **Response**: Verify mail server changes are authorized
+
+3. **DMARC Policy Weakened**
+
+   - **What it monitors**: Changes from "reject" to "quarantine" or "none"
+   - **Why it's important**: Weaker policies allow more spoofed emails to reach users
+   - **Response**: Investigate why policy was weakened, restore if unauthorized
+
+4. **Unexpected Certificate Issued**
+
+   - **What it monitors**: New SSL certificates issued for your domain
+   - **Why it's important**: Could indicate certificate-based attacks or unauthorized issuance
+   - **Response**: Verify the certificate was requested by your team, revoke if unauthorized
+
+## Incident Response Plan
+
+### Immediate Response
+
+1. **Verify the compromise** - Check DNS records via multiple resolvers
+2. **Access registrar account** - Attempt login, check for lockout
+3. **Contact registrar security team** - Use pre-documented emergency contacts
+4. **Document everything** - Screenshot all current settings
+
+### Containment
+
+1. **Invoke registry lock** if available
+2. **Update NS records** if you maintain access
+3. **Warn users** via social media/status page
+4. **Contact law enforcement** if significant theft occurred
+
+### Recovery
+
+1. **Regain control** through registrar security procedures
+2. **Audit all DNS records** against known-good baseline
+3. **Reset all credentials** for registrar and DNS hosting
+4. **Review access logs** to understand attack vector
+
+### Post-Incident
+
+1. **Conduct thorough investigation**
+2. **Update security measures** based on lessons learned
+3. **Consider legal action** if appropriate
+4. **Publish transparency report** to rebuild trust
+
+---
+
+---
+
+### PAGE: /monitoring/guidelines
+**Title:** On-Chain Monitoring Guidelines
+**Referenced by controls:** ir-2.1.1
+
+# Guidelines for On-Chain Monitoring
+
+
+
+
+Effective on-chain monitoring is complex, and involves setting up systems and processes to continuously observe
+blockchain activities and detect any anomalies.
+
+## Best Practices
+
+### Define Monitoring Objectives
+
+1. Determine the critical metrics to monitor, such as large fund transfers, token minting events, and changes in
+contract ownership.
+
+### Implement Monitoring Tools
+
+1. Use automated monitoring tools that can continuously track blockchain activities and generate alerts for anomalies.
+2. Supplement automated tools with periodic manual reviews.
+
+### Establish Alerting Mechanisms
+
+1. Set up real-time alerts to notify relevant project members of any suspicious activities or threshold breaches.
+2. Use multiple channels for alerts, such as email, SMS, and messaging apps where available, to ensure timely response.
+
+### Regular Reviews and Updates
+
+1. Conduct regular reviews of your monitoring systems to ensure they are functioning correctly and covering all
+necessary metrics.
+2. Regularly update thresholds and alert configurations to reflect your current needs.
+
+### Incident Response
+
+1. Develop and maintain an [incident response plan](/incident-management/overview) to handle alerts and anomalies as
+soon as possible.
+
+---
+
+---
+
+### PAGE: /governance/compliance-regulatory-requirements
+**Title:** Compliance & Regulatory Requirements | SEAL
+**Referenced by controls:** ir-2.1.3
+
+# Compliance with Regulatory Requirements
+
+
+
+
+Compliance with regulatory requirements may be essential for your project. Understanding the needs and ensuring the
+necessary compliance helps protect your project from potential legal penalties.
+
+## Key Regulatory Frameworks
+
+Some examples of regulatory frameworks or standards for web3 are:
+
+- **GDPR (General Data Protection Regulation)**: Applies to organizations handling the personal data of EU citizens. It
+mandates strict data protection measures and grants individuals significant rights over their data, as soon on
+[https://gdpr.eu/](https://gdpr.eu/).
+- **MiCA**: Companies seeking to offer crypto services or assets within the EU are in scope. While this may seem
+daunting, there are different levels of compliance needed depending on the project, as can be seen on
+[https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/markets-crypto-assets-regulation-mica](https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/markets-crypto-assets-regulation-mica)
+
+## Best Practices for Compliance
+
+# Best Practices for Regulatory Compliance in Terms of Security
+
+## 1. Understand Applicable Regulations
+
+- **Identify Relevant Regulations:** Clearly identify all regulatory frameworks that apply to your organization, such as
+GDPR, HIPAA, CCPA, or PCI DSS.
+- **Regularly Review Legal Requirements:** Stay updated on changes in regulations that impact your industry, ensuring
+compliance measures evolve accordingly.
+- **Engage Legal Counsel:** Work with legal experts to interpret regulations accurately and implement appropriate
+security controls.
+
+## 2. Develop a Robust Security Policy Framework
+
+- **Comprehensive Security Policies:** Develop detailed security policies that align with regulatory requirements,
+covering areas like data protection, access control, and incident response.
+- **Policy Documentation:** Maintain thorough documentation of all security policies, procedures, and controls, ensuring
+they are easily accessible for audits and reviews.
+- **Regular Policy Updates:** Review and update security policies regularly to reflect changes in regulations and
+emerging threats.
+
+## 3. Data Protection and Privacy
+
+- **Data Classification:** Classify data based on sensitivity and regulatory requirements, ensuring appropriate
+protection levels for each category.
+- **Data Minimization:** Collect and retain only the minimum amount of data necessary for business operations, reducing
+exposure to potential breaches.
+- **Anonymization and Pseudonymization:** Where possible, apply anonymization or pseudonymization techniques to protect
+personal data.
+
+## 4. Access Management and Control
+
+- **Role-Based Access Control (RBAC):** Implement RBAC to ensure that employees have access only to the data and systems
+necessary for their roles.
+- **Multi-Factor Authentication (MFA):** Require MFA for access to sensitive systems and data, adding an extra layer of
+security.
+- **Regular Access Audits:** Conduct regular audits of user access rights to ensure compliance with the principle of
+least privilege.
+
+## 5. Incident Response Planning
+
+- **Comprehensive Incident Response Plan:** Develop an incident response plan that aligns with regulatory requirements,
+detailing steps for identifying, responding to, and reporting security incidents.
+- **Regulatory Reporting:** Ensure the incident response plan includes protocols for reporting breaches to regulatory
+authorities within the required timeframes.
+- **Regular Testing:** Conduct regular simulations and tabletop exercises to test the effectiveness of the incident
+response plan.
+
+## 6. Continuous Monitoring and Auditing
+
+- **Automated Monitoring Tools:** Implement automated tools to continuously monitor compliance with security regulations
+and detect potential vulnerabilities or breaches.
+- **Internal Audits:** Conduct regular internal audits to assess compliance with security policies and regulatory
+requirements.
+- **External Audits:** Engage third-party auditors to provide independent assessments of your security posture and
+compliance status.
+
+## 7. Employee Training and Awareness
+
+- **Regular Training Programs:** Provide regular training on regulatory requirements, data protection, and security best
+practices for all employees.
+- **Phishing and Social Engineering Awareness:** Educate employees about phishing, social engineering, and other common
+attack vectors that could lead to compliance breaches.
+- **Role-Specific Training:** Tailor training programs to address the specific regulatory and security responsibilities
+of different roles within the organization.
+
+## 8. Third-Party Risk Management
+
+- **Vendor Due Diligence:** Conduct thorough due diligence on third-party vendors to ensure they comply with relevant
+security regulations.
+- **Contractual Obligations:** Include specific security and compliance requirements in contracts with third-party
+vendors.
+- **Continuous Monitoring:** Monitor third-party vendors’ compliance with security requirements throughout the
+relationship.
+
+## 9. Data Encryption and Secure Communication
+
+- **Encryption Standards:** Use strong encryption standards for protecting data both at rest and in transit, in line
+with regulatory requirements.
+- **Secure Communication Channels:** Ensure that all communication involving sensitive data is conducted over secure
+channels (e.g., TLS, VPN).
+- **Key Management:** Implement robust key management practices to protect encryption keys from unauthorized access.
+
+## 10. Documentation and Record-Keeping
+
+- **Compliance Documentation:** Maintain detailed records of compliance efforts, including audit results, incident
+reports, and training logs.
+- **Retention Policies:** Establish data retention policies that comply with regulatory requirements, ensuring that
+records are kept for the required duration.
+- **Audit Trails:** Ensure that all access to sensitive data is logged, creating a clear audit trail for compliance
+verification.
+
+# Useful Resources
+
+Here are some useful resources where you can follow and learn more about the best practices mentioned:
+
+1. **National Institute of Standards and Technology (NIST)**
+   - **NIST Cybersecurity Framework:** A comprehensive resource for implementing cybersecurity best practices and
+   complying with regulatory requirements.
+   - URL: [https://www.nist.gov/cyberframework](https://www.nist.gov/cyberframework)
+
+2. **International Organization for Standardization (ISO)**
+   - **ISO/IEC 27001 Information Security Management:** The leading international standard for information security
+   management, providing guidelines for establishing, implementing, and maintaining an effective security program.
+   - URL:
+   [https://www.iso.org/isoiec-27001-information-security.html](https://www.iso.org/isoiec-27001-information-security.html)
+
+3. **Center for Internet Security (CIS)**
+   - **CIS Controls:** A prioritized set of actions that help organizations comply with regulatory requirements and
+   improve their cybersecurity posture.
+   - URL: [https://www.cisecurity.org/controls/](https://www.cisecurity.org/controls/)
+
+4. **General Data Protection Regulation (GDPR)**
+   - **Official GDPR Portal:** Provides detailed information on GDPR requirements, including guidelines, tools, and
+   resources for compliance.
+   - URL: [https://gdpr.eu/](https://gdpr.eu/)
+
+5. **Health Insurance Portability and Accountability Act (HIPAA)**
+   - **HIPAA Journal:** Offers news, resources, and guidelines for ensuring compliance with HIPAA regulations,
+   particularly in the healthcare sector.
+   - URL: [https://www.hipaajournal.com/](https://www.hipaajournal.com/)
+
+6. **Payment Card Industry Data Security Standard (PCI DSS)**
+   - **Official PCI Security Standards Council:** Provides comprehensive resources, including guidelines and tools for
+   complying with PCI DSS requirements.
+   - URL: [https://www.pcisecuritystandards.org/](https://www.pcisecuritystandards.org/)
+
+7. **Cybersecurity & Infrastructure Security Agency (CISA)**
+   - **CISA Best Practices:** Offers guidelines and resources for improving cybersecurity, including incident response
+   planning and third-party risk management.
+   - URL: [https://www.cisa.gov/publication/best-practices](https://www.cisa.gov/publication/best-practices)
+
+8. **Cloud Security Alliance (CSA)**
+   - **CSA Security Guidance for Cloud Computing:** Provides best practices and guidance for ensuring compliance and
+   security in cloud environments.
+   - URL:
+   [https://cloudsecurityalliance.org/artifacts/security-guidance-v4/](https://cloudsecurityalliance.org/artifacts/security-guidance-v4/)
+
+9. **International Association of Privacy Professionals (IAPP)**
+   - **IAPP Resource Center:** Offers a wealth of resources, including whitepapers, research, and tools, to help
+   organizations comply with data protection regulations.
+   - URL: [https://iapp.org/resources/](https://iapp.org/resources/)
+
+10. **SANS Institute**
+
+- **SANS Security Resources:** Provides extensive resources, including guides, whitepapers, and training courses,
+for improving security and regulatory compliance.
+- URL: [https://www.sans.org/security-resources/](https://www.sans.org/security-resources/)
+
+---
+
+---
+
+### PAGE: /multisig-for-protocols/setup-and-configuration
+**Title:** Multisig Setup & Configuration | SEAL
+**Referenced by controls:** ir-3.1.1, ir-3.1.2
+
+# Setup & Configuration
+
+
+
+
+This page covers the technical deployment and configuration of multisigs on supported networks.
+
+## Basic Setup
+
+### EVM Networks (Ethereum, Base, etc.)
+
+1. Go to [https://app.safe.global](https://app.safe.global)
+2. Connect wallet of the deploying signer
+3. Create new Safe with your determined threshold and signer addresses
+4. **Multi-network deployment**: If deploying on multiple networks, Safe UI will offer to replicate the configuration
+
+### Solana
+
+1. Go to [https://squads.xyz/squads-multisig](https://squads.xyz/squads-multisig)
+2. Connect wallet of the deploying signer
+3. Create new multisig with your determined threshold and signer addresses
+
+## Self-Hosted Multisig UI
+
+Multi-sig coordination UIs should be self-hosted to eliminate supply chain risk. Hosted UI should be IP restricted to
+allow access only from signer machines.
+
+Deploy from [Safe Wallet Monorepo](https://github.com/safe-global/safe-wallet-monorepo/tree/dev/apps/web).
+While it should not be your final line of defense, securing the UI does protect your verification process
+from being compromised by supply-chain attacks.
+
+For emergency situations when the primary UI is unavailable, see
+[Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure).
+
+## Delegated Proposer
+
+It is recommended, but not required to authorize a separate transaction proposer for a Safe. This address can prepare
+transactions for signers to sign but is not an authorized signer on the Safe. Therefore **there is no risk of malicious
+signatures which can affect the Safe assets**. This wallet can hold no funds and simply act as a proposer. The primary
+reason to have a delegated proposer is that the hash verification utilities depend on the Safe API (unless details are
+entered manually). Until a transaction is **proposed** it does not show up in the API so the hash verification tools
+cannot detect it.
+
+![Delegated proposer configuration interface](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/delegated-proposer-configuration-interface.png)
+
+## Modules & Guards
+
+### Allowance Module (Required for Treasury Multisigs)
+
+If your multisig will hold any assets on behalf of the DAO, set up governance rescue capability:
+
+**Mainnet configuration:**
+
+- **Module**: Allowance Module
+- **Grant allowance to**: DAO Agent
+- **Amount**: Max value for each token held
+
+### Zodiac Delay Modifier (Time-Locks)
+
+Consider using [Zodiac Modifier Delay](https://github.com/gnosisguild/zodiac-modifier-delay/tree/main) or equivalent
+for implementing on-chain time-lock transaction delays to Safe wallets.
+
+See [Use Case Specific Requirements](/multisig-for-protocols/use-case-specific-requirements#timelock-configuration)
+for detailed timelock configuration guidance.
+
+### Other Modules
+
+Do not install any other modules or guards without explicit governance approval and security review.
+
+## Contract-Level Controls
+
+**Advanced Configuration Warning:** The following contract-level controls are advanced security features that can
+provide additional protection but require careful implementation. Before implementing any guards or modules:
+
+- **Conduct thorough research** on available guard implementations and their compatibility with your multisig setup
+- **Ensure all guards are well-audited** by reputable security firms before deployment
+- **Test extensively** on testnets to verify functionality and edge cases
+- **Understand the risks**: Incorrect configuration or incompatible guards can render your multisig unusable,
+potentially locking access to funds permanently
+
+### Address Whitelisting
+
+Approved smart contract and wallet addresses must be added to a whitelist that is enforced at the contract-level.
+Interactions with all other addresses should be denied and revert the transaction. Updating the whitelist should
+require an extra signer in addition to the standard transaction approval quorum.
+
+### Invariant Enforcement
+
+Design contracts to enforce invariants and expected state changes such as token balance changes, ownership and
+administration, and proxy implementation addresses. Ensure contracts automatically revert transactions if any
+invariant is violated.
+
+## Initial Testing
+
+### Verify Basic Functionality
+
+1. **Small test transaction**: Send a low-value token transfer (e.g., 1 USDS or equivalent)
+2. **All signers test**: Ensure each signer can successfully sign the test transaction
+3. **Confirm execution**: Verify the transaction executes as expected
+4. **Test communication**: Use your established channels to coordinate the test
+
+## Pre-Launch Checklist
+
+- [ ] Safe deployed with correct threshold
+- [ ] All signer addresses added and [verified](/multisig-for-protocols/registration-and-documentation#signer-verification-process)
+- [ ] Allowance module configured (if required)
+- [ ] Test transaction completed successfully
+- [ ] All signers confirmed they can sign
+- [ ] [Communication channels](/multisig-for-protocols/communication-setup) tested during transaction
+- [ ] Safe addresses documented for all networks
+
+### Practice on Testnet
+
+Before deploying on mainnet, thoroughly practice wallet creation, transaction signing, and owner management on
+a test network.
+
+Once setup is complete, proceed to [Registration &
+Documentation](/multisig-for-protocols/registration-and-documentation) for registration and documentation requirements.
+
+## Nested Safes
+
+A nested Safe is one in which a Safe is set as a signer on another Safe rather than an EOA. This can be useful on a
+case-by-case basis. For example, if a signer is an entity that might want to have multiple individual signers, the
+nested Safe could have a 1/X threshold allowing anyone authorized on the team to sign. However, this configuration
+allows the signers on the nested Safe to update the signer addresses without needing authorization from the main Safe.
+
+It is generally recommended **not** to use nested safe on protocol multisigs unless there is a specific use case that
+it enables.
+
+## Next Steps
+
+After completing setup:
+
+1. [Registration & Documentation](/multisig-for-protocols/registration-and-documentation) - Document your multisig
+2. [Communication Setup](/multisig-for-protocols/communication-setup) - Establish secure communication
+3. [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds) - Ensure all signers are properly configured
+
+## Active Monitoring
+
+Implement monitoring and alerting systems to be immediately notified of any on-chain activity related to the multisig,
+including proposed transactions, new signatures, and owner changes (e.g., using tools like [Safe
+Watcher](https://github.com/Gearbox-protocol/safe-watcher)).
+
+### Immutable Monitoring Channels
+
+Monitoring channels (e.g. email, Slack or Telegram chats) must be immutable (or trigger alerts when their configuration
+changes or logs are deleted/tampered with) and redundant such that an admin could not disable or tamper with one
+monitoring channel without generating an alert on the other channel.
+
+---
+
+### PAGE: /wallet-security/seed-phrase-management
+**Title:** Seed Phrase Management
+**Referenced by controls:** ir-3.1.3
+
+# Seed Phrase Management
+
+
+
+
+## Private Key & Seed Phrase Management
+
+The **seed phrase** (or mnemonic phrase) is the master key to a non-custodial wallet, granting complete control over all
+its derived **private keys** and assets. The management of this phrase is the single most important aspect of
+self-custody security.
+
+> ⚠️ If you suspect for even a moment that your private key or seed phrase has been lost, viewed by another person, or
+> exposed digitally (e.g., shown on-screen, copied to a clipboard on a connected device), you must **consider it
+> compromised.** Immediately create a new, secure wallet and transfer all assets to it.
+
+### Secure Storage Practices
+
+The goal is to protect the seed phrase from both physical threats (theft, fire, water damage) and digital threats
+(hacking, malware). The foundational principle is to keep your seed phrase offline at all times.
+
+As soon as a new wallet is created, back it up using one of the following offline methods. Wallet providers do not have
+access to your seed phrase and cannot help you recover it.
+
+- **Physical Written Copies**: Writing the phrase on paper or a notebook is a common starting point. To mitigate risks
+
+of loss or damage from fire or water, store multiple copies in secure, geographically separate locations (e.g., a
+personal safe, a trusted family member's home, a bank deposit box).
+
+- **Durable Metal Storage**: For superior protection against physical damage, etch or stamp your seed phrase onto a
+
+metal plate (e.g., steel, titanium). Commercial products are available for this purpose. These should also be stored in
+secure, separate locations.
+
+### Enhanced security option
+
+For extra security, split seed into 3 pieces:
+
+- **Piece 1**: Words 1-16
+- **Piece 2**: Words 9-24
+- **Piece 3**: Words 1-8 and 17-24
+
+#### Storage locations:
+
+- Different secure locations (safe deposit box, home safe, trusted family)
+- Each piece stored with clear labeling system
+
+### Tamper evident bags:
+
+Storing sensitive devices or documents in a tamper evident bag offers high confidentiality and integrity. You can sign &
+date these bags, and also take a picture of its serial number.
+
+![Tamper evident bag example](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/tamper-evident-bag-example.png)
+
+**Use case:**
+You can put your Piece 1: Words 1-16 of your seed, inside a safe.
+Piece 2: Words 9-24 of your seed, somewhere safe (different location) in a tamper evident bag (could be at your parents place).
+Piece 3: Words 1-8 and 17-24 of your seed, somewhere safe (different location) in a tamper evident bag (could be
+somewhere else, at a family member or trusted friend).
+You can put your backup ledger while traveling inside this, in the safe of your hotel room to detect tampering.
+The main idea is to never have at the same place your 24 words, but still be able to recover your seed within 2 pieces
+of paper out of 3.
+You can find a useful [link here to our EthCC
+swag](https://drive.google.com/file/d/1L1CMiKRL3TXQBE5bWYNv6dfF94HSdZ8C/view?usp=sharing) that shows you how to easily
+split your seed in 3 as recommended.
+
+### Prohibited Practices
+
+Under no circumstances should you ever store your seed phrase in any of the following ways:
+
+- Taking a digital photograph of it.
+- Uploading it to cloud storage (iCloud, Google Drive, Dropbox).
+- Sending it via text message or any messaging app.
+- Sending it in an email, even to yourself.
+- Storing it in a plain text file on a computer or phone.
+- Sharing it with anyone. Wallet providers will **never** ask for your seed phrase.
+- Password managers or digital storage
+- Traveling with seed phrases
+- Storing all pieces in same location
+- Using a device obtained from an untrusted source, such as a conference, hackathon, or third-party online marketplace,
+as it may be tampered with.
+
+## Organizational Seed Phrase Security
+
+For organizations managing multisig wallets, seed phrase security requires additional properties beyond individual storage:
+
+### Security Properties
+
+- **Disaster Resistant**: The seed phrase is either duplicated or split, with components/copies secured across multiple
+geographic locations. This way, if disaster strikes, keys can be recovered from other locations.
+- **Theft Resistant**: An attacker gaining access to one piece of physical storage media for the seed phrase would not
+allow them to rebuild the wallet on its own
+- **Operator Loss Resistant**: Reconstituting the seed phrase should be possible with the absence of one or more
+operators
+
+### Seed Phrase Encryption
+
+> ⚠️ **Warning: Encryption adds recovery risk.** Only implement custom encryption schemes if you are sophisticated and
+> have robust documentation practices. If you forget your encryption method or passphrase, your funds are **permanently
+> inaccessible**—there is no recovery option. Many users and organizations face greater risk of locking themselves out
+> with custom encryption than from an attacker discovering a securely stored backup. Evaluate whether strong physical
+> security alone may be sufficient for your threat model.
+
+The reason to encrypt seed phrases is that if they are discovered unencrypted, the wallet is permanently compromised.
+However, if you encrypt your seed phrase, you are much more likely to forget the encryption when trying to restore the
+wallet. If you have stored the seed securely, it is unlikely to be discovered in the first place.
+
+Never store seed phrases in plain text or on an internet connected device. For additional protection, seed phrases can
+optionally be encrypted through some method. For example:
+
+- Seed phrases can be mixed in a randomly generated, recorded order
+- Have a 25th secret word
+- Require a passphrase to be imported into a wallet
+
+Regardless of the method, the related secret value should be stored in a password manager. (**Do not store your seed
+phrase in a password manager.**)
+
+### Advanced Backup Options
+
+**Key Splitting:**
+
+Split the key into multiple shards and securely distribute them:
+
+- Use [Shamir's Secret Sharing algorithm](https://en.wikipedia.org/wiki/Shamir%27s_secret_sharing) for N of M key shards
+- Consider using this [Shamir Secret Sharing implementation](https://github.com/privy-io/shamir-secret-sharing)
+- Seed phrases can be sharded using Shamir's Secret Sharing algorithm, with each shard recommended to be shared with a
+trusted guardian (3rd party custodian service, family members, password manager, personal physical media, etc.)
+
+**Multi-Share Backups:**
+
+Use device-supported multi-share backups where available:
+
+- [Trezor Multi-Share Backup](https://trezor.io/learn/a/multi-share-backup-on-trezor)
+
+**Secure Distribution:**
+
+Give shards to trusted family members, put in bank safe deposit boxes, and keep hidden around your house.
+
+> **Note**: If you're concerned about targeted attacks like kidnapping or home invasions, consider avoiding storing
+any shards in your primary residence.
+
+### Multisig Social Recovery
+
+**Optional Self-Recovery**:
+
+- Seed phrase backups are not strictly necessary with a healthy quorum
+- Multi-sig signing wallets should not be used for any other purpose and could be re-provisioned by existing quorum
+admins
+- Maintain a healthy enough signing pool that loss of access to a few accounts at once could be recovered from
+- Personal backup methods for admins are required to maintain access to on-chain assets in the event of loss of access
+to hardware wallets
+
+**Quorum Social Recovery**: If access to wallet is lost, the quorum can vote to edit members to replace the
+inaccessible wallet.
+
+### Ongoing Security Hygiene
+
+**1. Periodic Security Audits:**
+
+On a recurring basis (e.g., every 6 months), conduct a security review by asking:
+
+- Do I know the physical location of all my seed phrase backups?
+- Are my storage methods still secure and uncompromised?
+- If my primary device were destroyed, do I have a clear plan to recover my assets?
+
+**2. Key Rotation:**
+
+While you can use the same keys for years, it is a best practice to periodically rotate them by moving assets to new
+wallets.
+
+**3. Succession Planning:**
+
+Establish a clear, secure protocol for a trusted next-of-kin to access your assets in case of incapacitation or death.
+This may involve sealed instructions stored with a lawyer or in a safe deposit box.
+
+## Emergency access plan
+
+### Trusted contacts
+
+- Designate 2-3 trusted individuals who can access backup locations
+- Clear instructions for emergency seed access
+- Regular check-ins with trusted contacts
+
+### Recovery scenario example
+
+"Call [trusted person] with code word [predetermined phrase], tell them to get the metal plate from safe location A,
+they give you words 1-16 over the phone. Then call [second person] with code word for location B to get words 9-24. Use
+both pieces to reconstruct seed immediately, then change all security settings."
+
+### Documentation
+
+- Emergency contact information stored separately from seed
+- Code words/phrases for identity verification
+- Access instructions for trusted contacts
+- Regular testing of emergency procedures
+- Update procedures when contacts or locations change
+
+Remember: Your seed phrase security is the foundation of multisig security. Take time to implement proper storage
+procedures appropriate for your risk level.
+
+---
+
+### PAGE: /infrastructure/domain-and-dns-security/registrar-and-locks
+**Title:** Registrar Security & Registry Locks | SEAL
+**Referenced by controls:** ir-4.1.2
+
+# Registrar Security & Registry Locks
+
+
+
+
+## Choosing a Secure Registrar
+
+Your domain registrar is the company that manages your domain registration with the central registry. This is often the
+weakest link in domain security, as many registrars have poor security practices and are vulnerable to social
+engineering attacks.
+
+### Enterprise-Grade Registrars (Recommended)
+
+These registrars are designed for high-value domains and have security measures that consumer registrars lack:
+
+- **MarkMonitor**: Used by Fortune 500 companies, requires legal documentation for changes, dedicated security team
+- **AWS Route53**: IAM policy integration, CloudTrail logging, uses Amazon Registrar for major TLDs (but check TLD support)
+- **Cloudflare Registrar**: No markup pricing, automatic DNSSEC, built-in DDoS protection, requires Cloudflare services
+
+### Consumer Registrars to Avoid for Critical Domains
+
+These registrars are designed for personal use and lack the security measures needed for Web3 projects:
+
+- **GoDaddy**: History of social engineering vulnerabilities, call center support vulnerable to manipulation
+  - [2020 incident: Employees tricked into compromising cryptocurrency domains](https://threatpost.com/godaddy-employees-tricked-compromise-cryptocurrency/161520/)
+  - [Multiple low-tech, high-impact breaches](https://krebsonsecurity.com/2023/02/when-low-tech-hacks-cause-high-impact-breaches/)
+- **Namecheap**: While better than GoDaddy, still vulnerable to social engineering and lacks enterprise-grade security controls
+- **Consumer-focused services** (Google Domains/Squarespace): Designed for personal use, not enterprise security
+- **Resellers**: Add another layer of complexity and potential attack surface
+
+**Due diligence**: Check [ICANN Compliance Notices](https://www.icann.org/compliance/notices) for registrar
+terminations, breaches, and compliance issues. ICANN has terminated several registrars due to security issues and
+breaches. Review your registrar's compliance history before trusting them with critical domains.
+
+## Registry Lock (EPP Lock)
+
+Registry lock prevents unauthorized transfers at the registry level, not just the registrar. This is the strongest
+protection available for domain security.
+
+**Important distinction**: EPP status codes apply to **registry objects** (transfers, deletes, nameserver sets, contact
+updates), NOT DNS zone edits at your provider's DNS panel. You can still edit A records, MX records, TXT records, etc.
+in your DNS hosting provider's interface even with EPP locks enabled.
+
+**EPP Status Codes** that protect your domain:
+
+- `clientTransferProhibited`: Prevents domain transfers to another registrar
+- `clientUpdateProhibited`: Prevents registry object updates (nameservers, contact information)
+- `clientDeleteProhibited`: Prevents domain deletion
+- `serverTransferProhibited`: Registry-level transfer protection (stronger than client-level)
+- `serverUpdateProhibited`: Registry-level update protection (nameservers, contacts)
+- `serverDeleteProhibited`: Registry-level deletion protection
+
+**How it protects you**: Standard transfer locks only prevent transfers between registrars, but registry locks with full
+EPP protections prevent unauthorized changes to critical registry objects including transfers, deletions, nameserver
+changes, and contact modifications. Server-level locks require manual verification with the registry operator (like
+Verisign for .com domains), making social engineering attacks at the registrar level completely ineffective.
+
+**What EPP locks do NOT block**: DNS record edits (A, AAAA, MX, TXT, etc.) in your DNS provider's panel remain fully
+functional. EPP locks protect registry-level changes, not zone-level DNS record edits.
+
+**Setup**: Contact enterprise registrars for registry-operator level locks. This typically requires additional fees and
+documentation but provides the highest level of security.
+
+## Multi-Factor Authentication
+
+Multi-factor authentication (MFA) adds an extra layer of security beyond just passwords, which are easily compromised
+through phishing or data breaches.
+
+**Strong recommendation**: Use **Hardware Security Keys (FIDO2/WebAuthn)** for registrar accounts. Given the critical
+nature of domain security and the irreversibility of domain hijacks, hardware keys are the ONLY authentication method we
+strongly recommend for Web3 projects.
+
+**Authentication options**:
+
+1. **Hardware Security Keys (YubiKey, Titan, etc.) - STRONGLY RECOMMENDED**
+   - **Immune to phishing**: Cannot be tricked by fake login pages
+   - **No shared secrets**: Private key never leaves the device
+   - **No SIM swap vulnerability**: Physical device required
+   - **FIDO2/WebAuthn standard**: Industry-standard cryptographic authentication
+   - **Why critical for domains**: Domain control = organization control; hardware keys provide the highest assurance
+
+2. **TOTP Applications (Google Authenticator, Authy) - DISCOURAGED**
+   - Vulnerable to phishing through man-in-the-middle attacks
+   - Shared secrets can be compromised during setup
+   - QR codes can be intercepted or screenshotted
+   - Only use as a last resort if registrar doesn't support hardware keys
+   - If forced to use TOTP, ensure registrar has additional protections
+
+3. **SMS 2FA - DO NOT USE**
+   - **Extremely vulnerable to SIM swapping attacks**
+   - SMS can be intercepted via SS7 vulnerabilities
+   - Social engineering attacks target mobile carriers
+   - No cryptographic security
+   - Numerous high-profile compromises via SMS 2FA
+   - **Never use SMS 2FA for domain registrar accounts**
+
+**Action item**: If your registrar only supports SMS or TOTP, consider **migrating to an enterprise registrar**
+(MarkMonitor, AWS Route53 Registrar, Cloudflare Registrar) that supports hardware security keys.
+
+## Dedicated Security Contact Email
+
+Use a dedicated email address for domain security that's completely separate from your main domain and personal accounts.
+
+**Why this matters**: If your main domain is compromised, you need a way to receive security notifications and regain
+control. Using the same domain creates a circular dependency.
+
+```
+❌ admin@yourdomain.com (circular dependency - if domain is hijacked, you lose email access)
+❌ personal@gmail.com (too many attack vectors, likely used across multiple services)
+⚠️ domain-security@protonmail.com (better than gmail, but still a shared service)
+✅ security@yourcompany-domains.com (best - separate domain dedicated to domain management)
+```
+
+As a best practice register a separate domain specifically for domain management (e.g., `yourproject-domains.com` or
+`yourproject-security.com`) with a different registrar than your main domain. This ensures you maintain communication
+channels even if your primary domain is completely compromised.
+
+## Access Control Best Practices
+
+Limit and monitor who has access to your domain registrar account, as each person with access represents a potential
+attack vector.
+
+**Key practices**:
+
+- Document all personnel with registrar access
+- Use role-based access where available
+- Implement approval workflows for critical changes
+- Regular access audits (quarterly minimum)
+
+## WHOIS Privacy Protection
+
+WHOIS records contain personal information about domain owners that is publicly accessible by default, including names,
+addresses, phone numbers, and email addresses.
+
+**Why it matters**: Without WHOIS privacy, your personal information is exposed to:
+
+- Attackers gathering information for social engineering attacks
+- Spammers harvesting contact details
+- Competitors researching your infrastructure
+- Anyone running a simple WHOIS lookup
+
+**Setup**:
+
+- Enable WHOIS privacy/proxy service through your registrar (often free or low-cost)
+- Use company information instead of personal details where privacy isn't available
+- Consider using a separate business entity for domain registration
+- Be aware that some TLDs (.us, .ca) don't allow WHOIS privacy
+
+**Important**: WHOIS privacy doesn't affect your legal ownership - you remain the legitimate owner, the privacy service
+just shields your personal information from public view.
+
+## WHOIS vs RDAP
+
+**RDAP (Registration Data Access Protocol)** is the modern replacement for WHOIS. While WHOIS is still widely used, RDAP
+should be preferred for domain information lookups.
+
+**Why RDAP is better**:
+
+- **Structured data**: JSON-based responses are machine-readable and easier to parse
+- **Standardized**: Consistent format across registries and registrars
+- **Better display**: Modern CLIs and tools display RDAP data in organized, readable formats
+- **More reliable**: Built on RESTful APIs with better authentication and access control
+- **Links to authoritative sources**: Provides direct links to registrar and registry RDAP endpoints
+
+**Using RDAP**:
+
+- **Command-line tools**: Use RDAP CLIs like `rdap` (Rust-based) or `nicinfo` (Ruby-based)
+- **Web tools**: Many registries provide RDAP web interfaces
+- **Example lookup**: `rdap yourdomain.com` displays domain status, EPP codes, nameservers, registrar info, and
+  expiration dates
+
+**Example RDAP output**:
+
+```
+❯ rdap google.com
+2025-10-06T20:36:58.203437Z  INFO rdap: ICANN RDAP 0.0.23 Command Line Interface
+2025-10-06T20:36:58.203497Z  INFO rdap: query type is Domain Lookup for value 'google.com'
+――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
+ • host                       : rdap.verisign.com
+ • Request URI                : https://rdap.verisign.com/com/v1/domain/google.com
+
+――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
+                                   Domain GOOGLE.COM
+
+  ┌────────────────────────────┬─────────────────────────────────────────────────────┐
+  │                     Summary│Domain GOOGLE.COM                                    │
+  │                            │• 292 (Registrar)                                    │
+  │                            │  • Abuse                                            │
+  │                            │• Nameserver NS1.GOOGLE.COM                          │
+  │                            │• Nameserver NS2.GOOGLE.COM                          │
+  │                            │• Nameserver NS3.GOOGLE.COM                          │
+  │                            │• Nameserver NS4.GOOGLE.COM                          │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │        Identifiers         │                                                     │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │                    LDH Name│GOOGLE.COM                                           │
+  │                Unicode Name│                                                     │
+  │                      Handle│2138514_DOMAIN_COM-VRSN                              │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │        Information         │                                                     │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │                      Status│• Client Delete Prohibited                           │
+  │                            │• Client Transfer Prohibited                         │
+  │                            │• Client Update Prohibited                           │
+  │                            │• Server Delete Prohibited                           │
+  │                            │• Server Transfer Prohibited                         │
+  │                            │• Server Update Prohibited                           │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │           Events           │                                                     │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │                Registration│• Mon, 15-Sep-1997 04:00:00 +00:00                   │
+  │                  Expiration│• Thu, 14-Sep-2028 04:00:00 +00:00                   │
+  │                Last Changed│• Mon,  9-Sep-2019 15:39:04 +00:00                   │
+  │Last Update Of RDAP Database│• Mon,  6-Oct-2025 20:36:39 +00:00                   │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │           Links            │                                                     │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │                        Self│• https://rdap.verisign.com/com/v1/domain/GOOGLE.COM │
+  │                     Related│• https://rdap.markmonitor.com/rdap/domain/GOOGLE.COM│
+  └────────────────────────────┴─────────────────────────────────────────────────────┘
+
+                                    292 (Registrar)
+
+                ┌─────────────────┬────────────────────────────────────┐
+                │          Summary│292 (Registrar)                     │
+                │                 │• Abuse                             │
+                ├─────────────────┼────────────────────────────────────┤
+                │   Identifiers   │                                    │
+                ├─────────────────┼────────────────────────────────────┤
+                │           Handle│292                                 │
+                │            Roles│• registrar                         │
+                │IANA Registrar ID│292                                 │
+                ├─────────────────┼────────────────────────────────────┤
+                │     Contact     │                                    │
+                ├─────────────────┼────────────────────────────────────┤
+                │        Full Name│MarkMonitor Inc.                    │
+                ├─────────────────┼────────────────────────────────────┤
+                │      Links      │                                    │
+                ├─────────────────┼────────────────────────────────────┤
+                │            About│• http://www.markmonitor.com        │
+                │                 │• https://rdap.markmonitor.com/rdap/│
+                └─────────────────┴────────────────────────────────────┘
+```
+
+**What RDAP shows**:
+
+- Domain status and EPP lock codes (clientTransferProhibited, serverUpdateProhibited, etc.)
+- Nameserver information
+- Registrar details and abuse contacts
+- Registration, expiration, and last update dates
+- Links to registry and registrar RDAP endpoints
+
+**For security audits**: Use RDAP to verify your domain's EPP status codes, confirm registry locks are active, check
+nameserver configurations, and validate expiration dates. The structured output makes it ideal for automated monitoring
+and compliance checks.
+
+## Domain Expiration Protection
+
+Domain expiration is a critical yet often overlooked security risk. When domains expire, they enter a grace period
+before becoming publicly available, creating an opportunity for attackers to snipe your domain.
+
+**Expiration timeline (typical for gTLDs following ICANN rules)**:
+
+- Day 0: Domain expires (site goes down)
+- Day 1-45: Auto-renew grace period (can renew at normal price)
+- Day 46-75: Redemption period (costs 10x+ to recover)
+- Day 76-80: Pending delete
+- Day 81: Public availability (bot armies compete to register)
+
+**Important**: Grace and redemption periods **differ per TLD**. Generic TLDs (gTLDs like .com, .org, .net) follow ICANN
+rules with the timeline above. Country code TLDs (ccTLDs like .uk, .de, .ca) often have different policies set by their
+respective registries. Always verify your specific TLD's expiration policy with your registrar or registry.
+
+**Protection measures**:
+
+- **Enable auto-renewal** on all critical domains
+- **Set multiple renewal reminders** at 90, 60, 30, and 7 days before expiration
+- **Register domains for maximum period** (up to 10 years for most TLDs)
+- **Use a domain monitoring service** that alerts on upcoming expirations
+- **Document renewal dates** in your security calendar
+- **Ensure payment methods stay current** - expired credit cards are a common cause of accidental expiration
+- **Designate a backup person** responsible for domain renewals
+
+**Pro tip**: Set calendar reminders to check auto-renewal status quarterly - don't assume it's working until you verify.
+
+---
+
+---
+
+### PAGE: /incident-management/communication-strategies
+**Title:** Incident Communication Strategies | SEAL
+**Referenced by controls:** ir-4.1.2
+
+# Communication Strategies
+
+
+
+
+Communication during an incident can be very hard, as people are often scrambling to fix the issue at hand. Nonetheless,
+from aa team member, outsider or observer's point of view, communication is very important to be able to understand
+what's happening, and it also provide some time to reflect and think about what is going on. With that said, providing
+information before confirming that it's accurate, can often be very negative and cause uncertainty. It is recommended to
+have a person designated for communication during an incident, and that updates are sent out on a fixed schedule, and
+it can often be that the update is that there is currently no new information available.
+
+## Best Practices
+
+1. Define and establish secure communication channels for incident response teams.
+Use [encrypted messaging apps](/encryption/communication-encryption)
+2. Appoint primary and backup spokespersons to handle internal and external communications during an incident.
+3. Develop pre-approved templates for incident notifications, updates, and press releases to ensure consistency and
+speed.
+4. Provide regular updates to all stakeholders, including employees, customers, partners, and regulatory authorities, to
+keep them informed of the situation and response efforts.
+5. Maintain clear communication within the incident response team to ensure that everyone is aware of their roles and
+responsibilities.
+6. Be transparent with external stakeholders about the incident, the impact, and the steps being taken to address it.
+Avoid speculation and provide factual information.
+
+---
+
+---
+
+### PAGE: /multisig-for-protocols/personal-security-opsec
+**Title:** Multisig Personal Security (OpSec) | SEAL
+**Referenced by controls:** ir-4.1.2
+
+# Personal Security (OpSec)
+
+
+
+
+## Account Security
+
+### Basic requirements
+
+- 2FA enabled on all accounts (authenticator apps or hardware keys)
+- Password manager with unique, strong passwords for every account
+- Remove phone numbers from account recovery options where possible
+- Regular security checkups and removal of unused app permissions
+- Backup email for account recovery (separate from primary email)
+
+### For extra security
+
+**YubiKeys**: Use hardware security keys instead of authenticator apps
+
+- Provides stronger protection against phishing and SIM swapping
+- Recommended: 3 keys (primary, backup, secure storage)
+- Models: YubiKey 5C NFC, YubiKey 5C Nano
+
+**Cold backup accounts**: Separate email/phone for sensitive account recovery
+
+- Backup / cold accounts are tied to sensitive accounts (AppleID, Telegram, Signal, WhatsApp, Password Manager etc).
+  Such email addresses must never be shared with anyone and kept private to remain secure and not targeted.
+
+Example: random44@gmail is tied to your AppleID, and you are only logged in (the email) on a separate secure device. If
+your main device (laptop) gets compromised, you will be able to recover your account or revoke sessions, moreover your
+cold account won't be affected / compromised. It prevents people from targeting your accounts by not knowing your email
+linked to it.
+
+- Use different providers from primary accounts (Gmail, Proton)
+- Only access from secure devices
+- Never used for regular communications
+
+## Device Security
+
+### Basic requirements
+
+- Full disk encryption enabled (FileVault/BitLocker)
+- Automatic updates enabled on all devices
+- Screen lock after 5 minutes inactivity on computers, 30 seconds on mobile
+- Strong passcodes (6+ digits or alphanumeric on mobile)
+- Endpoint protection software on computers
+- No admin rights for daily use accounts (create separate admin account)
+
+### For extra security
+
+**Dedicated signing device**: Clean laptop/tablet used only for multisig operations
+
+- Minimal software installation
+- Regular security updates
+- Clean restart before each use
+- Offline storage when not in use
+- Justification: Reduces attack surface for high-value operations
+
+## Network Security
+
+### Dedicated Signing Machines
+
+- Multi-sig operations must be performed on devices dedicated only to these transactions and verification tools
+- All network access should be default blocked, with only the minimum necessary IPs to execute these transaction
+signatures allowed
+- Signing devices must be operated on private, authenticated networks or over trusted VPNs
+
+### Air-Gapped Machine Options
+
+- For highest security, physically remove or disable the network interface
+- Use USB drives (with strict auto-run restrictions) or QR codes to transfer transaction data
+
+### Advanced OS-Level Controls
+
+- Consider employing SELinux or similar tools for advanced security configurations
+- Restrict file system access and inter-process communications
+
+### Network Monitoring Tools
+
+Organizations must implement active network monitoring on signing devices:
+
+- [Little Snitch](https://www.obdev.at/products/littlesnitch/index.html) for active firewall and network monitoring
+- [Lulu](https://objective-see.org/products/lulu.html) as a free, open source alternative to Little Snitch
+- [Glasswire](https://www.glasswire.com/) can be used for Windows machines
+
+### DNS Security
+
+Use [DeFi DNS Whitelist](https://github.com/0xKoda/defi-dns-whitelist/tree/main) as a firewall for dedicated signing machines.
+
+## Communication Security
+
+### Basic requirements
+
+**Signal with verified safety number verification** for multisig communications: You MUST check the codes with the
+person you are interacting to « verify » them.
+How? Click on any chat > Contact name > View Safety Number > Call on another communication channel to verify them >
+Click at the bottom "Mark as Verified".
+If the account connects on a new device these codes will change & you will receive a security notification.
+
+- Screen lock enabled on mobile devices
+- 2FA enabled on backup platforms (Telegram/Discord/Slack)
+- Privacy settings maximized on all platforms
+- Session management - remove old/unknown devices regularly
+
+### Signal configuration
+
+- Registration lock enabled
+- Signal PIN configured
+- Hide phone number (use username only)
+- Safety number verification for all contacts
+- Disappearing messages for sensitive chats
+
+### URL Navigation Safety
+
+Links to URLs containing transaction requests or confirmation data (even those provided by trusted parties) must never
+be clicked - they must be navigated to by using bookmarks or typing them out manually.
+
+### For extra security
+
+**Enhanced verification**: Advanced safety procedures for critical communications
+
+- Code words for identity verification
+- Multiple verification channels for important requests
+- Regular communication channel security audits
+
+## Travel considerations
+
+### What to bring
+
+- Primary hardware wallet only (leave backups secure at home)
+- Essential devices only (laptop + phone)
+- Emergency contact information (offline copy)
+- Own chargers and cables
+
+### What NOT to bring
+
+- Seed phrases (never travel with these)
+- Backup hardware wallets
+- USB drives with sensitive data
+- Non-essential devices
+
+### Basic travel security
+
+- Use device locks at all times
+- Avoid public WiFi (use mobile hotspot or VPN)
+- Don't leave devices unattended in hotel rooms
+- Use hotel safes for device storage when out
+- Have offline backup of emergency contacts
+
+### For extra security
+
+**Enhanced travel procedures**: Additional precautions for high-risk situations
+
+- Disable biometric unlock at airports/borders (use PIN only) - prevents forced unlocking
+- Decline hotel housekeeping services - reduces access to devices
+- Advance notification to multisig team (72 hours for critical operations)
+- Use separate carrier SIM card for travel communications
+- Professional security assessment of travel destinations
+
+## Implementation priority
+
+### Start with basics
+
+Focus on fundamental security practices first
+
+- Password manager + 2FA on all accounts
+- Device encryption and screen locks
+- Signal setup with safety number verification
+- Basic travel security practices
+
+### Add extra security
+
+Implement additional measures based on your risk level and operational needs
+
+- YubiKeys for critical accounts
+- Dedicated signing devices for high-value operations
+- Enhanced travel procedures for international travel
+- Professional security assessments for critical roles
+
+Remember: Perfect security doesn't exist - focus on practical improvements that significantly reduce your risk while
+remaining operationally feasible.
+
+For the full OpSec article, see [Operational Security](/opsec/overview).
+
+---
+
+### PAGE: /incident-management/playbooks/decentralized-ir
+**Title:** Decentralized Incident Response | SEAL
+**Referenced by controls:** ir-5.1.1
+
+# Decentralized Incident Response Framework (DeIRF)
+
+
+
+
+A lightweight, end-to-end scaffold for security teams that work without a single authority.
+Use it as a menu, not a mandate.
+
+## 1. Guiding Principles
+
+| Principle | What it means in practice |
+| ----------- | --------------------------- |
+| **Zero-trust by default** | Assume every identity, device, and network path is potentially hostile. |
+| **Shared responsibility** | Any responder can start an action if quorum rules are met. |
+| **Minimum viable process** | Fewer steps, fewer blockers, faster containment. |
+| **Open tooling** | Prefer transparent, auditable, community-maintained tools. |
+| **Identity plurality** | Accept multiple forms of strong identity proof. |
+| **Evidence first** | Collect before you change anything. |
+| **Continuous learning** | Retrospective after every incident and drill. |
+
+---
+
+## 2. Roles and Identities
+
+| Role | Key duties | Identity options (at least two) |
+| ------ | ----------- | ---------------------------------- |
+| **First Reporter** | Sounds the alarm and starts evidence capture. | GPG key, DID, or multisig wallet signature |
+| **Triage Lead** | Confirms severity, forms a swarm, assigns tasks. | FIDO2 passkey, GPG, signed Matrix handle |
+| **Comms Lead** | Handles community and regulator updates. | Company issued OIDC, Lens profile |
+| **Containment Lead** | Executes on chain actions or host isolation. | Multisig signer, SSH CA cert |
+| **Recorder** | Maintains the timeline in an immutable log. | GPG key, signed git commit |
+
+> **Tip**: Publish a public mapping of handles to real names and keep it in a tamper evident repo.
+
+---
+
+## 3. Preparation Checklist
+
+| Item | Why it matters | Suggested tools |
+| ------ | ---------------- | ----------------- |
+| Asset inventory (code, infra, keys) | You cannot protect what you do not know. | ConfigDB + IaC scans, Sheet/CSV |
+| Log pipeline with reliable clock | Forensic accuracy and ordering. | Vector + Loki or OpenSearch, Elasticsearch, RunReveal |
+| Secure comms channels | Quick swarm with strong auth. | Matrix + E2EE, Signal groups, Wire |
+| Evidence bucket (write-once) | Keeps raw data safe. | S3 object-lock, Storj, or IPFS |
+| Automated alert rules | Detect known bad patterns. | On chain monitors, Falco, OpenZeppelin Defender, Slackbot |
+| Drill schedule | Muscle memory beats panic. | Calendar invites, gamedays, CTF |
+
+---
+
+## 4. Detection and Triage Flow
+
+1. **Alert fires or user reports an issue.**
+2. **First Reporter** opens a ticket in the transparent issue tracker (GitHub security advisory or private GitLab
+issue).
+3. **Triage Lead** checks severity matrix.
+4. If **P1**, spin up a temporary incident channel with a predefined template.
+5. Assign Leads and set T-minus deadlines.
+
+| Pros | Cons |
+| ------ | ------ |
+| Fast and clear ownership | Relies on people in multiple time zones being awake |
+| Public log builds trust | Attackers also watch public data if over-shared |
+
+---
+
+## 5. Containment Options
+
+| Method | When to use | Pros | Cons |
+| -------- | ------------- | ------ | ------ |
+| **Smart contract pause / circuit breaker** | Critical on-chain bug | Stops further damage instantly | Requires a pre-coded pause function and multisig |
+| **Multisig treasury freeze** | Key compromise or theft | No central keyholder | Coordination overhead |
+| **Host or pod quarantine** | Off-chain infra breach | Isolates without full shutdown | Needs orchestration rights |
+| **DNS or CDN reroute** | Phishing or DDoS | Quick traffic shift | May break some services |
+
+Keep a one-liner command ready for each action and store it in the runbook.
+
+---
+
+## 6. Eradication and Recovery
+
+1. Patch or replace vulnerable code.
+2. Peer review with at least two signers.
+3. Deploy to staging with replay of attack scenario.
+4. Roll forward to production by multisig or automated pipeline.
+5. Verify by monitoring metrics and logs for stability.
+
+| Automation hint | Keep it simple |
+| ----------------- | ---------------- |
+| GitHub Actions, ArgoCD, and Defender Autotasks are popular. | Always include a manual approval gate in case of false positives. |
+
+---
+
+## 7. Post-Incident Actions
+
+| Step | Purpose | Tool Example |
+| ------ | --------- | ------------- |
+| **Retrospective within 72 h** | Capture lessons before they fade. | Miro board, Markdown doc in repo |
+| **Update runbooks and detection rules** | Prevent repeat events. | Docs-as-code PR |
+| **Reward community reporters** | Encourage transparency. | Bug bounty payouts, incentive model |
+| **Public disclosure** | Build long-term trust. | Blog post plus on-chain message |
+
+---
+
+## 8. Quick-Start Templates
+
+| Need | Template location |
+| ------ | ------------------- |
+| Incident channel message | /templates/incident-kickoff.md |
+| Retrospective form | /templates/retro-form.md |
+
+---
+
+## 9. Pros and Cons of Decentralized IR
+
+| Aspect | Pros | Cons |
+| -------- | ------ | ------ |
+| **No single point of failure** | Resilience if one keyholder is offline. | Slower consensus for urgent actions. |
+| **Community trust** | Transparent logs and multisig votes. | Public scrutiny can amplify panic. |
+| **Open tools** | Low cost, auditable, extensible. | Less vendor support, more DIY. |
+| **Identity plurality** | Flexibility for global teams. | Complex to manage revocation and role drift. |
+
+---
+
+## 10. Keep It Alive
+
+- Run quarterly red team drills.
+- Rotate secrets on a fixed cadence.
+- Review identity proofs every six months.
+- Measure mean time to detect and contain.
+- Iterate on this framework during each retrospective.
+
+> **Remember**: Simplicity plus strong fundamentals beat heavy processes every time.
+
+---
+
+---
+
diff --git a/scripts/data/eval-briefs/sfc-multisig-ops.md b/scripts/data/eval-briefs/sfc-multisig-ops.md
new file mode 100644
index 00000000..e97f04e5
--- /dev/null
+++ b/scripts/data/eval-briefs/sfc-multisig-ops.md
@@ -0,0 +1,2903 @@
+# Evaluation Brief: sfc-multisig-ops
+
+## TASK
+
+For each control below, evaluate whether the candidate framework pages ACTUALLY meet the baseline requirements.
+A page must SUBSTANTIVELY address the baseline — not just mention related keywords.
+Be strict: if a baseline says "reviewed at least annually" and the page doesn't mention review cadence, that baseline is NOT met.
+
+## CONTROLS (24 total)
+
+### ms-1.1.1: Named Multisig Operations Owner
+**Question:** Is there a clearly named person or team accountable for multisig operations?
+**Baselines (1):**
+  1. Accountability scope covers policy maintenance, signer onboarding/offboarding, documentation accuracy, periodic reviews, and incident escalation
+**Candidate pages:** /wallet-security/secure-multisig-best-practices, /multisig-for-protocols/implementation-checklist, /multisig-for-protocols/overview
+
+### ms-1.1.2: Multisig Registry and Documentation
+**Question:** Do you maintain a complete, accurate, and accessible record of all your multisigs, their configurations, and their signers?
+**Baselines (3):**
+  1. Registry includes address, network, threshold, classification, purpose, signer addresses, controlled contracts, on-chain roles, and last review date
+  2. Updated within 24 hours for security-critical changes, 3 days for routine changes
+  3. Accessible to signers and key personnel
+**Candidate pages:** /wallet-security/secure-multisig-best-practices, /multisig-for-protocols/implementation-checklist, /multisig-for-protocols/setup-and-configuration
+
+### ms-2.1.1: Multisig Classification and Risk-Based Controls
+**Question:** Do you classify your multisigs by risk level and apply security controls proportional to each classification?
+**Baselines (5):**
+  1. Classification considers impact factors (financial exposure, protocol criticality, reputational risk) and operational needs (response time, coordination complexity)
+  2. Each classification maps to specific required controls (thresholds, quorum composition, review cadence)
+  3. All multisigs must have at least 3 distinct signers with a signing threshold of 50% or greater; N-of-N configurations should be avoided
+  4. Higher-risk classifications require stronger controls (more signers, higher thresholds)
+  5. Classifications reviewed every 6 months and after significant changes (TVL shifts, new products, protocol upgrades, security incidents)
+**Candidate pages:** /multisig-for-protocols/implementation-checklist, /wallet-security/secure-multisig-best-practices, /multisig-for-protocols/overview
+
+### ms-2.1.2: Contract-Level Security Controls
+**Question:** Have you evaluated contract-level security controls that could limit the impact of a multisig compromise?
+**Baselines (4):**
+  1. Evaluation covers timelocks, modules, guards, address whitelisting, invariant enforcement, and parameter bounds
+  2. Controls evaluated for each multisig based on classification
+  3. Security review required before enabling any module or guard
+  4. Decisions documented, including rationale for controls not implemented
+**Candidate pages:** /multisig-for-protocols/implementation-checklist, /multisig-for-protocols/overview, /wallet-security/secure-multisig-best-practices
+
+### ms-2.1.3: Exception Approval Process
+**Question:** Do you have a process for approving and tracking exceptions to multisig policies?
+**Baselines (2):**
+  1. Exceptions require documented justification, expiry date, compensating controls, and remediation plan
+  2. Critical-class exceptions require executive or security-lead approval
+**Candidate pages:** /multisig-for-protocols/implementation-checklist, /multisig-for-protocols/overview, /wallet-security/secure-multisig-best-practices
+
+### ms-2.1.4: Wallet Segregation
+**Question:** Do you distribute assets across multiple wallets to limit the impact of a single compromise?
+**Baselines (2):**
+  1. Segregation considers value, operational needs, and risk tolerance
+  2. Examples include hot/cold separation and treasury distribution across multiple wallets
+**Candidate pages:** /opsec/travel/guide, /wallet-security/secure-multisig-best-practices, /wallet-security/encumbered-wallets
+
+### ms-3.1.1: Signer Address Verification
+**Question:** Do you verify that each signer address on your multisigs belongs to the intended person?
+**Baselines (1):**
+  1. Verification process includes message signing with the signer address, verification via an independent tool, and documented proof of verification
+**Candidate pages:** /wallet-security/secure-multisig-best-practices, /multisig-for-protocols/implementation-checklist, /multisig-for-protocols/setup-and-configuration
+
+### ms-3.1.2: Signer Key Management Standards
+**Question:** Do you enforce signer key management standards?
+**Baselines (2):**
+  1. Hardware wallets required for all multisig operations
+  2. Each signer uses a fresh, dedicated address per multisig, used exclusively for that multisig's operations
+**Candidate pages:** /multisig-for-protocols/implementation-checklist, /wallet-security/secure-multisig-best-practices, /multisig-for-protocols/overview
+
+### ms-3.1.3: Seed Phrase Backup and Protection
+**Question:** Do you securely back up and protect signer seed phrases and recovery materials?
+**Baselines (4):**
+  1. Seed phrases never stored digitally, in cloud storage, or photographed
+  2. Backups are geographically distributed (disaster resistant)
+  3. No single point of compromise (theft resistant)
+  4. Recoverable if one operator is unavailable (operator-loss resistant)
+**Candidate pages:** /wallet-security/secure-multisig-best-practices, /opsec/travel/guide, /wallet-security/seed-phrase-management
+
+### ms-3.1.4: Signer Lifecycle Management
+**Question:** Do you have a defined process for adding, removing, and periodically verifying signers?
+**Baselines (2):**
+  1. Offboarded signers removed within 48-72 hours (Emergency-class), 7 days (Critical-class), 14 days (others)
+  2. Access reviews quarterly, confirming each signer still controls their key
+**Candidate pages:** /wallet-security/secure-multisig-best-practices, /multisig-for-protocols/setup-and-configuration, /wallet-security/signing-and-verification/secure-multisig-signing-process
+
+### ms-3.1.5: Signer Training and Assessment
+**Question:** Are signers trained and assessed on security practices before they are authorized to sign?
+**Baselines (3):**
+  1. Training covers transaction verification, emergency procedures, phishing and social engineering awareness
+  2. Practical skills assessment included
+  3. Annual refreshers; updates within 30 days of significant procedure changes
+**Candidate pages:** /wallet-security/secure-multisig-best-practices, /multisig-for-protocols/implementation-checklist, /opsec/appendices/case-studies
+
+### ms-3.1.6: Hardware Wallet Standards
+**Question:** Do you define and enforce hardware wallet standards for multisig operations?
+**Baselines (2):**
+  1. Wallet capability requirements include adequate display, clear signing support, PIN security, and firmware integrity verification
+  2. Procurement through verified supply chains (direct from manufacturer or authorized resellers), with device authenticity verification
+**Candidate pages:** /multisig-for-protocols/implementation-checklist, /multisig-for-protocols/overview, /wallet-security/secure-multisig-best-practices
+
+### ms-3.1.7: Secure Signing Environment
+**Question:** Do signers use a secure environment for signing operations?
+**Baselines (2):**
+  1. Device security requirements documented and enforced
+  2. Dedicated signing devices or network isolation for high-value operations
+**Candidate pages:** /wallet-security/secure-multisig-best-practices, /multisig-for-protocols/personal-security-opsec, /multisig-for-protocols/emergency-procedures
+
+### ms-3.1.8: Signer Diversity
+**Question:** Are your signers distributed across roles, entities, and geographies to prevent a single event from compromising quorum?
+**Baselines (1):**
+  1. Diversity requirements scale with multisig classification
+**Candidate pages:** /multisig-for-protocols/implementation-checklist, /wallet-security/secure-multisig-best-practices, /multisig-for-protocols/overview
+
+### ms-4.1.1: Transaction Handling Process
+**Question:** Do you have a defined, documented process for how transactions are proposed, verified, and executed?
+**Baselines (8):**
+  1. Process covers initiation, approval, simulation, execution, and confirmation
+  2. Defines who is authorized to initiate transactions
+  3. Each signer independently verifies transaction details (chain ID, target address, calldata, value, nonce, operation type) before signing
+  4. Transaction hashes compared across at least two independent interfaces (e.g., web UI and CLI, or web and mobile app)
+  5. DELEGATECALL operations to untrusted addresses flagged as high risk
+  6. High-risk transactions (large transfers, emergency actions, protocol changes) require waiting periods where feasible and elevated threshold approval
+  7. High-risk thresholds defined based on classification and reviewed periodically
+  8. Private transaction submission used when appropriate to prevent front-running or MEV extraction
+**Candidate pages:** /wallet-security/secure-multisig-best-practices, /wallet-security/signing-and-verification/secure-multisig-signing-process, /multisig-for-protocols/setup-and-configuration
+
+### ms-4.1.2: Transaction Audit Trails
+**Question:** Do you keep records of all transaction reviews, approvals, and executions?
+**Baselines (2):**
+  1. Retained for 3 years
+  2. Records include proposer, approvers, verification evidence, timestamps, and issues encountered
+**Candidate pages:** /multisig-for-protocols/backup-signing-and-infrastructure, /multisig-for-protocols/setup-and-configuration, /opsec/core-concepts/web3-considerations
+
+### ms-4.1.3: Tool and Platform Evaluation
+**Question:** Do you vet the tools and platforms used for multisig operations before adoption?
+**Baselines (2):**
+  1. Evaluation considers whether tools are open source or audited by 2+ reputable firms, have no known critical unpatched vulnerabilities, and have established ecosystem adoption
+  2. Formal process for adopting new tools
+**Candidate pages:** /multisig-for-protocols/implementation-checklist, /multisig-for-protocols/overview, /wallet-security/secure-multisig-best-practices
+
+### ms-4.1.4: Backup Signing Infrastructure
+**Question:** Do you have backup infrastructure in case your primary signing tools are unavailable?
+**Baselines (3):**
+  1. Alternate signing UI
+  2. 2-3 backup RPC providers
+  3. Alternate block explorer
+**Candidate pages:** /multisig-for-protocols/backup-signing-and-infrastructure, /multisig-for-protocols/implementation-checklist, /opsec/travel/guide
+
+### ms-5.1.1: Secure Communication Procedures
+**Question:** Do you have secure communication procedures for multisig operations, including standard identity verification?
+**Baselines (5):**
+  1. Dedicated primary and backup channels on different platforms
+  2. End-to-end encryption, MFA required, invitation-based membership
+  3. Signer identity verified as standard procedure during signing operations (e.g., code words, video call, secondary authenticated channel)
+  4. Documented procedures for channel compromise including switching to backup channels and out-of-band verification
+  5. All signers trained on these procedures; compromise response tested annually
+**Candidate pages:** /multisig-for-protocols/implementation-checklist, /wallet-security/secure-multisig-best-practices, /multisig-for-protocols/backup-signing-and-infrastructure
+
+### ms-5.1.2: Emergency Contact List
+**Question:** Do you maintain a current emergency contact list for all multisig stakeholders?
+**Baselines (3):**
+  1. Includes protocol security team, external security resources, legal/compliance contacts, and backup contacts for signers
+  2. Personal emergency contacts for each signer (e.g., trusted family member, close colleague) for situations where the signer is unreachable through normal channels
+  3. Reviewed every 6 months
+**Candidate pages:** /wallet-security/secure-multisig-best-practices, /multisig-for-protocols/implementation-checklist, /multisig-for-protocols/setup-and-configuration
+
+### ms-6.1.1: Emergency Playbooks
+**Question:** Do you have step-by-step emergency playbooks?
+**Baselines (3):**
+  1. Scenarios covered include key compromise, lost access, communication channel compromise, and urgent protocol actions
+  2. Each scenario has procedures and escalation paths
+  3. Playbooks accessible through at least one backup method independent of the primary documentation platform
+**Candidate pages:** /multisig-for-protocols/backup-signing-and-infrastructure, /opsec/travel/guide, /multisig-for-protocols/implementation-checklist
+
+### ms-6.1.2: Signer Reachability and Escalation
+**Question:** Can you reach enough signers to meet quorum at any time, including outside business hours?
+**Baselines (4):**
+  1. Response times by classification - Emergency less than 2 hours, Time-Sensitive 2-12 hours, Routine 24-48 hours
+  2. Paging covers all signers including external parties
+  3. Tested quarterly
+  4. Escalation paths documented
+**Candidate pages:** /wallet-security/secure-multisig-best-practices, /multisig-for-protocols/emergency-procedures, /multisig-for-protocols/planning-and-classification
+
+### ms-6.1.3: Multisig Monitoring and Alerts
+**Question:** Do you monitor all multisigs for unauthorized or suspicious activity?
+**Baselines (3):**
+  1. Monitored events include signer/threshold changes, transfers exceeding thresholds, nonce gaps, interactions with unknown addresses, failed transactions, module/guard changes, and low submitter/proposer balances
+  2. Alerting and escalation paths documented
+  3. Monitoring infrastructure protected against tampering
+**Candidate pages:** /wallet-security/secure-multisig-best-practices, /multisig-for-protocols/implementation-checklist, /multisig-for-protocols/setup-and-configuration
+
+### ms-6.1.4: Emergency Drills and Improvement
+**Question:** Do you regularly rehearse your emergency procedures and track improvements?
+**Baselines (3):**
+  1. Annual minimum
+  2. After major procedure changes
+  3. Documentation includes date, participants, response times, issues identified, and improvements made
+**Candidate pages:** /multisig-for-protocols/implementation-checklist, /multisig-for-protocols/emergency-procedures, /wallet-security/secure-multisig-best-practices
+
+---
+
+## FRAMEWORK PAGES (14 unique)
+
+### PAGE: /wallet-security/secure-multisig-best-practices
+**Title:** Secure Multisig Best Practices | SEAL
+**Referenced by controls:** ms-1.1.1, ms-1.1.2, ms-2.1.1, ms-2.1.2, ms-2.1.3, ms-2.1.4, ms-3.1.1, ms-3.1.2, ms-3.1.3, ms-3.1.4, ms-3.1.5, ms-3.1.6, ms-3.1.7, ms-3.1.8, ms-4.1.1, ms-4.1.3, ms-5.1.1, ms-5.1.2, ms-6.1.2, ms-6.1.3, ms-6.1.4
+
+# Secure Multisig Best Practices
+
+
+
+
+> Guidance for designing, operating, and auditing high-assurance multisigs. Use this as your single source for baseline
+> rules, setup guidance, and daily operations.
+
+## Who This Is For
+
+Advanced technical users, developers, Decentralized Autonomous Organizations (DAOs), and organizations responsible for
+managing protocol treasuries, smart contract ownership, or significant personal/collective assets.
+
+## Primary Goal
+
+The primary objective is to eliminate single points of failure and establish robust, distributed control over high-value
+assets and critical smart contract functions.
+
+## Core Concept: M-of-N Scheme
+
+A multisignature (multisig) wallet is a smart contract that requires a predefined minimum number of approvals `M` from a
+total set of authorized signers `N` to execute a transaction. This is known as an `M-of-N` scheme (e.g., 2-of-3,
+3-of-5).
+
+By distributing signing authority, a multisig ensures that the compromise of a single private key is insufficient to
+authorize the movement of funds or execute a privileged action.
+
+## General Rules
+
+### Thresholds & Configuration
+
+- Minimum of 3 signers
+- 50% signing threshold
+- 7+ signers for multisigs holding 1M+ in assets (USD equivalent)
+- Please see Classification Matrix in
+  [Planning & Classification](/multisig-for-protocols/planning-and-classification#step-3-classification-matrix)
+  for more information on threshold selection.
+- All signers must use hardware wallets
+- Multisigs managing assets on behalf of a DAO should set unlimited allowance with primary DAO agent
+- Signers on multisigs with critical protocol configuration or security roles are discouraged from using their
+addresses for other purposes. They should create a brand new wallet for that purpose instead.
+- All signing wallets should be monitored for any activity that is not directly related to multi-sig operations.
+- No multisigs should use modules/guards except those mentioned in
+[Setup & Configuration → Modules & Guards](/multisig-for-protocols/setup-and-configuration#modules--guards)
+unless clear justification and security review is provided
+- Threshold exceptions can be made for multisigs that are used in frequent operations but are highly constrained
+by smart contracts. For example, rate setting operations with tight bounds and a backup recovery mechanism to
+replace the multisig.
+
+#### Threshold Selection
+
+Avoid `N-of-N` schemes, as the loss of a single key would result in a permanent loss of access to all funds.
+
+#### Strategic Signer Distribution
+
+The security of a multisig depends entirely on the operational security (OpSec) of its individual signer keys. Storing
+multiple signer keys on the same device or in the same physical location negates the security benefits. Effective
+distribution strategies include:
+
+- Using different hardware wallet models and manufacturers.
+- Maintaining geographical separation for devices holding signer keys.
+- Assigning signer keys to different trusted individuals within an organization.
+- Using diverse client software to interact with the multisig to mitigate single-point-of-failure risks from a software
+vulnerability.
+
+#### Signer Composition Requirements
+
+- **Role Diversity**: Signers should be diverse individuals to reduce risk of multiple compromised accounts - a
+mix of executives, developers, and operational roles is recommended
+- **Technical Expertise**: Include a high number of competent, well-vetted technical signers that will understand full
+transaction details and effects in your signing quorum
+- **External Parties**: Multi-sigs managing high value wallets and contracts should have at least 1 additional required
+signer that is external to the organization (such as a security partner or trusted advisor)
+
+### Communication & Documentation
+
+- In the event of loss of access to keys or potential compromise of keys or communication channels, the signer must
+  immediately notify the other multisig participants and email your security contact - [Incident
+  Reporting](/multisig-for-protocols/incident-reporting)
+- Signers should use dedicated communication channels for multisig operations and maintain backup ways of reaching other
+  signers
+- All multisigs should be documented in the protocol documenting its purpose, general operating rules, multisig wallet
+  address, and list of signer addresses
+- Signers should verify their addresses by signing a message stating their affiliation and the multisig they intend to
+  join (entity affiliation is ok)
+
+#### Out-of-Band Verification for Admin Changes
+
+Any critical administrative action, such as adding or replacing a signer, must be verified through multiple, independent
+communication channels (e.g., a video call and a signed message) to prevent social engineering attacks.
+
+### Signer rotation
+
+- Signers can be rotated, but detailed documentation should be maintained
+- Any changes to signer composition should be documented in the protocol documentation
+- Any signer change should not reduce the number of signers or decrease the threshold unless clear justification is
+  given and documented
+
+#### Updating signer addresses
+
+If the original key is accessible:
+
+- The signer proves ownership of a new address by signing a message with their existing address.
+- The signer must follow the steps in
+[Signer Verification process](/multisig-for-protocols/registration-and-documentation#signer-verification-process)
+
+If the original key is lost:
+
+- The signer must verify their identity to the other signers through alternative methods such as:
+  - Authentication via a verified social media account.
+  - A video call with other signers for confirmation.
+  - Other sufficient methods.
+
+### Training & Drills
+
+- All signers should complete training as outlined in the
+[Implementation Checklist](/multisig-for-protocols/implementation-checklist)
+- For multisigs that perform emergency operations like pausing, teams should have processes to regularly conduct drills
+  to ensure operational readiness and signer availability
+
+## Setup Best Practices
+
+See General Rules above for thresholds and signer distribution guidance.
+
+- **Practice on Testnet:** Before deploying on mainnet, thoroughly practice wallet creation, transaction signing, and
+owner management on a test network.
+
+- **Timelocks:** Enforce a mandatory delay between the approval of a transaction and its execution. This provides a
+critical window for the community or team to detect and react to malicious proposals.
+
+- **Veto Quorum:** Establish a smaller veto group separate from the confirmation quorum to review and confirm
+transaction legitimacy. Organizations can establish veto quorums to bypass time-locks in case of emergency.
+The standard quorum plus two additional signers should be required to bypass.
+
+- **Role-Based Access Control (RBAC):** Implement modules that grant specific, limited permissions to certain addresses
+(e.g., a "pauser" or "executor" role) without making them full owners, adhering to the principle of least privilege.
+
+- **Disaster Recovery Plan:** Establish a clear, documented process for what to do when a signer is compromised, the
+multi-signature UI is down, or other emergencies arise. These should be done at regular intervals.
+
+## Operational Best Practices
+
+- **Signer Key Revocation and Replacement:** A  feature of multisigs is the ability to add, remove, or replace signer
+keys. If a signer's key is compromised or lost, it can be revoked and replaced with a new, secure key through a
+transaction approved by the remaining owners, preserving the integrity of the wallet's assets without needing to migrate
+funds.
+
+- **Secure Signing Environment:** For maximum security, all signing activities should be performed on a dedicated,
+air-gapped, or hardened device running a secure OS. Using a primary work laptop significantly increases the risk of
+malware interference.
+
+- **Independent Transaction Verification:**  Before signing, always verify the raw transaction data (target address,
+function call, parameters) to ensure it matches the intended operation.
+
+- **Out-of-Band Verification for Admin Changes:** Any critical administrative action, such as adding or replacing a
+signer, must be verified through multiple, independent communication channels (e.g., a video call and a signed message)
+to prevent social engineering attacks.
+
+- **Active Monitoring:** Implement monitoring and alerting systems to be immediately notified of any on-chain activity
+related to the multisig, including proposed transactions, new signatures, and owner changes (e.g., using tools like
+[Safe Watcher](https://github.com/Gearbox-protocol/safe-watcher) ).
+
+- **Documented Procedures:** Maintain clear, secure, and accessible documentation for all multisig procedures, including
+  transaction creation, signing, and emergency recovery plans.
+- **General Signing Guidelines:** Use hardware wallets, dedicated signing profiles, and re-verify before execution.
+  Require a "how to check" guide and communicate status after signing (e.g., "checked, signed, X more required"). Last
+  signer executes when applicable.
+
+## Contract-Level Security
+
+- **Invariant Enforcement:** Design contracts to enforce invariants and expected state changes such as token balance
+changes, ownership and administration, and proxy implementation addresses. Ensure contracts automatically revert
+transactions if any invariant is violated.
+
+- **Address Whitelisting:** Approved smart contract and wallet addresses must be added to a whitelist that is enforced
+at the contract-level. Interactions with all other addresses should be denied and revert the transaction. Updating the
+whitelist should require an extra signer in addition to the standard transaction approval quorum.
+
+For detailed configuration guidance, see
+[Setup & Configuration → Contract-Level Controls](/multisig-for-protocols/setup-and-configuration#contract-level-controls).
+
+## Acknowledgements
+
+Some ideas were borrowed from the [EF's multisig SOP notes](https://notes.ethereum.org/@fredrik/multisig-sop) and
+[Manifold Finance multisig best practices](https://hackmd.io/@manifoldx/multisig-best-practices).
+
+---
+
+---
+
+### PAGE: /multisig-for-protocols/implementation-checklist
+**Title:** Multisig Implementation Checklist | SEAL
+**Referenced by controls:** ms-1.1.1, ms-1.1.2, ms-2.1.1, ms-2.1.2, ms-2.1.3, ms-3.1.1, ms-3.1.2, ms-3.1.5, ms-3.1.6, ms-3.1.8, ms-4.1.3, ms-4.1.4, ms-5.1.1, ms-5.1.2, ms-6.1.1, ms-6.1.3, ms-6.1.4
+
+# Implementation Checklist
+
+
+
+
+This checklist ensures all multisig participants have the knowledge and skills necessary for secure operations. Complete
+all applicable sections before beginning multisig operations.
+
+## For Multisig Administrators
+
+### Planning & Setup
+
+- [ ] I have classified my multisig using the impact and operational framework from [Planning & Classification](/multisig-for-protocols/planning-and-classification)
+- [ ] I have selected appropriate thresholds based on the classification guidance
+- [ ] I have identified and verified all signers for the multisig
+- [ ] I have deployed the multisig with correct configuration
+- [ ] I have set up required modules (eg. allowance module to rescue assets)
+
+### Documentation & Communication
+
+- [ ] I have classified and documented the new multisig using templates from [Registration & Documentation](/multisig-for-protocols/registration-and-documentation)
+- [ ] I have set up primary and backup communication channels per [Communication Setup](/multisig-for-protocols/communication-setup)
+- [ ] I have tested emergency notification procedures
+- [ ] I have documented emergency contact information
+
+### Ongoing Management
+
+- [ ] I have established procedures for regular reviews and updates per [Registration & Documentation](/multisig-for-protocols/registration-and-documentation)
+- [ ] I have set up backup infrastructure and tested alternative UIs per [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)
+- [ ] I have verified all signers have completed training requirements
+- [ ] I understand signer rotation procedures for my multisig type
+
+## For Signers
+
+### Hardware & Security Setup
+
+- [ ] I have purchased recommended hardware wallet from authorized source per [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds)
+- [ ] I have set up my hardware wallet with proper firmware and PIN
+- [ ] I have created and tested backup hardware wallet with same seed
+- [ ] I have stored my seed phrase securely using approved methods from [Seed Phrase Management](/wallet-security/seed-phrase-management)
+- [ ] I have created dedicated accounts for each multisig I'm signing for
+
+### Operational Readiness
+
+- [ ] I have joined multisig communication channels (primary and backup) per [Communication Setup](/multisig-for-protocols/communication-setup)
+- [ ] I have verified my signer address using the required signature process from [Joining a Multisig](/multisig-for-protocols/joining-a-multisig)
+- [ ] I understand my multisig's classification and response time requirements
+- [ ] I have completed a test transaction with the multisig team
+
+### Transaction Verification
+
+- [ ] I can use approved verification tools (Safe CLI Utils, OpenZeppelin SafeUtils for EVM) from [Tools & Resources →
+  Transaction Verification](/wallet-security/tools-&-resources#transaction-verification)
+- [ ] I understand how to verify transaction hashes before signing
+- [ ] I can decode and verify transaction details (amounts, recipients, contract calls)
+- [ ] I have practiced verifying both simple transfers and complex transactions
+
+### Emergency Preparedness
+
+- [ ] I have downloaded backup UIs (Eternal Safe for EVM, Squads public client for Solana) per [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)
+- [ ] I know how to sign transactions when primary UI is down per [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)
+- [ ] I understand emergency procedures for key compromise and communication failures per [Emergency Procedures](/multisig-for-protocols/emergency-procedures)
+- [ ] I have tested backup communication methods with my team
+- [ ] I know who to contact for security incidents and emergencies per [Incident Reporting](/multisig-for-protocols/incident-reporting)
+
+### Personal Security
+
+- [ ] I have enabled 2FA on all accounts with approved methods (YubiKey preferred) per [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec)
+- [ ] I use dedicated devices or accounts for multisig operations when required
+- [ ] I have implemented travel security procedures appropriate for my risk level
+- [ ] I understand incident reporting procedures for security concerns
+
+### Compliance
+
+- [ ] I have read and understand all sections of this security framework
+- [ ] I understand my specific role requirements based on multisig classification
+- [ ] I know how to properly offboard when leaving a multisig role per [Offboarding](/multisig-for-protocols/offboarding)
+- [ ] I commit to following these security procedures and reporting any deviations
+
+## Specialized Training by Use Case
+
+### Emergency Response Multisigs
+
+Additional requirements from [Use Case Specific Requirements](/multisig-for-protocols/use-case-specific-requirements):
+
+- [ ] I understand 24/7 availability requirements
+- [ ] I have participated in emergency simulation drills
+- [ ] I know how to respond to emergency paging
+- [ ] I understand streamlined verification procedures for emergencies
+
+### Treasury Multisigs
+
+- [ ] I understand allowance module configuration and purpose
+- [ ] I know governance rescue procedures
+- [ ] I understand financial reporting requirements
+
+### Smart Contract Control Multisigs
+
+- [ ] I understand timelock configuration per [Use Case Specific Requirements → Timelock Configuration](/multisig-for-protocols/use-case-specific-requirements#timelock-configuration)
+- [ ] I know how to verify staged transactions
+- [ ] I understand higher threshold requirements for upgrades
+
+## Practical Skills Assessment
+
+### Transaction Verification (EVM)
+
+- [ ] I can successfully verify a Safe transaction hash using CLI tools
+- [ ] I can decode transaction calldata and identify recipients and amounts
+- [ ] I can identify risky transaction types and warnings
+- [ ] I can verify nested Safe transactions if applicable
+
+### Transaction Verification (Solana)
+
+- [ ] I can analyze Solana transaction instruction data
+- [ ] I can convert hex values to decimal for amount verification
+- [ ] I can identify different transaction types (SOL transfer, token transfer, config changes)
+
+### Emergency Procedures
+
+- [ ] I can access backup UIs and complete a transaction
+- [ ] I can contact team via backup communication channels
+- [ ] I know how to report key compromise immediately
+- [ ] I can execute identity verification procedures if needed
+
+### Tool Proficiency
+
+- [ ] I am comfortable using my hardware wallet for signing
+- [ ] I can navigate backup block explorers
+- [ ] I can use alternative RPC endpoints
+- [ ] I understand how to manually simulate transactions
+
+## Documentation Review
+
+### Required Reading Completed
+
+- [ ] [Secure Multisig Best Practices](/wallet-security/secure-multisig-best-practices) - Core requirements for all multisigs
+- [ ] [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds) - Device security requirements
+- [ ] [Seed Phrase Management](/wallet-security/seed-phrase-management) - Key protection procedures
+- [ ] [Safe Multisig: Step-by-Step
+Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification) - Signing procedures
+- [ ] [Emergency Procedures](/multisig-for-protocols/emergency-procedures) - Crisis response protocols
+- [ ] [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec) - Account and device security
+
+### Role-Specific Documentation
+
+**For Administrators:**
+
+- [ ] [Planning & Classification](/multisig-for-protocols/planning-and-classification)
+- [ ] [Setup & Configuration](/multisig-for-protocols/setup-and-configuration)
+- [ ] [Registration & Documentation](/multisig-for-protocols/registration-and-documentation)
+- [ ] [Communication Setup](/multisig-for-protocols/communication-setup)
+- [ ] [Registration & Documentation](/multisig-for-protocols/registration-and-documentation)
+
+**For Specialized Use Cases:**
+
+- [ ] [Use Case Specific Requirements](/multisig-for-protocols/use-case-specific-requirements)
+- [ ] [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)
+- [ ] [Use Case Specific Requirements → Timelock Configuration](/multisig-for-protocols/use-case-specific-requirements#timelock-configuration)
+  (if applicable)
+
+## Certification and Acknowledgment
+
+### Training Completion
+
+- [ ] I have completed all applicable training requirements
+- [ ] I have successfully demonstrated practical skills
+- [ ] I understand the security implications of my role
+- [ ] I acknowledge my responsibilities as a multisig participant
+
+### Ongoing Commitment
+
+- [ ] I commit to following all security procedures outlined in this framework
+- [ ] I will report any security incidents or concerns promptly
+- [ ] I will participate in regular training updates and refreshers
+- [ ] I will maintain the required level of security for my role
+
+### Trainer Verification (if applicable)
+
+**For organizations requiring formal training:**
+
+Trainer: _________________ Date: _________________
+
+Trainee has demonstrated competency in:
+
+- [ ] Transaction verification procedures
+- [ ] Emergency response protocols
+- [ ] Security best practices
+- [ ] Role-specific requirements
+
+**Signature:** _________________
+
+## Refresher Training Schedule
+
+### Regular Updates
+
+- **Monthly**: Review emergency procedures and contact information
+- **Quarterly**: Practice backup system usage and emergency drills
+- **Annually**: Complete full framework review and updates
+- **As needed**: Training on new tools, procedures, or threats
+
+### Trigger Events
+
+Additional training required after:
+
+- Framework updates or changes
+- Security incidents affecting the team
+- New tool adoption
+- Role changes or additional responsibilities
+
+## Related Documents
+
+All documents in this framework serve as training materials. Refer to individual documents for detailed procedures and
+requirements specific to your role.
+
+---
+
+### PAGE: /multisig-for-protocols/overview
+**Title:** Multisig Security Framework | SEAL
+**Referenced by controls:** ms-1.1.1, ms-2.1.1, ms-2.1.2, ms-2.1.3, ms-3.1.2, ms-3.1.6, ms-3.1.8, ms-4.1.3
+
+# Multisig Security Framework
+
+
+
+
+## How to use this guide
+
+**Quick start**: New to multisigs? Start with the Foundation for the essentials, then jump to your role:
+
+- Setting up a new multisig? → Multisig Administration: [Setup &
+  Configuration](/multisig-for-protocols/setup-and-configuration) and [Registration &
+  Documentation](/multisig-for-protocols/registration-and-documentation)
+- Joining as a signer? → [Joining a Multisig](/multisig-for-protocols/joining-a-multisig) and [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds)
+- Need to sign a transaction? → Signing & Verification:
+[Safe Multisig](/wallet-security/signing-and-verification/secure-multisig-safe-verification) and
+[Squads](/wallet-security/signing-and-verification/secure-multisig-squads-verification)
+- Emergency situation? → [Emergency Procedures](/multisig-for-protocols/emergency-procedures)
+
+## Core principles
+
+- **Security first**: Every multisig must meet [minimum security standards](/wallet-security/secure-multisig-best-practices)
+- **Operational readiness**: Procedures that work under pressure
+- **Clear accountability**: Everyone knows their role and responsibilities
+- **Emergency preparedness**: Plans for when things go wrong
+
+## Framework Structure
+
+### 1. Foundation
+
+- [Secure Multisig Best Practices](/wallet-security/secure-multisig-best-practices) - Core requirements for all multisigs
+
+### 2. Multisig Administration
+
+- [Planning & Classification](/multisig-for-protocols/planning-and-classification) - Assess requirements and classify risk
+- [Setup & Configuration](/multisig-for-protocols/setup-and-configuration) - Deploy and configure multisigs
+- [Registration & Documentation](/multisig-for-protocols/registration-and-documentation) - Document and verify setup
+- [Communication Setup](/multisig-for-protocols/communication-setup) - Establish secure communication channels
+- [Use Case Specific Requirements](/multisig-for-protocols/use-case-specific-requirements) - Special requirements by type
+
+### 3. For Signers
+
+- [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds) - Secure device configuration
+- [Seed Phrase Management](/wallet-security/seed-phrase-management) - Protect your recovery keys
+- [Joining a Multisig](/multisig-for-protocols/joining-a-multisig) - Verification and onboarding process
+- [Safe Multisig: Step-by-Step
+Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification) - Safely verify and sign transactions
+- [Emergency Procedures](/multisig-for-protocols/emergency-procedures) - Handle key compromise and emergencies
+- [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure) - Use backup interfaces
+- [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec) - Protect your accounts and devices
+- [Incident Reporting](/multisig-for-protocols/incident-reporting) - Report security issues and incidents
+- [Offboarding](/multisig-for-protocols/offboarding) - Safely leave a multisig role
+
+### 4. Reference
+
+- [Implementation Checklist](/multisig-for-protocols/implementation-checklist) - Verify readiness for multisig operations
+
+---
+
+### PAGE: /multisig-for-protocols/setup-and-configuration
+**Title:** Multisig Setup & Configuration | SEAL
+**Referenced by controls:** ms-1.1.2, ms-3.1.1, ms-3.1.4, ms-4.1.1, ms-4.1.2, ms-5.1.2, ms-6.1.3
+
+# Setup & Configuration
+
+
+
+
+This page covers the technical deployment and configuration of multisigs on supported networks.
+
+## Basic Setup
+
+### EVM Networks (Ethereum, Base, etc.)
+
+1. Go to [https://app.safe.global](https://app.safe.global)
+2. Connect wallet of the deploying signer
+3. Create new Safe with your determined threshold and signer addresses
+4. **Multi-network deployment**: If deploying on multiple networks, Safe UI will offer to replicate the configuration
+
+### Solana
+
+1. Go to [https://squads.xyz/squads-multisig](https://squads.xyz/squads-multisig)
+2. Connect wallet of the deploying signer
+3. Create new multisig with your determined threshold and signer addresses
+
+## Self-Hosted Multisig UI
+
+Multi-sig coordination UIs should be self-hosted to eliminate supply chain risk. Hosted UI should be IP restricted to
+allow access only from signer machines.
+
+Deploy from [Safe Wallet Monorepo](https://github.com/safe-global/safe-wallet-monorepo/tree/dev/apps/web).
+While it should not be your final line of defense, securing the UI does protect your verification process
+from being compromised by supply-chain attacks.
+
+For emergency situations when the primary UI is unavailable, see
+[Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure).
+
+## Delegated Proposer
+
+It is recommended, but not required to authorize a separate transaction proposer for a Safe. This address can prepare
+transactions for signers to sign but is not an authorized signer on the Safe. Therefore **there is no risk of malicious
+signatures which can affect the Safe assets**. This wallet can hold no funds and simply act as a proposer. The primary
+reason to have a delegated proposer is that the hash verification utilities depend on the Safe API (unless details are
+entered manually). Until a transaction is **proposed** it does not show up in the API so the hash verification tools
+cannot detect it.
+
+![Delegated proposer configuration interface](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/delegated-proposer-configuration-interface.png)
+
+## Modules & Guards
+
+### Allowance Module (Required for Treasury Multisigs)
+
+If your multisig will hold any assets on behalf of the DAO, set up governance rescue capability:
+
+**Mainnet configuration:**
+
+- **Module**: Allowance Module
+- **Grant allowance to**: DAO Agent
+- **Amount**: Max value for each token held
+
+### Zodiac Delay Modifier (Time-Locks)
+
+Consider using [Zodiac Modifier Delay](https://github.com/gnosisguild/zodiac-modifier-delay/tree/main) or equivalent
+for implementing on-chain time-lock transaction delays to Safe wallets.
+
+See [Use Case Specific Requirements](/multisig-for-protocols/use-case-specific-requirements#timelock-configuration)
+for detailed timelock configuration guidance.
+
+### Other Modules
+
+Do not install any other modules or guards without explicit governance approval and security review.
+
+## Contract-Level Controls
+
+**Advanced Configuration Warning:** The following contract-level controls are advanced security features that can
+provide additional protection but require careful implementation. Before implementing any guards or modules:
+
+- **Conduct thorough research** on available guard implementations and their compatibility with your multisig setup
+- **Ensure all guards are well-audited** by reputable security firms before deployment
+- **Test extensively** on testnets to verify functionality and edge cases
+- **Understand the risks**: Incorrect configuration or incompatible guards can render your multisig unusable,
+potentially locking access to funds permanently
+
+### Address Whitelisting
+
+Approved smart contract and wallet addresses must be added to a whitelist that is enforced at the contract-level.
+Interactions with all other addresses should be denied and revert the transaction. Updating the whitelist should
+require an extra signer in addition to the standard transaction approval quorum.
+
+### Invariant Enforcement
+
+Design contracts to enforce invariants and expected state changes such as token balance changes, ownership and
+administration, and proxy implementation addresses. Ensure contracts automatically revert transactions if any
+invariant is violated.
+
+## Initial Testing
+
+### Verify Basic Functionality
+
+1. **Small test transaction**: Send a low-value token transfer (e.g., 1 USDS or equivalent)
+2. **All signers test**: Ensure each signer can successfully sign the test transaction
+3. **Confirm execution**: Verify the transaction executes as expected
+4. **Test communication**: Use your established channels to coordinate the test
+
+## Pre-Launch Checklist
+
+- [ ] Safe deployed with correct threshold
+- [ ] All signer addresses added and [verified](/multisig-for-protocols/registration-and-documentation#signer-verification-process)
+- [ ] Allowance module configured (if required)
+- [ ] Test transaction completed successfully
+- [ ] All signers confirmed they can sign
+- [ ] [Communication channels](/multisig-for-protocols/communication-setup) tested during transaction
+- [ ] Safe addresses documented for all networks
+
+### Practice on Testnet
+
+Before deploying on mainnet, thoroughly practice wallet creation, transaction signing, and owner management on
+a test network.
+
+Once setup is complete, proceed to [Registration &
+Documentation](/multisig-for-protocols/registration-and-documentation) for registration and documentation requirements.
+
+## Nested Safes
+
+A nested Safe is one in which a Safe is set as a signer on another Safe rather than an EOA. This can be useful on a
+case-by-case basis. For example, if a signer is an entity that might want to have multiple individual signers, the
+nested Safe could have a 1/X threshold allowing anyone authorized on the team to sign. However, this configuration
+allows the signers on the nested Safe to update the signer addresses without needing authorization from the main Safe.
+
+It is generally recommended **not** to use nested safe on protocol multisigs unless there is a specific use case that
+it enables.
+
+## Next Steps
+
+After completing setup:
+
+1. [Registration & Documentation](/multisig-for-protocols/registration-and-documentation) - Document your multisig
+2. [Communication Setup](/multisig-for-protocols/communication-setup) - Establish secure communication
+3. [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds) - Ensure all signers are properly configured
+
+## Active Monitoring
+
+Implement monitoring and alerting systems to be immediately notified of any on-chain activity related to the multisig,
+including proposed transactions, new signatures, and owner changes (e.g., using tools like [Safe
+Watcher](https://github.com/Gearbox-protocol/safe-watcher)).
+
+### Immutable Monitoring Channels
+
+Monitoring channels (e.g. email, Slack or Telegram chats) must be immutable (or trigger alerts when their configuration
+changes or logs are deleted/tampered with) and redundant such that an admin could not disable or tamper with one
+monitoring channel without generating an alert on the other channel.
+
+---
+
+### PAGE: /opsec/travel/guide
+**Title:** Travel Security Guide
+**Referenced by controls:** ms-2.1.4, ms-3.1.3, ms-4.1.4, ms-6.1.1
+
+# Personal security travel guide — full
+
+
+
+
+Travel introduces unique security risks to your digital assets and sensitive information. Proper preparation before,
+vigilance during, and careful review after travel creates a comprehensive defense strategy that balances security
+with practical usability.
+
+When we travel, our normal security routines are disrupted, and we face elevated risks from physical theft, digital
+surveillance, border inspections, and social engineering. Web3 professionals face additional challenges when traveling
+with crypto assets or access to treasury funds. The resources in this guide provide practical guidance for maintaining
+operational security while traveling.
+
+> 🔑 Key Takeaway: Minimize data exposure by carrying only essential devices with full-disk encryption and updated
+> software. Secure accounts with backup 2FA methods, avoid biometrics at borders, use trusted networks with VPNs, and
+> never leave devices unattended. Guard against USB attacks, shoulder surfing, and hidden cameras. For crypto, use
+> strong passphrases and never travel with seed phrases. Upon returning, scan devices for malware and consider resetting
+> high-risk devices.
+
+{/* separator */}
+
+> ❗ This is not, by any means, an extensive guide on this subject or expected to be followed at its core. Its intention
+> is to guide and provide hints as to where to apply security. This will vary depending on case to case, or, in other
+> words, the risks you expose yourself to, by specifically traveling.
+
+This guide is categorized into four sections:
+
+1. **Before traveling:** All the things you could do before you depart, such as hardening some devices or making sure
+you have a backup of the data you’ll be traveling with, even letting know someone you’ll be calling in case of an
+emergency and how to identify you. This does not necessarily mean that if you’re reading this while traveling you cannot
+do anything from that list, only that it might be more challenging to execute depending on your context.
+2. **While traveling:** All the things you have to pay attention to or take care of while on the move. Is it necessary
+to connect to that conference’s WiFi? Have you checked if there is a camera that might be recording your keystrokes?
+Leaving your computer unattended or just running whatever software your hackathon teammate asks you to download in order
+for your promising project to win.
+3. **Returning home:** Not in the literal sense of it, but directed toward all the things you have to do after your
+travels. From updating your processes based on experience to wiping exposed devices before rejoining them to your
+networks.
+4. **Additional information for high-profile targets:** If you are a high-profile target, you’ll evidently realize that
+some of these initial suggestions fall short within your threat model. This section provides a hint toward profiles like
+yours.
+
+## Before traveling
+
+> 💡**Remove or securely store** any data, devices, printed files, and documents **you don’t absolutely need on the
+> trip**. The less sensitive information and fewer critical assets you carry, the lower the risk and impact if loss,
+> theft, or inspection occurs. Minimize your digital and physical footprint by leaving backups and originals securely at
+> home or in trusted locations, and encrypt what must travel with you. This principle applies to laptops, phones,
+> hardware wallets, paper backups, and any portable storage media.
+
+### **Perform a quick threat model**
+
+Even if you are already traveling, take 5 minutes to map out your risks. Identify **what assets** you're carrying
+(laptops, phones, hardware wallets, seed phrases, account access), **who might target them** (thieves, cybercriminals,
+border agents, etc.), and **how attacks might happen** (device theft, tampering, malware, coercion). For each threat,
+plan a mitigation. For example, if you're carrying a hardware wallet, a threat is pickpocketing – mitigation could be
+keeping it attached to yourself (just don't use ledger's necklace visibly) and securing it with a secure PIN/passphrase
+(no patterns, not repeated across devices).
+
+This exercise keeps security measures proportionate to your situation.
+
+### **Secure devices with encryption & updates**
+
+Enable full-disk encryption on all devices (laptops, phones, tablets) to protect data if lost or stolen. Most modern
+OSes have this by default (e.g. BitLocker for Windows, FileVault for MacOS, LUKS for Linux,or Android/iOS encryption –
+just ensure a strong password/PIN is set).
+
+Use popular devices like iPhones and Pixels. Install the latest OS and app updates since these patch security
+vulnerabilities. This does not mean that using the latest versions is the safest take, but usually there's a balanced
+trade-off when they got security patches. You can also consider to install — only trustworthy — mobile security
+applications, which try to add a layer of control and also reminds you of important security updates.
+
+**Note:** On iOS, due to sandboxing, apps can't scan the entire OS for malware, so many security apps focus on VPN,
+phishing web protection, breach alerts, etc.
+
+If you must bring high-risk confidential data, consider encrypting those files individually using tools like VeraCrypt,
+FileVault, BitLocker, LUKS/dm-crypt, and more.
+
+### **Back up and prepare for loss**
+
+Back up your devices before travel (and ensure cloud backups like iCloud/Google are up to date). This way, if a device
+is lost or confiscated, you won’t lose important information. Record device details (make, model, serial numbers, IMEI
+for phones) and keep that list separate – it will help in filing reports or remote-wipe commands.
+
+If your company uses Mobile Device Management (MDM) on phones or laptops, verify the device is enrolled and you know how
+to trigger a remote wipe or “lost mode.” Test “Find My” or equivalent device-finding services so you can use them if
+needed. Pack chargers and cables so you won’t need to borrow unknown ones (which could be malicious).
+
+### **Protect Accounts with 2FA redundancy**
+
+Plan for how you'll access accounts that use two-factor authentication if your main device is unavailable. For
+authenticator apps (TOTP codes), **export backup codes** for your important accounts and keep them **securely** in
+services like 1Password or NordPass (you can check passwordmanager.com for more information on which one to pick).
+Alternatively, consider storing them elsewhere physically. If your 2FA is tied to a phone number (SMS or voice),
+**disable SMS for 2FA**. For technologies that are unfortunately dependent on phone numbers, use a separate line
+(not your personal one) from services like Google Voice, Burner App or SLYFONE. Transfer your number to an eSIM since
+[they are harder to physically steal or swap than a physical SIM](https://support.apple.com/en-ca/118227#:~:text=Use%20eSIM%20while%20traveling%20internationally,obtain%2C%20carry%2C%20and%20swap).
+
+Ensure your password manager is accessible – many like 1Password have a *Travel Mode* that removes sensitive vaults from
+your device while you travel (you can restore them later). This limits exposure if your
+[device is searched or seized](https://www.schneier.com/blog/archives/2025/04/cell-phone-opsec-for-border-crossings.html).
+
+You can also register a backup or alternative 2FA method, like a secondary phone (the device) or a PIN-protected
+hardware key to be used as a passkey. Be responsible with the use of software passkeys, particularly in situations
+where you are using a password manager to store both your passwords and passkeys, as this creates a single point of
+failure.
+
+### **Secure your wallets and keys**
+
+**Hardware wallets (e.g. Ledger, Trezor):** Update the firmware and test the device before you leave, don't do this
+while traveling. **Do NOT bring any written seed phrases** under any circumstance – seed backups are unencrypted keys
+that are far easier to steal or copy than a hardware device. Leave seed backups in a secure place, travel only with
+your hardware wallet if necessary. Enable all security features on the device (set a strong PIN, and use a BIP39
+passphrase for
+example, if supported) so that even if the device is stolen, the amount of required information to access your crypto,
+is high. Carry hardware wallets and security keys **in your carry-on or under your sight**, not in checked luggage, to
+avoid loss or tampering.
+
+**Yubikeys and 2FA tokens:** Bring them to protect logins and make sure they're enabled on your
+critical accounts. Keep them on your person or in a separate bag from your laptop/phone so that a thief or snoop can't
+easily steal both at once. If you have a **spare hardware wallet or Yubikey**, you might leave one at home as a backup
+in case the one you carry is lost. Add, when possible, an extra layer of security to the token, such as a PIN code.
+
+### **Lock down phones**
+
+On your smartphone, take advantage of security settings **before** you travel. Set a strong passcode (not just a 4-digit
+PIN or pattern). Consider **disabling Touch ID/Face ID** if you might face situations where someone could force-unlock
+your device using your biometrics – in many jurisdictions, authorities can compel a fingerprint or face scan more easily
+than a memorized password
+[.](https://www.schneier.com/blog/archives/2025/04/cell-phone-opsec-for-border-crossings.html#:~:text=deactivate%20biometric%20security%20and%20require,10%20failed%20PIN%20unlock%20attempts)
+At a minimum, know how to quickly and
+[**temporarily disable biometrics**](https://news.ycombinator.com/item?id=43630624);
+for example, on an iPhone,
+[holding the side button and a volume button will trigger an emergency mode that requires the passcode to unlock](https://www.themacguys.com/essential-travel-security-tips-for-apple-devices/).
+On Android, use *Lockdown* mode if available (which only temporarily disables biometrics and is different
+from iOS Lockdown Mode).
+
+If you have an iPhone, enable **Lockdown Mode** (extreme protection on iOS) even if you are not at
+[high risk or traveling to a high-threat region](https://www.themacguys.com/essential-travel-security-tips-for-apple-devices/#:~:text=This%20mode%20is%20ideal%20when,or%20dealing%20with%20sensitive%20data)
+ – but be aware [it restricts many features](https://support.apple.com/en-gb/105120), though totally worth it.
+
+Disabling or restricting USB debugging on Android and using iOS USB restricted mode helps prevent unauthorized physical
+USB access and reduces risks from malicious cables or compromised charging stations.
+
+If your phone is managed by work (MDM), inform your IT team of your travel so they can assist with any location-based
+security policies and ensure you have the latest security profile. Finally, consider using a **dedicated eSIM/local
+SIM** for travel data. This can protect your primary phone number (you can keep your main line on eSIM and turn it off,
+while using a local data eSIM for mobile internet) and avoids physical SIM issues.
+
+**Configure additional phone protections:** On iOS devices, disable Control Center and Notification Center access from
+the lock screen (Settings > Face ID & Passcode) to prevent thieves from seeing notifications or enabling Airplane Mode
+without unlocking. Disable USB accessory connections when locked to prevent unauthorized connections. For device
+recovery, ensure Find My iPhone is enabled with "Send Last Location" and "Find Network" options activated so tracking
+continues even if the device is powered off.
+
+On Android, similar protections can be configured: disable notifications on lock screen (Settings > Notifications > On
+lock screen > Don't show notifications), and enable "Find My Device" with all location services.
+
+**Pay special attention apps security**: many financial apps default to PIN verification instead of biometrics, which
+means a thief who has your phone and knows your PIN could potentially access your financial accounts even if they can't
+bypass Face ID/Touch ID. Use unique PINs for banking apps that differ from your device PIN, or where possible, configure
+these apps to require biometric verification for every login.
+
+### **Minimize digital footprint & social visibility**
+
+It's not just cyber threats – **operational security** matters. **Avoid announcing your travel plans publicly**
+[on social media](https://blackcloak.io/social-media-and-travel-be-careful-of-what-you-share/) and be careful
+with real-time updates. Posts about being away from home can signal to criminals that you (and possibly valuable
+devices or even your house) are vulnerable. Consider sharing trip photos and crypto conference highlights **after**
+you return or only with trusted contacts. Ensure your social media privacy settings are tightened so strangers can't
+see your travel posts.
+
+When registering for events, use privacy-focused tools like iOS's **Hide My Email** or create burner emails through
+providers like Tuta. ProtonMail has had some controversy lately, but could still be a good alternative. If you don't
+need to keep the inbox at all, just create a throwaway mail, there are plenty of options out there. Avoid giving out
+personal details unnecessarily during registration—use minimal, generic info to reduce your digital footprint.
+
+**Discretion** is key: if possible,
+[don't advertise that you work in crypto](https://www.unchained.com/blog/7-tips-traveling-bitcoin#:~:text=,or%20clothing%20with%20bitcoin%20logos)
+or carry cryptocurrency. For example, **remove or cover any crypto stickers on laptops or bags**, and avoid wearing
+company swag or Bitcoin/Ethereum logos while in transit. These can be neon signs attracting thieves or unwanted
+attention ("I have valuable data or wallets!"). If asked about your work or luggage by curious strangers, have a
+**cover story** (e.g. "I work in finance/IT")
+rather than "I manage a crypto fund". High-profile team members might travel under pseudonyms
+or at least not list their company on luggage tags to stay low-profile. Also, be wary that you might be traveling with
+someone with these characteristics, so don't give them away.
+
+### **Plan emergency and incident responses**
+
+Before departure, know what you'll do if something goes wrong. Have a **fallback plan** in case of device loss: who will
+you notify & how (have safe words and beware of deepfakes or impersonations); how will you revoke access to sensitive
+accounts; and how will you continue working (e.g., a backup laptop or a colleague who can step in).
+
+If traveling to
+[countries with strict tech](https://www.perplexity.ai/search/countries-that-list-cryptopgra-bBSItefPSUi7HP2lTNekjA) or
+[encryption laws](https://it.cornell.edu/security-and-policy/travel-internationally-technology#:~:text=Some%20countries%20have%20restrictions%20on,Consider%20requesting%20a%20loaner%20laptop)
+(e.g., China, Russia, UAE), devices like VPNs, encrypted messaging apps (Signal, or Telegram with Secret Chats only),
+hardware wallets (Ledger, Trezor), Yubikeys, or encryption software (VeraCrypt, BitLocker) may be flagged by border
+authorities. Research local laws beforehand. Consider carrying a travel letter from your organization explaining the
+professional need for these tools, or use sanitized loaner devices to avoid issues at border controls.
+
+Share your itinerary and contact information with a trusted peer so they can assist or monitor for any issues.
+
+Finally, schedule critical work (especially high-value transactions) for **before or after** your trip if possible, so
+you’re not forced to do ultra-sensitive actions on the road. Criminals usually play with the “time-sensitive factor,”
+trying to trick you into doing something quick and urgent, by committing something reckless.
+
+## While traveling
+
+### **Network safety – avoid untrusted Wi-Fi & Bluetooth**
+
+Treat **every network as potentially hostile**. Whenever possible, use a **cellular connection or a personal hotspot**
+instead of public Wi-Fi – your mobile data is encrypted and safer than an open café or hotel network. If you must use
+public Wi-Fi (hotel, airport, conference), verify the network name with staff and
+[**disable auto-connect**](https://www.cisa.gov/sites/default/files/publications/Cybersecurity%20While%20Traveling.pdf)
+features so your devices don't join networks without prompting you.
+
+**Turn off Wi-Fi and Bluetooth** on your phone and laptop when you're not using them; this reduces the risk of
+unsolicited connections or Bluetooth-based attacks. Also, disable any device-to-device sharing like **AirDrop** or
+**Nearby Share**
+[to prevent strangers from sending you files](https://www.cypherock.com/blogs/post-safe-vacation-tips-while-traveling-with-crypto#:~:text=Switch%20off%20any%20shared%20networks).
+
+**Use a trustworthy VPN** for an extra layer of encryption for your internet traffic, although in most cases by using an
+updated device, safe hardcoded DNS records, and ensuring SSL while browsing (enforce HTTPS-only-modes or adding
+“http://*” to your uBlock list, might be enough. A reputable, non-logging VPN (or your company’s VPN) helps protect
+against snooping on public networks, especially if you’re handling highly sensitive work and using several communication
+channels.
+
+Using a personal portable router combined with a trusted VPN adds a strong layer of security when connecting to public
+Wi-Fi networks. This setup creates a private, encrypted tunnel between your devices and the internet, minimizing
+exposure to malicious actors on shared networks. Whenever possible, prefer mobile data over Wi-Fi, as cellular networks
+provide better encryption and isolation by default. If you must use Wi-Fi, disable automatic connections and ensure you
+connect only to verified, trusted networks to reduce risk.
+
+### **Device handling – keep them close and protected**
+
+Never leave your devices (laptops, phones, hardware wallets) **unattended or unsecured** in public. Keep them on your
+person or within sight whenever possible. In a conference or cafe, use a cable lock for your laptop if you must step
+away briefly, take it with you or get someone you trust to watch it over for you.
+
+In hotels/Airbnbs, **use the room safe** for small devices when you're out. These safes can easily be opened by an experienced
+thief or rogue/malicious staff. Consider a portable travel safe/bag you can lock to a fixed object. A
+[**portable door lock**](https://www.travelandleisure.com/sabre-portable-door-lock-review-7643179#:~:text=schedule%20and%20explore%20fascinating%20destinations,star%20ratings%20at%20Amazon)
+or door jammer for your room can add an extra barrier against intruders (useful in rentals without chain locks). This
+simple gadget prevents anyone (even with a key) from opening your door while you're inside, giving you peace of mind at
+night. When out and about, be mindful of pickpockets – use bags that zip and consider a subtle anti-theft backpack for
+expensive gadgets or important assets.
+
+For hardware wallets or Yubikeys, a good practice is to **separate them** from the device they authenticate: e.g. don't
+carry your Yubikey on the same keychain as your laptop bag key; keep it hidden on you. And, of course, **keep devices
+powered off** or locked when not in use –
+[enable short auto-lock timeouts](https://www.cisa.gov/sites/default/files/publications/Cybersecurity%20While%20Traveling.pdf#:~:text=%E2%80%A2%20%20%20%20,Some%20devices%20will)
+on your phone/laptop so they aren't unlocked if
+snatched[.](https://www.cisa.gov/sites/default/files/publications/Cybersecurity%20While%20Traveling.pdf#:~:text=%E2%80%A2%20%20%20%20,Some%20devices%20will)
+
+### **Beware of public USB charging**
+
+Avoid plug-and-play charging stations at airports or malls. The risk of
+["**juice jacking**"](https://www.cypherock.com/blogs/post-safe-vacation-tips-while-traveling-with-crypto?srsltid=AfmBOopuzAsUtNwqCqfUBteTEyH4MOTvIaRhoXoIUyNHH8Yv5XzILrSr#:~:text=Stay%20away%20from%20Public%20charger,stations),
+although small,
+is that a malicious charging kiosk or cable can inject malware or siphon data when you connect via USB. Depending on
+your profile risk, you might encounter technologies that mimic different kind of cables and accessories with the same
+purpose. These exist out of the box, and have been widely used by red-teamers and pentesters (re OMG cable).
+
+Stick to using your own charger plugged into a power outlet, or use a **USB data blocker** (a little adapter that
+only passes power, not data). Similarly, do not plug unknown USB drives into your laptop – if someone hands you
+a free USB stick at an event, assume it could be a trap.
+[**USBGuard**](https://github.com/USBGuard/usbguard#:~:text=USBGuard%20is%20a%20software%20framework,may%20interact%20with%20the%20system)
+software (for Linux) or equivalent can be used to restrict USB device access on your computer, allowing only
+whitelisted devices. This tool can prevent an unknown USB from automatically tampering with your system by requiring
+authorization for new devices. At a minimum, disable any "USB autorun" features and consider locking down ports if your
+OS allows.
+
+### **Screen privacy and social engineering**
+
+Practice situational awareness when working in public spaces.
+[**Shoulder surfing**](https://www.trio.so/blog/shoulder-surfing-in-computer-security)
+is a real threat – someone nearby could be
+watching you enter passwords or PIN codes. Use a **privacy screen filter** on your laptop or phone to narrow the viewing
+angle. This makes it much harder for anyone not directly in front of your screen to read it. Sit with your back to a
+wall when possible, and shield the keypad with your body or hand when typing sensitive info.
+
+In crowded conferences or airports, be cautious if someone you don't know strikes up conversation — might be trying to
+distract you or talk about crypto; scammers might engage you to glean info or even attempt to get you to unlock your
+device. **Don't log in to critical accounts in front of others** – you never know who's looking.
+
+Also be mindful of **phishing attempts**: traveling users are prime targets for fake "urgent" emails or messages.
+Double-check any unusual prompts before entering credentials, especially if you're on
+[untrusted Wi-Fi](https://www.cisa.gov/sites/default/files/publications/Cybersecurity%20While%20Traveling.pdf#:~:text=banking%2C%20or%20sensitive%20work%2C%20using,using%20a%20public%20wireless%20network)
+(use your VPN and look for HTTPS).
+
+### **Maintain OpSec in public**
+
+While traveling, **blend in and stay discreet**. Refrain from discussing sensitive matters in public areas where
+eavesdropping is possible, or directly sharing things like where you are staying to people you don't know. Even hotel
+lobbies or rideshares might not be secure for private discussions.
+
+When meeting people, don't give your phone to others to type down their socials, and remember to disable default options
+like Telegram's sharing phone number when adding a contact.
+
+Remember that **hidden cameras or microphones** could exist in unfamiliar environments. It's rare but not unheard of,
+especially in
+[Airbnbs or rented spaces](https://www.washingtonpost.com/travel/2024/05/22/hidden-cameras-airnbnb-rental-properties/#:~:text=On%20the%20kitchen%20table%2C%20he,activate%20the%20camera%20tucked%20inside)
+– malicious hosts have hidden cameras in items like smoke detectors, clock radios, or USB chargers
+[.](https://www.washingtonpost.com/travel/2024/05/22/hidden-cameras-airnbnb-rental-properties/#:~:text=On%20the%20kitchen%20table%2C%20he,activate%20the%20camera%20tucked%20inside)
+Give your accommodations a scan: look for odd or
+[extra devices plugged in](https://www.washingtonpost.com/travel/2024/05/22/hidden-cameras-airnbnb-rental-properties/)
+(especially facing beds or desks) and cover or unplug them if suspicious. You can also play ambient noise (or use a
+noise generator app) during confidential conversations to thwart any listening devices.
+
+**Keep a low profile**: as mentioned,
+[don't flaunt crypto wealth or gear.](https://www.unchained.com/blog/7-tips-traveling-bitcoin#:~:text=,or%20clothing%20with%20bitcoin%20logos)
+For example, if attending a blockchain conference, consider using an alias on your name badge that doesn't explicitly
+say your company or title, and don't display that badge outside the venue. When moving around, secure your laptop in a
+nondescript sleeve or bag (instead of one with a well-known conference brand). The goal is to avoid drawing the
+attention of both petty thieves and more organized attackers by limiting the signals that you're a high-value crypto
+target.
+
+Don't rely on security through obscurity. Going "stealth" doesn't make you immune to attacks. The suggestions in
+this section are meant to complement, not replace, the other security measures.
+
+### **Traveling with high-value crypto or duties**
+
+If you *must* make crypto transactions or access sensitive systems while on the road, do so with caution. Use trusted
+hardware and networks: e.g. if you need to send a transaction, use your hardware wallet on your own laptop (never a
+shared computer), on a secured connection.
+
+Be aware of **surveillance at events** – attackers have been known to watch for people handling sensitive info. If you
+need to access a seed or enter a recovery phrase, do it in a private, secure setting (never over public Wi-Fi or in view
+of anyone, including cameras). Consider that
+[**everyone knows you own crypto at a crypto event**](https://www.unchained.com/blog/7-tips-traveling-bitcoin#:~:text=If%20you%27re%20traveling%20to%20an,in%20your%20belongings%20while%20traveling),
+so your threat profile is
+elevated[.](https://www.unchained.com/blog/7-tips-traveling-bitcoin#:~:text=If%20you%27re%20traveling%20to%20an,in%20your%20belongings%20while%20traveling)
+Adjust your security: for instance, **enable a passphrase or a pin on any single-signature wallet** you carry so that
+even if someone obtains your hardware wallet, they can't access funds without that passphrase. For large amounts, rely
+on multi-sigs, verifying payloads before signing – you might carry one key on you and leave another key(s) with trusted
+parties so no single person has all
+signing power while traveling. In short, treat any on-trip crypto operations with more care than you would in the
+office or at home.
+
+### While presenting or doing public appearances
+
+One often overlooked risk is the exposure caused by presenting or hosting technical workshops in public. Without
+properly hardening or isolating your computer before setting up, you may unintentionally expose network services to
+hostile environments or reveal sensitive information on-screen. Always prepare a clean, minimal environment and verify
+no confidential data or open ports are accessible before connecting to unfamiliar networks or projecting your screen.
+
+### **Physical safety and common sense**
+
+Operational security also has a physical aspect. **Trust your instincts** and normal travel safety rules: stick to
+well-lit and populated areas if carrying devices at night, don’t let strangers “shoulder surf” your ATM or credit card
+PIN (check for skimmers, fake interfaces), and keep your travel documents secure since identity theft can be as damaging
+as device theft.
+
+Use hotel lockers at conferences if provided (for example, some events offer secure charging lockers – use them rather
+than leaving devices out only).
+
+Beware of the classic “evil maid” scenario in hotels (where someone might tamper with your laptop in your room): using
+tamper-evident tape or seals on your laptop case can help detect this, though it’s mostly a concern for high-risk
+targets. If you have tamper-evident stickers or tamper-evident bags, you can seal your device in them overnight – any
+attempt to open or remove the device will leave a visible trace. While not foolproof against a determined adversary, it
+raises the bar and can deter casual snooping.
+
+Petty thieves may look beyond obvious valuables. Simply locking items in a dorm safe or hiding them at home might deter
+casual theft, but savvy criminals often search inside books, behind electrical outlets, or within patterns on walls or
+furniture to find hidden stashes. Consider unconventional hiding spots and avoid predictable storage methods. Layer your
+physical security measures with tamper-evident seals or discreet decoy containers to raise the effort required for
+unauthorized access.
+
+Above all, maintain an **alert posture**: be aware of who’s around when you’re working, and if something feels off (like
+someone persistently hovering or a device acting strangely), don’t ignore it. You can always relocate, power down your
+device, or otherwise cut off exposure at the first sign of trouble.
+
+## Returning home
+
+### **Secure your accounts and passwords**
+
+Once you're back, if you suspect that any account credentials you used while abroad *might* have been exposed
+(especially if you had to log in over a hotel or conference Wi-Fi), address the issue. Change the passwords for any
+accounts you accessed unsafely during the trip – but if you don't feel is necessary, sometimes you pose a greater risk
+at doing so.
+
+Do this from a *trusted* device/network (ideally wait till you're on your home or office network, not the airport
+Wi-Fi). Use this opportunity to upgrade weak passwords and ensure 2FA is still working on those accounts. Check your
+email filters and crypto account settings for any unauthorized changes (attackers sometimes add forwarding rules or new
+withdrawal addresses if they did get access).
+
+Essentially, **rotate secrets** that may have been used under less-secure conditions.
+
+### **Inspect and clean your devices**
+
+After traveling, give your devices a thorough once-over. Run a reputable anti-malware scan on laptops and phones. Look
+for any unusual apps, processes, or device behavior (for example, unusual battery drain could indicate malware).
+
+If you were in a high-risk environment or your device was out of your control at any point, consider wiping the device
+and restoring it from your pre-trip backup (or factory-resetting a phone)
+[to ensure it's clean](https://architectsecurity.org/2017/10/mobile-device-security-for-international-travelers-part-3-how-to-clean-up-your-mobile-devices-after-international-travel/#:~:text=Assume%2C%20whether%20correct%20or%20not%2C,and%20must%20be%20rebuilt%20anew)[.](https://architectsecurity.org/2017/10/mobile-device-security-for-international-travelers-part-3-how-to-clean-up-your-mobile-devices-after-international-travel/#:~:text=The%20goal%20after%20travel%20is,to%20a%20%E2%80%9Cknown%20good%E2%80%9D%20state)
+This is especially recommended for "burner" devices used on the trip – you can safely restore your data onto your main
+device and decommission the travel device.
+
+[... truncated ...]
+
+---
+
+### PAGE: /wallet-security/encumbered-wallets
+**Title:** TEE-based Encumbered Wallets
+**Referenced by controls:** ms-2.1.4
+
+# TEE-based Encumbered Wallets
+
+
+
+
+## User Profile
+
+Advanced users, developers, and organizations wanting to implement fine-grained security policies, that don't want to
+(EVM, Solana, Sui) or can't (Bitcoin, Litecoin, Dogecoin, XRP) make fully customizable logic on each chain individually.
+Additionally, encumbered wallets can use encrypted storage thus providing a level of transaction privacy.
+
+## Primary Goal
+
+To implement optionally private smart contract-like logic and programmable policies for wallet operations across any
+blockchain by encumbering private keys with restrictions. This enables features like conditional signing, multi-party
+authorization, time-locked transactions, and compliance policies that work universally, regardless of the underlying
+chain's capabilities, by instead relying on TEEs.
+
+## Core Concept: Key Encumbrance
+
+Key encumbrance refers to placing cryptographic or policy-based restrictions on a private key’s signing power. Instead
+of a raw key being free to sign any message, its use is “handcuffed” by rules or proofs, and access to it is limited to
+a preset interface. Examples include:
+
+* A key can only sign if a specific policy is met (e.g., only transfers to whitelisted addresses).
+* A key must co-sign with another party’s key (multi-sig or MPC).
+* A key’s signing rights are tied to a verifiable execution environment (e.g., inside a TEE or governed by smart
+  contract logic).
+
+Essentially, key encumbrance adds programmable controls to private keys, enabling fine-grained access, delegation, and compliance.
+
+## Core Concept: Trusted Execution Environments (TEEs)
+
+A Trusted Execution Environment (TEE) is a secure area of a processor that provides hardware-level protection for code
+and data. TEEs create an isolated environment where sensitive operations can run protected from the main operating
+system, other applications, and even privileged system software.
+
+**Key TEE Properties:**
+
+* **Hardware-based Isolation**: Code and data within the TEE are protected by CPU-level security features, not just
+  software isolation.
+* **Attestation**: TEEs can cryptographically prove their identity and the integrity of the code running inside them.
+* **Sealed Storage**: Data can be encrypted and tied to the specific TEE instance, ensuring it cannot be accessed
+  outside the secure environment.
+* **Memory Protection**: TEE memory is encrypted and isolated from the host system, preventing external access to
+  sensitive data.
+
+**Common TEE Technologies:**
+
+* **Intel SGX (Software Guard Extensions)**: Creates secure enclaves within applications that protect against privileged
+  malware and physical attacks.
+* **ARM TrustZone**: Divides the processor into "secure" and "non-secure" worlds, with hardware-enforced separation.
+* **AMD Memory Guard**: Provides memory encryption and isolation features similar to Intel SGX.
+* **Confidential Computing Platforms**: Cloud-based TEE services like Azure Confidential Computing or AWS Nitro Enclaves.
+
+**In Encumbered Wallets:**
+
+TEEs enable private keys to be generated, stored, and used within a protected environment where:
+
+* Keys never exist in plaintext outside the TEE
+* Policy logic runs confidentially within the secure enclave
+* External observers cannot see the encumbrance rules or key operations
+* Attestation proves the wallet is running authentic, unmodified code
+
+This hardware-level protection makes TEE-based encumbered wallets significantly more secure than software-only
+solutions, as even root or physical access to the host system cannot compromise the keys or policies within the TEE.
+
+**Please note that lately there has been a lot of controversy around TEEs, and many researchers are proving that it is not always the case that they add a layer of security. For more information on this, you can check out [TEE.fail](https://TEE.fail), which addresses vulnerabilities in Intel's and AMD's implementation.**
+
+## Key Benefits & Features
+
+**Cross-Chain Compatibility:**
+
+* **Universal Policy Logic**: Implement sophisticated access controls and transaction policies on any blockchain,
+  including Bitcoin, Litecoin, Dogecoin, and other non-smart contract chains.
+* **Chain-Agnostic Security**: Deploy consistent security policies across multiple blockchains without depending on each
+  chain's native capabilities.
+
+**Advanced Access Control:**
+
+* **Fine-Grained Permissions**: Delegate specific rights (voting, trading, asset transfer) to different parties without
+  revealing the full wallet structure.
+* **Time-Bounded Policies**: Implement temporary access controls that automatically expire after specified periods.
+* **Hierarchical Delegation**: Create multi-level permission structures where sub-policies can grant further access down
+  the chain.
+* **Asset-Time Segmentation**: Ensure that specific assets are controlled by exactly one policy at any given time,
+  preventing conflicts.
+
+**Privacy & Selective Disclosure:**
+
+* **Confidential Operations**: Policy logic and key operations remain encrypted and hidden from external observers.
+* **Compartmentalized Access**: Each delegatee only sees their authorized subset of operations, maintaining privacy of
+  the overall wallet structure.
+* **Selective Transparency**: Use view keys to prove compliance or ownership to auditors without revealing spending
+  control or full delegation hierarchy.
+
+**Compliance & Auditability:**
+
+* **Regulatory Compliance**: Support AML/KYC requirements through selective disclosure mechanisms without compromising
+  user privacy.
+* **Institutional Auditing**: Enable institutions to prove 1:1 collateralization or policy adherence to regulators using
+  view keys.
+* **Non-Transferability Proofs**: Demonstrate that certain assets (like compliance-bound RWAs or soulbound tokens)
+  remain under original owner control.
+
+**Operational Flexibility:**
+
+* **Programmable Recovery**: Implement sophisticated recovery mechanisms that work across any blockchain without relying
+  on smart contract support.
+* **Dynamic Policy Updates**: Modify access controls and delegation structures without changing the underlying
+  blockchain infrastructure.
+* **Multi-Asset Management**: Apply consistent policies across different cryptocurrencies and blockchain networks from a
+  single encumbered wallet system.
+
+## Security Considerations & Best Practices
+
+* Implement threshold or multi-party computation-based key custody rather than placing sole trust in a single TEE
+  enclave. Use multi-party threshold signatures or distributed key generation so that a single compromised node cannot
+  break the entire system, providing resilience against both hardware attacks and operational failures.
+* Incorporate economic incentive mechanisms such as staking requirements for TEE operators to align security incentives
+  through cryptoeconomic design. Require operators to post collateral that can be slashed for malicious behavior,
+  attestation failures, or policy violations, creating financial disincentives for compromise attempts and encouraging
+  proactive security maintenance of TEE infrastructure.
+* Carefully evaluate TEE technology selection based on application memory requirements and security priorities. For
+  encumbered wallet applications with modest memory needs (under 256MB), prefer Intel SGX v1 (Client SGX) which provides
+  integrity protection against hardware attacks, whereas applications requiring larger secure memory may need to accept
+  the trade-offs of newer implementations like Scalable SGX or SEV-SNP that offer greater memory capacity but lack
+  integrity protection against physical attacks.
+* Establish continuous re-attestation processes that periodically re-verify enclave conformance on a regular schedule
+  such as hourly or per-block intervals. This helps detect drift, tampering, or compromise attempts over time and
+  ensures that the enclave maintains its security properties throughout its operational lifetime.
+* Implement dual-attestation architectures for cloud-deployed nodes by requiring both Intel DCAP quotes and cloud
+  provider attestation services (such as Azure MAA or AWS Nitro Attestation). This approach provides defense-in-depth by
+  anchoring trust through multiple independent attestation roots with different threat models and security assumptions.
+* Maintain transparent attestation policy publication by documenting and publicly sharing allowed CPU models, TCB
+  versions, QE/PCS builds, and upgrade paths. This enables operators and auditors to verify compliance independently
+  while providing clear guidance for secure deployment configurations and helping detect potentially compromised or
+  outdated systems.
+* Collaborate with hardware vendors and ecosystem partners to push for enhanced TEE security features including replay
+  protection, alias detection, and memory mapping integrity. Engage in industry efforts to improve the fundamental
+  security properties of TEE implementations and advocate for standardized security enhancements across different TEE
+  platforms.
+
+## Relevant Papers
+
+* Austgen, J., Fábrega, A., Kelkar, M., Vilardell, D., Allen, S., Babel, K., Yu, J., & Juels, A. (2024, December 3).
+  Liquefaction: Privately liquefying blockchain assets. [arXiv.org](https://arxiv.org/abs/2412.02634)
+* Dai, W., Deng, J., Wang, Q., Cui, C., Zou, D., & Jin, H. (2018). SBLWT: a secure blockchain lightweight wallet based
+  on TrustZone. IEEE Access, 6, 40638–40648. [https://doi.org/10.1109/access.2018.2856864](https://doi.org/10.1109/access.2018.2856864)
+* Yu, J. (n.d.). PASS: A Provenanced Access Subaccount System for Blockchain Wallets [Stanford University](https://cs191.stanford.edu/projects/Yu,%20Jay_Systems%20191W.pdf)
+* Aublin, P.-L., Mahhouk, M., & Kapitza, R. (n.d.). Towards TEEs with Large Secure Memory and Integrity Protection
+  Against HW Attacks [IIJ Innovation Institute, TU Braunschweig](https://www.ibr.cs.tu-bs.de/bib/xml/aublin2022scalableSGX.html)
+
+---
+
+---
+
+### PAGE: /wallet-security/seed-phrase-management
+**Title:** Seed Phrase Management
+**Referenced by controls:** ms-3.1.3
+
+# Seed Phrase Management
+
+
+
+
+## Private Key & Seed Phrase Management
+
+The **seed phrase** (or mnemonic phrase) is the master key to a non-custodial wallet, granting complete control over all
+its derived **private keys** and assets. The management of this phrase is the single most important aspect of
+self-custody security.
+
+> ⚠️ If you suspect for even a moment that your private key or seed phrase has been lost, viewed by another person, or
+> exposed digitally (e.g., shown on-screen, copied to a clipboard on a connected device), you must **consider it
+> compromised.** Immediately create a new, secure wallet and transfer all assets to it.
+
+### Secure Storage Practices
+
+The goal is to protect the seed phrase from both physical threats (theft, fire, water damage) and digital threats
+(hacking, malware). The foundational principle is to keep your seed phrase offline at all times.
+
+As soon as a new wallet is created, back it up using one of the following offline methods. Wallet providers do not have
+access to your seed phrase and cannot help you recover it.
+
+- **Physical Written Copies**: Writing the phrase on paper or a notebook is a common starting point. To mitigate risks
+
+of loss or damage from fire or water, store multiple copies in secure, geographically separate locations (e.g., a
+personal safe, a trusted family member's home, a bank deposit box).
+
+- **Durable Metal Storage**: For superior protection against physical damage, etch or stamp your seed phrase onto a
+
+metal plate (e.g., steel, titanium). Commercial products are available for this purpose. These should also be stored in
+secure, separate locations.
+
+### Enhanced security option
+
+For extra security, split seed into 3 pieces:
+
+- **Piece 1**: Words 1-16
+- **Piece 2**: Words 9-24
+- **Piece 3**: Words 1-8 and 17-24
+
+#### Storage locations:
+
+- Different secure locations (safe deposit box, home safe, trusted family)
+- Each piece stored with clear labeling system
+
+### Tamper evident bags:
+
+Storing sensitive devices or documents in a tamper evident bag offers high confidentiality and integrity. You can sign &
+date these bags, and also take a picture of its serial number.
+
+![Tamper evident bag example](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/tamper-evident-bag-example.png)
+
+**Use case:**
+You can put your Piece 1: Words 1-16 of your seed, inside a safe.
+Piece 2: Words 9-24 of your seed, somewhere safe (different location) in a tamper evident bag (could be at your parents place).
+Piece 3: Words 1-8 and 17-24 of your seed, somewhere safe (different location) in a tamper evident bag (could be
+somewhere else, at a family member or trusted friend).
+You can put your backup ledger while traveling inside this, in the safe of your hotel room to detect tampering.
+The main idea is to never have at the same place your 24 words, but still be able to recover your seed within 2 pieces
+of paper out of 3.
+You can find a useful [link here to our EthCC
+swag](https://drive.google.com/file/d/1L1CMiKRL3TXQBE5bWYNv6dfF94HSdZ8C/view?usp=sharing) that shows you how to easily
+split your seed in 3 as recommended.
+
+### Prohibited Practices
+
+Under no circumstances should you ever store your seed phrase in any of the following ways:
+
+- Taking a digital photograph of it.
+- Uploading it to cloud storage (iCloud, Google Drive, Dropbox).
+- Sending it via text message or any messaging app.
+- Sending it in an email, even to yourself.
+- Storing it in a plain text file on a computer or phone.
+- Sharing it with anyone. Wallet providers will **never** ask for your seed phrase.
+- Password managers or digital storage
+- Traveling with seed phrases
+- Storing all pieces in same location
+- Using a device obtained from an untrusted source, such as a conference, hackathon, or third-party online marketplace,
+as it may be tampered with.
+
+## Organizational Seed Phrase Security
+
+For organizations managing multisig wallets, seed phrase security requires additional properties beyond individual storage:
+
+### Security Properties
+
+- **Disaster Resistant**: The seed phrase is either duplicated or split, with components/copies secured across multiple
+geographic locations. This way, if disaster strikes, keys can be recovered from other locations.
+- **Theft Resistant**: An attacker gaining access to one piece of physical storage media for the seed phrase would not
+allow them to rebuild the wallet on its own
+- **Operator Loss Resistant**: Reconstituting the seed phrase should be possible with the absence of one or more
+operators
+
+### Seed Phrase Encryption
+
+> ⚠️ **Warning: Encryption adds recovery risk.** Only implement custom encryption schemes if you are sophisticated and
+> have robust documentation practices. If you forget your encryption method or passphrase, your funds are **permanently
+> inaccessible**—there is no recovery option. Many users and organizations face greater risk of locking themselves out
+> with custom encryption than from an attacker discovering a securely stored backup. Evaluate whether strong physical
+> security alone may be sufficient for your threat model.
+
+The reason to encrypt seed phrases is that if they are discovered unencrypted, the wallet is permanently compromised.
+However, if you encrypt your seed phrase, you are much more likely to forget the encryption when trying to restore the
+wallet. If you have stored the seed securely, it is unlikely to be discovered in the first place.
+
+Never store seed phrases in plain text or on an internet connected device. For additional protection, seed phrases can
+optionally be encrypted through some method. For example:
+
+- Seed phrases can be mixed in a randomly generated, recorded order
+- Have a 25th secret word
+- Require a passphrase to be imported into a wallet
+
+Regardless of the method, the related secret value should be stored in a password manager. (**Do not store your seed
+phrase in a password manager.**)
+
+### Advanced Backup Options
+
+**Key Splitting:**
+
+Split the key into multiple shards and securely distribute them:
+
+- Use [Shamir's Secret Sharing algorithm](https://en.wikipedia.org/wiki/Shamir%27s_secret_sharing) for N of M key shards
+- Consider using this [Shamir Secret Sharing implementation](https://github.com/privy-io/shamir-secret-sharing)
+- Seed phrases can be sharded using Shamir's Secret Sharing algorithm, with each shard recommended to be shared with a
+trusted guardian (3rd party custodian service, family members, password manager, personal physical media, etc.)
+
+**Multi-Share Backups:**
+
+Use device-supported multi-share backups where available:
+
+- [Trezor Multi-Share Backup](https://trezor.io/learn/a/multi-share-backup-on-trezor)
+
+**Secure Distribution:**
+
+Give shards to trusted family members, put in bank safe deposit boxes, and keep hidden around your house.
+
+> **Note**: If you're concerned about targeted attacks like kidnapping or home invasions, consider avoiding storing
+any shards in your primary residence.
+
+### Multisig Social Recovery
+
+**Optional Self-Recovery**:
+
+- Seed phrase backups are not strictly necessary with a healthy quorum
+- Multi-sig signing wallets should not be used for any other purpose and could be re-provisioned by existing quorum
+admins
+- Maintain a healthy enough signing pool that loss of access to a few accounts at once could be recovered from
+- Personal backup methods for admins are required to maintain access to on-chain assets in the event of loss of access
+to hardware wallets
+
+**Quorum Social Recovery**: If access to wallet is lost, the quorum can vote to edit members to replace the
+inaccessible wallet.
+
+### Ongoing Security Hygiene
+
+**1. Periodic Security Audits:**
+
+On a recurring basis (e.g., every 6 months), conduct a security review by asking:
+
+- Do I know the physical location of all my seed phrase backups?
+- Are my storage methods still secure and uncompromised?
+- If my primary device were destroyed, do I have a clear plan to recover my assets?
+
+**2. Key Rotation:**
+
+While you can use the same keys for years, it is a best practice to periodically rotate them by moving assets to new
+wallets.
+
+**3. Succession Planning:**
+
+Establish a clear, secure protocol for a trusted next-of-kin to access your assets in case of incapacitation or death.
+This may involve sealed instructions stored with a lawyer or in a safe deposit box.
+
+## Emergency access plan
+
+### Trusted contacts
+
+- Designate 2-3 trusted individuals who can access backup locations
+- Clear instructions for emergency seed access
+- Regular check-ins with trusted contacts
+
+### Recovery scenario example
+
+"Call [trusted person] with code word [predetermined phrase], tell them to get the metal plate from safe location A,
+they give you words 1-16 over the phone. Then call [second person] with code word for location B to get words 9-24. Use
+both pieces to reconstruct seed immediately, then change all security settings."
+
+### Documentation
+
+- Emergency contact information stored separately from seed
+- Code words/phrases for identity verification
+- Access instructions for trusted contacts
+- Regular testing of emergency procedures
+- Update procedures when contacts or locations change
+
+Remember: Your seed phrase security is the foundation of multisig security. Take time to implement proper storage
+procedures appropriate for your risk level.
+
+---
+
+### PAGE: /wallet-security/signing-and-verification/secure-multisig-signing-process
+**Title:** Secure Multisig Signing Process | SEAL
+**Referenced by controls:** ms-3.1.4, ms-4.1.1
+
+# Verifying Multisig Transactions
+
+
+
+
+The security of a multisig wallet relies on each signer independently verifying what they are signing. A compromised web
+interface could present a legitimate-looking transaction while tricking a hardware wallet into signing a malicious one.
+
+The verification process is divided into two distinct phases: signing the off-chain message and executing the on-chain transaction.
+
+## Key Definitions (EVM)
+
+- **Domain Hash**: EIP-712 domain separator, unique to each Safe. Ensures signatures cannot be replayed on other
+  networks or Safes.
+- **Message Hash**: Raw hash of transaction parameters. This appears on your hardware wallet.
+- **SafeTxHash**: Combined hash of domain + message hash. Used for nested Safe approvals.
+
+## Phase 1: Signing the Off-Chain Message
+
+When you are the first signer or are adding your signature to a transaction that has not yet met its threshold, you are
+not sending an on-chain transaction. Instead, you are signing a structured, off-chain message that conforms to the
+**EIP-712** standard.
+
+**Goal**: To confirm that the cryptographic hash displayed on your hardware wallet exactly matches the hash of the
+transaction you intend to approve.
+
+### Process
+
+1. **Initiate Signing**: Start the signing process in the multisig wallet's web interface.
+2. **Verify on Hardware Wallet**: Your hardware wallet will display an EIP-712 hash for you to sign.
+3. **Compute Hash**: Use an independent, local tool to re-calculate the expected hash from the transaction's parameters
+(`nonce`, `to`, `value`, `data`, etc.). For a list of recommended options, see the [Transaction Verification
+Tools](/wallet-security/tools-&-resources) section.
+4. **Compare Hashes**: Compare the `SafeTxHash` generated by the local tool with the hash displayed on your hardware
+wallet's screen. **They must match perfectly.**
+   - All signers must verify transaction data on at least two independent devices
+   - All signers must verify transaction data through at least two separate communication channels
+5. **Simulate Transaction**: At least 2 signers must use transaction simulation tools to verify transaction effects.
+Simulation testing output should be shared with and reviewed by all signers before signing.
+   - Warning: Simulations can be spoofed - always apply critical thinking and good judgement during
+     transaction reviews since a simulation can display one thing and then do something else entirely
+     when actually executed on chain
+6. **Sign**: If the hashes match and simulation results are verified, you can confidently sign the message on your
+hardware wallet. This confirms you are approving the correct transaction, even if the web UI has been compromised.
+
+## Phase 2: Executing the On-Chain Transaction
+
+Once a transaction has the required M-of-N signatures, it can be executed. This involves submitting a final on-chain
+transaction that calls the `execTransaction` function on the multisig contract, passing in all the previously signed
+data.
+
+**Goal**: To confirm that the on-chain transaction being sent correctly encapsulates the multisig transaction you and
+other signers approved.
+
+### Process
+
+1. **Initiate Execution**: In the multisig interface, start the execution of the fully signed transaction.
+2. **Verify Calldata**: Your hardware wallet will prompt you to sign a new on-chain transaction. It will display the raw
+transaction data (calldata), which should show a call to the `execTransaction` function.
+3. **Decode and Compare**: Use a calldata decoder
+(e.g.,[calldata.swiss-knife.xyz](https://calldata.swiss-knife.xyz/decoder)) to parse the data shown on your hardware
+wallet.
+4. **Confirm Parameters**: Carefully check the decoded parameters within the `execTransaction` call, especially the
+internal destination address (`to`), `value`, and `data` payload. Ensure they match the original, intended transaction.
+5. **Sign and Broadcast**: If the calldata is correct, sign the transaction on your hardware wallet to broadcast it to
+the network.
+
+## Operational Best Practices
+
+> ⚠️ **Beware of `DELEGATECALL`**: In a smart contract multisig transaction, an `operation: 1 (DELEGATECALL)` is
+> dangerous if the target contract is not explicitly known and trusted. This opcode gives another contract full control
+> over your wallet's context and storage.
+
+- **Transaction Simulation**: Before signing, use a simulator like **[Tenderly](https://tenderly.co/)** or
+  **[Alchemy](https://www.alchemy.com/docs/reference/simulation)** to preview the transaction's outcome. This helps
+  confirm that it will not revert and will result in the expected state changes.
+- **Hardware Wallet Standard**: All multisig signers should use hardware wallets to protect their keys from online
+  threats. Data shown in a browser extension wallet should be treated with the same skepticism as data in the web UI.
+- **Secure signing environment**: Use a dedicated, air-gapped, or hardened device. Avoid primary work laptops.
+- **Alternative Frontends**: To further reduce reliance on a single public UI, consider using an alternative or
+  self-hosted multisig interface.
+- **Separate browser/profile for signing**: Use a dedicated browser or browser profile when interacting with signing UIs
+  to reduce cross-extension/session risk.
+- **Require a "how to check" guide**: Every transaction should include explicit verification instructions for signers.
+- **Verify addresses and amounts via independent sources**: Do not rely solely on messages from co-signers.
+- **Check transactions in the queue**: If unclear what a transaction does and why, do not sign; ask for explanation.
+- **Communicate status**: After review, state whether a transaction is ready to execute and confirm after signing
+  ("checked, signed, X more required").
+- **Last signer executes**: If executable immediately, the last signer should execute; otherwise coordinate clearly.
+- **Re-verify before execution**: Treat execution as a fresh signing event and re-check parameters.
+- **Use checksummed addresses**: Always use checksummed format to prevent copy/paste or case errors.
+
+### Simulation notes with timelocks
+
+When using a timelock, simulations may show the staging event rather than actual execution. Inspect the staged payload
+and verify cancellation/execution roles and parameters before proceeding.
+
+---
+
+---
+
+### PAGE: /opsec/appendices/case-studies
+**Title:** OpSec Case Studies
+**Referenced by controls:** ms-3.1.5
+
+# Case Studies & Exercises
+
+
+
+
+This section provides real-world case studies and tabletop exercises that organizations can use to learn from past
+incidents and test their security readiness. These examples illustrate common security challenges and effective response
+strategies.
+
+## Web3 Security Incidents
+
+### Case Study 1: Private Key Compromise
+
+#### Incident Overview
+
+A mid-sized DeFi protocol experienced a security breach when an attacker gained access to a private key used for
+deploying smart contracts. The attacker used the key to deploy a malicious contract update that drained approximately $3
+million from the protocol.
+
+#### Root Causes
+
+1. The private key was stored in a development environment with inadequate access controls
+2. The same key was used for both testing and production deployments
+3. There was no multi-signature requirement for contract deployments
+4. Monitoring systems failed to detect the unauthorized deployment
+
+#### Response Actions
+
+1. The team immediately alerted users via social media and official channels
+2. All remaining funds were moved to secure wallets
+3. A forensic investigation was initiated to determine the attack vector
+4. Law enforcement and blockchain analytics firms were engaged
+5. The team implemented a compensation plan for affected users
+
+#### Lessons Learned
+
+1. Implement multi-signature requirements for all critical operations
+2. Establish separate keys for different environments with appropriate controls
+3. Improve deployment security with additional verification steps
+4. Enhance monitoring to detect unauthorized deployments
+5. Develop and test incident response procedures specific to key compromise
+
+### Case Study 2: Social Engineering Attack
+
+#### Incident Overview
+
+A community manager for a popular NFT project had their Discord account compromised after clicking a link in a direct
+message that appeared to come from a team member. The attacker used the compromised account to post a fake minting link,
+ resulting in approximately 50 community members connecting their wallets and losing assets.
+
+#### Root Causes
+
+1. Lack of verification procedures for team communications
+2. Insufficient security awareness training for team members
+3. Absence of multi-factor authentication on critical accounts
+4. Inadequate controls for posting official announcements
+
+#### Response Actions
+
+1. The team removed the compromised account's permissions
+2. An official announcement was made warning about the scam
+3. The fake minting site was reported for takedown
+4. Affected community members were identified for potential compensation
+5. Communication procedures were revised to prevent similar incidents
+
+#### Lessons Learned
+
+1. Implement strong authentication for all team accounts
+2. Establish verification protocols for team communications
+3. Create a secure process for publishing official announcements
+4. Conduct regular security awareness training for team members
+5. Develop an incident response plan specific to community channel compromises
+
+## Tabletop Exercises
+
+### Exercise 1: Wallet Security Incident
+
+#### Scenario
+
+Your organization's multi-signature wallet has shown unusual transaction activity. A transaction that was not authorized
+by the team has been initiated, requiring one more signature to execute. The transaction would send a significant
+amount of funds to an unknown address.
+
+#### Exercise Questions
+
+1. What immediate actions would you take?
+2. How would you investigate the source of the unauthorized transaction?
+3. What stakeholders need to be notified, and what information would you provide?
+4. What steps would you take to secure your remaining assets?
+5. How would you communicate with your community or users?
+
+#### Key Discussion Points
+
+- Multi-signature wallet security procedures
+- Transaction verification processes
+- Incident response roles and responsibilities
+- Communication strategies during security incidents
+- Forensic investigation approaches
+
+### Exercise 2: Smart Contract Vulnerability
+
+#### Scenario
+
+A security researcher has privately disclosed a critical vulnerability in one of your deployed smart contracts. The
+vulnerability could potentially allow an attacker to drain funds, but it requires specific conditions that have not yet
+occurred. You have approximately 48 hours before these conditions align.
+
+#### Exercise Questions
+
+1. How would you validate the reported vulnerability?
+2. What immediate mitigation steps could you take?
+3. How would you prioritize and approach developing a fix?
+4. What stakeholders need to be involved in the decision-making process?
+5. How and when would you communicate with users and the broader community?
+
+#### Key Discussion Points
+
+- Vulnerability verification processes
+- Short-term mitigation strategies
+- Smart contract upgrade procedures
+- Decision-making during time-sensitive incidents
+- Responsible disclosure and communication
+
+### Exercise 3: Team Member Device Compromise
+
+#### Scenario
+
+A developer on your team reports that their laptop has been stolen while traveling. The laptop was used for development
+work and had access to various internal systems. The developer had logged into several services recently and is unsure
+if all sessions were properly closed.
+
+#### Exercise Questions
+
+1. What immediate actions would you take to contain potential damage?
+2. What systems and access credentials might be at risk?
+3. How would you determine if any unauthorized access has occurred?
+4. What steps would you take to restore secure operations?
+5. How would you improve security to prevent similar incidents?
+
+#### Key Discussion Points
+
+- Device security policies and procedures
+- Access revocation processes
+- Security monitoring and detection capabilities
+- Recovery procedures for compromised credentials
+- Travel security policies
+
+## Security Exercises for Teams
+
+### Red Team Exercise: Phishing Simulation
+
+#### Exercise Overview
+
+This exercise simulates a phishing attack targeting team members to test awareness and response.
+
+#### Setup Requirements
+
+1. Prepare simulated phishing emails targeting different team roles
+2. Create a safe landing page that records interactions
+3. Establish monitoring to track responses
+4. Prepare educational materials for post-exercise discussion
+
+#### Exercise Process
+
+1. Send simulated phishing emails to selected team members
+2. Monitor interactions with the phishing content
+3. Document actions taken by recipients
+4. Track if and how the incident is reported
+5. Conduct a debrief session to discuss results
+
+#### Evaluation Criteria
+
+- Percentage of team members who detected the phishing attempt
+- Time taken to report suspicious emails
+- Effectiveness of reporting procedures
+- Quality of response from security team
+- Lessons learned and areas for improvement
+
+### Security Control Assessment: Key Management
+
+#### Exercise Overview
+
+This exercise evaluates the effectiveness of cryptocurrency key management procedures.
+
+#### Setup Requirements
+
+1. Create a test environment with non-production keys
+2. Prepare scenarios that test different aspects of key management
+3. Establish evaluation criteria for each scenario
+4. Ensure safety measures to prevent actual asset risk
+
+#### Exercise Process
+
+1. Simulate routine key management operations
+2. Introduce scenarios requiring emergency access to keys
+3. Test key recovery procedures
+4. Evaluate separation of duties enforcement
+5. Assess documentation and procedure clarity
+
+#### Evaluation Criteria
+
+- Adherence to established key management procedures
+- Effectiveness of security controls
+- Time required to safely complete key operations
+- Quality of documentation and procedures
+- Identification of gaps and improvement opportunities
+
+These case studies and exercises provide practical examples and scenarios that organizations can use to learn from past
+incidents and test their security readiness. By regularly conducting such exercises, teams can identify weaknesses in
+their security posture and improve their ability to respond effectively to incidents.
+
+---
+
+---
+
+### PAGE: /multisig-for-protocols/personal-security-opsec
+**Title:** Multisig Personal Security (OpSec) | SEAL
+**Referenced by controls:** ms-3.1.7
+
+# Personal Security (OpSec)
+
+
+
+
+## Account Security
+
+### Basic requirements
+
+- 2FA enabled on all accounts (authenticator apps or hardware keys)
+- Password manager with unique, strong passwords for every account
+- Remove phone numbers from account recovery options where possible
+- Regular security checkups and removal of unused app permissions
+- Backup email for account recovery (separate from primary email)
+
+### For extra security
+
+**YubiKeys**: Use hardware security keys instead of authenticator apps
+
+- Provides stronger protection against phishing and SIM swapping
+- Recommended: 3 keys (primary, backup, secure storage)
+- Models: YubiKey 5C NFC, YubiKey 5C Nano
+
+**Cold backup accounts**: Separate email/phone for sensitive account recovery
+
+- Backup / cold accounts are tied to sensitive accounts (AppleID, Telegram, Signal, WhatsApp, Password Manager etc).
+  Such email addresses must never be shared with anyone and kept private to remain secure and not targeted.
+
+Example: random44@gmail is tied to your AppleID, and you are only logged in (the email) on a separate secure device. If
+your main device (laptop) gets compromised, you will be able to recover your account or revoke sessions, moreover your
+cold account won't be affected / compromised. It prevents people from targeting your accounts by not knowing your email
+linked to it.
+
+- Use different providers from primary accounts (Gmail, Proton)
+- Only access from secure devices
+- Never used for regular communications
+
+## Device Security
+
+### Basic requirements
+
+- Full disk encryption enabled (FileVault/BitLocker)
+- Automatic updates enabled on all devices
+- Screen lock after 5 minutes inactivity on computers, 30 seconds on mobile
+- Strong passcodes (6+ digits or alphanumeric on mobile)
+- Endpoint protection software on computers
+- No admin rights for daily use accounts (create separate admin account)
+
+### For extra security
+
+**Dedicated signing device**: Clean laptop/tablet used only for multisig operations
+
+- Minimal software installation
+- Regular security updates
+- Clean restart before each use
+- Offline storage when not in use
+- Justification: Reduces attack surface for high-value operations
+
+## Network Security
+
+### Dedicated Signing Machines
+
+- Multi-sig operations must be performed on devices dedicated only to these transactions and verification tools
+- All network access should be default blocked, with only the minimum necessary IPs to execute these transaction
+signatures allowed
+- Signing devices must be operated on private, authenticated networks or over trusted VPNs
+
+### Air-Gapped Machine Options
+
+- For highest security, physically remove or disable the network interface
+- Use USB drives (with strict auto-run restrictions) or QR codes to transfer transaction data
+
+### Advanced OS-Level Controls
+
+- Consider employing SELinux or similar tools for advanced security configurations
+- Restrict file system access and inter-process communications
+
+### Network Monitoring Tools
+
+Organizations must implement active network monitoring on signing devices:
+
+- [Little Snitch](https://www.obdev.at/products/littlesnitch/index.html) for active firewall and network monitoring
+- [Lulu](https://objective-see.org/products/lulu.html) as a free, open source alternative to Little Snitch
+- [Glasswire](https://www.glasswire.com/) can be used for Windows machines
+
+### DNS Security
+
+Use [DeFi DNS Whitelist](https://github.com/0xKoda/defi-dns-whitelist/tree/main) as a firewall for dedicated signing machines.
+
+## Communication Security
+
+### Basic requirements
+
+**Signal with verified safety number verification** for multisig communications: You MUST check the codes with the
+person you are interacting to « verify » them.
+How? Click on any chat > Contact name > View Safety Number > Call on another communication channel to verify them >
+Click at the bottom "Mark as Verified".
+If the account connects on a new device these codes will change & you will receive a security notification.
+
+- Screen lock enabled on mobile devices
+- 2FA enabled on backup platforms (Telegram/Discord/Slack)
+- Privacy settings maximized on all platforms
+- Session management - remove old/unknown devices regularly
+
+### Signal configuration
+
+- Registration lock enabled
+- Signal PIN configured
+- Hide phone number (use username only)
+- Safety number verification for all contacts
+- Disappearing messages for sensitive chats
+
+### URL Navigation Safety
+
+Links to URLs containing transaction requests or confirmation data (even those provided by trusted parties) must never
+be clicked - they must be navigated to by using bookmarks or typing them out manually.
+
+### For extra security
+
+**Enhanced verification**: Advanced safety procedures for critical communications
+
+- Code words for identity verification
+- Multiple verification channels for important requests
+- Regular communication channel security audits
+
+## Travel considerations
+
+### What to bring
+
+- Primary hardware wallet only (leave backups secure at home)
+- Essential devices only (laptop + phone)
+- Emergency contact information (offline copy)
+- Own chargers and cables
+
+### What NOT to bring
+
+- Seed phrases (never travel with these)
+- Backup hardware wallets
+- USB drives with sensitive data
+- Non-essential devices
+
+### Basic travel security
+
+- Use device locks at all times
+- Avoid public WiFi (use mobile hotspot or VPN)
+- Don't leave devices unattended in hotel rooms
+- Use hotel safes for device storage when out
+- Have offline backup of emergency contacts
+
+### For extra security
+
+**Enhanced travel procedures**: Additional precautions for high-risk situations
+
+- Disable biometric unlock at airports/borders (use PIN only) - prevents forced unlocking
+- Decline hotel housekeeping services - reduces access to devices
+- Advance notification to multisig team (72 hours for critical operations)
+- Use separate carrier SIM card for travel communications
+- Professional security assessment of travel destinations
+
+## Implementation priority
+
+### Start with basics
+
+Focus on fundamental security practices first
+
+- Password manager + 2FA on all accounts
+- Device encryption and screen locks
+- Signal setup with safety number verification
+- Basic travel security practices
+
+### Add extra security
+
+Implement additional measures based on your risk level and operational needs
+
+- YubiKeys for critical accounts
+- Dedicated signing devices for high-value operations
+- Enhanced travel procedures for international travel
+- Professional security assessments for critical roles
+
+Remember: Perfect security doesn't exist - focus on practical improvements that significantly reduce your risk while
+remaining operationally feasible.
+
+For the full OpSec article, see [Operational Security](/opsec/overview).
+
+---
+
+### PAGE: /multisig-for-protocols/emergency-procedures
+**Title:** Multisig Emergency Procedures | SEAL
+**Referenced by controls:** ms-3.1.7, ms-6.1.2, ms-6.1.4
+
+# Emergency Procedures
+
+
+
+
+When security incidents occur, quick and decisive action is critical. This page covers procedures for key compromise,
+lost access, and communication breaches.
+
+## Key Compromise
+
+### Immediate Actions (Within 30 Minutes)
+
+1. **Stop operations** - Halt all non-emergency transactions
+2. **Notify team** - Alert via all communication channels using emergency notification template
+3. **Assess scope** - Determine which keys may be compromised
+4. **Escalate** - Contact Security team immediately
+5. **Document** - Record timeline and details
+
+### Recovery Process
+
+1. **Isolate** - Quarantine potentially compromised devices
+2. **New hardware setup** - Set up fresh wallet with new seed following [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds)
+3. **Coordinate replacement** - Plan signer replacement transaction with team
+4. **Execute replacement** - Replace compromised signer on multisig, following steps for signer rotation in [Secure
+   Multisig Best Practices](/wallet-security/secure-multisig-best-practices)
+5. **Verify security** - Confirm new setup before resuming operations
+
+## Lost Key Access
+
+### Immediate Steps
+
+1. **Try backup device first** if available
+2. **Contact team immediately** via backup communication channels
+3. **Do not panic** - Lost access doesn't mean compromised keys
+4. **Document the situation** - Record what happened and when
+
+### Identity Verification Process
+
+Since you can't sign with your key, verify identity through alternative methods:
+
+- **Video call** with other signers
+- **Authentication** via verified social media account
+- **Other pre-arranged verification methods**
+
+### Replacement Coordination
+
+1. **Generate new hardware wallet** following standard setup procedures in [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds)
+2. **Verify new address** through identity verification process above
+3. **Coordinate timing** with other signers for replacement transaction
+4. **Execute replacement** once team confirms identity
+5. **Update documentation** with new signer information
+
+## Communication Account Compromise
+
+### If Telegram/Signal/Discord Gets Taken Over
+
+#### Immediate Actions
+
+1. **Assume all recent messages are suspect** - Don't trust recent communication
+2. **Use backup channels** to alert team about compromise
+3. **Change passwords** and enable additional security on compromised account
+
+#### Team Verification Process
+
+**For the compromised person:**
+
+- Use alternative contact methods (email, phone, other platforms)
+- Verify identity through video call or pre-arranged methods
+- Provide proof of the compromise (screenshots, platform confirmation)
+
+**For other team members:**
+
+- Verify all recent requests from compromised account
+- Cancel any pending transactions initiated via compromised communication
+- Require additional verification for any future requests until resolved
+
+#### Recovery Steps
+
+1. **Regain account control** through platform recovery processes
+2. **Enable maximum security** (2FA, security keys, session management)
+3. **Review recent message history** for unauthorized communications
+4. **Alert team** when account is secured and verified clean
+5. **Resume normal operations** only after team confirms account security
+
+## Emergency Notification Template
+
+Use this template for security incidents or key compromises:
+
+```
+Subject: [URGENT] Multisig Security Incident - [Multisig Name]
+
+Immediate details:
+- Multisig address: [ADDRESS]
+- Classification: [Impact Level / Operational Type]
+- Incident type: [Key Compromise / Communication Failure / System Issue]
+- Time of discovery: [TIMESTAMP]
+- Reporting signer: [NAME/HANDLE]
+
+Situation summary: [Brief description of what happened and current status]
+
+Immediate actions taken:
+□ Stopped non-emergency operations
+□ Isolated affected systems
+□ Notified team members
+□ [Other actions]
+
+Next steps required:
+□ Security team assessment
+□ Key rotation process
+□ Emergency transaction execution
+□ [Other actions]
+
+Current multisig status:
+- Available signers: [X/Y]
+- Communication status: [Operational/Compromised]
+- Operational capability: [Full/Limited/Suspended]
+```
+
+## Emergency Communication Protocols
+
+### Multi-Channel Notification
+
+- **Primary channel**: Alert via main communication channel
+- **Backup channels**: Simultaneously notify via backup platforms
+- **Emergency contacts**: Use emergency contact procedures if established
+
+### Identity Verification
+
+- **Code words**: Use pre-established verification phrases
+- **Multiple confirmations**: Verify through multiple channels
+- **Video verification**: Use video calls for critical confirmations
+
+### Information Sharing
+
+- **Need-to-know basis**: Share only essential information
+- **Secure channels only**: Use most secure available communication
+- **Documentation**: Record all emergency communications
+
+## Operational Emergency Procedures
+
+### For Emergency Response Multisigs
+
+#### Rapid Response Protocol
+
+1. **Immediate assessment** - Determine scope and urgency
+2. **Signer activation** - Contact threshold number of signers
+3. **Streamlined verification** - Use minimal verification appropriate for risk level
+4. **Execute response** - Implement emergency measures
+5. **Post-action review** - Document and assess response effectiveness
+
+#### 24/7 Availability
+
+- **Geographic distribution** - Ensure coverage across time zones
+- **Backup signers** - Have additional signers available for activation
+- **Communication redundancy** - Multiple ways to reach each signer
+
+### Emergency Drill Procedures
+
+#### Regular Testing Schedule
+
+- **Quarterly**: Communication system tests
+- **Bi-annually**: Emergency paging system tests
+- **Annually**: Full emergency simulation with all signers
+
+#### Drill Components
+
+1. **Notification test** - Verify all signers receive alerts
+2. **Response time measurement** - Track time to threshold signatures
+3. **Process verification** - Ensure procedures work under pressure
+4. **Documentation review** - Update procedures based on drill results
+
+## Recovery and Post-Incident
+
+### Immediate Recovery
+
+1. **Restore operations** - Resume normal operations once threat is mitigated
+2. **Monitor for issues** - Watch for any residual security concerns
+3. **Update security measures** - Implement additional controls if needed
+
+### Post-Incident Analysis
+
+1. **Root cause analysis** - Determine how incident occurred
+2. **Process improvement** - Update procedures to prevent recurrence
+3. **Team debriefing** - Gather lessons learned from all participants
+4. **Documentation updates** - Revise emergency procedures based on experience
+
+### Communication
+
+1. **Team notification** - Inform team when incident is resolved
+2. **Stakeholder updates** - Notify relevant parties as appropriate
+3. **Documentation** - Complete incident report for future reference
+
+## Emergency Contact Information
+
+### Security Team Contact
+
+- **Email**: [Security team email]
+- **Emergency escalation**: [24/7 emergency contact if available]
+- **Communication**: Use subject line format from emergency notification template
+
+### Internal Escalation
+
+- **Protocol leadership**: [Contact information]
+- **Technical team**: [Emergency technical contact]
+- **Legal/compliance**: [If regulatory notification required]
+
+## Related Documents
+
+- [Incident Reporting](/multisig-for-protocols/incident-reporting) - Formal incident reporting procedures
+- [Communication Setup](/multisig-for-protocols/communication-setup) - Backup communication channels
+- [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds) - Device replacement procedures
+- [Seed Phrase Management](/wallet-security/seed-phrase-management) - Key recovery procedures
+- [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec) - Account security measures
+
+---
+
+### PAGE: /multisig-for-protocols/backup-signing-and-infrastructure
+**Title:** Backup Signing & Infrastructure | SEAL
+**Referenced by controls:** ms-4.1.2, ms-4.1.4, ms-5.1.1, ms-6.1.1
+
+TagList,
+  AttributionList,
+  TagProvider,
+  TagFilter,
+  ContributeFooter,
+} from "../../../components";
+
+
+
+
+# Backup Signing & Infrastructure
+
+
+
+
+If the default interfaces for either Safe or Squads are down or suspected of being compromised, these alternatives
+enable continued critical signing operations. As a signer, you should familiarize yourself with these tools and practice
+signing transactions with your team.
+
+## UI Alternatives
+
+### EVM Networks
+
+**Eternal Safe - Decentralized fork of Safe\{Wallet\}**
+
+- GitHub: [https://github.com/eternalsafe/wallet](https://github.com/eternalsafe/wallet)
+- Hosted (IPFS): [https://eternalsafe.eth.limo](https://eternalsafe.eth.limo) (requires bring your own RPC)
+- Local: Can be downloaded and run locally
+
+Note: Local/alternative UIs may not be actively maintained. Treat them as emergency options and perform extra
+verification. Please DYOR.
+
+### Solana
+
+**Squads Public Client - Open source Squads V4 interface: **
+
+- GitHub: [https://github.com/Squads-Protocol/public-v4-client](https://github.com/Squads-Protocol/public-v4-client)
+- Features: Verifiable build, self-hostable with Docker, IPFS distribution
+- Local: Can be built and run locally
+
+### Mobile (Safe)
+
+**Safe Mobile Apps: **
+
+- GitHub: [https://github.com/safe-global/safe-wallet-monorepo/tree/dev/apps/mobile](https://github.com/safe-global/safe-wallet-monorepo/tree/dev/apps/mobile)
+- App Store: [https://apps.apple.com/us/app/safe-mobile/id6748754793](https://apps.apple.com/us/app/safe-mobile/id6748754793)
+- Play Store: [https://play.google.com/store/apps/details?id=global.safe.mobileapp](https://play.google.com/store/apps/details?id=global.safe.mobileapp)
+
+## RPC Backup Options
+
+### Basic guidance:
+
+- Multiple providers: Set up accounts with 2-3 different RPC services
+  - eg. Alchemy, Infura, Chainstack, Quicknode, Tenderly
+- Avoid correlation: Choose providers that don't share infrastructure, if that information is available
+- Private RPCs preferred: Public RPC URLs are typically not sufficient for reliable operation
+
+### Administrator responsibilities
+
+Ensure signer preparedness:
+
+- Provide access to offline UI tools listed above
+- Verify signers have practiced using backup interfaces
+- Test backup RPCs during non-emergency periods
+- Document procedures for switching to backup infrastructure
+
+## Block Explorer Backup Options
+
+### EVM Networks
+
+Etherscan provides the default block explorer for nearly all EVM chains. In the event that Etherscan is compromised or
+goes down, it is important to have backup options that can be used for monitoring and investigating transactions.
+
+**Blockscout - Open source Etherscan alternative: **
+
+- [https://www.blockscout.com/](https://www.blockscout.com/)
+- Available for all EVM networks
+- Can also be [self-hosted](https://github.com/blockscout/blockscout), although it requires significant time to run full
+  node and index
+
+More explorers: A broader list of network explorers is maintained here: [https://explorer.swiss-knife.xyz/](https://explorer.swiss-knife.xyz/)
+
+### Solana Networks
+
+Both explorer.solana.com and Solscan are reliable options for Solana transaction exploration and decoding.
+
+**explorer.solana.com** - [https://explorer.solana.com/](https://explorer.solana.com/)
+
+- Can be [self-hosted](https://github.com/solana-foundation/explorer) using open source code
+
+**Solscan** - [https://solscan.io/](https://solscan.io/)
+
+## Preparation
+
+**It is recommended to download dependencies ahead of time and store them in a secure location** so they are easily
+accessible during emergencies.
+
+## EVM Networks
+
+### Eternal Safe - Decentralized fork of Safe\{Wallet\}
+
+#### Access Options
+
+- **GitHub**: [https://github.com/eternalsafe/wallet](https://github.com/eternalsafe/wallet)
+- **Hosted (IPFS)**: [https://eternalsafe.eth.limo](https://eternalsafe.eth.limo) (requires bring your own RPC)
+- **Local**: Can be downloaded and run locally
+
+#### Setup
+
+1. Select network and enter an RPC URL
+   <div align="center">
+     <img
+       src="https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/eternal-safe-network-selection.png"
+       alt="Eternal Safe network selection"
+       style={{ height: "400px" }}
+     />
+     <p>
+       <em>
+         Eternal Safe network selection screen: choose your network and enter an
+         RPC URL
+       </em>
+     </p>
+   </div>
+2. Enter Safe address and load
+   ![Eternal Safe address entry](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/eternal-safe-address-entry.png)
+3. Eternal Safe will automatically detect Ether balances but not ERC20 tokens. They can be added manually
+   ![Eternal Safe token configuration](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/eternal-safe-token-configuration.png)
+
+#### Transaction Verification
+
+**Critical**: It is still essential to verify hashes and calldata from Eternal Safe. Follow the verification steps in
+[Safe Multisig: Step-by-Step Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification).
+
+#### Smart Link System
+
+Once a transaction has been signed by one signer, a **Smart Link** is created which can be forwarded to the next signer
+to add their signature. The transactions do not go to any centralized backend.
+
+**Example Smart Link:**
+
+```
+Please sign this Eternal Safe transaction for the Safe: base:0xA79C6968E3c75aE4eF388370d1f142720D498fEC.
+Current confirmations: 1 of 2.
+https://eternalsafe.eth.limo/transactions/tx/?safe=base:0xA79C6968E3c75aE4eF388370d1f142720D498fEC&tx=eyJzaWduYXR1cmVzIjp7ImRhdGFUeXBlIjoiTWFwIiwidmFsdWUiOltbIjB4NDBiYjMyZjA4NjJkMjI3ODEzYzg2ZmQ4M2E3YjNjOWRiOTA3NGUyYSIseyJzaWduZXIiOiIweDQwYkIzMkYwODYyRDIyNzgxM2M4NkZEODNBN0IzYzlkYjkwNzRFMkEiLCJkYXRhIjoiMHgwZDMxZTZjODIxZjBhMGZlM2M5NmNlZWY4ZDNhM2JhZmU3YmZmZTliODQ0ZWNkYzBkYWNmNzc0MzFkODQ0NjU4MTgwZjUwNmZlMjZiZjMzOTQwY2VhOTJiMzlhNDNjODRkMDRhNThiMGY1ODQ2NzhlNzE0YTllMWJkMzE0NTg5ZjFiIn1dXX0sImRhdGEiOnsiZGF0YSI6IjB4IiwiYmFzZUdhcyI6IjAiLCJnYXNQcmljZSI6IjAiLCJzYWZlVHhHYXMiOiIwIiwiZ2FzVG9rZW4iOiIweDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAiLCJub25jZSI6NCwicmVmdW5kUmVjZWl2ZXIiOiIweDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAiLCJ2YWx1ZSI6IjEwMDAwMDAwMDAwMDAwMDAiLCJ0byI6IjB4RTBiY2ZlNWUzMEFCYTBCNDZmMTNCMEMyNENiQzQ3MERDQTNlYjg2NSIsIm9wZXJhdGlvbiI6MH19
+```
+
+#### Execution
+
+Once all signatures are collected, execute the transaction. **Note**: Prior to execution you can manually simulate using
+Tenderly by entering the transaction data, but an automatic simulation link will not be available.
+
+## Solana
+
+### Squads Public Client - Open source Squads V4 interface
+
+#### Access Options
+
+- **GitHub**: [https://github.com/Squads-Protocol/public-v4-client](https://github.com/Squads-Protocol/public-v4-client)
+- **Hosted**: [https://backup.app.squads.so/](https://backup.app.squads.so/)
+- **Features**: Verifiable build, self-hostable with Docker, IPFS distribution
+- **Local**: Can be built and run locally
+
+#### Setup
+
+1. If running locally, follow setup instructions in [https://github.com/Squads-Protocol/public-v4-client](https://github.com/Squads-Protocol/public-v4-client)
+ and access via `http://localhost:8080`
+2. Enter RPC URL in settings
+   ![Squads RPC configuration](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/squads-rpc-configuration.png)
+3. Enter multisig address in the **lower** text box (Search for Multisig Config) and select the detected Multisig Config
+   ![Squads multisig selection](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/squads-multisig-selection.png)
+
+#### Transaction Operations
+
+1. Create, approve, or execute transactions. _Smart Links_ are not needed for Solana as all transactions are on chain
+   and accessible via the RPC without an API
+   ![Squads transaction interface](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/squads-transaction-interface.png)
+
+## Security Considerations
+
+### Enhanced Verification
+
+When using backup systems:
+
+- **Extra caution required**: Be more thorough with verification procedures
+- **Multiple verification methods**: Use additional tools to cross-check transaction details
+- **Team confirmation**: Verify with other signers before proceeding with critical transactions
+- **Documentation**: Record use of backup systems and any issues encountered
+
+### Risk Assessment
+
+- **Delay non-critical operations**: Consider postponing non-urgent transactions until primary systems recover
+- **Emergency operations only**: For critical emergency responses, proceed with enhanced verification
+- **Communication**: Keep team informed about system status and verification procedures
+
+## Testing and Preparation
+
+### Regular Practice
+
+- **Monthly testing**: Practice using backup interfaces during normal operations
+- **Team coordination**: Ensure all signers can operate backup systems
+- **Process documentation**: Update procedures based on practice sessions
+
+### Emergency Drills
+
+- **Simulated outages**: Practice coordinating with backup systems during drills
+- **Communication testing**: Verify backup communication channels work with backup UIs
+- **Time measurement**: Track how long backup system activation takes
+
+## Troubleshooting
+
+### Common Issues
+
+- **RPC connectivity**: Switch to alternative RPC providers if connection fails
+- **Transaction loading**: Refresh or try different network endpoints
+- **Signature verification**: Use multiple verification tools when in doubt
+
+### Support Resources
+
+- **GitHub documentation**: Refer to project documentation for technical issues
+- **Team assistance**: Coordinate with other signers for problem-solving
+- **Alternative tools**: Have multiple backup options available
+
+## Related Documents
+
+- [Safe Multisig: Step-by-Step
+Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification) - Verification procedures
+- [Emergency Procedures](/multisig-for-protocols/emergency-procedures) - General emergency response
+- [Communication Setup](/multisig-for-protocols/communication-setup) - Backup communication during outages
+
+---
+
+### PAGE: /opsec/core-concepts/web3-considerations
+**Title:** Web3 Security Considerations
+**Referenced by controls:** ms-4.1.2
+
+# Web3-Specific OpSec Considerations
+
+
+
+
+> 🔑 **Key Takeaway**: Web3 environments require specialized security approaches that balance blockchain transparency
+> with privacy, address immutability risks, manage self-custody responsibilities, secure decentralized operations,
+> mitigate smart contract vulnerabilities, and navigate community-driven security challenges.
+
+In addition to traditional OpSec principles, Web3 environments require consideration of unique challenges. Many
+organizations claim to be backed only by decentralized technologies, but they later realize that part of their process
+is dependant on technologies that are not.
+
+{/* > **🔗 Related Framework:** Explore the dedicated [Web3-Specific OpSec](/operational-security/web3-specific-opsec/)
+framework for comprehensive guidance. */}
+
+## Transparency vs. Privacy
+
+Balancing the transparent nature of blockchain with the need for operational privacy.
+
+### Suggested steps
+
+1. Understand what information is publicly visible on-chain
+   - Transaction amounts, addresses, contract interactions, and timestamps
+   - Use block explorers and analysis tools to understand your on-chain footprint
+2. Develop strategies to maintain operational privacy while utilizing public blockchains
+   - Use different addresses for different transaction types or business functions
+   - Consider privacy-focused layer 2 solutions for sensitive operations
+3. Use privacy-enhancing technologies where appropriate
+   - ZK (Zero-Knowledge) protocols for privacy-preserving computations
+   - Privacy pools or similar technologies (when legally permissible)
+   - Privacy-focused blockchains for specific operations (e.g., Monero, Zcash)
+
+## Immutability and Finality
+
+Recognizing that blockchain transactions are generally irreversible, requiring heightened security before execution.
+
+### Suggested steps
+
+1. Implement robust verification procedures before executing transactions
+   - Mandatory multi-person review for transactions above defined thresholds
+   - Automated checks for anomalous transaction patterns
+   - Hash verification of destination addresses
+2. Use multi-signature requirements for high-value transactions
+   - 3-of-5 or 2-of-3 signature schemes for treasury operations
+   - Hardware wallets for each signer with physical separation
+   - Time-locks for large transfers (24-48 hour delay before execution)
+3. Deploy transaction simulation tools to verify outcomes before execution
+   - Use Tenderly or similar platforms to simulate transactions in a fork of the chain
+   - Verify gas estimates and test with small amounts first when using new contracts\
+   - Use auxiliary tools such as
+   [Safe Multi-sig Transaction Hashes](https://github.com/pcaversaccio/safe-tx-hashes-util)
+4. Establish secure deployment practices for smart contracts
+   - Use formal verification tools before mainnet deployment
+   - Implement deployment scripts with dry-run functionality
+   - Require multiple approvals in your deployment pipeline
+   - Consider gradual deployments with circuit breakers for critical contracts
+
+## Self-Custody Responsibility
+
+Managing private keys and digital assets with appropriate security controls.
+
+> **🔗 Related Framework:** For detailed guidance on wallet security practices, see the
+> [Wallet Security](/wallet-security/overview) framework.
+
+### Suggested steps
+
+1. Develop clear procedures for wallet security
+   - Air-gapped hardware wallet setups for cold storage
+   - Specific seed phrase backup procedures (e.g., metal backups, split storage)
+   - Clear rules for when hot vs. cold wallets should be used
+2. Implement separation of duties for transaction approval
+   - Different roles for transaction initiation, verification, and execution
+   - Rotation of responsibilities to prevent single points of compromise
+   - Hardware security modules (HSMs) for institutional-grade key management
+3. Balance security with operational efficiency
+   - Define thresholds for different security requirements (e.g., `<$10K`, `$10K-$100K`, `>$100K`)
+   - Implement tiered wallet architecture (hot wallets for operations, cold storage for reserves)
+   - Establish secure methods for replenishing hot wallets from cold storage
+4. [Stay up-to-date](/awareness/staying-informed-and-continuous-learning) with best practices in wallet security and
+custody solutions
+   - Subscribe to security advisory services for cryptocurrencies
+   - Follow developments in MPC (Multi-Party Computation) wallet technologies
+   - Regularly review and test recovery procedures
+
+## Decentralized Operations
+
+Securing operations across distributed teams and systems.
+
+### Suggested steps
+
+1. Establish clear security protocols for remote team members
+   - Device security requirements (disk encryption, endpoint protection, auto-updates)
+   - Secure home network guidelines (dedicated VLANs, strong WPA3 passwords)
+   - Clear policies for public WiFi usage (always-on VPN requirement)
+2. Use secure communication channels for sensitive discussions
+   - End-to-end encrypted messaging (Signal, Matrix/Element with verified devices)
+   - Ephemeral messaging for highly sensitive topics (disappearing messages)
+   - Encrypted video conferencing with waiting rooms and passwords (Jitsi, Signal)
+   - PGP-encrypted emails for sensitive communications that need to be preserved
+3. Implement strong authentication for all team members
+   - Hardware security keys (Yubikeys, Passkeys) as primary 2FA method
+   - TOTP apps as backup authentication method (not SMS)
+   - Passwordless authentication where possible (WebAuthn/FIDO2)
+   - Regular access review and prompt offboarding procedures
+4. Create guidelines for secure collaboration in a distributed environment
+   - Encrypted file storage and sharing (Cryptomator, end-to-end encrypted cloud storage)
+   - Private repositories with signed commits for code collaboration
+   - Secure DevOps practices for CI/CD pipelines
+   - Role-based access to administrative systems with just-in-time privilege elevation
+
+## Smart Contract Vulnerabilities
+
+Addressing the immutable nature of deployed code.
+
+### Suggested steps
+
+1. Conduct thorough code reviews and security audits before deployment
+   - Multiple independent security audits for critical contracts
+   - Comprehensive test coverage (>95%) for all contract functions
+   - Symbolic execution and static analysis tools (Slither, Mythril)
+2. Implement upgradability patterns where appropriate
+   - Proxy patterns with clear governance mechanisms
+   - Immutable core logic with upgradeable periphery
+   - Emergency pause functionality with decentralized controls
+3. Use formal verification where possible
+   - Mathematical proofs of contract correctness for critical functions
+   - Verification of business logic and security properties
+   - Property-based testing frameworks (Echidna, Scribble)
+4. Maintain comprehensive testing environments
+   - Local development environments with mainnet forking
+   - Testnet deployments with real-world simulation
+   - Adversarial testing and red team exercises
+5. Consider timelocks and circuit breakers for critical functions
+   - Time-delayed administration actions (48-72 hours)
+   - Value-limit circuit breakers for suspicious transaction volumes
+   - Decentralized monitoring and alerting systems
+
+## Community Dynamics
+
+Managing security in open, community-driven projects.
+
+### Suggested steps
+
+1. Develop clear security guidelines for community contributors
+   - Documented security policies in repositories
+   - Security templates for pull requests
+   - Required security reviews for changes to sensitive components
+2. Establish review processes for community-submitted code
+   - Multi-level review requirements based on code criticality
+   - Automated security scanning integrated into CI/CD pipelines
+   - Bounty programs for vulnerability identification
+3. Create security awareness programs for the community
+   - Educational resources on common vulnerabilities
+   - Regular security-focused community calls or workshops
+   - Recognition for security-conscious contributions
+4. Balance transparency with operational security needs
+   - Clear guidelines on what information should remain private
+   - Secure channels for reporting vulnerabilities
+   - Responsible disclosure policies and timelines
+   - Public security incident post-mortems (with appropriate redactions)
+
+---
+
+---
+
+### PAGE: /multisig-for-protocols/planning-and-classification
+**Title:** Multisig Planning & Classification | SEAL
+**Referenced by controls:** ms-6.1.2
+
+TagList,
+  AttributionList,
+  TagProvider,
+  TagFilter,
+  ContributeFooter,
+} from "../../../components";
+
+
+
+
+# Planning & Classification
+
+
+
+
+Before setting up a new multisig, take time to properly assess its role and requirements. This planning phase will guide
+all subsequent configuration decisions and help ensure appropriate security measures.
+
+## Before You Start
+
+### Define Purpose and Scope
+
+Document the multisig's intended use:
+
+- **Primary function** - What will this multisig do?
+- **Asset types and amounts** - What will it control?
+- **Operational frequency** - How often will it be used?
+- **Decision timeline** - How quickly must it respond?
+- **Integration points** - What systems will it interact with?
+
+### Assess Constraints and Recovery
+
+Consider limiting factors that affect risk:
+
+- **Smart contract constraints** - What technical limits reduce risk?
+- **Governance recovery** - Can governance override or recover funds?
+- **Operational limits** - Are there built-in spending or parameter limits?
+- **Backup mechanisms** - What happens if this multisig fails?
+
+### Identify Stakeholders
+
+Determine who should be involved:
+
+- **Required expertise** - What knowledge is needed for decisions?
+- **Geographic distribution** - Do you need global coverage?
+- **External signers** - Should independent parties be involved?
+- **Backup signers** - Who can step in if primary signers are unavailable?
+
+## Classification Process
+
+Use this dual classification system to determine appropriate security measures. These classifications are guidance to
+help you think through risk levels - they inform threshold selection, signer requirements, and operational procedures in
+later sections.
+
+### Step 1: Impact Assessment
+
+What happens if this multisig is compromised or fails?
+
+#### Financial Exposure:
+
+- Direct funds controlled by the multisig
+- Indirect exposure through protocol impacts
+- Maximum potential loss in worst-case scenario
+
+#### Protocol Impact:
+
+- Can the protocol function without this multisig?
+- How difficult would recovery be?
+- Are there alternative execution paths?
+
+#### Reputational Risk:
+
+- How visible is this multisig to the community?
+- What would compromise mean for the protocol's reputation?
+- Are there regulatory or compliance considerations?
+
+#### Impact Classification
+
+| Level | Financial Exposure | Protocol Impact | Reputational Risk |
+| ------------ | ---------------------- | ----------------------------------------------------- | ----------------------------- |
+| **Low** | \<$100k direct exposure | Minimal disruption, alternative paths exist | Limited scope impact |
+| **Medium** | $100k - $1M exposure | Significant operational delays, workarounds available | Moderate reputational concern |
+| **High** | $1M - $10M exposure | Major protocol disruption, difficult recovery | Serious reputational damage |
+| **Critical** | \>$10M exposure | Protocol-wide failure, catastrophic impact | Severe reputational damage |
+
+### Step 2: Operational Assessment
+
+How quickly and under what conditions must this multisig respond?
+
+#### Response Time Requirements:
+
+- How quickly must decisions be made?
+- What are the consequences of delays?
+- Are there market or competitive timing factors?
+
+#### Decision Context:
+
+- Are operations routine and predictable?
+- Do market conditions affect timing?
+- Is this primarily for emergency response?
+
+#### Coordination Complexity:
+
+- How many parties must coordinate?
+- Are signers distributed globally?
+- What communication is required?
+
+#### Operational Classification
+
+| Type | Response Time | Decision Context | Verification Level |
+| ------------------ | ------------- | -------------------------------------------- | -------------------------------- |
+| **Routine** | 24-48 hours | Standard procedures, predictable operations | Full verification protocols |
+| **Time-Sensitive** | 2-12 hours | Market conditions, protocol needs | Streamlined but thorough |
+| **Emergency** | \<2 hours | Crisis response, preventing immediate damage | Minimal delays, risk-appropriate |
+
+### Step 3: Classification Matrix
+
+Combine your impact and operational assessments. Below are some example configurations.
+
+| Use Case | Impact | Operational | Standard Threshold |
+| ------------------- | -------- | -------------- | ------------------ |
+| Emergency Freeze | Critical | Emergency | 2/4 |
+| Protocol Parameters | High | Routine | 4/7 (higher for upgrades, consider 7/9+) |
+| Capital Allocation | High | Time-Sensitive | 3/5 |
+| Treasury - Large | High | Routine | 4/7 |
+| Treasury - Small | Medium | Routine | 3/5 |
+| Constrained DeFi | Medium | Time-Sensitive | 2/3 |
+
+### Step 4: Document Your Decision
+
+Record your classification decision in the [Registration template](/multisig-for-protocols/registration-and-documentation#registration-template).
+
+## Important Notes
+
+⚠️ **When between classifications**: Always err toward higher security requirements. Classifications can be relaxed with
+proper justification, but security incidents cannot be undone.
+
+This classification will guide your threshold selection ([Thresholds &
+Configuration](/wallet-security/secure-multisig-best-practices#thresholds--configuration)), signer requirements, and
+operational procedures throughout the rest of the documentation.
+
+## Next Steps
+
+After completing classification, proceed to:
+
+1. [Setup & Configuration](/multisig-for-protocols/setup-and-configuration) - Deploy your multisig
+2. [Registration & Documentation](/multisig-for-protocols/registration-and-documentation) - Document your setup
+
+---
+
diff --git a/scripts/data/eval-briefs/sfc-treasury-ops.md b/scripts/data/eval-briefs/sfc-treasury-ops.md
new file mode 100644
index 00000000..5a19017a
--- /dev/null
+++ b/scripts/data/eval-briefs/sfc-treasury-ops.md
@@ -0,0 +1,3516 @@
+# Evaluation Brief: sfc-treasury-ops
+
+## TASK
+
+For each control below, evaluate whether the candidate framework pages ACTUALLY meet the baseline requirements.
+A page must SUBSTANTIVELY address the baseline — not just mention related keywords.
+Be strict: if a baseline says "reviewed at least annually" and the page doesn't mention review cadence, that baseline is NOT met.
+
+## CONTROLS (21 total)
+
+### tro-1.1.1: Treasury Operations Owner
+**Question:** Is there a clearly designated person or team accountable for treasury operations?
+**Baselines (1):**
+  1. Accountability scope covers policy upkeep, security reviews, operational hygiene, access control oversight, and incident escalation
+**Candidate pages:** /treasury-operations/enhanced-controls, /wallet-security/encumbered-wallets, /multisig-for-protocols/emergency-procedures
+
+### tro-1.1.2: Treasury Registry and Documentation
+**Question:** Do you maintain a complete, current record of all treasury wallets, accounts, and their configurations?
+**Baselines (3):**
+  1. Registry includes wallet/account address, network/chain, custody provider, custody model, purpose/classification, authorized signers/approvers, controlled contracts or protocols, and last review date
+  2. Updated within 24 hours for security-critical changes (signer changes, new wallets), 3 days for routine changes
+  3. Accessible to authorized treasury personnel
+**Candidate pages:** /wallet-security/secure-multisig-best-practices, /treasury-operations/enhanced-controls, /treasury-operations/transaction-verification
+
+### tro-1.1.3: Custody Architecture Rationale
+**Question:** Do you have documented rationale for your treasury custody architecture?
+**Baselines (3):**
+  1. Custody model documented for each wallet/account (custodial, self-custody, co-managed, MPC, multisig, HSM)
+  2. Technology trade-offs understood by the team (not necessarily a formal document — could be a brief internal memo)
+  3. Custody architecture reviewed when treasury size, operational needs, or risk profile changes significantly
+**Candidate pages:** /multisig-for-protocols/implementation-checklist, /treasury-operations/transaction-verification, /treasury-operations/enhanced-controls
+
+### tro-1.1.4: Treasury Infrastructure Change Management
+**Question:** Do you have change management procedures for treasury infrastructure modifications?
+**Baselines (5):**
+  1. Covers wallet setups, custody configurations, signer/approver permission changes, and protocol integrations
+  2. Changes require documented approval before implementation
+  3. All changes logged with justification and approver
+  4. Changes reflected in the treasury registry within defined SLAs
+  5. Rollback procedures documented for critical changes
+**Candidate pages:** /treasury-operations/enhanced-controls, /wallet-security/secure-multisig-best-practices, /multisig-for-protocols/setup-and-configuration
+
+### tro-2.1.1: Treasury Wallet Risk Classification
+**Question:** Do you classify your treasury wallets and accounts by risk level and assign security controls accordingly?
+**Baselines (5):**
+  1. Classification considers financial exposure, operational dependency, and regulatory impact
+  2. Impact levels defined (e.g., Low <1%, Medium 1-10%, High 10-25%, Critical >25% of total assets)
+  3. Operational types defined based on transaction frequency and urgency requirements
+  4. Each classification maps to specific controls including approval thresholds, MFA requirements, whitelist delays, and monitoring levels
+  5. Classification reviewed when asset values, operational patterns, or risk profile change significantly
+**Candidate pages:** /treasury-operations/enhanced-controls, /treasury-operations/classification, /wallet-security/secure-multisig-best-practices
+
+### tro-2.1.2: Fund Allocation Limits and Rebalancing
+**Question:** Do you enforce fund allocation limits and rebalancing triggers across your treasury?
+**Baselines (4):**
+  1. Maximum allocation defined per wallet, per custody provider, and per chain
+  2. Rebalancing triggers documented (e.g., when a wallet exceeds its allocation ceiling or falls below operational minimums)
+  3. Allocation limits reviewed periodically and after significant treasury changes
+  4. No single wallet or custody account holds more than the organization's defined maximum concentration
+**Candidate pages:** /treasury-operations/enhanced-controls, /treasury-operations/transaction-verification, /treasury-operations/classification
+
+### tro-3.1.1: Custody Platform Security Configuration
+**Question:** Do you configure and maintain security controls on your custody platforms?
+**Baselines (6):**
+  1. Transaction policy rules configured: multi-approval workflows, approval thresholds scaled to transaction value, address whitelisting with cooling-off periods, velocity/spending limits
+  2. Hardware security key MFA required for all approvers on High and Critical accounts
+  3. Session timeouts and re-authentication for sensitive operations
+  4. Network restrictions: IP whitelisting, VPN requirements where supported, geographic access restrictions
+  5. Separation of duties enforced: initiators cannot approve their own transactions, admins cannot unilaterally execute withdrawals
+  6. Platform configurations documented and reviewed at least quarterly
+**Candidate pages:** /treasury-operations/enhanced-controls, /treasury-operations/transaction-verification, /treasury-operations/registration-documents
+
+### tro-3.1.2: Credential and Secret Management
+**Question:** Do you securely manage all credentials and secrets used in treasury operations?
+**Baselines (5):**
+  1. Covers API keys, service accounts, owner/admin credentials, and signing keys
+  2. Credentials stored in dedicated secret management systems, not in code, documents, or shared drives
+  3. Owner and admin credentials isolated from day-to-day operational access
+  4. Credential rotation schedule defined and enforced
+  5. Access to credentials logged and monitored
+**Candidate pages:** /treasury-operations/enhanced-controls, /multisig-for-protocols/personal-security-opsec, /wallet-security/secure-multisig-best-practices
+
+### tro-3.1.3: Access Reviews for Treasury Systems
+**Question:** Do you periodically review who has access to treasury systems?
+**Baselines (3):**
+  1. Access reviews conducted at least quarterly for High/Critical accounts, annually for others
+  2. Reviews verify each user still requires their current access level
+  3. Access promptly revoked when personnel change roles or leave
+**Candidate pages:** /treasury-operations/enhanced-controls, /treasury-operations/registration-documents, /wallet-security/secure-multisig-best-practices
+
+### tro-3.1.4: Personnel Operational Security
+**Question:** Do you enforce operational security requirements for treasury personnel?
+**Baselines (6):**
+  1. Device security requirements documented: dedicated devices for custody access, full disk encryption, automatic screen lock
+  2. Signing devices (hardware wallets) securely stored when not in use
+  3. Backup materials (seed phrases, recovery keys) stored securely with geographic distribution
+  4. VPN mandatory for all remote treasury platform access
+  5. Travel security procedures for personnel with signing or custody access capabilities
+  6. Mobile devices used as second factors have endpoint security monitoring
+**Candidate pages:** /treasury-operations/enhanced-controls, /wallet-security/seed-phrase-management, /multisig-for-protocols/personal-security-opsec
+
+### tro-4.1.1: Transaction Verification and Execution
+**Question:** Do you have a defined process for verifying and executing treasury transactions?
+**Baselines (8):**
+  1. Pre-execution verification includes: recipient address validation, amount verification, network confirmation, and transaction simulation
+  2. Test transactions required before sending to new addresses
+  3. Address verified through multiple independent sources; never copied from email, chat, or transaction history
+  4. Multi-party confirmation required: minimum 2 internal personnel for large transfers
+  5. Specific procedures for receiving large incoming transfers (address generation, bidirectional test, sender coordination)
+  6. Specific procedures for OTC transactions where applicable
+  7. High-value transfers (organization-defined threshold) require video call verification with liveness checks
+  8. All transaction parameters read aloud and confirmed before execution
+**Candidate pages:** /treasury-operations/enhanced-controls, /treasury-operations/transaction-verification, /wallet-security/secure-multisig-best-practices
+
+### tro-4.1.2: Signer and Approver Knowledge
+**Question:** Are treasury signers and approvers knowledgeable in the security practices relevant to their role?
+**Baselines (4):**
+  1. Knowledge covers: transaction verification procedures, address validation techniques, social engineering awareness, emergency procedures
+  2. Competence demonstrated before authorization (e.g., verifying a test transaction end-to-end)
+  3. Knowledge refreshed annually; updated within 30 days of significant procedure changes
+  4. Covers custody-platform-specific workflows and policy engine rules
+**Candidate pages:** /treasury-operations/enhanced-controls, /wallet-security/secure-multisig-best-practices, /treasury-operations/transaction-verification
+
+### tro-4.1.3: Secure Communication Procedures
+**Question:** Do you have secure communication procedures for treasury operations, including standard identity verification?
+**Baselines (6):**
+  1. Dedicated primary and backup channels on different platforms
+  2. End-to-end encryption, MFA required, invitation-based membership
+  3. Identity verified as standard procedure during signing/approval operations (e.g., code phrases, video call, secondary authenticated channel)
+  4. Anti-social-engineering protocols: established verification procedures for address changes or unusual requests
+  5. Documented procedures for channel compromise including switching to backup channels and out-of-band verification
+  6. All treasury personnel trained on these procedures; compromise response tested annually
+**Candidate pages:** /multisig-for-protocols/implementation-checklist, /multisig-for-protocols/backup-signing-and-infrastructure, /multisig-for-protocols/emergency-procedures
+
+### tro-5.1.1: Protocol Evaluation and Exposure Limits
+**Question:** Do you evaluate external protocols and enforce exposure limits before deploying treasury funds?
+**Baselines (4):**
+  1. Due diligence process for all protocols before deployment: smart contract audit status, team reputation, TVL history, insurance coverage
+  2. Exposure limits defined per protocol, per chain, and per deployment category (DeFi, staking, liquid staking, etc.)
+  3. Limits reviewed periodically and after significant market or protocol changes
+  4. Risk re-evaluation triggered by: security incidents, major governance proposals, significant TVL changes, new vulnerabilities disclosed
+**Candidate pages:** /treasury-operations/enhanced-controls, /wallet-security/secure-multisig-best-practices, /wallet-security/account-abstraction
+
+### tro-5.1.2: Position Lifecycle Management
+**Question:** Do you have procedures for managing the lifecycle of your positions in external protocols?
+**Baselines (4):**
+  1. Entry procedures: smart contract address verification against multiple independent sources, token approval management (minimal approvals, revocation after use)
+  2. Emergency withdrawal/exit procedures documented for all active positions
+  3. Alternative access methods documented in case primary UIs are unavailable (direct contract interaction, CLI tools, alternative frontends)
+  4. Unbonding/unstaking timelines understood and factored into liquidity planning
+**Candidate pages:** /wallet-security/secure-multisig-best-practices, /multisig-for-protocols/implementation-checklist, /wallet-security/account-abstraction
+
+### tro-6.1.1: Monitoring and Threat Awareness
+**Question:** Do you monitor your treasury for anomalous activity, external threats, and operational risks?
+**Baselines (9):**
+  1. Transaction monitoring: unusual amounts, unexpected destinations, failed transactions, policy violations
+  2. Account state monitoring: balance changes, configuration modifications, new device enrollments, authentication anomalies
+  3. External threat intelligence: protocol vulnerabilities, DeFi/staking risks, relevant security incidents in the ecosystem
+  4. Vendor/platform monitoring: custody platform status, infrastructure alerts, service availability
+  5. Compliance monitoring: transactions and wallet addresses screened for sanctions and compliance risk
+  6. Protocol and position monitoring: deployed protocol health, governance changes, TVL shifts, collateral ratios, reward accrual, liquidation risks
+  7. Alerting with defined severity levels and escalation paths
+  8. Critical alerts (large unexpected transactions, unauthorized access attempts) trigger immediate investigation
+  9. Monitoring system integrity protected — alerts triggered when monitoring configurations are changed, disabled, or degraded
+**Candidate pages:** /treasury-operations/enhanced-controls, /incident-management/playbooks/seal-911-war-room-guidelines, /wallet-security/tools-and-resources
+
+### tro-6.1.2: Incident Response Plan
+**Question:** Do you have an incident response plan for treasury security events, and do you test it?
+**Baselines (7):**
+  1. Severity levels defined with escalation procedures specific to treasury operations
+  2. Containment procedures: fund protection actions (emergency freeze, transfer to secure cold storage, policy lockdown)
+  3. Covers key scenarios: custody platform compromise, unauthorized transaction, signer key compromise, vendor breach
+  4. Emergency contacts pre-documented: custody provider security team, SEAL 911, legal counsel
+  5. Communication plan for stakeholders
+  6. Drills conducted at least annually; after major procedure changes
+  7. Drill documentation includes: date, participants, response times, issues identified, improvements made
+**Candidate pages:** /treasury-operations/enhanced-controls, /wallet-security/secure-multisig-best-practices, /treasury-operations/transaction-verification
+
+### tro-7.1.1: Vendor Security Management
+**Question:** Do you evaluate and monitor the security of third-party services used in treasury operations?
+**Baselines (4):**
+  1. Initial due diligence before adoption: security certifications (SOC 2, ISO 27001), audit history, insurance coverage, incident history
+  2. Ongoing monitoring: SOC report currency, security incident notifications, service availability tracking
+  3. Contractual security requirements verified periodically (at least annually)
+  4. Critical vendor changes (ownership, infrastructure, security posture) trigger re-evaluation
+**Candidate pages:** /incident-management/playbooks/seal-911-war-room-guidelines, /treasury-operations/enhanced-controls, /governance/compliance-regulatory-requirements
+
+### tro-7.1.2: Backup Infrastructure and Alternate Access
+**Question:** Do you have backup infrastructure and alternate access methods for treasury operations?
+**Baselines (4):**
+  1. Alternate access methods for custody platforms documented and tested (e.g., API access, mobile app, secondary UI)
+  2. Backup RPC providers configured
+  3. Procedures for operating treasury if primary custody platform is unavailable
+  4. Backup infrastructure tested at least annually
+**Candidate pages:** /multisig-for-protocols/backup-signing-and-infrastructure, /multisig-for-protocols/implementation-checklist, /treasury-operations/enhanced-controls
+
+### tro-8.1.1: Financial Recordkeeping and Reconciliation
+**Question:** Do you maintain accurate treasury records and conduct periodic reconciliation?
+**Baselines (5):**
+  1. All treasury transactions recorded with categorization, documentation, and authorization chain
+  2. Periodic reconciliation between custody platform records, on-chain balances, and accounting records
+  3. Reconciliation frequency scaled to account classification: daily for Active Operations, weekly for Warm Storage, monthly for Cold Vault
+  4. Discrepancies investigated and resolved promptly
+  5. Treasury reporting procedures documented with defined cadence and audience
+**Candidate pages:** /treasury-operations/enhanced-controls, /treasury-operations/transaction-verification, /treasury-operations/classification
+
+### tro-8.1.2: Insurance Coverage
+**Question:** Do you maintain insurance coverage appropriate for your treasury operations?
+**Baselines (4):**
+  1. Coverage scope documented: what's covered (custody theft, hack, insider fraud) and what's excluded
+  2. Coverage amounts appropriate relative to assets held
+  3. Custody provider's insurance evaluated as part of vendor due diligence
+  4. Insurance coverage reviewed at least annually or when treasury size changes significantly
+**Candidate pages:** /treasury-operations/enhanced-controls, /treasury-operations/transaction-verification, /treasury-operations/classification
+
+---
+
+## FRAMEWORK PAGES (16 unique)
+
+### PAGE: /treasury-operations/enhanced-controls
+**Title:** Enhanced Controls for High-Risk Accounts | SEAL
+**Referenced by controls:** tro-1.1.1, tro-1.1.2, tro-1.1.3, tro-1.1.4, tro-2.1.1, tro-2.1.2, tro-3.1.1, tro-3.1.2, tro-3.1.3, tro-3.1.4, tro-4.1.1, tro-4.1.2, tro-5.1.1, tro-6.1.1, tro-6.1.2, tro-7.1.1, tro-7.1.2, tro-8.1.1, tro-8.1.2
+
+TagList,
+  AttributionList,
+  TagProvider,
+  TagFilter,
+  ContributeFooter,
+} from "../../../components";
+
+
+
+
+# Enhanced Controls for High-Risk Accounts
+
+
+
+
+For Critical and High impact custodial accounts, implement the following controls in addition to baseline measures.
+
+---
+
+## Transaction Verification
+
+- Test transactions: Send maximum $100 to new addresses before executing full transaction
+- Multi-channel confirmation: Request via one channel, approve via separate channel
+- Simulation requirement: All transactions must be simulated before execution
+- Address verification: Verify new addresses against three independent sources
+
+For DeFi interactions: refer to the [DeFi Risk Assessment Guide](https://entethalliance.org/specs/defi-risks/v1/) for
+recommended procedures.
+
+## Access Security
+
+- Hardware security keys (FIDO2/WebAuthn) mandatory for all approvers
+  - Secure fallback: Each approver must register minimum 2 hardware keys stored in separate secure locations
+  - Key loss procedure: Temporary access via backup key + additional approver verification via multiple channels +
+    mandatory key replacement within 48 hours
+- IP whitelisting with 24-hour change approval delay - if treasury software supports application-level IP whitelisting,
+  restrict to VPN IP range only
+- Device fingerprinting with new device approval process
+- Session timeout and re-authentication for sensitive operations
+- Dedicated credentials: Use separate email addresses and passwords exclusively for custody access, not shared with
+  other corporate systems
+
+## Device Security
+
+- Dedicated secure workstations and mobile devices for custody access only (no general browsing, email, or other
+  corporate activities)
+- Network isolation on separate VLAN/segment
+- VPN mandatory for all platform access; if treasury platform supports it, configure IP whitelisting to only allow
+  access from VPN IP addresses
+- Full disk encryption with automatic screen lock
+- MDM-enforced security baseline with remote wipe capability
+- Mobile endpoint security monitoring (e.g., iVerify) for devices used as second factors or keystores, without requiring
+  full MDM admin control
+
+## MPC for Large Holdings
+
+For organizations managing >10% of total assets or >$10M equivalent in a single custodial account consider using MPC:
+
+- Evaluate MPC (Multi-Party Computation) custody solutions that distribute key material across multiple parties
+- Consider threshold signature schemes (e.g., 3-of-5 or 5-of-9) where no single party controls sufficient key shares
+- Implement geographic distribution of key share holders across multiple jurisdictions
+- Establish clear key refresh and rotation procedures
+- Document recovery procedures and test annually
+
+### Custody/MPC Policy Thresholds for Treasury Operations
+
+- Minimum of 3 distinct approvers across roles (e.g., Treasury, Security, Finance)
+- Target majority approval (≥50% of designated approver group; e.g., 3/5, 4/7)
+- Scale quorum size with assets-at-risk and operational blast radius
+- Enforce separation of duties: requester cannot be an approver; admins cannot unilaterally execute withdrawals
+
+Policy scope definitions (examples):
+
+- Emergency Freeze: Temporarily block withdrawals/policy changes across workspaces
+- Protocol Parameters: Custody/policy engine settings, risk rules, policy changes
+- Capital Allocation: Movements between accounts, exchanges, or strategies
+- Treasury – Large: Routine treasury transfers above internal threshold or rate limit
+- Treasury – Small: Routine operational transfers below internal threshold or rate limit
+- Constrained DeFi: Time-sensitive interactions with pre-approved protocols/contracts
+
+Suggested approver thresholds (treasury contexts):
+
+| Operation            | Impact   | Urgency        | Approver Threshold            |
+| -------------------- | -------- | -------------- | ----------------------------- |
+| Emergency Freeze     | Critical | Emergency      | 2/4                           |
+| Protocol Parameters  | High     | Routine        | 4/7 (7/9+ for upgrades)       |
+| Capital Allocation   | High     | Time-Sensitive | 3/5                           |
+| Treasury - Large     | High     | Routine        | 4/7                           |
+| Treasury - Small     | Medium   | Routine        | 3/5                           |
+| Constrained DeFi     | Medium   | Time-Sensitive | 2/3                           |
+
+## Custody Policy Engine Rules
+
+Most custody/MPC platforms provide a policy engine that evaluates transaction rules and takes one of three actions:
+allow, block, or require additional approvals.
+
+Core rule elements:
+
+- Action: allow | block | escalate (require more approvers)
+- Asset selector: all assets or specific assets/tokens
+- Amount limits: per-transaction limit and optional rolling window aggregation
+- Source and destination selectors: account/wallet groups, internal vs external addresses, exchanges
+- Transaction type: transfers, contract interactions, approvals/signing
+- Initiators and approvers: who can initiate and who must authorize (with thresholds)
+- Rule identity and ordering: each rule has an ID; engines typically evaluate rules in order (first-match wins)
+
+## Zero Trust Architecture Alternative
+
+A Zero Trust architecture involves continuous verification of user, device, and context, rather than reliance on a
+single perimeter or network location. Centralizing access through a secure environment (such as a bastion host or
+isolated cloud workspace) can support Zero Trust principles when combined with strong identity and device posture
+enforcement.
+
+- Bastion Host Approach: Deploy a hardened jump server that acts as the sole gateway to custody platforms.
+  - All custody sessions route through the bastion with full session recording
+  - Bastion enforces MFA, device posture checks, and approved software versions
+  - No direct custody access from employee devices
+  - Centralized patch management and security configuration
+  
+- Cloud Workspace Isolation: Use browser-isolated or virtual workspace environments (e.g., Citrix, AWS WorkSpaces, Azure
+  Virtual Desktop)
+  - Custody access occurs only within a controlled virtual environment
+  - Copy/paste and download restrictions prevent data exfiltration
+  - Session timeout and automatic workspace destruction after use
+  - Significantly reduces risk from compromised employee devices
+
+## Security Monitoring & Logging
+
+For Critical and High impact accounts, implement centralized security monitoring:
+
+- SIEM Deployment: Deploy SIEM to centralize logs from custody platforms, authentication systems, and access devices.
+  Create real-time correlation rules for suspicious patterns (failed authentication, geographic anomalies, policy
+  changes).
+
+- Internal Incident Response: Build dedicated incident response capability for custody-related security events. Define
+  clear escalation procedures, maintain 24/7 on-call rotation for Critical accounts, and establish playbooks for custody
+  compromise scenarios.
+
+- Essential Log Sources: Authentication events, transaction attempts, policy modifications, access changes, whitelist
+  updates, IP address changes, new device enrollments, and approval workflows.
+
+For Medium and Low impact accounts, leverage custodian's native audit logs with weekly manual review and automated
+alerting for critical events (new device enrollment, policy changes, transactions above threshold).
+
+---
+
+### See also
+
+- Classification: [Custodial Treasury Security: Classification Framework](./classification)
+- Templates: [Registration Documents](./registration-documents)
+
+---
+
+### PAGE: /wallet-security/encumbered-wallets
+**Title:** TEE-based Encumbered Wallets
+**Referenced by controls:** tro-1.1.1
+
+# TEE-based Encumbered Wallets
+
+
+
+
+## User Profile
+
+Advanced users, developers, and organizations wanting to implement fine-grained security policies, that don't want to
+(EVM, Solana, Sui) or can't (Bitcoin, Litecoin, Dogecoin, XRP) make fully customizable logic on each chain individually.
+Additionally, encumbered wallets can use encrypted storage thus providing a level of transaction privacy.
+
+## Primary Goal
+
+To implement optionally private smart contract-like logic and programmable policies for wallet operations across any
+blockchain by encumbering private keys with restrictions. This enables features like conditional signing, multi-party
+authorization, time-locked transactions, and compliance policies that work universally, regardless of the underlying
+chain's capabilities, by instead relying on TEEs.
+
+## Core Concept: Key Encumbrance
+
+Key encumbrance refers to placing cryptographic or policy-based restrictions on a private key’s signing power. Instead
+of a raw key being free to sign any message, its use is “handcuffed” by rules or proofs, and access to it is limited to
+a preset interface. Examples include:
+
+* A key can only sign if a specific policy is met (e.g., only transfers to whitelisted addresses).
+* A key must co-sign with another party’s key (multi-sig or MPC).
+* A key’s signing rights are tied to a verifiable execution environment (e.g., inside a TEE or governed by smart
+  contract logic).
+
+Essentially, key encumbrance adds programmable controls to private keys, enabling fine-grained access, delegation, and compliance.
+
+## Core Concept: Trusted Execution Environments (TEEs)
+
+A Trusted Execution Environment (TEE) is a secure area of a processor that provides hardware-level protection for code
+and data. TEEs create an isolated environment where sensitive operations can run protected from the main operating
+system, other applications, and even privileged system software.
+
+**Key TEE Properties:**
+
+* **Hardware-based Isolation**: Code and data within the TEE are protected by CPU-level security features, not just
+  software isolation.
+* **Attestation**: TEEs can cryptographically prove their identity and the integrity of the code running inside them.
+* **Sealed Storage**: Data can be encrypted and tied to the specific TEE instance, ensuring it cannot be accessed
+  outside the secure environment.
+* **Memory Protection**: TEE memory is encrypted and isolated from the host system, preventing external access to
+  sensitive data.
+
+**Common TEE Technologies:**
+
+* **Intel SGX (Software Guard Extensions)**: Creates secure enclaves within applications that protect against privileged
+  malware and physical attacks.
+* **ARM TrustZone**: Divides the processor into "secure" and "non-secure" worlds, with hardware-enforced separation.
+* **AMD Memory Guard**: Provides memory encryption and isolation features similar to Intel SGX.
+* **Confidential Computing Platforms**: Cloud-based TEE services like Azure Confidential Computing or AWS Nitro Enclaves.
+
+**In Encumbered Wallets:**
+
+TEEs enable private keys to be generated, stored, and used within a protected environment where:
+
+* Keys never exist in plaintext outside the TEE
+* Policy logic runs confidentially within the secure enclave
+* External observers cannot see the encumbrance rules or key operations
+* Attestation proves the wallet is running authentic, unmodified code
+
+This hardware-level protection makes TEE-based encumbered wallets significantly more secure than software-only
+solutions, as even root or physical access to the host system cannot compromise the keys or policies within the TEE.
+
+**Please note that lately there has been a lot of controversy around TEEs, and many researchers are proving that it is not always the case that they add a layer of security. For more information on this, you can check out [TEE.fail](https://TEE.fail), which addresses vulnerabilities in Intel's and AMD's implementation.**
+
+## Key Benefits & Features
+
+**Cross-Chain Compatibility:**
+
+* **Universal Policy Logic**: Implement sophisticated access controls and transaction policies on any blockchain,
+  including Bitcoin, Litecoin, Dogecoin, and other non-smart contract chains.
+* **Chain-Agnostic Security**: Deploy consistent security policies across multiple blockchains without depending on each
+  chain's native capabilities.
+
+**Advanced Access Control:**
+
+* **Fine-Grained Permissions**: Delegate specific rights (voting, trading, asset transfer) to different parties without
+  revealing the full wallet structure.
+* **Time-Bounded Policies**: Implement temporary access controls that automatically expire after specified periods.
+* **Hierarchical Delegation**: Create multi-level permission structures where sub-policies can grant further access down
+  the chain.
+* **Asset-Time Segmentation**: Ensure that specific assets are controlled by exactly one policy at any given time,
+  preventing conflicts.
+
+**Privacy & Selective Disclosure:**
+
+* **Confidential Operations**: Policy logic and key operations remain encrypted and hidden from external observers.
+* **Compartmentalized Access**: Each delegatee only sees their authorized subset of operations, maintaining privacy of
+  the overall wallet structure.
+* **Selective Transparency**: Use view keys to prove compliance or ownership to auditors without revealing spending
+  control or full delegation hierarchy.
+
+**Compliance & Auditability:**
+
+* **Regulatory Compliance**: Support AML/KYC requirements through selective disclosure mechanisms without compromising
+  user privacy.
+* **Institutional Auditing**: Enable institutions to prove 1:1 collateralization or policy adherence to regulators using
+  view keys.
+* **Non-Transferability Proofs**: Demonstrate that certain assets (like compliance-bound RWAs or soulbound tokens)
+  remain under original owner control.
+
+**Operational Flexibility:**
+
+* **Programmable Recovery**: Implement sophisticated recovery mechanisms that work across any blockchain without relying
+  on smart contract support.
+* **Dynamic Policy Updates**: Modify access controls and delegation structures without changing the underlying
+  blockchain infrastructure.
+* **Multi-Asset Management**: Apply consistent policies across different cryptocurrencies and blockchain networks from a
+  single encumbered wallet system.
+
+## Security Considerations & Best Practices
+
+* Implement threshold or multi-party computation-based key custody rather than placing sole trust in a single TEE
+  enclave. Use multi-party threshold signatures or distributed key generation so that a single compromised node cannot
+  break the entire system, providing resilience against both hardware attacks and operational failures.
+* Incorporate economic incentive mechanisms such as staking requirements for TEE operators to align security incentives
+  through cryptoeconomic design. Require operators to post collateral that can be slashed for malicious behavior,
+  attestation failures, or policy violations, creating financial disincentives for compromise attempts and encouraging
+  proactive security maintenance of TEE infrastructure.
+* Carefully evaluate TEE technology selection based on application memory requirements and security priorities. For
+  encumbered wallet applications with modest memory needs (under 256MB), prefer Intel SGX v1 (Client SGX) which provides
+  integrity protection against hardware attacks, whereas applications requiring larger secure memory may need to accept
+  the trade-offs of newer implementations like Scalable SGX or SEV-SNP that offer greater memory capacity but lack
+  integrity protection against physical attacks.
+* Establish continuous re-attestation processes that periodically re-verify enclave conformance on a regular schedule
+  such as hourly or per-block intervals. This helps detect drift, tampering, or compromise attempts over time and
+  ensures that the enclave maintains its security properties throughout its operational lifetime.
+* Implement dual-attestation architectures for cloud-deployed nodes by requiring both Intel DCAP quotes and cloud
+  provider attestation services (such as Azure MAA or AWS Nitro Attestation). This approach provides defense-in-depth by
+  anchoring trust through multiple independent attestation roots with different threat models and security assumptions.
+* Maintain transparent attestation policy publication by documenting and publicly sharing allowed CPU models, TCB
+  versions, QE/PCS builds, and upgrade paths. This enables operators and auditors to verify compliance independently
+  while providing clear guidance for secure deployment configurations and helping detect potentially compromised or
+  outdated systems.
+* Collaborate with hardware vendors and ecosystem partners to push for enhanced TEE security features including replay
+  protection, alias detection, and memory mapping integrity. Engage in industry efforts to improve the fundamental
+  security properties of TEE implementations and advocate for standardized security enhancements across different TEE
+  platforms.
+
+## Relevant Papers
+
+* Austgen, J., Fábrega, A., Kelkar, M., Vilardell, D., Allen, S., Babel, K., Yu, J., & Juels, A. (2024, December 3).
+  Liquefaction: Privately liquefying blockchain assets. [arXiv.org](https://arxiv.org/abs/2412.02634)
+* Dai, W., Deng, J., Wang, Q., Cui, C., Zou, D., & Jin, H. (2018). SBLWT: a secure blockchain lightweight wallet based
+  on TrustZone. IEEE Access, 6, 40638–40648. [https://doi.org/10.1109/access.2018.2856864](https://doi.org/10.1109/access.2018.2856864)
+* Yu, J. (n.d.). PASS: A Provenanced Access Subaccount System for Blockchain Wallets [Stanford University](https://cs191.stanford.edu/projects/Yu,%20Jay_Systems%20191W.pdf)
+* Aublin, P.-L., Mahhouk, M., & Kapitza, R. (n.d.). Towards TEEs with Large Secure Memory and Integrity Protection
+  Against HW Attacks [IIJ Innovation Institute, TU Braunschweig](https://www.ibr.cs.tu-bs.de/bib/xml/aublin2022scalableSGX.html)
+
+---
+
+---
+
+### PAGE: /multisig-for-protocols/emergency-procedures
+**Title:** Multisig Emergency Procedures | SEAL
+**Referenced by controls:** tro-1.1.1, tro-4.1.3
+
+# Emergency Procedures
+
+
+
+
+When security incidents occur, quick and decisive action is critical. This page covers procedures for key compromise,
+lost access, and communication breaches.
+
+## Key Compromise
+
+### Immediate Actions (Within 30 Minutes)
+
+1. **Stop operations** - Halt all non-emergency transactions
+2. **Notify team** - Alert via all communication channels using emergency notification template
+3. **Assess scope** - Determine which keys may be compromised
+4. **Escalate** - Contact Security team immediately
+5. **Document** - Record timeline and details
+
+### Recovery Process
+
+1. **Isolate** - Quarantine potentially compromised devices
+2. **New hardware setup** - Set up fresh wallet with new seed following [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds)
+3. **Coordinate replacement** - Plan signer replacement transaction with team
+4. **Execute replacement** - Replace compromised signer on multisig, following steps for signer rotation in [Secure
+   Multisig Best Practices](/wallet-security/secure-multisig-best-practices)
+5. **Verify security** - Confirm new setup before resuming operations
+
+## Lost Key Access
+
+### Immediate Steps
+
+1. **Try backup device first** if available
+2. **Contact team immediately** via backup communication channels
+3. **Do not panic** - Lost access doesn't mean compromised keys
+4. **Document the situation** - Record what happened and when
+
+### Identity Verification Process
+
+Since you can't sign with your key, verify identity through alternative methods:
+
+- **Video call** with other signers
+- **Authentication** via verified social media account
+- **Other pre-arranged verification methods**
+
+### Replacement Coordination
+
+1. **Generate new hardware wallet** following standard setup procedures in [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds)
+2. **Verify new address** through identity verification process above
+3. **Coordinate timing** with other signers for replacement transaction
+4. **Execute replacement** once team confirms identity
+5. **Update documentation** with new signer information
+
+## Communication Account Compromise
+
+### If Telegram/Signal/Discord Gets Taken Over
+
+#### Immediate Actions
+
+1. **Assume all recent messages are suspect** - Don't trust recent communication
+2. **Use backup channels** to alert team about compromise
+3. **Change passwords** and enable additional security on compromised account
+
+#### Team Verification Process
+
+**For the compromised person:**
+
+- Use alternative contact methods (email, phone, other platforms)
+- Verify identity through video call or pre-arranged methods
+- Provide proof of the compromise (screenshots, platform confirmation)
+
+**For other team members:**
+
+- Verify all recent requests from compromised account
+- Cancel any pending transactions initiated via compromised communication
+- Require additional verification for any future requests until resolved
+
+#### Recovery Steps
+
+1. **Regain account control** through platform recovery processes
+2. **Enable maximum security** (2FA, security keys, session management)
+3. **Review recent message history** for unauthorized communications
+4. **Alert team** when account is secured and verified clean
+5. **Resume normal operations** only after team confirms account security
+
+## Emergency Notification Template
+
+Use this template for security incidents or key compromises:
+
+```
+Subject: [URGENT] Multisig Security Incident - [Multisig Name]
+
+Immediate details:
+- Multisig address: [ADDRESS]
+- Classification: [Impact Level / Operational Type]
+- Incident type: [Key Compromise / Communication Failure / System Issue]
+- Time of discovery: [TIMESTAMP]
+- Reporting signer: [NAME/HANDLE]
+
+Situation summary: [Brief description of what happened and current status]
+
+Immediate actions taken:
+□ Stopped non-emergency operations
+□ Isolated affected systems
+□ Notified team members
+□ [Other actions]
+
+Next steps required:
+□ Security team assessment
+□ Key rotation process
+□ Emergency transaction execution
+□ [Other actions]
+
+Current multisig status:
+- Available signers: [X/Y]
+- Communication status: [Operational/Compromised]
+- Operational capability: [Full/Limited/Suspended]
+```
+
+## Emergency Communication Protocols
+
+### Multi-Channel Notification
+
+- **Primary channel**: Alert via main communication channel
+- **Backup channels**: Simultaneously notify via backup platforms
+- **Emergency contacts**: Use emergency contact procedures if established
+
+### Identity Verification
+
+- **Code words**: Use pre-established verification phrases
+- **Multiple confirmations**: Verify through multiple channels
+- **Video verification**: Use video calls for critical confirmations
+
+### Information Sharing
+
+- **Need-to-know basis**: Share only essential information
+- **Secure channels only**: Use most secure available communication
+- **Documentation**: Record all emergency communications
+
+## Operational Emergency Procedures
+
+### For Emergency Response Multisigs
+
+#### Rapid Response Protocol
+
+1. **Immediate assessment** - Determine scope and urgency
+2. **Signer activation** - Contact threshold number of signers
+3. **Streamlined verification** - Use minimal verification appropriate for risk level
+4. **Execute response** - Implement emergency measures
+5. **Post-action review** - Document and assess response effectiveness
+
+#### 24/7 Availability
+
+- **Geographic distribution** - Ensure coverage across time zones
+- **Backup signers** - Have additional signers available for activation
+- **Communication redundancy** - Multiple ways to reach each signer
+
+### Emergency Drill Procedures
+
+#### Regular Testing Schedule
+
+- **Quarterly**: Communication system tests
+- **Bi-annually**: Emergency paging system tests
+- **Annually**: Full emergency simulation with all signers
+
+#### Drill Components
+
+1. **Notification test** - Verify all signers receive alerts
+2. **Response time measurement** - Track time to threshold signatures
+3. **Process verification** - Ensure procedures work under pressure
+4. **Documentation review** - Update procedures based on drill results
+
+## Recovery and Post-Incident
+
+### Immediate Recovery
+
+1. **Restore operations** - Resume normal operations once threat is mitigated
+2. **Monitor for issues** - Watch for any residual security concerns
+3. **Update security measures** - Implement additional controls if needed
+
+### Post-Incident Analysis
+
+1. **Root cause analysis** - Determine how incident occurred
+2. **Process improvement** - Update procedures to prevent recurrence
+3. **Team debriefing** - Gather lessons learned from all participants
+4. **Documentation updates** - Revise emergency procedures based on experience
+
+### Communication
+
+1. **Team notification** - Inform team when incident is resolved
+2. **Stakeholder updates** - Notify relevant parties as appropriate
+3. **Documentation** - Complete incident report for future reference
+
+## Emergency Contact Information
+
+### Security Team Contact
+
+- **Email**: [Security team email]
+- **Emergency escalation**: [24/7 emergency contact if available]
+- **Communication**: Use subject line format from emergency notification template
+
+### Internal Escalation
+
+- **Protocol leadership**: [Contact information]
+- **Technical team**: [Emergency technical contact]
+- **Legal/compliance**: [If regulatory notification required]
+
+## Related Documents
+
+- [Incident Reporting](/multisig-for-protocols/incident-reporting) - Formal incident reporting procedures
+- [Communication Setup](/multisig-for-protocols/communication-setup) - Backup communication channels
+- [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds) - Device replacement procedures
+- [Seed Phrase Management](/wallet-security/seed-phrase-management) - Key recovery procedures
+- [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec) - Account security measures
+
+---
+
+### PAGE: /wallet-security/secure-multisig-best-practices
+**Title:** Secure Multisig Best Practices | SEAL
+**Referenced by controls:** tro-1.1.2, tro-1.1.4, tro-2.1.1, tro-3.1.2, tro-3.1.3, tro-4.1.1, tro-4.1.2, tro-5.1.1, tro-5.1.2, tro-6.1.2
+
+# Secure Multisig Best Practices
+
+
+
+
+> Guidance for designing, operating, and auditing high-assurance multisigs. Use this as your single source for baseline
+> rules, setup guidance, and daily operations.
+
+## Who This Is For
+
+Advanced technical users, developers, Decentralized Autonomous Organizations (DAOs), and organizations responsible for
+managing protocol treasuries, smart contract ownership, or significant personal/collective assets.
+
+## Primary Goal
+
+The primary objective is to eliminate single points of failure and establish robust, distributed control over high-value
+assets and critical smart contract functions.
+
+## Core Concept: M-of-N Scheme
+
+A multisignature (multisig) wallet is a smart contract that requires a predefined minimum number of approvals `M` from a
+total set of authorized signers `N` to execute a transaction. This is known as an `M-of-N` scheme (e.g., 2-of-3,
+3-of-5).
+
+By distributing signing authority, a multisig ensures that the compromise of a single private key is insufficient to
+authorize the movement of funds or execute a privileged action.
+
+## General Rules
+
+### Thresholds & Configuration
+
+- Minimum of 3 signers
+- 50% signing threshold
+- 7+ signers for multisigs holding 1M+ in assets (USD equivalent)
+- Please see Classification Matrix in
+  [Planning & Classification](/multisig-for-protocols/planning-and-classification#step-3-classification-matrix)
+  for more information on threshold selection.
+- All signers must use hardware wallets
+- Multisigs managing assets on behalf of a DAO should set unlimited allowance with primary DAO agent
+- Signers on multisigs with critical protocol configuration or security roles are discouraged from using their
+addresses for other purposes. They should create a brand new wallet for that purpose instead.
+- All signing wallets should be monitored for any activity that is not directly related to multi-sig operations.
+- No multisigs should use modules/guards except those mentioned in
+[Setup & Configuration → Modules & Guards](/multisig-for-protocols/setup-and-configuration#modules--guards)
+unless clear justification and security review is provided
+- Threshold exceptions can be made for multisigs that are used in frequent operations but are highly constrained
+by smart contracts. For example, rate setting operations with tight bounds and a backup recovery mechanism to
+replace the multisig.
+
+#### Threshold Selection
+
+Avoid `N-of-N` schemes, as the loss of a single key would result in a permanent loss of access to all funds.
+
+#### Strategic Signer Distribution
+
+The security of a multisig depends entirely on the operational security (OpSec) of its individual signer keys. Storing
+multiple signer keys on the same device or in the same physical location negates the security benefits. Effective
+distribution strategies include:
+
+- Using different hardware wallet models and manufacturers.
+- Maintaining geographical separation for devices holding signer keys.
+- Assigning signer keys to different trusted individuals within an organization.
+- Using diverse client software to interact with the multisig to mitigate single-point-of-failure risks from a software
+vulnerability.
+
+#### Signer Composition Requirements
+
+- **Role Diversity**: Signers should be diverse individuals to reduce risk of multiple compromised accounts - a
+mix of executives, developers, and operational roles is recommended
+- **Technical Expertise**: Include a high number of competent, well-vetted technical signers that will understand full
+transaction details and effects in your signing quorum
+- **External Parties**: Multi-sigs managing high value wallets and contracts should have at least 1 additional required
+signer that is external to the organization (such as a security partner or trusted advisor)
+
+### Communication & Documentation
+
+- In the event of loss of access to keys or potential compromise of keys or communication channels, the signer must
+  immediately notify the other multisig participants and email your security contact - [Incident
+  Reporting](/multisig-for-protocols/incident-reporting)
+- Signers should use dedicated communication channels for multisig operations and maintain backup ways of reaching other
+  signers
+- All multisigs should be documented in the protocol documenting its purpose, general operating rules, multisig wallet
+  address, and list of signer addresses
+- Signers should verify their addresses by signing a message stating their affiliation and the multisig they intend to
+  join (entity affiliation is ok)
+
+#### Out-of-Band Verification for Admin Changes
+
+Any critical administrative action, such as adding or replacing a signer, must be verified through multiple, independent
+communication channels (e.g., a video call and a signed message) to prevent social engineering attacks.
+
+### Signer rotation
+
+- Signers can be rotated, but detailed documentation should be maintained
+- Any changes to signer composition should be documented in the protocol documentation
+- Any signer change should not reduce the number of signers or decrease the threshold unless clear justification is
+  given and documented
+
+#### Updating signer addresses
+
+If the original key is accessible:
+
+- The signer proves ownership of a new address by signing a message with their existing address.
+- The signer must follow the steps in
+[Signer Verification process](/multisig-for-protocols/registration-and-documentation#signer-verification-process)
+
+If the original key is lost:
+
+- The signer must verify their identity to the other signers through alternative methods such as:
+  - Authentication via a verified social media account.
+  - A video call with other signers for confirmation.
+  - Other sufficient methods.
+
+### Training & Drills
+
+- All signers should complete training as outlined in the
+[Implementation Checklist](/multisig-for-protocols/implementation-checklist)
+- For multisigs that perform emergency operations like pausing, teams should have processes to regularly conduct drills
+  to ensure operational readiness and signer availability
+
+## Setup Best Practices
+
+See General Rules above for thresholds and signer distribution guidance.
+
+- **Practice on Testnet:** Before deploying on mainnet, thoroughly practice wallet creation, transaction signing, and
+owner management on a test network.
+
+- **Timelocks:** Enforce a mandatory delay between the approval of a transaction and its execution. This provides a
+critical window for the community or team to detect and react to malicious proposals.
+
+- **Veto Quorum:** Establish a smaller veto group separate from the confirmation quorum to review and confirm
+transaction legitimacy. Organizations can establish veto quorums to bypass time-locks in case of emergency.
+The standard quorum plus two additional signers should be required to bypass.
+
+- **Role-Based Access Control (RBAC):** Implement modules that grant specific, limited permissions to certain addresses
+(e.g., a "pauser" or "executor" role) without making them full owners, adhering to the principle of least privilege.
+
+- **Disaster Recovery Plan:** Establish a clear, documented process for what to do when a signer is compromised, the
+multi-signature UI is down, or other emergencies arise. These should be done at regular intervals.
+
+## Operational Best Practices
+
+- **Signer Key Revocation and Replacement:** A  feature of multisigs is the ability to add, remove, or replace signer
+keys. If a signer's key is compromised or lost, it can be revoked and replaced with a new, secure key through a
+transaction approved by the remaining owners, preserving the integrity of the wallet's assets without needing to migrate
+funds.
+
+- **Secure Signing Environment:** For maximum security, all signing activities should be performed on a dedicated,
+air-gapped, or hardened device running a secure OS. Using a primary work laptop significantly increases the risk of
+malware interference.
+
+- **Independent Transaction Verification:**  Before signing, always verify the raw transaction data (target address,
+function call, parameters) to ensure it matches the intended operation.
+
+- **Out-of-Band Verification for Admin Changes:** Any critical administrative action, such as adding or replacing a
+signer, must be verified through multiple, independent communication channels (e.g., a video call and a signed message)
+to prevent social engineering attacks.
+
+- **Active Monitoring:** Implement monitoring and alerting systems to be immediately notified of any on-chain activity
+related to the multisig, including proposed transactions, new signatures, and owner changes (e.g., using tools like
+[Safe Watcher](https://github.com/Gearbox-protocol/safe-watcher) ).
+
+- **Documented Procedures:** Maintain clear, secure, and accessible documentation for all multisig procedures, including
+  transaction creation, signing, and emergency recovery plans.
+- **General Signing Guidelines:** Use hardware wallets, dedicated signing profiles, and re-verify before execution.
+  Require a "how to check" guide and communicate status after signing (e.g., "checked, signed, X more required"). Last
+  signer executes when applicable.
+
+## Contract-Level Security
+
+- **Invariant Enforcement:** Design contracts to enforce invariants and expected state changes such as token balance
+changes, ownership and administration, and proxy implementation addresses. Ensure contracts automatically revert
+transactions if any invariant is violated.
+
+- **Address Whitelisting:** Approved smart contract and wallet addresses must be added to a whitelist that is enforced
+at the contract-level. Interactions with all other addresses should be denied and revert the transaction. Updating the
+whitelist should require an extra signer in addition to the standard transaction approval quorum.
+
+For detailed configuration guidance, see
+[Setup & Configuration → Contract-Level Controls](/multisig-for-protocols/setup-and-configuration#contract-level-controls).
+
+## Acknowledgements
+
+Some ideas were borrowed from the [EF's multisig SOP notes](https://notes.ethereum.org/@fredrik/multisig-sop) and
+[Manifold Finance multisig best practices](https://hackmd.io/@manifoldx/multisig-best-practices).
+
+---
+
+---
+
+### PAGE: /treasury-operations/transaction-verification
+**Title:** Treasury Transaction Verification | SEAL
+**Referenced by controls:** tro-1.1.2, tro-1.1.3, tro-2.1.2, tro-3.1.1, tro-4.1.1, tro-4.1.2, tro-6.1.2, tro-8.1.1, tro-8.1.2
+
+TagList,
+  AttributionList,
+  TagProvider,
+  TagFilter,
+  ContributeFooter,
+} from "../../../components";
+
+
+
+
+# Guide: Large Cryptocurrency Transfers
+
+
+
+
+## Core Principles
+
+Large cryptocurrency transfers require rigorous verification because transactions are irreversible. This guide covers
+both receiving and sending significant amounts, with security measures scaling to transfer size.
+
+## Part 1: Receiving Large Transfers
+
+### Pre-Transfer Setup (48 Hours Before)
+
+#### Choose Appropriate Deposit Address
+
+The address strategy depends on your custody model:
+
+**For Institutional Custody** (Coinbase, Anchorage, BitGo):
+
+- **Always generate a fresh deposit address** for large incoming transfers
+- **Verify you're on the correct website** - check URL carefully, bookmark the official site, watch for phishing lookalikes
+- Use the platform's "offline deposit address" or "new address" function
+- **Why fresh addresses?** Prevents counterparties from viewing your entire treasury balance/history and isolates each
+  major transfer for clean audit trails
+
+**For Self-Custody Multisigs**:
+
+- **Use your established, proven multisig address** that has been successfully tested in prior transactions
+- **Never generate a fresh multisig for large transfers** - multisig setup is complex and a new deployment risks misconfiguration
+- The battle-tested multisig you've been using is safer than a newly created one
+- Document the multisig configuration: threshold (e.g., 3-of-5), signer addresses, and deployment transaction
+- Verify multisig configuration on block explorer before providing address to sender
+
+#### Address Verification Protocol
+
+Have 2-3 team members independently verify the address:
+
+```
+1. Retrieve address from custody platform or multisig interface
+2. Person A: Verify via custody UI or block explorer (multisig configuration)
+3. Person B: Independently verify via separate block explorer or multisig interface
+4. Perform checksum validation:
+   - Ethereum: EIP-55 checksum
+   - Bitcoin: Bech32 checksum
+5. For multisigs: Verify threshold and signer configuration match expected setup
+```
+
+**For transfers >$1M**: Require all verifiers to sign a document confirming they verified the address character-by-character.
+
+#### Bidirectional Test Transaction
+
+This should occur **24-48 hours before the main transfer**.
+
+**Phase 1: Sender → You (Incoming Test): **
+
+```
+1. Sender sends small amount (0.001 ETH or 0.0001 BTC) to your new address
+2. Verify receipt through multiple sources:
+   - Custody platform interface
+   - Primary block explorer (Etherscan, Blockchain.com)
+   - Secondary block explorer (redundancy check)
+3. Document transaction hash and confirmation time
+```
+
+**Phase 2: You → Sender (Outgoing Test): **
+
+```
+4. Send test amount BACK to another address you control
+5. You confirm you received the return transaction
+```
+
+**Why bidirectional?** Proves address can both receive AND withdraw funds before large transfer arrives, and confirms
+both parties control their stated addresses.
+
+#### Coordinate with Sender
+
+Provide via encrypted channel (PGP email or Signal):
+
+- Deposit address
+- Network specification (Ethereum mainnet chain ID 1, Bitcoin mainnet)
+- Test transaction hash (incoming only)
+- Video call scheduled time for live transfer
+
+Request from sender:
+
+- Source wallet addresses they'll send from
+- Approximate transfer timing: specific date and time window
+  - Example: "Tuesday, March 15th, 2:00-6:00 PM EST"
+  - This allows you to have all required personnel available and monitoring
+- Whether they'll use single or multiple transactions
+
+**Best practices for transaction splitting:**
+
+- **\<$10M**: Single transaction preferred (simpler, one confirmation cycle, cleaner records)
+- **\>$10M**: Consider 2-3 separate transactions (reduces single-transaction risk, allows staged confirmation, provides
+  pause points to verify each step)
+- **\>$50M**: Multiple transactions strongly recommended with 30-minute intervals between each
+**Anti-Duress Protocols:**
+
+Since kidnapping and other forms of duress have been employed by criminals to steal cryptocurrency, organizations should
+prepare for this. Establish a duress word that indicates a transfer is not being made of your own free will. Once the
+duress word is mentioned during an exchange involving the transfer, law enforcement will be contacted and the
+transaction not processed. Procedures should be put in place with concrete run books for these situations. Safe words
+should not appear in run books or any digital format.
+**Anti-Social-Engineering Protocols:**
+
+Establish code phrase during initial verified meeting. Use this phrase to authenticate any address changes or unusual
+requests. Example: "What was the name of the restaurant where we finalized the agreement?" Exchange secondary contact
+numbers for key personnel - if primary contact requests changes, call secondary to confirm. Maintain out-of-band
+verification: if request comes via email, confirm via phone.
+
+**Red flags that should trigger immediate verification:**
+
+- Urgent requests to bypass procedures or claims of "emergency"
+- Requests to send to "temporary" or "new" address without proper verification
+- Pressure to skip test transactions or any rushed requests
+
+If anything feels wrong, STOP and verify through multiple channels. Urgency is an attacker's favorite tool - legitimate
+counterparties will understand security delays.
+
+### Day of Transfer
+
+#### Pre-Transfer Video Verification (30 minutes prior to transfer)
+
+Require video call with minimum 2 _internal_ people present.
+
+**Liveness and identity verification** (prevents AI deepfakes):
+
+```
+1. Ask participant to hold up specific number of fingers (change unpredictably)
+2. Ask them to wave their hand in front of their face
+3. Request they state current date and time
+4. Reference specific details from previous conversations only real participant would know
+5. If anything seems off, halt the transfer and investigate
+```
+
+**Critical confirmations during call:**
+
+1. **Address Reconfirmation**
+
+   - Read deposit address character-by-character from your screen
+   - Sender confirms they see identical address on their screen
+   - **Critical: "Read ONLY from your custody platform or multisig interface (Safe, Zodiac, etc.)"**
+   - **Do NOT copy from email, Etherscan, any block explorer, or any intermediary source**
+   - **Only trust the address shown directly in your custody interface or multisig platform**
+   - For multisigs: State the configuration (e.g., "3-of-5 multisig at address 0x...")
+   - This prevents compromised email, address poisoning, and man-in-the-middle attacks from causing misdirection
+
+2. **Test Transaction Review**
+
+   - Display test transaction on block explorer during call
+   - Confirm sender sees same transaction hash
+   - Review the bidirectional test from 24-48 hours ago
+
+3. **Amount and Network**
+   - State total amount in native units and USD equivalent
+   - Confirm network explicitly: "Ethereum mainnet, chain ID 1" (not testnet, not L2)
+   - If ERC-20 tokens: State token name AND read out full contract address
+     - Example: "Sending 100,000 USDC, contract address 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"
+     - Verify contract address against official source (token website, CoinGecko) on call
+   - Confirm no mistakes in decimal places or token contract
+
+#### Live Monitoring
+
+**Understanding Blockchain Finality:**
+
+Wait for enough confirmations that a chain reorganization becomes economically infeasible or cryptographically impossible.
+
+**Monitoring phases:**
+
+```
+1. Transaction Broadcast: Appears in mempool, verify correct parameters
+2. First Confirmation: Included in a block
+3. Progressive Confirmations: Each block makes reversal exponentially harder
+4. Finality: Sufficient confirmations reached, transaction irreversible
+```
+
+**Confirmation requirements by chain:**
+
+- **Ethereum**: 2 epochs (~12.8 minutes)
+- **Bitcoin**: 6 confirmations (~60 minutes)
+- **Polygon**: 128 confirmations (~5 minutes)
+- **Solana**: ~12.8 seconds
+
+**On-call updates from Technical Operator:**
+
+- "Transaction in mempool, parameters correct"
+- "Block 1 confirmed, no anomalies"
+- "Block 12 confirmed, [X.XXX] ETH received and final"
+
+#### Dual Confirmation Requirement
+
+Before ending call, verify through TWO sources:
+
+1. Custody platform showing updated balance
+2. Block explorer showing confirmed transaction
+
+#### Post-Receipt Actions
+
+**Immediate (within 15 min):**
+
+- Document transaction hash, block number, timestamp
+- Record amount in native units and USD equivalent
+- Note all personnel involved
+
+**Within 30 minutes:**
+
+- Email confirmation to sender with transaction details
+
+## Part 2: Sending Large Cryptocurrency Transfers
+
+### Pre-Transfer Planning (72 Hours Before)
+
+#### Authorization
+
+Document and obtain approvals:
+
+- Purpose of transfer
+- Recipient verification
+- Amount and timeline
+- Required signatures based on amount:
+  - \<$100K: Treasury Manager
+  - $100K-$1M: CFO + Security Officer
+  - \>$1M: CFO + CEO
+
+#### Recipient Address Verification
+
+Multi-source verification is critical:
+
+```
+STEP 1: Receive address through official channel
+├─> Request via verified email/signed contract
+
+STEP 2: Independent verification through multiple sources (e.g., email, phone call)
+├─> At least two team members independently confirm the recipient address using different communication channels (such as verified email and a direct phone call with the recipient)
+
+STEP 3: Mandatory test transaction
+├─> Send $10-100 equivalent first
+├─> Wait for recipient confirmation
+├─> Recipient provides test transaction hash
+├─> Verify hash matches your outbound transaction
+└─> Proves recipient controls address and communications secure
+```
+
+**Never skip the test transaction.**
+
+#### Whitelist Addition (If Using Custody Platform)
+
+Most custody platforms support whitelisting:
+
+```
+1. Submit whitelist request with justification
+2. Wait mandatory cooling-off period:
+   - Standard: 24-48 hours
+   - High security: 72 hours
+3. Different team member approves whitelist addition
+4. Test transaction AFTER whitelist approval
+```
+
+**Why cooling-off periods?** Prevents attackers who gain account access from immediately adding malicious addresses and
+draining funds. Gives time for legitimate personnel to notice unauthorized changes.
+
+### Day of Transfer
+
+#### Final Verification Checklist (15 min before)
+
+Minimum 2 _internal_ people present, verify:
+
+```
+□ Authorization documentation signed
+□ Recipient address verified by 2 independent sources
+□ Test transaction confirmed successful by recipient
+□ Whitelist cooling-off period complete (if applicable)
+□ Exact amount confirmed (recipient expects this amount)
+□ Network confirmed (mainnet, not testnet)
+□ Sufficient balance in source wallet (amount + fees + buffer)
+□ All required approvers available next 60 minutes
+```
+
+**For transfers \>$1M**: Conduct formal video call with all approvers present.
+
+#### Execution Protocol
+
+**Video Call Requirements**:
+
+```
+1. Screen share custody interface or wallet
+2. Primary operator reads transaction parameters aloud:
+   - "Sending [X.XXXXX] ETH"
+   - "To address: 0x[read full address character-by-character]"
+   - "On network: Ethereum mainnet, chain ID 1"
+
+3. Each approver independently verifies on their device:
+   - Destination matches authorized recipient
+   - Amount matches approved transfer
+   - Network is correct
+
+4. Approvers use MFA to approve:
+   - Hardware security key, biometric, or authenticator app
+   - For multisigs: Each signer verifies transaction details on their signing device
+   - Verbally confirm: "I approve this transaction"
+
+5. Final approval triggers broadcast to blockchain
+```
+
+#### Post-Submission Monitoring
+
+Monitor transaction through finality:
+
+```
+1. Copy transaction hash from custody platform
+2. Enter into block explorer immediately
+3. Verify parameters match intended transaction
+4. Monitor confirmation progress:
+   - Ethereum: Wait for 12 confirmations (~3 minutes)
+   - Bitcoin: Wait for 6 confirmations (~60 minutes)
+5. Watch for recipient confirmation of receipt
+```
+
+#### Confirmation and Documentation
+
+After transaction reaches finality:
+
+```
+1. Internal record (within 15 min):
+   - Transaction hash and block number
+   - Timestamp and confirmation count
+   - Source wallet balance updated in records
+
+2. Request receipt from recipient (within 30 min):
+   - Formal acknowledgment they received funds
+
+3. Permanent documentation:
+   - Full transaction details (hash, block, timestamp, amount)
+   - Authorization chain (who approved, when)
+   - Personnel involved
+```
+
+---
+
+## Multi-Signature Best Practices
+
+See the Multisigs for Protocols guide.
+
+# TODO: Add link to Multisigs for Protocols guide. AFTER IT IS MERGED
+
+## Critical Risk Mitigations
+
+### Address Verification
+
+**Multisig and custody interface verification:**
+
+- Always verify addresses directly from your custody platform or multisig interface (Safe, Zodiac, etc.)
+- For multisigs: Cross-check configuration (threshold, signers) on block explorer
+- Never trust copy-pasted addresses from email or chat
+- Verify entire address character-by-character
+
+**Address poisoning defense:**
+
+- Never copy from transaction history
+- Always copy from authoritative source
+- Use custody platform address books when available
+
+### Communication Security
+
+**Email compromise prevention:**
+
+- Address confirmation during video call prevents MITM
+- Live verbal verification catches discrepancies
+- Code phrases for authentication
+
+**Social engineering defense:**
+
+- Never accept urgent bypass requests
+- Callback on known numbers to verify
+- Any request to skip verification triggers security review
+
+### Multi-Party Controls
+
+**Prevents single-actor fraud:**
+
+- Multiple personnel
+- Video recording of approvals
+- Separation of duties: requester ≠ approver ≠ technical executor
+
+### Transaction Parameter Security
+
+**Custody platform policy engines:**
+
+
+[... truncated ...]
+
+---
+
+### PAGE: /multisig-for-protocols/implementation-checklist
+**Title:** Multisig Implementation Checklist | SEAL
+**Referenced by controls:** tro-1.1.3, tro-4.1.3, tro-5.1.2, tro-7.1.2
+
+# Implementation Checklist
+
+
+
+
+This checklist ensures all multisig participants have the knowledge and skills necessary for secure operations. Complete
+all applicable sections before beginning multisig operations.
+
+## For Multisig Administrators
+
+### Planning & Setup
+
+- [ ] I have classified my multisig using the impact and operational framework from [Planning & Classification](/multisig-for-protocols/planning-and-classification)
+- [ ] I have selected appropriate thresholds based on the classification guidance
+- [ ] I have identified and verified all signers for the multisig
+- [ ] I have deployed the multisig with correct configuration
+- [ ] I have set up required modules (eg. allowance module to rescue assets)
+
+### Documentation & Communication
+
+- [ ] I have classified and documented the new multisig using templates from [Registration & Documentation](/multisig-for-protocols/registration-and-documentation)
+- [ ] I have set up primary and backup communication channels per [Communication Setup](/multisig-for-protocols/communication-setup)
+- [ ] I have tested emergency notification procedures
+- [ ] I have documented emergency contact information
+
+### Ongoing Management
+
+- [ ] I have established procedures for regular reviews and updates per [Registration & Documentation](/multisig-for-protocols/registration-and-documentation)
+- [ ] I have set up backup infrastructure and tested alternative UIs per [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)
+- [ ] I have verified all signers have completed training requirements
+- [ ] I understand signer rotation procedures for my multisig type
+
+## For Signers
+
+### Hardware & Security Setup
+
+- [ ] I have purchased recommended hardware wallet from authorized source per [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds)
+- [ ] I have set up my hardware wallet with proper firmware and PIN
+- [ ] I have created and tested backup hardware wallet with same seed
+- [ ] I have stored my seed phrase securely using approved methods from [Seed Phrase Management](/wallet-security/seed-phrase-management)
+- [ ] I have created dedicated accounts for each multisig I'm signing for
+
+### Operational Readiness
+
+- [ ] I have joined multisig communication channels (primary and backup) per [Communication Setup](/multisig-for-protocols/communication-setup)
+- [ ] I have verified my signer address using the required signature process from [Joining a Multisig](/multisig-for-protocols/joining-a-multisig)
+- [ ] I understand my multisig's classification and response time requirements
+- [ ] I have completed a test transaction with the multisig team
+
+### Transaction Verification
+
+- [ ] I can use approved verification tools (Safe CLI Utils, OpenZeppelin SafeUtils for EVM) from [Tools & Resources →
+  Transaction Verification](/wallet-security/tools-&-resources#transaction-verification)
+- [ ] I understand how to verify transaction hashes before signing
+- [ ] I can decode and verify transaction details (amounts, recipients, contract calls)
+- [ ] I have practiced verifying both simple transfers and complex transactions
+
+### Emergency Preparedness
+
+- [ ] I have downloaded backup UIs (Eternal Safe for EVM, Squads public client for Solana) per [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)
+- [ ] I know how to sign transactions when primary UI is down per [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)
+- [ ] I understand emergency procedures for key compromise and communication failures per [Emergency Procedures](/multisig-for-protocols/emergency-procedures)
+- [ ] I have tested backup communication methods with my team
+- [ ] I know who to contact for security incidents and emergencies per [Incident Reporting](/multisig-for-protocols/incident-reporting)
+
+### Personal Security
+
+- [ ] I have enabled 2FA on all accounts with approved methods (YubiKey preferred) per [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec)
+- [ ] I use dedicated devices or accounts for multisig operations when required
+- [ ] I have implemented travel security procedures appropriate for my risk level
+- [ ] I understand incident reporting procedures for security concerns
+
+### Compliance
+
+- [ ] I have read and understand all sections of this security framework
+- [ ] I understand my specific role requirements based on multisig classification
+- [ ] I know how to properly offboard when leaving a multisig role per [Offboarding](/multisig-for-protocols/offboarding)
+- [ ] I commit to following these security procedures and reporting any deviations
+
+## Specialized Training by Use Case
+
+### Emergency Response Multisigs
+
+Additional requirements from [Use Case Specific Requirements](/multisig-for-protocols/use-case-specific-requirements):
+
+- [ ] I understand 24/7 availability requirements
+- [ ] I have participated in emergency simulation drills
+- [ ] I know how to respond to emergency paging
+- [ ] I understand streamlined verification procedures for emergencies
+
+### Treasury Multisigs
+
+- [ ] I understand allowance module configuration and purpose
+- [ ] I know governance rescue procedures
+- [ ] I understand financial reporting requirements
+
+### Smart Contract Control Multisigs
+
+- [ ] I understand timelock configuration per [Use Case Specific Requirements → Timelock Configuration](/multisig-for-protocols/use-case-specific-requirements#timelock-configuration)
+- [ ] I know how to verify staged transactions
+- [ ] I understand higher threshold requirements for upgrades
+
+## Practical Skills Assessment
+
+### Transaction Verification (EVM)
+
+- [ ] I can successfully verify a Safe transaction hash using CLI tools
+- [ ] I can decode transaction calldata and identify recipients and amounts
+- [ ] I can identify risky transaction types and warnings
+- [ ] I can verify nested Safe transactions if applicable
+
+### Transaction Verification (Solana)
+
+- [ ] I can analyze Solana transaction instruction data
+- [ ] I can convert hex values to decimal for amount verification
+- [ ] I can identify different transaction types (SOL transfer, token transfer, config changes)
+
+### Emergency Procedures
+
+- [ ] I can access backup UIs and complete a transaction
+- [ ] I can contact team via backup communication channels
+- [ ] I know how to report key compromise immediately
+- [ ] I can execute identity verification procedures if needed
+
+### Tool Proficiency
+
+- [ ] I am comfortable using my hardware wallet for signing
+- [ ] I can navigate backup block explorers
+- [ ] I can use alternative RPC endpoints
+- [ ] I understand how to manually simulate transactions
+
+## Documentation Review
+
+### Required Reading Completed
+
+- [ ] [Secure Multisig Best Practices](/wallet-security/secure-multisig-best-practices) - Core requirements for all multisigs
+- [ ] [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds) - Device security requirements
+- [ ] [Seed Phrase Management](/wallet-security/seed-phrase-management) - Key protection procedures
+- [ ] [Safe Multisig: Step-by-Step
+Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification) - Signing procedures
+- [ ] [Emergency Procedures](/multisig-for-protocols/emergency-procedures) - Crisis response protocols
+- [ ] [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec) - Account and device security
+
+### Role-Specific Documentation
+
+**For Administrators:**
+
+- [ ] [Planning & Classification](/multisig-for-protocols/planning-and-classification)
+- [ ] [Setup & Configuration](/multisig-for-protocols/setup-and-configuration)
+- [ ] [Registration & Documentation](/multisig-for-protocols/registration-and-documentation)
+- [ ] [Communication Setup](/multisig-for-protocols/communication-setup)
+- [ ] [Registration & Documentation](/multisig-for-protocols/registration-and-documentation)
+
+**For Specialized Use Cases:**
+
+- [ ] [Use Case Specific Requirements](/multisig-for-protocols/use-case-specific-requirements)
+- [ ] [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)
+- [ ] [Use Case Specific Requirements → Timelock Configuration](/multisig-for-protocols/use-case-specific-requirements#timelock-configuration)
+  (if applicable)
+
+## Certification and Acknowledgment
+
+### Training Completion
+
+- [ ] I have completed all applicable training requirements
+- [ ] I have successfully demonstrated practical skills
+- [ ] I understand the security implications of my role
+- [ ] I acknowledge my responsibilities as a multisig participant
+
+### Ongoing Commitment
+
+- [ ] I commit to following all security procedures outlined in this framework
+- [ ] I will report any security incidents or concerns promptly
+- [ ] I will participate in regular training updates and refreshers
+- [ ] I will maintain the required level of security for my role
+
+### Trainer Verification (if applicable)
+
+**For organizations requiring formal training:**
+
+Trainer: _________________ Date: _________________
+
+Trainee has demonstrated competency in:
+
+- [ ] Transaction verification procedures
+- [ ] Emergency response protocols
+- [ ] Security best practices
+- [ ] Role-specific requirements
+
+**Signature:** _________________
+
+## Refresher Training Schedule
+
+### Regular Updates
+
+- **Monthly**: Review emergency procedures and contact information
+- **Quarterly**: Practice backup system usage and emergency drills
+- **Annually**: Complete full framework review and updates
+- **As needed**: Training on new tools, procedures, or threats
+
+### Trigger Events
+
+Additional training required after:
+
+- Framework updates or changes
+- Security incidents affecting the team
+- New tool adoption
+- Role changes or additional responsibilities
+
+## Related Documents
+
+All documents in this framework serve as training materials. Refer to individual documents for detailed procedures and
+requirements specific to your role.
+
+---
+
+### PAGE: /multisig-for-protocols/setup-and-configuration
+**Title:** Multisig Setup & Configuration | SEAL
+**Referenced by controls:** tro-1.1.4
+
+# Setup & Configuration
+
+
+
+
+This page covers the technical deployment and configuration of multisigs on supported networks.
+
+## Basic Setup
+
+### EVM Networks (Ethereum, Base, etc.)
+
+1. Go to [https://app.safe.global](https://app.safe.global)
+2. Connect wallet of the deploying signer
+3. Create new Safe with your determined threshold and signer addresses
+4. **Multi-network deployment**: If deploying on multiple networks, Safe UI will offer to replicate the configuration
+
+### Solana
+
+1. Go to [https://squads.xyz/squads-multisig](https://squads.xyz/squads-multisig)
+2. Connect wallet of the deploying signer
+3. Create new multisig with your determined threshold and signer addresses
+
+## Self-Hosted Multisig UI
+
+Multi-sig coordination UIs should be self-hosted to eliminate supply chain risk. Hosted UI should be IP restricted to
+allow access only from signer machines.
+
+Deploy from [Safe Wallet Monorepo](https://github.com/safe-global/safe-wallet-monorepo/tree/dev/apps/web).
+While it should not be your final line of defense, securing the UI does protect your verification process
+from being compromised by supply-chain attacks.
+
+For emergency situations when the primary UI is unavailable, see
+[Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure).
+
+## Delegated Proposer
+
+It is recommended, but not required to authorize a separate transaction proposer for a Safe. This address can prepare
+transactions for signers to sign but is not an authorized signer on the Safe. Therefore **there is no risk of malicious
+signatures which can affect the Safe assets**. This wallet can hold no funds and simply act as a proposer. The primary
+reason to have a delegated proposer is that the hash verification utilities depend on the Safe API (unless details are
+entered manually). Until a transaction is **proposed** it does not show up in the API so the hash verification tools
+cannot detect it.
+
+![Delegated proposer configuration interface](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/delegated-proposer-configuration-interface.png)
+
+## Modules & Guards
+
+### Allowance Module (Required for Treasury Multisigs)
+
+If your multisig will hold any assets on behalf of the DAO, set up governance rescue capability:
+
+**Mainnet configuration:**
+
+- **Module**: Allowance Module
+- **Grant allowance to**: DAO Agent
+- **Amount**: Max value for each token held
+
+### Zodiac Delay Modifier (Time-Locks)
+
+Consider using [Zodiac Modifier Delay](https://github.com/gnosisguild/zodiac-modifier-delay/tree/main) or equivalent
+for implementing on-chain time-lock transaction delays to Safe wallets.
+
+See [Use Case Specific Requirements](/multisig-for-protocols/use-case-specific-requirements#timelock-configuration)
+for detailed timelock configuration guidance.
+
+### Other Modules
+
+Do not install any other modules or guards without explicit governance approval and security review.
+
+## Contract-Level Controls
+
+**Advanced Configuration Warning:** The following contract-level controls are advanced security features that can
+provide additional protection but require careful implementation. Before implementing any guards or modules:
+
+- **Conduct thorough research** on available guard implementations and their compatibility with your multisig setup
+- **Ensure all guards are well-audited** by reputable security firms before deployment
+- **Test extensively** on testnets to verify functionality and edge cases
+- **Understand the risks**: Incorrect configuration or incompatible guards can render your multisig unusable,
+potentially locking access to funds permanently
+
+### Address Whitelisting
+
+Approved smart contract and wallet addresses must be added to a whitelist that is enforced at the contract-level.
+Interactions with all other addresses should be denied and revert the transaction. Updating the whitelist should
+require an extra signer in addition to the standard transaction approval quorum.
+
+### Invariant Enforcement
+
+Design contracts to enforce invariants and expected state changes such as token balance changes, ownership and
+administration, and proxy implementation addresses. Ensure contracts automatically revert transactions if any
+invariant is violated.
+
+## Initial Testing
+
+### Verify Basic Functionality
+
+1. **Small test transaction**: Send a low-value token transfer (e.g., 1 USDS or equivalent)
+2. **All signers test**: Ensure each signer can successfully sign the test transaction
+3. **Confirm execution**: Verify the transaction executes as expected
+4. **Test communication**: Use your established channels to coordinate the test
+
+## Pre-Launch Checklist
+
+- [ ] Safe deployed with correct threshold
+- [ ] All signer addresses added and [verified](/multisig-for-protocols/registration-and-documentation#signer-verification-process)
+- [ ] Allowance module configured (if required)
+- [ ] Test transaction completed successfully
+- [ ] All signers confirmed they can sign
+- [ ] [Communication channels](/multisig-for-protocols/communication-setup) tested during transaction
+- [ ] Safe addresses documented for all networks
+
+### Practice on Testnet
+
+Before deploying on mainnet, thoroughly practice wallet creation, transaction signing, and owner management on
+a test network.
+
+Once setup is complete, proceed to [Registration &
+Documentation](/multisig-for-protocols/registration-and-documentation) for registration and documentation requirements.
+
+## Nested Safes
+
+A nested Safe is one in which a Safe is set as a signer on another Safe rather than an EOA. This can be useful on a
+case-by-case basis. For example, if a signer is an entity that might want to have multiple individual signers, the
+nested Safe could have a 1/X threshold allowing anyone authorized on the team to sign. However, this configuration
+allows the signers on the nested Safe to update the signer addresses without needing authorization from the main Safe.
+
+It is generally recommended **not** to use nested safe on protocol multisigs unless there is a specific use case that
+it enables.
+
+## Next Steps
+
+After completing setup:
+
+1. [Registration & Documentation](/multisig-for-protocols/registration-and-documentation) - Document your multisig
+2. [Communication Setup](/multisig-for-protocols/communication-setup) - Establish secure communication
+3. [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds) - Ensure all signers are properly configured
+
+## Active Monitoring
+
+Implement monitoring and alerting systems to be immediately notified of any on-chain activity related to the multisig,
+including proposed transactions, new signatures, and owner changes (e.g., using tools like [Safe
+Watcher](https://github.com/Gearbox-protocol/safe-watcher)).
+
+### Immutable Monitoring Channels
+
+Monitoring channels (e.g. email, Slack or Telegram chats) must be immutable (or trigger alerts when their configuration
+changes or logs are deleted/tampered with) and redundant such that an admin could not disable or tamper with one
+monitoring channel without generating an alert on the other channel.
+
+---
+
+### PAGE: /treasury-operations/classification
+**Title:** Treasury Security Classification | SEAL
+**Referenced by controls:** tro-2.1.1, tro-2.1.2, tro-8.1.1, tro-8.1.2
+
+TagList,
+  AttributionList,
+  TagProvider,
+  TagFilter,
+  ContributeFooter,
+} from "../../../components";
+
+
+
+
+# Custodial Treasury Security: Classification Framework
+
+
+
+
+Proper documentation and classification of custodial accounts is essential for institutional treasury security. This
+guide focuses on the security assessment and classification framework for crypto assets held with third-party
+custodians.
+
+> See also: [Registration Documents](./registration-documents) and [Enhanced Controls for High-Risk Accounts](./enhanced-controls)
+
+## Classification Process
+
+Use this dual classification to determine appropriate security controls for each custodial account.
+
+### Step 1: Impact Assessment
+
+Evaluate the consequences if this account is compromised or unavailable.
+
+#### Financial Impact
+
+Calculate the total value at risk in this account:
+
+- Current market value of all assets held
+- Include value of any active positions (e.g., staked assets, DeFi deposits)
+- What is the financial impact if unavailable for 7 days?
+
+#### Operational Impact
+
+Assess the consequences if this account becomes unavailable:
+
+- What specific operations require this account?
+- Do you have a secondary custody account that can handle these operations?
+- What is the reputational impact if this account is compromised or unavailable?
+
+#### Regulatory Impact
+
+Evaluate regulatory and compliance consequences:
+
+- Are assets in this account subject to regulatory reporting requirements (SEC filings, audit requirements)?
+- Does this account hold regulated assets (e.g., stablecoins subject to reserves reporting)?
+- What are the regulatory deadlines that could be missed if this account is unavailable?
+
+#### Impact Classification
+
+| Level        | Financial Exposure (% of Total Assets) | Operational Dependency                       | Regulatory Impact                                    |
+| ------------ | -------------------------------------- | -------------------------------------------- | ---------------------------------------------------- |
+| **Low**      | \<1%                                   | No critical operations depend on it          | No regulatory reporting tied to this account         |
+| **Medium**   | 1% - 10%                               | Important but alternative funding available  | Periodic reporting; delays manageable                |
+| **High**     | 10% - 25%                              | Critical operations, limited alternatives    | Regular regulatory filings; delays cause violations  |
+| **Critical** | \>25%                                  | Business-critical, no alternatives for weeks | Real-time reporting requirements; SEC filings; audit |
+
+### Step 2: Operational Assessment
+
+Evaluate how frequently and urgently this account must be accessed.
+
+#### Transaction Frequency
+
+Document typical transaction patterns:
+
+- Transactions per month
+- Typical transaction sizes
+- Predictability of transaction timing
+
+#### Access Urgency
+
+Define response time requirements:
+
+- What is the maximum acceptable delay for routine transactions?
+- Are there scenarios requiring same-day execution?
+- What are the consequences of 24-hour, 72-hour, or 7-day delays?
+
+#### Coordination Requirements
+
+Assess how transactions are executed:
+
+- How many approvers are needed for typical transactions?
+- Are transactions handled manually or through automated systems?
+- Do approvers need to coordinate across timezones?
+
+Note: Single-approver configurations should only be used for low-value operational accounts (\<0.1%) with additional
+compensating controls like strict spending limits and daily reconciliation.
+
+#### Operational Classification
+
+| Type                  | Frequency     | Response Window | Example Use Cases                                  |
+| --------------------- | ------------- | --------------- | -------------------------------------------------- |
+| **Cold Vault**        | \<5 tx/month  | 48-72 hours     | Long-term reserves, infrequent rebalancing         |
+| **Warm Storage**      | 5-50 tx/month | 4-24 hours      | Scheduled payments, planned operations             |
+| **Active Operations** | \>50 tx/month | \<4 hours       | Trading capital, frequent operational expenses     |
+| **Time-Critical**     | Unpredictable | \<2 hours       | Collateral management, market-sensitive operations |
+
+### Step 3: Security Control Matrix
+
+Combine impact and operational assessments to determine required controls.
+
+| Use Case | Impact | Operational | Approvers | MFA Requirement | Whitelist Delay | Additional Controls |
+| --- | --- | --- | --- | --- | --- | --- |
+| Payments | Low | Active Ops | 2 | Standard TOTP | 6 hours | **Baseline (all accounts):** Dedicated devices for custody access, address whitelisting enabled, test small amount to new addresses before full transaction, transaction simulation. **Low-specific:** Per-transaction cap, monthly aggregate limit |
+| Operational Wallet | Medium | Active Ops | 2 | Hardware required | 12 hours | All Low controls + daily transaction caps, weekly reconciliation, monthly audit |
+| Liquidation Protection | Medium-High | Time-Critical | 2 | Hardware required | None | All Low/Medium controls + automated alerts for position health, real-time monitoring |
+| DeFi Positions | Medium-High | Warm Storage | 3 | Hardware mandatory | 24 hours | All Low/Medium controls + smart contract whitelist, position monitoring, daily reconciliation |
+| Trading Capital (variable) | High | Active Ops | 3 | Hardware mandatory | 6 hours | All Low/Medium controls + smart contract whitelist, real-time monitoring, daily reconciliation |
+| Active Treasury (5-10%) | High | Warm Storage | 3-4 | Hardware mandatory | 24 hours | All Low/Medium controls + transaction velocity limits, SIEM monitoring, multi-channel confirmation |
+| Secondary Reserve (10-25%) | Critical | Cold Vault | 4-5 | Hardware mandatory | 48 hours | All Low/Medium/High controls + geographic distribution of approvers, MPC recommended |
+| Primary Reserve (>25% assets) | Critical | Cold Vault | 5-7 | Hardware mandatory | 72 hours | All Low/Medium/High controls + geographic distribution of approvers, MPC recommended |
+
+### Step 4: Document Your Decision
+
+- Record impact level and operational type with justification
+- Capture approver thresholds and required controls
+- Store links to relevant custody accounts and addresses
+
+Proceed to: [Registration Documents](./registration-documents)
+
+For Critical/High accounts, ensure you also review: [Enhanced Controls for High-Risk Accounts](./enhanced-controls)
+
+---
+
+### PAGE: /treasury-operations/registration-documents
+**Title:** Custodial Account Registration | SEAL
+**Referenced by controls:** tro-3.1.1, tro-3.1.3
+
+TagList,
+  AttributionList,
+  TagProvider,
+  TagFilter,
+  ContributeFooter,
+} from "../../../components";
+
+
+
+
+# Registration Documents
+
+
+
+
+Use these standardized templates to register custodial accounts, track access changes, document security configurations,
+and perform quarterly reviews.
+
+> See also: [Classification Framework](./classification) and [Enhanced Controls for High-Risk Accounts](./enhanced-controls)
+
+---
+
+## Registration Template
+
+Use this template when initially documenting a custodial account.
+
+```
+CUSTODIAL ACCOUNT REGISTRATION
+
+Account Name: [Descriptive name]
+Custodian: [Provider name and legal entity]
+Account ID: [Custodian reference number]
+Network(s): [Bitcoin, Ethereum, etc.]
+Registration Date: YYYY-MM-DD
+Registered By: [Name]
+
+CLASSIFICATION
+Impact Level: [Low / Medium / High / Critical]
+Operational Type: [Cold Vault / Warm Storage / Active Operations / Time-Critical]
+
+Justification:
+- Financial exposure: $XXX,XXX,XXX
+- Operational dependency: [Description]
+- Recovery time objective: [X hours/days]
+
+ASSETS CONTROLLED
+Asset   | Network  | Value     | Purpose
+--------|----------|-----------|------------------------------
+BTC     | Bitcoin  | $XXX,XXX  | [Reserve/Trading/Operations]
+ETH     | Ethereum | $XXX,XXX  | [Reserve/Trading/Operations]
+USDC    | Ethereum | $XXX,XXX  | [Reserve/Trading/Operations]
+
+CUSTODY MODEL
+Type: [Qualified Custodian / Co-managed / MPC Platform]
+Key Management: [MPC 3-of-5 / Multi-sig 2-of-3 / HSM]
+Key Control: [Custodian only / Co-managed / Client-controlled]
+Recovery Capability: [Yes - describe / No]
+
+INITIAL ACCESS SETUP
+Primary Administrator: [Name, added YYYY-MM-DD]
+Initial Approvers: [Names, added YYYY-MM-DD]
+
+Note: Complete access details documented in Access Change Template
+Note: Security configuration documented in Security Configuration Template
+
+ATTESTATION
+This account [meets / deviates from] security standards for its classification.
+
+[If deviation: Explain gap and compensating controls]
+
+CONTACTS
+Security Owner: [Name, email, phone]
+Backup Contact: [Name, email, phone]
+Custodian Support: [Name, email, phone]
+
+Last Updated: YYYY-MM-DD
+Updated By: [Name]
+```
+
+---
+
+## Access Change Template
+
+Use this template when modifying user access to a custodial account.
+
+```
+CUSTODIAL ACCOUNT ACCESS CHANGE
+
+Account Name: [Name]
+Custodian: [Provider]
+Account ID: [Reference]
+Change Date: YYYY-MM-DD
+Changed By: [Name]
+
+ACCESS MODIFICATIONS
+
+Additions:
+Name/Role | Access Level | MFA Method     | Justification
+----------|--------------|----------------|------------------------------
+[Name]    | [Approver]   | [Hardware key] | [Reason for addition]
+
+Removals:
+Name/Role | Access Level | Removal Reason
+----------|--------------|-------------------------------
+[Name]    | [Approver]   | [Personnel change / Security / Other]
+
+Permission Changes:
+Name/Role | Old Level | New Level | Justification
+----------|-----------|-----------|---------------------------
+[Name]    | [Initiator] | [Approver] | [Reason for elevation]
+
+CURRENT ACCESS LIST (after changes)
+Name/Role | Level     | MFA Method    | Device ID
+----------|-----------|---------------|---------
+[Name]    | Admin     | Hardware key  | [ID]
+[Name]    | Approver  | Hardware key  | [ID]
+[Name]    | Approver  | Hardware key  | [ID]
+[Name]    | Initiator | TOTP          | [ID]
+
+VERIFICATION
+[ ] All removed users confirmed deactivated in custodian platform
+[ ] All new users completed MFA setup
+[ ] Access permissions tested and verified
+[ ] Emergency contacts updated
+[ ] Documentation updated in [location]
+
+APPROVALS
+Requested By: _________________ Date: _______
+Approved By: _________________ Date: _______
+Security Review: _________________ Date: _______
+
+Change Ticket: [Reference number if applicable]
+```
+
+---
+
+## Security Configuration Template
+
+Use this template to document detailed security settings. Complete this after initial account registration.
+
+```
+CUSTODIAL ACCOUNT SECURITY CONFIGURATION
+
+Account: [Name]
+Custodian: [Provider]
+Last Configuration Update: YYYY-MM-DD
+Configured By: [Name]
+
+AUTHENTICATION SETTINGS
+
+Multi-Factor Authentication:
+Role | Primary Method | Backup Method | Enrollment Status
+Administrator | Hardware key + biometric | Hardware key + PIN | [Active]
+Approver | Hardware key | TOTP + SMS | [Active]
+Initiator | Hardware key or TOTP | SMS | [Active]
+Viewer | TOTP | SMS | [Active]
+
+Session Controls:
+- Timeout: [X minutes]
+- Re-auth required for: [High-value transactions, policy changes, user management]
+- Concurrent sessions: [Allowed/Blocked]
+
+ACCESS CONTROL
+
+Current User List:
+Name/Role | Level    | MFA Method   | Device ID | Added Date
+----------|----------|--------------|----------|------------
+[Name]    | Admin    | Hardware key | [ID]     | YYYY-MM-DD
+[Name]    | Approver | Hardware key | [ID]     | YYYY-MM-DD
+[Name]    | Approver | Hardware key | [ID]     | YYYY-MM-DD
+
+Note: Track all access changes using Access Change Template
+
+Approval Thresholds:
+Transaction Value (% of Total Assets) | Required Approvers | Time Delay | Additional Requirements
+<0.1%          | 1 | None       | MFA
+0.1% - 1%   | 3 | 4 hours    | MFA
+1% - 10%    | 4 | 24 hours   | Multi-channel confirmation, test transaction
+10% - 25%    | 5 | 24 hours   | Multi-channel confirmation, test transaction
+>25%           | 7 | 48 hours   | Multi-channel confirmation, test transaction
+
+Separation of Duties:
+[ ] Initiators cannot approve own transactions
+[ ] Admins cannot unilaterally execute withdrawals
+[ ] Minimum [X] unique approvers required
+
+NETWORK RESTRICTIONS
+
+IP Whitelist:
+XXX.XXX.XXX.XXX - [Office Location]
+XXX.XXX.XXX.XXX - [VPN Range]
+XXX.XXX.XXX.XXX - [Backup Location]
+
+Change Approval: [24 hour delay / XX approvers required]
+Emergency Override: [Process description]
+
+VPN Requirement: [Mandatory / Optional]
+Geographic Restrictions: [Blocked countries/regions]
+Device Fingerprinting: [Enabled / Disabled]
+
+TRANSACTION POLICIES
+
+Address Whitelisting:
+Status: [Enabled / Disabled]
+Current Addresses: [XX addresses]
+Addition Process: [XX approvers, YY hour delay]
+Review Schedule: [Monthly / Quarterly]
+
+Transaction Limits:
+Limit Type        | Amount   | Override Process
+------------------|----------|-----------------
+Single Transaction | $XXX,XXX | [Authorization required]
+Hourly Aggregate   | $XXX,XXX | [Authorization required]
+Daily Aggregate    | $XXX,XXX | [Authorization required]
+Weekly Aggregate   | $XXX,XXX | [Authorization required]
+Monthly Aggregate  | $XXX,XXX | [Authorization required]
+
+Time-Lock Settings:
+Change Type                          | Delay Period
+-------------------------------------|-------------
+New address addition                 | XX hours
+Policy modification                  | XX hours
+High-value transaction (>$XXX,XXX)   | XX hours
+
+MONITORING & ALERTS
+
+Real-Time Alerts:
+Type                       | Enabled
+---------------------------|--------
+All outgoing transactions  | [ ]
+New device login           | [ ]
+Failed authentication attempts (>X) | [ ]
+Policy violations          | [ ]
+Large transactions (>$XXX,XXX) | [ ]
+Unusual access times       | [ ]
+New geographic location    | [ ]
+
+Alert Routing:
+Severity | Contact         | Method       | Response Time
+---------|------------------|-------------|--------------
+Critical | [Name, phone]   | SMS + Call   | <15 min
+High     | [Name, phone]   | SMS + Email  | <1 hour
+Medium   | [Name, email]   | Email        | <4 hours
+
+VERIFICATION
+[ ] All settings tested and operational
+[ ] Alert routing verified
+[ ] User access confirmed
+[ ] Documentation stored in [location]
+
+Configured By: _________________ Date: _______
+Reviewed By: _________________ Date: _______
+Approved By: _________________ Date: _______
+```
+
+---
+
+## Quarterly Review Template
+
+Use this template for regular security reviews of custodial accounts.
+
+```
+CUSTODIAL ACCOUNT QUARTERLY REVIEW
+
+Account: [Name]
+Custodian: [Provider]
+Review Period: [Q1/Q2/Q3/Q4 YYYY]
+Review Date: YYYY-MM-DD
+Reviewed By: [Name]
+
+ACCESS AUDIT
+
+Current Users:
+Name/Role | Level | Last Login | MFA Status | Action Required
+[Name] | Admin | YYYY-MM-DD | Active | None
+[Name] | Approver | YYYY-MM-DD | Active | None
+[Name] | Approver | Never logged in | Inactive | Remove access
+
+Access Changes This Quarter: [X additions, Y removals, Z modifications]
+
+Findings:
+[ ] All users still require current access level
+[ ] No dormant accounts (>90 days inactive)
+[ ] MFA functioning for all users
+[ ] No unauthorized access detected
+
+Actions Required:
+- [List any access to be removed/modified]
+- [List any policy updates needed]
+
+TRANSACTION REVIEW
+
+Transaction Volume:
+- Total transactions: [X]
+- Average per month: [Y]
+- Largest transaction: $XXX,XXX
+- Total outflow: $XXX,XXX
+
+Pattern Analysis:
+[ ] Transactions within expected parameters
+[ ] No unusual transaction patterns detected
+[ ] All large transactions properly authorized
+[ ] Test transactions performed correctly
+
+Anomalies Detected:
+- [List any unusual activity or violations]
+
+SECURITY CONFIGURATION
+
+Whitelist Review:
+- Current addresses: [X]
+- Addresses added this quarter: [Y]
+- Addresses to remove: [Z]
+- Review complete: [Yes/No]
+
+Spending Limits:
+Current | Actual Usage | Status
+Single: $XXX,XXX | Max: $XXX,XXX | [Appropriate / Adjust]
+Daily: $XXX,XXX | Avg: $XXX,XXX | [Appropriate / Adjust]
+Monthly: $XXX,XXX | Avg: $XXX,XXX | [Appropriate / Adjust]
+
+Findings:
+[ ] Limits appropriate for current usage
+[ ] No limit breaches this quarter
+[ ] IP whitelist current and accurate
+[ ] Time-locks functioning properly
+
+ALERT EFFECTIVENESS
+
+Alerts This Quarter:
+Type | Count | False Positive Rate
+Critical | [X] | [Y%]
+High | [X] | [Y%]
+Medium | [X] | [Y%]
+
+Response Times:
+Severity | Target | Actual Average | Status
+Critical | <15 min | [X min] | [Met/Missed]
+High | <1 hour | [X min] | [Met/Missed]
+Medium | <4 hours | [X hours] | [Met/Missed]
+
+Findings:
+[ ] Alert routing working correctly
+[ ] Response times meeting SLAs
+[ ] No missed critical alerts
+
+Actions Required:
+- [Adjust alert thresholds if needed]
+- [Update contact information]
+
+CUSTODIAN RELATIONSHIP
+
+SOC Reports: [Current / Expired - date]
+Security Incidents: [Any custodian-wide incidents this quarter]
+Service Quality: [Any issues or concerns]
+Communication: [Regular contact maintained]
+
+RISK ASSESSMENT UPDATE
+
+Classification Review:
+Current: [Impact Level / Operational Type]
+Still Appropriate: [Yes / No]
+
+If No, Recommended Change:
+New Classification: [Level / Type]
+Justification: [Explain change in risk profile]
+
+Asset Value Change: [% increase/decrease]
+Operational Change: [Any significant changes in usage]
+
+RECOMMENDATIONS
+
+Security Improvements:
+1. [Recommendation]
+2. [Recommendation]
+3. [Recommendation]
+
+Operational Improvements:
+1. [Recommendation]
+2. [Recommendation]
+
+ATTESTATION
+
+This account [continues to meet / deviates from] security standards.
+
+[If deviation: Describe and provide remediation plan]
+
+APPROVALS
+
+Reviewer: _________________ Date: _______
+Security Officer: _________________ Date: _______
+Treasury Lead: _________________ Date: _______
+
+Next Review Due: YYYY-MM-DD
+```
+
+---
+
+---
+
+### PAGE: /multisig-for-protocols/personal-security-opsec
+**Title:** Multisig Personal Security (OpSec) | SEAL
+**Referenced by controls:** tro-3.1.2, tro-3.1.4
+
+# Personal Security (OpSec)
+
+
+
+
+## Account Security
+
+### Basic requirements
+
+- 2FA enabled on all accounts (authenticator apps or hardware keys)
+- Password manager with unique, strong passwords for every account
+- Remove phone numbers from account recovery options where possible
+- Regular security checkups and removal of unused app permissions
+- Backup email for account recovery (separate from primary email)
+
+### For extra security
+
+**YubiKeys**: Use hardware security keys instead of authenticator apps
+
+- Provides stronger protection against phishing and SIM swapping
+- Recommended: 3 keys (primary, backup, secure storage)
+- Models: YubiKey 5C NFC, YubiKey 5C Nano
+
+**Cold backup accounts**: Separate email/phone for sensitive account recovery
+
+- Backup / cold accounts are tied to sensitive accounts (AppleID, Telegram, Signal, WhatsApp, Password Manager etc).
+  Such email addresses must never be shared with anyone and kept private to remain secure and not targeted.
+
+Example: random44@gmail is tied to your AppleID, and you are only logged in (the email) on a separate secure device. If
+your main device (laptop) gets compromised, you will be able to recover your account or revoke sessions, moreover your
+cold account won't be affected / compromised. It prevents people from targeting your accounts by not knowing your email
+linked to it.
+
+- Use different providers from primary accounts (Gmail, Proton)
+- Only access from secure devices
+- Never used for regular communications
+
+## Device Security
+
+### Basic requirements
+
+- Full disk encryption enabled (FileVault/BitLocker)
+- Automatic updates enabled on all devices
+- Screen lock after 5 minutes inactivity on computers, 30 seconds on mobile
+- Strong passcodes (6+ digits or alphanumeric on mobile)
+- Endpoint protection software on computers
+- No admin rights for daily use accounts (create separate admin account)
+
+### For extra security
+
+**Dedicated signing device**: Clean laptop/tablet used only for multisig operations
+
+- Minimal software installation
+- Regular security updates
+- Clean restart before each use
+- Offline storage when not in use
+- Justification: Reduces attack surface for high-value operations
+
+## Network Security
+
+### Dedicated Signing Machines
+
+- Multi-sig operations must be performed on devices dedicated only to these transactions and verification tools
+- All network access should be default blocked, with only the minimum necessary IPs to execute these transaction
+signatures allowed
+- Signing devices must be operated on private, authenticated networks or over trusted VPNs
+
+### Air-Gapped Machine Options
+
+- For highest security, physically remove or disable the network interface
+- Use USB drives (with strict auto-run restrictions) or QR codes to transfer transaction data
+
+### Advanced OS-Level Controls
+
+- Consider employing SELinux or similar tools for advanced security configurations
+- Restrict file system access and inter-process communications
+
+### Network Monitoring Tools
+
+Organizations must implement active network monitoring on signing devices:
+
+- [Little Snitch](https://www.obdev.at/products/littlesnitch/index.html) for active firewall and network monitoring
+- [Lulu](https://objective-see.org/products/lulu.html) as a free, open source alternative to Little Snitch
+- [Glasswire](https://www.glasswire.com/) can be used for Windows machines
+
+### DNS Security
+
+Use [DeFi DNS Whitelist](https://github.com/0xKoda/defi-dns-whitelist/tree/main) as a firewall for dedicated signing machines.
+
+## Communication Security
+
+### Basic requirements
+
+**Signal with verified safety number verification** for multisig communications: You MUST check the codes with the
+person you are interacting to « verify » them.
+How? Click on any chat > Contact name > View Safety Number > Call on another communication channel to verify them >
+Click at the bottom "Mark as Verified".
+If the account connects on a new device these codes will change & you will receive a security notification.
+
+- Screen lock enabled on mobile devices
+- 2FA enabled on backup platforms (Telegram/Discord/Slack)
+- Privacy settings maximized on all platforms
+- Session management - remove old/unknown devices regularly
+
+### Signal configuration
+
+- Registration lock enabled
+- Signal PIN configured
+- Hide phone number (use username only)
+- Safety number verification for all contacts
+- Disappearing messages for sensitive chats
+
+### URL Navigation Safety
+
+Links to URLs containing transaction requests or confirmation data (even those provided by trusted parties) must never
+be clicked - they must be navigated to by using bookmarks or typing them out manually.
+
+### For extra security
+
+**Enhanced verification**: Advanced safety procedures for critical communications
+
+- Code words for identity verification
+- Multiple verification channels for important requests
+- Regular communication channel security audits
+
+## Travel considerations
+
+### What to bring
+
+- Primary hardware wallet only (leave backups secure at home)
+- Essential devices only (laptop + phone)
+- Emergency contact information (offline copy)
+- Own chargers and cables
+
+### What NOT to bring
+
+- Seed phrases (never travel with these)
+- Backup hardware wallets
+- USB drives with sensitive data
+- Non-essential devices
+
+### Basic travel security
+
+- Use device locks at all times
+- Avoid public WiFi (use mobile hotspot or VPN)
+- Don't leave devices unattended in hotel rooms
+- Use hotel safes for device storage when out
+- Have offline backup of emergency contacts
+
+### For extra security
+
+**Enhanced travel procedures**: Additional precautions for high-risk situations
+
+- Disable biometric unlock at airports/borders (use PIN only) - prevents forced unlocking
+- Decline hotel housekeeping services - reduces access to devices
+- Advance notification to multisig team (72 hours for critical operations)
+- Use separate carrier SIM card for travel communications
+- Professional security assessment of travel destinations
+
+## Implementation priority
+
+### Start with basics
+
+Focus on fundamental security practices first
+
+- Password manager + 2FA on all accounts
+- Device encryption and screen locks
+- Signal setup with safety number verification
+- Basic travel security practices
+
+### Add extra security
+
+Implement additional measures based on your risk level and operational needs
+
+- YubiKeys for critical accounts
+- Dedicated signing devices for high-value operations
+- Enhanced travel procedures for international travel
+- Professional security assessments for critical roles
+
+Remember: Perfect security doesn't exist - focus on practical improvements that significantly reduce your risk while
+remaining operationally feasible.
+
+For the full OpSec article, see [Operational Security](/opsec/overview).
+
+---
+
+### PAGE: /wallet-security/seed-phrase-management
+**Title:** Seed Phrase Management
+**Referenced by controls:** tro-3.1.4
+
+# Seed Phrase Management
+
+
+
+
+## Private Key & Seed Phrase Management
+
+The **seed phrase** (or mnemonic phrase) is the master key to a non-custodial wallet, granting complete control over all
+its derived **private keys** and assets. The management of this phrase is the single most important aspect of
+self-custody security.
+
+> ⚠️ If you suspect for even a moment that your private key or seed phrase has been lost, viewed by another person, or
+> exposed digitally (e.g., shown on-screen, copied to a clipboard on a connected device), you must **consider it
+> compromised.** Immediately create a new, secure wallet and transfer all assets to it.
+
+### Secure Storage Practices
+
+The goal is to protect the seed phrase from both physical threats (theft, fire, water damage) and digital threats
+(hacking, malware). The foundational principle is to keep your seed phrase offline at all times.
+
+As soon as a new wallet is created, back it up using one of the following offline methods. Wallet providers do not have
+access to your seed phrase and cannot help you recover it.
+
+- **Physical Written Copies**: Writing the phrase on paper or a notebook is a common starting point. To mitigate risks
+
+of loss or damage from fire or water, store multiple copies in secure, geographically separate locations (e.g., a
+personal safe, a trusted family member's home, a bank deposit box).
+
+- **Durable Metal Storage**: For superior protection against physical damage, etch or stamp your seed phrase onto a
+
+metal plate (e.g., steel, titanium). Commercial products are available for this purpose. These should also be stored in
+secure, separate locations.
+
+### Enhanced security option
+
+For extra security, split seed into 3 pieces:
+
+- **Piece 1**: Words 1-16
+- **Piece 2**: Words 9-24
+- **Piece 3**: Words 1-8 and 17-24
+
+#### Storage locations:
+
+- Different secure locations (safe deposit box, home safe, trusted family)
+- Each piece stored with clear labeling system
+
+### Tamper evident bags:
+
+Storing sensitive devices or documents in a tamper evident bag offers high confidentiality and integrity. You can sign &
+date these bags, and also take a picture of its serial number.
+
+![Tamper evident bag example](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/tamper-evident-bag-example.png)
+
+**Use case:**
+You can put your Piece 1: Words 1-16 of your seed, inside a safe.
+Piece 2: Words 9-24 of your seed, somewhere safe (different location) in a tamper evident bag (could be at your parents place).
+Piece 3: Words 1-8 and 17-24 of your seed, somewhere safe (different location) in a tamper evident bag (could be
+somewhere else, at a family member or trusted friend).
+You can put your backup ledger while traveling inside this, in the safe of your hotel room to detect tampering.
+The main idea is to never have at the same place your 24 words, but still be able to recover your seed within 2 pieces
+of paper out of 3.
+You can find a useful [link here to our EthCC
+swag](https://drive.google.com/file/d/1L1CMiKRL3TXQBE5bWYNv6dfF94HSdZ8C/view?usp=sharing) that shows you how to easily
+split your seed in 3 as recommended.
+
+### Prohibited Practices
+
+Under no circumstances should you ever store your seed phrase in any of the following ways:
+
+- Taking a digital photograph of it.
+- Uploading it to cloud storage (iCloud, Google Drive, Dropbox).
+- Sending it via text message or any messaging app.
+- Sending it in an email, even to yourself.
+- Storing it in a plain text file on a computer or phone.
+- Sharing it with anyone. Wallet providers will **never** ask for your seed phrase.
+- Password managers or digital storage
+- Traveling with seed phrases
+- Storing all pieces in same location
+- Using a device obtained from an untrusted source, such as a conference, hackathon, or third-party online marketplace,
+as it may be tampered with.
+
+## Organizational Seed Phrase Security
+
+For organizations managing multisig wallets, seed phrase security requires additional properties beyond individual storage:
+
+### Security Properties
+
+- **Disaster Resistant**: The seed phrase is either duplicated or split, with components/copies secured across multiple
+geographic locations. This way, if disaster strikes, keys can be recovered from other locations.
+- **Theft Resistant**: An attacker gaining access to one piece of physical storage media for the seed phrase would not
+allow them to rebuild the wallet on its own
+- **Operator Loss Resistant**: Reconstituting the seed phrase should be possible with the absence of one or more
+operators
+
+### Seed Phrase Encryption
+
+> ⚠️ **Warning: Encryption adds recovery risk.** Only implement custom encryption schemes if you are sophisticated and
+> have robust documentation practices. If you forget your encryption method or passphrase, your funds are **permanently
+> inaccessible**—there is no recovery option. Many users and organizations face greater risk of locking themselves out
+> with custom encryption than from an attacker discovering a securely stored backup. Evaluate whether strong physical
+> security alone may be sufficient for your threat model.
+
+The reason to encrypt seed phrases is that if they are discovered unencrypted, the wallet is permanently compromised.
+However, if you encrypt your seed phrase, you are much more likely to forget the encryption when trying to restore the
+wallet. If you have stored the seed securely, it is unlikely to be discovered in the first place.
+
+Never store seed phrases in plain text or on an internet connected device. For additional protection, seed phrases can
+optionally be encrypted through some method. For example:
+
+- Seed phrases can be mixed in a randomly generated, recorded order
+- Have a 25th secret word
+- Require a passphrase to be imported into a wallet
+
+Regardless of the method, the related secret value should be stored in a password manager. (**Do not store your seed
+phrase in a password manager.**)
+
+### Advanced Backup Options
+
+**Key Splitting:**
+
+Split the key into multiple shards and securely distribute them:
+
+- Use [Shamir's Secret Sharing algorithm](https://en.wikipedia.org/wiki/Shamir%27s_secret_sharing) for N of M key shards
+- Consider using this [Shamir Secret Sharing implementation](https://github.com/privy-io/shamir-secret-sharing)
+- Seed phrases can be sharded using Shamir's Secret Sharing algorithm, with each shard recommended to be shared with a
+trusted guardian (3rd party custodian service, family members, password manager, personal physical media, etc.)
+
+**Multi-Share Backups:**
+
+Use device-supported multi-share backups where available:
+
+- [Trezor Multi-Share Backup](https://trezor.io/learn/a/multi-share-backup-on-trezor)
+
+**Secure Distribution:**
+
+Give shards to trusted family members, put in bank safe deposit boxes, and keep hidden around your house.
+
+> **Note**: If you're concerned about targeted attacks like kidnapping or home invasions, consider avoiding storing
+any shards in your primary residence.
+
+### Multisig Social Recovery
+
+**Optional Self-Recovery**:
+
+- Seed phrase backups are not strictly necessary with a healthy quorum
+- Multi-sig signing wallets should not be used for any other purpose and could be re-provisioned by existing quorum
+admins
+- Maintain a healthy enough signing pool that loss of access to a few accounts at once could be recovered from
+- Personal backup methods for admins are required to maintain access to on-chain assets in the event of loss of access
+to hardware wallets
+
+**Quorum Social Recovery**: If access to wallet is lost, the quorum can vote to edit members to replace the
+inaccessible wallet.
+
+### Ongoing Security Hygiene
+
+**1. Periodic Security Audits:**
+
+On a recurring basis (e.g., every 6 months), conduct a security review by asking:
+
+- Do I know the physical location of all my seed phrase backups?
+- Are my storage methods still secure and uncompromised?
+- If my primary device were destroyed, do I have a clear plan to recover my assets?
+
+**2. Key Rotation:**
+
+While you can use the same keys for years, it is a best practice to periodically rotate them by moving assets to new
+wallets.
+
+**3. Succession Planning:**
+
+Establish a clear, secure protocol for a trusted next-of-kin to access your assets in case of incapacitation or death.
+This may involve sealed instructions stored with a lawyer or in a safe deposit box.
+
+## Emergency access plan
+
+### Trusted contacts
+
+- Designate 2-3 trusted individuals who can access backup locations
+- Clear instructions for emergency seed access
+- Regular check-ins with trusted contacts
+
+### Recovery scenario example
+
+"Call [trusted person] with code word [predetermined phrase], tell them to get the metal plate from safe location A,
+they give you words 1-16 over the phone. Then call [second person] with code word for location B to get words 9-24. Use
+both pieces to reconstruct seed immediately, then change all security settings."
+
+### Documentation
+
+- Emergency contact information stored separately from seed
+- Code words/phrases for identity verification
+- Access instructions for trusted contacts
+- Regular testing of emergency procedures
+- Update procedures when contacts or locations change
+
+Remember: Your seed phrase security is the foundation of multisig security. Take time to implement proper storage
+procedures appropriate for your risk level.
+
+---
+
+### PAGE: /multisig-for-protocols/backup-signing-and-infrastructure
+**Title:** Backup Signing & Infrastructure | SEAL
+**Referenced by controls:** tro-4.1.3, tro-7.1.2
+
+TagList,
+  AttributionList,
+  TagProvider,
+  TagFilter,
+  ContributeFooter,
+} from "../../../components";
+
+
+
+
+# Backup Signing & Infrastructure
+
+
+
+
+If the default interfaces for either Safe or Squads are down or suspected of being compromised, these alternatives
+enable continued critical signing operations. As a signer, you should familiarize yourself with these tools and practice
+signing transactions with your team.
+
+## UI Alternatives
+
+### EVM Networks
+
+**Eternal Safe - Decentralized fork of Safe\{Wallet\}**
+
+- GitHub: [https://github.com/eternalsafe/wallet](https://github.com/eternalsafe/wallet)
+- Hosted (IPFS): [https://eternalsafe.eth.limo](https://eternalsafe.eth.limo) (requires bring your own RPC)
+- Local: Can be downloaded and run locally
+
+Note: Local/alternative UIs may not be actively maintained. Treat them as emergency options and perform extra
+verification. Please DYOR.
+
+### Solana
+
+**Squads Public Client - Open source Squads V4 interface: **
+
+- GitHub: [https://github.com/Squads-Protocol/public-v4-client](https://github.com/Squads-Protocol/public-v4-client)
+- Features: Verifiable build, self-hostable with Docker, IPFS distribution
+- Local: Can be built and run locally
+
+### Mobile (Safe)
+
+**Safe Mobile Apps: **
+
+- GitHub: [https://github.com/safe-global/safe-wallet-monorepo/tree/dev/apps/mobile](https://github.com/safe-global/safe-wallet-monorepo/tree/dev/apps/mobile)
+- App Store: [https://apps.apple.com/us/app/safe-mobile/id6748754793](https://apps.apple.com/us/app/safe-mobile/id6748754793)
+- Play Store: [https://play.google.com/store/apps/details?id=global.safe.mobileapp](https://play.google.com/store/apps/details?id=global.safe.mobileapp)
+
+## RPC Backup Options
+
+### Basic guidance:
+
+- Multiple providers: Set up accounts with 2-3 different RPC services
+  - eg. Alchemy, Infura, Chainstack, Quicknode, Tenderly
+- Avoid correlation: Choose providers that don't share infrastructure, if that information is available
+- Private RPCs preferred: Public RPC URLs are typically not sufficient for reliable operation
+
+### Administrator responsibilities
+
+Ensure signer preparedness:
+
+- Provide access to offline UI tools listed above
+- Verify signers have practiced using backup interfaces
+- Test backup RPCs during non-emergency periods
+- Document procedures for switching to backup infrastructure
+
+## Block Explorer Backup Options
+
+### EVM Networks
+
+Etherscan provides the default block explorer for nearly all EVM chains. In the event that Etherscan is compromised or
+goes down, it is important to have backup options that can be used for monitoring and investigating transactions.
+
+**Blockscout - Open source Etherscan alternative: **
+
+- [https://www.blockscout.com/](https://www.blockscout.com/)
+- Available for all EVM networks
+- Can also be [self-hosted](https://github.com/blockscout/blockscout), although it requires significant time to run full
+  node and index
+
+More explorers: A broader list of network explorers is maintained here: [https://explorer.swiss-knife.xyz/](https://explorer.swiss-knife.xyz/)
+
+### Solana Networks
+
+Both explorer.solana.com and Solscan are reliable options for Solana transaction exploration and decoding.
+
+**explorer.solana.com** - [https://explorer.solana.com/](https://explorer.solana.com/)
+
+- Can be [self-hosted](https://github.com/solana-foundation/explorer) using open source code
+
+**Solscan** - [https://solscan.io/](https://solscan.io/)
+
+## Preparation
+
+**It is recommended to download dependencies ahead of time and store them in a secure location** so they are easily
+accessible during emergencies.
+
+## EVM Networks
+
+### Eternal Safe - Decentralized fork of Safe\{Wallet\}
+
+#### Access Options
+
+- **GitHub**: [https://github.com/eternalsafe/wallet](https://github.com/eternalsafe/wallet)
+- **Hosted (IPFS)**: [https://eternalsafe.eth.limo](https://eternalsafe.eth.limo) (requires bring your own RPC)
+- **Local**: Can be downloaded and run locally
+
+#### Setup
+
+1. Select network and enter an RPC URL
+   <div align="center">
+     <img
+       src="https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/eternal-safe-network-selection.png"
+       alt="Eternal Safe network selection"
+       style={{ height: "400px" }}
+     />
+     <p>
+       <em>
+         Eternal Safe network selection screen: choose your network and enter an
+         RPC URL
+       </em>
+     </p>
+   </div>
+2. Enter Safe address and load
+   ![Eternal Safe address entry](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/eternal-safe-address-entry.png)
+3. Eternal Safe will automatically detect Ether balances but not ERC20 tokens. They can be added manually
+   ![Eternal Safe token configuration](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/eternal-safe-token-configuration.png)
+
+#### Transaction Verification
+
+**Critical**: It is still essential to verify hashes and calldata from Eternal Safe. Follow the verification steps in
+[Safe Multisig: Step-by-Step Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification).
+
+#### Smart Link System
+
+Once a transaction has been signed by one signer, a **Smart Link** is created which can be forwarded to the next signer
+to add their signature. The transactions do not go to any centralized backend.
+
+**Example Smart Link:**
+
+```
+Please sign this Eternal Safe transaction for the Safe: base:0xA79C6968E3c75aE4eF388370d1f142720D498fEC.
+Current confirmations: 1 of 2.
+https://eternalsafe.eth.limo/transactions/tx/?safe=base:0xA79C6968E3c75aE4eF388370d1f142720D498fEC&tx=eyJzaWduYXR1cmVzIjp7ImRhdGFUeXBlIjoiTWFwIiwidmFsdWUiOltbIjB4NDBiYjMyZjA4NjJkMjI3ODEzYzg2ZmQ4M2E3YjNjOWRiOTA3NGUyYSIseyJzaWduZXIiOiIweDQwYkIzMkYwODYyRDIyNzgxM2M4NkZEODNBN0IzYzlkYjkwNzRFMkEiLCJkYXRhIjoiMHgwZDMxZTZjODIxZjBhMGZlM2M5NmNlZWY4ZDNhM2JhZmU3YmZmZTliODQ0ZWNkYzBkYWNmNzc0MzFkODQ0NjU4MTgwZjUwNmZlMjZiZjMzOTQwY2VhOTJiMzlhNDNjODRkMDRhNThiMGY1ODQ2NzhlNzE0YTllMWJkMzE0NTg5ZjFiIn1dXX0sImRhdGEiOnsiZGF0YSI6IjB4IiwiYmFzZUdhcyI6IjAiLCJnYXNQcmljZSI6IjAiLCJzYWZlVHhHYXMiOiIwIiwiZ2FzVG9rZW4iOiIweDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAiLCJub25jZSI6NCwicmVmdW5kUmVjZWl2ZXIiOiIweDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAiLCJ2YWx1ZSI6IjEwMDAwMDAwMDAwMDAwMDAiLCJ0byI6IjB4RTBiY2ZlNWUzMEFCYTBCNDZmMTNCMEMyNENiQzQ3MERDQTNlYjg2NSIsIm9wZXJhdGlvbiI6MH19
+```
+
+#### Execution
+
+Once all signatures are collected, execute the transaction. **Note**: Prior to execution you can manually simulate using
+Tenderly by entering the transaction data, but an automatic simulation link will not be available.
+
+## Solana
+
+### Squads Public Client - Open source Squads V4 interface
+
+#### Access Options
+
+- **GitHub**: [https://github.com/Squads-Protocol/public-v4-client](https://github.com/Squads-Protocol/public-v4-client)
+- **Hosted**: [https://backup.app.squads.so/](https://backup.app.squads.so/)
+- **Features**: Verifiable build, self-hostable with Docker, IPFS distribution
+- **Local**: Can be built and run locally
+
+#### Setup
+
+1. If running locally, follow setup instructions in [https://github.com/Squads-Protocol/public-v4-client](https://github.com/Squads-Protocol/public-v4-client)
+ and access via `http://localhost:8080`
+2. Enter RPC URL in settings
+   ![Squads RPC configuration](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/squads-rpc-configuration.png)
+3. Enter multisig address in the **lower** text box (Search for Multisig Config) and select the detected Multisig Config
+   ![Squads multisig selection](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/squads-multisig-selection.png)
+
+#### Transaction Operations
+
+1. Create, approve, or execute transactions. _Smart Links_ are not needed for Solana as all transactions are on chain
+   and accessible via the RPC without an API
+   ![Squads transaction interface](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/squads-transaction-interface.png)
+
+## Security Considerations
+
+### Enhanced Verification
+
+When using backup systems:
+
+- **Extra caution required**: Be more thorough with verification procedures
+- **Multiple verification methods**: Use additional tools to cross-check transaction details
+- **Team confirmation**: Verify with other signers before proceeding with critical transactions
+- **Documentation**: Record use of backup systems and any issues encountered
+
+### Risk Assessment
+
+- **Delay non-critical operations**: Consider postponing non-urgent transactions until primary systems recover
+- **Emergency operations only**: For critical emergency responses, proceed with enhanced verification
+- **Communication**: Keep team informed about system status and verification procedures
+
+## Testing and Preparation
+
+### Regular Practice
+
+- **Monthly testing**: Practice using backup interfaces during normal operations
+- **Team coordination**: Ensure all signers can operate backup systems
+- **Process documentation**: Update procedures based on practice sessions
+
+### Emergency Drills
+
+- **Simulated outages**: Practice coordinating with backup systems during drills
+- **Communication testing**: Verify backup communication channels work with backup UIs
+- **Time measurement**: Track how long backup system activation takes
+
+## Troubleshooting
+
+### Common Issues
+
+- **RPC connectivity**: Switch to alternative RPC providers if connection fails
+- **Transaction loading**: Refresh or try different network endpoints
+- **Signature verification**: Use multiple verification tools when in doubt
+
+### Support Resources
+
+- **GitHub documentation**: Refer to project documentation for technical issues
+- **Team assistance**: Coordinate with other signers for problem-solving
+- **Alternative tools**: Have multiple backup options available
+
+## Related Documents
+
+- [Safe Multisig: Step-by-Step
+Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification) - Verification procedures
+- [Emergency Procedures](/multisig-for-protocols/emergency-procedures) - General emergency response
+- [Communication Setup](/multisig-for-protocols/communication-setup) - Backup communication during outages
+
+---
+
+### PAGE: /wallet-security/account-abstraction
+**Title:** Account Abstraction Wallets
+**Referenced by controls:** tro-5.1.1, tro-5.1.2
+
+# Account Abstraction Wallets
+
+
+
+
+## User Profile
+
+Advanced users, developers, and organizations interested in programmable security, customizable transaction rules, and
+moving beyond the limitations of standard Externally Owned Accounts (EOAs) to eliminate single points of failure like
+seed phrase loss.
+
+## Primary Goal
+
+To leverage the power of smart contracts at the account level, enabling features like social recovery, gas sponsorship,
+batch transactions, and flexible security policies that are not possible with an EOA.
+
+## Core Concept: ERC-4337
+
+Account Abstraction (AA) turns a user's account into a smart contract, making it programmable. Instead of being
+controlled directly by a single private key, the account's logic is defined by its code. This is achieved through
+**ERC-4337**, a standard that enables AA without requiring changes to the core Ethereum protocol. It introduces a
+higher-level pseudo-transaction system with several key components:
+
+* **Smart Contract Account**: The user's wallet itself is a smart contract, containing custom logic for validating
+transactions.
+* **UserOperation**: A data structure that bundles the user's intent, calldata, and signature. This object is sent to a
+dedicated, alternative mempool.
+* **Bundlers**: Specialized nodes that package multiple `UserOperation` objects from the mempool into a single
+transaction and submit it to the `EntryPoint` contract.
+* **EntryPoint**: A singleton smart contract that acts as the central orchestrator. It verifies and executes the bundled
+`UserOperations`, ensuring that accounts and paymasters have sufficient funds to pay for gas.
+* **Paymasters**: Optional smart contracts that can sponsor gas fees on behalf of the user, enabling gasless
+transactions for the end-user or allowing fees to be paid in ERC-20 tokens.
+
+## Key Benefits & Features
+
+* **Enhanced Security**:
+  * **Social Recovery**: Mitigate the risk of losing a primary key by designating trusted "guardians" (other accounts or
+  devices) who can collectively approve an account recovery.
+  * **Customizable Policies**: Implement robust security rules directly into the wallet, such as daily spending limits,
+  whitelisting trusted contracts, or requiring multisig confirmation for transactions over a certain value.
+
+* **Improved User Experience**:
+  * **Gasless Transactions**: Enjoy a smoother experience where dApps can sponsor gas fees, or pay for transactions
+  using ERC-20 tokens instead of needing the chain's native asset (e.g., ETH).
+  * **Simplified Interactions**: Perform complex, multi-step actions (like `approve` and `swap`) in a single, atomic
+  transaction, reducing clicks and potential points of failure.
+
+## Security Considerations & Best Practices
+
+* **Smart Contract Risk**: The security of an AA wallet is entirely dependent on the quality and security of its
+underlying smart contract code. Bugs or vulnerabilities in the account's implementation can lead to a total loss of
+funds. **Thorough audits of the account logic are non-negotiable.**
+* **Guardian Selection and Security**: The strength of the social recovery model depends on the security and
+independence of the guardians. They should be diverse and not susceptible to a single common threat.
+* **EntryPoint Centralization**: The `EntryPoint` contract is a central trust point for the entire ERC-4337 ecosystem. A
+vulnerability in the official `EntryPoint` could have widespread consequences. Use only the canonical, heavily audited
+`EntryPoint` contract.
+* **Paymaster and Factory Security**: Malicious or poorly coded Paymasters and Factories can introduce DoS vectors or
+other risks. The ERC-4337 standard includes a reputation system and staking mechanisms to throttle or ban misbehaving
+entities, but users should only interact with trusted and audited Paymasters.
+* **Gas Overhead**: The added logic in a smart contract account means that transactions can be more expensive than those
+from a standard EOA. This trade-off between features and cost should be considered, though it can be offset by gas
+sponsorship.
+* **Key Revocation**: If the primary signing key is compromised, the recovery process allows you to swap it out for a
+new one without having to move all assets to a new wallet address.
+* **Advanced Guardian Setups**: For enhanced security, guardian roles can be implemented using **Multi-Party Computation
+(MPC)**. In an MPC-based recovery, guardians hold cryptographic shares that are used collectively to authorize a
+recovery action. This method allows guardians to produce a valid signature through a distributed computation using their
+individual shares, without ever reconstructing a single master key on any device.
+
+---
+
+---
+
+### PAGE: /incident-management/playbooks/seal-911-war-room-guidelines
+**Title:** SEAL 911 War Room Guidelines | SEAL
+**Referenced by controls:** tro-6.1.1, tro-7.1.1
+
+# SEAL 911
+
+
+
+
+SEAL 911 is a project designed to give users, developers, and even other security researchers an accessible method to
+contact a small group of highly trusted security researchers. The group can be reached via the [Telegram
+bot](https://t.me/seal_911_bot).
+
+Members of SEAL 911 follow a strict
+[CODE OF CONDUCT](https://github.com/security-alliance/seal-911/blob/main/CODE_OF_CONDUCT.md).
+
+When interacting with SEAL 911, ensure that you give as much information as possible in order to avoid double work by
+the security researchers.
+
+## Crisis Handbook - Smart Contract Hack | [Google Doc](https://docs.google.com/document/d/1DaAiuGFkMEMMiIuvqhePL5aDFGHJ9Ya6D04rdaldqC0/edit#heading=h.c4h2beeflqpo)
+
+### Actions Checklist
+
+### Perform Immediately
+
+- [ ] Notify SEAL 911 Bot of the incident. Use this message template to get started.
+- [ ] Create a War Room with audio and share the invite link with trusted individuals.
+- [ ] Duplicate this document to allow collaboration and share the link in the War Room.
+- [ ] Review the Advice to Keep in Mind section.
+
+### Perform in Parallel by Role
+
+1. **Assign Key Roles to War Room Members**:
+   - [ ] Assign members to specific roles.
+
+2. **Analysis**:
+   - [ ] Scope the impact of the attack.
+   - [ ] Gather Transactions Involved.
+   - [ ] Gather Affected Addresses.
+   - [ ] Record Funds Movement.
+   - [ ] Gather Attacker Information.
+   - [ ] Investigate the issue and update the Issue Description.
+   - [ ] Propose workable solutions.
+
+3. **Protocol actions**:
+   - [ ] Take immediate corrective/preventative actions to prevent further loss of funds.
+   - [ ] Pause contracts if possible.
+   - [ ] Execute pre-made defensive scripts.
+   - [ ] Prioritize proposed solutions.
+   - [ ] Validate and execute the solution.
+   - [ ] Prepare monitoring alerts for situations that require future actions.
+
+4. **Web actions**:
+   - [ ] Disable deposits and/or withdrawals as needed in the web UI.
+   - [ ] Enable front-end IP or Address blacklisting.
+   - [ ] Create front-end for any user actions necessary (approval revoking, fund migrating, etc.).
+
+5. **Communications**:
+   - [ ] Identify social platforms that communications on the incident must be sent to.
+   - [ ] Prepare messages for incident communication internally and externally.
+   - [ ] Gather security contacts for any potentially affected downstream protocols (bridges, lending protocols).
+   - [ ] Notify block explorers (like Etherscan) for attacker address labeling.
+   - [ ] Continuously monitor social media for users providing additional information that aids whitehat efforts.
+   - [ ] Monitor War Room efforts and maintain the Event Timeline.
+
+### After all of the above is complete, consider Post Incident Actions
+
+## Information Gathering
+
+Information will primarily be shared and acted upon in the War Room. As time allows, consolidate intel in the below
+section to achieve the following:
+
+- Accurately scope the incident impact.
+- Inform new War Room members and third parties efficiently.
+- Aid external communication.
+
+This is the chief duty of the Scribe.
+
+### Issue Description
+
+The issue involves an unauthorized transfer of funds from the protocol's treasury contract due to a vulnerability in the
+contract's access control mechanism. The attacker exploited this vulnerability to initiate multiple transfers,
+siphoning funds to an external wallet.
+
+### Events Timeline
+
+Record events to construct an overall timeline of the incident. Events worth recording:
+
+- First notice of the incident
+- War room creation
+- External communications
+- Attack transactions
+- Transactions performed by the team
+
+Record times in UTC. Use a UTC Time Converter.
+
+| Date-Time (UTC) | Event Description | Notes |
+| --- | --- | --- |
+| 2024-08-23 12:45 | First notice of the unauthorized transfer | Alert received via monitoring system |
+| 2024-08-23 12:50 | War room created | Initial members invited |
+| 2024-08-23 13:05 | Notified SEAL 911 Bot | Incident report submitted |
+| 2024-08-23 13:15 | Attack transaction identified | Transaction hash: 0x123456789abc |
+| 2024-08-23 13:20 | Contracts paused | Prevented further fund transfers |
+| 2024-08-23 13:30 | External communication initiated | First update sent via Twitter |
+
+### Transactions Involved
+
+Record all transactions related to the incident.
+
+| Transaction Link | Notes |
+| --- | --- |
+| [0x123456789abcdef...](https://etherscan.io/tx/0x123456789abcdef) | Initial exploit transaction |
+| [0xabcdef123456789...](https://etherscan.io/tx/0xabcdef123456789) | Attacker moving funds to mixer |
+| [0xfedcba987654321...](https://etherscan.io/tx/0xfedcba987654321) | Defensive move by the team |
+
+### Affected Addresses
+
+Record affected addresses related to the incident (protocol contracts, bridges, users, etc.).
+
+| Address Link | Status | Notes |
+| --- | --- | --- |
+| [0x1111222233334444...](https://etherscan.io/address/0x11112222) | At Risk | User wallet, interacted with exploit |
+| [0x5555666677778888...](https://etherscan.io/address/0x55556666) | Impacted | Protocol treasury address |
+| [0x99990000aaaabbbb...](https://etherscan.io/address/0x99990000) | Paused | Lending protocol contract |
+| [0xaaaabbbbccccdddd...](https://etherscan.io/address/0xaaaabbbb) | Saved | Bridge contract, funds secured |
+| [0xddddeeeeffff0000...](https://etherscan.io/address/0xddddeeee) | Needs Review | User wallet, unusual activity noted |
+| [0x2222333344445555...](https://etherscan.io/address/0x22223333) | Uncertain | User wallet, pending analysis |
+
+### Funds Movement
+
+Record funds movement to gather the impact of the incident and organize recovery efforts.
+
+- Original address that held the funds
+- Transaction that moved the funds
+- Assets and amounts the funds are comprised of
+- Destination the funds moved to (Contract, CEX, Bridge, Mixer)
+- Recovery Status of the funds
+
+Use Phalcon Tx Explorer to aid in recording funds movement.
+
+| Origin | Transaction Link | Amount / Asset | Destination | Recovery Status | Notes |
+| --- | --- | --- | --- | --- | --- |
+| [0x5555666677778888...](https://etherscan.io/address/0x5555) | [0xabcdef123456789...](https://etherscan.io/tx/0xabcdef) | 1000 ETH | [Mixer address](https://etherscan.io/address/0x12) | Needs Review | Funds moved to Tornado Cash |
+| [0x99990000aaaabbbb...](https://etherscan.io/address/0x9999) | [0x9876543210fedcba...](https://etherscan.io/tx/0x987654) | 500,000 DAI | [CEX address](https://etherscan.io/address/0x34) | In Progress | Funds transferred to centralized exchange |
+| [0xaaaabbbbccccdddd...](https://etherscan.io/address/0xaaaa) | [0x123456789abcdef...](https://etherscan.io/tx/0x123456) | 200 BTC | [Contract address](https://etherscan.io/address/0x56) | Recovered | Funds recovered via multisig |
+| [0xddddeeeeffff0000...](https://etherscan.io/address/0xdddd) | [0xfedcba987654321...](https://etherscan.io/tx/0xfedcba) | 50,000 USDC | [Bridge address](https://etherscan.io/address/0x78) | Uncertain | Funds possibly moved cross-chain |
+
+### Attacker Information
+
+Gather attacker information to aid legal efforts and fund recovery.
+
+| Address Link | Funded By | Notes |
+| --- | --- | --- |
+| [0xabcdefabcdefabcd...](https://etherscan.io/address/0xabcdefab) | Tornado Cash | Initial funding from Tornado Cash mixer |
+| [0x123456789abcdef...](https://etherscan.io/address/0x12345678) | CEX | Received funds from centralized exchange |
+| [0xfedcba987654321...](https://etherscan.io/address/0xfedcba98) | Unknown | No prior activity, potentially new wallet |
+
+## Post Incident Actions
+
+1. Confirm the incident has been resolved.
+2. Create monitoring alerts for situations requiring future actions.
+3. Prepare scripts to perform any actions related to monitoring events in the future.
+4. Consider creating additional defensive scripts (pause/upgrade) to use for future situations.
+5. Schedule a Post Mortem write-up.
+6. Post the write-up to relevant social media.
+
+## Appendix
+
+### Advice to Keep in Mind
+
+- Limit the War Room occupancy. Be careful not to invite too many people during the early stages. Sensitive information
+is being shared; be wary.
+- Make it clear to War Room members not to publicize information without the protocol’s consent.
+- Do not speak to the press/news/publications.
+
+### Key Roles
+
+- **Operations**: Initiates War Room, assigns roles, distributes tasks, herds multisig participants.
+  - *Person Responsible*
+- **Scribe**: Consolidates gathered information for efficiency in knowledge-sharing.
+  - *Person Responsible*
+- **Strategy Lead**: Prioritizes actions, considers trade-offs of decisions.
+  - *Person Responsible*
+- **Protocol Lead**: Responsible for smart-contract actions (pausing, upgrading, etc.).
+  - *Person Responsible*
+- **Web/Infrastructure Lead**: Responsible for updating the front-end, managing servers.
+  - *Person Responsible*
+- **External Communicator**: Social media and user communications.
+  - *Person Responsible*
+
+### Suggested Tools and Platforms
+
+| Name | Type | Notes |
+| --- | --- | --- |
+| Discord | Platform | A familiar platform for web3 collaboration. Spin up a server quickly using our [recommended template](https://discord.new/CkADqy5aWsAH). Tips: New users must be granted the `approved` role before they can view chats. Upon creation, grant yourself the `approved` role and share an invite link with trusted members. |
+| Telegram | Platform | A familiar platform for web3 collaboration. Tips: Upon New Group creation, enable chat history as visible to new members. To do this: Info -> Edit -> Chat History For New Members -> Visible |
+| Google Hangouts | Platform | |
+| Phalcon Tx Explorer | Tx Analysis | |
+| Openchain Trace Explorer | Tx Analysis | |
+| Tenderly Tx Explorer | Tx Analysis, Debugging | Some features require login. |
+| Tenderly Alerts | Monitoring | Monitor addresses, on-chain actions, etc. Requires login. |
+| MetaSleuth | Monitoring | Monitor fund movement. 50 address limit. Requires login (premium feature). |
+| Github / Gist | Code Sharing | Create a private repo or secret gists and share the link with War Room participants only. |
+| CodeShare | Code Sharing | Sessions expire after 24 hours. |
+| HackMD | Code Sharing | Private notes become published after ~48 hours. Be very careful with sensitive information! |
+
+### SEAL Message Template
+
+Fill out with relevant information and send to SEAL 911 Bot.
+
+```plaintext
+Protocol: [Protocol Name]
+Attack Tx(s): [Transaction Hash(es)]
+Funds at Risk: [Estimated Amount in USD or Token]
+
+[Brief Description of the incident]
+```
+
+---
+
+---
+
+### PAGE: /wallet-security/tools-and-resources
+**Title:** Wallet Security Tools & Resources | SEAL
+**Referenced by controls:** tro-6.1.1
+
+# Tools & Resources
+
+
+
+
+This section provides a curated list of tools and resources to help users select wallets, practice safe signing habits,
+and verify transactions. Using these tools is a critical part of a robust security strategy.
+
+## Wallet Selection
+
+Before choosing a wallet, it is essential to consult independent, community-trusted resources.
+
+- **[ethereum.org/wallets](https://ethereum.org/en/wallets/find-wallet/)**: The official, community-maintained list of
+wallets, filterable by features. A reliable starting point for discovering wallets.
+- **[Wallet Scrutiny](https://walletscrutiny.com/)**: An in-depth review site that focuses on transparency,
+verifiability, and reproducibility. It flags wallets that are closed-source or have other potential security concerns.
+- **[Wallet Security Ranking](https://www.coinspect.com/wallets/)**: Evaluates wallets by permissions, intent clarity,
+device security, and threat prevention to help users choose safer, more trustworthy options.
+- **[Wallet Beat](https://beta.walletbeat.eth.limo/wallet/summary/)**: Aims to provide a comprehensive list of wallets,
+their functionality, practices, and support for certain standards.
+
+## Hardware Wallets
+
+Hardware wallets provide the highest level of security for storing cryptocurrency by keeping private keys offline and
+isolated from potentially compromised computers.
+
+- **[Top 9 Cryptocurrency Hardware Wallets for 2025](https://patrickalphac.medium.com/top-9-cryptocurrency-hardware-wallets-for-2025-security-researcher-review-9fcb16d771e0)**:
+A comprehensive security researcher review comparing the top hardware wallets, including analysis of security features,
+usability, and recommendations for different use cases.
+
+## Wallet Applications
+
+### Rabby Wallet
+
+- Install [Rabby wallet](https://rabby.io/)
+  - Verify open source code
+  - Enable pre-sign security checks (e.g. new address warnings)
+  - Use built-in transaction simulation
+
+### MetaMask with Security Snaps (Alternative)
+
+- Install [MetaMask](https://metamask.io/)
+- Install recommended security Snaps:
+  - [Tenderly Snap](https://snaps.metamask.io/snap/npm/tenderly/metamask-snap/) -
+  Allows you to easily simulate transactions before confirming them
+  - [Forta Network Snap](https://snaps.metamask.io/snap/npm/forta-network/metamask-snap/) -
+  Scam and malicious address detection
+
+## Transaction Simulation
+
+Transaction simulators allow you to preview the exact outcome of a transaction before signing it, preventing errors and
+security risks.
+
+- **[Tenderly](https://tenderly.co/)**: A platform that allows you to simulate transactions and preview, helping to
+prevent transaction failures, security risks, and unnecessary gas costs.
+- **[Alchemy Simulation APIs](https://www.alchemy.com/docs/reference/simulation)**: An API suite that predicts the
+precise impact of a transaction before it reaches the blockchain.
+
+## Monitoring & Alerting
+
+Implement continuous monitoring to detect unauthorized or suspicious activity on your multisig wallets.
+
+### Multisig Monitoring
+
+- [Gearbox Safe Watcher](https://github.com/Gearbox-protocol/safe-watcher) or equivalent for monitoring and alerts
+  - Connect to Telegram for notifications
+  - Monitor for suspicious delegateCall transactions
+
+### Network Security
+
+For dedicated signing machines, implement network-level protections:
+
+- **[DeFi DNS Whitelist](https://github.com/0xKoda/defi-dns-whitelist/tree/main)**: A curated whitelist of legitimate
+DeFi domains that can be used as a firewall for dedicated signing machines
+- **[Little Snitch](https://www.obdev.at/products/littlesnitch/index.html)** (macOS): Active firewall and network
+monitoring
+- **[Lulu](https://objective-see.org/products/lulu.html)** (macOS): Free, open-source network monitor
+- **[Glasswire](https://www.glasswire.com/)** (Windows): Network monitoring with firewall capabilities
+
+For more on network security configuration, see
+[Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec#network-security).
+
+## Transaction Verification
+
+These tools are designed to help you independently verify the integrity of transaction data, especially for multisig
+operations.
+
+- **[Safe Multisig Transaction Hashes](https://github.com/pcaversaccio/safe-tx-hashes-util)**: A Bash script that
+locally calculates domain and message hashes using the EIP-712 standard. It allows you to generate the exact hash that
+your hardware wallet will display.
+- **[Cyfrin Safe TX Hashes](https://github.com/Cyfrin/safe-tx-hashes)**: for additional support without relying on Safe API.
+- **[Safe Utils](https://safeutils.openzeppelin.com/)**: A user-friendly web interface for calculating and verifying
+Safe transaction hashes. While convenient, remember the security advantages of using a local, offline tool like
+`safe-hash` for high-value transactions.
+- **[Foundry cast](https://book.getfoundry.sh/reference/cast/cast-decode-calldata)**: A powerful command-line tool for
+local, offline decoding.
+- **[safe-hash](https://github.com/Cyfrin/safe-hash-rs)**: A command-line tool for locally verifying Safe transaction
+data and EIP-712 messages before signing. It is designed to protect against phishing by allowing you to independently
+generate the hash your wallet will ask you to sign.
+- **[calldata.swiss-knife.xyz](https://calldata.swiss-knife.xyz/decoder)**: Web-based tool for quick decoding of
+transaction data.
+- **[Lido Safe TX Hashes
+  Calculation](https://lido.mypinata.cloud/ipfs/bafybeibuhixxt7rdqxfbuw2tnv3lr6r4qeh4janh3setljbtvwqwtzepsa)**: IPFS
+  hosted tool with simple hash calculation.
+
+### Conversion & Utilities
+
+- **[Hex ↔ Decimal Converter](https://www.rapidtables.com/convert/number/hex-to-decimal.html)**: Handy for interpreting
+  raw instruction bytes (e.g., Solana instruction data) when verifying simulations.
+
+## Security Training
+
+These tools allow you to practice identifying threats in a safe, simulated environment.
+
+- **[The Phishing Dojo](https://www.phishingdojo.com/)**: An interactive threat simulation platform designed to train
+users to recognize real-world security risks. It offers realistic, in-browser scenarios covering phishing emails,
+fraudulent wallet signing requests, spoofed block explorer data, and malicious DApps, all without requiring any special
+setup or browser extensions.
+- **[Wise Signer](https://wise-signer.cyfrin.io/)**: An interactive platform that challenges users to identify safe and
+dangerous transactions before signing them. It is an excellent tool for learning to recognize common phishing attacks
+and deceptive transaction patterns without risking real assets.
+- **[Web3 Wallet Security Courses](https://updraft.cyfrin.io/career-tracks/web3-wallet-security/)**: Offers a structured
+curriculum for hands-on security training, guiding users from foundational concepts in "Web3 Wallet Security Basics" to
+advanced techniques. The advanced course covers critical topics like Safe multisig configuration, EIP-712 signature
+verification, and real-world hack analysis.
+- **[How to Multisig](https://howtomultisig.com/)**: A dedicated resource with best practices on how to implement secure
+standard operating procedures for multisig wallets.
+
+---
+
+---
+
+### PAGE: /governance/compliance-regulatory-requirements
+**Title:** Compliance & Regulatory Requirements | SEAL
+**Referenced by controls:** tro-7.1.1
+
+# Compliance with Regulatory Requirements
+
+
+
+
+Compliance with regulatory requirements may be essential for your project. Understanding the needs and ensuring the
+necessary compliance helps protect your project from potential legal penalties.
+
+## Key Regulatory Frameworks
+
+Some examples of regulatory frameworks or standards for web3 are:
+
+- **GDPR (General Data Protection Regulation)**: Applies to organizations handling the personal data of EU citizens. It
+mandates strict data protection measures and grants individuals significant rights over their data, as soon on
+[https://gdpr.eu/](https://gdpr.eu/).
+- **MiCA**: Companies seeking to offer crypto services or assets within the EU are in scope. While this may seem
+daunting, there are different levels of compliance needed depending on the project, as can be seen on
+[https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/markets-crypto-assets-regulation-mica](https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/markets-crypto-assets-regulation-mica)
+
+## Best Practices for Compliance
+
+# Best Practices for Regulatory Compliance in Terms of Security
+
+## 1. Understand Applicable Regulations
+
+- **Identify Relevant Regulations:** Clearly identify all regulatory frameworks that apply to your organization, such as
+GDPR, HIPAA, CCPA, or PCI DSS.
+- **Regularly Review Legal Requirements:** Stay updated on changes in regulations that impact your industry, ensuring
+compliance measures evolve accordingly.
+- **Engage Legal Counsel:** Work with legal experts to interpret regulations accurately and implement appropriate
+security controls.
+
+## 2. Develop a Robust Security Policy Framework
+
+- **Comprehensive Security Policies:** Develop detailed security policies that align with regulatory requirements,
+covering areas like data protection, access control, and incident response.
+- **Policy Documentation:** Maintain thorough documentation of all security policies, procedures, and controls, ensuring
+they are easily accessible for audits and reviews.
+- **Regular Policy Updates:** Review and update security policies regularly to reflect changes in regulations and
+emerging threats.
+
+## 3. Data Protection and Privacy
+
+- **Data Classification:** Classify data based on sensitivity and regulatory requirements, ensuring appropriate
+protection levels for each category.
+- **Data Minimization:** Collect and retain only the minimum amount of data necessary for business operations, reducing
+exposure to potential breaches.
+- **Anonymization and Pseudonymization:** Where possible, apply anonymization or pseudonymization techniques to protect
+personal data.
+
+## 4. Access Management and Control
+
+- **Role-Based Access Control (RBAC):** Implement RBAC to ensure that employees have access only to the data and systems
+necessary for their roles.
+- **Multi-Factor Authentication (MFA):** Require MFA for access to sensitive systems and data, adding an extra layer of
+security.
+- **Regular Access Audits:** Conduct regular audits of user access rights to ensure compliance with the principle of
+least privilege.
+
+## 5. Incident Response Planning
+
+- **Comprehensive Incident Response Plan:** Develop an incident response plan that aligns with regulatory requirements,
+detailing steps for identifying, responding to, and reporting security incidents.
+- **Regulatory Reporting:** Ensure the incident response plan includes protocols for reporting breaches to regulatory
+authorities within the required timeframes.
+- **Regular Testing:** Conduct regular simulations and tabletop exercises to test the effectiveness of the incident
+response plan.
+
+## 6. Continuous Monitoring and Auditing
+
+- **Automated Monitoring Tools:** Implement automated tools to continuously monitor compliance with security regulations
+and detect potential vulnerabilities or breaches.
+- **Internal Audits:** Conduct regular internal audits to assess compliance with security policies and regulatory
+requirements.
+- **External Audits:** Engage third-party auditors to provide independent assessments of your security posture and
+compliance status.
+
+## 7. Employee Training and Awareness
+
+- **Regular Training Programs:** Provide regular training on regulatory requirements, data protection, and security best
+practices for all employees.
+- **Phishing and Social Engineering Awareness:** Educate employees about phishing, social engineering, and other common
+attack vectors that could lead to compliance breaches.
+- **Role-Specific Training:** Tailor training programs to address the specific regulatory and security responsibilities
+of different roles within the organization.
+
+## 8. Third-Party Risk Management
+
+- **Vendor Due Diligence:** Conduct thorough due diligence on third-party vendors to ensure they comply with relevant
+security regulations.
+- **Contractual Obligations:** Include specific security and compliance requirements in contracts with third-party
+vendors.
+- **Continuous Monitoring:** Monitor third-party vendors’ compliance with security requirements throughout the
+relationship.
+
+## 9. Data Encryption and Secure Communication
+
+- **Encryption Standards:** Use strong encryption standards for protecting data both at rest and in transit, in line
+with regulatory requirements.
+- **Secure Communication Channels:** Ensure that all communication involving sensitive data is conducted over secure
+channels (e.g., TLS, VPN).
+- **Key Management:** Implement robust key management practices to protect encryption keys from unauthorized access.
+
+## 10. Documentation and Record-Keeping
+
+- **Compliance Documentation:** Maintain detailed records of compliance efforts, including audit results, incident
+reports, and training logs.
+- **Retention Policies:** Establish data retention policies that comply with regulatory requirements, ensuring that
+records are kept for the required duration.
+- **Audit Trails:** Ensure that all access to sensitive data is logged, creating a clear audit trail for compliance
+verification.
+
+# Useful Resources
+
+Here are some useful resources where you can follow and learn more about the best practices mentioned:
+
+1. **National Institute of Standards and Technology (NIST)**
+   - **NIST Cybersecurity Framework:** A comprehensive resource for implementing cybersecurity best practices and
+   complying with regulatory requirements.
+   - URL: [https://www.nist.gov/cyberframework](https://www.nist.gov/cyberframework)
+
+2. **International Organization for Standardization (ISO)**
+   - **ISO/IEC 27001 Information Security Management:** The leading international standard for information security
+   management, providing guidelines for establishing, implementing, and maintaining an effective security program.
+   - URL:
+   [https://www.iso.org/isoiec-27001-information-security.html](https://www.iso.org/isoiec-27001-information-security.html)
+
+3. **Center for Internet Security (CIS)**
+   - **CIS Controls:** A prioritized set of actions that help organizations comply with regulatory requirements and
+   improve their cybersecurity posture.
+   - URL: [https://www.cisecurity.org/controls/](https://www.cisecurity.org/controls/)
+
+4. **General Data Protection Regulation (GDPR)**
+   - **Official GDPR Portal:** Provides detailed information on GDPR requirements, including guidelines, tools, and
+   resources for compliance.
+   - URL: [https://gdpr.eu/](https://gdpr.eu/)
+
+5. **Health Insurance Portability and Accountability Act (HIPAA)**
+   - **HIPAA Journal:** Offers news, resources, and guidelines for ensuring compliance with HIPAA regulations,
+   particularly in the healthcare sector.
+   - URL: [https://www.hipaajournal.com/](https://www.hipaajournal.com/)
+
+6. **Payment Card Industry Data Security Standard (PCI DSS)**
+   - **Official PCI Security Standards Council:** Provides comprehensive resources, including guidelines and tools for
+   complying with PCI DSS requirements.
+   - URL: [https://www.pcisecuritystandards.org/](https://www.pcisecuritystandards.org/)
+
+7. **Cybersecurity & Infrastructure Security Agency (CISA)**
+   - **CISA Best Practices:** Offers guidelines and resources for improving cybersecurity, including incident response
+   planning and third-party risk management.
+   - URL: [https://www.cisa.gov/publication/best-practices](https://www.cisa.gov/publication/best-practices)
+
+8. **Cloud Security Alliance (CSA)**
+   - **CSA Security Guidance for Cloud Computing:** Provides best practices and guidance for ensuring compliance and
+   security in cloud environments.
+   - URL:
+   [https://cloudsecurityalliance.org/artifacts/security-guidance-v4/](https://cloudsecurityalliance.org/artifacts/security-guidance-v4/)
+
+9. **International Association of Privacy Professionals (IAPP)**
+   - **IAPP Resource Center:** Offers a wealth of resources, including whitepapers, research, and tools, to help
+   organizations comply with data protection regulations.
+   - URL: [https://iapp.org/resources/](https://iapp.org/resources/)
+
+10. **SANS Institute**
+
+- **SANS Security Resources:** Provides extensive resources, including guides, whitepapers, and training courses,
+for improving security and regulatory compliance.
+- URL: [https://www.sans.org/security-resources/](https://www.sans.org/security-resources/)
+
+---
+
+---
+
diff --git a/scripts/data/eval-briefs/sfc-workspace-security.md b/scripts/data/eval-briefs/sfc-workspace-security.md
new file mode 100644
index 00000000..58cb5731
--- /dev/null
+++ b/scripts/data/eval-briefs/sfc-workspace-security.md
@@ -0,0 +1,3975 @@
+# Evaluation Brief: sfc-workspace-security
+
+## TASK
+
+For each control below, evaluate whether the candidate framework pages ACTUALLY meet the baseline requirements.
+A page must SUBSTANTIVELY address the baseline — not just mention related keywords.
+Be strict: if a baseline says "reviewed at least annually" and the page doesn't mention review cadence, that baseline is NOT met.
+
+## CONTROLS (23 total)
+
+### ws-1.1.1: Workspace Security Owner
+**Question:** Is there a clearly designated person or team accountable for workspace security?
+**Baselines (1):**
+  1. Accountability scope covers policy maintenance, device and account standards, access control oversight, periodic reviews, and incident escalation
+**Candidate pages:** /opsec/core-concepts/security-fundamentals, /opsec/principles/principles, /opsec/travel/guide
+
+### ws-1.1.2: Workspace Security Policy
+**Question:** Do you maintain a workspace security policy that is accessible and understood by all personnel?
+**Baselines (3):**
+  1. Policy covers core expectations including device security, account hygiene, credential management, acceptable use, and incident reporting
+  2. Written in plain language so all personnel can follow it
+  3. Policy reviewed at least annually and after significant changes (security incidents, technology shifts, organizational restructuring)
+**Candidate pages:** /opsec/travel/guide, /awareness/understanding-threat-vectors, /awareness/cultivating-a-security-aware-mindset
+
+### ws-1.1.3: Asset Inventory
+**Question:** Do you maintain an inventory of organizational devices and accounts with defined ownership?
+**Baselines (4):**
+  1. Scoped to devices and accounts with access to sensitive systems or data
+  2. Device inventory tracks make/model, owner, OS version, encryption status, and EDR/MDM enrollment
+  3. Account inventory covers organizational accounts (eg. email, cloud, social media) with defined ownership
+  4. Updated as devices/accounts are provisioned or decommissioned
+**Candidate pages:** /opsec/travel/guide, /encryption/volume-encryption, /encryption/partition-encryption
+
+### ws-1.1.4: System and Data Classification
+**Question:** Do you classify systems and data by sensitivity to determine appropriate security controls?
+**Baselines (3):**
+  1. Classification levels defined (e.g., critical, high, standard)
+  2. Classification determines which controls apply (access restrictions, monitoring, encryption, backup requirements)
+  3. Classification reviewed when systems, data sensitivity, or organizational structure change
+**Candidate pages:** /opsec/travel/guide, /opsec/control-domains/technical, /opsec/core-concepts/security-fundamentals
+
+### ws-2.1.1: Device Security Standards
+**Question:** Do you define and enforce security standards for organizational devices?
+**Baselines (7):**
+  1. Full disk encryption enabled on all devices
+  2. Automatic OS and application patching enabled or enforced
+  3. Strong authentication required (password/biometric, auto-lock timeouts, lock screens)
+  4. Administrative privileges separated from daily-use accounts
+  5. Devices procured through verified supply chains and verified for integrity upon receipt
+  6. Device compliance verified upon provisioning and monitored on an ongoing basis
+  7. BYOD policy defining what personal devices can access and the security controls required (e.g., MDM enrollment, separate work profiles)
+**Candidate pages:** /opsec/travel/guide, /encryption/volume-encryption, /encryption/partition-encryption
+
+### ws-2.1.2: Device Lifecycle Management
+**Question:** Do you have procedures for device loss, theft, and secure decommissioning?
+**Baselines (3):**
+  1. Remote lock and wipe capability for all organizational devices
+  2. Documented procedures for responding to lost or stolen devices (notification, remote wipe, credential rotation, incident escalation)
+  3. Secure decommissioning procedures including data sanitization and verified destruction for storage media
+**Candidate pages:** /opsec/travel/guide, /opsec/control-domains/technical, /opsec/control-domains/physical-environmental
+
+### ws-2.1.3: Endpoint Protection
+**Question:** Do you deploy and monitor endpoint protection on organizational devices?
+**Baselines (4):**
+  1. EDR or MDM deployed on all organizational devices with documented coverage
+  2. Alert triage and response procedures defined with severity-based escalation
+  3. Compliance enforcement actions documented (e.g., quarantine non-compliant devices, block access)
+  4. Monitoring coverage includes detection of malware, unauthorized software, and policy violations
+**Candidate pages:** /opsec/core-concepts/security-fundamentals, /opsec/travel/guide, /guides/account_management/discord
+
+### ws-2.1.4: Physical and Travel Security
+**Question:** Do you maintain physical security requirements for workspaces and travel?
+**Baselines (6):**
+  1. Physical workspace requirements defined for both on-site and remote work environments
+  2. Screen privacy and shoulder-surfing awareness enforced
+  3. Travel security procedures documented covering device handling, network usage, and border crossings
+  4. High-risk travel procedures defined (loaner devices, enhanced controls, check-in schedules)
+  5. USB and charging security addressed (data blockers, no public USB ports)
+  6. Devices physically secured when not in active use (cable locks, safes, carry-on luggage for travel)
+**Candidate pages:** /opsec/travel/guide, /opsec/control-domains/physical-environmental, /opsec/core-concepts/security-fundamentals
+
+### ws-3.1.1: Account Lifecycle Management
+**Question:** Do you have procedures for provisioning, modifying, and revoking user accounts?
+**Baselines (5):**
+  1. Account creation requires documented approval from the account owner's manager or designated authority
+  2. Accounts provisioned with minimum necessary permissions (least privilege)
+  3. Modification of account permissions requires documented approval
+  4. Account revocation procedures tied to offboarding and role changes
+  5. Service accounts and shared credentials inventoried with defined ownership
+**Candidate pages:** /guides/account_management/discord, /opsec/travel/guide, /dprk-it-workers/techniques-tactics-and-procedures
+
+### ws-3.1.2: Multi-Factor Authentication
+**Question:** Do you enforce multi-factor authentication across organizational accounts?
+**Baselines (5):**
+  1. MFA required for all organizational accounts by default
+  2. Hardware security keys required for high-privilege and critical accounts (admin, infrastructure, custody)
+  3. Phishing-resistant MFA preferred (FIDO2/WebAuthn, hardware keys) over SMS or TOTP where available
+  4. Exceptions documented with justification, compensating controls, and expiry date
+  5. Backup MFA methods configured for account recovery
+**Candidate pages:** /opsec/travel/guide, /opsec/control-domains/technical, /guides/account_management/discord
+
+### ws-3.1.3: Organizational Account Security
+**Question:** Do you maintain security standards for all organizational accounts, including enterprise platforms and external services?
+**Baselines (5):**
+  1. Security configuration standards defined and applied for enterprise platforms (Google Workspace, Microsoft 365, collaboration tools)
+  2. Social media and public-facing accounts secured with strong authentication and defined ownership
+  3. Ownership verified and documented for all organizational accounts
+  4. Recovery methods restricted to organizational channels (no personal recovery emails or phone numbers on organizational accounts)
+  5. Account configurations reviewed periodically for drift or unauthorized changes
+**Candidate pages:** /opsec/travel/guide, /guides/account_management/discord, /opsec/core-concepts/security-fundamentals
+
+### ws-3.1.4: Credential Management Standards
+**Question:** Do you enforce credential management standards, including secure storage and individual accountability?
+**Baselines (7):**
+  1. Password manager required for all personnel; no passwords stored in plain text, documents, or browsers
+  2. Unique, strong passwords for every account (minimum length/complexity standards defined)
+  3. Individual accounts required for all personnel — no sharing of personal login credentials
+  4. When credentials must be provisioned or shared (e.g., service accounts, API keys, onboarding), transmission only through encrypted channels (password manager sharing features, not email or chat)
+  5. Credential rotation schedule defined based on risk; rotation triggered immediately after suspected compromise
+  6. Enhanced controls for high-privilege credentials (admin accounts, service accounts, API keys) including stricter rotation, separate storage, and logged access
+  7. Service account and API key inventory maintained with defined ownership
+**Candidate pages:** /opsec/travel/guide, /awareness/cultivating-a-security-aware-mindset, /guides/account_management/telegram
+
+### ws-3.1.5: Access Reviews
+**Question:** Do you conduct periodic access reviews and promptly adjust permissions when roles change?
+**Baselines (5):**
+  1. Scheduled access reviews at least quarterly for critical systems, annually for others
+  2. Access adjusted within defined timelines when employees change roles
+  3. Reviews verify each user still requires their current level of access
+  4. Unnecessary permissions revoked promptly with documented evidence
+  5. Insider threat consideration included — for each role, assess what damage could be done with current access
+**Candidate pages:** /opsec/core-concepts/security-fundamentals, /guides/account_management/discord, /opsec/travel/guide
+
+### ws-4.1.1: Software Evaluation and Approval
+**Question:** Do you evaluate and approve software, extensions, and tools before organizational use?
+**Baselines (5):**
+  1. Evaluation criteria for all software before adoption (browsers, extensions, IDEs, libraries, AI assistants, SaaS tools)
+  2. Data privacy and leakage risks assessed (does the tool send data to third parties for training or analytics?)
+  3. Approved software list maintained; unapproved software restricted
+  4. Browser extension approval process defined
+  5. Dependency management includes version pinning, vulnerability scanning, and update policies
+**Candidate pages:** /opsec/travel/guide, /opsec/core-concepts/security-fundamentals, /opsec/core-concepts/implementation-process
+
+### ws-4.1.2: Source Code and Repository Security
+**Question:** Do you secure source code repositories against unauthorized access and credential exposure?
+**Baselines (5):**
+  1. Role-based access control with least-privilege permissions
+  2. Branch protection rules enforced on critical branches (require reviews, signed commits)
+  3. Automated secret scanning enabled to detect credentials, API keys, and private keys in code
+  4. Pre-commit hooks or CI checks to prevent secrets from being committed
+  5. Repository security audited periodically (access permissions, configuration, open PRs)
+**Candidate pages:** /guides/account_management/github, /opsec/travel/guide, /opsec/core-concepts/security-fundamentals
+
+### ws-5.1.1: Network Security
+**Question:** Do you enforce secure network access for organizational systems?
+**Baselines (4):**
+  1. VPN or zero-trust network access required for accessing internal resources remotely
+  2. Wi-Fi security standards defined (no auto-connect, avoid public Wi-Fi for sensitive operations)
+  3. Network segmentation applied where applicable (separate guest networks, development environments)
+  4. Cellular or personal hotspot preferred over public Wi-Fi for sensitive work
+**Candidate pages:** /opsec/travel/guide, /opsec/core-concepts/security-fundamentals, /opsec/control-domains/technical
+
+### ws-5.1.2: Secure Communications
+**Question:** Do you secure organizational communications and verify identity for sensitive interactions?
+**Baselines (5):**
+  1. End-to-end encrypted channels used for sensitive communications
+  2. Identity verification procedures established for sensitive requests (e.g., access changes, financial approvals, credential sharing)
+  3. Anti-impersonation protocols documented (e.g., secondary channel verification, code words, video confirmation)
+  4. Email security configured (SPF, DKIM, DMARC) to prevent spoofing
+  5. Procedures for channel compromise including switching to backup channels
+**Candidate pages:** /opsec/travel/guide, /guides/account_management/telegram, /opsec/control-domains/technical
+
+### ws-6.1.1: Security Onboarding
+**Question:** Do you verify employee identity and provide security onboarding before granting system access?
+**Baselines (5):**
+  1. Identity and authorization verified before any access is provisioned
+  2. Background checks or identity verification appropriate to role sensitivity
+  3. Security onboarding includes device provisioning, account creation, MFA setup, and initial security training
+  4. New personnel acknowledge security policies before access is granted
+  5. Onboarding checklist documented and consistently applied
+**Candidate pages:** /opsec/travel/guide, /opsec/control-domains/people, /opsec/core-concepts/security-fundamentals
+
+### ws-6.1.2: Security Offboarding
+**Question:** Do you have comprehensive offboarding procedures for departing personnel?
+**Baselines (5):**
+  1. All account access revoked within 24 hours of departure
+  2. Devices returned and verified for data sanitization
+  3. Credentials and secrets rotated for any shared systems the departing person accessed
+  4. Offboarding checklist documented covering: account deprovisioning, device return, credential rotation, access to organizational repositories and tools, recovery of company property
+  5. Involuntary departures trigger immediate access revocation before notification where feasible
+**Candidate pages:** /opsec/travel/guide, /awareness/understanding-threat-vectors, /guides/account_management/discord
+
+### ws-6.1.3: Security Awareness and Training
+**Question:** Do you maintain a security awareness program with regular training and testing?
+**Baselines (5):**
+  1. Training covers workspace security topics: phishing, social engineering, device security, credential hygiene, and incident reporting
+  2. Phishing simulations conducted at least quarterly
+  3. Follow-up training required for personnel who fail simulations
+  4. Training content updated annually and after significant threats or procedure changes
+  5. Covers crypto-specific risks: fake job offers, malicious browser extensions, clipboard hijacking, social engineering via DMs
+**Candidate pages:** /awareness/staying-informed-and-continuous-learning, /opsec/control-domains/people, /opsec/appendices/case-studies
+
+### ws-7.1.1: Workspace Security Monitoring and Incident Response
+**Question:** Do you detect and respond to workspace security incidents?
+**Baselines (5):**
+  1. Monitoring in place for common workspace threats: account takeovers, unauthorized access, credential leaks, device compromise, data exfiltration
+  2. Response procedures documented for key scenarios: compromised account, compromised device, data leak, insider threat event
+  3. Escalation paths defined with severity levels
+  4. Credential leak monitoring (dark web, breach databases, paste sites, code repositories)
+  5. Incidents documented with timeline, root cause, actions taken, and lessons learned
+**Candidate pages:** /opsec/core-concepts/security-fundamentals, /opsec/appendices/case-studies, /opsec/travel/guide
+
+### ws-7.1.2: Insider Threat Assessment
+**Question:** Do you assess insider threat risks and enforce least-privilege access for each role?
+**Baselines (4):**
+  1. Damage scenarios documented for each role (what could this person do if compromised or malicious?)
+  2. Least-privilege access enforced across all systems
+  3. Separation of duties applied for critical operations (e.g., no single person can deploy to production, execute large transactions, and manage access controls)
+  4. Assessed during periodic access reviews
+**Candidate pages:** /opsec/core-concepts/security-fundamentals, /opsec/travel/guide, /opsec/control-domains/people
+
+### ws-7.1.3: Third-Party Access Management
+**Question:** Do you manage third-party access with time-limited, purpose-specific permissions?
+**Baselines (5):**
+  1. Third-party access requires documented approval with defined scope and expiry date
+  2. Access limited to minimum necessary systems and data
+  3. Access revoked automatically upon contract expiry or project completion
+  4. Audit trails maintained for all third-party access
+  5. Third-party vendor security evaluated before granting access (security certifications, incident history)
+**Candidate pages:** /opsec/core-concepts/security-fundamentals, /opsec/appendices/glossary, /guides/account_management/discord
+
+---
+
+## FRAMEWORK PAGES (18 unique)
+
+### PAGE: /opsec/core-concepts/security-fundamentals
+**Title:** Security Fundamentals
+**Referenced by controls:** ws-1.1.1, ws-1.1.4, ws-2.1.3, ws-2.1.4, ws-3.1.3, ws-3.1.5, ws-4.1.1, ws-4.1.2, ws-5.1.1, ws-6.1.1, ws-7.1.1, ws-7.1.2, ws-7.1.3
+
+# Security Fundamentals
+
+
+
+
+> 🔑 **Key Takeaway**: Effective security operations are built on five practical fundamentals: layered protective
+> measures, minimized access scopes, controlled information flows, system isolation, and continuous visibility — working
+> together to secure critical assets in dynamic environments.
+
+## Relationship to Implementation Process
+
+This document outlines the foundational security approaches that should be embedded throughout your organization's
+operations. They complement the practical
+[Operational Implementation Process](/opsec/core-concepts/implementation-process),
+which defines specific action steps:
+
+- These fundamentals establish **enduring approaches** that shape your security architecture
+- The implementation process provides a **sequential workflow** for security teams to follow
+
+While these fundamentals provide the security principles that should be consistently applied across your environment,
+the implementation process offers a structured methodology for putting security into practice. Both elements must work
+in concert - these fundamentals guide your overall approach, while the implementation process provides the tactical
+roadmap.
+
+For organizations just beginning their security journey, start with the
+[Operational Implementation Process](/opsec/core-concepts/implementation-process) for concrete steps.
+
+The ultimate goal is to prevent unauthorized access to systems and information that could cause operational, financial,
+or reputational harm if compromised.
+
+> **Practical Example: Web3 Organization**
+>
+> Consider a Web3 project managing a DeFi protocol with a treasury of $10M in assets. Practical security fundamentals in
+> action include:
+>
+> - **Layered protection**: Hardware security modules for key storage, multi-signature requirements (3-of-5) for
+> transactions, automated monitoring for unusual patterns, and regular third-party security audits
+> - **Minimal access scopes**: Deployment keys accessible only to specific DevOps team members, with different
+> permission levels strictly enforced between development, staging, and production environments
+> - **Information flow control**: Private keys for multi-signature wallets distributed among trusted team members based
+> on role, with sensitive incident response procedures restricted to the security team
+> - **System isolation**: Clear separation between development environments and production systems, with treasury
+> management isolated from day-to-day operations
+> - **Continuous visibility**: Real-time monitoring systems tracking transaction patterns, weekly security reviews, and
+> quarterly penetration tests with findings addressed in prioritized sprints
+
+## 1. Layered Protection
+
+Implement multiple overlapping security controls so that if one mechanism fails, others will continue to protect your
+assets.
+
+> **🔗 Related Framework:** This approach is reinforced in frameworks like [Infrastructure](/infrastructure/overview)
+> with [Zero-Trust Principles](/infrastructure/zero-trust-principles) and
+> [Network Security](/infrastructure/network-security).
+
+### Practical Application
+
+1. Implement multiple defensive mechanisms that protect against the same risks using different methods
+   - Example: Protect admin interfaces using network ACLs, MFA, time-limited access windows, and anomaly detection
+2. Deploy protection at each layer of your technology stack
+   - Network layer: Firewalls, network segmentation, DDoS protection
+   - Host layer: Endpoint protection, host-based IDS, secure configuration
+   - Application layer: Input validation, output encoding, API security
+   - Data layer: Encryption, access controls, data loss prevention
+3. Identify and eliminate single points of failure in your security architecture
+   - Map defense coverage to ensure overlapping protections
+   - Document security dependencies and create contingency plans
+4. Test defensive layers regularly through realistic scenarios
+   - Conduct tabletop exercises focused on specific defensive failures
+   - Use red team exercises to validate defense-in-depth effectiveness
+5. Maintain a continuous improvement cycle for each defensive layer
+   - Review and update security controls after incidents or near-misses
+   - Track industry developments to identify emerging defensive tactics
+
+## 2. Minimal Access Scopes
+
+Grant users, systems, and processes only the specific permissions they need to perform their required functions and
+nothing more.
+
+> **🔗 Related Framework:** For detailed implementation, see [Identity and Access Management](/iam/overview) and
+> [Role-Based Access Control](/iam/role-based-access-control).
+
+### Practical Application
+
+1. Implement a structured permission model that starts with zero access
+   - Default deny: Require explicit permission grants for all access
+   - Document justification for each permission granted
+   - Create standardized role templates for common job functions
+2. Establish automated processes for access lifecycle management
+   - Onboarding: Provision minimal initial access based on role
+   - Role changes: Adjust permissions when responsibilities change
+   - Offboarding: Remove all access immediately upon departure
+3. Apply time-based restrictions to elevated privileges
+   - Use just-in-time access for administrative functions
+   - Implement automatic session termination after periods of inactivity
+   - Require re-authentication for sensitive operations
+4. Conduct regular access reviews with verification
+   - Quarterly: Review all privileged accounts and service accounts
+   - Semi-annually: Audit all standard user accounts and group memberships
+   - Use automated tools to identify inactive or excessive permissions
+5. Implement technical controls to enforce minimal access
+   - Application permissions: API scopes, feature flags, entitlement checks
+   - Infrastructure permissions: IAM policies, network ACLs, resource policies
+   - Database permissions: Row-level security, column-level controls
+
+## 3. Information Flow Control
+
+Ensure sensitive information is only accessible to those with a legitimate need to know, with restrictions on how that
+information can be shared and used.
+
+{/* > **🔗 Related Framework:** This approach is supported by practices in [Data
+Protection](/opsec/old/data-protection/overview) and aspects of [Privacy](/privacy/overview). */}
+
+### Practical Application
+
+1. Implement a practical data classification system with clear handling requirements
+   - Public: Information approved for general distribution
+   - Internal: Business information for employee use only
+   - Confidential: Sensitive information requiring specific protections
+   - Restricted: Critical information with strictly controlled access
+2. Define and enforce data handling procedures for each classification level
+   - Storage requirements: Where information can be stored
+   - Transmission rules: How information can be sent/shared
+   - Processing restrictions: How information can be used
+   - Retention limits: How long information should be kept
+3. Deploy technical controls to enforce information flow policies
+   - Data loss prevention tools to monitor and block unauthorized sharing
+   - Encryption for data at rest and in transit based on sensitivity
+   - Information rights management for persistent protection
+4. Establish secure channels for different types of communication
+   - High-sensitivity: End-to-end encrypted messaging with disappearing messages
+   - Medium-sensitivity: Encrypted collaboration platforms with access controls
+   - Low-sensitivity: Standard business communication tools
+5. Train users on practical information handling procedures
+   - Provide clear guidelines with concrete examples
+   - Use realistic scenarios in training materials
+   - Conduct periodic verification checks
+
+## 4. System Isolation
+
+Segment systems and networks into isolated zones to contain security breaches and limit lateral movement.
+
+### Practical Application
+
+1. Implement network segmentation based on security requirements
+   - Create security zones with consistent trust levels
+   - Implement strict traffic control between zones
+   - Document and regularly review allowed communication paths
+2. Establish environment separation with controlled boundaries
+   - Maintain distinct development, testing, staging, and production environments
+   - Implement one-way data flows from higher to lower environments
+   - Control code promotion processes between environments
+3. Isolate high-value systems with enhanced protection
+   - Place critical infrastructure on dedicated hardware
+   - Example: Run blockchain nodes on dedicated hardware isolated from general workstations
+   - Implement jump servers or privileged access workstations for administrative access
+4. Apply micro-segmentation where appropriate
+   - Container isolation: Enforce pod security policies and network policies
+   - Application segmentation: Implement service meshes with mutual TLS
+   - Process isolation: Use containerization, virtualization, or sandboxing
+5. Monitor and enforce boundary controls
+   - Implement egress filtering to control outbound connections
+   - Deploy internal firewalls between segments
+   - Use network monitoring to detect unauthorized communication attempts
+
+## 5. Continuous Visibility
+
+Maintain ongoing awareness of your security posture through active monitoring, testing, and continuous improvement.
+
+> **🔗 Related Framework:** For implementation details, see the [Monitoring](/monitoring/overview) framework, including
+> [Guidelines](/monitoring/guidelines) and [Thresholds](/monitoring/thresholds). Also relevant is
+> [Incident Management](/incident-management/overview) for response to detected issues.
+
+### Practical Application
+
+1. Implement a multi-layered monitoring strategy
+   - System monitoring: Performance, availability, and system integrity
+   - Security monitoring: Threat detection, anomaly identification, and correlation
+   - Compliance monitoring: Policy enforcement and regulatory requirements
+   - Establish clear ownership for each monitoring domain
+2. Define actionable metrics tied to security objectives
+   - Leading indicators: Metrics that help predict future issues
+   - Example: Percentage of systems with current patches
+   - Lagging indicators: Metrics that measure past performance
+   - Example: Mean time to detect and respond to incidents
+3. Establish a regular testing cadence to validate security controls
+   - Vulnerability scanning: Weekly automated scans
+   - Penetration testing: Quarterly focused tests on critical systems
+   - Red team exercises: Annual comprehensive assessments
+4. Implement a structured incident management process
+   - Define clear incident response procedures with specific roles
+   - Conduct regular tabletop exercises to practice response
+   - Perform thorough post-incident reviews focused on improvement
+   - Create feedback loops to security controls based on incidents
+5. Maintain an active threat intelligence program
+   - Collect intelligence relevant to your specific environment
+   - Analyze and contextualize threats for your organization
+   - Disseminate actionable intelligence to appropriate teams
+   - Use threat intelligence to drive security improvements
+
+---
+
+---
+
+### PAGE: /opsec/principles/principles
+**Title:** OpSec Core Principles
+**Referenced by controls:** ws-1.1.1
+
+# Operational Security Principles
+
+
+
+
+> 🔑 **Key Takeaway**: Effective OpSec relies on five core principles: layered defenses, minimal access rights,
+> need-to-know information sharing, system compartmentalization, and continuous monitoring—all working together to
+> protect sensitive information from adversaries.
+
+The goal is to prevent adversaries from gaining access to information that could be harmful if disclosed or compromised.
+
+> **Practical Example: Web3 Organization**
+>
+> Consider a Web3 project managing a DeFi protocol with a treasury of $10M in assets. Proper operational security would
+> involve:
+>
+> - **Multiple security layers**: Hardware wallets for cold storage, multi-signature requirements for transactions,
+> regular security audits, and continuous monitoring
+> - **Access control**: Only specific team members have access to deployment keys, with different permission levels for
+> development, testing, and production environments
+> - **Compartmentalized information**: Private keys for multi-signature wallets are distributed among trusted team
+> members with no single person having access to all keys, and sensitive incident response procedures are only shared
+> with the security team
+> - **Regular threat assessment**: The team conducts quarterly reviews of potential attack vectors, from smart contract
+> vulnerabilities to [social engineering](/awareness/understanding-threat-vectors) attempts targeting team members
+
+## 1. Defense in Depth
+
+Defense in Depth is the practice of layering security controls throughout your systems and processes, so that if one
+control fails, others will provide protection.
+
+> **🔗 Related Framework:** This principle is applied across multiple frameworks including
+> [Infrastructure](/infrastructure/overview) with [Zero-Trust Principles](/infrastructure/zero-trust-principles) and
+> [Network Security](/infrastructure/network-security).
+
+### Implementation
+
+1. Deploy multiple security controls that address the same risk in different ways
+2. Implement security at various layers: physical, technical, administrative, and human
+3. Ensure no single point of failure exists in your security architecture
+4. Review the effectiveness of security layers regularly to identify gaps
+5. Foster a [security-aware mindset](/awareness/cultivating-a-security-aware-mindset) across all team members
+
+## 2. Principle of Least Privilege
+
+The Principle of Least Privilege dictates that users, systems, and processes should have only the minimum access rights
+necessary to perform their functions.
+
+> **🔗 Related Framework:** For comprehensive implementation, see [Identity and Access Management](/iam/overview) and
+> [Role-Based Access Control](/iam/role-based-access-control).
+
+### Implementation
+
+1. Grant the minimum level of access required for users to perform their duties
+2. Review and adjust access rights when roles change
+3. Implement role-based access control (RBAC) to standardize permissions
+4. Use time-limited and just-in-time access for administrative privileges
+5. Regularly audit access rights to identify and remove excessive permissions
+6. Establish a thorough offboarding process to immediately revoke access when team members leave
+7. Remove credentials for deactivated accounts, as these can become security liabilities even when dormant
+
+## 3. Need-to-Know Basis
+
+Information should only be shared with individuals who require that information to perform their duties.
+
+> **🔗 Related Framework:** This principle is supported by practices in [Data
+> Protection](/opsec/old/data-protection/overview) and aspects of [Privacy](/privacy/overview).
+
+### Implementation
+
+1. Classify information based on sensitivity and restrict access accordingly
+2. Compartmentalize sensitive information to limit exposure in case of a breach
+3. Implement clear data handling and sharing policies
+4. Train team members on proper handling and sharing of sensitive information through regular [security
+training]
+{/*TODO: "/awareness/security-training" is this link this: /awareness/cultivating-a-security-aware-mindset ? */}
+5. Use secure communication channels for sensitive information
+
+## 4. Compartmentalization
+
+Dividing information and systems into isolated segments to limit the impact of a breach.
+
+### Implementation
+
+1. Segment networks and systems based on functionality and sensitivity
+2. Isolate critical assets from general-purpose systems
+3. Separate development, testing, and production environments
+4. Use separate accounts and access methods for different security domains
+5. Implement firewalls and access controls between segments
+
+## 5. Continuous Monitoring and Improvement
+
+Security is not a one-time implementation but a continuous process of monitoring, evaluating, and improving.
+
+> **🔗 Related Framework:** For implementation details, see the [Monitoring](/monitoring/overview) framework, including
+> [Guidelines](/monitoring/guidelines) and [Thresholds](/monitoring/thresholds). Also relevant is
+> [Incident Management](/incident-management/overview) for response to detected issues.
+
+### Implementation
+
+1. Establish security metrics to measure the effectiveness of controls
+2. Implement monitoring systems to detect security events and anomalies
+3. Conduct regular security assessments and penetration tests
+4. Learn from security incidents and near-misses
+5. Update security controls based on new threats, vulnerabilities, and technologies
+6. Ensure team members are
+[staying informed and continuously learning](/awareness/staying-informed-and-continuous-learning)
+about evolving security threats
+7. Utilize available [security resources](/awareness/resources-and-further-reading) to keep your security practices
+current
+
+---
+
+---
+
+### PAGE: /opsec/travel/guide
+**Title:** Travel Security Guide
+**Referenced by controls:** ws-1.1.1, ws-1.1.2, ws-1.1.3, ws-1.1.4, ws-2.1.1, ws-2.1.2, ws-2.1.3, ws-2.1.4, ws-3.1.1, ws-3.1.2, ws-3.1.3, ws-3.1.4, ws-3.1.5, ws-4.1.1, ws-4.1.2, ws-5.1.1, ws-5.1.2, ws-6.1.1, ws-6.1.2, ws-7.1.1, ws-7.1.2
+
+# Personal security travel guide — full
+
+
+
+
+Travel introduces unique security risks to your digital assets and sensitive information. Proper preparation before,
+vigilance during, and careful review after travel creates a comprehensive defense strategy that balances security
+with practical usability.
+
+When we travel, our normal security routines are disrupted, and we face elevated risks from physical theft, digital
+surveillance, border inspections, and social engineering. Web3 professionals face additional challenges when traveling
+with crypto assets or access to treasury funds. The resources in this guide provide practical guidance for maintaining
+operational security while traveling.
+
+> 🔑 Key Takeaway: Minimize data exposure by carrying only essential devices with full-disk encryption and updated
+> software. Secure accounts with backup 2FA methods, avoid biometrics at borders, use trusted networks with VPNs, and
+> never leave devices unattended. Guard against USB attacks, shoulder surfing, and hidden cameras. For crypto, use
+> strong passphrases and never travel with seed phrases. Upon returning, scan devices for malware and consider resetting
+> high-risk devices.
+
+{/* separator */}
+
+> ❗ This is not, by any means, an extensive guide on this subject or expected to be followed at its core. Its intention
+> is to guide and provide hints as to where to apply security. This will vary depending on case to case, or, in other
+> words, the risks you expose yourself to, by specifically traveling.
+
+This guide is categorized into four sections:
+
+1. **Before traveling:** All the things you could do before you depart, such as hardening some devices or making sure
+you have a backup of the data you’ll be traveling with, even letting know someone you’ll be calling in case of an
+emergency and how to identify you. This does not necessarily mean that if you’re reading this while traveling you cannot
+do anything from that list, only that it might be more challenging to execute depending on your context.
+2. **While traveling:** All the things you have to pay attention to or take care of while on the move. Is it necessary
+to connect to that conference’s WiFi? Have you checked if there is a camera that might be recording your keystrokes?
+Leaving your computer unattended or just running whatever software your hackathon teammate asks you to download in order
+for your promising project to win.
+3. **Returning home:** Not in the literal sense of it, but directed toward all the things you have to do after your
+travels. From updating your processes based on experience to wiping exposed devices before rejoining them to your
+networks.
+4. **Additional information for high-profile targets:** If you are a high-profile target, you’ll evidently realize that
+some of these initial suggestions fall short within your threat model. This section provides a hint toward profiles like
+yours.
+
+## Before traveling
+
+> 💡**Remove or securely store** any data, devices, printed files, and documents **you don’t absolutely need on the
+> trip**. The less sensitive information and fewer critical assets you carry, the lower the risk and impact if loss,
+> theft, or inspection occurs. Minimize your digital and physical footprint by leaving backups and originals securely at
+> home or in trusted locations, and encrypt what must travel with you. This principle applies to laptops, phones,
+> hardware wallets, paper backups, and any portable storage media.
+
+### **Perform a quick threat model**
+
+Even if you are already traveling, take 5 minutes to map out your risks. Identify **what assets** you're carrying
+(laptops, phones, hardware wallets, seed phrases, account access), **who might target them** (thieves, cybercriminals,
+border agents, etc.), and **how attacks might happen** (device theft, tampering, malware, coercion). For each threat,
+plan a mitigation. For example, if you're carrying a hardware wallet, a threat is pickpocketing – mitigation could be
+keeping it attached to yourself (just don't use ledger's necklace visibly) and securing it with a secure PIN/passphrase
+(no patterns, not repeated across devices).
+
+This exercise keeps security measures proportionate to your situation.
+
+### **Secure devices with encryption & updates**
+
+Enable full-disk encryption on all devices (laptops, phones, tablets) to protect data if lost or stolen. Most modern
+OSes have this by default (e.g. BitLocker for Windows, FileVault for MacOS, LUKS for Linux,or Android/iOS encryption –
+just ensure a strong password/PIN is set).
+
+Use popular devices like iPhones and Pixels. Install the latest OS and app updates since these patch security
+vulnerabilities. This does not mean that using the latest versions is the safest take, but usually there's a balanced
+trade-off when they got security patches. You can also consider to install — only trustworthy — mobile security
+applications, which try to add a layer of control and also reminds you of important security updates.
+
+**Note:** On iOS, due to sandboxing, apps can't scan the entire OS for malware, so many security apps focus on VPN,
+phishing web protection, breach alerts, etc.
+
+If you must bring high-risk confidential data, consider encrypting those files individually using tools like VeraCrypt,
+FileVault, BitLocker, LUKS/dm-crypt, and more.
+
+### **Back up and prepare for loss**
+
+Back up your devices before travel (and ensure cloud backups like iCloud/Google are up to date). This way, if a device
+is lost or confiscated, you won’t lose important information. Record device details (make, model, serial numbers, IMEI
+for phones) and keep that list separate – it will help in filing reports or remote-wipe commands.
+
+If your company uses Mobile Device Management (MDM) on phones or laptops, verify the device is enrolled and you know how
+to trigger a remote wipe or “lost mode.” Test “Find My” or equivalent device-finding services so you can use them if
+needed. Pack chargers and cables so you won’t need to borrow unknown ones (which could be malicious).
+
+### **Protect Accounts with 2FA redundancy**
+
+Plan for how you'll access accounts that use two-factor authentication if your main device is unavailable. For
+authenticator apps (TOTP codes), **export backup codes** for your important accounts and keep them **securely** in
+services like 1Password or NordPass (you can check passwordmanager.com for more information on which one to pick).
+Alternatively, consider storing them elsewhere physically. If your 2FA is tied to a phone number (SMS or voice),
+**disable SMS for 2FA**. For technologies that are unfortunately dependent on phone numbers, use a separate line
+(not your personal one) from services like Google Voice, Burner App or SLYFONE. Transfer your number to an eSIM since
+[they are harder to physically steal or swap than a physical SIM](https://support.apple.com/en-ca/118227#:~:text=Use%20eSIM%20while%20traveling%20internationally,obtain%2C%20carry%2C%20and%20swap).
+
+Ensure your password manager is accessible – many like 1Password have a *Travel Mode* that removes sensitive vaults from
+your device while you travel (you can restore them later). This limits exposure if your
+[device is searched or seized](https://www.schneier.com/blog/archives/2025/04/cell-phone-opsec-for-border-crossings.html).
+
+You can also register a backup or alternative 2FA method, like a secondary phone (the device) or a PIN-protected
+hardware key to be used as a passkey. Be responsible with the use of software passkeys, particularly in situations
+where you are using a password manager to store both your passwords and passkeys, as this creates a single point of
+failure.
+
+### **Secure your wallets and keys**
+
+**Hardware wallets (e.g. Ledger, Trezor):** Update the firmware and test the device before you leave, don't do this
+while traveling. **Do NOT bring any written seed phrases** under any circumstance – seed backups are unencrypted keys
+that are far easier to steal or copy than a hardware device. Leave seed backups in a secure place, travel only with
+your hardware wallet if necessary. Enable all security features on the device (set a strong PIN, and use a BIP39
+passphrase for
+example, if supported) so that even if the device is stolen, the amount of required information to access your crypto,
+is high. Carry hardware wallets and security keys **in your carry-on or under your sight**, not in checked luggage, to
+avoid loss or tampering.
+
+**Yubikeys and 2FA tokens:** Bring them to protect logins and make sure they're enabled on your
+critical accounts. Keep them on your person or in a separate bag from your laptop/phone so that a thief or snoop can't
+easily steal both at once. If you have a **spare hardware wallet or Yubikey**, you might leave one at home as a backup
+in case the one you carry is lost. Add, when possible, an extra layer of security to the token, such as a PIN code.
+
+### **Lock down phones**
+
+On your smartphone, take advantage of security settings **before** you travel. Set a strong passcode (not just a 4-digit
+PIN or pattern). Consider **disabling Touch ID/Face ID** if you might face situations where someone could force-unlock
+your device using your biometrics – in many jurisdictions, authorities can compel a fingerprint or face scan more easily
+than a memorized password
+[.](https://www.schneier.com/blog/archives/2025/04/cell-phone-opsec-for-border-crossings.html#:~:text=deactivate%20biometric%20security%20and%20require,10%20failed%20PIN%20unlock%20attempts)
+At a minimum, know how to quickly and
+[**temporarily disable biometrics**](https://news.ycombinator.com/item?id=43630624);
+for example, on an iPhone,
+[holding the side button and a volume button will trigger an emergency mode that requires the passcode to unlock](https://www.themacguys.com/essential-travel-security-tips-for-apple-devices/).
+On Android, use *Lockdown* mode if available (which only temporarily disables biometrics and is different
+from iOS Lockdown Mode).
+
+If you have an iPhone, enable **Lockdown Mode** (extreme protection on iOS) even if you are not at
+[high risk or traveling to a high-threat region](https://www.themacguys.com/essential-travel-security-tips-for-apple-devices/#:~:text=This%20mode%20is%20ideal%20when,or%20dealing%20with%20sensitive%20data)
+ – but be aware [it restricts many features](https://support.apple.com/en-gb/105120), though totally worth it.
+
+Disabling or restricting USB debugging on Android and using iOS USB restricted mode helps prevent unauthorized physical
+USB access and reduces risks from malicious cables or compromised charging stations.
+
+If your phone is managed by work (MDM), inform your IT team of your travel so they can assist with any location-based
+security policies and ensure you have the latest security profile. Finally, consider using a **dedicated eSIM/local
+SIM** for travel data. This can protect your primary phone number (you can keep your main line on eSIM and turn it off,
+while using a local data eSIM for mobile internet) and avoids physical SIM issues.
+
+**Configure additional phone protections:** On iOS devices, disable Control Center and Notification Center access from
+the lock screen (Settings > Face ID & Passcode) to prevent thieves from seeing notifications or enabling Airplane Mode
+without unlocking. Disable USB accessory connections when locked to prevent unauthorized connections. For device
+recovery, ensure Find My iPhone is enabled with "Send Last Location" and "Find Network" options activated so tracking
+continues even if the device is powered off.
+
+On Android, similar protections can be configured: disable notifications on lock screen (Settings > Notifications > On
+lock screen > Don't show notifications), and enable "Find My Device" with all location services.
+
+**Pay special attention apps security**: many financial apps default to PIN verification instead of biometrics, which
+means a thief who has your phone and knows your PIN could potentially access your financial accounts even if they can't
+bypass Face ID/Touch ID. Use unique PINs for banking apps that differ from your device PIN, or where possible, configure
+these apps to require biometric verification for every login.
+
+### **Minimize digital footprint & social visibility**
+
+It's not just cyber threats – **operational security** matters. **Avoid announcing your travel plans publicly**
+[on social media](https://blackcloak.io/social-media-and-travel-be-careful-of-what-you-share/) and be careful
+with real-time updates. Posts about being away from home can signal to criminals that you (and possibly valuable
+devices or even your house) are vulnerable. Consider sharing trip photos and crypto conference highlights **after**
+you return or only with trusted contacts. Ensure your social media privacy settings are tightened so strangers can't
+see your travel posts.
+
+When registering for events, use privacy-focused tools like iOS's **Hide My Email** or create burner emails through
+providers like Tuta. ProtonMail has had some controversy lately, but could still be a good alternative. If you don't
+need to keep the inbox at all, just create a throwaway mail, there are plenty of options out there. Avoid giving out
+personal details unnecessarily during registration—use minimal, generic info to reduce your digital footprint.
+
+**Discretion** is key: if possible,
+[don't advertise that you work in crypto](https://www.unchained.com/blog/7-tips-traveling-bitcoin#:~:text=,or%20clothing%20with%20bitcoin%20logos)
+or carry cryptocurrency. For example, **remove or cover any crypto stickers on laptops or bags**, and avoid wearing
+company swag or Bitcoin/Ethereum logos while in transit. These can be neon signs attracting thieves or unwanted
+attention ("I have valuable data or wallets!"). If asked about your work or luggage by curious strangers, have a
+**cover story** (e.g. "I work in finance/IT")
+rather than "I manage a crypto fund". High-profile team members might travel under pseudonyms
+or at least not list their company on luggage tags to stay low-profile. Also, be wary that you might be traveling with
+someone with these characteristics, so don't give them away.
+
+### **Plan emergency and incident responses**
+
+Before departure, know what you'll do if something goes wrong. Have a **fallback plan** in case of device loss: who will
+you notify & how (have safe words and beware of deepfakes or impersonations); how will you revoke access to sensitive
+accounts; and how will you continue working (e.g., a backup laptop or a colleague who can step in).
+
+If traveling to
+[countries with strict tech](https://www.perplexity.ai/search/countries-that-list-cryptopgra-bBSItefPSUi7HP2lTNekjA) or
+[encryption laws](https://it.cornell.edu/security-and-policy/travel-internationally-technology#:~:text=Some%20countries%20have%20restrictions%20on,Consider%20requesting%20a%20loaner%20laptop)
+(e.g., China, Russia, UAE), devices like VPNs, encrypted messaging apps (Signal, or Telegram with Secret Chats only),
+hardware wallets (Ledger, Trezor), Yubikeys, or encryption software (VeraCrypt, BitLocker) may be flagged by border
+authorities. Research local laws beforehand. Consider carrying a travel letter from your organization explaining the
+professional need for these tools, or use sanitized loaner devices to avoid issues at border controls.
+
+Share your itinerary and contact information with a trusted peer so they can assist or monitor for any issues.
+
+Finally, schedule critical work (especially high-value transactions) for **before or after** your trip if possible, so
+you’re not forced to do ultra-sensitive actions on the road. Criminals usually play with the “time-sensitive factor,”
+trying to trick you into doing something quick and urgent, by committing something reckless.
+
+## While traveling
+
+### **Network safety – avoid untrusted Wi-Fi & Bluetooth**
+
+Treat **every network as potentially hostile**. Whenever possible, use a **cellular connection or a personal hotspot**
+instead of public Wi-Fi – your mobile data is encrypted and safer than an open café or hotel network. If you must use
+public Wi-Fi (hotel, airport, conference), verify the network name with staff and
+[**disable auto-connect**](https://www.cisa.gov/sites/default/files/publications/Cybersecurity%20While%20Traveling.pdf)
+features so your devices don't join networks without prompting you.
+
+**Turn off Wi-Fi and Bluetooth** on your phone and laptop when you're not using them; this reduces the risk of
+unsolicited connections or Bluetooth-based attacks. Also, disable any device-to-device sharing like **AirDrop** or
+**Nearby Share**
+[to prevent strangers from sending you files](https://www.cypherock.com/blogs/post-safe-vacation-tips-while-traveling-with-crypto#:~:text=Switch%20off%20any%20shared%20networks).
+
+**Use a trustworthy VPN** for an extra layer of encryption for your internet traffic, although in most cases by using an
+updated device, safe hardcoded DNS records, and ensuring SSL while browsing (enforce HTTPS-only-modes or adding
+“http://*” to your uBlock list, might be enough. A reputable, non-logging VPN (or your company’s VPN) helps protect
+against snooping on public networks, especially if you’re handling highly sensitive work and using several communication
+channels.
+
+Using a personal portable router combined with a trusted VPN adds a strong layer of security when connecting to public
+Wi-Fi networks. This setup creates a private, encrypted tunnel between your devices and the internet, minimizing
+exposure to malicious actors on shared networks. Whenever possible, prefer mobile data over Wi-Fi, as cellular networks
+provide better encryption and isolation by default. If you must use Wi-Fi, disable automatic connections and ensure you
+connect only to verified, trusted networks to reduce risk.
+
+### **Device handling – keep them close and protected**
+
+Never leave your devices (laptops, phones, hardware wallets) **unattended or unsecured** in public. Keep them on your
+person or within sight whenever possible. In a conference or cafe, use a cable lock for your laptop if you must step
+away briefly, take it with you or get someone you trust to watch it over for you.
+
+In hotels/Airbnbs, **use the room safe** for small devices when you're out. These safes can easily be opened by an experienced
+thief or rogue/malicious staff. Consider a portable travel safe/bag you can lock to a fixed object. A
+[**portable door lock**](https://www.travelandleisure.com/sabre-portable-door-lock-review-7643179#:~:text=schedule%20and%20explore%20fascinating%20destinations,star%20ratings%20at%20Amazon)
+or door jammer for your room can add an extra barrier against intruders (useful in rentals without chain locks). This
+simple gadget prevents anyone (even with a key) from opening your door while you're inside, giving you peace of mind at
+night. When out and about, be mindful of pickpockets – use bags that zip and consider a subtle anti-theft backpack for
+expensive gadgets or important assets.
+
+For hardware wallets or Yubikeys, a good practice is to **separate them** from the device they authenticate: e.g. don't
+carry your Yubikey on the same keychain as your laptop bag key; keep it hidden on you. And, of course, **keep devices
+powered off** or locked when not in use –
+[enable short auto-lock timeouts](https://www.cisa.gov/sites/default/files/publications/Cybersecurity%20While%20Traveling.pdf#:~:text=%E2%80%A2%20%20%20%20,Some%20devices%20will)
+on your phone/laptop so they aren't unlocked if
+snatched[.](https://www.cisa.gov/sites/default/files/publications/Cybersecurity%20While%20Traveling.pdf#:~:text=%E2%80%A2%20%20%20%20,Some%20devices%20will)
+
+### **Beware of public USB charging**
+
+Avoid plug-and-play charging stations at airports or malls. The risk of
+["**juice jacking**"](https://www.cypherock.com/blogs/post-safe-vacation-tips-while-traveling-with-crypto?srsltid=AfmBOopuzAsUtNwqCqfUBteTEyH4MOTvIaRhoXoIUyNHH8Yv5XzILrSr#:~:text=Stay%20away%20from%20Public%20charger,stations),
+although small,
+is that a malicious charging kiosk or cable can inject malware or siphon data when you connect via USB. Depending on
+your profile risk, you might encounter technologies that mimic different kind of cables and accessories with the same
+purpose. These exist out of the box, and have been widely used by red-teamers and pentesters (re OMG cable).
+
+Stick to using your own charger plugged into a power outlet, or use a **USB data blocker** (a little adapter that
+only passes power, not data). Similarly, do not plug unknown USB drives into your laptop – if someone hands you
+a free USB stick at an event, assume it could be a trap.
+[**USBGuard**](https://github.com/USBGuard/usbguard#:~:text=USBGuard%20is%20a%20software%20framework,may%20interact%20with%20the%20system)
+software (for Linux) or equivalent can be used to restrict USB device access on your computer, allowing only
+whitelisted devices. This tool can prevent an unknown USB from automatically tampering with your system by requiring
+authorization for new devices. At a minimum, disable any "USB autorun" features and consider locking down ports if your
+OS allows.
+
+### **Screen privacy and social engineering**
+
+Practice situational awareness when working in public spaces.
+[**Shoulder surfing**](https://www.trio.so/blog/shoulder-surfing-in-computer-security)
+is a real threat – someone nearby could be
+watching you enter passwords or PIN codes. Use a **privacy screen filter** on your laptop or phone to narrow the viewing
+angle. This makes it much harder for anyone not directly in front of your screen to read it. Sit with your back to a
+wall when possible, and shield the keypad with your body or hand when typing sensitive info.
+
+In crowded conferences or airports, be cautious if someone you don't know strikes up conversation — might be trying to
+distract you or talk about crypto; scammers might engage you to glean info or even attempt to get you to unlock your
+device. **Don't log in to critical accounts in front of others** – you never know who's looking.
+
+Also be mindful of **phishing attempts**: traveling users are prime targets for fake "urgent" emails or messages.
+Double-check any unusual prompts before entering credentials, especially if you're on
+[untrusted Wi-Fi](https://www.cisa.gov/sites/default/files/publications/Cybersecurity%20While%20Traveling.pdf#:~:text=banking%2C%20or%20sensitive%20work%2C%20using,using%20a%20public%20wireless%20network)
+(use your VPN and look for HTTPS).
+
+### **Maintain OpSec in public**
+
+While traveling, **blend in and stay discreet**. Refrain from discussing sensitive matters in public areas where
+eavesdropping is possible, or directly sharing things like where you are staying to people you don't know. Even hotel
+lobbies or rideshares might not be secure for private discussions.
+
+When meeting people, don't give your phone to others to type down their socials, and remember to disable default options
+like Telegram's sharing phone number when adding a contact.
+
+Remember that **hidden cameras or microphones** could exist in unfamiliar environments. It's rare but not unheard of,
+especially in
+[Airbnbs or rented spaces](https://www.washingtonpost.com/travel/2024/05/22/hidden-cameras-airnbnb-rental-properties/#:~:text=On%20the%20kitchen%20table%2C%20he,activate%20the%20camera%20tucked%20inside)
+– malicious hosts have hidden cameras in items like smoke detectors, clock radios, or USB chargers
+[.](https://www.washingtonpost.com/travel/2024/05/22/hidden-cameras-airnbnb-rental-properties/#:~:text=On%20the%20kitchen%20table%2C%20he,activate%20the%20camera%20tucked%20inside)
+Give your accommodations a scan: look for odd or
+[extra devices plugged in](https://www.washingtonpost.com/travel/2024/05/22/hidden-cameras-airnbnb-rental-properties/)
+(especially facing beds or desks) and cover or unplug them if suspicious. You can also play ambient noise (or use a
+noise generator app) during confidential conversations to thwart any listening devices.
+
+**Keep a low profile**: as mentioned,
+[don't flaunt crypto wealth or gear.](https://www.unchained.com/blog/7-tips-traveling-bitcoin#:~:text=,or%20clothing%20with%20bitcoin%20logos)
+For example, if attending a blockchain conference, consider using an alias on your name badge that doesn't explicitly
+say your company or title, and don't display that badge outside the venue. When moving around, secure your laptop in a
+nondescript sleeve or bag (instead of one with a well-known conference brand). The goal is to avoid drawing the
+attention of both petty thieves and more organized attackers by limiting the signals that you're a high-value crypto
+target.
+
+Don't rely on security through obscurity. Going "stealth" doesn't make you immune to attacks. The suggestions in
+this section are meant to complement, not replace, the other security measures.
+
+### **Traveling with high-value crypto or duties**
+
+If you *must* make crypto transactions or access sensitive systems while on the road, do so with caution. Use trusted
+hardware and networks: e.g. if you need to send a transaction, use your hardware wallet on your own laptop (never a
+shared computer), on a secured connection.
+
+Be aware of **surveillance at events** – attackers have been known to watch for people handling sensitive info. If you
+need to access a seed or enter a recovery phrase, do it in a private, secure setting (never over public Wi-Fi or in view
+of anyone, including cameras). Consider that
+[**everyone knows you own crypto at a crypto event**](https://www.unchained.com/blog/7-tips-traveling-bitcoin#:~:text=If%20you%27re%20traveling%20to%20an,in%20your%20belongings%20while%20traveling),
+so your threat profile is
+elevated[.](https://www.unchained.com/blog/7-tips-traveling-bitcoin#:~:text=If%20you%27re%20traveling%20to%20an,in%20your%20belongings%20while%20traveling)
+Adjust your security: for instance, **enable a passphrase or a pin on any single-signature wallet** you carry so that
+even if someone obtains your hardware wallet, they can't access funds without that passphrase. For large amounts, rely
+on multi-sigs, verifying payloads before signing – you might carry one key on you and leave another key(s) with trusted
+parties so no single person has all
+signing power while traveling. In short, treat any on-trip crypto operations with more care than you would in the
+office or at home.
+
+### While presenting or doing public appearances
+
+One often overlooked risk is the exposure caused by presenting or hosting technical workshops in public. Without
+properly hardening or isolating your computer before setting up, you may unintentionally expose network services to
+hostile environments or reveal sensitive information on-screen. Always prepare a clean, minimal environment and verify
+no confidential data or open ports are accessible before connecting to unfamiliar networks or projecting your screen.
+
+### **Physical safety and common sense**
+
+Operational security also has a physical aspect. **Trust your instincts** and normal travel safety rules: stick to
+well-lit and populated areas if carrying devices at night, don’t let strangers “shoulder surf” your ATM or credit card
+PIN (check for skimmers, fake interfaces), and keep your travel documents secure since identity theft can be as damaging
+as device theft.
+
+Use hotel lockers at conferences if provided (for example, some events offer secure charging lockers – use them rather
+than leaving devices out only).
+
+Beware of the classic “evil maid” scenario in hotels (where someone might tamper with your laptop in your room): using
+tamper-evident tape or seals on your laptop case can help detect this, though it’s mostly a concern for high-risk
+targets. If you have tamper-evident stickers or tamper-evident bags, you can seal your device in them overnight – any
+attempt to open or remove the device will leave a visible trace. While not foolproof against a determined adversary, it
+raises the bar and can deter casual snooping.
+
+Petty thieves may look beyond obvious valuables. Simply locking items in a dorm safe or hiding them at home might deter
+casual theft, but savvy criminals often search inside books, behind electrical outlets, or within patterns on walls or
+furniture to find hidden stashes. Consider unconventional hiding spots and avoid predictable storage methods. Layer your
+physical security measures with tamper-evident seals or discreet decoy containers to raise the effort required for
+unauthorized access.
+
+Above all, maintain an **alert posture**: be aware of who’s around when you’re working, and if something feels off (like
+someone persistently hovering or a device acting strangely), don’t ignore it. You can always relocate, power down your
+device, or otherwise cut off exposure at the first sign of trouble.
+
+## Returning home
+
+### **Secure your accounts and passwords**
+
+Once you're back, if you suspect that any account credentials you used while abroad *might* have been exposed
+(especially if you had to log in over a hotel or conference Wi-Fi), address the issue. Change the passwords for any
+accounts you accessed unsafely during the trip – but if you don't feel is necessary, sometimes you pose a greater risk
+at doing so.
+
+Do this from a *trusted* device/network (ideally wait till you're on your home or office network, not the airport
+Wi-Fi). Use this opportunity to upgrade weak passwords and ensure 2FA is still working on those accounts. Check your
+email filters and crypto account settings for any unauthorized changes (attackers sometimes add forwarding rules or new
+withdrawal addresses if they did get access).
+
+Essentially, **rotate secrets** that may have been used under less-secure conditions.
+
+### **Inspect and clean your devices**
+
+After traveling, give your devices a thorough once-over. Run a reputable anti-malware scan on laptops and phones. Look
+for any unusual apps, processes, or device behavior (for example, unusual battery drain could indicate malware).
+
+If you were in a high-risk environment or your device was out of your control at any point, consider wiping the device
+and restoring it from your pre-trip backup (or factory-resetting a phone)
+[to ensure it's clean](https://architectsecurity.org/2017/10/mobile-device-security-for-international-travelers-part-3-how-to-clean-up-your-mobile-devices-after-international-travel/#:~:text=Assume%2C%20whether%20correct%20or%20not%2C,and%20must%20be%20rebuilt%20anew)[.](https://architectsecurity.org/2017/10/mobile-device-security-for-international-travelers-part-3-how-to-clean-up-your-mobile-devices-after-international-travel/#:~:text=The%20goal%20after%20travel%20is,to%20a%20%E2%80%9Cknown%20good%E2%80%9D%20state)
+This is especially recommended for "burner" devices used on the trip – you can safely restore your data onto your main
+device and decommission the travel device.
+
+[... truncated ...]
+
+---
+
+### PAGE: /awareness/understanding-threat-vectors
+**Title:** Understanding Threat Vectors
+**Referenced by controls:** ws-1.1.2, ws-6.1.2
+
+# 2. Understanding Threat Vectors
+
+
+
+
+> 🔑 **Key Takeaway**: Understanding the various ways attackers can target you and your organization is essential for
+> effective defense. By recognizing common attack patterns like phishing, social engineering, and emerging threats in
+> digital spaces, you can better protect yourself and your team from potential security breaches.
+
+## 2.1. Traditional Attack Vectors
+
+### 2.1.1. Social Engineering & Phishing
+
+- **Phishing Emails:**
+
+Look for red flags like misspellings, odd URLs, and urgent language.
+**Scenario Example:** An email that claims "Your account will be locked in 24 hours" but uses a suspicious domain.
+
+- **SMS & Messaging Scams:**
+
+Attackers may use text messages or direct social media messages to bypass email filters.
+**Scenario Example:** A text message that claims to be from a delivery service asking for a confirmation code.
+
+- **Voice Phishing (Vishing):**
+
+Phone calls that pretend to be from a trusted organization, often using spoofed caller IDs.
+**Scenario Example:** A staff member receives a voicemail warning about a potential security breach and instructing them
+to call a specific number immediately.
+
+- **Pretexting:**
+
+Attackers create a fabricated scenario to steal personal information or gain access.
+**Scenario Example:** Someone pretending to be a new contractor who needs urgent access to systems or information.
+
+- **Baiting:**
+
+Offering something enticing to entrap the victim.
+**Scenario Example:** Leaving infected USB drives in public places or offering free downloads that contain malware.
+
+- **Tailgating:**
+
+Physically following authorized personnel into restricted areas without proper credentials.
+**Scenario Example:** An unknown person following an employee through a secure door by claiming they forgot their access
+card.
+
+- **Shoulder Surfing:**
+
+Observing someone's screen, keyboard, or device to gather information.
+**Scenario Example:** A threat actor monitoring your screen in a shared co-working space to capture sensitive
+information or credentials.
+
+### 2.1.2. Malware & Technical Attacks
+
+- **Ransomware:**
+
+Malicious software that encrypts files and demands payment for decryption.
+**Scenario Example:** An organization finds their critical files encrypted with a ransom note demanding cryptocurrency
+payment.
+
+- **Man-in-the-Middle Attacks:**
+
+Intercepting communications between two parties.
+**Scenario Example:** An attacker on a public Wi-Fi network intercepts unencrypted traffic to steal credentials.
+
+- **Credential Stuffing:**
+
+Using stolen username/password combinations to attempt access to multiple services.
+**Scenario Example:** After a data breach at one service, attackers try the same credentials on financial or email
+accounts.
+
+## 2.2. Web3-Specific Threats
+
+### 2.2.1. Crypto-Focused Attacks
+
+- **Crypto Drainers:**
+
+A common attack where a threat actor suggests users can participate in an airdrop by visiting a provided link.
+Unsuspecting users who click the link are directed to a counterfeit website, where they are asked to authenticate their
+wallet and sign a transaction. Once signed, the threat actor gains access to steal funds from the wallet.
+
+- **Rug Pulls:**
+
+In the context of web3 and cryptocurrencies, these scams typically involve fraudulent schemes designed to swindle
+individuals out of their digital assets. For example, an enticing new project may promise revolutionary technology and
+unprecedented returns. However, the project developers quickly vanish, leaving investors with worthless tokens and empty
+promises.
+
+- **Token Approval Exploits:**
+
+Attackers may trick users into approving smart contracts that give unlimited access to tokens in their wallet. These
+"allowances" permit the approved contract to transfer any amount of a specific token without further permission. Always
+verify what permissions you're granting when signing transactions and set specific approval limits when possible.
+
+### 2.2.2. Smart Contract Vulnerabilities
+
+- **Reentrancy Attacks:**
+
+Exploiting a contract's execution flow to repeatedly withdraw funds.
+**Scenario Example:** A malicious contract calls back into the victim contract before the first execution is complete,
+draining funds with each call.
+
+- **Flash Loan Attacks:**
+
+Using uncollateralized loans to manipulate market prices and exploit vulnerabilities.
+**Scenario Example:** An attacker borrows a large amount of cryptocurrency, manipulates a price oracle, exploits a
+vulnerability, and repays the loan in a single transaction.
+
+## 2.3. Common Indicators & Red Flags
+
+### 2.3.1. Behavioral Cues
+
+- **Inconsistencies:**
+
+Look for changes in tone or style in communications from known contacts.
+**Scenario Example:** A normally formal manager sends a casual message with unexpected requests.
+
+- **Unusual Requests:**
+
+Requests for urgent transfers of money, sensitive information, or changes in process should always trigger caution.
+
+- **Environmental Anomalies:**
+
+Spotting unexpected logins or unfamiliar devices in account activity reports can indicate compromised accounts.
+
+### 2.3.2. Technical Indicators
+
+- **Unexpected Authentication Prompts:**
+
+Sudden requests to re-authenticate without clear reason.
+**Scenario Example:** Being asked to provide credentials on a site you're already logged into.
+
+- **Browser Certificate Warnings:**
+
+Alerts about invalid or expired security certificates.
+**Scenario Example:** Your browser displays a warning that a connection is not secure when visiting a familiar website.
+
+- **Unusual System Behavior:**
+
+Slowdowns, crashes, or unexpected pop-ups.
+**Scenario Example:** Your computer suddenly runs significantly slower or displays unfamiliar advertisements.
+
+### 2.3.3. Checklist for Suspicious Communications
+
+- Does the message contain spelling errors or unusual formatting?
+- Is the sender's email or username slightly different from the norm?
+- Are there requests for urgent action without proper verification channels?
+- Does the message create a sense of fear, urgency, or excitement?
+- Is there an unexpected attachment or link?
+- Does the request bypass normal security procedures?
+
+## 2.4. Preventive Measures
+
+### 2.4.1. General Security Practices
+
+- **Double-Check Requests:**
+
+Always verify the identity of individuals requesting sensitive information, especially if the request is unusual or
+urgent.
+**Scenario Example:** If you receive an email from your CEO asking for an urgent wire transfer, call them directly using
+a known phone number to confirm.
+
+- **Use Secure Channels:**
+
+Communicate through official channels and avoid sharing sensitive information over unsecured methods.
+**Scenario Example:** Use your organization's established communication platforms rather than responding to external
+email links.
+
+### 2.4.2. Web3-Specific Protections
+
+- **Check & Remove Token Approvals:**
+
+Regularly check which smart contracts have approvals to handle funds in your wallet and revoke unnecessary approvals to
+improve your security posture.
+**Useful Tools:**
+
+- [Unrekt](https://app.unrekt.net/)
+- [Etherscan Token Approval Checker](https://etherscan.io/tokenapprovalchecker)
+
+- **Scrutinize Transaction Requests:**
+
+Never sign a transaction unless you are completely sure exactly what you are signing. Be especially skeptical of offers
+that seem too good to be true.
+
+- **Hardware Wallets for Critical Assets:**
+
+Use hardware wallets for storing significant cryptocurrency holdings.
+**Scenario Example:** Keeping your long-term investments on a hardware wallet while only maintaining small amounts in
+hot wallets for daily transactions.
+
+---
+
+---
+
+### PAGE: /awareness/cultivating-a-security-aware-mindset
+**Title:** Cultivating A Security Aware Mindset | SEAL
+**Referenced by controls:** ws-1.1.2, ws-3.1.4
+
+# 3. Cultivating a Security-Aware Mindset
+
+
+
+
+> 🔑 **Key Takeaway**: Developing a security-aware mindset is about building habits that prioritize caution and
+> verification. By questioning unusual requests, pausing before acting, and leveraging peer support, you transform
+> security from a set of rules into an intuitive approach to daily interactions.
+
+## 3.1. Behavioral Best Practices
+
+### Practical Tips
+
+- **Question Unusual Requests:**
+
+Always verify any request for sensitive information or financial transactions through a separate communication channel.
+
+- **Pause Before Reacting:**
+
+Take a moment to think before clicking a link or downloading an attachment. **Example:** If you get an unexpected file
+from a colleague, call them directly to confirm they sent it.
+
+- **Peer Verification:**
+
+Leverage your team by asking a colleague's opinion if something seems off.
+
+> **Scenario Example**
+A community manager receives a direct message on Discord that looks like it comes from a well-known project partner,
+asking for private credentials. Instead of immediately responding, they cross-check the message in a team meeting or via
+a known contact method.
+
+## 3.2 Awareness in Community Settings
+
+### Unique Challenges on Social Platforms
+
+- **Platform-Specific Red Flags:**
+
+Each community platform—Discord, Twitter, Telegram—has its own quirks.
+**Example:** On Telegram, unsolicited group invites with suspicious usernames could be phishing attempts.
+
+- **Community Role Awareness:**
+
+Moderators and administrators should be extra cautious since they have higher privileges.
+**Example:** A moderator on a crypto project Discord might notice a sudden spike in login attempts from an unfamiliar IP
+ range.
+
+- **Culture of Reporting:**
+
+Foster an environment where suspicious behavior is immediately reported and discussed, not brushed aside.
+
+> **Scenario Example**
+During a routine community chat, several members report receiving odd messages that urge them to click on a link. The
+community manager organizes a quick session to remind members of red flags and the correct reporting channels,
+reinforcing collective vigilance.
+
+## 3.3 Organizational Strategies for Security Culture
+
+- **Leadership Commitment:**
+
+Ensure that leadership demonstrates a strong commitment to security by prioritizing and investing in security
+initiatives. Leaders should model security-conscious behavior and allocate appropriate resources to security efforts.
+
+- **Regular Communication:**
+
+Communicate the importance of security regularly through team meetings, newsletters, and other channels. Keep security
+topics visible and relevant to all team members.
+
+- **Security Policies and Procedures:**
+
+Develop and enforce clear security policies and procedures that outline expectations and responsibilities for all team
+members.
+
+- **Encourage Reporting:**
+
+Create an environment where team members feel comfortable reporting security incidents, suspicious activities, and
+potential vulnerabilities without fear of retribution.
+
+- **Recognition and Rewards:**
+
+Recognize and reward team members who demonstrate exemplary security practices and contribute to the organization's
+security efforts.
+
+- **Continuous Improvement:**
+
+Continuously assess and improve the project's security culture through feedback, assessments, and audits.
+
+- **Shared Responsibility:**
+
+Instill a sense of responsibility for security at all levels of the project, emphasizing that security is everyone's
+job.
+
+- **Collaboration:**
+
+Promote collaboration and information sharing among team members to enhance overall security awareness and response
+capabilities.
+
+> **Scenario Example**
+A project implements a monthly "Security Spotlight" where different aspects of security are highlighted, and team
+members can share their experiences or ask questions. This regular touchpoint keeps security top-of-mind and encourages
+ongoing dialogue about best practices.
+
+## 3.4 Essential Security Practices
+
+### 3.4.1. Password Management
+
+- **Strong, Unique Passwords:**
+
+Use complex, unique passwords for each account to prevent credential stuffing attacks.
+**Example:** A passphrase like "correct-horse-battery-staple" (with four random words) is both strong and memorable,
+while being more secure than shorter passwords with special characters like "P@ssw0rd!".
+
+- **Password Managers:**
+
+Utilize a reputable password manager to securely store and generate complex passwords.
+**Example:** Tools like Bitwarden, 1Password, or KeePassXC can generate and store unique passwords for all your
+accounts.
+
+### 3.4.2. Multi-Factor Authentication (MFA)
+
+- **Enable MFA Everywhere Possible:**
+
+Add an extra layer of security beyond just passwords.
+**Example:** Even if someone obtains your password, they still can't access your account without the second factor.
+
+- **Choose Secure MFA Methods:**
+
+Hardware tokens and authenticator apps are more secure than SMS-based verification.
+**Example:** Use YubiKeys or authenticator apps like Authy instead of SMS, which can be vulnerable to SIM swapping
+attacks.
+
+### 3.4.3. Secure Communication
+
+- **End-to-End Encryption:**
+
+Use messaging platforms with end-to-end encryption for sensitive communications.
+**Example:** Signal provides strong encryption for messages, ensuring only the intended recipient can read them.
+
+- **Verify Communication Channels:**
+
+Be cautious of unexpected platform changes for important communications.
+**Example:** If a colleague suddenly asks to switch from your company's official channel to a personal messaging app for
+ work discussions, verify this request directly.
+
+### 3.4.4. Device Security
+
+- **Keep Systems Updated:**
+
+Regularly update your operating system and applications to patch security vulnerabilities.
+**Example:** Schedule automatic updates or set a weekly reminder to check for and install updates.
+
+- **Secure Your Workspace:**
+
+Be mindful of physical security in shared or public spaces.
+**Example:** Use privacy screens when working in public and lock your device when stepping away.
+
+## 3.5. Incident Response Awareness
+
+### 3.5.1. Recognizing Security Incidents
+
+- **Know the Warning Signs:**
+
+Understand what constitutes a potential security incident.
+**Example:** Unexpected account lockouts, strange system behavior, or unusual access requests could indicate a breach.
+
+- **Immediate Actions:**
+
+Know what steps to take when you suspect a security incident.
+**Example:** Disconnect from networks, document what happened, and report to your security team immediately.
+
+### 3.5.2. Reporting Procedures
+
+- **Clear Reporting Channels:**
+
+Ensure everyone knows how and where to report security concerns.
+**Example:** Have a dedicated email address or communication channel specifically for security reports.
+
+- **No-Blame Culture:**
+
+Encourage prompt reporting by focusing on solutions rather than blame.
+**Example:** Acknowledge and thank team members who report potential issues, even if they turn out to be false alarms.
+
+> **Scenario Example**
+A team member notices unusual login attempts to their account. Instead of ignoring it or feeling embarrassed, they
+immediately report it to the security team, who can then investigate whether this is part of a larger attack pattern
+affecting other users.
+
+---
+
+---
+
+### PAGE: /encryption/volume-encryption
+**Title:** Volume Encryption
+**Referenced by controls:** ws-1.1.3, ws-2.1.1
+
+# Volume Encryption
+
+
+
+
+## What is Volume Encryption?
+
+Volume encryption is the process of encrypting a specific storage volume or partition to protect the data it contains.
+Unlike full disk encryption, which encrypts the entire disk, volume encryption allows for selective encryption of
+specific volumes, providing flexibility in managing encrypted and un-encrypted data on the same device.
+
+## Importance of Volume Encryption
+
+Volume encryption is essential for protecting sensitive information from unauthorized access, especially in environments
+where different types of data coexist on the same device. It helps prevent data breaches in case of unauthorized access
+to specific volumes and ensures compliance with data protection regulations.
+
+## Uses of Volume Encryption
+
+- **Protecting Sensitive Data**: Ensures that sensitive information stored on specific volumes is secure.
+- **Compliance**: Helps organizations meet regulatory requirements for data protection.
+- **Data Breach Prevention**: Reduces the risk of data breaches in case of unauthorized access to specific volumes.
+- **Secure Decommissioning**: Ensures that data on encrypted volumes is not recoverable when storage devices are
+  decommissioned or repurposed.
+
+## Examples of Volume Encryption
+
+- **Partition Encryption**: Encrypts specific partitions or volumes on a disk, allowing for selective encryption of
+  sensitive data.
+- **Virtual Encrypted Disks**: Creates virtual encrypted disks within files, providing an additional layer of security
+  for sensitive data.
+
+## Known Technologies for Volume Encryption
+
+- **BitLocker**: A volume encryption feature included with Microsoft Windows that provides encryption for specific
+  volumes.
+- **LUKS (Linux Unified Key Setup)**: A disk encryption specification for Linux that provides a standard for volume
+  encryption.
+- **VeraCrypt**: An open-source disk encryption software that can create virtual encrypted disks within a file or
+  encrypt specific partitions.
+
+## Best Practices for Volume Encryption
+
+1. **Use Strong Encryption Algorithms**: Ensure that the encryption algorithms used are strong and up-to-date, such as
+  AES-256.
+2. **Enable Encryption on Sensitive Volumes**: Apply volume encryption to all volumes that store sensitive information.
+3. **Regularly Update Encryption Software**: Keep encryption software and tools updated to protect against
+  vulnerabilities.
+4. **Implement Access Controls**: Use strong authentication methods, such as multi-factor authentication (MFA), to
+  control access to encrypted volumes.
+5. **Backup Encryption Keys**: Securely backup encryption keys to prevent data loss in case of key corruption or loss.
+6. **Monitor and Audit**: Regularly monitor and audit encryption settings and access logs to ensure compliance and
+  detect any unauthorized access attempts.
+
+By following these best practices and using reliable volume encryption technologies, organizations can significantly
+enhance the security of their data and protect against unauthorized access and data breaches.
+$$
+
+---
+
+---
+
+### PAGE: /encryption/partition-encryption
+**Title:** Partition Encryption
+**Referenced by controls:** ws-1.1.3, ws-2.1.1
+
+# Partition Encryption
+
+
+
+
+## What is Partition Encryption?
+
+Partition encryption is the process of encrypting specific partitions on a storage device. This allows for selective
+encryption of data, providing flexibility in managing encrypted and un-encrypted data on the same device. Unlike full
+disk encryption, which encrypts the entire disk, partition encryption targets specific areas, making it ideal for
+protecting sensitive data without impacting the entire storage system.
+
+## Importance of Partition Encryption
+
+Partition encryption is crucial for protecting sensitive information from unauthorized access, especially in
+environments where different types of data coexist on the same device. It helps prevent data breaches in case of
+unauthorized access to specific partitions and ensures compliance with data protection regulations.
+
+## Uses of Partition Encryption
+
+- **Protecting Sensitive Data**: Ensures that sensitive information stored on specific partitions is secure.
+- **Compliance**: Helps organizations meet regulatory requirements for data protection.
+- **Data Breach Prevention**: Reduces the risk of data breaches in case of unauthorized access to specific partitions.
+- **Secure Decommissioning**: Ensures that data on encrypted partitions is not recoverable when storage devices are
+decommissioned or repurposed.
+
+## Examples of Partition Encryption
+
+- **BitLocker**: A partition encryption feature included with Microsoft Windows that provides encryption for specific
+  partitions. [Learn how to use
+  BitLocker](https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-overview)
+- **LUKS (Linux Unified Key Setup)**: A disk encryption specification for Linux that provides a standard for partition
+  encryption. [Learn how to use LUKS](https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions)
+- **VeraCrypt**: An open-source disk encryption software that can encrypt specific partitions. [Learn how to use
+  VeraCrypt](https://www.veracrypt.fr/en/Documentation.html)
+
+## Best Practices for Partition Encryption
+
+1. **Use Strong Encryption Algorithms**: Ensure that the encryption algorithms used are strong and up-to-date, such as
+  AES-256.
+2. **Enable Encryption on Sensitive Partitions**: Apply partition encryption to all partitions that store sensitive
+  information.
+3. **Regularly Update Encryption Software**: Keep encryption software and tools updated to protect against
+  vulnerabilities.
+4. **Implement Access Controls**: Use strong authentication methods, such as multi-factor authentication (MFA), to
+  control access to encrypted partitions.
+5. **Backup Encryption Keys**: Securely backup encryption keys to prevent data loss in case of key corruption or loss.
+6. **Monitor and Audit**: Regularly monitor and audit encryption settings and access logs to ensure compliance and
+  detect any unauthorized access attempts.
+
+By following these best practices and using reliable partition encryption technologies, organizations can significantly
+enhance the security of their data and protect against unauthorized access and data breaches.
+
+---
+
+---
+
+### PAGE: /opsec/control-domains/technical
+**Title:** Technical Security Controls
+**Referenced by controls:** ws-1.1.4, ws-2.1.2, ws-3.1.2, ws-5.1.1, ws-5.1.2
+
+# Technical & Digital Controls
+
+
+
+
+Technical controls form the backbone of operational security, protecting systems, networks, and data from digital
+threats. This section outlines key technical controls that should be implemented as part of a comprehensive security
+program.
+
+## Device Hardening
+
+Securing devices by minimizing attack surfaces and implementing defensive configurations.
+
+### Key Components
+
+1. **Secure Configuration Baselines**: Standardized secure configurations for different device types
+2. **Endpoint Protection**: Anti-malware, application control, and other protective tools
+3. **OS Hardening**: Removing unnecessary services and securing operating systems
+4. **Patch Management**: Keeping systems updated with security patches
+5. **Local Firewall**: Controlling network connections at the device level
+
+### Implementation Steps
+
+1. Develop secure configuration baselines for each device type
+2. Implement endpoint protection solutions on all devices
+3. Remove or disable unnecessary services, applications, and features
+4. Establish an effective patch management process
+5. Configure local firewalls with appropriate rules
+6. Regularly scan for compliance with security baselines
+
+### Web3-Specific Considerations
+
+1. **Development Environments**: Securing environments used for smart contract development
+2. **Cold Storage Systems**: Hardening systems used for cryptocurrency key management
+3. **Transaction Signing Devices**: Enhanced security for devices used to sign transactions
+4. **Node Operation**: Specialized hardening for blockchain node infrastructure
+5. **Testing Environments**: Securing environments used for contract testing and simulation
+
+## Network & Communication Security
+
+Protecting data in transit and securing network infrastructure against attacks.
+
+### Key Components
+
+1. **Network Segmentation**: Dividing networks into security zones
+2. **Encrypted Communications**: Protecting data transmitted over networks
+3. **Secure Remote Access**: VPN and other secure access solutions
+4. **Network Monitoring**: Detecting suspicious network activity
+5. **Perimeter Security**: Firewalls, intrusion prevention, and other boundary protections
+
+### Implementation Steps
+
+1. Implement network segmentation based on security requirements
+2. Deploy encryption for all sensitive communications
+3. Establish secure remote access solutions with strong authentication
+4. Implement network monitoring and traffic analysis
+5. Deploy and properly configure perimeter security controls
+6. Regularly test network security through vulnerability assessments and penetration testing
+
+### Web3-Specific Considerations
+
+1. **Node Communication**: Securing blockchain node communications
+2. **API Security**: Protecting interfaces to blockchain services
+3. **RPC Endpoint Protection**: Securing remote procedure call endpoints
+4. **P2P Network Security**: Addressing risks in peer-to-peer networks
+5. **MEV Protection**: Mitigating risks related to maximal extractable value
+
+## Encrypted Storage & Backups
+
+Protecting data at rest through encryption and secure backup strategies.
+
+### Key Components
+
+1. **Full-Disk Encryption**: Encrypting entire storage devices
+2. **File-Level Encryption**: Protecting individual sensitive files
+3. **Key Management**: Securely managing encryption keys
+4. **Secure Backups**: Protecting backup data through encryption and access controls
+5. **Recovery Testing**: Verifying the ability to restore from backups
+
+### Implementation Steps
+
+1. Implement full-disk encryption on all devices storing sensitive data
+2. Deploy file-level encryption for particularly sensitive information
+3. Establish secure key management processes with appropriate access controls
+4. Implement encrypted and access-controlled backup solutions
+5. Regularly test backup recovery processes
+6. Store backup media securely with appropriate physical protections
+
+### Web3-Specific Considerations
+
+1. **Seed Phrase Backups**: Secure storage of wallet recovery information
+2. **Multi-Location Backups**: Distributing backup data to prevent single points of failure
+3. **Cold Storage Backups**: Offline backup strategies for critical keys
+4. **Smart Contract Backups**: Preserving contract source code and deployment parameters
+5. **Social Recovery Options**: Implementing secure social recovery systems for critical keys
+
+## Two-Factor & Hardware Authentication
+
+Strengthening authentication through multiple factors and hardware-based solutions.
+
+### Key Components
+
+1. **Multi-Factor Authentication**: Requiring multiple verification methods
+2. **Hardware Security Keys**: Physical devices for authentication
+3. **Biometric Authentication**: Using biological characteristics for verification
+4. **Time-Based One-Time Passwords**: Temporary codes for authentication
+5. **Single Sign-On Integration**: Centralizing and securing authentication
+
+### Implementation Steps
+
+1. Implement multi-factor authentication for all access to sensitive systems
+2. Deploy hardware security keys for high-value accounts and systems
+3. Establish backup authentication methods and recovery processes
+4. Integrate MFA with single sign-on solutions where appropriate
+5. Train users on proper use of authentication tools
+6. Regularly audit authentication configurations and access
+
+### Web3-Specific Considerations
+
+1. **Hardware Wallets**: Using dedicated devices for cryptocurrency transactions
+2. **Multi-Signature Setups**: Requiring multiple approvals for critical transactions
+3. **Air-Gapped Signing**: Using offline devices for transaction signing
+4. **Social Recovery**: Implementing secure key recovery through trusted contacts
+5. **DApp Authentication**: Securing connections to decentralized applications
+
+## Cryptocurrency-Specific Controls
+
+Technical controls specifically designed to address the unique security challenges of cryptocurrency operations.
+
+### Key Components
+
+1. **Wallet Security**: Technical measures to secure cryptocurrency wallets
+2. **Transaction Verification**: Processes to verify transaction details before signing
+3. **Key Management**: Secure generation, storage, and use of cryptographic keys
+4. **Blockchain Monitoring**: Tracking on-chain activity for anomalies
+5. **Smart Contract Security**: Technical controls for secure contract interaction
+
+### Implementation Steps
+
+1. Implement appropriate wallet solutions based on security requirements
+2. Establish transaction verification procedures with multiple checks
+3. Deploy secure key management practices and technologies
+4. Implement monitoring for blockchain transactions and activities
+5. Develop secure processes for smart contract interaction
+6. Regularly review and update cryptocurrency security controls
+
+### Web3-Specific Best Practices
+
+1. **Cold Storage**: Using offline systems for storing significant assets
+2. **Multi-Signature Wallets**: Requiring multiple approvals for transactions
+3. **Transaction Simulation**: Testing transactions before execution
+4. **Gas Limit Setting**: Controlling transaction costs and preventing attacks
+5. **Contract Interaction Verification**: Verifying contract behavior before approval
+
+Effective technical and digital controls provide a strong foundation for operational security. By implementing
+comprehensive device, network, data, and authentication protections, organizations can significantly reduce their attack
+surface and better protect their digital assets.
+
+---
+
+---
+
+### PAGE: /opsec/control-domains/physical-environmental
+**Title:** Physical & Environmental Security
+**Referenced by controls:** ws-2.1.2, ws-2.1.4
+
+# Physical & Environmental Controls
+
+
+
+
+Physical security is a crucial component of operational security that is often overlooked in digital-focused
+organizations. This section covers controls to protect physical assets, secure workspaces, and address travel security
+concerns.
+
+## Secure Workspace & Travel Security
+
+Implementing controls to secure physical work environments and protect team members while traveling.
+
+### Secure Workspace Components
+
+1. **Physical Access Controls**: Restricting access to facilities and sensitive areas
+2. **Visitor Management**: Procedures for handling visitors and contractors
+3. **Clean Desk Policy**: Guidelines for securing sensitive information when not in use
+4. **Environmental Monitoring**: Detection of environmental threats (fire, water, etc.)
+5. **Equipment Security**: Physical protection of hardware and devices
+
+### Implementation Steps for Workspace Security
+
+1. Implement appropriate physical access controls based on sensitivity
+2. Establish visitor management procedures and logging
+3. Develop and enforce clean desk and clear screen policies
+4. Implement environmental monitoring and response procedures
+5. Secure hardware with appropriate physical controls (locks, alarms, etc.)
+
+### Travel Security Components
+
+1. **Pre-Travel Assessment**: Evaluating security risks at destinations
+2. **Secure Travel Practices**: Guidelines for secure behavior while traveling
+3. **Device Security**: Protecting devices and data during travel
+4. **Emergency Response**: Procedures for handling security incidents while traveling
+5. **Post-Travel Measures**: Actions to take after returning from high-risk locations
+
+### Implementation Steps for Travel Security
+
+1. Develop pre-travel risk assessment procedures
+2. Create travel security guidelines for different risk levels
+3. Implement technical controls for devices used during travel
+4. Establish emergency response procedures for travelers
+5. Develop and enforce post-travel security measures where appropriate
+
+### Web3-Specific Considerations
+
+1. **Remote-First Organizations**: Addressing physical security in distributed teams
+2. **Hardware Wallets**: Securing cryptocurrency hardware devices
+3. **Conference Security**: Protecting team members at industry events
+4. **Pseudonymous Team Members**: Balancing privacy with physical security needs
+5. **Doxing Risks**: Protecting team members from having personal information exposed
+
+## Tamper-Evidence & "Evil-Maid" Attacks
+
+Protecting against physical tampering with devices and equipment, especially when left unattended.
+
+### Key Components
+
+1. **Tamper-Evident Measures**: Physical indicators of device tampering
+2. **Device Integrity Verification**: Methods to verify device has not been compromised
+3. **Secure Storage**: Protected storage for sensitive devices when not in use
+4. **Device Handling Procedures**: Guidelines for maintaining device chain of custody
+5. **Response Procedures**: Actions to take when tampering is suspected
+
+### Implementation Steps
+
+1. Implement tamper-evident measures for sensitive devices (seals, markers, etc.)
+2. Establish procedures for verifying device integrity after periods of absence
+3. Provide secure storage options for devices when not in use
+4. Develop clear device handling procedures
+5. Create response plans for suspected tampering incidents
+6. Train team members on tamper detection and response
+
+### Web3-Specific Considerations
+
+1. **Hardware Wallet Security**: Protecting cryptocurrency hardware devices
+2. **Cold Storage**: Physical security for offline key storage
+3. **Seed Phrase Protection**: Secure storage of recovery phrases
+4. **Air-Gapped Systems**: Maintaining security of isolated systems
+5. **Physical Backup Security**: Protecting backup storage media
+
+## Physical Security of Critical Assets
+
+Protecting the physical security of servers, network equipment, and other critical infrastructure.
+
+### Key Components
+
+1. **Asset Inventory**: Cataloging and tracking physical assets
+2. **Secure Facilities**: Protected locations for critical infrastructure
+3. **Environmental Controls**: Protection against environmental threats
+4. **Maintenance Procedures**: Secure processes for equipment maintenance
+5. **Disposal Procedures**: Secure disposal of equipment and media
+
+### Implementation Steps
+
+1. Maintain a comprehensive inventory of physical assets
+2. Implement appropriate physical security controls for facilities
+3. Deploy environmental monitoring and protection systems
+4. Establish secure maintenance procedures
+5. Develop and enforce secure disposal procedures for equipment and media
+
+### Web3-Specific Considerations
+
+1. **Node Security**: Physical protection of blockchain nodes
+2. **Validator Security**: Enhanced protection for validator infrastructure
+3. **Redundancy Planning**: Physical distribution of backup systems
+4. **Hardware Security Modules**: Physical protection of HSMs
+5. **Key Ceremony Security**: Physical controls for key generation events
+
+Effective physical and environmental security controls address risks that are often overlooked in digital-focused
+organizations. By implementing appropriate physical protections, organizations can prevent attacks that bypass technical
+controls through physical access or tampering.
+
+---
+
+---
+
+### PAGE: /guides/account_management/discord
+**Title:** Discord Security
+**Referenced by controls:** ws-2.1.3, ws-3.1.1, ws-3.1.2, ws-3.1.3, ws-3.1.5, ws-6.1.2, ws-7.1.3
+
+# Discord Security
+
+
+
+
+## Summary
+
+> 🔑 **Key Takeaway for Discord:** To secure your Discord server, focus on implementing robust access controls and
+> enforcing two-factor authentication for all administrators. Regularly audit roles and permissions, and maintain
+> vigilant moderation. Educate your community about security best practices to prevent unauthorized access and protect
+> against potential threats.
+
+Discord offers a variety of security features that are essential to use. Despite these, users should stay alert to
+threats like phishing, which can target server moderators. Such threats may appear as QR code scams, fake login screens,
+or misleading direct messages pretending to be from Discord support.
+
+To enhance the security of your Discord server, take into account these suggestions. They cover important aspects like
+server settings, roles and permissions, moderation, bots, channels, invites, member screening, logging, and other
+security measures.
+
+---
+
+## For Individuals
+
+These settings apply to your personal Discord account. All team members, moderators, and admins should configure these
+on their own accounts.
+
+### Account Security Checklist
+
+- [ ] User Settings > My Account: Ensure **2FA** is enabled (authenticator app and/or security key), Remove a phone
+  number if you have one added to your account, and after 2FA is setup select **View Backup Codes**, and note down
+  your backup codes offline
+- [ ] User Settings > My Account: Ensure **SMS Backup Authentication** is **disabled**
+- [ ] User Settings > Content & Social > Social Permissions: Allow DMs from other server members > **Disabled**
+- [ ] User Settings > Content & Social > Direct Message Spam: Select **Filter all** to filter all DMs for spam
+  (encourages moderators and community members to adopt the same setting to minimize phishing DMs)
+- [ ] User Settings > Authorized Apps: Review and **Deauthorize** any unnecessary apps
+- [ ] User Setting > Devices: Review and remove unnecessary devices, or **Log Out All Known Devices**
+- [ ] User Settings > Connections: Review and remove any unnecessary connections
+
+---
+
+## For Team Members
+
+These guidelines apply to moderators and team members who help manage the server but don't have full administrative access.
+
+Team members should:
+
+- Understand the permissions their role grants using **Server Settings > Roles > View Server as Role** — this allows
+  you to see what members with a certain role can see and access
+- Be aware of the server's AutoMod rules for: Spam, Harmful Links, Mention Spam, Inappropriate Words, and any custom
+  keyword filters and exempted roles
+
+---
+
+## For Admins
+
+These settings and practices apply to server administrators with elevated privileges.
+
+### Server Settings Checklist
+
+#### Safety Setup
+
+- Safety Setup > Moderation:
+  - [ ] Require 2FA for moderation > **Enabled**
+  - This ensures all moderators have an extra layer of security
+- Safety Setup > Verification Level:
+  - [ ] Choose from: None, Low, Medium, High, Highest
+  - [ ] Set to at least **Medium** (registered on Discord for 5+ minutes) — Recommended: "Moderate" for public servers
+  - Higher levels protect against spammers and raids
+- Safety Setup > Raid Protection and CAPTCHA:
+  - [ ] Activate all relevant settings to require CAPTCHA for new user actions
+  - [ ] Activity Alerts > **Enabled**
+  - [ ] CAPTCHA suspicious accounts before they are able to join > **Enabled**
+  - [ ] CAPTCHA all accounts before they are able to join during a suspected raid > **Enabled**
+  - This protection uses machine learning to detect and block bot-driven join-raids. When activated, it sends alerts
+    to a specified channel and requires CAPTCHA verification for new users for one hour after detection.
+- Safety Setup > DM and Spam Protection:
+  - [ ] Hide DMs from suspicious users > **Enabled**
+  - [ ] Filter DMs from unknown users > **Enabled**
+  - [ ] Warn members before they visit outbound links > **Enabled**
+  - [ ] Hide all messages from and delete suspected spammers > **Enabled**
+
+#### AutoMod
+
+- Server Settings > Safety Setup > AutoMod:
+  - [ ] Set up rules for: **Spam**, **Harmful Links**, **Mention Spam**, **Inappropriate Words**
+  - [ ] Configure custom keyword filters and exempted roles
+  - [ ] Customize the response to spam (block message, send alert, timeout member)
+  - [ ] Add to the existing automod rule to block keywords in a user's name: Support, Bot, Admin, Tech, Helpdesk, etc.
+  - [ ] Create a private channel that mods, team, and admins have visibility to and set each AutoMod rule to send
+    logs to that channel for review
+
+#### Server Overview
+
+- Server Settings > Engagement > Default Notification Settings: Select **Only @mentions**
+  - Reduces potential spam notifications for members, making them more vigilant about suspicious or phishing content
+
+#### Roles
+
+- Server Settings > Roles:
+  - [ ] Review admin role members — high-privilege roles with **Administrator** permission should have **2-3 members
+    max**
+  - [ ] Review bot role permissions and confirm members list contains only the bot user
+  - [ ] Review mod role permissions and members list
+  - [ ] Review user role permissions — watch for: **Manage Channels**, **Manage Roles**, **Manage Webhooks**, **Manage
+    Server**, **Administrator**
+  - [ ] Remove any lingering or overly broad permissions, and any roles with excess or unintended members
+  - [ ] Check channel-level permission overrides on private channels
+
+> **Note on Role Permissions:** For each role, carefully review the 32 available permissions. Key permissions to
+> restrict: Administrator, Manage Webhooks, Manage Server, Manage Roles, & Manage Channels. Never give Admin or Kick
+> permissions to anyone you don't fully trust.
+>
+> **Administrator** should ideally be reserved for a single admin role with minimal members. It is recommended to have
+> no more than 2-3 admins with this privilege in order to reduce risk due to account compromise and insider threats,
+> but to retain some redundancy.
+>
+> Minimal bots actually need **Administrator** permissions. Review what permissions a bot actually needs and do not
+> default to Admin permissions just because developers request it as the easy option. If a bot does require
+> Administrator, mitigate this risk by monitoring the Discord audit logs frequently or create alerts on a private
+> channel to notify when admin permissions are exercised within the server.
+>
+> Permissions can also be set at the channel level. It is important to check your private channels for any permission
+> overrides that may have been set!
+
+#### Integrations
+
+- Server Settings > Integrations:
+  - [ ] Review each bot's permissions and remove unnecessary permissions
+  - [ ] Remove any unnecessary integrations & reevaluate necessity of integrations with excessive permissions
+- Server Settings > Integrations > Manage Bot/App > **Roles & Members** / **Channels**:
+  - [ ] Remove permissions for bots that ask for Admin or other permissions that aren't needed — use least privilege
+    with permissions at the role level and channel level
+  - [ ] Uninstall any bots that aren't actively used or needed
+  - [ ] Confirm all bots and apps are
+    [**Verified**](https://support-dev.discord.com/hc/en-us/articles/23926564536471-How-Do-I-Get-My-App-Verified)
+  - [ ] Restrict command permissions of integrations where possible (Manage > Roles & Members / Channels / Command
+    Overrides)
+- Server Settings > Integrations > Webhooks:
+  - [ ] Review and remove any unnecessary webhooks
+  - [ ] Reevaluate necessity of webhooks with excessive permissions
+
+> **Note on Integration Security:** Integrations and webhooks add 3rd party risk and permission misconfiguration risk.
+> Ensure that permissions are correct, and either remove external integrations or understand the risk they present.
+
+#### Invites
+
+- Server Settings > Invites:
+  - [ ] Review and delete unnecessary or old invites regularly
+
+#### Privacy Settings
+
+- Server Settings > Privacy Settings:
+  - [ ] Disable **Direct Messages** — this prevents users from DMing other members in this server
+
+#### Community Features
+
+- Server Settings > Community:
+  - [ ] Enable the Community Feature
+  - Unlocks tools like membership screening, server insights, welcome screen, and discovery settings. Helps maintain
+    a structured, secure environment by surfacing official rules and critical info to newcomers.
+- Server Settings > Server Insights:
+  - [ ] Enable Server Insights for detailed analytics
+  - Use this data to inform moderation strategies and server improvements
+
+> **Note on Safety Features:**
+>
+> - Activity alerts notify on anomalous DM activity, which could indicate your community is being targeted by scammers
+>   or social engineering attackers.
+> - Raid Protection and CAPTCHA can also be satisfied by a bot, if preferred over Discord's built-in functionality.
+> - Hiding/filtering DMs between server members is recommended to prevent scams, spam, and social engineering of your
+>   users.
+> - In the event of a security incident, Discord provides
+>   [**Security Actions**](https://support.discord.com/hc/en-us/articles/17439993574167-Activity-Alerts-Security-Actions#h_01HAD80CK67WF59GDGR7XGVAN8)
+>   for pausing invites and DMs to allow you to protect your community while responding to ongoing threats.
+
+---
+
+### Role Hierarchy Setup
+
+Roles should be structured with higher-privilege roles at the top. Go to Server Settings > Roles, create roles like
+Cold Admin, Team, Moderator, & Verified, and drag to reorder (higher roles override lower roles):
+
+1. Cold Admin (highest)
+2. Team
+3. Moderator
+4. Verified (lowest)
+
+**Recommended permissions by role:**
+
+| Role | Recommended Permissions |
+| ---- | ----------------------- |
+| **Moderators** | View Channels, View Audit Log, View Server Insights, Kick Members, Ban Members, Timeout Members, Send Messages and Create Posts, Embed Links, Attach Files, Add Reactions, Add External Emoji, Use External Stickers, Manage Messages, Bypass Slowmode, Read Message History, Request to Speak |
+| **Members** | View Channels, Send Messages and Create Posts, Embed Links, Add Reactions, Read Message History, Request to Speak |
+
+Use **Server Settings > Roles > [Role] > View Server as Role** to see what members with a certain role can see and access.
+
+---
+
+### Channel Management
+
+#### Organization
+
+- Use categories to group related channels
+- Suggested categories: Information, General, Voice Channels, Topic-Specific
+
+#### Per-Channel Settings
+
+(Right-click channel > Edit Channel > Permissions):
+
+- [ ] Set custom permissions for roles or members in specific channels
+
+#### Channel Settings > Overview
+
+- [ ] Slow Mode: Set appropriate cooldown (e.g., 5-30 seconds) for busy channels
+- [ ] Age-Restricted Channel: Enable for channels with mature content
+
+---
+
+### Member Screening Setup
+
+Beyond enabling in Safety Setup:
+
+- Implement a verification bot like Wick that does in-channel captcha for users to join the server
+- Require users to complete an in-channel captcha before accessing the server
+- Advance Settings: Have verification bot filter based on account age, PFP set, and timeout for incomplete captcha
+
+---
+
+### Invite Best Practices
+
+When creating invites:
+
+- Set "Expire After" (recommended: 24 hours)
+- Set "Max Number of Uses" (recommended: 50-100)
+
+---
+
+### Logging Setup
+
+- Ensure admin/mod roles have "View Audit Log" permission
+- Create a private logging channel visible only to admins/mods
+- Use a logging bot like Logger or Dyno to send detailed logs
+- Configure audit log output to a private channel for easier monitoring
+
+---
+
+### Security Bots
+
+Various third-party Discord bots offer valuable security and protection features, facilitating automated moderation
+for your server. In the sections below, we'll explore different categories of security bots and highlight popular
+options for each category.
+
+#### Anti-Impersonation Bots
+
+Set up custom rules to prevent other users from joining using the same username and PFP (profile picture) to
+impersonate you or other important members of the server. A popular bot in this category is
+[Hashbot](https://hashbot.com).
+
+#### Anti-Raid Bots
+
+To prevent spam bots from joining your server all at once, an attack known as raiding, you can also set up bots with
+particular rules. Beemo is a good example of a bot in this category.
+
+#### Anti-Nuke Bots
+
+This is a monitoring system to observe and note any changes (spontaneous or planned) that take place in your discord
+server. Some key observation markers are channel and role creation/deletions, banning or kicking members, and webhook
+creation/deletion.
+
+#### Moderation & Link Whitelisting Bots
+
+Only allows approved links to be used in the discord server. A popular bot in this category is Goodknight Bot.
+
+#### General Moderation Bots
+
+Consider bots like Dyno for advanced moderation and logging, or Carl-bot for reaction roles and custom commands. Set
+up security Bots as described above.
+
+_The bots above are not all-inclusive but rather a recommended list of bots to help protect your Discord server in
+these categories._
+
+---
+
+### Establish Clear Server Rules
+
+- Create a #rules channel
+- Use Discord's built-in rules screening feature
+- Include sections on: Behavior, Content, Moderation Actions, Appeals Process
+
+---
+
+### Regular Reviews
+
+| Frequency | Action |
+| --------- | ------ |
+| **Monthly** | Review all role permissions; use a spreadsheet to track changes and justifications |
+| **Quarterly** | Assess if server rules need updating; announce any changes in a dedicated announcements channel |
+| **Bi-annually** | Delete or archive inactive channels; remove roles that are no longer needed |
+
+Also regularly:
+
+- Ensure bots are from reputable sources and receive frequent updates
+- Review bot permissions after each significant update to avoid newly introduced vulnerabilities
+- Keep track of newly introduced features such as Threads, Scheduled Events, or Stage Channels and configure their
+  permissions carefully (e.g., who can start or join a Thread) to prevent abuse by spammers or scammers
+
+---
+
+### Cold Admin Accounts
+
+A Cold Admin account provides enhanced security because it serves exclusively as the server owner and is not used for
+everyday activities. If a regular admin account is compromised, attackers gain full access to the server or account,
+making it challenging to involve support and potentially requiring days or weeks to resolve the issue. Using a Cold
+Admin means creating a separate account dedicated solely to ownership functions, keeping it isolated from routine
+operations.
+
+#### What is a Cold Device?
+
+A Cold Device is a factory-reset device with no previous configuration. This should be a dedicated phone or laptop —
+you can use an old iPhone/Android, Windows device, or even a Chromebook to keep costs down. Everyone involved in
+setup and maintenance must ONLY access the Cold Admin account from a cold device.
+
+#### Cold Admin Setup
+
+##### Step 1: Create a dedicated email account
+
+Create a brand new Gmail account specifically for this Discord account. Do not use a VPN during this process, and
+it's best to use an incognito browser. After creating the Gmail account:
+
+- [ ] Set up 2FA immediately (authenticator app recommended, or Security Key for maximum security)
+- [ ] Ensure "Skip password when possible" is **off**
+- [ ] Do not add a phone number to the account
+- [ ] Note down the 10 backup codes **offline on paper** (DO NOT store online)
+- [ ] Write down the email, password, and backup codes on paper and store securely
+
+##### Step 2: Create the Discord account
+
+Head to [https://discord.com](https://discord.com) and create a new account using the Gmail account you just created.
+
+- [ ] Write down the email, username, password, and date of birth **offline**
+- [ ] Use a username that is not related to your project
+- [ ] Give the profile a profile picture in **My Account > Edit User Profile**
+- [ ] Go to **Content & Social** and disable DMs from server members and set spam filter to maximum
+- [ ] Set the account status to **Invisible** so no one can see if it's online (click profile in bottom left > change status)
+
+##### Step 3: Join the server and transfer ownership
+
+- [ ] Send the Cold Admin account a friend request from your personal Discord account
+- [ ] Have the Cold Admin join the Discord server and complete verification like a normal account
+- [ ] Assign the Cold Admin the highest admin role
+- [ ] Have the Cold Admin send a few messages in a private team chat
+- [ ] Wait approximately 24 hours, send a few more messages, then transfer ownership
+
+**To transfer ownership:** Go to **Server Settings > Members** > Search for the Cold Admin account > Click the three
+dots > Select **Transfer Ownership** > Input 2FA > Confirm
+
+> ⚠️ **CRITICAL:** Triple-check that you are transferring to the correct Cold Admin account. If you transfer to the
+> wrong account, recovery will be extremely difficult.
+
+#### Use of Cold Admin Account
+
+- **Do not** use the Cold Admin account for day-to-day operations
+- Log into both the Gmail and Discord account at least once a month (set a phone reminder)
+- Use only for: inviting/adding bots, making major changes only the server owner can perform
+- If an incident or compromise occurs, log into the Cold Admin to regain control — the server owner always maintains
+  full access rights
+
+---
+
+### Backup Systems
+
+- Use a bot like ServerBackup to regularly backup your server configuration
+- Store backups securely off-platform
+
+---
+
+### Additional Recommendations
+
+- Set up account leveling for new members for gradually enabling permissions
+- Regularly review server audit logs for admin and mod actions
+- Use anti-raid bots like Wick or Dyno and configure automatic lock-down settings for suspicious activity
+- Regularly review **Server Settings > Integrations** for newly added apps or link shorteners; disable suspicious
+  integrations or automate link scanning with a bot that checks URLs against known phishing databases
+
+> **Important:** Discord servers should not be used for any confidential communication (i.e., any admin discussions
+> beyond the scope of server moderation) — even restricted channels and DMs are not end-to-end encrypted.
+
+---
+
+### Stay Updated
+
+- Consult the official [Discord Moderator Academy](https://discord.com/moderation) for ongoing best practices and new features
+- Implement recommended strategies (e.g., improved spam filters, updated role recommendations)
+
+---
+
+## Additional Resources
+
+
+[... truncated ...]
+
+---
+
+### PAGE: /dprk-it-workers/techniques-tactics-and-procedures
+**Title:** DPRK IT Worker TTPs
+**Referenced by controls:** ws-3.1.1
+
+# Techniques, Tactics, and Procedures
+
+
+
+
+This section focuses on avoiding, discovering, and confirming the threat of DPRK IT Workers to your organization.
+The sections dedicated to answering the questions "Am I interviewing a DPRK IT Worker?" and "Did I hire a DPRK IT
+Worker?" are interchangeable and both provide strategy outlines for avoiding, discovering, and confirming DPRK-related
+insider threats. Your organization can use tips from these sections to identify a DPRK IT Worker before you hire them,
+as well as to identify them after you have made the mistake of hiring one.
+
+This section focuses on dealing with emergent situations to identify potential DPRK IT workers who are attempting
+to or already have infiltrated your organization. In the next section,
+([**Mitigating DPRK IT Workers**](/dprk-it-workers/mitigating-dprk-it-workers)), we will discuss strategies to harden
+your organization to minimize both the impact and the chances of infiltration and how to deal with the fallout of
+hiring a DPRK IT Worker.
+
+## How can DPRK IT Workers find a job in your company?
+
+1. There is no single established channel through which a DPRK IT Worker can approach your company.
+    Applying with an impressive CV and GitHub portfolio through a public channel (LinkedIn/Job Portal) is common;
+    however, we have often observed alternative routes, such as:
+     1. **Direct outreach to CEO/CTO.** They are persistent until clearly denied the opportunity, and even then,
+        the actor may change their identity and try again.
+     2. **Initiating contact through open-source contributions.** An actor will submit valid Pull Requests to your
+        repositories and use this as a way to request a job interview.
+     3. **Recommendation.** A worker will come recommended by another DPRK IT Worker or by a company they previously
+        infiltrated (where the company may or may not be aware the employee is a DPRK IT Worker).
+     4. **Tech recruiters.** Recruiters often prioritize evaluating skillsets over performing background checks.
+        DPRK IT Workers can appear on their radar and be unwittingly pushed by a legitimate tech recruiter to your company.
+     5. **Bounty/Hackathon participation.** DPRK IT Workers look for ANY source of revenue, no matter how small or
+        large. If your company runs free-for-all bounty systems, it's extremely likely that some of the contributors are
+        DPRK IT Workers.
+     6. **Hired through a "dev shop."** If you recruit your employees through an outsourcing agency, you need to
+        ensure their vetting process is appropriate. The outsourcing agency itself can be a victim of DPRK IT Worker
+        infiltration.
+2. The bottom line is that there is no single "safe" remote recruitment channel. You should vet your potential
+    employees independently and **look beyond their skillset, which can often be impressive.** We have observed
+    DPRK IT Workers joining companies by utilizing all the channels mentioned above. Establish a high-quality hiring
+    process to avoid recruiting DPRK IT Workers; do not blindly rely on outsourced solutions.
+
+## Am I Interviewing a DPRK IT Worker?
+
+1. The list below can serve as a guide for avoiding hiring a DPRK IT Worker and as an exit-interview guide for
+    verifying if an employee is a DPRK IT Worker.
+2. Before discussing the heuristics: **Don't over-focus on stereotypical DPRK IT worker characteristics, such as being
+    an Asian male in their 20s or 30s, using specific headphones, or obscuring their background. What you are looking for
+    is evidence of misrepresentation and fraud. Job fraud is not exclusive to North Koreans - approach it as such.**
+3. Below is a list of 'red flags' that can help you evaluate with higher confidence if you are dealing with a DPRK IT
+   Worker. However, always keep the above point in mind! For every 'obvious' DPRK IT Worker, there will be some who are
+   able to evade most, if not all, of the following flags:
+     1. **Is their video on?** If not, insist they enable their camera.
+         1. Some DPRK IT Workers have no problem presenting as themselves (without a facilitator, AI, or disabled
+            video). See if you recognize anyone from this
+            [Collection of DPRK IT Workers photos](https://x.com/browsercookies/media).
+     2. **Is the background visible or obscured?** An obscured background isn't always a red flag, but it can be
+        helpful for the final assessment.
+         1. DPRK IT Workers love "stock" backgrounds. You'll often find them using the Golden Gate Bridge as a
+            backdrop. Other times, you may notice them sitting in low-quality housing where the workspace is only divided
+            by temporary walls or rugs.
+     3. Read:
+        [Detect if it's an AI-generated face or
+        deepfake](https://unit42.paloaltonetworks.com/north-korean-synthetic-identity-creation/).
+     4. **Start with small talk** relevant to their claimed nationality and location. This is especially important if
+        you're dealing with someone presenting as an Asian man but providing, for example, Latin American documents/names
+        while claiming to live in Southeast Asia (an identity mismatch). **Note: While a smaller number of female DPRK IT
+        workers have been identified, they do exist. In other cases, you might encounter hired female facilitators. If the
+        candidate claims to be in your country, offer an on-site interview. Beware, DPRK IT workers may send a stand-in.
+        Verify that the person attending is the same one from the call.**
+     5. **Keep an open mind** about gender, nationality, and experience. **DPRK IT workers are known to use
+        facilitators from all over the world. This means you might encounter a non-Korean individual on the call who is,
+        in fact, a DPRK IT worker.** Similarly, a DPRK IT worker's portfolio can sometimes be impressive and not far off
+        from their claimed experience. In previous instances, we've found profiles showing 2-3 years of work for reputable
+        organizations.
+     6. **Go through the candidate's background.** Verify the timelines of their claimed experience (e.g., "You worked
+        at Company X from when to when?"). While the candidate answers, observe if they seem to be reading from a script.
+        Try to mix up details from their claimed experience and note their reaction (e.g., "I see you worked at XYZ," when
+        you know from their CV that they didn't). This is good general advice. If the candidate appears to be relying on
+        ChatGPT for answers (reading from the screen), it's a red flag.
+     7. **Conduct a language comprehension test.** If the candidate claims to be Japanese, ask them questions in
+        Japanese. Beware, some DPRK IT workers can speak Japanese or Chinese, though their proficiency is often similar
+        to their English skills (A1/A2 level). See: [North Korean failing to answer questions in Japanese despite claiming
+        to be
+        Japanese](https://www.ketman.org/dprk-it-workers-in-freelance-platform-onlyDust.html#:~:text=With%20the%20sole,can%20watch%20below.)
+     8. **Ask if the candidate is at home or a co-working space.**
+         1. Look for movement in the background.
+         2. If they claim to be at home, you can try a quick KYC check: **ask them to show their ID card next to
+            their face.**
+     9. **Carefully observe the candidate's screen presentation if they share their screen.** Often, you might notice
+        different GitHub, Gmail, or other social network profiles active on their screen than those claimed in their CV.
+        It's best not to give the candidate a chance to prepare for this. Casually ask, "Could you walk us through your
+        best code on GitHub by sharing your screen?"
+     10. **Evaluating a potential DPRK IT Worker's GitHub profile:**
+         1. The account creation date is later than the commits in its hosted repositories (an artificially aged
+            account). This is especially suspicious if many repositories follow this pattern and the user claims experience
+            aligning with the age of these manipulated commits. This can be a false positive but is usually easy to clear
+            up. Some users re-upload their old code, pre-dating the GitHub account creation date. A false positive for this
+            particular flag can be deduced from the overall quality of the account.
+         2. A high number of followers and accounts followed (e.g., over 200). If the user is a popular developer
+            with a significant online presence, this isn't a red flag. **False positives can occur for accounts that
+            automatically follow back or for Developer Relations (DevRel) and recruitment professionals.**
+         3. A high number of contributors to the user's repositories. If the user is not a popular developer, this
+            is a red flag. Regular developers typically won't have 100+ contributors to their repositories without a
+            significant online presence. **This flag has a tendency to be polluted with high numbers of contributors on
+            "copied" repositories, where a DPRK IT Worker has "injected" themselves as an author but has also kept the
+            original contributors' usernames.**
+         4. Quality of opened Pull Requests and Issues. **It's useful to retrieve the full history of Pull Requests
+            and Issues opened by the user and review them for quality.** For advanced DPRK IT workers, these may not differ
+            significantly from those of regular developers. Additionally, if a suspicious user was `@pinged` in a PR or
+            Issue, it might help uncover a previous nickname. Look for automated or spam-like text/code. DPRK IT Workers
+            will often go for "quantity" over "quality." **At the same time, some DPRK IT Workers will be authors of
+            perfectly valid Pull Requests and Issues - an artifact of their previous employment or a better
+            credibility-building effort.**
+         5. **Overly informative (full of images and stats) GitHub profile README/About page.**
+             1. This can be a false positive. Regular developers have been observed to overuse this section.
+         6. **Avatars.**
+             1. DPRK IT workers often use AI-generated images (not necessarily faces) as their avatars.
+                They typically use freely accessible models like Stable Diffusion or Midjourney.
+             2. "Cartoonish" avatars are also popular: CGI-style images of fictional characters, Minion avatars,
+                and NFT-related avatars (especially Pengu and Doodles).
+             3. **Having no avatar at all is also common.**
+             4. Reference:
+                [Identifying Suspicious Github Accounts](https://www.ketman.org/identifying-suspicious-gh-accounts.html)
+         7. **Social media links.**
+             1. In many cases, there will be a Twitter link. It's always worth visiting.
+                 1. Check the "Media" page for images uploaded by the account owner. **Can you find any
+                    pictures from conferences or showing their physical appearance?** DPRK IT workers usually will not
+                    post pictures from physical locations. **The exception to this rule would be "facilitator" or
+                    "purchased/stolen" accounts.**
+                 2. Look for job-begging tweets.
+                 3. References:
+                     1. [Nick Franklin Case - A well developed IT Worker
+                        persona](https://x.com/tanuki42_/status/1905003045433290940)
+                     2. [Nick Franklin Case - Activity across different
+                        platforms](https://x.com/danielvf/status/1905642180749775189)
+         8. **Suspicious interactions.**
+             1. Contributions to low-quality external repositories and/or organizations. **DPRK IT workers are
+                known to set up "fake" organizations on GitHub, often populated by other IT workers. Similarly, DPRK IT
+                workers will cross-commit to each other's repositories.** It's worth checking the profiles of contributors
+                to the potential threat actor's repositories: are these contributors legitimate themselves? A full data
+                dump of the GitHub account may be useful, but cherry-picking a few repositories from the profile is often
+                effective enough for a first pass.
+                 1. Reference:
+                    [A counter example - Good looking IT Worker Github
+                    Profiles](https://x.com/blackbigswan/status/1873364567285449160)
+         9. **Repositories.**
+             1. "Copied repositories." DPRK IT workers will try to boost their credibility by pushing a clone
+                of a legitimate repository to their own account (Google: "How to fake Github history"). They will often
+                edit the `.git` config and insert their own account data. Usually, they won't remove all original
+                contributors but will insert themselves among them. **Use GitHub's search feature to find the original
+                repository by name, commit SHA, or a unique string extracted from within the repository. Compare the actual
+                account creation date with the profile's UI-displayed history: is it consistent, or is the account's
+                creation date more recent than the years of activity displayed?** A simple API query to get the account
+                creation date from GitHub may be necessary here.
+             2. GitHub's Activity Badge for contributing to an organization. Verify if it's an actual
+                contribution like a PR or commit or just a spam Issue/Comment/PR. This is an often-utilized method for
+                highly popular repositories (e.g., OpenZeppelin, Paradigm) where core developers are reluctant to merge
+                spam PRs.
+                 1. Reference: [DPRK IT Workers faking Github Activity
+                Badges](https://x.com/blackbigswan/status/1876953373187920054/photo/1)
+     11. **Evaluating other immediately available data points:**
+         1. **Full Name.**
+             1. Even if a full name is "fake," it can still be a useful data point. DPRK IT workers rotate their
+                identities, but they need to maintain them for at least some time. **Another challenge they face is
+                managing multiple personas; you may catch an "identity confusion" where a DPRK IT worker uses different
+                names in different places, for example, a different name used/mentioned on GitHub than on a call or on
+                other social profiles.** It's also possible to notice different names used with the same (or different)
+                GitHub owner's email addresses.
+                 1. Take extra care with Asian names, especially Chinese names. Chinese citizens often
+                    westernize or shorten their full names in various ways. This doesn't necessarily mean they are
+                    malicious.
+             2. In most cases, DPRK IT workers prefer to use Asian (Japanese, Chinese, Korean) names. However,
+                they are also known to use fake names from all around the world, corresponding to where their
+                "facilitators" are based. This includes American names ("James" being an extremely popular choice) and
+                even European names (e.g., Polish, Ukrainian, Hungarian).
+                 1. DPRK IT workers may have access to KYC documents issued for their claimed nationality.
+                    **You should be alarmed by highly unorthodox combinations**, such as an Asian man living in Indonesia
+                    with Argentinian KYC documents.
+         2. **Location.**
+             1. Japan and the USA are extremely popular choices for claimed locations. Additionally, Southeast
+                Asian countries like Thailand, Malaysia, Singapore, or Taiwan are also common. The actual physical location
+                is commonly the DPRK (Pyongyang, border regions), China (border regions), Eastern Russia (Vladivostok),
+                Laos (Vientiane), Indonesia, Vietnam, and parts of Africa. It's possible to obtain the IP address of a
+                potential DPRK IT worker through a DocuSign document that collects HTTP headers. DPRK IT workers are known
+                to utilize "laptop farms," meaning they can hide their IP behind an actual fixed/landline IP address in
+                their claimed country of residence.
+         3. **OSINT analysis.**
+             1. We recommend checking each suspicious email address with a service like
+                [https://epieos.com](https://epieos.com). It can provide additional data points, such as a LinkedIn
+                profile, which can uncover further identity mismatches.
+                 1. On LinkedIn, examine the strength of the actor's connection network.
+
+## Did I hire a DPRK IT Worker?
+
+1. The list below serves as a guide for confirming your suspicions if one of your employees is a potential
+    DPRK IT Worker. We're focusing on using non-enterprise flags accessible to even the smallest of projects.
+    The assumption is that your project has limited EDR/SIEM logging infrastructure (you should, however, consider
+    implementing some monitoring infrastructure in the future).
+     1. If your organization has EDR/SIEM capability, Read:
+        [DTEX advisory on DPRK Insider Threat Kill
+        Chain](https://www.dtexsystems.com/resources/i3-threat-advisory-inside-the-dprk/)
+     2. Consider using GitHub Enterprise for your organization to have access to more detailed logs.
+2. Before discussing the heuristics: **Don't focus on negating your suspicion; focus on clearing it up.
+    It doesn't matter if you're checking a long-time employee who provides good technical output, is not Korean/Asian,
+    logs into the workspace using a US-based IP, or came recommended. DPRK IT Workers have been known to successfully
+    evade detection for YEARS.** Focus on creating a full profile of your employee and judge it based on the complete
+    picture and any inconsistencies you find.
+3. Below is a list of 'red flags' that should prompt immediate action from your side (e.g. a deep background check):
+     1. **Avoiding real-life meetings.** Even if they initially agree to meet, they might come up with explanations
+        as to why they can't. They often cite 'family reasons' or 'travel abroad.' The situation can repeat itself for
+        every single meeting proposal, regardless of the location. **You can propose to meet at their location as a final
+        test.**
+     2. **Inconsistencies in work and communication.** It's often the case that a single DPRK IT Worker account is
+        operated by a few individuals, especially if your company communication is sparse. One week you may observe good
+        quality and high output; the next week, a significant drop. Similarly, for communication, you may observe the
+        worker being overly 'mute' on all company sync calls or clueless as to what was discussed in previous meetings.
+        They will also often have issues communicating about their code but not with the code development itself
+        (a sign of more than one worker on a single account).
+     3. **Timezone.** If your worker claims to be in Texas (GMT-5) but is located in Pyongyang (GMT+9), you may
+        observe work patterns closer to North Korean time than to Texan time. Note that DPRK IT Workers work around the
+        clock and can circumvent this flag easily.
+     4. **Bogus work history.** Verify if the job history claimed on their CV is real. You can always reach out to
+        the previous company for background information. In most cases, the history will be made up, but there are
+        exceptions. DPRK IT Workers may list legitimate companies for which they did previous work but were let go
+        (without that company's knowledge of their true nature). Sometimes, DPRK IT Workers will list organizations
+        they control, so exercise caution when contacting anyone for background information.
+     5. **Identity switch.** Be on guard if an employee's profile suddenly changes its nickname/identity.
+        DPRK IT Workers do this often, usually when discovered in one of their previous jobs and for fear that someone
+        will notify your company. **They may suddenly start using a different GitHub handle (this includes suddenly pushing
+        a Pull Request using a different account than usual), delete their social media accounts, or get banned from
+        LinkedIn.** Additionally, they may occasionally 'confuse' their fake identities and log in to your company
+        workspace or a meeting using a completely different account.
+     6. **Identity mismatch.** It should raise questions if your employee is Asian but provides non-Asian KYC
+        documentation along with poor language skills. **Run a background check on all the data.** Can you find a person
+        with the same name whose identity was potentially stolen or borrowed? Is the address provided legitimate, or does
+        it seem 'random' (e.g., an empty house, a business venue)? Google "(Full Name of your worker) + sentenced" to see
+        if the DPRK IT Worker bought a criminal's identity (an often-seen case with claimed US-based personas). Perform a
+        reverse image search on your worker's profile pictures/avatars. Are there more similar accounts using the exact
+        same image? **Beware that DPRK IT Workers have no issues providing credible-looking KYC documentation; some of
+        these documents even pass authentication checks on specialized services.**
+     7. **Recommending other suspicious accounts for work.** DPRK IT Workers will leverage their initial foothold
+        in your organization to propose other DPRK IT Workers for a job. Their recommendations will usually follow the
+        same patterns. Many organizations fall for it and hire multiple workers **(sometimes, as much as 50-70% of the
+        entire company is composed of DPRK IT Workers if such tactics succeed).** Additionally, check if the potential
+        DPRK IT Worker hasn't already added some of their 'friends' to your organization without your knowledge.
+     8. **Proximity to other suspicious/spam accounts.** Don't be fooled by GitHub or Twitter accounts that are over
+        10 years old. DPRK IT Workers can easily source these. However, check if your worker has any meaningful history of
+        interaction with their followers/following. Or, do all accounts in proximity to your worker appear spam-like or
+        like bots?
+     9. **Poor social skills.** It's usually (but not always) the case that a DPRK IT Worker will have trouble with
+        'small talk.' This isn't necessarily because of cultural differences (DPRK IT Workers are educated on Western
+        culture and language as part of their job). It's often because of the sheer volume of remote gigs they handle
+        and how confusing it can be. A DPRK IT Worker will prefer to always steer the conversation toward technical details.
+     10.**Review Workspace logs (IP addresses).** Check if the IP addresses used to log in to your infrastructure
+        are coming from the same location as claimed by the worker. VPNs, proxies, or Russian ISPs are red flags, as
+        are highly inconsistent IP ranges (a mix of the sources mentioned). Beware that DPRK IT Workers are known to
+        utilize "Laptop Farms."
+        Read: [North Korea Infiltrates U.S. Remote Jobs - With the Help of Everyday Americans](https://archive.ph/Mb68C)
+     11.**Payments.** North Koreans can organize a 'drop' bank account to receive wire transfers; however, their
+        preferred method of receiving a salary will be through cryptocurrency, usually at a flat rate that they
+        will not try to negotiate. In most cases, DPRK IT Workers will work at a discount to industry standards
+        without complaining (25-50% discount). It may be the case that the worker's CEX account gets frozen, and they will
+        come back to your organization for help unfreezing it (by providing proof of employment).
+
+## After a DPRK IT Worker is hired by your company:
+
+1. **The main goal of a DPRK IT Worker is to keep their job and salary coming for as long as possible.** It's worth
+    understanding that DPRK IT Workers themselves vary in quality. For more 'senior' workers, keeping the job will be easy
+    as their output and technical skills are high. For 'junior' ones, the engagement may end on the basis of poor
+    performance.
+     1. We have observed cases where DPRK IT Workers are fine with taking a salary cut to help a project stay afloat,
+        as long as they continue to be paid.
+2. **The highest risk to your organization, which occurs immediately after you on-board the DPRK IT Worker, is a data
+    and secrets leak.** DPRK IT Workers do not care about your organization's and their operational security. When you
+    assign access to a single DPRK IT Worker, you can be sure more individuals are using the same access. Unbeknownst to
+    you, everything that's private to this single worker is now accessible over a (usually) poorly secured internal DPRK
+    IT Worker network.
+3. **We have observed DPRK IT Workers passing access or sensitive information to DPRK Hacking teams.**
+    This is not often the case, as the goal of the DPRK IT Worker is to keep their job and salary as opposed to a one-time
+    hack. However, if the target is high-value, they won't hesitate or may not even have a say in whether or not their
+    employer is targeted for a hack.
+4. Some DPRK IT Workers also perform tasks adjacent to malicious campaigns like the "Contagious Interview." Read:
+    [North Korean Threat Actors lure tech job seekers as fake
+    recruiters](https://unit42.paloaltonetworks.com/north-korean-threat-actors-lure-tech-job-seekers-as-fake-recruiters/)
+    and [Two Campaigns by North Korea Bad Actors target job
+    hunters](https://unit42.paloaltonetworks.com/two-campaigns-by-north-korea-bad-actors-target-job-hunters/).
+    Your North Korean employee **may leverage the credibility granted by being employed at your company to conduct
+    malware-related campaigns in the present and future.** This could significantly affect your brand.
+5. **A DPRK IT Worker will try to escalate their access if possible**, whether by adding new members (who will also
+    be getting paid) or by getting permissions to release builds and packages. Additionally, **we have encountered
+    situations where DPRK IT Workers were added as signers to the multisig wallets** of the entire project as part
+    of the dev team!
+6. **DPRK IT Workers won't report code vulnerabilities to you** and may leave them for future exploitation.
+    First, they generally do not care about and are not invested in the success of your project to protect it from
+    being hacked. Second, they may intentionally leave the backdoor with the intent to use it in the future. Lastly,
+    they may simply miss the vulnerability because they are overworked across numerous remote gigs they're performing
+    at once.
+
+In the next section [**Mitigating DPRK IT Workers**](/dprk-it-workers/mitigating-dprk-it-workers) we will be discussing
+ways to harden your organization and employees against the DPRK IT Worker threat.
+
+---
+
+---
+
+### PAGE: /guides/account_management/telegram
+**Title:** Telegram Security
+**Referenced by controls:** ws-3.1.4, ws-5.1.2
+
+# Telegram Security
+
+
+
+
+## Summary
+
+> 🔑 **Key Takeaway:** Stay vigilant with group chats on Telegram. Implement verification steps and secure communication
+> practices to protect against sophisticated interception attacks.
+
+While **Telegram** is widely used in the crypto community, it's crucial to understand its security limitations. Telegram
+**does not** offer end-to-end encryption (**E2EE**) by default, which means your messages could potentially be accessed
+by third parties. Additionally, Telegram's reliance on phone numbers for account creation can expose users to SIM
+swapping attacks, and its peer-to-peer call feature can reveal your IP address to other users. If **E2EE** is a
+priority, consider using [Signal](https://signal.org/).
+
+However, if you choose to use **Telegram**, the following best practices can help enhance your security.
+
+---
+
+## For Individuals
+
+These settings apply to your personal Telegram account. All team members and admins should configure these on their own accounts.
+
+### Account Security Checklist
+
+- Account Settings:
+    - Privacy & Security >
+        - Security >
+            - [ ]  Two-Step Verification > **On**
+                - Telegram does not require a login by default. However, you can set up a password that acts as a "second" 2FA method when logging in from a new device.
+                - Telegram sign-ups require a phone number, but you can also enable two-factor authentication via a password—your main protection if you're ever SIM-swapped. **Don't reuse this password anywhere else.**
+                - Do not set a password hint, do add a recovery email
+                - **SMS Codes:** Telegram sends a code via SMS, which is not secure.
+                - **Email Recovery:** Offers email recovery, which is more secure but lacks options for authenticator apps or hardware keys.
+                - **Backup Password:** If you lose this password, access to your account may be compromised. Write it down offline and ensure it is not lost.
+            - [ ]  Local passcode > **On** (recommended)
+                - This feature adds a passcode to access your Telegram app after a period of inactivity. The default setting is "away for 1 hour."
+                - **Store Passcode Securely:** Do not lose this passcode—store it offline if needed.
+                - **Unique Passcode:** Ensure it is different from your phone's unlock passcode.
+            - Active sessions >
+                - Telegram supports auto-terminating inactive sessions. You can also manually review and end any suspicious active sessions.
+                - [ ]  Review and delete all unused sessions
+                - [ ]  Terminate old sessions > **1 month**
+        - Privacy >
+            - Consider adjusting the following settings based on your country, usage, and purpose for using Telegram:
+            - [ ]  Phone Number > Who can see my phone number > **Nobody**
+                - Making your phone number visible can expose you to unwanted contact or social engineering attacks. Restricting visibility helps safeguard your personal info.
+            - [ ]  Phone Number > Who can find me by my number > **My Contacts**
+            - [ ]  Phone Number > Exceptions > Remove all
+            - [ ]  Last Seen & Online > Who can see my timestamp > **Nobody**/**My Contacts**
+            - [ ]  Last Seen & Online > Exceptions > Remove all
+            - [ ]  Profile Photo > Who can see my profile photo > **Everybody**
+                - Set to **Everybody** to stop scammers from impersonating your profile picture.
+            - [ ]  Bio > Who can see my bio > **Nobody** (depending on use of Telegram)
+            - [ ]  Date of Birth > Who can see my date of birth > **Nobody**
+            - [ ]  Date of Birth > Exceptions > Remove all
+            - [ ]  Forwarded Messages > Who can add a link to my account when forwarding my messages > **Nobody**
+            - [ ]  Calls > Who can call me > **Nobody**/**My Contacts**
+            - [ ]  Calls > Exceptions > Remove all
+            - [ ]  Calls > Peer-to-peer > Use peer-to-peer with > **Nobody**/**My Contacts**
+                
+                > **Note**: Peer-to-peer calls leak your IP address to callers. Set to **Nobody** to preserve anonymity
+                
+            - [ ]  Calls > Peer-to-peer > Exceptions > Always allow > Remove all
+            - [ ]  Groups & Channels > Who can add me to groups and channels > **Nobody**/**My contacts**
+                - This helps prevent being added to random groups that may impersonate legitimate groups and lead to scams.
+            - [ ]  Groups & Channels > Exceptions > Remove all
+            - [ ]  Voice Messages > Who can send me voice messages > **Nobody**/**My contacts**
+            - [ ]  Voice Messages > Exceptions > Remove all
+            - [ ]  Messages > Who can send me messages > **My Contacts and Premium Users** (or **Everybody**/**My Contacts** depending on use of Telegram)
+        - [ ]  New chats from unknown users > Archive and Mute > **Enabled**
+        - [ ]  Bots and website > **Clear Payment and Shipping Info**
+        - [ ]  Auto-Delete Messages > Set a time frame (e.g., 1 week) based on your risk tolerance
+            - Consider the photo you shared with a friend several months ago. While it might have slipped your mind, an attacker who gains access to your account could find such information quite valuable.
+    - Advanced >
+        - [ ]  Automatic media download > Disable all types in all cases
+            
+            > **Note**: Automatic media download leaves you exposed to advanced malware attacks
+            
+        - Version and updates >
+            - Ensure you are always using the latest version of Telegram to benefit from the newest security patches and features.
+            - [ ]  Check for Updates: Visit your device's app store regularly
+            - [ ]  Update automatically > **Enabled**
+            - [ ]  Install beta versions > **Disabled**
+
+> **Authentication Guidelines**: When establishing a secret chat, [compare the encryption keys](https://core.telegram.org/techfaq#q-how-are-secret-chats-authenticated) outside of telegram, in an established/authenticated channel, outside of telegram. When establishing a peer-to-peer (encrypted) call, [compare the emojis](https://core.telegram.org/techfaq#q-how-are-voice-and-video-calls-authenticated) in an established/authenticated channel, outside of telegram. These are your defenses against man-in-the-middle attacks. You **must** confirm these details if using Telegram for private communications. That said, it is suggested to use a secure platform like [Signal](https://signal.org/) for confidential communication.
+
+---
+
+### Device-Level Security
+
+Securing the device you use for Telegram is crucial for preventing unauthorized access to your account and messages.
+
+- [ ]  **Enable Full Device Encryption**:
+    - Ensure your device has full disk encryption enabled
+    - For iOS: This is enabled by default with a passcode
+    - For Android: Go to **Settings > Security > Encryption** and follow instructions
+
+- [ ]  **Set Strong Device Passcodes**:
+    - Use alphanumeric passwords rather than simple PINs
+    - Enable biometric authentication as a secondary measure
+
+- [ ]  **Keep Your Device Updated**:
+    - Install OS updates promptly to patch security vulnerabilities
+    - Update Telegram to the latest version regularly
+
+- [ ]  **Install Security Software**:
+    - Use reputable anti-malware software on your device
+    - Consider privacy-focused apps that detect network anomalies
+
+- [ ]  **Secure Your Backups**:
+    - Ensure any device backups containing Telegram data are encrypted
+    - Be cautious about cloud backups that might store Telegram messages
+
+---
+
+### Advanced Privacy Measures
+
+#### Consider Using a Different Phone Number
+
+Even if you implement all the recommended security measures, there are still valid reasons to use a separate phone
+number. For instance, it can help prevent your contacts from discovering your Telegram account or reduce the risk of
+accidental number exposure. This is particularly important because the **"Share My Phone Number"** option is enabled by
+default whenever you add a new contact.
+
+**Using a VoIP Number**
+
+Telegram restricts many VoIP providers, but services like [Google Voice](https://voice.google.com/) or
+[Burner](https://www.burnerapp.com/) might work. Purchase a burner number solely for Telegram if you prefer additional
+anonymity.
+
+**Using an Anonymous Number**
+
+In December 2022, Telegram introduced support for anonymous numbers purchased through its [TON](https://ton.org/)
+blockchain infrastructure. You can also check out [Fragment](https://fragment.com/) for such options.
+
+#### Use Secret Chats for Enhanced Privacy
+
+For conversations that require an extra layer of security, use Telegram's Secret Chats, which offer **end-to-end
+encryption**.
+
+1. **Start a Secret Chat**: Open the chat with the desired contact, tap on their name, and select **Start Secret Chat**
+2. **Benefits**:
+   - Messages are encrypted and can only be read by you and the recipient
+   - Offers self-destruct timers for messages
+   - Prevents forwarding of messages to other chats
+
+#### Data Settings
+
+**Go to:** Settings > Privacy and Security > Data Settings
+
+- [ ]  **Sync Contacts:** Disable (depending on use of Telegram) to prevent syncing your contacts.
+- [ ]  **Suggest Frequent Contacts:** Disable (depending on use of Telegram) to avoid unsolicited contact suggestions.
+
+---
+
+### Best Practices for Safe Use
+
+- [ ]  **Use Secret Chats:** When messaging someone, create a 'secret' chat to ensure encrypted 1:1 communication, providing end-to-end encryption for sensitive transactions.
+- [ ]  **Verify Group Invites and Authenticity:** Always triple-check group invitations and confirm the legitimacy of group chats through separate channels to avoid joining impostor groups that share malicious links.
+- [ ]  **Beware of Unsolicited DMs:** Never trust direct messages from anyone sending links or posing as "support," "exchanges," or "team" members.
+- [ ]  **Double-Check Payment Details:** Verify payment information through multiple methods before transferring funds to prevent fund redirection.
+- [ ]  **Block and Report Scammers:** Use the block function to prevent further contact, and report spammers/scammers instead of just deleting chats.
+- [ ]  **Be Cautious with Third-Party Bots and Integrations:**
+    - Third-party bots can enhance functionality but may also introduce vulnerabilities.
+    - Only add bots from reputable sources
+    - Limit the permissions you grant to bots
+    - Periodically review and remove unnecessary bots
+- [ ]  **Exercise Caution with Mini Apps:** Avoid logging in or providing information to mini apps that redirect outside of Telegram. Triple-check the username of the mini app to ensure its legitimacy, as Telegram lacks a bot verification system. Never download or run any commands from Telegram on your device.
+- [ ]  **Enhance Privacy with a VPN:** *Advanced tip:* Set up a proxy or VPN to hide your IP address while using the Telegram app.
+- [ ]  **Stay Vigilant Against Scam Ads:** Be aware that anyone can post ads in channels, with 99% being scam ads. Exercise caution when interacting with advertisements.
+
+---
+
+### Platform-Specific Risks: Man-in-the-Group Attack
+
+Attackers can exploit Telegram's group chat features to intercept and manipulate communications between two parties.
+Here's a concise example of how such an attack might occur:
+
+#### Scenario: Intercepting a Payment Deal
+
+**Step 1: Initial Communication**
+
+- **Alice** and **Bob** decide to finalize a cryptocurrency deal using a Telegram group chat named **"Crypto Deals"**.
+
+**Step 2: Attackers Create Cloned Groups**
+
+- **Attacker 1** creates **Group A** impersonating **Alice**.
+- **Attacker 2** creates **Group B** impersonating **Bob**.
+
+**Step 3: Replicating Conversations**
+
+- **In Group A (Impersonating Alice):**
+  - The attacker, posing as Alice, relays Alice's messages from Group B to maintain the conversation.
+
+- **In Group B (Impersonating Bob):**
+  - The attacker, posing as Bob, mirrors Bob's messages from Group A, acting as a middleman without altering the
+    content.
+
+**Step 4: Swapping Payment Details**
+
+- **In Group A:**
+  - Fake Alice and Bob agree to the terms of the deal.
+  - Bob shares his payment address.
+
+- **In Group B:**
+  - Fake Bob shares his swapped payment address.
+  - The conversation continues normally, with neither Alice nor Bob aware of the swap.
+
+**Step 5: Execution of the Scam**
+
+- **Alice** sends the payment to what she believes are Bob's details but are actually those of Fake Bob.
+- The attacker now controls both ends of the conversation, having successfully redirected the funds.
+
+---
+
+## For Team Members
+
+These guidelines apply to team members who help manage Telegram groups/channels but don't have full administrative access.
+
+Team members should:
+- Ensure their individual account settings are configured according to the checklist above
+- Each admin must follow the guidance for securing their individual accounts
+- Add a suffix to your username, for example: "MyName | will never DM you"
+- Understand how to verify the authenticity of admins and official messages
+- Be aware of the Man-in-the-Group Attack scenario described above
+
+---
+
+## For Admins
+
+These settings and practices apply to Telegram group/channel administrators with elevated privileges.
+
+### Channel & Group Settings Checklist
+
+#### Channel Settings
+
+- Open channel > click channel name > **Channel settings**
+    - [ ]  Sign messages > **Enable** (if non-repudiation is desired)
+    - [ ]  Administrators > Review the list and remove any unnecessary
+
+#### Group Settings
+
+- Open group > click group name > click three dots > **Manage group**
+    - [ ]  Channel type > **Private** (if public discoverability is not necessary)
+    - [ ]  Channel type > Content protection > **Enabled** (if confidentiality is needed)
+    - [ ]  Sign messages > **Enabled**
+    - [ ]  Chat history for new members > **Hidden**
+        - This is not available if Topics are enabled
+    - **Permissions:**
+        - [ ]  Send media > should be restricted appropriately
+            - At minimum, **Files** and **Embed links** should be disabled
+        - [ ]  Add members > **Disabled** (if not necessary) [[1]](#1-member-control)
+        - [ ]  Pin messages > **Disabled**
+        - [ ]  Change group info > **Disabled**
+        - [ ]  Slow mode > At least **10s**, if not obstructive
+        - [ ]  Exceptions should be restricted to valid use cases
+            - Team members should have exceptions granted to them for these rather than them being admins, when possible
+    - [ ]  **Invite links** > Review and remove unnecessary
+        - Links should be limited by time period or number of users, when not obstructive
+    - [ ]  **Administrators** > Review and remove unnecessary & review permissions of each admin
+        - Again, it is recommended to add exceptions for team members rather than add them as admins, when possible
+        - Remove unnecessary permissions, especially **Add new admins**
+        - **Aggressive Anti-Spam** > **Enabled**
+    - [ ]  **Members** > Review and remove unnecessary (If a confidential channel)
+
+---
+
+### Admin Permissions Management
+
+If you manage Telegram groups or channels, properly configuring admin permissions is crucial for maintaining security.
+
+- [ ]  **Limit Admin Privileges**:
+    - Go to your group/channel, tap the group name, select **Administrators**
+    - Only grant necessary permissions to each admin
+    - Avoid giving "Add Users" permission to untrusted admins
+
+- [ ]  **Implement Admin Verification**:
+    - Establish a verification process before promoting members to admin
+    - Use separate channels (like voice calls) to confirm admin identities
+    - Document when admin changes occur and why
+
+- [ ]  **Configure Group Settings**:
+    - Restrict member actions such as sending media or links
+    - Enable "Slow Mode" for large groups to prevent spam
+    - Use discussion groups for channels to control information flow
+
+- [ ]  **Audit Admin Activities**:
+    - Regularly review admin actions in the group
+    - Remove inactive or suspicious admins
+    - Consider using admin action logs if available
+
+- [ ]  **Handle Admin Transitions Securely**:
+    - Have protocols for transferring ownership if needed
+    - Revoke admin rights immediately when team members leave
+
+- [ ]  **Limit Group Permissions:** Restrict who can add members to groups to prevent unauthorized cloning and protect against raids.
+
+---
+
+### Additional Recommendations
+
+- [ ]  Add a disclaimer in the description and/or as a pinned message to your channel that states that you will not DM users, and that support will only be offered via the public channel and dedicated support channels [[2]](#2-security-disclaimers)
+- [ ]  Add a suffix to admin usernames, for example: "MyName | will never DM you"
+- [ ]  Each admin must follow the guidance for securing their individual accounts
+
+---
+
+### Educate Community Members on Security Practices
+
+If you're managing a community on Telegram, educating your members about security is vital for collective protection.
+
+- [ ]  **Regular Security Announcements**:
+    - Schedule periodic reminders about security best practices
+    - Pin important security announcements in your group/channel
+    - Create dedicated security FAQ channels or posts
+
+- [ ]  **Clear Verification Procedures**:
+    - Establish and communicate how official communications will occur
+    - Create verification steps for new members to follow
+    - Document how to verify the authenticity of admins and official messages
+
+- [ ]  **Threat Awareness Training**:
+    - Share examples of common scams targeting your community
+    - Post screenshots of phishing attempts (with sensitive info redacted)
+    - Explain the "Man-in-the-Group Attack" and how to avoid it
+
+- [ ]  **Incident Reporting Protocol**:
+    - Create clear guidelines for reporting suspicious activity
+    - Designate security-focused admins to handle reports
+    - Acknowledge reports publicly (without specifics) to encourage vigilance
+
+- [ ]  **Security Resources**:
+    - Develop simple, accessible security guides for members
+    - Share platform-specific security updates when Telegram releases them
+    - Create a security checklist for new community members
+
+---
+
+### Notes
+
+#### [1] Member Control
+
+Restricting the ability to add only to admins allows for revocability of invite links to stop raids or to freeze the channel if needed.
+
+#### [2] Security Disclaimers
+
+Telegram channels and groups should not be used for any confidential communication, as they are not end-to-end encrypted, except for 1:1 "secret chats" (which should not be commingled with unencrypted chats).
+
+Example disclaimer: "We will NEVER message you directly to offer support or assistance with our product. For support, please email us at support@\<company\>.com. DO NOT interact with anyone DMing and claiming to be a \<company\> member. Please report scams to reports@\<company\>.com"
+
+---
+
+---
+
+### PAGE: /opsec/core-concepts/implementation-process
+**Title:** OpSec Implementation Process | SEAL
+**Referenced by controls:** ws-4.1.1
+
+# Operational Implementation Process
+
+
+
+
+> 🔑 **Key Takeaway**: Operational security is implemented through a practical five-phase process: critical asset
+> identification, practical threat analysis, actionable vulnerability assessment, contextual risk evaluation, and
+> targeted control deployment.
+
+## Relationship to Security Fundamentals
+
+This document outlines a practical implementation process for operational security that organizations can follow in
+sequence. This process complements the [Security Fundamentals](/opsec/core-concepts/security-fundamentals) document,
+which defines the guiding principles:
+
+- This process provides a **sequential workflow** for security teams to follow
+- The fundamentals establish **enduring principles** that shape security architecture
+
+While this process offers a concrete methodology for implementation, the fundamentals establish the ongoing security
+approaches that must be maintained throughout your systems. Both elements must work together: the fundamentals guide
+your overall approach, while this process provides the tactical roadmap.
+
+For organizations just beginning their security journey, start here with these concrete implementation steps.
+
+## 1. Critical Asset Identification
+
+Map and document the assets that would cause significant harm to your organization if compromised.
+
+> **🔗 Related Framework:** This phase integrates with [Asset Inventory](/infrastructure/asset-inventory) practices and
+> drives [Data Protection](/opsec/old/data-protection/overview) strategies.
+
+### Implementation Actions
+
+1. Conduct asset discovery across your environment using both automated tools and manual inventorying
+   - Digital assets: Use network scanning, CMDB tools, and cloud resource inventories
+   - Physical assets: Document hardware, systems and access points
+2. Apply a practical classification system with clear, actionable categories
+   - High-value assets: Direct financial impact if compromised (e.g., private keys, treasury wallets)
+   - Operational assets: Required for continued business operations
+   - Sensitive data: Includes Customer information, intellectual property, strategic plans
+3. Map information flows to understand how data moves between systems
+4. Assign specific owners responsible for each asset category
+5. Establish a sustainable review cadence based on your environment
+   - High-volatility environments: Monthly reviews
+   - Stable environments: Quarterly reviews
+   - Document trigger events that require immediate reassessment (e.g., acquisitions, new product, etc.)
+
+## 2. Practical Threat Analysis
+
+Identify specific, relevant threat actors and their tactics based on your organization's profile.
+
+> **🔗 Related Framework:** For hands-on approaches, see
+> [Understanding Threat Vectors](/awareness/understanding-threat-vectors) and [Threat Modeling](/threat-modeling/overview)
+> frameworks.
+
+### Implementation Actions
+
+1. Create a focused threat profile based on:
+   - Your industry's recent attack history (consult threat intelligence reports)
+   - Your organization's specific attack surface
+   - The value of your assets to different adversaries
+2. Document concrete adversary personas with specific capabilities:
+   - External attackers: Targeted vs. opportunistic
+   - Insider risks: Privileged users, contractors, disgruntled employees
+   - Supply chain actors: Vendors with access to your systems
+3. Map threat actors to their likely tactics using MITRE ATT&CK or similar frameworks
+4. Establish threat intelligence feeds relevant to your environment
+5. Create a lightweight process for updating threat models when new intelligence emerges
+
+## 3. Actionable Vulnerability Assessment
+
+Systematically identify and validate weaknesses in your environment through practical testing.
+
+> **🔗 Related Framework:** This aligns with the [Security Testing](/security-testing/overview) framework and includes
+> practices like [Static Application Security Testing](/security-testing/overview) and [Dynamic Application Security Testing](/security-testing/overview).
+
+### Implementation Actions
+
+1. Implement a layered vulnerability discovery program:
+   - Automated scanning: Deploy tools appropriate for your environment (infrastructure, applications, cloud)
+   - Manual testing: Conduct regular penetration tests focusing on critical systems
+   - Red team exercises: Simulate real-world attacks against your defenses
+2. Examine security processes for operational gaps:
+   - Incident response procedures: Test through tabletop exercises
+   - Access management: Audit privilege escalation paths
+   - Change management: Review for security bypass opportunities
+3. Evaluate security awareness through:
+   - Targeted phishing simulations
+   - Knowledge assessments
+   - Procedural compliance checks
+4. Document findings in a centralized vulnerability management system with clear ownership
+5. Implement a consistent vulnerability scoring system to enable prioritization
+
+## 4. Contextual Risk Evaluation
+
+Analyze identified risks in the context of your business to drive informed decision-making.
+
+> **🔗 Related Framework:** For practical approaches, see [Governance](/governance/overview) and
+> [Risk Management](/governance/risk-management) frameworks.
+
+### Implementation Actions
+
+1. Establish a practical risk calculation methodology that considers:
+   - Business impact (financial, operational, reputational)
+   - Exploitation likelihood based on real-world attack patterns
+   - Existing control effectiveness
+2. Create a prioritized risk register with clear owners and timelines
+3. Define risk acceptance criteria based on your organization's risk tolerance
+4. Develop risk narratives that translate technical findings into business impacts
+5. Implement a streamlined risk review process that:
+   - Enables timely decisions
+   - Involves appropriate stakeholders
+   - Documents rationale for future reference
+   - Triggers reassessment when conditions change
+
+## 5. Targeted Control Deployment
+
+Implement security controls that address prioritized risks while minimizing operational friction.
+
+> **🔗 Related Framework:** Implementation integrates with [Security Automation](/security-automation/overview) and
+> control frameworks like [Infrastructure](/infrastructure/overview) and
+> [Identity and Access Management](/iam/overview).
+
+### Implementation Actions
+
+1. Design a defense-in-depth strategy with layered controls:
+   - Preventive: Stop attacks before they succeed
+   - Detective: Identify attacks in progress
+   - Responsive: Limit damage from successful attacks
+   - Recovery: Restore normal operations
+2. Select controls using a balanced approach:
+   - Technical feasibility in your environment
+   - Implementation and maintenance costs
+   - Potential operational impact
+   - Coverage of multiple risks where possible
+3. Implement controls using a phased approach:
+   - Quick wins: Deploy high-impact, low-effort controls first
+   - Foundational controls: Build core security capabilities
+   - Advanced measures: Address sophisticated threats
+4. Validate control effectiveness through:
+   - Technical testing
+   - Process verification
+   - Metrics collection
+5. Document clear procedures for:
+   - Control operation
+   - Maintenance requirements
+   - Monitoring and alerting
+   - Incident response when controls fail
+
+---
+
+---
+
+### PAGE: /guides/account_management/github
+**Title:** GitHub Security
+**Referenced by controls:** ws-4.1.2
+
+# GitHub Security
+
+
+
+
+## Summary
+
+> 🔑 **Key Takeaway for GitHub:** Secure your GitHub account with non-SMS two-factor authentication, enable push protection, and regularly review connected apps and sessions. For organizations, enforce signed commits, branch protection rules, and restrict member privileges to minimize supply chain attack risks.
+
+This checklist is adapted from [Auditware's W3OSC](https://github.com/W3OSC/web3-opsec-standard) standards.
+
+---
+
+## For Individuals
+
+These settings apply to your personal GitHub account. All team members and admins should configure these on their own accounts.
+
+### Individual Account Settings
+
+- Account Settings:
+    - [ ]  Public profile > Contributions & activity > Make profile private and hide activity > **On**
+    - [ ]  Password and authentication > Two-factor authentication > Enable and configure any method other than **SMS/Text message**
+    - [ ]  Sessions > Review and revoke any unrecognized or unnecessary
+    - [ ]  SSH and GPG keys > Review and remove any unnecessary
+    - [ ]  Organizations > Review and leave any unnecessary
+    - [ ]  Code security > User > Push protection for yourself > **Enabled**
+    - [ ]  Applications > Review and remove any unnecessary
+    - [ ]  Developer settings >
+        - [ ]  GitHub Apps > Review and remove any unnecessary
+        - [ ]  OAuth Apps > Review and remove any unnecessary
+        - [ ]  Personal access tokens > Review and remove any unnecessary
+
+---
+
+## For Team Members
+
+These guidelines apply to team members who contribute to repositories but don't have administrative access.
+
+Team members should:
+- Ensure their individual account settings are configured according to the checklist above
+- Enable GPG signing for commits to meet signed commit requirements
+- Be aware of branch protection rules that may require pull request approvals
+- Regularly review and rotate personal access tokens
+- Report any suspicious repository activity to organization admins
+
+---
+
+## For Admins
+
+These settings and practices apply to GitHub organization administrators with elevated privileges.
+
+### Repository Settings
+
+#### General Settings
+
+- [ ]  General > Danger Zone > Repository visibility > **Private**
+- [ ]  Collaborators and teams > Review access and remove any unnecessary
+    - [ ]  Ensure there are no more than 3 admins
+
+#### Branch Protection
+
+- [ ]  Branches > Branch protection rules > For each branch that triggers automated deployments, set the following protections:
+    - Protect matching branches > Require a pull request before merging
+        - Require approvals > **2+** recommended
+    - Rules applied to everyone including administrators > Allow force pushes > **Off**
+
+#### Repository Rules
+
+- Rules > Rulesets > New ruleset > New branch ruleset:
+    - [ ]  **Name**: EnforceSignedCommits
+        - **Targets**: All branches
+        - **Rules**:
+            - Require signed commits > **On**
+    - [ ]  **Name**: BlockForcePushes
+        - **Targets**: All branches
+        - **Rules**:
+            - Block force pushes > **On**
+
+#### Actions Security
+
+- Actions >
+    - [ ]  Actions permissions > Set minimum permissions needed
+        - **Disable actions** - if not needed
+        - **Allow organization actions and reusable workflows** - if only internal actions are used
+        - **Allow organization, and select non-organization, actions and reusable workflows** - if external actions are used
+    - [ ]  Fork pull request workflows > Run workflows from fork pull requests > **Off**
+    - [ ]  Workflow permissions > **Read repository contents and packages permissions**
+        - [ ]  Allow Github Actions to create and approve pull requests > **Off**
+    - [ ]  Access > **Not accessible**
+
+#### Security Features
+
+- [ ]  Webhooks > Review webhooks and delete any unnecessary or overly permissive
+- [ ]  Pages > Branch > **None** (to disable)
+- Code security >
+    - [ ]  Dependency graph > **Enabled**
+    - [ ]  Dependabot alerts > **Enabled**
+    - [ ]  Dependabot security updates > **Disabled**
+    - [ ]  Grouped security updates > **Disabled**
+    - [ ]  Dependabot version updates > **Disabled**
+    - [ ]  Access to alerts > No additional users (only admins)
+
+#### Access Control
+
+- [ ]  Deploy keys > Remove all [[1]](#1-deploy-keys-warning)
+- [ ]  Secrets and variables > Review secrets and variables and remove any unnecessary
+- [ ]  GitHub Apps > Installed GitHub Apps > Review configurations and uninstall any unnecessary
+    - [ ]  Review permissions are appropriate and that repository access is scoped only to relevant repositories
+
+### Organization Settings
+
+#### Member Privileges
+
+- Member privileges >
+    - [ ]  Base permissions > Any other than **Admin**
+    - [ ]  Repository creation > Public > **Off**
+    - [ ]  Repository forking > Allow forking of private repositories > **Off**
+    - [ ]  Projects base permissions > Any other than **Admin**
+    - [ ]  Integration access requests > Allow integration requests from outside collaborators > **Off**
+    - Admin repository permissions >
+        - [ ]  Allow members to change repository visibilities for this organization > **Off**
+        - [ ]  Allow members to delete or transfer repositories for this organization > **Off**
+        - [ ]  Allow repository administrators to delete issues for this organization > **Off**
+    - [ ]  Member team permissions > Allow members to create teams > **Off**
+
+#### Organization Rules
+
+- Repository > Rulesets > New ruleset > New branch ruleset: [[2]](#2-enterprise-features)
+    - [ ]  **Name**: EnforceSignedCommits
+        - **Targets > Target repositories**: All branches
+        - **Rules > Branch rules**:
+            - Require signed commits > **On**
+    - [ ]  **Name**: BlockForcePushes
+        - **Targets > Target repositories**: All branches
+        - **Rules > Branch rules**:
+            - Block force pushes > **On**
+
+#### Project and Actions Settings
+
+- [ ]  Planning > Projects > Allow members to change project visibilities for this organization > **Off**
+- Actions > General >
+    - Policies > **All repositories**
+        - [ ]  **Allow organization actions and reusable workflows** or **Allow organization, and select non-organization, actions and reusable workflows**
+    - [ ]  Approval for running fork pull request workflows from contributors > **Require approval for all external contributors**
+    - [ ]  Fork pull request workflows in private repositories > Run workflows from fork pull requests > **On**
+    - [ ]  Workflow permissions > **Read repository contents and packages permissions**
+        - [ ]  Allow GitHub Actions to create and approve pull requests > **Off**
+
+#### Security and Access
+
+- [ ]  Webhooks > Review and remove any unnecessary
+    - [ ]  For each webhook, ensure SSL verification is enabled
+- [ ]  Packages > Package creation > Public > **Disabled**
+- Authentication security >
+    - [ ]  Require two-factor authentication for everyone in the organization. > **On**
+        - [ ]  Only allow secure two-factor methods > **On**
+- [ ]  Deploy keys > **Disabled**
+
+#### Code Security Configuration
+
+- Code security > Configurations > New configuration:
+    - Dependency graph and Dependabot >
+        - [ ]  Dependency graph > **Enabled**
+        - [ ]  Dependabot alerts > **Enabled**
+    - [ ]  Code scanning > Default setup > **Enabled**
+    - [ ]  Secret scanning >
+        - [ ]  Alerts > **Enabled**
+        - [ ]  Validity checks > **Disabled**
+        - [ ]  Non-provider patterns > **Enabled**
+        - [ ]  Push protection > **Enabled**
+    - [ ]  Policy >
+        - [ ]  Use as default for newly created repositories > **All repositories**
+        - [ ]  Enforce configurations > **Enforce**
+    - [ ]  **Save configuration** and **Apply to > All repositories**
+
+#### Access Management
+
+- [ ]  Secrets and variables > Review secrets and variables and remove any unnecessary
+- [ ]  GitHub Apps > Installed GitHub Apps > Review configurations and uninstall any unnecessary
+    - [ ]  Review permissions are appropriate and that repository access is scoped only to relevant repositories
+- [ ]  OAuth app policy > Review policies and edit/deny any unnecessary
+- Personal access tokens >
+    - [ ]  **Restrict access via fine-grained personal access tokens**
+    - [ ]  **Require administrator approval**
+    - [ ]  **Restrict access via personal access tokens (classic)**
+    - [ ]  **Enroll** [[3]](#3-audit-logs)
+
+---
+
+## Notes
+
+### [1] Deploy Keys Warning
+
+Do not use deploy keys, they are possession-based access tokens that are a significant security risk. Use [GitHub Apps](https://docs.github.com/en/apps/overview) instead.
+
+### [2] Enterprise Features
+
+This is only available if you have a GitHub Enterprise plan. If you do not, you can set these same rules at the repo level instead.
+
+### [3] Audit Logs
+
+It is recommended to regularly review audit logs for your organization at Logs > Audit log.
+
+---
+
+**Related**: For repository hardening guidance, see [DevSecOps - Repository Hardening](/devsecops/repository-hardening).
+
+---
+
+---
+
+### PAGE: /opsec/control-domains/people
+**Title:** Personnel Security Controls
+**Referenced by controls:** ws-6.1.1, ws-6.1.3, ws-7.1.2
+
+# People & Personnel Controls
+
+
+
+
+People are both the greatest asset and potentially the greatest vulnerability in any security program. This section
+outlines controls to mitigate human-related security risks while fostering a security-aware culture.
+
+## Social-Engineering Defense
+
+Protecting against attacks that manipulate people to divulge confidential information or perform actions that compromise
+security.
+
+### Key Components
+
+1. **Awareness Training**: Educating team members about social engineering tactics
+2. **Attack Simulation**: Conducting controlled social engineering exercises
+3. **Verification Procedures**: Establishing processes to verify requestor identity
+4. **Reporting Mechanisms**: Creating clear channels for reporting suspicious activities
+5. **Response Protocols**: Developing procedures for handling potential social engineering incidents
+
+### Implementation Steps
+
+1. Develop targeted training on common social engineering tactics
+2. Implement regular phishing simulations and other controlled tests
+3. Establish protocols for verifying requests for sensitive information or actions
+4. Create and communicate clear procedures for reporting suspicious activities
+5. Regularly update training and awareness materials based on current threats
+
+### Web3-Specific Considerations
+
+1. **Community Channels**: Address social engineering in Discord, Telegram, and other platforms
+2. **Crypto-Specific Scams**: Educate about common scams like fake airdrops and giveaways
+3. **Impersonation**: Train team members to verify identity through secure channels
+4. **Public Information**: Consider the risks of publicly available information about team members
+5. **Multiple Communication Channels**: Establish out-of-band verification for critical actions
+
+## Insider-Threat Mitigation
+
+Addressing risks posed by team members who may intentionally or unintentionally compromise security.
+
+### Key Components
+
+1. **Access Controls**: Implementing least privilege and separation of duties
+2. **Monitoring**: Establishing appropriate monitoring of user activities
+3. **Onboarding/Offboarding**: Securing processes for adding and removing team members
+4. **Behavior Analytics**: Identifying unusual activities that may indicate threats
+5. **Response Procedures**: Developing protocols for addressing potential insider threats
+
+### Implementation Steps
+
+1. Implement robust access controls based on the principle of least privilege
+2. Establish monitoring for critical systems and sensitive data access
+3. Develop and enforce secure onboarding and offboarding procedures
+4. Create guidelines for identifying and reporting concerning behaviors
+5. Establish response procedures that balance security with privacy and legal considerations
+
+### Web3-Specific Considerations
+
+1. **Key Management**: Implement controls for those with access to private keys
+2. **Multi-Signature Requirements**: Use multi-signature arrangements for critical operations
+3. **Distributed Teams**: Address insider threat risks in remote and distributed teams
+4. **Pseudonymous Contributors**: Develop trust models for pseudonymous team members
+5. **Financial Incentives**: Consider unique incentives related to cryptocurrency holdings
+
+## Security Training & Culture
+
+Building a culture where security is valued and integrated into daily operations.
+
+### Key Components
+
+1. **Security Awareness Program**: Comprehensive training on security principles
+2. **Role-Based Training**: Specialized training based on job responsibilities
+3. **Security Champions**: Designated representatives who promote security within teams
+4. **Continuous Learning**: Ongoing education about emerging threats
+5. **Positive Reinforcement**: Recognizing and rewarding security-conscious behavior
+
+### Implementation Steps
+
+1. Develop a comprehensive security awareness program
+2. Implement role-specific security training for different functions
+3. Establish a security champions program to promote security within teams
+4. Create a continuous learning program with regular updates on new threats
+5. Develop recognition programs for security-conscious behaviors and reporting
+6. Integrate security into performance evaluations and team objectives
+
+### Web3-Specific Considerations
+
+1. **Crypto-Specific Training**: Educate on unique aspects of blockchain security
+2. **Open-Source Mindset**: Balance security with transparency in an open-source culture
+3. **Decentralized Teams**: Deliver effective training across distributed organizations
+4. **Rapidly Evolving Threats**: Keep training current with fast-changing Web3 threats
+5. **Community Education**: Extend security awareness to community members and users
+
+## Personnel Security Measures
+
+Ensuring appropriate security controls throughout the employment lifecycle.
+
+### Key Components
+
+1. **Pre-Employment Screening**: Appropriate background checks and verification
+2. **Security Agreements**: Confidentiality and acceptable use policies
+3. **Clear Expectations**: Defined security responsibilities for all roles
+4. **Performance Management**: Integration of security into performance evaluation
+5. **Termination Procedures**: Secure processes for departing team members
+
+### Implementation Steps
+
+1. Implement appropriate pre-employment screening procedures
+2. Develop and require security agreements for all team members
+3. Clearly document security responsibilities in job descriptions
+4. Include security considerations in performance evaluations
+5. Establish and enforce secure termination procedures
+
+### Web3-Specific Considerations
+
+1. **Pseudonymous Contributors**: Develop alternative verification approaches
+2. **Global Teams**: Navigate screening challenges across different jurisdictions
+3. **Community Contributors**: Address security for non-employee contributors
+4. **DAO Participants**: Establish security expectations in decentralized organizations
+5. **Key Recovery**: Implement procedures for key recovery when team members depart
+
+Effective people and personnel controls recognize that security is fundamentally a human issue. By addressing social
+engineering, insider threats, and security awareness, organizations can transform their people from potential
+vulnerabilities into a critical line of defense.
+
+---
+
+---
+
+### PAGE: /awareness/staying-informed-and-continuous-learning
+**Title:** Staying Informed And Continuous Learning | SEAL
+**Referenced by controls:** ws-6.1.3
+
+# 4. Staying Informed & Continuous Learning
+
+
+
+
+> 🔑 **Key Takeaway**: Security is not a one-time achievement but an ongoing journey of learning and adaptation. By
+> establishing regular training routines, staying current with emerging threats, and fostering a culture of continuous
+> improvement, you ensure your security awareness remains effective against evolving challenges.
+
+## 4.1. Comprehensive Security Training Framework
+
+### 4.1.1. Training Approaches
+
+- **Bite-Sized Learning:**
+
+Security training doesn't need to be lengthy or overwhelming. Short, focused sessions of relevant information can be
+more effective than infrequent, lengthy presentations.
+Example: Weekly 5-minute security tips delivered via team chat or email.
+
+- **Role-Based Training:**
+
+Tailor security training to specific roles and access levels within your organization.
+Example: Developers might need more in-depth training on secure coding practices, while community managers might focus
+more on social engineering awareness.
+
+- **Recurring Schedule:**
+
+Make security training a regular, ongoing activity rather than a one-time event.
+Example: Monthly security topics with quarterly refreshers on critical subjects.
+
+- **Practical Application:**
+
+Include hands-on exercises that allow people to apply what they've learned.
+Example: Conduct simulated phishing tests followed by immediate feedback and learning opportunities.
+
+- **Interactive Training Methods:**
+
+Use interactive training methods, such as SEAL Wargames or workshops to engage team members and enhance learning.
+
+- **Real-World Scenarios:**
+
+Incorporate real-world scenarios and case studies to illustrate the impact of security breaches and the importance of
+preventive measures.
+
+- **Assessments and Quizzes:**
+
+Use assessments and quizzes to evaluate the effectiveness of training and identify areas where additional training may
+be needed.
+
+### 4.1.2. Training Delivery
+
+- **Regular Awareness Sessions:**
+
+Schedule quarterly webinars or short training refreshers focusing on the latest trends and emerging threats.
+
+- **Interactive Simulations:**
+
+Participate in phishing simulations or scenario-based exercises that allow you to practice identifying and responding to
+threats in a risk-free environment.
+
+- **Security Awareness Campaigns:**
+
+Implement periodic campaigns that focus on specific security themes to reinforce key messages.
+Example: A "Phishing Awareness Month" with targeted activities and resources.
+
+### 4.1.3. Measuring Training Effectiveness
+
+- **Baseline Assessments:**
+
+Conduct assessments before and after training to measure improvement.
+
+- **Behavioral Metrics:**
+
+Track security-related behaviors such as reporting rates for suspicious emails or incidents.
+
+- **Feedback Collection:**
+
+Gather participant feedback to continuously improve training content and delivery methods.
+
+## 4.2. Essential Training Topics
+
+- **Phishing and Social Engineering:**
+
+Educate team members on recognizing and responding to phishing attacks and social engineering tactics, with special
+focus on web3-specific threats.
+
+- **Password Management:**
+
+Provide best practices for creating and managing strong passwords and using password managers.
+
+- **Data Protection:**
+
+Teach methods for protecting sensitive data, including encryption, access controls, and secure data handling practices.
+
+- **Incident Reporting:**
+
+Instruct team members on how to report security incidents and suspicious activities promptly.
+
+- **Secure Coding Practices:**
+
+For developers, provide training on secure coding practices and common vulnerabilities in web3 environments.
+
+- **Device and Account Security:**
+
+Cover best practices for securing devices and accounts, including updates, encryption, and access controls.
+
+- **Emerging Threats:**
+
+Keep team members informed about new and evolving security threats relevant to your organization.
+
+## 4.3. Trusted Information Sources
+
+### 4.3.1. Security Newsletters
+
+- **Industry News:**
+
+Subscribe to newsletters from sources such as FIRST.org for broader cybersecurity trends.
+Example: The SANS NewsBites provides twice-weekly summaries of the most important security news.
+
+- **Vendor Updates:**
+
+Follow security updates from the software and hardware vendors in your project stack.
+Example: Subscribe to security bulletins from cloud providers, operating system vendors, and key software dependencies.
+
+### 4.3.2. Security Communities
+
+- **Online Forums and Groups:**
+
+Join online communities dedicated to security topics.
+Example: The SEAL Discord provides a space to discuss security challenges specific to web3 projects.
+
+- **Local and Virtual Meetups:**
+
+Attend security-focused events to network and learn.
+Example: Conferences like DeFi Security Summit offer insights into emerging threats and defenses.
+
+### 4.3.3. Security Blogs and Podcasts
+
+- **Technical Blogs:**
+
+Follow security researchers and organizations that regularly publish detailed analyses.
+Example: Trail of Bits blog provides in-depth technical security content.
+
+- **Security Podcasts:**
+
+Listen to podcasts that cover current security topics.
+Example: The Daily Stormcast from FIRST.org offers brief daily updates, while Darknet Diaries provides longer-form
+stories about notable security incidents.
+
+## 4.4. Implementing a Learning Culture
+
+- **Share Knowledge:**
+
+Create channels for team members to share security articles, news, and insights.
+Example: A dedicated Slack channel for security-related content.
+
+- **Recognize Vigilance:**
+
+Acknowledge and reward security-conscious behavior.
+Example: Highlight team members who identify and report potential security issues.
+
+- **Learn from Incidents:**
+
+Use security incidents (both internal and external) as learning opportunities.
+Example: After major industry breaches, conduct brief sessions to discuss what happened and how similar issues could be
+prevented in your organization.
+
+---
+
+---
+
+### PAGE: /opsec/appendices/case-studies
+**Title:** OpSec Case Studies
+**Referenced by controls:** ws-6.1.3, ws-7.1.1
+
+# Case Studies & Exercises
+
+
+
+
+This section provides real-world case studies and tabletop exercises that organizations can use to learn from past
+incidents and test their security readiness. These examples illustrate common security challenges and effective response
+strategies.
+
+## Web3 Security Incidents
+
+### Case Study 1: Private Key Compromise
+
+#### Incident Overview
+
+A mid-sized DeFi protocol experienced a security breach when an attacker gained access to a private key used for
+deploying smart contracts. The attacker used the key to deploy a malicious contract update that drained approximately $3
+million from the protocol.
+
+#### Root Causes
+
+1. The private key was stored in a development environment with inadequate access controls
+2. The same key was used for both testing and production deployments
+3. There was no multi-signature requirement for contract deployments
+4. Monitoring systems failed to detect the unauthorized deployment
+
+#### Response Actions
+
+1. The team immediately alerted users via social media and official channels
+2. All remaining funds were moved to secure wallets
+3. A forensic investigation was initiated to determine the attack vector
+4. Law enforcement and blockchain analytics firms were engaged
+5. The team implemented a compensation plan for affected users
+
+#### Lessons Learned
+
+1. Implement multi-signature requirements for all critical operations
+2. Establish separate keys for different environments with appropriate controls
+3. Improve deployment security with additional verification steps
+4. Enhance monitoring to detect unauthorized deployments
+5. Develop and test incident response procedures specific to key compromise
+
+### Case Study 2: Social Engineering Attack
+
+#### Incident Overview
+
+A community manager for a popular NFT project had their Discord account compromised after clicking a link in a direct
+message that appeared to come from a team member. The attacker used the compromised account to post a fake minting link,
+ resulting in approximately 50 community members connecting their wallets and losing assets.
+
+#### Root Causes
+
+1. Lack of verification procedures for team communications
+2. Insufficient security awareness training for team members
+3. Absence of multi-factor authentication on critical accounts
+4. Inadequate controls for posting official announcements
+
+#### Response Actions
+
+1. The team removed the compromised account's permissions
+2. An official announcement was made warning about the scam
+3. The fake minting site was reported for takedown
+4. Affected community members were identified for potential compensation
+5. Communication procedures were revised to prevent similar incidents
+
+#### Lessons Learned
+
+1. Implement strong authentication for all team accounts
+2. Establish verification protocols for team communications
+3. Create a secure process for publishing official announcements
+4. Conduct regular security awareness training for team members
+5. Develop an incident response plan specific to community channel compromises
+
+## Tabletop Exercises
+
+### Exercise 1: Wallet Security Incident
+
+#### Scenario
+
+Your organization's multi-signature wallet has shown unusual transaction activity. A transaction that was not authorized
+by the team has been initiated, requiring one more signature to execute. The transaction would send a significant
+amount of funds to an unknown address.
+
+#### Exercise Questions
+
+1. What immediate actions would you take?
+2. How would you investigate the source of the unauthorized transaction?
+3. What stakeholders need to be notified, and what information would you provide?
+4. What steps would you take to secure your remaining assets?
+5. How would you communicate with your community or users?
+
+#### Key Discussion Points
+
+- Multi-signature wallet security procedures
+- Transaction verification processes
+- Incident response roles and responsibilities
+- Communication strategies during security incidents
+- Forensic investigation approaches
+
+### Exercise 2: Smart Contract Vulnerability
+
+#### Scenario
+
+A security researcher has privately disclosed a critical vulnerability in one of your deployed smart contracts. The
+vulnerability could potentially allow an attacker to drain funds, but it requires specific conditions that have not yet
+occurred. You have approximately 48 hours before these conditions align.
+
+#### Exercise Questions
+
+1. How would you validate the reported vulnerability?
+2. What immediate mitigation steps could you take?
+3. How would you prioritize and approach developing a fix?
+4. What stakeholders need to be involved in the decision-making process?
+5. How and when would you communicate with users and the broader community?
+
+#### Key Discussion Points
+
+- Vulnerability verification processes
+- Short-term mitigation strategies
+- Smart contract upgrade procedures
+- Decision-making during time-sensitive incidents
+- Responsible disclosure and communication
+
+### Exercise 3: Team Member Device Compromise
+
+#### Scenario
+
+A developer on your team reports that their laptop has been stolen while traveling. The laptop was used for development
+work and had access to various internal systems. The developer had logged into several services recently and is unsure
+if all sessions were properly closed.
+
+#### Exercise Questions
+
+1. What immediate actions would you take to contain potential damage?
+2. What systems and access credentials might be at risk?
+3. How would you determine if any unauthorized access has occurred?
+4. What steps would you take to restore secure operations?
+5. How would you improve security to prevent similar incidents?
+
+#### Key Discussion Points
+
+- Device security policies and procedures
+- Access revocation processes
+- Security monitoring and detection capabilities
+- Recovery procedures for compromised credentials
+- Travel security policies
+
+## Security Exercises for Teams
+
+### Red Team Exercise: Phishing Simulation
+
+#### Exercise Overview
+
+This exercise simulates a phishing attack targeting team members to test awareness and response.
+
+#### Setup Requirements
+
+1. Prepare simulated phishing emails targeting different team roles
+2. Create a safe landing page that records interactions
+3. Establish monitoring to track responses
+4. Prepare educational materials for post-exercise discussion
+
+#### Exercise Process
+
+1. Send simulated phishing emails to selected team members
+2. Monitor interactions with the phishing content
+3. Document actions taken by recipients
+4. Track if and how the incident is reported
+5. Conduct a debrief session to discuss results
+
+#### Evaluation Criteria
+
+- Percentage of team members who detected the phishing attempt
+- Time taken to report suspicious emails
+- Effectiveness of reporting procedures
+- Quality of response from security team
+- Lessons learned and areas for improvement
+
+### Security Control Assessment: Key Management
+
+#### Exercise Overview
+
+This exercise evaluates the effectiveness of cryptocurrency key management procedures.
+
+#### Setup Requirements
+
+1. Create a test environment with non-production keys
+2. Prepare scenarios that test different aspects of key management
+3. Establish evaluation criteria for each scenario
+4. Ensure safety measures to prevent actual asset risk
+
+#### Exercise Process
+
+1. Simulate routine key management operations
+2. Introduce scenarios requiring emergency access to keys
+3. Test key recovery procedures
+4. Evaluate separation of duties enforcement
+5. Assess documentation and procedure clarity
+
+#### Evaluation Criteria
+
+- Adherence to established key management procedures
+- Effectiveness of security controls
+- Time required to safely complete key operations
+- Quality of documentation and procedures
+- Identification of gaps and improvement opportunities
+
+These case studies and exercises provide practical examples and scenarios that organizations can use to learn from past
+incidents and test their security readiness. By regularly conducting such exercises, teams can identify weaknesses in
+their security posture and improve their ability to respond effectively to incidents.
+
+---
+
+---
+
+### PAGE: /opsec/appendices/glossary
+**Title:** Security Glossary
+**Referenced by controls:** ws-7.1.3
+
+# Glossary of Terms
+
+
+
+
+This glossary provides definitions for key terms used throughout the Operational Security framework. It includes both
+general security terminology and Web3-specific concepts to help ensure a common understanding of security concepts.
+
+## General Security Terms
+
+### A
+
+**Access Control**: Systems and policies that restrict access to resources based on user identity and authorization
+level.
+
+**Authentication**: The process of verifying the identity of a user, system, or entity.
+
+**Authorization**: The process of determining what actions an authenticated entity is permitted to perform.
+
+**Availability**: The property of being accessible and usable upon demand by an authorized entity.
+
+### B
+
+**Backup**: A copy of data created and stored separately from the original, to enable recovery in case of data loss.
+
+**Breach**: An incident that results in the unauthorized access, disclosure, or acquisition of protected data.
+
+### C
+
+**Confidentiality**: The property that information is not made available or disclosed to unauthorized individuals,
+entities, or processes.
+
+**Configuration Management**: The process of establishing and maintaining consistency of a system's performance and
+functional attributes with its requirements and design.
+
+**Containment**: Actions taken to limit the scope and impact of a security incident.
+
+**Countermeasure**: An action, device, procedure, or technique that mitigates a security threat or vulnerability.
+
+### D
+
+**Defense in Depth**: A security strategy that employs multiple layers of controls to protect resources.
+
+**Disaster Recovery**: A set of policies, tools, and procedures to enable the recovery of vital technology
+infrastructure and systems following a disaster.
+
+### E
+
+**Encryption**: The process of converting information into a code to prevent unauthorized access.
+
+**Endpoint Security**: The practice of securing entry points of end-user devices such as desktops, laptops, and mobile
+devices from being exploited by malicious actors.
+
+### I
+
+**Incident Response**: The process of addressing and managing the aftermath of a security breach or attack.
+
+**Integrity**: The property that data has not been altered in an unauthorized manner since it was created, transmitted,
+or stored.
+
+**Intrusion Detection System (IDS)**: A system that monitors network traffic for suspicious activity and issues alerts
+when such activity is discovered.
+
+### L
+
+**Least Privilege**: The principle of providing users with the minimum levels of access necessary to perform their job
+functions.
+
+**Logging**: The recording of events, activities, and changes within a system or network.
+
+### M
+
+**Malware**: Software designed to disrupt, damage, or gain unauthorized access to a computer system.
+
+**Multi-Factor Authentication (MFA)**: An authentication method that requires a user to provide two or more verification
+ factors to gain access.
+
+### P
+
+**Penetration Testing**: An authorized simulated attack on a computer system to evaluate its security.
+
+**Phishing**: A technique for attempting to acquire sensitive data, such as passwords or credit card details, by
+masquerading as a trustworthy entity.
+
+**Principle of Least Privilege**: The concept of granting users only the minimum access rights necessary to perform
+their job functions.
+
+### R
+
+**Risk Assessment**: The process of identifying, analyzing, and evaluating risk.
+
+**Risk Management**: The coordinated activities to direct and control an organization with regard to risk.
+
+### S
+
+**Security Controls**: Safeguards or countermeasures to avoid, detect, counteract, or minimize security risks.
+
+**Security Incident**: An event that potentially compromises the confidentiality, integrity, or availability of
+information or systems.
+
+**Separation of Duties**: A principle that divides critical functions among different staff members to prevent fraud and
+errors.
+
+### T
+
+**Threat**: A potential cause of an unwanted incident, which may result in harm to a system or organization.
+
+**Two-Factor Authentication (2FA)**: A method of confirming a user's claimed identity by utilizing a combination of two
+different factors.
+
+### V
+
+**Vulnerability**: A weakness that can be exploited by a threat actor to perform unauthorized actions.
+
+**Vulnerability Assessment**: The process of identifying, quantifying, and prioritizing vulnerabilities in systems,
+applications, and network infrastructure.
+
+## Web3-Specific Terms
+
+### A
+
+**Air-Gapped**: A security measure where a computer or network is physically isolated from unsecured networks, such as
+the public internet or an insecure local area network.
+
+### B
+
+**Blockchain**: A distributed ledger technology that maintains a continuously growing list of records, called blocks,
+which are linked and secured using cryptography.
+
+### C
+
+**Cold Storage**: The practice of keeping a reserve of cryptocurrency offline, typically in hardware wallets or paper
+wallets.
+
+**Consensus Mechanism**: The process in a blockchain network that achieves agreement among distributed processes or
+systems on a single data value.
+
+**Custodial Wallet**: A cryptocurrency wallet where the private keys are held by a third-party service.
+
+### D
+
+**Decentralized Application (DApp)**: An application that runs on a decentralized network, avoiding a single point of
+control or failure.
+
+**Decentralized Autonomous Organization (DAO)**: An organization represented by rules encoded as a computer program that
+is transparent, controlled by the organization members, and not influenced by a central government.
+
+### E
+
+**Externally Owned Account (EOA)**: An Ethereum account controlled by a private key, typically belonging to a person.
+
+### G
+
+**Gas**: A unit that measures the amount of computational effort required to execute operations on the Ethereum network.
+
+### H
+
+**Hardware Wallet**: A special type of cryptocurrency wallet that stores the user's private keys in a secure hardware
+device.
+
+**Hot Wallet**: A cryptocurrency wallet that is connected to the internet, allowing for quick transactions but with
+increased security risks.
+
+### M
+
+**Mempool**: A collection of all transaction data that have been verified by nodes but have not yet been recorded onto
+the blockchain.
+
+**Multisignature (Multisig)**: A digital signature scheme that allows a group of users to sign a single document, with
+multiple parties required to authorize a transaction.
+
+### N
+
+**Node**: A computer that connects to a blockchain network and maintains a copy of the blockchain.
+
+**Non-Custodial Wallet**: A cryptocurrency wallet where users have full control over their private keys and
+cryptocurrency.
+
+### P
+
+**Private Key**: A secret number that allows cryptocurrency to be spent. It is paired with a public key in asymmetric
+cryptography.
+
+**Public Key**: A cryptographic key that can be obtained and used by anyone to encrypt messages intended for a
+particular recipient, such that the encrypted messages can only be decrypted by the recipient's paired private key.
+
+### S
+
+**Smart Contract**: Self-executing contracts with the terms of the agreement directly written into code, which
+automatically enforce and execute the terms when predetermined conditions are met.
+
+**Seed Phrase**: A series of words generated by cryptocurrency wallets that give users access to the cryptocurrency
+associated with that wallet.
+
+### T
+
+**Token**: A digital asset that is created, issued, and managed on an existing blockchain.
+
+**Transaction**: The record of a change in ownership of a cryptocurrency or the execution of a smart contract.
+
+### W
+
+**Wallet**: Software that stores private and public keys and interacts with various blockchain to enable users to send
+and receive digital currency and monitor their balance.
+
+**Web3**: The concept of a new iteration of the web which incorporates concepts such as decentralization, blockchain
+technologies, and token-based economics.
+
+This glossary provides a common language for discussing operational security concepts. Understanding these terms is
+essential for effective communication about security risks, controls, and practices in both traditional and Web3
+environments.
+
+---
+
+---
+
diff --git a/scripts/data/eval-results/sfc-devops-infrastructure.json b/scripts/data/eval-results/sfc-devops-infrastructure.json
new file mode 100644
index 00000000..f546b445
--- /dev/null
+++ b/scripts/data/eval-results/sfc-devops-infrastructure.json
@@ -0,0 +1,325 @@
+[
+  {
+    "controlId": "di-1.1.1",
+    "controlTitle": "DevOps Security Owner",
+    "refs": [],
+    "gaps": [
+      "Accountability scope covers policy maintenance, security reviews, access control oversight, pipeline governance, and incident escalation"
+    ]
+  },
+  {
+    "controlId": "di-1.1.2",
+    "controlTitle": "DevOps Security Policy",
+    "refs": [],
+    "gaps": [
+      "Policy covers environment standards, access controls, deployment procedures, code management, and supply chain security",
+      "Accessible to all developers and infrastructure operators",
+      "Reviewed at least annually and after significant changes"
+    ]
+  },
+  {
+    "controlId": "di-1.1.3",
+    "controlTitle": "Development Environment Isolation",
+    "refs": [
+      {
+        "page": "/devsecops/integrated-development-environments",
+        "header": null,
+        "coverage": "partial",
+        "baselinesMet": [
+          "See QA notes: Evaluator missed coverage. IDE page states 'Ensure that potential development environments are isolated from production environments' (addresses baseline about production credential isolation). CI/CD "
+        ],
+        "baselinesMissed": []
+      }
+    ],
+    "gaps": [
+      "Development activities performed in containerized or virtualized environments",
+      "Each code repository has its own isolated environment to prevent cross-contamination",
+      "Production credentials not accessible from development environments",
+      "Separate accounts or profiles for development vs. privileged operations",
+      "Code execution sandboxed to prevent host system compromise"
+    ]
+  },
+  {
+    "controlId": "di-1.1.4",
+    "controlTitle": "Development Tools Approval",
+    "refs": [
+      {
+        "page": "/devsecops/integrated-development-environments",
+        "header": null,
+        "coverage": "partial",
+        "baselinesMet": [
+          "Extensions and plugins obtained only from official repositories (mentions 'trusted sources')"
+        ],
+        "baselinesMissed": [
+          "Evaluation criteria cover IDEs, extensions, plugins, AI-powered tools, and third-party services",
+          "AI tools assessed for data privacy risks",
+          "Approved tool list maintained; unapproved tools restricted",
+          "Regular reviews of installed tools"
+        ]
+      }
+    ],
+    "gaps": [
+      "Evaluation criteria cover IDEs, extensions, plugins, AI-powered tools, and third-party services",
+      "AI tools assessed for data privacy risks",
+      "Approved tool list maintained; unapproved tools restricted",
+      "Regular reviews of installed tools to identify unused or unrecognized items"
+    ]
+  },
+  {
+    "controlId": "di-2.1.1",
+    "controlTitle": "Repository Security",
+    "refs": [
+      {
+        "page": "/secure-software-development/secure-code-repositories-version-control",
+        "header": "Best Practices for Secure Code Repositories",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Role-based access control with least-privilege permissions",
+          "Branch protection rules enforced on main/production branches",
+          "Signed commits required for all code changes",
+          "Multi-party code review required for merges",
+          "MFA required for all repository members"
+        ],
+        "baselinesMissed": [
+          "Repository access reviewed periodically (audit logs mentioned but not periodic access reviews)"
+        ]
+      }
+    ],
+    "gaps": [
+      "Repository access reviewed periodically"
+    ]
+  },
+  {
+    "controlId": "di-2.1.2",
+    "controlTitle": "Secret Scanning",
+    "refs": [
+      {
+        "page": "/devsecops/continuous-integration-continuous-deployment",
+        "header": null,
+        "coverage": "partial",
+        "baselinesMet": [
+          "CI/CD pipeline checks for leaked credentials (partial: automated scanning)",
+          "Scanning integrated into CI/CD pipeline"
+        ],
+        "baselinesMissed": [
+          "Pre-commit hooks deployed to prevent secrets from being committed",
+          "Remediation procedures for discovered secrets (immediate rotation, revocation)"
+        ]
+      }
+    ],
+    "gaps": [
+      "Pre-commit hooks deployed to prevent secrets from being committed in the first place",
+      "Remediation procedures for discovered secrets (immediate rotation, revocation)"
+    ]
+  },
+  {
+    "controlId": "di-2.1.3",
+    "controlTitle": "External Contributor Review",
+    "refs": [],
+    "gaps": [
+      "Additional approvers required for all external code contributions",
+      "Code contributions tracked; unexpected changes flagged",
+      "External collaborators restricted to minimum necessary repository permissions",
+      "CI/CD pipelines do not automatically execute for external contributor PRs without approval"
+    ]
+  },
+  {
+    "controlId": "di-2.1.4",
+    "controlTitle": "Dependency and Supply Chain Security",
+    "refs": [
+      {
+        "page": "/supply-chain/dependency-awareness",
+        "header": "Best Practices for Dependency Awareness",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Packages obtained from official repositories and trusted sources only",
+          "Dependencies scanned for known vulnerabilities before deployment",
+          "Regular dependency audits for outdated or vulnerable components"
+        ],
+        "baselinesMissed": [
+          "Package names verified against typosquatting patterns before installation",
+          "Dependency version pinning enforced to prevent automatic updates",
+          "Changelog reviewed for dependency updates to verify expected functionality"
+        ]
+      }
+    ],
+    "gaps": [
+      "Package names verified against typosquatting patterns before installation",
+      "Dependency version pinning enforced to prevent automatic updates to compromised versions",
+      "Changelog reviewed for dependency updates to verify expected functionality"
+    ]
+  },
+  {
+    "controlId": "di-3.1.1",
+    "controlTitle": "Pipeline Security Controls",
+    "refs": [
+      {
+        "page": "/devsecops/continuous-integration-continuous-deployment",
+        "header": null,
+        "coverage": "partial",
+        "baselinesMet": [
+          "Builds are deterministic with strict dependency sets",
+          "Strict access controls for CI/CD pipelines (partial: limits who can modify)"
+        ],
+        "baselinesMissed": [
+          "Pipeline configuration changes require multi-party approval",
+          "Separate service accounts with minimal permissions used for pipeline execution",
+          "Manual deployment by humans restricted; deployments automated through controlled pipelines",
+          "Pipeline and build configurations version-controlled and reviewed"
+        ]
+      }
+    ],
+    "gaps": [
+      "Pipeline configuration changes require multi-party approval",
+      "Separate service accounts with minimal permissions used for pipeline execution",
+      "Manual deployment by humans restricted; deployments automated through controlled pipelines",
+      "Pipeline and build configurations version-controlled and reviewed"
+    ]
+  },
+  {
+    "controlId": "di-3.1.2",
+    "controlTitle": "Secrets Management",
+    "refs": [],
+    "gaps": [
+      "Dedicated secrets management system used (not environment variables in plain text)",
+      "Secrets never stored in source code or unencrypted configuration files",
+      "Production secrets not directly accessible by humans",
+      "Pipeline secrets accessible only by service accounts",
+      "Secret rotation schedule defined; rotation triggered immediately after suspected compromise"
+    ]
+  },
+  {
+    "controlId": "di-3.1.3",
+    "controlTitle": "Security Testing Integration",
+    "refs": [
+      {
+        "page": "/devsecops/continuous-integration-continuous-deployment",
+        "header": null,
+        "coverage": "partial",
+        "baselinesMet": [
+          "Static analysis and dependency scanning integrated into CI/CD",
+          "PR testing must pass before merging (implies review)"
+        ],
+        "baselinesMissed": [
+          "Security scan results reviewed before deployment approval (not explicitly stated)",
+          "Testing and validation performed in staging environments before production deployment"
+        ]
+      },
+      {
+        "page": "/devsecops/security-testing",
+        "header": null,
+        "coverage": "partial",
+        "baselinesMet": [
+          "SAST tools integrated into CI/CD pipeline"
+        ],
+        "baselinesMissed": [
+          "Dependency vulnerability scanning automated in CI/CD (DAST mentioned, not dependency scanning)",
+          "Security scan results reviewed before deployment approval",
+          "Testing and validation performed in staging environments before production"
+        ]
+      }
+    ],
+    "gaps": [
+      "Security scan results reviewed before deployment approval",
+      "Testing and validation performed in staging environments before production deployment"
+    ]
+  },
+  {
+    "controlId": "di-4.1.1",
+    "controlTitle": "Infrastructure as Code",
+    "refs": [
+      {
+        "page": "/security-automation/infrastructure-as-code",
+        "header": null,
+        "coverage": "partial",
+        "baselinesMet": [
+          "All infrastructure defined and managed through code",
+          "IaC security scanning performed before deployment"
+        ],
+        "baselinesMissed": [
+          "Infrastructure changes deployed through automated pipelines, no manual steps required",
+          "Infrastructure changes require multi-party approval"
+        ]
+      }
+    ],
+    "gaps": [
+      "Infrastructure changes deployed through automated pipelines, no manual steps required",
+      "Infrastructure changes require multi-party approval"
+    ]
+  },
+  {
+    "controlId": "di-4.1.2",
+    "controlTitle": "Infrastructure Access Controls",
+    "refs": [
+      {
+        "page": "/secure-software-development/secure-code-repositories-version-control",
+        "header": "Best Practices for Secure Code Repositories",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Individual accounts with MFA required (for repositories)",
+          "Role-based access control (minimum necessary permissions)",
+          "All access activities logged and monitored (audit logs)"
+        ],
+        "baselinesMissed": [
+          "Privileged access is time-limited and requires multi-party approval (JIT access)",
+          "Break-glass accounts established for emergency access",
+          "Break-glass usage triggers immediate alerts and requires post-incident review"
+        ]
+      }
+    ],
+    "gaps": [
+      "Privileged access is time-limited and requires multi-party approval (JIT access)",
+      "Break-glass accounts established for emergency access with individual accountability",
+      "Break-glass usage triggers immediate alerts to entire team and requires post-incident review"
+    ]
+  },
+  {
+    "controlId": "di-4.1.3",
+    "controlTitle": "Backup and Disaster Recovery",
+    "refs": [
+      {
+        "page": "/secure-software-development/secure-code-repositories-version-control",
+        "header": "Secure Version Control Practices",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Regular backups of code repository",
+          "Backups stored independently (secure, offsite location)"
+        ],
+        "baselinesMissed": [
+          "Critical systems have automated backup procedures",
+          "Disaster recovery plan documented with RTO and RPO defined",
+          "Backup and recovery procedures tested regularly"
+        ]
+      }
+    ],
+    "gaps": [
+      "Critical systems have automated backup procedures (beyond just code repos)",
+      "Disaster recovery plan documented with recovery time and recovery point objectives defined",
+      "Backup and recovery procedures tested regularly"
+    ]
+  },
+  {
+    "controlId": "di-4.1.4",
+    "controlTitle": "Cloud Security Monitoring",
+    "refs": [
+      {
+        "page": "/infrastructure/cloud",
+        "header": "Cloud Infrastructure",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Cloud security configurations monitored (comprehensive logging, monitoring, threat detection)",
+          "Administrative actions trigger alerts (real-time incident response)",
+          "Comprehensive logging enabled (AWS CloudTrail, Azure Monitor, Google Cloud Logging)"
+        ],
+        "baselinesMissed": [
+          "Cloud provider security notifications subscribed to and promptly reviewed",
+          "Multi-cloud strategies considered to reduce single-provider dependency"
+        ]
+      }
+    ],
+    "gaps": [
+      "Cloud provider security notifications subscribed to and promptly reviewed",
+      "Multi-cloud strategies considered to reduce single-provider dependency"
+    ]
+  }
+]
\ No newline at end of file
diff --git a/scripts/data/eval-results/sfc-dns-registrar.json b/scripts/data/eval-results/sfc-dns-registrar.json
new file mode 100644
index 00000000..8087b3b5
--- /dev/null
+++ b/scripts/data/eval-results/sfc-dns-registrar.json
@@ -0,0 +1,281 @@
+[
+  {
+    "controlId": "dns-1.1.1",
+    "controlTitle": "Domain Security Owner",
+    "refs": [],
+    "gaps": [
+      "Accountability scope covers policy maintenance, security reviews, renewal management, access control oversight, and incident escalation"
+    ]
+  },
+  {
+    "controlId": "dns-1.1.2",
+    "controlTitle": "Domain Inventory and Documentation",
+    "refs": [],
+    "gaps": [
+      "Registry includes domain name, ownership, purpose, expiration date, registrar, DNS record configurations, security settings (DNSSEC, CAA), and registrar account configurations",
+      "Accessible to relevant team members"
+    ]
+  },
+  {
+    "controlId": "dns-2.1.1",
+    "controlTitle": "Domain Classification and Compliance",
+    "refs": [],
+    "gaps": [
+      "Classification considers criticality, financial exposure, and operational impact",
+      "Domains where users may transact funds or that are external-facing classified at the highest tier",
+      "Each classification maps to specific security requirements (DNSSEC, locks, monitoring frequency, access controls)",
+      "Compliance verified at least annually through configuration review against documented standards"
+    ]
+  },
+  {
+    "controlId": "dns-2.1.2",
+    "controlTitle": "Enterprise Registrar Security Requirements",
+    "refs": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "header": "Choosing a Secure Registrar",
+        "coverage": "full",
+        "baselinesMet": [
+          "Registrar supports registry locks (server-level EPP locks)",
+          "Registrar supports hardware security key MFA (FIDO2/WebAuthn)",
+          "Registrar has no history of social engineering vulnerabilities",
+          "Due diligence includes checking ICANN compliance notices"
+        ],
+        "baselinesMissed": []
+      }
+    ],
+    "gaps": []
+  },
+  {
+    "controlId": "dns-3.1.1",
+    "controlTitle": "Registrar Access Control",
+    "refs": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "header": "Access Control Best Practices",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Hardware security key MFA (FIDO2/WebAuthn) required for all accounts",
+          "Access reviews conducted at least annually (mentions quarterly)"
+        ],
+        "baselinesMissed": [
+          "Documented who is authorized, how access is granted/revoked, and role-based permissions (mentions but doesn't teach HOW to document)",
+          "Access revoked promptly when no longer needed (not actionably addressed)"
+        ]
+      }
+    ],
+    "gaps": [
+      "Documented procedures for who is authorized, how access is granted/revoked, and role-based permissions implementation",
+      "Prompt access revocation procedures when no longer needed"
+    ]
+  },
+  {
+    "controlId": "dns-3.1.2",
+    "controlTitle": "Dedicated Domain Security Contact Email",
+    "refs": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "header": "Dedicated Security Contact Email",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Hosted on a different domain than any domain it's responsible for",
+          "Not a personal email address",
+          "Used exclusively for domain security purposes"
+        ],
+        "baselinesMissed": [
+          "Alias that notifies multiple people (not explicitly stated)"
+        ]
+      }
+    ],
+    "gaps": [
+      "Alias that notifies multiple people"
+    ]
+  },
+  {
+    "controlId": "dns-3.1.3",
+    "controlTitle": "Change Management for Domain Operations",
+    "refs": [],
+    "gaps": [
+      "Covers transfers, deletions, nameserver changes, and DNS record modifications",
+      "Relevant team members notified before critical changes",
+      "All changes logged",
+      "Critical changes verified through out-of-band confirmation with the registrar"
+    ]
+  },
+  {
+    "controlId": "dns-4.1.1",
+    "controlTitle": "DNS Security Standards",
+    "refs": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "header": "DNSSEC Implementation",
+        "coverage": "partial",
+        "baselinesMet": [
+          "DNSSEC enabled and validated on all critical domains",
+          "CAA records configured to restrict certificate issuance"
+        ],
+        "baselinesMissed": [
+          "TTL policies documented with rationale",
+          "Standards applied consistently based on domain classification"
+        ]
+      }
+    ],
+    "gaps": [
+      "TTL policies documented with rationale",
+      "Standards applied consistently based on domain classification"
+    ]
+  },
+  {
+    "controlId": "dns-4.1.2",
+    "controlTitle": "Email Authentication Standards",
+    "refs": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "header": "Email Security Configuration",
+        "coverage": "partial",
+        "baselinesMet": [
+          "SPF, DKIM, and DMARC configured for all domains that send email",
+          "DMARC policy set to reject for domains actively sending email",
+          "DMARC aggregate reports (rua) monitored and reviewed",
+          "MTA-STS configured where supported",
+          "Domains that don't send email have SPF/DMARC records that reject all"
+        ],
+        "baselinesMissed": []
+      }
+    ],
+    "gaps": []
+  },
+  {
+    "controlId": "dns-4.1.3",
+    "controlTitle": "Domain Lock Implementation",
+    "refs": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "header": "Registry Lock (EPP Lock)",
+        "coverage": "full",
+        "baselinesMet": [
+          "Registry locks (server-level EPP locks) enabled for critical domains",
+          "Transfer locks enabled on all domains",
+          "Lock status verified periodically (mentions EPP status codes)"
+        ],
+        "baselinesMissed": []
+      }
+    ],
+    "gaps": []
+  },
+  {
+    "controlId": "dns-4.1.4",
+    "controlTitle": "TLS Certificate Lifecycle Management",
+    "refs": [],
+    "gaps": [
+      "Covers issuance, renewal, and revocation procedures",
+      "Certificates tracked with expiration alerts",
+      "Automated renewal where possible",
+      "Revocation procedures documented for compromised certificates"
+    ]
+  },
+  {
+    "controlId": "dns-5.1.1",
+    "controlTitle": "Domain and DNS Monitoring",
+    "refs": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "header": "DNS Record Monitoring",
+        "coverage": "partial",
+        "baselinesMet": [
+          "DNS record monitoring covers NS, A/AAAA, MX, TXT/SPF/DMARC, CAA, DNSSEC, TTL changes",
+          "Registration monitoring covers lock status, registrar settings, nameserver delegation",
+          "Critical alerts trigger immediate investigation",
+          "Monitoring infrastructure not dependent on domains being monitored"
+        ],
+        "baselinesMissed": [
+          "Alerting and escalation paths documented (mentioned but not detailed HOW to document)"
+        ]
+      }
+    ],
+    "gaps": [
+      "Detailed guidance on documenting alerting and escalation paths"
+    ]
+  },
+  {
+    "controlId": "dns-5.1.2",
+    "controlTitle": "Certificate Transparency Monitoring",
+    "refs": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "header": "Certificate Transparency Monitoring",
+        "coverage": "full",
+        "baselinesMet": [
+          "Subscribed to a CT monitoring service that alerts on new certificate issuance",
+          "Alerts reviewed and unauthorized certificates investigated promptly",
+          "Wildcard certificates flagged if not expected"
+        ],
+        "baselinesMissed": []
+      }
+    ],
+    "gaps": []
+  },
+  {
+    "controlId": "dns-5.1.3",
+    "controlTitle": "Domain Expiration Prevention",
+    "refs": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "header": "Domain Expiration Protection",
+        "coverage": "full",
+        "baselinesMet": [
+          "Auto-renewal enabled on all domains",
+          "Calendar reminders at 90, 60, 30, and 7 days before expiration",
+          "Payment methods verified current",
+          "Backup person designated for renewal responsibility"
+        ],
+        "baselinesMissed": []
+      }
+    ],
+    "gaps": []
+  },
+  {
+    "controlId": "dns-6.1.1",
+    "controlTitle": "Alerting and Emergency Contacts",
+    "refs": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "header": "Setting Up Alerts",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Alerting system in place to notify stakeholders when potential compromise detected",
+          "Communication plan for warning users (status page, social media)"
+        ],
+        "baselinesMissed": [
+          "Emergency contacts pre-documented (registrar security, SEAL 911, legal) - partially in overview but not comprehensive"
+        ]
+      }
+    ],
+    "gaps": [
+      "Comprehensive emergency contact documentation including registrar security team, SEAL 911, and legal counsel"
+    ]
+  },
+  {
+    "controlId": "dns-6.1.2",
+    "controlTitle": "Domain Incident Response Plan",
+    "refs": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "header": "Incident Response Plan",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Covers registrar account compromise, DNS hijacking, unauthorized transfers",
+          "Emergency registry lock activation procedures",
+          "Procedures for regaining control of compromised domains",
+          "Post-recovery validation (DNS records verified, credentials reset, logs reviewed)"
+        ],
+        "baselinesMissed": [
+          "Plan tested at least annually"
+        ]
+      }
+    ],
+    "gaps": [
+      "Plan tested at least annually (can be combined with broader IR drills)"
+    ]
+  }
+]
\ No newline at end of file
diff --git a/scripts/data/eval-results/sfc-incident-response.json b/scripts/data/eval-results/sfc-incident-response.json
new file mode 100644
index 00000000..27169c20
--- /dev/null
+++ b/scripts/data/eval-results/sfc-incident-response.json
@@ -0,0 +1,412 @@
+[
+  {
+    "controlId": "ir-1.1.1",
+    "controlTitle": "IR Team and Role Assignments",
+    "refs": [],
+    "gaps": [
+      "Incident commander (with designated backup) who coordinates response, assigns tasks, and makes time-sensitive decisions",
+      "Subject matter experts identified for key domains (smart contracts, infrastructure, security) who can analyze attacks and prepare response strategies",
+      "Scribe role defined for real-time incident documentation",
+      "Communications personnel designated for public information sharing and record-keeping",
+      "Legal support available with procedures for reviewing response actions, whitehat engagement, and public communications",
+      "Decision makers defined for high-stakes decisions (system shutdown, public disclosure, fund recovery)"
+    ]
+  },
+  {
+    "controlId": "ir-1.1.2",
+    "controlTitle": "Stakeholder Coordination and Contacts",
+    "refs": [
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "header": "Emergency Contact Information",
+        "coverage": "partial",
+        "baselinesMet": [
+          "External expertise contacts (Security team mentioned)",
+          "Escalation order documented (template includes escalation to Security team)"
+        ],
+        "baselinesMissed": [
+          "Internal coordination procedures between technical and operational teams",
+          "External protocol contacts for dependencies",
+          "Legal counsel and PR contacts",
+          "Infrastructure vendor support contacts",
+          "Contact list reviewed quarterly"
+        ]
+      },
+      {
+        "page": "/incident-management/playbooks/seal-911-war-room-guidelines",
+        "header": "Key Roles",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Internal coordination procedures (role assignments for Operations, Protocol Lead, Web/Infrastructure Lead, External Communicator)",
+          "External expertise contacts (SEAL 911, security researchers)",
+          "Escalation order (implicit in role structure)"
+        ],
+        "baselinesMissed": [
+          "External protocol contacts for dependencies",
+          "Legal counsel and PR contacts (communications mentioned but not specific contacts)",
+          "Infrastructure vendor support contacts",
+          "Contact list reviewed quarterly"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "header": "Communication & Documentation",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Internal coordination (signers must notify multisig participants of incidents)"
+        ],
+        "baselinesMissed": [
+          "External protocol contacts",
+          "External expertise contacts",
+          "Legal counsel and PR contacts",
+          "Infrastructure vendor contacts",
+          "Contact list reviewed quarterly",
+          "Escalation order for P1 incidents"
+        ]
+      }
+    ],
+    "gaps": [
+      "External protocol contacts for protocols you depend on and protocols that depend on you",
+      "Legal counsel and communications/PR contacts with specific documented procedures",
+      "Infrastructure vendor support contacts and escalation procedures",
+      "Contact list reviewed at least quarterly and after team changes"
+    ]
+  },
+  {
+    "controlId": "ir-2.1.1",
+    "controlTitle": "Monitoring Coverage",
+    "refs": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "header": "DNS Record Monitoring",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Monitoring coverage for critical systems (DNS/domain infrastructure)",
+          "Credential exposure detection (mentioned in Certificate Transparency monitoring)",
+          "Organizational account monitoring (domain/DNS as critical organizational asset)",
+          "Monitoring coverage documented (what to watch for is documented)"
+        ],
+        "baselinesMissed": [
+          "24/7 monitoring with after-hours procedures",
+          "Credential and secret exposure in code repositories and dark web"
+        ]
+      },
+      {
+        "page": "/monitoring/guidelines",
+        "header": "Best Practices",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Monitoring objectives defined (critical metrics)",
+          "Monitoring coverage documented (define what to monitor)"
+        ],
+        "baselinesMissed": [
+          "24/7 monitoring capabilities with after-hours procedures",
+          "Credential and secret exposure detection",
+          "Organizational account monitoring",
+          "Known gaps documented"
+        ]
+      }
+    ],
+    "gaps": [
+      "24/7 monitoring capabilities with procedures for after-hours alert handling",
+      "Credential and secret exposure detection including dark web monitoring, breach database scanning, and secret scanning in code repositories",
+      "Organizational account monitoring including social media accounts and websites monitored for unauthorized access or compromise"
+    ]
+  },
+  {
+    "controlId": "ir-2.1.2",
+    "controlTitle": "Alerting, Paging, and Escalation",
+    "refs": [
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "header": "Immediate Actions",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Triage and classification procedures (assess scope, escalate)",
+          "Management notification for high-severity (contact Security team)",
+          "Escalation paths (Emergency notification template with escalation)"
+        ],
+        "baselinesMissed": [
+          "Automated alerting configured",
+          "Alerts include embedded triage guidance",
+          "Time-based escalation triggers",
+          "Redundant paging systems",
+          "On-call schedules maintained",
+          "Backup procedures when on-call unreachable"
+        ]
+      }
+    ],
+    "gaps": [
+      "Automated alerting configured for security events and operational issues",
+      "Alerts include embedded triage guidance for distinguishing true incidents from false positives",
+      "Time-based escalation triggers if initial responder doesn't acknowledge within defined window",
+      "Redundant paging systems with documented failover procedures",
+      "On-call schedules maintained with adequate coverage for operational needs",
+      "Backup procedures when on-call personnel are unreachable"
+    ]
+  },
+  {
+    "controlId": "ir-2.1.3",
+    "controlTitle": "Logging Integrity and Retention",
+    "refs": [],
+    "gaps": [
+      "Log retention periods defined for security, infrastructure, and cloud provider logs",
+      "Retention adequate for forensic analysis (consider regulatory requirements and typical investigation timelines)",
+      "Tamper-evident logging for security-relevant events including access logs, alerting system logs, and infrastructure logs",
+      "Alerts triggered if logs are altered, deleted, or if monitoring/logging is disabled",
+      "Log sources documented — what's captured and where it's stored"
+    ]
+  },
+  {
+    "controlId": "ir-3.1.1",
+    "controlTitle": "Response Playbooks",
+    "refs": [
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "header": "Key Compromise",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Playbooks cover key compromise scenario",
+          "Initial response actions (stop operations, notify, assess, escalate, document)",
+          "Key compromise includes procedures for rotating keys",
+          "Role-specific responsibilities (First Reporter, team coordination)"
+        ],
+        "baselinesMissed": [
+          "Playbooks for protocol exploits, infrastructure failures, access control breaches, supply chain compromises, frontend/DNS compromise",
+          "Escalation criteria for leadership engagement, system shutdown, public disclosure, external assistance"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "header": "Signer rotation",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Key compromise procedures (signer rotation when compromised)",
+          "Threshold reviewed after signer replacement"
+        ],
+        "baselinesMissed": [
+          "Playbooks for protocol exploits, infrastructure failures, access control breaches, supply chain, frontend/DNS",
+          "Initial response actions for each scenario",
+          "Role-specific responsibilities",
+          "Escalation criteria documented"
+        ]
+      }
+    ],
+    "gaps": [
+      "Playbooks cover protocol exploits, infrastructure failures, access control breaches, supply chain compromises, and frontend/DNS compromise",
+      "Each playbook includes containment, evidence preservation, and stakeholder notification",
+      "Escalation criteria documented for when to engage leadership, when to shut down systems, when to make public disclosure, and when to engage external assistance"
+    ]
+  },
+  {
+    "controlId": "ir-3.1.2",
+    "controlTitle": "Signer Reachability and Coordination",
+    "refs": [
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "header": "Training & Drills",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Procedures for emergency operations (drills mentioned)",
+          "Tested quarterly (for emergency multisigs)"
+        ],
+        "baselinesMissed": [
+          "Cross-timezone signer availability procedures",
+          "Signers integrated into on-call/paging systems",
+          "Escalation paths when signers unreachable"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "header": null,
+        "coverage": "partial",
+        "baselinesMet": [],
+        "baselinesMissed": [
+          "Procedures for coordinating multisig operations during incidents",
+          "Cross-timezone signer availability",
+          "Signers integrated into on-call/paging",
+          "Escalation paths for unreachable signers",
+          "Tested quarterly"
+        ]
+      }
+    ],
+    "gaps": [
+      "Procedures for coordinating multisig operations during incidents, including cross-timezone signer availability",
+      "Signers integrated into on-call/paging systems",
+      "Escalation paths documented for when signers are unreachable"
+    ]
+  },
+  {
+    "controlId": "ir-3.1.3",
+    "controlTitle": "Emergency Transaction Readiness",
+    "refs": [
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "header": "UI Alternatives",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Backup signing infrastructure (Eternal Safe, Squads Public Client)",
+          "Alternate signing UI (multiple UI options documented)",
+          "Backup RPC providers (guidance provided)",
+          "Alternate block explorer (Blockscout, explorer.solana.com, Solscan)",
+          "Emergency execution procedures (documented how to use backup systems)"
+        ],
+        "baselinesMissed": [
+          "Pre-signed or pre-prepared emergency transactions"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "header": "Emergency Preparedness",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Backup signing infrastructure (downloaded backup UIs)",
+          "Emergency execution procedures (understanding how to sign when primary UI is down)"
+        ],
+        "baselinesMissed": [
+          "Pre-signed or pre-prepared emergency transactions"
+        ]
+      }
+    ],
+    "gaps": [
+      "Pre-signed or pre-prepared emergency transactions for critical protocol functions (pause, freeze, parameter changes) where feasible"
+    ]
+  },
+  {
+    "controlId": "ir-4.1.1",
+    "controlTitle": "Incident Communication Channels",
+    "refs": [
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "header": "Documentation & Communication",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Primary and backup communication channels (set up per Communication Setup)",
+          "Multiple channels on different platforms (tested emergency notification)"
+        ],
+        "baselinesMissed": [
+          "Documented access controls and member lists",
+          "Documented failover procedures",
+          "Procedures for rapidly creating incident-specific channels",
+          "Secure communication procedures for sensitive information"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "header": "Emergency Communication Protocols",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Multiple communication channels (primary, backup, emergency contacts)",
+          "Secure communication procedures (need-to-know, secure channels)",
+          "Procedures for identity verification during incidents"
+        ],
+        "baselinesMissed": [
+          "Documented access controls and member lists",
+          "Documented failover procedures",
+          "Procedures for rapidly creating war room channels"
+        ]
+      }
+    ],
+    "gaps": [
+      "Dedicated incident communication channels with documented access controls and member lists",
+      "Documented failover procedures between primary and backup channels",
+      "Procedures for rapidly creating incident-specific channels (war room) when needed"
+    ]
+  },
+  {
+    "controlId": "ir-4.1.2",
+    "controlTitle": "Internal Status Updates",
+    "refs": [
+      {
+        "page": "/incident-management/communication-strategies",
+        "header": "Best Practices",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Status update cadence defined (regular updates to stakeholders)",
+          "Format and distribution for internal stakeholders (provide regular updates to employees)"
+        ],
+        "baselinesMissed": []
+      }
+    ],
+    "gaps": []
+  },
+  {
+    "controlId": "ir-4.1.3",
+    "controlTitle": "Public Communication and Information Management",
+    "refs": [
+      {
+        "page": "/incident-management/playbooks/seal-911-war-room-guidelines",
+        "header": "Communications",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Procedures for coordinating communications during and after incidents",
+          "Procedures for managing public information flow (monitoring social media)",
+          "Designated approval flow (External Communicator role)"
+        ],
+        "baselinesMissed": [
+          "Pre-approved communication templates for different incident types and severity"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "header": "Emergency Notification Template",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Pre-approved communication templates (emergency notification template provided)"
+        ],
+        "baselinesMissed": [
+          "Templates for different incident types and severity levels",
+          "Procedures for coordinating with protocol users during/after",
+          "Procedures for managing misinformation",
+          "Designated approval flow before public statements"
+        ]
+      }
+    ],
+    "gaps": [
+      "Pre-approved communication templates for different incident types and severity levels (only one emergency template provided)",
+      "Procedures for managing public information flow and correcting misinformation during active incidents"
+    ]
+  },
+  {
+    "controlId": "ir-5.1.1",
+    "controlTitle": "IR Drills and Testing",
+    "refs": [
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "header": "Emergency Drill Procedures",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Drills conducted regularly (quarterly, bi-annually, annually)",
+          "Tests full pipeline (notification, response time, process verification)",
+          "Production alerting validated (notification test, response time measurement)"
+        ],
+        "baselinesMissed": [
+          "Drills cover different incident types across exercises",
+          "Drill documentation with gaps and corrective actions",
+          "Corrective actions tracked to completion",
+          "Findings incorporated into playbook updates"
+        ]
+      },
+      {
+        "page": "/incident-management/playbooks/decentralized-ir",
+        "header": "Keep It Alive",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Drills conducted regularly (quarterly red team drills)",
+          "Findings incorporated into updates (iterate on framework during retrospective)"
+        ],
+        "baselinesMissed": [
+          "Tests full pipeline from monitoring through recovery",
+          "Production alerting validated end-to-end",
+          "Drill documentation with participants, response times, gaps",
+          "Corrective actions tracked to completion"
+        ]
+      }
+    ],
+    "gaps": [
+      "Drills cover different incident types across exercises (protocol exploit, infrastructure failure, key compromise, etc.)",
+      "Drill documentation includes date, scenario, participants, response times, gaps identified, and corrective actions",
+      "Corrective actions tracked to completion with owners and deadlines"
+    ]
+  }
+]
\ No newline at end of file
diff --git a/scripts/data/eval-results/sfc-multisig-ops.json b/scripts/data/eval-results/sfc-multisig-ops.json
new file mode 100644
index 00000000..280b062b
--- /dev/null
+++ b/scripts/data/eval-results/sfc-multisig-ops.json
@@ -0,0 +1,582 @@
+[
+  {
+    "controlId": "ms-1.1.1",
+    "controlTitle": "Named Multisig Operations Owner",
+    "refs": [
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "header": "For Multisig Administrators",
+        "coverage": "partial",
+        "baselinesMet": [],
+        "baselinesMissed": [
+          "Accountability scope covers policy maintenance, signer onboarding/offboarding, documentation accuracy, periodic reviews, and incident escalation"
+        ]
+      }
+    ],
+    "gaps": [
+      "Accountability scope covers policy maintenance, signer onboarding/offboarding, documentation accuracy, periodic reviews, and incident escalation - NO page teaches organizations HOW to establish clear accountability with defined scope covering all these areas"
+    ]
+  },
+  {
+    "controlId": "ms-1.1.2",
+    "controlTitle": "Multisig Registry and Documentation",
+    "refs": [
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "header": "Communication & Documentation",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Registry includes address, network, threshold, classification, purpose, signer addresses, controlled contracts, on-chain roles, and last review date (mentions documentation of purpose, wallet address, signer addresses)"
+        ],
+        "baselinesMissed": [
+          "Updated within 24 hours for security-critical changes, 3 days for routine changes",
+          "Accessible to signers and key personnel"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "header": "Documentation & Communication",
+        "coverage": "partial",
+        "baselinesMet": [],
+        "baselinesMissed": [
+          "Registry includes address, network, threshold, classification, purpose, signer addresses, controlled contracts, on-chain roles, and last review date",
+          "Updated within 24 hours for security-critical changes, 3 days for routine changes",
+          "Accessible to signers and key personnel"
+        ]
+      }
+    ],
+    "gaps": [
+      "Updated within 24 hours for security-critical changes, 3 days for routine changes - NO page provides specific update timeline requirements",
+      "Accessible to signers and key personnel - NO page substantively teaches access control for registry",
+      "Complete registry structure with ALL required fields (network, classification, controlled contracts, on-chain roles, last review date) not fully taught"
+    ]
+  },
+  {
+    "controlId": "ms-2.1.1",
+    "controlTitle": "Multisig Classification and Risk-Based Controls",
+    "refs": [
+      {
+        "page": "/multisig-for-protocols/planning-and-classification",
+        "header": "Classification Process",
+        "coverage": "full",
+        "baselinesMet": [
+          "Classification considers impact factors (financial exposure, protocol criticality, reputational risk) and operational needs (response time, coordination complexity)",
+          "Each classification maps to specific required controls (thresholds, quorum composition, review cadence)",
+          "Higher-risk classifications require stronger controls (more signers, higher thresholds)",
+          "Classifications reviewed every 6 months and after significant changes (TVL shifts, new products, protocol upgrades, security incidents)"
+        ],
+        "baselinesMissed": [
+          "All multisigs must have at least 3 distinct signers with a signing threshold of 50% or greater; N-of-N configurations should be avoided"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "header": "Thresholds & Configuration",
+        "coverage": "full",
+        "baselinesMet": [
+          "All multisigs must have at least 3 distinct signers with a signing threshold of 50% or greater; N-of-N configurations should be avoided",
+          "Higher-risk classifications require stronger controls (more signers, higher thresholds)"
+        ],
+        "baselinesMissed": [
+          "Classification considers impact factors and operational needs in a formal framework",
+          "Each classification maps to specific required controls",
+          "Classifications reviewed every 6 months and after significant changes"
+        ]
+      }
+    ],
+    "gaps": []
+  },
+  {
+    "controlId": "ms-2.1.2",
+    "controlTitle": "Contract-Level Security Controls",
+    "refs": [
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "header": "Contract-Level Controls",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Evaluation covers timelocks, modules, guards, address whitelisting, invariant enforcement, and parameter bounds",
+          "Security review required before enabling any module or guard"
+        ],
+        "baselinesMissed": [
+          "Controls evaluated for each multisig based on classification",
+          "Decisions documented, including rationale for controls not implemented"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "header": "Contract-Level Security",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Evaluation covers timelocks, modules, guards, address whitelisting, invariant enforcement, and parameter bounds"
+        ],
+        "baselinesMissed": [
+          "Controls evaluated for each multisig based on classification",
+          "Security review required before enabling any module or guard",
+          "Decisions documented, including rationale for controls not implemented"
+        ]
+      }
+    ],
+    "gaps": [
+      "Controls evaluated for each multisig based on classification - NO page teaches systematic evaluation process tied to classification levels",
+      "Decisions documented, including rationale for controls not implemented - NO page provides documentation requirements for control selection decisions"
+    ]
+  },
+  {
+    "controlId": "ms-2.1.3",
+    "controlTitle": "Exception Approval Process",
+    "refs": [],
+    "gaps": [
+      "Exceptions require documented justification, expiry date, compensating controls, and remediation plan - NO page teaches exception approval process",
+      "Critical-class exceptions require executive or security-lead approval - NO page defines approval authority by classification"
+    ]
+  },
+  {
+    "controlId": "ms-2.1.4",
+    "controlTitle": "Wallet Segregation",
+    "refs": [],
+    "gaps": [
+      "Segregation considers value, operational needs, and risk tolerance - NO page substantively teaches HOW to determine segregation strategy",
+      "Examples include hot/cold separation and treasury distribution across multiple wallets - mentioned in context of travel security in /opsec/travel/guide but NOT as a multisig operational requirement"
+    ]
+  },
+  {
+    "controlId": "ms-3.1.1",
+    "controlTitle": "Signer Address Verification",
+    "refs": [
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "header": "Communication & Documentation",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Verification process includes message signing with the signer address, verification via an independent tool, and documented proof of verification"
+        ],
+        "baselinesMissed": []
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "header": "Pre-Launch Checklist",
+        "coverage": "partial",
+        "baselinesMet": [],
+        "baselinesMissed": [
+          "Verification process includes message signing with the signer address, verification via an independent tool, and documented proof of verification"
+        ]
+      }
+    ],
+    "gaps": []
+  },
+  {
+    "controlId": "ms-3.1.2",
+    "controlTitle": "Signer Key Management Standards",
+    "refs": [
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "header": "Thresholds & Configuration",
+        "coverage": "full",
+        "baselinesMet": [
+          "Hardware wallets required for all multisig operations",
+          "Each signer uses a fresh, dedicated address per multisig, used exclusively for that multisig's operations"
+        ],
+        "baselinesMissed": []
+      }
+    ],
+    "gaps": []
+  },
+  {
+    "controlId": "ms-3.1.3",
+    "controlTitle": "Seed Phrase Backup and Protection",
+    "refs": [
+      {
+        "page": "/wallet-security/seed-phrase-management",
+        "header": "Secure Storage Practices",
+        "coverage": "full",
+        "baselinesMet": [
+          "Seed phrases never stored digitally, in cloud storage, or photographed",
+          "Backups are geographically distributed (disaster resistant)",
+          "No single point of compromise (theft resistant)",
+          "Recoverable if one operator is unavailable (operator-loss resistant)"
+        ],
+        "baselinesMissed": []
+      }
+    ],
+    "gaps": []
+  },
+  {
+    "controlId": "ms-3.1.4",
+    "controlTitle": "Signer Lifecycle Management",
+    "refs": [
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "header": "Signer rotation",
+        "coverage": "partial",
+        "baselinesMet": [],
+        "baselinesMissed": [
+          "Offboarded signers removed within 48-72 hours (Emergency-class), 7 days (Critical-class), 14 days (others)",
+          "Access reviews quarterly, confirming each signer still controls their key"
+        ]
+      }
+    ],
+    "gaps": [
+      "Offboarded signers removed within 48-72 hours (Emergency-class), 7 days (Critical-class), 14 days (others) - NO page provides specific timeline requirements by classification",
+      "Access reviews quarterly, confirming each signer still controls their key - NO page teaches quarterly access review process"
+    ]
+  },
+  {
+    "controlId": "ms-3.1.5",
+    "controlTitle": "Signer Training and Assessment",
+    "refs": [
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "header": "For Signers",
+        "coverage": "full",
+        "baselinesMet": [
+          "Training covers transaction verification, emergency procedures, phishing and social engineering awareness",
+          "Practical skills assessment included"
+        ],
+        "baselinesMissed": [
+          "Annual refreshers; updates within 30 days of significant procedure changes"
+        ]
+      }
+    ],
+    "gaps": [
+      "Annual refreshers; updates within 30 days of significant procedure changes - NO page specifies ongoing training cadence requirements"
+    ]
+  },
+  {
+    "controlId": "ms-3.1.6",
+    "controlTitle": "Hardware Wallet Standards",
+    "refs": [
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "header": "Hardware & Security Setup",
+        "coverage": "full",
+        "baselinesMet": [
+          "Wallet capability requirements include adequate display, clear signing support, PIN security, and firmware integrity verification",
+          "Procurement through verified supply chains (direct from manufacturer or authorized resellers), with device authenticity verification"
+        ],
+        "baselinesMissed": []
+      }
+    ],
+    "gaps": []
+  },
+  {
+    "controlId": "ms-3.1.7",
+    "controlTitle": "Secure Signing Environment",
+    "refs": [
+      {
+        "page": "/multisig-for-protocols/personal-security-opsec",
+        "header": "Network Security",
+        "coverage": "full",
+        "baselinesMet": [
+          "Device security requirements documented and enforced",
+          "Dedicated signing devices or network isolation for high-value operations"
+        ],
+        "baselinesMissed": []
+      }
+    ],
+    "gaps": []
+  },
+  {
+    "controlId": "ms-3.1.8",
+    "controlTitle": "Signer Diversity",
+    "refs": [
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "header": "Strategic Signer Distribution",
+        "coverage": "full",
+        "baselinesMet": [
+          "Diversity requirements scale with multisig classification (inferred from role diversity, geographical separation, external parties requirements)"
+        ],
+        "baselinesMissed": []
+      }
+    ],
+    "gaps": []
+  },
+  {
+    "controlId": "ms-4.1.1",
+    "controlTitle": "Transaction Handling Process",
+    "refs": [
+      {
+        "page": "/wallet-security/signing-and-verification/secure-multisig-signing-process",
+        "header": "Phase 1: Signing the Off-Chain Message",
+        "coverage": "full",
+        "baselinesMet": [
+          "Process covers initiation, approval, simulation, execution, and confirmation",
+          "Each signer independently verifies transaction details (chain ID, target address, calldata, value, nonce, operation type) before signing",
+          "Transaction hashes compared across at least two independent interfaces",
+          "DELEGATECALL operations to untrusted addresses flagged as high risk"
+        ],
+        "baselinesMissed": [
+          "Defines who is authorized to initiate transactions",
+          "High-risk transactions require waiting periods where feasible and elevated threshold approval",
+          "High-risk thresholds defined based on classification and reviewed periodically",
+          "Private transaction submission used when appropriate to prevent front-running or MEV extraction"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "header": "Operational Best Practices",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Each signer independently verifies transaction details before signing",
+          "Transaction simulation used before signing"
+        ],
+        "baselinesMissed": [
+          "Process covers initiation, approval, simulation, execution, and confirmation",
+          "Defines who is authorized to initiate transactions",
+          "Transaction hashes compared across at least two independent interfaces",
+          "DELEGATECALL operations flagged as high risk",
+          "High-risk transactions require waiting periods and elevated threshold approval",
+          "High-risk thresholds defined based on classification",
+          "Private transaction submission used when appropriate"
+        ]
+      }
+    ],
+    "gaps": [
+      "Defines who is authorized to initiate transactions - NO page teaches authorization framework for transaction initiation",
+      "High-risk transactions require waiting periods where feasible and elevated threshold approval - mentioned timelocks in setup but not as operational requirement",
+      "High-risk thresholds defined based on classification and reviewed periodically - NO page teaches risk threshold definition process",
+      "Private transaction submission used when appropriate to prevent front-running or MEV extraction - NO page teaches when/how to use private RPCs for transaction submission"
+    ]
+  },
+  {
+    "controlId": "ms-4.1.2",
+    "controlTitle": "Transaction Audit Trails",
+    "refs": [],
+    "gaps": [
+      "Retained for 3 years - NO page specifies retention period",
+      "Records include proposer, approvers, verification evidence, timestamps, and issues encountered - NO page teaches comprehensive audit trail documentation requirements"
+    ]
+  },
+  {
+    "controlId": "ms-4.1.3",
+    "controlTitle": "Tool and Platform Evaluation",
+    "refs": [
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "header": "Transaction Verification",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Evaluation considers whether tools are open source or audited by 2+ reputable firms (implied by tool recommendations)"
+        ],
+        "baselinesMissed": [
+          "Formal process for adopting new tools",
+          "Tools have no known critical unpatched vulnerabilities and have established ecosystem adoption"
+        ]
+      }
+    ],
+    "gaps": [
+      "Formal process for adopting new tools - NO page teaches tool adoption approval process",
+      "Tools have no known critical unpatched vulnerabilities and have established ecosystem adoption - mentioned but not taught as evaluation criteria"
+    ]
+  },
+  {
+    "controlId": "ms-4.1.4",
+    "controlTitle": "Backup Signing Infrastructure",
+    "refs": [
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "header": "UI Alternatives",
+        "coverage": "full",
+        "baselinesMet": [
+          "Alternate signing UI",
+          "2-3 backup RPC providers",
+          "Alternate block explorer"
+        ],
+        "baselinesMissed": []
+      }
+    ],
+    "gaps": []
+  },
+  {
+    "controlId": "ms-5.1.1",
+    "controlTitle": "Secure Communication Procedures",
+    "refs": [
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "header": "Documentation & Communication",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Dedicated primary and backup channels on different platforms",
+          "End-to-end encryption, MFA required, invitation-based membership"
+        ],
+        "baselinesMissed": [
+          "Signer identity verified as standard procedure during signing operations (e.g., code words, video call, secondary authenticated channel)",
+          "Documented procedures for channel compromise including switching to backup channels and out-of-band verification",
+          "All signers trained on these procedures; compromise response tested annually"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "header": "Communication Account Compromise",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Documented procedures for channel compromise including switching to backup channels and out-of-band verification"
+        ],
+        "baselinesMissed": [
+          "Dedicated primary and backup channels on different platforms",
+          "End-to-end encryption, MFA required, invitation-based membership",
+          "Signer identity verified as standard procedure during signing operations",
+          "All signers trained on these procedures; compromise response tested annually"
+        ]
+      }
+    ],
+    "gaps": [
+      "Signer identity verified as standard procedure during signing operations (e.g., code words, video call, secondary authenticated channel) - mentioned in emergency procedures but NOT as standard operational procedure for ALL signing operations",
+      "All signers trained on these procedures; compromise response tested annually - NO page specifies annual testing requirement for communication compromise procedures"
+    ]
+  },
+  {
+    "controlId": "ms-5.1.2",
+    "controlTitle": "Emergency Contact List",
+    "refs": [
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "header": "Documentation & Communication",
+        "coverage": "partial",
+        "baselinesMet": [],
+        "baselinesMissed": [
+          "Includes protocol security team, external security resources, legal/compliance contacts, and backup contacts for signers",
+          "Personal emergency contacts for each signer (e.g., trusted family member, close colleague) for situations where the signer is unreachable through normal channels",
+          "Reviewed every 6 months"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "header": "Emergency Contact Information",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Includes protocol security team, external security resources, legal/compliance contacts, and backup contacts for signers"
+        ],
+        "baselinesMissed": [
+          "Personal emergency contacts for each signer",
+          "Reviewed every 6 months"
+        ]
+      }
+    ],
+    "gaps": [
+      "Personal emergency contacts for each signer (e.g., trusted family member, close colleague) for situations where the signer is unreachable through normal channels - NO page teaches requirement for personal emergency contacts",
+      "Reviewed every 6 months - NO page specifies review cadence for emergency contact lists"
+    ]
+  },
+  {
+    "controlId": "ms-6.1.1",
+    "controlTitle": "Emergency Playbooks",
+    "refs": [
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "header": "Key Compromise",
+        "coverage": "full",
+        "baselinesMet": [
+          "Scenarios covered include key compromise, lost access, communication channel compromise, and urgent protocol actions",
+          "Each scenario has procedures and escalation paths",
+          "Playbooks accessible through at least one backup method independent of the primary documentation platform"
+        ],
+        "baselinesMissed": []
+      }
+    ],
+    "gaps": []
+  },
+  {
+    "controlId": "ms-6.1.2",
+    "controlTitle": "Signer Reachability and Escalation",
+    "refs": [
+      {
+        "page": "/multisig-for-protocols/planning-and-classification",
+        "header": "Step 2: Operational Assessment",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Response times by classification - Emergency less than 2 hours, Time-Sensitive 2-12 hours, Routine 24-48 hours"
+        ],
+        "baselinesMissed": [
+          "Paging covers all signers including external parties",
+          "Tested quarterly",
+          "Escalation paths documented"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "header": "For Emergency Response Multisigs",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Escalation paths documented"
+        ],
+        "baselinesMissed": [
+          "Response times by classification",
+          "Paging covers all signers including external parties",
+          "Tested quarterly"
+        ]
+      }
+    ],
+    "gaps": [
+      "Paging covers all signers including external parties - NO page teaches establishment of paging system for all signers",
+      "Tested quarterly - NO page specifies quarterly testing requirement for reachability"
+    ]
+  },
+  {
+    "controlId": "ms-6.1.3",
+    "controlTitle": "Multisig Monitoring and Alerts",
+    "refs": [
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "header": "Operational Best Practices",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Monitored events include signer/threshold changes, transfers exceeding thresholds, nonce gaps, interactions with unknown addresses, failed transactions, module/guard changes (partial list mentioned)"
+        ],
+        "baselinesMissed": [
+          "Alerting and escalation paths documented",
+          "Monitoring infrastructure protected against tampering"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "header": "Active Monitoring",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Monitored events include proposed transactions, new signatures, and owner changes (partial list)"
+        ],
+        "baselinesMissed": [
+          "Monitored events include transfers exceeding thresholds, nonce gaps, interactions with unknown addresses, failed transactions, module/guard changes, low submitter/proposer balances",
+          "Alerting and escalation paths documented",
+          "Monitoring infrastructure protected against tampering"
+        ]
+      }
+    ],
+    "gaps": [
+      "Complete list of monitored events (transfers exceeding thresholds, nonce gaps, interactions with unknown addresses, failed transactions, module/guard changes, low submitter/proposer balances) - NO page provides comprehensive monitoring event list",
+      "Alerting and escalation paths documented - NO page teaches documentation of alert escalation",
+      "Monitoring infrastructure protected against tampering - NO page addresses monitoring system security"
+    ]
+  },
+  {
+    "controlId": "ms-6.1.4",
+    "controlTitle": "Emergency Drills and Improvement",
+    "refs": [
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "header": "Specialized Training by Use Case",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Annual minimum (implied by emergency simulation drills requirement)"
+        ],
+        "baselinesMissed": [
+          "After major procedure changes",
+          "Documentation includes date, participants, response times, issues identified, and improvements made"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "header": "Emergency Drill Procedures",
+        "coverage": "full",
+        "baselinesMet": [
+          "Annual minimum (quarterly for some tests)",
+          "After major procedure changes (implied)",
+          "Documentation includes date, participants, response times, issues identified, and improvements made"
+        ],
+        "baselinesMissed": []
+      }
+    ],
+    "gaps": []
+  }
+]
\ No newline at end of file
diff --git a/scripts/data/eval-results/sfc-treasury-ops.json b/scripts/data/eval-results/sfc-treasury-ops.json
new file mode 100644
index 00000000..891bdcd6
--- /dev/null
+++ b/scripts/data/eval-results/sfc-treasury-ops.json
@@ -0,0 +1,487 @@
+[
+  {
+    "controlId": "tro-1.1.1",
+    "controlTitle": "Treasury Operations Owner",
+    "refs": [],
+    "gaps": [
+      "Accountability scope covers policy upkeep, security reviews, operational hygiene, access control oversight, and incident escalation"
+    ]
+  },
+  {
+    "controlId": "tro-1.1.2",
+    "controlTitle": "Treasury Registry and Documentation",
+    "refs": [
+      {
+        "page": "/treasury-operations/registration-documents",
+        "header": "Registration Template",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Registry includes wallet/account address, network/chain, custody provider, custody model, purpose/classification, authorized signers/approvers, controlled contracts or protocols, and last review date",
+          "Accessible to authorized treasury personnel"
+        ],
+        "baselinesMissed": [
+          "Updated within 24 hours for security-critical changes (signer changes, new wallets), 3 days for routine changes"
+        ]
+      }
+    ],
+    "gaps": [
+      "Updated within 24 hours for security-critical changes (signer changes, new wallets), 3 days for routine changes"
+    ]
+  },
+  {
+    "controlId": "tro-1.1.3",
+    "controlTitle": "Custody Architecture Rationale",
+    "refs": [
+      {
+        "page": "/treasury-operations/enhanced-controls",
+        "header": "MPC for Large Holdings",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Custody model documented for each wallet/account (custodial, self-custody, co-managed, MPC, multisig, HSM)"
+        ],
+        "baselinesMissed": [
+          "Technology trade-offs understood by the team",
+          "Custody architecture reviewed when treasury size, operational needs, or risk profile changes significantly"
+        ]
+      }
+    ],
+    "gaps": [
+      "Technology trade-offs understood by the team (not necessarily a formal document — could be a brief internal memo)",
+      "Custody architecture reviewed when treasury size, operational needs, or risk profile changes significantly"
+    ]
+  },
+  {
+    "controlId": "tro-1.1.4",
+    "controlTitle": "Treasury Infrastructure Change Management",
+    "refs": [
+      {
+        "page": "/treasury-operations/registration-documents",
+        "header": "Access Change Template",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Changes require documented approval before implementation",
+          "All changes logged with justification and approver"
+        ],
+        "baselinesMissed": [
+          "Covers wallet setups, custody configurations, signer/approver permission changes, and protocol integrations",
+          "Changes reflected in the treasury registry within defined SLAs",
+          "Rollback procedures documented for critical changes"
+        ]
+      }
+    ],
+    "gaps": [
+      "Covers wallet setups, custody configurations, signer/approver permission changes, and protocol integrations",
+      "Changes reflected in the treasury registry within defined SLAs",
+      "Rollback procedures documented for critical changes"
+    ]
+  },
+  {
+    "controlId": "tro-2.1.1",
+    "controlTitle": "Treasury Wallet Risk Classification",
+    "refs": [
+      {
+        "page": "/treasury-operations/classification",
+        "header": null,
+        "coverage": "full",
+        "baselinesMet": [
+          "Classification considers financial exposure, operational dependency, and regulatory impact",
+          "Impact levels defined (e.g., Low <1%, Medium 1-10%, High 10-25%, Critical >25% of total assets)",
+          "Operational types defined based on transaction frequency and urgency requirements",
+          "Each classification maps to specific controls including approval thresholds, MFA requirements, whitelist delays, and monitoring levels",
+          "Classification reviewed when asset values, operational patterns, or risk profile change significantly"
+        ],
+        "baselinesMissed": []
+      }
+    ],
+    "gaps": []
+  },
+  {
+    "controlId": "tro-2.1.2",
+    "controlTitle": "Fund Allocation Limits and Rebalancing",
+    "refs": [],
+    "gaps": [
+      "Maximum allocation defined per wallet, per custody provider, and per chain",
+      "Rebalancing triggers documented (e.g., when a wallet exceeds its allocation ceiling or falls below operational minimums)",
+      "Allocation limits reviewed periodically and after significant treasury changes",
+      "No single wallet or custody account holds more than the organization's defined maximum concentration"
+    ]
+  },
+  {
+    "controlId": "tro-3.1.1",
+    "controlTitle": "Custody Platform Security Configuration",
+    "refs": [
+      {
+        "page": "/treasury-operations/enhanced-controls",
+        "header": "Access Security",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Transaction policy rules configured: multi-approval workflows, approval thresholds scaled to transaction value, address whitelisting with cooling-off periods, velocity/spending limits",
+          "Hardware security key MFA required for all approvers on High and Critical accounts",
+          "Session timeouts and re-authentication for sensitive operations",
+          "Network restrictions: IP whitelisting, VPN requirements where supported, geographic access restrictions",
+          "Separation of duties enforced: initiators cannot approve their own transactions, admins cannot unilaterally execute withdrawals"
+        ],
+        "baselinesMissed": [
+          "Platform configurations documented and reviewed at least quarterly"
+        ]
+      },
+      {
+        "page": "/treasury-operations/registration-documents",
+        "header": "Security Configuration Template",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Transaction policy rules configured: multi-approval workflows, approval thresholds scaled to transaction value, address whitelisting with cooling-off periods, velocity/spending limits",
+          "Hardware security key MFA required for all approvers on High and Critical accounts",
+          "Session timeouts and re-authentication for sensitive operations",
+          "Network restrictions: IP whitelisting, VPN requirements where supported, geographic access restrictions",
+          "Separation of duties enforced: initiators cannot approve their own transactions, admins cannot unilaterally execute withdrawals",
+          "Platform configurations documented and reviewed at least quarterly"
+        ],
+        "baselinesMissed": []
+      }
+    ],
+    "gaps": []
+  },
+  {
+    "controlId": "tro-3.1.2",
+    "controlTitle": "Credential and Secret Management",
+    "refs": [
+      {
+        "page": "/treasury-operations/enhanced-controls",
+        "header": "Access Security",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Credentials stored in dedicated secret management systems, not in code, documents, or shared drives",
+          "Owner and admin credentials isolated from day-to-day operational access"
+        ],
+        "baselinesMissed": [
+          "Covers API keys, service accounts, owner/admin credentials, and signing keys",
+          "Credential rotation schedule defined and enforced",
+          "Access to credentials logged and monitored"
+        ]
+      },
+      {
+        "page": "/wallet-security/seed-phrase-management",
+        "header": null,
+        "coverage": "partial",
+        "baselinesMet": [
+          "Credentials stored in dedicated secret management systems, not in code, documents, or shared drives"
+        ],
+        "baselinesMissed": [
+          "Covers API keys, service accounts, owner/admin credentials, and signing keys",
+          "Owner and admin credentials isolated from day-to-day operational access",
+          "Credential rotation schedule defined and enforced",
+          "Access to credentials logged and monitored"
+        ]
+      }
+    ],
+    "gaps": [
+      "Credential rotation schedule defined and enforced",
+      "Access to credentials logged and monitored"
+    ]
+  },
+  {
+    "controlId": "tro-3.1.3",
+    "controlTitle": "Access Reviews for Treasury Systems",
+    "refs": [
+      {
+        "page": "/treasury-operations/registration-documents",
+        "header": "Quarterly Review Template",
+        "coverage": "full",
+        "baselinesMet": [
+          "Access reviews conducted at least quarterly for High/Critical accounts, annually for others",
+          "Reviews verify each user still requires their current access level",
+          "Access promptly revoked when personnel change roles or leave"
+        ],
+        "baselinesMissed": []
+      }
+    ],
+    "gaps": []
+  },
+  {
+    "controlId": "tro-3.1.4",
+    "controlTitle": "Personnel Operational Security",
+    "refs": [
+      {
+        "page": "/treasury-operations/enhanced-controls",
+        "header": "Device Security",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Device security requirements documented: dedicated devices for custody access, full disk encryption, automatic screen lock",
+          "VPN mandatory for all remote treasury platform access",
+          "Mobile devices used as second factors have endpoint security monitoring"
+        ],
+        "baselinesMissed": [
+          "Signing devices (hardware wallets) securely stored when not in use",
+          "Backup materials (seed phrases, recovery keys) stored securely with geographic distribution",
+          "Travel security procedures for personnel with signing or custody access capabilities"
+        ]
+      },
+      {
+        "page": "/wallet-security/seed-phrase-management",
+        "header": "Secure Storage Practices",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Backup materials (seed phrases, recovery keys) stored securely with geographic distribution"
+        ],
+        "baselinesMissed": [
+          "Device security requirements documented: dedicated devices for custody access, full disk encryption, automatic screen lock",
+          "Signing devices (hardware wallets) securely stored when not in use",
+          "VPN mandatory for all remote treasury platform access",
+          "Travel security procedures for personnel with signing or custody access capabilities",
+          "Mobile devices used as second factors have endpoint security monitoring"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/personal-security-opsec",
+        "header": "Device Security",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Device security requirements documented: dedicated devices for custody access, full disk encryption, automatic screen lock",
+          "Signing devices (hardware wallets) securely stored when not in use",
+          "Backup materials (seed phrases, recovery keys) stored securely with geographic distribution",
+          "VPN mandatory for all remote treasury platform access",
+          "Travel security procedures for personnel with signing or custody access capabilities",
+          "Mobile devices used as second factors have endpoint security monitoring"
+        ],
+        "baselinesMissed": []
+      }
+    ],
+    "gaps": []
+  },
+  {
+    "controlId": "tro-4.1.1",
+    "controlTitle": "Transaction Verification and Execution",
+    "refs": [
+      {
+        "page": "/treasury-operations/transaction-verification",
+        "header": "Execution Protocol",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Pre-execution verification includes: recipient address validation, amount verification, network confirmation, and transaction simulation",
+          "Test transactions required before sending to new addresses",
+          "Address verified through multiple independent sources; never copied from email, chat, or transaction history",
+          "Multi-party confirmation required: minimum 2 internal personnel for large transfers",
+          "Specific procedures for receiving large incoming transfers (address generation, bidirectional test, sender coordination)",
+          "High-value transfers (organization-defined threshold) require video call verification with liveness checks",
+          "All transaction parameters read aloud and confirmed before execution"
+        ],
+        "baselinesMissed": [
+          "Specific procedures for OTC transactions where applicable"
+        ]
+      }
+    ],
+    "gaps": [
+      "Specific procedures for OTC transactions where applicable"
+    ]
+  },
+  {
+    "controlId": "tro-4.1.2",
+    "controlTitle": "Signer and Approver Knowledge",
+    "refs": [
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "header": "Transaction Verification",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Knowledge covers: transaction verification procedures, address validation techniques, social engineering awareness, emergency procedures",
+          "Competence demonstrated before authorization (e.g., verifying a test transaction end-to-end)"
+        ],
+        "baselinesMissed": [
+          "Knowledge refreshed annually; updated within 30 days of significant procedure changes",
+          "Covers custody-platform-specific workflows and policy engine rules"
+        ]
+      }
+    ],
+    "gaps": [
+      "Knowledge refreshed annually; updated within 30 days of significant procedure changes",
+      "Covers custody-platform-specific workflows and policy engine rules"
+    ]
+  },
+  {
+    "controlId": "tro-4.1.3",
+    "controlTitle": "Secure Communication Procedures",
+    "refs": [
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "header": "Communication Account Compromise",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Identity verified as standard procedure during signing/approval operations (e.g., code phrases, video call, secondary authenticated channel)",
+          "Anti-social-engineering protocols: established verification procedures for address changes or unusual requests",
+          "Documented procedures for channel compromise including switching to backup channels and out-of-band verification"
+        ],
+        "baselinesMissed": [
+          "Dedicated primary and backup channels on different platforms",
+          "End-to-end encryption, MFA required, invitation-based membership",
+          "All treasury personnel trained on these procedures; compromise response tested annually"
+        ]
+      }
+    ],
+    "gaps": [
+      "Dedicated primary and backup channels on different platforms",
+      "End-to-end encryption, MFA required, invitation-based membership",
+      "All treasury personnel trained on these procedures; compromise response tested annually"
+    ]
+  },
+  {
+    "controlId": "tro-5.1.1",
+    "controlTitle": "Protocol Evaluation and Exposure Limits",
+    "refs": [],
+    "gaps": [
+      "Due diligence process for all protocols before deployment: smart contract audit status, team reputation, TVL history, insurance coverage",
+      "Exposure limits defined per protocol, per chain, and per deployment category (DeFi, staking, liquid staking, etc.)",
+      "Limits reviewed periodically and after significant market or protocol changes",
+      "Risk re-evaluation triggered by: security incidents, major governance proposals, significant TVL changes, new vulnerabilities disclosed"
+    ]
+  },
+  {
+    "controlId": "tro-5.1.2",
+    "controlTitle": "Position Lifecycle Management",
+    "refs": [
+      {
+        "page": "/treasury-operations/transaction-verification",
+        "header": "Transaction Parameter Security",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Entry procedures: smart contract address verification against multiple independent sources, token approval management (minimal approvals, revocation after use)"
+        ],
+        "baselinesMissed": [
+          "Emergency withdrawal/exit procedures documented for all active positions",
+          "Alternative access methods documented in case primary UIs are unavailable (direct contract interaction, CLI tools, alternative frontends)",
+          "Unbonding/unstaking timelines understood and factored into liquidity planning"
+        ]
+      }
+    ],
+    "gaps": [
+      "Emergency withdrawal/exit procedures documented for all active positions",
+      "Alternative access methods documented in case primary UIs are unavailable (direct contract interaction, CLI tools, alternative frontends)",
+      "Unbonding/unstaking timelines understood and factored into liquidity planning"
+    ]
+  },
+  {
+    "controlId": "tro-6.1.1",
+    "controlTitle": "Monitoring and Threat Awareness",
+    "refs": [
+      {
+        "page": "/treasury-operations/enhanced-controls",
+        "header": "Security Monitoring & Logging",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Transaction monitoring: unusual amounts, unexpected destinations, failed transactions, policy violations",
+          "Account state monitoring: balance changes, configuration modifications, new device enrollments, authentication anomalies",
+          "Alerting with defined severity levels and escalation paths",
+          "Critical alerts (large unexpected transactions, unauthorized access attempts) trigger immediate investigation"
+        ],
+        "baselinesMissed": [
+          "External threat intelligence: protocol vulnerabilities, DeFi/staking risks, relevant security incidents in the ecosystem",
+          "Vendor/platform monitoring: custody platform status, infrastructure alerts, service availability",
+          "Compliance monitoring: transactions and wallet addresses screened for sanctions and compliance risk",
+          "Protocol and position monitoring: deployed protocol health, governance changes, TVL shifts, collateral ratios, reward accrual, liquidation risks",
+          "Monitoring system integrity protected — alerts triggered when monitoring configurations are changed, disabled, or degraded"
+        ]
+      }
+    ],
+    "gaps": [
+      "External threat intelligence: protocol vulnerabilities, DeFi/staking risks, relevant security incidents in the ecosystem",
+      "Vendor/platform monitoring: custody platform status, infrastructure alerts, service availability",
+      "Compliance monitoring: transactions and wallet addresses screened for sanctions and compliance risk",
+      "Protocol and position monitoring: deployed protocol health, governance changes, TVL shifts, collateral ratios, reward accrual, liquidation risks",
+      "Monitoring system integrity protected — alerts triggered when monitoring configurations are changed, disabled, or degraded"
+    ]
+  },
+  {
+    "controlId": "tro-6.1.2",
+    "controlTitle": "Incident Response Plan",
+    "refs": [
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "header": "Emergency Notification Template",
+        "coverage": "full",
+        "baselinesMet": [
+          "Severity levels defined with escalation procedures specific to treasury operations",
+          "Containment procedures: fund protection actions (emergency freeze, transfer to secure cold storage, policy lockdown)",
+          "Covers key scenarios: custody platform compromise, unauthorized transaction, signer key compromise, vendor breach",
+          "Emergency contacts pre-documented: custody provider security team, SEAL 911, legal counsel"
+        ],
+        "baselinesMissed": [
+          "Communication plan for stakeholders",
+          "Drills conducted at least annually; after major procedure changes",
+          "Drill documentation includes: date, participants, response times, issues identified, improvements made"
+        ]
+      }
+    ],
+    "gaps": [
+      "Communication plan for stakeholders",
+      "Drills conducted at least annually; after major procedure changes",
+      "Drill documentation includes: date, participants, response times, issues identified, improvements made"
+    ]
+  },
+  {
+    "controlId": "tro-7.1.1",
+    "controlTitle": "Vendor Security Management",
+    "refs": [],
+    "gaps": [
+      "Initial due diligence before adoption: security certifications (SOC 2, ISO 27001), audit history, insurance coverage, incident history",
+      "Ongoing monitoring: SOC report currency, security incident notifications, service availability tracking",
+      "Contractual security requirements verified periodically (at least annually)",
+      "Critical vendor changes (ownership, infrastructure, security posture) trigger re-evaluation"
+    ]
+  },
+  {
+    "controlId": "tro-7.1.2",
+    "controlTitle": "Backup Infrastructure and Alternate Access",
+    "refs": [
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "header": "UI Alternatives",
+        "coverage": "full",
+        "baselinesMet": [
+          "Alternate access methods for custody platforms documented and tested (e.g., API access, mobile app, secondary UI)",
+          "Backup RPC providers configured",
+          "Procedures for operating treasury if primary custody platform is unavailable",
+          "Backup infrastructure tested at least annually"
+        ],
+        "baselinesMissed": []
+      }
+    ],
+    "gaps": []
+  },
+  {
+    "controlId": "tro-8.1.1",
+    "controlTitle": "Financial Recordkeeping and Reconciliation",
+    "refs": [
+      {
+        "page": "/treasury-operations/registration-documents",
+        "header": "Security Configuration Template",
+        "coverage": "partial",
+        "baselinesMet": [
+          "All treasury transactions recorded with categorization, documentation, and authorization chain"
+        ],
+        "baselinesMissed": [
+          "Periodic reconciliation between custody platform records, on-chain balances, and accounting records",
+          "Reconciliation frequency scaled to account classification: daily for Active Operations, weekly for Warm Storage, monthly for Cold Vault",
+          "Discrepancies investigated and resolved promptly",
+          "Treasury reporting procedures documented with defined cadence and audience"
+        ]
+      }
+    ],
+    "gaps": [
+      "Periodic reconciliation between custody platform records, on-chain balances, and accounting records",
+      "Reconciliation frequency scaled to account classification: daily for Active Operations, weekly for Warm Storage, monthly for Cold Vault",
+      "Discrepancies investigated and resolved promptly",
+      "Treasury reporting procedures documented with defined cadence and audience"
+    ]
+  },
+  {
+    "controlId": "tro-8.1.2",
+    "controlTitle": "Insurance Coverage",
+    "refs": [],
+    "gaps": [
+      "Coverage scope documented: what's covered (custody theft, hack, insider fraud) and what's excluded",
+      "Coverage amounts appropriate relative to assets held",
+      "Custody provider's insurance evaluated as part of vendor due diligence",
+      "Insurance coverage reviewed at least annually or when treasury size changes significantly"
+    ]
+  }
+]
\ No newline at end of file
diff --git a/scripts/data/eval-results/sfc-workspace-security.json b/scripts/data/eval-results/sfc-workspace-security.json
new file mode 100644
index 00000000..b5f6c539
--- /dev/null
+++ b/scripts/data/eval-results/sfc-workspace-security.json
@@ -0,0 +1,850 @@
+[
+  {
+    "controlId": "ws-1.1.1",
+    "controlTitle": "Workspace Security Owner",
+    "refs": [
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "header": "Continuous Visibility",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Accountability touches on establishing clear ownership for monitoring domains"
+        ],
+        "baselinesMissed": [
+          "Does not address comprehensive workspace security ownership scope covering policy maintenance, device/account standards, access control oversight, periodic reviews, and incident escalation"
+        ]
+      }
+    ],
+    "gaps": [
+      "Full accountability scope covering policy maintenance, device and account standards, access control oversight, periodic reviews, and incident escalation - no page provides comprehensive guidance on designating a workspace security owner with this full scope"
+    ]
+  },
+  {
+    "controlId": "ws-1.1.2",
+    "controlTitle": "Workspace Security Policy",
+    "refs": [],
+    "gaps": [
+      "Policy covering core expectations including device security, account hygiene, credential management, acceptable use, and incident reporting",
+      "Written in plain language so all personnel can follow it",
+      "Policy reviewed at least annually and after significant changes"
+    ]
+  },
+  {
+    "controlId": "ws-1.1.3",
+    "controlTitle": "Asset Inventory",
+    "refs": [
+      {
+        "page": "/opsec/core-concepts/implementation-process",
+        "header": "Critical Asset Identification",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Map and document assets",
+          "Asset discovery and classification"
+        ],
+        "baselinesMissed": [
+          "Does not specify device inventory tracking (make/model, owner, OS version, encryption status, EDR/MDM enrollment)",
+          "Does not cover account inventory with ownership",
+          "Does not address updates as devices/accounts are provisioned or decommissioned"
+        ]
+      }
+    ],
+    "gaps": [
+      "Device inventory tracking make/model, owner, OS version, encryption status, and EDR/MDM enrollment",
+      "Account inventory covering organizational accounts with defined ownership",
+      "Updated as devices/accounts are provisioned or decommissioned"
+    ]
+  },
+  {
+    "controlId": "ws-1.1.4",
+    "controlTitle": "System and Data Classification",
+    "refs": [
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "header": "Information Flow Control",
+        "coverage": "full",
+        "baselinesMet": [
+          "Classification levels defined (Public, Internal, Confidential, Restricted)",
+          "Classification determines which controls apply",
+          "Data handling procedures for each classification level"
+        ],
+        "baselinesMissed": []
+      },
+      {
+        "page": "/opsec/core-concepts/implementation-process",
+        "header": "Critical Asset Identification",
+        "coverage": "full",
+        "baselinesMet": [
+          "Apply practical classification system with clear categories",
+          "Classification reviewed when conditions change"
+        ],
+        "baselinesMissed": []
+      }
+    ],
+    "gaps": []
+  },
+  {
+    "controlId": "ws-2.1.1",
+    "controlTitle": "Device Security Standards",
+    "refs": [
+      {
+        "page": "/opsec/travel/guide",
+        "header": "Secure devices with encryption & updates",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Full disk encryption enabled",
+          "Install latest OS and app updates",
+          "Strong authentication required (strong password/PIN)"
+        ],
+        "baselinesMissed": [
+          "Automatic OS and application patching",
+          "Administrative privileges separated from daily-use accounts",
+          "Devices procured through verified supply chains",
+          "Device compliance verification and monitoring",
+          "BYOD policy"
+        ]
+      },
+      {
+        "page": "/encryption/volume-encryption",
+        "header": null,
+        "coverage": "partial",
+        "baselinesMet": [
+          "Full disk encryption guidance"
+        ],
+        "baselinesMissed": [
+          "OS patching",
+          "Authentication",
+          "Admin privileges separation",
+          "Supply chain",
+          "Compliance monitoring",
+          "BYOD policy"
+        ]
+      },
+      {
+        "page": "/encryption/partition-encryption",
+        "header": null,
+        "coverage": "partial",
+        "baselinesMet": [
+          "Encryption for specific partitions"
+        ],
+        "baselinesMissed": [
+          "OS patching",
+          "Authentication",
+          "Admin privileges separation",
+          "Supply chain",
+          "Compliance monitoring",
+          "BYOD policy"
+        ]
+      }
+    ],
+    "gaps": [
+      "Automatic OS and application patching enabled or enforced",
+      "Administrative privileges separated from daily-use accounts",
+      "Devices procured through verified supply chains and verified for integrity upon receipt",
+      "Device compliance verified upon provisioning and monitored on an ongoing basis",
+      "BYOD policy defining what personal devices can access and security controls required"
+    ]
+  },
+  {
+    "controlId": "ws-2.1.2",
+    "controlTitle": "Device Lifecycle Management",
+    "refs": [
+      {
+        "page": "/opsec/travel/guide",
+        "header": "Back up and prepare for loss",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Remote wipe capability mentioned (Find My, MDM)",
+          "Procedures for lost devices (remote wipe, filing reports)"
+        ],
+        "baselinesMissed": [
+          "Documented procedures for credential rotation after loss",
+          "Incident escalation procedures",
+          "Secure decommissioning with data sanitization and verified destruction"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/physical-environmental",
+        "header": "Physical Security of Critical Assets",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Secure disposal procedures for equipment and media"
+        ],
+        "baselinesMissed": [
+          "Remote lock and wipe capability",
+          "Response procedures for lost/stolen devices",
+          "Credential rotation"
+        ]
+      }
+    ],
+    "gaps": [
+      "Documented procedures for credential rotation after device loss or theft",
+      "Incident escalation procedures for lost/stolen devices"
+    ]
+  },
+  {
+    "controlId": "ws-2.1.3",
+    "controlTitle": "Endpoint Protection",
+    "refs": [
+      {
+        "page": "/opsec/travel/guide",
+        "header": "Inspect and clean your devices",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Run anti-malware scan",
+          "Look for unusual behavior"
+        ],
+        "baselinesMissed": [
+          "EDR/MDM deployed on all devices with documented coverage",
+          "Alert triage and response procedures",
+          "Compliance enforcement actions",
+          "Monitoring for malware, unauthorized software, policy violations"
+        ]
+      }
+    ],
+    "gaps": [
+      "EDR or MDM deployed on all organizational devices with documented coverage",
+      "Alert triage and response procedures defined with severity-based escalation",
+      "Compliance enforcement actions documented",
+      "Monitoring coverage includes detection of malware, unauthorized software, and policy violations"
+    ]
+  },
+  {
+    "controlId": "ws-2.1.4",
+    "controlTitle": "Physical and Travel Security",
+    "refs": [
+      {
+        "page": "/opsec/travel/guide",
+        "header": null,
+        "coverage": "full",
+        "baselinesMet": [
+          "Screen privacy and shoulder-surfing awareness (privacy screen filter, shield keypad)",
+          "Travel security procedures (pre-travel assessment, secure travel practices, device security)",
+          "High-risk travel procedures (loaner devices, enhanced controls)",
+          "USB and charging security (avoid juice jacking, USB data blockers, no unknown USB drives)",
+          "Devices physically secured (cable locks, room safes, carry-on luggage)"
+        ],
+        "baselinesMissed": [
+          "Physical workspace requirements for on-site and remote work not comprehensively covered"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/physical-environmental",
+        "header": "Secure Workspace & Travel Security",
+        "coverage": "full",
+        "baselinesMet": [
+          "Physical workspace requirements (physical access controls, clean desk policy)",
+          "Travel security procedures",
+          "Device security during travel",
+          "Secure storage options"
+        ],
+        "baselinesMissed": []
+      }
+    ],
+    "gaps": []
+  },
+  {
+    "controlId": "ws-3.1.1",
+    "controlTitle": "Account Lifecycle Management",
+    "refs": [
+      {
+        "page": "/guides/account_management/discord",
+        "header": "Roles",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Review admin role members and permissions",
+          "Remove unnecessary permissions and members"
+        ],
+        "baselinesMissed": [
+          "Account creation approval process",
+          "Accounts provisioned with minimum necessary permissions systematically",
+          "Account modification approval",
+          "Account revocation tied to offboarding",
+          "Service accounts inventoried with ownership"
+        ]
+      }
+    ],
+    "gaps": [
+      "Account creation requires documented approval from manager or designated authority",
+      "Accounts provisioned with minimum necessary permissions (least privilege)",
+      "Modification of account permissions requires documented approval",
+      "Account revocation procedures tied to offboarding and role changes",
+      "Service accounts and shared credentials inventoried with defined ownership"
+    ]
+  },
+  {
+    "controlId": "ws-3.1.2",
+    "controlTitle": "Multi-Factor Authentication",
+    "refs": [
+      {
+        "page": "/opsec/travel/guide",
+        "header": "Protect Accounts with 2FA redundancy",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Plan for 2FA redundancy",
+          "Disable SMS for 2FA",
+          "Register backup 2FA methods"
+        ],
+        "baselinesMissed": [
+          "MFA required for all organizational accounts by default",
+          "Hardware security keys required for high-privilege accounts",
+          "Exceptions documented with justification and expiry"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/technical",
+        "header": "Two-Factor & Hardware Authentication",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Multi-factor authentication for all access to sensitive systems",
+          "Hardware security keys for high-value accounts",
+          "Backup authentication methods and recovery processes",
+          "Phishing-resistant MFA (hardware keys)"
+        ],
+        "baselinesMissed": [
+          "Exceptions documented with justification, compensating controls, and expiry date not explicitly covered"
+        ]
+      },
+      {
+        "page": "/guides/account_management/discord",
+        "header": "For Individuals - Account Security Checklist",
+        "coverage": "partial",
+        "baselinesMet": [
+          "2FA enabled requirement",
+          "Require 2FA for moderation"
+        ],
+        "baselinesMissed": [
+          "Hardware keys for high-privilege accounts",
+          "Phishing-resistant MFA preferred",
+          "Exceptions documented",
+          "Backup MFA methods"
+        ]
+      }
+    ],
+    "gaps": [
+      "Exceptions documented with justification, compensating controls, and expiry date"
+    ]
+  },
+  {
+    "controlId": "ws-3.1.3",
+    "controlTitle": "Organizational Account Security",
+    "refs": [
+      {
+        "page": "/guides/account_management/discord",
+        "header": "Server Settings Checklist",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Security configuration standards for Discord platform",
+          "Ownership verified through admin reviews"
+        ],
+        "baselinesMissed": [
+          "Security standards for enterprise platforms broadly",
+          "Social media and public-facing accounts",
+          "Recovery methods restricted to organizational channels",
+          "Periodic review for drift"
+        ]
+      }
+    ],
+    "gaps": [
+      "Security configuration standards defined and applied for enterprise platforms (Google Workspace, Microsoft 365, collaboration tools)",
+      "Social media and public-facing accounts secured with strong authentication and defined ownership",
+      "Recovery methods restricted to organizational channels (no personal recovery emails or phone numbers)",
+      "Account configurations reviewed periodically for drift or unauthorized changes"
+    ]
+  },
+  {
+    "controlId": "ws-3.1.4",
+    "controlTitle": "Credential Management Standards",
+    "refs": [
+      {
+        "page": "/opsec/travel/guide",
+        "header": "Protect Accounts with 2FA redundancy",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Password manager accessible (1Password Travel Mode)",
+          "Backup codes stored securely"
+        ],
+        "baselinesMissed": [
+          "Password manager required for all personnel",
+          "Unique strong passwords for every account",
+          "Individual accounts required (no sharing)",
+          "Credential transmission only through encrypted channels",
+          "Rotation schedule",
+          "Enhanced controls for high-privilege credentials",
+          "Service account inventory"
+        ]
+      },
+      {
+        "page": "/awareness/cultivating-a-security-aware-mindset",
+        "header": "Password Management",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Strong, unique passwords for each account",
+          "Password managers to securely store and generate passwords"
+        ],
+        "baselinesMissed": [
+          "No passwords in plain text/documents/browsers requirement",
+          "Individual accounts required",
+          "Credential transmission security",
+          "Rotation schedule",
+          "Enhanced controls for high-privilege",
+          "Service account inventory"
+        ]
+      },
+      {
+        "page": "/guides/account_management/telegram",
+        "header": "Account Security Checklist",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Strong unique password that doesn't get reused"
+        ],
+        "baselinesMissed": [
+          "Password manager required",
+          "Credential transmission",
+          "Rotation schedule",
+          "Enhanced controls",
+          "Service account inventory"
+        ]
+      }
+    ],
+    "gaps": [
+      "Password manager required for all personnel; no passwords stored in plain text, documents, or browsers",
+      "Individual accounts required for all personnel — no sharing of personal login credentials",
+      "Credential transmission only through encrypted channels (password manager sharing features, not email or chat)",
+      "Credential rotation schedule defined based on risk; rotation triggered immediately after suspected compromise",
+      "Enhanced controls for high-privilege credentials including stricter rotation, separate storage, and logged access",
+      "Service account and API key inventory maintained with defined ownership"
+    ]
+  },
+  {
+    "controlId": "ws-3.1.5",
+    "controlTitle": "Access Reviews",
+    "refs": [
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "header": "Minimal Access Scopes",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Conduct regular access reviews (quarterly for critical, annually for others)",
+          "Reviews verify each user still requires current access"
+        ],
+        "baselinesMissed": [
+          "Access adjusted within defined timelines when roles change",
+          "Unnecessary permissions revoked with documented evidence",
+          "Insider threat consideration"
+        ]
+      },
+      {
+        "page": "/guides/account_management/discord",
+        "header": "Regular Reviews",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Monthly review of role permissions",
+          "Quarterly assessment of rules",
+          "Track changes and justifications"
+        ],
+        "baselinesMissed": [
+          "Access adjusted when employees change roles",
+          "Insider threat damage scenarios",
+          "Reviews for critical vs standard systems"
+        ]
+      }
+    ],
+    "gaps": [
+      "Access adjusted within defined timelines when employees change roles",
+      "Unnecessary permissions revoked promptly with documented evidence",
+      "Insider threat consideration included — for each role, assess what damage could be done with current access"
+    ]
+  },
+  {
+    "controlId": "ws-4.1.1",
+    "controlTitle": "Software Evaluation and Approval",
+    "refs": [
+      {
+        "page": "/opsec/travel/guide",
+        "header": "Minimize digital footprint & social visibility",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Privacy-focused tools mentioned (Hide My Email, Tuta, ProtonMail)"
+        ],
+        "baselinesMissed": [
+          "Evaluation criteria for software before adoption",
+          "Data privacy and leakage risk assessment",
+          "Approved software list",
+          "Browser extension approval",
+          "Dependency management"
+        ]
+      }
+    ],
+    "gaps": [
+      "Evaluation criteria for all software before adoption (browsers, extensions, IDEs, libraries, AI assistants, SaaS tools)",
+      "Data privacy and leakage risks assessed (does the tool send data to third parties?)",
+      "Approved software list maintained; unapproved software restricted",
+      "Browser extension approval process defined",
+      "Dependency management includes version pinning, vulnerability scanning, and update policies"
+    ]
+  },
+  {
+    "controlId": "ws-4.1.2",
+    "controlTitle": "Source Code and Repository Security",
+    "refs": [
+      {
+        "page": "/guides/account_management/github",
+        "header": "Repository Settings",
+        "coverage": "full",
+        "baselinesMet": [
+          "Role-based access control (Collaborators and teams)",
+          "Branch protection rules enforced (require reviews, signed commits)",
+          "Automated secret scanning enabled (Code security settings)",
+          "Pre-commit hooks/CI checks (Push protection for secrets)",
+          "Repository security audited periodically (Sessions, SSH keys, webhooks review)"
+        ],
+        "baselinesMissed": []
+      }
+    ],
+    "gaps": []
+  },
+  {
+    "controlId": "ws-5.1.1",
+    "controlTitle": "Network Security",
+    "refs": [
+      {
+        "page": "/opsec/travel/guide",
+        "header": "Network safety – avoid untrusted Wi-Fi & Bluetooth",
+        "coverage": "partial",
+        "baselinesMet": [
+          "VPN or cellular connection preferred for sensitive operations",
+          "Wi-Fi security standards (disable auto-connect, avoid public Wi-Fi)",
+          "Cellular or personal hotspot preferred over public Wi-Fi"
+        ],
+        "baselinesMissed": [
+          "Network segmentation not covered"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/technical",
+        "header": "Network & Communication Security",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Network segmentation based on security requirements",
+          "Secure remote access solutions (VPN)",
+          "Network monitoring"
+        ],
+        "baselinesMissed": []
+      }
+    ],
+    "gaps": []
+  },
+  {
+    "controlId": "ws-5.1.2",
+    "controlTitle": "Secure Communications",
+    "refs": [
+      {
+        "page": "/opsec/travel/guide",
+        "header": "Plan emergency and incident responses",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Fallback plan for communication (safe words, beware deepfakes)"
+        ],
+        "baselinesMissed": [
+          "End-to-end encrypted channels used",
+          "Identity verification procedures for sensitive requests",
+          "Anti-impersonation protocols documented",
+          "Email security (SPF, DKIM, DMARC)",
+          "Procedures for channel compromise"
+        ]
+      },
+      {
+        "page": "/guides/account_management/telegram",
+        "header": "Use Secret Chats for Enhanced Privacy",
+        "coverage": "partial",
+        "baselinesMet": [
+          "End-to-end encrypted channels (Secret Chats)",
+          "Identity verification (compare encryption keys)"
+        ],
+        "baselinesMissed": [
+          "Anti-impersonation protocols beyond basic verification",
+          "Email security configuration",
+          "Procedures for channel compromise"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/technical",
+        "header": "Network & Communication Security",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Encrypted communications protecting data in transit"
+        ],
+        "baselinesMissed": [
+          "Identity verification procedures",
+          "Anti-impersonation protocols",
+          "Email security (SPF, DKIM, DMARC)",
+          "Channel compromise procedures"
+        ]
+      }
+    ],
+    "gaps": [
+      "Anti-impersonation protocols documented (e.g., secondary channel verification, code words, video confirmation)",
+      "Email security configured (SPF, DKIM, DMARC) to prevent spoofing",
+      "Procedures for channel compromise including switching to backup channels"
+    ]
+  },
+  {
+    "controlId": "ws-6.1.1",
+    "controlTitle": "Security Onboarding",
+    "refs": [
+      {
+        "page": "/opsec/control-domains/people",
+        "header": "Personnel Security Measures",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Pre-employment screening procedures",
+          "Security agreements for all team members",
+          "Security responsibilities in job descriptions"
+        ],
+        "baselinesMissed": [
+          "Security onboarding includes device provisioning, account creation, MFA setup, and initial training",
+          "New personnel acknowledge policies before access",
+          "Onboarding checklist documented and consistently applied"
+        ]
+      }
+    ],
+    "gaps": [
+      "Security onboarding includes device provisioning, account creation, MFA setup, and initial security training",
+      "New personnel acknowledge security policies before access is granted",
+      "Onboarding checklist documented and consistently applied"
+    ]
+  },
+  {
+    "controlId": "ws-6.1.2",
+    "controlTitle": "Security Offboarding",
+    "refs": [
+      {
+        "page": "/opsec/travel/guide",
+        "header": "Back up and prepare for loss",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Remote wipe capability for devices"
+        ],
+        "baselinesMissed": [
+          "All account access revoked within 24 hours",
+          "Credentials rotated for shared systems",
+          "Offboarding checklist",
+          "Involuntary departures trigger immediate revocation"
+        ]
+      },
+      {
+        "page": "/awareness/understanding-threat-vectors",
+        "header": null,
+        "coverage": "partial",
+        "baselinesMet": [
+          "General awareness of insider threats"
+        ],
+        "baselinesMissed": [
+          "Specific offboarding procedures",
+          "Account revocation timeline",
+          "Credential rotation",
+          "Device return and sanitization",
+          "Offboarding checklist"
+        ]
+      },
+      {
+        "page": "/guides/account_management/discord",
+        "header": "Regular Reviews",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Remove unnecessary role members"
+        ],
+        "baselinesMissed": [
+          "24-hour revocation timeline",
+          "Device return",
+          "Credential rotation",
+          "Comprehensive offboarding checklist",
+          "Involuntary departure procedures"
+        ]
+      }
+    ],
+    "gaps": [
+      "All account access revoked within 24 hours of departure",
+      "Devices returned and verified for data sanitization",
+      "Credentials and secrets rotated for any shared systems the departing person accessed",
+      "Offboarding checklist documented covering: account deprovisioning, device return, credential rotation, access to organizational repositories and tools, recovery of company property",
+      "Involuntary departures trigger immediate access revocation before notification where feasible"
+    ]
+  },
+  {
+    "controlId": "ws-6.1.3",
+    "controlTitle": "Security Awareness and Training",
+    "refs": [
+      {
+        "page": "/awareness/staying-informed-and-continuous-learning",
+        "header": "Comprehensive Security Training Framework",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Training covers phishing, social engineering, device security, credential hygiene, incident reporting",
+          "Training content updated annually",
+          "Crypto-specific risks covered (fake job offers, malicious extensions, clipboard hijacking, social engineering via DMs)"
+        ],
+        "baselinesMissed": [
+          "Phishing simulations conducted quarterly",
+          "Follow-up training for those who fail simulations"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/people",
+        "header": "Security Training & Culture",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Comprehensive security awareness program",
+          "Role-specific training",
+          "Continuous learning about emerging threats"
+        ],
+        "baselinesMissed": [
+          "Phishing simulations quarterly",
+          "Follow-up training for failures",
+          "Crypto-specific risks detail"
+        ]
+      },
+      {
+        "page": "/opsec/appendices/case-studies",
+        "header": null,
+        "coverage": "partial",
+        "baselinesMet": [
+          "Real-world scenarios for training",
+          "Tabletop exercises"
+        ],
+        "baselinesMissed": [
+          "Regular phishing simulations",
+          "Follow-up training process",
+          "Training content update schedule",
+          "Crypto-specific risks coverage"
+        ]
+      }
+    ],
+    "gaps": [
+      "Phishing simulations conducted at least quarterly",
+      "Follow-up training required for personnel who fail simulations"
+    ]
+  },
+  {
+    "controlId": "ws-7.1.1",
+    "controlTitle": "Workspace Security Monitoring and Incident Response",
+    "refs": [
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "header": "Continuous Visibility",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Multi-layered monitoring strategy",
+          "Regular testing cadence",
+          "Structured incident management process",
+          "Post-incident reviews"
+        ],
+        "baselinesMissed": [
+          "Monitoring for workspace-specific threats (account takeovers, unauthorized access, credential leaks, device compromise, data exfiltration)",
+          "Response procedures for workspace scenarios",
+          "Credential leak monitoring"
+        ]
+      },
+      {
+        "page": "/opsec/appendices/case-studies",
+        "header": "Tabletop Exercises",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Incident response scenarios and procedures",
+          "Tabletop exercises for testing"
+        ],
+        "baselinesMissed": [
+          "Ongoing monitoring in place",
+          "Credential leak monitoring",
+          "Documented procedures for specific workspace scenarios"
+        ]
+      }
+    ],
+    "gaps": [
+      "Monitoring in place for common workspace threats: account takeovers, unauthorized access, credential leaks, device compromise, data exfiltration",
+      "Response procedures documented for key scenarios: compromised account, compromised device, data leak, insider threat event",
+      "Credential leak monitoring (dark web, breach databases, paste sites, code repositories)"
+    ]
+  },
+  {
+    "controlId": "ws-7.1.2",
+    "controlTitle": "Insider Threat Assessment",
+    "refs": [
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "header": "Minimal Access Scopes",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Least-privilege access enforced"
+        ],
+        "baselinesMissed": [
+          "Damage scenarios documented for each role",
+          "Separation of duties for critical operations",
+          "Assessed during access reviews"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/people",
+        "header": "Insider-Threat Mitigation",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Least-privilege access enforced across all systems",
+          "Monitoring for critical systems and sensitive data access",
+          "Guidelines for identifying concerning behaviors"
+        ],
+        "baselinesMissed": [
+          "Damage scenarios documented for each role not explicitly covered",
+          "Separation of duties applied for critical operations not detailed"
+        ]
+      }
+    ],
+    "gaps": [
+      "Damage scenarios documented for each role (what could this person do if compromised or malicious?)",
+      "Separation of duties applied for critical operations (no single person can deploy to production, execute large transactions, and manage access controls)"
+    ]
+  },
+  {
+    "controlId": "ws-7.1.3",
+    "controlTitle": "Third-Party Access Management",
+    "refs": [
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "header": "Minimal Access Scopes",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Just-in-time access for administrative functions",
+          "Time-based restrictions to elevated privileges"
+        ],
+        "baselinesMissed": [
+          "Third-party access requires documented approval with scope and expiry",
+          "Access limited to minimum necessary systems",
+          "Automatic revocation upon contract expiry",
+          "Audit trails for third-party access",
+          "Vendor security evaluation"
+        ]
+      },
+      {
+        "page": "/guides/account_management/discord",
+        "header": "Integrations",
+        "coverage": "partial",
+        "baselinesMet": [
+          "Review bot permissions and remove unnecessary",
+          "Least privilege for integrations"
+        ],
+        "baselinesMissed": [
+          "Documented approval with scope and expiry",
+          "Automatic revocation upon contract end",
+          "Audit trails",
+          "Vendor security evaluation before granting access"
+        ]
+      }
+    ],
+    "gaps": [
+      "Third-party access requires documented approval with defined scope and expiry date",
+      "Access limited to minimum necessary systems and data",
+      "Access revoked automatically upon contract expiry or project completion",
+      "Audit trails maintained for all third-party access",
+      "Third-party vendor security evaluated before granting access (security certifications, incident history)"
+    ]
+  }
+]
\ No newline at end of file
diff --git a/scripts/data/framework-pages.json b/scripts/data/framework-pages.json
new file mode 100644
index 00000000..dc4cda3b
--- /dev/null
+++ b/scripts/data/framework-pages.json
@@ -0,0 +1,10138 @@
+[
+  {
+    "path": "/awareness/core-awareness-principles",
+    "title": "Core Awareness Principles",
+    "domain": "awareness",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Key concepts",
+        "anchor": "key-concepts"
+      }
+    ],
+    "lineCount": 68
+  },
+  {
+    "path": "/awareness/cultivating-a-security-aware-mindset",
+    "title": "Cultivating A Security Aware Mindset | SEAL",
+    "domain": "awareness",
+    "headers": [
+      {
+        "level": 2,
+        "text": "3.1. Behavioral Best Practices",
+        "anchor": "31-behavioral-best-practices"
+      },
+      {
+        "level": 3,
+        "text": "Practical Tips",
+        "anchor": "practical-tips"
+      },
+      {
+        "level": 2,
+        "text": "3.2 Awareness in Community Settings",
+        "anchor": "32-awareness-in-community-settings"
+      },
+      {
+        "level": 3,
+        "text": "Unique Challenges on Social Platforms",
+        "anchor": "unique-challenges-on-social-platforms"
+      },
+      {
+        "level": 2,
+        "text": "3.3 Organizational Strategies for Security Culture",
+        "anchor": "33-organizational-strategies-for-security-culture"
+      },
+      {
+        "level": 2,
+        "text": "3.4 Essential Security Practices",
+        "anchor": "34-essential-security-practices"
+      },
+      {
+        "level": 3,
+        "text": "3.4.1. Password Management",
+        "anchor": "341-password-management"
+      },
+      {
+        "level": 3,
+        "text": "3.4.2. Multi-Factor Authentication (MFA)",
+        "anchor": "342-multi-factor-authentication-mfa"
+      },
+      {
+        "level": 3,
+        "text": "3.4.3. Secure Communication",
+        "anchor": "343-secure-communication"
+      },
+      {
+        "level": 3,
+        "text": "3.4.4. Device Security",
+        "anchor": "344-device-security"
+      },
+      {
+        "level": 2,
+        "text": "3.5. Incident Response Awareness",
+        "anchor": "35-incident-response-awareness"
+      },
+      {
+        "level": 3,
+        "text": "3.5.1. Recognizing Security Incidents",
+        "anchor": "351-recognizing-security-incidents"
+      },
+      {
+        "level": 3,
+        "text": "3.5.2. Reporting Procedures",
+        "anchor": "352-reporting-procedures"
+      }
+    ],
+    "lineCount": 212
+  },
+  {
+    "path": "/awareness/overview",
+    "title": "Security Awareness",
+    "domain": "awareness",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Introduction & Objectives",
+        "anchor": "introduction-objectives"
+      },
+      {
+        "level": 3,
+        "text": "Objectives",
+        "anchor": "objectives"
+      },
+      {
+        "level": 2,
+        "text": "Contents",
+        "anchor": "contents"
+      }
+    ],
+    "lineCount": 69
+  },
+  {
+    "path": "/awareness/resources-and-further-reading",
+    "title": "Security Resources & Further Reading | SEAL",
+    "domain": "awareness",
+    "headers": [
+      {
+        "level": 2,
+        "text": "5.1. Additional Learning Materials",
+        "anchor": "51-additional-learning-materials"
+      },
+      {
+        "level": 2,
+        "text": "5.2. Recommended Security Newsletters",
+        "anchor": "52-recommended-security-newsletters"
+      },
+      {
+        "level": 2,
+        "text": "5.3. Security Podcasts and Media",
+        "anchor": "53-security-podcasts-and-media"
+      },
+      {
+        "level": 2,
+        "text": "5.4. Security Training Resources",
+        "anchor": "54-security-training-resources"
+      },
+      {
+        "level": 2,
+        "text": "5.5. Web3-Specific Security Resources",
+        "anchor": "55-web3-specific-security-resources"
+      },
+      {
+        "level": 2,
+        "text": "5.6. Web3 Security Tools",
+        "anchor": "56-web3-security-tools"
+      },
+      {
+        "level": 2,
+        "text": "5.7. Security Tools and Services",
+        "anchor": "57-security-tools-and-services"
+      }
+    ],
+    "lineCount": 128
+  },
+  {
+    "path": "/awareness/staying-informed-and-continuous-learning",
+    "title": "Staying Informed And Continuous Learning | SEAL",
+    "domain": "awareness",
+    "headers": [
+      {
+        "level": 2,
+        "text": "4.1. Comprehensive Security Training Framework",
+        "anchor": "41-comprehensive-security-training-framework"
+      },
+      {
+        "level": 3,
+        "text": "4.1.1. Training Approaches",
+        "anchor": "411-training-approaches"
+      },
+      {
+        "level": 3,
+        "text": "4.1.2. Training Delivery",
+        "anchor": "412-training-delivery"
+      },
+      {
+        "level": 3,
+        "text": "4.1.3. Measuring Training Effectiveness",
+        "anchor": "413-measuring-training-effectiveness"
+      },
+      {
+        "level": 2,
+        "text": "4.2. Essential Training Topics",
+        "anchor": "42-essential-training-topics"
+      },
+      {
+        "level": 2,
+        "text": "4.3. Trusted Information Sources",
+        "anchor": "43-trusted-information-sources"
+      },
+      {
+        "level": 3,
+        "text": "4.3.1. Security Newsletters",
+        "anchor": "431-security-newsletters"
+      },
+      {
+        "level": 3,
+        "text": "4.3.2. Security Communities",
+        "anchor": "432-security-communities"
+      },
+      {
+        "level": 3,
+        "text": "4.3.3. Security Blogs and Podcasts",
+        "anchor": "433-security-blogs-and-podcasts"
+      },
+      {
+        "level": 2,
+        "text": "4.4. Implementing a Learning Culture",
+        "anchor": "44-implementing-a-learning-culture"
+      }
+    ],
+    "lineCount": 193
+  },
+  {
+    "path": "/awareness/understanding-threat-vectors",
+    "title": "Understanding Threat Vectors",
+    "domain": "awareness",
+    "headers": [
+      {
+        "level": 2,
+        "text": "2.1. Traditional Attack Vectors",
+        "anchor": "21-traditional-attack-vectors"
+      },
+      {
+        "level": 3,
+        "text": "2.1.1. Social Engineering & Phishing",
+        "anchor": "211-social-engineering-phishing"
+      },
+      {
+        "level": 3,
+        "text": "2.1.2. Malware & Technical Attacks",
+        "anchor": "212-malware-technical-attacks"
+      },
+      {
+        "level": 2,
+        "text": "2.2. Web3-Specific Threats",
+        "anchor": "22-web3-specific-threats"
+      },
+      {
+        "level": 3,
+        "text": "2.2.1. Crypto-Focused Attacks",
+        "anchor": "221-crypto-focused-attacks"
+      },
+      {
+        "level": 3,
+        "text": "2.2.2. Smart Contract Vulnerabilities",
+        "anchor": "222-smart-contract-vulnerabilities"
+      },
+      {
+        "level": 2,
+        "text": "2.3. Common Indicators & Red Flags",
+        "anchor": "23-common-indicators-red-flags"
+      },
+      {
+        "level": 3,
+        "text": "2.3.1. Behavioral Cues",
+        "anchor": "231-behavioral-cues"
+      },
+      {
+        "level": 3,
+        "text": "2.3.2. Technical Indicators",
+        "anchor": "232-technical-indicators"
+      },
+      {
+        "level": 3,
+        "text": "2.3.3. Checklist for Suspicious Communications",
+        "anchor": "233-checklist-for-suspicious-communications"
+      },
+      {
+        "level": 2,
+        "text": "2.4. Preventive Measures",
+        "anchor": "24-preventive-measures"
+      },
+      {
+        "level": 3,
+        "text": "2.4.1. General Security Practices",
+        "anchor": "241-general-security-practices"
+      },
+      {
+        "level": 3,
+        "text": "2.4.2. Web3-Specific Protections",
+        "anchor": "242-web3-specific-protections"
+      }
+    ],
+    "lineCount": 215
+  },
+  {
+    "path": "/community-management/discord",
+    "title": "Discord Security",
+    "domain": "community-management",
+    "headers": [],
+    "lineCount": 27
+  },
+  {
+    "path": "/community-management/overview",
+    "title": "Community Management",
+    "domain": "community-management",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Best Practices for Community Security",
+        "anchor": "best-practices-for-community-security"
+      },
+      {
+        "level": 3,
+        "text": "Strong Passwords and Two-Factor Authentication (2FA)",
+        "anchor": "strong-passwords-and-two-factor-authentication-2fa"
+      },
+      {
+        "level": 3,
+        "text": "Phishing Awareness",
+        "anchor": "phishing-awareness"
+      },
+      {
+        "level": 3,
+        "text": "Operational Security (OpSec)",
+        "anchor": "operational-security-opsec"
+      },
+      {
+        "level": 3,
+        "text": "Emergency Response Plan",
+        "anchor": "emergency-response-plan"
+      }
+    ],
+    "lineCount": 89
+  },
+  {
+    "path": "/community-management/telegram",
+    "title": "Telegram Security",
+    "domain": "community-management",
+    "headers": [],
+    "lineCount": 24
+  },
+  {
+    "path": "/community-management/twitter",
+    "title": "Twitter/X Security",
+    "domain": "community-management",
+    "headers": [],
+    "lineCount": 24
+  },
+  {
+    "path": "/contribute/champions",
+    "title": "",
+    "domain": "contribute",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/contribute/contributing",
+    "title": "Contributing Guide",
+    "domain": "contribute",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Live versions",
+        "anchor": "live-versions"
+      },
+      {
+        "level": 2,
+        "text": "Ways to contribute",
+        "anchor": "ways-to-contribute"
+      },
+      {
+        "level": 3,
+        "text": "1. Quick edits",
+        "anchor": "1-quick-edits"
+      },
+      {
+        "level": 3,
+        "text": "2. Add a new section or expand an existing one",
+        "anchor": "2-add-a-new-section-or-expand-an-existing-one"
+      },
+      {
+        "level": 2,
+        "text": "Development environment setup",
+        "anchor": "development-environment-setup"
+      },
+      {
+        "level": 3,
+        "text": "Option A: DevContainer with VSCode",
+        "anchor": "option-a-devcontainer-with-vscode"
+      },
+      {
+        "level": 3,
+        "text": "Option B: DevContainer CLI Only (No VSCode Required)",
+        "anchor": "option-b-devcontainer-cli-only-no-vscode-required"
+      },
+      {
+        "level": 3,
+        "text": "Option C: Local installation",
+        "anchor": "option-c-local-installation"
+      },
+      {
+        "level": 2,
+        "text": "Fixing unsigned commits",
+        "anchor": "fixing-unsigned-commits"
+      },
+      {
+        "level": 3,
+        "text": "1. Rebase your recent commits",
+        "anchor": "1-rebase-your-recent-commits"
+      },
+      {
+        "level": 3,
+        "text": "2. Mark commits to fix",
+        "anchor": "2-mark-commits-to-fix"
+      },
+      {
+        "level": 3,
+        "text": "3. Re-sign each commit",
+        "anchor": "3-re-sign-each-commit"
+      },
+      {
+        "level": 3,
+        "text": "4. Push your changes",
+        "anchor": "4-push-your-changes"
+      },
+      {
+        "level": 3,
+        "text": "5. Verify",
+        "anchor": "5-verify"
+      },
+      {
+        "level": 2,
+        "text": "Contributor tasks beyond content changes",
+        "anchor": "contributor-tasks-beyond-content-changes"
+      },
+      {
+        "level": 3,
+        "text": "1. Frontmatter",
+        "anchor": "1-frontmatter"
+      },
+      {
+        "level": 3,
+        "text": "3. Sidebar / Navigation",
+        "anchor": "3-sidebar-navigation"
+      },
+      {
+        "level": 3,
+        "text": "4. Error Checking",
+        "anchor": "4-error-checking"
+      },
+      {
+        "level": 2,
+        "text": "Style guide",
+        "anchor": "style-guide"
+      },
+      {
+        "level": 3,
+        "text": "Writing guidelines",
+        "anchor": "writing-guidelines"
+      },
+      {
+        "level": 3,
+        "text": "Content standardization",
+        "anchor": "content-standardization"
+      },
+      {
+        "level": 3,
+        "text": "Visual representation / drawings",
+        "anchor": "visual-representation-drawings"
+      },
+      {
+        "level": 3,
+        "text": "Linking resources",
+        "anchor": "linking-resources"
+      },
+      {
+        "level": 3,
+        "text": "In-page notices",
+        "anchor": "in-page-notices"
+      },
+      {
+        "level": 2,
+        "text": "Anything else?",
+        "anchor": "anything-else"
+      },
+      {
+        "level": 2,
+        "text": "About this page",
+        "anchor": "about-this-page"
+      }
+    ],
+    "lineCount": 402
+  },
+  {
+    "path": "/contribute/spotlight-zone",
+    "title": "Spotlight Zone",
+    "domain": "contribute",
+    "headers": [],
+    "lineCount": 22
+  },
+  {
+    "path": "/contribute/stewards",
+    "title": "Becoming a Framework Steward",
+    "domain": "contribute",
+    "headers": [
+      {
+        "level": 2,
+        "text": "What is a Framework Steward?",
+        "anchor": "what-is-a-framework-steward"
+      },
+      {
+        "level": 2,
+        "text": "The Steward's Role",
+        "anchor": "the-stewards-role"
+      },
+      {
+        "level": 2,
+        "text": "Why Become a Steward?",
+        "anchor": "why-become-a-steward"
+      },
+      {
+        "level": 3,
+        "text": "Recognition and Growth",
+        "anchor": "recognition-and-growth"
+      },
+      {
+        "level": 3,
+        "text": "Tangible Benefits",
+        "anchor": "tangible-benefits"
+      },
+      {
+        "level": 3,
+        "text": "Lasting Impact",
+        "anchor": "lasting-impact"
+      },
+      {
+        "level": 2,
+        "text": "Stewardship in Action: What It Looks Like",
+        "anchor": "stewardship-in-action-what-it-looks-like"
+      },
+      {
+        "level": 3,
+        "text": "Time Commitment",
+        "anchor": "time-commitment"
+      },
+      {
+        "level": 3,
+        "text": "Support Structure",
+        "anchor": "support-structure"
+      },
+      {
+        "level": 2,
+        "text": "How to Apply",
+        "anchor": "how-to-apply"
+      },
+      {
+        "level": 2,
+        "text": "Join Us in Building a Safer Web3",
+        "anchor": "join-us-in-building-a-safer-web3"
+      }
+    ],
+    "lineCount": 107
+  },
+  {
+    "path": "/devsecops/code-signing",
+    "title": "Implementing Code Signing",
+    "domain": "devsecops",
+    "headers": [],
+    "lineCount": 35
+  },
+  {
+    "path": "/devsecops/continuous-integration-continuous-deployment",
+    "title": "Securing CI/CD Pipelines | SEAL",
+    "domain": "devsecops",
+    "headers": [],
+    "lineCount": 37
+  },
+  {
+    "path": "/devsecops/integrated-development-environments",
+    "title": "Securing Development Environments | SEAL",
+    "domain": "devsecops",
+    "headers": [],
+    "lineCount": 34
+  },
+  {
+    "path": "/devsecops/overview",
+    "title": "DevSecOps",
+    "domain": "devsecops",
+    "headers": [],
+    "lineCount": 42
+  },
+  {
+    "path": "/devsecops/repository-hardening",
+    "title": "Repository Hardening",
+    "domain": "devsecops",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Configuration Checklists",
+        "anchor": "configuration-checklists"
+      }
+    ],
+    "lineCount": 44
+  },
+  {
+    "path": "/devsecops/security-testing",
+    "title": "Security Testing",
+    "domain": "devsecops",
+    "headers": [],
+    "lineCount": 33
+  },
+  {
+    "path": "/dprk-it-workers/case-studies",
+    "title": "DPRK IT Worker Case Studies | SEAL",
+    "domain": "dprk-it-workers",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Story 1",
+        "anchor": "story-1"
+      },
+      {
+        "level": 2,
+        "text": "Story 2",
+        "anchor": "story-2"
+      },
+      {
+        "level": 2,
+        "text": "Story 3",
+        "anchor": "story-3"
+      }
+    ],
+    "lineCount": 83
+  },
+  {
+    "path": "/dprk-it-workers/general-information",
+    "title": "DPRK IT Workers Overview",
+    "domain": "dprk-it-workers",
+    "headers": [
+      {
+        "level": 2,
+        "text": "What is an insider threat? Who are DPRK IT Workers?",
+        "anchor": "what-is-an-insider-threat-who-are-dprk-it-workers"
+      },
+      {
+        "level": 2,
+        "text": "Operational structure and short history of DPRK IT Workers",
+        "anchor": "operational-structure-and-short-history-of-dprk-it-workers"
+      },
+      {
+        "level": 2,
+        "text": "What are the goals of DPRK IT Workers?",
+        "anchor": "what-are-the-goals-of-dprk-it-workers"
+      },
+      {
+        "level": 2,
+        "text": "How many DPRK IT Workers are there?",
+        "anchor": "how-many-dprk-it-workers-are-there"
+      },
+      {
+        "level": 2,
+        "text": "Average DPRK IT Worker Profile",
+        "anchor": "average-dprk-it-worker-profile"
+      }
+    ],
+    "lineCount": 126
+  },
+  {
+    "path": "/dprk-it-workers/mitigating-dprk-it-workers",
+    "title": "Mitigating DPRK IT Worker Threats | SEAL",
+    "domain": "dprk-it-workers",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Hardening your hiring processes",
+        "anchor": "hardening-your-hiring-processes"
+      },
+      {
+        "level": 2,
+        "text": "Hardening your organization",
+        "anchor": "hardening-your-organization"
+      },
+      {
+        "level": 2,
+        "text": "I hired a DPRK IT Worker. What now?",
+        "anchor": "i-hired-a-dprk-it-worker-what-now"
+      },
+      {
+        "level": 2,
+        "text": "Data collection",
+        "anchor": "data-collection"
+      },
+      {
+        "level": 2,
+        "text": "Overview of risks to your organization",
+        "anchor": "overview-of-risks-to-your-organization"
+      }
+    ],
+    "lineCount": 181
+  },
+  {
+    "path": "/dprk-it-workers/overview",
+    "title": "Insider Threats (DPRK)",
+    "domain": "dprk-it-workers",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Table of Contents",
+        "anchor": "table-of-contents"
+      },
+      {
+        "level": 3,
+        "text": "Overview of risks to your organization",
+        "anchor": "overview-of-risks-to-your-organization"
+      }
+    ],
+    "lineCount": 95
+  },
+  {
+    "path": "/dprk-it-workers/summary",
+    "title": "DPRK IT Workers Summary",
+    "domain": "dprk-it-workers",
+    "headers": [],
+    "lineCount": 78
+  },
+  {
+    "path": "/dprk-it-workers/techniques-tactics-and-procedures",
+    "title": "DPRK IT Worker TTPs",
+    "domain": "dprk-it-workers",
+    "headers": [
+      {
+        "level": 2,
+        "text": "How can DPRK IT Workers find a job in your company?",
+        "anchor": "how-can-dprk-it-workers-find-a-job-in-your-company"
+      },
+      {
+        "level": 2,
+        "text": "Am I Interviewing a DPRK IT Worker?",
+        "anchor": "am-i-interviewing-a-dprk-it-worker"
+      },
+      {
+        "level": 2,
+        "text": "Did I hire a DPRK IT Worker?",
+        "anchor": "did-i-hire-a-dprk-it-worker"
+      },
+      {
+        "level": 2,
+        "text": "After a DPRK IT Worker is hired by your company:",
+        "anchor": "after-a-dprk-it-worker-is-hired-by-your-company"
+      }
+    ],
+    "lineCount": 326
+  },
+  {
+    "path": "/encryption/cloud-data-encryption",
+    "title": "Cloud Data Encryption",
+    "domain": "encryption",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Best Practices",
+        "anchor": "best-practices"
+      }
+    ],
+    "lineCount": 80
+  },
+  {
+    "path": "/encryption/communication-encryption",
+    "title": "Securing Communications",
+    "domain": "encryption",
+    "headers": [
+      {
+        "level": 2,
+        "text": "End-to-End Encrypted Messaging Systems",
+        "anchor": "end-to-end-encrypted-messaging-systems"
+      },
+      {
+        "level": 2,
+        "text": "Messaging Systems Without Default End-to-End Encryption",
+        "anchor": "messaging-systems-without-default-end-to-end-encryption"
+      }
+    ],
+    "lineCount": 75
+  },
+  {
+    "path": "/encryption/database-encryption",
+    "title": "Database Encryption",
+    "domain": "encryption",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Best Practices",
+        "anchor": "best-practices"
+      }
+    ],
+    "lineCount": 35
+  },
+  {
+    "path": "/encryption/email-encryption",
+    "title": "Email Encryption",
+    "domain": "encryption",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Best Practices",
+        "anchor": "best-practices"
+      }
+    ],
+    "lineCount": 74
+  },
+  {
+    "path": "/encryption/encryption-in-transit",
+    "title": "Encryption In Transit",
+    "domain": "encryption",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Best Practices",
+        "anchor": "best-practices"
+      }
+    ],
+    "lineCount": 34
+  },
+  {
+    "path": "/encryption/file-encryption",
+    "title": "File Encryption",
+    "domain": "encryption",
+    "headers": [],
+    "lineCount": 28
+  },
+  {
+    "path": "/encryption/full-disk-encryption",
+    "title": "Full Disk Encryption",
+    "domain": "encryption",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Best Practices",
+        "anchor": "best-practices"
+      }
+    ],
+    "lineCount": 34
+  },
+  {
+    "path": "/encryption/hardware-encryption",
+    "title": "Hardware Encryption",
+    "domain": "encryption",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Best Practices",
+        "anchor": "best-practices"
+      }
+    ],
+    "lineCount": 32
+  },
+  {
+    "path": "/encryption/overview",
+    "title": "Encryption",
+    "domain": "encryption",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Contents",
+        "anchor": "contents"
+      }
+    ],
+    "lineCount": 40
+  },
+  {
+    "path": "/encryption/partition-encryption",
+    "title": "Partition Encryption",
+    "domain": "encryption",
+    "headers": [
+      {
+        "level": 2,
+        "text": "What is Partition Encryption?",
+        "anchor": "what-is-partition-encryption"
+      },
+      {
+        "level": 2,
+        "text": "Importance of Partition Encryption",
+        "anchor": "importance-of-partition-encryption"
+      },
+      {
+        "level": 2,
+        "text": "Uses of Partition Encryption",
+        "anchor": "uses-of-partition-encryption"
+      },
+      {
+        "level": 2,
+        "text": "Examples of Partition Encryption",
+        "anchor": "examples-of-partition-encryption"
+      },
+      {
+        "level": 2,
+        "text": "Best Practices for Partition Encryption",
+        "anchor": "best-practices-for-partition-encryption"
+      }
+    ],
+    "lineCount": 71
+  },
+  {
+    "path": "/encryption/volume-encryption",
+    "title": "Volume Encryption",
+    "domain": "encryption",
+    "headers": [
+      {
+        "level": 2,
+        "text": "What is Volume Encryption?",
+        "anchor": "what-is-volume-encryption"
+      },
+      {
+        "level": 2,
+        "text": "Importance of Volume Encryption",
+        "anchor": "importance-of-volume-encryption"
+      },
+      {
+        "level": 2,
+        "text": "Uses of Volume Encryption",
+        "anchor": "uses-of-volume-encryption"
+      },
+      {
+        "level": 2,
+        "text": "Examples of Volume Encryption",
+        "anchor": "examples-of-volume-encryption"
+      },
+      {
+        "level": 2,
+        "text": "Known Technologies for Volume Encryption",
+        "anchor": "known-technologies-for-volume-encryption"
+      },
+      {
+        "level": 2,
+        "text": "Best Practices for Volume Encryption",
+        "anchor": "best-practices-for-volume-encryption"
+      }
+    ],
+    "lineCount": 76
+  },
+  {
+    "path": "/ens/cross-chain-compatibility",
+    "title": "ENS Cross Chain Compatibility | SEAL",
+    "domain": "ens",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Respect Cointype for [Chain-Specific Resolution](https://docs.ens.domains/ensip/9)",
+        "anchor": "respect-cointype-for-chain-specific-resolutionhttpsdocsensdomainsensip9"
+      },
+      {
+        "level": 2,
+        "text": "Implement CCIP-Read Support",
+        "anchor": "implement-ccip-read-support"
+      },
+      {
+        "level": 2,
+        "text": "Test Multi-Chain Implementations",
+        "anchor": "test-multi-chain-implementations"
+      },
+      {
+        "level": 2,
+        "text": "Handle Reverse Records Per Chain",
+        "anchor": "handle-reverse-records-per-chain"
+      }
+    ],
+    "lineCount": 72
+  },
+  {
+    "path": "/ens/data-integrity-verification",
+    "title": "ENS Data Integrity Verification | SEAL",
+    "domain": "ens",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Use On-chain Resolution for Financial Transactions",
+        "anchor": "use-on-chain-resolution-for-financial-transactions"
+      },
+      {
+        "level": 2,
+        "text": "Verify Forward Resolution on [Reverse Records](https://docs.ens.domains/ensip/3)",
+        "anchor": "verify-forward-resolution-on-reverse-recordshttpsdocsensdomainsensip3"
+      }
+    ],
+    "lineCount": 50
+  },
+  {
+    "path": "/ens/interface-compliance",
+    "title": "ENS Interface Compliance",
+    "domain": "ens",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Verify Resolver Interface Support",
+        "anchor": "verify-resolver-interface-support"
+      },
+      {
+        "level": 2,
+        "text": "Signal Supported Interfaces in Custom Resolvers",
+        "anchor": "signal-supported-interfaces-in-custom-resolvers"
+      },
+      {
+        "level": 2,
+        "text": "Stay Updated with ENS Improvement Proposals (ENSIPs)",
+        "anchor": "stay-updated-with-ens-improvement-proposals-ensips"
+      }
+    ],
+    "lineCount": 67
+  },
+  {
+    "path": "/ens/name-handling-normalization",
+    "title": "ENS Name Handling & Normalization | SEAL",
+    "domain": "ens",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Normalize Names per [ENSIP-15](https://docs.ens.domains/ensip/15)",
+        "anchor": "normalize-names-per-ensip-15httpsdocsensdomainsensip15"
+      },
+      {
+        "level": 2,
+        "text": "Implement Security Measures for Homograph Attacks",
+        "anchor": "implement-security-measures-for-homograph-attacks"
+      },
+      {
+        "level": 2,
+        "text": "Properly Handle Emoji in ENS Names",
+        "anchor": "properly-handle-emoji-in-ens-names"
+      }
+    ],
+    "lineCount": 68
+  },
+  {
+    "path": "/ens/overview",
+    "title": "ENS Best Practices",
+    "domain": "ens",
+    "headers": [
+      {
+        "level": 2,
+        "text": "What This Framework Covers",
+        "anchor": "what-this-framework-covers"
+      }
+    ],
+    "lineCount": 53
+  },
+  {
+    "path": "/ens/smart-contract-integration",
+    "title": "ENS Smart Contract Integration | SEAL",
+    "domain": "ens",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Name Your Smart Contracts",
+        "anchor": "name-your-smart-contracts"
+      },
+      {
+        "level": 2,
+        "text": "Leverage ENS as an Infrastructure Component",
+        "anchor": "leverage-ens-as-an-infrastructure-component"
+      }
+    ],
+    "lineCount": 55
+  },
+  {
+    "path": "/external-security-reviews/overview",
+    "title": "External Security Reviews",
+    "domain": "external-security-reviews",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Why Are External Security Reviews Important?",
+        "anchor": "why-are-external-security-reviews-important"
+      },
+      {
+        "level": 2,
+        "text": "Scope of External Security Reviews",
+        "anchor": "scope-of-external-security-reviews"
+      },
+      {
+        "level": 2,
+        "text": "Contents",
+        "anchor": "contents"
+      }
+    ],
+    "lineCount": 65
+  },
+  {
+    "path": "/external-security-reviews/security-policies-procedures",
+    "title": "Security Policies & Procedures | SEAL",
+    "domain": "external-security-reviews",
+    "headers": [],
+    "lineCount": 38
+  },
+  {
+    "path": "/external-security-reviews/smart-contracts/expectation",
+    "title": "What to Expect from a Smart Contract Audit | SEAL",
+    "domain": "external-security-reviews",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Scoping Phase",
+        "anchor": "scoping-phase"
+      },
+      {
+        "level": 2,
+        "text": "Initial Assessment Phase",
+        "anchor": "initial-assessment-phase"
+      },
+      {
+        "level": 2,
+        "text": "Deliverables",
+        "anchor": "deliverables"
+      },
+      {
+        "level": 3,
+        "text": "Initial Report",
+        "anchor": "initial-report"
+      },
+      {
+        "level": 3,
+        "text": "Mitigation Phase",
+        "anchor": "mitigation-phase"
+      },
+      {
+        "level": 3,
+        "text": "Final Report",
+        "anchor": "final-report"
+      },
+      {
+        "level": 2,
+        "text": "Timeline and Cost Expectations",
+        "anchor": "timeline-and-cost-expectations"
+      },
+      {
+        "level": 3,
+        "text": "Duration",
+        "anchor": "duration"
+      },
+      {
+        "level": 3,
+        "text": "Cost Range",
+        "anchor": "cost-range"
+      },
+      {
+        "level": 2,
+        "text": "Important Limitations",
+        "anchor": "important-limitations"
+      }
+    ],
+    "lineCount": 92
+  },
+  {
+    "path": "/external-security-reviews/smart-contracts/manual-review",
+    "title": "Smart Contract Manual Code Review",
+    "domain": "external-security-reviews",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Gather resources",
+        "anchor": "gather-resources"
+      },
+      {
+        "level": 2,
+        "text": "Smart contract higher overview",
+        "anchor": "smart-contract-higher-overview"
+      },
+      {
+        "level": 2,
+        "text": "Manual review",
+        "anchor": "manual-review"
+      },
+      {
+        "level": 2,
+        "text": "Functional testing",
+        "anchor": "functional-testing"
+      },
+      {
+        "level": 2,
+        "text": "Automated review",
+        "anchor": "automated-review"
+      },
+      {
+        "level": 2,
+        "text": "Report writing",
+        "anchor": "report-writing"
+      },
+      {
+        "level": 2,
+        "text": "Updated code review",
+        "anchor": "updated-code-review"
+      },
+      {
+        "level": 2,
+        "text": "Final thoughts",
+        "anchor": "final-thoughts"
+      },
+      {
+        "level": 2,
+        "text": "References",
+        "anchor": "references"
+      }
+    ],
+    "lineCount": 358
+  },
+  {
+    "path": "/external-security-reviews/smart-contracts/overview",
+    "title": "Smart Contract Security Reviews | SEAL",
+    "domain": "external-security-reviews",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Why Smart Contract Security Reviews Are Critical",
+        "anchor": "why-smart-contract-security-reviews-are-critical"
+      },
+      {
+        "level": 2,
+        "text": "Smart Contract Security Review Process",
+        "anchor": "smart-contract-security-review-process"
+      },
+      {
+        "level": 3,
+        "text": "Audit Methodologies",
+        "anchor": "audit-methodologies"
+      },
+      {
+        "level": 2,
+        "text": "Types of Smart Contract Audits",
+        "anchor": "types-of-smart-contract-audits"
+      },
+      {
+        "level": 3,
+        "text": "Private Audits",
+        "anchor": "private-audits"
+      },
+      {
+        "level": 3,
+        "text": "Public/Competitive Audits",
+        "anchor": "publiccompetitive-audits"
+      },
+      {
+        "level": 2,
+        "text": "Contents",
+        "anchor": "contents"
+      }
+    ],
+    "lineCount": 86
+  },
+  {
+    "path": "/external-security-reviews/smart-contracts/preparation",
+    "title": "Preparing for a Smart Contract Audit",
+    "domain": "external-security-reviews",
+    "headers": [
+      {
+        "level": 2,
+        "text": "How to Get the Most Out of Your Security Review",
+        "anchor": "how-to-get-the-most-out-of-your-security-review"
+      },
+      {
+        "level": 2,
+        "text": "Set a Goal for the Review",
+        "anchor": "set-a-goal-for-the-review"
+      },
+      {
+        "level": 2,
+        "text": "Internal Due Diligence",
+        "anchor": "internal-due-diligence"
+      },
+      {
+        "level": 2,
+        "text": "Write Clear Documentation",
+        "anchor": "write-clear-documentation"
+      },
+      {
+        "level": 2,
+        "text": "Provide a Robust Test Suite",
+        "anchor": "provide-a-robust-test-suite"
+      },
+      {
+        "level": 2,
+        "text": "Conduct an Initial Code Walkthrough",
+        "anchor": "conduct-an-initial-code-walkthrough"
+      }
+    ],
+    "lineCount": 90
+  },
+  {
+    "path": "/external-security-reviews/smart-contracts/vendor-selection",
+    "title": "Selecting a Smart Contract Auditor",
+    "domain": "external-security-reviews",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Types of Security Audits",
+        "anchor": "types-of-security-audits"
+      },
+      {
+        "level": 3,
+        "text": "Private Security Audits",
+        "anchor": "private-security-audits"
+      },
+      {
+        "level": 3,
+        "text": "Public/Competitive Security Audits",
+        "anchor": "publiccompetitive-security-audits"
+      },
+      {
+        "level": 2,
+        "text": "Vendor Selection Criteria",
+        "anchor": "vendor-selection-criteria"
+      },
+      {
+        "level": 3,
+        "text": "1. Track Record and Reputation",
+        "anchor": "1-track-record-and-reputation"
+      },
+      {
+        "level": 3,
+        "text": "2. Domain Expertise",
+        "anchor": "2-domain-expertise"
+      },
+      {
+        "level": 3,
+        "text": "3. Technical Capabilities",
+        "anchor": "3-technical-capabilities"
+      },
+      {
+        "level": 3,
+        "text": "4. Security Methodology",
+        "anchor": "4-security-methodology"
+      },
+      {
+        "level": 2,
+        "text": "Due Diligence Process",
+        "anchor": "due-diligence-process"
+      },
+      {
+        "level": 2,
+        "text": "Red Flags to Avoid",
+        "anchor": "red-flags-to-avoid"
+      }
+    ],
+    "lineCount": 121
+  },
+  {
+    "path": "/front-end-web-app/common-vulnerabilities",
+    "title": "Common Web Vulnerabilities",
+    "domain": "front-end-web-app",
+    "headers": [
+      {
+        "level": 2,
+        "text": "General Vulnerabilities",
+        "anchor": "general-vulnerabilities"
+      },
+      {
+        "level": 2,
+        "text": "Web Application Vulnerabilities",
+        "anchor": "web-application-vulnerabilities"
+      },
+      {
+        "level": 2,
+        "text": "Mobile Application Vulnerabilities",
+        "anchor": "mobile-application-vulnerabilities"
+      }
+    ],
+    "lineCount": 52
+  },
+  {
+    "path": "/front-end-web-app/mobile-application-security",
+    "title": "Mobile Application Security",
+    "domain": "front-end-web-app",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Best Practices",
+        "anchor": "best-practices"
+      }
+    ],
+    "lineCount": 42
+  },
+  {
+    "path": "/front-end-web-app/overview",
+    "title": "Front-End Web Application Security | SEAL",
+    "domain": "front-end-web-app",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Contents",
+        "anchor": "contents"
+      }
+    ],
+    "lineCount": 35
+  },
+  {
+    "path": "/front-end-web-app/security-tools-resources",
+    "title": "Security Tools & Resources",
+    "domain": "front-end-web-app",
+    "headers": [],
+    "lineCount": 37
+  },
+  {
+    "path": "/front-end-web-app/web-application-security",
+    "title": "Web Application Security",
+    "domain": "front-end-web-app",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Best Practices",
+        "anchor": "best-practices"
+      }
+    ],
+    "lineCount": 40
+  },
+  {
+    "path": "/governance/compliance-regulatory-requirements",
+    "title": "Compliance & Regulatory Requirements | SEAL",
+    "domain": "governance",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Key Regulatory Frameworks",
+        "anchor": "key-regulatory-frameworks"
+      },
+      {
+        "level": 2,
+        "text": "Best Practices for Compliance",
+        "anchor": "best-practices-for-compliance"
+      },
+      {
+        "level": 2,
+        "text": "1. Understand Applicable Regulations",
+        "anchor": "1-understand-applicable-regulations"
+      },
+      {
+        "level": 2,
+        "text": "2. Develop a Robust Security Policy Framework",
+        "anchor": "2-develop-a-robust-security-policy-framework"
+      },
+      {
+        "level": 2,
+        "text": "3. Data Protection and Privacy",
+        "anchor": "3-data-protection-and-privacy"
+      },
+      {
+        "level": 2,
+        "text": "4. Access Management and Control",
+        "anchor": "4-access-management-and-control"
+      },
+      {
+        "level": 2,
+        "text": "5. Incident Response Planning",
+        "anchor": "5-incident-response-planning"
+      },
+      {
+        "level": 2,
+        "text": "6. Continuous Monitoring and Auditing",
+        "anchor": "6-continuous-monitoring-and-auditing"
+      },
+      {
+        "level": 2,
+        "text": "7. Employee Training and Awareness",
+        "anchor": "7-employee-training-and-awareness"
+      },
+      {
+        "level": 2,
+        "text": "8. Third-Party Risk Management",
+        "anchor": "8-third-party-risk-management"
+      },
+      {
+        "level": 2,
+        "text": "9. Data Encryption and Secure Communication",
+        "anchor": "9-data-encryption-and-secure-communication"
+      },
+      {
+        "level": 2,
+        "text": "10. Documentation and Record-Keeping",
+        "anchor": "10-documentation-and-record-keeping"
+      }
+    ],
+    "lineCount": 189
+  },
+  {
+    "path": "/governance/overview",
+    "title": "Governance",
+    "domain": "governance",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Contents",
+        "anchor": "contents"
+      }
+    ],
+    "lineCount": 33
+  },
+  {
+    "path": "/governance/risk-management",
+    "title": "Risk Management",
+    "domain": "governance",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Best Practices for Risk Management",
+        "anchor": "best-practices-for-risk-management"
+      }
+    ],
+    "lineCount": 36
+  },
+  {
+    "path": "/governance/security-metrics-kpis",
+    "title": "Security Metrics & KPIs",
+    "domain": "governance",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Key Security Metrics",
+        "anchor": "key-security-metrics"
+      },
+      {
+        "level": 2,
+        "text": "Key Performance Indicators (KPIs)",
+        "anchor": "key-performance-indicators-kpis"
+      }
+    ],
+    "lineCount": 45
+  },
+  {
+    "path": "/guides/account_management/discord",
+    "title": "Discord Security",
+    "domain": "guides",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Summary",
+        "anchor": "summary"
+      },
+      {
+        "level": 2,
+        "text": "For Individuals",
+        "anchor": "for-individuals"
+      },
+      {
+        "level": 3,
+        "text": "Account Security Checklist",
+        "anchor": "account-security-checklist"
+      },
+      {
+        "level": 2,
+        "text": "For Team Members",
+        "anchor": "for-team-members"
+      },
+      {
+        "level": 2,
+        "text": "For Admins",
+        "anchor": "for-admins"
+      },
+      {
+        "level": 3,
+        "text": "Server Settings Checklist",
+        "anchor": "server-settings-checklist"
+      },
+      {
+        "level": 3,
+        "text": "Role Hierarchy Setup",
+        "anchor": "role-hierarchy-setup"
+      },
+      {
+        "level": 3,
+        "text": "Channel Management",
+        "anchor": "channel-management"
+      },
+      {
+        "level": 3,
+        "text": "Member Screening Setup",
+        "anchor": "member-screening-setup"
+      },
+      {
+        "level": 3,
+        "text": "Invite Best Practices",
+        "anchor": "invite-best-practices"
+      },
+      {
+        "level": 3,
+        "text": "Logging Setup",
+        "anchor": "logging-setup"
+      },
+      {
+        "level": 3,
+        "text": "Security Bots",
+        "anchor": "security-bots"
+      },
+      {
+        "level": 3,
+        "text": "Establish Clear Server Rules",
+        "anchor": "establish-clear-server-rules"
+      },
+      {
+        "level": 3,
+        "text": "Regular Reviews",
+        "anchor": "regular-reviews"
+      },
+      {
+        "level": 3,
+        "text": "Cold Admin Accounts",
+        "anchor": "cold-admin-accounts"
+      },
+      {
+        "level": 3,
+        "text": "Backup Systems",
+        "anchor": "backup-systems"
+      },
+      {
+        "level": 3,
+        "text": "Additional Recommendations",
+        "anchor": "additional-recommendations"
+      },
+      {
+        "level": 3,
+        "text": "Stay Updated",
+        "anchor": "stay-updated"
+      },
+      {
+        "level": 2,
+        "text": "Additional Resources",
+        "anchor": "additional-resources"
+      }
+    ],
+    "lineCount": 428
+  },
+  {
+    "path": "/guides/account_management/github",
+    "title": "GitHub Security",
+    "domain": "guides",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Summary",
+        "anchor": "summary"
+      },
+      {
+        "level": 2,
+        "text": "For Individuals",
+        "anchor": "for-individuals"
+      },
+      {
+        "level": 3,
+        "text": "Individual Account Settings",
+        "anchor": "individual-account-settings"
+      },
+      {
+        "level": 2,
+        "text": "For Team Members",
+        "anchor": "for-team-members"
+      },
+      {
+        "level": 2,
+        "text": "For Admins",
+        "anchor": "for-admins"
+      },
+      {
+        "level": 3,
+        "text": "Repository Settings",
+        "anchor": "repository-settings"
+      },
+      {
+        "level": 3,
+        "text": "Organization Settings",
+        "anchor": "organization-settings"
+      },
+      {
+        "level": 2,
+        "text": "Notes",
+        "anchor": "notes"
+      },
+      {
+        "level": 3,
+        "text": "[1] Deploy Keys Warning",
+        "anchor": "1-deploy-keys-warning"
+      },
+      {
+        "level": 3,
+        "text": "[2] Enterprise Features",
+        "anchor": "2-enterprise-features"
+      },
+      {
+        "level": 3,
+        "text": "[3] Audit Logs",
+        "anchor": "3-audit-logs"
+      }
+    ],
+    "lineCount": 227
+  },
+  {
+    "path": "/guides/account_management/godaddy",
+    "title": "GoDaddy Security",
+    "domain": "guides",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Summary",
+        "anchor": "summary"
+      },
+      {
+        "level": 2,
+        "text": "For Individuals",
+        "anchor": "for-individuals"
+      },
+      {
+        "level": 3,
+        "text": "Individual Account Settings",
+        "anchor": "individual-account-settings"
+      },
+      {
+        "level": 2,
+        "text": "For Team Members",
+        "anchor": "for-team-members"
+      },
+      {
+        "level": 2,
+        "text": "For Admins",
+        "anchor": "for-admins"
+      },
+      {
+        "level": 3,
+        "text": "Domain Security",
+        "anchor": "domain-security"
+      },
+      {
+        "level": 3,
+        "text": "Best Practices",
+        "anchor": "best-practices"
+      }
+    ],
+    "lineCount": 78
+  },
+  {
+    "path": "/guides/account_management/linear",
+    "title": "Linear Security",
+    "domain": "guides",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Summary",
+        "anchor": "summary"
+      },
+      {
+        "level": 2,
+        "text": "For Individuals",
+        "anchor": "for-individuals"
+      },
+      {
+        "level": 3,
+        "text": "Individual Account Settings",
+        "anchor": "individual-account-settings"
+      },
+      {
+        "level": 2,
+        "text": "For Team Members",
+        "anchor": "for-team-members"
+      },
+      {
+        "level": 2,
+        "text": "For Admins",
+        "anchor": "for-admins"
+      },
+      {
+        "level": 3,
+        "text": "Admin Settings",
+        "anchor": "admin-settings"
+      }
+    ],
+    "lineCount": 74
+  },
+  {
+    "path": "/guides/account_management/mercury",
+    "title": "Mercury Security",
+    "domain": "guides",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Summary",
+        "anchor": "summary"
+      },
+      {
+        "level": 2,
+        "text": "For Individuals",
+        "anchor": "for-individuals"
+      },
+      {
+        "level": 3,
+        "text": "Account Security Checklist",
+        "anchor": "account-security-checklist"
+      },
+      {
+        "level": 2,
+        "text": "For Team Members",
+        "anchor": "for-team-members"
+      },
+      {
+        "level": 2,
+        "text": "For Admins",
+        "anchor": "for-admins"
+      },
+      {
+        "level": 3,
+        "text": "Company Settings",
+        "anchor": "company-settings"
+      }
+    ],
+    "lineCount": 71
+  },
+  {
+    "path": "/guides/account_management/notion",
+    "title": "Notion Security",
+    "domain": "guides",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Summary",
+        "anchor": "summary"
+      },
+      {
+        "level": 2,
+        "text": "For Individuals",
+        "anchor": "for-individuals"
+      },
+      {
+        "level": 3,
+        "text": "Account Security Checklist",
+        "anchor": "account-security-checklist"
+      },
+      {
+        "level": 2,
+        "text": "For Team Members",
+        "anchor": "for-team-members"
+      },
+      {
+        "level": 2,
+        "text": "For Admins",
+        "anchor": "for-admins"
+      },
+      {
+        "level": 3,
+        "text": "Workspace Settings",
+        "anchor": "workspace-settings"
+      },
+      {
+        "level": 2,
+        "text": "Notes",
+        "anchor": "notes"
+      },
+      {
+        "level": 3,
+        "text": "[1] Enterprise Features",
+        "anchor": "1-enterprise-features"
+      }
+    ],
+    "lineCount": 101
+  },
+  {
+    "path": "/guides/account_management/overview",
+    "title": "Account Management",
+    "domain": "guides",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Communication Platforms",
+        "anchor": "communication-platforms"
+      },
+      {
+        "level": 2,
+        "text": "DevOps & Infrastructure",
+        "anchor": "devops-infrastructure"
+      },
+      {
+        "level": 2,
+        "text": "Business Tools",
+        "anchor": "business-tools"
+      }
+    ],
+    "lineCount": 57
+  },
+  {
+    "path": "/guides/account_management/render",
+    "title": "Render Security",
+    "domain": "guides",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Summary",
+        "anchor": "summary"
+      },
+      {
+        "level": 2,
+        "text": "For Individuals",
+        "anchor": "for-individuals"
+      },
+      {
+        "level": 3,
+        "text": "Account Security Checklist",
+        "anchor": "account-security-checklist"
+      },
+      {
+        "level": 2,
+        "text": "For Team Members",
+        "anchor": "for-team-members"
+      },
+      {
+        "level": 2,
+        "text": "For Admins",
+        "anchor": "for-admins"
+      },
+      {
+        "level": 3,
+        "text": "Workspace Settings",
+        "anchor": "workspace-settings"
+      }
+    ],
+    "lineCount": 68
+  },
+  {
+    "path": "/guides/account_management/sentry",
+    "title": "Sentry Security",
+    "domain": "guides",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Summary",
+        "anchor": "summary"
+      },
+      {
+        "level": 2,
+        "text": "For Individuals",
+        "anchor": "for-individuals"
+      },
+      {
+        "level": 3,
+        "text": "Individual Account Settings",
+        "anchor": "individual-account-settings"
+      },
+      {
+        "level": 2,
+        "text": "For Team Members",
+        "anchor": "for-team-members"
+      },
+      {
+        "level": 2,
+        "text": "For Admins",
+        "anchor": "for-admins"
+      },
+      {
+        "level": 3,
+        "text": "Organization Settings",
+        "anchor": "organization-settings"
+      },
+      {
+        "level": 3,
+        "text": "Developer Settings",
+        "anchor": "developer-settings"
+      }
+    ],
+    "lineCount": 87
+  },
+  {
+    "path": "/guides/account_management/signal",
+    "title": "Signal Security",
+    "domain": "guides",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Summary",
+        "anchor": "summary"
+      },
+      {
+        "level": 2,
+        "text": "For Individuals",
+        "anchor": "for-individuals"
+      },
+      {
+        "level": 3,
+        "text": "Account Security Checklist",
+        "anchor": "account-security-checklist"
+      },
+      {
+        "level": 3,
+        "text": "Best Practices & Additional Tips",
+        "anchor": "best-practices-additional-tips"
+      }
+    ],
+    "lineCount": 69
+  },
+  {
+    "path": "/guides/account_management/slack",
+    "title": "Slack Security",
+    "domain": "guides",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Summary",
+        "anchor": "summary"
+      },
+      {
+        "level": 2,
+        "text": "For Team Members",
+        "anchor": "for-team-members"
+      },
+      {
+        "level": 2,
+        "text": "For Admins",
+        "anchor": "for-admins"
+      },
+      {
+        "level": 3,
+        "text": "Workspace Settings",
+        "anchor": "workspace-settings"
+      },
+      {
+        "level": 3,
+        "text": "Member Management",
+        "anchor": "member-management"
+      },
+      {
+        "level": 3,
+        "text": "Security Settings",
+        "anchor": "security-settings"
+      }
+    ],
+    "lineCount": 74
+  },
+  {
+    "path": "/guides/account_management/telegram",
+    "title": "Telegram Security",
+    "domain": "guides",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Summary",
+        "anchor": "summary"
+      },
+      {
+        "level": 2,
+        "text": "For Individuals",
+        "anchor": "for-individuals"
+      },
+      {
+        "level": 3,
+        "text": "Account Security Checklist",
+        "anchor": "account-security-checklist"
+      },
+      {
+        "level": 3,
+        "text": "Device-Level Security",
+        "anchor": "device-level-security"
+      },
+      {
+        "level": 3,
+        "text": "Advanced Privacy Measures",
+        "anchor": "advanced-privacy-measures"
+      },
+      {
+        "level": 3,
+        "text": "Best Practices for Safe Use",
+        "anchor": "best-practices-for-safe-use"
+      },
+      {
+        "level": 3,
+        "text": "Platform-Specific Risks: Man-in-the-Group Attack",
+        "anchor": "platform-specific-risks-man-in-the-group-attack"
+      },
+      {
+        "level": 2,
+        "text": "For Team Members",
+        "anchor": "for-team-members"
+      },
+      {
+        "level": 2,
+        "text": "For Admins",
+        "anchor": "for-admins"
+      },
+      {
+        "level": 3,
+        "text": "Channel & Group Settings Checklist",
+        "anchor": "channel-group-settings-checklist"
+      },
+      {
+        "level": 3,
+        "text": "Admin Permissions Management",
+        "anchor": "admin-permissions-management"
+      },
+      {
+        "level": 3,
+        "text": "Additional Recommendations",
+        "anchor": "additional-recommendations"
+      },
+      {
+        "level": 3,
+        "text": "Educate Community Members on Security Practices",
+        "anchor": "educate-community-members-on-security-practices"
+      },
+      {
+        "level": 3,
+        "text": "Notes",
+        "anchor": "notes"
+      }
+    ],
+    "lineCount": 374
+  },
+  {
+    "path": "/guides/account_management/trello",
+    "title": "Trello Security",
+    "domain": "guides",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Summary",
+        "anchor": "summary"
+      },
+      {
+        "level": 2,
+        "text": "For Individuals",
+        "anchor": "for-individuals"
+      },
+      {
+        "level": 3,
+        "text": "Account Security Checklist",
+        "anchor": "account-security-checklist"
+      },
+      {
+        "level": 3,
+        "text": "Best Practices & Additional Tips",
+        "anchor": "best-practices-additional-tips"
+      }
+    ],
+    "lineCount": 57
+  },
+  {
+    "path": "/guides/account_management/twitter",
+    "title": "Twitter/X Security",
+    "domain": "guides",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Summary",
+        "anchor": "summary"
+      },
+      {
+        "level": 2,
+        "text": "For Individuals",
+        "anchor": "for-individuals"
+      },
+      {
+        "level": 3,
+        "text": "Account Security Checklist",
+        "anchor": "account-security-checklist"
+      },
+      {
+        "level": 3,
+        "text": "Best Practices & Additional Tips",
+        "anchor": "best-practices-additional-tips"
+      },
+      {
+        "level": 3,
+        "text": "Notes",
+        "anchor": "notes"
+      },
+      {
+        "level": 2,
+        "text": "For Team Members",
+        "anchor": "for-team-members"
+      },
+      {
+        "level": 2,
+        "text": "For Admins",
+        "anchor": "for-admins"
+      },
+      {
+        "level": 3,
+        "text": "Typefully Integration",
+        "anchor": "typefully-integration"
+      }
+    ],
+    "lineCount": 131
+  },
+  {
+    "path": "/guides/account_management/vercel",
+    "title": "Vercel Security",
+    "domain": "guides",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Summary",
+        "anchor": "summary"
+      },
+      {
+        "level": 2,
+        "text": "For Individuals",
+        "anchor": "for-individuals"
+      },
+      {
+        "level": 3,
+        "text": "Individual Account Settings",
+        "anchor": "individual-account-settings"
+      },
+      {
+        "level": 2,
+        "text": "For Team Members",
+        "anchor": "for-team-members"
+      },
+      {
+        "level": 2,
+        "text": "For Admins",
+        "anchor": "for-admins"
+      },
+      {
+        "level": 3,
+        "text": "Team Settings",
+        "anchor": "team-settings"
+      },
+      {
+        "level": 3,
+        "text": "Project Settings",
+        "anchor": "project-settings"
+      }
+    ],
+    "lineCount": 94
+  },
+  {
+    "path": "/guides/overview",
+    "title": "Guides",
+    "domain": "guides",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Available Guide Categories",
+        "anchor": "available-guide-categories"
+      },
+      {
+        "level": 3,
+        "text": "[Account Management](/guides/account_management/overview)",
+        "anchor": "account-managementguidesaccount_managementoverview"
+      }
+    ],
+    "lineCount": 38
+  },
+  {
+    "path": "/iam/access-management",
+    "title": "Access Management",
+    "domain": "iam",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Practices for Access Management",
+        "anchor": "practices-for-access-management"
+      },
+      {
+        "level": 2,
+        "text": "Best Practices for Access Management",
+        "anchor": "best-practices-for-access-management"
+      }
+    ],
+    "lineCount": 49
+  },
+  {
+    "path": "/iam/overview",
+    "title": "Identity and Access Management | SEAL",
+    "domain": "iam",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Contents",
+        "anchor": "contents"
+      }
+    ],
+    "lineCount": 34
+  },
+  {
+    "path": "/iam/role-based-access-control",
+    "title": "Role-Based Access Control",
+    "domain": "iam",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Key Principles of RBAC",
+        "anchor": "key-principles-of-rbac"
+      }
+    ],
+    "lineCount": 42
+  },
+  {
+    "path": "/iam/secure-authentication",
+    "title": "Secure Authentication",
+    "domain": "iam",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Key Authentication Methods",
+        "anchor": "key-authentication-methods"
+      },
+      {
+        "level": 2,
+        "text": "Best Practices for Secure Authentication",
+        "anchor": "best-practices-for-secure-authentication"
+      }
+    ],
+    "lineCount": 49
+  },
+  {
+    "path": "/incident-management/communication-strategies",
+    "title": "Incident Communication Strategies | SEAL",
+    "domain": "incident-management",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Best Practices",
+        "anchor": "best-practices"
+      }
+    ],
+    "lineCount": 44
+  },
+  {
+    "path": "/incident-management/incident-detection-and-response",
+    "title": "Incident Detection And Response | SEAL",
+    "domain": "incident-management",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Key Components of Incident Detection",
+        "anchor": "key-components-of-incident-detection"
+      },
+      {
+        "level": 2,
+        "text": "Key Components of Incident Response",
+        "anchor": "key-components-of-incident-response"
+      }
+    ],
+    "lineCount": 44
+  },
+  {
+    "path": "/incident-management/lessons-learned",
+    "title": "Incident Lessons Learned",
+    "domain": "incident-management",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Best Practices",
+        "anchor": "best-practices"
+      }
+    ],
+    "lineCount": 40
+  },
+  {
+    "path": "/incident-management/overview",
+    "title": "Incident Management",
+    "domain": "incident-management",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Contents",
+        "anchor": "contents"
+      }
+    ],
+    "lineCount": 37
+  },
+  {
+    "path": "/incident-management/playbooks/decentralized-ir",
+    "title": "Decentralized Incident Response | SEAL",
+    "domain": "incident-management",
+    "headers": [
+      {
+        "level": 2,
+        "text": "1. Guiding Principles",
+        "anchor": "1-guiding-principles"
+      },
+      {
+        "level": 2,
+        "text": "2. Roles and Identities",
+        "anchor": "2-roles-and-identities"
+      },
+      {
+        "level": 2,
+        "text": "3. Preparation Checklist",
+        "anchor": "3-preparation-checklist"
+      },
+      {
+        "level": 2,
+        "text": "4. Detection and Triage Flow",
+        "anchor": "4-detection-and-triage-flow"
+      },
+      {
+        "level": 2,
+        "text": "5. Containment Options",
+        "anchor": "5-containment-options"
+      },
+      {
+        "level": 2,
+        "text": "6. Eradication and Recovery",
+        "anchor": "6-eradication-and-recovery"
+      },
+      {
+        "level": 2,
+        "text": "7. Post-Incident Actions",
+        "anchor": "7-post-incident-actions"
+      },
+      {
+        "level": 2,
+        "text": "8. Quick-Start Templates",
+        "anchor": "8-quick-start-templates"
+      },
+      {
+        "level": 2,
+        "text": "9. Pros and Cons of Decentralized IR",
+        "anchor": "9-pros-and-cons-of-decentralized-ir"
+      },
+      {
+        "level": 2,
+        "text": "10. Keep It Alive",
+        "anchor": "10-keep-it-alive"
+      }
+    ],
+    "lineCount": 155
+  },
+  {
+    "path": "/incident-management/playbooks/hacked-dprk",
+    "title": "North Korea (DPRK) Attack Response | SEAL",
+    "domain": "incident-management",
+    "headers": [
+      {
+        "level": 2,
+        "text": "The Fake Video Conference Software",
+        "anchor": "the-fake-video-conference-software"
+      },
+      {
+        "level": 2,
+        "text": "The Fake PDF",
+        "anchor": "the-fake-pdf"
+      }
+    ],
+    "lineCount": 91
+  },
+  {
+    "path": "/incident-management/playbooks/hacked-drainer",
+    "title": "Wallet Drainer Attack Response | SEAL",
+    "domain": "incident-management",
+    "headers": [],
+    "lineCount": 52
+  },
+  {
+    "path": "/incident-management/playbooks/hacked-elusive-comet",
+    "title": "ELUSIVE COMET Attack Response | SEAL",
+    "domain": "incident-management",
+    "headers": [],
+    "lineCount": 77
+  },
+  {
+    "path": "/incident-management/playbooks/malware",
+    "title": "Malware Infection Response",
+    "domain": "incident-management",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Secure your crypto assets",
+        "anchor": "secure-your-crypto-assets"
+      },
+      {
+        "level": 2,
+        "text": "Notify your colleagues/friends",
+        "anchor": "notify-your-colleaguesfriends"
+      },
+      {
+        "level": 2,
+        "text": "Secure your accounts",
+        "anchor": "secure-your-accounts"
+      },
+      {
+        "level": 2,
+        "text": "Notify the authorities",
+        "anchor": "notify-the-authorities"
+      },
+      {
+        "level": 2,
+        "text": "Get a new computer",
+        "anchor": "get-a-new-computer"
+      },
+      {
+        "level": 2,
+        "text": "Stay vigilant",
+        "anchor": "stay-vigilant"
+      }
+    ],
+    "lineCount": 183
+  },
+  {
+    "path": "/incident-management/playbooks/overview",
+    "title": "Incident Response Playbooks",
+    "domain": "incident-management",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Best Practices",
+        "anchor": "best-practices"
+      }
+    ],
+    "lineCount": 37
+  },
+  {
+    "path": "/incident-management/playbooks/seal-911-war-room-guidelines",
+    "title": "SEAL 911 War Room Guidelines | SEAL",
+    "domain": "incident-management",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Crisis Handbook - Smart Contract Hack | [Google Doc](https://docs.google.com/document/d/1DaAiuGFkMEMMiIuvqhePL5aDFGHJ9Ya6D04rdaldqC0/edit#heading=h.c4h2beeflqpo)",
+        "anchor": "crisis-handbook---smart-contract-hack-google-dochttpsdocsgooglecomdocumentd1daaiugfkmemmiiuvqhepl5adfghj9ya6d04rdaldqc0editheadinghc4h2beeflqpo"
+      },
+      {
+        "level": 3,
+        "text": "Actions Checklist",
+        "anchor": "actions-checklist"
+      },
+      {
+        "level": 3,
+        "text": "Perform Immediately",
+        "anchor": "perform-immediately"
+      },
+      {
+        "level": 3,
+        "text": "Perform in Parallel by Role",
+        "anchor": "perform-in-parallel-by-role"
+      },
+      {
+        "level": 3,
+        "text": "After all of the above is complete, consider Post Incident Actions",
+        "anchor": "after-all-of-the-above-is-complete-consider-post-incident-actions"
+      },
+      {
+        "level": 2,
+        "text": "Information Gathering",
+        "anchor": "information-gathering"
+      },
+      {
+        "level": 3,
+        "text": "Issue Description",
+        "anchor": "issue-description"
+      },
+      {
+        "level": 3,
+        "text": "Events Timeline",
+        "anchor": "events-timeline"
+      },
+      {
+        "level": 3,
+        "text": "Transactions Involved",
+        "anchor": "transactions-involved"
+      },
+      {
+        "level": 3,
+        "text": "Affected Addresses",
+        "anchor": "affected-addresses"
+      },
+      {
+        "level": 3,
+        "text": "Funds Movement",
+        "anchor": "funds-movement"
+      },
+      {
+        "level": 3,
+        "text": "Attacker Information",
+        "anchor": "attacker-information"
+      },
+      {
+        "level": 2,
+        "text": "Post Incident Actions",
+        "anchor": "post-incident-actions"
+      },
+      {
+        "level": 2,
+        "text": "Appendix",
+        "anchor": "appendix"
+      },
+      {
+        "level": 3,
+        "text": "Advice to Keep in Mind",
+        "anchor": "advice-to-keep-in-mind"
+      },
+      {
+        "level": 3,
+        "text": "Key Roles",
+        "anchor": "key-roles"
+      },
+      {
+        "level": 3,
+        "text": "Suggested Tools and Platforms",
+        "anchor": "suggested-tools-and-platforms"
+      },
+      {
+        "level": 3,
+        "text": "SEAL Message Template",
+        "anchor": "seal-message-template"
+      }
+    ],
+    "lineCount": 232
+  },
+  {
+    "path": "/infrastructure/asset-inventory",
+    "title": "Asset Inventory",
+    "domain": "infrastructure",
+    "headers": [],
+    "lineCount": 34
+  },
+  {
+    "path": "/infrastructure/cloud",
+    "title": "Cloud Infrastructure",
+    "domain": "infrastructure",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Cloud Provider Hardening Guides",
+        "anchor": "cloud-provider-hardening-guides"
+      },
+      {
+        "level": 2,
+        "text": "Open Source Tools",
+        "anchor": "open-source-tools"
+      }
+    ],
+    "lineCount": 61
+  },
+  {
+    "path": "/infrastructure/ddos-protection",
+    "title": "DDoS Protection",
+    "domain": "infrastructure",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Best Practices",
+        "anchor": "best-practices"
+      },
+      {
+        "level": 3,
+        "text": "AWS",
+        "anchor": "aws"
+      },
+      {
+        "level": 3,
+        "text": "Azure",
+        "anchor": "azure"
+      },
+      {
+        "level": 3,
+        "text": "GCP",
+        "anchor": "gcp"
+      },
+      {
+        "level": 2,
+        "text": "External DDoS Protection Providers",
+        "anchor": "external-ddos-protection-providers"
+      }
+    ],
+    "lineCount": 66
+  },
+  {
+    "path": "/infrastructure/domain-and-dns-security/dns-basics-and-attacks",
+    "title": "DNS Basics & Common Attacks | SEAL",
+    "domain": "infrastructure",
+    "headers": [
+      {
+        "level": 2,
+        "text": "How DNS Resolution Works",
+        "anchor": "how-dns-resolution-works"
+      },
+      {
+        "level": 2,
+        "text": "Common Attack Vectors",
+        "anchor": "common-attack-vectors"
+      }
+    ],
+    "lineCount": 87
+  },
+  {
+    "path": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+    "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+    "domain": "infrastructure",
+    "headers": [
+      {
+        "level": 2,
+        "text": "DNSSEC Implementation",
+        "anchor": "dnssec-implementation"
+      },
+      {
+        "level": 2,
+        "text": "CAA Records",
+        "anchor": "caa-records"
+      },
+      {
+        "level": 2,
+        "text": "SMTP DANE",
+        "anchor": "smtp-dane"
+      },
+      {
+        "level": 2,
+        "text": "Email Security Configuration",
+        "anchor": "email-security-configuration"
+      },
+      {
+        "level": 3,
+        "text": "SPF (Sender Policy Framework)",
+        "anchor": "spf-sender-policy-framework"
+      },
+      {
+        "level": 3,
+        "text": "DKIM (DomainKeys Identified Mail)",
+        "anchor": "dkim-domainkeys-identified-mail"
+      },
+      {
+        "level": 3,
+        "text": "MTA-STS (Mail Transfer Agent Strict Transport Security)",
+        "anchor": "mta-sts-mail-transfer-agent-strict-transport-security"
+      },
+      {
+        "level": 3,
+        "text": "DMARC (Domain-based Message Authentication)",
+        "anchor": "dmarc-domain-based-message-authentication"
+      }
+    ],
+    "lineCount": 324
+  },
+  {
+    "path": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+    "title": "DNS Monitoring & Incident Response | SEAL",
+    "domain": "infrastructure",
+    "headers": [
+      {
+        "level": 2,
+        "text": "DNS Record Monitoring",
+        "anchor": "dns-record-monitoring"
+      },
+      {
+        "level": 2,
+        "text": "Certificate Transparency Monitoring",
+        "anchor": "certificate-transparency-monitoring"
+      },
+      {
+        "level": 2,
+        "text": "Passive DNS Monitoring",
+        "anchor": "passive-dns-monitoring"
+      },
+      {
+        "level": 2,
+        "text": "Setting Up Alerts",
+        "anchor": "setting-up-alerts"
+      },
+      {
+        "level": 3,
+        "text": "Critical Alerts (Immediate Response Required)",
+        "anchor": "critical-alerts-immediate-response-required"
+      },
+      {
+        "level": 3,
+        "text": "High Priority Alerts (When NS Unchanged)",
+        "anchor": "high-priority-alerts-when-ns-unchanged"
+      },
+      {
+        "level": 2,
+        "text": "Incident Response Plan",
+        "anchor": "incident-response-plan"
+      },
+      {
+        "level": 3,
+        "text": "Immediate Response",
+        "anchor": "immediate-response"
+      },
+      {
+        "level": 3,
+        "text": "Containment",
+        "anchor": "containment"
+      },
+      {
+        "level": 3,
+        "text": "Recovery",
+        "anchor": "recovery"
+      },
+      {
+        "level": 3,
+        "text": "Post-Incident",
+        "anchor": "post-incident"
+      }
+    ],
+    "lineCount": 200
+  },
+  {
+    "path": "/infrastructure/domain-and-dns-security/overview",
+    "title": "Domain & DNS Security | SEAL",
+    "domain": "infrastructure",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      },
+      {
+        "level": 3,
+        "text": "Why Domain Security is Critical in Web3",
+        "anchor": "why-domain-security-is-critical-in-web3"
+      },
+      {
+        "level": 2,
+        "text": "Historical Context",
+        "anchor": "historical-context"
+      },
+      {
+        "level": 3,
+        "text": "Notable Domain Security Incidents",
+        "anchor": "notable-domain-security-incidents"
+      },
+      {
+        "level": 2,
+        "text": "References and Resources",
+        "anchor": "references-and-resources"
+      },
+      {
+        "level": 3,
+        "text": "Incident Response Contacts",
+        "anchor": "incident-response-contacts"
+      },
+      {
+        "level": 3,
+        "text": "Standards and Best Practices",
+        "anchor": "standards-and-best-practices"
+      }
+    ],
+    "lineCount": 90
+  },
+  {
+    "path": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+    "title": "Registrar Security & Registry Locks | SEAL",
+    "domain": "infrastructure",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Choosing a Secure Registrar",
+        "anchor": "choosing-a-secure-registrar"
+      },
+      {
+        "level": 3,
+        "text": "Enterprise-Grade Registrars (Recommended)",
+        "anchor": "enterprise-grade-registrars-recommended"
+      },
+      {
+        "level": 3,
+        "text": "Consumer Registrars to Avoid for Critical Domains",
+        "anchor": "consumer-registrars-to-avoid-for-critical-domains"
+      },
+      {
+        "level": 2,
+        "text": "Registry Lock (EPP Lock)",
+        "anchor": "registry-lock-epp-lock"
+      },
+      {
+        "level": 2,
+        "text": "Multi-Factor Authentication",
+        "anchor": "multi-factor-authentication"
+      },
+      {
+        "level": 2,
+        "text": "Dedicated Security Contact Email",
+        "anchor": "dedicated-security-contact-email"
+      },
+      {
+        "level": 2,
+        "text": "Access Control Best Practices",
+        "anchor": "access-control-best-practices"
+      },
+      {
+        "level": 2,
+        "text": "WHOIS Privacy Protection",
+        "anchor": "whois-privacy-protection"
+      },
+      {
+        "level": 2,
+        "text": "WHOIS vs RDAP",
+        "anchor": "whois-vs-rdap"
+      },
+      {
+        "level": 2,
+        "text": "Domain Expiration Protection",
+        "anchor": "domain-expiration-protection"
+      }
+    ],
+    "lineCount": 307
+  },
+  {
+    "path": "/infrastructure/identity-and-access-management",
+    "title": "Identity And Access Management | SEAL",
+    "domain": "infrastructure",
+    "headers": [],
+    "lineCount": 26
+  },
+  {
+    "path": "/infrastructure/network-security",
+    "title": "Network Security",
+    "domain": "infrastructure",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Best Practices",
+        "anchor": "best-practices"
+      }
+    ],
+    "lineCount": 45
+  },
+  {
+    "path": "/infrastructure/operating-system-security",
+    "title": "Operating System Security",
+    "domain": "infrastructure",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Best Practices",
+        "anchor": "best-practices"
+      }
+    ],
+    "lineCount": 44
+  },
+  {
+    "path": "/infrastructure/overview",
+    "title": "Infrastructure",
+    "domain": "infrastructure",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Contents",
+        "anchor": "contents"
+      }
+    ],
+    "lineCount": 47
+  },
+  {
+    "path": "/infrastructure/zero-trust-principles",
+    "title": "Zero Trust Principles",
+    "domain": "infrastructure",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Key Principles",
+        "anchor": "key-principles"
+      },
+      {
+        "level": 2,
+        "text": "Implementation Strategies",
+        "anchor": "implementation-strategies"
+      }
+    ],
+    "lineCount": 43
+  },
+  {
+    "path": "/intro/how-to-navigate-the-website",
+    "title": "How to Navigate the Website | SEAL",
+    "domain": "intro",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Categories",
+        "anchor": "categories"
+      },
+      {
+        "level": 2,
+        "text": "Filtering by Profile",
+        "anchor": "filtering-by-profile"
+      }
+    ],
+    "lineCount": 46
+  },
+  {
+    "path": "/intro/introduction",
+    "title": "Introduction to SEAL Frameworks",
+    "domain": "intro",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Why We Created This Resource",
+        "anchor": "why-we-created-this-resource"
+      },
+      {
+        "level": 2,
+        "text": "Who Can Benefit",
+        "anchor": "who-can-benefit"
+      },
+      {
+        "level": 2,
+        "text": "How to Contribute",
+        "anchor": "how-to-contribute"
+      },
+      {
+        "level": 2,
+        "text": "Who We Are",
+        "anchor": "who-we-are"
+      }
+    ],
+    "lineCount": 50
+  },
+  {
+    "path": "/intro/overview-of-each-framework",
+    "title": "Overview Of Each Framework | SEAL",
+    "domain": "intro",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Community Management",
+        "anchor": "community-management"
+      },
+      {
+        "level": 2,
+        "text": "Awareness",
+        "anchor": "awareness"
+      },
+      {
+        "level": 2,
+        "text": "Operational Security (OpSec)",
+        "anchor": "operational-security-opsec"
+      },
+      {
+        "level": 2,
+        "text": "Wallet Security",
+        "anchor": "wallet-security"
+      },
+      {
+        "level": 2,
+        "text": "Multisig for Protocols",
+        "anchor": "multisig-for-protocols"
+      },
+      {
+        "level": 2,
+        "text": "External Security Reviews",
+        "anchor": "external-security-reviews"
+      },
+      {
+        "level": 2,
+        "text": "Vulnerability Disclosure",
+        "anchor": "vulnerability-disclosure"
+      },
+      {
+        "level": 2,
+        "text": "Infrastructure",
+        "anchor": "infrastructure"
+      },
+      {
+        "level": 2,
+        "text": "Monitoring",
+        "anchor": "monitoring"
+      },
+      {
+        "level": 2,
+        "text": "Front-End/Web Application",
+        "anchor": "front-endweb-application"
+      },
+      {
+        "level": 2,
+        "text": "Incident Management",
+        "anchor": "incident-management"
+      },
+      {
+        "level": 2,
+        "text": "Threat Modeling",
+        "anchor": "threat-modeling"
+      },
+      {
+        "level": 2,
+        "text": "Insider Threats (DPRK IT Workers)",
+        "anchor": "insider-threats-dprk-it-workers"
+      },
+      {
+        "level": 2,
+        "text": "Governance",
+        "anchor": "governance"
+      },
+      {
+        "level": 2,
+        "text": "DevSecOps",
+        "anchor": "devsecops"
+      },
+      {
+        "level": 2,
+        "text": "Privacy",
+        "anchor": "privacy"
+      },
+      {
+        "level": 2,
+        "text": "Supply Chain",
+        "anchor": "supply-chain"
+      },
+      {
+        "level": 2,
+        "text": "Security Automation",
+        "anchor": "security-automation"
+      },
+      {
+        "level": 2,
+        "text": "Identity and Access Management (IAM)",
+        "anchor": "identity-and-access-management-iam"
+      },
+      {
+        "level": 2,
+        "text": "Secure Software Development",
+        "anchor": "secure-software-development"
+      },
+      {
+        "level": 2,
+        "text": "Security Testing",
+        "anchor": "security-testing"
+      },
+      {
+        "level": 2,
+        "text": "ENS",
+        "anchor": "ens"
+      },
+      {
+        "level": 2,
+        "text": "Safe Harbor",
+        "anchor": "safe-harbor"
+      },
+      {
+        "level": 2,
+        "text": "Encryption",
+        "anchor": "encryption"
+      },
+      {
+        "level": 2,
+        "text": "Treasury Operations",
+        "anchor": "treasury-operations"
+      },
+      {
+        "level": 2,
+        "text": "SEAL Certifications",
+        "anchor": "seal-certifications"
+      }
+    ],
+    "lineCount": 270
+  },
+  {
+    "path": "/intro/what-is-it",
+    "title": "What It Is",
+    "domain": "intro",
+    "headers": [],
+    "lineCount": 26
+  },
+  {
+    "path": "/intro/what-it-isnt",
+    "title": "What It Isn't",
+    "domain": "intro",
+    "headers": [],
+    "lineCount": 30
+  },
+  {
+    "path": "/monitoring/guidelines",
+    "title": "On-Chain Monitoring Guidelines",
+    "domain": "monitoring",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Best Practices",
+        "anchor": "best-practices"
+      },
+      {
+        "level": 3,
+        "text": "Define Monitoring Objectives",
+        "anchor": "define-monitoring-objectives"
+      },
+      {
+        "level": 3,
+        "text": "Implement Monitoring Tools",
+        "anchor": "implement-monitoring-tools"
+      },
+      {
+        "level": 3,
+        "text": "Establish Alerting Mechanisms",
+        "anchor": "establish-alerting-mechanisms"
+      },
+      {
+        "level": 3,
+        "text": "Regular Reviews and Updates",
+        "anchor": "regular-reviews-and-updates"
+      },
+      {
+        "level": 3,
+        "text": "Incident Response",
+        "anchor": "incident-response"
+      }
+    ],
+    "lineCount": 54
+  },
+  {
+    "path": "/monitoring/overview",
+    "title": "Monitoring",
+    "domain": "monitoring",
+    "headers": [],
+    "lineCount": 28
+  },
+  {
+    "path": "/monitoring/thresholds",
+    "title": "Monitoring Alert Thresholds",
+    "domain": "monitoring",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Generic Guidelines",
+        "anchor": "generic-guidelines"
+      },
+      {
+        "level": 3,
+        "text": "Understand Normal Activity Patterns",
+        "anchor": "understand-normal-activity-patterns"
+      },
+      {
+        "level": 3,
+        "text": "Set Thresholds for Alerts",
+        "anchor": "set-thresholds-for-alerts"
+      },
+      {
+        "level": 3,
+        "text": "Adjust Thresholds Over Time",
+        "anchor": "adjust-thresholds-over-time"
+      },
+      {
+        "level": 3,
+        "text": "Multi-Layered Thresholds",
+        "anchor": "multi-layered-thresholds"
+      },
+      {
+        "level": 3,
+        "text": "Anomaly Detection",
+        "anchor": "anomaly-detection"
+      }
+    ],
+    "lineCount": 60
+  },
+  {
+    "path": "/multisig-for-protocols/backup-signing-and-infrastructure",
+    "title": "Backup Signing & Infrastructure | SEAL",
+    "domain": "multisig-for-protocols",
+    "headers": [
+      {
+        "level": 2,
+        "text": "UI Alternatives",
+        "anchor": "ui-alternatives"
+      },
+      {
+        "level": 3,
+        "text": "EVM Networks",
+        "anchor": "evm-networks"
+      },
+      {
+        "level": 3,
+        "text": "Solana",
+        "anchor": "solana"
+      },
+      {
+        "level": 3,
+        "text": "Mobile (Safe)",
+        "anchor": "mobile-safe"
+      },
+      {
+        "level": 2,
+        "text": "RPC Backup Options",
+        "anchor": "rpc-backup-options"
+      },
+      {
+        "level": 3,
+        "text": "Basic guidance:",
+        "anchor": "basic-guidance"
+      },
+      {
+        "level": 3,
+        "text": "Administrator responsibilities",
+        "anchor": "administrator-responsibilities"
+      },
+      {
+        "level": 2,
+        "text": "Block Explorer Backup Options",
+        "anchor": "block-explorer-backup-options"
+      },
+      {
+        "level": 3,
+        "text": "EVM Networks",
+        "anchor": "evm-networks"
+      },
+      {
+        "level": 3,
+        "text": "Solana Networks",
+        "anchor": "solana-networks"
+      },
+      {
+        "level": 2,
+        "text": "Preparation",
+        "anchor": "preparation"
+      },
+      {
+        "level": 2,
+        "text": "EVM Networks",
+        "anchor": "evm-networks"
+      },
+      {
+        "level": 3,
+        "text": "Eternal Safe - Decentralized fork of Safe\\{Wallet\\}",
+        "anchor": "eternal-safe---decentralized-fork-of-safewallet"
+      },
+      {
+        "level": 2,
+        "text": "Solana",
+        "anchor": "solana"
+      },
+      {
+        "level": 3,
+        "text": "Squads Public Client - Open source Squads V4 interface",
+        "anchor": "squads-public-client---open-source-squads-v4-interface"
+      },
+      {
+        "level": 2,
+        "text": "Security Considerations",
+        "anchor": "security-considerations"
+      },
+      {
+        "level": 3,
+        "text": "Enhanced Verification",
+        "anchor": "enhanced-verification"
+      },
+      {
+        "level": 3,
+        "text": "Risk Assessment",
+        "anchor": "risk-assessment"
+      },
+      {
+        "level": 2,
+        "text": "Testing and Preparation",
+        "anchor": "testing-and-preparation"
+      },
+      {
+        "level": 3,
+        "text": "Regular Practice",
+        "anchor": "regular-practice"
+      },
+      {
+        "level": 3,
+        "text": "Emergency Drills",
+        "anchor": "emergency-drills"
+      },
+      {
+        "level": 2,
+        "text": "Troubleshooting",
+        "anchor": "troubleshooting"
+      },
+      {
+        "level": 3,
+        "text": "Common Issues",
+        "anchor": "common-issues"
+      },
+      {
+        "level": 3,
+        "text": "Support Resources",
+        "anchor": "support-resources"
+      },
+      {
+        "level": 2,
+        "text": "Related Documents",
+        "anchor": "related-documents"
+      }
+    ],
+    "lineCount": 247
+  },
+  {
+    "path": "/multisig-for-protocols/communication-setup",
+    "title": "Multisig Communication Setup | SEAL",
+    "domain": "multisig-for-protocols",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Primary channel",
+        "anchor": "primary-channel"
+      },
+      {
+        "level": 2,
+        "text": "Backup channels",
+        "anchor": "backup-channels"
+      },
+      {
+        "level": 2,
+        "text": "Paging system (Critical/Emergency Multisigs)",
+        "anchor": "paging-system-criticalemergency-multisigs"
+      }
+    ],
+    "lineCount": 54
+  },
+  {
+    "path": "/multisig-for-protocols/emergency-procedures",
+    "title": "Multisig Emergency Procedures | SEAL",
+    "domain": "multisig-for-protocols",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Key Compromise",
+        "anchor": "key-compromise"
+      },
+      {
+        "level": 3,
+        "text": "Immediate Actions (Within 30 Minutes)",
+        "anchor": "immediate-actions-within-30-minutes"
+      },
+      {
+        "level": 3,
+        "text": "Recovery Process",
+        "anchor": "recovery-process"
+      },
+      {
+        "level": 2,
+        "text": "Lost Key Access",
+        "anchor": "lost-key-access"
+      },
+      {
+        "level": 3,
+        "text": "Immediate Steps",
+        "anchor": "immediate-steps"
+      },
+      {
+        "level": 3,
+        "text": "Identity Verification Process",
+        "anchor": "identity-verification-process"
+      },
+      {
+        "level": 3,
+        "text": "Replacement Coordination",
+        "anchor": "replacement-coordination"
+      },
+      {
+        "level": 2,
+        "text": "Communication Account Compromise",
+        "anchor": "communication-account-compromise"
+      },
+      {
+        "level": 3,
+        "text": "If Telegram/Signal/Discord Gets Taken Over",
+        "anchor": "if-telegramsignaldiscord-gets-taken-over"
+      },
+      {
+        "level": 2,
+        "text": "Emergency Notification Template",
+        "anchor": "emergency-notification-template"
+      },
+      {
+        "level": 2,
+        "text": "Emergency Communication Protocols",
+        "anchor": "emergency-communication-protocols"
+      },
+      {
+        "level": 3,
+        "text": "Multi-Channel Notification",
+        "anchor": "multi-channel-notification"
+      },
+      {
+        "level": 3,
+        "text": "Identity Verification",
+        "anchor": "identity-verification"
+      },
+      {
+        "level": 3,
+        "text": "Information Sharing",
+        "anchor": "information-sharing"
+      },
+      {
+        "level": 2,
+        "text": "Operational Emergency Procedures",
+        "anchor": "operational-emergency-procedures"
+      },
+      {
+        "level": 3,
+        "text": "For Emergency Response Multisigs",
+        "anchor": "for-emergency-response-multisigs"
+      },
+      {
+        "level": 3,
+        "text": "Emergency Drill Procedures",
+        "anchor": "emergency-drill-procedures"
+      },
+      {
+        "level": 2,
+        "text": "Recovery and Post-Incident",
+        "anchor": "recovery-and-post-incident"
+      },
+      {
+        "level": 3,
+        "text": "Immediate Recovery",
+        "anchor": "immediate-recovery"
+      },
+      {
+        "level": 3,
+        "text": "Post-Incident Analysis",
+        "anchor": "post-incident-analysis"
+      },
+      {
+        "level": 3,
+        "text": "Communication",
+        "anchor": "communication"
+      },
+      {
+        "level": 2,
+        "text": "Emergency Contact Information",
+        "anchor": "emergency-contact-information"
+      },
+      {
+        "level": 3,
+        "text": "Security Team Contact",
+        "anchor": "security-team-contact"
+      },
+      {
+        "level": 3,
+        "text": "Internal Escalation",
+        "anchor": "internal-escalation"
+      },
+      {
+        "level": 2,
+        "text": "Related Documents",
+        "anchor": "related-documents"
+      }
+    ],
+    "lineCount": 236
+  },
+  {
+    "path": "/multisig-for-protocols/implementation-checklist",
+    "title": "Multisig Implementation Checklist | SEAL",
+    "domain": "multisig-for-protocols",
+    "headers": [
+      {
+        "level": 2,
+        "text": "For Multisig Administrators",
+        "anchor": "for-multisig-administrators"
+      },
+      {
+        "level": 3,
+        "text": "Planning & Setup",
+        "anchor": "planning-setup"
+      },
+      {
+        "level": 3,
+        "text": "Documentation & Communication",
+        "anchor": "documentation-communication"
+      },
+      {
+        "level": 3,
+        "text": "Ongoing Management",
+        "anchor": "ongoing-management"
+      },
+      {
+        "level": 2,
+        "text": "For Signers",
+        "anchor": "for-signers"
+      },
+      {
+        "level": 3,
+        "text": "Hardware & Security Setup",
+        "anchor": "hardware-security-setup"
+      },
+      {
+        "level": 3,
+        "text": "Operational Readiness",
+        "anchor": "operational-readiness"
+      },
+      {
+        "level": 3,
+        "text": "Transaction Verification",
+        "anchor": "transaction-verification"
+      },
+      {
+        "level": 3,
+        "text": "Emergency Preparedness",
+        "anchor": "emergency-preparedness"
+      },
+      {
+        "level": 3,
+        "text": "Personal Security",
+        "anchor": "personal-security"
+      },
+      {
+        "level": 3,
+        "text": "Compliance",
+        "anchor": "compliance"
+      },
+      {
+        "level": 2,
+        "text": "Specialized Training by Use Case",
+        "anchor": "specialized-training-by-use-case"
+      },
+      {
+        "level": 3,
+        "text": "Emergency Response Multisigs",
+        "anchor": "emergency-response-multisigs"
+      },
+      {
+        "level": 3,
+        "text": "Treasury Multisigs",
+        "anchor": "treasury-multisigs"
+      },
+      {
+        "level": 3,
+        "text": "Smart Contract Control Multisigs",
+        "anchor": "smart-contract-control-multisigs"
+      },
+      {
+        "level": 2,
+        "text": "Practical Skills Assessment",
+        "anchor": "practical-skills-assessment"
+      },
+      {
+        "level": 3,
+        "text": "Transaction Verification (EVM)",
+        "anchor": "transaction-verification-evm"
+      },
+      {
+        "level": 3,
+        "text": "Transaction Verification (Solana)",
+        "anchor": "transaction-verification-solana"
+      },
+      {
+        "level": 3,
+        "text": "Emergency Procedures",
+        "anchor": "emergency-procedures"
+      },
+      {
+        "level": 3,
+        "text": "Tool Proficiency",
+        "anchor": "tool-proficiency"
+      },
+      {
+        "level": 2,
+        "text": "Documentation Review",
+        "anchor": "documentation-review"
+      },
+      {
+        "level": 3,
+        "text": "Required Reading Completed",
+        "anchor": "required-reading-completed"
+      },
+      {
+        "level": 3,
+        "text": "Role-Specific Documentation",
+        "anchor": "role-specific-documentation"
+      },
+      {
+        "level": 2,
+        "text": "Certification and Acknowledgment",
+        "anchor": "certification-and-acknowledgment"
+      },
+      {
+        "level": 3,
+        "text": "Training Completion",
+        "anchor": "training-completion"
+      },
+      {
+        "level": 3,
+        "text": "Ongoing Commitment",
+        "anchor": "ongoing-commitment"
+      },
+      {
+        "level": 3,
+        "text": "Trainer Verification (if applicable)",
+        "anchor": "trainer-verification-if-applicable"
+      },
+      {
+        "level": 2,
+        "text": "Refresher Training Schedule",
+        "anchor": "refresher-training-schedule"
+      },
+      {
+        "level": 3,
+        "text": "Regular Updates",
+        "anchor": "regular-updates"
+      },
+      {
+        "level": 3,
+        "text": "Trigger Events",
+        "anchor": "trigger-events"
+      },
+      {
+        "level": 2,
+        "text": "Related Documents",
+        "anchor": "related-documents"
+      }
+    ],
+    "lineCount": 236
+  },
+  {
+    "path": "/multisig-for-protocols/incident-reporting",
+    "title": "Multisig Incident Reporting | SEAL",
+    "domain": "multisig-for-protocols",
+    "headers": [
+      {
+        "level": 2,
+        "text": "What to Report",
+        "anchor": "what-to-report"
+      },
+      {
+        "level": 3,
+        "text": "Security incidents (report immediately)",
+        "anchor": "security-incidents-report-immediately"
+      },
+      {
+        "level": 3,
+        "text": "Operational issues (Report Within 24 Hours)",
+        "anchor": "operational-issues-report-within-24-hours"
+      },
+      {
+        "level": 3,
+        "text": "Near misses (report when convenient)",
+        "anchor": "near-misses-report-when-convenient"
+      },
+      {
+        "level": 2,
+        "text": "How to report",
+        "anchor": "how-to-report"
+      },
+      {
+        "level": 3,
+        "text": "Immediate security incidents",
+        "anchor": "immediate-security-incidents"
+      },
+      {
+        "level": 3,
+        "text": "Standard reporting",
+        "anchor": "standard-reporting"
+      },
+      {
+        "level": 3,
+        "text": "Emergency contact",
+        "anchor": "emergency-contact"
+      },
+      {
+        "level": 2,
+        "text": "Emergency notification template",
+        "anchor": "emergency-notification-template"
+      },
+      {
+        "level": 2,
+        "text": "Documentation",
+        "anchor": "documentation"
+      }
+    ],
+    "lineCount": 139
+  },
+  {
+    "path": "/multisig-for-protocols/joining-a-multisig",
+    "title": "Joining a Multisig",
+    "domain": "multisig-for-protocols",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Verifying address ownership",
+        "anchor": "verifying-address-ownership"
+      },
+      {
+        "level": 3,
+        "text": "Preparing and sharing address & Signature",
+        "anchor": "preparing-and-sharing-address-signature"
+      },
+      {
+        "level": 2,
+        "text": "Ethereum signature verification",
+        "anchor": "ethereum-signature-verification"
+      },
+      {
+        "level": 3,
+        "text": "Etherscan UI",
+        "anchor": "etherscan-ui"
+      },
+      {
+        "level": 3,
+        "text": "MyCrypto",
+        "anchor": "mycrypto"
+      }
+    ],
+    "lineCount": 77
+  },
+  {
+    "path": "/multisig-for-protocols/offboarding",
+    "title": "Multisig Offboarding",
+    "domain": "multisig-for-protocols",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Signer removal",
+        "anchor": "signer-removal"
+      },
+      {
+        "level": 2,
+        "text": "Clean up access",
+        "anchor": "clean-up-access"
+      },
+      {
+        "level": 2,
+        "text": "Handover",
+        "anchor": "handover"
+      }
+    ],
+    "lineCount": 47
+  },
+  {
+    "path": "/multisig-for-protocols/overview",
+    "title": "Multisig Security Framework | SEAL",
+    "domain": "multisig-for-protocols",
+    "headers": [
+      {
+        "level": 2,
+        "text": "How to use this guide",
+        "anchor": "how-to-use-this-guide"
+      },
+      {
+        "level": 2,
+        "text": "Core principles",
+        "anchor": "core-principles"
+      },
+      {
+        "level": 2,
+        "text": "Framework Structure",
+        "anchor": "framework-structure"
+      },
+      {
+        "level": 3,
+        "text": "1. Foundation",
+        "anchor": "1-foundation"
+      },
+      {
+        "level": 3,
+        "text": "2. Multisig Administration",
+        "anchor": "2-multisig-administration"
+      },
+      {
+        "level": 3,
+        "text": "3. For Signers",
+        "anchor": "3-for-signers"
+      },
+      {
+        "level": 3,
+        "text": "4. Reference",
+        "anchor": "4-reference"
+      }
+    ],
+    "lineCount": 78
+  },
+  {
+    "path": "/multisig-for-protocols/personal-security-opsec",
+    "title": "Multisig Personal Security (OpSec) | SEAL",
+    "domain": "multisig-for-protocols",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Account Security",
+        "anchor": "account-security"
+      },
+      {
+        "level": 3,
+        "text": "Basic requirements",
+        "anchor": "basic-requirements"
+      },
+      {
+        "level": 3,
+        "text": "For extra security",
+        "anchor": "for-extra-security"
+      },
+      {
+        "level": 2,
+        "text": "Device Security",
+        "anchor": "device-security"
+      },
+      {
+        "level": 3,
+        "text": "Basic requirements",
+        "anchor": "basic-requirements"
+      },
+      {
+        "level": 3,
+        "text": "For extra security",
+        "anchor": "for-extra-security"
+      },
+      {
+        "level": 2,
+        "text": "Network Security",
+        "anchor": "network-security"
+      },
+      {
+        "level": 3,
+        "text": "Dedicated Signing Machines",
+        "anchor": "dedicated-signing-machines"
+      },
+      {
+        "level": 3,
+        "text": "Air-Gapped Machine Options",
+        "anchor": "air-gapped-machine-options"
+      },
+      {
+        "level": 3,
+        "text": "Advanced OS-Level Controls",
+        "anchor": "advanced-os-level-controls"
+      },
+      {
+        "level": 3,
+        "text": "Network Monitoring Tools",
+        "anchor": "network-monitoring-tools"
+      },
+      {
+        "level": 3,
+        "text": "DNS Security",
+        "anchor": "dns-security"
+      },
+      {
+        "level": 2,
+        "text": "Communication Security",
+        "anchor": "communication-security"
+      },
+      {
+        "level": 3,
+        "text": "Basic requirements",
+        "anchor": "basic-requirements"
+      },
+      {
+        "level": 3,
+        "text": "Signal configuration",
+        "anchor": "signal-configuration"
+      },
+      {
+        "level": 3,
+        "text": "URL Navigation Safety",
+        "anchor": "url-navigation-safety"
+      },
+      {
+        "level": 3,
+        "text": "For extra security",
+        "anchor": "for-extra-security"
+      },
+      {
+        "level": 2,
+        "text": "Travel considerations",
+        "anchor": "travel-considerations"
+      },
+      {
+        "level": 3,
+        "text": "What to bring",
+        "anchor": "what-to-bring"
+      },
+      {
+        "level": 3,
+        "text": "What NOT to bring",
+        "anchor": "what-not-to-bring"
+      },
+      {
+        "level": 3,
+        "text": "Basic travel security",
+        "anchor": "basic-travel-security"
+      },
+      {
+        "level": 3,
+        "text": "For extra security",
+        "anchor": "for-extra-security"
+      },
+      {
+        "level": 2,
+        "text": "Implementation priority",
+        "anchor": "implementation-priority"
+      },
+      {
+        "level": 3,
+        "text": "Start with basics",
+        "anchor": "start-with-basics"
+      },
+      {
+        "level": 3,
+        "text": "Add extra security",
+        "anchor": "add-extra-security"
+      }
+    ],
+    "lineCount": 206
+  },
+  {
+    "path": "/multisig-for-protocols/planning-and-classification",
+    "title": "Multisig Planning & Classification | SEAL",
+    "domain": "multisig-for-protocols",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Before You Start",
+        "anchor": "before-you-start"
+      },
+      {
+        "level": 3,
+        "text": "Define Purpose and Scope",
+        "anchor": "define-purpose-and-scope"
+      },
+      {
+        "level": 3,
+        "text": "Assess Constraints and Recovery",
+        "anchor": "assess-constraints-and-recovery"
+      },
+      {
+        "level": 3,
+        "text": "Identify Stakeholders",
+        "anchor": "identify-stakeholders"
+      },
+      {
+        "level": 2,
+        "text": "Classification Process",
+        "anchor": "classification-process"
+      },
+      {
+        "level": 3,
+        "text": "Step 1: Impact Assessment",
+        "anchor": "step-1-impact-assessment"
+      },
+      {
+        "level": 3,
+        "text": "Step 2: Operational Assessment",
+        "anchor": "step-2-operational-assessment"
+      },
+      {
+        "level": 3,
+        "text": "Step 3: Classification Matrix",
+        "anchor": "step-3-classification-matrix"
+      },
+      {
+        "level": 3,
+        "text": "Step 4: Document Your Decision",
+        "anchor": "step-4-document-your-decision"
+      },
+      {
+        "level": 2,
+        "text": "Important Notes",
+        "anchor": "important-notes"
+      },
+      {
+        "level": 2,
+        "text": "Next Steps",
+        "anchor": "next-steps"
+      }
+    ],
+    "lineCount": 166
+  },
+  {
+    "path": "/multisig-for-protocols/registration-and-documentation",
+    "title": "Multisig Registration & Documentation | SEAL",
+    "domain": "multisig-for-protocols",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Protocol Documentation",
+        "anchor": "protocol-documentation"
+      },
+      {
+        "level": 2,
+        "text": "Registration Template",
+        "anchor": "registration-template"
+      },
+      {
+        "level": 2,
+        "text": "Signer Verification Process",
+        "anchor": "signer-verification-process"
+      },
+      {
+        "level": 2,
+        "text": "Update Template",
+        "anchor": "update-template"
+      },
+      {
+        "level": 2,
+        "text": "Documentation Requirements",
+        "anchor": "documentation-requirements"
+      },
+      {
+        "level": 3,
+        "text": "Initial Registration",
+        "anchor": "initial-registration"
+      },
+      {
+        "level": 3,
+        "text": "Ongoing Maintenance",
+        "anchor": "ongoing-maintenance"
+      },
+      {
+        "level": 2,
+        "text": "Ongoing Management",
+        "anchor": "ongoing-management"
+      },
+      {
+        "level": 3,
+        "text": "Regular reviews",
+        "anchor": "regular-reviews"
+      },
+      {
+        "level": 3,
+        "text": "Signer changes",
+        "anchor": "signer-changes"
+      },
+      {
+        "level": 3,
+        "text": "Documentation updates",
+        "anchor": "documentation-updates"
+      },
+      {
+        "level": 2,
+        "text": "Related Documents",
+        "anchor": "related-documents"
+      }
+    ],
+    "lineCount": 170
+  },
+  {
+    "path": "/multisig-for-protocols/setup-and-configuration",
+    "title": "Multisig Setup & Configuration | SEAL",
+    "domain": "multisig-for-protocols",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Basic Setup",
+        "anchor": "basic-setup"
+      },
+      {
+        "level": 3,
+        "text": "EVM Networks (Ethereum, Base, etc.)",
+        "anchor": "evm-networks-ethereum-base-etc"
+      },
+      {
+        "level": 3,
+        "text": "Solana",
+        "anchor": "solana"
+      },
+      {
+        "level": 2,
+        "text": "Self-Hosted Multisig UI",
+        "anchor": "self-hosted-multisig-ui"
+      },
+      {
+        "level": 2,
+        "text": "Delegated Proposer",
+        "anchor": "delegated-proposer"
+      },
+      {
+        "level": 2,
+        "text": "Modules & Guards",
+        "anchor": "modules-guards"
+      },
+      {
+        "level": 3,
+        "text": "Allowance Module (Required for Treasury Multisigs)",
+        "anchor": "allowance-module-required-for-treasury-multisigs"
+      },
+      {
+        "level": 3,
+        "text": "Zodiac Delay Modifier (Time-Locks)",
+        "anchor": "zodiac-delay-modifier-time-locks"
+      },
+      {
+        "level": 3,
+        "text": "Other Modules",
+        "anchor": "other-modules"
+      },
+      {
+        "level": 2,
+        "text": "Contract-Level Controls",
+        "anchor": "contract-level-controls"
+      },
+      {
+        "level": 3,
+        "text": "Address Whitelisting",
+        "anchor": "address-whitelisting"
+      },
+      {
+        "level": 3,
+        "text": "Invariant Enforcement",
+        "anchor": "invariant-enforcement"
+      },
+      {
+        "level": 2,
+        "text": "Initial Testing",
+        "anchor": "initial-testing"
+      },
+      {
+        "level": 3,
+        "text": "Verify Basic Functionality",
+        "anchor": "verify-basic-functionality"
+      },
+      {
+        "level": 2,
+        "text": "Pre-Launch Checklist",
+        "anchor": "pre-launch-checklist"
+      },
+      {
+        "level": 3,
+        "text": "Practice on Testnet",
+        "anchor": "practice-on-testnet"
+      },
+      {
+        "level": 2,
+        "text": "Nested Safes",
+        "anchor": "nested-safes"
+      },
+      {
+        "level": 2,
+        "text": "Next Steps",
+        "anchor": "next-steps"
+      },
+      {
+        "level": 2,
+        "text": "Active Monitoring",
+        "anchor": "active-monitoring"
+      },
+      {
+        "level": 3,
+        "text": "Immutable Monitoring Channels",
+        "anchor": "immutable-monitoring-channels"
+      }
+    ],
+    "lineCount": 171
+  },
+  {
+    "path": "/multisig-for-protocols/use-case-specific-requirements",
+    "title": "Multisig Use Case Requirements | SEAL",
+    "domain": "multisig-for-protocols",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Treasury Multisigs",
+        "anchor": "treasury-multisigs"
+      },
+      {
+        "level": 3,
+        "text": "Key requirements:",
+        "anchor": "key-requirements"
+      },
+      {
+        "level": 3,
+        "text": "Hot/Cold Wallet Separation",
+        "anchor": "hotcold-wallet-separation"
+      },
+      {
+        "level": 3,
+        "text": "Wallet Segregation",
+        "anchor": "wallet-segregation"
+      },
+      {
+        "level": 3,
+        "text": "External Signer Requirements",
+        "anchor": "external-signer-requirements"
+      },
+      {
+        "level": 3,
+        "text": "External Transaction Monitoring",
+        "anchor": "external-transaction-monitoring"
+      },
+      {
+        "level": 2,
+        "text": "Emergency response Multisigs",
+        "anchor": "emergency-response-multisigs"
+      },
+      {
+        "level": 3,
+        "text": "Training & Drills:",
+        "anchor": "training-drills"
+      },
+      {
+        "level": 3,
+        "text": "Additional requirements:",
+        "anchor": "additional-requirements"
+      },
+      {
+        "level": 2,
+        "text": "Capital allocation Multisigs",
+        "anchor": "capital-allocation-multisigs"
+      },
+      {
+        "level": 3,
+        "text": "Operational constraints:",
+        "anchor": "operational-constraints"
+      },
+      {
+        "level": 2,
+        "text": "Smart contract control Multisigs",
+        "anchor": "smart-contract-control-multisigs"
+      },
+      {
+        "level": 3,
+        "text": "On-chain constraints:",
+        "anchor": "on-chain-constraints"
+      },
+      {
+        "level": 3,
+        "text": "Threshold considerations:",
+        "anchor": "threshold-considerations"
+      },
+      {
+        "level": 2,
+        "text": "Timelock Configuration",
+        "anchor": "timelock-configuration"
+      },
+      {
+        "level": 3,
+        "text": "Configuration",
+        "anchor": "configuration"
+      },
+      {
+        "level": 3,
+        "text": "Veto Quorum",
+        "anchor": "veto-quorum"
+      },
+      {
+        "level": 3,
+        "text": "Recommended Time-Lock Delays",
+        "anchor": "recommended-time-lock-delays"
+      },
+      {
+        "level": 3,
+        "text": "Simulation Consideration",
+        "anchor": "simulation-consideration"
+      }
+    ],
+    "lineCount": 130
+  },
+  {
+    "path": "/opsec/appendices/case-studies",
+    "title": "OpSec Case Studies",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Web3 Security Incidents",
+        "anchor": "web3-security-incidents"
+      },
+      {
+        "level": 3,
+        "text": "Case Study 1: Private Key Compromise",
+        "anchor": "case-study-1-private-key-compromise"
+      },
+      {
+        "level": 3,
+        "text": "Case Study 2: Social Engineering Attack",
+        "anchor": "case-study-2-social-engineering-attack"
+      },
+      {
+        "level": 2,
+        "text": "Tabletop Exercises",
+        "anchor": "tabletop-exercises"
+      },
+      {
+        "level": 3,
+        "text": "Exercise 1: Wallet Security Incident",
+        "anchor": "exercise-1-wallet-security-incident"
+      },
+      {
+        "level": 3,
+        "text": "Exercise 2: Smart Contract Vulnerability",
+        "anchor": "exercise-2-smart-contract-vulnerability"
+      },
+      {
+        "level": 3,
+        "text": "Exercise 3: Team Member Device Compromise",
+        "anchor": "exercise-3-team-member-device-compromise"
+      },
+      {
+        "level": 2,
+        "text": "Security Exercises for Teams",
+        "anchor": "security-exercises-for-teams"
+      },
+      {
+        "level": 3,
+        "text": "Red Team Exercise: Phishing Simulation",
+        "anchor": "red-team-exercise-phishing-simulation"
+      },
+      {
+        "level": 3,
+        "text": "Security Control Assessment: Key Management",
+        "anchor": "security-control-assessment-key-management"
+      }
+    ],
+    "lineCount": 231
+  },
+  {
+    "path": "/opsec/appendices/glossary",
+    "title": "Security Glossary",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "General Security Terms",
+        "anchor": "general-security-terms"
+      },
+      {
+        "level": 3,
+        "text": "A",
+        "anchor": "a"
+      },
+      {
+        "level": 3,
+        "text": "B",
+        "anchor": "b"
+      },
+      {
+        "level": 3,
+        "text": "C",
+        "anchor": "c"
+      },
+      {
+        "level": 3,
+        "text": "D",
+        "anchor": "d"
+      },
+      {
+        "level": 3,
+        "text": "E",
+        "anchor": "e"
+      },
+      {
+        "level": 3,
+        "text": "I",
+        "anchor": "i"
+      },
+      {
+        "level": 3,
+        "text": "L",
+        "anchor": "l"
+      },
+      {
+        "level": 3,
+        "text": "M",
+        "anchor": "m"
+      },
+      {
+        "level": 3,
+        "text": "P",
+        "anchor": "p"
+      },
+      {
+        "level": 3,
+        "text": "R",
+        "anchor": "r"
+      },
+      {
+        "level": 3,
+        "text": "S",
+        "anchor": "s"
+      },
+      {
+        "level": 3,
+        "text": "T",
+        "anchor": "t"
+      },
+      {
+        "level": 3,
+        "text": "V",
+        "anchor": "v"
+      },
+      {
+        "level": 2,
+        "text": "Web3-Specific Terms",
+        "anchor": "web3-specific-terms"
+      },
+      {
+        "level": 3,
+        "text": "A",
+        "anchor": "a"
+      },
+      {
+        "level": 3,
+        "text": "B",
+        "anchor": "b"
+      },
+      {
+        "level": 3,
+        "text": "C",
+        "anchor": "c"
+      },
+      {
+        "level": 3,
+        "text": "D",
+        "anchor": "d"
+      },
+      {
+        "level": 3,
+        "text": "E",
+        "anchor": "e"
+      },
+      {
+        "level": 3,
+        "text": "G",
+        "anchor": "g"
+      },
+      {
+        "level": 3,
+        "text": "H",
+        "anchor": "h"
+      },
+      {
+        "level": 3,
+        "text": "M",
+        "anchor": "m"
+      },
+      {
+        "level": 3,
+        "text": "N",
+        "anchor": "n"
+      },
+      {
+        "level": 3,
+        "text": "P",
+        "anchor": "p"
+      },
+      {
+        "level": 3,
+        "text": "S",
+        "anchor": "s"
+      },
+      {
+        "level": 3,
+        "text": "T",
+        "anchor": "t"
+      },
+      {
+        "level": 3,
+        "text": "W",
+        "anchor": "w"
+      }
+    ],
+    "lineCount": 232
+  },
+  {
+    "path": "/opsec/appendices/overview",
+    "title": "OpSec Resources & Appendices",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Overview of Appendices",
+        "anchor": "overview-of-appendices"
+      },
+      {
+        "level": 2,
+        "text": "Section Outline",
+        "anchor": "section-outline"
+      },
+      {
+        "level": 2,
+        "text": "Using the Appendices",
+        "anchor": "using-the-appendices"
+      },
+      {
+        "level": 2,
+        "text": "Web3-Specific Resources",
+        "anchor": "web3-specific-resources"
+      },
+      {
+        "level": 2,
+        "text": "Contributing to the Appendices",
+        "anchor": "contributing-to-the-appendices"
+      }
+    ],
+    "lineCount": 82
+  },
+  {
+    "path": "/opsec/appendices/policies",
+    "title": "Security Policy Templates",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Core Security Policies",
+        "anchor": "core-security-policies"
+      },
+      {
+        "level": 3,
+        "text": "Information Security Policy",
+        "anchor": "information-security-policy"
+      },
+      {
+        "level": 2,
+        "text": "Purpose",
+        "anchor": "purpose"
+      },
+      {
+        "level": 2,
+        "text": "Scope",
+        "anchor": "scope"
+      },
+      {
+        "level": 2,
+        "text": "Policy Statements",
+        "anchor": "policy-statements"
+      },
+      {
+        "level": 2,
+        "text": "Roles and Responsibilities",
+        "anchor": "roles-and-responsibilities"
+      },
+      {
+        "level": 2,
+        "text": "Compliance",
+        "anchor": "compliance"
+      },
+      {
+        "level": 2,
+        "text": "Related Documents",
+        "anchor": "related-documents"
+      },
+      {
+        "level": 3,
+        "text": "Access Control Policy",
+        "anchor": "access-control-policy"
+      },
+      {
+        "level": 2,
+        "text": "Purpose",
+        "anchor": "purpose"
+      },
+      {
+        "level": 2,
+        "text": "Scope",
+        "anchor": "scope"
+      },
+      {
+        "level": 2,
+        "text": "Policy Statements",
+        "anchor": "policy-statements"
+      },
+      {
+        "level": 2,
+        "text": "Implementation Guidelines",
+        "anchor": "implementation-guidelines"
+      },
+      {
+        "level": 2,
+        "text": "Exceptions",
+        "anchor": "exceptions"
+      },
+      {
+        "level": 2,
+        "text": "Web3-Specific Policies",
+        "anchor": "web3-specific-policies"
+      },
+      {
+        "level": 3,
+        "text": "Cryptocurrency Key Management Policy",
+        "anchor": "cryptocurrency-key-management-policy"
+      },
+      {
+        "level": 2,
+        "text": "Purpose",
+        "anchor": "purpose"
+      },
+      {
+        "level": 2,
+        "text": "Scope",
+        "anchor": "scope"
+      },
+      {
+        "level": 2,
+        "text": "Policy Statements",
+        "anchor": "policy-statements"
+      },
+      {
+        "level": 2,
+        "text": "Implementation Guidelines",
+        "anchor": "implementation-guidelines"
+      },
+      {
+        "level": 2,
+        "text": "Roles and Responsibilities",
+        "anchor": "roles-and-responsibilities"
+      },
+      {
+        "level": 3,
+        "text": "Smart Contract Deployment Policy",
+        "anchor": "smart-contract-deployment-policy"
+      },
+      {
+        "level": 2,
+        "text": "Purpose",
+        "anchor": "purpose"
+      },
+      {
+        "level": 2,
+        "text": "Scope",
+        "anchor": "scope"
+      },
+      {
+        "level": 2,
+        "text": "Policy Statements",
+        "anchor": "policy-statements"
+      },
+      {
+        "level": 2,
+        "text": "Implementation Guidelines",
+        "anchor": "implementation-guidelines"
+      },
+      {
+        "level": 2,
+        "text": "Roles and Responsibilities",
+        "anchor": "roles-and-responsibilities"
+      },
+      {
+        "level": 2,
+        "text": "Procedure Templates",
+        "anchor": "procedure-templates"
+      },
+      {
+        "level": 3,
+        "text": "Incident Response Procedure",
+        "anchor": "incident-response-procedure"
+      },
+      {
+        "level": 2,
+        "text": "Purpose",
+        "anchor": "purpose"
+      },
+      {
+        "level": 2,
+        "text": "Incident Detection and Reporting",
+        "anchor": "incident-detection-and-reporting"
+      },
+      {
+        "level": 2,
+        "text": "Incident Response Phases",
+        "anchor": "incident-response-phases"
+      },
+      {
+        "level": 2,
+        "text": "Communication Guidelines",
+        "anchor": "communication-guidelines"
+      },
+      {
+        "level": 2,
+        "text": "Specific Incident Types",
+        "anchor": "specific-incident-types"
+      },
+      {
+        "level": 3,
+        "text": "Key Ceremony Procedure",
+        "anchor": "key-ceremony-procedure"
+      },
+      {
+        "level": 2,
+        "text": "Purpose",
+        "anchor": "purpose"
+      },
+      {
+        "level": 2,
+        "text": "Preparation",
+        "anchor": "preparation"
+      },
+      {
+        "level": 2,
+        "text": "Key Generation Process",
+        "anchor": "key-generation-process"
+      },
+      {
+        "level": 2,
+        "text": "Security Controls",
+        "anchor": "security-controls"
+      },
+      {
+        "level": 2,
+        "text": "Post-Ceremony Actions",
+        "anchor": "post-ceremony-actions"
+      },
+      {
+        "level": 2,
+        "text": "Checklists and Forms",
+        "anchor": "checklists-and-forms"
+      },
+      {
+        "level": 3,
+        "text": "Security Assessment Checklist",
+        "anchor": "security-assessment-checklist"
+      },
+      {
+        "level": 2,
+        "text": "System Information",
+        "anchor": "system-information"
+      },
+      {
+        "level": 2,
+        "text": "Access Controls",
+        "anchor": "access-controls"
+      },
+      {
+        "level": 2,
+        "text": "Network Security",
+        "anchor": "network-security"
+      },
+      {
+        "level": 2,
+        "text": "Data Protection",
+        "anchor": "data-protection"
+      },
+      {
+        "level": 2,
+        "text": "System Security",
+        "anchor": "system-security"
+      },
+      {
+        "level": 2,
+        "text": "Physical Security",
+        "anchor": "physical-security"
+      },
+      {
+        "level": 2,
+        "text": "Incident Response",
+        "anchor": "incident-response"
+      },
+      {
+        "level": 2,
+        "text": "Additional Notes",
+        "anchor": "additional-notes"
+      }
+    ],
+    "lineCount": 407
+  },
+  {
+    "path": "/opsec/browser/overview",
+    "title": "Browser Security",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 22
+  },
+  {
+    "path": "/opsec/continuous-improvement-metrics",
+    "title": "Security Improvement Metrics | SEAL",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Post-Mortem & Lessons Learned",
+        "anchor": "post-mortem-lessons-learned"
+      },
+      {
+        "level": 3,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      },
+      {
+        "level": 2,
+        "text": "Security KPIs & Reporting",
+        "anchor": "security-kpis-reporting"
+      },
+      {
+        "level": 3,
+        "text": "Key Security Metrics",
+        "anchor": "key-security-metrics"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Metrics",
+        "anchor": "web3-specific-metrics"
+      },
+      {
+        "level": 2,
+        "text": "Continuous Assessment",
+        "anchor": "continuous-assessment"
+      },
+      {
+        "level": 3,
+        "text": "Assessment Types",
+        "anchor": "assessment-types"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Assessments",
+        "anchor": "web3-specific-assessments"
+      },
+      {
+        "level": 2,
+        "text": "Security Program Maturity",
+        "anchor": "security-program-maturity"
+      },
+      {
+        "level": 3,
+        "text": "Maturity Models",
+        "anchor": "maturity-models"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Maturity Considerations",
+        "anchor": "web3-specific-maturity-considerations"
+      },
+      {
+        "level": 2,
+        "text": "Building a Security-Conscious Culture",
+        "anchor": "building-a-security-conscious-culture"
+      },
+      {
+        "level": 3,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Cultural Considerations",
+        "anchor": "web3-specific-cultural-considerations"
+      }
+    ],
+    "lineCount": 179
+  },
+  {
+    "path": "/opsec/control-domains/organizational",
+    "title": "Organizational Security Controls",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Compliance & Regulatory Alignment",
+        "anchor": "compliance-regulatory-alignment"
+      },
+      {
+        "level": 3,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      },
+      {
+        "level": 2,
+        "text": "Supply-Chain Security",
+        "anchor": "supply-chain-security"
+      },
+      {
+        "level": 3,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      },
+      {
+        "level": 2,
+        "text": "Organizational Structure & Roles",
+        "anchor": "organizational-structure-roles"
+      },
+      {
+        "level": 3,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      }
+    ],
+    "lineCount": 118
+  },
+  {
+    "path": "/opsec/control-domains/organizational/compliance-regulatory-alignment",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/control-domains/organizational/supply-chain-security",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/control-domains/overview",
+    "title": "OpSec Control Domains",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Introduction to Control Domains",
+        "anchor": "introduction-to-control-domains"
+      },
+      {
+        "level": 2,
+        "text": "Implementing a Balanced Control Framework",
+        "anchor": "implementing-a-balanced-control-framework"
+      },
+      {
+        "level": 2,
+        "text": "Section Outline",
+        "anchor": "section-outline"
+      },
+      {
+        "level": 2,
+        "text": "Control Selection and Implementation",
+        "anchor": "control-selection-and-implementation"
+      },
+      {
+        "level": 2,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      }
+    ],
+    "lineCount": 93
+  },
+  {
+    "path": "/opsec/control-domains/people",
+    "title": "Personnel Security Controls",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Social-Engineering Defense",
+        "anchor": "social-engineering-defense"
+      },
+      {
+        "level": 3,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      },
+      {
+        "level": 2,
+        "text": "Insider-Threat Mitigation",
+        "anchor": "insider-threat-mitigation"
+      },
+      {
+        "level": 3,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      },
+      {
+        "level": 2,
+        "text": "Security Training & Culture",
+        "anchor": "security-training-culture"
+      },
+      {
+        "level": 3,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      },
+      {
+        "level": 2,
+        "text": "Personnel Security Measures",
+        "anchor": "personnel-security-measures"
+      },
+      {
+        "level": 3,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      }
+    ],
+    "lineCount": 146
+  },
+  {
+    "path": "/opsec/control-domains/people/insider-threat-mitigation",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/control-domains/people/security-training-culture",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/control-domains/people/social-engineering-defense",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/control-domains/physical-environmental",
+    "title": "Physical & Environmental Security",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Secure Workspace & Travel Security",
+        "anchor": "secure-workspace-travel-security"
+      },
+      {
+        "level": 3,
+        "text": "Secure Workspace Components",
+        "anchor": "secure-workspace-components"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps for Workspace Security",
+        "anchor": "implementation-steps-for-workspace-security"
+      },
+      {
+        "level": 3,
+        "text": "Travel Security Components",
+        "anchor": "travel-security-components"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps for Travel Security",
+        "anchor": "implementation-steps-for-travel-security"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      },
+      {
+        "level": 2,
+        "text": "Tamper-Evidence & \"Evil-Maid\" Attacks",
+        "anchor": "tamper-evidence-evil-maid-attacks"
+      },
+      {
+        "level": 3,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      },
+      {
+        "level": 2,
+        "text": "Physical Security of Critical Assets",
+        "anchor": "physical-security-of-critical-assets"
+      },
+      {
+        "level": 3,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      }
+    ],
+    "lineCount": 135
+  },
+  {
+    "path": "/opsec/control-domains/physical-environmental/secure-workspace-travel",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/control-domains/physical-environmental/tamper-evidence",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/control-domains/technical",
+    "title": "Technical Security Controls",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Device Hardening",
+        "anchor": "device-hardening"
+      },
+      {
+        "level": 3,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      },
+      {
+        "level": 2,
+        "text": "Network & Communication Security",
+        "anchor": "network-communication-security"
+      },
+      {
+        "level": 3,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      },
+      {
+        "level": 2,
+        "text": "Encrypted Storage & Backups",
+        "anchor": "encrypted-storage-backups"
+      },
+      {
+        "level": 3,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      },
+      {
+        "level": 2,
+        "text": "Two-Factor & Hardware Authentication",
+        "anchor": "two-factor-hardware-authentication"
+      },
+      {
+        "level": 3,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      },
+      {
+        "level": 2,
+        "text": "Cryptocurrency-Specific Controls",
+        "anchor": "cryptocurrency-specific-controls"
+      },
+      {
+        "level": 3,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Best Practices",
+        "anchor": "web3-specific-best-practices"
+      }
+    ],
+    "lineCount": 178
+  },
+  {
+    "path": "/opsec/control-domains/technical/cryptocurrency-controls",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/control-domains/technical/device-hardening",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/control-domains/technical/encrypted-storage-backups",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/control-domains/technical/network-communication-security",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/control-domains/technical/two-factor-hardware-auth",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/core-concepts/implementation-process",
+    "title": "OpSec Implementation Process | SEAL",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Relationship to Security Fundamentals",
+        "anchor": "relationship-to-security-fundamentals"
+      },
+      {
+        "level": 2,
+        "text": "1. Critical Asset Identification",
+        "anchor": "1-critical-asset-identification"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Actions",
+        "anchor": "implementation-actions"
+      },
+      {
+        "level": 2,
+        "text": "2. Practical Threat Analysis",
+        "anchor": "2-practical-threat-analysis"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Actions",
+        "anchor": "implementation-actions"
+      },
+      {
+        "level": 2,
+        "text": "3. Actionable Vulnerability Assessment",
+        "anchor": "3-actionable-vulnerability-assessment"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Actions",
+        "anchor": "implementation-actions"
+      },
+      {
+        "level": 2,
+        "text": "4. Contextual Risk Evaluation",
+        "anchor": "4-contextual-risk-evaluation"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Actions",
+        "anchor": "implementation-actions"
+      },
+      {
+        "level": 2,
+        "text": "5. Targeted Control Deployment",
+        "anchor": "5-targeted-control-deployment"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Actions",
+        "anchor": "implementation-actions"
+      }
+    ],
+    "lineCount": 174
+  },
+  {
+    "path": "/opsec/core-concepts/security-fundamentals",
+    "title": "Security Fundamentals",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Relationship to Implementation Process",
+        "anchor": "relationship-to-implementation-process"
+      },
+      {
+        "level": 2,
+        "text": "1. Layered Protection",
+        "anchor": "1-layered-protection"
+      },
+      {
+        "level": 3,
+        "text": "Practical Application",
+        "anchor": "practical-application"
+      },
+      {
+        "level": 2,
+        "text": "2. Minimal Access Scopes",
+        "anchor": "2-minimal-access-scopes"
+      },
+      {
+        "level": 3,
+        "text": "Practical Application",
+        "anchor": "practical-application"
+      },
+      {
+        "level": 2,
+        "text": "3. Information Flow Control",
+        "anchor": "3-information-flow-control"
+      },
+      {
+        "level": 3,
+        "text": "Practical Application",
+        "anchor": "practical-application"
+      },
+      {
+        "level": 2,
+        "text": "4. System Isolation",
+        "anchor": "4-system-isolation"
+      },
+      {
+        "level": 3,
+        "text": "Practical Application",
+        "anchor": "practical-application"
+      },
+      {
+        "level": 2,
+        "text": "5. Continuous Visibility",
+        "anchor": "5-continuous-visibility"
+      },
+      {
+        "level": 3,
+        "text": "Practical Application",
+        "anchor": "practical-application"
+      }
+    ],
+    "lineCount": 225
+  },
+  {
+    "path": "/opsec/core-concepts/web3-considerations",
+    "title": "Web3 Security Considerations",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Transparency vs. Privacy",
+        "anchor": "transparency-vs-privacy"
+      },
+      {
+        "level": 3,
+        "text": "Suggested steps",
+        "anchor": "suggested-steps"
+      },
+      {
+        "level": 2,
+        "text": "Immutability and Finality",
+        "anchor": "immutability-and-finality"
+      },
+      {
+        "level": 3,
+        "text": "Suggested steps",
+        "anchor": "suggested-steps"
+      },
+      {
+        "level": 2,
+        "text": "Self-Custody Responsibility",
+        "anchor": "self-custody-responsibility"
+      },
+      {
+        "level": 3,
+        "text": "Suggested steps",
+        "anchor": "suggested-steps"
+      },
+      {
+        "level": 2,
+        "text": "Decentralized Operations",
+        "anchor": "decentralized-operations"
+      },
+      {
+        "level": 3,
+        "text": "Suggested steps",
+        "anchor": "suggested-steps"
+      },
+      {
+        "level": 2,
+        "text": "Smart Contract Vulnerabilities",
+        "anchor": "smart-contract-vulnerabilities"
+      },
+      {
+        "level": 3,
+        "text": "Suggested steps",
+        "anchor": "suggested-steps"
+      },
+      {
+        "level": 2,
+        "text": "Community Dynamics",
+        "anchor": "community-dynamics"
+      },
+      {
+        "level": 3,
+        "text": "Suggested steps",
+        "anchor": "suggested-steps"
+      }
+    ],
+    "lineCount": 187
+  },
+  {
+    "path": "/opsec/endpoint/overview",
+    "title": "Endpoint Security",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 22
+  },
+  {
+    "path": "/opsec/google/overview",
+    "title": "Google Workspace Security",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Summary",
+        "anchor": "summary"
+      },
+      {
+        "level": 2,
+        "text": "For Individuals",
+        "anchor": "for-individuals"
+      },
+      {
+        "level": 3,
+        "text": "Account Security Checklist",
+        "anchor": "account-security-checklist"
+      },
+      {
+        "level": 3,
+        "text": "Extended Security Settings",
+        "anchor": "extended-security-settings"
+      },
+      {
+        "level": 3,
+        "text": "Advanced Protection Program",
+        "anchor": "advanced-protection-program"
+      },
+      {
+        "level": 3,
+        "text": "Best Practices & Ongoing Maintenance",
+        "anchor": "best-practices-ongoing-maintenance"
+      },
+      {
+        "level": 2,
+        "text": "For Team Members",
+        "anchor": "for-team-members"
+      },
+      {
+        "level": 2,
+        "text": "For Admins",
+        "anchor": "for-admins"
+      },
+      {
+        "level": 3,
+        "text": "Admin Settings (Workspace Configuration)",
+        "anchor": "admin-settings-workspace-configuration"
+      },
+      {
+        "level": 3,
+        "text": "Notes",
+        "anchor": "notes"
+      }
+    ],
+    "lineCount": 197
+  },
+  {
+    "path": "/opsec/improvement/post-mortem",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/improvement/security-kpis",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/integration/devsecops",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/integration/governance",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/integration/overview",
+    "title": "OpSec Integration",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Section Outline",
+        "anchor": "section-outline"
+      },
+      {
+        "level": 2,
+        "text": "DevSecOps Alignment",
+        "anchor": "devsecops-alignment"
+      },
+      {
+        "level": 3,
+        "text": "Key Integration Points",
+        "anchor": "key-integration-points"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      },
+      {
+        "level": 2,
+        "text": "Privacy Framework Alignment",
+        "anchor": "privacy-framework-alignment"
+      },
+      {
+        "level": 3,
+        "text": "Key Integration Points",
+        "anchor": "key-integration-points"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      },
+      {
+        "level": 2,
+        "text": "Governance Framework Alignment",
+        "anchor": "governance-framework-alignment"
+      },
+      {
+        "level": 3,
+        "text": "Key Integration Points",
+        "anchor": "key-integration-points"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      },
+      {
+        "level": 2,
+        "text": "Mapping to Security Standards",
+        "anchor": "mapping-to-security-standards"
+      },
+      {
+        "level": 3,
+        "text": "Common Security Standards",
+        "anchor": "common-security-standards"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Standards",
+        "anchor": "web3-specific-standards"
+      },
+      {
+        "level": 2,
+        "text": "Creating a Unified Security Approach",
+        "anchor": "creating-a-unified-security-approach"
+      },
+      {
+        "level": 3,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      }
+    ],
+    "lineCount": 185
+  },
+  {
+    "path": "/opsec/integration/privacy",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/mfa/overview",
+    "title": "Multi-Factor Authentication",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 22
+  },
+  {
+    "path": "/opsec/old/cloud-third-party/g-suite-security",
+    "title": "",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Account Security",
+        "anchor": "account-security"
+      },
+      {
+        "level": 3,
+        "text": "Multi-Factor Authentication (MFA)",
+        "anchor": "multi-factor-authentication-mfa"
+      },
+      {
+        "level": 3,
+        "text": "Strong Password Policies",
+        "anchor": "strong-password-policies"
+      },
+      {
+        "level": 2,
+        "text": "Access Management",
+        "anchor": "access-management"
+      },
+      {
+        "level": 3,
+        "text": "Role-Based Access Control (RBAC)",
+        "anchor": "role-based-access-control-rbac"
+      },
+      {
+        "level": 3,
+        "text": "Least Privilege Principle",
+        "anchor": "least-privilege-principle"
+      },
+      {
+        "level": 2,
+        "text": "Data Protection",
+        "anchor": "data-protection"
+      },
+      {
+        "level": 3,
+        "text": "Data Loss Prevention (DLP)",
+        "anchor": "data-loss-prevention-dlp"
+      },
+      {
+        "level": 3,
+        "text": "Encryption",
+        "anchor": "encryption"
+      },
+      {
+        "level": 2,
+        "text": "Monitoring and Alerts",
+        "anchor": "monitoring-and-alerts"
+      },
+      {
+        "level": 3,
+        "text": "Activity Monitoring",
+        "anchor": "activity-monitoring"
+      },
+      {
+        "level": 3,
+        "text": "Incident Response",
+        "anchor": "incident-response"
+      },
+      {
+        "level": 2,
+        "text": "Device Management",
+        "anchor": "device-management"
+      },
+      {
+        "level": 3,
+        "text": "Mobile Device Management (MDM)",
+        "anchor": "mobile-device-management-mdm"
+      },
+      {
+        "level": 2,
+        "text": "Communication and Collaboration",
+        "anchor": "communication-and-collaboration"
+      },
+      {
+        "level": 3,
+        "text": "Secure Sharing",
+        "anchor": "secure-sharing"
+      },
+      {
+        "level": 3,
+        "text": "Email Security",
+        "anchor": "email-security"
+      },
+      {
+        "level": 2,
+        "text": "Compliance and Governance",
+        "anchor": "compliance-and-governance"
+      },
+      {
+        "level": 3,
+        "text": "Compliance Settings",
+        "anchor": "compliance-settings"
+      }
+    ],
+    "lineCount": 116
+  },
+  {
+    "path": "/opsec/old/cloud-third-party/overview",
+    "title": "",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Introduction",
+        "anchor": "introduction"
+      },
+      {
+        "level": 2,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 2,
+        "text": "Risk-Based Approach",
+        "anchor": "risk-based-approach"
+      },
+      {
+        "level": 2,
+        "text": "Web3 Considerations",
+        "anchor": "web3-considerations"
+      }
+    ],
+    "lineCount": 66
+  },
+  {
+    "path": "/opsec/old/core-opsec-principles",
+    "title": "",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Defense in Depth",
+        "anchor": "defense-in-depth"
+      },
+      {
+        "level": 3,
+        "text": "Implementation",
+        "anchor": "implementation"
+      },
+      {
+        "level": 2,
+        "text": "Principle of Least Privilege",
+        "anchor": "principle-of-least-privilege"
+      },
+      {
+        "level": 3,
+        "text": "Implementation",
+        "anchor": "implementation"
+      },
+      {
+        "level": 2,
+        "text": "Need-to-Know Basis",
+        "anchor": "need-to-know-basis"
+      },
+      {
+        "level": 3,
+        "text": "Implementation",
+        "anchor": "implementation"
+      },
+      {
+        "level": 2,
+        "text": "Threat Modeling for OpSec",
+        "anchor": "threat-modeling-for-opsec"
+      },
+      {
+        "level": 3,
+        "text": "Implementation",
+        "anchor": "implementation"
+      },
+      {
+        "level": 2,
+        "text": "Risk Assessment and Management",
+        "anchor": "risk-assessment-and-management"
+      },
+      {
+        "level": 3,
+        "text": "Implementation",
+        "anchor": "implementation"
+      },
+      {
+        "level": 2,
+        "text": "Continuous Monitoring and Improvement",
+        "anchor": "continuous-monitoring-and-improvement"
+      },
+      {
+        "level": 3,
+        "text": "Implementation",
+        "anchor": "implementation"
+      },
+      {
+        "level": 2,
+        "text": "Web3-Specific OpSec Principles",
+        "anchor": "web3-specific-opsec-principles"
+      },
+      {
+        "level": 3,
+        "text": "Transparency vs. Privacy",
+        "anchor": "transparency-vs-privacy"
+      },
+      {
+        "level": 3,
+        "text": "Immutability and Finality",
+        "anchor": "immutability-and-finality"
+      },
+      {
+        "level": 3,
+        "text": "Self-Custody Responsibility",
+        "anchor": "self-custody-responsibility"
+      },
+      {
+        "level": 3,
+        "text": "Implementation",
+        "anchor": "implementation"
+      }
+    ],
+    "lineCount": 191
+  },
+  {
+    "path": "/opsec/old/data-protection/overview",
+    "title": "",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Introduction",
+        "anchor": "introduction"
+      },
+      {
+        "level": 2,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 2,
+        "text": "Risk-Based Approach",
+        "anchor": "risk-based-approach"
+      },
+      {
+        "level": 2,
+        "text": "Web3 Considerations",
+        "anchor": "web3-considerations"
+      }
+    ],
+    "lineCount": 70
+  },
+  {
+    "path": "/opsec/old/device-endpoint-security/overview",
+    "title": "",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Introduction",
+        "anchor": "introduction"
+      },
+      {
+        "level": 2,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 2,
+        "text": "Risk-Based Approach",
+        "anchor": "risk-based-approach"
+      },
+      {
+        "level": 2,
+        "text": "Web3 Considerations",
+        "anchor": "web3-considerations"
+      }
+    ],
+    "lineCount": 68
+  },
+  {
+    "path": "/opsec/old/device-endpoint-security/standard-operating-environment",
+    "title": "",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Key Components of an SOE",
+        "anchor": "key-components-of-an-soe"
+      },
+      {
+        "level": 3,
+        "text": "Device Configuration",
+        "anchor": "device-configuration"
+      },
+      {
+        "level": 3,
+        "text": "User Access Controls",
+        "anchor": "user-access-controls"
+      },
+      {
+        "level": 3,
+        "text": "Security Software",
+        "anchor": "security-software"
+      },
+      {
+        "level": 3,
+        "text": "Data Management",
+        "anchor": "data-management"
+      },
+      {
+        "level": 3,
+        "text": "Network Security",
+        "anchor": "network-security"
+      }
+    ],
+    "lineCount": 74
+  },
+  {
+    "path": "/opsec/old/digital-identity-access/overview",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/old/digital-identity-access/password-secrets-management",
+    "title": "",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Best Practices",
+        "anchor": "best-practices"
+      },
+      {
+        "level": 2,
+        "text": "Password and Key Security",
+        "anchor": "password-and-key-security"
+      },
+      {
+        "level": 3,
+        "text": "Passphrases",
+        "anchor": "passphrases"
+      },
+      {
+        "level": 3,
+        "text": "Password Cards (e.g., Qwertycards)",
+        "anchor": "password-cards-eg-qwertycards"
+      },
+      {
+        "level": 3,
+        "text": "Non-default BIP-44 Derivation Path",
+        "anchor": "non-default-bip-44-derivation-path"
+      },
+      {
+        "level": 3,
+        "text": "Password Managers",
+        "anchor": "password-managers"
+      },
+      {
+        "level": 2,
+        "text": "Key Storage and Recovery",
+        "anchor": "key-storage-and-recovery"
+      },
+      {
+        "level": 3,
+        "text": "Memory and Notebook",
+        "anchor": "memory-and-notebook"
+      },
+      {
+        "level": 3,
+        "text": "Paper Wallets",
+        "anchor": "paper-wallets"
+      },
+      {
+        "level": 3,
+        "text": "Encrypted Drives",
+        "anchor": "encrypted-drives"
+      },
+      {
+        "level": 3,
+        "text": "Back-ups / Rotation / Recovery",
+        "anchor": "back-ups-rotation-recovery"
+      },
+      {
+        "level": 3,
+        "text": "Shamir Backup",
+        "anchor": "shamir-backup"
+      },
+      {
+        "level": 2,
+        "text": "Authentication and Access Control",
+        "anchor": "authentication-and-access-control"
+      },
+      {
+        "level": 3,
+        "text": "2FA / MFA (Multi-Factor Authentication)",
+        "anchor": "2fa-mfa-multi-factor-authentication"
+      },
+      {
+        "level": 3,
+        "text": "SSO (Single Sign-On)",
+        "anchor": "sso-single-sign-on"
+      },
+      {
+        "level": 3,
+        "text": "Trusted Key Management System (KMS)",
+        "anchor": "trusted-key-management-system-kms"
+      },
+      {
+        "level": 3,
+        "text": "Hardware Security Keys",
+        "anchor": "hardware-security-keys"
+      },
+      {
+        "level": 2,
+        "text": "Biometric Security",
+        "anchor": "biometric-security"
+      },
+      {
+        "level": 3,
+        "text": "Fingerprint Scanners",
+        "anchor": "fingerprint-scanners"
+      },
+      {
+        "level": 3,
+        "text": "Facial Recognition",
+        "anchor": "facial-recognition"
+      }
+    ],
+    "lineCount": 130
+  },
+  {
+    "path": "/opsec/old/digital-identity-access/sim-swapping",
+    "title": "",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Stop Using SMS-Based 2FA",
+        "anchor": "stop-using-sms-based-2fa"
+      },
+      {
+        "level": 2,
+        "text": "Switch to a High-Security Carrier",
+        "anchor": "switch-to-a-high-security-carrier"
+      },
+      {
+        "level": 3,
+        "text": "USA",
+        "anchor": "usa"
+      },
+      {
+        "level": 2,
+        "text": "Place a Note on Your Carrier Account",
+        "anchor": "place-a-note-on-your-carrier-account"
+      }
+    ],
+    "lineCount": 98
+  },
+  {
+    "path": "/opsec/old/governance-program-management",
+    "title": "Governance Program Management",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Security Policies & Roles",
+        "anchor": "security-policies-roles"
+      },
+      {
+        "level": 3,
+        "text": "Key Security Policies",
+        "anchor": "key-security-policies"
+      },
+      {
+        "level": 3,
+        "text": "Essential Security Roles",
+        "anchor": "essential-security-roles"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 2,
+        "text": "Third-Party/Vendor Governance",
+        "anchor": "third-partyvendor-governance"
+      },
+      {
+        "level": 3,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 2,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      },
+      {
+        "level": 3,
+        "text": "Best Practices for Web3 Organizations",
+        "anchor": "best-practices-for-web3-organizations"
+      }
+    ],
+    "lineCount": 103
+  },
+  {
+    "path": "/opsec/old/governance/security-policies-roles",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/old/governance/third-party-vendor-governance",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/old/human-centered-security/detecting-and-mitigating-insider-threats",
+    "title": "",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "What Are Insider Threats?",
+        "anchor": "what-are-insider-threats"
+      },
+      {
+        "level": 2,
+        "text": "Understanding Insider Threat Motivations",
+        "anchor": "understanding-insider-threat-motivations"
+      },
+      {
+        "level": 3,
+        "text": "Financial Motivations",
+        "anchor": "financial-motivations"
+      },
+      {
+        "level": 3,
+        "text": "Coercion and Social Engineering",
+        "anchor": "coercion-and-social-engineering"
+      },
+      {
+        "level": 3,
+        "text": "Ideological or Political Reasons",
+        "anchor": "ideological-or-political-reasons"
+      },
+      {
+        "level": 3,
+        "text": "Personal Grievances",
+        "anchor": "personal-grievances"
+      },
+      {
+        "level": 3,
+        "text": "Lack of Awareness",
+        "anchor": "lack-of-awareness"
+      },
+      {
+        "level": 3,
+        "text": "Some Examples",
+        "anchor": "some-examples"
+      },
+      {
+        "level": 2,
+        "text": "Detecting Insider Threats",
+        "anchor": "detecting-insider-threats"
+      },
+      {
+        "level": 3,
+        "text": "Monitoring and Analytics",
+        "anchor": "monitoring-and-analytics"
+      },
+      {
+        "level": 3,
+        "text": "Access Controls",
+        "anchor": "access-controls"
+      },
+      {
+        "level": 3,
+        "text": "Training and Awareness",
+        "anchor": "training-and-awareness"
+      },
+      {
+        "level": 2,
+        "text": "Mitigating Insider Threats",
+        "anchor": "mitigating-insider-threats"
+      },
+      {
+        "level": 3,
+        "text": "Incident Response Plan",
+        "anchor": "incident-response-plan"
+      },
+      {
+        "level": 3,
+        "text": "Technical Controls",
+        "anchor": "technical-controls"
+      },
+      {
+        "level": 3,
+        "text": "Project Policies",
+        "anchor": "project-policies"
+      },
+      {
+        "level": 3,
+        "text": "Behavioral and Cultural Measures",
+        "anchor": "behavioral-and-cultural-measures"
+      }
+    ],
+    "lineCount": 145
+  },
+  {
+    "path": "/opsec/old/human-centered-security/overview",
+    "title": "",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Introduction",
+        "anchor": "introduction"
+      },
+      {
+        "level": 2,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 2,
+        "text": "Intersection with Awareness",
+        "anchor": "intersection-with-awareness"
+      },
+      {
+        "level": 2,
+        "text": "Risk-Based Approach",
+        "anchor": "risk-based-approach"
+      }
+    ],
+    "lineCount": 63
+  },
+  {
+    "path": "/opsec/old/human-centered-security/personal-opsec",
+    "title": "",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Digital Footprint Management",
+        "anchor": "digital-footprint-management"
+      },
+      {
+        "level": 3,
+        "text": "Social Media Practices",
+        "anchor": "social-media-practices"
+      },
+      {
+        "level": 3,
+        "text": "Public Information Minimization",
+        "anchor": "public-information-minimization"
+      },
+      {
+        "level": 2,
+        "text": "Personal Device Security",
+        "anchor": "personal-device-security"
+      },
+      {
+        "level": 3,
+        "text": "Home Network Security",
+        "anchor": "home-network-security"
+      },
+      {
+        "level": 3,
+        "text": "Personal Device Hardening",
+        "anchor": "personal-device-hardening"
+      },
+      {
+        "level": 2,
+        "text": "Secure Communication Practices",
+        "anchor": "secure-communication-practices"
+      },
+      {
+        "level": 2,
+        "text": "Physical Security Awareness",
+        "anchor": "physical-security-awareness"
+      },
+      {
+        "level": 2,
+        "text": "Web3-Specific Personal OpSec",
+        "anchor": "web3-specific-personal-opsec"
+      },
+      {
+        "level": 3,
+        "text": "Cryptocurrency Security",
+        "anchor": "cryptocurrency-security"
+      },
+      {
+        "level": 3,
+        "text": "Identity Separation",
+        "anchor": "identity-separation"
+      },
+      {
+        "level": 2,
+        "text": "Personal Threat Modeling",
+        "anchor": "personal-threat-modeling"
+      },
+      {
+        "level": 2,
+        "text": "Balance and Sustainability",
+        "anchor": "balance-and-sustainability"
+      },
+      {
+        "level": 2,
+        "text": "Reporting and Support",
+        "anchor": "reporting-and-support"
+      }
+    ],
+    "lineCount": 114
+  },
+  {
+    "path": "/opsec/old/human-centered-security/social-engineering-defense",
+    "title": "",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Understanding Social Engineering",
+        "anchor": "understanding-social-engineering"
+      },
+      {
+        "level": 2,
+        "text": "General Defense Strategies",
+        "anchor": "general-defense-strategies"
+      },
+      {
+        "level": 2,
+        "text": "Specific Defensive Considerations",
+        "anchor": "specific-defensive-considerations"
+      },
+      {
+        "level": 3,
+        "text": "Phishing Defense",
+        "anchor": "phishing-defense"
+      },
+      {
+        "level": 3,
+        "text": "Voice and In-Person Manipulation Defense",
+        "anchor": "voice-and-in-person-manipulation-defense"
+      },
+      {
+        "level": 3,
+        "text": "Physical Security Considerations",
+        "anchor": "physical-security-considerations"
+      },
+      {
+        "level": 2,
+        "text": "Cross-Function Collaboration",
+        "anchor": "cross-function-collaboration"
+      },
+      {
+        "level": 2,
+        "text": "Integration with Threat Intelligence",
+        "anchor": "integration-with-threat-intelligence"
+      },
+      {
+        "level": 2,
+        "text": "Incident Response for Social Engineering Attacks",
+        "anchor": "incident-response-for-social-engineering-attacks"
+      },
+      {
+        "level": 2,
+        "text": "Building Resilience",
+        "anchor": "building-resilience"
+      }
+    ],
+    "lineCount": 102
+  },
+  {
+    "path": "/opsec/old/human-centered-security/travel-security",
+    "title": "",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Pre-Travel Preparation",
+        "anchor": "pre-travel-preparation"
+      },
+      {
+        "level": 3,
+        "text": "Risk Assessment",
+        "anchor": "risk-assessment"
+      },
+      {
+        "level": 3,
+        "text": "Device Preparation",
+        "anchor": "device-preparation"
+      },
+      {
+        "level": 3,
+        "text": "Documentation and Emergency Planning",
+        "anchor": "documentation-and-emergency-planning"
+      },
+      {
+        "level": 2,
+        "text": "In-Transit Security",
+        "anchor": "in-transit-security"
+      },
+      {
+        "level": 2,
+        "text": "On-Location Security",
+        "anchor": "on-location-security"
+      },
+      {
+        "level": 3,
+        "text": "Physical Security",
+        "anchor": "physical-security"
+      },
+      {
+        "level": 3,
+        "text": "Digital Security",
+        "anchor": "digital-security"
+      },
+      {
+        "level": 2,
+        "text": "Post-Travel Procedures",
+        "anchor": "post-travel-procedures"
+      },
+      {
+        "level": 2,
+        "text": "Special Considerations for High-Risk Locations",
+        "anchor": "special-considerations-for-high-risk-locations"
+      },
+      {
+        "level": 2,
+        "text": "Web3-Specific Travel Security",
+        "anchor": "web3-specific-travel-security"
+      },
+      {
+        "level": 2,
+        "text": "Integration with Other Security Frameworks",
+        "anchor": "integration-with-other-security-frameworks"
+      }
+    ],
+    "lineCount": 111
+  },
+  {
+    "path": "/opsec/old/incident-response-recovery",
+    "title": "Incident Response Recovery",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Playbooks for Common Incidents",
+        "anchor": "playbooks-for-common-incidents"
+      },
+      {
+        "level": 3,
+        "text": "Device Loss or Theft",
+        "anchor": "device-loss-or-theft"
+      },
+      {
+        "level": 3,
+        "text": "Account Compromise",
+        "anchor": "account-compromise"
+      },
+      {
+        "level": 3,
+        "text": "Malware Infection",
+        "anchor": "malware-infection"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Incidents",
+        "anchor": "web3-specific-incidents"
+      },
+      {
+        "level": 2,
+        "text": "Containment, Eradication & Recovery Steps",
+        "anchor": "containment-eradication-recovery-steps"
+      },
+      {
+        "level": 3,
+        "text": "Containment",
+        "anchor": "containment"
+      },
+      {
+        "level": 3,
+        "text": "Eradication",
+        "anchor": "eradication"
+      },
+      {
+        "level": 3,
+        "text": "Recovery",
+        "anchor": "recovery"
+      },
+      {
+        "level": 2,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      },
+      {
+        "level": 2,
+        "text": "Documentation and Reporting",
+        "anchor": "documentation-and-reporting"
+      },
+      {
+        "level": 2,
+        "text": "Post-Incident Activities",
+        "anchor": "post-incident-activities"
+      }
+    ],
+    "lineCount": 190
+  },
+  {
+    "path": "/opsec/old/incident-response/containment-recovery",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/old/incident-response/playbooks",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/old/lifecycle/countermeasures",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/old/lifecycle/identify",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/old/lifecycle/overview",
+    "title": "Lifecycle",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Overview of the OpSec Lifecycle",
+        "anchor": "overview-of-the-opsec-lifecycle"
+      },
+      {
+        "level": 2,
+        "text": "Section Outline",
+        "anchor": "section-outline"
+      },
+      {
+        "level": 2,
+        "text": "Phase 1: Identify Information & Assets",
+        "anchor": "phase-1-identify-information-assets"
+      },
+      {
+        "level": 2,
+        "text": "Phase 2: Threat Modeling & Analysis",
+        "anchor": "phase-2-threat-modeling-analysis"
+      },
+      {
+        "level": 2,
+        "text": "Phase 3: Vulnerability Assessment",
+        "anchor": "phase-3-vulnerability-assessment"
+      },
+      {
+        "level": 2,
+        "text": "Phase 4: Risk Assessment & Prioritization",
+        "anchor": "phase-4-risk-assessment-prioritization"
+      },
+      {
+        "level": 2,
+        "text": "Phase 5: Countermeasure Selection & Implementation",
+        "anchor": "phase-5-countermeasure-selection-implementation"
+      },
+      {
+        "level": 2,
+        "text": "Continuous Improvement",
+        "anchor": "continuous-improvement"
+      },
+      {
+        "level": 2,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      }
+    ],
+    "lineCount": 140
+  },
+  {
+    "path": "/opsec/old/lifecycle/risk-prioritization",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/old/lifecycle/threat-modeling",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/old/lifecycle/vulnerability-assessment",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/old/monitoring-detection",
+    "title": "Monitoring Detection",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Log Management & SIEM",
+        "anchor": "log-management-siem"
+      },
+      {
+        "level": 3,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      },
+      {
+        "level": 2,
+        "text": "Alert Thresholds & Dashboards",
+        "anchor": "alert-thresholds-dashboards"
+      },
+      {
+        "level": 3,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      },
+      {
+        "level": 2,
+        "text": "Threat Detection Approaches",
+        "anchor": "threat-detection-approaches"
+      },
+      {
+        "level": 3,
+        "text": "Signature-Based Detection",
+        "anchor": "signature-based-detection"
+      },
+      {
+        "level": 3,
+        "text": "Behavioral Detection",
+        "anchor": "behavioral-detection"
+      },
+      {
+        "level": 3,
+        "text": "Heuristic Detection",
+        "anchor": "heuristic-detection"
+      },
+      {
+        "level": 3,
+        "text": "Threat Hunting",
+        "anchor": "threat-hunting"
+      },
+      {
+        "level": 2,
+        "text": "Web3-Specific Monitoring",
+        "anchor": "web3-specific-monitoring"
+      },
+      {
+        "level": 3,
+        "text": "On-Chain Monitoring",
+        "anchor": "on-chain-monitoring"
+      },
+      {
+        "level": 3,
+        "text": "Off-Chain Monitoring",
+        "anchor": "off-chain-monitoring"
+      }
+    ],
+    "lineCount": 157
+  },
+  {
+    "path": "/opsec/old/monitoring/alert-thresholds",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/old/monitoring/log-management",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/old/network-communication/overview",
+    "title": "",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Introduction",
+        "anchor": "introduction"
+      },
+      {
+        "level": 2,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 2,
+        "text": "Risk-Based Approach",
+        "anchor": "risk-based-approach"
+      },
+      {
+        "level": 2,
+        "text": "Web3 Considerations",
+        "anchor": "web3-considerations"
+      }
+    ],
+    "lineCount": 71
+  },
+  {
+    "path": "/opsec/old/network-communication/telegram",
+    "title": "",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "1. Use Two-Step Verification",
+        "anchor": "1-use-two-step-verification"
+      },
+      {
+        "level": 2,
+        "text": "2. Enable End-to-End Encryption for Secret Chats",
+        "anchor": "2-enable-end-to-end-encryption-for-secret-chats"
+      },
+      {
+        "level": 2,
+        "text": "3. Set Self-Destruct Timers for Messages",
+        "anchor": "3-set-self-destruct-timers-for-messages"
+      },
+      {
+        "level": 2,
+        "text": "4. Control Your Online Presence",
+        "anchor": "4-control-your-online-presence"
+      },
+      {
+        "level": 2,
+        "text": "5. Limit Who Can Add You to Groups",
+        "anchor": "5-limit-who-can-add-you-to-groups"
+      },
+      {
+        "level": 2,
+        "text": "6. Use a Strong Passcode Lock",
+        "anchor": "6-use-a-strong-passcode-lock"
+      },
+      {
+        "level": 2,
+        "text": "7. Review Active Sessions Regularly",
+        "anchor": "7-review-active-sessions-regularly"
+      },
+      {
+        "level": 2,
+        "text": "8. Avoid Clicking on Suspicious Links",
+        "anchor": "8-avoid-clicking-on-suspicious-links"
+      },
+      {
+        "level": 2,
+        "text": "9. Control Data Sharing",
+        "anchor": "9-control-data-sharing"
+      },
+      {
+        "level": 2,
+        "text": "10. Be Cautious with Public Channels and Bots",
+        "anchor": "10-be-cautious-with-public-channels-and-bots"
+      },
+      {
+        "level": 2,
+        "text": "11. Regularly Update the App",
+        "anchor": "11-regularly-update-the-app"
+      },
+      {
+        "level": 2,
+        "text": "12. Avoid Using Third-Party Telegram Apps",
+        "anchor": "12-avoid-using-third-party-telegram-apps"
+      },
+      {
+        "level": 2,
+        "text": "13. Backup Your Two-Step Verification Password",
+        "anchor": "13-backup-your-two-step-verification-password"
+      },
+      {
+        "level": 2,
+        "text": "14. Disable Automatic Media Download",
+        "anchor": "14-disable-automatic-media-download"
+      }
+    ],
+    "lineCount": 103
+  },
+  {
+    "path": "/opsec/old/network-communication/wireless-security",
+    "title": "",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Key Components of Wireless Security",
+        "anchor": "key-components-of-wireless-security"
+      },
+      {
+        "level": 3,
+        "text": "Secure Network Configuration",
+        "anchor": "secure-network-configuration"
+      },
+      {
+        "level": 3,
+        "text": "Access Control",
+        "anchor": "access-control"
+      },
+      {
+        "level": 3,
+        "text": "Monitoring and Intrusion Detection",
+        "anchor": "monitoring-and-intrusion-detection"
+      },
+      {
+        "level": 3,
+        "text": "Device Security",
+        "anchor": "device-security"
+      },
+      {
+        "level": 2,
+        "text": "Best Practices for Wireless Security",
+        "anchor": "best-practices-for-wireless-security"
+      },
+      {
+        "level": 3,
+        "text": "Network Security",
+        "anchor": "network-security"
+      },
+      {
+        "level": 3,
+        "text": "Guest Networks",
+        "anchor": "guest-networks"
+      }
+    ],
+    "lineCount": 72
+  },
+  {
+    "path": "/opsec/old/overview",
+    "title": "",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Framework Contents",
+        "anchor": "framework-contents"
+      }
+    ],
+    "lineCount": 55
+  },
+  {
+    "path": "/opsec/old/physical-security/overview",
+    "title": "",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Best Practices",
+        "anchor": "best-practices"
+      },
+      {
+        "level": 2,
+        "text": "Secure Traveling",
+        "anchor": "secure-traveling"
+      },
+      {
+        "level": 3,
+        "text": "Preparation",
+        "anchor": "preparation"
+      },
+      {
+        "level": 3,
+        "text": "During Travel",
+        "anchor": "during-travel"
+      },
+      {
+        "level": 3,
+        "text": "Border Security",
+        "anchor": "border-security"
+      },
+      {
+        "level": 2,
+        "text": "Preventing \"Wrench Attacks\"",
+        "anchor": "preventing-wrench-attacks"
+      },
+      {
+        "level": 3,
+        "text": "Mitigation Strategies",
+        "anchor": "mitigation-strategies"
+      },
+      {
+        "level": 2,
+        "text": "Home Security",
+        "anchor": "home-security"
+      },
+      {
+        "level": 2,
+        "text": "Device Protection",
+        "anchor": "device-protection"
+      },
+      {
+        "level": 3,
+        "text": "Hardware Security",
+        "anchor": "hardware-security"
+      },
+      {
+        "level": 3,
+        "text": "Environmental Considerations",
+        "anchor": "environmental-considerations"
+      },
+      {
+        "level": 2,
+        "text": "Emergency Contacts",
+        "anchor": "emergency-contacts"
+      }
+    ],
+    "lineCount": 98
+  },
+  {
+    "path": "/opsec/old/risk-management-overview",
+    "title": "Risk Management Overview",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Risk Assessment Process",
+        "anchor": "risk-assessment-process"
+      },
+      {
+        "level": 3,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Prioritization Methodology",
+        "anchor": "prioritization-methodology"
+      },
+      {
+        "level": 2,
+        "text": "Trade-off Analysis",
+        "anchor": "trade-off-analysis"
+      },
+      {
+        "level": 3,
+        "text": "Key Considerations",
+        "anchor": "key-considerations"
+      },
+      {
+        "level": 3,
+        "text": "Decision-Making Framework",
+        "anchor": "decision-making-framework"
+      },
+      {
+        "level": 2,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      },
+      {
+        "level": 3,
+        "text": "Unique Risk Factors",
+        "anchor": "unique-risk-factors"
+      },
+      {
+        "level": 3,
+        "text": "Best Practices for Web3 Organizations",
+        "anchor": "best-practices-for-web3-organizations"
+      },
+      {
+        "level": 3,
+        "text": "Pinnipeds Inc. Risk Assessment",
+        "anchor": "pinnipeds-inc-risk-assessment"
+      },
+      {
+        "level": 2,
+        "text": "Further Reading & Tools",
+        "anchor": "further-reading-tools"
+      }
+    ],
+    "lineCount": 179
+  },
+  {
+    "path": "/opsec/old/risk-management/overview",
+    "title": "Risk Management",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Section Outline",
+        "anchor": "section-outline"
+      },
+      {
+        "level": 2,
+        "text": "Risk Assessment Process",
+        "anchor": "risk-assessment-process"
+      },
+      {
+        "level": 3,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 3,
+        "text": "Implementation Steps",
+        "anchor": "implementation-steps"
+      },
+      {
+        "level": 3,
+        "text": "Prioritization Methodology",
+        "anchor": "prioritization-methodology"
+      },
+      {
+        "level": 2,
+        "text": "Trade-off Analysis",
+        "anchor": "trade-off-analysis"
+      },
+      {
+        "level": 3,
+        "text": "Key Considerations",
+        "anchor": "key-considerations"
+      },
+      {
+        "level": 3,
+        "text": "Decision-Making Framework",
+        "anchor": "decision-making-framework"
+      },
+      {
+        "level": 2,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      },
+      {
+        "level": 3,
+        "text": "Unique Risk Factors",
+        "anchor": "unique-risk-factors"
+      },
+      {
+        "level": 3,
+        "text": "Best Practices for Web3 Organizations",
+        "anchor": "best-practices-for-web3-organizations"
+      },
+      {
+        "level": 3,
+        "text": "Pinnipeds Inc. Risk Assessment",
+        "anchor": "pinnipeds-inc-risk-assessment"
+      },
+      {
+        "level": 2,
+        "text": "Further Reading & Tools",
+        "anchor": "further-reading-tools"
+      }
+    ],
+    "lineCount": 190
+  },
+  {
+    "path": "/opsec/old/risk-management/risk-assessment-prioritization",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/old/risk-management/trade-off-analysis",
+    "title": "",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/opsec/old/threat-modeling-overview",
+    "title": "Threat Modeling Overview",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Why is it important",
+        "anchor": "why-is-it-important"
+      },
+      {
+        "level": 3,
+        "text": "Common pitfalls & examples",
+        "anchor": "common-pitfalls-examples"
+      },
+      {
+        "level": 2,
+        "text": "Practical guidance",
+        "anchor": "practical-guidance"
+      },
+      {
+        "level": 3,
+        "text": "Asset inventory",
+        "anchor": "asset-inventory"
+      },
+      {
+        "level": 3,
+        "text": "Pinnipeds Inc. Asset Inventory",
+        "anchor": "pinnipeds-inc-asset-inventory"
+      },
+      {
+        "level": 3,
+        "text": "Adversary analysis",
+        "anchor": "adversary-analysis"
+      },
+      {
+        "level": 3,
+        "text": "Pinnipeds Inc. Adversary Analysis",
+        "anchor": "pinnipeds-inc-adversary-analysis"
+      },
+      {
+        "level": 3,
+        "text": "Attack vector mapping",
+        "anchor": "attack-vector-mapping"
+      },
+      {
+        "level": 3,
+        "text": "Pinnipeds Inc. Attack Vector Analysis",
+        "anchor": "pinnipeds-inc-attack-vector-analysis"
+      },
+      {
+        "level": 2,
+        "text": "Implementation details",
+        "anchor": "implementation-details"
+      },
+      {
+        "level": 2,
+        "text": "Practical Frameworks and Tools",
+        "anchor": "practical-frameworks-and-tools"
+      },
+      {
+        "level": 3,
+        "text": "STRIDE Threat Categorization Framework",
+        "anchor": "stride-threat-categorization-framework"
+      },
+      {
+        "level": 3,
+        "text": "Attack Trees: Visualizing Attack Paths",
+        "anchor": "attack-trees-visualizing-attack-paths"
+      },
+      {
+        "level": 2,
+        "text": "Further Reading & Tools",
+        "anchor": "further-reading-tools"
+      },
+      {
+        "level": 3,
+        "text": "Frameworks & References",
+        "anchor": "frameworks-references"
+      },
+      {
+        "level": 3,
+        "text": "Visualization & Modeling Tools",
+        "anchor": "visualization-modeling-tools"
+      }
+    ],
+    "lineCount": 261
+  },
+  {
+    "path": "/opsec/old/web3-specific-opsec/overview",
+    "title": "",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Introduction",
+        "anchor": "introduction"
+      },
+      {
+        "level": 2,
+        "text": "Key Components",
+        "anchor": "key-components"
+      },
+      {
+        "level": 2,
+        "text": "Risk-Based Approach",
+        "anchor": "risk-based-approach"
+      },
+      {
+        "level": 2,
+        "text": "Intersection with Traditional Security",
+        "anchor": "intersection-with-traditional-security"
+      }
+    ],
+    "lineCount": 72
+  },
+  {
+    "path": "/opsec/overview",
+    "title": "Operational Security",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Core Components",
+        "anchor": "core-components"
+      },
+      {
+        "level": 2,
+        "text": "Additional contents",
+        "anchor": "additional-contents"
+      },
+      {
+        "level": 2,
+        "text": "What is Operational Security?",
+        "anchor": "what-is-operational-security"
+      },
+      {
+        "level": 2,
+        "text": "Security Fundamentals",
+        "anchor": "security-fundamentals"
+      },
+      {
+        "level": 2,
+        "text": "Operational Implementation Process",
+        "anchor": "operational-implementation-process"
+      },
+      {
+        "level": 2,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      },
+      {
+        "level": 2,
+        "text": "Using This Framework",
+        "anchor": "using-this-framework"
+      }
+    ],
+    "lineCount": 134
+  },
+  {
+    "path": "/opsec/passwords/overview",
+    "title": "Password Management",
+    "domain": "opsec",
+    "headers": [],
+    "lineCount": 22
+  },
+  {
+    "path": "/opsec/principles/five-steps",
+    "title": "Five OpSec Steps",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "1. Identification of Critical Information",
+        "anchor": "1-identification-of-critical-information"
+      },
+      {
+        "level": 3,
+        "text": "Implementation",
+        "anchor": "implementation"
+      },
+      {
+        "level": 2,
+        "text": "2. Threat Analysis",
+        "anchor": "2-threat-analysis"
+      },
+      {
+        "level": 3,
+        "text": "Implementation",
+        "anchor": "implementation"
+      },
+      {
+        "level": 2,
+        "text": "3. Vulnerability Assessment",
+        "anchor": "3-vulnerability-assessment"
+      },
+      {
+        "level": 3,
+        "text": "Implementation",
+        "anchor": "implementation"
+      },
+      {
+        "level": 2,
+        "text": "4. Risk Assessment",
+        "anchor": "4-risk-assessment"
+      },
+      {
+        "level": 3,
+        "text": "Implementation",
+        "anchor": "implementation"
+      },
+      {
+        "level": 2,
+        "text": "5. Countermeasure Implementation",
+        "anchor": "5-countermeasure-implementation"
+      },
+      {
+        "level": 3,
+        "text": "Implementation",
+        "anchor": "implementation"
+      }
+    ],
+    "lineCount": 116
+  },
+  {
+    "path": "/opsec/principles/overview",
+    "title": "OpSec Principles & Concepts",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "What is Operational Security?",
+        "anchor": "what-is-operational-security"
+      },
+      {
+        "level": 2,
+        "text": "Core Principles",
+        "anchor": "core-principles"
+      },
+      {
+        "level": 2,
+        "text": "The Five Steps of the OpSec Process",
+        "anchor": "the-five-steps-of-the-opsec-process"
+      },
+      {
+        "level": 2,
+        "text": "Web3-Specific Considerations",
+        "anchor": "web3-specific-considerations"
+      }
+    ],
+    "lineCount": 84
+  },
+  {
+    "path": "/opsec/principles/principles",
+    "title": "OpSec Core Principles",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "1. Defense in Depth",
+        "anchor": "1-defense-in-depth"
+      },
+      {
+        "level": 3,
+        "text": "Implementation",
+        "anchor": "implementation"
+      },
+      {
+        "level": 2,
+        "text": "2. Principle of Least Privilege",
+        "anchor": "2-principle-of-least-privilege"
+      },
+      {
+        "level": 3,
+        "text": "Implementation",
+        "anchor": "implementation"
+      },
+      {
+        "level": 2,
+        "text": "3. Need-to-Know Basis",
+        "anchor": "3-need-to-know-basis"
+      },
+      {
+        "level": 3,
+        "text": "Implementation",
+        "anchor": "implementation"
+      },
+      {
+        "level": 2,
+        "text": "4. Compartmentalization",
+        "anchor": "4-compartmentalization"
+      },
+      {
+        "level": 3,
+        "text": "Implementation",
+        "anchor": "implementation"
+      },
+      {
+        "level": 2,
+        "text": "5. Continuous Monitoring and Improvement",
+        "anchor": "5-continuous-monitoring-and-improvement"
+      },
+      {
+        "level": 3,
+        "text": "Implementation",
+        "anchor": "implementation"
+      }
+    ],
+    "lineCount": 138
+  },
+  {
+    "path": "/opsec/principles/web3-considerations",
+    "title": "Web3 OpSec Considerations",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Transparency vs. Privacy",
+        "anchor": "transparency-vs-privacy"
+      },
+      {
+        "level": 3,
+        "text": "Implementation",
+        "anchor": "implementation"
+      },
+      {
+        "level": 2,
+        "text": "Immutability and Finality",
+        "anchor": "immutability-and-finality"
+      },
+      {
+        "level": 3,
+        "text": "Implementation",
+        "anchor": "implementation"
+      },
+      {
+        "level": 2,
+        "text": "Self-Custody Responsibility",
+        "anchor": "self-custody-responsibility"
+      },
+      {
+        "level": 3,
+        "text": "Implementation",
+        "anchor": "implementation"
+      },
+      {
+        "level": 2,
+        "text": "Decentralized Operations",
+        "anchor": "decentralized-operations"
+      },
+      {
+        "level": 3,
+        "text": "Implementation",
+        "anchor": "implementation"
+      },
+      {
+        "level": 2,
+        "text": "Smart Contract Vulnerabilities",
+        "anchor": "smart-contract-vulnerabilities"
+      },
+      {
+        "level": 3,
+        "text": "Implementation",
+        "anchor": "implementation"
+      },
+      {
+        "level": 2,
+        "text": "Community Dynamics",
+        "anchor": "community-dynamics"
+      },
+      {
+        "level": 3,
+        "text": "Implementation",
+        "anchor": "implementation"
+      }
+    ],
+    "lineCount": 110
+  },
+  {
+    "path": "/opsec/travel/guide",
+    "title": "Travel Security Guide",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Before traveling",
+        "anchor": "before-traveling"
+      },
+      {
+        "level": 3,
+        "text": "**Perform a quick threat model**",
+        "anchor": "perform-a-quick-threat-model"
+      },
+      {
+        "level": 3,
+        "text": "**Secure devices with encryption & updates**",
+        "anchor": "secure-devices-with-encryption-updates"
+      },
+      {
+        "level": 3,
+        "text": "**Back up and prepare for loss**",
+        "anchor": "back-up-and-prepare-for-loss"
+      },
+      {
+        "level": 3,
+        "text": "**Protect Accounts with 2FA redundancy**",
+        "anchor": "protect-accounts-with-2fa-redundancy"
+      },
+      {
+        "level": 3,
+        "text": "**Secure your wallets and keys**",
+        "anchor": "secure-your-wallets-and-keys"
+      },
+      {
+        "level": 3,
+        "text": "**Lock down phones**",
+        "anchor": "lock-down-phones"
+      },
+      {
+        "level": 3,
+        "text": "**Minimize digital footprint & social visibility**",
+        "anchor": "minimize-digital-footprint-social-visibility"
+      },
+      {
+        "level": 3,
+        "text": "**Plan emergency and incident responses**",
+        "anchor": "plan-emergency-and-incident-responses"
+      },
+      {
+        "level": 2,
+        "text": "While traveling",
+        "anchor": "while-traveling"
+      },
+      {
+        "level": 3,
+        "text": "**Network safety – avoid untrusted Wi-Fi & Bluetooth**",
+        "anchor": "network-safety-avoid-untrusted-wi-fi-bluetooth"
+      },
+      {
+        "level": 3,
+        "text": "**Device handling – keep them close and protected**",
+        "anchor": "device-handling-keep-them-close-and-protected"
+      },
+      {
+        "level": 3,
+        "text": "**Beware of public USB charging**",
+        "anchor": "beware-of-public-usb-charging"
+      },
+      {
+        "level": 3,
+        "text": "**Screen privacy and social engineering**",
+        "anchor": "screen-privacy-and-social-engineering"
+      },
+      {
+        "level": 3,
+        "text": "**Maintain OpSec in public**",
+        "anchor": "maintain-opsec-in-public"
+      },
+      {
+        "level": 3,
+        "text": "**Traveling with high-value crypto or duties**",
+        "anchor": "traveling-with-high-value-crypto-or-duties"
+      },
+      {
+        "level": 3,
+        "text": "While presenting or doing public appearances",
+        "anchor": "while-presenting-or-doing-public-appearances"
+      },
+      {
+        "level": 3,
+        "text": "**Physical safety and common sense**",
+        "anchor": "physical-safety-and-common-sense"
+      },
+      {
+        "level": 2,
+        "text": "Returning home",
+        "anchor": "returning-home"
+      },
+      {
+        "level": 3,
+        "text": "**Secure your accounts and passwords**",
+        "anchor": "secure-your-accounts-and-passwords"
+      },
+      {
+        "level": 3,
+        "text": "**Inspect and clean your devices**",
+        "anchor": "inspect-and-clean-your-devices"
+      },
+      {
+        "level": 3,
+        "text": "**Post-travel review**",
+        "anchor": "post-travel-review"
+      },
+      {
+        "level": 2,
+        "text": "Additional precautions for high-risk travelers",
+        "anchor": "additional-precautions-for-high-risk-travelers"
+      },
+      {
+        "level": 3,
+        "text": "**Use loaner or \"burner\" devices**",
+        "anchor": "use-loaner-or-burner-devices"
+      },
+      {
+        "level": 3,
+        "text": "**Plan for customs and border checks**",
+        "anchor": "plan-for-customs-and-border-checks"
+      },
+      {
+        "level": 3,
+        "text": "**Enhanced device protections**",
+        "anchor": "enhanced-device-protections"
+      },
+      {
+        "level": 3,
+        "text": "**Protect crypto keys with multi-party controls**",
+        "anchor": "protect-crypto-keys-with-multi-party-controls"
+      },
+      {
+        "level": 3,
+        "text": "**Post-trip device rebuilding**",
+        "anchor": "post-trip-device-rebuilding"
+      },
+      {
+        "level": 2,
+        "text": "Conclusion",
+        "anchor": "conclusion"
+      }
+    ],
+    "lineCount": 609
+  },
+  {
+    "path": "/opsec/travel/overview",
+    "title": "Operational Security While Traveling | SEAL",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Three-phase Security Approach",
+        "anchor": "three-phase-security-approach"
+      }
+    ],
+    "lineCount": 61
+  },
+  {
+    "path": "/opsec/travel/tldr",
+    "title": "Travel Security Quick Reference",
+    "domain": "opsec",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Before traveling",
+        "anchor": "before-traveling"
+      },
+      {
+        "level": 2,
+        "text": "While traveling",
+        "anchor": "while-traveling"
+      },
+      {
+        "level": 2,
+        "text": "Returning home",
+        "anchor": "returning-home"
+      },
+      {
+        "level": 2,
+        "text": "High-risk traveler extras",
+        "anchor": "high-risk-traveler-extras"
+      }
+    ],
+    "lineCount": 93
+  },
+  {
+    "path": "/privacy/data-removal-services",
+    "title": "Data Removal Services",
+    "domain": "privacy",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Steps to Remove Your Data",
+        "anchor": "steps-to-remove-your-data"
+      },
+      {
+        "level": 2,
+        "text": "Data Removal Services",
+        "anchor": "data-removal-services"
+      },
+      {
+        "level": 2,
+        "text": "Best Practices",
+        "anchor": "best-practices"
+      }
+    ],
+    "lineCount": 69
+  },
+  {
+    "path": "/privacy/digital-footprint",
+    "title": "Managing Your Digital Footprint | SEAL",
+    "domain": "privacy",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Understanding Your Digital Footprint",
+        "anchor": "understanding-your-digital-footprint"
+      },
+      {
+        "level": 2,
+        "text": "Managing Your Digital Footprint",
+        "anchor": "managing-your-digital-footprint"
+      },
+      {
+        "level": 2,
+        "text": "Tools for Managing Your Digital Footprint",
+        "anchor": "tools-for-managing-your-digital-footprint"
+      },
+      {
+        "level": 2,
+        "text": "Best Practices",
+        "anchor": "best-practices"
+      }
+    ],
+    "lineCount": 77
+  },
+  {
+    "path": "/privacy/encrypted-communication-tools",
+    "title": "Encrypted Communication Tools | SEAL",
+    "domain": "privacy",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Popular Encrypted Communication Tools",
+        "anchor": "popular-encrypted-communication-tools"
+      },
+      {
+        "level": 2,
+        "text": "Best Practices for Encrypted Communication",
+        "anchor": "best-practices-for-encrypted-communication"
+      },
+      {
+        "level": 2,
+        "text": "Additional Resources",
+        "anchor": "additional-resources"
+      }
+    ],
+    "lineCount": 87
+  },
+  {
+    "path": "/privacy/financial-privacy-services",
+    "title": "Financial Privacy Services",
+    "domain": "privacy",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Tools for Financial Privacy",
+        "anchor": "tools-for-financial-privacy"
+      },
+      {
+        "level": 2,
+        "text": "Strategies for Financial Privacy",
+        "anchor": "strategies-for-financial-privacy"
+      }
+    ],
+    "lineCount": 61
+  },
+  {
+    "path": "/privacy/overview",
+    "title": "Privacy",
+    "domain": "privacy",
+    "headers": [],
+    "lineCount": 28
+  },
+  {
+    "path": "/privacy/privacy-focused-operating-systems-tools",
+    "title": "Privacy-Focused Operating Systems | SEAL",
+    "domain": "privacy",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Privacy-Focused Operating Systems",
+        "anchor": "privacy-focused-operating-systems"
+      },
+      {
+        "level": 2,
+        "text": "Privacy-Focused Tools",
+        "anchor": "privacy-focused-tools"
+      }
+    ],
+    "lineCount": 64
+  },
+  {
+    "path": "/privacy/secure-browsing",
+    "title": "Secure Browsing",
+    "domain": "privacy",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Best Practices for Secure Browsing",
+        "anchor": "best-practices-for-secure-browsing"
+      },
+      {
+        "level": 2,
+        "text": "Tools for Secure Browsing",
+        "anchor": "tools-for-secure-browsing"
+      },
+      {
+        "level": 2,
+        "text": "Secure Search Engines",
+        "anchor": "secure-search-engines"
+      },
+      {
+        "level": 2,
+        "text": "Best Practices",
+        "anchor": "best-practices"
+      }
+    ],
+    "lineCount": 86
+  },
+  {
+    "path": "/privacy/vpn-services",
+    "title": "VPN Services",
+    "domain": "privacy",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Choosing a VPN Service",
+        "anchor": "choosing-a-vpn-service"
+      },
+      {
+        "level": 2,
+        "text": "Recommended VPN Services",
+        "anchor": "recommended-vpn-services"
+      },
+      {
+        "level": 2,
+        "text": "Best Practices for Using a VPN",
+        "anchor": "best-practices-for-using-a-vpn"
+      }
+    ],
+    "lineCount": 91
+  },
+  {
+    "path": "/safe-harbor/on-chain-adoption-guide",
+    "title": "Safe Harbor On-Chain Adoption Guide | SEAL",
+    "domain": "safe-harbor",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Why On-Chain Adoption Matters",
+        "anchor": "why-on-chain-adoption-matters"
+      },
+      {
+        "level": 2,
+        "text": "How On-Chain Adoption Works",
+        "anchor": "how-on-chain-adoption-works"
+      },
+      {
+        "level": 2,
+        "text": "Three Ways to Deploy and Register",
+        "anchor": "three-ways-to-deploy-and-register"
+      },
+      {
+        "level": 3,
+        "text": "1. SEAL Self-Adoption Website + Script/Multisig Registration",
+        "anchor": "1-seal-self-adoption-website-scriptmultisig-registration"
+      },
+      {
+        "level": 3,
+        "text": "2. Multisig Registration (Gnosis Safe)",
+        "anchor": "2-multisig-registration-gnosis-safe"
+      },
+      {
+        "level": 3,
+        "text": "3. Foundry Script / Custom Code",
+        "anchor": "3-foundry-script-custom-code"
+      },
+      {
+        "level": 2,
+        "text": "V3 Contract Addresses",
+        "anchor": "v3-contract-addresses"
+      }
+    ],
+    "lineCount": 141
+  },
+  {
+    "path": "/safe-harbor/overview",
+    "title": "SEAL Whitehat Safe Harbor | SEAL",
+    "domain": "safe-harbor",
+    "headers": [
+      {
+        "level": 2,
+        "text": "What is Safe Harbor?",
+        "anchor": "what-is-safe-harbor"
+      },
+      {
+        "level": 2,
+        "text": "Why we started Safe Harbor",
+        "anchor": "why-we-started-safe-harbor"
+      },
+      {
+        "level": 2,
+        "text": "Vetted by industry leaders and top Web3 lawyers",
+        "anchor": "vetted-by-industry-leaders-and-top-web3-lawyers"
+      },
+      {
+        "level": 2,
+        "text": "Who's Adopted Safe Harbor",
+        "anchor": "whos-adopted-safe-harbor"
+      },
+      {
+        "level": 2,
+        "text": "How Safe Harbor Protects Your Protocol",
+        "anchor": "how-safe-harbor-protects-your-protocol"
+      },
+      {
+        "level": 2,
+        "text": "How to Adopt Safe Harbor (3 Options)",
+        "anchor": "how-to-adopt-safe-harbor-3-options"
+      },
+      {
+        "level": 3,
+        "text": "1. Get White-Glove Onboarding (Free)",
+        "anchor": "1-get-white-glove-onboarding-free"
+      },
+      {
+        "level": 3,
+        "text": "2. Self-Adopt Using Our Guide",
+        "anchor": "2-self-adopt-using-our-guide"
+      },
+      {
+        "level": 3,
+        "text": "3. Adopt Through a Third-Party Provider",
+        "anchor": "3-adopt-through-a-third-party-provider"
+      },
+      {
+        "level": 2,
+        "text": "Proven Results: Whitehats Have Recovered $150M+",
+        "anchor": "proven-results-whitehats-have-recovered-150m"
+      },
+      {
+        "level": 2,
+        "text": "FAQ",
+        "anchor": "faq"
+      }
+    ],
+    "lineCount": 254
+  },
+  {
+    "path": "/safe-harbor/scope-terms",
+    "title": "Safe Harbor Scope Terms",
+    "domain": "safe-harbor",
+    "headers": [
+      {
+        "level": 2,
+        "text": "1. Asset Recovery Address",
+        "anchor": "1-asset-recovery-address"
+      },
+      {
+        "level": 2,
+        "text": "2. Security Contact",
+        "anchor": "2-security-contact"
+      },
+      {
+        "level": 2,
+        "text": "3. Assets Under Scope",
+        "anchor": "3-assets-under-scope"
+      },
+      {
+        "level": 2,
+        "text": "4. Bounty Terms",
+        "anchor": "4-bounty-terms"
+      },
+      {
+        "level": 3,
+        "text": "4.1 Bounty Calculation",
+        "anchor": "41-bounty-calculation"
+      },
+      {
+        "level": 3,
+        "text": "4.2 Bounty Percentage",
+        "anchor": "42-bounty-percentage"
+      },
+      {
+        "level": 3,
+        "text": "4.3 Bounty Cap (USD)",
+        "anchor": "43-bounty-cap-usd"
+      },
+      {
+        "level": 3,
+        "text": "4.4 Aggregate Bounty Cap (USD)",
+        "anchor": "44-aggregate-bounty-cap-usd"
+      },
+      {
+        "level": 3,
+        "text": "4.5 Retainable",
+        "anchor": "45-retainable"
+      },
+      {
+        "level": 2,
+        "text": "5. Identity Verification",
+        "anchor": "5-identity-verification"
+      },
+      {
+        "level": 2,
+        "text": "6. Diligence Requirements",
+        "anchor": "6-diligence-requirements"
+      }
+    ],
+    "lineCount": 160
+  },
+  {
+    "path": "/safe-harbor/self-adoption-guide",
+    "title": "Safe Harbor Self-Adoption Guide | SEAL",
+    "domain": "safe-harbor",
+    "headers": [
+      {
+        "level": 2,
+        "text": "1. Scope Definition",
+        "anchor": "1-scope-definition"
+      },
+      {
+        "level": 2,
+        "text": "2. DAO Proposal (If applicable)",
+        "anchor": "2-dao-proposal-if-applicable"
+      },
+      {
+        "level": 2,
+        "text": "3. On-Chain Adoption",
+        "anchor": "3-on-chain-adoption"
+      },
+      {
+        "level": 2,
+        "text": "4. Update Terms of Service & Docs",
+        "anchor": "4-update-terms-of-service-docs"
+      },
+      {
+        "level": 3,
+        "text": "Terms of Service (TOS)",
+        "anchor": "terms-of-service-tos"
+      },
+      {
+        "level": 3,
+        "text": "Documentation",
+        "anchor": "documentation"
+      },
+      {
+        "level": 2,
+        "text": "5. Announcement",
+        "anchor": "5-announcement"
+      }
+    ],
+    "lineCount": 141
+  },
+  {
+    "path": "/safe-harbor/self-checklist",
+    "title": "Safe Harbor Self-Checklist",
+    "domain": "safe-harbor",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Can Safe Harbor Help Your Protocol?",
+        "anchor": "can-safe-harbor-help-your-protocol"
+      },
+      {
+        "level": 2,
+        "text": "What Does Adoption Involve?",
+        "anchor": "what-does-adoption-involve"
+      },
+      {
+        "level": 2,
+        "text": "Ready to Get Started?",
+        "anchor": "ready-to-get-started"
+      }
+    ],
+    "lineCount": 79
+  },
+  {
+    "path": "/safe-harbor/whitehat",
+    "title": "Whitehat Rescue Guide",
+    "domain": "safe-harbor",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Why You Should Care",
+        "anchor": "why-you-should-care"
+      },
+      {
+        "level": 2,
+        "text": "Whitehat Adoption",
+        "anchor": "whitehat-adoption"
+      },
+      {
+        "level": 2,
+        "text": "In the Event of a Hack",
+        "anchor": "in-the-event-of-a-hack"
+      },
+      {
+        "level": 3,
+        "text": "Pre-Intervention",
+        "anchor": "pre-intervention"
+      },
+      {
+        "level": 3,
+        "text": "Post-Intervention",
+        "anchor": "post-intervention"
+      }
+    ],
+    "lineCount": 104
+  },
+  {
+    "path": "/secure-software-development/code-reviews-peer-audits",
+    "title": "Code Reviews & Peer Audits",
+    "domain": "secure-software-development",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Best Practices for Code Reviews",
+        "anchor": "best-practices-for-code-reviews"
+      },
+      {
+        "level": 2,
+        "text": "Conducting Effective Code Reviews",
+        "anchor": "conducting-effective-code-reviews"
+      }
+    ],
+    "lineCount": 62
+  },
+  {
+    "path": "/secure-software-development/overview",
+    "title": "Secure Software Development | SEAL",
+    "domain": "secure-software-development",
+    "headers": [],
+    "lineCount": 29
+  },
+  {
+    "path": "/secure-software-development/secure-code-repositories-version-control",
+    "title": "Secure Code Repositories & Version Control | SEAL",
+    "domain": "secure-software-development",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Best Practices for Secure Code Repositories",
+        "anchor": "best-practices-for-secure-code-repositories"
+      },
+      {
+        "level": 2,
+        "text": "Secure Version Control Practices",
+        "anchor": "secure-version-control-practices"
+      }
+    ],
+    "lineCount": 59
+  },
+  {
+    "path": "/secure-software-development/secure-coding-standards-guidelines",
+    "title": "Secure Coding Standards & Guidelines | SEAL",
+    "domain": "secure-software-development",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Secure Coding Standards",
+        "anchor": "secure-coding-standards"
+      },
+      {
+        "level": 2,
+        "text": "Guidelines for Secure Coding",
+        "anchor": "guidelines-for-secure-coding"
+      }
+    ],
+    "lineCount": 67
+  },
+  {
+    "path": "/secure-software-development/threat-modeling-secure-design-principles",
+    "title": "Threat Modeling & Secure Design | SEAL",
+    "domain": "secure-software-development",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Threat Modeling",
+        "anchor": "threat-modeling"
+      },
+      {
+        "level": 2,
+        "text": "Secure Design Principles",
+        "anchor": "secure-design-principles"
+      }
+    ],
+    "lineCount": 73
+  },
+  {
+    "path": "/security-automation/compliance-checks",
+    "title": "Automated Compliance Checks",
+    "domain": "security-automation",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Benefits of Automated Compliance Checks",
+        "anchor": "benefits-of-automated-compliance-checks"
+      },
+      {
+        "level": 2,
+        "text": "Tools for Automated Compliance Checks",
+        "anchor": "tools-for-automated-compliance-checks"
+      },
+      {
+        "level": 2,
+        "text": "Best Practices",
+        "anchor": "best-practices"
+      }
+    ],
+    "lineCount": 74
+  },
+  {
+    "path": "/security-automation/infrastructure-as-code",
+    "title": "Infrastructure as Code Security | SEAL",
+    "domain": "security-automation",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Benefits of Automating Security in IaC",
+        "anchor": "benefits-of-automating-security-in-iac"
+      },
+      {
+        "level": 2,
+        "text": "Best Practices for Secure IaC",
+        "anchor": "best-practices-for-secure-iac"
+      },
+      {
+        "level": 2,
+        "text": "Tools for Automating Security in IaC",
+        "anchor": "tools-for-automating-security-in-iac"
+      }
+    ],
+    "lineCount": 84
+  },
+  {
+    "path": "/security-automation/overview",
+    "title": "Security Automation",
+    "domain": "security-automation",
+    "headers": [],
+    "lineCount": 31
+  },
+  {
+    "path": "/security-automation/threat-detection-response",
+    "title": "Threat Detection & Response | SEAL",
+    "domain": "security-automation",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Guidelines for Threat Detection and Response",
+        "anchor": "guidelines-for-threat-detection-and-response"
+      },
+      {
+        "level": 2,
+        "text": "Example Best Practice",
+        "anchor": "example-best-practice"
+      },
+      {
+        "level": 2,
+        "text": "Incident Example",
+        "anchor": "incident-example"
+      },
+      {
+        "level": 2,
+        "text": "Sample Process",
+        "anchor": "sample-process"
+      }
+    ],
+    "lineCount": 70
+  },
+  {
+    "path": "/security-testing/formal-verification",
+    "title": "Formal Verification",
+    "domain": "security-testing",
+    "headers": [
+      {
+        "level": 2,
+        "text": "What is Formal Verification?",
+        "anchor": "what-is-formal-verification"
+      },
+      {
+        "level": 2,
+        "text": "Symbolic Execution",
+        "anchor": "symbolic-execution"
+      },
+      {
+        "level": 3,
+        "text": "1. Explore All Possible Paths",
+        "anchor": "1-explore-all-possible-paths"
+      },
+      {
+        "level": 3,
+        "text": "2. Convert Paths to Mathematical Expressions",
+        "anchor": "2-convert-paths-to-mathematical-expressions"
+      },
+      {
+        "level": 3,
+        "text": "3. Feed to SMT/SAT Solver",
+        "anchor": "3-feed-to-smtsat-solver"
+      },
+      {
+        "level": 2,
+        "text": "Real-World Example: Complex Math Functions",
+        "anchor": "real-world-example-complex-math-functions"
+      },
+      {
+        "level": 3,
+        "text": "Formal Verification Test with Halmos",
+        "anchor": "formal-verification-test-with-halmos"
+      },
+      {
+        "level": 3,
+        "text": "The Power of Formal Verification",
+        "anchor": "the-power-of-formal-verification"
+      },
+      {
+        "level": 2,
+        "text": "Limitations",
+        "anchor": "limitations"
+      },
+      {
+        "level": 3,
+        "text": "Path Explosion Problem",
+        "anchor": "path-explosion-problem"
+      },
+      {
+        "level": 3,
+        "text": "Significant Effort Required",
+        "anchor": "significant-effort-required"
+      },
+      {
+        "level": 3,
+        "text": "Specification Challenge",
+        "anchor": "specification-challenge"
+      },
+      {
+        "level": 3,
+        "text": "Solver Limitations",
+        "anchor": "solver-limitations"
+      },
+      {
+        "level": 2,
+        "text": "Tools and Frameworks",
+        "anchor": "tools-and-frameworks"
+      },
+      {
+        "level": 2,
+        "text": "References",
+        "anchor": "references"
+      }
+    ],
+    "lineCount": 213
+  },
+  {
+    "path": "/security-testing/fuzz-testing",
+    "title": "Fuzz Testing",
+    "domain": "security-testing",
+    "headers": [
+      {
+        "level": 2,
+        "text": "What is Fuzz Testing?",
+        "anchor": "what-is-fuzz-testing"
+      },
+      {
+        "level": 2,
+        "text": "Why Normal Unit Tests Aren't Enough",
+        "anchor": "why-normal-unit-tests-arent-enough"
+      },
+      {
+        "level": 2,
+        "text": "Stateless Fuzz Tests",
+        "anchor": "stateless-fuzz-tests"
+      },
+      {
+        "level": 2,
+        "text": "Stateful vs Stateless Fuzzing",
+        "anchor": "stateful-vs-stateless-fuzzing"
+      },
+      {
+        "level": 3,
+        "text": "The Hidden Bug",
+        "anchor": "the-hidden-bug"
+      },
+      {
+        "level": 3,
+        "text": "Stateful Fuzz Tests (Invariant Tests)",
+        "anchor": "stateful-fuzz-tests-invariant-tests"
+      },
+      {
+        "level": 2,
+        "text": "Real-World Smart Contract Invariants",
+        "anchor": "real-world-smart-contract-invariants"
+      },
+      {
+        "level": 2,
+        "text": "Fuzz Testing Tools",
+        "anchor": "fuzz-testing-tools"
+      },
+      {
+        "level": 2,
+        "text": "Best Practices",
+        "anchor": "best-practices"
+      },
+      {
+        "level": 2,
+        "text": "References",
+        "anchor": "references"
+      }
+    ],
+    "lineCount": 263
+  },
+  {
+    "path": "/security-testing/integration-testing",
+    "title": "Integration Testing",
+    "domain": "security-testing",
+    "headers": [
+      {
+        "level": 2,
+        "text": "What are Fork Tests?",
+        "anchor": "what-are-fork-tests"
+      },
+      {
+        "level": 2,
+        "text": "Why Fork Testing Matters",
+        "anchor": "why-fork-testing-matters"
+      },
+      {
+        "level": 2,
+        "text": "How to Implement Fork Tests",
+        "anchor": "how-to-implement-fork-tests"
+      },
+      {
+        "level": 2,
+        "text": "References",
+        "anchor": "references"
+      }
+    ],
+    "lineCount": 70
+  },
+  {
+    "path": "/security-testing/mutation-testing",
+    "title": "Mutation Testing",
+    "domain": "security-testing",
+    "headers": [
+      {
+        "level": 2,
+        "text": "What is Mutation Testing?",
+        "anchor": "what-is-mutation-testing"
+      },
+      {
+        "level": 2,
+        "text": "How does it work?",
+        "anchor": "how-does-it-work"
+      },
+      {
+        "level": 2,
+        "text": "Types of Mutants",
+        "anchor": "types-of-mutants"
+      },
+      {
+        "level": 2,
+        "text": "Selecting mutations",
+        "anchor": "selecting-mutations"
+      },
+      {
+        "level": 2,
+        "text": "Modifier Mutation Example",
+        "anchor": "modifier-mutation-example"
+      },
+      {
+        "level": 2,
+        "text": "Best Practices and things to keep in mind",
+        "anchor": "best-practices-and-things-to-keep-in-mind"
+      },
+      {
+        "level": 3,
+        "text": "1. Make sure your Line and Branch coverage is already very high, close to 100%",
+        "anchor": "1-make-sure-your-line-and-branch-coverage-is-already-very-high-close-to-100"
+      },
+      {
+        "level": 3,
+        "text": "2. Achieving a 100% mutation score might not be feasible",
+        "anchor": "2-achieving-a-100-mutation-score-might-not-be-feasible"
+      },
+      {
+        "level": 3,
+        "text": "3. Consider using only a subset of the mutators available",
+        "anchor": "3-consider-using-only-a-subset-of-the-mutators-available"
+      },
+      {
+        "level": 3,
+        "text": "4. Consider using cloud infrastructure if your codebase is reasonably large",
+        "anchor": "4-consider-using-cloud-infrastructure-if-your-codebase-is-reasonably-large"
+      },
+      {
+        "level": 2,
+        "text": "Limitations",
+        "anchor": "limitations"
+      },
+      {
+        "level": 2,
+        "text": "Tools and Frameworks",
+        "anchor": "tools-and-frameworks"
+      },
+      {
+        "level": 2,
+        "text": "References",
+        "anchor": "references"
+      }
+    ],
+    "lineCount": 189
+  },
+  {
+    "path": "/security-testing/overview",
+    "title": "Security Testing",
+    "domain": "security-testing",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Goal",
+        "anchor": "goal"
+      },
+      {
+        "level": 2,
+        "text": "Smart Contracts",
+        "anchor": "smart-contracts"
+      },
+      {
+        "level": 2,
+        "text": "Evaluating your test suite",
+        "anchor": "evaluating-your-test-suite"
+      }
+    ],
+    "lineCount": 77
+  },
+  {
+    "path": "/security-testing/static-analysis",
+    "title": "Static Analysis",
+    "domain": "security-testing",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Static Analysis in Practice",
+        "anchor": "static-analysis-in-practice"
+      },
+      {
+        "level": 2,
+        "text": "Static Analysis Tools",
+        "anchor": "static-analysis-tools"
+      },
+      {
+        "level": 2,
+        "text": "References",
+        "anchor": "references"
+      }
+    ],
+    "lineCount": 78
+  },
+  {
+    "path": "/security-testing/unit-testing",
+    "title": "Unit Testing",
+    "domain": "security-testing",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Overview",
+        "anchor": "overview"
+      },
+      {
+        "level": 2,
+        "text": "The Foundation of Security Testing",
+        "anchor": "the-foundation-of-security-testing"
+      },
+      {
+        "level": 2,
+        "text": "Writing Effective Unit Tests",
+        "anchor": "writing-effective-unit-tests"
+      },
+      {
+        "level": 3,
+        "text": "Basic Unit Test Structure",
+        "anchor": "basic-unit-test-structure"
+      },
+      {
+        "level": 3,
+        "text": "Security-Focused Test Cases",
+        "anchor": "security-focused-test-cases"
+      },
+      {
+        "level": 3,
+        "text": "From Unit Test to Fuzz Test",
+        "anchor": "from-unit-test-to-fuzz-test"
+      },
+      {
+        "level": 2,
+        "text": "Mocking External Dependencies",
+        "anchor": "mocking-external-dependencies"
+      },
+      {
+        "level": 3,
+        "text": "Why Mock in Unit Tests?",
+        "anchor": "why-mock-in-unit-tests"
+      },
+      {
+        "level": 3,
+        "text": "Example Mock",
+        "anchor": "example-mock"
+      },
+      {
+        "level": 3,
+        "text": "When NOT to Mock",
+        "anchor": "when-not-to-mock"
+      },
+      {
+        "level": 2,
+        "text": "Best Practices",
+        "anchor": "best-practices"
+      },
+      {
+        "level": 3,
+        "text": "1. Achieve High Code Coverage",
+        "anchor": "1-achieve-high-code-coverage"
+      },
+      {
+        "level": 3,
+        "text": "2. Test All Access Controls",
+        "anchor": "2-test-all-access-controls"
+      },
+      {
+        "level": 3,
+        "text": "3. Test Arithmetic Operations",
+        "anchor": "3-test-arithmetic-operations"
+      },
+      {
+        "level": 3,
+        "text": "4. Use Descriptive Test Names",
+        "anchor": "4-use-descriptive-test-names"
+      },
+      {
+        "level": 3,
+        "text": "5. Arrange, Act, Assert Pattern",
+        "anchor": "5-arrange-act-assert-pattern"
+      },
+      {
+        "level": 2,
+        "text": "Common Smart Contract Tools and Frameworks",
+        "anchor": "common-smart-contract-tools-and-frameworks"
+      },
+      {
+        "level": 2,
+        "text": "References",
+        "anchor": "references"
+      }
+    ],
+    "lineCount": 298
+  },
+  {
+    "path": "/supply-chain/dependency-awareness",
+    "title": "Dependency Awareness",
+    "domain": "supply-chain",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Importance of Dependency Awareness",
+        "anchor": "importance-of-dependency-awareness"
+      },
+      {
+        "level": 2,
+        "text": "Best Practices for Dependency Awareness",
+        "anchor": "best-practices-for-dependency-awareness"
+      }
+    ],
+    "lineCount": 64
+  },
+  {
+    "path": "/supply-chain/overview",
+    "title": "Supply Chain Security",
+    "domain": "supply-chain",
+    "headers": [],
+    "lineCount": 28
+  },
+  {
+    "path": "/supply-chain/supply-chain-levels-software-artifacts",
+    "title": "Supply Chain Levels Software Artifacts | SEAL",
+    "domain": "supply-chain",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Framework for Supply Chain Levels",
+        "anchor": "framework-for-supply-chain-levels"
+      },
+      {
+        "level": 2,
+        "text": "Best Practices for Securing Supply Chain Levels",
+        "anchor": "best-practices-for-securing-supply-chain-levels"
+      }
+    ],
+    "lineCount": 67
+  },
+  {
+    "path": "/threat-modeling/create-maintain-threat-models",
+    "title": "Creating Threat Models",
+    "domain": "threat-modeling",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Steps to Create a Threat Model",
+        "anchor": "steps-to-create-a-threat-model"
+      },
+      {
+        "level": 2,
+        "text": "Maintaining Threat Models",
+        "anchor": "maintaining-threat-models"
+      },
+      {
+        "level": 2,
+        "text": "Tools for Threat Modeling",
+        "anchor": "tools-for-threat-modeling"
+      }
+    ],
+    "lineCount": 92
+  },
+  {
+    "path": "/threat-modeling/identity-mitigate-threats",
+    "title": "Identify & Mitigate Threats",
+    "domain": "threat-modeling",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Identifying Threats",
+        "anchor": "identifying-threats"
+      },
+      {
+        "level": 2,
+        "text": "Mitigating Threats",
+        "anchor": "mitigating-threats"
+      }
+    ],
+    "lineCount": 75
+  },
+  {
+    "path": "/threat-modeling/overview",
+    "title": "Threat Modeling",
+    "domain": "threat-modeling",
+    "headers": [],
+    "lineCount": 26
+  },
+  {
+    "path": "/treasury-operations/classification",
+    "title": "Treasury Security Classification | SEAL",
+    "domain": "treasury-operations",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Classification Process",
+        "anchor": "classification-process"
+      },
+      {
+        "level": 3,
+        "text": "Step 1: Impact Assessment",
+        "anchor": "step-1-impact-assessment"
+      },
+      {
+        "level": 3,
+        "text": "Step 2: Operational Assessment",
+        "anchor": "step-2-operational-assessment"
+      },
+      {
+        "level": 3,
+        "text": "Step 3: Security Control Matrix",
+        "anchor": "step-3-security-control-matrix"
+      },
+      {
+        "level": 3,
+        "text": "Step 4: Document Your Decision",
+        "anchor": "step-4-document-your-decision"
+      }
+    ],
+    "lineCount": 145
+  },
+  {
+    "path": "/treasury-operations/enhanced-controls",
+    "title": "Enhanced Controls for High-Risk Accounts | SEAL",
+    "domain": "treasury-operations",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Transaction Verification",
+        "anchor": "transaction-verification"
+      },
+      {
+        "level": 2,
+        "text": "Access Security",
+        "anchor": "access-security"
+      },
+      {
+        "level": 2,
+        "text": "Device Security",
+        "anchor": "device-security"
+      },
+      {
+        "level": 2,
+        "text": "MPC for Large Holdings",
+        "anchor": "mpc-for-large-holdings"
+      },
+      {
+        "level": 3,
+        "text": "Custody/MPC Policy Thresholds for Treasury Operations",
+        "anchor": "custodympc-policy-thresholds-for-treasury-operations"
+      },
+      {
+        "level": 2,
+        "text": "Custody Policy Engine Rules",
+        "anchor": "custody-policy-engine-rules"
+      },
+      {
+        "level": 2,
+        "text": "Zero Trust Architecture Alternative",
+        "anchor": "zero-trust-architecture-alternative"
+      },
+      {
+        "level": 2,
+        "text": "Security Monitoring & Logging",
+        "anchor": "security-monitoring-logging"
+      },
+      {
+        "level": 3,
+        "text": "See also",
+        "anchor": "see-also"
+      }
+    ],
+    "lineCount": 169
+  },
+  {
+    "path": "/treasury-operations/overview",
+    "title": "Treasury Operations Security | SEAL",
+    "domain": "treasury-operations",
+    "headers": [
+      {
+        "level": 2,
+        "text": "What is Treasury Operations Security?",
+        "anchor": "what-is-treasury-operations-security"
+      },
+      {
+        "level": 2,
+        "text": "Core Components",
+        "anchor": "core-components"
+      },
+      {
+        "level": 3,
+        "text": "[Classification Framework](./classification)",
+        "anchor": "classification-frameworkclassification"
+      },
+      {
+        "level": 3,
+        "text": "[Registration Documents](./registration-documents)",
+        "anchor": "registration-documentsregistration-documents"
+      },
+      {
+        "level": 3,
+        "text": "[Enhanced Controls](./enhanced-controls)",
+        "anchor": "enhanced-controlsenhanced-controls"
+      },
+      {
+        "level": 3,
+        "text": "[Transaction Verification](./transaction-verification)",
+        "anchor": "transaction-verificationtransaction-verification"
+      },
+      {
+        "level": 2,
+        "text": "Getting Started",
+        "anchor": "getting-started"
+      }
+    ],
+    "lineCount": 70
+  },
+  {
+    "path": "/treasury-operations/registration-documents",
+    "title": "Custodial Account Registration | SEAL",
+    "domain": "treasury-operations",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Registration Template",
+        "anchor": "registration-template"
+      },
+      {
+        "level": 2,
+        "text": "Access Change Template",
+        "anchor": "access-change-template"
+      },
+      {
+        "level": 2,
+        "text": "Security Configuration Template",
+        "anchor": "security-configuration-template"
+      },
+      {
+        "level": 2,
+        "text": "Quarterly Review Template",
+        "anchor": "quarterly-review-template"
+      }
+    ],
+    "lineCount": 416
+  },
+  {
+    "path": "/treasury-operations/transaction-verification",
+    "title": "Treasury Transaction Verification | SEAL",
+    "domain": "treasury-operations",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Core Principles",
+        "anchor": "core-principles"
+      },
+      {
+        "level": 2,
+        "text": "Part 1: Receiving Large Transfers",
+        "anchor": "part-1-receiving-large-transfers"
+      },
+      {
+        "level": 3,
+        "text": "Pre-Transfer Setup (48 Hours Before)",
+        "anchor": "pre-transfer-setup-48-hours-before"
+      },
+      {
+        "level": 3,
+        "text": "Day of Transfer",
+        "anchor": "day-of-transfer"
+      },
+      {
+        "level": 2,
+        "text": "Part 2: Sending Large Cryptocurrency Transfers",
+        "anchor": "part-2-sending-large-cryptocurrency-transfers"
+      },
+      {
+        "level": 3,
+        "text": "Pre-Transfer Planning (72 Hours Before)",
+        "anchor": "pre-transfer-planning-72-hours-before"
+      },
+      {
+        "level": 3,
+        "text": "Day of Transfer",
+        "anchor": "day-of-transfer"
+      },
+      {
+        "level": 2,
+        "text": "Multi-Signature Best Practices",
+        "anchor": "multi-signature-best-practices"
+      },
+      {
+        "level": 2,
+        "text": "Critical Risk Mitigations",
+        "anchor": "critical-risk-mitigations"
+      },
+      {
+        "level": 3,
+        "text": "Address Verification",
+        "anchor": "address-verification"
+      },
+      {
+        "level": 3,
+        "text": "Communication Security",
+        "anchor": "communication-security"
+      },
+      {
+        "level": 3,
+        "text": "Multi-Party Controls",
+        "anchor": "multi-party-controls"
+      },
+      {
+        "level": 3,
+        "text": "Transaction Parameter Security",
+        "anchor": "transaction-parameter-security"
+      },
+      {
+        "level": 2,
+        "text": "Key Principles Summary",
+        "anchor": "key-principles-summary"
+      }
+    ],
+    "lineCount": 442
+  },
+  {
+    "path": "/user-team-security/overview",
+    "title": "",
+    "domain": "user-team-security",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/user-team-security/phishing-social-engineering",
+    "title": "",
+    "domain": "user-team-security",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/user-team-security/security-aware-culture",
+    "title": "",
+    "domain": "user-team-security",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/user-team-security/security-training",
+    "title": "",
+    "domain": "user-team-security",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/vulnerability-disclosure/bug-bounties",
+    "title": "Bug Bounty Programs",
+    "domain": "vulnerability-disclosure",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Bug Bounty as a Service",
+        "anchor": "bug-bounty-as-a-service"
+      },
+      {
+        "level": 3,
+        "text": "Web3",
+        "anchor": "web3"
+      },
+      {
+        "level": 3,
+        "text": "Web2",
+        "anchor": "web2"
+      },
+      {
+        "level": 2,
+        "text": "Pros and Cons of Running Your Own Bug Bounty Program",
+        "anchor": "pros-and-cons-of-running-your-own-bug-bounty-program"
+      },
+      {
+        "level": 3,
+        "text": "Pros",
+        "anchor": "pros"
+      },
+      {
+        "level": 3,
+        "text": "Cons",
+        "anchor": "cons"
+      },
+      {
+        "level": 2,
+        "text": "Key Elements of a Successful Bug Bounty Program",
+        "anchor": "key-elements-of-a-successful-bug-bounty-program"
+      },
+      {
+        "level": 3,
+        "text": "Scope",
+        "anchor": "scope"
+      },
+      {
+        "level": 3,
+        "text": "Rewards",
+        "anchor": "rewards"
+      },
+      {
+        "level": 3,
+        "text": "Triage and Response",
+        "anchor": "triage-and-response"
+      },
+      {
+        "level": 3,
+        "text": "Communication",
+        "anchor": "communication"
+      },
+      {
+        "level": 3,
+        "text": "Legal and Ethical Considerations",
+        "anchor": "legal-and-ethical-considerations"
+      }
+    ],
+    "lineCount": 85
+  },
+  {
+    "path": "/vulnerability-disclosure/overview",
+    "title": "Vulnerability Disclosure",
+    "domain": "vulnerability-disclosure",
+    "headers": [],
+    "lineCount": 31
+  },
+  {
+    "path": "/vulnerability-disclosure/security-contact",
+    "title": "Security Contact",
+    "domain": "vulnerability-disclosure",
+    "headers": [
+      {
+        "level": 2,
+        "text": "SECURE.md File",
+        "anchor": "securemd-file"
+      },
+      {
+        "level": 3,
+        "text": "Importance",
+        "anchor": "importance"
+      },
+      {
+        "level": 3,
+        "text": "Example Content",
+        "anchor": "example-content"
+      },
+      {
+        "level": 2,
+        "text": "Reporting a Vulnerability",
+        "anchor": "reporting-a-vulnerability"
+      },
+      {
+        "level": 2,
+        "text": "Security Email Address",
+        "anchor": "security-email-address"
+      },
+      {
+        "level": 3,
+        "text": "Importance",
+        "anchor": "importance"
+      },
+      {
+        "level": 3,
+        "text": "Setup",
+        "anchor": "setup"
+      },
+      {
+        "level": 2,
+        "text": ".well-known/security.txt",
+        "anchor": "well-knownsecuritytxt"
+      },
+      {
+        "level": 3,
+        "text": "Importance",
+        "anchor": "importance"
+      },
+      {
+        "level": 3,
+        "text": "Example Content",
+        "anchor": "example-content"
+      },
+      {
+        "level": 3,
+        "text": "Implementation",
+        "anchor": "implementation"
+      },
+      {
+        "level": 2,
+        "text": "Managing Security Contacts",
+        "anchor": "managing-security-contacts"
+      },
+      {
+        "level": 3,
+        "text": "Responsibilities",
+        "anchor": "responsibilities"
+      },
+      {
+        "level": 2,
+        "text": "Best Practices",
+        "anchor": "best-practices"
+      }
+    ],
+    "lineCount": 97
+  },
+  {
+    "path": "/wallet-security/account-abstraction",
+    "title": "Account Abstraction Wallets",
+    "domain": "wallet-security",
+    "headers": [
+      {
+        "level": 2,
+        "text": "User Profile",
+        "anchor": "user-profile"
+      },
+      {
+        "level": 2,
+        "text": "Primary Goal",
+        "anchor": "primary-goal"
+      },
+      {
+        "level": 2,
+        "text": "Core Concept: ERC-4337",
+        "anchor": "core-concept-erc-4337"
+      },
+      {
+        "level": 2,
+        "text": "Key Benefits & Features",
+        "anchor": "key-benefits-features"
+      },
+      {
+        "level": 2,
+        "text": "Security Considerations & Best Practices",
+        "anchor": "security-considerations-best-practices"
+      }
+    ],
+    "lineCount": 95
+  },
+  {
+    "path": "/wallet-security/cold-vs-hot-wallet",
+    "title": "Cold Vs Hot Wallet",
+    "domain": "wallet-security",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Cold Wallets",
+        "anchor": "cold-wallets"
+      },
+      {
+        "level": 3,
+        "text": "What Are They?",
+        "anchor": "what-are-they"
+      },
+      {
+        "level": 3,
+        "text": "Types of Cold Wallets",
+        "anchor": "types-of-cold-wallets"
+      },
+      {
+        "level": 3,
+        "text": "Use Cases",
+        "anchor": "use-cases"
+      },
+      {
+        "level": 2,
+        "text": "Hot Wallets",
+        "anchor": "hot-wallets"
+      },
+      {
+        "level": 3,
+        "text": "What Are They?",
+        "anchor": "what-are-they"
+      },
+      {
+        "level": 3,
+        "text": "Types of Hot Wallets",
+        "anchor": "types-of-hot-wallets"
+      },
+      {
+        "level": 3,
+        "text": "Use Cases",
+        "anchor": "use-cases"
+      },
+      {
+        "level": 2,
+        "text": "Comparison",
+        "anchor": "comparison"
+      },
+      {
+        "level": 2,
+        "text": "**Key Security Considerations**",
+        "anchor": "key-security-considerations"
+      }
+    ],
+    "lineCount": 100
+  },
+  {
+    "path": "/wallet-security/custodial-vs-non-custodial",
+    "title": "Custodial Vs Non-Custodial Wallets | SEAL",
+    "domain": "wallet-security",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Custodial Wallets",
+        "anchor": "custodial-wallets"
+      },
+      {
+        "level": 3,
+        "text": "What Are They?",
+        "anchor": "what-are-they"
+      },
+      {
+        "level": 3,
+        "text": "Characteristics",
+        "anchor": "characteristics"
+      },
+      {
+        "level": 3,
+        "text": "Use Cases",
+        "anchor": "use-cases"
+      },
+      {
+        "level": 2,
+        "text": "Non-Custodial Wallets",
+        "anchor": "non-custodial-wallets"
+      },
+      {
+        "level": 3,
+        "text": "What Are They?",
+        "anchor": "what-are-they"
+      },
+      {
+        "level": 3,
+        "text": "Characteristics",
+        "anchor": "characteristics"
+      },
+      {
+        "level": 3,
+        "text": "Use Cases",
+        "anchor": "use-cases"
+      },
+      {
+        "level": 2,
+        "text": "Comparison",
+        "anchor": "comparison"
+      }
+    ],
+    "lineCount": 85
+  },
+  {
+    "path": "/wallet-security/encumbered-wallets",
+    "title": "TEE-based Encumbered Wallets",
+    "domain": "wallet-security",
+    "headers": [
+      {
+        "level": 2,
+        "text": "User Profile",
+        "anchor": "user-profile"
+      },
+      {
+        "level": 2,
+        "text": "Primary Goal",
+        "anchor": "primary-goal"
+      },
+      {
+        "level": 2,
+        "text": "Core Concept: Key Encumbrance",
+        "anchor": "core-concept-key-encumbrance"
+      },
+      {
+        "level": 2,
+        "text": "Core Concept: Trusted Execution Environments (TEEs)",
+        "anchor": "core-concept-trusted-execution-environments-tees"
+      },
+      {
+        "level": 2,
+        "text": "Key Benefits & Features",
+        "anchor": "key-benefits-features"
+      },
+      {
+        "level": 2,
+        "text": "Security Considerations & Best Practices",
+        "anchor": "security-considerations-best-practices"
+      },
+      {
+        "level": 2,
+        "text": "Relevant Papers",
+        "anchor": "relevant-papers"
+      }
+    ],
+    "lineCount": 178
+  },
+  {
+    "path": "/wallet-security/for-beginners-and-small-balances",
+    "title": "Wallets for Beginners & Small Balances | SEAL",
+    "domain": "wallet-security",
+    "headers": [
+      {
+        "level": 2,
+        "text": "User Profile",
+        "anchor": "user-profile"
+      },
+      {
+        "level": 2,
+        "text": "Primary Goal",
+        "anchor": "primary-goal"
+      },
+      {
+        "level": 2,
+        "text": "Recommended Setup",
+        "anchor": "recommended-setup"
+      },
+      {
+        "level": 2,
+        "text": "Key Considerations & Trade-offs",
+        "anchor": "key-considerations-trade-offs"
+      },
+      {
+        "level": 2,
+        "text": "How to Select a Wallet",
+        "anchor": "how-to-select-a-wallet"
+      }
+    ],
+    "lineCount": 70
+  },
+  {
+    "path": "/wallet-security/hardware-wallets",
+    "title": "",
+    "domain": "wallet-security",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/wallet-security/intermediates-and-medium-funds",
+    "title": "Wallets for Intermediates & Medium Funds | SEAL",
+    "domain": "wallet-security",
+    "headers": [
+      {
+        "level": 2,
+        "text": "User Profile",
+        "anchor": "user-profile"
+      },
+      {
+        "level": 2,
+        "text": "Primary Goal",
+        "anchor": "primary-goal"
+      },
+      {
+        "level": 2,
+        "text": "Recommended Setup",
+        "anchor": "recommended-setup"
+      },
+      {
+        "level": 2,
+        "text": "Key Considerations & Trade-offs",
+        "anchor": "key-considerations-trade-offs"
+      },
+      {
+        "level": 2,
+        "text": "How to Select a Hardware Wallet",
+        "anchor": "how-to-select-a-hardware-wallet"
+      },
+      {
+        "level": 3,
+        "text": "Brand Diversification",
+        "anchor": "brand-diversification"
+      },
+      {
+        "level": 2,
+        "text": "Initial Setup",
+        "anchor": "initial-setup"
+      },
+      {
+        "level": 3,
+        "text": "Purchase & Verification",
+        "anchor": "purchase-verification"
+      },
+      {
+        "level": 3,
+        "text": "Device Authenticity Verification",
+        "anchor": "device-authenticity-verification"
+      },
+      {
+        "level": 3,
+        "text": "Device Configuration",
+        "anchor": "device-configuration"
+      },
+      {
+        "level": 3,
+        "text": "Key Generation",
+        "anchor": "key-generation"
+      },
+      {
+        "level": 3,
+        "text": "Clear Signing",
+        "anchor": "clear-signing"
+      },
+      {
+        "level": 2,
+        "text": "Backup Device (For Critical Operations & Multisigs)",
+        "anchor": "backup-device-for-critical-operations-multisigs"
+      }
+    ],
+    "lineCount": 125
+  },
+  {
+    "path": "/wallet-security/overview",
+    "title": "Wallet Security",
+    "domain": "wallet-security",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Table of Contents",
+        "anchor": "table-of-contents"
+      }
+    ],
+    "lineCount": 72
+  },
+  {
+    "path": "/wallet-security/secure-multisig-best-practices",
+    "title": "Secure Multisig Best Practices | SEAL",
+    "domain": "wallet-security",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Who This Is For",
+        "anchor": "who-this-is-for"
+      },
+      {
+        "level": 2,
+        "text": "Primary Goal",
+        "anchor": "primary-goal"
+      },
+      {
+        "level": 2,
+        "text": "Core Concept: M-of-N Scheme",
+        "anchor": "core-concept-m-of-n-scheme"
+      },
+      {
+        "level": 2,
+        "text": "General Rules",
+        "anchor": "general-rules"
+      },
+      {
+        "level": 3,
+        "text": "Thresholds & Configuration",
+        "anchor": "thresholds-configuration"
+      },
+      {
+        "level": 3,
+        "text": "Communication & Documentation",
+        "anchor": "communication-documentation"
+      },
+      {
+        "level": 3,
+        "text": "Signer rotation",
+        "anchor": "signer-rotation"
+      },
+      {
+        "level": 3,
+        "text": "Training & Drills",
+        "anchor": "training-drills"
+      },
+      {
+        "level": 2,
+        "text": "Setup Best Practices",
+        "anchor": "setup-best-practices"
+      },
+      {
+        "level": 2,
+        "text": "Operational Best Practices",
+        "anchor": "operational-best-practices"
+      },
+      {
+        "level": 2,
+        "text": "Contract-Level Security",
+        "anchor": "contract-level-security"
+      },
+      {
+        "level": 2,
+        "text": "Acknowledgements",
+        "anchor": "acknowledgements"
+      }
+    ],
+    "lineCount": 211
+  },
+  {
+    "path": "/wallet-security/seed-phrase-management",
+    "title": "Seed Phrase Management",
+    "domain": "wallet-security",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Private Key & Seed Phrase Management",
+        "anchor": "private-key-seed-phrase-management"
+      },
+      {
+        "level": 3,
+        "text": "Secure Storage Practices",
+        "anchor": "secure-storage-practices"
+      },
+      {
+        "level": 3,
+        "text": "Enhanced security option",
+        "anchor": "enhanced-security-option"
+      },
+      {
+        "level": 3,
+        "text": "Tamper evident bags:",
+        "anchor": "tamper-evident-bags"
+      },
+      {
+        "level": 3,
+        "text": "Prohibited Practices",
+        "anchor": "prohibited-practices"
+      },
+      {
+        "level": 2,
+        "text": "Organizational Seed Phrase Security",
+        "anchor": "organizational-seed-phrase-security"
+      },
+      {
+        "level": 3,
+        "text": "Security Properties",
+        "anchor": "security-properties"
+      },
+      {
+        "level": 3,
+        "text": "Seed Phrase Encryption",
+        "anchor": "seed-phrase-encryption"
+      },
+      {
+        "level": 3,
+        "text": "Advanced Backup Options",
+        "anchor": "advanced-backup-options"
+      },
+      {
+        "level": 3,
+        "text": "Multisig Social Recovery",
+        "anchor": "multisig-social-recovery"
+      },
+      {
+        "level": 3,
+        "text": "Ongoing Security Hygiene",
+        "anchor": "ongoing-security-hygiene"
+      },
+      {
+        "level": 2,
+        "text": "Emergency access plan",
+        "anchor": "emergency-access-plan"
+      },
+      {
+        "level": 3,
+        "text": "Trusted contacts",
+        "anchor": "trusted-contacts"
+      },
+      {
+        "level": 3,
+        "text": "Recovery scenario example",
+        "anchor": "recovery-scenario-example"
+      },
+      {
+        "level": 3,
+        "text": "Documentation",
+        "anchor": "documentation"
+      }
+    ],
+    "lineCount": 221
+  },
+  {
+    "path": "/wallet-security/signing-and-verification/secure-multisig-safe-verification",
+    "title": "Safe Multisig Verification | SEAL",
+    "domain": "wallet-security",
+    "headers": [
+      {
+        "level": 2,
+        "text": "General Signing Guidelines",
+        "anchor": "general-signing-guidelines"
+      },
+      {
+        "level": 3,
+        "text": "Basic Rules",
+        "anchor": "basic-rules"
+      },
+      {
+        "level": 2,
+        "text": "Key Definitions (EVM)",
+        "anchor": "key-definitions-evm"
+      },
+      {
+        "level": 2,
+        "text": "Recommended Tools",
+        "anchor": "recommended-tools"
+      },
+      {
+        "level": 2,
+        "text": "1) Transaction Preparation",
+        "anchor": "1-transaction-preparation"
+      },
+      {
+        "level": 2,
+        "text": "2) Simulation Testing",
+        "anchor": "2-simulation-testing"
+      },
+      {
+        "level": 2,
+        "text": "3) Hash & Calldata Verification",
+        "anchor": "3-hash-calldata-verification"
+      },
+      {
+        "level": 3,
+        "text": "Using web UI (OpenZeppelin Safe Utils)",
+        "anchor": "using-web-ui-openzeppelin-safe-utils"
+      },
+      {
+        "level": 3,
+        "text": "Checksummed address examples",
+        "anchor": "checksummed-address-examples"
+      },
+      {
+        "level": 2,
+        "text": "4) Hash Comparison",
+        "anchor": "4-hash-comparison"
+      },
+      {
+        "level": 2,
+        "text": "5) Calldata Review",
+        "anchor": "5-calldata-review"
+      },
+      {
+        "level": 3,
+        "text": "Tool diversity recommendation",
+        "anchor": "tool-diversity-recommendation"
+      },
+      {
+        "level": 2,
+        "text": "Special Cases: Nested Safes",
+        "anchor": "special-cases-nested-safes"
+      },
+      {
+        "level": 2,
+        "text": "Related Documents",
+        "anchor": "related-documents"
+      }
+    ],
+    "lineCount": 147
+  },
+  {
+    "path": "/wallet-security/signing-and-verification/secure-multisig-signing-process",
+    "title": "Secure Multisig Signing Process | SEAL",
+    "domain": "wallet-security",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Key Definitions (EVM)",
+        "anchor": "key-definitions-evm"
+      },
+      {
+        "level": 2,
+        "text": "Phase 1: Signing the Off-Chain Message",
+        "anchor": "phase-1-signing-the-off-chain-message"
+      },
+      {
+        "level": 3,
+        "text": "Process",
+        "anchor": "process"
+      },
+      {
+        "level": 2,
+        "text": "Phase 2: Executing the On-Chain Transaction",
+        "anchor": "phase-2-executing-the-on-chain-transaction"
+      },
+      {
+        "level": 3,
+        "text": "Process",
+        "anchor": "process"
+      },
+      {
+        "level": 2,
+        "text": "Operational Best Practices",
+        "anchor": "operational-best-practices"
+      },
+      {
+        "level": 3,
+        "text": "Simulation notes with timelocks",
+        "anchor": "simulation-notes-with-timelocks"
+      }
+    ],
+    "lineCount": 121
+  },
+  {
+    "path": "/wallet-security/signing-and-verification/secure-multisig-squads-verification",
+    "title": "Squads Multisig Verification | SEAL",
+    "domain": "wallet-security",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Workflow",
+        "anchor": "workflow"
+      },
+      {
+        "level": 2,
+        "text": "SOL Transfer Verification",
+        "anchor": "sol-transfer-verification"
+      },
+      {
+        "level": 2,
+        "text": "USDS Transfer Verification",
+        "anchor": "usds-transfer-verification"
+      },
+      {
+        "level": 2,
+        "text": "Configuration Change Verification",
+        "anchor": "configuration-change-verification"
+      },
+      {
+        "level": 2,
+        "text": "Signing & Execution",
+        "anchor": "signing-execution"
+      }
+    ],
+    "lineCount": 123
+  },
+  {
+    "path": "/wallet-security/signing-and-verification/signing-verification",
+    "title": "Signing Verification",
+    "domain": "wallet-security",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Core Principles of Secure Signing",
+        "anchor": "core-principles-of-secure-signing"
+      },
+      {
+        "level": 2,
+        "text": "In This Section",
+        "anchor": "in-this-section"
+      }
+    ],
+    "lineCount": 76
+  },
+  {
+    "path": "/wallet-security/signing-and-verification/verifying-7702",
+    "title": "Verifying EIP-7702 Transactions | SEAL",
+    "domain": "wallet-security",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Benefits of EIP-7702",
+        "anchor": "benefits-of-eip-7702"
+      },
+      {
+        "level": 2,
+        "text": "Risks of EIP-7702",
+        "anchor": "risks-of-eip-7702"
+      },
+      {
+        "level": 2,
+        "text": "Guidance for Users",
+        "anchor": "guidance-for-users"
+      }
+    ],
+    "lineCount": 70
+  },
+  {
+    "path": "/wallet-security/signing-and-verification/verifying-standard-transactions",
+    "title": "Verifying Standard Transactions | SEAL",
+    "domain": "wallet-security",
+    "headers": [
+      {
+        "level": 2,
+        "text": "1. Verify the Origin",
+        "anchor": "1-verify-the-origin"
+      },
+      {
+        "level": 2,
+        "text": "2. Verify the Smart Contract Address",
+        "anchor": "2-verify-the-smart-contract-address"
+      },
+      {
+        "level": 2,
+        "text": "3. Verify the Function and Parameters",
+        "anchor": "3-verify-the-function-and-parameters"
+      },
+      {
+        "level": 2,
+        "text": "4. Sanity-Check the Network Fee (Gas)",
+        "anchor": "4-sanity-check-the-network-fee-gas"
+      }
+    ],
+    "lineCount": 67
+  },
+  {
+    "path": "/wallet-security/signing-schemes",
+    "title": "",
+    "domain": "wallet-security",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/wallet-security/software-wallets",
+    "title": "",
+    "domain": "wallet-security",
+    "headers": [],
+    "lineCount": 2
+  },
+  {
+    "path": "/wallet-security/tools-and-resources",
+    "title": "Wallet Security Tools & Resources | SEAL",
+    "domain": "wallet-security",
+    "headers": [
+      {
+        "level": 2,
+        "text": "Wallet Selection",
+        "anchor": "wallet-selection"
+      },
+      {
+        "level": 2,
+        "text": "Hardware Wallets",
+        "anchor": "hardware-wallets"
+      },
+      {
+        "level": 2,
+        "text": "Wallet Applications",
+        "anchor": "wallet-applications"
+      },
+      {
+        "level": 3,
+        "text": "Rabby Wallet",
+        "anchor": "rabby-wallet"
+      },
+      {
+        "level": 3,
+        "text": "MetaMask with Security Snaps (Alternative)",
+        "anchor": "metamask-with-security-snaps-alternative"
+      },
+      {
+        "level": 2,
+        "text": "Transaction Simulation",
+        "anchor": "transaction-simulation"
+      },
+      {
+        "level": 2,
+        "text": "Monitoring & Alerting",
+        "anchor": "monitoring-alerting"
+      },
+      {
+        "level": 3,
+        "text": "Multisig Monitoring",
+        "anchor": "multisig-monitoring"
+      },
+      {
+        "level": 3,
+        "text": "Network Security",
+        "anchor": "network-security"
+      },
+      {
+        "level": 2,
+        "text": "Transaction Verification",
+        "anchor": "transaction-verification"
+      },
+      {
+        "level": 3,
+        "text": "Conversion & Utilities",
+        "anchor": "conversion-utilities"
+      },
+      {
+        "level": 2,
+        "text": "Security Training",
+        "anchor": "security-training"
+      }
+    ],
+    "lineCount": 151
+  }
+]
\ No newline at end of file
diff --git a/scripts/data/mappings/sfc-devops-infrastructure.json b/scripts/data/mappings/sfc-devops-infrastructure.json
new file mode 100644
index 00000000..18498ca8
--- /dev/null
+++ b/scripts/data/mappings/sfc-devops-infrastructure.json
@@ -0,0 +1,1062 @@
+[
+  {
+    "controlId": "di-1.1.1",
+    "controlTitle": "DevOps Security Owner",
+    "description": "Is there a clearly designated person or team accountable for development and infrastructure security?",
+    "baselineCount": 1,
+    "baselines": [
+      "Accountability scope covers policy maintenance, security reviews, access control oversight, pipeline governance, and incident escalation"
+    ],
+    "candidates": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 33,
+        "matchedSections": [
+          "access control best practices",
+          "whois vs rdap"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 28,
+        "matchedSections": []
+      },
+      {
+        "page": "/secure-software-development/secure-code-repositories-version-control",
+        "title": "Secure Code Repositories & Version Control | SEAL",
+        "score": 28,
+        "matchedSections": [
+          "best practices for secure code repositories"
+        ]
+      },
+      {
+        "page": "/security-testing/unit-testing",
+        "title": "Unit Testing",
+        "score": 25,
+        "matchedSections": [
+          "overview",
+          "security-focused test cases",
+          "2. test all access controls"
+        ]
+      },
+      {
+        "page": "/security-automation/infrastructure-as-code",
+        "title": "Infrastructure as Code Security | SEAL",
+        "score": 24,
+        "matchedSections": [
+          "best practices for secure iac"
+        ]
+      },
+      {
+        "page": "/supply-chain/supply-chain-levels-software-artifacts",
+        "title": "Supply Chain Levels Software Artifacts | SEAL",
+        "score": 24,
+        "matchedSections": [
+          "best practices for securing supply chain levels"
+        ]
+      },
+      {
+        "page": "/infrastructure/cloud",
+        "title": "Cloud Infrastructure",
+        "score": 23,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/overview",
+        "title": "Domain & DNS Security | SEAL",
+        "score": 20,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "di-1.1.2",
+    "controlTitle": "DevOps Security Policy",
+    "description": "Do you maintain documented security policies governing development and infrastructure operations?",
+    "baselineCount": 3,
+    "baselines": [
+      "Policy covers environment standards, access controls, deployment procedures, code management, and supply chain security",
+      "Accessible to all developers and infrastructure operators",
+      "Reviewed at least annually and after significant changes (security incidents, technology shifts, organizational restructuring)"
+    ],
+    "candidates": [
+      {
+        "page": "/supply-chain/supply-chain-levels-software-artifacts",
+        "title": "Supply Chain Levels Software Artifacts | SEAL",
+        "score": 53,
+        "matchedSections": [
+          "best practices for securing supply chain levels",
+          "framework for supply chain levels"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 36,
+        "matchedSections": []
+      },
+      {
+        "page": "/security-testing/unit-testing",
+        "title": "Unit Testing",
+        "score": 36,
+        "matchedSections": [
+          "overview",
+          "2. test all access controls"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 35,
+        "matchedSections": []
+      },
+      {
+        "page": "/security-automation/infrastructure-as-code",
+        "title": "Infrastructure as Code Security | SEAL",
+        "score": 35,
+        "matchedSections": []
+      },
+      {
+        "page": "/security-automation/compliance-checks",
+        "title": "Automated Compliance Checks",
+        "score": 32,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/cloud",
+        "title": "Cloud Infrastructure",
+        "score": 30,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+        "score": 29,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "di-1.1.3",
+    "controlTitle": "Development Environment Isolation",
+    "description": "Do you isolate development environments from production systems?",
+    "baselineCount": 5,
+    "baselines": [
+      "Development activities performed in containerized or virtualized environments",
+      "Each code repository has its own isolated environment to prevent cross-contamination",
+      "Production credentials not accessible from development environments",
+      "Separate accounts or profiles for development vs. privileged operations (e.g., wallet signing, cloud admin)",
+      "Code execution sandboxed to prevent host system compromise"
+    ],
+    "candidates": [
+      {
+        "page": "/devsecops/integrated-development-environments",
+        "title": "Securing Development Environments | SEAL",
+        "score": 35,
+        "matchedSections": []
+      },
+      {
+        "page": "/secure-software-development/secure-code-repositories-version-control",
+        "title": "Secure Code Repositories & Version Control | SEAL",
+        "score": 24,
+        "matchedSections": []
+      },
+      {
+        "page": "/devsecops/overview",
+        "title": "DevSecOps",
+        "score": 22,
+        "matchedSections": []
+      },
+      {
+        "page": "/secure-software-development/code-reviews-peer-audits",
+        "title": "Code Reviews & Peer Audits",
+        "score": 20,
+        "matchedSections": []
+      },
+      {
+        "page": "/security-automation/compliance-checks",
+        "title": "Automated Compliance Checks",
+        "score": 19,
+        "matchedSections": []
+      },
+      {
+        "page": "/secure-software-development/overview",
+        "title": "Secure Software Development | SEAL",
+        "score": 18,
+        "matchedSections": []
+      },
+      {
+        "page": "/secure-software-development/secure-coding-standards-guidelines",
+        "title": "Secure Coding Standards & Guidelines | SEAL",
+        "score": 18,
+        "matchedSections": [
+          "guidelines for secure coding"
+        ]
+      },
+      {
+        "page": "/security-testing/unit-testing",
+        "title": "Unit Testing",
+        "score": 18,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "di-1.1.4",
+    "controlTitle": "Development Tools Approval",
+    "description": "Do you evaluate and approve development tools before organizational use?",
+    "baselineCount": 5,
+    "baselines": [
+      "Evaluation criteria cover IDEs, extensions, plugins, AI-powered tools, and third-party services",
+      "Extensions and plugins obtained only from official repositories",
+      "AI tools assessed for data privacy risks (does the tool send code to third parties for training or analytics?)",
+      "Approved tool list maintained; unapproved tools restricted",
+      "Regular reviews of installed tools to identify unused or unrecognized items"
+    ],
+    "candidates": [
+      {
+        "page": "/security-automation/infrastructure-as-code",
+        "title": "Infrastructure as Code Security | SEAL",
+        "score": 35,
+        "matchedSections": []
+      },
+      {
+        "page": "/devsecops/integrated-development-environments",
+        "title": "Securing Development Environments | SEAL",
+        "score": 30,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+        "score": 30,
+        "matchedSections": []
+      },
+      {
+        "page": "/secure-software-development/code-reviews-peer-audits",
+        "title": "Code Reviews & Peer Audits",
+        "score": 30,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 28,
+        "matchedSections": []
+      },
+      {
+        "page": "/security-automation/compliance-checks",
+        "title": "Automated Compliance Checks",
+        "score": 28,
+        "matchedSections": []
+      },
+      {
+        "page": "/security-testing/static-analysis",
+        "title": "Static Analysis",
+        "score": 26,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 25,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "di-2.1.1",
+    "controlTitle": "Repository Security",
+    "description": "Do you enforce security controls on your source code repositories?",
+    "baselineCount": 6,
+    "baselines": [
+      "Role-based access control with least-privilege permissions",
+      "Branch protection rules enforced on main/production branches",
+      "Signed commits required for all code changes",
+      "Multi-party code review required for merges to protected branches",
+      "MFA required for all repository members",
+      "Repository access reviewed periodically"
+    ],
+    "candidates": [
+      {
+        "page": "/secure-software-development/secure-code-repositories-version-control",
+        "title": "Secure Code Repositories & Version Control | SEAL",
+        "score": 83,
+        "matchedSections": [
+          "best practices for secure code repositories"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 53,
+        "matchedSections": [
+          "access control best practices",
+          "whois vs rdap"
+        ]
+      },
+      {
+        "page": "/secure-software-development/code-reviews-peer-audits",
+        "title": "Code Reviews & Peer Audits",
+        "score": 53,
+        "matchedSections": [
+          "best practices for code reviews",
+          "conducting effective code reviews"
+        ]
+      },
+      {
+        "page": "/devsecops/repository-hardening",
+        "title": "Repository Hardening",
+        "score": 47,
+        "matchedSections": []
+      },
+      {
+        "page": "/security-testing/unit-testing",
+        "title": "Unit Testing",
+        "score": 37,
+        "matchedSections": [
+          "overview",
+          "security-focused test cases",
+          "2. test all access controls"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 35,
+        "matchedSections": []
+      },
+      {
+        "page": "/secure-software-development/secure-coding-standards-guidelines",
+        "title": "Secure Coding Standards & Guidelines | SEAL",
+        "score": 34,
+        "matchedSections": [
+          "guidelines for secure coding"
+        ]
+      },
+      {
+        "page": "/supply-chain/supply-chain-levels-software-artifacts",
+        "title": "Supply Chain Levels Software Artifacts | SEAL",
+        "score": 32,
+        "matchedSections": [
+          "best practices for securing supply chain levels"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "di-2.1.2",
+    "controlTitle": "Secret Scanning",
+    "description": "Do you scan source code for accidentally committed secrets?",
+    "baselineCount": 4,
+    "baselines": [
+      "Automated scanning for committed secrets (API keys, private keys, credentials) in all repositories",
+      "Pre-commit hooks deployed to prevent secrets from being committed in the first place",
+      "Remediation procedures for discovered secrets (immediate rotation, revocation)",
+      "Scanning integrated into CI/CD pipeline"
+    ],
+    "candidates": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 24,
+        "matchedSections": []
+      },
+      {
+        "page": "/secure-software-development/secure-code-repositories-version-control",
+        "title": "Secure Code Repositories & Version Control | SEAL",
+        "score": 23,
+        "matchedSections": [
+          "secure version control practices"
+        ]
+      },
+      {
+        "page": "/devsecops/continuous-integration-continuous-deployment",
+        "title": "Securing CI/CD Pipelines | SEAL",
+        "score": 21,
+        "matchedSections": []
+      },
+      {
+        "page": "/security-automation/compliance-checks",
+        "title": "Automated Compliance Checks",
+        "score": 16,
+        "matchedSections": [
+          "best practices"
+        ]
+      },
+      {
+        "page": "/secure-software-development/secure-coding-standards-guidelines",
+        "title": "Secure Coding Standards & Guidelines | SEAL",
+        "score": 15,
+        "matchedSections": [
+          "guidelines for secure coding"
+        ]
+      },
+      {
+        "page": "/security-automation/infrastructure-as-code",
+        "title": "Infrastructure as Code Security | SEAL",
+        "score": 13,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 12,
+        "matchedSections": [
+          "dns record monitoring",
+          "recovery"
+        ]
+      },
+      {
+        "page": "/devsecops/overview",
+        "title": "DevSecOps",
+        "score": 8,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "di-2.1.3",
+    "controlTitle": "External Contributor Review",
+    "description": "Do you apply enhanced review for code contributions from external collaborators?",
+    "baselineCount": 4,
+    "baselines": [
+      "Additional approvers required for all external code contributions",
+      "Code contributions tracked; unexpected changes flagged (e.g., commit rewrites, unprompted edits)",
+      "External collaborators restricted to minimum necessary repository permissions",
+      "CI/CD pipelines do not automatically execute for external contributor PRs without approval"
+    ],
+    "candidates": [
+      {
+        "page": "/secure-software-development/secure-code-repositories-version-control",
+        "title": "Secure Code Repositories & Version Control | SEAL",
+        "score": 33,
+        "matchedSections": [
+          "secure version control practices"
+        ]
+      },
+      {
+        "page": "/security-testing/unit-testing",
+        "title": "Unit Testing",
+        "score": 32,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 23,
+        "matchedSections": [
+          "dns record monitoring"
+        ]
+      },
+      {
+        "page": "/security-testing/overview",
+        "title": "Security Testing",
+        "score": 21,
+        "matchedSections": []
+      },
+      {
+        "page": "/secure-software-development/code-reviews-peer-audits",
+        "title": "Code Reviews & Peer Audits",
+        "score": 20,
+        "matchedSections": []
+      },
+      {
+        "page": "/security-testing/mutation-testing",
+        "title": "Mutation Testing",
+        "score": 20,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 19,
+        "matchedSections": []
+      },
+      {
+        "page": "/secure-software-development/secure-coding-standards-guidelines",
+        "title": "Secure Coding Standards & Guidelines | SEAL",
+        "score": 18,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "di-2.1.4",
+    "controlTitle": "Dependency and Supply Chain Security",
+    "description": "Do you verify and manage dependencies to prevent supply chain attacks?",
+    "baselineCount": 6,
+    "baselines": [
+      "Packages obtained from official repositories and trusted sources only",
+      "Package names verified against typosquatting patterns before installation",
+      "Dependencies scanned for known vulnerabilities before deployment",
+      "Dependency version pinning enforced to prevent automatic updates to compromised versions",
+      "Regular dependency audits for outdated or vulnerable components",
+      "Changelog reviewed for dependency updates to verify expected functionality"
+    ],
+    "candidates": [
+      {
+        "page": "/supply-chain/dependency-awareness",
+        "title": "Dependency Awareness",
+        "score": 43,
+        "matchedSections": []
+      },
+      {
+        "page": "/supply-chain/supply-chain-levels-software-artifacts",
+        "title": "Supply Chain Levels Software Artifacts | SEAL",
+        "score": 43,
+        "matchedSections": [
+          "framework for supply chain levels",
+          "best practices for securing supply chain levels"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 39,
+        "matchedSections": []
+      },
+      {
+        "page": "/security-testing/unit-testing",
+        "title": "Unit Testing",
+        "score": 28,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+        "score": 22,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 22,
+        "matchedSections": []
+      },
+      {
+        "page": "/supply-chain/overview",
+        "title": "Supply Chain Security",
+        "score": 19,
+        "matchedSections": []
+      },
+      {
+        "page": "/devsecops/repository-hardening",
+        "title": "Repository Hardening",
+        "score": 16,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "di-3.1.1",
+    "controlTitle": "Pipeline Security Controls",
+    "description": "Do you control who can modify and execute your deployment pipelines?",
+    "baselineCount": 5,
+    "baselines": [
+      "Pipeline configuration changes require multi-party approval",
+      "Separate service accounts with minimal permissions used for pipeline execution",
+      "Manual deployment by humans restricted; deployments automated through controlled pipelines",
+      "Pipeline and build configurations version-controlled and reviewed",
+      "Builds are deterministic with strict dependency sets"
+    ],
+    "candidates": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 28,
+        "matchedSections": []
+      },
+      {
+        "page": "/security-automation/infrastructure-as-code",
+        "title": "Infrastructure as Code Security | SEAL",
+        "score": 26,
+        "matchedSections": []
+      },
+      {
+        "page": "/devsecops/continuous-integration-continuous-deployment",
+        "title": "Securing CI/CD Pipelines | SEAL",
+        "score": 23,
+        "matchedSections": []
+      },
+      {
+        "page": "/secure-software-development/secure-code-repositories-version-control",
+        "title": "Secure Code Repositories & Version Control | SEAL",
+        "score": 19,
+        "matchedSections": []
+      },
+      {
+        "page": "/security-automation/compliance-checks",
+        "title": "Automated Compliance Checks",
+        "score": 16,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 15,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+        "score": 12,
+        "matchedSections": []
+      },
+      {
+        "page": "/security-testing/mutation-testing",
+        "title": "Mutation Testing",
+        "score": 12,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "di-3.1.2",
+    "controlTitle": "Secrets Management",
+    "description": "Do you securely manage secrets used in pipelines and applications?",
+    "baselineCount": 5,
+    "baselines": [
+      "Dedicated secrets management system used (not environment variables in plain text)",
+      "Secrets never stored in source code or unencrypted configuration files",
+      "Production secrets not directly accessible by humans",
+      "Pipeline secrets accessible only by service accounts",
+      "Secret rotation schedule defined; rotation triggered immediately after suspected compromise"
+    ],
+    "candidates": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 31,
+        "matchedSections": []
+      },
+      {
+        "page": "/security-automation/infrastructure-as-code",
+        "title": "Infrastructure as Code Security | SEAL",
+        "score": 20,
+        "matchedSections": []
+      },
+      {
+        "page": "/security-automation/compliance-checks",
+        "title": "Automated Compliance Checks",
+        "score": 19,
+        "matchedSections": [
+          "tools for automated compliance checks"
+        ]
+      },
+      {
+        "page": "/security-testing/mutation-testing",
+        "title": "Mutation Testing",
+        "score": 15,
+        "matchedSections": []
+      },
+      {
+        "page": "/monitoring/thresholds",
+        "title": "Monitoring Alert Thresholds",
+        "score": 14,
+        "matchedSections": [
+          "set thresholds for alerts",
+          "multi-layered thresholds"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+        "score": 13,
+        "matchedSections": [
+          "mta-sts (mail transfer agent strict transport security)"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 12,
+        "matchedSections": []
+      },
+      {
+        "page": "/secure-software-development/secure-coding-standards-guidelines",
+        "title": "Secure Coding Standards & Guidelines | SEAL",
+        "score": 11,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "di-3.1.3",
+    "controlTitle": "Security Testing Integration",
+    "description": "Do you integrate security testing into your development and deployment pipelines?",
+    "baselineCount": 4,
+    "baselines": [
+      "Static analysis (SAST) tools integrated into CI/CD pipeline",
+      "Dependency vulnerability scanning automated in CI/CD",
+      "Security scan results reviewed before deployment approval",
+      "Testing and validation performed in staging environments before production deployment"
+    ],
+    "candidates": [
+      {
+        "page": "/devsecops/overview",
+        "title": "DevSecOps",
+        "score": 44,
+        "matchedSections": []
+      },
+      {
+        "page": "/devsecops/continuous-integration-continuous-deployment",
+        "title": "Securing CI/CD Pipelines | SEAL",
+        "score": 39,
+        "matchedSections": []
+      },
+      {
+        "page": "/devsecops/security-testing",
+        "title": "Security Testing",
+        "score": 34,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+        "score": 33,
+        "matchedSections": []
+      },
+      {
+        "page": "/security-automation/infrastructure-as-code",
+        "title": "Infrastructure as Code Security | SEAL",
+        "score": 32,
+        "matchedSections": []
+      },
+      {
+        "page": "/security-automation/compliance-checks",
+        "title": "Automated Compliance Checks",
+        "score": 31,
+        "matchedSections": [
+          "best practices"
+        ]
+      },
+      {
+        "page": "/secure-software-development/secure-code-repositories-version-control",
+        "title": "Secure Code Repositories & Version Control | SEAL",
+        "score": 29,
+        "matchedSections": [
+          "secure version control practices"
+        ]
+      },
+      {
+        "page": "/supply-chain/supply-chain-levels-software-artifacts",
+        "title": "Supply Chain Levels Software Artifacts | SEAL",
+        "score": 28,
+        "matchedSections": [
+          "best practices for securing supply chain levels"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "di-4.1.1",
+    "controlTitle": "Infrastructure as Code",
+    "description": "Do you manage infrastructure through code with version control and review?",
+    "baselineCount": 4,
+    "baselines": [
+      "All infrastructure defined and managed through code (e.g., Terraform, CloudFormation)",
+      "Infrastructure changes deployed through automated pipelines, no manual steps required",
+      "Infrastructure changes require multi-party approval",
+      "IaC security scanning performed before deployment"
+    ],
+    "candidates": [
+      {
+        "page": "/security-automation/infrastructure-as-code",
+        "title": "Infrastructure as Code Security | SEAL",
+        "score": 52,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 37,
+        "matchedSections": []
+      },
+      {
+        "page": "/secure-software-development/secure-code-repositories-version-control",
+        "title": "Secure Code Repositories & Version Control | SEAL",
+        "score": 34,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 32,
+        "matchedSections": []
+      },
+      {
+        "page": "/security-automation/compliance-checks",
+        "title": "Automated Compliance Checks",
+        "score": 30,
+        "matchedSections": [
+          "tools for automated compliance checks"
+        ]
+      },
+      {
+        "page": "/infrastructure/overview",
+        "title": "Infrastructure",
+        "score": 25,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+        "score": 24,
+        "matchedSections": []
+      },
+      {
+        "page": "/secure-software-development/code-reviews-peer-audits",
+        "title": "Code Reviews & Peer Audits",
+        "score": 24,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "di-4.1.2",
+    "controlTitle": "Infrastructure Access Controls",
+    "description": "Do you enforce least-privilege access controls for infrastructure?",
+    "baselineCount": 6,
+    "baselines": [
+      "Individual accounts with MFA required; no shared accounts",
+      "Privileged access is time-limited and requires multi-party approval (JIT access)",
+      "Day-to-day operations use minimum necessary permissions (read-only where possible)",
+      "Break-glass accounts established for emergency access with individual accountability",
+      "Break-glass usage triggers immediate alerts to the entire team and requires post-incident review",
+      "All access activities logged and monitored"
+    ],
+    "candidates": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 61,
+        "matchedSections": [
+          "dns record monitoring",
+          "setting up alerts",
+          "critical alerts (immediate response required)",
+          "high priority alerts (when ns unchanged)"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 53,
+        "matchedSections": [
+          "domain expiration protection"
+        ]
+      },
+      {
+        "page": "/secure-software-development/secure-code-repositories-version-control",
+        "title": "Secure Code Repositories & Version Control | SEAL",
+        "score": 34,
+        "matchedSections": [
+          "best practices for secure code repositories"
+        ]
+      },
+      {
+        "page": "/security-testing/unit-testing",
+        "title": "Unit Testing",
+        "score": 30,
+        "matchedSections": [
+          "overview",
+          "2. test all access controls"
+        ]
+      },
+      {
+        "page": "/infrastructure/zero-trust-principles",
+        "title": "Zero Trust Principles",
+        "score": 28,
+        "matchedSections": []
+      },
+      {
+        "page": "/supply-chain/supply-chain-levels-software-artifacts",
+        "title": "Supply Chain Levels Software Artifacts | SEAL",
+        "score": 28,
+        "matchedSections": [
+          "best practices for securing supply chain levels"
+        ]
+      },
+      {
+        "page": "/infrastructure/cloud",
+        "title": "Cloud Infrastructure",
+        "score": 22,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+        "score": 22,
+        "matchedSections": [
+          "dnssec implementation"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "di-4.1.3",
+    "controlTitle": "Backup and Disaster Recovery",
+    "description": "Do you maintain backup and disaster recovery procedures with periodic testing?",
+    "baselineCount": 4,
+    "baselines": [
+      "Critical systems have automated backup procedures",
+      "Disaster recovery plan documented with recovery time and recovery point objectives defined",
+      "Backup and recovery procedures tested regularly",
+      "Backups stored independently of primary infrastructure"
+    ],
+    "candidates": [
+      {
+        "page": "/infrastructure/cloud",
+        "title": "Cloud Infrastructure",
+        "score": 31,
+        "matchedSections": []
+      },
+      {
+        "page": "/secure-software-development/secure-code-repositories-version-control",
+        "title": "Secure Code Repositories & Version Control | SEAL",
+        "score": 30,
+        "matchedSections": [
+          "secure version control practices"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 21,
+        "matchedSections": [
+          "domain expiration protection"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 16,
+        "matchedSections": []
+      },
+      {
+        "page": "/monitoring/thresholds",
+        "title": "Monitoring Alert Thresholds",
+        "score": 16,
+        "matchedSections": [
+          "set thresholds for alerts",
+          "multi-layered thresholds"
+        ]
+      },
+      {
+        "page": "/monitoring/guidelines",
+        "title": "On-Chain Monitoring Guidelines",
+        "score": 14,
+        "matchedSections": [
+          "define monitoring objectives"
+        ]
+      },
+      {
+        "page": "/security-automation/compliance-checks",
+        "title": "Automated Compliance Checks",
+        "score": 14,
+        "matchedSections": [
+          "tools for automated compliance checks"
+        ]
+      },
+      {
+        "page": "/security-automation/infrastructure-as-code",
+        "title": "Infrastructure as Code Security | SEAL",
+        "score": 12,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "di-4.1.4",
+    "controlTitle": "Cloud Security Monitoring",
+    "description": "Do you monitor cloud security configurations and respond to provider security notifications?",
+    "baselineCount": 5,
+    "baselines": [
+      "Cloud security configurations continuously monitored for drift and unauthorized changes",
+      "Administrative actions trigger alerts",
+      "Cloud provider security notifications subscribed to and promptly reviewed",
+      "Comprehensive logging enabled (e.g., CloudTrail, Azure Monitor, Google Cloud Logging)",
+      "Multi-cloud strategies considered to reduce single-provider dependency"
+    ],
+    "candidates": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 218,
+        "matchedSections": [
+          "dns record monitoring",
+          "setting up alerts",
+          "critical alerts (immediate response required)",
+          "high priority alerts (when ns unchanged)",
+          "certificate transparency monitoring",
+          "passive dns monitoring"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+        "score": 113,
+        "matchedSections": [
+          "dnssec implementation",
+          "mta-sts (mail transfer agent strict transport security)",
+          "dmarc (domain-based message authentication)"
+        ]
+      },
+      {
+        "page": "/infrastructure/cloud",
+        "title": "Cloud Infrastructure",
+        "score": 81,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 80,
+        "matchedSections": [
+          "domain expiration protection",
+          "enterprise-grade registrars (recommended)",
+          "multi-factor authentication",
+          "access control best practices",
+          "whois vs rdap"
+        ]
+      },
+      {
+        "page": "/monitoring/guidelines",
+        "title": "On-Chain Monitoring Guidelines",
+        "score": 65,
+        "matchedSections": [
+          "implement monitoring tools",
+          "establish alerting mechanisms",
+          "incident response",
+          "define monitoring objectives",
+          "regular reviews and updates"
+        ]
+      },
+      {
+        "page": "/security-automation/compliance-checks",
+        "title": "Automated Compliance Checks",
+        "score": 56,
+        "matchedSections": [
+          "benefits of automated compliance checks",
+          "tools for automated compliance checks"
+        ]
+      },
+      {
+        "page": "/monitoring/overview",
+        "title": "Monitoring",
+        "score": 52,
+        "matchedSections": []
+      },
+      {
+        "page": "/security-automation/threat-detection-response",
+        "title": "Threat Detection & Response | SEAL",
+        "score": 47,
+        "matchedSections": [
+          "guidelines for threat detection and response"
+        ]
+      }
+    ]
+  }
+]
\ No newline at end of file
diff --git a/scripts/data/mappings/sfc-dns-registrar.json b/scripts/data/mappings/sfc-dns-registrar.json
new file mode 100644
index 00000000..471d1337
--- /dev/null
+++ b/scripts/data/mappings/sfc-dns-registrar.json
@@ -0,0 +1,1366 @@
+[
+  {
+    "controlId": "dns-1.1.1",
+    "controlTitle": "Domain Security Owner",
+    "description": "Is there a clearly designated person or team accountable for domain security?",
+    "baselineCount": 1,
+    "baselines": [
+      "Accountability scope covers policy maintenance, security reviews, renewal management, access control oversight, and incident escalation"
+    ],
+    "candidates": [
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 49,
+        "matchedSections": [
+          "practical application",
+          "2. minimal access scopes"
+        ]
+      },
+      {
+        "page": "/opsec/principles/principles",
+        "title": "OpSec Core Principles",
+        "score": 45,
+        "matchedSections": [
+          "2. principle of least privilege",
+          "implementation"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 42,
+        "matchedSections": [
+          "access control best practices",
+          "whois vs rdap"
+        ]
+      },
+      {
+        "page": "/opsec/core-concepts/implementation-process",
+        "title": "OpSec Implementation Process | SEAL",
+        "score": 35,
+        "matchedSections": [
+          "implementation actions"
+        ]
+      },
+      {
+        "page": "/opsec/appendices/case-studies",
+        "title": "OpSec Case Studies",
+        "score": 34,
+        "matchedSections": [
+          "case study 1: private key compromise"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/physical-environmental",
+        "title": "Physical & Environmental Security",
+        "score": 32,
+        "matchedSections": [
+          "secure workspace components",
+          "implementation steps for workspace security"
+        ]
+      },
+      {
+        "page": "/opsec/integration/overview",
+        "title": "OpSec Integration",
+        "score": 32,
+        "matchedSections": [
+          "key integration points",
+          "implementation steps"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 31,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "dns-1.1.2",
+    "controlTitle": "Domain Inventory and Documentation",
+    "description": "Do you maintain a complete, current record of all your domains and their configurations?",
+    "baselineCount": 2,
+    "baselines": [
+      "Registry includes domain name, ownership, purpose, expiration date, registrar, DNS record configurations, security settings (DNSSEC, CAA), and registrar account configurations",
+      "Accessible to relevant team members"
+    ],
+    "candidates": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 277,
+        "matchedSections": [
+          "enterprise-grade registrars (recommended)",
+          "choosing a secure registrar",
+          "consumer registrars to avoid for critical domains",
+          "registry lock (epp lock)",
+          "multi-factor authentication",
+          "dedicated security contact email",
+          "access control best practices",
+          "whois privacy protection",
+          "whois vs rdap",
+          "domain expiration protection"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+        "score": 227,
+        "matchedSections": [
+          "dnssec implementation",
+          "smtp dane"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 112,
+        "matchedSections": [
+          "dns record monitoring",
+          "critical alerts (immediate response required)",
+          "immediate response",
+          "recovery"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/overview",
+        "title": "Domain & DNS Security | SEAL",
+        "score": 46,
+        "matchedSections": [
+          "standards and best practices",
+          "notable domain security incidents",
+          "incident response contacts"
+        ]
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 32,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/google/overview",
+        "title": "Google Workspace Security",
+        "score": 28,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 23,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/appendices/case-studies",
+        "title": "OpSec Case Studies",
+        "score": 19,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "dns-2.1.1",
+    "controlTitle": "Domain Classification and Compliance",
+    "description": "Do you classify your domains by risk level and verify they meet the security requirements for their classification?",
+    "baselineCount": 4,
+    "baselines": [
+      "Classification considers criticality, financial exposure, and operational impact",
+      "Domains where users may transact funds or that are external-facing classified at the highest tier",
+      "Each classification maps to specific security requirements (DNSSEC, locks, monitoring frequency, access controls)",
+      "Compliance verified at least annually through configuration review against documented standards"
+    ],
+    "candidates": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+        "score": 162,
+        "matchedSections": [
+          "dnssec implementation",
+          "smtp dane",
+          "dmarc (domain-based message authentication)"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 109,
+        "matchedSections": [
+          "dns record monitoring",
+          "critical alerts (immediate response required)",
+          "certificate transparency monitoring",
+          "passive dns monitoring"
+        ]
+      },
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 96,
+        "matchedSections": [
+          "practical application",
+          "relationship to implementation process",
+          "5. continuous visibility"
+        ]
+      },
+      {
+        "page": "/opsec/principles/principles",
+        "title": "OpSec Core Principles",
+        "score": 69,
+        "matchedSections": [
+          "implementation",
+          "5. continuous monitoring and improvement"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 66,
+        "matchedSections": [
+          "enterprise-grade registrars (recommended)",
+          "whois vs rdap",
+          "domain expiration protection"
+        ]
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 62,
+        "matchedSections": [
+          "**post-travel review**"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/technical",
+        "title": "Technical Security Controls",
+        "score": 58,
+        "matchedSections": [
+          "key components",
+          "implementation steps"
+        ]
+      },
+      {
+        "page": "/opsec/core-concepts/implementation-process",
+        "title": "OpSec Implementation Process | SEAL",
+        "score": 52,
+        "matchedSections": [
+          "implementation actions"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "dns-2.1.2",
+    "controlTitle": "Enterprise Registrar Security Requirements",
+    "description": "Do you use a registrar with enterprise-grade security for your critical domains?",
+    "baselineCount": 4,
+    "baselines": [
+      "Registrar supports registry locks (server-level EPP locks)",
+      "Registrar supports hardware security key MFA (FIDO2/WebAuthn)",
+      "Registrar has no history of social engineering vulnerabilities",
+      "Due diligence includes checking ICANN compliance notices for the registrar"
+    ],
+    "candidates": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 673,
+        "matchedSections": [
+          "consumer registrars to avoid for critical domains",
+          "registry lock (epp lock)",
+          "multi-factor authentication",
+          "whois privacy protection",
+          "choosing a secure registrar",
+          "enterprise-grade registrars (recommended)",
+          "dedicated security contact email",
+          "access control best practices",
+          "whois vs rdap",
+          "domain expiration protection"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+        "score": 181,
+        "matchedSections": [
+          "dnssec implementation"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 132,
+        "matchedSections": [
+          "critical alerts (immediate response required)",
+          "immediate response",
+          "recovery"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/overview",
+        "title": "Domain & DNS Security | SEAL",
+        "score": 60,
+        "matchedSections": [
+          "notable domain security incidents",
+          "incident response contacts"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/people",
+        "title": "Personnel Security Controls",
+        "score": 40,
+        "matchedSections": [
+          "key components",
+          "implementation steps",
+          "web3-specific considerations"
+        ]
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 39,
+        "matchedSections": [
+          "**screen privacy and social engineering**"
+        ]
+      },
+      {
+        "page": "/front-end-web-app/common-vulnerabilities",
+        "title": "Common Web Vulnerabilities",
+        "score": 30,
+        "matchedSections": [
+          "general vulnerabilities"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/overview",
+        "title": "OpSec Control Domains",
+        "score": 27,
+        "matchedSections": [
+          "section outline"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "dns-3.1.1",
+    "controlTitle": "Registrar Access Control",
+    "description": "Do you control and secure access to domain registrar and DNS management accounts?",
+    "baselineCount": 4,
+    "baselines": [
+      "Documented who is authorized, how access is granted/revoked, and role-based permissions where available",
+      "Hardware security key MFA (FIDO2/WebAuthn) required for all registrar and DNS management accounts",
+      "Access reviews conducted at least annually",
+      "Access revoked promptly when no longer needed"
+    ],
+    "candidates": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 295,
+        "matchedSections": [
+          "access control best practices",
+          "choosing a secure registrar",
+          "enterprise-grade registrars (recommended)",
+          "consumer registrars to avoid for critical domains",
+          "registry lock (epp lock)",
+          "multi-factor authentication",
+          "dedicated security contact email",
+          "whois privacy protection",
+          "whois vs rdap",
+          "domain expiration protection"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 83,
+        "matchedSections": [
+          "critical alerts (immediate response required)",
+          "immediate response",
+          "recovery"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+        "score": 81,
+        "matchedSections": [
+          "dnssec implementation"
+        ]
+      },
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 72,
+        "matchedSections": [
+          "2. minimal access scopes"
+        ]
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 60,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/principles/principles",
+        "title": "OpSec Core Principles",
+        "score": 59,
+        "matchedSections": [
+          "2. principle of least privilege",
+          "implementation"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/technical",
+        "title": "Technical Security Controls",
+        "score": 48,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/appendices/case-studies",
+        "title": "OpSec Case Studies",
+        "score": 47,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "dns-3.1.2",
+    "controlTitle": "Dedicated Domain Security Contact Email",
+    "description": "Is your domain security contact email independent of the domains it protects?",
+    "baselineCount": 4,
+    "baselines": [
+      "Hosted on a different domain than any domain it's responsible for",
+      "Not a personal email address",
+      "Used exclusively for domain security purposes",
+      "Alias that notifies multiple people"
+    ],
+    "candidates": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 60,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+        "score": 50,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 43,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 42,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/overview",
+        "title": "Domain & DNS Security | SEAL",
+        "score": 34,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/control-domains/overview",
+        "title": "OpSec Control Domains",
+        "score": 29,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/overview",
+        "title": "Infrastructure",
+        "score": 28,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/google/overview",
+        "title": "Google Workspace Security",
+        "score": 25,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "dns-3.1.3",
+    "controlTitle": "Change Management for Domain Operations",
+    "description": "Do you have change management procedures for critical domain operations?",
+    "baselineCount": 4,
+    "baselines": [
+      "Covers transfers, deletions, nameserver changes, and DNS record modifications",
+      "Relevant team members notified before critical changes",
+      "All changes logged",
+      "Critical changes verified through out-of-band confirmation with the registrar"
+    ],
+    "candidates": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 171,
+        "matchedSections": [
+          "choosing a secure registrar",
+          "enterprise-grade registrars (recommended)",
+          "consumer registrars to avoid for critical domains",
+          "registry lock (epp lock)",
+          "multi-factor authentication",
+          "dedicated security contact email",
+          "access control best practices",
+          "whois privacy protection",
+          "whois vs rdap",
+          "domain expiration protection"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 80,
+        "matchedSections": [
+          "critical alerts (immediate response required)",
+          "immediate response",
+          "recovery"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+        "score": 71,
+        "matchedSections": [
+          "dnssec implementation"
+        ]
+      },
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 36,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 32,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/appendices/case-studies",
+        "title": "OpSec Case Studies",
+        "score": 30,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/core-concepts/web3-considerations",
+        "title": "Web3 Security Considerations",
+        "score": 29,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/overview",
+        "title": "Domain & DNS Security | SEAL",
+        "score": 27,
+        "matchedSections": [
+          "notable domain security incidents",
+          "incident response contacts"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "dns-4.1.1",
+    "controlTitle": "DNS Security Standards",
+    "description": "Do you enforce DNS security standards across all your domains?",
+    "baselineCount": 4,
+    "baselines": [
+      "DNSSEC enabled and validated on all critical domains",
+      "CAA records configured to restrict certificate issuance to authorized CAs only",
+      "TTL policies documented with rationale",
+      "Standards applied consistently based on domain classification"
+    ],
+    "candidates": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+        "score": 166,
+        "matchedSections": [
+          "dnssec implementation",
+          "smtp dane"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 68,
+        "matchedSections": [
+          "dns record monitoring",
+          "critical alerts (immediate response required)"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/overview",
+        "title": "Domain & DNS Security | SEAL",
+        "score": 42,
+        "matchedSections": [
+          "standards and best practices"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 39,
+        "matchedSections": [
+          "enterprise-grade registrars (recommended)"
+        ]
+      },
+      {
+        "page": "/opsec/integration/overview",
+        "title": "OpSec Integration",
+        "score": 29,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 25,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 22,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/control-domains/overview",
+        "title": "OpSec Control Domains",
+        "score": 21,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "dns-4.1.2",
+    "controlTitle": "Email Authentication Standards",
+    "description": "Do you enforce email authentication standards and monitor for violations?",
+    "baselineCount": 5,
+    "baselines": [
+      "SPF, DKIM, and DMARC configured for all domains that send email",
+      "DMARC policy set to reject for domains actively sending email",
+      "DMARC aggregate reports (rua) monitored and reviewed",
+      "MTA-STS configured where supported to enforce encrypted email transport",
+      "Domains that don't send email have SPF/DMARC records that reject all email"
+    ],
+    "candidates": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+        "score": 247,
+        "matchedSections": [
+          "mta-sts (mail transfer agent strict transport security)",
+          "dnssec implementation",
+          "dmarc (domain-based message authentication)",
+          "spf (sender policy framework)",
+          "dkim (domainkeys identified mail)"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 149,
+        "matchedSections": [
+          "dns record monitoring",
+          "certificate transparency monitoring",
+          "passive dns monitoring",
+          "critical alerts (immediate response required)",
+          "high priority alerts (when ns unchanged)"
+        ]
+      },
+      {
+        "page": "/opsec/google/overview",
+        "title": "Google Workspace Security",
+        "score": 119,
+        "matchedSections": [
+          "best practices & ongoing maintenance",
+          "admin settings (workspace configuration)"
+        ]
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 82,
+        "matchedSections": [
+          "**secure your wallets and keys**",
+          "**plan emergency and incident responses**",
+          "**network safety – avoid untrusted wi-fi & bluetooth**",
+          "**plan for customs and border checks**",
+          "**post-travel review**",
+          "**enhanced device protections**"
+        ]
+      },
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 68,
+        "matchedSections": [
+          "practical application",
+          "relationship to implementation process",
+          "5. continuous visibility"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 60,
+        "matchedSections": [
+          "enterprise-grade registrars (recommended)",
+          "multi-factor authentication",
+          "access control best practices",
+          "whois vs rdap",
+          "domain expiration protection"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/overview",
+        "title": "Domain & DNS Security | SEAL",
+        "score": 31,
+        "matchedSections": [
+          "standards and best practices"
+        ]
+      },
+      {
+        "page": "/opsec/principles/principles",
+        "title": "OpSec Core Principles",
+        "score": 31,
+        "matchedSections": [
+          "5. continuous monitoring and improvement",
+          "implementation"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "dns-4.1.3",
+    "controlTitle": "Domain Lock Implementation",
+    "description": "Do you use domain locks to prevent unauthorized transfers and changes?",
+    "baselineCount": 3,
+    "baselines": [
+      "Registry locks (server-level EPP locks) enabled for all critical domains where supported",
+      "Transfer locks enabled on all domains",
+      "Lock status verified periodically"
+    ],
+    "candidates": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 73,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 39,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+        "score": 29,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 26,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/google/overview",
+        "title": "Google Workspace Security",
+        "score": 20,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/overview",
+        "title": "Domain & DNS Security | SEAL",
+        "score": 13,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/control-domains/overview",
+        "title": "OpSec Control Domains",
+        "score": 12,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/core-concepts/web3-considerations",
+        "title": "Web3 Security Considerations",
+        "score": 12,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "dns-4.1.4",
+    "controlTitle": "TLS Certificate Lifecycle Management",
+    "description": "Do you manage the full lifecycle of your TLS certificates?",
+    "baselineCount": 4,
+    "baselines": [
+      "Covers issuance, renewal, and revocation procedures",
+      "Certificates tracked with expiration alerts",
+      "Automated renewal where possible",
+      "Revocation procedures documented for compromised certificates"
+    ],
+    "candidates": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 44,
+        "matchedSections": [
+          "dns record monitoring",
+          "setting up alerts",
+          "critical alerts (immediate response required)",
+          "high priority alerts (when ns unchanged)"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+        "score": 30,
+        "matchedSections": [
+          "dnssec implementation"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 23,
+        "matchedSections": [
+          "domain expiration protection"
+        ]
+      },
+      {
+        "page": "/opsec/google/overview",
+        "title": "Google Workspace Security",
+        "score": 20,
+        "matchedSections": [
+          "best practices & ongoing maintenance",
+          "admin settings (workspace configuration)",
+          "notes"
+        ]
+      },
+      {
+        "page": "/monitoring/guidelines",
+        "title": "On-Chain Monitoring Guidelines",
+        "score": 19,
+        "matchedSections": [
+          "implement monitoring tools",
+          "establish alerting mechanisms",
+          "incident response"
+        ]
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 19,
+        "matchedSections": [
+          "**secure devices with encryption & updates**"
+        ]
+      },
+      {
+        "page": "/monitoring/thresholds",
+        "title": "Monitoring Alert Thresholds",
+        "score": 8,
+        "matchedSections": [
+          "set thresholds for alerts",
+          "multi-layered thresholds"
+        ]
+      },
+      {
+        "page": "/opsec/appendices/case-studies",
+        "title": "OpSec Case Studies",
+        "score": 6,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "dns-5.1.1",
+    "controlTitle": "Domain and DNS Monitoring",
+    "description": "Do you monitor your domains for unauthorized changes to DNS records, registration status, and security settings?",
+    "baselineCount": 5,
+    "baselines": [
+      "DNS record monitoring covers nameserver (NS) changes, A/AAAA changes, MX changes, TXT/SPF/DMARC changes, CAA record removal, DNSSEC status changes, and unexpected TTL drops",
+      "Registration monitoring covers lock status, registrar account settings, and nameserver delegation",
+      "Alerting and escalation paths documented",
+      "Critical alerts (nameserver changes, DNSSEC failure, registrar changes) trigger immediate investigation",
+      "Monitoring infrastructure not dependent on the domains being monitored"
+    ],
+    "candidates": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+        "score": 487,
+        "matchedSections": [
+          "dnssec implementation",
+          "smtp dane",
+          "mta-sts (mail transfer agent strict transport security)",
+          "dmarc (domain-based message authentication)",
+          "spf (sender policy framework)"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 478,
+        "matchedSections": [
+          "dns record monitoring",
+          "critical alerts (immediate response required)",
+          "setting up alerts",
+          "high priority alerts (when ns unchanged)",
+          "certificate transparency monitoring",
+          "passive dns monitoring",
+          "immediate response",
+          "recovery"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 402,
+        "matchedSections": [
+          "enterprise-grade registrars (recommended)",
+          "domain expiration protection",
+          "multi-factor authentication",
+          "access control best practices",
+          "whois vs rdap",
+          "choosing a secure registrar",
+          "consumer registrars to avoid for critical domains",
+          "registry lock (epp lock)",
+          "dedicated security contact email",
+          "whois privacy protection"
+        ]
+      },
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 206,
+        "matchedSections": [
+          "relationship to implementation process",
+          "practical application",
+          "5. continuous visibility"
+        ]
+      },
+      {
+        "page": "/opsec/principles/principles",
+        "title": "OpSec Core Principles",
+        "score": 136,
+        "matchedSections": [
+          "5. continuous monitoring and improvement",
+          "implementation"
+        ]
+      },
+      {
+        "page": "/monitoring/guidelines",
+        "title": "On-Chain Monitoring Guidelines",
+        "score": 120,
+        "matchedSections": [
+          "establish alerting mechanisms",
+          "implement monitoring tools",
+          "incident response",
+          "define monitoring objectives",
+          "regular reviews and updates"
+        ]
+      },
+      {
+        "page": "/opsec/google/overview",
+        "title": "Google Workspace Security",
+        "score": 97,
+        "matchedSections": [
+          "best practices & ongoing maintenance",
+          "admin settings (workspace configuration)",
+          "notes"
+        ]
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 96,
+        "matchedSections": [
+          "**protect crypto keys with multi-party controls**",
+          "**secure devices with encryption & updates**",
+          "**plan emergency and incident responses**",
+          "**post-travel review**",
+          "**enhanced device protections**"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "dns-5.1.2",
+    "controlTitle": "Certificate Transparency Monitoring",
+    "description": "Do you monitor Certificate Transparency logs for unauthorized certificates issued for your domains?",
+    "baselineCount": 3,
+    "baselines": [
+      "Subscribed to a CT monitoring service that alerts on new certificate issuance",
+      "Alerts reviewed and unauthorized certificates investigated promptly",
+      "Wildcard certificates flagged if not expected"
+    ],
+    "candidates": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 231,
+        "matchedSections": [
+          "dns record monitoring",
+          "setting up alerts",
+          "critical alerts (immediate response required)",
+          "high priority alerts (when ns unchanged)",
+          "certificate transparency monitoring",
+          "passive dns monitoring"
+        ]
+      },
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 99,
+        "matchedSections": [
+          "relationship to implementation process",
+          "practical application",
+          "5. continuous visibility"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+        "score": 79,
+        "matchedSections": [
+          "dnssec implementation",
+          "mta-sts (mail transfer agent strict transport security)",
+          "dmarc (domain-based message authentication)"
+        ]
+      },
+      {
+        "page": "/monitoring/guidelines",
+        "title": "On-Chain Monitoring Guidelines",
+        "score": 77,
+        "matchedSections": [
+          "implement monitoring tools",
+          "establish alerting mechanisms",
+          "incident response",
+          "define monitoring objectives",
+          "regular reviews and updates"
+        ]
+      },
+      {
+        "page": "/opsec/principles/principles",
+        "title": "OpSec Core Principles",
+        "score": 60,
+        "matchedSections": [
+          "5. continuous monitoring and improvement",
+          "implementation"
+        ]
+      },
+      {
+        "page": "/monitoring/overview",
+        "title": "Monitoring",
+        "score": 49,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 44,
+        "matchedSections": [
+          "domain expiration protection",
+          "enterprise-grade registrars (recommended)",
+          "multi-factor authentication",
+          "access control best practices",
+          "whois vs rdap"
+        ]
+      },
+      {
+        "page": "/opsec/google/overview",
+        "title": "Google Workspace Security",
+        "score": 44,
+        "matchedSections": [
+          "best practices & ongoing maintenance",
+          "admin settings (workspace configuration)",
+          "notes"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "dns-5.1.3",
+    "controlTitle": "Domain Expiration Prevention",
+    "description": "Do you actively prevent domain expiration?",
+    "baselineCount": 4,
+    "baselines": [
+      "Auto-renewal enabled on all domains",
+      "Calendar reminders at 90, 60, 30, and 7 days before expiration",
+      "Payment methods verified current",
+      "Backup person designated for renewal responsibility"
+    ],
+    "candidates": [
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 70,
+        "matchedSections": [
+          "before traveling",
+          "**back up and prepare for loss**",
+          "**protect accounts with 2fa redundancy**",
+          "**secure your wallets and keys**",
+          "**plan emergency and incident responses**",
+          "**inspect and clean your devices**",
+          "**protect crypto keys with multi-party controls**",
+          "**post-trip device rebuilding**",
+          "conclusion"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/technical",
+        "title": "Technical Security Controls",
+        "score": 53,
+        "matchedSections": [
+          "encrypted storage & backups",
+          "key components",
+          "implementation steps",
+          "web3-specific considerations"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 43,
+        "matchedSections": [
+          "domain expiration protection"
+        ]
+      },
+      {
+        "page": "/opsec/google/overview",
+        "title": "Google Workspace Security",
+        "score": 25,
+        "matchedSections": [
+          "account security checklist",
+          "extended security settings"
+        ]
+      },
+      {
+        "page": "/opsec/core-concepts/web3-considerations",
+        "title": "Web3 Security Considerations",
+        "score": 16,
+        "matchedSections": [
+          "suggested steps"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/physical-environmental",
+        "title": "Physical & Environmental Security",
+        "score": 14,
+        "matchedSections": [
+          "web3-specific considerations"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/overview",
+        "title": "OpSec Control Domains",
+        "score": 13,
+        "matchedSections": [
+          "section outline"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+        "score": 10,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "dns-6.1.1",
+    "controlTitle": "Alerting and Emergency Contacts",
+    "description": "Do you have alerting and emergency contacts in place for domain security incidents?",
+    "baselineCount": 3,
+    "baselines": [
+      "Alerting system in place to notify relevant stakeholders when a potential compromise is detected",
+      "Emergency contacts pre-documented including registrar security team, SEAL 911, and legal counsel",
+      "Communication plan for warning users (status page, social media, in-app warnings)"
+    ],
+    "candidates": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 152,
+        "matchedSections": [
+          "choosing a secure registrar",
+          "enterprise-grade registrars (recommended)",
+          "consumer registrars to avoid for critical domains",
+          "registry lock (epp lock)",
+          "multi-factor authentication",
+          "dedicated security contact email",
+          "access control best practices",
+          "whois privacy protection",
+          "whois vs rdap",
+          "domain expiration protection"
+        ]
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 68,
+        "matchedSections": [
+          "**protect crypto keys with multi-party controls**"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 57,
+        "matchedSections": [
+          "critical alerts (immediate response required)",
+          "immediate response",
+          "recovery"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+        "score": 56,
+        "matchedSections": [
+          "dnssec implementation"
+        ]
+      },
+      {
+        "page": "/opsec/appendices/case-studies",
+        "title": "OpSec Case Studies",
+        "score": 44,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/overview",
+        "title": "Domain & DNS Security | SEAL",
+        "score": 38,
+        "matchedSections": [
+          "notable domain security incidents",
+          "incident response contacts"
+        ]
+      },
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 35,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/control-domains/people",
+        "title": "Personnel Security Controls",
+        "score": 29,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "dns-6.1.2",
+    "controlTitle": "Domain Incident Response Plan",
+    "description": "Do you have an incident response plan for domain hijacking and DNS compromise?",
+    "baselineCount": 5,
+    "baselines": [
+      "Covers key scenarios including registrar account compromise, DNS hijacking, and unauthorized transfers",
+      "Emergency registry lock activation procedures",
+      "Procedures for regaining control of compromised domains",
+      "Post-recovery validation including DNS records verified against known-good baseline, all credentials reset, and access logs reviewed",
+      "Plan tested at least annually (can be combined with broader IR drills)"
+    ],
+    "candidates": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 164,
+        "matchedSections": [
+          "choosing a secure registrar",
+          "enterprise-grade registrars (recommended)",
+          "consumer registrars to avoid for critical domains",
+          "registry lock (epp lock)",
+          "multi-factor authentication",
+          "dedicated security contact email",
+          "access control best practices",
+          "whois privacy protection",
+          "whois vs rdap",
+          "domain expiration protection"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 99,
+        "matchedSections": [
+          "critical alerts (immediate response required)",
+          "incident response plan",
+          "recovery",
+          "immediate response"
+        ]
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 63,
+        "matchedSections": [
+          "**plan emergency and incident responses**",
+          "**screen privacy and social engineering**",
+          "**secure your accounts and passwords**",
+          "conclusion"
+        ]
+      },
+      {
+        "page": "/opsec/appendices/case-studies",
+        "title": "OpSec Case Studies",
+        "score": 60,
+        "matchedSections": [
+          "case study 1: private key compromise",
+          "case study 2: social engineering attack",
+          "exercise 1: wallet security incident",
+          "exercise 3: team member device compromise"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+        "score": 58,
+        "matchedSections": [
+          "dnssec implementation"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/overview",
+        "title": "Domain & DNS Security | SEAL",
+        "score": 40,
+        "matchedSections": [
+          "incident response contacts",
+          "notable domain security incidents"
+        ]
+      },
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 34,
+        "matchedSections": [
+          "relationship to implementation process",
+          "practical application"
+        ]
+      },
+      {
+        "page": "/opsec/appendices/glossary",
+        "title": "Security Glossary",
+        "score": 27,
+        "matchedSections": [
+          "i"
+        ]
+      }
+    ]
+  }
+]
\ No newline at end of file
diff --git a/scripts/data/mappings/sfc-incident-response.json b/scripts/data/mappings/sfc-incident-response.json
new file mode 100644
index 00000000..476c36d0
--- /dev/null
+++ b/scripts/data/mappings/sfc-incident-response.json
@@ -0,0 +1,1225 @@
+[
+  {
+    "controlId": "ir-1.1.1",
+    "controlTitle": "IR Team and Role Assignments",
+    "description": "Do you have an incident response team with clearly defined roles and responsibilities?",
+    "baselineCount": 7,
+    "baselines": [
+      "Incident commander (with designated backup) who coordinates response, assigns tasks, and makes time-sensitive decisions",
+      "Subject matter experts identified for key domains (smart contracts, infrastructure, security) who can analyze attacks and prepare response strategies",
+      "Scribe role defined for real-time incident documentation",
+      "Communications personnel designated for public information sharing and record-keeping",
+      "Legal support available with procedures for reviewing response actions, whitehat engagement, and public communications",
+      "Decision makers defined for high-stakes decisions (system shutdown, public disclosure, fund recovery)",
+      "Roles, authorities, and escalation measures reviewed at least annually and after protocol changes, team restructuring, or major incidents"
+    ],
+    "candidates": [
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 130,
+        "matchedSections": [
+          "documentation & communication",
+          "ongoing management",
+          "hardware & security setup",
+          "operational readiness",
+          "emergency preparedness",
+          "emergency procedures",
+          "tool proficiency",
+          "role-specific documentation",
+          "regular updates"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 123,
+        "matchedSections": [
+          "security team contact",
+          "internal escalation",
+          "immediate steps",
+          "if telegram/signal/discord gets taken over",
+          "multi-channel notification",
+          "for emergency response multisigs",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 119,
+        "matchedSections": [
+          "rpc backup options",
+          "administrator responsibilities",
+          "block explorer backup options",
+          "evm networks",
+          "squads public client - open source squads v4 interface",
+          "enhanced verification",
+          "regular practice",
+          "emergency drills",
+          "support resources",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/governance/compliance-regulatory-requirements",
+        "title": "Compliance & Regulatory Requirements | SEAL",
+        "score": 90,
+        "matchedSections": [
+          "2. develop a robust security policy framework",
+          "5. incident response planning",
+          "10. documentation and record-keeping"
+        ]
+      },
+      {
+        "page": "/incident-management/playbooks/seal-911-war-room-guidelines",
+        "title": "SEAL 911 War Room Guidelines | SEAL",
+        "score": 89,
+        "matchedSections": []
+      },
+      {
+        "page": "/multisig-for-protocols/personal-security-opsec",
+        "title": "Multisig Personal Security (OpSec) | SEAL",
+        "score": 75,
+        "matchedSections": [
+          "dns security",
+          "basic requirements",
+          "for extra security",
+          "what to bring",
+          "what not to bring",
+          "basic travel security"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 71,
+        "matchedSections": [
+          "thresholds & configuration",
+          "core concept: m-of-n scheme",
+          "communication & documentation"
+        ]
+      },
+      {
+        "page": "/incident-management/incident-detection-and-response",
+        "title": "Incident Detection And Response | SEAL",
+        "score": 69,
+        "matchedSections": [
+          "key components of incident response"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ir-1.1.2",
+    "controlTitle": "Stakeholder Coordination and Contacts",
+    "description": "Do you maintain current contacts and coordination procedures for all parties needed during an incident?",
+    "baselineCount": 7,
+    "baselines": [
+      "Internal coordination procedures between technical (devs, auditors) and operational teams (security council, communications)",
+      "External protocol contacts for protocols you depend on and protocols that depend on you",
+      "External expertise contacts including forensics firms, security consultants, SEAL 911, and auditors",
+      "Legal counsel and communications/PR contacts",
+      "Infrastructure vendor support contacts and escalation procedures",
+      "Contact list reviewed at least quarterly and after team changes",
+      "Escalation order documented for P1 incidents (e.g., SEAL 911 → decision makers → security partners → legal)"
+    ],
+    "candidates": [
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 78,
+        "matchedSections": [
+          "security team contact",
+          "internal escalation"
+        ]
+      },
+      {
+        "page": "/incident-management/playbooks/seal-911-war-room-guidelines",
+        "title": "SEAL 911 War Room Guidelines | SEAL",
+        "score": 72,
+        "matchedSections": []
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 56,
+        "matchedSections": []
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 53,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 51,
+        "matchedSections": []
+      },
+      {
+        "page": "/multisig-for-protocols/registration-and-documentation",
+        "title": "Multisig Registration & Documentation | SEAL",
+        "score": 48,
+        "matchedSections": []
+      },
+      {
+        "page": "/governance/compliance-regulatory-requirements",
+        "title": "Compliance & Regulatory Requirements | SEAL",
+        "score": 46,
+        "matchedSections": []
+      },
+      {
+        "page": "/wallet-security/seed-phrase-management",
+        "title": "Seed Phrase Management",
+        "score": 42,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "ir-2.1.1",
+    "controlTitle": "Monitoring Coverage",
+    "description": "Do you maintain monitoring coverage for your critical systems, protocols, and external attack surfaces?",
+    "baselineCount": 5,
+    "baselines": [
+      "Monitoring covers critical smart contracts, infrastructure, and on-chain activity",
+      "24/7 monitoring capabilities with procedures for after-hours alert handling",
+      "Credential and secret exposure detection including dark web monitoring, breach database scanning, and secret scanning in code repositories",
+      "Organizational account monitoring including social media accounts and websites monitored for unauthorized access or compromise",
+      "Monitoring coverage documented — what's covered, what's not, and known gaps"
+    ],
+    "candidates": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 344,
+        "matchedSections": [
+          "recovery",
+          "dns record monitoring",
+          "setting up alerts",
+          "critical alerts (immediate response required)",
+          "high priority alerts (when ns unchanged)",
+          "certificate transparency monitoring",
+          "passive dns monitoring"
+        ]
+      },
+      {
+        "page": "/incident-management/playbooks/seal-911-war-room-guidelines",
+        "title": "SEAL 911 War Room Guidelines | SEAL",
+        "score": 190,
+        "matchedSections": [
+          "perform in parallel by role",
+          "events timeline",
+          "post incident actions",
+          "suggested tools and platforms"
+        ]
+      },
+      {
+        "page": "/monitoring/guidelines",
+        "title": "On-Chain Monitoring Guidelines",
+        "score": 170,
+        "matchedSections": [
+          "implement monitoring tools",
+          "establish alerting mechanisms",
+          "regular reviews and updates",
+          "incident response",
+          "define monitoring objectives"
+        ]
+      },
+      {
+        "page": "/wallet-security/tools-and-resources",
+        "title": "Wallet Security Tools & Resources | SEAL",
+        "score": 155,
+        "matchedSections": [
+          "monitoring & alerting",
+          "multisig monitoring",
+          "network security"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 153,
+        "matchedSections": [
+          "active monitoring",
+          "immutable monitoring channels",
+          "zodiac delay modifier (time-locks)"
+        ]
+      },
+      {
+        "page": "/monitoring/overview",
+        "title": "Monitoring",
+        "score": 150,
+        "matchedSections": []
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 105,
+        "matchedSections": [
+          "thresholds & configuration",
+          "operational best practices"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/personal-security-opsec",
+        "title": "Multisig Personal Security (OpSec) | SEAL",
+        "score": 96,
+        "matchedSections": [
+          "network monitoring tools"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ir-2.1.2",
+    "controlTitle": "Alerting, Paging, and Escalation",
+    "description": "Do you have alerting and paging systems that reliably route incidents to available responders?",
+    "baselineCount": 8,
+    "baselines": [
+      "Automated alerting configured for security events and operational issues",
+      "Alerts include embedded triage guidance for distinguishing true incidents from false positives",
+      "Triage and classification procedures documented with escalation paths based on severity",
+      "Time-based escalation triggers if initial responder doesn't acknowledge within defined window",
+      "Management notification requirements for high-severity incidents",
+      "Redundant paging systems with documented failover procedures",
+      "On-call schedules maintained with adequate coverage for operational needs",
+      "Backup procedures when on-call personnel are unreachable"
+    ],
+    "candidates": [
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 99,
+        "matchedSections": [
+          "documentation & communication",
+          "ongoing management",
+          "hardware & security setup",
+          "operational readiness",
+          "emergency preparedness",
+          "emergency procedures",
+          "tool proficiency",
+          "role-specific documentation",
+          "regular updates",
+          "emergency response multisigs"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 83,
+        "matchedSections": [
+          "rpc backup options",
+          "administrator responsibilities",
+          "block explorer backup options",
+          "evm networks",
+          "squads public client - open source squads v4 interface",
+          "enhanced verification",
+          "regular practice",
+          "emergency drills",
+          "support resources",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 83,
+        "matchedSections": [
+          "security team contact",
+          "internal escalation",
+          "immediate steps",
+          "if telegram/signal/discord gets taken over",
+          "multi-channel notification",
+          "for emergency response multisigs",
+          "related documents",
+          "emergency drill procedures"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/personal-security-opsec",
+        "title": "Multisig Personal Security (OpSec) | SEAL",
+        "score": 50,
+        "matchedSections": [
+          "dns security",
+          "basic requirements",
+          "for extra security",
+          "what to bring",
+          "what not to bring",
+          "basic travel security"
+        ]
+      },
+      {
+        "page": "/wallet-security/seed-phrase-management",
+        "title": "Seed Phrase Management",
+        "score": 49,
+        "matchedSections": [
+          "tamper evident bags:",
+          "seed phrase encryption",
+          "advanced backup options",
+          "multisig social recovery",
+          "ongoing security hygiene",
+          "trusted contacts"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 47,
+        "matchedSections": [
+          "core concept: m-of-n scheme",
+          "thresholds & configuration",
+          "communication & documentation",
+          "operational best practices"
+        ]
+      },
+      {
+        "page": "/incident-management/playbooks/decentralized-ir",
+        "title": "Decentralized Incident Response | SEAL",
+        "score": 40,
+        "matchedSections": [
+          "4. detection and triage flow",
+          "2. roles and identities"
+        ]
+      },
+      {
+        "page": "/monitoring/guidelines",
+        "title": "On-Chain Monitoring Guidelines",
+        "score": 37,
+        "matchedSections": [
+          "define monitoring objectives",
+          "establish alerting mechanisms",
+          "implement monitoring tools",
+          "incident response"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ir-2.1.3",
+    "controlTitle": "Logging Integrity and Retention",
+    "description": "Do you maintain tamper-evident logs with adequate retention for incident investigation?",
+    "baselineCount": 5,
+    "baselines": [
+      "Log retention periods defined for security, infrastructure, and cloud provider logs",
+      "Retention adequate for forensic analysis (consider regulatory requirements and typical investigation timelines)",
+      "Tamper-evident logging for security-relevant events including access logs, alerting system logs, and infrastructure logs",
+      "Alerts triggered if logs are altered, deleted, or if monitoring/logging is disabled",
+      "Log sources documented — what's captured and where it's stored"
+    ],
+    "candidates": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 119,
+        "matchedSections": [
+          "dns record monitoring",
+          "setting up alerts",
+          "critical alerts (immediate response required)",
+          "high priority alerts (when ns unchanged)",
+          "certificate transparency monitoring",
+          "passive dns monitoring"
+        ]
+      },
+      {
+        "page": "/incident-management/playbooks/seal-911-war-room-guidelines",
+        "title": "SEAL 911 War Room Guidelines | SEAL",
+        "score": 61,
+        "matchedSections": [
+          "perform in parallel by role",
+          "post incident actions",
+          "suggested tools and platforms",
+          "events timeline"
+        ]
+      },
+      {
+        "page": "/governance/compliance-regulatory-requirements",
+        "title": "Compliance & Regulatory Requirements | SEAL",
+        "score": 51,
+        "matchedSections": [
+          "6. continuous monitoring and auditing",
+          "8. third-party risk management"
+        ]
+      },
+      {
+        "page": "/monitoring/guidelines",
+        "title": "On-Chain Monitoring Guidelines",
+        "score": 51,
+        "matchedSections": [
+          "define monitoring objectives",
+          "establish alerting mechanisms",
+          "implement monitoring tools",
+          "incident response",
+          "regular reviews and updates"
+        ]
+      },
+      {
+        "page": "/wallet-security/tools-and-resources",
+        "title": "Wallet Security Tools & Resources | SEAL",
+        "score": 48,
+        "matchedSections": [
+          "network security",
+          "monitoring & alerting",
+          "multisig monitoring"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 46,
+        "matchedSections": [
+          "active monitoring",
+          "immutable monitoring channels"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 36,
+        "matchedSections": [
+          "domain expiration protection",
+          "whois vs rdap"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+        "score": 34,
+        "matchedSections": [
+          "dnssec implementation",
+          "dmarc (domain-based message authentication)"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ir-3.1.1",
+    "controlTitle": "Response Playbooks",
+    "description": "Do you maintain response playbooks for common incident types?",
+    "baselineCount": 5,
+    "baselines": [
+      "Playbooks cover key scenarios including protocol exploits, infrastructure failures, access control breaches, key compromise, supply chain compromises, and frontend/DNS compromise",
+      "Each playbook includes initial response actions covering containment, evidence preservation, and stakeholder notification",
+      "Role-specific responsibilities defined for each scenario (who does what — technical, comms, legal)",
+      "Escalation criteria documented for when to engage leadership, when to shut down systems, when to make public disclosure, and when to engage external assistance",
+      "Key compromise playbook includes procedures for rotating keys and replacing compromised signers, with threshold and access reviewed after any signer replacement"
+    ],
+    "candidates": [
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 263,
+        "matchedSections": [
+          "setup best practices",
+          "thresholds & configuration",
+          "signer rotation",
+          "core concept: m-of-n scheme",
+          "communication & documentation",
+          "training & drills",
+          "operational best practices",
+          "contract-level security"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 152,
+        "matchedSections": [
+          "security team contact",
+          "internal escalation",
+          "for emergency response multisigs",
+          "emergency drill procedures",
+          "identity verification process",
+          "replacement coordination",
+          "recovery process"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 122,
+        "matchedSections": [
+          "self-hosted multisig ui",
+          "evm networks (ethereum, base, etc.)",
+          "solana",
+          "pre-launch checklist",
+          "nested safes",
+          "delegated proposer",
+          "verify basic functionality",
+          "next steps",
+          "address whitelisting"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/registration-and-documentation",
+        "title": "Multisig Registration & Documentation | SEAL",
+        "score": 98,
+        "matchedSections": [
+          "ongoing maintenance",
+          "signer changes",
+          "initial registration",
+          "signer verification process",
+          "update template",
+          "documentation updates",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/wallet-security/signing-and-verification/secure-multisig-signing-process",
+        "title": "Secure Multisig Signing Process | SEAL",
+        "score": 86,
+        "matchedSections": [
+          "phase 1: signing the off-chain message",
+          "process",
+          "phase 2: executing the on-chain transaction",
+          "operational best practices",
+          "key definitions (evm)"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 79,
+        "matchedSections": [
+          "administrator responsibilities",
+          "enhanced verification",
+          "regular practice",
+          "support resources",
+          "eternal safe - decentralized fork of safe\\{wallet\\}"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/use-case-specific-requirements",
+        "title": "Multisig Use Case Requirements | SEAL",
+        "score": 72,
+        "matchedSections": [
+          "additional requirements:",
+          "threshold considerations:",
+          "training & drills:",
+          "operational constraints:",
+          "veto quorum",
+          "hot/cold wallet separation",
+          "external signer requirements",
+          "configuration"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 71,
+        "matchedSections": [
+          "planning & setup",
+          "smart contract control multisigs",
+          "ongoing management",
+          "for signers",
+          "operational readiness"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ir-3.1.2",
+    "controlTitle": "Signer Reachability and Coordination",
+    "description": "Can you reach enough signers to execute emergency on-chain actions at any time, including outside business hours?",
+    "baselineCount": 4,
+    "baselines": [
+      "Procedures for coordinating multisig operations during incidents, including cross-timezone signer availability",
+      "Signers integrated into on-call/paging systems",
+      "Escalation paths documented for when signers are unreachable",
+      "Tested quarterly"
+    ],
+    "candidates": [
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 510,
+        "matchedSections": [
+          "core concept: m-of-n scheme",
+          "thresholds & configuration",
+          "communication & documentation",
+          "signer rotation",
+          "training & drills",
+          "operational best practices",
+          "contract-level security",
+          "acknowledgements",
+          "setup best practices"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 387,
+        "matchedSections": [
+          "for multisig administrators",
+          "planning & setup",
+          "documentation & communication",
+          "ongoing management",
+          "hardware & security setup",
+          "operational readiness",
+          "emergency preparedness",
+          "personal security",
+          "compliance",
+          "emergency response multisigs",
+          "treasury multisigs",
+          "smart contract control multisigs",
+          "required reading completed",
+          "role-specific documentation",
+          "training completion",
+          "for signers"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 269,
+        "matchedSections": [
+          "solana",
+          "self-hosted multisig ui",
+          "delegated proposer",
+          "allowance module (required for treasury multisigs)",
+          "zodiac delay modifier (time-locks)",
+          "contract-level controls",
+          "pre-launch checklist",
+          "practice on testnet",
+          "nested safes",
+          "next steps",
+          "active monitoring",
+          "verify basic functionality",
+          "evm networks (ethereum, base, etc.)",
+          "address whitelisting"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/overview",
+        "title": "Multisig Security Framework | SEAL",
+        "score": 259,
+        "matchedSections": [
+          "how to use this guide",
+          "core principles",
+          "1. foundation",
+          "2. multisig administration",
+          "3. for signers",
+          "4. reference"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/registration-and-documentation",
+        "title": "Multisig Registration & Documentation | SEAL",
+        "score": 224,
+        "matchedSections": [
+          "protocol documentation",
+          "signer verification process",
+          "initial registration",
+          "regular reviews",
+          "signer changes",
+          "documentation updates",
+          "related documents",
+          "ongoing maintenance",
+          "update template"
+        ]
+      },
+      {
+        "page": "/wallet-security/signing-and-verification/secure-multisig-signing-process",
+        "title": "Secure Multisig Signing Process | SEAL",
+        "score": 213,
+        "matchedSections": [
+          "process",
+          "phase 2: executing the on-chain transaction",
+          "operational best practices",
+          "phase 1: signing the off-chain message"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 204,
+        "matchedSections": [
+          "security team contact",
+          "internal escalation",
+          "recovery process",
+          "for emergency response multisigs",
+          "related documents",
+          "identity verification process",
+          "replacement coordination",
+          "emergency drill procedures"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 198,
+        "matchedSections": [
+          "eternal safe - decentralized fork of safe\\{wallet\\}",
+          "squads public client - open source squads v4 interface",
+          "related documents",
+          "administrator responsibilities",
+          "enhanced verification",
+          "regular practice",
+          "support resources"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ir-3.1.3",
+    "controlTitle": "Emergency Transaction Readiness",
+    "description": "Do you have backup signing infrastructure and pre-prepared emergency transactions for critical protocol functions?",
+    "baselineCount": 3,
+    "baselines": [
+      "Pre-signed or pre-prepared emergency transactions for critical protocol functions (pause, freeze, parameter changes) where feasible",
+      "Backup signing infrastructure available including alternate signing UI, backup RPC providers, and alternate block explorer",
+      "Emergency execution procedures documented (what to pause/freeze/modify and the process for doing so)"
+    ],
+    "candidates": [
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 269,
+        "matchedSections": [
+          "rpc backup options",
+          "administrator responsibilities",
+          "block explorer backup options",
+          "evm networks",
+          "squads public client - open source squads v4 interface",
+          "enhanced verification",
+          "regular practice",
+          "emergency drills",
+          "support resources",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 232,
+        "matchedSections": [
+          "documentation & communication",
+          "ongoing management",
+          "hardware & security setup",
+          "operational readiness",
+          "emergency preparedness",
+          "emergency procedures",
+          "tool proficiency",
+          "role-specific documentation",
+          "regular updates"
+        ]
+      },
+      {
+        "page": "/wallet-security/seed-phrase-management",
+        "title": "Seed Phrase Management",
+        "score": 138,
+        "matchedSections": [
+          "tamper evident bags:",
+          "seed phrase encryption",
+          "advanced backup options",
+          "multisig social recovery",
+          "ongoing security hygiene",
+          "trusted contacts"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/personal-security-opsec",
+        "title": "Multisig Personal Security (OpSec) | SEAL",
+        "score": 121,
+        "matchedSections": [
+          "basic requirements",
+          "for extra security",
+          "what to bring",
+          "what not to bring",
+          "basic travel security"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 114,
+        "matchedSections": [
+          "immediate steps",
+          "if telegram/signal/discord gets taken over",
+          "multi-channel notification",
+          "for emergency response multisigs",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 84,
+        "matchedSections": [
+          "thresholds & configuration",
+          "communication & documentation"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/overview",
+        "title": "Multisig Security Framework | SEAL",
+        "score": 73,
+        "matchedSections": [
+          "3. for signers"
+        ]
+      },
+      {
+        "page": "/wallet-security/intermediates-and-medium-funds",
+        "title": "Wallets for Intermediates & Medium Funds | SEAL",
+        "score": 67,
+        "matchedSections": [
+          "backup device (for critical operations & multisigs)"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ir-4.1.1",
+    "controlTitle": "Incident Communication Channels",
+    "description": "Do you maintain secure, dedicated communication channels for incident response?",
+    "baselineCount": 4,
+    "baselines": [
+      "Dedicated incident communication channels with documented access controls and member lists",
+      "Multiple communication channels (primary and backup) on different platforms, with documented failover procedures",
+      "Procedures for rapidly creating incident-specific channels (war room) when needed",
+      "Secure communication procedures for sensitive incident information including need-to-know access and encrypted channels"
+    ],
+    "candidates": [
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 130,
+        "matchedSections": [
+          "documentation & communication",
+          "ongoing management",
+          "hardware & security setup",
+          "operational readiness",
+          "emergency preparedness",
+          "emergency procedures",
+          "tool proficiency",
+          "role-specific documentation",
+          "regular updates"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 119,
+        "matchedSections": [
+          "immediate steps",
+          "if telegram/signal/discord gets taken over",
+          "multi-channel notification",
+          "for emergency response multisigs",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 111,
+        "matchedSections": [
+          "rpc backup options",
+          "administrator responsibilities",
+          "block explorer backup options",
+          "evm networks",
+          "squads public client - open source squads v4 interface",
+          "enhanced verification",
+          "regular practice",
+          "emergency drills",
+          "support resources",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/governance/compliance-regulatory-requirements",
+        "title": "Compliance & Regulatory Requirements | SEAL",
+        "score": 95,
+        "matchedSections": [
+          "2. develop a robust security policy framework",
+          "5. incident response planning",
+          "10. documentation and record-keeping"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 91,
+        "matchedSections": [
+          "thresholds & configuration",
+          "communication & documentation"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/personal-security-opsec",
+        "title": "Multisig Personal Security (OpSec) | SEAL",
+        "score": 88,
+        "matchedSections": [
+          "basic requirements",
+          "for extra security",
+          "what to bring",
+          "what not to bring",
+          "basic travel security"
+        ]
+      },
+      {
+        "page": "/incident-management/playbooks/seal-911-war-room-guidelines",
+        "title": "SEAL 911 War Room Guidelines | SEAL",
+        "score": 83,
+        "matchedSections": [
+          "perform immediately",
+          "perform in parallel by role",
+          "information gathering",
+          "events timeline",
+          "advice to keep in mind",
+          "key roles",
+          "suggested tools and platforms"
+        ]
+      },
+      {
+        "page": "/wallet-security/seed-phrase-management",
+        "title": "Seed Phrase Management",
+        "score": 80,
+        "matchedSections": [
+          "seed phrase encryption",
+          "tamper evident bags:",
+          "advanced backup options",
+          "multisig social recovery",
+          "ongoing security hygiene",
+          "trusted contacts"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ir-4.1.2",
+    "controlTitle": "Internal Status Updates",
+    "description": "Do you have procedures for providing regular status updates to stakeholders during incidents?",
+    "baselineCount": 2,
+    "baselines": [
+      "Status update cadence defined by severity level",
+      "Format and distribution lists for internal stakeholders"
+    ],
+    "candidates": [
+      {
+        "page": "/infrastructure/domain-and-dns-security/registrar-and-locks",
+        "title": "Registrar Security & Registry Locks | SEAL",
+        "score": 21,
+        "matchedSections": []
+      },
+      {
+        "page": "/incident-management/communication-strategies",
+        "title": "Incident Communication Strategies | SEAL",
+        "score": 14,
+        "matchedSections": [
+          "best practices"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/personal-security-opsec",
+        "title": "Multisig Personal Security (OpSec) | SEAL",
+        "score": 14,
+        "matchedSections": [
+          "dns security"
+        ]
+      },
+      {
+        "page": "/governance/compliance-regulatory-requirements",
+        "title": "Compliance & Regulatory Requirements | SEAL",
+        "score": 13,
+        "matchedSections": []
+      },
+      {
+        "page": "/monitoring/thresholds",
+        "title": "Monitoring Alert Thresholds",
+        "score": 13,
+        "matchedSections": [
+          "set thresholds for alerts",
+          "multi-layered thresholds"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 13,
+        "matchedSections": []
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 13,
+        "matchedSections": []
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 13,
+        "matchedSections": [
+          "core concept: m-of-n scheme"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ir-4.1.3",
+    "controlTitle": "Public Communication and Information Management",
+    "description": "Do you have procedures for public communication and information management during incidents?",
+    "baselineCount": 4,
+    "baselines": [
+      "Pre-approved communication templates for different incident types and severity levels",
+      "Procedures for coordinating communications with protocol users during and after incidents",
+      "Procedures for managing public information flow and correcting misinformation during active incidents",
+      "Designated communications approval flow before public statements are released"
+    ],
+    "candidates": [
+      {
+        "page": "/incident-management/playbooks/seal-911-war-room-guidelines",
+        "title": "SEAL 911 War Room Guidelines | SEAL",
+        "score": 40,
+        "matchedSections": []
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 40,
+        "matchedSections": []
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 38,
+        "matchedSections": []
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/dnssec-and-email",
+        "title": "DNSSEC, CAA, SMTP DANE and Email Security | SEAL",
+        "score": 35,
+        "matchedSections": []
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 35,
+        "matchedSections": []
+      },
+      {
+        "page": "/governance/compliance-regulatory-requirements",
+        "title": "Compliance & Regulatory Requirements | SEAL",
+        "score": 33,
+        "matchedSections": []
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 29,
+        "matchedSections": []
+      },
+      {
+        "page": "/incident-management/playbooks/decentralized-ir",
+        "title": "Decentralized Incident Response | SEAL",
+        "score": 28,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "ir-5.1.1",
+    "controlTitle": "IR Drills and Testing",
+    "description": "Do you conduct regular incident response drills and evaluate the results?",
+    "baselineCount": 7,
+    "baselines": [
+      "Drills conducted at least annually",
+      "Drills cover different incident types across exercises (protocol exploit, infrastructure failure, key compromise, etc.)",
+      "Tests the full pipeline from monitoring through alerting, paging, triage, escalation, team coordination, containment, and recovery",
+      "Production alerting pipeline validated end-to-end from event detection through to responder notification and acknowledgment",
+      "Drill documentation includes date, scenario, participants, response times, gaps identified, and corrective actions",
+      "Corrective actions tracked to completion with owners and deadlines",
+      "Drill findings incorporated into playbook and procedure updates"
+    ],
+    "candidates": [
+      {
+        "page": "/incident-management/playbooks/decentralized-ir",
+        "title": "Decentralized Incident Response | SEAL",
+        "score": 103,
+        "matchedSections": [
+          "6. eradication and recovery",
+          "10. keep it alive",
+          "1. guiding principles",
+          "3. preparation checklist",
+          "2. roles and identities",
+          "5. containment options",
+          "4. detection and triage flow"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 99,
+        "matchedSections": [
+          "security team contact",
+          "internal escalation",
+          "emergency drill procedures"
+        ]
+      },
+      {
+        "page": "/infrastructure/domain-and-dns-security/monitoring-and-alerting",
+        "title": "DNS Monitoring & Incident Response | SEAL",
+        "score": 91,
+        "matchedSections": [
+          "critical alerts (immediate response required)",
+          "incident response plan",
+          "dns record monitoring",
+          "certificate transparency monitoring",
+          "passive dns monitoring",
+          "containment"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 89,
+        "matchedSections": [
+          "emergency response multisigs",
+          "regular updates"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 84,
+        "matchedSections": [
+          "operational best practices",
+          "training & drills"
+        ]
+      },
+      {
+        "page": "/governance/compliance-regulatory-requirements",
+        "title": "Compliance & Regulatory Requirements | SEAL",
+        "score": 73,
+        "matchedSections": [
+          "2. develop a robust security policy framework",
+          "5. incident response planning",
+          "10. documentation and record-keeping",
+          "6. continuous monitoring and auditing",
+          "8. third-party risk management"
+        ]
+      },
+      {
+        "page": "/incident-management/playbooks/seal-911-war-room-guidelines",
+        "title": "SEAL 911 War Room Guidelines | SEAL",
+        "score": 67,
+        "matchedSections": [
+          "perform in parallel by role",
+          "events timeline",
+          "post incident actions",
+          "suggested tools and platforms"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 65,
+        "matchedSections": [
+          "evm networks",
+          "emergency drills"
+        ]
+      }
+    ]
+  }
+]
\ No newline at end of file
diff --git a/scripts/data/mappings/sfc-multisig-ops.json b/scripts/data/mappings/sfc-multisig-ops.json
new file mode 100644
index 00000000..ce8116a8
--- /dev/null
+++ b/scripts/data/mappings/sfc-multisig-ops.json
@@ -0,0 +1,2950 @@
+[
+  {
+    "controlId": "ms-1.1.1",
+    "controlTitle": "Named Multisig Operations Owner",
+    "description": "Is there a clearly named person or team accountable for multisig operations?",
+    "baselineCount": 1,
+    "baselines": [
+      "Accountability scope covers policy maintenance, signer onboarding/offboarding, documentation accuracy, periodic reviews, and incident escalation"
+    ],
+    "candidates": [
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 347,
+        "matchedSections": [
+          "core concept: m-of-n scheme",
+          "thresholds & configuration",
+          "communication & documentation",
+          "signer rotation",
+          "training & drills",
+          "operational best practices",
+          "contract-level security",
+          "acknowledgements",
+          "setup best practices"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 346,
+        "matchedSections": [
+          "for multisig administrators",
+          "planning & setup",
+          "documentation & communication",
+          "ongoing management",
+          "hardware & security setup",
+          "operational readiness",
+          "emergency preparedness",
+          "personal security",
+          "compliance",
+          "emergency response multisigs",
+          "treasury multisigs",
+          "smart contract control multisigs",
+          "required reading completed",
+          "role-specific documentation",
+          "training completion",
+          "for signers"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/overview",
+        "title": "Multisig Security Framework | SEAL",
+        "score": 251,
+        "matchedSections": [
+          "how to use this guide",
+          "core principles",
+          "1. foundation",
+          "2. multisig administration",
+          "3. for signers",
+          "4. reference"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 194,
+        "matchedSections": [
+          "solana",
+          "self-hosted multisig ui",
+          "delegated proposer",
+          "allowance module (required for treasury multisigs)",
+          "zodiac delay modifier (time-locks)",
+          "contract-level controls",
+          "pre-launch checklist",
+          "practice on testnet",
+          "nested safes",
+          "next steps",
+          "active monitoring",
+          "evm networks (ethereum, base, etc.)",
+          "address whitelisting",
+          "verify basic functionality"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/registration-and-documentation",
+        "title": "Multisig Registration & Documentation | SEAL",
+        "score": 169,
+        "matchedSections": [
+          "protocol documentation",
+          "signer verification process",
+          "initial registration",
+          "regular reviews",
+          "signer changes",
+          "documentation updates",
+          "related documents",
+          "update template",
+          "ongoing maintenance"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 143,
+        "matchedSections": [
+          "eternal safe - decentralized fork of safe\\{wallet\\}",
+          "squads public client - open source squads v4 interface",
+          "related documents",
+          "administrator responsibilities",
+          "enhanced verification",
+          "regular practice",
+          "support resources"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 123,
+        "matchedSections": [
+          "security team contact",
+          "internal escalation",
+          "recovery process",
+          "for emergency response multisigs",
+          "related documents",
+          "identity verification process",
+          "replacement coordination",
+          "emergency drill procedures"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/use-case-specific-requirements",
+        "title": "Multisig Use Case Requirements | SEAL",
+        "score": 102,
+        "matchedSections": [
+          "treasury multisigs",
+          "key requirements:",
+          "emergency response multisigs",
+          "capital allocation multisigs",
+          "smart contract control multisigs",
+          "threshold considerations:",
+          "configuration",
+          "simulation consideration",
+          "hot/cold wallet separation",
+          "external signer requirements",
+          "training & drills:",
+          "additional requirements:",
+          "operational constraints:",
+          "veto quorum"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ms-1.1.2",
+    "controlTitle": "Multisig Registry and Documentation",
+    "description": "Do you maintain a complete, accurate, and accessible record of all your multisigs, their configurations, and their signers?",
+    "baselineCount": 3,
+    "baselines": [
+      "Registry includes address, network, threshold, classification, purpose, signer addresses, controlled contracts, on-chain roles, and last review date",
+      "Updated within 24 hours for security-critical changes, 3 days for routine changes",
+      "Accessible to signers and key personnel"
+    ],
+    "candidates": [
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 514,
+        "matchedSections": [
+          "core concept: m-of-n scheme",
+          "thresholds & configuration",
+          "communication & documentation",
+          "signer rotation",
+          "training & drills",
+          "operational best practices",
+          "contract-level security",
+          "acknowledgements",
+          "setup best practices"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 379,
+        "matchedSections": [
+          "for multisig administrators",
+          "planning & setup",
+          "documentation & communication",
+          "ongoing management",
+          "hardware & security setup",
+          "operational readiness",
+          "emergency preparedness",
+          "personal security",
+          "compliance",
+          "emergency response multisigs",
+          "treasury multisigs",
+          "smart contract control multisigs",
+          "required reading completed",
+          "role-specific documentation",
+          "training completion",
+          "for signers"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 276,
+        "matchedSections": [
+          "solana",
+          "self-hosted multisig ui",
+          "delegated proposer",
+          "allowance module (required for treasury multisigs)",
+          "zodiac delay modifier (time-locks)",
+          "contract-level controls",
+          "pre-launch checklist",
+          "practice on testnet",
+          "nested safes",
+          "next steps",
+          "active monitoring",
+          "evm networks (ethereum, base, etc.)",
+          "verify basic functionality",
+          "address whitelisting"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/overview",
+        "title": "Multisig Security Framework | SEAL",
+        "score": 248,
+        "matchedSections": [
+          "how to use this guide",
+          "core principles",
+          "1. foundation",
+          "2. multisig administration",
+          "3. for signers",
+          "4. reference"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/registration-and-documentation",
+        "title": "Multisig Registration & Documentation | SEAL",
+        "score": 232,
+        "matchedSections": [
+          "protocol documentation",
+          "signer verification process",
+          "initial registration",
+          "regular reviews",
+          "signer changes",
+          "documentation updates",
+          "related documents",
+          "ongoing maintenance",
+          "update template"
+        ]
+      },
+      {
+        "page": "/wallet-security/signing-and-verification/secure-multisig-signing-process",
+        "title": "Secure Multisig Signing Process | SEAL",
+        "score": 190,
+        "matchedSections": [
+          "process",
+          "phase 2: executing the on-chain transaction",
+          "operational best practices",
+          "phase 1: signing the off-chain message"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/use-case-specific-requirements",
+        "title": "Multisig Use Case Requirements | SEAL",
+        "score": 178,
+        "matchedSections": [
+          "treasury multisigs",
+          "key requirements:",
+          "emergency response multisigs",
+          "capital allocation multisigs",
+          "smart contract control multisigs",
+          "threshold considerations:",
+          "configuration",
+          "simulation consideration",
+          "additional requirements:",
+          "training & drills:",
+          "operational constraints:",
+          "veto quorum",
+          "hot/cold wallet separation",
+          "external signer requirements",
+          "on-chain constraints:",
+          "timelock configuration"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 170,
+        "matchedSections": [
+          "eternal safe - decentralized fork of safe\\{wallet\\}",
+          "squads public client - open source squads v4 interface",
+          "related documents",
+          "administrator responsibilities",
+          "enhanced verification",
+          "regular practice",
+          "support resources"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ms-2.1.1",
+    "controlTitle": "Multisig Classification and Risk-Based Controls",
+    "description": "Do you classify your multisigs by risk level and apply security controls proportional to each classification?",
+    "baselineCount": 5,
+    "baselines": [
+      "Classification considers impact factors (financial exposure, protocol criticality, reputational risk) and operational needs (response time, coordination complexity)",
+      "Each classification maps to specific required controls (thresholds, quorum composition, review cadence)",
+      "All multisigs must have at least 3 distinct signers with a signing threshold of 50% or greater; N-of-N configurations should be avoided",
+      "Higher-risk classifications require stronger controls (more signers, higher thresholds)",
+      "Classifications reviewed every 6 months and after significant changes (TVL shifts, new products, protocol upgrades, security incidents)"
+    ],
+    "candidates": [
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 729,
+        "matchedSections": [
+          "for multisig administrators",
+          "planning & setup",
+          "documentation & communication",
+          "ongoing management",
+          "hardware & security setup",
+          "operational readiness",
+          "emergency preparedness",
+          "personal security",
+          "compliance",
+          "emergency response multisigs",
+          "treasury multisigs",
+          "smart contract control multisigs",
+          "required reading completed",
+          "role-specific documentation",
+          "training completion",
+          "for signers"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 650,
+        "matchedSections": [
+          "core concept: m-of-n scheme",
+          "thresholds & configuration",
+          "communication & documentation",
+          "signer rotation",
+          "training & drills",
+          "operational best practices",
+          "contract-level security",
+          "acknowledgements",
+          "setup best practices"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/overview",
+        "title": "Multisig Security Framework | SEAL",
+        "score": 498,
+        "matchedSections": [
+          "how to use this guide",
+          "core principles",
+          "1. foundation",
+          "2. multisig administration",
+          "3. for signers",
+          "4. reference"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 377,
+        "matchedSections": [
+          "solana",
+          "self-hosted multisig ui",
+          "delegated proposer",
+          "allowance module (required for treasury multisigs)",
+          "zodiac delay modifier (time-locks)",
+          "contract-level controls",
+          "pre-launch checklist",
+          "practice on testnet",
+          "nested safes",
+          "next steps",
+          "active monitoring",
+          "evm networks (ethereum, base, etc.)",
+          "verify basic functionality"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/registration-and-documentation",
+        "title": "Multisig Registration & Documentation | SEAL",
+        "score": 318,
+        "matchedSections": [
+          "protocol documentation",
+          "signer verification process",
+          "initial registration",
+          "regular reviews",
+          "signer changes",
+          "documentation updates",
+          "related documents",
+          "ongoing maintenance"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 254,
+        "matchedSections": [
+          "eternal safe - decentralized fork of safe\\{wallet\\}",
+          "squads public client - open source squads v4 interface",
+          "related documents",
+          "administrator responsibilities",
+          "enhanced verification",
+          "regular practice",
+          "support resources"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/use-case-specific-requirements",
+        "title": "Multisig Use Case Requirements | SEAL",
+        "score": 254,
+        "matchedSections": [
+          "treasury multisigs",
+          "key requirements:",
+          "emergency response multisigs",
+          "capital allocation multisigs",
+          "smart contract control multisigs",
+          "threshold considerations:",
+          "configuration",
+          "simulation consideration",
+          "additional requirements:",
+          "training & drills:",
+          "operational constraints:",
+          "veto quorum"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/planning-and-classification",
+        "title": "Multisig Planning & Classification | SEAL",
+        "score": 226,
+        "matchedSections": [
+          "define purpose and scope",
+          "assess constraints and recovery",
+          "step 1: impact assessment",
+          "step 2: operational assessment",
+          "classification process",
+          "identify stakeholders"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ms-2.1.2",
+    "controlTitle": "Contract-Level Security Controls",
+    "description": "Have you evaluated contract-level security controls that could limit the impact of a multisig compromise?",
+    "baselineCount": 4,
+    "baselines": [
+      "Evaluation covers timelocks, modules, guards, address whitelisting, invariant enforcement, and parameter bounds",
+      "Controls evaluated for each multisig based on classification",
+      "Security review required before enabling any module or guard",
+      "Decisions documented, including rationale for controls not implemented"
+    ],
+    "candidates": [
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 653,
+        "matchedSections": [
+          "for multisig administrators",
+          "planning & setup",
+          "documentation & communication",
+          "ongoing management",
+          "hardware & security setup",
+          "operational readiness",
+          "emergency preparedness",
+          "personal security",
+          "compliance",
+          "emergency response multisigs",
+          "treasury multisigs",
+          "smart contract control multisigs",
+          "required reading completed",
+          "role-specific documentation",
+          "training completion"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/overview",
+        "title": "Multisig Security Framework | SEAL",
+        "score": 479,
+        "matchedSections": [
+          "how to use this guide",
+          "core principles",
+          "1. foundation",
+          "2. multisig administration",
+          "3. for signers",
+          "4. reference"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 446,
+        "matchedSections": [
+          "core concept: m-of-n scheme",
+          "thresholds & configuration",
+          "communication & documentation",
+          "signer rotation",
+          "training & drills",
+          "operational best practices",
+          "contract-level security",
+          "acknowledgements",
+          "setup best practices"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 292,
+        "matchedSections": [
+          "solana",
+          "self-hosted multisig ui",
+          "delegated proposer",
+          "allowance module (required for treasury multisigs)",
+          "zodiac delay modifier (time-locks)",
+          "contract-level controls",
+          "pre-launch checklist",
+          "practice on testnet",
+          "nested safes",
+          "next steps",
+          "active monitoring"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/registration-and-documentation",
+        "title": "Multisig Registration & Documentation | SEAL",
+        "score": 227,
+        "matchedSections": [
+          "protocol documentation",
+          "signer verification process",
+          "initial registration",
+          "regular reviews",
+          "signer changes",
+          "documentation updates",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 213,
+        "matchedSections": [
+          "eternal safe - decentralized fork of safe\\{wallet\\}",
+          "squads public client - open source squads v4 interface",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/use-case-specific-requirements",
+        "title": "Multisig Use Case Requirements | SEAL",
+        "score": 165,
+        "matchedSections": [
+          "treasury multisigs",
+          "key requirements:",
+          "emergency response multisigs",
+          "capital allocation multisigs",
+          "smart contract control multisigs",
+          "threshold considerations:",
+          "configuration",
+          "simulation consideration"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/planning-and-classification",
+        "title": "Multisig Planning & Classification | SEAL",
+        "score": 139,
+        "matchedSections": [
+          "define purpose and scope",
+          "assess constraints and recovery",
+          "step 1: impact assessment",
+          "step 2: operational assessment"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ms-2.1.3",
+    "controlTitle": "Exception Approval Process",
+    "description": "Do you have a process for approving and tracking exceptions to multisig policies?",
+    "baselineCount": 2,
+    "baselines": [
+      "Exceptions require documented justification, expiry date, compensating controls, and remediation plan",
+      "Critical-class exceptions require executive or security-lead approval"
+    ],
+    "candidates": [
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 313,
+        "matchedSections": [
+          "for multisig administrators",
+          "planning & setup",
+          "documentation & communication",
+          "ongoing management",
+          "hardware & security setup",
+          "operational readiness",
+          "emergency preparedness",
+          "personal security",
+          "compliance",
+          "emergency response multisigs",
+          "treasury multisigs",
+          "smart contract control multisigs",
+          "required reading completed",
+          "role-specific documentation",
+          "training completion"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/overview",
+        "title": "Multisig Security Framework | SEAL",
+        "score": 234,
+        "matchedSections": [
+          "how to use this guide",
+          "core principles",
+          "1. foundation",
+          "2. multisig administration",
+          "3. for signers",
+          "4. reference"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 214,
+        "matchedSections": [
+          "core concept: m-of-n scheme",
+          "thresholds & configuration",
+          "communication & documentation",
+          "signer rotation",
+          "training & drills",
+          "operational best practices",
+          "contract-level security",
+          "acknowledgements"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 135,
+        "matchedSections": [
+          "solana",
+          "self-hosted multisig ui",
+          "delegated proposer",
+          "allowance module (required for treasury multisigs)",
+          "zodiac delay modifier (time-locks)",
+          "contract-level controls",
+          "pre-launch checklist",
+          "practice on testnet",
+          "nested safes",
+          "next steps",
+          "active monitoring"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/registration-and-documentation",
+        "title": "Multisig Registration & Documentation | SEAL",
+        "score": 105,
+        "matchedSections": [
+          "protocol documentation",
+          "signer verification process",
+          "initial registration",
+          "regular reviews",
+          "signer changes",
+          "documentation updates",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 102,
+        "matchedSections": [
+          "eternal safe - decentralized fork of safe\\{wallet\\}",
+          "squads public client - open source squads v4 interface",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/use-case-specific-requirements",
+        "title": "Multisig Use Case Requirements | SEAL",
+        "score": 71,
+        "matchedSections": [
+          "treasury multisigs",
+          "key requirements:",
+          "emergency response multisigs",
+          "capital allocation multisigs",
+          "smart contract control multisigs",
+          "threshold considerations:",
+          "configuration",
+          "simulation consideration"
+        ]
+      },
+      {
+        "page": "/wallet-security/signing-and-verification/secure-multisig-signing-process",
+        "title": "Secure Multisig Signing Process | SEAL",
+        "score": 66,
+        "matchedSections": [
+          "process",
+          "phase 2: executing the on-chain transaction",
+          "operational best practices"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ms-2.1.4",
+    "controlTitle": "Wallet Segregation",
+    "description": "Do you distribute assets across multiple wallets to limit the impact of a single compromise?",
+    "baselineCount": 2,
+    "baselines": [
+      "Segregation considers value, operational needs, and risk tolerance",
+      "Examples include hot/cold separation and treasury distribution across multiple wallets"
+    ],
+    "candidates": [
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 48,
+        "matchedSections": [
+          "additional precautions for high-risk travelers",
+          "**protect crypto keys with multi-party controls**"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 42,
+        "matchedSections": []
+      },
+      {
+        "page": "/wallet-security/encumbered-wallets",
+        "title": "TEE-based Encumbered Wallets",
+        "score": 40,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/core-concepts/web3-considerations",
+        "title": "Web3 Security Considerations",
+        "score": 36,
+        "matchedSections": [
+          "suggested steps"
+        ]
+      },
+      {
+        "page": "/opsec/core-concepts/implementation-process",
+        "title": "OpSec Implementation Process | SEAL",
+        "score": 34,
+        "matchedSections": [
+          "implementation actions"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/use-case-specific-requirements",
+        "title": "Multisig Use Case Requirements | SEAL",
+        "score": 30,
+        "matchedSections": [
+          "treasury multisigs",
+          "hot/cold wallet separation"
+        ]
+      },
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 30,
+        "matchedSections": [
+          "relationship to implementation process"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/technical",
+        "title": "Technical Security Controls",
+        "score": 29,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "ms-3.1.1",
+    "controlTitle": "Signer Address Verification",
+    "description": "Do you verify that each signer address on your multisigs belongs to the intended person?",
+    "baselineCount": 1,
+    "baselines": [
+      "Verification process includes message signing with the signer address, verification via an independent tool, and documented proof of verification"
+    ],
+    "candidates": [
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 516,
+        "matchedSections": [
+          "core concept: m-of-n scheme",
+          "thresholds & configuration",
+          "communication & documentation",
+          "signer rotation",
+          "training & drills",
+          "operational best practices",
+          "contract-level security",
+          "acknowledgements",
+          "setup best practices"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 374,
+        "matchedSections": [
+          "for multisig administrators",
+          "planning & setup",
+          "documentation & communication",
+          "ongoing management",
+          "hardware & security setup",
+          "operational readiness",
+          "emergency preparedness",
+          "personal security",
+          "compliance",
+          "emergency response multisigs",
+          "treasury multisigs",
+          "smart contract control multisigs",
+          "required reading completed",
+          "role-specific documentation",
+          "training completion",
+          "for signers"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 271,
+        "matchedSections": [
+          "solana",
+          "self-hosted multisig ui",
+          "delegated proposer",
+          "allowance module (required for treasury multisigs)",
+          "zodiac delay modifier (time-locks)",
+          "contract-level controls",
+          "pre-launch checklist",
+          "practice on testnet",
+          "nested safes",
+          "next steps",
+          "active monitoring",
+          "evm networks (ethereum, base, etc.)",
+          "address whitelisting",
+          "verify basic functionality"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/overview",
+        "title": "Multisig Security Framework | SEAL",
+        "score": 269,
+        "matchedSections": [
+          "how to use this guide",
+          "core principles",
+          "1. foundation",
+          "2. multisig administration",
+          "3. for signers",
+          "4. reference"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/registration-and-documentation",
+        "title": "Multisig Registration & Documentation | SEAL",
+        "score": 224,
+        "matchedSections": [
+          "protocol documentation",
+          "signer verification process",
+          "initial registration",
+          "regular reviews",
+          "signer changes",
+          "documentation updates",
+          "related documents",
+          "update template",
+          "ongoing maintenance"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 185,
+        "matchedSections": [
+          "eternal safe - decentralized fork of safe\\{wallet\\}",
+          "squads public client - open source squads v4 interface",
+          "related documents",
+          "administrator responsibilities",
+          "enhanced verification",
+          "regular practice",
+          "support resources"
+        ]
+      },
+      {
+        "page": "/wallet-security/signing-and-verification/secure-multisig-signing-process",
+        "title": "Secure Multisig Signing Process | SEAL",
+        "score": 170,
+        "matchedSections": [
+          "process",
+          "phase 2: executing the on-chain transaction",
+          "operational best practices",
+          "phase 1: signing the off-chain message"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 161,
+        "matchedSections": [
+          "recovery process",
+          "for emergency response multisigs",
+          "related documents",
+          "identity verification process",
+          "replacement coordination",
+          "emergency drill procedures"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ms-3.1.2",
+    "controlTitle": "Signer Key Management Standards",
+    "description": "Do you enforce signer key management standards?",
+    "baselineCount": 2,
+    "baselines": [
+      "Hardware wallets required for all multisig operations",
+      "Each signer uses a fresh, dedicated address per multisig, used exclusively for that multisig's operations"
+    ],
+    "candidates": [
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 991,
+        "matchedSections": [
+          "for multisig administrators",
+          "planning & setup",
+          "documentation & communication",
+          "ongoing management",
+          "hardware & security setup",
+          "operational readiness",
+          "emergency preparedness",
+          "personal security",
+          "compliance",
+          "emergency response multisigs",
+          "treasury multisigs",
+          "smart contract control multisigs",
+          "required reading completed",
+          "role-specific documentation",
+          "training completion",
+          "for signers"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 903,
+        "matchedSections": [
+          "thresholds & configuration",
+          "operational best practices",
+          "core concept: m-of-n scheme",
+          "communication & documentation",
+          "signer rotation",
+          "training & drills",
+          "contract-level security",
+          "acknowledgements",
+          "setup best practices"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/overview",
+        "title": "Multisig Security Framework | SEAL",
+        "score": 720,
+        "matchedSections": [
+          "how to use this guide",
+          "core principles",
+          "1. foundation",
+          "2. multisig administration",
+          "3. for signers",
+          "4. reference"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 508,
+        "matchedSections": [
+          "solana",
+          "self-hosted multisig ui",
+          "delegated proposer",
+          "allowance module (required for treasury multisigs)",
+          "zodiac delay modifier (time-locks)",
+          "contract-level controls",
+          "pre-launch checklist",
+          "practice on testnet",
+          "nested safes",
+          "next steps",
+          "active monitoring",
+          "evm networks (ethereum, base, etc.)",
+          "address whitelisting",
+          "verify basic functionality"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/registration-and-documentation",
+        "title": "Multisig Registration & Documentation | SEAL",
+        "score": 416,
+        "matchedSections": [
+          "protocol documentation",
+          "signer verification process",
+          "initial registration",
+          "regular reviews",
+          "signer changes",
+          "documentation updates",
+          "related documents",
+          "update template",
+          "ongoing maintenance"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 375,
+        "matchedSections": [
+          "eternal safe - decentralized fork of safe\\{wallet\\}",
+          "squads public client - open source squads v4 interface",
+          "related documents",
+          "administrator responsibilities",
+          "enhanced verification",
+          "regular practice",
+          "support resources"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/use-case-specific-requirements",
+        "title": "Multisig Use Case Requirements | SEAL",
+        "score": 288,
+        "matchedSections": [
+          "treasury multisigs",
+          "key requirements:",
+          "emergency response multisigs",
+          "capital allocation multisigs",
+          "smart contract control multisigs",
+          "threshold considerations:",
+          "configuration",
+          "simulation consideration",
+          "hot/cold wallet separation",
+          "external signer requirements",
+          "training & drills:",
+          "additional requirements:",
+          "operational constraints:",
+          "veto quorum"
+        ]
+      },
+      {
+        "page": "/wallet-security/signing-and-verification/secure-multisig-signing-process",
+        "title": "Secure Multisig Signing Process | SEAL",
+        "score": 273,
+        "matchedSections": [
+          "operational best practices",
+          "process",
+          "phase 2: executing the on-chain transaction",
+          "phase 1: signing the off-chain message"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ms-3.1.3",
+    "controlTitle": "Seed Phrase Backup and Protection",
+    "description": "Do you securely back up and protect signer seed phrases and recovery materials?",
+    "baselineCount": 4,
+    "baselines": [
+      "Seed phrases never stored digitally, in cloud storage, or photographed",
+      "Backups are geographically distributed (disaster resistant)",
+      "No single point of compromise (theft resistant)",
+      "Recoverable if one operator is unavailable (operator-loss resistant)"
+    ],
+    "candidates": [
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 150,
+        "matchedSections": [
+          "core concept: m-of-n scheme",
+          "thresholds & configuration",
+          "communication & documentation",
+          "signer rotation",
+          "training & drills",
+          "setup best practices",
+          "operational best practices",
+          "contract-level security"
+        ]
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 100,
+        "matchedSections": [
+          "**protect crypto keys with multi-party controls**",
+          "before traveling",
+          "**back up and prepare for loss**",
+          "**secure your wallets and keys**",
+          "**inspect and clean your devices**",
+          "**post-trip device rebuilding**",
+          "conclusion"
+        ]
+      },
+      {
+        "page": "/wallet-security/seed-phrase-management",
+        "title": "Seed Phrase Management",
+        "score": 78,
+        "matchedSections": [
+          "advanced backup options",
+          "multisig social recovery",
+          "ongoing security hygiene"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 64,
+        "matchedSections": [
+          "evm networks (ethereum, base, etc.)",
+          "solana",
+          "self-hosted multisig ui",
+          "delegated proposer",
+          "address whitelisting",
+          "verify basic functionality",
+          "pre-launch checklist",
+          "nested safes",
+          "next steps"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 62,
+        "matchedSections": [
+          "recovery process",
+          "identity verification process",
+          "replacement coordination",
+          "for emergency response multisigs",
+          "emergency drill procedures"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/registration-and-documentation",
+        "title": "Multisig Registration & Documentation | SEAL",
+        "score": 53,
+        "matchedSections": [
+          "signer verification process",
+          "update template",
+          "initial registration",
+          "ongoing maintenance",
+          "signer changes",
+          "documentation updates",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/technical",
+        "title": "Technical Security Controls",
+        "score": 44,
+        "matchedSections": [
+          "encrypted storage & backups",
+          "key components",
+          "web3-specific considerations"
+        ]
+      },
+      {
+        "page": "/wallet-security/signing-and-verification/secure-multisig-signing-process",
+        "title": "Secure Multisig Signing Process | SEAL",
+        "score": 43,
+        "matchedSections": [
+          "phase 1: signing the off-chain message",
+          "process",
+          "phase 2: executing the on-chain transaction",
+          "operational best practices"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ms-3.1.4",
+    "controlTitle": "Signer Lifecycle Management",
+    "description": "Do you have a defined process for adding, removing, and periodically verifying signers?",
+    "baselineCount": 2,
+    "baselines": [
+      "Offboarded signers removed within 48-72 hours (Emergency-class), 7 days (Critical-class), 14 days (others)",
+      "Access reviews quarterly, confirming each signer still controls their key"
+    ],
+    "candidates": [
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 257,
+        "matchedSections": [
+          "core concept: m-of-n scheme",
+          "thresholds & configuration",
+          "communication & documentation",
+          "signer rotation",
+          "training & drills",
+          "setup best practices",
+          "operational best practices",
+          "contract-level security"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 114,
+        "matchedSections": [
+          "delegated proposer",
+          "verify basic functionality",
+          "pre-launch checklist",
+          "nested safes",
+          "next steps",
+          "evm networks (ethereum, base, etc.)",
+          "solana",
+          "self-hosted multisig ui",
+          "address whitelisting"
+        ]
+      },
+      {
+        "page": "/wallet-security/signing-and-verification/secure-multisig-signing-process",
+        "title": "Secure Multisig Signing Process | SEAL",
+        "score": 110,
+        "matchedSections": [
+          "process",
+          "phase 2: executing the on-chain transaction",
+          "operational best practices",
+          "phase 1: signing the off-chain message",
+          "key definitions (evm)"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/registration-and-documentation",
+        "title": "Multisig Registration & Documentation | SEAL",
+        "score": 108,
+        "matchedSections": [
+          "initial registration",
+          "ongoing maintenance",
+          "signer changes",
+          "signer verification process",
+          "update template",
+          "documentation updates",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 107,
+        "matchedSections": [
+          "identity verification process",
+          "replacement coordination",
+          "for emergency response multisigs",
+          "emergency drill procedures",
+          "recovery process"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 66,
+        "matchedSections": [
+          "administrator responsibilities",
+          "enhanced verification",
+          "regular practice",
+          "support resources",
+          "eternal safe - decentralized fork of safe\\{wallet\\}"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/use-case-specific-requirements",
+        "title": "Multisig Use Case Requirements | SEAL",
+        "score": 63,
+        "matchedSections": [
+          "training & drills:",
+          "additional requirements:",
+          "operational constraints:",
+          "veto quorum",
+          "hot/cold wallet separation",
+          "external signer requirements",
+          "configuration"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/planning-and-classification",
+        "title": "Multisig Planning & Classification | SEAL",
+        "score": 54,
+        "matchedSections": [
+          "identify stakeholders",
+          "step 2: operational assessment",
+          "classification process",
+          "define purpose and scope"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ms-3.1.5",
+    "controlTitle": "Signer Training and Assessment",
+    "description": "Are signers trained and assessed on security practices before they are authorized to sign?",
+    "baselineCount": 3,
+    "baselines": [
+      "Training covers transaction verification, emergency procedures, phishing and social engineering awareness",
+      "Practical skills assessment included",
+      "Annual refreshers; updates within 30 days of significant procedure changes"
+    ],
+    "candidates": [
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 97,
+        "matchedSections": [
+          "communication & documentation",
+          "operational best practices",
+          "core concept: m-of-n scheme",
+          "thresholds & configuration",
+          "signer rotation",
+          "training & drills",
+          "setup best practices"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 57,
+        "matchedSections": [
+          "planning & setup",
+          "ongoing management",
+          "for signers"
+        ]
+      },
+      {
+        "page": "/opsec/appendices/case-studies",
+        "title": "OpSec Case Studies",
+        "score": 55,
+        "matchedSections": [
+          "case study 2: social engineering attack",
+          "red team exercise: phishing simulation"
+        ]
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 54,
+        "matchedSections": [
+          "**screen privacy and social engineering**",
+          "**secure devices with encryption & updates**",
+          "**protect crypto keys with multi-party controls**"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 52,
+        "matchedSections": [
+          "identity verification process",
+          "replacement coordination",
+          "for emergency response multisigs",
+          "emergency drill procedures"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/people",
+        "title": "Personnel Security Controls",
+        "score": 51,
+        "matchedSections": [
+          "key components",
+          "implementation steps",
+          "web3-specific considerations"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 48,
+        "matchedSections": [
+          "delegated proposer",
+          "verify basic functionality",
+          "pre-launch checklist",
+          "nested safes",
+          "next steps"
+        ]
+      },
+      {
+        "page": "/wallet-security/signing-and-verification/secure-multisig-signing-process",
+        "title": "Secure Multisig Signing Process | SEAL",
+        "score": 47,
+        "matchedSections": [
+          "process",
+          "phase 2: executing the on-chain transaction",
+          "operational best practices"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ms-3.1.6",
+    "controlTitle": "Hardware Wallet Standards",
+    "description": "Do you define and enforce hardware wallet standards for multisig operations?",
+    "baselineCount": 2,
+    "baselines": [
+      "Wallet capability requirements include adequate display, clear signing support, PIN security, and firmware integrity verification",
+      "Procurement through verified supply chains (direct from manufacturer or authorized resellers), with device authenticity verification"
+    ],
+    "candidates": [
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 374,
+        "matchedSections": [
+          "hardware & security setup",
+          "tool proficiency",
+          "required reading completed",
+          "for multisig administrators",
+          "planning & setup",
+          "documentation & communication",
+          "ongoing management",
+          "operational readiness",
+          "emergency preparedness",
+          "personal security",
+          "compliance",
+          "emergency response multisigs",
+          "treasury multisigs",
+          "smart contract control multisigs",
+          "role-specific documentation",
+          "training completion"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/overview",
+        "title": "Multisig Security Framework | SEAL",
+        "score": 275,
+        "matchedSections": [
+          "how to use this guide",
+          "3. for signers",
+          "core principles",
+          "1. foundation",
+          "2. multisig administration",
+          "4. reference"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 262,
+        "matchedSections": [
+          "thresholds & configuration",
+          "operational best practices",
+          "core concept: m-of-n scheme",
+          "communication & documentation",
+          "signer rotation",
+          "training & drills",
+          "contract-level security",
+          "acknowledgements"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 164,
+        "matchedSections": [
+          "next steps",
+          "self-hosted multisig ui",
+          "solana",
+          "delegated proposer",
+          "allowance module (required for treasury multisigs)",
+          "zodiac delay modifier (time-locks)",
+          "contract-level controls",
+          "pre-launch checklist",
+          "practice on testnet",
+          "nested safes",
+          "active monitoring"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 136,
+        "matchedSections": [
+          "eternal safe - decentralized fork of safe\\{wallet\\}",
+          "squads public client - open source squads v4 interface",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/wallet-security/signing-and-verification/secure-multisig-signing-process",
+        "title": "Secure Multisig Signing Process | SEAL",
+        "score": 126,
+        "matchedSections": [
+          "key definitions (evm)",
+          "phase 1: signing the off-chain message",
+          "process",
+          "operational best practices",
+          "phase 2: executing the on-chain transaction"
+        ]
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 120,
+        "matchedSections": [
+          "before traveling",
+          "**perform a quick threat model**",
+          "**secure your wallets and keys**",
+          "**plan emergency and incident responses**",
+          "**device handling – keep them close and protected**",
+          "**traveling with high-value crypto or duties**",
+          "**inspect and clean your devices**",
+          "**use loaner or \"burner\" devices**",
+          "additional precautions for high-risk travelers",
+          "**protect crypto keys with multi-party controls**",
+          "conclusion"
+        ]
+      },
+      {
+        "page": "/wallet-security/tools-and-resources",
+        "title": "Wallet Security Tools & Resources | SEAL",
+        "score": 119,
+        "matchedSections": [
+          "hardware wallets",
+          "transaction verification",
+          "monitoring & alerting",
+          "multisig monitoring",
+          "network security",
+          "security training"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ms-3.1.7",
+    "controlTitle": "Secure Signing Environment",
+    "description": "Do signers use a secure environment for signing operations?",
+    "baselineCount": 2,
+    "baselines": [
+      "Device security requirements documented and enforced",
+      "Dedicated signing devices or network isolation for high-value operations"
+    ],
+    "candidates": [
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 93,
+        "matchedSections": [
+          "core concept: m-of-n scheme",
+          "thresholds & configuration",
+          "communication & documentation",
+          "signer rotation",
+          "training & drills",
+          "setup best practices"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/personal-security-opsec",
+        "title": "Multisig Personal Security (OpSec) | SEAL",
+        "score": 52,
+        "matchedSections": []
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 48,
+        "matchedSections": [
+          "identity verification process",
+          "replacement coordination",
+          "for emergency response multisigs",
+          "emergency drill procedures"
+        ]
+      },
+      {
+        "page": "/wallet-security/signing-and-verification/secure-multisig-signing-process",
+        "title": "Secure Multisig Signing Process | SEAL",
+        "score": 48,
+        "matchedSections": [
+          "process",
+          "phase 2: executing the on-chain transaction",
+          "operational best practices"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 47,
+        "matchedSections": [
+          "administrator responsibilities",
+          "enhanced verification",
+          "regular practice",
+          "support resources"
+        ]
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 43,
+        "matchedSections": [
+          "**protect crypto keys with multi-party controls**"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 42,
+        "matchedSections": [
+          "planning & setup",
+          "ongoing management",
+          "for signers"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 37,
+        "matchedSections": [
+          "delegated proposer",
+          "verify basic functionality",
+          "pre-launch checklist",
+          "nested safes",
+          "next steps"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ms-3.1.8",
+    "controlTitle": "Signer Diversity",
+    "description": "Are your signers distributed across roles, entities, and geographies to prevent a single event from compromising quorum?",
+    "baselineCount": 1,
+    "baselines": [
+      "Diversity requirements scale with multisig classification"
+    ],
+    "candidates": [
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 328,
+        "matchedSections": [
+          "for multisig administrators",
+          "planning & setup",
+          "documentation & communication",
+          "ongoing management",
+          "hardware & security setup",
+          "operational readiness",
+          "emergency preparedness",
+          "personal security",
+          "compliance",
+          "emergency response multisigs",
+          "treasury multisigs",
+          "smart contract control multisigs",
+          "required reading completed",
+          "role-specific documentation",
+          "training completion",
+          "for signers"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 271,
+        "matchedSections": [
+          "core concept: m-of-n scheme",
+          "thresholds & configuration",
+          "communication & documentation",
+          "signer rotation",
+          "training & drills",
+          "operational best practices",
+          "contract-level security",
+          "acknowledgements",
+          "setup best practices"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/overview",
+        "title": "Multisig Security Framework | SEAL",
+        "score": 239,
+        "matchedSections": [
+          "how to use this guide",
+          "core principles",
+          "1. foundation",
+          "2. multisig administration",
+          "3. for signers",
+          "4. reference"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 149,
+        "matchedSections": [
+          "solana",
+          "self-hosted multisig ui",
+          "delegated proposer",
+          "allowance module (required for treasury multisigs)",
+          "zodiac delay modifier (time-locks)",
+          "contract-level controls",
+          "pre-launch checklist",
+          "practice on testnet",
+          "nested safes",
+          "next steps",
+          "active monitoring",
+          "verify basic functionality"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/registration-and-documentation",
+        "title": "Multisig Registration & Documentation | SEAL",
+        "score": 129,
+        "matchedSections": [
+          "protocol documentation",
+          "signer verification process",
+          "initial registration",
+          "regular reviews",
+          "signer changes",
+          "documentation updates",
+          "related documents",
+          "ongoing maintenance"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 118,
+        "matchedSections": [
+          "eternal safe - decentralized fork of safe\\{wallet\\}",
+          "squads public client - open source squads v4 interface",
+          "related documents",
+          "administrator responsibilities",
+          "enhanced verification",
+          "regular practice",
+          "support resources"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/use-case-specific-requirements",
+        "title": "Multisig Use Case Requirements | SEAL",
+        "score": 95,
+        "matchedSections": [
+          "treasury multisigs",
+          "key requirements:",
+          "emergency response multisigs",
+          "capital allocation multisigs",
+          "smart contract control multisigs",
+          "threshold considerations:",
+          "configuration",
+          "simulation consideration",
+          "training & drills:",
+          "additional requirements:",
+          "operational constraints:",
+          "veto quorum"
+        ]
+      },
+      {
+        "page": "/wallet-security/signing-and-verification/secure-multisig-signing-process",
+        "title": "Secure Multisig Signing Process | SEAL",
+        "score": 93,
+        "matchedSections": [
+          "process",
+          "phase 2: executing the on-chain transaction",
+          "operational best practices"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ms-4.1.1",
+    "controlTitle": "Transaction Handling Process",
+    "description": "Do you have a defined, documented process for how transactions are proposed, verified, and executed?",
+    "baselineCount": 8,
+    "baselines": [
+      "Process covers initiation, approval, simulation, execution, and confirmation",
+      "Defines who is authorized to initiate transactions",
+      "Each signer independently verifies transaction details (chain ID, target address, calldata, value, nonce, operation type) before signing",
+      "Transaction hashes compared across at least two independent interfaces (e.g., web UI and CLI, or web and mobile app)",
+      "DELEGATECALL operations to untrusted addresses flagged as high risk",
+      "High-risk transactions (large transfers, emergency actions, protocol changes) require waiting periods where feasible and elevated threshold approval",
+      "High-risk thresholds defined based on classification and reviewed periodically",
+      "Private transaction submission used when appropriate to prevent front-running or MEV extraction"
+    ],
+    "candidates": [
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 293,
+        "matchedSections": [
+          "thresholds & configuration",
+          "signer rotation",
+          "setup best practices",
+          "core concept: m-of-n scheme",
+          "communication & documentation",
+          "training & drills",
+          "operational best practices",
+          "contract-level security"
+        ]
+      },
+      {
+        "page": "/wallet-security/signing-and-verification/secure-multisig-signing-process",
+        "title": "Secure Multisig Signing Process | SEAL",
+        "score": 163,
+        "matchedSections": [
+          "phase 1: signing the off-chain message",
+          "process",
+          "phase 2: executing the on-chain transaction",
+          "operational best practices",
+          "key definitions (evm)",
+          "simulation notes with timelocks"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 157,
+        "matchedSections": [
+          "evm networks (ethereum, base, etc.)",
+          "solana",
+          "pre-launch checklist",
+          "nested safes",
+          "self-hosted multisig ui",
+          "delegated proposer",
+          "address whitelisting",
+          "verify basic functionality",
+          "next steps"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/use-case-specific-requirements",
+        "title": "Multisig Use Case Requirements | SEAL",
+        "score": 137,
+        "matchedSections": [
+          "additional requirements:",
+          "threshold considerations:",
+          "hot/cold wallet separation",
+          "external signer requirements",
+          "training & drills:",
+          "operational constraints:",
+          "configuration",
+          "veto quorum",
+          "external transaction monitoring",
+          "simulation consideration"
+        ]
+      },
+      {
+        "page": "/opsec/core-concepts/web3-considerations",
+        "title": "Web3 Security Considerations",
+        "score": 122,
+        "matchedSections": [
+          "suggested steps"
+        ]
+      },
+      {
+        "page": "/wallet-security/signing-and-verification/secure-multisig-safe-verification",
+        "title": "Safe Multisig Verification | SEAL",
+        "score": 122,
+        "matchedSections": [
+          "basic rules",
+          "tool diversity recommendation",
+          "key definitions (evm)",
+          "2) simulation testing"
+        ]
+      },
+      {
+        "page": "/wallet-security/tools-and-resources",
+        "title": "Wallet Security Tools & Resources | SEAL",
+        "score": 115,
+        "matchedSections": [
+          "security training",
+          "network security",
+          "rabby wallet",
+          "transaction simulation",
+          "conversion & utilities"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 110,
+        "matchedSections": [
+          "administrator responsibilities",
+          "eternal safe - decentralized fork of safe\\{wallet\\}",
+          "enhanced verification",
+          "regular practice",
+          "support resources"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ms-4.1.2",
+    "controlTitle": "Transaction Audit Trails",
+    "description": "Do you keep records of all transaction reviews, approvals, and executions?",
+    "baselineCount": 2,
+    "baselines": [
+      "Retained for 3 years",
+      "Records include proposer, approvers, verification evidence, timestamps, and issues encountered"
+    ],
+    "candidates": [
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 15,
+        "matchedSections": []
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 14,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/core-concepts/web3-considerations",
+        "title": "Web3 Security Considerations",
+        "score": 14,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 14,
+        "matchedSections": []
+      },
+      {
+        "page": "/wallet-security/signing-and-verification/secure-multisig-safe-verification",
+        "title": "Safe Multisig Verification | SEAL",
+        "score": 14,
+        "matchedSections": []
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 13,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/appendices/case-studies",
+        "title": "OpSec Case Studies",
+        "score": 12,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/control-domains/technical",
+        "title": "Technical Security Controls",
+        "score": 12,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "ms-4.1.3",
+    "controlTitle": "Tool and Platform Evaluation",
+    "description": "Do you vet the tools and platforms used for multisig operations before adoption?",
+    "baselineCount": 2,
+    "baselines": [
+      "Evaluation considers whether tools are open source or audited by 2+ reputable firms, have no known critical unpatched vulnerabilities, and have established ecosystem adoption",
+      "Formal process for adopting new tools"
+    ],
+    "candidates": [
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 334,
+        "matchedSections": [
+          "for multisig administrators",
+          "planning & setup",
+          "documentation & communication",
+          "ongoing management",
+          "hardware & security setup",
+          "operational readiness",
+          "emergency preparedness",
+          "personal security",
+          "compliance",
+          "emergency response multisigs",
+          "treasury multisigs",
+          "smart contract control multisigs",
+          "required reading completed",
+          "role-specific documentation",
+          "training completion"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/overview",
+        "title": "Multisig Security Framework | SEAL",
+        "score": 235,
+        "matchedSections": [
+          "how to use this guide",
+          "core principles",
+          "1. foundation",
+          "2. multisig administration",
+          "3. for signers",
+          "4. reference"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 216,
+        "matchedSections": [
+          "core concept: m-of-n scheme",
+          "thresholds & configuration",
+          "communication & documentation",
+          "signer rotation",
+          "training & drills",
+          "operational best practices",
+          "contract-level security",
+          "acknowledgements"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 136,
+        "matchedSections": [
+          "eternal safe - decentralized fork of safe\\{wallet\\}",
+          "squads public client - open source squads v4 interface",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 136,
+        "matchedSections": [
+          "solana",
+          "self-hosted multisig ui",
+          "delegated proposer",
+          "allowance module (required for treasury multisigs)",
+          "zodiac delay modifier (time-locks)",
+          "contract-level controls",
+          "pre-launch checklist",
+          "practice on testnet",
+          "nested safes",
+          "next steps",
+          "active monitoring"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/registration-and-documentation",
+        "title": "Multisig Registration & Documentation | SEAL",
+        "score": 104,
+        "matchedSections": [
+          "protocol documentation",
+          "signer verification process",
+          "initial registration",
+          "regular reviews",
+          "signer changes",
+          "documentation updates",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/wallet-security/tools-and-resources",
+        "title": "Wallet Security Tools & Resources | SEAL",
+        "score": 83,
+        "matchedSections": [
+          "monitoring & alerting",
+          "multisig monitoring",
+          "network security",
+          "transaction verification",
+          "security training"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/use-case-specific-requirements",
+        "title": "Multisig Use Case Requirements | SEAL",
+        "score": 76,
+        "matchedSections": [
+          "treasury multisigs",
+          "key requirements:",
+          "emergency response multisigs",
+          "capital allocation multisigs",
+          "smart contract control multisigs",
+          "threshold considerations:",
+          "configuration",
+          "simulation consideration"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ms-4.1.4",
+    "controlTitle": "Backup Signing Infrastructure",
+    "description": "Do you have backup infrastructure in case your primary signing tools are unavailable?",
+    "baselineCount": 3,
+    "baselines": [
+      "Alternate signing UI",
+      "2-3 backup RPC providers",
+      "Alternate block explorer"
+    ],
+    "candidates": [
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 153,
+        "matchedSections": [
+          "rpc backup options",
+          "administrator responsibilities",
+          "block explorer backup options",
+          "evm networks",
+          "squads public client - open source squads v4 interface",
+          "enhanced verification",
+          "regular practice",
+          "emergency drills",
+          "support resources",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 147,
+        "matchedSections": [
+          "documentation & communication",
+          "ongoing management",
+          "hardware & security setup",
+          "operational readiness",
+          "emergency preparedness",
+          "emergency procedures",
+          "tool proficiency",
+          "role-specific documentation",
+          "regular updates"
+        ]
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 130,
+        "matchedSections": [
+          "before traveling",
+          "**back up and prepare for loss**",
+          "**protect accounts with 2fa redundancy**",
+          "**secure your wallets and keys**",
+          "**plan emergency and incident responses**",
+          "**inspect and clean your devices**",
+          "**protect crypto keys with multi-party controls**",
+          "**post-trip device rebuilding**",
+          "conclusion"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/technical",
+        "title": "Technical Security Controls",
+        "score": 112,
+        "matchedSections": [
+          "encrypted storage & backups",
+          "key components",
+          "implementation steps",
+          "web3-specific considerations"
+        ]
+      },
+      {
+        "page": "/wallet-security/seed-phrase-management",
+        "title": "Seed Phrase Management",
+        "score": 86,
+        "matchedSections": [
+          "tamper evident bags:",
+          "seed phrase encryption",
+          "advanced backup options",
+          "multisig social recovery",
+          "ongoing security hygiene",
+          "trusted contacts"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/personal-security-opsec",
+        "title": "Multisig Personal Security (OpSec) | SEAL",
+        "score": 76,
+        "matchedSections": [
+          "basic requirements",
+          "for extra security",
+          "what to bring",
+          "what not to bring",
+          "basic travel security"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 53,
+        "matchedSections": [
+          "immediate steps",
+          "if telegram/signal/discord gets taken over",
+          "multi-channel notification",
+          "for emergency response multisigs",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/wallet-security/intermediates-and-medium-funds",
+        "title": "Wallets for Intermediates & Medium Funds | SEAL",
+        "score": 40,
+        "matchedSections": [
+          "backup device (for critical operations & multisigs)"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ms-5.1.1",
+    "controlTitle": "Secure Communication Procedures",
+    "description": "Do you have secure communication procedures for multisig operations, including standard identity verification?",
+    "baselineCount": 5,
+    "baselines": [
+      "Dedicated primary and backup channels on different platforms",
+      "End-to-end encryption, MFA required, invitation-based membership",
+      "Signer identity verified as standard procedure during signing operations (e.g., code words, video call, secondary authenticated channel)",
+      "Documented procedures for channel compromise including switching to backup channels and out-of-band verification",
+      "All signers trained on these procedures; compromise response tested annually"
+    ],
+    "candidates": [
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 523,
+        "matchedSections": [
+          "for multisig administrators",
+          "planning & setup",
+          "documentation & communication",
+          "ongoing management",
+          "hardware & security setup",
+          "operational readiness",
+          "emergency preparedness",
+          "personal security",
+          "compliance",
+          "emergency response multisigs",
+          "treasury multisigs",
+          "smart contract control multisigs",
+          "required reading completed",
+          "role-specific documentation",
+          "training completion",
+          "for signers",
+          "emergency procedures",
+          "tool proficiency",
+          "regular updates"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 480,
+        "matchedSections": [
+          "core concept: m-of-n scheme",
+          "thresholds & configuration",
+          "communication & documentation",
+          "signer rotation",
+          "training & drills",
+          "operational best practices",
+          "contract-level security",
+          "acknowledgements",
+          "setup best practices"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 311,
+        "matchedSections": [
+          "eternal safe - decentralized fork of safe\\{wallet\\}",
+          "squads public client - open source squads v4 interface",
+          "related documents",
+          "administrator responsibilities",
+          "enhanced verification",
+          "regular practice",
+          "support resources",
+          "rpc backup options",
+          "block explorer backup options",
+          "evm networks",
+          "emergency drills"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/overview",
+        "title": "Multisig Security Framework | SEAL",
+        "score": 297,
+        "matchedSections": [
+          "how to use this guide",
+          "core principles",
+          "1. foundation",
+          "2. multisig administration",
+          "3. for signers",
+          "4. reference"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 264,
+        "matchedSections": [
+          "solana",
+          "self-hosted multisig ui",
+          "delegated proposer",
+          "allowance module (required for treasury multisigs)",
+          "zodiac delay modifier (time-locks)",
+          "contract-level controls",
+          "pre-launch checklist",
+          "practice on testnet",
+          "nested safes",
+          "next steps",
+          "active monitoring",
+          "evm networks (ethereum, base, etc.)",
+          "address whitelisting",
+          "verify basic functionality"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 257,
+        "matchedSections": [
+          "recovery process",
+          "for emergency response multisigs",
+          "related documents",
+          "identity verification process",
+          "replacement coordination",
+          "emergency drill procedures",
+          "immediate steps",
+          "if telegram/signal/discord gets taken over",
+          "multi-channel notification"
+        ]
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 249,
+        "matchedSections": [
+          "additional precautions for high-risk travelers",
+          "**use loaner or \"burner\" devices**",
+          "**protect crypto keys with multi-party controls**",
+          "conclusion",
+          "**secure devices with encryption & updates**",
+          "**plan emergency and incident responses**",
+          "**network safety – avoid untrusted wi-fi & bluetooth**",
+          "**plan for customs and border checks**",
+          "**enhanced device protections**",
+          "before traveling",
+          "**back up and prepare for loss**",
+          "**protect accounts with 2fa redundancy**",
+          "**secure your wallets and keys**",
+          "**inspect and clean your devices**",
+          "**post-trip device rebuilding**"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/registration-and-documentation",
+        "title": "Multisig Registration & Documentation | SEAL",
+        "score": 195,
+        "matchedSections": [
+          "protocol documentation",
+          "signer verification process",
+          "initial registration",
+          "regular reviews",
+          "signer changes",
+          "documentation updates",
+          "related documents",
+          "update template",
+          "ongoing maintenance"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ms-5.1.2",
+    "controlTitle": "Emergency Contact List",
+    "description": "Do you maintain a current emergency contact list for all multisig stakeholders?",
+    "baselineCount": 3,
+    "baselines": [
+      "Includes protocol security team, external security resources, legal/compliance contacts, and backup contacts for signers",
+      "Personal emergency contacts for each signer (e.g., trusted family member, close colleague) for situations where the signer is unreachable through normal channels",
+      "Reviewed every 6 months"
+    ],
+    "candidates": [
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 567,
+        "matchedSections": [
+          "core concept: m-of-n scheme",
+          "thresholds & configuration",
+          "communication & documentation",
+          "signer rotation",
+          "training & drills",
+          "operational best practices",
+          "contract-level security",
+          "acknowledgements",
+          "setup best practices"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 456,
+        "matchedSections": [
+          "for multisig administrators",
+          "planning & setup",
+          "documentation & communication",
+          "ongoing management",
+          "hardware & security setup",
+          "operational readiness",
+          "emergency preparedness",
+          "personal security",
+          "compliance",
+          "emergency response multisigs",
+          "treasury multisigs",
+          "smart contract control multisigs",
+          "required reading completed",
+          "role-specific documentation",
+          "training completion",
+          "for signers",
+          "emergency procedures",
+          "tool proficiency",
+          "regular updates"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 298,
+        "matchedSections": [
+          "solana",
+          "self-hosted multisig ui",
+          "delegated proposer",
+          "allowance module (required for treasury multisigs)",
+          "zodiac delay modifier (time-locks)",
+          "contract-level controls",
+          "pre-launch checklist",
+          "practice on testnet",
+          "nested safes",
+          "next steps",
+          "active monitoring",
+          "verify basic functionality",
+          "evm networks (ethereum, base, etc.)",
+          "address whitelisting"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/overview",
+        "title": "Multisig Security Framework | SEAL",
+        "score": 286,
+        "matchedSections": [
+          "how to use this guide",
+          "core principles",
+          "1. foundation",
+          "2. multisig administration",
+          "3. for signers",
+          "4. reference"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 265,
+        "matchedSections": [
+          "eternal safe - decentralized fork of safe\\{wallet\\}",
+          "squads public client - open source squads v4 interface",
+          "related documents",
+          "administrator responsibilities",
+          "enhanced verification",
+          "regular practice",
+          "support resources",
+          "rpc backup options",
+          "block explorer backup options",
+          "evm networks",
+          "emergency drills"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/registration-and-documentation",
+        "title": "Multisig Registration & Documentation | SEAL",
+        "score": 254,
+        "matchedSections": [
+          "protocol documentation",
+          "signer verification process",
+          "initial registration",
+          "regular reviews",
+          "signer changes",
+          "documentation updates",
+          "related documents",
+          "ongoing maintenance",
+          "update template"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 233,
+        "matchedSections": [
+          "recovery process",
+          "for emergency response multisigs",
+          "related documents",
+          "identity verification process",
+          "replacement coordination",
+          "emergency drill procedures",
+          "immediate steps",
+          "if telegram/signal/discord gets taken over",
+          "multi-channel notification"
+        ]
+      },
+      {
+        "page": "/wallet-security/signing-and-verification/secure-multisig-signing-process",
+        "title": "Secure Multisig Signing Process | SEAL",
+        "score": 176,
+        "matchedSections": [
+          "process",
+          "phase 2: executing the on-chain transaction",
+          "operational best practices",
+          "phase 1: signing the off-chain message"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ms-6.1.1",
+    "controlTitle": "Emergency Playbooks",
+    "description": "Do you have step-by-step emergency playbooks?",
+    "baselineCount": 3,
+    "baselines": [
+      "Scenarios covered include key compromise, lost access, communication channel compromise, and urgent protocol actions",
+      "Each scenario has procedures and escalation paths",
+      "Playbooks accessible through at least one backup method independent of the primary documentation platform"
+    ],
+    "candidates": [
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 91,
+        "matchedSections": [
+          "rpc backup options",
+          "administrator responsibilities",
+          "block explorer backup options",
+          "evm networks",
+          "squads public client - open source squads v4 interface",
+          "enhanced verification",
+          "regular practice",
+          "emergency drills",
+          "support resources",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 85,
+        "matchedSections": [
+          "before traveling",
+          "**back up and prepare for loss**",
+          "**protect accounts with 2fa redundancy**",
+          "**secure your wallets and keys**",
+          "**plan emergency and incident responses**",
+          "**inspect and clean your devices**",
+          "**protect crypto keys with multi-party controls**",
+          "**post-trip device rebuilding**",
+          "conclusion"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 83,
+        "matchedSections": [
+          "documentation & communication",
+          "ongoing management",
+          "hardware & security setup",
+          "operational readiness",
+          "emergency preparedness",
+          "emergency procedures",
+          "tool proficiency",
+          "role-specific documentation",
+          "regular updates"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 75,
+        "matchedSections": [
+          "security team contact",
+          "internal escalation",
+          "immediate steps",
+          "if telegram/signal/discord gets taken over",
+          "multi-channel notification",
+          "for emergency response multisigs",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/wallet-security/seed-phrase-management",
+        "title": "Seed Phrase Management",
+        "score": 58,
+        "matchedSections": [
+          "tamper evident bags:",
+          "seed phrase encryption",
+          "advanced backup options",
+          "multisig social recovery",
+          "ongoing security hygiene",
+          "trusted contacts"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/technical",
+        "title": "Technical Security Controls",
+        "score": 57,
+        "matchedSections": [
+          "encrypted storage & backups",
+          "key components",
+          "implementation steps",
+          "web3-specific considerations"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 46,
+        "matchedSections": [
+          "thresholds & configuration",
+          "communication & documentation"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/personal-security-opsec",
+        "title": "Multisig Personal Security (OpSec) | SEAL",
+        "score": 44,
+        "matchedSections": [
+          "basic requirements",
+          "for extra security",
+          "what to bring",
+          "what not to bring",
+          "basic travel security"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ms-6.1.2",
+    "controlTitle": "Signer Reachability and Escalation",
+    "description": "Can you reach enough signers to meet quorum at any time, including outside business hours?",
+    "baselineCount": 4,
+    "baselines": [
+      "Response times by classification - Emergency less than 2 hours, Time-Sensitive 2-12 hours, Routine 24-48 hours",
+      "Paging covers all signers including external parties",
+      "Tested quarterly",
+      "Escalation paths documented"
+    ],
+    "candidates": [
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 122,
+        "matchedSections": [
+          "core concept: m-of-n scheme",
+          "thresholds & configuration",
+          "communication & documentation",
+          "signer rotation",
+          "training & drills",
+          "setup best practices"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 81,
+        "matchedSections": [
+          "security team contact",
+          "internal escalation",
+          "identity verification process",
+          "replacement coordination",
+          "for emergency response multisigs",
+          "emergency drill procedures"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/planning-and-classification",
+        "title": "Multisig Planning & Classification | SEAL",
+        "score": 63,
+        "matchedSections": [
+          "identify stakeholders",
+          "step 2: operational assessment"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/use-case-specific-requirements",
+        "title": "Multisig Use Case Requirements | SEAL",
+        "score": 59,
+        "matchedSections": [
+          "training & drills:",
+          "additional requirements:",
+          "operational constraints:",
+          "veto quorum"
+        ]
+      },
+      {
+        "page": "/wallet-security/signing-and-verification/secure-multisig-signing-process",
+        "title": "Secure Multisig Signing Process | SEAL",
+        "score": 58,
+        "matchedSections": [
+          "process",
+          "phase 2: executing the on-chain transaction",
+          "operational best practices"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/registration-and-documentation",
+        "title": "Multisig Registration & Documentation | SEAL",
+        "score": 53,
+        "matchedSections": [
+          "initial registration",
+          "ongoing maintenance",
+          "signer changes"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 52,
+        "matchedSections": [
+          "delegated proposer",
+          "verify basic functionality",
+          "pre-launch checklist",
+          "nested safes",
+          "next steps"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 48,
+        "matchedSections": [
+          "planning & setup",
+          "ongoing management",
+          "for signers",
+          "emergency response multisigs"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ms-6.1.3",
+    "controlTitle": "Multisig Monitoring and Alerts",
+    "description": "Do you monitor all multisigs for unauthorized or suspicious activity?",
+    "baselineCount": 3,
+    "baselines": [
+      "Monitored events include signer/threshold changes, transfers exceeding thresholds, nonce gaps, interactions with unknown addresses, failed transactions, module/guard changes, and low submitter/proposer balances",
+      "Alerting and escalation paths documented",
+      "Monitoring infrastructure protected against tampering"
+    ],
+    "candidates": [
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 430,
+        "matchedSections": [
+          "core concept: m-of-n scheme",
+          "thresholds & configuration",
+          "communication & documentation",
+          "signer rotation",
+          "training & drills",
+          "operational best practices",
+          "contract-level security",
+          "acknowledgements",
+          "setup best practices"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 361,
+        "matchedSections": [
+          "for multisig administrators",
+          "planning & setup",
+          "documentation & communication",
+          "ongoing management",
+          "hardware & security setup",
+          "operational readiness",
+          "emergency preparedness",
+          "personal security",
+          "compliance",
+          "emergency response multisigs",
+          "treasury multisigs",
+          "smart contract control multisigs",
+          "required reading completed",
+          "role-specific documentation",
+          "training completion",
+          "for signers"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 282,
+        "matchedSections": [
+          "solana",
+          "self-hosted multisig ui",
+          "delegated proposer",
+          "allowance module (required for treasury multisigs)",
+          "zodiac delay modifier (time-locks)",
+          "contract-level controls",
+          "pre-launch checklist",
+          "practice on testnet",
+          "nested safes",
+          "next steps",
+          "active monitoring",
+          "evm networks (ethereum, base, etc.)",
+          "address whitelisting",
+          "verify basic functionality",
+          "immutable monitoring channels"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/overview",
+        "title": "Multisig Security Framework | SEAL",
+        "score": 241,
+        "matchedSections": [
+          "how to use this guide",
+          "core principles",
+          "1. foundation",
+          "2. multisig administration",
+          "3. for signers",
+          "4. reference"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/registration-and-documentation",
+        "title": "Multisig Registration & Documentation | SEAL",
+        "score": 180,
+        "matchedSections": [
+          "protocol documentation",
+          "signer verification process",
+          "initial registration",
+          "regular reviews",
+          "signer changes",
+          "documentation updates",
+          "related documents",
+          "ongoing maintenance",
+          "update template"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/use-case-specific-requirements",
+        "title": "Multisig Use Case Requirements | SEAL",
+        "score": 162,
+        "matchedSections": [
+          "treasury multisigs",
+          "key requirements:",
+          "emergency response multisigs",
+          "capital allocation multisigs",
+          "smart contract control multisigs",
+          "threshold considerations:",
+          "configuration",
+          "simulation consideration",
+          "additional requirements:",
+          "hot/cold wallet separation",
+          "external signer requirements",
+          "training & drills:",
+          "operational constraints:",
+          "veto quorum",
+          "external transaction monitoring"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 140,
+        "matchedSections": [
+          "eternal safe - decentralized fork of safe\\{wallet\\}",
+          "squads public client - open source squads v4 interface",
+          "related documents",
+          "administrator responsibilities",
+          "enhanced verification",
+          "regular practice",
+          "support resources",
+          "evm networks"
+        ]
+      },
+      {
+        "page": "/wallet-security/tools-and-resources",
+        "title": "Wallet Security Tools & Resources | SEAL",
+        "score": 124,
+        "matchedSections": [
+          "monitoring & alerting",
+          "multisig monitoring",
+          "network security",
+          "transaction verification",
+          "security training"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ms-6.1.4",
+    "controlTitle": "Emergency Drills and Improvement",
+    "description": "Do you regularly rehearse your emergency procedures and track improvements?",
+    "baselineCount": 3,
+    "baselines": [
+      "Annual minimum",
+      "After major procedure changes",
+      "Documentation includes date, participants, response times, issues identified, and improvements made"
+    ],
+    "candidates": [
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 20,
+        "matchedSections": []
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 18,
+        "matchedSections": []
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 18,
+        "matchedSections": []
+      },
+      {
+        "page": "/governance/compliance-regulatory-requirements",
+        "title": "Compliance & Regulatory Requirements | SEAL",
+        "score": 15,
+        "matchedSections": []
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 14,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/appendices/case-studies",
+        "title": "OpSec Case Studies",
+        "score": 14,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 14,
+        "matchedSections": []
+      },
+      {
+        "page": "/multisig-for-protocols/use-case-specific-requirements",
+        "title": "Multisig Use Case Requirements | SEAL",
+        "score": 13,
+        "matchedSections": []
+      }
+    ]
+  }
+]
\ No newline at end of file
diff --git a/scripts/data/mappings/sfc-treasury-ops.json b/scripts/data/mappings/sfc-treasury-ops.json
new file mode 100644
index 00000000..c5af0a32
--- /dev/null
+++ b/scripts/data/mappings/sfc-treasury-ops.json
@@ -0,0 +1,2219 @@
+[
+  {
+    "controlId": "tro-1.1.1",
+    "controlTitle": "Treasury Operations Owner",
+    "description": "Is there a clearly designated person or team accountable for treasury operations?",
+    "baselineCount": 1,
+    "baselines": [
+      "Accountability scope covers policy upkeep, security reviews, operational hygiene, access control oversight, and incident escalation"
+    ],
+    "candidates": [
+      {
+        "page": "/treasury-operations/enhanced-controls",
+        "title": "Enhanced Controls for High-Risk Accounts | SEAL",
+        "score": 66,
+        "matchedSections": [
+          "security monitoring & logging",
+          "access security",
+          "device security",
+          "custody/mpc policy thresholds for treasury operations",
+          "see also"
+        ]
+      },
+      {
+        "page": "/wallet-security/encumbered-wallets",
+        "title": "TEE-based Encumbered Wallets",
+        "score": 38,
+        "matchedSections": [
+          "key benefits & features"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 37,
+        "matchedSections": [
+          "security team contact",
+          "internal escalation"
+        ]
+      },
+      {
+        "page": "/incident-management/playbooks/seal-911-war-room-guidelines",
+        "title": "SEAL 911 War Room Guidelines | SEAL",
+        "score": 33,
+        "matchedSections": [
+          "issue description",
+          "affected addresses"
+        ]
+      },
+      {
+        "page": "/governance/compliance-regulatory-requirements",
+        "title": "Compliance & Regulatory Requirements | SEAL",
+        "score": 32,
+        "matchedSections": [
+          "2. develop a robust security policy framework",
+          "4. access management and control"
+        ]
+      },
+      {
+        "page": "/treasury-operations/overview",
+        "title": "Treasury Operations Security | SEAL",
+        "score": 27,
+        "matchedSections": [
+          "what is treasury operations security?"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 25,
+        "matchedSections": [
+          "setup best practices"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 24,
+        "matchedSections": [
+          "treasury multisigs"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "tro-1.1.2",
+    "controlTitle": "Treasury Registry and Documentation",
+    "description": "Do you maintain a complete, current record of all treasury wallets, accounts, and their configurations?",
+    "baselineCount": 3,
+    "baselines": [
+      "Registry includes wallet/account address, network/chain, custody provider, custody model, purpose/classification, authorized signers/approvers, controlled contracts or protocols, and last review date",
+      "Updated within 24 hours for security-critical changes (signer changes, new wallets), 3 days for routine changes",
+      "Accessible to authorized treasury personnel"
+    ],
+    "candidates": [
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 253,
+        "matchedSections": [
+          "core concept: m-of-n scheme",
+          "thresholds & configuration",
+          "communication & documentation",
+          "signer rotation",
+          "training & drills",
+          "setup best practices",
+          "operational best practices",
+          "contract-level security"
+        ]
+      },
+      {
+        "page": "/treasury-operations/enhanced-controls",
+        "title": "Enhanced Controls for High-Risk Accounts | SEAL",
+        "score": 217,
+        "matchedSections": [
+          "access security",
+          "device security",
+          "custody/mpc policy thresholds for treasury operations",
+          "see also",
+          "mpc for large holdings",
+          "custody policy engine rules",
+          "zero trust architecture alternative",
+          "security monitoring & logging"
+        ]
+      },
+      {
+        "page": "/treasury-operations/transaction-verification",
+        "title": "Treasury Transaction Verification | SEAL",
+        "score": 163,
+        "matchedSections": [
+          "address verification",
+          "key principles summary",
+          "pre-transfer setup (48 hours before)",
+          "day of transfer",
+          "pre-transfer planning (72 hours before)",
+          "transaction parameter security"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 133,
+        "matchedSections": [
+          "delegated proposer",
+          "verify basic functionality",
+          "pre-launch checklist",
+          "nested safes",
+          "next steps",
+          "evm networks (ethereum, base, etc.)",
+          "solana",
+          "self-hosted multisig ui",
+          "address whitelisting",
+          "allowance module (required for treasury multisigs)"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/registration-and-documentation",
+        "title": "Multisig Registration & Documentation | SEAL",
+        "score": 114,
+        "matchedSections": [
+          "initial registration",
+          "ongoing maintenance",
+          "signer changes",
+          "signer verification process",
+          "update template",
+          "documentation updates",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/use-case-specific-requirements",
+        "title": "Multisig Use Case Requirements | SEAL",
+        "score": 105,
+        "matchedSections": [
+          "training & drills:",
+          "additional requirements:",
+          "operational constraints:",
+          "veto quorum",
+          "hot/cold wallet separation",
+          "external signer requirements",
+          "configuration",
+          "treasury multisigs"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 93,
+        "matchedSections": [
+          "identity verification process",
+          "replacement coordination",
+          "for emergency response multisigs",
+          "emergency drill procedures",
+          "recovery process"
+        ]
+      },
+      {
+        "page": "/wallet-security/signing-and-verification/secure-multisig-signing-process",
+        "title": "Secure Multisig Signing Process | SEAL",
+        "score": 90,
+        "matchedSections": [
+          "process",
+          "phase 2: executing the on-chain transaction",
+          "operational best practices",
+          "phase 1: signing the off-chain message"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "tro-1.1.3",
+    "controlTitle": "Custody Architecture Rationale",
+    "description": "Do you have documented rationale for your treasury custody architecture?",
+    "baselineCount": 3,
+    "baselines": [
+      "Custody model documented for each wallet/account (custodial, self-custody, co-managed, MPC, multisig, HSM)",
+      "Technology trade-offs understood by the team (not necessarily a formal document — could be a brief internal memo)",
+      "Custody architecture reviewed when treasury size, operational needs, or risk profile changes significantly"
+    ],
+    "candidates": [
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 336,
+        "matchedSections": [
+          "for multisig administrators",
+          "planning & setup",
+          "documentation & communication",
+          "ongoing management",
+          "hardware & security setup",
+          "operational readiness",
+          "emergency preparedness",
+          "personal security",
+          "compliance",
+          "emergency response multisigs",
+          "treasury multisigs",
+          "smart contract control multisigs",
+          "required reading completed",
+          "role-specific documentation",
+          "training completion"
+        ]
+      },
+      {
+        "page": "/treasury-operations/transaction-verification",
+        "title": "Treasury Transaction Verification | SEAL",
+        "score": 305,
+        "matchedSections": [
+          "pre-transfer setup (48 hours before)",
+          "day of transfer",
+          "multi-signature best practices",
+          "address verification",
+          "key principles summary",
+          "pre-transfer planning (72 hours before)",
+          "transaction parameter security"
+        ]
+      },
+      {
+        "page": "/treasury-operations/enhanced-controls",
+        "title": "Enhanced Controls for High-Risk Accounts | SEAL",
+        "score": 297,
+        "matchedSections": [
+          "access security",
+          "device security",
+          "custody/mpc policy thresholds for treasury operations",
+          "see also",
+          "mpc for large holdings",
+          "custody policy engine rules",
+          "zero trust architecture alternative",
+          "security monitoring & logging"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/overview",
+        "title": "Multisig Security Framework | SEAL",
+        "score": 241,
+        "matchedSections": [
+          "how to use this guide",
+          "core principles",
+          "1. foundation",
+          "2. multisig administration",
+          "3. for signers",
+          "4. reference"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 216,
+        "matchedSections": [
+          "core concept: m-of-n scheme",
+          "thresholds & configuration",
+          "communication & documentation",
+          "signer rotation",
+          "training & drills",
+          "operational best practices",
+          "contract-level security",
+          "acknowledgements"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 146,
+        "matchedSections": [
+          "solana",
+          "self-hosted multisig ui",
+          "delegated proposer",
+          "allowance module (required for treasury multisigs)",
+          "zodiac delay modifier (time-locks)",
+          "contract-level controls",
+          "pre-launch checklist",
+          "practice on testnet",
+          "nested safes",
+          "next steps",
+          "active monitoring"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/registration-and-documentation",
+        "title": "Multisig Registration & Documentation | SEAL",
+        "score": 118,
+        "matchedSections": [
+          "protocol documentation",
+          "signer verification process",
+          "initial registration",
+          "regular reviews",
+          "signer changes",
+          "documentation updates",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 113,
+        "matchedSections": [
+          "eternal safe - decentralized fork of safe\\{wallet\\}",
+          "squads public client - open source squads v4 interface",
+          "related documents"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "tro-1.1.4",
+    "controlTitle": "Treasury Infrastructure Change Management",
+    "description": "Do you have change management procedures for treasury infrastructure modifications?",
+    "baselineCount": 5,
+    "baselines": [
+      "Covers wallet setups, custody configurations, signer/approver permission changes, and protocol integrations",
+      "Changes require documented approval before implementation",
+      "All changes logged with justification and approver",
+      "Changes reflected in the treasury registry within defined SLAs",
+      "Rollback procedures documented for critical changes"
+    ],
+    "candidates": [
+      {
+        "page": "/treasury-operations/enhanced-controls",
+        "title": "Enhanced Controls for High-Risk Accounts | SEAL",
+        "score": 198,
+        "matchedSections": [
+          "access security",
+          "device security",
+          "custody/mpc policy thresholds for treasury operations",
+          "see also",
+          "mpc for large holdings",
+          "custody policy engine rules",
+          "zero trust architecture alternative",
+          "security monitoring & logging",
+          "transaction verification"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 192,
+        "matchedSections": [
+          "core concept: m-of-n scheme",
+          "thresholds & configuration",
+          "communication & documentation",
+          "signer rotation",
+          "training & drills",
+          "setup best practices",
+          "operational best practices",
+          "contract-level security"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 107,
+        "matchedSections": [
+          "evm networks (ethereum, base, etc.)",
+          "solana",
+          "self-hosted multisig ui",
+          "delegated proposer",
+          "address whitelisting",
+          "verify basic functionality",
+          "pre-launch checklist",
+          "nested safes",
+          "next steps",
+          "allowance module (required for treasury multisigs)"
+        ]
+      },
+      {
+        "page": "/treasury-operations/transaction-verification",
+        "title": "Treasury Transaction Verification | SEAL",
+        "score": 93,
+        "matchedSections": [
+          "pre-transfer setup (48 hours before)",
+          "address verification",
+          "key principles summary",
+          "day of transfer",
+          "pre-transfer planning (72 hours before)",
+          "transaction parameter security"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/registration-and-documentation",
+        "title": "Multisig Registration & Documentation | SEAL",
+        "score": 91,
+        "matchedSections": [
+          "signer verification process",
+          "update template",
+          "initial registration",
+          "ongoing maintenance",
+          "signer changes",
+          "documentation updates",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/use-case-specific-requirements",
+        "title": "Multisig Use Case Requirements | SEAL",
+        "score": 72,
+        "matchedSections": [
+          "hot/cold wallet separation",
+          "external signer requirements",
+          "training & drills:",
+          "additional requirements:",
+          "operational constraints:",
+          "configuration",
+          "veto quorum",
+          "treasury multisigs"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 60,
+        "matchedSections": [
+          "recovery process",
+          "identity verification process",
+          "replacement coordination",
+          "for emergency response multisigs",
+          "emergency drill procedures"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 56,
+        "matchedSections": [
+          "planning & setup",
+          "ongoing management",
+          "for signers",
+          "operational readiness",
+          "treasury multisigs"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "tro-2.1.1",
+    "controlTitle": "Treasury Wallet Risk Classification",
+    "description": "Do you classify your treasury wallets and accounts by risk level and assign security controls accordingly?",
+    "baselineCount": 5,
+    "baselines": [
+      "Classification considers financial exposure, operational dependency, and regulatory impact",
+      "Impact levels defined (e.g., Low <1%, Medium 1-10%, High 10-25%, Critical >25% of total assets)",
+      "Operational types defined based on transaction frequency and urgency requirements",
+      "Each classification maps to specific controls including approval thresholds, MFA requirements, whitelist delays, and monitoring levels",
+      "Classification reviewed when asset values, operational patterns, or risk profile change significantly"
+    ],
+    "candidates": [
+      {
+        "page": "/treasury-operations/enhanced-controls",
+        "title": "Enhanced Controls for High-Risk Accounts | SEAL",
+        "score": 203,
+        "matchedSections": [
+          "mpc for large holdings",
+          "custody/mpc policy thresholds for treasury operations",
+          "custody policy engine rules",
+          "security monitoring & logging",
+          "access security",
+          "device security",
+          "see also",
+          "transaction verification"
+        ]
+      },
+      {
+        "page": "/treasury-operations/classification",
+        "title": "Treasury Security Classification | SEAL",
+        "score": 125,
+        "matchedSections": [
+          "step 4: document your decision",
+          "step 1: impact assessment",
+          "step 2: operational assessment"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 110,
+        "matchedSections": [
+          "thresholds & configuration",
+          "signer rotation",
+          "setup best practices",
+          "core concept: m-of-n scheme",
+          "operational best practices"
+        ]
+      },
+      {
+        "page": "/treasury-operations/overview",
+        "title": "Treasury Operations Security | SEAL",
+        "score": 92,
+        "matchedSections": [
+          "[classification framework](./classification)",
+          "what is treasury operations security?",
+          "[enhanced controls](./enhanced-controls)"
+        ]
+      },
+      {
+        "page": "/monitoring/thresholds",
+        "title": "Monitoring Alert Thresholds",
+        "score": 87,
+        "matchedSections": [
+          "set thresholds for alerts",
+          "adjust thresholds over time",
+          "multi-layered thresholds"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/planning-and-classification",
+        "title": "Multisig Planning & Classification | SEAL",
+        "score": 76,
+        "matchedSections": [
+          "classification process",
+          "define purpose and scope"
+        ]
+      },
+      {
+        "page": "/wallet-security/tools-and-resources",
+        "title": "Wallet Security Tools & Resources | SEAL",
+        "score": 69,
+        "matchedSections": [
+          "network security",
+          "monitoring & alerting",
+          "multisig monitoring"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 68,
+        "matchedSections": [
+          "evm networks (ethereum, base, etc.)",
+          "solana",
+          "pre-launch checklist",
+          "nested safes",
+          "allowance module (required for treasury multisigs)",
+          "active monitoring",
+          "immutable monitoring channels"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "tro-2.1.2",
+    "controlTitle": "Fund Allocation Limits and Rebalancing",
+    "description": "Do you enforce fund allocation limits and rebalancing triggers across your treasury?",
+    "baselineCount": 4,
+    "baselines": [
+      "Maximum allocation defined per wallet, per custody provider, and per chain",
+      "Rebalancing triggers documented (e.g., when a wallet exceeds its allocation ceiling or falls below operational minimums)",
+      "Allocation limits reviewed periodically and after significant treasury changes",
+      "No single wallet or custody account holds more than the organization's defined maximum concentration"
+    ],
+    "candidates": [
+      {
+        "page": "/treasury-operations/enhanced-controls",
+        "title": "Enhanced Controls for High-Risk Accounts | SEAL",
+        "score": 244,
+        "matchedSections": [
+          "access security",
+          "device security",
+          "custody/mpc policy thresholds for treasury operations",
+          "see also",
+          "mpc for large holdings",
+          "custody policy engine rules",
+          "zero trust architecture alternative",
+          "security monitoring & logging",
+          "transaction verification"
+        ]
+      },
+      {
+        "page": "/treasury-operations/transaction-verification",
+        "title": "Treasury Transaction Verification | SEAL",
+        "score": 121,
+        "matchedSections": [
+          "pre-transfer setup (48 hours before)",
+          "day of transfer",
+          "pre-transfer planning (72 hours before)",
+          "address verification",
+          "transaction parameter security",
+          "key principles summary"
+        ]
+      },
+      {
+        "page": "/treasury-operations/classification",
+        "title": "Treasury Security Classification | SEAL",
+        "score": 58,
+        "matchedSections": [
+          "step 1: impact assessment",
+          "step 4: document your decision",
+          "step 2: operational assessment"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/use-case-specific-requirements",
+        "title": "Multisig Use Case Requirements | SEAL",
+        "score": 51,
+        "matchedSections": [
+          "treasury multisigs",
+          "hot/cold wallet separation"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 44,
+        "matchedSections": [
+          "core concept: m-of-n scheme"
+        ]
+      },
+      {
+        "page": "/wallet-security/encumbered-wallets",
+        "title": "TEE-based Encumbered Wallets",
+        "score": 41,
+        "matchedSections": [
+          "security considerations & best practices"
+        ]
+      },
+      {
+        "page": "/incident-management/playbooks/seal-911-war-room-guidelines",
+        "title": "SEAL 911 War Room Guidelines | SEAL",
+        "score": 37,
+        "matchedSections": [
+          "issue description",
+          "affected addresses"
+        ]
+      },
+      {
+        "page": "/treasury-operations/overview",
+        "title": "Treasury Operations Security | SEAL",
+        "score": 37,
+        "matchedSections": [
+          "what is treasury operations security?"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "tro-3.1.1",
+    "controlTitle": "Custody Platform Security Configuration",
+    "description": "Do you configure and maintain security controls on your custody platforms?",
+    "baselineCount": 6,
+    "baselines": [
+      "Transaction policy rules configured: multi-approval workflows, approval thresholds scaled to transaction value, address whitelisting with cooling-off periods, velocity/spending limits",
+      "Hardware security key MFA required for all approvers on High and Critical accounts",
+      "Session timeouts and re-authentication for sensitive operations",
+      "Network restrictions: IP whitelisting, VPN requirements where supported, geographic access restrictions",
+      "Separation of duties enforced: initiators cannot approve their own transactions, admins cannot unilaterally execute withdrawals",
+      "Platform configurations documented and reviewed at least quarterly"
+    ],
+    "candidates": [
+      {
+        "page": "/treasury-operations/enhanced-controls",
+        "title": "Enhanced Controls for High-Risk Accounts | SEAL",
+        "score": 187,
+        "matchedSections": [
+          "mpc for large holdings",
+          "custody/mpc policy thresholds for treasury operations",
+          "custody policy engine rules",
+          "security monitoring & logging",
+          "access security",
+          "device security",
+          "zero trust architecture alternative"
+        ]
+      },
+      {
+        "page": "/treasury-operations/transaction-verification",
+        "title": "Treasury Transaction Verification | SEAL",
+        "score": 111,
+        "matchedSections": [
+          "pre-transfer setup (48 hours before)",
+          "address verification",
+          "transaction parameter security",
+          "day of transfer",
+          "pre-transfer planning (72 hours before)",
+          "key principles summary"
+        ]
+      },
+      {
+        "page": "/treasury-operations/registration-documents",
+        "title": "Custodial Account Registration | SEAL",
+        "score": 101,
+        "matchedSections": [
+          "security configuration template"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 93,
+        "matchedSections": [
+          "thresholds & configuration",
+          "signer rotation",
+          "setup best practices"
+        ]
+      },
+      {
+        "page": "/wallet-security/encumbered-wallets",
+        "title": "TEE-based Encumbered Wallets",
+        "score": 73,
+        "matchedSections": [
+          "security considerations & best practices"
+        ]
+      },
+      {
+        "page": "/treasury-operations/classification",
+        "title": "Treasury Security Classification | SEAL",
+        "score": 64,
+        "matchedSections": [
+          "step 4: document your decision",
+          "step 1: impact assessment"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/personal-security-opsec",
+        "title": "Multisig Personal Security (OpSec) | SEAL",
+        "score": 62,
+        "matchedSections": []
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 57,
+        "matchedSections": [
+          "evm networks (ethereum, base, etc.)",
+          "solana",
+          "pre-launch checklist",
+          "nested safes"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "tro-3.1.2",
+    "controlTitle": "Credential and Secret Management",
+    "description": "Do you securely manage all credentials and secrets used in treasury operations?",
+    "baselineCount": 5,
+    "baselines": [
+      "Covers API keys, service accounts, owner/admin credentials, and signing keys",
+      "Credentials stored in dedicated secret management systems, not in code, documents, or shared drives",
+      "Owner and admin credentials isolated from day-to-day operational access",
+      "Credential rotation schedule defined and enforced",
+      "Access to credentials logged and monitored"
+    ],
+    "candidates": [
+      {
+        "page": "/treasury-operations/enhanced-controls",
+        "title": "Enhanced Controls for High-Risk Accounts | SEAL",
+        "score": 124,
+        "matchedSections": [
+          "access security",
+          "device security",
+          "custody/mpc policy thresholds for treasury operations",
+          "see also",
+          "transaction verification",
+          "security monitoring & logging"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/personal-security-opsec",
+        "title": "Multisig Personal Security (OpSec) | SEAL",
+        "score": 55,
+        "matchedSections": [
+          "dns security"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 54,
+        "matchedSections": [
+          "core concept: m-of-n scheme",
+          "thresholds & configuration"
+        ]
+      },
+      {
+        "page": "/wallet-security/encumbered-wallets",
+        "title": "TEE-based Encumbered Wallets",
+        "score": 45,
+        "matchedSections": []
+      },
+      {
+        "page": "/incident-management/playbooks/malware",
+        "title": "Malware Infection Response",
+        "score": 44,
+        "matchedSections": [
+          "secure your crypto assets"
+        ]
+      },
+      {
+        "page": "/wallet-security/seed-phrase-management",
+        "title": "Seed Phrase Management",
+        "score": 43,
+        "matchedSections": []
+      },
+      {
+        "page": "/wallet-security/custodial-vs-non-custodial",
+        "title": "Custodial Vs Non-Custodial Wallets | SEAL",
+        "score": 40,
+        "matchedSections": [
+          "characteristics"
+        ]
+      },
+      {
+        "page": "/treasury-operations/classification",
+        "title": "Treasury Security Classification | SEAL",
+        "score": 34,
+        "matchedSections": [
+          "step 1: impact assessment",
+          "step 2: operational assessment"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "tro-3.1.3",
+    "controlTitle": "Access Reviews for Treasury Systems",
+    "description": "Do you periodically review who has access to treasury systems?",
+    "baselineCount": 3,
+    "baselines": [
+      "Access reviews conducted at least quarterly for High/Critical accounts, annually for others",
+      "Reviews verify each user still requires their current access level",
+      "Access promptly revoked when personnel change roles or leave"
+    ],
+    "candidates": [
+      {
+        "page": "/treasury-operations/enhanced-controls",
+        "title": "Enhanced Controls for High-Risk Accounts | SEAL",
+        "score": 82,
+        "matchedSections": [
+          "access security",
+          "device security",
+          "custody/mpc policy thresholds for treasury operations",
+          "see also"
+        ]
+      },
+      {
+        "page": "/treasury-operations/registration-documents",
+        "title": "Custodial Account Registration | SEAL",
+        "score": 50,
+        "matchedSections": []
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 38,
+        "matchedSections": []
+      },
+      {
+        "page": "/multisig-for-protocols/personal-security-opsec",
+        "title": "Multisig Personal Security (OpSec) | SEAL",
+        "score": 36,
+        "matchedSections": []
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 35,
+        "matchedSections": []
+      },
+      {
+        "page": "/treasury-operations/overview",
+        "title": "Treasury Operations Security | SEAL",
+        "score": 31,
+        "matchedSections": [
+          "what is treasury operations security?"
+        ]
+      },
+      {
+        "page": "/wallet-security/encumbered-wallets",
+        "title": "TEE-based Encumbered Wallets",
+        "score": 31,
+        "matchedSections": []
+      },
+      {
+        "page": "/governance/compliance-regulatory-requirements",
+        "title": "Compliance & Regulatory Requirements | SEAL",
+        "score": 30,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "tro-3.1.4",
+    "controlTitle": "Personnel Operational Security",
+    "description": "Do you enforce operational security requirements for treasury personnel?",
+    "baselineCount": 6,
+    "baselines": [
+      "Device security requirements documented: dedicated devices for custody access, full disk encryption, automatic screen lock",
+      "Signing devices (hardware wallets) securely stored when not in use",
+      "Backup materials (seed phrases, recovery keys) stored securely with geographic distribution",
+      "VPN mandatory for all remote treasury platform access",
+      "Travel security procedures for personnel with signing or custody access capabilities",
+      "Mobile devices used as second factors have endpoint security monitoring"
+    ],
+    "candidates": [
+      {
+        "page": "/treasury-operations/enhanced-controls",
+        "title": "Enhanced Controls for High-Risk Accounts | SEAL",
+        "score": 287,
+        "matchedSections": [
+          "device security",
+          "access security",
+          "custody/mpc policy thresholds for treasury operations",
+          "see also",
+          "mpc for large holdings",
+          "custody policy engine rules",
+          "zero trust architecture alternative",
+          "security monitoring & logging"
+        ]
+      },
+      {
+        "page": "/wallet-security/seed-phrase-management",
+        "title": "Seed Phrase Management",
+        "score": 163,
+        "matchedSections": [
+          "multisig social recovery",
+          "private key & seed phrase management",
+          "seed phrase encryption",
+          "tamper evident bags:",
+          "advanced backup options",
+          "ongoing security hygiene",
+          "trusted contacts"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/personal-security-opsec",
+        "title": "Multisig Personal Security (OpSec) | SEAL",
+        "score": 160,
+        "matchedSections": [
+          "what not to bring",
+          "basic requirements",
+          "start with basics",
+          "for extra security",
+          "what to bring",
+          "basic travel security",
+          "network monitoring tools"
+        ]
+      },
+      {
+        "page": "/treasury-operations/transaction-verification",
+        "title": "Treasury Transaction Verification | SEAL",
+        "score": 156,
+        "matchedSections": [
+          "pre-transfer setup (48 hours before)",
+          "day of transfer",
+          "pre-transfer planning (72 hours before)",
+          "address verification",
+          "transaction parameter security",
+          "key principles summary"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 126,
+        "matchedSections": [
+          "treasury multisigs",
+          "documentation & communication",
+          "ongoing management",
+          "hardware & security setup",
+          "operational readiness",
+          "emergency preparedness",
+          "emergency procedures",
+          "tool proficiency",
+          "role-specific documentation",
+          "regular updates"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 111,
+        "matchedSections": [
+          "rpc backup options",
+          "administrator responsibilities",
+          "block explorer backup options",
+          "evm networks",
+          "squads public client - open source squads v4 interface",
+          "enhanced verification",
+          "regular practice",
+          "emergency drills",
+          "support resources",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/wallet-security/intermediates-and-medium-funds",
+        "title": "Wallets for Intermediates & Medium Funds | SEAL",
+        "score": 99,
+        "matchedSections": [
+          "recommended setup",
+          "backup device (for critical operations & multisigs)"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 97,
+        "matchedSections": [
+          "thresholds & configuration",
+          "operational best practices",
+          "communication & documentation"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "tro-4.1.1",
+    "controlTitle": "Transaction Verification and Execution",
+    "description": "Do you have a defined process for verifying and executing treasury transactions?",
+    "baselineCount": 8,
+    "baselines": [
+      "Pre-execution verification includes: recipient address validation, amount verification, network confirmation, and transaction simulation",
+      "Test transactions required before sending to new addresses",
+      "Address verified through multiple independent sources; never copied from email, chat, or transaction history",
+      "Multi-party confirmation required: minimum 2 internal personnel for large transfers",
+      "Specific procedures for receiving large incoming transfers (address generation, bidirectional test, sender coordination)",
+      "Specific procedures for OTC transactions where applicable",
+      "High-value transfers (organization-defined threshold) require video call verification with liveness checks",
+      "All transaction parameters read aloud and confirmed before execution"
+    ],
+    "candidates": [
+      {
+        "page": "/treasury-operations/enhanced-controls",
+        "title": "Enhanced Controls for High-Risk Accounts | SEAL",
+        "score": 210,
+        "matchedSections": [
+          "mpc for large holdings",
+          "custody/mpc policy thresholds for treasury operations",
+          "custody policy engine rules",
+          "security monitoring & logging",
+          "access security",
+          "device security",
+          "see also",
+          "transaction verification"
+        ]
+      },
+      {
+        "page": "/treasury-operations/transaction-verification",
+        "title": "Treasury Transaction Verification | SEAL",
+        "score": 210,
+        "matchedSections": [
+          "pre-transfer setup (48 hours before)",
+          "address verification",
+          "transaction parameter security"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 133,
+        "matchedSections": [
+          "thresholds & configuration",
+          "signer rotation",
+          "setup best practices",
+          "core concept: m-of-n scheme"
+        ]
+      },
+      {
+        "page": "/wallet-security/signing-and-verification/secure-multisig-signing-process",
+        "title": "Secure Multisig Signing Process | SEAL",
+        "score": 110,
+        "matchedSections": [
+          "phase 1: signing the off-chain message",
+          "key definitions (evm)",
+          "process",
+          "operational best practices",
+          "simulation notes with timelocks"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/use-case-specific-requirements",
+        "title": "Multisig Use Case Requirements | SEAL",
+        "score": 106,
+        "matchedSections": [
+          "additional requirements:",
+          "threshold considerations:",
+          "treasury multisigs",
+          "hot/cold wallet separation",
+          "external transaction monitoring",
+          "training & drills:",
+          "simulation consideration"
+        ]
+      },
+      {
+        "page": "/wallet-security/signing-and-verification/secure-multisig-safe-verification",
+        "title": "Safe Multisig Verification | SEAL",
+        "score": 105,
+        "matchedSections": [
+          "key definitions (evm)",
+          "2) simulation testing"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 103,
+        "matchedSections": [
+          "evm networks (ethereum, base, etc.)",
+          "solana",
+          "pre-launch checklist",
+          "nested safes",
+          "allowance module (required for treasury multisigs)"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 100,
+        "matchedSections": [
+          "planning & setup",
+          "smart contract control multisigs",
+          "treasury multisigs",
+          "emergency response multisigs"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "tro-4.1.2",
+    "controlTitle": "Signer and Approver Knowledge",
+    "description": "Are treasury signers and approvers knowledgeable in the security practices relevant to their role?",
+    "baselineCount": 4,
+    "baselines": [
+      "Knowledge covers: transaction verification procedures, address validation techniques, social engineering awareness, emergency procedures",
+      "Competence demonstrated before authorization (e.g., verifying a test transaction end-to-end)",
+      "Knowledge refreshed annually; updated within 30 days of significant procedure changes",
+      "Covers custody-platform-specific workflows and policy engine rules"
+    ],
+    "candidates": [
+      {
+        "page": "/treasury-operations/enhanced-controls",
+        "title": "Enhanced Controls for High-Risk Accounts | SEAL",
+        "score": 133,
+        "matchedSections": [
+          "access security",
+          "device security",
+          "custody/mpc policy thresholds for treasury operations",
+          "see also",
+          "mpc for large holdings",
+          "custody policy engine rules",
+          "zero trust architecture alternative",
+          "security monitoring & logging"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 112,
+        "matchedSections": [
+          "communication & documentation",
+          "operational best practices",
+          "core concept: m-of-n scheme",
+          "thresholds & configuration",
+          "signer rotation",
+          "training & drills",
+          "setup best practices"
+        ]
+      },
+      {
+        "page": "/treasury-operations/transaction-verification",
+        "title": "Treasury Transaction Verification | SEAL",
+        "score": 104,
+        "matchedSections": [
+          "communication security",
+          "address verification",
+          "key principles summary",
+          "pre-transfer setup (48 hours before)",
+          "day of transfer",
+          "pre-transfer planning (72 hours before)",
+          "transaction parameter security"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 60,
+        "matchedSections": [
+          "planning & setup",
+          "ongoing management",
+          "for signers",
+          "treasury multisigs"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 60,
+        "matchedSections": [
+          "delegated proposer",
+          "verify basic functionality",
+          "pre-launch checklist",
+          "nested safes",
+          "next steps",
+          "allowance module (required for treasury multisigs)"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 56,
+        "matchedSections": [
+          "identity verification process",
+          "replacement coordination",
+          "for emergency response multisigs",
+          "emergency drill procedures"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/use-case-specific-requirements",
+        "title": "Multisig Use Case Requirements | SEAL",
+        "score": 53,
+        "matchedSections": [
+          "training & drills:",
+          "additional requirements:",
+          "operational constraints:",
+          "veto quorum",
+          "treasury multisigs",
+          "hot/cold wallet separation"
+        ]
+      },
+      {
+        "page": "/wallet-security/signing-and-verification/secure-multisig-signing-process",
+        "title": "Secure Multisig Signing Process | SEAL",
+        "score": 50,
+        "matchedSections": [
+          "process",
+          "phase 2: executing the on-chain transaction",
+          "operational best practices"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "tro-4.1.3",
+    "controlTitle": "Secure Communication Procedures",
+    "description": "Do you have secure communication procedures for treasury operations, including standard identity verification?",
+    "baselineCount": 6,
+    "baselines": [
+      "Dedicated primary and backup channels on different platforms",
+      "End-to-end encryption, MFA required, invitation-based membership",
+      "Identity verified as standard procedure during signing/approval operations (e.g., code phrases, video call, secondary authenticated channel)",
+      "Anti-social-engineering protocols: established verification procedures for address changes or unusual requests",
+      "Documented procedures for channel compromise including switching to backup channels and out-of-band verification",
+      "All treasury personnel trained on these procedures; compromise response tested annually"
+    ],
+    "candidates": [
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 205,
+        "matchedSections": [
+          "treasury multisigs",
+          "documentation & communication",
+          "ongoing management",
+          "hardware & security setup",
+          "operational readiness",
+          "emergency preparedness",
+          "emergency procedures",
+          "tool proficiency",
+          "role-specific documentation",
+          "regular updates"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 180,
+        "matchedSections": [
+          "rpc backup options",
+          "administrator responsibilities",
+          "block explorer backup options",
+          "evm networks",
+          "squads public client - open source squads v4 interface",
+          "enhanced verification",
+          "regular practice",
+          "emergency drills",
+          "support resources",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 152,
+        "matchedSections": [
+          "immediate steps",
+          "if telegram/signal/discord gets taken over",
+          "multi-channel notification",
+          "for emergency response multisigs",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/treasury-operations/enhanced-controls",
+        "title": "Enhanced Controls for High-Risk Accounts | SEAL",
+        "score": 146,
+        "matchedSections": [
+          "access security",
+          "device security",
+          "custody/mpc policy thresholds for treasury operations",
+          "see also"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/personal-security-opsec",
+        "title": "Multisig Personal Security (OpSec) | SEAL",
+        "score": 132,
+        "matchedSections": [
+          "basic requirements",
+          "start with basics",
+          "for extra security",
+          "what to bring",
+          "what not to bring",
+          "basic travel security"
+        ]
+      },
+      {
+        "page": "/wallet-security/seed-phrase-management",
+        "title": "Seed Phrase Management",
+        "score": 128,
+        "matchedSections": [
+          "seed phrase encryption",
+          "tamper evident bags:",
+          "advanced backup options",
+          "multisig social recovery",
+          "ongoing security hygiene",
+          "trusted contacts"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 115,
+        "matchedSections": [
+          "thresholds & configuration",
+          "communication & documentation"
+        ]
+      },
+      {
+        "page": "/treasury-operations/transaction-verification",
+        "title": "Treasury Transaction Verification | SEAL",
+        "score": 83,
+        "matchedSections": [
+          "pre-transfer setup (48 hours before)"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "tro-5.1.1",
+    "controlTitle": "Protocol Evaluation and Exposure Limits",
+    "description": "Do you evaluate external protocols and enforce exposure limits before deploying treasury funds?",
+    "baselineCount": 4,
+    "baselines": [
+      "Due diligence process for all protocols before deployment: smart contract audit status, team reputation, TVL history, insurance coverage",
+      "Exposure limits defined per protocol, per chain, and per deployment category (DeFi, staking, liquid staking, etc.)",
+      "Limits reviewed periodically and after significant market or protocol changes",
+      "Risk re-evaluation triggered by: security incidents, major governance proposals, significant TVL changes, new vulnerabilities disclosed"
+    ],
+    "candidates": [
+      {
+        "page": "/treasury-operations/enhanced-controls",
+        "title": "Enhanced Controls for High-Risk Accounts | SEAL",
+        "score": 123,
+        "matchedSections": [
+          "access security",
+          "device security",
+          "custody/mpc policy thresholds for treasury operations",
+          "see also",
+          "transaction verification",
+          "security monitoring & logging"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 85,
+        "matchedSections": [
+          "who this is for",
+          "primary goal",
+          "core concept: m-of-n scheme",
+          "thresholds & configuration",
+          "contract-level security"
+        ]
+      },
+      {
+        "page": "/wallet-security/account-abstraction",
+        "title": "Account Abstraction Wallets",
+        "score": 71,
+        "matchedSections": [
+          "primary goal",
+          "core concept: erc-4337",
+          "security considerations & best practices"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 69,
+        "matchedSections": [
+          "address whitelisting",
+          "allowance module (required for treasury multisigs)",
+          "other modules"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/use-case-specific-requirements",
+        "title": "Multisig Use Case Requirements | SEAL",
+        "score": 68,
+        "matchedSections": [
+          "operational constraints:",
+          "smart contract control multisigs",
+          "on-chain constraints:",
+          "treasury multisigs",
+          "hot/cold wallet separation",
+          "timelock configuration"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/planning-and-classification",
+        "title": "Multisig Planning & Classification | SEAL",
+        "score": 64,
+        "matchedSections": [
+          "assess constraints and recovery",
+          "define purpose and scope"
+        ]
+      },
+      {
+        "page": "/incident-management/playbooks/seal-911-war-room-guidelines",
+        "title": "SEAL 911 War Room Guidelines | SEAL",
+        "score": 57,
+        "matchedSections": [
+          "crisis handbook - smart contract hack | [google doc](https://docs.google.com/document/d/1daaiugfkmemmiiuvqhepl5adfghj9ya6d04rdaldqc0/edit#heading=h.c4h2beeflqpo)",
+          "issue description",
+          "affected addresses"
+        ]
+      },
+      {
+        "page": "/treasury-operations/transaction-verification",
+        "title": "Treasury Transaction Verification | SEAL",
+        "score": 56,
+        "matchedSections": [
+          "pre-transfer setup (48 hours before)"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "tro-5.1.2",
+    "controlTitle": "Position Lifecycle Management",
+    "description": "Do you have procedures for managing the lifecycle of your positions in external protocols?",
+    "baselineCount": 4,
+    "baselines": [
+      "Entry procedures: smart contract address verification against multiple independent sources, token approval management (minimal approvals, revocation after use)",
+      "Emergency withdrawal/exit procedures documented for all active positions",
+      "Alternative access methods documented in case primary UIs are unavailable (direct contract interaction, CLI tools, alternative frontends)",
+      "Unbonding/unstaking timelines understood and factored into liquidity planning"
+    ],
+    "candidates": [
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 82,
+        "matchedSections": [
+          "who this is for",
+          "primary goal",
+          "core concept: m-of-n scheme",
+          "thresholds & configuration",
+          "contract-level security"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 56,
+        "matchedSections": [
+          "smart contract control multisigs"
+        ]
+      },
+      {
+        "page": "/wallet-security/account-abstraction",
+        "title": "Account Abstraction Wallets",
+        "score": 56,
+        "matchedSections": [
+          "primary goal",
+          "core concept: erc-4337",
+          "security considerations & best practices"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 49,
+        "matchedSections": []
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 45,
+        "matchedSections": [
+          "address whitelisting"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/use-case-specific-requirements",
+        "title": "Multisig Use Case Requirements | SEAL",
+        "score": 40,
+        "matchedSections": [
+          "operational constraints:",
+          "smart contract control multisigs",
+          "on-chain constraints:"
+        ]
+      },
+      {
+        "page": "/treasury-operations/transaction-verification",
+        "title": "Treasury Transaction Verification | SEAL",
+        "score": 40,
+        "matchedSections": []
+      },
+      {
+        "page": "/wallet-security/encumbered-wallets",
+        "title": "TEE-based Encumbered Wallets",
+        "score": 39,
+        "matchedSections": [
+          "primary goal",
+          "key benefits & features",
+          "security considerations & best practices"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "tro-6.1.1",
+    "controlTitle": "Monitoring and Threat Awareness",
+    "description": "Do you monitor your treasury for anomalous activity, external threats, and operational risks?",
+    "baselineCount": 9,
+    "baselines": [
+      "Transaction monitoring: unusual amounts, unexpected destinations, failed transactions, policy violations",
+      "Account state monitoring: balance changes, configuration modifications, new device enrollments, authentication anomalies",
+      "External threat intelligence: protocol vulnerabilities, DeFi/staking risks, relevant security incidents in the ecosystem",
+      "Vendor/platform monitoring: custody platform status, infrastructure alerts, service availability",
+      "Compliance monitoring: transactions and wallet addresses screened for sanctions and compliance risk",
+      "Protocol and position monitoring: deployed protocol health, governance changes, TVL shifts, collateral ratios, reward accrual, liquidation risks",
+      "Alerting with defined severity levels and escalation paths",
+      "Critical alerts (large unexpected transactions, unauthorized access attempts) trigger immediate investigation",
+      "Monitoring system integrity protected — alerts triggered when monitoring configurations are changed, disabled, or degraded"
+    ],
+    "candidates": [
+      {
+        "page": "/treasury-operations/enhanced-controls",
+        "title": "Enhanced Controls for High-Risk Accounts | SEAL",
+        "score": 325,
+        "matchedSections": [
+          "security monitoring & logging",
+          "access security",
+          "device security",
+          "custody/mpc policy thresholds for treasury operations",
+          "see also",
+          "mpc for large holdings",
+          "custody policy engine rules",
+          "zero trust architecture alternative",
+          "transaction verification"
+        ]
+      },
+      {
+        "page": "/incident-management/playbooks/seal-911-war-room-guidelines",
+        "title": "SEAL 911 War Room Guidelines | SEAL",
+        "score": 324,
+        "matchedSections": [
+          "issue description",
+          "affected addresses",
+          "perform in parallel by role",
+          "post incident actions",
+          "suggested tools and platforms",
+          "events timeline"
+        ]
+      },
+      {
+        "page": "/wallet-security/tools-and-resources",
+        "title": "Wallet Security Tools & Resources | SEAL",
+        "score": 283,
+        "matchedSections": [
+          "network security",
+          "multisig monitoring",
+          "monitoring & alerting"
+        ]
+      },
+      {
+        "page": "/treasury-operations/transaction-verification",
+        "title": "Treasury Transaction Verification | SEAL",
+        "score": 265,
+        "matchedSections": [
+          "pre-transfer setup (48 hours before)",
+          "day of transfer",
+          "pre-transfer planning (72 hours before)",
+          "address verification",
+          "transaction parameter security",
+          "key principles summary"
+        ]
+      },
+      {
+        "page": "/monitoring/guidelines",
+        "title": "On-Chain Monitoring Guidelines",
+        "score": 250,
+        "matchedSections": [
+          "define monitoring objectives",
+          "implement monitoring tools",
+          "establish alerting mechanisms",
+          "incident response",
+          "regular reviews and updates"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 244,
+        "matchedSections": [
+          "allowance module (required for treasury multisigs)",
+          "other modules",
+          "immutable monitoring channels",
+          "active monitoring"
+        ]
+      },
+      {
+        "page": "/monitoring/overview",
+        "title": "Monitoring",
+        "score": 202,
+        "matchedSections": []
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 163,
+        "matchedSections": [
+          "core concept: m-of-n scheme",
+          "operational best practices",
+          "thresholds & configuration"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "tro-6.1.2",
+    "controlTitle": "Incident Response Plan",
+    "description": "Do you have an incident response plan for treasury security events, and do you test it?",
+    "baselineCount": 7,
+    "baselines": [
+      "Severity levels defined with escalation procedures specific to treasury operations",
+      "Containment procedures: fund protection actions (emergency freeze, transfer to secure cold storage, policy lockdown)",
+      "Covers key scenarios: custody platform compromise, unauthorized transaction, signer key compromise, vendor breach",
+      "Emergency contacts pre-documented: custody provider security team, SEAL 911, legal counsel",
+      "Communication plan for stakeholders",
+      "Drills conducted at least annually; after major procedure changes",
+      "Drill documentation includes: date, participants, response times, issues identified, improvements made"
+    ],
+    "candidates": [
+      {
+        "page": "/treasury-operations/enhanced-controls",
+        "title": "Enhanced Controls for High-Risk Accounts | SEAL",
+        "score": 260,
+        "matchedSections": [
+          "security monitoring & logging",
+          "access security",
+          "device security",
+          "custody/mpc policy thresholds for treasury operations",
+          "see also",
+          "mpc for large holdings",
+          "custody policy engine rules",
+          "zero trust architecture alternative",
+          "transaction verification"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 213,
+        "matchedSections": [
+          "core concept: m-of-n scheme",
+          "thresholds & configuration",
+          "communication & documentation",
+          "signer rotation",
+          "training & drills",
+          "setup best practices",
+          "operational best practices",
+          "contract-level security"
+        ]
+      },
+      {
+        "page": "/treasury-operations/transaction-verification",
+        "title": "Treasury Transaction Verification | SEAL",
+        "score": 154,
+        "matchedSections": [
+          "pre-transfer setup (48 hours before)",
+          "address verification",
+          "key principles summary",
+          "day of transfer",
+          "pre-transfer planning (72 hours before)",
+          "transaction parameter security"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 150,
+        "matchedSections": [
+          "security team contact",
+          "internal escalation",
+          "recovery process",
+          "identity verification process",
+          "replacement coordination",
+          "for emergency response multisigs",
+          "emergency drill procedures"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 117,
+        "matchedSections": [
+          "planning & setup",
+          "ongoing management",
+          "for signers",
+          "operational readiness",
+          "treasury multisigs",
+          "emergency response multisigs",
+          "regular updates"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 112,
+        "matchedSections": [
+          "evm networks (ethereum, base, etc.)",
+          "solana",
+          "self-hosted multisig ui",
+          "delegated proposer",
+          "address whitelisting",
+          "verify basic functionality",
+          "pre-launch checklist",
+          "nested safes",
+          "next steps",
+          "allowance module (required for treasury multisigs)"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 91,
+        "matchedSections": [
+          "administrator responsibilities",
+          "eternal safe - decentralized fork of safe\\{wallet\\}",
+          "enhanced verification",
+          "regular practice",
+          "support resources",
+          "emergency drills"
+        ]
+      },
+      {
+        "page": "/governance/compliance-regulatory-requirements",
+        "title": "Compliance & Regulatory Requirements | SEAL",
+        "score": 88,
+        "matchedSections": [
+          "2. develop a robust security policy framework",
+          "5. incident response planning",
+          "10. documentation and record-keeping"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "tro-7.1.1",
+    "controlTitle": "Vendor Security Management",
+    "description": "Do you evaluate and monitor the security of third-party services used in treasury operations?",
+    "baselineCount": 4,
+    "baselines": [
+      "Initial due diligence before adoption: security certifications (SOC 2, ISO 27001), audit history, insurance coverage, incident history",
+      "Ongoing monitoring: SOC report currency, security incident notifications, service availability tracking",
+      "Contractual security requirements verified periodically (at least annually)",
+      "Critical vendor changes (ownership, infrastructure, security posture) trigger re-evaluation"
+    ],
+    "candidates": [
+      {
+        "page": "/incident-management/playbooks/seal-911-war-room-guidelines",
+        "title": "SEAL 911 War Room Guidelines | SEAL",
+        "score": 110,
+        "matchedSections": [
+          "issue description",
+          "affected addresses",
+          "perform in parallel by role",
+          "events timeline",
+          "post incident actions",
+          "suggested tools and platforms"
+        ]
+      },
+      {
+        "page": "/treasury-operations/enhanced-controls",
+        "title": "Enhanced Controls for High-Risk Accounts | SEAL",
+        "score": 107,
+        "matchedSections": [
+          "access security",
+          "device security",
+          "custody/mpc policy thresholds for treasury operations",
+          "see also",
+          "security monitoring & logging"
+        ]
+      },
+      {
+        "page": "/governance/compliance-regulatory-requirements",
+        "title": "Compliance & Regulatory Requirements | SEAL",
+        "score": 87,
+        "matchedSections": [
+          "6. continuous monitoring and auditing",
+          "8. third-party risk management"
+        ]
+      },
+      {
+        "page": "/wallet-security/tools-and-resources",
+        "title": "Wallet Security Tools & Resources | SEAL",
+        "score": 79,
+        "matchedSections": [
+          "monitoring & alerting",
+          "multisig monitoring",
+          "network security"
+        ]
+      },
+      {
+        "page": "/treasury-operations/transaction-verification",
+        "title": "Treasury Transaction Verification | SEAL",
+        "score": 77,
+        "matchedSections": [
+          "pre-transfer setup (48 hours before)",
+          "day of transfer"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 69,
+        "matchedSections": [
+          "allowance module (required for treasury multisigs)",
+          "active monitoring",
+          "immutable monitoring channels"
+        ]
+      },
+      {
+        "page": "/wallet-security/secure-multisig-best-practices",
+        "title": "Secure Multisig Best Practices | SEAL",
+        "score": 69,
+        "matchedSections": [
+          "thresholds & configuration",
+          "operational best practices"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/personal-security-opsec",
+        "title": "Multisig Personal Security (OpSec) | SEAL",
+        "score": 61,
+        "matchedSections": [
+          "network monitoring tools"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "tro-7.1.2",
+    "controlTitle": "Backup Infrastructure and Alternate Access",
+    "description": "Do you have backup infrastructure and alternate access methods for treasury operations?",
+    "baselineCount": 4,
+    "baselines": [
+      "Alternate access methods for custody platforms documented and tested (e.g., API access, mobile app, secondary UI)",
+      "Backup RPC providers configured",
+      "Procedures for operating treasury if primary custody platform is unavailable",
+      "Backup infrastructure tested at least annually"
+    ],
+    "candidates": [
+      {
+        "page": "/multisig-for-protocols/backup-signing-and-infrastructure",
+        "title": "Backup Signing & Infrastructure | SEAL",
+        "score": 220,
+        "matchedSections": [
+          "rpc backup options",
+          "administrator responsibilities",
+          "block explorer backup options",
+          "evm networks",
+          "squads public client - open source squads v4 interface",
+          "enhanced verification",
+          "regular practice",
+          "emergency drills",
+          "support resources",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 219,
+        "matchedSections": [
+          "treasury multisigs",
+          "documentation & communication",
+          "ongoing management",
+          "hardware & security setup",
+          "operational readiness",
+          "emergency preparedness",
+          "emergency procedures",
+          "tool proficiency",
+          "role-specific documentation",
+          "regular updates"
+        ]
+      },
+      {
+        "page": "/treasury-operations/enhanced-controls",
+        "title": "Enhanced Controls for High-Risk Accounts | SEAL",
+        "score": 207,
+        "matchedSections": [
+          "access security",
+          "device security",
+          "custody/mpc policy thresholds for treasury operations",
+          "see also",
+          "mpc for large holdings",
+          "custody policy engine rules",
+          "zero trust architecture alternative",
+          "security monitoring & logging"
+        ]
+      },
+      {
+        "page": "/wallet-security/seed-phrase-management",
+        "title": "Seed Phrase Management",
+        "score": 147,
+        "matchedSections": [
+          "private key & seed phrase management",
+          "tamper evident bags:",
+          "seed phrase encryption",
+          "advanced backup options",
+          "multisig social recovery",
+          "ongoing security hygiene",
+          "trusted contacts"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/personal-security-opsec",
+        "title": "Multisig Personal Security (OpSec) | SEAL",
+        "score": 116,
+        "matchedSections": [
+          "basic requirements",
+          "for extra security",
+          "what to bring",
+          "what not to bring",
+          "basic travel security"
+        ]
+      },
+      {
+        "page": "/treasury-operations/transaction-verification",
+        "title": "Treasury Transaction Verification | SEAL",
+        "score": 112,
+        "matchedSections": [
+          "pre-transfer setup (48 hours before)",
+          "day of transfer",
+          "pre-transfer planning (72 hours before)",
+          "address verification",
+          "transaction parameter security",
+          "key principles summary"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/emergency-procedures",
+        "title": "Multisig Emergency Procedures | SEAL",
+        "score": 107,
+        "matchedSections": [
+          "immediate steps",
+          "if telegram/signal/discord gets taken over",
+          "multi-channel notification",
+          "for emergency response multisigs",
+          "related documents"
+        ]
+      },
+      {
+        "page": "/wallet-security/intermediates-and-medium-funds",
+        "title": "Wallets for Intermediates & Medium Funds | SEAL",
+        "score": 61,
+        "matchedSections": [
+          "backup device (for critical operations & multisigs)"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "tro-8.1.1",
+    "controlTitle": "Financial Recordkeeping and Reconciliation",
+    "description": "Do you maintain accurate treasury records and conduct periodic reconciliation?",
+    "baselineCount": 5,
+    "baselines": [
+      "All treasury transactions recorded with categorization, documentation, and authorization chain",
+      "Periodic reconciliation between custody platform records, on-chain balances, and accounting records",
+      "Reconciliation frequency scaled to account classification: daily for Active Operations, weekly for Warm Storage, monthly for Cold Vault",
+      "Discrepancies investigated and resolved promptly",
+      "Treasury reporting procedures documented with defined cadence and audience"
+    ],
+    "candidates": [
+      {
+        "page": "/treasury-operations/enhanced-controls",
+        "title": "Enhanced Controls for High-Risk Accounts | SEAL",
+        "score": 196,
+        "matchedSections": [
+          "access security",
+          "device security",
+          "custody/mpc policy thresholds for treasury operations",
+          "see also",
+          "mpc for large holdings",
+          "custody policy engine rules",
+          "zero trust architecture alternative",
+          "security monitoring & logging",
+          "transaction verification"
+        ]
+      },
+      {
+        "page": "/treasury-operations/transaction-verification",
+        "title": "Treasury Transaction Verification | SEAL",
+        "score": 77,
+        "matchedSections": [
+          "pre-transfer setup (48 hours before)",
+          "day of transfer",
+          "pre-transfer planning (72 hours before)",
+          "address verification",
+          "transaction parameter security",
+          "key principles summary"
+        ]
+      },
+      {
+        "page": "/treasury-operations/classification",
+        "title": "Treasury Security Classification | SEAL",
+        "score": 63,
+        "matchedSections": [
+          "step 1: impact assessment",
+          "step 4: document your decision",
+          "step 2: operational assessment"
+        ]
+      },
+      {
+        "page": "/treasury-operations/overview",
+        "title": "Treasury Operations Security | SEAL",
+        "score": 61,
+        "matchedSections": [
+          "what is treasury operations security?"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/use-case-specific-requirements",
+        "title": "Multisig Use Case Requirements | SEAL",
+        "score": 49,
+        "matchedSections": [
+          "treasury multisigs",
+          "hot/cold wallet separation",
+          "operational constraints:",
+          "on-chain constraints:",
+          "timelock configuration"
+        ]
+      },
+      {
+        "page": "/incident-management/playbooks/seal-911-war-room-guidelines",
+        "title": "SEAL 911 War Room Guidelines | SEAL",
+        "score": 44,
+        "matchedSections": [
+          "issue description",
+          "affected addresses",
+          "suggested tools and platforms"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 39,
+        "matchedSections": [
+          "treasury multisigs"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/setup-and-configuration",
+        "title": "Multisig Setup & Configuration | SEAL",
+        "score": 35,
+        "matchedSections": [
+          "allowance module (required for treasury multisigs)",
+          "zodiac delay modifier (time-locks)",
+          "active monitoring"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "tro-8.1.2",
+    "controlTitle": "Insurance Coverage",
+    "description": "Do you maintain insurance coverage appropriate for your treasury operations?",
+    "baselineCount": 4,
+    "baselines": [
+      "Coverage scope documented: what's covered (custody theft, hack, insider fraud) and what's excluded",
+      "Coverage amounts appropriate relative to assets held",
+      "Custody provider's insurance evaluated as part of vendor due diligence",
+      "Insurance coverage reviewed at least annually or when treasury size changes significantly"
+    ],
+    "candidates": [
+      {
+        "page": "/treasury-operations/enhanced-controls",
+        "title": "Enhanced Controls for High-Risk Accounts | SEAL",
+        "score": 186,
+        "matchedSections": [
+          "access security",
+          "device security",
+          "custody/mpc policy thresholds for treasury operations",
+          "see also",
+          "mpc for large holdings",
+          "custody policy engine rules",
+          "zero trust architecture alternative",
+          "security monitoring & logging"
+        ]
+      },
+      {
+        "page": "/treasury-operations/transaction-verification",
+        "title": "Treasury Transaction Verification | SEAL",
+        "score": 107,
+        "matchedSections": [
+          "pre-transfer setup (48 hours before)",
+          "day of transfer",
+          "pre-transfer planning (72 hours before)",
+          "address verification",
+          "transaction parameter security",
+          "key principles summary"
+        ]
+      },
+      {
+        "page": "/treasury-operations/classification",
+        "title": "Treasury Security Classification | SEAL",
+        "score": 43,
+        "matchedSections": [
+          "step 1: impact assessment",
+          "step 4: document your decision"
+        ]
+      },
+      {
+        "page": "/treasury-operations/overview",
+        "title": "Treasury Operations Security | SEAL",
+        "score": 41,
+        "matchedSections": [
+          "what is treasury operations security?"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/use-case-specific-requirements",
+        "title": "Multisig Use Case Requirements | SEAL",
+        "score": 29,
+        "matchedSections": [
+          "treasury multisigs",
+          "hot/cold wallet separation"
+        ]
+      },
+      {
+        "page": "/incident-management/playbooks/seal-911-war-room-guidelines",
+        "title": "SEAL 911 War Room Guidelines | SEAL",
+        "score": 24,
+        "matchedSections": [
+          "issue description",
+          "affected addresses"
+        ]
+      },
+      {
+        "page": "/multisig-for-protocols/implementation-checklist",
+        "title": "Multisig Implementation Checklist | SEAL",
+        "score": 23,
+        "matchedSections": [
+          "treasury multisigs"
+        ]
+      },
+      {
+        "page": "/wallet-security/custodial-vs-non-custodial",
+        "title": "Custodial Vs Non-Custodial Wallets | SEAL",
+        "score": 20,
+        "matchedSections": [
+          "what are they?",
+          "use cases"
+        ]
+      }
+    ]
+  }
+]
\ No newline at end of file
diff --git a/scripts/data/mappings/sfc-workspace-security.json b/scripts/data/mappings/sfc-workspace-security.json
new file mode 100644
index 00000000..53067634
--- /dev/null
+++ b/scripts/data/mappings/sfc-workspace-security.json
@@ -0,0 +1,1955 @@
+[
+  {
+    "controlId": "ws-1.1.1",
+    "controlTitle": "Workspace Security Owner",
+    "description": "Is there a clearly designated person or team accountable for workspace security?",
+    "baselineCount": 1,
+    "baselines": [
+      "Accountability scope covers policy maintenance, device and account standards, access control oversight, periodic reviews, and incident escalation"
+    ],
+    "candidates": [
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 39,
+        "matchedSections": [
+          "practical application",
+          "2. minimal access scopes"
+        ]
+      },
+      {
+        "page": "/opsec/principles/principles",
+        "title": "OpSec Core Principles",
+        "score": 37,
+        "matchedSections": [
+          "2. principle of least privilege",
+          "implementation"
+        ]
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 35,
+        "matchedSections": []
+      },
+      {
+        "page": "/guides/account_management/discord",
+        "title": "Discord Security",
+        "score": 34,
+        "matchedSections": [
+          "summary"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/physical-environmental",
+        "title": "Physical & Environmental Security",
+        "score": 33,
+        "matchedSections": [
+          "secure workspace components",
+          "implementation steps for workspace security"
+        ]
+      },
+      {
+        "page": "/opsec/google/overview",
+        "title": "Google Workspace Security",
+        "score": 31,
+        "matchedSections": []
+      },
+      {
+        "page": "/guides/account_management/telegram",
+        "title": "Telegram Security",
+        "score": 30,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/appendices/case-studies",
+        "title": "OpSec Case Studies",
+        "score": 29,
+        "matchedSections": [
+          "case study 1: private key compromise"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ws-1.1.2",
+    "controlTitle": "Workspace Security Policy",
+    "description": "Do you maintain a workspace security policy that is accessible and understood by all personnel?",
+    "baselineCount": 3,
+    "baselines": [
+      "Policy covers core expectations including device security, account hygiene, credential management, acceptable use, and incident reporting",
+      "Written in plain language so all personnel can follow it",
+      "Policy reviewed at least annually and after significant changes (security incidents, technology shifts, organizational restructuring)"
+    ],
+    "candidates": [
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 64,
+        "matchedSections": [
+          "**screen privacy and social engineering**",
+          "**secure your accounts and passwords**",
+          "conclusion"
+        ]
+      },
+      {
+        "page": "/awareness/understanding-threat-vectors",
+        "title": "Understanding Threat Vectors",
+        "score": 44,
+        "matchedSections": [
+          "2.1.1. social engineering & phishing",
+          "2.1.2. malware & technical attacks",
+          "2.3.2. technical indicators"
+        ]
+      },
+      {
+        "page": "/awareness/cultivating-a-security-aware-mindset",
+        "title": "Cultivating A Security Aware Mindset | SEAL",
+        "score": 43,
+        "matchedSections": [
+          "practical tips",
+          "3.4.1. password management"
+        ]
+      },
+      {
+        "page": "/opsec/appendices/case-studies",
+        "title": "OpSec Case Studies",
+        "score": 43,
+        "matchedSections": [
+          "exercise 3: team member device compromise"
+        ]
+      },
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 43,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/continuous-improvement-metrics",
+        "title": "Security Improvement Metrics | SEAL",
+        "score": 40,
+        "matchedSections": []
+      },
+      {
+        "page": "/guides/account_management/telegram",
+        "title": "Telegram Security",
+        "score": 38,
+        "matchedSections": []
+      },
+      {
+        "page": "/guides/account_management/discord",
+        "title": "Discord Security",
+        "score": 36,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "ws-1.1.3",
+    "controlTitle": "Asset Inventory",
+    "description": "Do you maintain an inventory of organizational devices and accounts with defined ownership?",
+    "baselineCount": 4,
+    "baselines": [
+      "Scoped to devices and accounts with access to sensitive systems or data",
+      "Device inventory tracks make/model, owner, OS version, encryption status, and EDR/MDM enrollment",
+      "Account inventory covers organizational accounts (eg. email, cloud, social media) with defined ownership",
+      "Updated as devices/accounts are provisioned or decommissioned"
+    ],
+    "candidates": [
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 152,
+        "matchedSections": [
+          "**secure devices with encryption & updates**",
+          "**plan emergency and incident responses**",
+          "**network safety – avoid untrusted wi-fi & bluetooth**",
+          "**plan for customs and border checks**",
+          "**enhanced device protections**",
+          "**protect crypto keys with multi-party controls**",
+          "conclusion",
+          "**back up and prepare for loss**",
+          "**lock down phones**",
+          "**post-trip device rebuilding**"
+        ]
+      },
+      {
+        "page": "/encryption/volume-encryption",
+        "title": "Volume Encryption",
+        "score": 114,
+        "matchedSections": [
+          "what is volume encryption?",
+          "importance of volume encryption",
+          "uses of volume encryption",
+          "examples of volume encryption",
+          "known technologies for volume encryption",
+          "best practices for volume encryption"
+        ]
+      },
+      {
+        "page": "/encryption/partition-encryption",
+        "title": "Partition Encryption",
+        "score": 106,
+        "matchedSections": [
+          "what is partition encryption?",
+          "importance of partition encryption",
+          "uses of partition encryption",
+          "examples of partition encryption",
+          "best practices for partition encryption"
+        ]
+      },
+      {
+        "page": "/encryption/overview",
+        "title": "Encryption",
+        "score": 96,
+        "matchedSections": [
+          "contents"
+        ]
+      },
+      {
+        "page": "/encryption/cloud-data-encryption",
+        "title": "Cloud Data Encryption",
+        "score": 94,
+        "matchedSections": [
+          "best practices"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/technical",
+        "title": "Technical Security Controls",
+        "score": 78,
+        "matchedSections": [
+          "implementation steps",
+          "encrypted storage & backups",
+          "key components"
+        ]
+      },
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 76,
+        "matchedSections": [
+          "relationship to implementation process",
+          "practical application"
+        ]
+      },
+      {
+        "page": "/guides/account_management/telegram",
+        "title": "Telegram Security",
+        "score": 75,
+        "matchedSections": [
+          "summary",
+          "account security checklist",
+          "device-level security",
+          "advanced privacy measures",
+          "best practices for safe use"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ws-1.1.4",
+    "controlTitle": "System and Data Classification",
+    "description": "Do you classify systems and data by sensitivity to determine appropriate security controls?",
+    "baselineCount": 3,
+    "baselines": [
+      "Classification levels defined (e.g., critical, high, standard)",
+      "Classification determines which controls apply (access restrictions, monitoring, encryption, backup requirements)",
+      "Classification reviewed when systems, data sensitivity, or organizational structure change"
+    ],
+    "candidates": [
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 150,
+        "matchedSections": [
+          "**secure devices with encryption & updates**",
+          "**plan emergency and incident responses**",
+          "**network safety – avoid untrusted wi-fi & bluetooth**",
+          "**plan for customs and border checks**",
+          "**enhanced device protections**",
+          "**protect crypto keys with multi-party controls**",
+          "conclusion",
+          "before traveling",
+          "**back up and prepare for loss**",
+          "**protect accounts with 2fa redundancy**",
+          "**secure your wallets and keys**",
+          "**inspect and clean your devices**",
+          "**post-trip device rebuilding**",
+          "**post-travel review**"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/technical",
+        "title": "Technical Security Controls",
+        "score": 144,
+        "matchedSections": [
+          "implementation steps",
+          "encrypted storage & backups",
+          "key components",
+          "web3-specific considerations"
+        ]
+      },
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 139,
+        "matchedSections": [
+          "relationship to implementation process",
+          "practical application",
+          "5. continuous visibility"
+        ]
+      },
+      {
+        "page": "/encryption/cloud-data-encryption",
+        "title": "Cloud Data Encryption",
+        "score": 127,
+        "matchedSections": [
+          "best practices"
+        ]
+      },
+      {
+        "page": "/encryption/volume-encryption",
+        "title": "Volume Encryption",
+        "score": 121,
+        "matchedSections": [
+          "what is volume encryption?",
+          "importance of volume encryption",
+          "uses of volume encryption",
+          "examples of volume encryption",
+          "known technologies for volume encryption",
+          "best practices for volume encryption"
+        ]
+      },
+      {
+        "page": "/encryption/partition-encryption",
+        "title": "Partition Encryption",
+        "score": 112,
+        "matchedSections": [
+          "what is partition encryption?",
+          "importance of partition encryption",
+          "uses of partition encryption",
+          "examples of partition encryption",
+          "best practices for partition encryption"
+        ]
+      },
+      {
+        "page": "/encryption/overview",
+        "title": "Encryption",
+        "score": 93,
+        "matchedSections": [
+          "contents"
+        ]
+      },
+      {
+        "page": "/opsec/principles/principles",
+        "title": "OpSec Core Principles",
+        "score": 79,
+        "matchedSections": [
+          "5. continuous monitoring and improvement",
+          "implementation"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ws-2.1.1",
+    "controlTitle": "Device Security Standards",
+    "description": "Do you define and enforce security standards for organizational devices?",
+    "baselineCount": 7,
+    "baselines": [
+      "Full disk encryption enabled on all devices",
+      "Automatic OS and application patching enabled or enforced",
+      "Strong authentication required (password/biometric, auto-lock timeouts, lock screens)",
+      "Administrative privileges separated from daily-use accounts",
+      "Devices procured through verified supply chains and verified for integrity upon receipt",
+      "Device compliance verified upon provisioning and monitored on an ongoing basis",
+      "BYOD policy defining what personal devices can access and the security controls required (e.g., MDM enrollment, separate work profiles)"
+    ],
+    "candidates": [
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 222,
+        "matchedSections": [
+          "**secure devices with encryption & updates**",
+          "**protect accounts with 2fa redundancy**",
+          "**lock down phones**",
+          "**screen privacy and social engineering**",
+          "**secure your accounts and passwords**",
+          "**post-travel review**",
+          "**plan for customs and border checks**",
+          "conclusion",
+          "**plan emergency and incident responses**",
+          "**network safety – avoid untrusted wi-fi & bluetooth**",
+          "**enhanced device protections**",
+          "**protect crypto keys with multi-party controls**",
+          "**back up and prepare for loss**",
+          "**post-trip device rebuilding**"
+        ]
+      },
+      {
+        "page": "/encryption/volume-encryption",
+        "title": "Volume Encryption",
+        "score": 125,
+        "matchedSections": [
+          "what is volume encryption?",
+          "importance of volume encryption",
+          "uses of volume encryption",
+          "examples of volume encryption",
+          "known technologies for volume encryption",
+          "best practices for volume encryption"
+        ]
+      },
+      {
+        "page": "/encryption/partition-encryption",
+        "title": "Partition Encryption",
+        "score": 113,
+        "matchedSections": [
+          "what is partition encryption?",
+          "importance of partition encryption",
+          "uses of partition encryption",
+          "examples of partition encryption",
+          "best practices for partition encryption"
+        ]
+      },
+      {
+        "page": "/guides/account_management/telegram",
+        "title": "Telegram Security",
+        "score": 109,
+        "matchedSections": [
+          "device-level security",
+          "account security checklist",
+          "summary",
+          "advanced privacy measures",
+          "best practices for safe use"
+        ]
+      },
+      {
+        "page": "/encryption/cloud-data-encryption",
+        "title": "Cloud Data Encryption",
+        "score": 96,
+        "matchedSections": [
+          "best practices"
+        ]
+      },
+      {
+        "page": "/opsec/google/overview",
+        "title": "Google Workspace Security",
+        "score": 95,
+        "matchedSections": [
+          "account security checklist",
+          "extended security settings",
+          "admin settings (workspace configuration)"
+        ]
+      },
+      {
+        "page": "/encryption/overview",
+        "title": "Encryption",
+        "score": 94,
+        "matchedSections": [
+          "contents"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/technical",
+        "title": "Technical Security Controls",
+        "score": 92,
+        "matchedSections": [
+          "key components",
+          "implementation steps",
+          "encrypted storage & backups"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ws-2.1.2",
+    "controlTitle": "Device Lifecycle Management",
+    "description": "Do you have procedures for device loss, theft, and secure decommissioning?",
+    "baselineCount": 3,
+    "baselines": [
+      "Remote lock and wipe capability for all organizational devices",
+      "Documented procedures for responding to lost or stolen devices (notification, remote wipe, credential rotation, incident escalation)",
+      "Secure decommissioning procedures including data sanitization and verified destruction for storage media"
+    ],
+    "candidates": [
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 88,
+        "matchedSections": [
+          "**screen privacy and social engineering**",
+          "**secure your accounts and passwords**",
+          "conclusion",
+          "**back up and prepare for loss**"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/technical",
+        "title": "Technical Security Controls",
+        "score": 42,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/control-domains/physical-environmental",
+        "title": "Physical & Environmental Security",
+        "score": 36,
+        "matchedSections": []
+      },
+      {
+        "page": "/awareness/understanding-threat-vectors",
+        "title": "Understanding Threat Vectors",
+        "score": 32,
+        "matchedSections": [
+          "2.1.1. social engineering & phishing",
+          "2.1.2. malware & technical attacks",
+          "2.3.2. technical indicators"
+        ]
+      },
+      {
+        "page": "/opsec/travel/tldr",
+        "title": "Travel Security Quick Reference",
+        "score": 27,
+        "matchedSections": []
+      },
+      {
+        "page": "/awareness/cultivating-a-security-aware-mindset",
+        "title": "Cultivating A Security Aware Mindset | SEAL",
+        "score": 25,
+        "matchedSections": [
+          "practical tips",
+          "3.4.1. password management"
+        ]
+      },
+      {
+        "page": "/guides/account_management/discord",
+        "title": "Discord Security",
+        "score": 25,
+        "matchedSections": []
+      },
+      {
+        "page": "/guides/account_management/telegram",
+        "title": "Telegram Security",
+        "score": 24,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "ws-2.1.3",
+    "controlTitle": "Endpoint Protection",
+    "description": "Do you deploy and monitor endpoint protection on organizational devices?",
+    "baselineCount": 4,
+    "baselines": [
+      "EDR or MDM deployed on all organizational devices with documented coverage",
+      "Alert triage and response procedures defined with severity-based escalation",
+      "Compliance enforcement actions documented (e.g., quarantine non-compliant devices, block access)",
+      "Monitoring coverage includes detection of malware, unauthorized software, and policy violations"
+    ],
+    "candidates": [
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 138,
+        "matchedSections": [
+          "relationship to implementation process",
+          "practical application",
+          "5. continuous visibility"
+        ]
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 77,
+        "matchedSections": [
+          "**secure devices with encryption & updates**",
+          "**physical safety and common sense**",
+          "**protect crypto keys with multi-party controls**",
+          "**plan emergency and incident responses**",
+          "**post-travel review**",
+          "**enhanced device protections**",
+          "**back up and prepare for loss**",
+          "**lock down phones**",
+          "**post-trip device rebuilding**"
+        ]
+      },
+      {
+        "page": "/guides/account_management/discord",
+        "title": "Discord Security",
+        "score": 74,
+        "matchedSections": [
+          "summary",
+          "server settings checklist",
+          "logging setup",
+          "security bots"
+        ]
+      },
+      {
+        "page": "/opsec/principles/principles",
+        "title": "OpSec Core Principles",
+        "score": 73,
+        "matchedSections": [
+          "5. continuous monitoring and improvement",
+          "implementation"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/technical",
+        "title": "Technical Security Controls",
+        "score": 71,
+        "matchedSections": [
+          "key components",
+          "implementation steps",
+          "web3-specific considerations"
+        ]
+      },
+      {
+        "page": "/opsec/appendices/case-studies",
+        "title": "OpSec Case Studies",
+        "score": 62,
+        "matchedSections": [
+          "case study 1: private key compromise",
+          "exercise 3: team member device compromise",
+          "red team exercise: phishing simulation"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/physical-environmental",
+        "title": "Physical & Environmental Security",
+        "score": 56,
+        "matchedSections": [
+          "secure workspace components",
+          "implementation steps for workspace security",
+          "implementation steps"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/organizational",
+        "title": "Organizational Security Controls",
+        "score": 50,
+        "matchedSections": [
+          "key components",
+          "implementation steps"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ws-2.1.4",
+    "controlTitle": "Physical and Travel Security",
+    "description": "Do you maintain physical security requirements for workspaces and travel?",
+    "baselineCount": 6,
+    "baselines": [
+      "Physical workspace requirements defined for both on-site and remote work environments",
+      "Screen privacy and shoulder-surfing awareness enforced",
+      "Travel security procedures documented covering device handling, network usage, and border crossings",
+      "High-risk travel procedures defined (loaner devices, enhanced controls, check-in schedules)",
+      "USB and charging security addressed (data blockers, no public USB ports)",
+      "Devices physically secured when not in active use (cable locks, safes, carry-on luggage for travel)"
+    ],
+    "candidates": [
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 150,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/control-domains/physical-environmental",
+        "title": "Physical & Environmental Security",
+        "score": 84,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 82,
+        "matchedSections": [
+          "relationship to implementation process",
+          "practical application"
+        ]
+      },
+      {
+        "page": "/opsec/travel/tldr",
+        "title": "Travel Security Quick Reference",
+        "score": 67,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/control-domains/technical",
+        "title": "Technical Security Controls",
+        "score": 57,
+        "matchedSections": []
+      },
+      {
+        "page": "/dprk-it-workers/mitigating-dprk-it-workers",
+        "title": "Mitigating DPRK IT Worker Threats | SEAL",
+        "score": 56,
+        "matchedSections": [
+          "hardening your organization"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/overview",
+        "title": "OpSec Control Domains",
+        "score": 55,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/core-concepts/web3-considerations",
+        "title": "Web3 Security Considerations",
+        "score": 54,
+        "matchedSections": [
+          "suggested steps"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ws-3.1.1",
+    "controlTitle": "Account Lifecycle Management",
+    "description": "Do you have procedures for provisioning, modifying, and revoking user accounts?",
+    "baselineCount": 5,
+    "baselines": [
+      "Account creation requires documented approval from the account owner's manager or designated authority",
+      "Accounts provisioned with minimum necessary permissions (least privilege)",
+      "Modification of account permissions requires documented approval",
+      "Account revocation procedures tied to offboarding and role changes",
+      "Service accounts and shared credentials inventoried with defined ownership"
+    ],
+    "candidates": [
+      {
+        "page": "/guides/account_management/discord",
+        "title": "Discord Security",
+        "score": 72,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 68,
+        "matchedSections": [
+          "**screen privacy and social engineering**",
+          "**secure your accounts and passwords**",
+          "conclusion"
+        ]
+      },
+      {
+        "page": "/dprk-it-workers/techniques-tactics-and-procedures",
+        "title": "DPRK IT Worker TTPs",
+        "score": 52,
+        "matchedSections": []
+      },
+      {
+        "page": "/awareness/understanding-threat-vectors",
+        "title": "Understanding Threat Vectors",
+        "score": 48,
+        "matchedSections": [
+          "2.1.1. social engineering & phishing",
+          "2.1.2. malware & technical attacks",
+          "2.3.2. technical indicators"
+        ]
+      },
+      {
+        "page": "/guides/account_management/twitter",
+        "title": "Twitter/X Security",
+        "score": 48,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 48,
+        "matchedSections": [
+          "relationship to implementation process",
+          "practical application"
+        ]
+      },
+      {
+        "page": "/guides/account_management/telegram",
+        "title": "Telegram Security",
+        "score": 47,
+        "matchedSections": []
+      },
+      {
+        "page": "/guides/account_management/github",
+        "title": "GitHub Security",
+        "score": 43,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "ws-3.1.2",
+    "controlTitle": "Multi-Factor Authentication",
+    "description": "Do you enforce multi-factor authentication across organizational accounts?",
+    "baselineCount": 5,
+    "baselines": [
+      "MFA required for all organizational accounts by default",
+      "Hardware security keys required for high-privilege and critical accounts (admin, infrastructure, custody)",
+      "Phishing-resistant MFA preferred (FIDO2/WebAuthn, hardware keys) over SMS or TOTP where available",
+      "Exceptions documented with justification, compensating controls, and expiry date",
+      "Backup MFA methods configured for account recovery"
+    ],
+    "candidates": [
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 142,
+        "matchedSections": [
+          "**secure devices with encryption & updates**",
+          "**screen privacy and social engineering**",
+          "before traveling",
+          "**back up and prepare for loss**",
+          "**protect accounts with 2fa redundancy**",
+          "**secure your wallets and keys**",
+          "**plan emergency and incident responses**",
+          "**inspect and clean your devices**",
+          "**protect crypto keys with multi-party controls**",
+          "**post-trip device rebuilding**",
+          "conclusion"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/technical",
+        "title": "Technical Security Controls",
+        "score": 108,
+        "matchedSections": [
+          "key components",
+          "implementation steps",
+          "encrypted storage & backups",
+          "web3-specific considerations"
+        ]
+      },
+      {
+        "page": "/guides/account_management/discord",
+        "title": "Discord Security",
+        "score": 83,
+        "matchedSections": [
+          "summary",
+          "account security checklist",
+          "server settings checklist",
+          "additional recommendations",
+          "cold admin accounts",
+          "backup systems"
+        ]
+      },
+      {
+        "page": "/guides/account_management/telegram",
+        "title": "Telegram Security",
+        "score": 71,
+        "matchedSections": [
+          "educate community members on security practices",
+          "account security checklist",
+          "device-level security"
+        ]
+      },
+      {
+        "page": "/opsec/core-concepts/web3-considerations",
+        "title": "Web3 Security Considerations",
+        "score": 58,
+        "matchedSections": [
+          "self-custody responsibility",
+          "suggested steps"
+        ]
+      },
+      {
+        "page": "/guides/account_management/twitter",
+        "title": "Twitter/X Security",
+        "score": 56,
+        "matchedSections": [
+          "summary",
+          "best practices & additional tips",
+          "for team members",
+          "account security checklist"
+        ]
+      },
+      {
+        "page": "/opsec/appendices/case-studies",
+        "title": "OpSec Case Studies",
+        "score": 55,
+        "matchedSections": [
+          "case study 2: social engineering attack",
+          "red team exercise: phishing simulation"
+        ]
+      },
+      {
+        "page": "/opsec/google/overview",
+        "title": "Google Workspace Security",
+        "score": 55,
+        "matchedSections": [
+          "account security checklist",
+          "extended security settings"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ws-3.1.3",
+    "controlTitle": "Organizational Account Security",
+    "description": "Do you maintain security standards for all organizational accounts, including enterprise platforms and external services?",
+    "baselineCount": 5,
+    "baselines": [
+      "Security configuration standards defined and applied for enterprise platforms (Google Workspace, Microsoft 365, collaboration tools)",
+      "Social media and public-facing accounts secured with strong authentication and defined ownership",
+      "Ownership verified and documented for all organizational accounts",
+      "Recovery methods restricted to organizational channels (no personal recovery emails or phone numbers on organizational accounts)",
+      "Account configurations reviewed periodically for drift or unauthorized changes"
+    ],
+    "candidates": [
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 106,
+        "matchedSections": []
+      },
+      {
+        "page": "/guides/account_management/discord",
+        "title": "Discord Security",
+        "score": 80,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 75,
+        "matchedSections": [
+          "relationship to implementation process",
+          "practical application"
+        ]
+      },
+      {
+        "page": "/guides/account_management/telegram",
+        "title": "Telegram Security",
+        "score": 69,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/google/overview",
+        "title": "Google Workspace Security",
+        "score": 67,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/control-domains/organizational",
+        "title": "Organizational Security Controls",
+        "score": 59,
+        "matchedSections": [
+          "key components",
+          "implementation steps"
+        ]
+      },
+      {
+        "page": "/dprk-it-workers/techniques-tactics-and-procedures",
+        "title": "DPRK IT Worker TTPs",
+        "score": 58,
+        "matchedSections": []
+      },
+      {
+        "page": "/guides/account_management/twitter",
+        "title": "Twitter/X Security",
+        "score": 56,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "ws-3.1.4",
+    "controlTitle": "Credential Management Standards",
+    "description": "Do you enforce credential management standards, including secure storage and individual accountability?",
+    "baselineCount": 7,
+    "baselines": [
+      "Password manager required for all personnel; no passwords stored in plain text, documents, or browsers",
+      "Unique, strong passwords for every account (minimum length/complexity standards defined)",
+      "Individual accounts required for all personnel — no sharing of personal login credentials",
+      "When credentials must be provisioned or shared (e.g., service accounts, API keys, onboarding), transmission only through encrypted channels (password manager sharing features, not email or chat)",
+      "Credential rotation schedule defined based on risk; rotation triggered immediately after suspected compromise",
+      "Enhanced controls for high-privilege credentials (admin accounts, service accounts, API keys) including stricter rotation, separate storage, and logged access",
+      "Service account and API key inventory maintained with defined ownership"
+    ],
+    "candidates": [
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 346,
+        "matchedSections": [
+          "**screen privacy and social engineering**",
+          "**secure your accounts and passwords**",
+          "conclusion",
+          "**secure devices with encryption & updates**",
+          "**protect accounts with 2fa redundancy**",
+          "**lock down phones**",
+          "**post-travel review**",
+          "**plan for customs and border checks**",
+          "**secure your wallets and keys**",
+          "**plan emergency and incident responses**",
+          "**network safety – avoid untrusted wi-fi & bluetooth**"
+        ]
+      },
+      {
+        "page": "/awareness/cultivating-a-security-aware-mindset",
+        "title": "Cultivating A Security Aware Mindset | SEAL",
+        "score": 200,
+        "matchedSections": [
+          "practical tips",
+          "3.4.1. password management",
+          "3.4.2. multi-factor authentication (mfa)"
+        ]
+      },
+      {
+        "page": "/guides/account_management/telegram",
+        "title": "Telegram Security",
+        "score": 164,
+        "matchedSections": [
+          "account security checklist",
+          "device-level security",
+          "advanced privacy measures",
+          "best practices for safe use",
+          "notes"
+        ]
+      },
+      {
+        "page": "/awareness/understanding-threat-vectors",
+        "title": "Understanding Threat Vectors",
+        "score": 159,
+        "matchedSections": [
+          "2.1.1. social engineering & phishing",
+          "2.1.2. malware & technical attacks",
+          "2.3.2. technical indicators"
+        ]
+      },
+      {
+        "page": "/opsec/google/overview",
+        "title": "Google Workspace Security",
+        "score": 151,
+        "matchedSections": [
+          "account security checklist",
+          "extended security settings",
+          "admin settings (workspace configuration)"
+        ]
+      },
+      {
+        "page": "/community-management/overview",
+        "title": "Community Management",
+        "score": 149,
+        "matchedSections": [
+          "phishing awareness",
+          "strong passwords and two-factor authentication (2fa)"
+        ]
+      },
+      {
+        "page": "/guides/account_management/twitter",
+        "title": "Twitter/X Security",
+        "score": 120,
+        "matchedSections": [
+          "account security checklist",
+          "best practices & additional tips"
+        ]
+      },
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 116,
+        "matchedSections": [
+          "relationship to implementation process",
+          "practical application"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ws-3.1.5",
+    "controlTitle": "Access Reviews",
+    "description": "Do you conduct periodic access reviews and promptly adjust permissions when roles change?",
+    "baselineCount": 5,
+    "baselines": [
+      "Scheduled access reviews at least quarterly for critical systems, annually for others",
+      "Access adjusted within defined timelines when employees change roles",
+      "Reviews verify each user still requires their current level of access",
+      "Unnecessary permissions revoked promptly with documented evidence",
+      "Insider threat consideration included — for each role, assess what damage could be done with current access"
+    ],
+    "candidates": [
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 97,
+        "matchedSections": [
+          "relationship to implementation process",
+          "practical application"
+        ]
+      },
+      {
+        "page": "/guides/account_management/discord",
+        "title": "Discord Security",
+        "score": 83,
+        "matchedSections": [
+          "server settings checklist"
+        ]
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 73,
+        "matchedSections": []
+      },
+      {
+        "page": "/dprk-it-workers/mitigating-dprk-it-workers",
+        "title": "Mitigating DPRK IT Worker Threats | SEAL",
+        "score": 71,
+        "matchedSections": [
+          "hardening your organization",
+          "i hired a dprk it worker. what now?"
+        ]
+      },
+      {
+        "page": "/dprk-it-workers/techniques-tactics-and-procedures",
+        "title": "DPRK IT Worker TTPs",
+        "score": 63,
+        "matchedSections": [
+          "did i hire a dprk it worker?"
+        ]
+      },
+      {
+        "page": "/opsec/principles/principles",
+        "title": "OpSec Core Principles",
+        "score": 57,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/control-domains/people",
+        "title": "Personnel Security Controls",
+        "score": 56,
+        "matchedSections": [
+          "key components",
+          "web3-specific considerations"
+        ]
+      },
+      {
+        "page": "/opsec/core-concepts/implementation-process",
+        "title": "OpSec Implementation Process | SEAL",
+        "score": 56,
+        "matchedSections": [
+          "relationship to security fundamentals",
+          "implementation actions"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ws-4.1.1",
+    "controlTitle": "Software Evaluation and Approval",
+    "description": "Do you evaluate and approve software, extensions, and tools before organizational use?",
+    "baselineCount": 5,
+    "baselines": [
+      "Evaluation criteria for all software before adoption (browsers, extensions, IDEs, libraries, AI assistants, SaaS tools)",
+      "Data privacy and leakage risks assessed (does the tool send data to third parties for training or analytics?)",
+      "Approved software list maintained; unapproved software restricted",
+      "Browser extension approval process defined",
+      "Dependency management includes version pinning, vulnerability scanning, and update policies"
+    ],
+    "candidates": [
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 65,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 60,
+        "matchedSections": [
+          "relationship to implementation process",
+          "practical application"
+        ]
+      },
+      {
+        "page": "/opsec/core-concepts/implementation-process",
+        "title": "OpSec Implementation Process | SEAL",
+        "score": 47,
+        "matchedSections": [
+          "relationship to security fundamentals",
+          "implementation actions"
+        ]
+      },
+      {
+        "page": "/opsec/appendices/glossary",
+        "title": "Security Glossary",
+        "score": 44,
+        "matchedSections": []
+      },
+      {
+        "page": "/guides/account_management/telegram",
+        "title": "Telegram Security",
+        "score": 39,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/continuous-improvement-metrics",
+        "title": "Security Improvement Metrics | SEAL",
+        "score": 36,
+        "matchedSections": [
+          "implementation steps",
+          "maturity models",
+          "web3-specific maturity considerations",
+          "key components"
+        ]
+      },
+      {
+        "page": "/awareness/resources-and-further-reading",
+        "title": "Security Resources & Further Reading | SEAL",
+        "score": 33,
+        "matchedSections": [
+          "5.5. web3-specific security resources"
+        ]
+      },
+      {
+        "page": "/encryption/cloud-data-encryption",
+        "title": "Cloud Data Encryption",
+        "score": 33,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "ws-4.1.2",
+    "controlTitle": "Source Code and Repository Security",
+    "description": "Do you secure source code repositories against unauthorized access and credential exposure?",
+    "baselineCount": 5,
+    "baselines": [
+      "Role-based access control with least-privilege permissions",
+      "Branch protection rules enforced on critical branches (require reviews, signed commits)",
+      "Automated secret scanning enabled to detect credentials, API keys, and private keys in code",
+      "Pre-commit hooks or CI checks to prevent secrets from being committed",
+      "Repository security audited periodically (access permissions, configuration, open PRs)"
+    ],
+    "candidates": [
+      {
+        "page": "/guides/account_management/github",
+        "title": "GitHub Security",
+        "score": 132,
+        "matchedSections": [
+          "repository settings",
+          "summary",
+          "for team members"
+        ]
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 113,
+        "matchedSections": [
+          "**screen privacy and social engineering**",
+          "**secure your accounts and passwords**",
+          "conclusion"
+        ]
+      },
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 92,
+        "matchedSections": [
+          "practical application",
+          "2. minimal access scopes"
+        ]
+      },
+      {
+        "page": "/guides/account_management/discord",
+        "title": "Discord Security",
+        "score": 77,
+        "matchedSections": [
+          "summary"
+        ]
+      },
+      {
+        "page": "/opsec/principles/principles",
+        "title": "OpSec Core Principles",
+        "score": 77,
+        "matchedSections": [
+          "2. principle of least privilege",
+          "implementation"
+        ]
+      },
+      {
+        "page": "/guides/account_management/telegram",
+        "title": "Telegram Security",
+        "score": 75,
+        "matchedSections": []
+      },
+      {
+        "page": "/awareness/understanding-threat-vectors",
+        "title": "Understanding Threat Vectors",
+        "score": 69,
+        "matchedSections": [
+          "2.1.1. social engineering & phishing",
+          "2.1.2. malware & technical attacks",
+          "2.3.2. technical indicators"
+        ]
+      },
+      {
+        "page": "/opsec/appendices/case-studies",
+        "title": "OpSec Case Studies",
+        "score": 66,
+        "matchedSections": [
+          "case study 1: private key compromise",
+          "exercise 3: team member device compromise"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ws-5.1.1",
+    "controlTitle": "Network Security",
+    "description": "Do you enforce secure network access for organizational systems?",
+    "baselineCount": 4,
+    "baselines": [
+      "VPN or zero-trust network access required for accessing internal resources remotely",
+      "Wi-Fi security standards defined (no auto-connect, avoid public Wi-Fi for sensitive operations)",
+      "Network segmentation applied where applicable (separate guest networks, development environments)",
+      "Cellular or personal hotspot preferred over public Wi-Fi for sensitive work"
+    ],
+    "candidates": [
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 114,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 98,
+        "matchedSections": [
+          "1. layered protection",
+          "relationship to implementation process",
+          "practical application"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/technical",
+        "title": "Technical Security Controls",
+        "score": 63,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/principles/principles",
+        "title": "OpSec Core Principles",
+        "score": 59,
+        "matchedSections": [
+          "1. defense in depth"
+        ]
+      },
+      {
+        "page": "/opsec/appendices/glossary",
+        "title": "Security Glossary",
+        "score": 58,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/core-concepts/web3-considerations",
+        "title": "Web3 Security Considerations",
+        "score": 54,
+        "matchedSections": [
+          "suggested steps"
+        ]
+      },
+      {
+        "page": "/opsec/travel/tldr",
+        "title": "Travel Security Quick Reference",
+        "score": 48,
+        "matchedSections": []
+      },
+      {
+        "page": "/guides/account_management/telegram",
+        "title": "Telegram Security",
+        "score": 43,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "ws-5.1.2",
+    "controlTitle": "Secure Communications",
+    "description": "Do you secure organizational communications and verify identity for sensitive interactions?",
+    "baselineCount": 5,
+    "baselines": [
+      "End-to-end encrypted channels used for sensitive communications",
+      "Identity verification procedures established for sensitive requests (e.g., access changes, financial approvals, credential sharing)",
+      "Anti-impersonation protocols documented (e.g., secondary channel verification, code words, video confirmation)",
+      "Email security configured (SPF, DKIM, DMARC) to prevent spoofing",
+      "Procedures for channel compromise including switching to backup channels"
+    ],
+    "candidates": [
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 171,
+        "matchedSections": [
+          "**screen privacy and social engineering**",
+          "**secure your accounts and passwords**",
+          "conclusion",
+          "**secure your wallets and keys**",
+          "**plan emergency and incident responses**",
+          "**network safety – avoid untrusted wi-fi & bluetooth**",
+          "**plan for customs and border checks**",
+          "before traveling",
+          "**back up and prepare for loss**",
+          "**protect accounts with 2fa redundancy**",
+          "**inspect and clean your devices**",
+          "**protect crypto keys with multi-party controls**",
+          "**post-trip device rebuilding**"
+        ]
+      },
+      {
+        "page": "/guides/account_management/telegram",
+        "title": "Telegram Security",
+        "score": 118,
+        "matchedSections": [
+          "account security checklist",
+          "device-level security",
+          "advanced privacy measures",
+          "best practices for safe use",
+          "notes"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/technical",
+        "title": "Technical Security Controls",
+        "score": 117,
+        "matchedSections": [
+          "key components",
+          "encrypted storage & backups",
+          "implementation steps",
+          "web3-specific considerations"
+        ]
+      },
+      {
+        "page": "/guides/account_management/discord",
+        "title": "Discord Security",
+        "score": 101,
+        "matchedSections": [
+          "additional recommendations",
+          "account security checklist",
+          "cold admin accounts",
+          "backup systems"
+        ]
+      },
+      {
+        "page": "/opsec/core-concepts/web3-considerations",
+        "title": "Web3 Security Considerations",
+        "score": 94,
+        "matchedSections": [
+          "suggested steps"
+        ]
+      },
+      {
+        "page": "/awareness/understanding-threat-vectors",
+        "title": "Understanding Threat Vectors",
+        "score": 88,
+        "matchedSections": [
+          "2.1.1. social engineering & phishing",
+          "2.1.2. malware & technical attacks",
+          "2.3.2. technical indicators"
+        ]
+      },
+      {
+        "page": "/opsec/google/overview",
+        "title": "Google Workspace Security",
+        "score": 80,
+        "matchedSections": [
+          "account security checklist",
+          "extended security settings",
+          "admin settings (workspace configuration)"
+        ]
+      },
+      {
+        "page": "/awareness/cultivating-a-security-aware-mindset",
+        "title": "Cultivating A Security Aware Mindset | SEAL",
+        "score": 65,
+        "matchedSections": [
+          "practical tips",
+          "3.4.1. password management"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ws-6.1.1",
+    "controlTitle": "Security Onboarding",
+    "description": "Do you verify employee identity and provide security onboarding before granting system access?",
+    "baselineCount": 5,
+    "baselines": [
+      "Identity and authorization verified before any access is provisioned",
+      "Background checks or identity verification appropriate to role sensitivity",
+      "Security onboarding includes device provisioning, account creation, MFA setup, and initial security training",
+      "New personnel acknowledge security policies before access is granted",
+      "Onboarding checklist documented and consistently applied"
+    ],
+    "candidates": [
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 79,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/control-domains/people",
+        "title": "Personnel Security Controls",
+        "score": 74,
+        "matchedSections": [
+          "security training & culture",
+          "implementation steps"
+        ]
+      },
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 74,
+        "matchedSections": []
+      },
+      {
+        "page": "/guides/account_management/discord",
+        "title": "Discord Security",
+        "score": 71,
+        "matchedSections": []
+      },
+      {
+        "page": "/dprk-it-workers/techniques-tactics-and-procedures",
+        "title": "DPRK IT Worker TTPs",
+        "score": 67,
+        "matchedSections": []
+      },
+      {
+        "page": "/guides/account_management/telegram",
+        "title": "Telegram Security",
+        "score": 64,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/appendices/glossary",
+        "title": "Security Glossary",
+        "score": 62,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/google/overview",
+        "title": "Google Workspace Security",
+        "score": 55,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "ws-6.1.2",
+    "controlTitle": "Security Offboarding",
+    "description": "Do you have comprehensive offboarding procedures for departing personnel?",
+    "baselineCount": 5,
+    "baselines": [
+      "All account access revoked within 24 hours of departure",
+      "Devices returned and verified for data sanitization",
+      "Credentials and secrets rotated for any shared systems the departing person accessed",
+      "Offboarding checklist documented covering: account deprovisioning, device return, credential rotation, access to organizational repositories and tools, recovery of company property",
+      "Involuntary departures trigger immediate access revocation before notification where feasible"
+    ],
+    "candidates": [
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 99,
+        "matchedSections": [
+          "**screen privacy and social engineering**",
+          "**secure your accounts and passwords**",
+          "conclusion"
+        ]
+      },
+      {
+        "page": "/awareness/understanding-threat-vectors",
+        "title": "Understanding Threat Vectors",
+        "score": 69,
+        "matchedSections": [
+          "2.1.1. social engineering & phishing",
+          "2.1.2. malware & technical attacks",
+          "2.3.2. technical indicators"
+        ]
+      },
+      {
+        "page": "/guides/account_management/discord",
+        "title": "Discord Security",
+        "score": 47,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/appendices/case-studies",
+        "title": "OpSec Case Studies",
+        "score": 47,
+        "matchedSections": [
+          "exercise 3: team member device compromise"
+        ]
+      },
+      {
+        "page": "/dprk-it-workers/techniques-tactics-and-procedures",
+        "title": "DPRK IT Worker TTPs",
+        "score": 46,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/control-domains/technical",
+        "title": "Technical Security Controls",
+        "score": 44,
+        "matchedSections": []
+      },
+      {
+        "page": "/dprk-it-workers/mitigating-dprk-it-workers",
+        "title": "Mitigating DPRK IT Worker Threats | SEAL",
+        "score": 43,
+        "matchedSections": [
+          "overview of risks to your organization"
+        ]
+      },
+      {
+        "page": "/opsec/appendices/glossary",
+        "title": "Security Glossary",
+        "score": 43,
+        "matchedSections": []
+      }
+    ]
+  },
+  {
+    "controlId": "ws-6.1.3",
+    "controlTitle": "Security Awareness and Training",
+    "description": "Do you maintain a security awareness program with regular training and testing?",
+    "baselineCount": 5,
+    "baselines": [
+      "Training covers workspace security topics: phishing, social engineering, device security, credential hygiene, and incident reporting",
+      "Phishing simulations conducted at least quarterly",
+      "Follow-up training required for personnel who fail simulations",
+      "Training content updated annually and after significant threats or procedure changes",
+      "Covers crypto-specific risks: fake job offers, malicious browser extensions, clipboard hijacking, social engineering via DMs"
+    ],
+    "candidates": [
+      {
+        "page": "/awareness/staying-informed-and-continuous-learning",
+        "title": "Staying Informed And Continuous Learning | SEAL",
+        "score": 148,
+        "matchedSections": [
+          "4.1.1. training approaches",
+          "4.2. essential training topics",
+          "4.1.2. training delivery"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/people",
+        "title": "Personnel Security Controls",
+        "score": 139,
+        "matchedSections": [
+          "key components",
+          "implementation steps",
+          "web3-specific considerations"
+        ]
+      },
+      {
+        "page": "/opsec/appendices/case-studies",
+        "title": "OpSec Case Studies",
+        "score": 113,
+        "matchedSections": [
+          "case study 2: social engineering attack",
+          "red team exercise: phishing simulation",
+          "exercise 3: team member device compromise"
+        ]
+      },
+      {
+        "page": "/guides/account_management/discord",
+        "title": "Discord Security",
+        "score": 106,
+        "matchedSections": [
+          "server settings checklist",
+          "summary",
+          "account security checklist",
+          "additional recommendations"
+        ]
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 102,
+        "matchedSections": [
+          "**screen privacy and social engineering**",
+          "**secure devices with encryption & updates**",
+          "**secure your accounts and passwords**",
+          "conclusion"
+        ]
+      },
+      {
+        "page": "/awareness/understanding-threat-vectors",
+        "title": "Understanding Threat Vectors",
+        "score": 100,
+        "matchedSections": [
+          "2.1.1. social engineering & phishing",
+          "2.1.2. malware & technical attacks",
+          "2.3.2. technical indicators"
+        ]
+      },
+      {
+        "page": "/awareness/resources-and-further-reading",
+        "title": "Security Resources & Further Reading | SEAL",
+        "score": 94,
+        "matchedSections": [
+          "5.1. additional learning materials",
+          "5.4. security training resources"
+        ]
+      },
+      {
+        "page": "/community-management/overview",
+        "title": "Community Management",
+        "score": 73,
+        "matchedSections": [
+          "phishing awareness"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ws-7.1.1",
+    "controlTitle": "Workspace Security Monitoring and Incident Response",
+    "description": "Do you detect and respond to workspace security incidents?",
+    "baselineCount": 5,
+    "baselines": [
+      "Monitoring in place for common workspace threats: account takeovers, unauthorized access, credential leaks, device compromise, data exfiltration",
+      "Response procedures documented for key scenarios: compromised account, compromised device, data leak, insider threat event",
+      "Escalation paths defined with severity levels",
+      "Credential leak monitoring (dark web, breach databases, paste sites, code repositories)",
+      "Incidents documented with timeline, root cause, actions taken, and lessons learned"
+    ],
+    "candidates": [
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 154,
+        "matchedSections": [
+          "relationship to implementation process",
+          "practical application",
+          "5. continuous visibility"
+        ]
+      },
+      {
+        "page": "/opsec/appendices/case-studies",
+        "title": "OpSec Case Studies",
+        "score": 120,
+        "matchedSections": [
+          "case study 1: private key compromise",
+          "exercise 3: team member device compromise",
+          "red team exercise: phishing simulation"
+        ]
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 116,
+        "matchedSections": [
+          "**screen privacy and social engineering**",
+          "**secure your accounts and passwords**",
+          "conclusion",
+          "**post-travel review**"
+        ]
+      },
+      {
+        "page": "/opsec/principles/principles",
+        "title": "OpSec Core Principles",
+        "score": 103,
+        "matchedSections": [
+          "implementation",
+          "5. continuous monitoring and improvement"
+        ]
+      },
+      {
+        "page": "/guides/account_management/discord",
+        "title": "Discord Security",
+        "score": 82,
+        "matchedSections": [
+          "server settings checklist",
+          "logging setup",
+          "security bots"
+        ]
+      },
+      {
+        "page": "/awareness/understanding-threat-vectors",
+        "title": "Understanding Threat Vectors",
+        "score": 78,
+        "matchedSections": [
+          "2.1.1. social engineering & phishing",
+          "2.1.2. malware & technical attacks",
+          "2.3.2. technical indicators"
+        ]
+      },
+      {
+        "page": "/dprk-it-workers/techniques-tactics-and-procedures",
+        "title": "DPRK IT Worker TTPs",
+        "score": 72,
+        "matchedSections": [
+          "did i hire a dprk it worker?"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/people",
+        "title": "Personnel Security Controls",
+        "score": 70,
+        "matchedSections": [
+          "key components",
+          "implementation steps",
+          "web3-specific considerations"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ws-7.1.2",
+    "controlTitle": "Insider Threat Assessment",
+    "description": "Do you assess insider threat risks and enforce least-privilege access for each role?",
+    "baselineCount": 4,
+    "baselines": [
+      "Damage scenarios documented for each role (what could this person do if compromised or malicious?)",
+      "Least-privilege access enforced across all systems",
+      "Separation of duties applied for critical operations (e.g., no single person can deploy to production, execute large transactions, and manage access controls)",
+      "Assessed during periodic access reviews"
+    ],
+    "candidates": [
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 83,
+        "matchedSections": [
+          "practical application"
+        ]
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 78,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/control-domains/people",
+        "title": "Personnel Security Controls",
+        "score": 63,
+        "matchedSections": [
+          "key components",
+          "implementation steps",
+          "web3-specific considerations"
+        ]
+      },
+      {
+        "page": "/opsec/principles/principles",
+        "title": "OpSec Core Principles",
+        "score": 57,
+        "matchedSections": [
+          "implementation"
+        ]
+      },
+      {
+        "page": "/opsec/control-domains/technical",
+        "title": "Technical Security Controls",
+        "score": 55,
+        "matchedSections": [
+          "key components",
+          "implementation steps"
+        ]
+      },
+      {
+        "page": "/dprk-it-workers/overview",
+        "title": "Insider Threats (DPRK)",
+        "score": 53,
+        "matchedSections": [
+          "table of contents"
+        ]
+      },
+      {
+        "page": "/opsec/appendices/case-studies",
+        "title": "OpSec Case Studies",
+        "score": 53,
+        "matchedSections": [
+          "case study 1: private key compromise"
+        ]
+      },
+      {
+        "page": "/guides/account_management/discord",
+        "title": "Discord Security",
+        "score": 52,
+        "matchedSections": [
+          "summary",
+          "server settings checklist"
+        ]
+      }
+    ]
+  },
+  {
+    "controlId": "ws-7.1.3",
+    "controlTitle": "Third-Party Access Management",
+    "description": "Do you manage third-party access with time-limited, purpose-specific permissions?",
+    "baselineCount": 5,
+    "baselines": [
+      "Third-party access requires documented approval with defined scope and expiry date",
+      "Access limited to minimum necessary systems and data",
+      "Access revoked automatically upon contract expiry or project completion",
+      "Audit trails maintained for all third-party access",
+      "Third-party vendor security evaluated before granting access (security certifications, incident history)"
+    ],
+    "candidates": [
+      {
+        "page": "/opsec/core-concepts/security-fundamentals",
+        "title": "Security Fundamentals",
+        "score": 84,
+        "matchedSections": [
+          "relationship to implementation process",
+          "practical application"
+        ]
+      },
+      {
+        "page": "/opsec/appendices/glossary",
+        "title": "Security Glossary",
+        "score": 73,
+        "matchedSections": []
+      },
+      {
+        "page": "/guides/account_management/discord",
+        "title": "Discord Security",
+        "score": 71,
+        "matchedSections": []
+      },
+      {
+        "page": "/guides/account_management/telegram",
+        "title": "Telegram Security",
+        "score": 71,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/travel/guide",
+        "title": "Travel Security Guide",
+        "score": 65,
+        "matchedSections": []
+      },
+      {
+        "page": "/dprk-it-workers/mitigating-dprk-it-workers",
+        "title": "Mitigating DPRK IT Worker Threats | SEAL",
+        "score": 64,
+        "matchedSections": [
+          "hardening your organization"
+        ]
+      },
+      {
+        "page": "/opsec/google/overview",
+        "title": "Google Workspace Security",
+        "score": 64,
+        "matchedSections": []
+      },
+      {
+        "page": "/opsec/principles/principles",
+        "title": "OpSec Core Principles",
+        "score": 64,
+        "matchedSections": []
+      }
+    ]
+  }
+]
\ No newline at end of file
diff --git a/scripts/data/qa-briefs/sfc-devops-infrastructure.md b/scripts/data/qa-briefs/sfc-devops-infrastructure.md
new file mode 100644
index 00000000..5e57c02a
--- /dev/null
+++ b/scripts/data/qa-briefs/sfc-devops-infrastructure.md
@@ -0,0 +1,455 @@
+# QA Brief: sfc-devops-infrastructure
+
+## YOUR TASK
+
+Verify the evaluation claims below. For each control with refs:
+1. Read the ACTUAL page content (provided below)
+2. Read the control's FULL baselines
+3. Check: does the page ACTUALLY meet the baselines claimed in "baselinesMet"?
+4. Check: are the "baselinesMissed" correct (is there content that was overlooked)?
+5. Check: is the coverage rating ("full"/"partial") justified?
+
+Be STRICT. If the evaluator was too generous, downgrade. If they missed coverage, upgrade.
+
+## EVALUATION CLAIMS TO VERIFY (10 controls with refs)
+
+### di-1.1.4: Development Tools Approval
+**Full baselines:**
+  1. Evaluation criteria cover IDEs, extensions, plugins, AI-powered tools, and third-party services
+  2. Extensions and plugins obtained only from official repositories
+  3. AI tools assessed for data privacy risks (does the tool send code to third parties for training or analytics?)
+  4. Approved tool list maintained; unapproved tools restricted
+  5. Regular reviews of installed tools to identify unused or unrecognized items
+
+**Evaluator's assessment:**
+- **/devsecops/integrated-development-environments**  — **partial**
+  Met: Extensions and plugins obtained only from official repositories (mentions 'trusted sources')
+  Missed: Evaluation criteria cover IDEs, extensions, plugins, AI-powered tools, and third-party services; AI tools assessed for data privacy risks; Approved tool list maintained; unapproved tools restricted; Regular reviews of installed tools
+**Gaps:** Evaluation criteria cover IDEs, extensions, plugins, AI-powered tools, and third-party services; AI tools assessed for data privacy risks; Approved tool list maintained; unapproved tools restricted; Regular reviews of installed tools to identify unused or unrecognized items
+
+### di-2.1.1: Repository Security
+**Full baselines:**
+  1. Role-based access control with least-privilege permissions
+  2. Branch protection rules enforced on main/production branches
+  3. Signed commits required for all code changes
+  4. Multi-party code review required for merges to protected branches
+  5. MFA required for all repository members
+  6. Repository access reviewed periodically
+
+**Evaluator's assessment:**
+- **/secure-software-development/secure-code-repositories-version-control** → Best Practices for Secure Code Repositories — **full**
+  Met: Role-based access control with least-privilege permissions; Branch protection rules enforced on main/production branches; Signed commits required for all code changes; Multi-party code review required for merges; MFA required for all repository members
+  Missed: Repository access reviewed periodically (audit logs mentioned but not periodic access reviews)
+**Gaps:** Repository access reviewed periodically
+
+### di-2.1.2: Secret Scanning
+**Full baselines:**
+  1. Automated scanning for committed secrets (API keys, private keys, credentials) in all repositories
+  2. Pre-commit hooks deployed to prevent secrets from being committed in the first place
+  3. Remediation procedures for discovered secrets (immediate rotation, revocation)
+  4. Scanning integrated into CI/CD pipeline
+
+**Evaluator's assessment:**
+- **/devsecops/continuous-integration-continuous-deployment**  — **partial**
+  Met: CI/CD pipeline checks for leaked credentials (partial: automated scanning); Scanning integrated into CI/CD pipeline
+  Missed: Pre-commit hooks deployed to prevent secrets from being committed; Remediation procedures for discovered secrets (immediate rotation, revocation)
+**Gaps:** Pre-commit hooks deployed to prevent secrets from being committed in the first place; Remediation procedures for discovered secrets (immediate rotation, revocation)
+
+### di-2.1.4: Dependency and Supply Chain Security
+**Full baselines:**
+  1. Packages obtained from official repositories and trusted sources only
+  2. Package names verified against typosquatting patterns before installation
+  3. Dependencies scanned for known vulnerabilities before deployment
+  4. Dependency version pinning enforced to prevent automatic updates to compromised versions
+  5. Regular dependency audits for outdated or vulnerable components
+  6. Changelog reviewed for dependency updates to verify expected functionality
+
+**Evaluator's assessment:**
+- **/supply-chain/dependency-awareness** → Best Practices for Dependency Awareness — **partial**
+  Met: Packages obtained from official repositories and trusted sources only; Dependencies scanned for known vulnerabilities before deployment; Regular dependency audits for outdated or vulnerable components
+  Missed: Package names verified against typosquatting patterns before installation; Dependency version pinning enforced to prevent automatic updates; Changelog reviewed for dependency updates to verify expected functionality
+**Gaps:** Package names verified against typosquatting patterns before installation; Dependency version pinning enforced to prevent automatic updates to compromised versions; Changelog reviewed for dependency updates to verify expected functionality
+
+### di-3.1.1: Pipeline Security Controls
+**Full baselines:**
+  1. Pipeline configuration changes require multi-party approval
+  2. Separate service accounts with minimal permissions used for pipeline execution
+  3. Manual deployment by humans restricted; deployments automated through controlled pipelines
+  4. Pipeline and build configurations version-controlled and reviewed
+  5. Builds are deterministic with strict dependency sets
+
+**Evaluator's assessment:**
+- **/devsecops/continuous-integration-continuous-deployment**  — **partial**
+  Met: Builds are deterministic with strict dependency sets; Strict access controls for CI/CD pipelines (partial: limits who can modify)
+  Missed: Pipeline configuration changes require multi-party approval; Separate service accounts with minimal permissions used for pipeline execution; Manual deployment by humans restricted; deployments automated through controlled pipelines; Pipeline and build configurations version-controlled and reviewed
+**Gaps:** Pipeline configuration changes require multi-party approval; Separate service accounts with minimal permissions used for pipeline execution; Manual deployment by humans restricted; deployments automated through controlled pipelines; Pipeline and build configurations version-controlled and reviewed
+
+### di-3.1.3: Security Testing Integration
+**Full baselines:**
+  1. Static analysis (SAST) tools integrated into CI/CD pipeline
+  2. Dependency vulnerability scanning automated in CI/CD
+  3. Security scan results reviewed before deployment approval
+  4. Testing and validation performed in staging environments before production deployment
+
+**Evaluator's assessment:**
+- **/devsecops/continuous-integration-continuous-deployment**  — **partial**
+  Met: Static analysis and dependency scanning integrated into CI/CD; PR testing must pass before merging (implies review)
+  Missed: Security scan results reviewed before deployment approval (not explicitly stated); Testing and validation performed in staging environments before production deployment
+- **/devsecops/security-testing**  — **partial**
+  Met: SAST tools integrated into CI/CD pipeline
+  Missed: Dependency vulnerability scanning automated in CI/CD (DAST mentioned, not dependency scanning); Security scan results reviewed before deployment approval; Testing and validation performed in staging environments before production
+**Gaps:** Security scan results reviewed before deployment approval; Testing and validation performed in staging environments before production deployment
+
+### di-4.1.1: Infrastructure as Code
+**Full baselines:**
+  1. All infrastructure defined and managed through code (e.g., Terraform, CloudFormation)
+  2. Infrastructure changes deployed through automated pipelines, no manual steps required
+  3. Infrastructure changes require multi-party approval
+  4. IaC security scanning performed before deployment
+
+**Evaluator's assessment:**
+- **/security-automation/infrastructure-as-code**  — **partial**
+  Met: All infrastructure defined and managed through code; IaC security scanning performed before deployment
+  Missed: Infrastructure changes deployed through automated pipelines, no manual steps required; Infrastructure changes require multi-party approval
+**Gaps:** Infrastructure changes deployed through automated pipelines, no manual steps required; Infrastructure changes require multi-party approval
+
+### di-4.1.2: Infrastructure Access Controls
+**Full baselines:**
+  1. Individual accounts with MFA required; no shared accounts
+  2. Privileged access is time-limited and requires multi-party approval (JIT access)
+  3. Day-to-day operations use minimum necessary permissions (read-only where possible)
+  4. Break-glass accounts established for emergency access with individual accountability
+  5. Break-glass usage triggers immediate alerts to the entire team and requires post-incident review
+  6. All access activities logged and monitored
+
+**Evaluator's assessment:**
+- **/secure-software-development/secure-code-repositories-version-control** → Best Practices for Secure Code Repositories — **partial**
+  Met: Individual accounts with MFA required (for repositories); Role-based access control (minimum necessary permissions); All access activities logged and monitored (audit logs)
+  Missed: Privileged access is time-limited and requires multi-party approval (JIT access); Break-glass accounts established for emergency access; Break-glass usage triggers immediate alerts and requires post-incident review
+**Gaps:** Privileged access is time-limited and requires multi-party approval (JIT access); Break-glass accounts established for emergency access with individual accountability; Break-glass usage triggers immediate alerts to entire team and requires post-incident review
+
+### di-4.1.3: Backup and Disaster Recovery
+**Full baselines:**
+  1. Critical systems have automated backup procedures
+  2. Disaster recovery plan documented with recovery time and recovery point objectives defined
+  3. Backup and recovery procedures tested regularly
+  4. Backups stored independently of primary infrastructure
+
+**Evaluator's assessment:**
+- **/secure-software-development/secure-code-repositories-version-control** → Secure Version Control Practices — **partial**
+  Met: Regular backups of code repository; Backups stored independently (secure, offsite location)
+  Missed: Critical systems have automated backup procedures; Disaster recovery plan documented with RTO and RPO defined; Backup and recovery procedures tested regularly
+**Gaps:** Critical systems have automated backup procedures (beyond just code repos); Disaster recovery plan documented with recovery time and recovery point objectives defined; Backup and recovery procedures tested regularly
+
+### di-4.1.4: Cloud Security Monitoring
+**Full baselines:**
+  1. Cloud security configurations continuously monitored for drift and unauthorized changes
+  2. Administrative actions trigger alerts
+  3. Cloud provider security notifications subscribed to and promptly reviewed
+  4. Comprehensive logging enabled (e.g., CloudTrail, Azure Monitor, Google Cloud Logging)
+  5. Multi-cloud strategies considered to reduce single-provider dependency
+
+**Evaluator's assessment:**
+- **/infrastructure/cloud** → Cloud Infrastructure — **partial**
+  Met: Cloud security configurations monitored (comprehensive logging, monitoring, threat detection); Administrative actions trigger alerts (real-time incident response); Comprehensive logging enabled (AWS CloudTrail, Azure Monitor, Google Cloud Logging)
+  Missed: Cloud provider security notifications subscribed to and promptly reviewed; Multi-cloud strategies considered to reduce single-provider dependency
+**Gaps:** Cloud provider security notifications subscribed to and promptly reviewed; Multi-cloud strategies considered to reduce single-provider dependency
+
+## FALSE-NEGATIVE CHECK (5 controls marked "no coverage")
+
+Verify these truly have no relevant framework page. If any page below partially covers them, note it.
+
+### di-1.1.1: DevOps Security Owner
+**Baselines:** Accountability scope covers policy maintenance, security reviews, access control oversight, pipeline governance, and incident escalation
+
+### di-1.1.2: DevOps Security Policy
+**Baselines:** Policy covers environment standards, access controls, deployment procedures, code management, and supply chain security; Accessible to all developers and infrastructure operators; Reviewed at least annually and after significant changes (security incidents, technology shifts, organizational restructuring)
+
+### di-1.1.3: Development Environment Isolation
+**Baselines:** Development activities performed in containerized or virtualized environments; Each code repository has its own isolated environment to prevent cross-contamination; Production credentials not accessible from development environments (+2 more)
+
+### di-2.1.3: External Contributor Review
+**Baselines:** Additional approvers required for all external code contributions; Code contributions tracked; unexpected changes flagged (e.g., commit rewrites, unprompted edits); External collaborators restricted to minimum necessary repository permissions (+1 more)
+
+### di-3.1.2: Secrets Management
+**Baselines:** Dedicated secrets management system used (not environment variables in plain text); Secrets never stored in source code or unencrypted configuration files; Production secrets not directly accessible by humans (+2 more)
+
+---
+
+## FRAMEWORK PAGES (7 pages)
+
+### PAGE: /devsecops/continuous-integration-continuous-deployment
+
+# Continuous Integration and Continuous Deployment (CI/CD)
+
+
+
+
+Continuous Integration and Continuous Deployment are there to ensure good code quality and create rapid and secure
+deployments. Some best practices are:
+
+1. Ensure every PR undergoes CI testing (e.g., GitHub Actions) that must pass before merging. CI tests should at least
+  include unit tests, integration tests, and checks for known vulnerabilities in dependencies.
+2. The CI/CD pipeline should check for misconfigurations and leaked credentials.
+3. Produce deterministic builds with a strict set of dependencies and/or a build container that can reliably produce the
+  same results on different machines.
+4. Integrate security scanning tools to detect vulnerabilities in code and dependencies during the CI process.
+5. Use isolated environments for building and testing to prevent contamination between different stages of the pipeline.
+6. Implement strict access controls for CI/CD pipelines to limit who can modify the pipeline configurations.
+
+---
+
+---
+
+### PAGE: /devsecops/integrated-development-environments
+
+# Integrated Development Environments (IDEs)
+
+
+
+
+Integrated Development Environments (IDEs) are essential tools for developers, but they also need to be secured.
+Consider implementing the following best practices:
+
+1. Ensure IDEs are configured securely, with plugins and extensions only installed from trusted sources. Some IDEs have
+  features that allow for automated execution of files in folders. Use restricted mode if you don't fully trust a project.
+2. Keep IDEs and their plugins/extensions up-to-date to protect against vulnerabilities.
+3. Integrate static code analysis tools within the IDE to catch security issues early in the development process.
+4. Configure IDEs to follow the principle of least privilege, limiting access to sensitive information and systems.
+5. Ensure that potential development environments are isolated from production environments.
+
+---
+
+---
+
+### PAGE: /devsecops/security-testing
+
+# Security Testing
+
+
+
+
+Security testing is a crucial part of the DevSecOps process, as it helps identify vulnerabilities early on so that they
+can be taken care of before they become an issue in production.
+
+1. Integrate SAST tools into the CI/CD pipeline to analyze source code for vulnerabilities.
+2. Use DAST tools to test running applications for security issues.
+3. Combine SAST and DAST approaches with IAST tools for comprehensive security testing.
+4. Implement fuzz testing to discover security vulnerabilities by inputting random data.
+
+---
+
+---
+
+### PAGE: /infrastructure/cloud
+
+# Cloud Infrastructure
+
+
+
+
+Securing your cloud infrastructure could be considered as important as securing your decentralized application, as a lot
+of users will be interacting with your dapp through the cloud provider. Some best practices to consider are:
+
+1. Implement strict access controls and identity management to ensure that only authorized individuals can interact with
+cloud resources. Use role-based access control (RBAC) and multi-factor authentication (MFA).
+2. Encrypt data both in transit and at rest. Use managed encryption keys or bring your own keys (BYOK) for enhanced
+security.
+3. Configure virtual private clouds (VPCs), implement firewalls, and monitor network traffic to protect against
+unauthorized access and threats.
+4. Set up comprehensive logging, monitoring, and threat detection systems to identify and respond to security incidents
+in real-time. Use services like AWS CloudTrail, Azure Monitor, and Google Cloud Logging.
+5. Implement high availability, data backup, and disaster recovery plans to protect against service disruptions. Use
+automated fail-over and replication strategies.
+6. Ensure compliance with regulatory requirements (e.g., GDPR, MiCA).
+
+## Cloud Provider Hardening Guides
+
+All cloud providers have hardening guides that provide step-by-step instructions and best practices for securing cloud
+infrastructure:
+
+- **AWS**: [Security, Identity, and Compliance](https://aws.amazon.com/architecture/security-identity-compliance/)
+- **Azure**:
+[Best Practices and Patterns](https://learn.microsoft.com/en-us/azure/security/fundamentals/best-practices-and-patterns)
+- **GCP**: [Security Best Practices](https://cloud.google.com/security/best-practices)
+
+## Open Source Tools
+
+To aid with vulnerability detection and compliance, you could consider using the following open-source tools:
+
+- **CloudSploit**: [CloudSploit](https://github.com/aquasecurity/cloudsploit)
+- **Prowler**: [Prowler](https://github.com/prowler-cloud/prowler)
+- **S3Scanner (AWS)**: [S3Scanner](https://github.com/sa7mon/S3Scanner)
+- **Zeus (AWS)**: [Zeus](https://github.com/DenizParlak/Zeus)
+
+---
+
+---
+
+### PAGE: /secure-software-development/secure-code-repositories-version-control
+
+# Secure Code Repositories and Version Control
+
+
+
+
+Managing secure code repositories and having version control practices helps protect your project from unauthorized
+access and ensuring the integrity of your project.
+
+## Best Practices for Secure Code Repositories
+
+1. **Access Control**
+   - Implement strict access controls to limit who can view, modify, and commit code.
+   - Use role-based access control (RBAC) to grant permissions based on the user's role within the organization.
+
+2. **Multi-Factor Authentication (MFA)**
+   - Require MFA for all users accessing the code repository to add an extra layer of security.
+   - Use hardware tokens or authentication apps for stronger security.
+
+3. **Branch Protection**
+   - Enable branch protection rules to prevent unauthorized changes to critical branches such as main/master.
+   - Require code reviews and approvals by another person before changes can be merged into the main/master branch.
+
+4. **Audit Logs**
+   - Enable audit logging to track all activities within the repository.
+   - Regularly review logs to detect any suspicious activities or unauthorized access attempts.
+
+## Secure Version Control Practices
+
+1. **Commit Signing**
+   - Require developers to sign their commits with GPG keys to verify the authenticity of the code changes.
+   - Enforce commit signing policies in the version control system.
+
+2. **Regular Backups**
+   - Regularly back up the code repository to prevent data loss.
+   - Store backups in a secure, offsite location.
+
+3. **Continuous Integration/Continuous Deployment (CI/CD)**
+   - Integrate security checks into the CI/CD pipeline to automatically scan code for vulnerabilities.
+   - Ensure that only tested and approved code is deployed to production.
+
+---
+
+---
+
+### PAGE: /security-automation/infrastructure-as-code
+
+# Infrastructure as Code
+
+
+
+
+Infrastructure as Code (IaC) is the managing and provisioning computing infrastructure through machine-readable
+definition files, rather than manual  configuration or interactive configuration tools. Automating security within IaC
+helps ensure that infrastructure is configured securely and consistently.
+
+## Benefits of Automating Security in IaC
+
+1. **Consistency**
+   - Ensures that infrastructure is provisioned and configured consistently across environments.
+   - Reduces the risk of configuration drift and security misconfigurations.
+
+2. **Scalability**
+   - Enables scalable deployment of secure infrastructure.
+   - Simplifies management of large-scale environments.
+
+3. **Version Control**
+   - Treats infrastructure configurations as code, allowing version control and change tracking.
+   - Facilitates rollback to previous configurations if issues arise.
+
+## Best Practices for Secure IaC
+
+1. **Use Trusted Modules**
+   - Use trusted and verified modules or templates for infrastructure provisioning.
+   - Avoid using unverified or outdated modules that may contain vulnerabilities.
+
+2. **Implement Least Privilege**
+   - Ensure that infrastructure components have the minimum necessary permissions.
+   - Use role-based access control (RBAC) to manage permissions.
+
+3. **Automate Security Scans**
+   - Integrate security scanning tools into the IaC pipeline to automatically detect and remediate vulnerabilities.
+   - Use tools like Checkov, tfsec, and Terrascan to scan Terraform configurations for security issues.
+
+4. **Encrypt Sensitive Data**
+   - Encrypt sensitive data at rest and in transit within the infrastructure.
+   - Use managed encryption services provided by cloud providers.
+
+5. **Regularly Update IaC Templates**
+   - Keep IaC templates and modules up to date with the latest security patches and best practices.
+   - Regularly review and update configurations to address new security threats.
+
+## Tools for Automating Security in IaC
+
+1. **Terraform**
+   - A widely used IaC tool that allows for the automated provisioning of infrastructure across various cloud providers.
+   - Supports integration with security scanning tools like tfsec and Checkov.
+
+2. **AWS CloudFormation**
+   - An IaC service provided by AWS for modeling and setting up AWS resources.
+   - Supports AWS Config rules for automated compliance checks.
+
+3. **Azure Resource Manager (ARM) Templates**
+   - IaC templates for deploying and managing Azure resources.
+   - Integrates with Azure Policy for enforcing security policies.
+
+4. **Ansible**
+   - An open-source automation tool for configuration management and application deployment.
+   - Supports security roles and playbooks for automating security configurations.
+
+---
+
+---
+
+### PAGE: /supply-chain/dependency-awareness
+
+# Dependency Awareness
+
+
+
+
+Dependency awareness is the practice of understanding and managing all the external libraries, frameworks, and
+components that a software project relies on. Dependencies can introduce vulnerabilities and risks, which means it's
+important to keep track of them and ensure they are secure.
+
+## Importance of Dependency Awareness
+
+1. **Security Risks**
+   - Dependencies can contain vulnerabilities that may be exploited by threat actors.
+
+2. **Compliance**
+   - Ensuring that dependencies comply with licensing and regulatory requirements is essential to avoid legal issues.
+
+3. **Maintainability**
+   - Understanding dependencies and their impact on the project will help understand if it's possible to update a
+   dependency used by your application.
+
+## Best Practices for Dependency Awareness
+
+1. **Use Dependency Management Tools**
+   - Leverage tools that can automatically track and manage dependencies. Examples include:
+     - **Web2:**
+       - **Snyk:** Monitors and fixes vulnerabilities in dependencies.
+       - **Dependabot:** Automatically updates dependencies in GitHub projects.
+     - **Solidity:**
+       - **Ethlint:** Analyzes and lints Solidity code, including dependencies.
+       - **MythX:** Scans for vulnerabilities in smart contract dependencies.
+
+2. **Regularly Update Dependencies**
+   - Regularly update dependencies to the latest secure versions after verifying them.
+
+3. **Monitor for Vulnerabilities**
+   - Continuously monitor dependencies for known vulnerabilities using tools like Snyk, npm audit, and GitHub Security
+   Alerts.
+
+4. **Audit Dependencies**
+   - Perform regular audits of dependencies to ensure they are necessary and secure. Remove unused or outdated
+   dependencies.
+
+5. **Use Trusted Sources**
+   - Only use dependencies from trusted and reputable sources. Avoid using unverified or poorly maintained libraries.
+
+---
+
+---
+
diff --git a/scripts/data/qa-briefs/sfc-dns-registrar.md b/scripts/data/qa-briefs/sfc-dns-registrar.md
new file mode 100644
index 00000000..b3aea905
--- /dev/null
+++ b/scripts/data/qa-briefs/sfc-dns-registrar.md
@@ -0,0 +1,953 @@
+# QA Brief: sfc-dns-registrar
+
+## YOUR TASK
+
+Verify the evaluation claims below. For each control with refs:
+1. Read the ACTUAL page content (provided below)
+2. Read the control's FULL baselines
+3. Check: does the page ACTUALLY meet the baselines claimed in "baselinesMet"?
+4. Check: are the "baselinesMissed" correct (is there content that was overlooked)?
+5. Check: is the coverage rating ("full"/"partial") justified?
+
+Be STRICT. If the evaluator was too generous, downgrade. If they missed coverage, upgrade.
+
+## EVALUATION CLAIMS TO VERIFY (11 controls with refs)
+
+### dns-2.1.2: Enterprise Registrar Security Requirements
+**Full baselines:**
+  1. Registrar supports registry locks (server-level EPP locks)
+  2. Registrar supports hardware security key MFA (FIDO2/WebAuthn)
+  3. Registrar has no history of social engineering vulnerabilities
+  4. Due diligence includes checking ICANN compliance notices for the registrar
+
+**Evaluator's assessment:**
+- **/infrastructure/domain-and-dns-security/registrar-and-locks** → Choosing a Secure Registrar — **full**
+  Met: Registrar supports registry locks (server-level EPP locks); Registrar supports hardware security key MFA (FIDO2/WebAuthn); Registrar has no history of social engineering vulnerabilities; Due diligence includes checking ICANN compliance notices
+
+### dns-3.1.1: Registrar Access Control
+**Full baselines:**
+  1. Documented who is authorized, how access is granted/revoked, and role-based permissions where available
+  2. Hardware security key MFA (FIDO2/WebAuthn) required for all registrar and DNS management accounts
+  3. Access reviews conducted at least annually
+  4. Access revoked promptly when no longer needed
+
+**Evaluator's assessment:**
+- **/infrastructure/domain-and-dns-security/registrar-and-locks** → Access Control Best Practices — **partial**
+  Met: Hardware security key MFA (FIDO2/WebAuthn) required for all accounts; Access reviews conducted at least annually (mentions quarterly)
+  Missed: Documented who is authorized, how access is granted/revoked, and role-based permissions (mentions but doesn't teach HOW to document); Access revoked promptly when no longer needed (not actionably addressed)
+**Gaps:** Documented procedures for who is authorized, how access is granted/revoked, and role-based permissions implementation; Prompt access revocation procedures when no longer needed
+
+### dns-3.1.2: Dedicated Domain Security Contact Email
+**Full baselines:**
+  1. Hosted on a different domain than any domain it's responsible for
+  2. Not a personal email address
+  3. Used exclusively for domain security purposes
+  4. Alias that notifies multiple people
+
+**Evaluator's assessment:**
+- **/infrastructure/domain-and-dns-security/registrar-and-locks** → Dedicated Security Contact Email — **partial**
+  Met: Hosted on a different domain than any domain it's responsible for; Not a personal email address; Used exclusively for domain security purposes
+  Missed: Alias that notifies multiple people (not explicitly stated)
+**Gaps:** Alias that notifies multiple people
+
+### dns-4.1.1: DNS Security Standards
+**Full baselines:**
+  1. DNSSEC enabled and validated on all critical domains
+  2. CAA records configured to restrict certificate issuance to authorized CAs only
+  3. TTL policies documented with rationale
+  4. Standards applied consistently based on domain classification
+
+**Evaluator's assessment:**
+- **/infrastructure/domain-and-dns-security/dnssec-and-email** → DNSSEC Implementation — **partial**
+  Met: DNSSEC enabled and validated on all critical domains; CAA records configured to restrict certificate issuance
+  Missed: TTL policies documented with rationale; Standards applied consistently based on domain classification
+**Gaps:** TTL policies documented with rationale; Standards applied consistently based on domain classification
+
+### dns-4.1.2: Email Authentication Standards
+**Full baselines:**
+  1. SPF, DKIM, and DMARC configured for all domains that send email
+  2. DMARC policy set to reject for domains actively sending email
+  3. DMARC aggregate reports (rua) monitored and reviewed
+  4. MTA-STS configured where supported to enforce encrypted email transport
+  5. Domains that don't send email have SPF/DMARC records that reject all email
+
+**Evaluator's assessment:**
+- **/infrastructure/domain-and-dns-security/dnssec-and-email** → Email Security Configuration — **full**
+  Met: SPF, DKIM, and DMARC configured for all domains that send email; DMARC policy set to reject for domains actively sending email; DMARC aggregate reports (rua) monitored and reviewed; MTA-STS configured where supported; Domains that don't send email have SPF/DMARC records that reject all
+
+### dns-4.1.3: Domain Lock Implementation
+**Full baselines:**
+  1. Registry locks (server-level EPP locks) enabled for all critical domains where supported
+  2. Transfer locks enabled on all domains
+  3. Lock status verified periodically
+
+**Evaluator's assessment:**
+- **/infrastructure/domain-and-dns-security/registrar-and-locks** → Registry Lock (EPP Lock) — **full**
+  Met: Registry locks (server-level EPP locks) enabled for critical domains; Transfer locks enabled on all domains; Lock status verified periodically (mentions EPP status codes)
+
+### dns-5.1.1: Domain and DNS Monitoring
+**Full baselines:**
+  1. DNS record monitoring covers nameserver (NS) changes, A/AAAA changes, MX changes, TXT/SPF/DMARC changes, CAA record removal, DNSSEC status changes, and unexpected TTL drops
+  2. Registration monitoring covers lock status, registrar account settings, and nameserver delegation
+  3. Alerting and escalation paths documented
+  4. Critical alerts (nameserver changes, DNSSEC failure, registrar changes) trigger immediate investigation
+  5. Monitoring infrastructure not dependent on the domains being monitored
+
+**Evaluator's assessment:**
+- **/infrastructure/domain-and-dns-security/monitoring-and-alerting** → DNS Record Monitoring — **full**
+  Met: DNS record monitoring covers NS, A/AAAA, MX, TXT/SPF/DMARC, CAA, DNSSEC, TTL changes; Registration monitoring covers lock status, registrar settings, nameserver delegation; Critical alerts trigger immediate investigation; Monitoring infrastructure not dependent on domains being monitored
+  Missed: Alerting and escalation paths documented (mentioned but not detailed HOW to document)
+**Gaps:** Detailed guidance on documenting alerting and escalation paths
+
+### dns-5.1.2: Certificate Transparency Monitoring
+**Full baselines:**
+  1. Subscribed to a CT monitoring service that alerts on new certificate issuance
+  2. Alerts reviewed and unauthorized certificates investigated promptly
+  3. Wildcard certificates flagged if not expected
+
+**Evaluator's assessment:**
+- **/infrastructure/domain-and-dns-security/monitoring-and-alerting** → Certificate Transparency Monitoring — **full**
+  Met: Subscribed to a CT monitoring service that alerts on new certificate issuance; Alerts reviewed and unauthorized certificates investigated promptly; Wildcard certificates flagged if not expected
+
+### dns-5.1.3: Domain Expiration Prevention
+**Full baselines:**
+  1. Auto-renewal enabled on all domains
+  2. Calendar reminders at 90, 60, 30, and 7 days before expiration
+  3. Payment methods verified current
+  4. Backup person designated for renewal responsibility
+
+**Evaluator's assessment:**
+- **/infrastructure/domain-and-dns-security/registrar-and-locks** → Domain Expiration Protection — **full**
+  Met: Auto-renewal enabled on all domains; Calendar reminders at 90, 60, 30, and 7 days before expiration; Payment methods verified current; Backup person designated for renewal responsibility
+
+### dns-6.1.1: Alerting and Emergency Contacts
+**Full baselines:**
+  1. Alerting system in place to notify relevant stakeholders when a potential compromise is detected
+  2. Emergency contacts pre-documented including registrar security team, SEAL 911, and legal counsel
+  3. Communication plan for warning users (status page, social media, in-app warnings)
+
+**Evaluator's assessment:**
+- **/infrastructure/domain-and-dns-security/monitoring-and-alerting** → Setting Up Alerts — **full**
+  Met: Alerting system in place to notify stakeholders when potential compromise detected; Communication plan for warning users (status page, social media)
+  Missed: Emergency contacts pre-documented (registrar security, SEAL 911, legal) - partially in overview but not comprehensive
+**Gaps:** Comprehensive emergency contact documentation including registrar security team, SEAL 911, and legal counsel
+
+### dns-6.1.2: Domain Incident Response Plan
+**Full baselines:**
+  1. Covers key scenarios including registrar account compromise, DNS hijacking, and unauthorized transfers
+  2. Emergency registry lock activation procedures
+  3. Procedures for regaining control of compromised domains
+  4. Post-recovery validation including DNS records verified against known-good baseline, all credentials reset, and access logs reviewed
+  5. Plan tested at least annually (can be combined with broader IR drills)
+
+**Evaluator's assessment:**
+- **/infrastructure/domain-and-dns-security/monitoring-and-alerting** → Incident Response Plan — **full**
+  Met: Covers registrar account compromise, DNS hijacking, unauthorized transfers; Emergency registry lock activation procedures; Procedures for regaining control of compromised domains; Post-recovery validation (DNS records verified, credentials reset, logs reviewed)
+  Missed: Plan tested at least annually
+**Gaps:** Plan tested at least annually (can be combined with broader IR drills)
+
+## FALSE-NEGATIVE CHECK (5 controls marked "no coverage")
+
+Verify these truly have no relevant framework page. If any page below partially covers them, note it.
+
+### dns-1.1.1: Domain Security Owner
+**Baselines:** Accountability scope covers policy maintenance, security reviews, renewal management, access control oversight, and incident escalation
+
+### dns-1.1.2: Domain Inventory and Documentation
+**Baselines:** Registry includes domain name, ownership, purpose, expiration date, registrar, DNS record configurations, security settings (DNSSEC, CAA), and registrar account configurations; Accessible to relevant team members
+
+### dns-2.1.1: Domain Classification and Compliance
+**Baselines:** Classification considers criticality, financial exposure, and operational impact; Domains where users may transact funds or that are external-facing classified at the highest tier; Each classification maps to specific security requirements (DNSSEC, locks, monitoring frequency, access controls) (+1 more)
+
+### dns-3.1.3: Change Management for Domain Operations
+**Baselines:** Covers transfers, deletions, nameserver changes, and DNS record modifications; Relevant team members notified before critical changes; All changes logged (+1 more)
+
+### dns-4.1.4: TLS Certificate Lifecycle Management
+**Baselines:** Covers issuance, renewal, and revocation procedures; Certificates tracked with expiration alerts; Automated renewal where possible (+1 more)
+
+---
+
+## FRAMEWORK PAGES (3 pages)
+
+### PAGE: /infrastructure/domain-and-dns-security/dnssec-and-email
+
+# DNSSEC, CAA, SMTP DANE and Email Security
+
+
+
+
+## DNSSEC Implementation
+
+DNSSEC (DNS Security Extensions) provides cryptographic authentication of DNS responses, preventing attackers from
+redirecting your users to malicious sites by tampering with DNS queries. Think of it as a digital signature that proves
+the DNS response came from the legitimate source.
+
+**How it protects you**: Without DNSSEC, attackers can intercept DNS queries and return fake IP addresses, redirecting
+users to malicious sites that look identical to yours. DNSSEC prevents this by cryptographically signing all DNS
+responses. While most client devices and many recursive resolvers do not perform DNSSEC validation on general DNS
+queries, DNSSEC is sometimes required and often preferred as a foundational component for security-sensitive internet
+protocols and features such as SMTP DANE, SSHFP, and CAA.
+
+**Preconditions**:
+
+- Domain is using the provider's nameservers
+- Registrar supports DS records
+- If registrar supports CDS/CDNSKEY auto-publish, enable that if offered
+
+**Practical setup**:
+
+1) **Enable signing at DNS provider**
+   - Turn on DNSSEC in the zone settings
+   - Provider generates KSK (Key Signing Key) and ZSK (Zone Signing Key), signs the zone, and shows DS parameters:
+     - **Key Tag**: Unique identifier for the key
+     - **Algorithm**: Common options:
+       - `13` (ECDSAP256SHA256) - Recommended
+       - `8` (RSASHA256)
+       - `15` (ECDSAP384SHA384)
+     - **Digest Type**:
+       - `2` (SHA-256) - Recommended for widest compatibility
+       - `4` (SHA-384)
+     - **Digest**: Hex string of the hash
+
+2) **Publish DS at registrar**
+   - Create a DS record with the exact four fields above
+   - Prefer Algorithm `13` (ECDSAP256SHA256) with Digest Type `2` (SHA-256) where supported
+   - If both digest types 2 and 4 are offered, pick 2 for the widest compatibility
+
+   Example registrar DS template:
+
+   ```
+   Owner: yourdomain.tld
+   Key Tag: 2371
+   Algorithm: 13
+   Digest Type: 2
+   Digest: 5C9F3E7B3F...A1C7
+   ```
+
+3) **Verify validation**
+   - Wait for registrar DS propagation (can take minutes to hours)
+   - Verify from a validating resolver using command-line tools:
+     - `dig +dnssec example.com A` (check for AD flag in response)
+     - `kdig +dnssec example.com A` (Knot DNS tool)
+     - `drill -D example.com A` (LDNS tool)
+   - For detailed analysis, use web tools:
+     - [Verisign DNSSEC Analyzer](https://dnssec-analyzer.verisignlabs.com/yourdomain.org)
+     - [DNSViz](https://dnsviz.net/d/yourdomain.org/analyze/)
+
+4) **Monitor validation and changes**
+   - Set up alerts for DS record changes at the registrar
+   - Monitor DNSSEC validation status regularly
+   - Watch for DNSKEY rollovers and ensure they complete successfully
+
+**Security notes**:
+
+- DNSSEC authenticates data; it does **not** encrypt queries. Use DoT (DNS over TLS) or DoH (DNS over HTTPS) for
+  transport privacy if needed.
+- Harden registrar accounts, protect transfer locks, and monitor for DS changes; DS removal downgrades protection.
+- A hijacked registrar account can remove DS records, eliminating DNSSEC protection
+- Add alerts on registrar activity to detect unauthorized changes
+
+## CAA Records
+
+Certificate Authority Authorization (CAA) records specify which Certificate Authorities (CAs) are allowed to issue SSL
+certificates for your domain. This prevents unauthorized certificate issuance, which attackers could use to create fake
+SSL certificates for your domain.
+
+**How it protects you**: Without CAA records, any Certificate Authority can issue SSL certificates for your domain.
+Attackers could potentially obtain fake certificates and use them in sophisticated phishing attacks that appear to have
+valid SSL encryption.
+A well behaved CA not explicitly permitted via CAA records will deny certificate requests for that domain. \
+While CA compromises are rare, history shows they do happen — and in such cases, attackers could potentially bypass
+or ignore CAA entirely. \
+Notable incidents include:
+
+- [DigiNotar (2011)](https://en.wikipedia.org/wiki/DigiNotar)
+- [Comodo (2011)](https://www.theregister.com/2011/03/28/comodo_gate_hacker_breaks_cover/) \
+Honorable mention, where it’s unclear whether CAA would have prevented the issue:
+- [Symantec Mis‑Issuance (2015–2017)](https://groups.google.com/a/chromium.org/g/blink-dev/c/eUAKwjihhBs/m/rpxMXjZHCQAJ)
+
+Before setting CAA records, identify which CA issued your current certificate:
+
+- **Command line**: `openssl s_client -connect yourdomain.com:443 -servername yourdomain.com | openssl x509 -noout -issuer`
+- **Web tools**: [SSL Labs Server Test](https://www.ssllabs.com/ssltest/) provides comprehensive certificate analysis
+  including issuer information
+- **Browser**: Click the padlock icon → Certificate details → Issuer information
+
+**Setup process**: Add CAA records to your DNS zone. Most DNS providers allow you to add these through their web interface:
+
+With the issuers full name in hand we now need to map it to the "Issuer Domain Name".
+There is no centralized repository mapping public CA's to their issuer domain names but they are generally easily found with
+a simple search for f.x. "Let's Encrypt CAA". \
+The Common CA Database also provides a
+[comprehensive collection to reference](https://ccadb.org/resources).
+
+```
+# Allow only specific CAs to issue certificates
+example.com. CAA 0 issue "letsencrypt.org"
+example.com. CAA 0 issue "digicert.com"
+
+# Send violation reports when unauthorized CAs attempt issuance
+example.com. CAA 0 iodef "mailto:security@example.com"
+
+# Control wildcard certificate issuance separately
+example.com. CAA 0 issuewild "letsencrypt.org"
+
+# Completely disable all certificate issuance (useful for non-web domains)
+example.com. CAA 0 issue ";"
+```
+
+## SMTP DANE
+
+DNS-based Authentication of Named Entities (DANE) is an email security protocol that relies on TLSA DNS
+records secured via DNSSEC. The TLSA record contains information on the MX and the certificate in use,
+allowing a secure connection to be made using that certificate.
+This prevents both MiTM and downgrade attacks. \
+DANE requires DNSSEC to be enabled on your domain - without it, TLSA records can be spoofed and offer no security benefit.
+
+If no record is found, SMTP DANE supporting clients will fall back to their usual connection flow.
+
+*While traditional PKI relies on trusted CAs, DANE allows domain owners to specify their own certificates,
+relying instead on DNSSEC to authenticate the certificate.*
+
+**Current industry support**: Of the major providers, Microsoft is the only one that currently supports
+SMTP DANE since its [RFC](https://datatracker.ietf.org/doc/html/rfc7672) was published in 2015. Notable
+smaller implementers include Comcast, Protonmail, Cisco, Fastmail, Posteo and Mailbox.org.
+
+**Implementation**: For those interested, a simple step-by-step tutorial can be found here for
+[Exchange Online](https://learn.microsoft.com/en-us/purview/how-smtp-dane-works#inbound-smtp-dane-with-dnssec).
+And for the brave, the Dutch Internet Standards Platform has published
+[detailed documentation](https://github.com/internetstandards/toolbox-wiki/blob/main/DANE-for-SMTP-how-to.md#reliable-certificate-rollover)
+on various aspects of supporting SMTP DANE on a self-hosted MX like postfix.
+
+**Example TLSA Record**:
+
+smtpdane.mx.microsoft. TLSA 900 "3 1 1 c495d9e40f7e625be22f83cc64305182ab0fe74232de30db8b218d09650cb0ea"
+
+- _25._tcp.smtpdane.mx.microsoft. → Host + port (SMTP uses 25/TCP)
+- TLSA → Record type for DANE
+- 900 → TTL in seconds
+- 3 1 1 →
+
+  - Usage 3 = Bind to end-entity cert
+  - Selector 1 = Public key info
+  - Match 1 = SHA-256 hash
+- Hex string → Hash of the MX certificate's public key
+
+**Further reading**:
+
+- [Microsoft SMTP DANE](https://learn.microsoft.com/en-us/purview/how-smtp-dane-works)
+- [RFC 7672](https://datatracker.ietf.org/doc/html/rfc7672)
+- [Google Cloud DNSSEC](https://docs.cloud.google.com/dns/docs/dnssec-advanced#tlsa) (only general docs, no
+  Google Mail support as of writing)
+
+## Email Security Configuration
+
+Email security records protect against email spoofing and phishing attacks. When your domain is compromised, attackers
+often change email settings to intercept password reset emails and other sensitive communications.
+
+### SPF (Sender Policy Framework)
+
+SPF records specify which mail servers are authorized to send emails on behalf of your domain. This prevents attackers
+from spoofing your domain in phishing emails.
+
+**How it protects you**: Without SPF, anyone can send emails claiming to be from your domain. Attackers use this for
+sophisticated phishing campaigns that appear to come from your legitimate email address.
+
+This is particularly dangerous as attackers can impersonate executives or team members to target your own organization
+and users - imagine receiving a "urgent wire transfer" request from your CFO's email address, or your users getting a
+"mandatory wallet update" from your official support email.
+
+**Setup**: Add an SPF record to your DNS zone:
+
+```
+example.com. TXT "v=spf1 include:_spf.google.com ~all"
+```
+
+### DKIM (DomainKeys Identified Mail)
+
+DKIM adds a digital signature to your emails, allowing receiving servers to verify that emails actually came from your
+domain and haven't been tampered with.
+
+**How it protects you**: DKIM signatures prove email authenticity and integrity, making it much harder for attackers to
+successfully spoof your domain in phishing campaigns.
+
+**Setup**: Configure with your email provider and publish public keys in DNS (your email provider will provide the
+specific records).
+
+### MTA-STS (Mail Transfer Agent Strict Transport Security)
+
+MTA-STS enforces encrypted connections between mail servers, preventing man-in-the-middle attacks on email transmission.
+
+**How it protects you**: Without MTA-STS, emails can be intercepted in transit. This is especially critical for password
+reset emails and other sensitive communications.
+
+**Deployment steps**:
+
+1) **Create the MTA-STS policy file**
+
+   Host a plain text file at: `https://mta-sts.<domain>/.well-known/mta-sts.txt`
+
+   Policy file structure:
+
+   ```
+   version: STSv1
+   mode: testing
+   mx: smtp.example.com
+   mx: alt1.smtp.example.com
+   max_age: 86400
+   ```
+
+   **Mode options**:
+
+   - `testing` - Monitor TLS failures but don't block mail (recommended to start)
+   - `enforce` - Require TLS for mail delivery
+   - `none` - Disable policy
+
+   **Important**: List all your MX servers. Ensure they have valid TLS certificates matching their hostnames.
+
+2) **Host the policy file over HTTPS**
+
+   The file must be:
+   - Publicly accessible at the exact path
+   - Served over HTTPS with a valid certificate
+   - Available 24/7 (use reliable hosting)
+
+3) **Publish DNS TXT record**
+
+   Create a TXT record at `_mta-sts.<domain>`:
+
+   ```
+   _mta-sts.example.com. TXT "v=STSv1; id=20250101000000"
+   ```
+
+   The `id` value (often a timestamp or version) signals mail servers to fetch the latest policy. Update it whenever you
+   change the policy file.
+
+4) **Testing and enforcement**
+   - Start with `mode: testing` to monitor without blocking
+   - Collect and review TLS failure reports
+   - Once confident, change to `mode: enforce`
+   - Update the `id` in DNS TXT record after policy changes
+
+**Provider-specific tips**:
+
+- **Google Workspace**: Manage MX in Admin console; host policy yourself; add TXT via DNS
+- **Cloudflare**: Host policy on Workers/Pages; manage TXT in DNS; HTTPS auto via Cloudflare SSL
+- **Amazon SES**: Host on S3 or CloudFront; manage TXT in Route 53; ensure domains are verified
+
+**Security notes**:
+
+- `max_age` determines how long mail servers cache the policy (86400 = 1 day)
+- All MX servers must support TLS with valid certificates
+- Monitor policy file availability - if unreachable, mail delivery may fail in enforce mode
+
+### DMARC (Domain-based Message Authentication)
+
+DMARC builds on SPF and DKIM to provide policy enforcement for email authentication. It tells receiving mail servers
+what to do with emails that fail authentication checks.
+
+**How it protects you**: DMARC prevents email spoofing by instructing receiving servers to reject or quarantine emails
+that fail authentication, protecting your users from phishing attacks.
+Without it, emails breaking SPF/DKIM may still be delivered by some providers (like Gmail, Outlook), often to the
+inbox or spam folder, sometimes with a warning banner (e.g., "This message may not be from…")
+DMARC also enables aggregate (rua) and forensic (ruf) reporting, giving domain owners visibility into who is sending
+email on their behalf - legitimate or otherwise.
+
+**Setup**: Add a DMARC record to your DNS zone:
+
+**Baseline example (aggregate reports only)**:
+
+```
+_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
+```
+
+**Report types**:
+
+- **`rua=`** (Aggregate reports): Daily summaries of authentication results. This is the baseline and widely supported.
+- **`ruf=`** (Failure reports): Real-time forensic reports for individual failures. Not recommended as they are:
+  - Not widely supported by mail providers
+  - Raise privacy concerns (contain message content/headers)
+  - May not deliver reliably
+  - Often unnecessary for monitoring purposes
+
+**Recommendation**: Start with aggregate reports only (`rua=`). They provide sufficient visibility into authentication
+issues without the privacy and reliability concerns of failure reports.
+
+---
+
+---
+
+### PAGE: /infrastructure/domain-and-dns-security/monitoring-and-alerting
+
+# Monitoring, Alerts, and Incident Response
+
+
+
+
+## DNS Record Monitoring
+
+DNS record monitoring involves continuously checking your domain's DNS records for unauthorized changes. Attackers often
+modify DNS records to redirect traffic to malicious servers while keeping your site partially functional.
+
+**What to watch for**:
+
+- **Nameserver (NS) record changes**: Attackers change your nameservers to point to their own DNS servers, giving them
+  complete control over all DNS records
+- **Sudden TTL drops**: Very low TTLs *can* indicate preparation for rapid DNS changes during an attack
+  - **Note**: Low TTL is common and legitimate with CDNs and auto-scaling contexts; Cloudflare "Auto" is often 300s
+  - **Context**: Cloudflare allows TTL 30-60s for [unproxied
+    records](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/); this is not inherently malicious
+  - **Monitor for**: *Unexpected* drops from higher values or drops combined with other suspicious activity
+- **CAA record removal or overrides**: Allows any Certificate Authority to issue certificates for your domain
+  - **Note**: Child zones override parent CAA records
+  - **Advanced monitoring**: Watch for parameters like `accounturi` and `validationmethods` which provide finer control
+    over certificate issuance
+- **DNSSEC disabled unexpectedly**: Removes cryptographic protection from DNS responses
+
+**If nameservers remain unchanged, also monitor**:
+
+- **A/AAAA record modifications**: IP address changes could redirect users to malicious sites
+- **MX record modifications**: Email server changes could intercept password reset emails
+- **TXT record changes**: Could affect email security (SPF/DMARC) or domain validation
+
+**Monitoring tools** (continuous change tracking):
+
+- [MXToolbox](https://mxtoolbox.com/) - Comprehensive DNS record monitoring and alerts
+- [HetrixTools](https://hetrixtools.com/) - Free DNS monitoring with email alerts
+- [SecurityTrails](https://securitytrails.com/) - Historical DNS data and change tracking
+
+**Analysis and debugging tools**:
+
+- [DNSViz](https://dnsviz.net/) - DNSSEC chain validation and debugging
+- [DNS Dumpster](https://dnsdumpster.com/) - DNS reconnaissance and record discovery
+
+**GitOps and zone control**:
+
+- [OctoDNS](https://github.com/octodns/octodns) - Infrastructure-as-code for DNS; manage zones via code with auditable,
+  reviewed changes through CI/CD
+- [DNSControl](https://github.com/StackExchange/dnscontrol) - Synchronize DNS across multiple providers; declarative
+  configuration with version control
+
+**Note**: If attackers change your NS records, they control everything. But attackers with DNS panel access might make
+subtle changes without touching NS records to avoid detection, which is why monitoring individual record types remains
+important.
+
+## Certificate Transparency Monitoring
+
+Certificate Transparency (CT) logs are public records of all SSL certificates issued by Certificate Authorities.
+Monitoring these logs helps detect unauthorized certificate issuance.
+
+**Why it matters**: Attackers sometimes obtain fake SSL certificates for legitimate domains to make phishing sites
+appear more credible. CT monitoring helps you detect these certificates before they're used in attacks.
+
+**Setup and tools**:
+
+- [crt.sh](https://crt.sh/) - Search and monitor CT logs for your domain
+- [Cert Spotter](https://sslmate.com/certspotter/) - Free CT monitoring with API access
+- Watch for wildcard certificates if you don't use them (could indicate broader compromise)
+
+## Passive DNS Monitoring
+
+Passive DNS monitoring tracks historical DNS resolution data across the internet, helping you detect brief changes that
+might be missed by periodic checks.
+
+**What it detects**:
+
+- **Brief record changes**: Attackers often make quick changes to avoid detection
+- **Geographic anomalies**: DNS records resolving to unexpected countries or regions
+- **Suspicious hosting provider changes**: Sudden switches to hosting providers known for malicious activity
+
+**Tools for passive DNS**:
+
+- [PassiveTotal (RiskIQ)](https://community.riskiq.com/) - Comprehensive passive DNS database
+- [Mnemonic Passive DNS](https://passivedns.mnemonic.no/) - Free passive DNS lookup
+- [SecurityTrails](https://securitytrails.com/) - Historical DNS and WHOIS data
+
+## Setting Up Alerts
+
+### Critical Alerts (Immediate Response Required)
+
+1. **Registrar Changed**
+
+   - **What it monitors**: Changes to your domain's registrar
+   - **Why it's critical**: Indicates potential domain hijacking or unauthorized transfer
+   - **Response**: Immediate verification and potential incident response activation
+
+2. **Nameserver Changed**
+
+   - **What it monitors**: Changes to nameserver records
+   - **Why it's critical**: Attackers often change nameservers to redirect traffic to malicious servers
+   - **Response**: Verify legitimacy, check if you initiated the change
+
+3. **DNSSEC Broken**
+
+   - **What it monitors**: DNSSEC validation failures or disabled DNSSEC
+   - **Why it's critical**: DNS responses can be tampered with, leading to man-in-the-middle attacks
+   - **Response**: Investigate signing issues, check for configuration changes
+
+4. **CAA Records Removed or Overridden**
+
+   - **What it monitors**: Removal of Certificate Authority Authorization records or child zone overrides
+   - **Why it's critical**: Allows any CA to issue certificates for your domain, enabling SSL certificate attacks
+   - **Response**: Restore CAA records immediately, investigate who removed them
+   - **Note**: Child zones override parent CAA; parameters like `accounturi` and `validationmethods` can provide finer control
+
+5. **Unexpected TTL Drops**
+
+   - **What it monitors**: Sudden TTL drops from higher values
+   - **Why it's important**: Can indicate preparation for rapid DNS changes (attack preparation)
+   - **Context**: Low TTL (30-300s) is normal for CDNs and auto-scaling; Cloudflare allows 30-60s for [unproxied records](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/)
+   - **Response**: Investigate *unexpected* drops or drops combined with other suspicious activity; verify if legitimate
+     infrastructure changes
+
+### High Priority Alerts (When NS Unchanged)
+
+1. **A Record Changed**
+
+   - **What it monitors**: IP redirects without NS changes
+   - **Why it's important**: Could redirect users to malicious servers
+   - **Response**: Verify the new IP address is legitimate and expected
+
+2. **MX Record Changed**
+
+   - **What it monitors**: Changes to mail server configurations
+   - **Why it's important**: Could intercept emails, including password reset messages
+   - **Response**: Verify mail server changes are authorized
+
+3. **DMARC Policy Weakened**
+
+   - **What it monitors**: Changes from "reject" to "quarantine" or "none"
+   - **Why it's important**: Weaker policies allow more spoofed emails to reach users
+   - **Response**: Investigate why policy was weakened, restore if unauthorized
+
+4. **Unexpected Certificate Issued**
+
+   - **What it monitors**: New SSL certificates issued for your domain
+   - **Why it's important**: Could indicate certificate-based attacks or unauthorized issuance
+   - **Response**: Verify the certificate was requested by your team, revoke if unauthorized
+
+## Incident Response Plan
+
+### Immediate Response
+
+1. **Verify the compromise** - Check DNS records via multiple resolvers
+2. **Access registrar account** - Attempt login, check for lockout
+3. **Contact registrar security team** - Use pre-documented emergency contacts
+4. **Document everything** - Screenshot all current settings
+
+### Containment
+
+1. **Invoke registry lock** if available
+2. **Update NS records** if you maintain access
+3. **Warn users** via social media/status page
+4. **Contact law enforcement** if significant theft occurred
+
+### Recovery
+
+1. **Regain control** through registrar security procedures
+2. **Audit all DNS records** against known-good baseline
+3. **Reset all credentials** for registrar and DNS hosting
+4. **Review access logs** to understand attack vector
+
+### Post-Incident
+
+1. **Conduct thorough investigation**
+2. **Update security measures** based on lessons learned
+3. **Consider legal action** if appropriate
+4. **Publish transparency report** to rebuild trust
+
+---
+
+---
+
+### PAGE: /infrastructure/domain-and-dns-security/registrar-and-locks
+
+# Registrar Security & Registry Locks
+
+
+
+
+## Choosing a Secure Registrar
+
+Your domain registrar is the company that manages your domain registration with the central registry. This is often the
+weakest link in domain security, as many registrars have poor security practices and are vulnerable to social
+engineering attacks.
+
+### Enterprise-Grade Registrars (Recommended)
+
+These registrars are designed for high-value domains and have security measures that consumer registrars lack:
+
+- **MarkMonitor**: Used by Fortune 500 companies, requires legal documentation for changes, dedicated security team
+- **AWS Route53**: IAM policy integration, CloudTrail logging, uses Amazon Registrar for major TLDs (but check TLD support)
+- **Cloudflare Registrar**: No markup pricing, automatic DNSSEC, built-in DDoS protection, requires Cloudflare services
+
+### Consumer Registrars to Avoid for Critical Domains
+
+These registrars are designed for personal use and lack the security measures needed for Web3 projects:
+
+- **GoDaddy**: History of social engineering vulnerabilities, call center support vulnerable to manipulation
+  - [2020 incident: Employees tricked into compromising cryptocurrency domains](https://threatpost.com/godaddy-employees-tricked-compromise-cryptocurrency/161520/)
+  - [Multiple low-tech, high-impact breaches](https://krebsonsecurity.com/2023/02/when-low-tech-hacks-cause-high-impact-breaches/)
+- **Namecheap**: While better than GoDaddy, still vulnerable to social engineering and lacks enterprise-grade security controls
+- **Consumer-focused services** (Google Domains/Squarespace): Designed for personal use, not enterprise security
+- **Resellers**: Add another layer of complexity and potential attack surface
+
+**Due diligence**: Check [ICANN Compliance Notices](https://www.icann.org/compliance/notices) for registrar
+terminations, breaches, and compliance issues. ICANN has terminated several registrars due to security issues and
+breaches. Review your registrar's compliance history before trusting them with critical domains.
+
+## Registry Lock (EPP Lock)
+
+Registry lock prevents unauthorized transfers at the registry level, not just the registrar. This is the strongest
+protection available for domain security.
+
+**Important distinction**: EPP status codes apply to **registry objects** (transfers, deletes, nameserver sets, contact
+updates), NOT DNS zone edits at your provider's DNS panel. You can still edit A records, MX records, TXT records, etc.
+in your DNS hosting provider's interface even with EPP locks enabled.
+
+**EPP Status Codes** that protect your domain:
+
+- `clientTransferProhibited`: Prevents domain transfers to another registrar
+- `clientUpdateProhibited`: Prevents registry object updates (nameservers, contact information)
+- `clientDeleteProhibited`: Prevents domain deletion
+- `serverTransferProhibited`: Registry-level transfer protection (stronger than client-level)
+- `serverUpdateProhibited`: Registry-level update protection (nameservers, contacts)
+- `serverDeleteProhibited`: Registry-level deletion protection
+
+**How it protects you**: Standard transfer locks only prevent transfers between registrars, but registry locks with full
+EPP protections prevent unauthorized changes to critical registry objects including transfers, deletions, nameserver
+changes, and contact modifications. Server-level locks require manual verification with the registry operator (like
+Verisign for .com domains), making social engineering attacks at the registrar level completely ineffective.
+
+**What EPP locks do NOT block**: DNS record edits (A, AAAA, MX, TXT, etc.) in your DNS provider's panel remain fully
+functional. EPP locks protect registry-level changes, not zone-level DNS record edits.
+
+**Setup**: Contact enterprise registrars for registry-operator level locks. This typically requires additional fees and
+documentation but provides the highest level of security.
+
+## Multi-Factor Authentication
+
+Multi-factor authentication (MFA) adds an extra layer of security beyond just passwords, which are easily compromised
+through phishing or data breaches.
+
+**Strong recommendation**: Use **Hardware Security Keys (FIDO2/WebAuthn)** for registrar accounts. Given the critical
+nature of domain security and the irreversibility of domain hijacks, hardware keys are the ONLY authentication method we
+strongly recommend for Web3 projects.
+
+**Authentication options**:
+
+1. **Hardware Security Keys (YubiKey, Titan, etc.) - STRONGLY RECOMMENDED**
+   - **Immune to phishing**: Cannot be tricked by fake login pages
+   - **No shared secrets**: Private key never leaves the device
+   - **No SIM swap vulnerability**: Physical device required
+   - **FIDO2/WebAuthn standard**: Industry-standard cryptographic authentication
+   - **Why critical for domains**: Domain control = organization control; hardware keys provide the highest assurance
+
+2. **TOTP Applications (Google Authenticator, Authy) - DISCOURAGED**
+   - Vulnerable to phishing through man-in-the-middle attacks
+   - Shared secrets can be compromised during setup
+   - QR codes can be intercepted or screenshotted
+   - Only use as a last resort if registrar doesn't support hardware keys
+   - If forced to use TOTP, ensure registrar has additional protections
+
+3. **SMS 2FA - DO NOT USE**
+   - **Extremely vulnerable to SIM swapping attacks**
+   - SMS can be intercepted via SS7 vulnerabilities
+   - Social engineering attacks target mobile carriers
+   - No cryptographic security
+   - Numerous high-profile compromises via SMS 2FA
+   - **Never use SMS 2FA for domain registrar accounts**
+
+**Action item**: If your registrar only supports SMS or TOTP, consider **migrating to an enterprise registrar**
+(MarkMonitor, AWS Route53 Registrar, Cloudflare Registrar) that supports hardware security keys.
+
+## Dedicated Security Contact Email
+
+Use a dedicated email address for domain security that's completely separate from your main domain and personal accounts.
+
+**Why this matters**: If your main domain is compromised, you need a way to receive security notifications and regain
+control. Using the same domain creates a circular dependency.
+
+```
+❌ admin@yourdomain.com (circular dependency - if domain is hijacked, you lose email access)
+❌ personal@gmail.com (too many attack vectors, likely used across multiple services)
+⚠️ domain-security@protonmail.com (better than gmail, but still a shared service)
+✅ security@yourcompany-domains.com (best - separate domain dedicated to domain management)
+```
+
+As a best practice register a separate domain specifically for domain management (e.g., `yourproject-domains.com` or
+`yourproject-security.com`) with a different registrar than your main domain. This ensures you maintain communication
+channels even if your primary domain is completely compromised.
+
+## Access Control Best Practices
+
+Limit and monitor who has access to your domain registrar account, as each person with access represents a potential
+attack vector.
+
+**Key practices**:
+
+- Document all personnel with registrar access
+- Use role-based access where available
+- Implement approval workflows for critical changes
+- Regular access audits (quarterly minimum)
+
+## WHOIS Privacy Protection
+
+WHOIS records contain personal information about domain owners that is publicly accessible by default, including names,
+addresses, phone numbers, and email addresses.
+
+**Why it matters**: Without WHOIS privacy, your personal information is exposed to:
+
+- Attackers gathering information for social engineering attacks
+- Spammers harvesting contact details
+- Competitors researching your infrastructure
+- Anyone running a simple WHOIS lookup
+
+**Setup**:
+
+- Enable WHOIS privacy/proxy service through your registrar (often free or low-cost)
+- Use company information instead of personal details where privacy isn't available
+- Consider using a separate business entity for domain registration
+- Be aware that some TLDs (.us, .ca) don't allow WHOIS privacy
+
+**Important**: WHOIS privacy doesn't affect your legal ownership - you remain the legitimate owner, the privacy service
+just shields your personal information from public view.
+
+## WHOIS vs RDAP
+
+**RDAP (Registration Data Access Protocol)** is the modern replacement for WHOIS. While WHOIS is still widely used, RDAP
+should be preferred for domain information lookups.
+
+**Why RDAP is better**:
+
+- **Structured data**: JSON-based responses are machine-readable and easier to parse
+- **Standardized**: Consistent format across registries and registrars
+- **Better display**: Modern CLIs and tools display RDAP data in organized, readable formats
+- **More reliable**: Built on RESTful APIs with better authentication and access control
+- **Links to authoritative sources**: Provides direct links to registrar and registry RDAP endpoints
+
+**Using RDAP**:
+
+- **Command-line tools**: Use RDAP CLIs like `rdap` (Rust-based) or `nicinfo` (Ruby-based)
+- **Web tools**: Many registries provide RDAP web interfaces
+- **Example lookup**: `rdap yourdomain.com` displays domain status, EPP codes, nameservers, registrar info, and
+  expiration dates
+
+**Example RDAP output**:
+
+```
+❯ rdap google.com
+2025-10-06T20:36:58.203437Z  INFO rdap: ICANN RDAP 0.0.23 Command Line Interface
+2025-10-06T20:36:58.203497Z  INFO rdap: query type is Domain Lookup for value 'google.com'
+――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
+ • host                       : rdap.verisign.com
+ • Request URI                : https://rdap.verisign.com/com/v1/domain/google.com
+
+――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
+                                   Domain GOOGLE.COM
+
+  ┌────────────────────────────┬─────────────────────────────────────────────────────┐
+  │                     Summary│Domain GOOGLE.COM                                    │
+  │                            │• 292 (Registrar)                                    │
+  │                            │  • Abuse                                            │
+  │                            │• Nameserver NS1.GOOGLE.COM                          │
+  │                            │• Nameserver NS2.GOOGLE.COM                          │
+  │                            │• Nameserver NS3.GOOGLE.COM                          │
+  │                            │• Nameserver NS4.GOOGLE.COM                          │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │        Identifiers         │                                                     │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │                    LDH Name│GOOGLE.COM                                           │
+  │                Unicode Name│                                                     │
+  │                      Handle│2138514_DOMAIN_COM-VRSN                              │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │        Information         │                                                     │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │                      Status│• Client Delete Prohibited                           │
+  │                            │• Client Transfer Prohibited                         │
+  │                            │• Client Update Prohibited                           │
+  │                            │• Server Delete Prohibited                           │
+  │                            │• Server Transfer Prohibited                         │
+  │                            │• Server Update Prohibited                           │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │           Events           │                                                     │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │                Registration│• Mon, 15-Sep-1997 04:00:00 +00:00                   │
+  │                  Expiration│• Thu, 14-Sep-2028 04:00:00 +00:00                   │
+  │                Last Changed│• Mon,  9-Sep-2019 15:39:04 +00:00                   │
+  │Last Update Of RDAP Database│• Mon,  6-Oct-2025 20:36:39 +00:00                   │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │           Links            │                                                     │
+  ├────────────────────────────┼─────────────────────────────────────────────────────┤
+  │                        Self│• https://rdap.verisign.com/com/v1/domain/GOOGLE.COM │
+  │                     Related│• https://rdap.markmonitor.com/rdap/domain/GOOGLE.COM│
+  └────────────────────────────┴─────────────────────────────────────────────────────┘
+
+                                    292 (Registrar)
+
+                ┌─────────────────┬────────────────────────────────────┐
+                │          Summary│292 (Registrar)                     │
+                │                 │• Abuse                             │
+                ├─────────────────┼────────────────────────────────────┤
+                │   Identifiers   │                                    │
+                ├─────────────────┼────────────────────────────────────┤
+                │           Handle│292                                 │
+                │            Roles│• registrar                         │
+                │IANA Registrar ID│292                                 │
+                ├─────────────────┼────────────────────────────────────┤
+                │     Contact     │                                    │
+                ├─────────────────┼────────────────────────────────────┤
+                │        Full Name│MarkMonitor Inc.                    │
+                ├─────────────────┼────────────────────────────────────┤
+                │      Links      │                                    │
+                ├─────────────────┼────────────────────────────────────┤
+                │            About│• http://www.markmonitor.com        │
+                │                 │• https://rdap.markmonitor.com/rdap/│
+                └─────────────────┴────────────────────────────────────┘
+```
+
+**What RDAP shows**:
+
+- Domain status and EPP lock codes (clientTransferProhibited, serverUpdateProhibited, etc.)
+- Nameserver information
+- Registrar details and abuse contacts
+- Registration, expiration, and last update dates
+- Links to registry and registrar RDAP endpoints
+
+**For security audits**: Use RDAP to verify your domain's EPP status codes, confirm registry locks are active, check
+nameserver configurations, and validate expiration dates. The structured output makes it ideal for automated monitoring
+and compliance checks.
+
+## Domain Expiration Protection
+
+Domain expiration is a critical yet often overlooked security risk. When domains expire, they enter a grace period
+before becoming publicly available, creating an opportunity for attackers to snipe your domain.
+
+**Expiration timeline (typical for gTLDs following ICANN rules)**:
+
+- Day 0: Domain expires (site goes down)
+- Day 1-45: Auto-renew grace period (can renew at normal price)
+- Day 46-75: Redemption period (costs 10x+ to recover)
+- Day 76-80: Pending delete
+- Day 81: Public availability (bot armies compete to register)
+
+**Important**: Grace and redemption periods **differ per TLD**. Generic TLDs (gTLDs like .com, .org, .net) follow ICANN
+rules with the timeline above. Country code TLDs (ccTLDs like .uk, .de, .ca) often have different policies set by their
+respective registries. Always verify your specific TLD's expiration policy with your registrar or registry.
+
+**Protection measures**:
+
+- **Enable auto-renewal** on all critical domains
+- **Set multiple renewal reminders** at 90, 60, 30, and 7 days before expiration
+- **Register domains for maximum period** (up to 10 years for most TLDs)
+- **Use a domain monitoring service** that alerts on upcoming expirations
+- **Document renewal dates** in your security calendar
+- **Ensure payment methods stay current** - expired credit cards are a common cause of accidental expiration
+- **Designate a backup person** responsible for domain renewals
+
+**Pro tip**: Set calendar reminders to check auto-renewal status quarterly - don't assume it's working until you verify.
+
+---
+
+---
+
diff --git a/scripts/data/qa-briefs/sfc-incident-response.md b/scripts/data/qa-briefs/sfc-incident-response.md
new file mode 100644
index 00000000..26633e7a
--- /dev/null
+++ b/scripts/data/qa-briefs/sfc-incident-response.md
@@ -0,0 +1,1838 @@
+# QA Brief: sfc-incident-response
+
+## YOUR TASK
+
+Verify the evaluation claims below. For each control with refs:
+1. Read the ACTUAL page content (provided below)
+2. Read the control's FULL baselines
+3. Check: does the page ACTUALLY meet the baselines claimed in "baselinesMet"?
+4. Check: are the "baselinesMissed" correct (is there content that was overlooked)?
+5. Check: is the coverage rating ("full"/"partial") justified?
+
+Be STRICT. If the evaluator was too generous, downgrade. If they missed coverage, upgrade.
+
+## EVALUATION CLAIMS TO VERIFY (11 controls with refs)
+
+### ir-1.1.1: IR Team and Role Assignments
+**Full baselines:**
+  1. Incident commander (with designated backup) who coordinates response, assigns tasks, and makes time-sensitive decisions
+  2. Subject matter experts identified for key domains (smart contracts, infrastructure, security) who can analyze attacks and prepare response strategies
+  3. Scribe role defined for real-time incident documentation
+  4. Communications personnel designated for public information sharing and record-keeping
+  5. Legal support available with procedures for reviewing response actions, whitehat engagement, and public communications
+  6. Decision makers defined for high-stakes decisions (system shutdown, public disclosure, fund recovery)
+  7. Roles, authorities, and escalation measures reviewed at least annually and after protocol changes, team restructuring, or major incidents
+
+**Evaluator's assessment:**
+- **/multisig-for-protocols/implementation-checklist** → Emergency Preparedness — **partial**
+  Met: Roles reviewed at least annually and after major incidents
+  Missed: Incident commander with designated backup; Subject matter experts for key domains; Scribe role for real-time documentation; Communications personnel for public info; Legal support procedures; Decision makers for high-stakes decisions
+- **/multisig-for-protocols/emergency-procedures** → Emergency Communication Protocols — **partial**
+  Met: Roles reviewed after major incidents (implicit in post-incident analysis)
+  Missed: Incident commander with designated backup; Subject matter experts for key domains; Scribe role for real-time documentation; Communications personnel designation; Legal support procedures; Decision makers for high-stakes decisions; Annual review of roles and authorities
+**Gaps:** Incident commander (with designated backup) who coordinates response, assigns tasks, and makes time-sensitive decisions; Subject matter experts identified for key domains (smart contracts, infrastructure, security) who can analyze attacks and prepare response strategies; Scribe role defined for real-time incident documentation; Communications personnel designated for public information sharing and record-keeping; Legal support available with procedures for reviewing response actions, whitehat engagement, and public communications; Decision makers defined for high-stakes decisions (system shutdown, public disclosure, fund recovery)
+
+### ir-1.1.2: Stakeholder Coordination and Contacts
+**Full baselines:**
+  1. Internal coordination procedures between technical (devs, auditors) and operational teams (security council, communications)
+  2. External protocol contacts for protocols you depend on and protocols that depend on you
+  3. External expertise contacts including forensics firms, security consultants, SEAL 911, and auditors
+  4. Legal counsel and communications/PR contacts
+  5. Infrastructure vendor support contacts and escalation procedures
+  6. Contact list reviewed at least quarterly and after team changes
+  7. Escalation order documented for P1 incidents (e.g., SEAL 911 → decision makers → security partners → legal)
+
+**Evaluator's assessment:**
+- **/multisig-for-protocols/emergency-procedures** → Emergency Contact Information — **partial**
+  Met: External expertise contacts (Security team mentioned); Escalation order documented (template includes escalation to Security team)
+  Missed: Internal coordination procedures between technical and operational teams; External protocol contacts for dependencies; Legal counsel and PR contacts; Infrastructure vendor support contacts; Contact list reviewed quarterly
+- **/incident-management/playbooks/seal-911-war-room-guidelines** → Key Roles — **partial**
+  Met: Internal coordination procedures (role assignments for Operations, Protocol Lead, Web/Infrastructure Lead, External Communicator); External expertise contacts (SEAL 911, security researchers); Escalation order (implicit in role structure)
+  Missed: External protocol contacts for dependencies; Legal counsel and PR contacts (communications mentioned but not specific contacts); Infrastructure vendor support contacts; Contact list reviewed quarterly
+- **/wallet-security/secure-multisig-best-practices** → Communication & Documentation — **partial**
+  Met: Internal coordination (signers must notify multisig participants of incidents)
+  Missed: External protocol contacts; External expertise contacts; Legal counsel and PR contacts; Infrastructure vendor contacts; Contact list reviewed quarterly; Escalation order for P1 incidents
+**Gaps:** External protocol contacts for protocols you depend on and protocols that depend on you; Legal counsel and communications/PR contacts with specific documented procedures; Infrastructure vendor support contacts and escalation procedures; Contact list reviewed at least quarterly and after team changes
+
+### ir-2.1.1: Monitoring Coverage
+**Full baselines:**
+  1. Monitoring covers critical smart contracts, infrastructure, and on-chain activity
+  2. 24/7 monitoring capabilities with procedures for after-hours alert handling
+  3. Credential and secret exposure detection including dark web monitoring, breach database scanning, and secret scanning in code repositories
+  4. Organizational account monitoring including social media accounts and websites monitored for unauthorized access or compromise
+  5. Monitoring coverage documented — what's covered, what's not, and known gaps
+
+**Evaluator's assessment:**
+- **/infrastructure/domain-and-dns-security/monitoring-and-alerting** → DNS Record Monitoring — **partial**
+  Met: Monitoring coverage for critical systems (DNS/domain infrastructure); Credential exposure detection (mentioned in Certificate Transparency monitoring); Organizational account monitoring (domain/DNS as critical organizational asset); Monitoring coverage documented (what to watch for is documented)
+  Missed: 24/7 monitoring with after-hours procedures; Credential and secret exposure in code repositories and dark web
+- **/monitoring/guidelines** → Best Practices — **partial**
+  Met: Monitoring objectives defined (critical metrics); Monitoring coverage documented (define what to monitor)
+  Missed: 24/7 monitoring capabilities with after-hours procedures; Credential and secret exposure detection; Organizational account monitoring; Known gaps documented
+**Gaps:** 24/7 monitoring capabilities with procedures for after-hours alert handling; Credential and secret exposure detection including dark web monitoring, breach database scanning, and secret scanning in code repositories; Organizational account monitoring including social media accounts and websites monitored for unauthorized access or compromise
+
+### ir-2.1.2: Alerting, Paging, and Escalation
+**Full baselines:**
+  1. Automated alerting configured for security events and operational issues
+  2. Alerts include embedded triage guidance for distinguishing true incidents from false positives
+  3. Triage and classification procedures documented with escalation paths based on severity
+  4. Time-based escalation triggers if initial responder doesn't acknowledge within defined window
+  5. Management notification requirements for high-severity incidents
+  6. Redundant paging systems with documented failover procedures
+  7. On-call schedules maintained with adequate coverage for operational needs
+  8. Backup procedures when on-call personnel are unreachable
+
+**Evaluator's assessment:**
+- **/multisig-for-protocols/emergency-procedures** → Immediate Actions — **partial**
+  Met: Triage and classification procedures (assess scope, escalate); Management notification for high-severity (contact Security team); Escalation paths (Emergency notification template with escalation)
+  Missed: Automated alerting configured; Alerts include embedded triage guidance; Time-based escalation triggers; Redundant paging systems; On-call schedules maintained; Backup procedures when on-call unreachable
+**Gaps:** Automated alerting configured for security events and operational issues; Alerts include embedded triage guidance for distinguishing true incidents from false positives; Time-based escalation triggers if initial responder doesn't acknowledge within defined window; Redundant paging systems with documented failover procedures; On-call schedules maintained with adequate coverage for operational needs; Backup procedures when on-call personnel are unreachable
+
+### ir-3.1.1: Response Playbooks
+**Full baselines:**
+  1. Playbooks cover key scenarios including protocol exploits, infrastructure failures, access control breaches, key compromise, supply chain compromises, and frontend/DNS compromise
+  2. Each playbook includes initial response actions covering containment, evidence preservation, and stakeholder notification
+  3. Role-specific responsibilities defined for each scenario (who does what — technical, comms, legal)
+  4. Escalation criteria documented for when to engage leadership, when to shut down systems, when to make public disclosure, and when to engage external assistance
+  5. Key compromise playbook includes procedures for rotating keys and replacing compromised signers, with threshold and access reviewed after any signer replacement
+
+**Evaluator's assessment:**
+- **/multisig-for-protocols/emergency-procedures** → Key Compromise — **partial**
+  Met: Playbooks cover key compromise scenario; Initial response actions (stop operations, notify, assess, escalate, document); Key compromise includes procedures for rotating keys; Role-specific responsibilities (First Reporter, team coordination)
+  Missed: Playbooks for protocol exploits, infrastructure failures, access control breaches, supply chain compromises, frontend/DNS compromise; Escalation criteria for leadership engagement, system shutdown, public disclosure, external assistance
+- **/wallet-security/secure-multisig-best-practices** → Signer rotation — **partial**
+  Met: Key compromise procedures (signer rotation when compromised); Threshold reviewed after signer replacement
+  Missed: Playbooks for protocol exploits, infrastructure failures, access control breaches, supply chain, frontend/DNS; Initial response actions for each scenario; Role-specific responsibilities; Escalation criteria documented
+**Gaps:** Playbooks cover protocol exploits, infrastructure failures, access control breaches, supply chain compromises, and frontend/DNS compromise; Each playbook includes containment, evidence preservation, and stakeholder notification; Escalation criteria documented for when to engage leadership, when to shut down systems, when to make public disclosure, and when to engage external assistance
+
+### ir-3.1.2: Signer Reachability and Coordination
+**Full baselines:**
+  1. Procedures for coordinating multisig operations during incidents, including cross-timezone signer availability
+  2. Signers integrated into on-call/paging systems
+  3. Escalation paths documented for when signers are unreachable
+  4. Tested quarterly
+
+**Evaluator's assessment:**
+- **/wallet-security/secure-multisig-best-practices** → Training & Drills — **partial**
+  Met: Procedures for emergency operations (drills mentioned); Tested quarterly (for emergency multisigs)
+  Missed: Cross-timezone signer availability procedures; Signers integrated into on-call/paging systems; Escalation paths when signers unreachable
+- **/multisig-for-protocols/setup-and-configuration**  — **partial**
+  Missed: Procedures for coordinating multisig operations during incidents; Cross-timezone signer availability; Signers integrated into on-call/paging; Escalation paths for unreachable signers; Tested quarterly
+**Gaps:** Procedures for coordinating multisig operations during incidents, including cross-timezone signer availability; Signers integrated into on-call/paging systems; Escalation paths documented for when signers are unreachable
+
+### ir-3.1.3: Emergency Transaction Readiness
+**Full baselines:**
+  1. Pre-signed or pre-prepared emergency transactions for critical protocol functions (pause, freeze, parameter changes) where feasible
+  2. Backup signing infrastructure available including alternate signing UI, backup RPC providers, and alternate block explorer
+  3. Emergency execution procedures documented (what to pause/freeze/modify and the process for doing so)
+
+**Evaluator's assessment:**
+- **/multisig-for-protocols/backup-signing-and-infrastructure** → UI Alternatives — **full**
+  Met: Backup signing infrastructure (Eternal Safe, Squads Public Client); Alternate signing UI (multiple UI options documented); Backup RPC providers (guidance provided); Alternate block explorer (Blockscout, explorer.solana.com, Solscan); Emergency execution procedures (documented how to use backup systems)
+  Missed: Pre-signed or pre-prepared emergency transactions
+- **/multisig-for-protocols/implementation-checklist** → Emergency Preparedness — **full**
+  Met: Backup signing infrastructure (downloaded backup UIs); Emergency execution procedures (understanding how to sign when primary UI is down)
+  Missed: Pre-signed or pre-prepared emergency transactions
+**Gaps:** Pre-signed or pre-prepared emergency transactions for critical protocol functions (pause, freeze, parameter changes) where feasible
+
+### ir-4.1.1: Incident Communication Channels
+**Full baselines:**
+  1. Dedicated incident communication channels with documented access controls and member lists
+  2. Multiple communication channels (primary and backup) on different platforms, with documented failover procedures
+  3. Procedures for rapidly creating incident-specific channels (war room) when needed
+  4. Secure communication procedures for sensitive incident information including need-to-know access and encrypted channels
+
+**Evaluator's assessment:**
+- **/multisig-for-protocols/implementation-checklist** → Documentation & Communication — **partial**
+  Met: Primary and backup communication channels (set up per Communication Setup); Multiple channels on different platforms (tested emergency notification)
+  Missed: Documented access controls and member lists; Documented failover procedures; Procedures for rapidly creating incident-specific channels; Secure communication procedures for sensitive information
+- **/multisig-for-protocols/emergency-procedures** → Emergency Communication Protocols — **partial**
+  Met: Multiple communication channels (primary, backup, emergency contacts); Secure communication procedures (need-to-know, secure channels); Procedures for identity verification during incidents
+  Missed: Documented access controls and member lists; Documented failover procedures; Procedures for rapidly creating war room channels
+**Gaps:** Dedicated incident communication channels with documented access controls and member lists; Documented failover procedures between primary and backup channels; Procedures for rapidly creating incident-specific channels (war room) when needed
+
+### ir-4.1.2: Internal Status Updates
+**Full baselines:**
+  1. Status update cadence defined by severity level
+  2. Format and distribution lists for internal stakeholders
+
+**Evaluator's assessment:**
+- **/incident-management/communication-strategies** → Best Practices — **full**
+  Met: Status update cadence defined (regular updates to stakeholders); Format and distribution for internal stakeholders (provide regular updates to employees)
+
+### ir-4.1.3: Public Communication and Information Management
+**Full baselines:**
+  1. Pre-approved communication templates for different incident types and severity levels
+  2. Procedures for coordinating communications with protocol users during and after incidents
+  3. Procedures for managing public information flow and correcting misinformation during active incidents
+  4. Designated communications approval flow before public statements are released
+
+**Evaluator's assessment:**
+- **/incident-management/playbooks/seal-911-war-room-guidelines** → Communications — **partial**
+  Met: Procedures for coordinating communications during and after incidents; Procedures for managing public information flow (monitoring social media); Designated approval flow (External Communicator role)
+  Missed: Pre-approved communication templates for different incident types and severity
+- **/multisig-for-protocols/emergency-procedures** → Emergency Notification Template — **partial**
+  Met: Pre-approved communication templates (emergency notification template provided)
+  Missed: Templates for different incident types and severity levels; Procedures for coordinating with protocol users during/after; Procedures for managing misinformation; Designated approval flow before public statements
+**Gaps:** Pre-approved communication templates for different incident types and severity levels (only one emergency template provided); Procedures for managing public information flow and correcting misinformation during active incidents
+
+### ir-5.1.1: IR Drills and Testing
+**Full baselines:**
+  1. Drills conducted at least annually
+  2. Drills cover different incident types across exercises (protocol exploit, infrastructure failure, key compromise, etc.)
+  3. Tests the full pipeline from monitoring through alerting, paging, triage, escalation, team coordination, containment, and recovery
+  4. Production alerting pipeline validated end-to-end from event detection through to responder notification and acknowledgment
+  5. Drill documentation includes date, scenario, participants, response times, gaps identified, and corrective actions
+  6. Corrective actions tracked to completion with owners and deadlines
+  7. Drill findings incorporated into playbook and procedure updates
+
+**Evaluator's assessment:**
+- **/multisig-for-protocols/emergency-procedures** → Emergency Drill Procedures — **partial**
+  Met: Drills conducted regularly (quarterly, bi-annually, annually); Tests full pipeline (notification, response time, process verification); Production alerting validated (notification test, response time measurement)
+  Missed: Drills cover different incident types across exercises; Drill documentation with gaps and corrective actions; Corrective actions tracked to completion; Findings incorporated into playbook updates
+- **/incident-management/playbooks/decentralized-ir** → Keep It Alive — **partial**
+  Met: Drills conducted regularly (quarterly red team drills); Findings incorporated into updates (iterate on framework during retrospective)
+  Missed: Tests full pipeline from monitoring through recovery; Production alerting validated end-to-end; Drill documentation with participants, response times, gaps; Corrective actions tracked to completion
+**Gaps:** Drills cover different incident types across exercises (protocol exploit, infrastructure failure, key compromise, etc.); Drill documentation includes date, scenario, participants, response times, gaps identified, and corrective actions; Corrective actions tracked to completion with owners and deadlines
+
+## FALSE-NEGATIVE CHECK (1 controls marked "no coverage")
+
+Verify these truly have no relevant framework page. If any page below partially covers them, note it.
+
+### ir-2.1.3: Logging Integrity and Retention
+**Baselines:** Log retention periods defined for security, infrastructure, and cloud provider logs; Retention adequate for forensic analysis (consider regulatory requirements and typical investigation timelines); Tamper-evident logging for security-relevant events including access logs, alerting system logs, and infrastructure logs (+2 more)
+
+---
+
+## FRAMEWORK PAGES (10 pages)
+
+### PAGE: /incident-management/communication-strategies
+
+# Communication Strategies
+
+
+
+
+Communication during an incident can be very hard, as people are often scrambling to fix the issue at hand. Nonetheless,
+from aa team member, outsider or observer's point of view, communication is very important to be able to understand
+what's happening, and it also provide some time to reflect and think about what is going on. With that said, providing
+information before confirming that it's accurate, can often be very negative and cause uncertainty. It is recommended to
+have a person designated for communication during an incident, and that updates are sent out on a fixed schedule, and
+it can often be that the update is that there is currently no new information available.
+
+## Best Practices
+
+1. Define and establish secure communication channels for incident response teams.
+Use [encrypted messaging apps](/encryption/communication-encryption)
+2. Appoint primary and backup spokespersons to handle internal and external communications during an incident.
+3. Develop pre-approved templates for incident notifications, updates, and press releases to ensure consistency and
+speed.
+4. Provide regular updates to all stakeholders, including employees, customers, partners, and regulatory authorities, to
+keep them informed of the situation and response efforts.
+5. Maintain clear communication within the incident response team to ensure that everyone is aware of their roles and
+responsibilities.
+6. Be transparent with external stakeholders about the incident, the impact, and the steps being taken to address it.
+Avoid speculation and provide factual information.
+
+---
+
+---
+
+### PAGE: /incident-management/playbooks/decentralized-ir
+
+# Decentralized Incident Response Framework (DeIRF)
+
+
+
+
+A lightweight, end-to-end scaffold for security teams that work without a single authority.
+Use it as a menu, not a mandate.
+
+## 1. Guiding Principles
+
+| Principle | What it means in practice |
+| ----------- | --------------------------- |
+| **Zero-trust by default** | Assume every identity, device, and network path is potentially hostile. |
+| **Shared responsibility** | Any responder can start an action if quorum rules are met. |
+| **Minimum viable process** | Fewer steps, fewer blockers, faster containment. |
+| **Open tooling** | Prefer transparent, auditable, community-maintained tools. |
+| **Identity plurality** | Accept multiple forms of strong identity proof. |
+| **Evidence first** | Collect before you change anything. |
+| **Continuous learning** | Retrospective after every incident and drill. |
+
+---
+
+## 2. Roles and Identities
+
+| Role | Key duties | Identity options (at least two) |
+| ------ | ----------- | ---------------------------------- |
+| **First Reporter** | Sounds the alarm and starts evidence capture. | GPG key, DID, or multisig wallet signature |
+| **Triage Lead** | Confirms severity, forms a swarm, assigns tasks. | FIDO2 passkey, GPG, signed Matrix handle |
+| **Comms Lead** | Handles community and regulator updates. | Company issued OIDC, Lens profile |
+| **Containment Lead** | Executes on chain actions or host isolation. | Multisig signer, SSH CA cert |
+| **Recorder** | Maintains the timeline in an immutable log. | GPG key, signed git commit |
+
+> **Tip**: Publish a public mapping of handles to real names and keep it in a tamper evident repo.
+
+---
+
+## 3. Preparation Checklist
+
+| Item | Why it matters | Suggested tools |
+| ------ | ---------------- | ----------------- |
+| Asset inventory (code, infra, keys) | You cannot protect what you do not know. | ConfigDB + IaC scans, Sheet/CSV |
+| Log pipeline with reliable clock | Forensic accuracy and ordering. | Vector + Loki or OpenSearch, Elasticsearch, RunReveal |
+| Secure comms channels | Quick swarm with strong auth. | Matrix + E2EE, Signal groups, Wire |
+| Evidence bucket (write-once) | Keeps raw data safe. | S3 object-lock, Storj, or IPFS |
+| Automated alert rules | Detect known bad patterns. | On chain monitors, Falco, OpenZeppelin Defender, Slackbot |
+| Drill schedule | Muscle memory beats panic. | Calendar invites, gamedays, CTF |
+
+---
+
+## 4. Detection and Triage Flow
+
+1. **Alert fires or user reports an issue.**
+2. **First Reporter** opens a ticket in the transparent issue tracker (GitHub security advisory or private GitLab
+issue).
+3. **Triage Lead** checks severity matrix.
+4. If **P1**, spin up a temporary incident channel with a predefined template.
+5. Assign Leads and set T-minus deadlines.
+
+| Pros | Cons |
+| ------ | ------ |
+| Fast and clear ownership | Relies on people in multiple time zones being awake |
+| Public log builds trust | Attackers also watch public data if over-shared |
+
+---
+
+## 5. Containment Options
+
+| Method | When to use | Pros | Cons |
+| -------- | ------------- | ------ | ------ |
+| **Smart contract pause / circuit breaker** | Critical on-chain bug | Stops further damage instantly | Requires a pre-coded pause function and multisig |
+| **Multisig treasury freeze** | Key compromise or theft | No central keyholder | Coordination overhead |
+| **Host or pod quarantine** | Off-chain infra breach | Isolates without full shutdown | Needs orchestration rights |
+| **DNS or CDN reroute** | Phishing or DDoS | Quick traffic shift | May break some services |
+
+Keep a one-liner command ready for each action and store it in the runbook.
+
+---
+
+## 6. Eradication and Recovery
+
+1. Patch or replace vulnerable code.
+2. Peer review with at least two signers.
+3. Deploy to staging with replay of attack scenario.
+4. Roll forward to production by multisig or automated pipeline.
+5. Verify by monitoring metrics and logs for stability.
+
+| Automation hint | Keep it simple |
+| ----------------- | ---------------- |
+| GitHub Actions, ArgoCD, and Defender Autotasks are popular. | Always include a manual approval gate in case of false positives. |
+
+---
+
+## 7. Post-Incident Actions
+
+| Step | Purpose | Tool Example |
+| ------ | --------- | ------------- |
+| **Retrospective within 72 h** | Capture lessons before they fade. | Miro board, Markdown doc in repo |
+| **Update runbooks and detection rules** | Prevent repeat events. | Docs-as-code PR |
+| **Reward community reporters** | Encourage transparency. | Bug bounty payouts, incentive model |
+| **Public disclosure** | Build long-term trust. | Blog post plus on-chain message |
+
+---
+
+## 8. Quick-Start Templates
+
+| Need | Template location |
+| ------ | ------------------- |
+| Incident channel message | /templates/incident-kickoff.md |
+| Retrospective form | /templates/retro-form.md |
+
+---
+
+## 9. Pros and Cons of Decentralized IR
+
+| Aspect | Pros | Cons |
+| -------- | ------ | ------ |
+| **No single point of failure** | Resilience if one keyholder is offline. | Slower consensus for urgent actions. |
+| **Community trust** | Transparent logs and multisig votes. | Public scrutiny can amplify panic. |
+| **Open tools** | Low cost, auditable, extensible. | Less vendor support, more DIY. |
+| **Identity plurality** | Flexibility for global teams. | Complex to manage revocation and role drift. |
+
+---
+
+## 10. Keep It Alive
+
+- Run quarterly red team drills.
+- Rotate secrets on a fixed cadence.
+- Review identity proofs every six months.
+- Measure mean time to detect and contain.
+- Iterate on this framework during each retrospective.
+
+> **Remember**: Simplicity plus strong fundamentals beat heavy processes every time.
+
+---
+
+---
+
+### PAGE: /incident-management/playbooks/seal-911-war-room-guidelines
+
+# SEAL 911
+
+
+
+
+SEAL 911 is a project designed to give users, developers, and even other security researchers an accessible method to
+contact a small group of highly trusted security researchers. The group can be reached via the [Telegram
+bot](https://t.me/seal_911_bot).
+
+Members of SEAL 911 follow a strict
+[CODE OF CONDUCT](https://github.com/security-alliance/seal-911/blob/main/CODE_OF_CONDUCT.md).
+
+When interacting with SEAL 911, ensure that you give as much information as possible in order to avoid double work by
+the security researchers.
+
+## Crisis Handbook - Smart Contract Hack | [Google Doc](https://docs.google.com/document/d/1DaAiuGFkMEMMiIuvqhePL5aDFGHJ9Ya6D04rdaldqC0/edit#heading=h.c4h2beeflqpo)
+
+### Actions Checklist
+
+### Perform Immediately
+
+- [ ] Notify SEAL 911 Bot of the incident. Use this message template to get started.
+- [ ] Create a War Room with audio and share the invite link with trusted individuals.
+- [ ] Duplicate this document to allow collaboration and share the link in the War Room.
+- [ ] Review the Advice to Keep in Mind section.
+
+### Perform in Parallel by Role
+
+1. **Assign Key Roles to War Room Members**:
+   - [ ] Assign members to specific roles.
+
+2. **Analysis**:
+   - [ ] Scope the impact of the attack.
+   - [ ] Gather Transactions Involved.
+   - [ ] Gather Affected Addresses.
+   - [ ] Record Funds Movement.
+   - [ ] Gather Attacker Information.
+   - [ ] Investigate the issue and update the Issue Description.
+   - [ ] Propose workable solutions.
+
+3. **Protocol actions**:
+   - [ ] Take immediate corrective/preventative actions to prevent further loss of funds.
+   - [ ] Pause contracts if possible.
+   - [ ] Execute pre-made defensive scripts.
+   - [ ] Prioritize proposed solutions.
+   - [ ] Validate and execute the solution.
+   - [ ] Prepare monitoring alerts for situations that require future actions.
+
+4. **Web actions**:
+   - [ ] Disable deposits and/or withdrawals as needed in the web UI.
+   - [ ] Enable front-end IP or Address blacklisting.
+   - [ ] Create front-end for any user actions necessary (approval revoking, fund migrating, etc.).
+
+5. **Communications**:
+   - [ ] Identify social platforms that communications on the incident must be sent to.
+   - [ ] Prepare messages for incident communication internally and externally.
+   - [ ] Gather security contacts for any potentially affected downstream protocols (bridges, lending protocols).
+   - [ ] Notify block explorers (like Etherscan) for attacker address labeling.
+   - [ ] Continuously monitor social media for users providing additional information that aids whitehat efforts.
+   - [ ] Monitor War Room efforts and maintain the Event Timeline.
+
+### After all of the above is complete, consider Post Incident Actions
+
+## Information Gathering
+
+Information will primarily be shared and acted upon in the War Room. As time allows, consolidate intel in the below
+section to achieve the following:
+
+- Accurately scope the incident impact.
+- Inform new War Room members and third parties efficiently.
+- Aid external communication.
+
+This is the chief duty of the Scribe.
+
+### Issue Description
+
+The issue involves an unauthorized transfer of funds from the protocol's treasury contract due to a vulnerability in the
+contract's access control mechanism. The attacker exploited this vulnerability to initiate multiple transfers,
+siphoning funds to an external wallet.
+
+### Events Timeline
+
+Record events to construct an overall timeline of the incident. Events worth recording:
+
+- First notice of the incident
+- War room creation
+- External communications
+- Attack transactions
+- Transactions performed by the team
+
+Record times in UTC. Use a UTC Time Converter.
+
+| Date-Time (UTC) | Event Description | Notes |
+| --- | --- | --- |
+| 2024-08-23 12:45 | First notice of the unauthorized transfer | Alert received via monitoring system |
+| 2024-08-23 12:50 | War room created | Initial members invited |
+| 2024-08-23 13:05 | Notified SEAL 911 Bot | Incident report submitted |
+| 2024-08-23 13:15 | Attack transaction identified | Transaction hash: 0x123456789abc |
+| 2024-08-23 13:20 | Contracts paused | Prevented further fund transfers |
+| 2024-08-23 13:30 | External communication initiated | First update sent via Twitter |
+
+### Transactions Involved
+
+Record all transactions related to the incident.
+
+| Transaction Link | Notes |
+| --- | --- |
+| [0x123456789abcdef...](https://etherscan.io/tx/0x123456789abcdef) | Initial exploit transaction |
+| [0xabcdef123456789...](https://etherscan.io/tx/0xabcdef123456789) | Attacker moving funds to mixer |
+| [0xfedcba987654321...](https://etherscan.io/tx/0xfedcba987654321) | Defensive move by the team |
+
+### Affected Addresses
+
+Record affected addresses related to the incident (protocol contracts, bridges, users, etc.).
+
+| Address Link | Status | Notes |
+| --- | --- | --- |
+| [0x1111222233334444...](https://etherscan.io/address/0x11112222) | At Risk | User wallet, interacted with exploit |
+| [0x5555666677778888...](https://etherscan.io/address/0x55556666) | Impacted | Protocol treasury address |
+| [0x99990000aaaabbbb...](https://etherscan.io/address/0x99990000) | Paused | Lending protocol contract |
+| [0xaaaabbbbccccdddd...](https://etherscan.io/address/0xaaaabbbb) | Saved | Bridge contract, funds secured |
+| [0xddddeeeeffff0000...](https://etherscan.io/address/0xddddeeee) | Needs Review | User wallet, unusual activity noted |
+| [0x2222333344445555...](https://etherscan.io/address/0x22223333) | Uncertain | User wallet, pending analysis |
+
+### Funds Movement
+
+Record funds movement to gather the impact of the incident and organize recovery efforts.
+
+- Original address that held the funds
+- Transaction that moved the funds
+- Assets and amounts the funds are comprised of
+- Destination the funds moved to (Contract, CEX, Bridge, Mixer)
+- Recovery Status of the funds
+
+Use Phalcon Tx Explorer to aid in recording funds movement.
+
+| Origin | Transaction Link | Amount / Asset | Destination | Recovery Status | Notes |
+| --- | --- | --- | --- | --- | --- |
+| [0x5555666677778888...](https://etherscan.io/address/0x5555) | [0xabcdef123456789...](https://etherscan.io/tx/0xabcdef) | 1000 ETH | [Mixer address](https://etherscan.io/address/0x12) | Needs Review | Funds moved to Tornado Cash |
+| [0x99990000aaaabbbb...](https://etherscan.io/address/0x9999) | [0x9876543210fedcba...](https://etherscan.io/tx/0x987654) | 500,000 DAI | [CEX address](https://etherscan.io/address/0x34) | In Progress | Funds transferred to centralized exchange |
+| [0xaaaabbbbccccdddd...](https://etherscan.io/address/0xaaaa) | [0x123456789abcdef...](https://etherscan.io/tx/0x123456) | 200 BTC | [Contract address](https://etherscan.io/address/0x56) | Recovered | Funds recovered via multisig |
+| [0xddddeeeeffff0000...](https://etherscan.io/address/0xdddd) | [0xfedcba987654321...](https://etherscan.io/tx/0xfedcba) | 50,000 USDC | [Bridge address](https://etherscan.io/address/0x78) | Uncertain | Funds possibly moved cross-chain |
+
+### Attacker Information
+
+Gather attacker information to aid legal efforts and fund recovery.
+
+| Address Link | Funded By | Notes |
+| --- | --- | --- |
+| [0xabcdefabcdefabcd...](https://etherscan.io/address/0xabcdefab) | Tornado Cash | Initial funding from Tornado Cash mixer |
+| [0x123456789abcdef...](https://etherscan.io/address/0x12345678) | CEX | Received funds from centralized exchange |
+| [0xfedcba987654321...](https://etherscan.io/address/0xfedcba98) | Unknown | No prior activity, potentially new wallet |
+
+## Post Incident Actions
+
+1. Confirm the incident has been resolved.
+2. Create monitoring alerts for situations requiring future actions.
+3. Prepare scripts to perform any actions related to monitoring events in the future.
+4. Consider creating additional defensive scripts (pause/upgrade) to use for future situations.
+5. Schedule a Post Mortem write-up.
+6. Post the write-up to relevant social media.
+
+## Appendix
+
+### Advice to Keep in Mind
+
+- Limit the War Room occupancy. Be careful not to invite too many people during the early stages. Sensitive information
+is being shared; be wary.
+- Make it clear to War Room members not to publicize information without the protocol’s consent.
+- Do not speak to the press/news/publications.
+
+### Key Roles
+
+- **Operations**: Initiates War Room, assigns roles, distributes tasks, herds multisig participants.
+  - *Person Responsible*
+- **Scribe**: Consolidates gathered information for efficiency in knowledge-sharing.
+  - *Person Responsible*
+- **Strategy Lead**: Prioritizes actions, considers trade-offs of decisions.
+  - *Person Responsible*
+- **Protocol Lead**: Responsible for smart-contract actions (pausing, upgrading, etc.).
+  - *Person Responsible*
+- **Web/Infrastructure Lead**: Responsible for updating the front-end, managing servers.
+  - *Person Responsible*
+- **External Communicator**: Social media and user communications.
+  - *Person Responsible*
+
+### Suggested Tools and Platforms
+
+| Name | Type | Notes |
+| --- | --- | --- |
+| Discord | Platform | A familiar platform for web3 collaboration. Spin up a server quickly using our [recommended template](https://discord.new/CkADqy5aWsAH). Tips: New users must be granted the `approved` role before they can view chats. Upon creation, grant yourself the `approved` role and share an invite link with trusted members. |
+| Telegram | Platform | A familiar platform for web3 collaboration. Tips: Upon New Group creation, enable chat history as visible to new members. To do this: Info -> Edit -> Chat History For New Members -> Visible |
+| Google Hangouts | Platform | |
+| Phalcon Tx Explorer | Tx Analysis | |
+| Openchain Trace Explorer | Tx Analysis | |
+| Tenderly Tx Explorer | Tx Analysis, Debugging | Some features require login. |
+| Tenderly Alerts | Monitoring | Monitor addresses, on-chain actions, etc. Requires login. |
+| MetaSleuth | Monitoring | Monitor fund movement. 50 address limit. Requires login (premium feature). |
+| Github / Gist | Code Sharing | Create a private repo or secret gists and share the link with War Room participants only. |
+| CodeShare | Code Sharing | Sessions expire after 24 hours. |
+| HackMD | Code Sharing | Private notes become published after ~48 hours. Be very careful with sensitive information! |
+
+### SEAL Message Template
+
+Fill out with relevant information and send to SEAL 911 Bot.
+
+```plaintext
+Protocol: [Protocol Name]
+Attack Tx(s): [Transaction Hash(es)]
+Funds at Risk: [Estimated Amount in USD or Token]
+
+[Brief Description of the incident]
+```
+
+---
+
+---
+
+### PAGE: /infrastructure/domain-and-dns-security/monitoring-and-alerting
+
+# Monitoring, Alerts, and Incident Response
+
+
+
+
+## DNS Record Monitoring
+
+DNS record monitoring involves continuously checking your domain's DNS records for unauthorized changes. Attackers often
+modify DNS records to redirect traffic to malicious servers while keeping your site partially functional.
+
+**What to watch for**:
+
+- **Nameserver (NS) record changes**: Attackers change your nameservers to point to their own DNS servers, giving them
+  complete control over all DNS records
+- **Sudden TTL drops**: Very low TTLs *can* indicate preparation for rapid DNS changes during an attack
+  - **Note**: Low TTL is common and legitimate with CDNs and auto-scaling contexts; Cloudflare "Auto" is often 300s
+  - **Context**: Cloudflare allows TTL 30-60s for [unproxied
+    records](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/); this is not inherently malicious
+  - **Monitor for**: *Unexpected* drops from higher values or drops combined with other suspicious activity
+- **CAA record removal or overrides**: Allows any Certificate Authority to issue certificates for your domain
+  - **Note**: Child zones override parent CAA records
+  - **Advanced monitoring**: Watch for parameters like `accounturi` and `validationmethods` which provide finer control
+    over certificate issuance
+- **DNSSEC disabled unexpectedly**: Removes cryptographic protection from DNS responses
+
+**If nameservers remain unchanged, also monitor**:
+
+- **A/AAAA record modifications**: IP address changes could redirect users to malicious sites
+- **MX record modifications**: Email server changes could intercept password reset emails
+- **TXT record changes**: Could affect email security (SPF/DMARC) or domain validation
+
+**Monitoring tools** (continuous change tracking):
+
+- [MXToolbox](https://mxtoolbox.com/) - Comprehensive DNS record monitoring and alerts
+- [HetrixTools](https://hetrixtools.com/) - Free DNS monitoring with email alerts
+- [SecurityTrails](https://securitytrails.com/) - Historical DNS data and change tracking
+
+**Analysis and debugging tools**:
+
+- [DNSViz](https://dnsviz.net/) - DNSSEC chain validation and debugging
+- [DNS Dumpster](https://dnsdumpster.com/) - DNS reconnaissance and record discovery
+
+**GitOps and zone control**:
+
+- [OctoDNS](https://github.com/octodns/octodns) - Infrastructure-as-code for DNS; manage zones via code with auditable,
+  reviewed changes through CI/CD
+- [DNSControl](https://github.com/StackExchange/dnscontrol) - Synchronize DNS across multiple providers; declarative
+  configuration with version control
+
+**Note**: If attackers change your NS records, they control everything. But attackers with DNS panel access might make
+subtle changes without touching NS records to avoid detection, which is why monitoring individual record types remains
+important.
+
+## Certificate Transparency Monitoring
+
+Certificate Transparency (CT) logs are public records of all SSL certificates issued by Certificate Authorities.
+Monitoring these logs helps detect unauthorized certificate issuance.
+
+**Why it matters**: Attackers sometimes obtain fake SSL certificates for legitimate domains to make phishing sites
+appear more credible. CT monitoring helps you detect these certificates before they're used in attacks.
+
+**Setup and tools**:
+
+- [crt.sh](https://crt.sh/) - Search and monitor CT logs for your domain
+- [Cert Spotter](https://sslmate.com/certspotter/) - Free CT monitoring with API access
+- Watch for wildcard certificates if you don't use them (could indicate broader compromise)
+
+## Passive DNS Monitoring
+
+Passive DNS monitoring tracks historical DNS resolution data across the internet, helping you detect brief changes that
+might be missed by periodic checks.
+
+**What it detects**:
+
+- **Brief record changes**: Attackers often make quick changes to avoid detection
+- **Geographic anomalies**: DNS records resolving to unexpected countries or regions
+- **Suspicious hosting provider changes**: Sudden switches to hosting providers known for malicious activity
+
+**Tools for passive DNS**:
+
+- [PassiveTotal (RiskIQ)](https://community.riskiq.com/) - Comprehensive passive DNS database
+- [Mnemonic Passive DNS](https://passivedns.mnemonic.no/) - Free passive DNS lookup
+- [SecurityTrails](https://securitytrails.com/) - Historical DNS and WHOIS data
+
+## Setting Up Alerts
+
+### Critical Alerts (Immediate Response Required)
+
+1. **Registrar Changed**
+
+   - **What it monitors**: Changes to your domain's registrar
+   - **Why it's critical**: Indicates potential domain hijacking or unauthorized transfer
+   - **Response**: Immediate verification and potential incident response activation
+
+2. **Nameserver Changed**
+
+   - **What it monitors**: Changes to nameserver records
+   - **Why it's critical**: Attackers often change nameservers to redirect traffic to malicious servers
+   - **Response**: Verify legitimacy, check if you initiated the change
+
+3. **DNSSEC Broken**
+
+   - **What it monitors**: DNSSEC validation failures or disabled DNSSEC
+   - **Why it's critical**: DNS responses can be tampered with, leading to man-in-the-middle attacks
+   - **Response**: Investigate signing issues, check for configuration changes
+
+4. **CAA Records Removed or Overridden**
+
+   - **What it monitors**: Removal of Certificate Authority Authorization records or child zone overrides
+   - **Why it's critical**: Allows any CA to issue certificates for your domain, enabling SSL certificate attacks
+   - **Response**: Restore CAA records immediately, investigate who removed them
+   - **Note**: Child zones override parent CAA; parameters like `accounturi` and `validationmethods` can provide finer control
+
+5. **Unexpected TTL Drops**
+
+   - **What it monitors**: Sudden TTL drops from higher values
+   - **Why it's important**: Can indicate preparation for rapid DNS changes (attack preparation)
+   - **Context**: Low TTL (30-300s) is normal for CDNs and auto-scaling; Cloudflare allows 30-60s for [unproxied records](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/)
+   - **Response**: Investigate *unexpected* drops or drops combined with other suspicious activity; verify if legitimate
+     infrastructure changes
+
+### High Priority Alerts (When NS Unchanged)
+
+1. **A Record Changed**
+
+   - **What it monitors**: IP redirects without NS changes
+   - **Why it's important**: Could redirect users to malicious servers
+   - **Response**: Verify the new IP address is legitimate and expected
+
+2. **MX Record Changed**
+
+   - **What it monitors**: Changes to mail server configurations
+   - **Why it's important**: Could intercept emails, including password reset messages
+   - **Response**: Verify mail server changes are authorized
+
+3. **DMARC Policy Weakened**
+
+   - **What it monitors**: Changes from "reject" to "quarantine" or "none"
+   - **Why it's important**: Weaker policies allow more spoofed emails to reach users
+   - **Response**: Investigate why policy was weakened, restore if unauthorized
+
+4. **Unexpected Certificate Issued**
+
+   - **What it monitors**: New SSL certificates issued for your domain
+   - **Why it's important**: Could indicate certificate-based attacks or unauthorized issuance
+   - **Response**: Verify the certificate was requested by your team, revoke if unauthorized
+
+## Incident Response Plan
+
+### Immediate Response
+
+1. **Verify the compromise** - Check DNS records via multiple resolvers
+2. **Access registrar account** - Attempt login, check for lockout
+3. **Contact registrar security team** - Use pre-documented emergency contacts
+4. **Document everything** - Screenshot all current settings
+
+### Containment
+
+1. **Invoke registry lock** if available
+2. **Update NS records** if you maintain access
+3. **Warn users** via social media/status page
+4. **Contact law enforcement** if significant theft occurred
+
+### Recovery
+
+1. **Regain control** through registrar security procedures
+2. **Audit all DNS records** against known-good baseline
+3. **Reset all credentials** for registrar and DNS hosting
+4. **Review access logs** to understand attack vector
+
+### Post-Incident
+
+1. **Conduct thorough investigation**
+2. **Update security measures** based on lessons learned
+3. **Consider legal action** if appropriate
+4. **Publish transparency report** to rebuild trust
+
+---
+
+---
+
+### PAGE: /monitoring/guidelines
+
+# Guidelines for On-Chain Monitoring
+
+
+
+
+Effective on-chain monitoring is complex, and involves setting up systems and processes to continuously observe
+blockchain activities and detect any anomalies.
+
+## Best Practices
+
+### Define Monitoring Objectives
+
+1. Determine the critical metrics to monitor, such as large fund transfers, token minting events, and changes in
+contract ownership.
+
+### Implement Monitoring Tools
+
+1. Use automated monitoring tools that can continuously track blockchain activities and generate alerts for anomalies.
+2. Supplement automated tools with periodic manual reviews.
+
+### Establish Alerting Mechanisms
+
+1. Set up real-time alerts to notify relevant project members of any suspicious activities or threshold breaches.
+2. Use multiple channels for alerts, such as email, SMS, and messaging apps where available, to ensure timely response.
+
+### Regular Reviews and Updates
+
+1. Conduct regular reviews of your monitoring systems to ensure they are functioning correctly and covering all
+necessary metrics.
+2. Regularly update thresholds and alert configurations to reflect your current needs.
+
+### Incident Response
+
+1. Develop and maintain an [incident response plan](/incident-management/overview) to handle alerts and anomalies as
+soon as possible.
+
+---
+
+---
+
+### PAGE: /multisig-for-protocols/backup-signing-and-infrastructure
+
+TagList,
+  AttributionList,
+  TagProvider,
+  TagFilter,
+  ContributeFooter,
+} from "../../../components";
+
+
+
+
+# Backup Signing & Infrastructure
+
+
+
+
+If the default interfaces for either Safe or Squads are down or suspected of being compromised, these alternatives
+enable continued critical signing operations. As a signer, you should familiarize yourself with these tools and practice
+signing transactions with your team.
+
+## UI Alternatives
+
+### EVM Networks
+
+**Eternal Safe - Decentralized fork of Safe\{Wallet\}**
+
+- GitHub: [https://github.com/eternalsafe/wallet](https://github.com/eternalsafe/wallet)
+- Hosted (IPFS): [https://eternalsafe.eth.limo](https://eternalsafe.eth.limo) (requires bring your own RPC)
+- Local: Can be downloaded and run locally
+
+Note: Local/alternative UIs may not be actively maintained. Treat them as emergency options and perform extra
+verification. Please DYOR.
+
+### Solana
+
+**Squads Public Client - Open source Squads V4 interface: **
+
+- GitHub: [https://github.com/Squads-Protocol/public-v4-client](https://github.com/Squads-Protocol/public-v4-client)
+- Features: Verifiable build, self-hostable with Docker, IPFS distribution
+- Local: Can be built and run locally
+
+### Mobile (Safe)
+
+**Safe Mobile Apps: **
+
+- GitHub: [https://github.com/safe-global/safe-wallet-monorepo/tree/dev/apps/mobile](https://github.com/safe-global/safe-wallet-monorepo/tree/dev/apps/mobile)
+- App Store: [https://apps.apple.com/us/app/safe-mobile/id6748754793](https://apps.apple.com/us/app/safe-mobile/id6748754793)
+- Play Store: [https://play.google.com/store/apps/details?id=global.safe.mobileapp](https://play.google.com/store/apps/details?id=global.safe.mobileapp)
+
+## RPC Backup Options
+
+### Basic guidance:
+
+- Multiple providers: Set up accounts with 2-3 different RPC services
+  - eg. Alchemy, Infura, Chainstack, Quicknode, Tenderly
+- Avoid correlation: Choose providers that don't share infrastructure, if that information is available
+- Private RPCs preferred: Public RPC URLs are typically not sufficient for reliable operation
+
+### Administrator responsibilities
+
+Ensure signer preparedness:
+
+- Provide access to offline UI tools listed above
+- Verify signers have practiced using backup interfaces
+- Test backup RPCs during non-emergency periods
+- Document procedures for switching to backup infrastructure
+
+## Block Explorer Backup Options
+
+### EVM Networks
+
+Etherscan provides the default block explorer for nearly all EVM chains. In the event that Etherscan is compromised or
+goes down, it is important to have backup options that can be used for monitoring and investigating transactions.
+
+**Blockscout - Open source Etherscan alternative: **
+
+- [https://www.blockscout.com/](https://www.blockscout.com/)
+- Available for all EVM networks
+- Can also be [self-hosted](https://github.com/blockscout/blockscout), although it requires significant time to run full
+  node and index
+
+More explorers: A broader list of network explorers is maintained here: [https://explorer.swiss-knife.xyz/](https://explorer.swiss-knife.xyz/)
+
+### Solana Networks
+
+Both explorer.solana.com and Solscan are reliable options for Solana transaction exploration and decoding.
+
+**explorer.solana.com** - [https://explorer.solana.com/](https://explorer.solana.com/)
+
+- Can be [self-hosted](https://github.com/solana-foundation/explorer) using open source code
+
+**Solscan** - [https://solscan.io/](https://solscan.io/)
+
+## Preparation
+
+**It is recommended to download dependencies ahead of time and store them in a secure location** so they are easily
+accessible during emergencies.
+
+## EVM Networks
+
+### Eternal Safe - Decentralized fork of Safe\{Wallet\}
+
+#### Access Options
+
+- **GitHub**: [https://github.com/eternalsafe/wallet](https://github.com/eternalsafe/wallet)
+- **Hosted (IPFS)**: [https://eternalsafe.eth.limo](https://eternalsafe.eth.limo) (requires bring your own RPC)
+- **Local**: Can be downloaded and run locally
+
+#### Setup
+
+1. Select network and enter an RPC URL
+   <div align="center">
+     <img
+       src="https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/eternal-safe-network-selection.png"
+       alt="Eternal Safe network selection"
+       style={{ height: "400px" }}
+     />
+     <p>
+       <em>
+         Eternal Safe network selection screen: choose your network and enter an
+         RPC URL
+       </em>
+     </p>
+   </div>
+2. Enter Safe address and load
+   ![Eternal Safe address entry](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/eternal-safe-address-entry.png)
+3. Eternal Safe will automatically detect Ether balances but not ERC20 tokens. They can be added manually
+   ![Eternal Safe token configuration](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/eternal-safe-token-configuration.png)
+
+#### Transaction Verification
+
+**Critical**: It is still essential to verify hashes and calldata from Eternal Safe. Follow the verification steps in
+[Safe Multisig: Step-by-Step Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification).
+
+#### Smart Link System
+
+Once a transaction has been signed by one signer, a **Smart Link** is created which can be forwarded to the next signer
+to add their signature. The transactions do not go to any centralized backend.
+
+**Example Smart Link:**
+
+```
+Please sign this Eternal Safe transaction for the Safe: base:0xA79C6968E3c75aE4eF388370d1f142720D498fEC.
+Current confirmations: 1 of 2.
+https://eternalsafe.eth.limo/transactions/tx/?safe=base:0xA79C6968E3c75aE4eF388370d1f142720D498fEC&tx=eyJzaWduYXR1cmVzIjp7ImRhdGFUeXBlIjoiTWFwIiwidmFsdWUiOltbIjB4NDBiYjMyZjA4NjJkMjI3ODEzYzg2ZmQ4M2E3YjNjOWRiOTA3NGUyYSIseyJzaWduZXIiOiIweDQwYkIzMkYwODYyRDIyNzgxM2M4NkZEODNBN0IzYzlkYjkwNzRFMkEiLCJkYXRhIjoiMHgwZDMxZTZjODIxZjBhMGZlM2M5NmNlZWY4ZDNhM2JhZmU3YmZmZTliODQ0ZWNkYzBkYWNmNzc0MzFkODQ0NjU4MTgwZjUwNmZlMjZiZjMzOTQwY2VhOTJiMzlhNDNjODRkMDRhNThiMGY1ODQ2NzhlNzE0YTllMWJkMzE0NTg5ZjFiIn1dXX0sImRhdGEiOnsiZGF0YSI6IjB4IiwiYmFzZUdhcyI6IjAiLCJnYXNQcmljZSI6IjAiLCJzYWZlVHhHYXMiOiIwIiwiZ2FzVG9rZW4iOiIweDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAiLCJub25jZSI6NCwicmVmdW5kUmVjZWl2ZXIiOiIweDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAiLCJ2YWx1ZSI6IjEwMDAwMDAwMDAwMDAwMDAiLCJ0byI6IjB4RTBiY2ZlNWUzMEFCYTBCNDZmMTNCMEMyNENiQzQ3MERDQTNlYjg2NSIsIm9wZXJhdGlvbiI6MH19
+```
+
+#### Execution
+
+Once all signatures are collected, execute the transaction. **Note**: Prior to execution you can manually simulate using
+Tenderly by entering the transaction data, but an automatic simulation link will not be available.
+
+## Solana
+
+### Squads Public Client - Open source Squads V4 interface
+
+#### Access Options
+
+- **GitHub**: [https://github.com/Squads-Protocol/public-v4-client](https://github.com/Squads-Protocol/public-v4-client)
+- **Hosted**: [https://backup.app.squads.so/](https://backup.app.squads.so/)
+- **Features**: Verifiable build, self-hostable with Docker, IPFS distribution
+- **Local**: Can be built and run locally
+
+#### Setup
+
+1. If running locally, follow setup instructions in [https://github.com/Squads-Protocol/public-v4-client](https://github.com/Squads-Protocol/public-v4-client)
+ and access via `http://localhost:8080`
+2. Enter RPC URL in settings
+   ![Squads RPC configuration](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/squads-rpc-configuration.png)
+3. Enter multisig address in the **lower** text box (Search for Multisig Config) and select the detected Multisig Config
+   ![Squads multisig selection](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/squads-multisig-selection.png)
+
+#### Transaction Operations
+
+1. Create, approve, or execute transactions. _Smart Links_ are not needed for Solana as all transactions are on chain
+   and accessible via the RPC without an API
+   ![Squads transaction interface](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/squads-transaction-interface.png)
+
+## Security Considerations
+
+### Enhanced Verification
+
+When using backup systems:
+
+- **Extra caution required**: Be more thorough with verification procedures
+- **Multiple verification methods**: Use additional tools to cross-check transaction details
+- **Team confirmation**: Verify with other signers before proceeding with critical transactions
+- **Documentation**: Record use of backup systems and any issues encountered
+
+### Risk Assessment
+
+- **Delay non-critical operations**: Consider postponing non-urgent transactions until primary systems recover
+- **Emergency operations only**: For critical emergency responses, proceed with enhanced verification
+- **Communication**: Keep team informed about system status and verification procedures
+
+## Testing and Preparation
+
+### Regular Practice
+
+- **Monthly testing**: Practice using backup interfaces during normal operations
+- **Team coordination**: Ensure all signers can operate backup systems
+- **Process documentation**: Update procedures based on practice sessions
+
+### Emergency Drills
+
+- **Simulated outages**: Practice coordinating with backup systems during drills
+- **Communication testing**: Verify backup communication channels work with backup UIs
+- **Time measurement**: Track how long backup system activation takes
+
+## Troubleshooting
+
+### Common Issues
+
+- **RPC connectivity**: Switch to alternative RPC providers if connection fails
+- **Transaction loading**: Refresh or try different network endpoints
+- **Signature verification**: Use multiple verification tools when in doubt
+
+### Support Resources
+
+- **GitHub documentation**: Refer to project documentation for technical issues
+- **Team assistance**: Coordinate with other signers for problem-solving
+- **Alternative tools**: Have multiple backup options available
+
+## Related Documents
+
+- [Safe Multisig: Step-by-Step
+Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification) - Verification procedures
+- [Emergency Procedures](/multisig-for-protocols/emergency-procedures) - General emergency response
+- [Communication Setup](/multisig-for-protocols/communication-setup) - Backup communication during outages
+
+---
+
+### PAGE: /multisig-for-protocols/emergency-procedures
+
+# Emergency Procedures
+
+
+
+
+When security incidents occur, quick and decisive action is critical. This page covers procedures for key compromise,
+lost access, and communication breaches.
+
+## Key Compromise
+
+### Immediate Actions (Within 30 Minutes)
+
+1. **Stop operations** - Halt all non-emergency transactions
+2. **Notify team** - Alert via all communication channels using emergency notification template
+3. **Assess scope** - Determine which keys may be compromised
+4. **Escalate** - Contact Security team immediately
+5. **Document** - Record timeline and details
+
+### Recovery Process
+
+1. **Isolate** - Quarantine potentially compromised devices
+2. **New hardware setup** - Set up fresh wallet with new seed following [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds)
+3. **Coordinate replacement** - Plan signer replacement transaction with team
+4. **Execute replacement** - Replace compromised signer on multisig, following steps for signer rotation in [Secure
+   Multisig Best Practices](/wallet-security/secure-multisig-best-practices)
+5. **Verify security** - Confirm new setup before resuming operations
+
+## Lost Key Access
+
+### Immediate Steps
+
+1. **Try backup device first** if available
+2. **Contact team immediately** via backup communication channels
+3. **Do not panic** - Lost access doesn't mean compromised keys
+4. **Document the situation** - Record what happened and when
+
+### Identity Verification Process
+
+Since you can't sign with your key, verify identity through alternative methods:
+
+- **Video call** with other signers
+- **Authentication** via verified social media account
+- **Other pre-arranged verification methods**
+
+### Replacement Coordination
+
+1. **Generate new hardware wallet** following standard setup procedures in [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds)
+2. **Verify new address** through identity verification process above
+3. **Coordinate timing** with other signers for replacement transaction
+4. **Execute replacement** once team confirms identity
+5. **Update documentation** with new signer information
+
+## Communication Account Compromise
+
+### If Telegram/Signal/Discord Gets Taken Over
+
+#### Immediate Actions
+
+1. **Assume all recent messages are suspect** - Don't trust recent communication
+2. **Use backup channels** to alert team about compromise
+3. **Change passwords** and enable additional security on compromised account
+
+#### Team Verification Process
+
+**For the compromised person:**
+
+- Use alternative contact methods (email, phone, other platforms)
+- Verify identity through video call or pre-arranged methods
+- Provide proof of the compromise (screenshots, platform confirmation)
+
+**For other team members:**
+
+- Verify all recent requests from compromised account
+- Cancel any pending transactions initiated via compromised communication
+- Require additional verification for any future requests until resolved
+
+#### Recovery Steps
+
+1. **Regain account control** through platform recovery processes
+2. **Enable maximum security** (2FA, security keys, session management)
+3. **Review recent message history** for unauthorized communications
+4. **Alert team** when account is secured and verified clean
+5. **Resume normal operations** only after team confirms account security
+
+## Emergency Notification Template
+
+Use this template for security incidents or key compromises:
+
+```
+Subject: [URGENT] Multisig Security Incident - [Multisig Name]
+
+Immediate details:
+- Multisig address: [ADDRESS]
+- Classification: [Impact Level / Operational Type]
+- Incident type: [Key Compromise / Communication Failure / System Issue]
+- Time of discovery: [TIMESTAMP]
+- Reporting signer: [NAME/HANDLE]
+
+Situation summary: [Brief description of what happened and current status]
+
+Immediate actions taken:
+□ Stopped non-emergency operations
+□ Isolated affected systems
+□ Notified team members
+□ [Other actions]
+
+Next steps required:
+□ Security team assessment
+□ Key rotation process
+□ Emergency transaction execution
+□ [Other actions]
+
+Current multisig status:
+- Available signers: [X/Y]
+- Communication status: [Operational/Compromised]
+- Operational capability: [Full/Limited/Suspended]
+```
+
+## Emergency Communication Protocols
+
+### Multi-Channel Notification
+
+- **Primary channel**: Alert via main communication channel
+- **Backup channels**: Simultaneously notify via backup platforms
+- **Emergency contacts**: Use emergency contact procedures if established
+
+### Identity Verification
+
+- **Code words**: Use pre-established verification phrases
+- **Multiple confirmations**: Verify through multiple channels
+- **Video verification**: Use video calls for critical confirmations
+
+### Information Sharing
+
+- **Need-to-know basis**: Share only essential information
+- **Secure channels only**: Use most secure available communication
+- **Documentation**: Record all emergency communications
+
+## Operational Emergency Procedures
+
+### For Emergency Response Multisigs
+
+#### Rapid Response Protocol
+
+1. **Immediate assessment** - Determine scope and urgency
+2. **Signer activation** - Contact threshold number of signers
+3. **Streamlined verification** - Use minimal verification appropriate for risk level
+4. **Execute response** - Implement emergency measures
+5. **Post-action review** - Document and assess response effectiveness
+
+#### 24/7 Availability
+
+- **Geographic distribution** - Ensure coverage across time zones
+- **Backup signers** - Have additional signers available for activation
+- **Communication redundancy** - Multiple ways to reach each signer
+
+### Emergency Drill Procedures
+
+#### Regular Testing Schedule
+
+- **Quarterly**: Communication system tests
+- **Bi-annually**: Emergency paging system tests
+- **Annually**: Full emergency simulation with all signers
+
+#### Drill Components
+
+1. **Notification test** - Verify all signers receive alerts
+2. **Response time measurement** - Track time to threshold signatures
+3. **Process verification** - Ensure procedures work under pressure
+4. **Documentation review** - Update procedures based on drill results
+
+## Recovery and Post-Incident
+
+### Immediate Recovery
+
+1. **Restore operations** - Resume normal operations once threat is mitigated
+2. **Monitor for issues** - Watch for any residual security concerns
+3. **Update security measures** - Implement additional controls if needed
+
+### Post-Incident Analysis
+
+1. **Root cause analysis** - Determine how incident occurred
+2. **Process improvement** - Update procedures to prevent recurrence
+3. **Team debriefing** - Gather lessons learned from all participants
+4. **Documentation updates** - Revise emergency procedures based on experience
+
+### Communication
+
+1. **Team notification** - Inform team when incident is resolved
+2. **Stakeholder updates** - Notify relevant parties as appropriate
+3. **Documentation** - Complete incident report for future reference
+
+## Emergency Contact Information
+
+### Security Team Contact
+
+- **Email**: [Security team email]
+- **Emergency escalation**: [24/7 emergency contact if available]
+- **Communication**: Use subject line format from emergency notification template
+
+### Internal Escalation
+
+- **Protocol leadership**: [Contact information]
+- **Technical team**: [Emergency technical contact]
+- **Legal/compliance**: [If regulatory notification required]
+
+## Related Documents
+
+- [Incident Reporting](/multisig-for-protocols/incident-reporting) - Formal incident reporting procedures
+- [Communication Setup](/multisig-for-protocols/communication-setup) - Backup communication channels
+- [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds) - Device replacement procedures
+- [Seed Phrase Management](/wallet-security/seed-phrase-management) - Key recovery procedures
+- [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec) - Account security measures
+
+---
+
+### PAGE: /multisig-for-protocols/implementation-checklist
+
+# Implementation Checklist
+
+
+
+
+This checklist ensures all multisig participants have the knowledge and skills necessary for secure operations. Complete
+all applicable sections before beginning multisig operations.
+
+## For Multisig Administrators
+
+### Planning & Setup
+
+- [ ] I have classified my multisig using the impact and operational framework from [Planning & Classification](/multisig-for-protocols/planning-and-classification)
+- [ ] I have selected appropriate thresholds based on the classification guidance
+- [ ] I have identified and verified all signers for the multisig
+- [ ] I have deployed the multisig with correct configuration
+- [ ] I have set up required modules (eg. allowance module to rescue assets)
+
+### Documentation & Communication
+
+- [ ] I have classified and documented the new multisig using templates from [Registration & Documentation](/multisig-for-protocols/registration-and-documentation)
+- [ ] I have set up primary and backup communication channels per [Communication Setup](/multisig-for-protocols/communication-setup)
+- [ ] I have tested emergency notification procedures
+- [ ] I have documented emergency contact information
+
+### Ongoing Management
+
+- [ ] I have established procedures for regular reviews and updates per [Registration & Documentation](/multisig-for-protocols/registration-and-documentation)
+- [ ] I have set up backup infrastructure and tested alternative UIs per [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)
+- [ ] I have verified all signers have completed training requirements
+- [ ] I understand signer rotation procedures for my multisig type
+
+## For Signers
+
+### Hardware & Security Setup
+
+- [ ] I have purchased recommended hardware wallet from authorized source per [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds)
+- [ ] I have set up my hardware wallet with proper firmware and PIN
+- [ ] I have created and tested backup hardware wallet with same seed
+- [ ] I have stored my seed phrase securely using approved methods from [Seed Phrase Management](/wallet-security/seed-phrase-management)
+- [ ] I have created dedicated accounts for each multisig I'm signing for
+
+### Operational Readiness
+
+- [ ] I have joined multisig communication channels (primary and backup) per [Communication Setup](/multisig-for-protocols/communication-setup)
+- [ ] I have verified my signer address using the required signature process from [Joining a Multisig](/multisig-for-protocols/joining-a-multisig)
+- [ ] I understand my multisig's classification and response time requirements
+- [ ] I have completed a test transaction with the multisig team
+
+### Transaction Verification
+
+- [ ] I can use approved verification tools (Safe CLI Utils, OpenZeppelin SafeUtils for EVM) from [Tools & Resources →
+  Transaction Verification](/wallet-security/tools-&-resources#transaction-verification)
+- [ ] I understand how to verify transaction hashes before signing
+- [ ] I can decode and verify transaction details (amounts, recipients, contract calls)
+- [ ] I have practiced verifying both simple transfers and complex transactions
+
+### Emergency Preparedness
+
+- [ ] I have downloaded backup UIs (Eternal Safe for EVM, Squads public client for Solana) per [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)
+- [ ] I know how to sign transactions when primary UI is down per [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)
+- [ ] I understand emergency procedures for key compromise and communication failures per [Emergency Procedures](/multisig-for-protocols/emergency-procedures)
+- [ ] I have tested backup communication methods with my team
+- [ ] I know who to contact for security incidents and emergencies per [Incident Reporting](/multisig-for-protocols/incident-reporting)
+
+### Personal Security
+
+- [ ] I have enabled 2FA on all accounts with approved methods (YubiKey preferred) per [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec)
+- [ ] I use dedicated devices or accounts for multisig operations when required
+- [ ] I have implemented travel security procedures appropriate for my risk level
+- [ ] I understand incident reporting procedures for security concerns
+
+### Compliance
+
+- [ ] I have read and understand all sections of this security framework
+- [ ] I understand my specific role requirements based on multisig classification
+- [ ] I know how to properly offboard when leaving a multisig role per [Offboarding](/multisig-for-protocols/offboarding)
+- [ ] I commit to following these security procedures and reporting any deviations
+
+## Specialized Training by Use Case
+
+### Emergency Response Multisigs
+
+Additional requirements from [Use Case Specific Requirements](/multisig-for-protocols/use-case-specific-requirements):
+
+- [ ] I understand 24/7 availability requirements
+- [ ] I have participated in emergency simulation drills
+- [ ] I know how to respond to emergency paging
+- [ ] I understand streamlined verification procedures for emergencies
+
+### Treasury Multisigs
+
+- [ ] I understand allowance module configuration and purpose
+- [ ] I know governance rescue procedures
+- [ ] I understand financial reporting requirements
+
+### Smart Contract Control Multisigs
+
+- [ ] I understand timelock configuration per [Use Case Specific Requirements → Timelock Configuration](/multisig-for-protocols/use-case-specific-requirements#timelock-configuration)
+- [ ] I know how to verify staged transactions
+- [ ] I understand higher threshold requirements for upgrades
+
+## Practical Skills Assessment
+
+### Transaction Verification (EVM)
+
+- [ ] I can successfully verify a Safe transaction hash using CLI tools
+- [ ] I can decode transaction calldata and identify recipients and amounts
+- [ ] I can identify risky transaction types and warnings
+- [ ] I can verify nested Safe transactions if applicable
+
+### Transaction Verification (Solana)
+
+- [ ] I can analyze Solana transaction instruction data
+- [ ] I can convert hex values to decimal for amount verification
+- [ ] I can identify different transaction types (SOL transfer, token transfer, config changes)
+
+### Emergency Procedures
+
+- [ ] I can access backup UIs and complete a transaction
+- [ ] I can contact team via backup communication channels
+- [ ] I know how to report key compromise immediately
+- [ ] I can execute identity verification procedures if needed
+
+### Tool Proficiency
+
+- [ ] I am comfortable using my hardware wallet for signing
+- [ ] I can navigate backup block explorers
+- [ ] I can use alternative RPC endpoints
+- [ ] I understand how to manually simulate transactions
+
+## Documentation Review
+
+### Required Reading Completed
+
+- [ ] [Secure Multisig Best Practices](/wallet-security/secure-multisig-best-practices) - Core requirements for all multisigs
+- [ ] [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds) - Device security requirements
+- [ ] [Seed Phrase Management](/wallet-security/seed-phrase-management) - Key protection procedures
+- [ ] [Safe Multisig: Step-by-Step
+Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification) - Signing procedures
+- [ ] [Emergency Procedures](/multisig-for-protocols/emergency-procedures) - Crisis response protocols
+- [ ] [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec) - Account and device security
+
+### Role-Specific Documentation
+
+**For Administrators:**
+
+- [ ] [Planning & Classification](/multisig-for-protocols/planning-and-classification)
+- [ ] [Setup & Configuration](/multisig-for-protocols/setup-and-configuration)
+- [ ] [Registration & Documentation](/multisig-for-protocols/registration-and-documentation)
+- [ ] [Communication Setup](/multisig-for-protocols/communication-setup)
+- [ ] [Registration & Documentation](/multisig-for-protocols/registration-and-documentation)
+
+**For Specialized Use Cases:**
+
+- [ ] [Use Case Specific Requirements](/multisig-for-protocols/use-case-specific-requirements)
+- [ ] [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)
+- [ ] [Use Case Specific Requirements → Timelock Configuration](/multisig-for-protocols/use-case-specific-requirements#timelock-configuration)
+  (if applicable)
+
+## Certification and Acknowledgment
+
+### Training Completion
+
+- [ ] I have completed all applicable training requirements
+- [ ] I have successfully demonstrated practical skills
+- [ ] I understand the security implications of my role
+- [ ] I acknowledge my responsibilities as a multisig participant
+
+### Ongoing Commitment
+
+- [ ] I commit to following all security procedures outlined in this framework
+- [ ] I will report any security incidents or concerns promptly
+- [ ] I will participate in regular training updates and refreshers
+- [ ] I will maintain the required level of security for my role
+
+### Trainer Verification (if applicable)
+
+**For organizations requiring formal training:**
+
+Trainer: _________________ Date: _________________
+
+Trainee has demonstrated competency in:
+
+- [ ] Transaction verification procedures
+- [ ] Emergency response protocols
+- [ ] Security best practices
+- [ ] Role-specific requirements
+
+**Signature:** _________________
+
+## Refresher Training Schedule
+
+### Regular Updates
+
+- **Monthly**: Review emergency procedures and contact information
+- **Quarterly**: Practice backup system usage and emergency drills
+- **Annually**: Complete full framework review and updates
+- **As needed**: Training on new tools, procedures, or threats
+
+### Trigger Events
+
+Additional training required after:
+
+- Framework updates or changes
+- Security incidents affecting the team
+- New tool adoption
+- Role changes or additional responsibilities
+
+## Related Documents
+
+All documents in this framework serve as training materials. Refer to individual documents for detailed procedures and
+requirements specific to your role.
+
+---
+
+### PAGE: /multisig-for-protocols/setup-and-configuration
+
+# Setup & Configuration
+
+
+
+
+This page covers the technical deployment and configuration of multisigs on supported networks.
+
+## Basic Setup
+
+### EVM Networks (Ethereum, Base, etc.)
+
+1. Go to [https://app.safe.global](https://app.safe.global)
+2. Connect wallet of the deploying signer
+3. Create new Safe with your determined threshold and signer addresses
+4. **Multi-network deployment**: If deploying on multiple networks, Safe UI will offer to replicate the configuration
+
+### Solana
+
+1. Go to [https://squads.xyz/squads-multisig](https://squads.xyz/squads-multisig)
+2. Connect wallet of the deploying signer
+3. Create new multisig with your determined threshold and signer addresses
+
+## Self-Hosted Multisig UI
+
+Multi-sig coordination UIs should be self-hosted to eliminate supply chain risk. Hosted UI should be IP restricted to
+allow access only from signer machines.
+
+Deploy from [Safe Wallet Monorepo](https://github.com/safe-global/safe-wallet-monorepo/tree/dev/apps/web).
+While it should not be your final line of defense, securing the UI does protect your verification process
+from being compromised by supply-chain attacks.
+
+For emergency situations when the primary UI is unavailable, see
+[Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure).
+
+## Delegated Proposer
+
+It is recommended, but not required to authorize a separate transaction proposer for a Safe. This address can prepare
+transactions for signers to sign but is not an authorized signer on the Safe. Therefore **there is no risk of malicious
+signatures which can affect the Safe assets**. This wallet can hold no funds and simply act as a proposer. The primary
+reason to have a delegated proposer is that the hash verification utilities depend on the Safe API (unless details are
+entered manually). Until a transaction is **proposed** it does not show up in the API so the hash verification tools
+cannot detect it.
+
+![Delegated proposer configuration interface](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/delegated-proposer-configuration-interface.png)
+
+## Modules & Guards
+
+### Allowance Module (Required for Treasury Multisigs)
+
+If your multisig will hold any assets on behalf of the DAO, set up governance rescue capability:
+
+**Mainnet configuration:**
+
+- **Module**: Allowance Module
+- **Grant allowance to**: DAO Agent
+- **Amount**: Max value for each token held
+
+### Zodiac Delay Modifier (Time-Locks)
+
+Consider using [Zodiac Modifier Delay](https://github.com/gnosisguild/zodiac-modifier-delay/tree/main) or equivalent
+for implementing on-chain time-lock transaction delays to Safe wallets.
+
+See [Use Case Specific Requirements](/multisig-for-protocols/use-case-specific-requirements#timelock-configuration)
+for detailed timelock configuration guidance.
+
+### Other Modules
+
+Do not install any other modules or guards without explicit governance approval and security review.
+
+## Contract-Level Controls
+
+**Advanced Configuration Warning:** The following contract-level controls are advanced security features that can
+provide additional protection but require careful implementation. Before implementing any guards or modules:
+
+- **Conduct thorough research** on available guard implementations and their compatibility with your multisig setup
+- **Ensure all guards are well-audited** by reputable security firms before deployment
+- **Test extensively** on testnets to verify functionality and edge cases
+- **Understand the risks**: Incorrect configuration or incompatible guards can render your multisig unusable,
+potentially locking access to funds permanently
+
+### Address Whitelisting
+
+Approved smart contract and wallet addresses must be added to a whitelist that is enforced at the contract-level.
+Interactions with all other addresses should be denied and revert the transaction. Updating the whitelist should
+require an extra signer in addition to the standard transaction approval quorum.
+
+### Invariant Enforcement
+
+Design contracts to enforce invariants and expected state changes such as token balance changes, ownership and
+administration, and proxy implementation addresses. Ensure contracts automatically revert transactions if any
+invariant is violated.
+
+## Initial Testing
+
+### Verify Basic Functionality
+
+1. **Small test transaction**: Send a low-value token transfer (e.g., 1 USDS or equivalent)
+2. **All signers test**: Ensure each signer can successfully sign the test transaction
+3. **Confirm execution**: Verify the transaction executes as expected
+4. **Test communication**: Use your established channels to coordinate the test
+
+## Pre-Launch Checklist
+
+- [ ] Safe deployed with correct threshold
+- [ ] All signer addresses added and [verified](/multisig-for-protocols/registration-and-documentation#signer-verification-process)
+- [ ] Allowance module configured (if required)
+- [ ] Test transaction completed successfully
+- [ ] All signers confirmed they can sign
+- [ ] [Communication channels](/multisig-for-protocols/communication-setup) tested during transaction
+- [ ] Safe addresses documented for all networks
+
+### Practice on Testnet
+
+Before deploying on mainnet, thoroughly practice wallet creation, transaction signing, and owner management on
+a test network.
+
+Once setup is complete, proceed to [Registration &
+Documentation](/multisig-for-protocols/registration-and-documentation) for registration and documentation requirements.
+
+## Nested Safes
+
+A nested Safe is one in which a Safe is set as a signer on another Safe rather than an EOA. This can be useful on a
+case-by-case basis. For example, if a signer is an entity that might want to have multiple individual signers, the
+nested Safe could have a 1/X threshold allowing anyone authorized on the team to sign. However, this configuration
+allows the signers on the nested Safe to update the signer addresses without needing authorization from the main Safe.
+
+It is generally recommended **not** to use nested safe on protocol multisigs unless there is a specific use case that
+it enables.
+
+## Next Steps
+
+After completing setup:
+
+1. [Registration & Documentation](/multisig-for-protocols/registration-and-documentation) - Document your multisig
+2. [Communication Setup](/multisig-for-protocols/communication-setup) - Establish secure communication
+3. [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds) - Ensure all signers are properly configured
+
+## Active Monitoring
+
+Implement monitoring and alerting systems to be immediately notified of any on-chain activity related to the multisig,
+including proposed transactions, new signatures, and owner changes (e.g., using tools like [Safe
+Watcher](https://github.com/Gearbox-protocol/safe-watcher)).
+
+### Immutable Monitoring Channels
+
+Monitoring channels (e.g. email, Slack or Telegram chats) must be immutable (or trigger alerts when their configuration
+changes or logs are deleted/tampered with) and redundant such that an admin could not disable or tamper with one
+monitoring channel without generating an alert on the other channel.
+
+---
+
+### PAGE: /wallet-security/secure-multisig-best-practices
+
+# Secure Multisig Best Practices
+
+
+
+
+> Guidance for designing, operating, and auditing high-assurance multisigs. Use this as your single source for baseline
+> rules, setup guidance, and daily operations.
+
+## Who This Is For
+
+Advanced technical users, developers, Decentralized Autonomous Organizations (DAOs), and organizations responsible for
+managing protocol treasuries, smart contract ownership, or significant personal/collective assets.
+
+## Primary Goal
+
+The primary objective is to eliminate single points of failure and establish robust, distributed control over high-value
+assets and critical smart contract functions.
+
+## Core Concept: M-of-N Scheme
+
+A multisignature (multisig) wallet is a smart contract that requires a predefined minimum number of approvals `M` from a
+total set of authorized signers `N` to execute a transaction. This is known as an `M-of-N` scheme (e.g., 2-of-3,
+3-of-5).
+
+By distributing signing authority, a multisig ensures that the compromise of a single private key is insufficient to
+authorize the movement of funds or execute a privileged action.
+
+## General Rules
+
+### Thresholds & Configuration
+
+- Minimum of 3 signers
+- 50% signing threshold
+- 7+ signers for multisigs holding 1M+ in assets (USD equivalent)
+- Please see Classification Matrix in
+  [Planning & Classification](/multisig-for-protocols/planning-and-classification#step-3-classification-matrix)
+  for more information on threshold selection.
+- All signers must use hardware wallets
+- Multisigs managing assets on behalf of a DAO should set unlimited allowance with primary DAO agent
+- Signers on multisigs with critical protocol configuration or security roles are discouraged from using their
+addresses for other purposes. They should create a brand new wallet for that purpose instead.
+- All signing wallets should be monitored for any activity that is not directly related to multi-sig operations.
+- No multisigs should use modules/guards except those mentioned in
+[Setup & Configuration → Modules & Guards](/multisig-for-protocols/setup-and-configuration#modules--guards)
+unless clear justification and security review is provided
+- Threshold exceptions can be made for multisigs that are used in frequent operations but are highly constrained
+by smart contracts. For example, rate setting operations with tight bounds and a backup recovery mechanism to
+replace the multisig.
+
+#### Threshold Selection
+
+Avoid `N-of-N` schemes, as the loss of a single key would result in a permanent loss of access to all funds.
+
+#### Strategic Signer Distribution
+
+The security of a multisig depends entirely on the operational security (OpSec) of its individual signer keys. Storing
+multiple signer keys on the same device or in the same physical location negates the security benefits. Effective
+distribution strategies include:
+
+- Using different hardware wallet models and manufacturers.
+- Maintaining geographical separation for devices holding signer keys.
+- Assigning signer keys to different trusted individuals within an organization.
+- Using diverse client software to interact with the multisig to mitigate single-point-of-failure risks from a software
+vulnerability.
+
+#### Signer Composition Requirements
+
+- **Role Diversity**: Signers should be diverse individuals to reduce risk of multiple compromised accounts - a
+mix of executives, developers, and operational roles is recommended
+- **Technical Expertise**: Include a high number of competent, well-vetted technical signers that will understand full
+transaction details and effects in your signing quorum
+- **External Parties**: Multi-sigs managing high value wallets and contracts should have at least 1 additional required
+signer that is external to the organization (such as a security partner or trusted advisor)
+
+### Communication & Documentation
+
+- In the event of loss of access to keys or potential compromise of keys or communication channels, the signer must
+  immediately notify the other multisig participants and email your security contact - [Incident
+  Reporting](/multisig-for-protocols/incident-reporting)
+- Signers should use dedicated communication channels for multisig operations and maintain backup ways of reaching other
+  signers
+- All multisigs should be documented in the protocol documenting its purpose, general operating rules, multisig wallet
+  address, and list of signer addresses
+- Signers should verify their addresses by signing a message stating their affiliation and the multisig they intend to
+  join (entity affiliation is ok)
+
+#### Out-of-Band Verification for Admin Changes
+
+Any critical administrative action, such as adding or replacing a signer, must be verified through multiple, independent
+communication channels (e.g., a video call and a signed message) to prevent social engineering attacks.
+
+### Signer rotation
+
+- Signers can be rotated, but detailed documentation should be maintained
+- Any changes to signer composition should be documented in the protocol documentation
+- Any signer change should not reduce the number of signers or decrease the threshold unless clear justification is
+  given and documented
+
+#### Updating signer addresses
+
+If the original key is accessible:
+
+- The signer proves ownership of a new address by signing a message with their existing address.
+- The signer must follow the steps in
+[Signer Verification process](/multisig-for-protocols/registration-and-documentation#signer-verification-process)
+
+If the original key is lost:
+
+- The signer must verify their identity to the other signers through alternative methods such as:
+  - Authentication via a verified social media account.
+  - A video call with other signers for confirmation.
+  - Other sufficient methods.
+
+### Training & Drills
+
+- All signers should complete training as outlined in the
+[Implementation Checklist](/multisig-for-protocols/implementation-checklist)
+- For multisigs that perform emergency operations like pausing, teams should have processes to regularly conduct drills
+  to ensure operational readiness and signer availability
+
+## Setup Best Practices
+
+See General Rules above for thresholds and signer distribution guidance.
+
+- **Practice on Testnet:** Before deploying on mainnet, thoroughly practice wallet creation, transaction signing, and
+owner management on a test network.
+
+- **Timelocks:** Enforce a mandatory delay between the approval of a transaction and its execution. This provides a
+critical window for the community or team to detect and react to malicious proposals.
+
+- **Veto Quorum:** Establish a smaller veto group separate from the confirmation quorum to review and confirm
+transaction legitimacy. Organizations can establish veto quorums to bypass time-locks in case of emergency.
+The standard quorum plus two additional signers should be required to bypass.
+
+- **Role-Based Access Control (RBAC):** Implement modules that grant specific, limited permissions to certain addresses
+(e.g., a "pauser" or "executor" role) without making them full owners, adhering to the principle of least privilege.
+
+- **Disaster Recovery Plan:** Establish a clear, documented process for what to do when a signer is compromised, the
+multi-signature UI is down, or other emergencies arise. These should be done at regular intervals.
+
+## Operational Best Practices
+
+- **Signer Key Revocation and Replacement:** A  feature of multisigs is the ability to add, remove, or replace signer
+keys. If a signer's key is compromised or lost, it can be revoked and replaced with a new, secure key through a
+transaction approved by the remaining owners, preserving the integrity of the wallet's assets without needing to migrate
+funds.
+
+- **Secure Signing Environment:** For maximum security, all signing activities should be performed on a dedicated,
+air-gapped, or hardened device running a secure OS. Using a primary work laptop significantly increases the risk of
+malware interference.
+
+- **Independent Transaction Verification:**  Before signing, always verify the raw transaction data (target address,
+function call, parameters) to ensure it matches the intended operation.
+
+- **Out-of-Band Verification for Admin Changes:** Any critical administrative action, such as adding or replacing a
+signer, must be verified through multiple, independent communication channels (e.g., a video call and a signed message)
+to prevent social engineering attacks.
+
+- **Active Monitoring:** Implement monitoring and alerting systems to be immediately notified of any on-chain activity
+related to the multisig, including proposed transactions, new signatures, and owner changes (e.g., using tools like
+[Safe Watcher](https://github.com/Gearbox-protocol/safe-watcher) ).
+
+- **Documented Procedures:** Maintain clear, secure, and accessible documentation for all multisig procedures, including
+  transaction creation, signing, and emergency recovery plans.
+- **General Signing Guidelines:** Use hardware wallets, dedicated signing profiles, and re-verify before execution.
+  Require a "how to check" guide and communicate status after signing (e.g., "checked, signed, X more required"). Last
+  signer executes when applicable.
+
+## Contract-Level Security
+
+- **Invariant Enforcement:** Design contracts to enforce invariants and expected state changes such as token balance
+changes, ownership and administration, and proxy implementation addresses. Ensure contracts automatically revert
+transactions if any invariant is violated.
+
+- **Address Whitelisting:** Approved smart contract and wallet addresses must be added to a whitelist that is enforced
+at the contract-level. Interactions with all other addresses should be denied and revert the transaction. Updating the
+whitelist should require an extra signer in addition to the standard transaction approval quorum.
+
+For detailed configuration guidance, see
+[Setup & Configuration → Contract-Level Controls](/multisig-for-protocols/setup-and-configuration#contract-level-controls).
+
+## Acknowledgements
+
+Some ideas were borrowed from the [EF's multisig SOP notes](https://notes.ethereum.org/@fredrik/multisig-sop) and
+[Manifold Finance multisig best practices](https://hackmd.io/@manifoldx/multisig-best-practices).
+
+---
+
+---
+
diff --git a/scripts/data/qa-briefs/sfc-multisig-ops.md b/scripts/data/qa-briefs/sfc-multisig-ops.md
new file mode 100644
index 00000000..a26f8c0f
--- /dev/null
+++ b/scripts/data/qa-briefs/sfc-multisig-ops.md
@@ -0,0 +1,1958 @@
+# QA Brief: sfc-multisig-ops
+
+## YOUR TASK
+
+Verify the evaluation claims below. For each control with refs:
+1. Read the ACTUAL page content (provided below)
+2. Read the control's FULL baselines
+3. Check: does the page ACTUALLY meet the baselines claimed in "baselinesMet"?
+4. Check: are the "baselinesMissed" correct (is there content that was overlooked)?
+5. Check: is the coverage rating ("full"/"partial") justified?
+
+Be STRICT. If the evaluator was too generous, downgrade. If they missed coverage, upgrade.
+
+## EVALUATION CLAIMS TO VERIFY (22 controls with refs)
+
+### ms-1.1.1: Named Multisig Operations Owner
+**Full baselines:**
+  1. Accountability scope covers policy maintenance, signer onboarding/offboarding, documentation accuracy, periodic reviews, and incident escalation
+
+**Evaluator's assessment:**
+- **/multisig-for-protocols/implementation-checklist** → For Multisig Administrators — **partial**
+  Missed: Accountability scope covers policy maintenance, signer onboarding/offboarding, documentation accuracy, periodic reviews, and incident escalation
+**Gaps:** Accountability scope covers policy maintenance, signer onboarding/offboarding, documentation accuracy, periodic reviews, and incident escalation - NO page teaches organizations HOW to establish clear accountability with defined scope covering all these areas
+
+### ms-1.1.2: Multisig Registry and Documentation
+**Full baselines:**
+  1. Registry includes address, network, threshold, classification, purpose, signer addresses, controlled contracts, on-chain roles, and last review date
+  2. Updated within 24 hours for security-critical changes, 3 days for routine changes
+  3. Accessible to signers and key personnel
+
+**Evaluator's assessment:**
+- **/wallet-security/secure-multisig-best-practices** → Communication & Documentation — **partial**
+  Met: Registry includes address, network, threshold, classification, purpose, signer addresses, controlled contracts, on-chain roles, and last review date (mentions documentation of purpose, wallet address, signer addresses)
+  Missed: Updated within 24 hours for security-critical changes, 3 days for routine changes; Accessible to signers and key personnel
+- **/multisig-for-protocols/implementation-checklist** → Documentation & Communication — **partial**
+  Missed: Registry includes address, network, threshold, classification, purpose, signer addresses, controlled contracts, on-chain roles, and last review date; Updated within 24 hours for security-critical changes, 3 days for routine changes; Accessible to signers and key personnel
+**Gaps:** Updated within 24 hours for security-critical changes, 3 days for routine changes - NO page provides specific update timeline requirements; Accessible to signers and key personnel - NO page substantively teaches access control for registry; Complete registry structure with ALL required fields (network, classification, controlled contracts, on-chain roles, last review date) not fully taught
+
+### ms-2.1.1: Multisig Classification and Risk-Based Controls
+**Full baselines:**
+  1. Classification considers impact factors (financial exposure, protocol criticality, reputational risk) and operational needs (response time, coordination complexity)
+  2. Each classification maps to specific required controls (thresholds, quorum composition, review cadence)
+  3. All multisigs must have at least 3 distinct signers with a signing threshold of 50% or greater; N-of-N configurations should be avoided
+  4. Higher-risk classifications require stronger controls (more signers, higher thresholds)
+  5. Classifications reviewed every 6 months and after significant changes (TVL shifts, new products, protocol upgrades, security incidents)
+
+**Evaluator's assessment:**
+- **/multisig-for-protocols/planning-and-classification** → Classification Process — **full**
+  Met: Classification considers impact factors (financial exposure, protocol criticality, reputational risk) and operational needs (response time, coordination complexity); Each classification maps to specific required controls (thresholds, quorum composition, review cadence); Higher-risk classifications require stronger controls (more signers, higher thresholds); Classifications reviewed every 6 months and after significant changes (TVL shifts, new products, protocol upgrades, security incidents)
+  Missed: All multisigs must have at least 3 distinct signers with a signing threshold of 50% or greater; N-of-N configurations should be avoided
+- **/wallet-security/secure-multisig-best-practices** → Thresholds & Configuration — **full**
+  Met: All multisigs must have at least 3 distinct signers with a signing threshold of 50% or greater; N-of-N configurations should be avoided; Higher-risk classifications require stronger controls (more signers, higher thresholds)
+  Missed: Classification considers impact factors and operational needs in a formal framework; Each classification maps to specific required controls; Classifications reviewed every 6 months and after significant changes
+
+### ms-2.1.2: Contract-Level Security Controls
+**Full baselines:**
+  1. Evaluation covers timelocks, modules, guards, address whitelisting, invariant enforcement, and parameter bounds
+  2. Controls evaluated for each multisig based on classification
+  3. Security review required before enabling any module or guard
+  4. Decisions documented, including rationale for controls not implemented
+
+**Evaluator's assessment:**
+- **/multisig-for-protocols/setup-and-configuration** → Contract-Level Controls — **partial**
+  Met: Evaluation covers timelocks, modules, guards, address whitelisting, invariant enforcement, and parameter bounds; Security review required before enabling any module or guard
+  Missed: Controls evaluated for each multisig based on classification; Decisions documented, including rationale for controls not implemented
+- **/wallet-security/secure-multisig-best-practices** → Contract-Level Security — **partial**
+  Met: Evaluation covers timelocks, modules, guards, address whitelisting, invariant enforcement, and parameter bounds
+  Missed: Controls evaluated for each multisig based on classification; Security review required before enabling any module or guard; Decisions documented, including rationale for controls not implemented
+**Gaps:** Controls evaluated for each multisig based on classification - NO page teaches systematic evaluation process tied to classification levels; Decisions documented, including rationale for controls not implemented - NO page provides documentation requirements for control selection decisions
+
+### ms-2.1.4: Wallet Segregation
+**Full baselines:**
+  1. Segregation considers value, operational needs, and risk tolerance
+  2. Examples include hot/cold separation and treasury distribution across multiple wallets
+
+**Evaluator's assessment:**
+- **/wallet-security/secure-multisig-best-practices** → General Rules — **partial**
+  Missed: Segregation considers value, operational needs, and risk tolerance; Examples include hot/cold separation and treasury distribution across multiple wallets
+**Gaps:** Segregation considers value, operational needs, and risk tolerance - NO page substantively teaches HOW to determine segregation strategy; Examples include hot/cold separation and treasury distribution across multiple wallets - mentioned in context of travel security in /opsec/travel/guide but NOT as a multisig operational requirement
+
+### ms-3.1.1: Signer Address Verification
+**Full baselines:**
+  1. Verification process includes message signing with the signer address, verification via an independent tool, and documented proof of verification
+
+**Evaluator's assessment:**
+- **/wallet-security/secure-multisig-best-practices** → Communication & Documentation — **full**
+  Met: Verification process includes message signing with the signer address, verification via an independent tool, and documented proof of verification
+- **/multisig-for-protocols/setup-and-configuration** → Pre-Launch Checklist — **partial**
+  Missed: Verification process includes message signing with the signer address, verification via an independent tool, and documented proof of verification
+
+### ms-3.1.2: Signer Key Management Standards
+**Full baselines:**
+  1. Hardware wallets required for all multisig operations
+  2. Each signer uses a fresh, dedicated address per multisig, used exclusively for that multisig's operations
+
+**Evaluator's assessment:**
+- **/wallet-security/secure-multisig-best-practices** → Thresholds & Configuration — **full**
+  Met: Hardware wallets required for all multisig operations; Each signer uses a fresh, dedicated address per multisig, used exclusively for that multisig's operations
+
+### ms-3.1.3: Seed Phrase Backup and Protection
+**Full baselines:**
+  1. Seed phrases never stored digitally, in cloud storage, or photographed
+  2. Backups are geographically distributed (disaster resistant)
+  3. No single point of compromise (theft resistant)
+  4. Recoverable if one operator is unavailable (operator-loss resistant)
+
+**Evaluator's assessment:**
+- **/wallet-security/seed-phrase-management** → Secure Storage Practices — **full**
+  Met: Seed phrases never stored digitally, in cloud storage, or photographed; Backups are geographically distributed (disaster resistant); No single point of compromise (theft resistant); Recoverable if one operator is unavailable (operator-loss resistant)
+
+### ms-3.1.4: Signer Lifecycle Management
+**Full baselines:**
+  1. Offboarded signers removed within 48-72 hours (Emergency-class), 7 days (Critical-class), 14 days (others)
+  2. Access reviews quarterly, confirming each signer still controls their key
+
+**Evaluator's assessment:**
+- **/wallet-security/secure-multisig-best-practices** → Signer rotation — **partial**
+  Missed: Offboarded signers removed within 48-72 hours (Emergency-class), 7 days (Critical-class), 14 days (others); Access reviews quarterly, confirming each signer still controls their key
+**Gaps:** Offboarded signers removed within 48-72 hours (Emergency-class), 7 days (Critical-class), 14 days (others) - NO page provides specific timeline requirements by classification; Access reviews quarterly, confirming each signer still controls their key - NO page teaches quarterly access review process
+
+### ms-3.1.5: Signer Training and Assessment
+**Full baselines:**
+  1. Training covers transaction verification, emergency procedures, phishing and social engineering awareness
+  2. Practical skills assessment included
+  3. Annual refreshers; updates within 30 days of significant procedure changes
+
+**Evaluator's assessment:**
+- **/multisig-for-protocols/implementation-checklist** → For Signers — **full**
+  Met: Training covers transaction verification, emergency procedures, phishing and social engineering awareness; Practical skills assessment included
+  Missed: Annual refreshers; updates within 30 days of significant procedure changes
+**Gaps:** Annual refreshers; updates within 30 days of significant procedure changes - NO page specifies ongoing training cadence requirements
+
+### ms-3.1.6: Hardware Wallet Standards
+**Full baselines:**
+  1. Wallet capability requirements include adequate display, clear signing support, PIN security, and firmware integrity verification
+  2. Procurement through verified supply chains (direct from manufacturer or authorized resellers), with device authenticity verification
+
+**Evaluator's assessment:**
+- **/multisig-for-protocols/implementation-checklist** → Hardware & Security Setup — **full**
+  Met: Wallet capability requirements include adequate display, clear signing support, PIN security, and firmware integrity verification; Procurement through verified supply chains (direct from manufacturer or authorized resellers), with device authenticity verification
+
+### ms-3.1.7: Secure Signing Environment
+**Full baselines:**
+  1. Device security requirements documented and enforced
+  2. Dedicated signing devices or network isolation for high-value operations
+
+**Evaluator's assessment:**
+- **/multisig-for-protocols/personal-security-opsec** → Network Security — **full**
+  Met: Device security requirements documented and enforced; Dedicated signing devices or network isolation for high-value operations
+
+### ms-3.1.8: Signer Diversity
+**Full baselines:**
+  1. Diversity requirements scale with multisig classification
+
+**Evaluator's assessment:**
+- **/wallet-security/secure-multisig-best-practices** → Strategic Signer Distribution — **full**
+  Met: Diversity requirements scale with multisig classification (inferred from role diversity, geographical separation, external parties requirements)
+
+### ms-4.1.1: Transaction Handling Process
+**Full baselines:**
+  1. Process covers initiation, approval, simulation, execution, and confirmation
+  2. Defines who is authorized to initiate transactions
+  3. Each signer independently verifies transaction details (chain ID, target address, calldata, value, nonce, operation type) before signing
+  4. Transaction hashes compared across at least two independent interfaces (e.g., web UI and CLI, or web and mobile app)
+  5. DELEGATECALL operations to untrusted addresses flagged as high risk
+  6. High-risk transactions (large transfers, emergency actions, protocol changes) require waiting periods where feasible and elevated threshold approval
+  7. High-risk thresholds defined based on classification and reviewed periodically
+  8. Private transaction submission used when appropriate to prevent front-running or MEV extraction
+
+**Evaluator's assessment:**
+- **/wallet-security/signing-and-verification/secure-multisig-signing-process** → Phase 1: Signing the Off-Chain Message — **full**
+  Met: Process covers initiation, approval, simulation, execution, and confirmation; Each signer independently verifies transaction details (chain ID, target address, calldata, value, nonce, operation type) before signing; Transaction hashes compared across at least two independent interfaces; DELEGATECALL operations to untrusted addresses flagged as high risk
+  Missed: Defines who is authorized to initiate transactions; High-risk transactions require waiting periods where feasible and elevated threshold approval; High-risk thresholds defined based on classification and reviewed periodically; Private transaction submission used when appropriate to prevent front-running or MEV extraction
+- **/wallet-security/secure-multisig-best-practices** → Operational Best Practices — **partial**
+  Met: Each signer independently verifies transaction details before signing; Transaction simulation used before signing
+  Missed: Process covers initiation, approval, simulation, execution, and confirmation; Defines who is authorized to initiate transactions; Transaction hashes compared across at least two independent interfaces; DELEGATECALL operations flagged as high risk; High-risk transactions require waiting periods and elevated threshold approval; High-risk thresholds defined based on classification; Private transaction submission used when appropriate
+**Gaps:** Defines who is authorized to initiate transactions - NO page teaches authorization framework for transaction initiation; High-risk transactions require waiting periods where feasible and elevated threshold approval - mentioned timelocks in setup but not as operational requirement; High-risk thresholds defined based on classification and reviewed periodically - NO page teaches risk threshold definition process; Private transaction submission used when appropriate to prevent front-running or MEV extraction - NO page teaches when/how to use private RPCs for transaction submission
+
+### ms-4.1.3: Tool and Platform Evaluation
+**Full baselines:**
+  1. Evaluation considers whether tools are open source or audited by 2+ reputable firms, have no known critical unpatched vulnerabilities, and have established ecosystem adoption
+  2. Formal process for adopting new tools
+
+**Evaluator's assessment:**
+- **/multisig-for-protocols/implementation-checklist** → Transaction Verification — **partial**
+  Met: Evaluation considers whether tools are open source or audited by 2+ reputable firms (implied by tool recommendations)
+  Missed: Formal process for adopting new tools; Tools have no known critical unpatched vulnerabilities and have established ecosystem adoption
+**Gaps:** Formal process for adopting new tools - NO page teaches tool adoption approval process; Tools have no known critical unpatched vulnerabilities and have established ecosystem adoption - mentioned but not taught as evaluation criteria
+
+### ms-4.1.4: Backup Signing Infrastructure
+**Full baselines:**
+  1. Alternate signing UI
+  2. 2-3 backup RPC providers
+  3. Alternate block explorer
+
+**Evaluator's assessment:**
+- **/multisig-for-protocols/backup-signing-and-infrastructure** → UI Alternatives — **full**
+  Met: Alternate signing UI; 2-3 backup RPC providers; Alternate block explorer
+
+### ms-5.1.1: Secure Communication Procedures
+**Full baselines:**
+  1. Dedicated primary and backup channels on different platforms
+  2. End-to-end encryption, MFA required, invitation-based membership
+  3. Signer identity verified as standard procedure during signing operations (e.g., code words, video call, secondary authenticated channel)
+  4. Documented procedures for channel compromise including switching to backup channels and out-of-band verification
+  5. All signers trained on these procedures; compromise response tested annually
+
+**Evaluator's assessment:**
+- **/multisig-for-protocols/implementation-checklist** → Documentation & Communication — **partial**
+  Met: Dedicated primary and backup channels on different platforms; End-to-end encryption, MFA required, invitation-based membership
+  Missed: Signer identity verified as standard procedure during signing operations (e.g., code words, video call, secondary authenticated channel); Documented procedures for channel compromise including switching to backup channels and out-of-band verification; All signers trained on these procedures; compromise response tested annually
+- **/multisig-for-protocols/emergency-procedures** → Communication Account Compromise — **partial**
+  Met: Documented procedures for channel compromise including switching to backup channels and out-of-band verification
+  Missed: Dedicated primary and backup channels on different platforms; End-to-end encryption, MFA required, invitation-based membership; Signer identity verified as standard procedure during signing operations; All signers trained on these procedures; compromise response tested annually
+**Gaps:** Signer identity verified as standard procedure during signing operations (e.g., code words, video call, secondary authenticated channel) - mentioned in emergency procedures but NOT as standard operational procedure for ALL signing operations; All signers trained on these procedures; compromise response tested annually - NO page specifies annual testing requirement for communication compromise procedures
+
+### ms-5.1.2: Emergency Contact List
+**Full baselines:**
+  1. Includes protocol security team, external security resources, legal/compliance contacts, and backup contacts for signers
+  2. Personal emergency contacts for each signer (e.g., trusted family member, close colleague) for situations where the signer is unreachable through normal channels
+  3. Reviewed every 6 months
+
+**Evaluator's assessment:**
+- **/multisig-for-protocols/implementation-checklist** → Documentation & Communication — **partial**
+  Missed: Includes protocol security team, external security resources, legal/compliance contacts, and backup contacts for signers; Personal emergency contacts for each signer (e.g., trusted family member, close colleague) for situations where the signer is unreachable through normal channels; Reviewed every 6 months
+- **/multisig-for-protocols/emergency-procedures** → Emergency Contact Information — **partial**
+  Met: Includes protocol security team, external security resources, legal/compliance contacts, and backup contacts for signers
+  Missed: Personal emergency contacts for each signer; Reviewed every 6 months
+**Gaps:** Personal emergency contacts for each signer (e.g., trusted family member, close colleague) for situations where the signer is unreachable through normal channels - NO page teaches requirement for personal emergency contacts; Reviewed every 6 months - NO page specifies review cadence for emergency contact lists
+
+### ms-6.1.1: Emergency Playbooks
+**Full baselines:**
+  1. Scenarios covered include key compromise, lost access, communication channel compromise, and urgent protocol actions
+  2. Each scenario has procedures and escalation paths
+  3. Playbooks accessible through at least one backup method independent of the primary documentation platform
+
+**Evaluator's assessment:**
+- **/multisig-for-protocols/emergency-procedures** → Key Compromise — **full**
+  Met: Scenarios covered include key compromise, lost access, communication channel compromise, and urgent protocol actions; Each scenario has procedures and escalation paths; Playbooks accessible through at least one backup method independent of the primary documentation platform
+
+### ms-6.1.2: Signer Reachability and Escalation
+**Full baselines:**
+  1. Response times by classification - Emergency less than 2 hours, Time-Sensitive 2-12 hours, Routine 24-48 hours
+  2. Paging covers all signers including external parties
+  3. Tested quarterly
+  4. Escalation paths documented
+
+**Evaluator's assessment:**
+- **/multisig-for-protocols/planning-and-classification** → Step 2: Operational Assessment — **partial**
+  Met: Response times by classification - Emergency less than 2 hours, Time-Sensitive 2-12 hours, Routine 24-48 hours
+  Missed: Paging covers all signers including external parties; Tested quarterly; Escalation paths documented
+- **/multisig-for-protocols/emergency-procedures** → For Emergency Response Multisigs — **partial**
+  Met: Escalation paths documented
+  Missed: Response times by classification; Paging covers all signers including external parties; Tested quarterly
+**Gaps:** Paging covers all signers including external parties - NO page teaches establishment of paging system for all signers; Tested quarterly - NO page specifies quarterly testing requirement for reachability
+
+### ms-6.1.3: Multisig Monitoring and Alerts
+**Full baselines:**
+  1. Monitored events include signer/threshold changes, transfers exceeding thresholds, nonce gaps, interactions with unknown addresses, failed transactions, module/guard changes, and low submitter/proposer balances
+  2. Alerting and escalation paths documented
+  3. Monitoring infrastructure protected against tampering
+
+**Evaluator's assessment:**
+- **/wallet-security/secure-multisig-best-practices** → Operational Best Practices — **partial**
+  Met: Monitored events include signer/threshold changes, transfers exceeding thresholds, nonce gaps, interactions with unknown addresses, failed transactions, module/guard changes (partial list mentioned)
+  Missed: Alerting and escalation paths documented; Monitoring infrastructure protected against tampering
+- **/multisig-for-protocols/setup-and-configuration** → Active Monitoring — **partial**
+  Met: Monitored events include proposed transactions, new signatures, and owner changes (partial list)
+  Missed: Monitored events include transfers exceeding thresholds, nonce gaps, interactions with unknown addresses, failed transactions, module/guard changes, low submitter/proposer balances; Alerting and escalation paths documented; Monitoring infrastructure protected against tampering
+**Gaps:** Complete list of monitored events (transfers exceeding thresholds, nonce gaps, interactions with unknown addresses, failed transactions, module/guard changes, low submitter/proposer balances) - NO page provides comprehensive monitoring event list; Alerting and escalation paths documented - NO page teaches documentation of alert escalation; Monitoring infrastructure protected against tampering - NO page addresses monitoring system security
+
+### ms-6.1.4: Emergency Drills and Improvement
+**Full baselines:**
+  1. Annual minimum
+  2. After major procedure changes
+  3. Documentation includes date, participants, response times, issues identified, and improvements made
+
+**Evaluator's assessment:**
+- **/multisig-for-protocols/implementation-checklist** → Specialized Training by Use Case — **partial**
+  Met: Annual minimum (implied by emergency simulation drills requirement)
+  Missed: After major procedure changes; Documentation includes date, participants, response times, issues identified, and improvements made
+- **/multisig-for-protocols/emergency-procedures** → Emergency Drill Procedures — **full**
+  Met: Annual minimum (quarterly for some tests); After major procedure changes (implied); Documentation includes date, participants, response times, issues identified, and improvements made
+
+## FALSE-NEGATIVE CHECK (2 controls marked "no coverage")
+
+Verify these truly have no relevant framework page. If any page below partially covers them, note it.
+
+### ms-2.1.3: Exception Approval Process
+**Baselines:** Exceptions require documented justification, expiry date, compensating controls, and remediation plan; Critical-class exceptions require executive or security-lead approval
+
+### ms-4.1.2: Transaction Audit Trails
+**Baselines:** Retained for 3 years; Records include proposer, approvers, verification evidence, timestamps, and issues encountered
+
+---
+
+## FRAMEWORK PAGES (9 pages)
+
+### PAGE: /multisig-for-protocols/backup-signing-and-infrastructure
+
+TagList,
+  AttributionList,
+  TagProvider,
+  TagFilter,
+  ContributeFooter,
+} from "../../../components";
+
+
+
+
+# Backup Signing & Infrastructure
+
+
+
+
+If the default interfaces for either Safe or Squads are down or suspected of being compromised, these alternatives
+enable continued critical signing operations. As a signer, you should familiarize yourself with these tools and practice
+signing transactions with your team.
+
+## UI Alternatives
+
+### EVM Networks
+
+**Eternal Safe - Decentralized fork of Safe\{Wallet\}**
+
+- GitHub: [https://github.com/eternalsafe/wallet](https://github.com/eternalsafe/wallet)
+- Hosted (IPFS): [https://eternalsafe.eth.limo](https://eternalsafe.eth.limo) (requires bring your own RPC)
+- Local: Can be downloaded and run locally
+
+Note: Local/alternative UIs may not be actively maintained. Treat them as emergency options and perform extra
+verification. Please DYOR.
+
+### Solana
+
+**Squads Public Client - Open source Squads V4 interface: **
+
+- GitHub: [https://github.com/Squads-Protocol/public-v4-client](https://github.com/Squads-Protocol/public-v4-client)
+- Features: Verifiable build, self-hostable with Docker, IPFS distribution
+- Local: Can be built and run locally
+
+### Mobile (Safe)
+
+**Safe Mobile Apps: **
+
+- GitHub: [https://github.com/safe-global/safe-wallet-monorepo/tree/dev/apps/mobile](https://github.com/safe-global/safe-wallet-monorepo/tree/dev/apps/mobile)
+- App Store: [https://apps.apple.com/us/app/safe-mobile/id6748754793](https://apps.apple.com/us/app/safe-mobile/id6748754793)
+- Play Store: [https://play.google.com/store/apps/details?id=global.safe.mobileapp](https://play.google.com/store/apps/details?id=global.safe.mobileapp)
+
+## RPC Backup Options
+
+### Basic guidance:
+
+- Multiple providers: Set up accounts with 2-3 different RPC services
+  - eg. Alchemy, Infura, Chainstack, Quicknode, Tenderly
+- Avoid correlation: Choose providers that don't share infrastructure, if that information is available
+- Private RPCs preferred: Public RPC URLs are typically not sufficient for reliable operation
+
+### Administrator responsibilities
+
+Ensure signer preparedness:
+
+- Provide access to offline UI tools listed above
+- Verify signers have practiced using backup interfaces
+- Test backup RPCs during non-emergency periods
+- Document procedures for switching to backup infrastructure
+
+## Block Explorer Backup Options
+
+### EVM Networks
+
+Etherscan provides the default block explorer for nearly all EVM chains. In the event that Etherscan is compromised or
+goes down, it is important to have backup options that can be used for monitoring and investigating transactions.
+
+**Blockscout - Open source Etherscan alternative: **
+
+- [https://www.blockscout.com/](https://www.blockscout.com/)
+- Available for all EVM networks
+- Can also be [self-hosted](https://github.com/blockscout/blockscout), although it requires significant time to run full
+  node and index
+
+More explorers: A broader list of network explorers is maintained here: [https://explorer.swiss-knife.xyz/](https://explorer.swiss-knife.xyz/)
+
+### Solana Networks
+
+Both explorer.solana.com and Solscan are reliable options for Solana transaction exploration and decoding.
+
+**explorer.solana.com** - [https://explorer.solana.com/](https://explorer.solana.com/)
+
+- Can be [self-hosted](https://github.com/solana-foundation/explorer) using open source code
+
+**Solscan** - [https://solscan.io/](https://solscan.io/)
+
+## Preparation
+
+**It is recommended to download dependencies ahead of time and store them in a secure location** so they are easily
+accessible during emergencies.
+
+## EVM Networks
+
+### Eternal Safe - Decentralized fork of Safe\{Wallet\}
+
+#### Access Options
+
+- **GitHub**: [https://github.com/eternalsafe/wallet](https://github.com/eternalsafe/wallet)
+- **Hosted (IPFS)**: [https://eternalsafe.eth.limo](https://eternalsafe.eth.limo) (requires bring your own RPC)
+- **Local**: Can be downloaded and run locally
+
+#### Setup
+
+1. Select network and enter an RPC URL
+   <div align="center">
+     <img
+       src="https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/eternal-safe-network-selection.png"
+       alt="Eternal Safe network selection"
+       style={{ height: "400px" }}
+     />
+     <p>
+       <em>
+         Eternal Safe network selection screen: choose your network and enter an
+         RPC URL
+       </em>
+     </p>
+   </div>
+2. Enter Safe address and load
+   ![Eternal Safe address entry](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/eternal-safe-address-entry.png)
+3. Eternal Safe will automatically detect Ether balances but not ERC20 tokens. They can be added manually
+   ![Eternal Safe token configuration](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/eternal-safe-token-configuration.png)
+
+#### Transaction Verification
+
+**Critical**: It is still essential to verify hashes and calldata from Eternal Safe. Follow the verification steps in
+[Safe Multisig: Step-by-Step Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification).
+
+#### Smart Link System
+
+Once a transaction has been signed by one signer, a **Smart Link** is created which can be forwarded to the next signer
+to add their signature. The transactions do not go to any centralized backend.
+
+**Example Smart Link:**
+
+```
+Please sign this Eternal Safe transaction for the Safe: base:0xA79C6968E3c75aE4eF388370d1f142720D498fEC.
+Current confirmations: 1 of 2.
+https://eternalsafe.eth.limo/transactions/tx/?safe=base:0xA79C6968E3c75aE4eF388370d1f142720D498fEC&tx=eyJzaWduYXR1cmVzIjp7ImRhdGFUeXBlIjoiTWFwIiwidmFsdWUiOltbIjB4NDBiYjMyZjA4NjJkMjI3ODEzYzg2ZmQ4M2E3YjNjOWRiOTA3NGUyYSIseyJzaWduZXIiOiIweDQwYkIzMkYwODYyRDIyNzgxM2M4NkZEODNBN0IzYzlkYjkwNzRFMkEiLCJkYXRhIjoiMHgwZDMxZTZjODIxZjBhMGZlM2M5NmNlZWY4ZDNhM2JhZmU3YmZmZTliODQ0ZWNkYzBkYWNmNzc0MzFkODQ0NjU4MTgwZjUwNmZlMjZiZjMzOTQwY2VhOTJiMzlhNDNjODRkMDRhNThiMGY1ODQ2NzhlNzE0YTllMWJkMzE0NTg5ZjFiIn1dXX0sImRhdGEiOnsiZGF0YSI6IjB4IiwiYmFzZUdhcyI6IjAiLCJnYXNQcmljZSI6IjAiLCJzYWZlVHhHYXMiOiIwIiwiZ2FzVG9rZW4iOiIweDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAiLCJub25jZSI6NCwicmVmdW5kUmVjZWl2ZXIiOiIweDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAiLCJ2YWx1ZSI6IjEwMDAwMDAwMDAwMDAwMDAiLCJ0byI6IjB4RTBiY2ZlNWUzMEFCYTBCNDZmMTNCMEMyNENiQzQ3MERDQTNlYjg2NSIsIm9wZXJhdGlvbiI6MH19
+```
+
+#### Execution
+
+Once all signatures are collected, execute the transaction. **Note**: Prior to execution you can manually simulate using
+Tenderly by entering the transaction data, but an automatic simulation link will not be available.
+
+## Solana
+
+### Squads Public Client - Open source Squads V4 interface
+
+#### Access Options
+
+- **GitHub**: [https://github.com/Squads-Protocol/public-v4-client](https://github.com/Squads-Protocol/public-v4-client)
+- **Hosted**: [https://backup.app.squads.so/](https://backup.app.squads.so/)
+- **Features**: Verifiable build, self-hostable with Docker, IPFS distribution
+- **Local**: Can be built and run locally
+
+#### Setup
+
+1. If running locally, follow setup instructions in [https://github.com/Squads-Protocol/public-v4-client](https://github.com/Squads-Protocol/public-v4-client)
+ and access via `http://localhost:8080`
+2. Enter RPC URL in settings
+   ![Squads RPC configuration](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/squads-rpc-configuration.png)
+3. Enter multisig address in the **lower** text box (Search for Multisig Config) and select the detected Multisig Config
+   ![Squads multisig selection](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/squads-multisig-selection.png)
+
+#### Transaction Operations
+
+1. Create, approve, or execute transactions. _Smart Links_ are not needed for Solana as all transactions are on chain
+   and accessible via the RPC without an API
+   ![Squads transaction interface](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/squads-transaction-interface.png)
+
+## Security Considerations
+
+### Enhanced Verification
+
+When using backup systems:
+
+- **Extra caution required**: Be more thorough with verification procedures
+- **Multiple verification methods**: Use additional tools to cross-check transaction details
+- **Team confirmation**: Verify with other signers before proceeding with critical transactions
+- **Documentation**: Record use of backup systems and any issues encountered
+
+### Risk Assessment
+
+- **Delay non-critical operations**: Consider postponing non-urgent transactions until primary systems recover
+- **Emergency operations only**: For critical emergency responses, proceed with enhanced verification
+- **Communication**: Keep team informed about system status and verification procedures
+
+## Testing and Preparation
+
+### Regular Practice
+
+- **Monthly testing**: Practice using backup interfaces during normal operations
+- **Team coordination**: Ensure all signers can operate backup systems
+- **Process documentation**: Update procedures based on practice sessions
+
+### Emergency Drills
+
+- **Simulated outages**: Practice coordinating with backup systems during drills
+- **Communication testing**: Verify backup communication channels work with backup UIs
+- **Time measurement**: Track how long backup system activation takes
+
+## Troubleshooting
+
+### Common Issues
+
+- **RPC connectivity**: Switch to alternative RPC providers if connection fails
+- **Transaction loading**: Refresh or try different network endpoints
+- **Signature verification**: Use multiple verification tools when in doubt
+
+### Support Resources
+
+- **GitHub documentation**: Refer to project documentation for technical issues
+- **Team assistance**: Coordinate with other signers for problem-solving
+- **Alternative tools**: Have multiple backup options available
+
+## Related Documents
+
+- [Safe Multisig: Step-by-Step
+Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification) - Verification procedures
+- [Emergency Procedures](/multisig-for-protocols/emergency-procedures) - General emergency response
+- [Communication Setup](/multisig-for-protocols/communication-setup) - Backup communication during outages
+
+---
+
+### PAGE: /multisig-for-protocols/emergency-procedures
+
+# Emergency Procedures
+
+
+
+
+When security incidents occur, quick and decisive action is critical. This page covers procedures for key compromise,
+lost access, and communication breaches.
+
+## Key Compromise
+
+### Immediate Actions (Within 30 Minutes)
+
+1. **Stop operations** - Halt all non-emergency transactions
+2. **Notify team** - Alert via all communication channels using emergency notification template
+3. **Assess scope** - Determine which keys may be compromised
+4. **Escalate** - Contact Security team immediately
+5. **Document** - Record timeline and details
+
+### Recovery Process
+
+1. **Isolate** - Quarantine potentially compromised devices
+2. **New hardware setup** - Set up fresh wallet with new seed following [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds)
+3. **Coordinate replacement** - Plan signer replacement transaction with team
+4. **Execute replacement** - Replace compromised signer on multisig, following steps for signer rotation in [Secure
+   Multisig Best Practices](/wallet-security/secure-multisig-best-practices)
+5. **Verify security** - Confirm new setup before resuming operations
+
+## Lost Key Access
+
+### Immediate Steps
+
+1. **Try backup device first** if available
+2. **Contact team immediately** via backup communication channels
+3. **Do not panic** - Lost access doesn't mean compromised keys
+4. **Document the situation** - Record what happened and when
+
+### Identity Verification Process
+
+Since you can't sign with your key, verify identity through alternative methods:
+
+- **Video call** with other signers
+- **Authentication** via verified social media account
+- **Other pre-arranged verification methods**
+
+### Replacement Coordination
+
+1. **Generate new hardware wallet** following standard setup procedures in [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds)
+2. **Verify new address** through identity verification process above
+3. **Coordinate timing** with other signers for replacement transaction
+4. **Execute replacement** once team confirms identity
+5. **Update documentation** with new signer information
+
+## Communication Account Compromise
+
+### If Telegram/Signal/Discord Gets Taken Over
+
+#### Immediate Actions
+
+1. **Assume all recent messages are suspect** - Don't trust recent communication
+2. **Use backup channels** to alert team about compromise
+3. **Change passwords** and enable additional security on compromised account
+
+#### Team Verification Process
+
+**For the compromised person:**
+
+- Use alternative contact methods (email, phone, other platforms)
+- Verify identity through video call or pre-arranged methods
+- Provide proof of the compromise (screenshots, platform confirmation)
+
+**For other team members:**
+
+- Verify all recent requests from compromised account
+- Cancel any pending transactions initiated via compromised communication
+- Require additional verification for any future requests until resolved
+
+#### Recovery Steps
+
+1. **Regain account control** through platform recovery processes
+2. **Enable maximum security** (2FA, security keys, session management)
+3. **Review recent message history** for unauthorized communications
+4. **Alert team** when account is secured and verified clean
+5. **Resume normal operations** only after team confirms account security
+
+## Emergency Notification Template
+
+Use this template for security incidents or key compromises:
+
+```
+Subject: [URGENT] Multisig Security Incident - [Multisig Name]
+
+Immediate details:
+- Multisig address: [ADDRESS]
+- Classification: [Impact Level / Operational Type]
+- Incident type: [Key Compromise / Communication Failure / System Issue]
+- Time of discovery: [TIMESTAMP]
+- Reporting signer: [NAME/HANDLE]
+
+Situation summary: [Brief description of what happened and current status]
+
+Immediate actions taken:
+□ Stopped non-emergency operations
+□ Isolated affected systems
+□ Notified team members
+□ [Other actions]
+
+Next steps required:
+□ Security team assessment
+□ Key rotation process
+□ Emergency transaction execution
+□ [Other actions]
+
+Current multisig status:
+- Available signers: [X/Y]
+- Communication status: [Operational/Compromised]
+- Operational capability: [Full/Limited/Suspended]
+```
+
+## Emergency Communication Protocols
+
+### Multi-Channel Notification
+
+- **Primary channel**: Alert via main communication channel
+- **Backup channels**: Simultaneously notify via backup platforms
+- **Emergency contacts**: Use emergency contact procedures if established
+
+### Identity Verification
+
+- **Code words**: Use pre-established verification phrases
+- **Multiple confirmations**: Verify through multiple channels
+- **Video verification**: Use video calls for critical confirmations
+
+### Information Sharing
+
+- **Need-to-know basis**: Share only essential information
+- **Secure channels only**: Use most secure available communication
+- **Documentation**: Record all emergency communications
+
+## Operational Emergency Procedures
+
+### For Emergency Response Multisigs
+
+#### Rapid Response Protocol
+
+1. **Immediate assessment** - Determine scope and urgency
+2. **Signer activation** - Contact threshold number of signers
+3. **Streamlined verification** - Use minimal verification appropriate for risk level
+4. **Execute response** - Implement emergency measures
+5. **Post-action review** - Document and assess response effectiveness
+
+#### 24/7 Availability
+
+- **Geographic distribution** - Ensure coverage across time zones
+- **Backup signers** - Have additional signers available for activation
+- **Communication redundancy** - Multiple ways to reach each signer
+
+### Emergency Drill Procedures
+
+#### Regular Testing Schedule
+
+- **Quarterly**: Communication system tests
+- **Bi-annually**: Emergency paging system tests
+- **Annually**: Full emergency simulation with all signers
+
+#### Drill Components
+
+1. **Notification test** - Verify all signers receive alerts
+2. **Response time measurement** - Track time to threshold signatures
+3. **Process verification** - Ensure procedures work under pressure
+4. **Documentation review** - Update procedures based on drill results
+
+## Recovery and Post-Incident
+
+### Immediate Recovery
+
+1. **Restore operations** - Resume normal operations once threat is mitigated
+2. **Monitor for issues** - Watch for any residual security concerns
+3. **Update security measures** - Implement additional controls if needed
+
+### Post-Incident Analysis
+
+1. **Root cause analysis** - Determine how incident occurred
+2. **Process improvement** - Update procedures to prevent recurrence
+3. **Team debriefing** - Gather lessons learned from all participants
+4. **Documentation updates** - Revise emergency procedures based on experience
+
+### Communication
+
+1. **Team notification** - Inform team when incident is resolved
+2. **Stakeholder updates** - Notify relevant parties as appropriate
+3. **Documentation** - Complete incident report for future reference
+
+## Emergency Contact Information
+
+### Security Team Contact
+
+- **Email**: [Security team email]
+- **Emergency escalation**: [24/7 emergency contact if available]
+- **Communication**: Use subject line format from emergency notification template
+
+### Internal Escalation
+
+- **Protocol leadership**: [Contact information]
+- **Technical team**: [Emergency technical contact]
+- **Legal/compliance**: [If regulatory notification required]
+
+## Related Documents
+
+- [Incident Reporting](/multisig-for-protocols/incident-reporting) - Formal incident reporting procedures
+- [Communication Setup](/multisig-for-protocols/communication-setup) - Backup communication channels
+- [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds) - Device replacement procedures
+- [Seed Phrase Management](/wallet-security/seed-phrase-management) - Key recovery procedures
+- [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec) - Account security measures
+
+---
+
+### PAGE: /multisig-for-protocols/implementation-checklist
+
+# Implementation Checklist
+
+
+
+
+This checklist ensures all multisig participants have the knowledge and skills necessary for secure operations. Complete
+all applicable sections before beginning multisig operations.
+
+## For Multisig Administrators
+
+### Planning & Setup
+
+- [ ] I have classified my multisig using the impact and operational framework from [Planning & Classification](/multisig-for-protocols/planning-and-classification)
+- [ ] I have selected appropriate thresholds based on the classification guidance
+- [ ] I have identified and verified all signers for the multisig
+- [ ] I have deployed the multisig with correct configuration
+- [ ] I have set up required modules (eg. allowance module to rescue assets)
+
+### Documentation & Communication
+
+- [ ] I have classified and documented the new multisig using templates from [Registration & Documentation](/multisig-for-protocols/registration-and-documentation)
+- [ ] I have set up primary and backup communication channels per [Communication Setup](/multisig-for-protocols/communication-setup)
+- [ ] I have tested emergency notification procedures
+- [ ] I have documented emergency contact information
+
+### Ongoing Management
+
+- [ ] I have established procedures for regular reviews and updates per [Registration & Documentation](/multisig-for-protocols/registration-and-documentation)
+- [ ] I have set up backup infrastructure and tested alternative UIs per [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)
+- [ ] I have verified all signers have completed training requirements
+- [ ] I understand signer rotation procedures for my multisig type
+
+## For Signers
+
+### Hardware & Security Setup
+
+- [ ] I have purchased recommended hardware wallet from authorized source per [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds)
+- [ ] I have set up my hardware wallet with proper firmware and PIN
+- [ ] I have created and tested backup hardware wallet with same seed
+- [ ] I have stored my seed phrase securely using approved methods from [Seed Phrase Management](/wallet-security/seed-phrase-management)
+- [ ] I have created dedicated accounts for each multisig I'm signing for
+
+### Operational Readiness
+
+- [ ] I have joined multisig communication channels (primary and backup) per [Communication Setup](/multisig-for-protocols/communication-setup)
+- [ ] I have verified my signer address using the required signature process from [Joining a Multisig](/multisig-for-protocols/joining-a-multisig)
+- [ ] I understand my multisig's classification and response time requirements
+- [ ] I have completed a test transaction with the multisig team
+
+### Transaction Verification
+
+- [ ] I can use approved verification tools (Safe CLI Utils, OpenZeppelin SafeUtils for EVM) from [Tools & Resources →
+  Transaction Verification](/wallet-security/tools-&-resources#transaction-verification)
+- [ ] I understand how to verify transaction hashes before signing
+- [ ] I can decode and verify transaction details (amounts, recipients, contract calls)
+- [ ] I have practiced verifying both simple transfers and complex transactions
+
+### Emergency Preparedness
+
+- [ ] I have downloaded backup UIs (Eternal Safe for EVM, Squads public client for Solana) per [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)
+- [ ] I know how to sign transactions when primary UI is down per [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)
+- [ ] I understand emergency procedures for key compromise and communication failures per [Emergency Procedures](/multisig-for-protocols/emergency-procedures)
+- [ ] I have tested backup communication methods with my team
+- [ ] I know who to contact for security incidents and emergencies per [Incident Reporting](/multisig-for-protocols/incident-reporting)
+
+### Personal Security
+
+- [ ] I have enabled 2FA on all accounts with approved methods (YubiKey preferred) per [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec)
+- [ ] I use dedicated devices or accounts for multisig operations when required
+- [ ] I have implemented travel security procedures appropriate for my risk level
+- [ ] I understand incident reporting procedures for security concerns
+
+### Compliance
+
+- [ ] I have read and understand all sections of this security framework
+- [ ] I understand my specific role requirements based on multisig classification
+- [ ] I know how to properly offboard when leaving a multisig role per [Offboarding](/multisig-for-protocols/offboarding)
+- [ ] I commit to following these security procedures and reporting any deviations
+
+## Specialized Training by Use Case
+
+### Emergency Response Multisigs
+
+Additional requirements from [Use Case Specific Requirements](/multisig-for-protocols/use-case-specific-requirements):
+
+- [ ] I understand 24/7 availability requirements
+- [ ] I have participated in emergency simulation drills
+- [ ] I know how to respond to emergency paging
+- [ ] I understand streamlined verification procedures for emergencies
+
+### Treasury Multisigs
+
+- [ ] I understand allowance module configuration and purpose
+- [ ] I know governance rescue procedures
+- [ ] I understand financial reporting requirements
+
+### Smart Contract Control Multisigs
+
+- [ ] I understand timelock configuration per [Use Case Specific Requirements → Timelock Configuration](/multisig-for-protocols/use-case-specific-requirements#timelock-configuration)
+- [ ] I know how to verify staged transactions
+- [ ] I understand higher threshold requirements for upgrades
+
+## Practical Skills Assessment
+
+### Transaction Verification (EVM)
+
+- [ ] I can successfully verify a Safe transaction hash using CLI tools
+- [ ] I can decode transaction calldata and identify recipients and amounts
+- [ ] I can identify risky transaction types and warnings
+- [ ] I can verify nested Safe transactions if applicable
+
+### Transaction Verification (Solana)
+
+- [ ] I can analyze Solana transaction instruction data
+- [ ] I can convert hex values to decimal for amount verification
+- [ ] I can identify different transaction types (SOL transfer, token transfer, config changes)
+
+### Emergency Procedures
+
+- [ ] I can access backup UIs and complete a transaction
+- [ ] I can contact team via backup communication channels
+- [ ] I know how to report key compromise immediately
+- [ ] I can execute identity verification procedures if needed
+
+### Tool Proficiency
+
+- [ ] I am comfortable using my hardware wallet for signing
+- [ ] I can navigate backup block explorers
+- [ ] I can use alternative RPC endpoints
+- [ ] I understand how to manually simulate transactions
+
+## Documentation Review
+
+### Required Reading Completed
+
+- [ ] [Secure Multisig Best Practices](/wallet-security/secure-multisig-best-practices) - Core requirements for all multisigs
+- [ ] [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds) - Device security requirements
+- [ ] [Seed Phrase Management](/wallet-security/seed-phrase-management) - Key protection procedures
+- [ ] [Safe Multisig: Step-by-Step
+Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification) - Signing procedures
+- [ ] [Emergency Procedures](/multisig-for-protocols/emergency-procedures) - Crisis response protocols
+- [ ] [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec) - Account and device security
+
+### Role-Specific Documentation
+
+**For Administrators:**
+
+- [ ] [Planning & Classification](/multisig-for-protocols/planning-and-classification)
+- [ ] [Setup & Configuration](/multisig-for-protocols/setup-and-configuration)
+- [ ] [Registration & Documentation](/multisig-for-protocols/registration-and-documentation)
+- [ ] [Communication Setup](/multisig-for-protocols/communication-setup)
+- [ ] [Registration & Documentation](/multisig-for-protocols/registration-and-documentation)
+
+**For Specialized Use Cases:**
+
+- [ ] [Use Case Specific Requirements](/multisig-for-protocols/use-case-specific-requirements)
+- [ ] [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)
+- [ ] [Use Case Specific Requirements → Timelock Configuration](/multisig-for-protocols/use-case-specific-requirements#timelock-configuration)
+  (if applicable)
+
+## Certification and Acknowledgment
+
+### Training Completion
+
+- [ ] I have completed all applicable training requirements
+- [ ] I have successfully demonstrated practical skills
+- [ ] I understand the security implications of my role
+- [ ] I acknowledge my responsibilities as a multisig participant
+
+### Ongoing Commitment
+
+- [ ] I commit to following all security procedures outlined in this framework
+- [ ] I will report any security incidents or concerns promptly
+- [ ] I will participate in regular training updates and refreshers
+- [ ] I will maintain the required level of security for my role
+
+### Trainer Verification (if applicable)
+
+**For organizations requiring formal training:**
+
+Trainer: _________________ Date: _________________
+
+Trainee has demonstrated competency in:
+
+- [ ] Transaction verification procedures
+- [ ] Emergency response protocols
+- [ ] Security best practices
+- [ ] Role-specific requirements
+
+**Signature:** _________________
+
+## Refresher Training Schedule
+
+### Regular Updates
+
+- **Monthly**: Review emergency procedures and contact information
+- **Quarterly**: Practice backup system usage and emergency drills
+- **Annually**: Complete full framework review and updates
+- **As needed**: Training on new tools, procedures, or threats
+
+### Trigger Events
+
+Additional training required after:
+
+- Framework updates or changes
+- Security incidents affecting the team
+- New tool adoption
+- Role changes or additional responsibilities
+
+## Related Documents
+
+All documents in this framework serve as training materials. Refer to individual documents for detailed procedures and
+requirements specific to your role.
+
+---
+
+### PAGE: /multisig-for-protocols/personal-security-opsec
+
+# Personal Security (OpSec)
+
+
+
+
+## Account Security
+
+### Basic requirements
+
+- 2FA enabled on all accounts (authenticator apps or hardware keys)
+- Password manager with unique, strong passwords for every account
+- Remove phone numbers from account recovery options where possible
+- Regular security checkups and removal of unused app permissions
+- Backup email for account recovery (separate from primary email)
+
+### For extra security
+
+**YubiKeys**: Use hardware security keys instead of authenticator apps
+
+- Provides stronger protection against phishing and SIM swapping
+- Recommended: 3 keys (primary, backup, secure storage)
+- Models: YubiKey 5C NFC, YubiKey 5C Nano
+
+**Cold backup accounts**: Separate email/phone for sensitive account recovery
+
+- Backup / cold accounts are tied to sensitive accounts (AppleID, Telegram, Signal, WhatsApp, Password Manager etc).
+  Such email addresses must never be shared with anyone and kept private to remain secure and not targeted.
+
+Example: random44@gmail is tied to your AppleID, and you are only logged in (the email) on a separate secure device. If
+your main device (laptop) gets compromised, you will be able to recover your account or revoke sessions, moreover your
+cold account won't be affected / compromised. It prevents people from targeting your accounts by not knowing your email
+linked to it.
+
+- Use different providers from primary accounts (Gmail, Proton)
+- Only access from secure devices
+- Never used for regular communications
+
+## Device Security
+
+### Basic requirements
+
+- Full disk encryption enabled (FileVault/BitLocker)
+- Automatic updates enabled on all devices
+- Screen lock after 5 minutes inactivity on computers, 30 seconds on mobile
+- Strong passcodes (6+ digits or alphanumeric on mobile)
+- Endpoint protection software on computers
+- No admin rights for daily use accounts (create separate admin account)
+
+### For extra security
+
+**Dedicated signing device**: Clean laptop/tablet used only for multisig operations
+
+- Minimal software installation
+- Regular security updates
+- Clean restart before each use
+- Offline storage when not in use
+- Justification: Reduces attack surface for high-value operations
+
+## Network Security
+
+### Dedicated Signing Machines
+
+- Multi-sig operations must be performed on devices dedicated only to these transactions and verification tools
+- All network access should be default blocked, with only the minimum necessary IPs to execute these transaction
+signatures allowed
+- Signing devices must be operated on private, authenticated networks or over trusted VPNs
+
+### Air-Gapped Machine Options
+
+- For highest security, physically remove or disable the network interface
+- Use USB drives (with strict auto-run restrictions) or QR codes to transfer transaction data
+
+### Advanced OS-Level Controls
+
+- Consider employing SELinux or similar tools for advanced security configurations
+- Restrict file system access and inter-process communications
+
+### Network Monitoring Tools
+
+Organizations must implement active network monitoring on signing devices:
+
+- [Little Snitch](https://www.obdev.at/products/littlesnitch/index.html) for active firewall and network monitoring
+- [Lulu](https://objective-see.org/products/lulu.html) as a free, open source alternative to Little Snitch
+- [Glasswire](https://www.glasswire.com/) can be used for Windows machines
+
+### DNS Security
+
+Use [DeFi DNS Whitelist](https://github.com/0xKoda/defi-dns-whitelist/tree/main) as a firewall for dedicated signing machines.
+
+## Communication Security
+
+### Basic requirements
+
+**Signal with verified safety number verification** for multisig communications: You MUST check the codes with the
+person you are interacting to « verify » them.
+How? Click on any chat > Contact name > View Safety Number > Call on another communication channel to verify them >
+Click at the bottom "Mark as Verified".
+If the account connects on a new device these codes will change & you will receive a security notification.
+
+- Screen lock enabled on mobile devices
+- 2FA enabled on backup platforms (Telegram/Discord/Slack)
+- Privacy settings maximized on all platforms
+- Session management - remove old/unknown devices regularly
+
+### Signal configuration
+
+- Registration lock enabled
+- Signal PIN configured
+- Hide phone number (use username only)
+- Safety number verification for all contacts
+- Disappearing messages for sensitive chats
+
+### URL Navigation Safety
+
+Links to URLs containing transaction requests or confirmation data (even those provided by trusted parties) must never
+be clicked - they must be navigated to by using bookmarks or typing them out manually.
+
+### For extra security
+
+**Enhanced verification**: Advanced safety procedures for critical communications
+
+- Code words for identity verification
+- Multiple verification channels for important requests
+- Regular communication channel security audits
+
+## Travel considerations
+
+### What to bring
+
+- Primary hardware wallet only (leave backups secure at home)
+- Essential devices only (laptop + phone)
+- Emergency contact information (offline copy)
+- Own chargers and cables
+
+### What NOT to bring
+
+- Seed phrases (never travel with these)
+- Backup hardware wallets
+- USB drives with sensitive data
+- Non-essential devices
+
+### Basic travel security
+
+- Use device locks at all times
+- Avoid public WiFi (use mobile hotspot or VPN)
+- Don't leave devices unattended in hotel rooms
+- Use hotel safes for device storage when out
+- Have offline backup of emergency contacts
+
+### For extra security
+
+**Enhanced travel procedures**: Additional precautions for high-risk situations
+
+- Disable biometric unlock at airports/borders (use PIN only) - prevents forced unlocking
+- Decline hotel housekeeping services - reduces access to devices
+- Advance notification to multisig team (72 hours for critical operations)
+- Use separate carrier SIM card for travel communications
+- Professional security assessment of travel destinations
+
+## Implementation priority
+
+### Start with basics
+
+Focus on fundamental security practices first
+
+- Password manager + 2FA on all accounts
+- Device encryption and screen locks
+- Signal setup with safety number verification
+- Basic travel security practices
+
+### Add extra security
+
+Implement additional measures based on your risk level and operational needs
+
+- YubiKeys for critical accounts
+- Dedicated signing devices for high-value operations
+- Enhanced travel procedures for international travel
+- Professional security assessments for critical roles
+
+Remember: Perfect security doesn't exist - focus on practical improvements that significantly reduce your risk while
+remaining operationally feasible.
+
+For the full OpSec article, see [Operational Security](/opsec/overview).
+
+---
+
+### PAGE: /multisig-for-protocols/planning-and-classification
+
+TagList,
+  AttributionList,
+  TagProvider,
+  TagFilter,
+  ContributeFooter,
+} from "../../../components";
+
+
+
+
+# Planning & Classification
+
+
+
+
+Before setting up a new multisig, take time to properly assess its role and requirements. This planning phase will guide
+all subsequent configuration decisions and help ensure appropriate security measures.
+
+## Before You Start
+
+### Define Purpose and Scope
+
+Document the multisig's intended use:
+
+- **Primary function** - What will this multisig do?
+- **Asset types and amounts** - What will it control?
+- **Operational frequency** - How often will it be used?
+- **Decision timeline** - How quickly must it respond?
+- **Integration points** - What systems will it interact with?
+
+### Assess Constraints and Recovery
+
+Consider limiting factors that affect risk:
+
+- **Smart contract constraints** - What technical limits reduce risk?
+- **Governance recovery** - Can governance override or recover funds?
+- **Operational limits** - Are there built-in spending or parameter limits?
+- **Backup mechanisms** - What happens if this multisig fails?
+
+### Identify Stakeholders
+
+Determine who should be involved:
+
+- **Required expertise** - What knowledge is needed for decisions?
+- **Geographic distribution** - Do you need global coverage?
+- **External signers** - Should independent parties be involved?
+- **Backup signers** - Who can step in if primary signers are unavailable?
+
+## Classification Process
+
+Use this dual classification system to determine appropriate security measures. These classifications are guidance to
+help you think through risk levels - they inform threshold selection, signer requirements, and operational procedures in
+later sections.
+
+### Step 1: Impact Assessment
+
+What happens if this multisig is compromised or fails?
+
+#### Financial Exposure:
+
+- Direct funds controlled by the multisig
+- Indirect exposure through protocol impacts
+- Maximum potential loss in worst-case scenario
+
+#### Protocol Impact:
+
+- Can the protocol function without this multisig?
+- How difficult would recovery be?
+- Are there alternative execution paths?
+
+#### Reputational Risk:
+
+- How visible is this multisig to the community?
+- What would compromise mean for the protocol's reputation?
+- Are there regulatory or compliance considerations?
+
+#### Impact Classification
+
+| Level | Financial Exposure | Protocol Impact | Reputational Risk |
+| ------------ | ---------------------- | ----------------------------------------------------- | ----------------------------- |
+| **Low** | \<$100k direct exposure | Minimal disruption, alternative paths exist | Limited scope impact |
+| **Medium** | $100k - $1M exposure | Significant operational delays, workarounds available | Moderate reputational concern |
+| **High** | $1M - $10M exposure | Major protocol disruption, difficult recovery | Serious reputational damage |
+| **Critical** | \>$10M exposure | Protocol-wide failure, catastrophic impact | Severe reputational damage |
+
+### Step 2: Operational Assessment
+
+How quickly and under what conditions must this multisig respond?
+
+#### Response Time Requirements:
+
+- How quickly must decisions be made?
+- What are the consequences of delays?
+- Are there market or competitive timing factors?
+
+#### Decision Context:
+
+- Are operations routine and predictable?
+- Do market conditions affect timing?
+- Is this primarily for emergency response?
+
+#### Coordination Complexity:
+
+- How many parties must coordinate?
+- Are signers distributed globally?
+- What communication is required?
+
+#### Operational Classification
+
+| Type | Response Time | Decision Context | Verification Level |
+| ------------------ | ------------- | -------------------------------------------- | -------------------------------- |
+| **Routine** | 24-48 hours | Standard procedures, predictable operations | Full verification protocols |
+| **Time-Sensitive** | 2-12 hours | Market conditions, protocol needs | Streamlined but thorough |
+| **Emergency** | \<2 hours | Crisis response, preventing immediate damage | Minimal delays, risk-appropriate |
+
+### Step 3: Classification Matrix
+
+Combine your impact and operational assessments. Below are some example configurations.
+
+| Use Case | Impact | Operational | Standard Threshold |
+| ------------------- | -------- | -------------- | ------------------ |
+| Emergency Freeze | Critical | Emergency | 2/4 |
+| Protocol Parameters | High | Routine | 4/7 (higher for upgrades, consider 7/9+) |
+| Capital Allocation | High | Time-Sensitive | 3/5 |
+| Treasury - Large | High | Routine | 4/7 |
+| Treasury - Small | Medium | Routine | 3/5 |
+| Constrained DeFi | Medium | Time-Sensitive | 2/3 |
+
+### Step 4: Document Your Decision
+
+Record your classification decision in the [Registration template](/multisig-for-protocols/registration-and-documentation#registration-template).
+
+## Important Notes
+
+⚠️ **When between classifications**: Always err toward higher security requirements. Classifications can be relaxed with
+proper justification, but security incidents cannot be undone.
+
+This classification will guide your threshold selection ([Thresholds &
+Configuration](/wallet-security/secure-multisig-best-practices#thresholds--configuration)), signer requirements, and
+operational procedures throughout the rest of the documentation.
+
+## Next Steps
+
+After completing classification, proceed to:
+
+1. [Setup & Configuration](/multisig-for-protocols/setup-and-configuration) - Deploy your multisig
+2. [Registration & Documentation](/multisig-for-protocols/registration-and-documentation) - Document your setup
+
+---
+
+### PAGE: /multisig-for-protocols/setup-and-configuration
+
+# Setup & Configuration
+
+
+
+
+This page covers the technical deployment and configuration of multisigs on supported networks.
+
+## Basic Setup
+
+### EVM Networks (Ethereum, Base, etc.)
+
+1. Go to [https://app.safe.global](https://app.safe.global)
+2. Connect wallet of the deploying signer
+3. Create new Safe with your determined threshold and signer addresses
+4. **Multi-network deployment**: If deploying on multiple networks, Safe UI will offer to replicate the configuration
+
+### Solana
+
+1. Go to [https://squads.xyz/squads-multisig](https://squads.xyz/squads-multisig)
+2. Connect wallet of the deploying signer
+3. Create new multisig with your determined threshold and signer addresses
+
+## Self-Hosted Multisig UI
+
+Multi-sig coordination UIs should be self-hosted to eliminate supply chain risk. Hosted UI should be IP restricted to
+allow access only from signer machines.
+
+Deploy from [Safe Wallet Monorepo](https://github.com/safe-global/safe-wallet-monorepo/tree/dev/apps/web).
+While it should not be your final line of defense, securing the UI does protect your verification process
+from being compromised by supply-chain attacks.
+
+For emergency situations when the primary UI is unavailable, see
+[Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure).
+
+## Delegated Proposer
+
+It is recommended, but not required to authorize a separate transaction proposer for a Safe. This address can prepare
+transactions for signers to sign but is not an authorized signer on the Safe. Therefore **there is no risk of malicious
+signatures which can affect the Safe assets**. This wallet can hold no funds and simply act as a proposer. The primary
+reason to have a delegated proposer is that the hash verification utilities depend on the Safe API (unless details are
+entered manually). Until a transaction is **proposed** it does not show up in the API so the hash verification tools
+cannot detect it.
+
+![Delegated proposer configuration interface](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/delegated-proposer-configuration-interface.png)
+
+## Modules & Guards
+
+### Allowance Module (Required for Treasury Multisigs)
+
+If your multisig will hold any assets on behalf of the DAO, set up governance rescue capability:
+
+**Mainnet configuration:**
+
+- **Module**: Allowance Module
+- **Grant allowance to**: DAO Agent
+- **Amount**: Max value for each token held
+
+### Zodiac Delay Modifier (Time-Locks)
+
+Consider using [Zodiac Modifier Delay](https://github.com/gnosisguild/zodiac-modifier-delay/tree/main) or equivalent
+for implementing on-chain time-lock transaction delays to Safe wallets.
+
+See [Use Case Specific Requirements](/multisig-for-protocols/use-case-specific-requirements#timelock-configuration)
+for detailed timelock configuration guidance.
+
+### Other Modules
+
+Do not install any other modules or guards without explicit governance approval and security review.
+
+## Contract-Level Controls
+
+**Advanced Configuration Warning:** The following contract-level controls are advanced security features that can
+provide additional protection but require careful implementation. Before implementing any guards or modules:
+
+- **Conduct thorough research** on available guard implementations and their compatibility with your multisig setup
+- **Ensure all guards are well-audited** by reputable security firms before deployment
+- **Test extensively** on testnets to verify functionality and edge cases
+- **Understand the risks**: Incorrect configuration or incompatible guards can render your multisig unusable,
+potentially locking access to funds permanently
+
+### Address Whitelisting
+
+Approved smart contract and wallet addresses must be added to a whitelist that is enforced at the contract-level.
+Interactions with all other addresses should be denied and revert the transaction. Updating the whitelist should
+require an extra signer in addition to the standard transaction approval quorum.
+
+### Invariant Enforcement
+
+Design contracts to enforce invariants and expected state changes such as token balance changes, ownership and
+administration, and proxy implementation addresses. Ensure contracts automatically revert transactions if any
+invariant is violated.
+
+## Initial Testing
+
+### Verify Basic Functionality
+
+1. **Small test transaction**: Send a low-value token transfer (e.g., 1 USDS or equivalent)
+2. **All signers test**: Ensure each signer can successfully sign the test transaction
+3. **Confirm execution**: Verify the transaction executes as expected
+4. **Test communication**: Use your established channels to coordinate the test
+
+## Pre-Launch Checklist
+
+- [ ] Safe deployed with correct threshold
+- [ ] All signer addresses added and [verified](/multisig-for-protocols/registration-and-documentation#signer-verification-process)
+- [ ] Allowance module configured (if required)
+- [ ] Test transaction completed successfully
+- [ ] All signers confirmed they can sign
+- [ ] [Communication channels](/multisig-for-protocols/communication-setup) tested during transaction
+- [ ] Safe addresses documented for all networks
+
+### Practice on Testnet
+
+Before deploying on mainnet, thoroughly practice wallet creation, transaction signing, and owner management on
+a test network.
+
+Once setup is complete, proceed to [Registration &
+Documentation](/multisig-for-protocols/registration-and-documentation) for registration and documentation requirements.
+
+## Nested Safes
+
+A nested Safe is one in which a Safe is set as a signer on another Safe rather than an EOA. This can be useful on a
+case-by-case basis. For example, if a signer is an entity that might want to have multiple individual signers, the
+nested Safe could have a 1/X threshold allowing anyone authorized on the team to sign. However, this configuration
+allows the signers on the nested Safe to update the signer addresses without needing authorization from the main Safe.
+
+It is generally recommended **not** to use nested safe on protocol multisigs unless there is a specific use case that
+it enables.
+
+## Next Steps
+
+After completing setup:
+
+1. [Registration & Documentation](/multisig-for-protocols/registration-and-documentation) - Document your multisig
+2. [Communication Setup](/multisig-for-protocols/communication-setup) - Establish secure communication
+3. [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds) - Ensure all signers are properly configured
+
+## Active Monitoring
+
+Implement monitoring and alerting systems to be immediately notified of any on-chain activity related to the multisig,
+including proposed transactions, new signatures, and owner changes (e.g., using tools like [Safe
+Watcher](https://github.com/Gearbox-protocol/safe-watcher)).
+
+### Immutable Monitoring Channels
+
+Monitoring channels (e.g. email, Slack or Telegram chats) must be immutable (or trigger alerts when their configuration
+changes or logs are deleted/tampered with) and redundant such that an admin could not disable or tamper with one
+monitoring channel without generating an alert on the other channel.
+
+---
+
+### PAGE: /wallet-security/secure-multisig-best-practices
+
+# Secure Multisig Best Practices
+
+
+
+
+> Guidance for designing, operating, and auditing high-assurance multisigs. Use this as your single source for baseline
+> rules, setup guidance, and daily operations.
+
+## Who This Is For
+
+Advanced technical users, developers, Decentralized Autonomous Organizations (DAOs), and organizations responsible for
+managing protocol treasuries, smart contract ownership, or significant personal/collective assets.
+
+## Primary Goal
+
+The primary objective is to eliminate single points of failure and establish robust, distributed control over high-value
+assets and critical smart contract functions.
+
+## Core Concept: M-of-N Scheme
+
+A multisignature (multisig) wallet is a smart contract that requires a predefined minimum number of approvals `M` from a
+total set of authorized signers `N` to execute a transaction. This is known as an `M-of-N` scheme (e.g., 2-of-3,
+3-of-5).
+
+By distributing signing authority, a multisig ensures that the compromise of a single private key is insufficient to
+authorize the movement of funds or execute a privileged action.
+
+## General Rules
+
+### Thresholds & Configuration
+
+- Minimum of 3 signers
+- 50% signing threshold
+- 7+ signers for multisigs holding 1M+ in assets (USD equivalent)
+- Please see Classification Matrix in
+  [Planning & Classification](/multisig-for-protocols/planning-and-classification#step-3-classification-matrix)
+  for more information on threshold selection.
+- All signers must use hardware wallets
+- Multisigs managing assets on behalf of a DAO should set unlimited allowance with primary DAO agent
+- Signers on multisigs with critical protocol configuration or security roles are discouraged from using their
+addresses for other purposes. They should create a brand new wallet for that purpose instead.
+- All signing wallets should be monitored for any activity that is not directly related to multi-sig operations.
+- No multisigs should use modules/guards except those mentioned in
+[Setup & Configuration → Modules & Guards](/multisig-for-protocols/setup-and-configuration#modules--guards)
+unless clear justification and security review is provided
+- Threshold exceptions can be made for multisigs that are used in frequent operations but are highly constrained
+by smart contracts. For example, rate setting operations with tight bounds and a backup recovery mechanism to
+replace the multisig.
+
+#### Threshold Selection
+
+Avoid `N-of-N` schemes, as the loss of a single key would result in a permanent loss of access to all funds.
+
+#### Strategic Signer Distribution
+
+The security of a multisig depends entirely on the operational security (OpSec) of its individual signer keys. Storing
+multiple signer keys on the same device or in the same physical location negates the security benefits. Effective
+distribution strategies include:
+
+- Using different hardware wallet models and manufacturers.
+- Maintaining geographical separation for devices holding signer keys.
+- Assigning signer keys to different trusted individuals within an organization.
+- Using diverse client software to interact with the multisig to mitigate single-point-of-failure risks from a software
+vulnerability.
+
+#### Signer Composition Requirements
+
+- **Role Diversity**: Signers should be diverse individuals to reduce risk of multiple compromised accounts - a
+mix of executives, developers, and operational roles is recommended
+- **Technical Expertise**: Include a high number of competent, well-vetted technical signers that will understand full
+transaction details and effects in your signing quorum
+- **External Parties**: Multi-sigs managing high value wallets and contracts should have at least 1 additional required
+signer that is external to the organization (such as a security partner or trusted advisor)
+
+### Communication & Documentation
+
+- In the event of loss of access to keys or potential compromise of keys or communication channels, the signer must
+  immediately notify the other multisig participants and email your security contact - [Incident
+  Reporting](/multisig-for-protocols/incident-reporting)
+- Signers should use dedicated communication channels for multisig operations and maintain backup ways of reaching other
+  signers
+- All multisigs should be documented in the protocol documenting its purpose, general operating rules, multisig wallet
+  address, and list of signer addresses
+- Signers should verify their addresses by signing a message stating their affiliation and the multisig they intend to
+  join (entity affiliation is ok)
+
+#### Out-of-Band Verification for Admin Changes
+
+Any critical administrative action, such as adding or replacing a signer, must be verified through multiple, independent
+communication channels (e.g., a video call and a signed message) to prevent social engineering attacks.
+
+### Signer rotation
+
+- Signers can be rotated, but detailed documentation should be maintained
+- Any changes to signer composition should be documented in the protocol documentation
+- Any signer change should not reduce the number of signers or decrease the threshold unless clear justification is
+  given and documented
+
+#### Updating signer addresses
+
+If the original key is accessible:
+
+- The signer proves ownership of a new address by signing a message with their existing address.
+- The signer must follow the steps in
+[Signer Verification process](/multisig-for-protocols/registration-and-documentation#signer-verification-process)
+
+If the original key is lost:
+
+- The signer must verify their identity to the other signers through alternative methods such as:
+  - Authentication via a verified social media account.
+  - A video call with other signers for confirmation.
+  - Other sufficient methods.
+
+### Training & Drills
+
+- All signers should complete training as outlined in the
+[Implementation Checklist](/multisig-for-protocols/implementation-checklist)
+- For multisigs that perform emergency operations like pausing, teams should have processes to regularly conduct drills
+  to ensure operational readiness and signer availability
+
+## Setup Best Practices
+
+See General Rules above for thresholds and signer distribution guidance.
+
+- **Practice on Testnet:** Before deploying on mainnet, thoroughly practice wallet creation, transaction signing, and
+owner management on a test network.
+
+- **Timelocks:** Enforce a mandatory delay between the approval of a transaction and its execution. This provides a
+critical window for the community or team to detect and react to malicious proposals.
+
+- **Veto Quorum:** Establish a smaller veto group separate from the confirmation quorum to review and confirm
+transaction legitimacy. Organizations can establish veto quorums to bypass time-locks in case of emergency.
+The standard quorum plus two additional signers should be required to bypass.
+
+- **Role-Based Access Control (RBAC):** Implement modules that grant specific, limited permissions to certain addresses
+(e.g., a "pauser" or "executor" role) without making them full owners, adhering to the principle of least privilege.
+
+- **Disaster Recovery Plan:** Establish a clear, documented process for what to do when a signer is compromised, the
+multi-signature UI is down, or other emergencies arise. These should be done at regular intervals.
+
+## Operational Best Practices
+
+- **Signer Key Revocation and Replacement:** A  feature of multisigs is the ability to add, remove, or replace signer
+keys. If a signer's key is compromised or lost, it can be revoked and replaced with a new, secure key through a
+transaction approved by the remaining owners, preserving the integrity of the wallet's assets without needing to migrate
+funds.
+
+- **Secure Signing Environment:** For maximum security, all signing activities should be performed on a dedicated,
+air-gapped, or hardened device running a secure OS. Using a primary work laptop significantly increases the risk of
+malware interference.
+
+- **Independent Transaction Verification:**  Before signing, always verify the raw transaction data (target address,
+function call, parameters) to ensure it matches the intended operation.
+
+- **Out-of-Band Verification for Admin Changes:** Any critical administrative action, such as adding or replacing a
+signer, must be verified through multiple, independent communication channels (e.g., a video call and a signed message)
+to prevent social engineering attacks.
+
+- **Active Monitoring:** Implement monitoring and alerting systems to be immediately notified of any on-chain activity
+related to the multisig, including proposed transactions, new signatures, and owner changes (e.g., using tools like
+[Safe Watcher](https://github.com/Gearbox-protocol/safe-watcher) ).
+
+- **Documented Procedures:** Maintain clear, secure, and accessible documentation for all multisig procedures, including
+  transaction creation, signing, and emergency recovery plans.
+- **General Signing Guidelines:** Use hardware wallets, dedicated signing profiles, and re-verify before execution.
+  Require a "how to check" guide and communicate status after signing (e.g., "checked, signed, X more required"). Last
+  signer executes when applicable.
+
+## Contract-Level Security
+
+- **Invariant Enforcement:** Design contracts to enforce invariants and expected state changes such as token balance
+changes, ownership and administration, and proxy implementation addresses. Ensure contracts automatically revert
+transactions if any invariant is violated.
+
+- **Address Whitelisting:** Approved smart contract and wallet addresses must be added to a whitelist that is enforced
+at the contract-level. Interactions with all other addresses should be denied and revert the transaction. Updating the
+whitelist should require an extra signer in addition to the standard transaction approval quorum.
+
+For detailed configuration guidance, see
+[Setup & Configuration → Contract-Level Controls](/multisig-for-protocols/setup-and-configuration#contract-level-controls).
+
+## Acknowledgements
+
+Some ideas were borrowed from the [EF's multisig SOP notes](https://notes.ethereum.org/@fredrik/multisig-sop) and
+[Manifold Finance multisig best practices](https://hackmd.io/@manifoldx/multisig-best-practices).
+
+---
+
+---
+
+### PAGE: /wallet-security/seed-phrase-management
+
+# Seed Phrase Management
+
+
+
+
+## Private Key & Seed Phrase Management
+
+The **seed phrase** (or mnemonic phrase) is the master key to a non-custodial wallet, granting complete control over all
+its derived **private keys** and assets. The management of this phrase is the single most important aspect of
+self-custody security.
+
+> ⚠️ If you suspect for even a moment that your private key or seed phrase has been lost, viewed by another person, or
+> exposed digitally (e.g., shown on-screen, copied to a clipboard on a connected device), you must **consider it
+> compromised.** Immediately create a new, secure wallet and transfer all assets to it.
+
+### Secure Storage Practices
+
+The goal is to protect the seed phrase from both physical threats (theft, fire, water damage) and digital threats
+(hacking, malware). The foundational principle is to keep your seed phrase offline at all times.
+
+As soon as a new wallet is created, back it up using one of the following offline methods. Wallet providers do not have
+access to your seed phrase and cannot help you recover it.
+
+- **Physical Written Copies**: Writing the phrase on paper or a notebook is a common starting point. To mitigate risks
+
+of loss or damage from fire or water, store multiple copies in secure, geographically separate locations (e.g., a
+personal safe, a trusted family member's home, a bank deposit box).
+
+- **Durable Metal Storage**: For superior protection against physical damage, etch or stamp your seed phrase onto a
+
+metal plate (e.g., steel, titanium). Commercial products are available for this purpose. These should also be stored in
+secure, separate locations.
+
+### Enhanced security option
+
+For extra security, split seed into 3 pieces:
+
+- **Piece 1**: Words 1-16
+- **Piece 2**: Words 9-24
+- **Piece 3**: Words 1-8 and 17-24
+
+#### Storage locations:
+
+- Different secure locations (safe deposit box, home safe, trusted family)
+- Each piece stored with clear labeling system
+
+### Tamper evident bags:
+
+Storing sensitive devices or documents in a tamper evident bag offers high confidentiality and integrity. You can sign &
+date these bags, and also take a picture of its serial number.
+
+![Tamper evident bag example](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/tamper-evident-bag-example.png)
+
+**Use case:**
+You can put your Piece 1: Words 1-16 of your seed, inside a safe.
+Piece 2: Words 9-24 of your seed, somewhere safe (different location) in a tamper evident bag (could be at your parents place).
+Piece 3: Words 1-8 and 17-24 of your seed, somewhere safe (different location) in a tamper evident bag (could be
+somewhere else, at a family member or trusted friend).
+You can put your backup ledger while traveling inside this, in the safe of your hotel room to detect tampering.
+The main idea is to never have at the same place your 24 words, but still be able to recover your seed within 2 pieces
+of paper out of 3.
+You can find a useful [link here to our EthCC
+swag](https://drive.google.com/file/d/1L1CMiKRL3TXQBE5bWYNv6dfF94HSdZ8C/view?usp=sharing) that shows you how to easily
+split your seed in 3 as recommended.
+
+### Prohibited Practices
+
+Under no circumstances should you ever store your seed phrase in any of the following ways:
+
+- Taking a digital photograph of it.
+- Uploading it to cloud storage (iCloud, Google Drive, Dropbox).
+- Sending it via text message or any messaging app.
+- Sending it in an email, even to yourself.
+- Storing it in a plain text file on a computer or phone.
+- Sharing it with anyone. Wallet providers will **never** ask for your seed phrase.
+- Password managers or digital storage
+- Traveling with seed phrases
+- Storing all pieces in same location
+- Using a device obtained from an untrusted source, such as a conference, hackathon, or third-party online marketplace,
+as it may be tampered with.
+
+## Organizational Seed Phrase Security
+
+For organizations managing multisig wallets, seed phrase security requires additional properties beyond individual storage:
+
+### Security Properties
+
+- **Disaster Resistant**: The seed phrase is either duplicated or split, with components/copies secured across multiple
+geographic locations. This way, if disaster strikes, keys can be recovered from other locations.
+- **Theft Resistant**: An attacker gaining access to one piece of physical storage media for the seed phrase would not
+allow them to rebuild the wallet on its own
+- **Operator Loss Resistant**: Reconstituting the seed phrase should be possible with the absence of one or more
+operators
+
+### Seed Phrase Encryption
+
+> ⚠️ **Warning: Encryption adds recovery risk.** Only implement custom encryption schemes if you are sophisticated and
+> have robust documentation practices. If you forget your encryption method or passphrase, your funds are **permanently
+> inaccessible**—there is no recovery option. Many users and organizations face greater risk of locking themselves out
+> with custom encryption than from an attacker discovering a securely stored backup. Evaluate whether strong physical
+> security alone may be sufficient for your threat model.
+
+The reason to encrypt seed phrases is that if they are discovered unencrypted, the wallet is permanently compromised.
+However, if you encrypt your seed phrase, you are much more likely to forget the encryption when trying to restore the
+wallet. If you have stored the seed securely, it is unlikely to be discovered in the first place.
+
+Never store seed phrases in plain text or on an internet connected device. For additional protection, seed phrases can
+optionally be encrypted through some method. For example:
+
+- Seed phrases can be mixed in a randomly generated, recorded order
+- Have a 25th secret word
+- Require a passphrase to be imported into a wallet
+
+Regardless of the method, the related secret value should be stored in a password manager. (**Do not store your seed
+phrase in a password manager.**)
+
+### Advanced Backup Options
+
+**Key Splitting:**
+
+Split the key into multiple shards and securely distribute them:
+
+- Use [Shamir's Secret Sharing algorithm](https://en.wikipedia.org/wiki/Shamir%27s_secret_sharing) for N of M key shards
+- Consider using this [Shamir Secret Sharing implementation](https://github.com/privy-io/shamir-secret-sharing)
+- Seed phrases can be sharded using Shamir's Secret Sharing algorithm, with each shard recommended to be shared with a
+trusted guardian (3rd party custodian service, family members, password manager, personal physical media, etc.)
+
+**Multi-Share Backups:**
+
+Use device-supported multi-share backups where available:
+
+- [Trezor Multi-Share Backup](https://trezor.io/learn/a/multi-share-backup-on-trezor)
+
+**Secure Distribution:**
+
+Give shards to trusted family members, put in bank safe deposit boxes, and keep hidden around your house.
+
+> **Note**: If you're concerned about targeted attacks like kidnapping or home invasions, consider avoiding storing
+any shards in your primary residence.
+
+### Multisig Social Recovery
+
+**Optional Self-Recovery**:
+
+- Seed phrase backups are not strictly necessary with a healthy quorum
+- Multi-sig signing wallets should not be used for any other purpose and could be re-provisioned by existing quorum
+admins
+- Maintain a healthy enough signing pool that loss of access to a few accounts at once could be recovered from
+- Personal backup methods for admins are required to maintain access to on-chain assets in the event of loss of access
+to hardware wallets
+
+**Quorum Social Recovery**: If access to wallet is lost, the quorum can vote to edit members to replace the
+inaccessible wallet.
+
+### Ongoing Security Hygiene
+
+**1. Periodic Security Audits:**
+
+On a recurring basis (e.g., every 6 months), conduct a security review by asking:
+
+- Do I know the physical location of all my seed phrase backups?
+- Are my storage methods still secure and uncompromised?
+- If my primary device were destroyed, do I have a clear plan to recover my assets?
+
+**2. Key Rotation:**
+
+While you can use the same keys for years, it is a best practice to periodically rotate them by moving assets to new
+wallets.
+
+**3. Succession Planning:**
+
+Establish a clear, secure protocol for a trusted next-of-kin to access your assets in case of incapacitation or death.
+This may involve sealed instructions stored with a lawyer or in a safe deposit box.
+
+## Emergency access plan
+
+### Trusted contacts
+
+- Designate 2-3 trusted individuals who can access backup locations
+- Clear instructions for emergency seed access
+- Regular check-ins with trusted contacts
+
+### Recovery scenario example
+
+"Call [trusted person] with code word [predetermined phrase], tell them to get the metal plate from safe location A,
+they give you words 1-16 over the phone. Then call [second person] with code word for location B to get words 9-24. Use
+both pieces to reconstruct seed immediately, then change all security settings."
+
+### Documentation
+
+- Emergency contact information stored separately from seed
+- Code words/phrases for identity verification
+- Access instructions for trusted contacts
+- Regular testing of emergency procedures
+- Update procedures when contacts or locations change
+
+Remember: Your seed phrase security is the foundation of multisig security. Take time to implement proper storage
+procedures appropriate for your risk level.
+
+---
+
+### PAGE: /wallet-security/signing-and-verification/secure-multisig-signing-process
+
+# Verifying Multisig Transactions
+
+
+
+
+The security of a multisig wallet relies on each signer independently verifying what they are signing. A compromised web
+interface could present a legitimate-looking transaction while tricking a hardware wallet into signing a malicious one.
+
+The verification process is divided into two distinct phases: signing the off-chain message and executing the on-chain transaction.
+
+## Key Definitions (EVM)
+
+- **Domain Hash**: EIP-712 domain separator, unique to each Safe. Ensures signatures cannot be replayed on other
+  networks or Safes.
+- **Message Hash**: Raw hash of transaction parameters. This appears on your hardware wallet.
+- **SafeTxHash**: Combined hash of domain + message hash. Used for nested Safe approvals.
+
+## Phase 1: Signing the Off-Chain Message
+
+When you are the first signer or are adding your signature to a transaction that has not yet met its threshold, you are
+not sending an on-chain transaction. Instead, you are signing a structured, off-chain message that conforms to the
+**EIP-712** standard.
+
+**Goal**: To confirm that the cryptographic hash displayed on your hardware wallet exactly matches the hash of the
+transaction you intend to approve.
+
+### Process
+
+1. **Initiate Signing**: Start the signing process in the multisig wallet's web interface.
+2. **Verify on Hardware Wallet**: Your hardware wallet will display an EIP-712 hash for you to sign.
+3. **Compute Hash**: Use an independent, local tool to re-calculate the expected hash from the transaction's parameters
+(`nonce`, `to`, `value`, `data`, etc.). For a list of recommended options, see the [Transaction Verification
+Tools](/wallet-security/tools-&-resources) section.
+4. **Compare Hashes**: Compare the `SafeTxHash` generated by the local tool with the hash displayed on your hardware
+wallet's screen. **They must match perfectly.**
+   - All signers must verify transaction data on at least two independent devices
+   - All signers must verify transaction data through at least two separate communication channels
+5. **Simulate Transaction**: At least 2 signers must use transaction simulation tools to verify transaction effects.
+Simulation testing output should be shared with and reviewed by all signers before signing.
+   - Warning: Simulations can be spoofed - always apply critical thinking and good judgement during
+     transaction reviews since a simulation can display one thing and then do something else entirely
+     when actually executed on chain
+6. **Sign**: If the hashes match and simulation results are verified, you can confidently sign the message on your
+hardware wallet. This confirms you are approving the correct transaction, even if the web UI has been compromised.
+
+## Phase 2: Executing the On-Chain Transaction
+
+Once a transaction has the required M-of-N signatures, it can be executed. This involves submitting a final on-chain
+transaction that calls the `execTransaction` function on the multisig contract, passing in all the previously signed
+data.
+
+**Goal**: To confirm that the on-chain transaction being sent correctly encapsulates the multisig transaction you and
+other signers approved.
+
+### Process
+
+1. **Initiate Execution**: In the multisig interface, start the execution of the fully signed transaction.
+2. **Verify Calldata**: Your hardware wallet will prompt you to sign a new on-chain transaction. It will display the raw
+transaction data (calldata), which should show a call to the `execTransaction` function.
+3. **Decode and Compare**: Use a calldata decoder
+(e.g.,[calldata.swiss-knife.xyz](https://calldata.swiss-knife.xyz/decoder)) to parse the data shown on your hardware
+wallet.
+4. **Confirm Parameters**: Carefully check the decoded parameters within the `execTransaction` call, especially the
+internal destination address (`to`), `value`, and `data` payload. Ensure they match the original, intended transaction.
+5. **Sign and Broadcast**: If the calldata is correct, sign the transaction on your hardware wallet to broadcast it to
+the network.
+
+## Operational Best Practices
+
+> ⚠️ **Beware of `DELEGATECALL`**: In a smart contract multisig transaction, an `operation: 1 (DELEGATECALL)` is
+> dangerous if the target contract is not explicitly known and trusted. This opcode gives another contract full control
+> over your wallet's context and storage.
+
+- **Transaction Simulation**: Before signing, use a simulator like **[Tenderly](https://tenderly.co/)** or
+  **[Alchemy](https://www.alchemy.com/docs/reference/simulation)** to preview the transaction's outcome. This helps
+  confirm that it will not revert and will result in the expected state changes.
+- **Hardware Wallet Standard**: All multisig signers should use hardware wallets to protect their keys from online
+  threats. Data shown in a browser extension wallet should be treated with the same skepticism as data in the web UI.
+- **Secure signing environment**: Use a dedicated, air-gapped, or hardened device. Avoid primary work laptops.
+- **Alternative Frontends**: To further reduce reliance on a single public UI, consider using an alternative or
+  self-hosted multisig interface.
+- **Separate browser/profile for signing**: Use a dedicated browser or browser profile when interacting with signing UIs
+  to reduce cross-extension/session risk.
+- **Require a "how to check" guide**: Every transaction should include explicit verification instructions for signers.
+- **Verify addresses and amounts via independent sources**: Do not rely solely on messages from co-signers.
+- **Check transactions in the queue**: If unclear what a transaction does and why, do not sign; ask for explanation.
+- **Communicate status**: After review, state whether a transaction is ready to execute and confirm after signing
+  ("checked, signed, X more required").
+- **Last signer executes**: If executable immediately, the last signer should execute; otherwise coordinate clearly.
+- **Re-verify before execution**: Treat execution as a fresh signing event and re-check parameters.
+- **Use checksummed addresses**: Always use checksummed format to prevent copy/paste or case errors.
+
+### Simulation notes with timelocks
+
+When using a timelock, simulations may show the staging event rather than actual execution. Inspect the staged payload
+and verify cancellation/execution roles and parameters before proceeding.
+
+---
+
+---
+
diff --git a/scripts/data/qa-briefs/sfc-treasury-ops.md b/scripts/data/qa-briefs/sfc-treasury-ops.md
new file mode 100644
index 00000000..294d1d70
--- /dev/null
+++ b/scripts/data/qa-briefs/sfc-treasury-ops.md
@@ -0,0 +1,2422 @@
+# QA Brief: sfc-treasury-ops
+
+## YOUR TASK
+
+Verify the evaluation claims below. For each control with refs:
+1. Read the ACTUAL page content (provided below)
+2. Read the control's FULL baselines
+3. Check: does the page ACTUALLY meet the baselines claimed in "baselinesMet"?
+4. Check: are the "baselinesMissed" correct (is there content that was overlooked)?
+5. Check: is the coverage rating ("full"/"partial") justified?
+
+Be STRICT. If the evaluator was too generous, downgrade. If they missed coverage, upgrade.
+
+## EVALUATION CLAIMS TO VERIFY (16 controls with refs)
+
+### tro-1.1.2: Treasury Registry and Documentation
+**Full baselines:**
+  1. Registry includes wallet/account address, network/chain, custody provider, custody model, purpose/classification, authorized signers/approvers, controlled contracts or protocols, and last review date
+  2. Updated within 24 hours for security-critical changes (signer changes, new wallets), 3 days for routine changes
+  3. Accessible to authorized treasury personnel
+
+**Evaluator's assessment:**
+- **/treasury-operations/registration-documents** → Registration Template — **full**
+  Met: Registry includes wallet/account address, network/chain, custody provider, custody model, purpose/classification, authorized signers/approvers, controlled contracts or protocols, and last review date; Accessible to authorized treasury personnel
+  Missed: Updated within 24 hours for security-critical changes (signer changes, new wallets), 3 days for routine changes
+**Gaps:** Updated within 24 hours for security-critical changes (signer changes, new wallets), 3 days for routine changes
+
+### tro-1.1.3: Custody Architecture Rationale
+**Full baselines:**
+  1. Custody model documented for each wallet/account (custodial, self-custody, co-managed, MPC, multisig, HSM)
+  2. Technology trade-offs understood by the team (not necessarily a formal document — could be a brief internal memo)
+  3. Custody architecture reviewed when treasury size, operational needs, or risk profile changes significantly
+
+**Evaluator's assessment:**
+- **/treasury-operations/enhanced-controls** → MPC for Large Holdings — **partial**
+  Met: Custody model documented for each wallet/account (custodial, self-custody, co-managed, MPC, multisig, HSM)
+  Missed: Technology trade-offs understood by the team; Custody architecture reviewed when treasury size, operational needs, or risk profile changes significantly
+**Gaps:** Technology trade-offs understood by the team (not necessarily a formal document — could be a brief internal memo); Custody architecture reviewed when treasury size, operational needs, or risk profile changes significantly
+
+### tro-1.1.4: Treasury Infrastructure Change Management
+**Full baselines:**
+  1. Covers wallet setups, custody configurations, signer/approver permission changes, and protocol integrations
+  2. Changes require documented approval before implementation
+  3. All changes logged with justification and approver
+  4. Changes reflected in the treasury registry within defined SLAs
+  5. Rollback procedures documented for critical changes
+
+**Evaluator's assessment:**
+- **/treasury-operations/registration-documents** → Access Change Template — **partial**
+  Met: Changes require documented approval before implementation; All changes logged with justification and approver
+  Missed: Covers wallet setups, custody configurations, signer/approver permission changes, and protocol integrations; Changes reflected in the treasury registry within defined SLAs; Rollback procedures documented for critical changes
+**Gaps:** Covers wallet setups, custody configurations, signer/approver permission changes, and protocol integrations; Changes reflected in the treasury registry within defined SLAs; Rollback procedures documented for critical changes
+
+### tro-2.1.1: Treasury Wallet Risk Classification
+**Full baselines:**
+  1. Classification considers financial exposure, operational dependency, and regulatory impact
+  2. Impact levels defined (e.g., Low <1%, Medium 1-10%, High 10-25%, Critical >25% of total assets)
+  3. Operational types defined based on transaction frequency and urgency requirements
+  4. Each classification maps to specific controls including approval thresholds, MFA requirements, whitelist delays, and monitoring levels
+  5. Classification reviewed when asset values, operational patterns, or risk profile change significantly
+
+**Evaluator's assessment:**
+- **/treasury-operations/classification**  — **full**
+  Met: Classification considers financial exposure, operational dependency, and regulatory impact; Impact levels defined (e.g., Low <1%, Medium 1-10%, High 10-25%, Critical >25% of total assets); Operational types defined based on transaction frequency and urgency requirements; Each classification maps to specific controls including approval thresholds, MFA requirements, whitelist delays, and monitoring levels; Classification reviewed when asset values, operational patterns, or risk profile change significantly
+
+### tro-3.1.1: Custody Platform Security Configuration
+**Full baselines:**
+  1. Transaction policy rules configured: multi-approval workflows, approval thresholds scaled to transaction value, address whitelisting with cooling-off periods, velocity/spending limits
+  2. Hardware security key MFA required for all approvers on High and Critical accounts
+  3. Session timeouts and re-authentication for sensitive operations
+  4. Network restrictions: IP whitelisting, VPN requirements where supported, geographic access restrictions
+  5. Separation of duties enforced: initiators cannot approve their own transactions, admins cannot unilaterally execute withdrawals
+  6. Platform configurations documented and reviewed at least quarterly
+
+**Evaluator's assessment:**
+- **/treasury-operations/enhanced-controls** → Access Security — **full**
+  Met: Transaction policy rules configured: multi-approval workflows, approval thresholds scaled to transaction value, address whitelisting with cooling-off periods, velocity/spending limits; Hardware security key MFA required for all approvers on High and Critical accounts; Session timeouts and re-authentication for sensitive operations; Network restrictions: IP whitelisting, VPN requirements where supported, geographic access restrictions; Separation of duties enforced: initiators cannot approve their own transactions, admins cannot unilaterally execute withdrawals
+  Missed: Platform configurations documented and reviewed at least quarterly
+- **/treasury-operations/registration-documents** → Security Configuration Template — **full**
+  Met: Transaction policy rules configured: multi-approval workflows, approval thresholds scaled to transaction value, address whitelisting with cooling-off periods, velocity/spending limits; Hardware security key MFA required for all approvers on High and Critical accounts; Session timeouts and re-authentication for sensitive operations; Network restrictions: IP whitelisting, VPN requirements where supported, geographic access restrictions; Separation of duties enforced: initiators cannot approve their own transactions, admins cannot unilaterally execute withdrawals; Platform configurations documented and reviewed at least quarterly
+
+### tro-3.1.2: Credential and Secret Management
+**Full baselines:**
+  1. Covers API keys, service accounts, owner/admin credentials, and signing keys
+  2. Credentials stored in dedicated secret management systems, not in code, documents, or shared drives
+  3. Owner and admin credentials isolated from day-to-day operational access
+  4. Credential rotation schedule defined and enforced
+  5. Access to credentials logged and monitored
+
+**Evaluator's assessment:**
+- **/treasury-operations/enhanced-controls** → Access Security — **partial**
+  Met: Credentials stored in dedicated secret management systems, not in code, documents, or shared drives; Owner and admin credentials isolated from day-to-day operational access
+  Missed: Covers API keys, service accounts, owner/admin credentials, and signing keys; Credential rotation schedule defined and enforced; Access to credentials logged and monitored
+- **/wallet-security/seed-phrase-management**  — **partial**
+  Met: Credentials stored in dedicated secret management systems, not in code, documents, or shared drives
+  Missed: Covers API keys, service accounts, owner/admin credentials, and signing keys; Owner and admin credentials isolated from day-to-day operational access; Credential rotation schedule defined and enforced; Access to credentials logged and monitored
+**Gaps:** Credential rotation schedule defined and enforced; Access to credentials logged and monitored
+
+### tro-3.1.3: Access Reviews for Treasury Systems
+**Full baselines:**
+  1. Access reviews conducted at least quarterly for High/Critical accounts, annually for others
+  2. Reviews verify each user still requires their current access level
+  3. Access promptly revoked when personnel change roles or leave
+
+**Evaluator's assessment:**
+- **/treasury-operations/registration-documents** → Quarterly Review Template — **full**
+  Met: Access reviews conducted at least quarterly for High/Critical accounts, annually for others; Reviews verify each user still requires their current access level; Access promptly revoked when personnel change roles or leave
+
+### tro-3.1.4: Personnel Operational Security
+**Full baselines:**
+  1. Device security requirements documented: dedicated devices for custody access, full disk encryption, automatic screen lock
+  2. Signing devices (hardware wallets) securely stored when not in use
+  3. Backup materials (seed phrases, recovery keys) stored securely with geographic distribution
+  4. VPN mandatory for all remote treasury platform access
+  5. Travel security procedures for personnel with signing or custody access capabilities
+  6. Mobile devices used as second factors have endpoint security monitoring
+
+**Evaluator's assessment:**
+- **/treasury-operations/enhanced-controls** → Device Security — **full**
+  Met: Device security requirements documented: dedicated devices for custody access, full disk encryption, automatic screen lock; VPN mandatory for all remote treasury platform access; Mobile devices used as second factors have endpoint security monitoring
+  Missed: Signing devices (hardware wallets) securely stored when not in use; Backup materials (seed phrases, recovery keys) stored securely with geographic distribution; Travel security procedures for personnel with signing or custody access capabilities
+- **/wallet-security/seed-phrase-management** → Secure Storage Practices — **partial**
+  Met: Backup materials (seed phrases, recovery keys) stored securely with geographic distribution
+  Missed: Device security requirements documented: dedicated devices for custody access, full disk encryption, automatic screen lock; Signing devices (hardware wallets) securely stored when not in use; VPN mandatory for all remote treasury platform access; Travel security procedures for personnel with signing or custody access capabilities; Mobile devices used as second factors have endpoint security monitoring
+- **/multisig-for-protocols/personal-security-opsec** → Device Security — **full**
+  Met: Device security requirements documented: dedicated devices for custody access, full disk encryption, automatic screen lock; Signing devices (hardware wallets) securely stored when not in use; Backup materials (seed phrases, recovery keys) stored securely with geographic distribution; VPN mandatory for all remote treasury platform access; Travel security procedures for personnel with signing or custody access capabilities; Mobile devices used as second factors have endpoint security monitoring
+
+### tro-4.1.1: Transaction Verification and Execution
+**Full baselines:**
+  1. Pre-execution verification includes: recipient address validation, amount verification, network confirmation, and transaction simulation
+  2. Test transactions required before sending to new addresses
+  3. Address verified through multiple independent sources; never copied from email, chat, or transaction history
+  4. Multi-party confirmation required: minimum 2 internal personnel for large transfers
+  5. Specific procedures for receiving large incoming transfers (address generation, bidirectional test, sender coordination)
+  6. Specific procedures for OTC transactions where applicable
+  7. High-value transfers (organization-defined threshold) require video call verification with liveness checks
+  8. All transaction parameters read aloud and confirmed before execution
+
+**Evaluator's assessment:**
+- **/treasury-operations/transaction-verification** → Execution Protocol — **full**
+  Met: Pre-execution verification includes: recipient address validation, amount verification, network confirmation, and transaction simulation; Test transactions required before sending to new addresses; Address verified through multiple independent sources; never copied from email, chat, or transaction history; Multi-party confirmation required: minimum 2 internal personnel for large transfers; Specific procedures for receiving large incoming transfers (address generation, bidirectional test, sender coordination); High-value transfers (organization-defined threshold) require video call verification with liveness checks; All transaction parameters read aloud and confirmed before execution
+  Missed: Specific procedures for OTC transactions where applicable
+**Gaps:** Specific procedures for OTC transactions where applicable
+
+### tro-4.1.2: Signer and Approver Knowledge
+**Full baselines:**
+  1. Knowledge covers: transaction verification procedures, address validation techniques, social engineering awareness, emergency procedures
+  2. Competence demonstrated before authorization (e.g., verifying a test transaction end-to-end)
+  3. Knowledge refreshed annually; updated within 30 days of significant procedure changes
+  4. Covers custody-platform-specific workflows and policy engine rules
+
+**Evaluator's assessment:**
+- **/multisig-for-protocols/implementation-checklist** → Transaction Verification — **partial**
+  Met: Knowledge covers: transaction verification procedures, address validation techniques, social engineering awareness, emergency procedures; Competence demonstrated before authorization (e.g., verifying a test transaction end-to-end)
+  Missed: Knowledge refreshed annually; updated within 30 days of significant procedure changes; Covers custody-platform-specific workflows and policy engine rules
+**Gaps:** Knowledge refreshed annually; updated within 30 days of significant procedure changes; Covers custody-platform-specific workflows and policy engine rules
+
+### tro-4.1.3: Secure Communication Procedures
+**Full baselines:**
+  1. Dedicated primary and backup channels on different platforms
+  2. End-to-end encryption, MFA required, invitation-based membership
+  3. Identity verified as standard procedure during signing/approval operations (e.g., code phrases, video call, secondary authenticated channel)
+  4. Anti-social-engineering protocols: established verification procedures for address changes or unusual requests
+  5. Documented procedures for channel compromise including switching to backup channels and out-of-band verification
+  6. All treasury personnel trained on these procedures; compromise response tested annually
+
+**Evaluator's assessment:**
+- **/multisig-for-protocols/emergency-procedures** → Communication Account Compromise — **partial**
+  Met: Identity verified as standard procedure during signing/approval operations (e.g., code phrases, video call, secondary authenticated channel); Anti-social-engineering protocols: established verification procedures for address changes or unusual requests; Documented procedures for channel compromise including switching to backup channels and out-of-band verification
+  Missed: Dedicated primary and backup channels on different platforms; End-to-end encryption, MFA required, invitation-based membership; All treasury personnel trained on these procedures; compromise response tested annually
+**Gaps:** Dedicated primary and backup channels on different platforms; End-to-end encryption, MFA required, invitation-based membership; All treasury personnel trained on these procedures; compromise response tested annually
+
+### tro-5.1.2: Position Lifecycle Management
+**Full baselines:**
+  1. Entry procedures: smart contract address verification against multiple independent sources, token approval management (minimal approvals, revocation after use)
+  2. Emergency withdrawal/exit procedures documented for all active positions
+  3. Alternative access methods documented in case primary UIs are unavailable (direct contract interaction, CLI tools, alternative frontends)
+  4. Unbonding/unstaking timelines understood and factored into liquidity planning
+
+**Evaluator's assessment:**
+- **/treasury-operations/transaction-verification** → Transaction Parameter Security — **partial**
+  Met: Entry procedures: smart contract address verification against multiple independent sources, token approval management (minimal approvals, revocation after use)
+  Missed: Emergency withdrawal/exit procedures documented for all active positions; Alternative access methods documented in case primary UIs are unavailable (direct contract interaction, CLI tools, alternative frontends); Unbonding/unstaking timelines understood and factored into liquidity planning
+**Gaps:** Emergency withdrawal/exit procedures documented for all active positions; Alternative access methods documented in case primary UIs are unavailable (direct contract interaction, CLI tools, alternative frontends); Unbonding/unstaking timelines understood and factored into liquidity planning
+
+### tro-6.1.1: Monitoring and Threat Awareness
+**Full baselines:**
+  1. Transaction monitoring: unusual amounts, unexpected destinations, failed transactions, policy violations
+  2. Account state monitoring: balance changes, configuration modifications, new device enrollments, authentication anomalies
+  3. External threat intelligence: protocol vulnerabilities, DeFi/staking risks, relevant security incidents in the ecosystem
+  4. Vendor/platform monitoring: custody platform status, infrastructure alerts, service availability
+  5. Compliance monitoring: transactions and wallet addresses screened for sanctions and compliance risk
+  6. Protocol and position monitoring: deployed protocol health, governance changes, TVL shifts, collateral ratios, reward accrual, liquidation risks
+  7. Alerting with defined severity levels and escalation paths
+  8. Critical alerts (large unexpected transactions, unauthorized access attempts) trigger immediate investigation
+  9. Monitoring system integrity protected — alerts triggered when monitoring configurations are changed, disabled, or degraded
+
+**Evaluator's assessment:**
+- **/treasury-operations/enhanced-controls** → Security Monitoring & Logging — **partial**
+  Met: Transaction monitoring: unusual amounts, unexpected destinations, failed transactions, policy violations; Account state monitoring: balance changes, configuration modifications, new device enrollments, authentication anomalies; Alerting with defined severity levels and escalation paths; Critical alerts (large unexpected transactions, unauthorized access attempts) trigger immediate investigation
+  Missed: External threat intelligence: protocol vulnerabilities, DeFi/staking risks, relevant security incidents in the ecosystem; Vendor/platform monitoring: custody platform status, infrastructure alerts, service availability; Compliance monitoring: transactions and wallet addresses screened for sanctions and compliance risk; Protocol and position monitoring: deployed protocol health, governance changes, TVL shifts, collateral ratios, reward accrual, liquidation risks; Monitoring system integrity protected — alerts triggered when monitoring configurations are changed, disabled, or degraded
+**Gaps:** External threat intelligence: protocol vulnerabilities, DeFi/staking risks, relevant security incidents in the ecosystem; Vendor/platform monitoring: custody platform status, infrastructure alerts, service availability; Compliance monitoring: transactions and wallet addresses screened for sanctions and compliance risk; Protocol and position monitoring: deployed protocol health, governance changes, TVL shifts, collateral ratios, reward accrual, liquidation risks; Monitoring system integrity protected — alerts triggered when monitoring configurations are changed, disabled, or degraded
+
+### tro-6.1.2: Incident Response Plan
+**Full baselines:**
+  1. Severity levels defined with escalation procedures specific to treasury operations
+  2. Containment procedures: fund protection actions (emergency freeze, transfer to secure cold storage, policy lockdown)
+  3. Covers key scenarios: custody platform compromise, unauthorized transaction, signer key compromise, vendor breach
+  4. Emergency contacts pre-documented: custody provider security team, SEAL 911, legal counsel
+  5. Communication plan for stakeholders
+  6. Drills conducted at least annually; after major procedure changes
+  7. Drill documentation includes: date, participants, response times, issues identified, improvements made
+
+**Evaluator's assessment:**
+- **/multisig-for-protocols/emergency-procedures** → Emergency Notification Template — **partial**
+  Met: Severity levels defined with escalation procedures specific to treasury operations; Containment procedures: fund protection actions (emergency freeze, transfer to secure cold storage, policy lockdown); Covers key scenarios: custody platform compromise, unauthorized transaction, signer key compromise, vendor breach; Emergency contacts pre-documented: custody provider security team, SEAL 911, legal counsel
+  Missed: Communication plan for stakeholders; Drills conducted at least annually; after major procedure changes; Drill documentation includes: date, participants, response times, issues identified, improvements made
+**Gaps:** Communication plan for stakeholders; Drills conducted at least annually; after major procedure changes; Drill documentation includes: date, participants, response times, issues identified, improvements made
+
+### tro-7.1.2: Backup Infrastructure and Alternate Access
+**Full baselines:**
+  1. Alternate access methods for custody platforms documented and tested (e.g., API access, mobile app, secondary UI)
+  2. Backup RPC providers configured
+  3. Procedures for operating treasury if primary custody platform is unavailable
+  4. Backup infrastructure tested at least annually
+
+**Evaluator's assessment:**
+- **/multisig-for-protocols/backup-signing-and-infrastructure** → UI Alternatives — **full**
+  Met: Alternate access methods for custody platforms documented and tested (e.g., API access, mobile app, secondary UI); Backup RPC providers configured; Procedures for operating treasury if primary custody platform is unavailable; Backup infrastructure tested at least annually
+
+### tro-8.1.1: Financial Recordkeeping and Reconciliation
+**Full baselines:**
+  1. All treasury transactions recorded with categorization, documentation, and authorization chain
+  2. Periodic reconciliation between custody platform records, on-chain balances, and accounting records
+  3. Reconciliation frequency scaled to account classification: daily for Active Operations, weekly for Warm Storage, monthly for Cold Vault
+  4. Discrepancies investigated and resolved promptly
+  5. Treasury reporting procedures documented with defined cadence and audience
+
+**Evaluator's assessment:**
+- **/treasury-operations/registration-documents** → Security Configuration Template — **partial**
+  Met: All treasury transactions recorded with categorization, documentation, and authorization chain
+  Missed: Periodic reconciliation between custody platform records, on-chain balances, and accounting records; Reconciliation frequency scaled to account classification: daily for Active Operations, weekly for Warm Storage, monthly for Cold Vault; Discrepancies investigated and resolved promptly; Treasury reporting procedures documented with defined cadence and audience
+**Gaps:** Periodic reconciliation between custody platform records, on-chain balances, and accounting records; Reconciliation frequency scaled to account classification: daily for Active Operations, weekly for Warm Storage, monthly for Cold Vault; Discrepancies investigated and resolved promptly; Treasury reporting procedures documented with defined cadence and audience
+
+## FALSE-NEGATIVE CHECK (5 controls marked "no coverage")
+
+Verify these truly have no relevant framework page. If any page below partially covers them, note it.
+
+### tro-1.1.1: Treasury Operations Owner
+**Baselines:** Accountability scope covers policy upkeep, security reviews, operational hygiene, access control oversight, and incident escalation
+
+### tro-2.1.2: Fund Allocation Limits and Rebalancing
+**Baselines:** Maximum allocation defined per wallet, per custody provider, and per chain; Rebalancing triggers documented (e.g., when a wallet exceeds its allocation ceiling or falls below operational minimums); Allocation limits reviewed periodically and after significant treasury changes (+1 more)
+
+### tro-5.1.1: Protocol Evaluation and Exposure Limits
+**Baselines:** Due diligence process for all protocols before deployment: smart contract audit status, team reputation, TVL history, insurance coverage; Exposure limits defined per protocol, per chain, and per deployment category (DeFi, staking, liquid staking, etc.); Limits reviewed periodically and after significant market or protocol changes (+1 more)
+
+### tro-7.1.1: Vendor Security Management
+**Baselines:** Initial due diligence before adoption: security certifications (SOC 2, ISO 27001), audit history, insurance coverage, incident history; Ongoing monitoring: SOC report currency, security incident notifications, service availability tracking; Contractual security requirements verified periodically (at least annually) (+1 more)
+
+### tro-8.1.2: Insurance Coverage
+**Baselines:** Coverage scope documented: what's covered (custody theft, hack, insider fraud) and what's excluded; Coverage amounts appropriate relative to assets held; Custody provider's insurance evaluated as part of vendor due diligence (+1 more)
+
+---
+
+## FRAMEWORK PAGES (9 pages)
+
+### PAGE: /multisig-for-protocols/backup-signing-and-infrastructure
+
+TagList,
+  AttributionList,
+  TagProvider,
+  TagFilter,
+  ContributeFooter,
+} from "../../../components";
+
+
+
+
+# Backup Signing & Infrastructure
+
+
+
+
+If the default interfaces for either Safe or Squads are down or suspected of being compromised, these alternatives
+enable continued critical signing operations. As a signer, you should familiarize yourself with these tools and practice
+signing transactions with your team.
+
+## UI Alternatives
+
+### EVM Networks
+
+**Eternal Safe - Decentralized fork of Safe\{Wallet\}**
+
+- GitHub: [https://github.com/eternalsafe/wallet](https://github.com/eternalsafe/wallet)
+- Hosted (IPFS): [https://eternalsafe.eth.limo](https://eternalsafe.eth.limo) (requires bring your own RPC)
+- Local: Can be downloaded and run locally
+
+Note: Local/alternative UIs may not be actively maintained. Treat them as emergency options and perform extra
+verification. Please DYOR.
+
+### Solana
+
+**Squads Public Client - Open source Squads V4 interface: **
+
+- GitHub: [https://github.com/Squads-Protocol/public-v4-client](https://github.com/Squads-Protocol/public-v4-client)
+- Features: Verifiable build, self-hostable with Docker, IPFS distribution
+- Local: Can be built and run locally
+
+### Mobile (Safe)
+
+**Safe Mobile Apps: **
+
+- GitHub: [https://github.com/safe-global/safe-wallet-monorepo/tree/dev/apps/mobile](https://github.com/safe-global/safe-wallet-monorepo/tree/dev/apps/mobile)
+- App Store: [https://apps.apple.com/us/app/safe-mobile/id6748754793](https://apps.apple.com/us/app/safe-mobile/id6748754793)
+- Play Store: [https://play.google.com/store/apps/details?id=global.safe.mobileapp](https://play.google.com/store/apps/details?id=global.safe.mobileapp)
+
+## RPC Backup Options
+
+### Basic guidance:
+
+- Multiple providers: Set up accounts with 2-3 different RPC services
+  - eg. Alchemy, Infura, Chainstack, Quicknode, Tenderly
+- Avoid correlation: Choose providers that don't share infrastructure, if that information is available
+- Private RPCs preferred: Public RPC URLs are typically not sufficient for reliable operation
+
+### Administrator responsibilities
+
+Ensure signer preparedness:
+
+- Provide access to offline UI tools listed above
+- Verify signers have practiced using backup interfaces
+- Test backup RPCs during non-emergency periods
+- Document procedures for switching to backup infrastructure
+
+## Block Explorer Backup Options
+
+### EVM Networks
+
+Etherscan provides the default block explorer for nearly all EVM chains. In the event that Etherscan is compromised or
+goes down, it is important to have backup options that can be used for monitoring and investigating transactions.
+
+**Blockscout - Open source Etherscan alternative: **
+
+- [https://www.blockscout.com/](https://www.blockscout.com/)
+- Available for all EVM networks
+- Can also be [self-hosted](https://github.com/blockscout/blockscout), although it requires significant time to run full
+  node and index
+
+More explorers: A broader list of network explorers is maintained here: [https://explorer.swiss-knife.xyz/](https://explorer.swiss-knife.xyz/)
+
+### Solana Networks
+
+Both explorer.solana.com and Solscan are reliable options for Solana transaction exploration and decoding.
+
+**explorer.solana.com** - [https://explorer.solana.com/](https://explorer.solana.com/)
+
+- Can be [self-hosted](https://github.com/solana-foundation/explorer) using open source code
+
+**Solscan** - [https://solscan.io/](https://solscan.io/)
+
+## Preparation
+
+**It is recommended to download dependencies ahead of time and store them in a secure location** so they are easily
+accessible during emergencies.
+
+## EVM Networks
+
+### Eternal Safe - Decentralized fork of Safe\{Wallet\}
+
+#### Access Options
+
+- **GitHub**: [https://github.com/eternalsafe/wallet](https://github.com/eternalsafe/wallet)
+- **Hosted (IPFS)**: [https://eternalsafe.eth.limo](https://eternalsafe.eth.limo) (requires bring your own RPC)
+- **Local**: Can be downloaded and run locally
+
+#### Setup
+
+1. Select network and enter an RPC URL
+   <div align="center">
+     <img
+       src="https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/eternal-safe-network-selection.png"
+       alt="Eternal Safe network selection"
+       style={{ height: "400px" }}
+     />
+     <p>
+       <em>
+         Eternal Safe network selection screen: choose your network and enter an
+         RPC URL
+       </em>
+     </p>
+   </div>
+2. Enter Safe address and load
+   ![Eternal Safe address entry](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/eternal-safe-address-entry.png)
+3. Eternal Safe will automatically detect Ether balances but not ERC20 tokens. They can be added manually
+   ![Eternal Safe token configuration](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/eternal-safe-token-configuration.png)
+
+#### Transaction Verification
+
+**Critical**: It is still essential to verify hashes and calldata from Eternal Safe. Follow the verification steps in
+[Safe Multisig: Step-by-Step Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification).
+
+#### Smart Link System
+
+Once a transaction has been signed by one signer, a **Smart Link** is created which can be forwarded to the next signer
+to add their signature. The transactions do not go to any centralized backend.
+
+**Example Smart Link:**
+
+```
+Please sign this Eternal Safe transaction for the Safe: base:0xA79C6968E3c75aE4eF388370d1f142720D498fEC.
+Current confirmations: 1 of 2.
+https://eternalsafe.eth.limo/transactions/tx/?safe=base:0xA79C6968E3c75aE4eF388370d1f142720D498fEC&tx=eyJzaWduYXR1cmVzIjp7ImRhdGFUeXBlIjoiTWFwIiwidmFsdWUiOltbIjB4NDBiYjMyZjA4NjJkMjI3ODEzYzg2ZmQ4M2E3YjNjOWRiOTA3NGUyYSIseyJzaWduZXIiOiIweDQwYkIzMkYwODYyRDIyNzgxM2M4NkZEODNBN0IzYzlkYjkwNzRFMkEiLCJkYXRhIjoiMHgwZDMxZTZjODIxZjBhMGZlM2M5NmNlZWY4ZDNhM2JhZmU3YmZmZTliODQ0ZWNkYzBkYWNmNzc0MzFkODQ0NjU4MTgwZjUwNmZlMjZiZjMzOTQwY2VhOTJiMzlhNDNjODRkMDRhNThiMGY1ODQ2NzhlNzE0YTllMWJkMzE0NTg5ZjFiIn1dXX0sImRhdGEiOnsiZGF0YSI6IjB4IiwiYmFzZUdhcyI6IjAiLCJnYXNQcmljZSI6IjAiLCJzYWZlVHhHYXMiOiIwIiwiZ2FzVG9rZW4iOiIweDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAiLCJub25jZSI6NCwicmVmdW5kUmVjZWl2ZXIiOiIweDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAiLCJ2YWx1ZSI6IjEwMDAwMDAwMDAwMDAwMDAiLCJ0byI6IjB4RTBiY2ZlNWUzMEFCYTBCNDZmMTNCMEMyNENiQzQ3MERDQTNlYjg2NSIsIm9wZXJhdGlvbiI6MH19
+```
+
+#### Execution
+
+Once all signatures are collected, execute the transaction. **Note**: Prior to execution you can manually simulate using
+Tenderly by entering the transaction data, but an automatic simulation link will not be available.
+
+## Solana
+
+### Squads Public Client - Open source Squads V4 interface
+
+#### Access Options
+
+- **GitHub**: [https://github.com/Squads-Protocol/public-v4-client](https://github.com/Squads-Protocol/public-v4-client)
+- **Hosted**: [https://backup.app.squads.so/](https://backup.app.squads.so/)
+- **Features**: Verifiable build, self-hostable with Docker, IPFS distribution
+- **Local**: Can be built and run locally
+
+#### Setup
+
+1. If running locally, follow setup instructions in [https://github.com/Squads-Protocol/public-v4-client](https://github.com/Squads-Protocol/public-v4-client)
+ and access via `http://localhost:8080`
+2. Enter RPC URL in settings
+   ![Squads RPC configuration](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/squads-rpc-configuration.png)
+3. Enter multisig address in the **lower** text box (Search for Multisig Config) and select the detected Multisig Config
+   ![Squads multisig selection](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/squads-multisig-selection.png)
+
+#### Transaction Operations
+
+1. Create, approve, or execute transactions. _Smart Links_ are not needed for Solana as all transactions are on chain
+   and accessible via the RPC without an API
+   ![Squads transaction interface](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/squads-transaction-interface.png)
+
+## Security Considerations
+
+### Enhanced Verification
+
+When using backup systems:
+
+- **Extra caution required**: Be more thorough with verification procedures
+- **Multiple verification methods**: Use additional tools to cross-check transaction details
+- **Team confirmation**: Verify with other signers before proceeding with critical transactions
+- **Documentation**: Record use of backup systems and any issues encountered
+
+### Risk Assessment
+
+- **Delay non-critical operations**: Consider postponing non-urgent transactions until primary systems recover
+- **Emergency operations only**: For critical emergency responses, proceed with enhanced verification
+- **Communication**: Keep team informed about system status and verification procedures
+
+## Testing and Preparation
+
+### Regular Practice
+
+- **Monthly testing**: Practice using backup interfaces during normal operations
+- **Team coordination**: Ensure all signers can operate backup systems
+- **Process documentation**: Update procedures based on practice sessions
+
+### Emergency Drills
+
+- **Simulated outages**: Practice coordinating with backup systems during drills
+- **Communication testing**: Verify backup communication channels work with backup UIs
+- **Time measurement**: Track how long backup system activation takes
+
+## Troubleshooting
+
+### Common Issues
+
+- **RPC connectivity**: Switch to alternative RPC providers if connection fails
+- **Transaction loading**: Refresh or try different network endpoints
+- **Signature verification**: Use multiple verification tools when in doubt
+
+### Support Resources
+
+- **GitHub documentation**: Refer to project documentation for technical issues
+- **Team assistance**: Coordinate with other signers for problem-solving
+- **Alternative tools**: Have multiple backup options available
+
+## Related Documents
+
+- [Safe Multisig: Step-by-Step
+Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification) - Verification procedures
+- [Emergency Procedures](/multisig-for-protocols/emergency-procedures) - General emergency response
+- [Communication Setup](/multisig-for-protocols/communication-setup) - Backup communication during outages
+
+---
+
+### PAGE: /multisig-for-protocols/emergency-procedures
+
+# Emergency Procedures
+
+
+
+
+When security incidents occur, quick and decisive action is critical. This page covers procedures for key compromise,
+lost access, and communication breaches.
+
+## Key Compromise
+
+### Immediate Actions (Within 30 Minutes)
+
+1. **Stop operations** - Halt all non-emergency transactions
+2. **Notify team** - Alert via all communication channels using emergency notification template
+3. **Assess scope** - Determine which keys may be compromised
+4. **Escalate** - Contact Security team immediately
+5. **Document** - Record timeline and details
+
+### Recovery Process
+
+1. **Isolate** - Quarantine potentially compromised devices
+2. **New hardware setup** - Set up fresh wallet with new seed following [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds)
+3. **Coordinate replacement** - Plan signer replacement transaction with team
+4. **Execute replacement** - Replace compromised signer on multisig, following steps for signer rotation in [Secure
+   Multisig Best Practices](/wallet-security/secure-multisig-best-practices)
+5. **Verify security** - Confirm new setup before resuming operations
+
+## Lost Key Access
+
+### Immediate Steps
+
+1. **Try backup device first** if available
+2. **Contact team immediately** via backup communication channels
+3. **Do not panic** - Lost access doesn't mean compromised keys
+4. **Document the situation** - Record what happened and when
+
+### Identity Verification Process
+
+Since you can't sign with your key, verify identity through alternative methods:
+
+- **Video call** with other signers
+- **Authentication** via verified social media account
+- **Other pre-arranged verification methods**
+
+### Replacement Coordination
+
+1. **Generate new hardware wallet** following standard setup procedures in [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds)
+2. **Verify new address** through identity verification process above
+3. **Coordinate timing** with other signers for replacement transaction
+4. **Execute replacement** once team confirms identity
+5. **Update documentation** with new signer information
+
+## Communication Account Compromise
+
+### If Telegram/Signal/Discord Gets Taken Over
+
+#### Immediate Actions
+
+1. **Assume all recent messages are suspect** - Don't trust recent communication
+2. **Use backup channels** to alert team about compromise
+3. **Change passwords** and enable additional security on compromised account
+
+#### Team Verification Process
+
+**For the compromised person:**
+
+- Use alternative contact methods (email, phone, other platforms)
+- Verify identity through video call or pre-arranged methods
+- Provide proof of the compromise (screenshots, platform confirmation)
+
+**For other team members:**
+
+- Verify all recent requests from compromised account
+- Cancel any pending transactions initiated via compromised communication
+- Require additional verification for any future requests until resolved
+
+#### Recovery Steps
+
+1. **Regain account control** through platform recovery processes
+2. **Enable maximum security** (2FA, security keys, session management)
+3. **Review recent message history** for unauthorized communications
+4. **Alert team** when account is secured and verified clean
+5. **Resume normal operations** only after team confirms account security
+
+## Emergency Notification Template
+
+Use this template for security incidents or key compromises:
+
+```
+Subject: [URGENT] Multisig Security Incident - [Multisig Name]
+
+Immediate details:
+- Multisig address: [ADDRESS]
+- Classification: [Impact Level / Operational Type]
+- Incident type: [Key Compromise / Communication Failure / System Issue]
+- Time of discovery: [TIMESTAMP]
+- Reporting signer: [NAME/HANDLE]
+
+Situation summary: [Brief description of what happened and current status]
+
+Immediate actions taken:
+□ Stopped non-emergency operations
+□ Isolated affected systems
+□ Notified team members
+□ [Other actions]
+
+Next steps required:
+□ Security team assessment
+□ Key rotation process
+□ Emergency transaction execution
+□ [Other actions]
+
+Current multisig status:
+- Available signers: [X/Y]
+- Communication status: [Operational/Compromised]
+- Operational capability: [Full/Limited/Suspended]
+```
+
+## Emergency Communication Protocols
+
+### Multi-Channel Notification
+
+- **Primary channel**: Alert via main communication channel
+- **Backup channels**: Simultaneously notify via backup platforms
+- **Emergency contacts**: Use emergency contact procedures if established
+
+### Identity Verification
+
+- **Code words**: Use pre-established verification phrases
+- **Multiple confirmations**: Verify through multiple channels
+- **Video verification**: Use video calls for critical confirmations
+
+### Information Sharing
+
+- **Need-to-know basis**: Share only essential information
+- **Secure channels only**: Use most secure available communication
+- **Documentation**: Record all emergency communications
+
+## Operational Emergency Procedures
+
+### For Emergency Response Multisigs
+
+#### Rapid Response Protocol
+
+1. **Immediate assessment** - Determine scope and urgency
+2. **Signer activation** - Contact threshold number of signers
+3. **Streamlined verification** - Use minimal verification appropriate for risk level
+4. **Execute response** - Implement emergency measures
+5. **Post-action review** - Document and assess response effectiveness
+
+#### 24/7 Availability
+
+- **Geographic distribution** - Ensure coverage across time zones
+- **Backup signers** - Have additional signers available for activation
+- **Communication redundancy** - Multiple ways to reach each signer
+
+### Emergency Drill Procedures
+
+#### Regular Testing Schedule
+
+- **Quarterly**: Communication system tests
+- **Bi-annually**: Emergency paging system tests
+- **Annually**: Full emergency simulation with all signers
+
+#### Drill Components
+
+1. **Notification test** - Verify all signers receive alerts
+2. **Response time measurement** - Track time to threshold signatures
+3. **Process verification** - Ensure procedures work under pressure
+4. **Documentation review** - Update procedures based on drill results
+
+## Recovery and Post-Incident
+
+### Immediate Recovery
+
+1. **Restore operations** - Resume normal operations once threat is mitigated
+2. **Monitor for issues** - Watch for any residual security concerns
+3. **Update security measures** - Implement additional controls if needed
+
+### Post-Incident Analysis
+
+1. **Root cause analysis** - Determine how incident occurred
+2. **Process improvement** - Update procedures to prevent recurrence
+3. **Team debriefing** - Gather lessons learned from all participants
+4. **Documentation updates** - Revise emergency procedures based on experience
+
+### Communication
+
+1. **Team notification** - Inform team when incident is resolved
+2. **Stakeholder updates** - Notify relevant parties as appropriate
+3. **Documentation** - Complete incident report for future reference
+
+## Emergency Contact Information
+
+### Security Team Contact
+
+- **Email**: [Security team email]
+- **Emergency escalation**: [24/7 emergency contact if available]
+- **Communication**: Use subject line format from emergency notification template
+
+### Internal Escalation
+
+- **Protocol leadership**: [Contact information]
+- **Technical team**: [Emergency technical contact]
+- **Legal/compliance**: [If regulatory notification required]
+
+## Related Documents
+
+- [Incident Reporting](/multisig-for-protocols/incident-reporting) - Formal incident reporting procedures
+- [Communication Setup](/multisig-for-protocols/communication-setup) - Backup communication channels
+- [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds) - Device replacement procedures
+- [Seed Phrase Management](/wallet-security/seed-phrase-management) - Key recovery procedures
+- [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec) - Account security measures
+
+---
+
+### PAGE: /multisig-for-protocols/implementation-checklist
+
+# Implementation Checklist
+
+
+
+
+This checklist ensures all multisig participants have the knowledge and skills necessary for secure operations. Complete
+all applicable sections before beginning multisig operations.
+
+## For Multisig Administrators
+
+### Planning & Setup
+
+- [ ] I have classified my multisig using the impact and operational framework from [Planning & Classification](/multisig-for-protocols/planning-and-classification)
+- [ ] I have selected appropriate thresholds based on the classification guidance
+- [ ] I have identified and verified all signers for the multisig
+- [ ] I have deployed the multisig with correct configuration
+- [ ] I have set up required modules (eg. allowance module to rescue assets)
+
+### Documentation & Communication
+
+- [ ] I have classified and documented the new multisig using templates from [Registration & Documentation](/multisig-for-protocols/registration-and-documentation)
+- [ ] I have set up primary and backup communication channels per [Communication Setup](/multisig-for-protocols/communication-setup)
+- [ ] I have tested emergency notification procedures
+- [ ] I have documented emergency contact information
+
+### Ongoing Management
+
+- [ ] I have established procedures for regular reviews and updates per [Registration & Documentation](/multisig-for-protocols/registration-and-documentation)
+- [ ] I have set up backup infrastructure and tested alternative UIs per [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)
+- [ ] I have verified all signers have completed training requirements
+- [ ] I understand signer rotation procedures for my multisig type
+
+## For Signers
+
+### Hardware & Security Setup
+
+- [ ] I have purchased recommended hardware wallet from authorized source per [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds)
+- [ ] I have set up my hardware wallet with proper firmware and PIN
+- [ ] I have created and tested backup hardware wallet with same seed
+- [ ] I have stored my seed phrase securely using approved methods from [Seed Phrase Management](/wallet-security/seed-phrase-management)
+- [ ] I have created dedicated accounts for each multisig I'm signing for
+
+### Operational Readiness
+
+- [ ] I have joined multisig communication channels (primary and backup) per [Communication Setup](/multisig-for-protocols/communication-setup)
+- [ ] I have verified my signer address using the required signature process from [Joining a Multisig](/multisig-for-protocols/joining-a-multisig)
+- [ ] I understand my multisig's classification and response time requirements
+- [ ] I have completed a test transaction with the multisig team
+
+### Transaction Verification
+
+- [ ] I can use approved verification tools (Safe CLI Utils, OpenZeppelin SafeUtils for EVM) from [Tools & Resources →
+  Transaction Verification](/wallet-security/tools-&-resources#transaction-verification)
+- [ ] I understand how to verify transaction hashes before signing
+- [ ] I can decode and verify transaction details (amounts, recipients, contract calls)
+- [ ] I have practiced verifying both simple transfers and complex transactions
+
+### Emergency Preparedness
+
+- [ ] I have downloaded backup UIs (Eternal Safe for EVM, Squads public client for Solana) per [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)
+- [ ] I know how to sign transactions when primary UI is down per [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)
+- [ ] I understand emergency procedures for key compromise and communication failures per [Emergency Procedures](/multisig-for-protocols/emergency-procedures)
+- [ ] I have tested backup communication methods with my team
+- [ ] I know who to contact for security incidents and emergencies per [Incident Reporting](/multisig-for-protocols/incident-reporting)
+
+### Personal Security
+
+- [ ] I have enabled 2FA on all accounts with approved methods (YubiKey preferred) per [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec)
+- [ ] I use dedicated devices or accounts for multisig operations when required
+- [ ] I have implemented travel security procedures appropriate for my risk level
+- [ ] I understand incident reporting procedures for security concerns
+
+### Compliance
+
+- [ ] I have read and understand all sections of this security framework
+- [ ] I understand my specific role requirements based on multisig classification
+- [ ] I know how to properly offboard when leaving a multisig role per [Offboarding](/multisig-for-protocols/offboarding)
+- [ ] I commit to following these security procedures and reporting any deviations
+
+## Specialized Training by Use Case
+
+### Emergency Response Multisigs
+
+Additional requirements from [Use Case Specific Requirements](/multisig-for-protocols/use-case-specific-requirements):
+
+- [ ] I understand 24/7 availability requirements
+- [ ] I have participated in emergency simulation drills
+- [ ] I know how to respond to emergency paging
+- [ ] I understand streamlined verification procedures for emergencies
+
+### Treasury Multisigs
+
+- [ ] I understand allowance module configuration and purpose
+- [ ] I know governance rescue procedures
+- [ ] I understand financial reporting requirements
+
+### Smart Contract Control Multisigs
+
+- [ ] I understand timelock configuration per [Use Case Specific Requirements → Timelock Configuration](/multisig-for-protocols/use-case-specific-requirements#timelock-configuration)
+- [ ] I know how to verify staged transactions
+- [ ] I understand higher threshold requirements for upgrades
+
+## Practical Skills Assessment
+
+### Transaction Verification (EVM)
+
+- [ ] I can successfully verify a Safe transaction hash using CLI tools
+- [ ] I can decode transaction calldata and identify recipients and amounts
+- [ ] I can identify risky transaction types and warnings
+- [ ] I can verify nested Safe transactions if applicable
+
+### Transaction Verification (Solana)
+
+- [ ] I can analyze Solana transaction instruction data
+- [ ] I can convert hex values to decimal for amount verification
+- [ ] I can identify different transaction types (SOL transfer, token transfer, config changes)
+
+### Emergency Procedures
+
+- [ ] I can access backup UIs and complete a transaction
+- [ ] I can contact team via backup communication channels
+- [ ] I know how to report key compromise immediately
+- [ ] I can execute identity verification procedures if needed
+
+### Tool Proficiency
+
+- [ ] I am comfortable using my hardware wallet for signing
+- [ ] I can navigate backup block explorers
+- [ ] I can use alternative RPC endpoints
+- [ ] I understand how to manually simulate transactions
+
+## Documentation Review
+
+### Required Reading Completed
+
+- [ ] [Secure Multisig Best Practices](/wallet-security/secure-multisig-best-practices) - Core requirements for all multisigs
+- [ ] [Hardware Wallet Setup](/wallet-security/intermediates-&-medium-funds) - Device security requirements
+- [ ] [Seed Phrase Management](/wallet-security/seed-phrase-management) - Key protection procedures
+- [ ] [Safe Multisig: Step-by-Step
+Verification](/wallet-security/signing-and-verification/secure-multisig-safe-verification) - Signing procedures
+- [ ] [Emergency Procedures](/multisig-for-protocols/emergency-procedures) - Crisis response protocols
+- [ ] [Personal Security (OpSec)](/multisig-for-protocols/personal-security-opsec) - Account and device security
+
+### Role-Specific Documentation
+
+**For Administrators:**
+
+- [ ] [Planning & Classification](/multisig-for-protocols/planning-and-classification)
+- [ ] [Setup & Configuration](/multisig-for-protocols/setup-and-configuration)
+- [ ] [Registration & Documentation](/multisig-for-protocols/registration-and-documentation)
+- [ ] [Communication Setup](/multisig-for-protocols/communication-setup)
+- [ ] [Registration & Documentation](/multisig-for-protocols/registration-and-documentation)
+
+**For Specialized Use Cases:**
+
+- [ ] [Use Case Specific Requirements](/multisig-for-protocols/use-case-specific-requirements)
+- [ ] [Backup Signing & Infrastructure](/multisig-for-protocols/backup-signing-and-infrastructure)
+- [ ] [Use Case Specific Requirements → Timelock Configuration](/multisig-for-protocols/use-case-specific-requirements#timelock-configuration)
+  (if applicable)
+
+## Certification and Acknowledgment
+
+### Training Completion
+
+- [ ] I have completed all applicable training requirements
+- [ ] I have successfully demonstrated practical skills
+- [ ] I understand the security implications of my role
+- [ ] I acknowledge my responsibilities as a multisig participant
+
+### Ongoing Commitment
+
+- [ ] I commit to following all security procedures outlined in this framework
+- [ ] I will report any security incidents or concerns promptly
+- [ ] I will participate in regular training updates and refreshers
+- [ ] I will maintain the required level of security for my role
+
+### Trainer Verification (if applicable)
+
+**For organizations requiring formal training:**
+
+Trainer: _________________ Date: _________________
+
+Trainee has demonstrated competency in:
+
+- [ ] Transaction verification procedures
+- [ ] Emergency response protocols
+- [ ] Security best practices
+- [ ] Role-specific requirements
+
+**Signature:** _________________
+
+## Refresher Training Schedule
+
+### Regular Updates
+
+- **Monthly**: Review emergency procedures and contact information
+- **Quarterly**: Practice backup system usage and emergency drills
+- **Annually**: Complete full framework review and updates
+- **As needed**: Training on new tools, procedures, or threats
+
+### Trigger Events
+
+Additional training required after:
+
+- Framework updates or changes
+- Security incidents affecting the team
+- New tool adoption
+- Role changes or additional responsibilities
+
+## Related Documents
+
+All documents in this framework serve as training materials. Refer to individual documents for detailed procedures and
+requirements specific to your role.
+
+---
+
+### PAGE: /multisig-for-protocols/personal-security-opsec
+
+# Personal Security (OpSec)
+
+
+
+
+## Account Security
+
+### Basic requirements
+
+- 2FA enabled on all accounts (authenticator apps or hardware keys)
+- Password manager with unique, strong passwords for every account
+- Remove phone numbers from account recovery options where possible
+- Regular security checkups and removal of unused app permissions
+- Backup email for account recovery (separate from primary email)
+
+### For extra security
+
+**YubiKeys**: Use hardware security keys instead of authenticator apps
+
+- Provides stronger protection against phishing and SIM swapping
+- Recommended: 3 keys (primary, backup, secure storage)
+- Models: YubiKey 5C NFC, YubiKey 5C Nano
+
+**Cold backup accounts**: Separate email/phone for sensitive account recovery
+
+- Backup / cold accounts are tied to sensitive accounts (AppleID, Telegram, Signal, WhatsApp, Password Manager etc).
+  Such email addresses must never be shared with anyone and kept private to remain secure and not targeted.
+
+Example: random44@gmail is tied to your AppleID, and you are only logged in (the email) on a separate secure device. If
+your main device (laptop) gets compromised, you will be able to recover your account or revoke sessions, moreover your
+cold account won't be affected / compromised. It prevents people from targeting your accounts by not knowing your email
+linked to it.
+
+- Use different providers from primary accounts (Gmail, Proton)
+- Only access from secure devices
+- Never used for regular communications
+
+## Device Security
+
+### Basic requirements
+
+- Full disk encryption enabled (FileVault/BitLocker)
+- Automatic updates enabled on all devices
+- Screen lock after 5 minutes inactivity on computers, 30 seconds on mobile
+- Strong passcodes (6+ digits or alphanumeric on mobile)
+- Endpoint protection software on computers
+- No admin rights for daily use accounts (create separate admin account)
+
+### For extra security
+
+**Dedicated signing device**: Clean laptop/tablet used only for multisig operations
+
+- Minimal software installation
+- Regular security updates
+- Clean restart before each use
+- Offline storage when not in use
+- Justification: Reduces attack surface for high-value operations
+
+## Network Security
+
+### Dedicated Signing Machines
+
+- Multi-sig operations must be performed on devices dedicated only to these transactions and verification tools
+- All network access should be default blocked, with only the minimum necessary IPs to execute these transaction
+signatures allowed
+- Signing devices must be operated on private, authenticated networks or over trusted VPNs
+
+### Air-Gapped Machine Options
+
+- For highest security, physically remove or disable the network interface
+- Use USB drives (with strict auto-run restrictions) or QR codes to transfer transaction data
+
+### Advanced OS-Level Controls
+
+- Consider employing SELinux or similar tools for advanced security configurations
+- Restrict file system access and inter-process communications
+
+### Network Monitoring Tools
+
+Organizations must implement active network monitoring on signing devices:
+
+- [Little Snitch](https://www.obdev.at/products/littlesnitch/index.html) for active firewall and network monitoring
+- [Lulu](https://objective-see.org/products/lulu.html) as a free, open source alternative to Little Snitch
+- [Glasswire](https://www.glasswire.com/) can be used for Windows machines
+
+### DNS Security
+
+Use [DeFi DNS Whitelist](https://github.com/0xKoda/defi-dns-whitelist/tree/main) as a firewall for dedicated signing machines.
+
+## Communication Security
+
+### Basic requirements
+
+**Signal with verified safety number verification** for multisig communications: You MUST check the codes with the
+person you are interacting to « verify » them.
+How? Click on any chat > Contact name > View Safety Number > Call on another communication channel to verify them >
+Click at the bottom "Mark as Verified".
+If the account connects on a new device these codes will change & you will receive a security notification.
+
+- Screen lock enabled on mobile devices
+- 2FA enabled on backup platforms (Telegram/Discord/Slack)
+- Privacy settings maximized on all platforms
+- Session management - remove old/unknown devices regularly
+
+### Signal configuration
+
+- Registration lock enabled
+- Signal PIN configured
+- Hide phone number (use username only)
+- Safety number verification for all contacts
+- Disappearing messages for sensitive chats
+
+### URL Navigation Safety
+
+Links to URLs containing transaction requests or confirmation data (even those provided by trusted parties) must never
+be clicked - they must be navigated to by using bookmarks or typing them out manually.
+
+### For extra security
+
+**Enhanced verification**: Advanced safety procedures for critical communications
+
+- Code words for identity verification
+- Multiple verification channels for important requests
+- Regular communication channel security audits
+
+## Travel considerations
+
+### What to bring
+
+- Primary hardware wallet only (leave backups secure at home)
+- Essential devices only (laptop + phone)
+- Emergency contact information (offline copy)
+- Own chargers and cables
+
+### What NOT to bring
+
+- Seed phrases (never travel with these)
+- Backup hardware wallets
+- USB drives with sensitive data
+- Non-essential devices
+
+### Basic travel security
+
+- Use device locks at all times
+- Avoid public WiFi (use mobile hotspot or VPN)
+- Don't leave devices unattended in hotel rooms
+- Use hotel safes for device storage when out
+- Have offline backup of emergency contacts
+
+### For extra security
+
+**Enhanced travel procedures**: Additional precautions for high-risk situations
+
+- Disable biometric unlock at airports/borders (use PIN only) - prevents forced unlocking
+- Decline hotel housekeeping services - reduces access to devices
+- Advance notification to multisig team (72 hours for critical operations)
+- Use separate carrier SIM card for travel communications
+- Professional security assessment of travel destinations
+
+## Implementation priority
+
+### Start with basics
+
+Focus on fundamental security practices first
+
+- Password manager + 2FA on all accounts
+- Device encryption and screen locks
+- Signal setup with safety number verification
+- Basic travel security practices
+
+### Add extra security
+
+Implement additional measures based on your risk level and operational needs
+
+- YubiKeys for critical accounts
+- Dedicated signing devices for high-value operations
+- Enhanced travel procedures for international travel
+- Professional security assessments for critical roles
+
+Remember: Perfect security doesn't exist - focus on practical improvements that significantly reduce your risk while
+remaining operationally feasible.
+
+For the full OpSec article, see [Operational Security](/opsec/overview).
+
+---
+
+### PAGE: /treasury-operations/classification
+
+TagList,
+  AttributionList,
+  TagProvider,
+  TagFilter,
+  ContributeFooter,
+} from "../../../components";
+
+
+
+
+# Custodial Treasury Security: Classification Framework
+
+
+
+
+Proper documentation and classification of custodial accounts is essential for institutional treasury security. This
+guide focuses on the security assessment and classification framework for crypto assets held with third-party
+custodians.
+
+> See also: [Registration Documents](./registration-documents) and [Enhanced Controls for High-Risk Accounts](./enhanced-controls)
+
+## Classification Process
+
+Use this dual classification to determine appropriate security controls for each custodial account.
+
+### Step 1: Impact Assessment
+
+Evaluate the consequences if this account is compromised or unavailable.
+
+#### Financial Impact
+
+Calculate the total value at risk in this account:
+
+- Current market value of all assets held
+- Include value of any active positions (e.g., staked assets, DeFi deposits)
+- What is the financial impact if unavailable for 7 days?
+
+#### Operational Impact
+
+Assess the consequences if this account becomes unavailable:
+
+- What specific operations require this account?
+- Do you have a secondary custody account that can handle these operations?
+- What is the reputational impact if this account is compromised or unavailable?
+
+#### Regulatory Impact
+
+Evaluate regulatory and compliance consequences:
+
+- Are assets in this account subject to regulatory reporting requirements (SEC filings, audit requirements)?
+- Does this account hold regulated assets (e.g., stablecoins subject to reserves reporting)?
+- What are the regulatory deadlines that could be missed if this account is unavailable?
+
+#### Impact Classification
+
+| Level        | Financial Exposure (% of Total Assets) | Operational Dependency                       | Regulatory Impact                                    |
+| ------------ | -------------------------------------- | -------------------------------------------- | ---------------------------------------------------- |
+| **Low**      | \<1%                                   | No critical operations depend on it          | No regulatory reporting tied to this account         |
+| **Medium**   | 1% - 10%                               | Important but alternative funding available  | Periodic reporting; delays manageable                |
+| **High**     | 10% - 25%                              | Critical operations, limited alternatives    | Regular regulatory filings; delays cause violations  |
+| **Critical** | \>25%                                  | Business-critical, no alternatives for weeks | Real-time reporting requirements; SEC filings; audit |
+
+### Step 2: Operational Assessment
+
+Evaluate how frequently and urgently this account must be accessed.
+
+#### Transaction Frequency
+
+Document typical transaction patterns:
+
+- Transactions per month
+- Typical transaction sizes
+- Predictability of transaction timing
+
+#### Access Urgency
+
+Define response time requirements:
+
+- What is the maximum acceptable delay for routine transactions?
+- Are there scenarios requiring same-day execution?
+- What are the consequences of 24-hour, 72-hour, or 7-day delays?
+
+#### Coordination Requirements
+
+Assess how transactions are executed:
+
+- How many approvers are needed for typical transactions?
+- Are transactions handled manually or through automated systems?
+- Do approvers need to coordinate across timezones?
+
+Note: Single-approver configurations should only be used for low-value operational accounts (\<0.1%) with additional
+compensating controls like strict spending limits and daily reconciliation.
+
+#### Operational Classification
+
+| Type                  | Frequency     | Response Window | Example Use Cases                                  |
+| --------------------- | ------------- | --------------- | -------------------------------------------------- |
+| **Cold Vault**        | \<5 tx/month  | 48-72 hours     | Long-term reserves, infrequent rebalancing         |
+| **Warm Storage**      | 5-50 tx/month | 4-24 hours      | Scheduled payments, planned operations             |
+| **Active Operations** | \>50 tx/month | \<4 hours       | Trading capital, frequent operational expenses     |
+| **Time-Critical**     | Unpredictable | \<2 hours       | Collateral management, market-sensitive operations |
+
+### Step 3: Security Control Matrix
+
+Combine impact and operational assessments to determine required controls.
+
+| Use Case | Impact | Operational | Approvers | MFA Requirement | Whitelist Delay | Additional Controls |
+| --- | --- | --- | --- | --- | --- | --- |
+| Payments | Low | Active Ops | 2 | Standard TOTP | 6 hours | **Baseline (all accounts):** Dedicated devices for custody access, address whitelisting enabled, test small amount to new addresses before full transaction, transaction simulation. **Low-specific:** Per-transaction cap, monthly aggregate limit |
+| Operational Wallet | Medium | Active Ops | 2 | Hardware required | 12 hours | All Low controls + daily transaction caps, weekly reconciliation, monthly audit |
+| Liquidation Protection | Medium-High | Time-Critical | 2 | Hardware required | None | All Low/Medium controls + automated alerts for position health, real-time monitoring |
+| DeFi Positions | Medium-High | Warm Storage | 3 | Hardware mandatory | 24 hours | All Low/Medium controls + smart contract whitelist, position monitoring, daily reconciliation |
+| Trading Capital (variable) | High | Active Ops | 3 | Hardware mandatory | 6 hours | All Low/Medium controls + smart contract whitelist, real-time monitoring, daily reconciliation |
+| Active Treasury (5-10%) | High | Warm Storage | 3-4 | Hardware mandatory | 24 hours | All Low/Medium controls + transaction velocity limits, SIEM monitoring, multi-channel confirmation |
+| Secondary Reserve (10-25%) | Critical | Cold Vault | 4-5 | Hardware mandatory | 48 hours | All Low/Medium/High controls + geographic distribution of approvers, MPC recommended |
+| Primary Reserve (>25% assets) | Critical | Cold Vault | 5-7 | Hardware mandatory | 72 hours | All Low/Medium/High controls + geographic distribution of approvers, MPC recommended |
+
+### Step 4: Document Your Decision
+
+- Record impact level and operational type with justification
+- Capture approver thresholds and required controls
+- Store links to relevant custody accounts and addresses
+
+Proceed to: [Registration Documents](./registration-documents)
+
+For Critical/High accounts, ensure you also review: [Enhanced Controls for High-Risk Accounts](./enhanced-controls)
+
+---
+
+### PAGE: /treasury-operations/enhanced-controls
+
+TagList,
+  AttributionList,
+  TagProvider,
+  TagFilter,
+  ContributeFooter,
+} from "../../../components";
+
+
+
+
+# Enhanced Controls for High-Risk Accounts
+
+
+
+
+For Critical and High impact custodial accounts, implement the following controls in addition to baseline measures.
+
+---
+
+## Transaction Verification
+
+- Test transactions: Send maximum $100 to new addresses before executing full transaction
+- Multi-channel confirmation: Request via one channel, approve via separate channel
+- Simulation requirement: All transactions must be simulated before execution
+- Address verification: Verify new addresses against three independent sources
+
+For DeFi interactions: refer to the [DeFi Risk Assessment Guide](https://entethalliance.org/specs/defi-risks/v1/) for
+recommended procedures.
+
+## Access Security
+
+- Hardware security keys (FIDO2/WebAuthn) mandatory for all approvers
+  - Secure fallback: Each approver must register minimum 2 hardware keys stored in separate secure locations
+  - Key loss procedure: Temporary access via backup key + additional approver verification via multiple channels +
+    mandatory key replacement within 48 hours
+- IP whitelisting with 24-hour change approval delay - if treasury software supports application-level IP whitelisting,
+  restrict to VPN IP range only
+- Device fingerprinting with new device approval process
+- Session timeout and re-authentication for sensitive operations
+- Dedicated credentials: Use separate email addresses and passwords exclusively for custody access, not shared with
+  other corporate systems
+
+## Device Security
+
+- Dedicated secure workstations and mobile devices for custody access only (no general browsing, email, or other
+  corporate activities)
+- Network isolation on separate VLAN/segment
+- VPN mandatory for all platform access; if treasury platform supports it, configure IP whitelisting to only allow
+  access from VPN IP addresses
+- Full disk encryption with automatic screen lock
+- MDM-enforced security baseline with remote wipe capability
+- Mobile endpoint security monitoring (e.g., iVerify) for devices used as second factors or keystores, without requiring
+  full MDM admin control
+
+## MPC for Large Holdings
+
+For organizations managing >10% of total assets or >$10M equivalent in a single custodial account consider using MPC:
+
+- Evaluate MPC (Multi-Party Computation) custody solutions that distribute key material across multiple parties
+- Consider threshold signature schemes (e.g., 3-of-5 or 5-of-9) where no single party controls sufficient key shares
+- Implement geographic distribution of key share holders across multiple jurisdictions
+- Establish clear key refresh and rotation procedures
+- Document recovery procedures and test annually
+
+### Custody/MPC Policy Thresholds for Treasury Operations
+
+- Minimum of 3 distinct approvers across roles (e.g., Treasury, Security, Finance)
+- Target majority approval (≥50% of designated approver group; e.g., 3/5, 4/7)
+- Scale quorum size with assets-at-risk and operational blast radius
+- Enforce separation of duties: requester cannot be an approver; admins cannot unilaterally execute withdrawals
+
+Policy scope definitions (examples):
+
+- Emergency Freeze: Temporarily block withdrawals/policy changes across workspaces
+- Protocol Parameters: Custody/policy engine settings, risk rules, policy changes
+- Capital Allocation: Movements between accounts, exchanges, or strategies
+- Treasury – Large: Routine treasury transfers above internal threshold or rate limit
+- Treasury – Small: Routine operational transfers below internal threshold or rate limit
+- Constrained DeFi: Time-sensitive interactions with pre-approved protocols/contracts
+
+Suggested approver thresholds (treasury contexts):
+
+| Operation            | Impact   | Urgency        | Approver Threshold            |
+| -------------------- | -------- | -------------- | ----------------------------- |
+| Emergency Freeze     | Critical | Emergency      | 2/4                           |
+| Protocol Parameters  | High     | Routine        | 4/7 (7/9+ for upgrades)       |
+| Capital Allocation   | High     | Time-Sensitive | 3/5                           |
+| Treasury - Large     | High     | Routine        | 4/7                           |
+| Treasury - Small     | Medium   | Routine        | 3/5                           |
+| Constrained DeFi     | Medium   | Time-Sensitive | 2/3                           |
+
+## Custody Policy Engine Rules
+
+Most custody/MPC platforms provide a policy engine that evaluates transaction rules and takes one of three actions:
+allow, block, or require additional approvals.
+
+Core rule elements:
+
+- Action: allow | block | escalate (require more approvers)
+- Asset selector: all assets or specific assets/tokens
+- Amount limits: per-transaction limit and optional rolling window aggregation
+- Source and destination selectors: account/wallet groups, internal vs external addresses, exchanges
+- Transaction type: transfers, contract interactions, approvals/signing
+- Initiators and approvers: who can initiate and who must authorize (with thresholds)
+- Rule identity and ordering: each rule has an ID; engines typically evaluate rules in order (first-match wins)
+
+## Zero Trust Architecture Alternative
+
+A Zero Trust architecture involves continuous verification of user, device, and context, rather than reliance on a
+single perimeter or network location. Centralizing access through a secure environment (such as a bastion host or
+isolated cloud workspace) can support Zero Trust principles when combined with strong identity and device posture
+enforcement.
+
+- Bastion Host Approach: Deploy a hardened jump server that acts as the sole gateway to custody platforms.
+  - All custody sessions route through the bastion with full session recording
+  - Bastion enforces MFA, device posture checks, and approved software versions
+  - No direct custody access from employee devices
+  - Centralized patch management and security configuration
+  
+- Cloud Workspace Isolation: Use browser-isolated or virtual workspace environments (e.g., Citrix, AWS WorkSpaces, Azure
+  Virtual Desktop)
+  - Custody access occurs only within a controlled virtual environment
+  - Copy/paste and download restrictions prevent data exfiltration
+  - Session timeout and automatic workspace destruction after use
+  - Significantly reduces risk from compromised employee devices
+
+## Security Monitoring & Logging
+
+For Critical and High impact accounts, implement centralized security monitoring:
+
+- SIEM Deployment: Deploy SIEM to centralize logs from custody platforms, authentication systems, and access devices.
+  Create real-time correlation rules for suspicious patterns (failed authentication, geographic anomalies, policy
+  changes).
+
+- Internal Incident Response: Build dedicated incident response capability for custody-related security events. Define
+  clear escalation procedures, maintain 24/7 on-call rotation for Critical accounts, and establish playbooks for custody
+  compromise scenarios.
+
+- Essential Log Sources: Authentication events, transaction attempts, policy modifications, access changes, whitelist
+  updates, IP address changes, new device enrollments, and approval workflows.
+
+For Medium and Low impact accounts, leverage custodian's native audit logs with weekly manual review and automated
+alerting for critical events (new device enrollment, policy changes, transactions above threshold).
+
+---
+
+### See also
+
+- Classification: [Custodial Treasury Security: Classification Framework](./classification)
+- Templates: [Registration Documents](./registration-documents)
+
+---
+
+### PAGE: /treasury-operations/registration-documents
+
+TagList,
+  AttributionList,
+  TagProvider,
+  TagFilter,
+  ContributeFooter,
+} from "../../../components";
+
+
+
+
+# Registration Documents
+
+
+
+
+Use these standardized templates to register custodial accounts, track access changes, document security configurations,
+and perform quarterly reviews.
+
+> See also: [Classification Framework](./classification) and [Enhanced Controls for High-Risk Accounts](./enhanced-controls)
+
+---
+
+## Registration Template
+
+Use this template when initially documenting a custodial account.
+
+```
+CUSTODIAL ACCOUNT REGISTRATION
+
+Account Name: [Descriptive name]
+Custodian: [Provider name and legal entity]
+Account ID: [Custodian reference number]
+Network(s): [Bitcoin, Ethereum, etc.]
+Registration Date: YYYY-MM-DD
+Registered By: [Name]
+
+CLASSIFICATION
+Impact Level: [Low / Medium / High / Critical]
+Operational Type: [Cold Vault / Warm Storage / Active Operations / Time-Critical]
+
+Justification:
+- Financial exposure: $XXX,XXX,XXX
+- Operational dependency: [Description]
+- Recovery time objective: [X hours/days]
+
+ASSETS CONTROLLED
+Asset   | Network  | Value     | Purpose
+--------|----------|-----------|------------------------------
+BTC     | Bitcoin  | $XXX,XXX  | [Reserve/Trading/Operations]
+ETH     | Ethereum | $XXX,XXX  | [Reserve/Trading/Operations]
+USDC    | Ethereum | $XXX,XXX  | [Reserve/Trading/Operations]
+
+CUSTODY MODEL
+Type: [Qualified Custodian / Co-managed / MPC Platform]
+Key Management: [MPC 3-of-5 / Multi-sig 2-of-3 / HSM]
+Key Control: [Custodian only / Co-managed / Client-controlled]
+Recovery Capability: [Yes - describe / No]
+
+INITIAL ACCESS SETUP
+Primary Administrator: [Name, added YYYY-MM-DD]
+Initial Approvers: [Names, added YYYY-MM-DD]
+
+Note: Complete access details documented in Access Change Template
+Note: Security configuration documented in Security Configuration Template
+
+ATTESTATION
+This account [meets / deviates from] security standards for its classification.
+
+[If deviation: Explain gap and compensating controls]
+
+CONTACTS
+Security Owner: [Name, email, phone]
+Backup Contact: [Name, email, phone]
+Custodian Support: [Name, email, phone]
+
+Last Updated: YYYY-MM-DD
+Updated By: [Name]
+```
+
+---
+
+## Access Change Template
+
+Use this template when modifying user access to a custodial account.
+
+```
+CUSTODIAL ACCOUNT ACCESS CHANGE
+
+Account Name: [Name]
+Custodian: [Provider]
+Account ID: [Reference]
+Change Date: YYYY-MM-DD
+Changed By: [Name]
+
+ACCESS MODIFICATIONS
+
+Additions:
+Name/Role | Access Level | MFA Method     | Justification
+----------|--------------|----------------|------------------------------
+[Name]    | [Approver]   | [Hardware key] | [Reason for addition]
+
+Removals:
+Name/Role | Access Level | Removal Reason
+----------|--------------|-------------------------------
+[Name]    | [Approver]   | [Personnel change / Security / Other]
+
+Permission Changes:
+Name/Role | Old Level | New Level | Justification
+----------|-----------|-----------|---------------------------
+[Name]    | [Initiator] | [Approver] | [Reason for elevation]
+
+CURRENT ACCESS LIST (after changes)
+Name/Role | Level     | MFA Method    | Device ID
+----------|-----------|---------------|---------
+[Name]    | Admin     | Hardware key  | [ID]
+[Name]    | Approver  | Hardware key  | [ID]
+[Name]    | Approver  | Hardware key  | [ID]
+[Name]    | Initiator | TOTP          | [ID]
+
+VERIFICATION
+[ ] All removed users confirmed deactivated in custodian platform
+[ ] All new users completed MFA setup
+[ ] Access permissions tested and verified
+[ ] Emergency contacts updated
+[ ] Documentation updated in [location]
+
+APPROVALS
+Requested By: _________________ Date: _______
+Approved By: _________________ Date: _______
+Security Review: _________________ Date: _______
+
+Change Ticket: [Reference number if applicable]
+```
+
+---
+
+## Security Configuration Template
+
+Use this template to document detailed security settings. Complete this after initial account registration.
+
+```
+CUSTODIAL ACCOUNT SECURITY CONFIGURATION
+
+Account: [Name]
+Custodian: [Provider]
+Last Configuration Update: YYYY-MM-DD
+Configured By: [Name]
+
+AUTHENTICATION SETTINGS
+
+Multi-Factor Authentication:
+Role | Primary Method | Backup Method | Enrollment Status
+Administrator | Hardware key + biometric | Hardware key + PIN | [Active]
+Approver | Hardware key | TOTP + SMS | [Active]
+Initiator | Hardware key or TOTP | SMS | [Active]
+Viewer | TOTP | SMS | [Active]
+
+Session Controls:
+- Timeout: [X minutes]
+- Re-auth required for: [High-value transactions, policy changes, user management]
+- Concurrent sessions: [Allowed/Blocked]
+
+ACCESS CONTROL
+
+Current User List:
+Name/Role | Level    | MFA Method   | Device ID | Added Date
+----------|----------|--------------|----------|------------
+[Name]    | Admin    | Hardware key | [ID]     | YYYY-MM-DD
+[Name]    | Approver | Hardware key | [ID]     | YYYY-MM-DD
+[Name]    | Approver | Hardware key | [ID]     | YYYY-MM-DD
+
+Note: Track all access changes using Access Change Template
+
+Approval Thresholds:
+Transaction Value (% of Total Assets) | Required Approvers | Time Delay | Additional Requirements
+<0.1%          | 1 | None       | MFA
+0.1% - 1%   | 3 | 4 hours    | MFA
+1% - 10%    | 4 | 24 hours   | Multi-channel confirmation, test transaction
+10% - 25%    | 5 | 24 hours   | Multi-channel confirmation, test transaction
+>25%           | 7 | 48 hours   | Multi-channel confirmation, test transaction
+
+Separation of Duties:
+[ ] Initiators cannot approve own transactions
+[ ] Admins cannot unilaterally execute withdrawals
+[ ] Minimum [X] unique approvers required
+
+NETWORK RESTRICTIONS
+
+IP Whitelist:
+XXX.XXX.XXX.XXX - [Office Location]
+XXX.XXX.XXX.XXX - [VPN Range]
+XXX.XXX.XXX.XXX - [Backup Location]
+
+Change Approval: [24 hour delay / XX approvers required]
+Emergency Override: [Process description]
+
+VPN Requirement: [Mandatory / Optional]
+Geographic Restrictions: [Blocked countries/regions]
+Device Fingerprinting: [Enabled / Disabled]
+
+TRANSACTION POLICIES
+
+Address Whitelisting:
+Status: [Enabled / Disabled]
+Current Addresses: [XX addresses]
+Addition Process: [XX approvers, YY hour delay]
+Review Schedule: [Monthly / Quarterly]
+
+Transaction Limits:
+Limit Type        | Amount   | Override Process
+------------------|----------|-----------------
+Single Transaction | $XXX,XXX | [Authorization required]
+Hourly Aggregate   | $XXX,XXX | [Authorization required]
+Daily Aggregate    | $XXX,XXX | [Authorization required]
+Weekly Aggregate   | $XXX,XXX | [Authorization required]
+Monthly Aggregate  | $XXX,XXX | [Authorization required]
+
+Time-Lock Settings:
+Change Type                          | Delay Period
+-------------------------------------|-------------
+New address addition                 | XX hours
+Policy modification                  | XX hours
+High-value transaction (>$XXX,XXX)   | XX hours
+
+MONITORING & ALERTS
+
+Real-Time Alerts:
+Type                       | Enabled
+---------------------------|--------
+All outgoing transactions  | [ ]
+New device login           | [ ]
+Failed authentication attempts (>X) | [ ]
+Policy violations          | [ ]
+Large transactions (>$XXX,XXX) | [ ]
+Unusual access times       | [ ]
+New geographic location    | [ ]
+
+Alert Routing:
+Severity | Contact         | Method       | Response Time
+---------|------------------|-------------|--------------
+Critical | [Name, phone]   | SMS + Call   | <15 min
+High     | [Name, phone]   | SMS + Email  | <1 hour
+Medium   | [Name, email]   | Email        | <4 hours
+
+VERIFICATION
+[ ] All settings tested and operational
+[ ] Alert routing verified
+[ ] User access confirmed
+[ ] Documentation stored in [location]
+
+Configured By: _________________ Date: _______
+Reviewed By: _________________ Date: _______
+Approved By: _________________ Date: _______
+```
+
+---
+
+## Quarterly Review Template
+
+Use this template for regular security reviews of custodial accounts.
+
+```
+CUSTODIAL ACCOUNT QUARTERLY REVIEW
+
+Account: [Name]
+Custodian: [Provider]
+Review Period: [Q1/Q2/Q3/Q4 YYYY]
+Review Date: YYYY-MM-DD
+Reviewed By: [Name]
+
+ACCESS AUDIT
+
+Current Users:
+Name/Role | Level | Last Login | MFA Status | Action Required
+[Name] | Admin | YYYY-MM-DD | Active | None
+[Name] | Approver | YYYY-MM-DD | Active | None
+[Name] | Approver | Never logged in | Inactive | Remove access
+
+Access Changes This Quarter: [X additions, Y removals, Z modifications]
+
+Findings:
+[ ] All users still require current access level
+[ ] No dormant accounts (>90 days inactive)
+[ ] MFA functioning for all users
+[ ] No unauthorized access detected
+
+Actions Required:
+- [List any access to be removed/modified]
+- [List any policy updates needed]
+
+TRANSACTION REVIEW
+
+Transaction Volume:
+- Total transactions: [X]
+- Average per month: [Y]
+- Largest transaction: $XXX,XXX
+- Total outflow: $XXX,XXX
+
+Pattern Analysis:
+[ ] Transactions within expected parameters
+[ ] No unusual transaction patterns detected
+[ ] All large transactions properly authorized
+[ ] Test transactions performed correctly
+
+Anomalies Detected:
+- [List any unusual activity or violations]
+
+SECURITY CONFIGURATION
+
+Whitelist Review:
+- Current addresses: [X]
+- Addresses added this quarter: [Y]
+- Addresses to remove: [Z]
+- Review complete: [Yes/No]
+
+Spending Limits:
+Current | Actual Usage | Status
+Single: $XXX,XXX | Max: $XXX,XXX | [Appropriate / Adjust]
+Daily: $XXX,XXX | Avg: $XXX,XXX | [Appropriate / Adjust]
+Monthly: $XXX,XXX | Avg: $XXX,XXX | [Appropriate / Adjust]
+
+Findings:
+[ ] Limits appropriate for current usage
+[ ] No limit breaches this quarter
+[ ] IP whitelist current and accurate
+[ ] Time-locks functioning properly
+
+ALERT EFFECTIVENESS
+
+Alerts This Quarter:
+Type | Count | False Positive Rate
+Critical | [X] | [Y%]
+High | [X] | [Y%]
+Medium | [X] | [Y%]
+
+Response Times:
+Severity | Target | Actual Average | Status
+Critical | <15 min | [X min] | [Met/Missed]
+High | <1 hour | [X min] | [Met/Missed]
+Medium | <4 hours | [X hours] | [Met/Missed]
+
+Findings:
+[ ] Alert routing working correctly
+[ ] Response times meeting SLAs
+[ ] No missed critical alerts
+
+Actions Required:
+- [Adjust alert thresholds if needed]
+- [Update contact information]
+
+CUSTODIAN RELATIONSHIP
+
+SOC Reports: [Current / Expired - date]
+Security Incidents: [Any custodian-wide incidents this quarter]
+Service Quality: [Any issues or concerns]
+Communication: [Regular contact maintained]
+
+RISK ASSESSMENT UPDATE
+
+Classification Review:
+Current: [Impact Level / Operational Type]
+Still Appropriate: [Yes / No]
+
+If No, Recommended Change:
+New Classification: [Level / Type]
+Justification: [Explain change in risk profile]
+
+Asset Value Change: [% increase/decrease]
+Operational Change: [Any significant changes in usage]
+
+RECOMMENDATIONS
+
+Security Improvements:
+1. [Recommendation]
+2. [Recommendation]
+3. [Recommendation]
+
+Operational Improvements:
+1. [Recommendation]
+2. [Recommendation]
+
+ATTESTATION
+
+This account [continues to meet / deviates from] security standards.
+
+[If deviation: Describe and provide remediation plan]
+
+APPROVALS
+
+Reviewer: _________________ Date: _______
+Security Officer: _________________ Date: _______
+Treasury Lead: _________________ Date: _______
+
+Next Review Due: YYYY-MM-DD
+```
+
+---
+
+---
+
+### PAGE: /treasury-operations/transaction-verification
+
+TagList,
+  AttributionList,
+  TagProvider,
+  TagFilter,
+  ContributeFooter,
+} from "../../../components";
+
+
+
+
+# Guide: Large Cryptocurrency Transfers
+
+
+
+
+## Core Principles
+
+Large cryptocurrency transfers require rigorous verification because transactions are irreversible. This guide covers
+both receiving and sending significant amounts, with security measures scaling to transfer size.
+
+## Part 1: Receiving Large Transfers
+
+### Pre-Transfer Setup (48 Hours Before)
+
+#### Choose Appropriate Deposit Address
+
+The address strategy depends on your custody model:
+
+**For Institutional Custody** (Coinbase, Anchorage, BitGo):
+
+- **Always generate a fresh deposit address** for large incoming transfers
+- **Verify you're on the correct website** - check URL carefully, bookmark the official site, watch for phishing lookalikes
+- Use the platform's "offline deposit address" or "new address" function
+- **Why fresh addresses?** Prevents counterparties from viewing your entire treasury balance/history and isolates each
+  major transfer for clean audit trails
+
+**For Self-Custody Multisigs**:
+
+- **Use your established, proven multisig address** that has been successfully tested in prior transactions
+- **Never generate a fresh multisig for large transfers** - multisig setup is complex and a new deployment risks misconfiguration
+- The battle-tested multisig you've been using is safer than a newly created one
+- Document the multisig configuration: threshold (e.g., 3-of-5), signer addresses, and deployment transaction
+- Verify multisig configuration on block explorer before providing address to sender
+
+#### Address Verification Protocol
+
+Have 2-3 team members independently verify the address:
+
+```
+1. Retrieve address from custody platform or multisig interface
+2. Person A: Verify via custody UI or block explorer (multisig configuration)
+3. Person B: Independently verify via separate block explorer or multisig interface
+4. Perform checksum validation:
+   - Ethereum: EIP-55 checksum
+   - Bitcoin: Bech32 checksum
+5. For multisigs: Verify threshold and signer configuration match expected setup
+```
+
+**For transfers >$1M**: Require all verifiers to sign a document confirming they verified the address character-by-character.
+
+#### Bidirectional Test Transaction
+
+This should occur **24-48 hours before the main transfer**.
+
+**Phase 1: Sender → You (Incoming Test): **
+
+```
+1. Sender sends small amount (0.001 ETH or 0.0001 BTC) to your new address
+2. Verify receipt through multiple sources:
+   - Custody platform interface
+   - Primary block explorer (Etherscan, Blockchain.com)
+   - Secondary block explorer (redundancy check)
+3. Document transaction hash and confirmation time
+```
+
+**Phase 2: You → Sender (Outgoing Test): **
+
+```
+4. Send test amount BACK to another address you control
+5. You confirm you received the return transaction
+```
+
+**Why bidirectional?** Proves address can both receive AND withdraw funds before large transfer arrives, and confirms
+both parties control their stated addresses.
+
+#### Coordinate with Sender
+
+Provide via encrypted channel (PGP email or Signal):
+
+- Deposit address
+- Network specification (Ethereum mainnet chain ID 1, Bitcoin mainnet)
+- Test transaction hash (incoming only)
+- Video call scheduled time for live transfer
+
+Request from sender:
+
+- Source wallet addresses they'll send from
+- Approximate transfer timing: specific date and time window
+  - Example: "Tuesday, March 15th, 2:00-6:00 PM EST"
+  - This allows you to have all required personnel available and monitoring
+- Whether they'll use single or multiple transactions
+
+**Best practices for transaction splitting:**
+
+- **\<$10M**: Single transaction preferred (simpler, one confirmation cycle, cleaner records)
+- **\>$10M**: Consider 2-3 separate transactions (reduces single-transaction risk, allows staged confirmation, provides
+  pause points to verify each step)
+- **\>$50M**: Multiple transactions strongly recommended with 30-minute intervals between each
+**Anti-Duress Protocols:**
+
+Since kidnapping and other forms of duress have been employed by criminals to steal cryptocurrency, organizations should
+prepare for this. Establish a duress word that indicates a transfer is not being made of your own free will. Once the
+duress word is mentioned during an exchange involving the transfer, law enforcement will be contacted and the
+transaction not processed. Procedures should be put in place with concrete run books for these situations. Safe words
+should not appear in run books or any digital format.
+**Anti-Social-Engineering Protocols:**
+
+Establish code phrase during initial verified meeting. Use this phrase to authenticate any address changes or unusual
+requests. Example: "What was the name of the restaurant where we finalized the agreement?" Exchange secondary contact
+numbers for key personnel - if primary contact requests changes, call secondary to confirm. Maintain out-of-band
+verification: if request comes via email, confirm via phone.
+
+**Red flags that should trigger immediate verification:**
+
+- Urgent requests to bypass procedures or claims of "emergency"
+- Requests to send to "temporary" or "new" address without proper verification
+- Pressure to skip test transactions or any rushed requests
+
+If anything feels wrong, STOP and verify through multiple channels. Urgency is an attacker's favorite tool - legitimate
+counterparties will understand security delays.
+
+### Day of Transfer
+
+#### Pre-Transfer Video Verification (30 minutes prior to transfer)
+
+Require video call with minimum 2 _internal_ people present.
+
+**Liveness and identity verification** (prevents AI deepfakes):
+
+```
+1. Ask participant to hold up specific number of fingers (change unpredictably)
+2. Ask them to wave their hand in front of their face
+3. Request they state current date and time
+4. Reference specific details from previous conversations only real participant would know
+5. If anything seems off, halt the transfer and investigate
+```
+
+**Critical confirmations during call:**
+
+1. **Address Reconfirmation**
+
+   - Read deposit address character-by-character from your screen
+   - Sender confirms they see identical address on their screen
+   - **Critical: "Read ONLY from your custody platform or multisig interface (Safe, Zodiac, etc.)"**
+   - **Do NOT copy from email, Etherscan, any block explorer, or any intermediary source**
+   - **Only trust the address shown directly in your custody interface or multisig platform**
+   - For multisigs: State the configuration (e.g., "3-of-5 multisig at address 0x...")
+   - This prevents compromised email, address poisoning, and man-in-the-middle attacks from causing misdirection
+
+2. **Test Transaction Review**
+
+   - Display test transaction on block explorer during call
+   - Confirm sender sees same transaction hash
+   - Review the bidirectional test from 24-48 hours ago
+
+3. **Amount and Network**
+   - State total amount in native units and USD equivalent
+   - Confirm network explicitly: "Ethereum mainnet, chain ID 1" (not testnet, not L2)
+   - If ERC-20 tokens: State token name AND read out full contract address
+     - Example: "Sending 100,000 USDC, contract address 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"
+     - Verify contract address against official source (token website, CoinGecko) on call
+   - Confirm no mistakes in decimal places or token contract
+
+#### Live Monitoring
+
+**Understanding Blockchain Finality:**
+
+Wait for enough confirmations that a chain reorganization becomes economically infeasible or cryptographically impossible.
+
+**Monitoring phases:**
+
+```
+1. Transaction Broadcast: Appears in mempool, verify correct parameters
+2. First Confirmation: Included in a block
+3. Progressive Confirmations: Each block makes reversal exponentially harder
+4. Finality: Sufficient confirmations reached, transaction irreversible
+```
+
+**Confirmation requirements by chain:**
+
+- **Ethereum**: 2 epochs (~12.8 minutes)
+- **Bitcoin**: 6 confirmations (~60 minutes)
+- **Polygon**: 128 confirmations (~5 minutes)
+- **Solana**: ~12.8 seconds
+
+**On-call updates from Technical Operator:**
+
+- "Transaction in mempool, parameters correct"
+- "Block 1 confirmed, no anomalies"
+- "Block 12 confirmed, [X.XXX] ETH received and final"
+
+#### Dual Confirmation Requirement
+
+Before ending call, verify through TWO sources:
+
+1. Custody platform showing updated balance
+2. Block explorer showing confirmed transaction
+
+#### Post-Receipt Actions
+
+**Immediate (within 15 min):**
+
+- Document transaction hash, block number, timestamp
+- Record amount in native units and USD equivalent
+- Note all personnel involved
+
+**Within 30 minutes:**
+
+- Email confirmation to sender with transaction details
+
+## Part 2: Sending Large Cryptocurrency Transfers
+
+### Pre-Transfer Planning (72 Hours Before)
+
+#### Authorization
+
+Document and obtain approvals:
+
+- Purpose of transfer
+- Recipient verification
+- Amount and timeline
+- Required signatures based on amount:
+  - \<$100K: Treasury Manager
+  - $100K-$1M: CFO + Security Officer
+  - \>$1M: CFO + CEO
+
+#### Recipient Address Verification
+
+Multi-source verification is critical:
+
+```
+STEP 1: Receive address through official channel
+├─> Request via verified email/signed contract
+
+STEP 2: Independent verification through multiple sources (e.g., email, phone call)
+├─> At least two team members independently confirm the recipient address using different communication channels (such as verified email and a direct phone call with the recipient)
+
+STEP 3: Mandatory test transaction
+├─> Send $10-100 equivalent first
+├─> Wait for recipient confirmation
+├─> Recipient provides test transaction hash
+├─> Verify hash matches your outbound transaction
+└─> Proves recipient controls address and communications secure
+```
+
+**Never skip the test transaction.**
+
+#### Whitelist Addition (If Using Custody Platform)
+
+Most custody platforms support whitelisting:
+
+```
+1. Submit whitelist request with justification
+2. Wait mandatory cooling-off period:
+   - Standard: 24-48 hours
+   - High security: 72 hours
+3. Different team member approves whitelist addition
+4. Test transaction AFTER whitelist approval
+```
+
+**Why cooling-off periods?** Prevents attackers who gain account access from immediately adding malicious addresses and
+draining funds. Gives time for legitimate personnel to notice unauthorized changes.
+
+### Day of Transfer
+
+#### Final Verification Checklist (15 min before)
+
+Minimum 2 _internal_ people present, verify:
+
+```
+□ Authorization documentation signed
+□ Recipient address verified by 2 independent sources
+□ Test transaction confirmed successful by recipient
+□ Whitelist cooling-off period complete (if applicable)
+□ Exact amount confirmed (recipient expects this amount)
+□ Network confirmed (mainnet, not testnet)
+□ Sufficient balance in source wallet (amount + fees + buffer)
+□ All required approvers available next 60 minutes
+```
+
+**For transfers \>$1M**: Conduct formal video call with all approvers present.
+
+#### Execution Protocol
+
+**Video Call Requirements**:
+
+```
+1. Screen share custody interface or wallet
+2. Primary operator reads transaction parameters aloud:
+   - "Sending [X.XXXXX] ETH"
+   - "To address: 0x[read full address character-by-character]"
+   - "On network: Ethereum mainnet, chain ID 1"
+
+3. Each approver independently verifies on their device:
+   - Destination matches authorized recipient
+   - Amount matches approved transfer
+   - Network is correct
+
+4. Approvers use MFA to approve:
+   - Hardware security key, biometric, or authenticator app
+   - For multisigs: Each signer verifies transaction details on their signing device
+   - Verbally confirm: "I approve this transaction"
+
+5. Final approval triggers broadcast to blockchain
+```
+
+#### Post-Submission Monitoring
+
+Monitor transaction through finality:
+
+```
+1. Copy transaction hash from custody platform
+2. Enter into block explorer immediately
+3. Verify parameters match intended transaction
+4. Monitor confirmation progress:
+   - Ethereum: Wait for 12 confirmations (~3 minutes)
+   - Bitcoin: Wait for 6 confirmations (~60 minutes)
+5. Watch for recipient confirmation of receipt
+```
+
+#### Confirmation and Documentation
+
+After transaction reaches finality:
+
+```
+1. Internal record (within 15 min):
+   - Transaction hash and block number
+   - Timestamp and confirmation count
+   - Source wallet balance updated in records
+
+2. Request receipt from recipient (within 30 min):
+   - Formal acknowledgment they received funds
+
+3. Permanent documentation:
+   - Full transaction details (hash, block, timestamp, amount)
+   - Authorization chain (who approved, when)
+   - Personnel involved
+```
+
+---
+
+## Multi-Signature Best Practices
+
+See the Multisigs for Protocols guide.
+
+# TODO: Add link to Multisigs for Protocols guide. AFTER IT IS MERGED
+
+## Critical Risk Mitigations
+
+### Address Verification
+
+**Multisig and custody interface verification:**
+
+- Always verify addresses directly from your custody platform or multisig interface (Safe, Zodiac, etc.)
+- For multisigs: Cross-check configuration (threshold, signers) on block explorer
+- Never trust copy-pasted addresses from email or chat
+- Verify entire address character-by-character
+
+**Address poisoning defense:**
+
+- Never copy from transaction history
+- Always copy from authoritative source
+- Use custody platform address books when available
+
+### Communication Security
+
+**Email compromise prevention:**
+
+- Address confirmation during video call prevents MITM
+- Live verbal verification catches discrepancies
+- Code phrases for authentication
+
+**Social engineering defense:**
+
+- Never accept urgent bypass requests
+- Callback on known numbers to verify
+- Any request to skip verification triggers security review
+
+### Multi-Party Controls
+
+**Prevents single-actor fraud:**
+
+- Multiple personnel
+- Video recording of approvals
+- Separation of duties: requester ≠ approver ≠ technical executor
+
+### Transaction Parameter Security
+
+**Custody platform policy engines:**
+
+
+[... truncated ...]
+
+---
+
+### PAGE: /wallet-security/seed-phrase-management
+
+# Seed Phrase Management
+
+
+
+
+## Private Key & Seed Phrase Management
+
+The **seed phrase** (or mnemonic phrase) is the master key to a non-custodial wallet, granting complete control over all
+its derived **private keys** and assets. The management of this phrase is the single most important aspect of
+self-custody security.
+
+> ⚠️ If you suspect for even a moment that your private key or seed phrase has been lost, viewed by another person, or
+> exposed digitally (e.g., shown on-screen, copied to a clipboard on a connected device), you must **consider it
+> compromised.** Immediately create a new, secure wallet and transfer all assets to it.
+
+### Secure Storage Practices
+
+The goal is to protect the seed phrase from both physical threats (theft, fire, water damage) and digital threats
+(hacking, malware). The foundational principle is to keep your seed phrase offline at all times.
+
+As soon as a new wallet is created, back it up using one of the following offline methods. Wallet providers do not have
+access to your seed phrase and cannot help you recover it.
+
+- **Physical Written Copies**: Writing the phrase on paper or a notebook is a common starting point. To mitigate risks
+
+of loss or damage from fire or water, store multiple copies in secure, geographically separate locations (e.g., a
+personal safe, a trusted family member's home, a bank deposit box).
+
+- **Durable Metal Storage**: For superior protection against physical damage, etch or stamp your seed phrase onto a
+
+metal plate (e.g., steel, titanium). Commercial products are available for this purpose. These should also be stored in
+secure, separate locations.
+
+### Enhanced security option
+
+For extra security, split seed into 3 pieces:
+
+- **Piece 1**: Words 1-16
+- **Piece 2**: Words 9-24
+- **Piece 3**: Words 1-8 and 17-24
+
+#### Storage locations:
+
+- Different secure locations (safe deposit box, home safe, trusted family)
+- Each piece stored with clear labeling system
+
+### Tamper evident bags:
+
+Storing sensitive devices or documents in a tamper evident bag offers high confidentiality and integrity. You can sign &
+date these bags, and also take a picture of its serial number.
+
+![Tamper evident bag example](https://frameworks-static.s3.us-east-2.amazonaws.com/images/multisig-for-protocols/tamper-evident-bag-example.png)
+
+**Use case:**
+You can put your Piece 1: Words 1-16 of your seed, inside a safe.
+Piece 2: Words 9-24 of your seed, somewhere safe (different location) in a tamper evident bag (could be at your parents place).
+Piece 3: Words 1-8 and 17-24 of your seed, somewhere safe (different location) in a tamper evident bag (could be
+somewhere else, at a family member or trusted friend).
+You can put your backup ledger while traveling inside this, in the safe of your hotel room to detect tampering.
+The main idea is to never have at the same place your 24 words, but still be able to recover your seed within 2 pieces
+of paper out of 3.
+You can find a useful [link here to our EthCC
+swag](https://drive.google.com/file/d/1L1CMiKRL3TXQBE5bWYNv6dfF94HSdZ8C/view?usp=sharing) that shows you how to easily
+split your seed in 3 as recommended.
+
+### Prohibited Practices
+
+Under no circumstances should you ever store your seed phrase in any of the following ways:
+
+- Taking a digital photograph of it.
+- Uploading it to cloud storage (iCloud, Google Drive, Dropbox).
+- Sending it via text message or any messaging app.
+- Sending it in an email, even to yourself.
+- Storing it in a plain text file on a computer or phone.
+- Sharing it with anyone. Wallet providers will **never** ask for your seed phrase.
+- Password managers or digital storage
+- Traveling with seed phrases
+- Storing all pieces in same location
+- Using a device obtained from an untrusted source, such as a conference, hackathon, or third-party online marketplace,
+as it may be tampered with.
+
+## Organizational Seed Phrase Security
+
+For organizations managing multisig wallets, seed phrase security requires additional properties beyond individual storage:
+
+### Security Properties
+
+- **Disaster Resistant**: The seed phrase is either duplicated or split, with components/copies secured across multiple
+geographic locations. This way, if disaster strikes, keys can be recovered from other locations.
+- **Theft Resistant**: An attacker gaining access to one piece of physical storage media for the seed phrase would not
+allow them to rebuild the wallet on its own
+- **Operator Loss Resistant**: Reconstituting the seed phrase should be possible with the absence of one or more
+operators
+
+### Seed Phrase Encryption
+
+> ⚠️ **Warning: Encryption adds recovery risk.** Only implement custom encryption schemes if you are sophisticated and
+> have robust documentation practices. If you forget your encryption method or passphrase, your funds are **permanently
+> inaccessible**—there is no recovery option. Many users and organizations face greater risk of locking themselves out
+> with custom encryption than from an attacker discovering a securely stored backup. Evaluate whether strong physical
+> security alone may be sufficient for your threat model.
+
+The reason to encrypt seed phrases is that if they are discovered unencrypted, the wallet is permanently compromised.
+However, if you encrypt your seed phrase, you are much more likely to forget the encryption when trying to restore the
+wallet. If you have stored the seed securely, it is unlikely to be discovered in the first place.
+
+Never store seed phrases in plain text or on an internet connected device. For additional protection, seed phrases can
+optionally be encrypted through some method. For example:
+
+- Seed phrases can be mixed in a randomly generated, recorded order
+- Have a 25th secret word
+- Require a passphrase to be imported into a wallet
+
+Regardless of the method, the related secret value should be stored in a password manager. (**Do not store your seed
+phrase in a password manager.**)
+
+### Advanced Backup Options
+
+**Key Splitting:**
+
+Split the key into multiple shards and securely distribute them:
+
+- Use [Shamir's Secret Sharing algorithm](https://en.wikipedia.org/wiki/Shamir%27s_secret_sharing) for N of M key shards
+- Consider using this [Shamir Secret Sharing implementation](https://github.com/privy-io/shamir-secret-sharing)
+- Seed phrases can be sharded using Shamir's Secret Sharing algorithm, with each shard recommended to be shared with a
+trusted guardian (3rd party custodian service, family members, password manager, personal physical media, etc.)
+
+**Multi-Share Backups:**
+
+Use device-supported multi-share backups where available:
+
+- [Trezor Multi-Share Backup](https://trezor.io/learn/a/multi-share-backup-on-trezor)
+
+**Secure Distribution:**
+
+Give shards to trusted family members, put in bank safe deposit boxes, and keep hidden around your house.
+
+> **Note**: If you're concerned about targeted attacks like kidnapping or home invasions, consider avoiding storing
+any shards in your primary residence.
+
+### Multisig Social Recovery
+
+**Optional Self-Recovery**:
+
+- Seed phrase backups are not strictly necessary with a healthy quorum
+- Multi-sig signing wallets should not be used for any other purpose and could be re-provisioned by existing quorum
+admins
+- Maintain a healthy enough signing pool that loss of access to a few accounts at once could be recovered from
+- Personal backup methods for admins are required to maintain access to on-chain assets in the event of loss of access
+to hardware wallets
+
+**Quorum Social Recovery**: If access to wallet is lost, the quorum can vote to edit members to replace the
+inaccessible wallet.
+
+### Ongoing Security Hygiene
+
+**1. Periodic Security Audits:**
+
+On a recurring basis (e.g., every 6 months), conduct a security review by asking:
+
+- Do I know the physical location of all my seed phrase backups?
+- Are my storage methods still secure and uncompromised?
+- If my primary device were destroyed, do I have a clear plan to recover my assets?
+
+**2. Key Rotation:**
+
+While you can use the same keys for years, it is a best practice to periodically rotate them by moving assets to new
+wallets.
+
+**3. Succession Planning:**
+
+Establish a clear, secure protocol for a trusted next-of-kin to access your assets in case of incapacitation or death.
+This may involve sealed instructions stored with a lawyer or in a safe deposit box.
+
+## Emergency access plan
+
+### Trusted contacts
+
+- Designate 2-3 trusted individuals who can access backup locations
+- Clear instructions for emergency seed access
+- Regular check-ins with trusted contacts
+
+### Recovery scenario example
+
+"Call [trusted person] with code word [predetermined phrase], tell them to get the metal plate from safe location A,
+they give you words 1-16 over the phone. Then call [second person] with code word for location B to get words 9-24. Use
+both pieces to reconstruct seed immediately, then change all security settings."
+
+### Documentation
+
+- Emergency contact information stored separately from seed
+- Code words/phrases for identity verification
+- Access instructions for trusted contacts
+- Regular testing of emergency procedures
+- Update procedures when contacts or locations change
+
+Remember: Your seed phrase security is the foundation of multisig security. Take time to implement proper storage
+procedures appropriate for your risk level.
+
+---
+
diff --git a/scripts/data/qa-briefs/sfc-workspace-security.md b/scripts/data/qa-briefs/sfc-workspace-security.md
new file mode 100644
index 00000000..7ebdca09
--- /dev/null
+++ b/scripts/data/qa-briefs/sfc-workspace-security.md
@@ -0,0 +1,3440 @@
+# QA Brief: sfc-workspace-security
+
+## YOUR TASK
+
+Verify the evaluation claims below. For each control with refs:
+1. Read the ACTUAL page content (provided below)
+2. Read the control's FULL baselines
+3. Check: does the page ACTUALLY meet the baselines claimed in "baselinesMet"?
+4. Check: are the "baselinesMissed" correct (is there content that was overlooked)?
+5. Check: is the coverage rating ("full"/"partial") justified?
+
+Be STRICT. If the evaluator was too generous, downgrade. If they missed coverage, upgrade.
+
+## EVALUATION CLAIMS TO VERIFY (22 controls with refs)
+
+### ws-1.1.1: Workspace Security Owner
+**Full baselines:**
+  1. Accountability scope covers policy maintenance, device and account standards, access control oversight, periodic reviews, and incident escalation
+
+**Evaluator's assessment:**
+- **/opsec/core-concepts/security-fundamentals** → Continuous Visibility — **partial**
+  Met: Accountability touches on establishing clear ownership for monitoring domains
+  Missed: Does not address comprehensive workspace security ownership scope covering policy maintenance, device/account standards, access control oversight, periodic reviews, and incident escalation
+**Gaps:** Full accountability scope covering policy maintenance, device and account standards, access control oversight, periodic reviews, and incident escalation - no page provides comprehensive guidance on designating a workspace security owner with this full scope
+
+### ws-1.1.3: Asset Inventory
+**Full baselines:**
+  1. Scoped to devices and accounts with access to sensitive systems or data
+  2. Device inventory tracks make/model, owner, OS version, encryption status, and EDR/MDM enrollment
+  3. Account inventory covers organizational accounts (eg. email, cloud, social media) with defined ownership
+  4. Updated as devices/accounts are provisioned or decommissioned
+
+**Evaluator's assessment:**
+- **/opsec/core-concepts/implementation-process** → Critical Asset Identification — **partial**
+  Met: Map and document assets; Asset discovery and classification
+  Missed: Does not specify device inventory tracking (make/model, owner, OS version, encryption status, EDR/MDM enrollment); Does not cover account inventory with ownership; Does not address updates as devices/accounts are provisioned or decommissioned
+**Gaps:** Device inventory tracking make/model, owner, OS version, encryption status, and EDR/MDM enrollment; Account inventory covering organizational accounts with defined ownership; Updated as devices/accounts are provisioned or decommissioned
+
+### ws-1.1.4: System and Data Classification
+**Full baselines:**
+  1. Classification levels defined (e.g., critical, high, standard)
+  2. Classification determines which controls apply (access restrictions, monitoring, encryption, backup requirements)
+  3. Classification reviewed when systems, data sensitivity, or organizational structure change
+
+**Evaluator's assessment:**
+- **/opsec/core-concepts/security-fundamentals** → Information Flow Control — **full**
+  Met: Classification levels defined (Public, Internal, Confidential, Restricted); Classification determines which controls apply; Data handling procedures for each classification level
+- **/opsec/core-concepts/implementation-process** → Critical Asset Identification — **full**
+  Met: Apply practical classification system with clear categories; Classification reviewed when conditions change
+
+### ws-2.1.1: Device Security Standards
+**Full baselines:**
+  1. Full disk encryption enabled on all devices
+  2. Automatic OS and application patching enabled or enforced
+  3. Strong authentication required (password/biometric, auto-lock timeouts, lock screens)
+  4. Administrative privileges separated from daily-use accounts
+  5. Devices procured through verified supply chains and verified for integrity upon receipt
+  6. Device compliance verified upon provisioning and monitored on an ongoing basis
+  7. BYOD policy defining what personal devices can access and the security controls required (e.g., MDM enrollment, separate work profiles)
+
+**Evaluator's assessment:**
+- **/opsec/travel/guide** → Secure devices with encryption & updates — **partial**
+  Met: Full disk encryption enabled; Install latest OS and app updates; Strong authentication required (strong password/PIN)
+  Missed: Automatic OS and application patching; Administrative privileges separated from daily-use accounts; Devices procured through verified supply chains; Device compliance verification and monitoring; BYOD policy
+- **/encryption/volume-encryption**  — **partial**
+  Met: Full disk encryption guidance
+  Missed: OS patching; Authentication; Admin privileges separation; Supply chain; Compliance monitoring; BYOD policy
+- **/encryption/partition-encryption**  — **partial**
+  Met: Encryption for specific partitions
+  Missed: OS patching; Authentication; Admin privileges separation; Supply chain; Compliance monitoring; BYOD policy
+**Gaps:** Automatic OS and application patching enabled or enforced; Administrative privileges separated from daily-use accounts; Devices procured through verified supply chains and verified for integrity upon receipt; Device compliance verified upon provisioning and monitored on an ongoing basis; BYOD policy defining what personal devices can access and security controls required
+
+### ws-2.1.2: Device Lifecycle Management
+**Full baselines:**
+  1. Remote lock and wipe capability for all organizational devices
+  2. Documented procedures for responding to lost or stolen devices (notification, remote wipe, credential rotation, incident escalation)
+  3. Secure decommissioning procedures including data sanitization and verified destruction for storage media
+
+**Evaluator's assessment:**
+- **/opsec/travel/guide** → Back up and prepare for loss — **partial**
+  Met: Remote wipe capability mentioned (Find My, MDM); Procedures for lost devices (remote wipe, filing reports)
+  Missed: Documented procedures for credential rotation after loss; Incident escalation procedures; Secure decommissioning with data sanitization and verified destruction
+- **/opsec/control-domains/physical-environmental** → Physical Security of Critical Assets — **partial**
+  Met: Secure disposal procedures for equipment and media
+  Missed: Remote lock and wipe capability; Response procedures for lost/stolen devices; Credential rotation
+**Gaps:** Documented procedures for credential rotation after device loss or theft; Incident escalation procedures for lost/stolen devices
+
+### ws-2.1.3: Endpoint Protection
+**Full baselines:**
+  1. EDR or MDM deployed on all organizational devices with documented coverage
+  2. Alert triage and response procedures defined with severity-based escalation
+  3. Compliance enforcement actions documented (e.g., quarantine non-compliant devices, block access)
+  4. Monitoring coverage includes detection of malware, unauthorized software, and policy violations
+
+**Evaluator's assessment:**
+- **/opsec/travel/guide** → Inspect and clean your devices — **partial**
+  Met: Run anti-malware scan; Look for unusual behavior
+  Missed: EDR/MDM deployed on all devices with documented coverage; Alert triage and response procedures; Compliance enforcement actions; Monitoring for malware, unauthorized software, policy violations
+**Gaps:** EDR or MDM deployed on all organizational devices with documented coverage; Alert triage and response procedures defined with severity-based escalation; Compliance enforcement actions documented; Monitoring coverage includes detection of malware, unauthorized software, and policy violations
+
+### ws-2.1.4: Physical and Travel Security
+**Full baselines:**
+  1. Physical workspace requirements defined for both on-site and remote work environments
+  2. Screen privacy and shoulder-surfing awareness enforced
+  3. Travel security procedures documented covering device handling, network usage, and border crossings
+  4. High-risk travel procedures defined (loaner devices, enhanced controls, check-in schedules)
+  5. USB and charging security addressed (data blockers, no public USB ports)
+  6. Devices physically secured when not in active use (cable locks, safes, carry-on luggage for travel)
+
+**Evaluator's assessment:**
+- **/opsec/travel/guide**  — **full**
+  Met: Screen privacy and shoulder-surfing awareness (privacy screen filter, shield keypad); Travel security procedures (pre-travel assessment, secure travel practices, device security); High-risk travel procedures (loaner devices, enhanced controls); USB and charging security (avoid juice jacking, USB data blockers, no unknown USB drives); Devices physically secured (cable locks, room safes, carry-on luggage)
+  Missed: Physical workspace requirements for on-site and remote work not comprehensively covered
+- **/opsec/control-domains/physical-environmental** → Secure Workspace & Travel Security — **full**
+  Met: Physical workspace requirements (physical access controls, clean desk policy); Travel security procedures; Device security during travel; Secure storage options
+
+### ws-3.1.1: Account Lifecycle Management
+**Full baselines:**
+  1. Account creation requires documented approval from the account owner's manager or designated authority
+  2. Accounts provisioned with minimum necessary permissions (least privilege)
+  3. Modification of account permissions requires documented approval
+  4. Account revocation procedures tied to offboarding and role changes
+  5. Service accounts and shared credentials inventoried with defined ownership
+
+**Evaluator's assessment:**
+- **/guides/account_management/discord** → Roles — **partial**
+  Met: Review admin role members and permissions; Remove unnecessary permissions and members
+  Missed: Account creation approval process; Accounts provisioned with minimum necessary permissions systematically; Account modification approval; Account revocation tied to offboarding; Service accounts inventoried with ownership
+**Gaps:** Account creation requires documented approval from manager or designated authority; Accounts provisioned with minimum necessary permissions (least privilege); Modification of account permissions requires documented approval; Account revocation procedures tied to offboarding and role changes; Service accounts and shared credentials inventoried with defined ownership
+
+### ws-3.1.2: Multi-Factor Authentication
+**Full baselines:**
+  1. MFA required for all organizational accounts by default
+  2. Hardware security keys required for high-privilege and critical accounts (admin, infrastructure, custody)
+  3. Phishing-resistant MFA preferred (FIDO2/WebAuthn, hardware keys) over SMS or TOTP where available
+  4. Exceptions documented with justification, compensating controls, and expiry date
+  5. Backup MFA methods configured for account recovery
+
+**Evaluator's assessment:**
+- **/opsec/travel/guide** → Protect Accounts with 2FA redundancy — **partial**
+  Met: Plan for 2FA redundancy; Disable SMS for 2FA; Register backup 2FA methods
+  Missed: MFA required for all organizational accounts by default; Hardware security keys required for high-privilege accounts; Exceptions documented with justification and expiry
+- **/opsec/control-domains/technical** → Two-Factor & Hardware Authentication — **full**
+  Met: Multi-factor authentication for all access to sensitive systems; Hardware security keys for high-value accounts; Backup authentication methods and recovery processes; Phishing-resistant MFA (hardware keys)
+  Missed: Exceptions documented with justification, compensating controls, and expiry date not explicitly covered
+- **/guides/account_management/discord** → For Individuals - Account Security Checklist — **partial**
+  Met: 2FA enabled requirement; Require 2FA for moderation
+  Missed: Hardware keys for high-privilege accounts; Phishing-resistant MFA preferred; Exceptions documented; Backup MFA methods
+**Gaps:** Exceptions documented with justification, compensating controls, and expiry date
+
+### ws-3.1.3: Organizational Account Security
+**Full baselines:**
+  1. Security configuration standards defined and applied for enterprise platforms (Google Workspace, Microsoft 365, collaboration tools)
+  2. Social media and public-facing accounts secured with strong authentication and defined ownership
+  3. Ownership verified and documented for all organizational accounts
+  4. Recovery methods restricted to organizational channels (no personal recovery emails or phone numbers on organizational accounts)
+  5. Account configurations reviewed periodically for drift or unauthorized changes
+
+**Evaluator's assessment:**
+- **/guides/account_management/discord** → Server Settings Checklist — **partial**
+  Met: Security configuration standards for Discord platform; Ownership verified through admin reviews
+  Missed: Security standards for enterprise platforms broadly; Social media and public-facing accounts; Recovery methods restricted to organizational channels; Periodic review for drift
+**Gaps:** Security configuration standards defined and applied for enterprise platforms (Google Workspace, Microsoft 365, collaboration tools); Social media and public-facing accounts secured with strong authentication and defined ownership; Recovery methods restricted to organizational channels (no personal recovery emails or phone numbers); Account configurations reviewed periodically for drift or unauthorized changes
+
+### ws-3.1.4: Credential Management Standards
+**Full baselines:**
+  1. Password manager required for all personnel; no passwords stored in plain text, documents, or browsers
+  2. Unique, strong passwords for every account (minimum length/complexity standards defined)
+  3. Individual accounts required for all personnel — no sharing of personal login credentials
+  4. When credentials must be provisioned or shared (e.g., service accounts, API keys, onboarding), transmission only through encrypted channels (password manager sharing features, not email or chat)
+  5. Credential rotation schedule defined based on risk; rotation triggered immediately after suspected compromise
+  6. Enhanced controls for high-privilege credentials (admin accounts, service accounts, API keys) including stricter rotation, separate storage, and logged access
+  7. Service account and API key inventory maintained with defined ownership
+
+**Evaluator's assessment:**
+- **/opsec/travel/guide** → Protect Accounts with 2FA redundancy — **partial**
+  Met: Password manager accessible (1Password Travel Mode); Backup codes stored securely
+  Missed: Password manager required for all personnel; Unique strong passwords for every account; Individual accounts required (no sharing); Credential transmission only through encrypted channels; Rotation schedule; Enhanced controls for high-privilege credentials; Service account inventory
+- **/awareness/cultivating-a-security-aware-mindset** → Password Management — **partial**
+  Met: Strong, unique passwords for each account; Password managers to securely store and generate passwords
+  Missed: No passwords in plain text/documents/browsers requirement; Individual accounts required; Credential transmission security; Rotation schedule; Enhanced controls for high-privilege; Service account inventory
+- **/guides/account_management/telegram** → Account Security Checklist — **partial**
+  Met: Strong unique password that doesn't get reused
+  Missed: Password manager required; Credential transmission; Rotation schedule; Enhanced controls; Service account inventory
+**Gaps:** Password manager required for all personnel; no passwords stored in plain text, documents, or browsers; Individual accounts required for all personnel — no sharing of personal login credentials; Credential transmission only through encrypted channels (password manager sharing features, not email or chat); Credential rotation schedule defined based on risk; rotation triggered immediately after suspected compromise; Enhanced controls for high-privilege credentials including stricter rotation, separate storage, and logged access; Service account and API key inventory maintained with defined ownership
+
+### ws-3.1.5: Access Reviews
+**Full baselines:**
+  1. Scheduled access reviews at least quarterly for critical systems, annually for others
+  2. Access adjusted within defined timelines when employees change roles
+  3. Reviews verify each user still requires their current level of access
+  4. Unnecessary permissions revoked promptly with documented evidence
+  5. Insider threat consideration included — for each role, assess what damage could be done with current access
+
+**Evaluator's assessment:**
+- **/opsec/core-concepts/security-fundamentals** → Minimal Access Scopes — **partial**
+  Met: Conduct regular access reviews (quarterly for critical, annually for others); Reviews verify each user still requires current access
+  Missed: Access adjusted within defined timelines when roles change; Unnecessary permissions revoked with documented evidence; Insider threat consideration
+- **/guides/account_management/discord** → Regular Reviews — **partial**
+  Met: Monthly review of role permissions; Quarterly assessment of rules; Track changes and justifications
+  Missed: Access adjusted when employees change roles; Insider threat damage scenarios; Reviews for critical vs standard systems
+**Gaps:** Access adjusted within defined timelines when employees change roles; Unnecessary permissions revoked promptly with documented evidence; Insider threat consideration included — for each role, assess what damage could be done with current access
+
+### ws-4.1.1: Software Evaluation and Approval
+**Full baselines:**
+  1. Evaluation criteria for all software before adoption (browsers, extensions, IDEs, libraries, AI assistants, SaaS tools)
+  2. Data privacy and leakage risks assessed (does the tool send data to third parties for training or analytics?)
+  3. Approved software list maintained; unapproved software restricted
+  4. Browser extension approval process defined
+  5. Dependency management includes version pinning, vulnerability scanning, and update policies
+
+**Evaluator's assessment:**
+- **/opsec/travel/guide** → Minimize digital footprint & social visibility — **partial**
+  Met: Privacy-focused tools mentioned (Hide My Email, Tuta, ProtonMail)
+  Missed: Evaluation criteria for software before adoption; Data privacy and leakage risk assessment; Approved software list; Browser extension approval; Dependency management
+**Gaps:** Evaluation criteria for all software before adoption (browsers, extensions, IDEs, libraries, AI assistants, SaaS tools); Data privacy and leakage risks assessed (does the tool send data to third parties?); Approved software list maintained; unapproved software restricted; Browser extension approval process defined; Dependency management includes version pinning, vulnerability scanning, and update policies
+
+### ws-4.1.2: Source Code and Repository Security
+**Full baselines:**
+  1. Role-based access control with least-privilege permissions
+  2. Branch protection rules enforced on critical branches (require reviews, signed commits)
+  3. Automated secret scanning enabled to detect credentials, API keys, and private keys in code
+  4. Pre-commit hooks or CI checks to prevent secrets from being committed
+  5. Repository security audited periodically (access permissions, configuration, open PRs)
+
+**Evaluator's assessment:**
+- **/guides/account_management/github** → Repository Settings — **full**
+  Met: Role-based access control (Collaborators and teams); Branch protection rules enforced (require reviews, signed commits); Automated secret scanning enabled (Code security settings); Pre-commit hooks/CI checks (Push protection for secrets); Repository security audited periodically (Sessions, SSH keys, webhooks review)
+
+### ws-5.1.1: Network Security
+**Full baselines:**
+  1. VPN or zero-trust network access required for accessing internal resources remotely
+  2. Wi-Fi security standards defined (no auto-connect, avoid public Wi-Fi for sensitive operations)
+  3. Network segmentation applied where applicable (separate guest networks, development environments)
+  4. Cellular or personal hotspot preferred over public Wi-Fi for sensitive work
+
+**Evaluator's assessment:**
+- **/opsec/travel/guide** → Network safety – avoid untrusted Wi-Fi & Bluetooth — **full**
+  Met: VPN or cellular connection preferred for sensitive operations; Wi-Fi security standards (disable auto-connect, avoid public Wi-Fi); Cellular or personal hotspot preferred over public Wi-Fi
+  Missed: Network segmentation not covered
+- **/opsec/control-domains/technical** → Network & Communication Security — **full**
+  Met: Network segmentation based on security requirements; Secure remote access solutions (VPN); Network monitoring
+
+### ws-5.1.2: Secure Communications
+**Full baselines:**
+  1. End-to-end encrypted channels used for sensitive communications
+  2. Identity verification procedures established for sensitive requests (e.g., access changes, financial approvals, credential sharing)
+  3. Anti-impersonation protocols documented (e.g., secondary channel verification, code words, video confirmation)
+  4. Email security configured (SPF, DKIM, DMARC) to prevent spoofing
+  5. Procedures for channel compromise including switching to backup channels
+
+**Evaluator's assessment:**
+- **/opsec/travel/guide** → Plan emergency and incident responses — **partial**
+  Met: Fallback plan for communication (safe words, beware deepfakes)
+  Missed: End-to-end encrypted channels used; Identity verification procedures for sensitive requests; Anti-impersonation protocols documented; Email security (SPF, DKIM, DMARC); Procedures for channel compromise
+- **/guides/account_management/telegram** → Use Secret Chats for Enhanced Privacy — **partial**
+  Met: End-to-end encrypted channels (Secret Chats); Identity verification (compare encryption keys)
+  Missed: Anti-impersonation protocols beyond basic verification; Email security configuration; Procedures for channel compromise
+- **/opsec/control-domains/technical** → Network & Communication Security — **partial**
+  Met: Encrypted communications protecting data in transit
+  Missed: Identity verification procedures; Anti-impersonation protocols; Email security (SPF, DKIM, DMARC); Channel compromise procedures
+**Gaps:** Anti-impersonation protocols documented (e.g., secondary channel verification, code words, video confirmation); Email security configured (SPF, DKIM, DMARC) to prevent spoofing; Procedures for channel compromise including switching to backup channels
+
+### ws-6.1.1: Security Onboarding
+**Full baselines:**
+  1. Identity and authorization verified before any access is provisioned
+  2. Background checks or identity verification appropriate to role sensitivity
+  3. Security onboarding includes device provisioning, account creation, MFA setup, and initial security training
+  4. New personnel acknowledge security policies before access is granted
+  5. Onboarding checklist documented and consistently applied
+
+**Evaluator's assessment:**
+- **/opsec/control-domains/people** → Personnel Security Measures — **partial**
+  Met: Pre-employment screening procedures; Security agreements for all team members; Security responsibilities in job descriptions
+  Missed: Security onboarding includes device provisioning, account creation, MFA setup, and initial training; New personnel acknowledge policies before access; Onboarding checklist documented and consistently applied
+**Gaps:** Security onboarding includes device provisioning, account creation, MFA setup, and initial security training; New personnel acknowledge security policies before access is granted; Onboarding checklist documented and consistently applied
+
+### ws-6.1.2: Security Offboarding
+**Full baselines:**
+  1. All account access revoked within 24 hours of departure
+  2. Devices returned and verified for data sanitization
+  3. Credentials and secrets rotated for any shared systems the departing person accessed
+  4. Offboarding checklist documented covering: account deprovisioning, device return, credential rotation, access to organizational repositories and tools, recovery of company property
+  5. Involuntary departures trigger immediate access revocation before notification where feasible
+
+**Evaluator's assessment:**
+- **/opsec/travel/guide** → Back up and prepare for loss — **partial**
+  Met: Remote wipe capability for devices
+  Missed: All account access revoked within 24 hours; Credentials rotated for shared systems; Offboarding checklist; Involuntary departures trigger immediate revocation
+- **/awareness/understanding-threat-vectors**  — **partial**
+  Met: General awareness of insider threats
+  Missed: Specific offboarding procedures; Account revocation timeline; Credential rotation; Device return and sanitization; Offboarding checklist
+- **/guides/account_management/discord** → Regular Reviews — **partial**
+  Met: Remove unnecessary role members
+  Missed: 24-hour revocation timeline; Device return; Credential rotation; Comprehensive offboarding checklist; Involuntary departure procedures
+**Gaps:** All account access revoked within 24 hours of departure; Devices returned and verified for data sanitization; Credentials and secrets rotated for any shared systems the departing person accessed; Offboarding checklist documented covering: account deprovisioning, device return, credential rotation, access to organizational repositories and tools, recovery of company property; Involuntary departures trigger immediate access revocation before notification where feasible
+
+### ws-6.1.3: Security Awareness and Training
+**Full baselines:**
+  1. Training covers workspace security topics: phishing, social engineering, device security, credential hygiene, and incident reporting
+  2. Phishing simulations conducted at least quarterly
+  3. Follow-up training required for personnel who fail simulations
+  4. Training content updated annually and after significant threats or procedure changes
+  5. Covers crypto-specific risks: fake job offers, malicious browser extensions, clipboard hijacking, social engineering via DMs
+
+**Evaluator's assessment:**
+- **/awareness/staying-informed-and-continuous-learning** → Comprehensive Security Training Framework — **full**
+  Met: Training covers phishing, social engineering, device security, credential hygiene, incident reporting; Training content updated annually; Crypto-specific risks covered (fake job offers, malicious extensions, clipboard hijacking, social engineering via DMs)
+  Missed: Phishing simulations conducted quarterly; Follow-up training for those who fail simulations
+- **/opsec/control-domains/people** → Security Training & Culture — **partial**
+  Met: Comprehensive security awareness program; Role-specific training; Continuous learning about emerging threats
+  Missed: Phishing simulations quarterly; Follow-up training for failures; Crypto-specific risks detail
+- **/opsec/appendices/case-studies**  — **partial**
+  Met: Real-world scenarios for training; Tabletop exercises
+  Missed: Regular phishing simulations; Follow-up training process; Training content update schedule; Crypto-specific risks coverage
+**Gaps:** Phishing simulations conducted at least quarterly; Follow-up training required for personnel who fail simulations
+
+### ws-7.1.1: Workspace Security Monitoring and Incident Response
+**Full baselines:**
+  1. Monitoring in place for common workspace threats: account takeovers, unauthorized access, credential leaks, device compromise, data exfiltration
+  2. Response procedures documented for key scenarios: compromised account, compromised device, data leak, insider threat event
+  3. Escalation paths defined with severity levels
+  4. Credential leak monitoring (dark web, breach databases, paste sites, code repositories)
+  5. Incidents documented with timeline, root cause, actions taken, and lessons learned
+
+**Evaluator's assessment:**
+- **/opsec/core-concepts/security-fundamentals** → Continuous Visibility — **partial**
+  Met: Multi-layered monitoring strategy; Regular testing cadence; Structured incident management process; Post-incident reviews
+  Missed: Monitoring for workspace-specific threats (account takeovers, unauthorized access, credential leaks, device compromise, data exfiltration); Response procedures for workspace scenarios; Credential leak monitoring
+- **/opsec/appendices/case-studies** → Tabletop Exercises — **partial**
+  Met: Incident response scenarios and procedures; Tabletop exercises for testing
+  Missed: Ongoing monitoring in place; Credential leak monitoring; Documented procedures for specific workspace scenarios
+**Gaps:** Monitoring in place for common workspace threats: account takeovers, unauthorized access, credential leaks, device compromise, data exfiltration; Response procedures documented for key scenarios: compromised account, compromised device, data leak, insider threat event; Credential leak monitoring (dark web, breach databases, paste sites, code repositories)
+
+### ws-7.1.2: Insider Threat Assessment
+**Full baselines:**
+  1. Damage scenarios documented for each role (what could this person do if compromised or malicious?)
+  2. Least-privilege access enforced across all systems
+  3. Separation of duties applied for critical operations (e.g., no single person can deploy to production, execute large transactions, and manage access controls)
+  4. Assessed during periodic access reviews
+
+**Evaluator's assessment:**
+- **/opsec/core-concepts/security-fundamentals** → Minimal Access Scopes — **partial**
+  Met: Least-privilege access enforced
+  Missed: Damage scenarios documented for each role; Separation of duties for critical operations; Assessed during access reviews
+- **/opsec/control-domains/people** → Insider-Threat Mitigation — **full**
+  Met: Least-privilege access enforced across all systems; Monitoring for critical systems and sensitive data access; Guidelines for identifying concerning behaviors
+  Missed: Damage scenarios documented for each role not explicitly covered; Separation of duties applied for critical operations not detailed
+**Gaps:** Damage scenarios documented for each role (what could this person do if compromised or malicious?); Separation of duties applied for critical operations (no single person can deploy to production, execute large transactions, and manage access controls)
+
+### ws-7.1.3: Third-Party Access Management
+**Full baselines:**
+  1. Third-party access requires documented approval with defined scope and expiry date
+  2. Access limited to minimum necessary systems and data
+  3. Access revoked automatically upon contract expiry or project completion
+  4. Audit trails maintained for all third-party access
+  5. Third-party vendor security evaluated before granting access (security certifications, incident history)
+
+**Evaluator's assessment:**
+- **/opsec/core-concepts/security-fundamentals** → Minimal Access Scopes — **partial**
+  Met: Just-in-time access for administrative functions; Time-based restrictions to elevated privileges
+  Missed: Third-party access requires documented approval with scope and expiry; Access limited to minimum necessary systems; Automatic revocation upon contract expiry; Audit trails for third-party access; Vendor security evaluation
+- **/guides/account_management/discord** → Integrations — **partial**
+  Met: Review bot permissions and remove unnecessary; Least privilege for integrations
+  Missed: Documented approval with scope and expiry; Automatic revocation upon contract end; Audit trails; Vendor security evaluation before granting access
+**Gaps:** Third-party access requires documented approval with defined scope and expiry date; Access limited to minimum necessary systems and data; Access revoked automatically upon contract expiry or project completion; Audit trails maintained for all third-party access; Third-party vendor security evaluated before granting access (security certifications, incident history)
+
+## FALSE-NEGATIVE CHECK (1 controls marked "no coverage")
+
+Verify these truly have no relevant framework page. If any page below partially covers them, note it.
+
+### ws-1.1.2: Workspace Security Policy
+**Baselines:** Policy covers core expectations including device security, account hygiene, credential management, acceptable use, and incident reporting; Written in plain language so all personnel can follow it; Policy reviewed at least annually and after significant changes (security incidents, technology shifts, organizational restructuring)
+
+---
+
+## FRAMEWORK PAGES (15 pages)
+
+### PAGE: /awareness/cultivating-a-security-aware-mindset
+
+# 3. Cultivating a Security-Aware Mindset
+
+
+
+
+> 🔑 **Key Takeaway**: Developing a security-aware mindset is about building habits that prioritize caution and
+> verification. By questioning unusual requests, pausing before acting, and leveraging peer support, you transform
+> security from a set of rules into an intuitive approach to daily interactions.
+
+## 3.1. Behavioral Best Practices
+
+### Practical Tips
+
+- **Question Unusual Requests:**
+
+Always verify any request for sensitive information or financial transactions through a separate communication channel.
+
+- **Pause Before Reacting:**
+
+Take a moment to think before clicking a link or downloading an attachment. **Example:** If you get an unexpected file
+from a colleague, call them directly to confirm they sent it.
+
+- **Peer Verification:**
+
+Leverage your team by asking a colleague's opinion if something seems off.
+
+> **Scenario Example**
+A community manager receives a direct message on Discord that looks like it comes from a well-known project partner,
+asking for private credentials. Instead of immediately responding, they cross-check the message in a team meeting or via
+a known contact method.
+
+## 3.2 Awareness in Community Settings
+
+### Unique Challenges on Social Platforms
+
+- **Platform-Specific Red Flags:**
+
+Each community platform—Discord, Twitter, Telegram—has its own quirks.
+**Example:** On Telegram, unsolicited group invites with suspicious usernames could be phishing attempts.
+
+- **Community Role Awareness:**
+
+Moderators and administrators should be extra cautious since they have higher privileges.
+**Example:** A moderator on a crypto project Discord might notice a sudden spike in login attempts from an unfamiliar IP
+ range.
+
+- **Culture of Reporting:**
+
+Foster an environment where suspicious behavior is immediately reported and discussed, not brushed aside.
+
+> **Scenario Example**
+During a routine community chat, several members report receiving odd messages that urge them to click on a link. The
+community manager organizes a quick session to remind members of red flags and the correct reporting channels,
+reinforcing collective vigilance.
+
+## 3.3 Organizational Strategies for Security Culture
+
+- **Leadership Commitment:**
+
+Ensure that leadership demonstrates a strong commitment to security by prioritizing and investing in security
+initiatives. Leaders should model security-conscious behavior and allocate appropriate resources to security efforts.
+
+- **Regular Communication:**
+
+Communicate the importance of security regularly through team meetings, newsletters, and other channels. Keep security
+topics visible and relevant to all team members.
+
+- **Security Policies and Procedures:**
+
+Develop and enforce clear security policies and procedures that outline expectations and responsibilities for all team
+members.
+
+- **Encourage Reporting:**
+
+Create an environment where team members feel comfortable reporting security incidents, suspicious activities, and
+potential vulnerabilities without fear of retribution.
+
+- **Recognition and Rewards:**
+
+Recognize and reward team members who demonstrate exemplary security practices and contribute to the organization's
+security efforts.
+
+- **Continuous Improvement:**
+
+Continuously assess and improve the project's security culture through feedback, assessments, and audits.
+
+- **Shared Responsibility:**
+
+Instill a sense of responsibility for security at all levels of the project, emphasizing that security is everyone's
+job.
+
+- **Collaboration:**
+
+Promote collaboration and information sharing among team members to enhance overall security awareness and response
+capabilities.
+
+> **Scenario Example**
+A project implements a monthly "Security Spotlight" where different aspects of security are highlighted, and team
+members can share their experiences or ask questions. This regular touchpoint keeps security top-of-mind and encourages
+ongoing dialogue about best practices.
+
+## 3.4 Essential Security Practices
+
+### 3.4.1. Password Management
+
+- **Strong, Unique Passwords:**
+
+Use complex, unique passwords for each account to prevent credential stuffing attacks.
+**Example:** A passphrase like "correct-horse-battery-staple" (with four random words) is both strong and memorable,
+while being more secure than shorter passwords with special characters like "P@ssw0rd!".
+
+- **Password Managers:**
+
+Utilize a reputable password manager to securely store and generate complex passwords.
+**Example:** Tools like Bitwarden, 1Password, or KeePassXC can generate and store unique passwords for all your
+accounts.
+
+### 3.4.2. Multi-Factor Authentication (MFA)
+
+- **Enable MFA Everywhere Possible:**
+
+Add an extra layer of security beyond just passwords.
+**Example:** Even if someone obtains your password, they still can't access your account without the second factor.
+
+- **Choose Secure MFA Methods:**
+
+Hardware tokens and authenticator apps are more secure than SMS-based verification.
+**Example:** Use YubiKeys or authenticator apps like Authy instead of SMS, which can be vulnerable to SIM swapping
+attacks.
+
+### 3.4.3. Secure Communication
+
+- **End-to-End Encryption:**
+
+Use messaging platforms with end-to-end encryption for sensitive communications.
+**Example:** Signal provides strong encryption for messages, ensuring only the intended recipient can read them.
+
+- **Verify Communication Channels:**
+
+Be cautious of unexpected platform changes for important communications.
+**Example:** If a colleague suddenly asks to switch from your company's official channel to a personal messaging app for
+ work discussions, verify this request directly.
+
+### 3.4.4. Device Security
+
+- **Keep Systems Updated:**
+
+Regularly update your operating system and applications to patch security vulnerabilities.
+**Example:** Schedule automatic updates or set a weekly reminder to check for and install updates.
+
+- **Secure Your Workspace:**
+
+Be mindful of physical security in shared or public spaces.
+**Example:** Use privacy screens when working in public and lock your device when stepping away.
+
+## 3.5. Incident Response Awareness
+
+### 3.5.1. Recognizing Security Incidents
+
+- **Know the Warning Signs:**
+
+Understand what constitutes a potential security incident.
+**Example:** Unexpected account lockouts, strange system behavior, or unusual access requests could indicate a breach.
+
+- **Immediate Actions:**
+
+Know what steps to take when you suspect a security incident.
+**Example:** Disconnect from networks, document what happened, and report to your security team immediately.
+
+### 3.5.2. Reporting Procedures
+
+- **Clear Reporting Channels:**
+
+Ensure everyone knows how and where to report security concerns.
+**Example:** Have a dedicated email address or communication channel specifically for security reports.
+
+- **No-Blame Culture:**
+
+Encourage prompt reporting by focusing on solutions rather than blame.
+**Example:** Acknowledge and thank team members who report potential issues, even if they turn out to be false alarms.
+
+> **Scenario Example**
+A team member notices unusual login attempts to their account. Instead of ignoring it or feeling embarrassed, they
+immediately report it to the security team, who can then investigate whether this is part of a larger attack pattern
+affecting other users.
+
+---
+
+---
+
+### PAGE: /awareness/staying-informed-and-continuous-learning
+
+# 4. Staying Informed & Continuous Learning
+
+
+
+
+> 🔑 **Key Takeaway**: Security is not a one-time achievement but an ongoing journey of learning and adaptation. By
+> establishing regular training routines, staying current with emerging threats, and fostering a culture of continuous
+> improvement, you ensure your security awareness remains effective against evolving challenges.
+
+## 4.1. Comprehensive Security Training Framework
+
+### 4.1.1. Training Approaches
+
+- **Bite-Sized Learning:**
+
+Security training doesn't need to be lengthy or overwhelming. Short, focused sessions of relevant information can be
+more effective than infrequent, lengthy presentations.
+Example: Weekly 5-minute security tips delivered via team chat or email.
+
+- **Role-Based Training:**
+
+Tailor security training to specific roles and access levels within your organization.
+Example: Developers might need more in-depth training on secure coding practices, while community managers might focus
+more on social engineering awareness.
+
+- **Recurring Schedule:**
+
+Make security training a regular, ongoing activity rather than a one-time event.
+Example: Monthly security topics with quarterly refreshers on critical subjects.
+
+- **Practical Application:**
+
+Include hands-on exercises that allow people to apply what they've learned.
+Example: Conduct simulated phishing tests followed by immediate feedback and learning opportunities.
+
+- **Interactive Training Methods:**
+
+Use interactive training methods, such as SEAL Wargames or workshops to engage team members and enhance learning.
+
+- **Real-World Scenarios:**
+
+Incorporate real-world scenarios and case studies to illustrate the impact of security breaches and the importance of
+preventive measures.
+
+- **Assessments and Quizzes:**
+
+Use assessments and quizzes to evaluate the effectiveness of training and identify areas where additional training may
+be needed.
+
+### 4.1.2. Training Delivery
+
+- **Regular Awareness Sessions:**
+
+Schedule quarterly webinars or short training refreshers focusing on the latest trends and emerging threats.
+
+- **Interactive Simulations:**
+
+Participate in phishing simulations or scenario-based exercises that allow you to practice identifying and responding to
+threats in a risk-free environment.
+
+- **Security Awareness Campaigns:**
+
+Implement periodic campaigns that focus on specific security themes to reinforce key messages.
+Example: A "Phishing Awareness Month" with targeted activities and resources.
+
+### 4.1.3. Measuring Training Effectiveness
+
+- **Baseline Assessments:**
+
+Conduct assessments before and after training to measure improvement.
+
+- **Behavioral Metrics:**
+
+Track security-related behaviors such as reporting rates for suspicious emails or incidents.
+
+- **Feedback Collection:**
+
+Gather participant feedback to continuously improve training content and delivery methods.
+
+## 4.2. Essential Training Topics
+
+- **Phishing and Social Engineering:**
+
+Educate team members on recognizing and responding to phishing attacks and social engineering tactics, with special
+focus on web3-specific threats.
+
+- **Password Management:**
+
+Provide best practices for creating and managing strong passwords and using password managers.
+
+- **Data Protection:**
+
+Teach methods for protecting sensitive data, including encryption, access controls, and secure data handling practices.
+
+- **Incident Reporting:**
+
+Instruct team members on how to report security incidents and suspicious activities promptly.
+
+- **Secure Coding Practices:**
+
+For developers, provide training on secure coding practices and common vulnerabilities in web3 environments.
+
+- **Device and Account Security:**
+
+Cover best practices for securing devices and accounts, including updates, encryption, and access controls.
+
+- **Emerging Threats:**
+
+Keep team members informed about new and evolving security threats relevant to your organization.
+
+## 4.3. Trusted Information Sources
+
+### 4.3.1. Security Newsletters
+
+- **Industry News:**
+
+Subscribe to newsletters from sources such as FIRST.org for broader cybersecurity trends.
+Example: The SANS NewsBites provides twice-weekly summaries of the most important security news.
+
+- **Vendor Updates:**
+
+Follow security updates from the software and hardware vendors in your project stack.
+Example: Subscribe to security bulletins from cloud providers, operating system vendors, and key software dependencies.
+
+### 4.3.2. Security Communities
+
+- **Online Forums and Groups:**
+
+Join online communities dedicated to security topics.
+Example: The SEAL Discord provides a space to discuss security challenges specific to web3 projects.
+
+- **Local and Virtual Meetups:**
+
+Attend security-focused events to network and learn.
+Example: Conferences like DeFi Security Summit offer insights into emerging threats and defenses.
+
+### 4.3.3. Security Blogs and Podcasts
+
+- **Technical Blogs:**
+
+Follow security researchers and organizations that regularly publish detailed analyses.
+Example: Trail of Bits blog provides in-depth technical security content.
+
+- **Security Podcasts:**
+
+Listen to podcasts that cover current security topics.
+Example: The Daily Stormcast from FIRST.org offers brief daily updates, while Darknet Diaries provides longer-form
+stories about notable security incidents.
+
+## 4.4. Implementing a Learning Culture
+
+- **Share Knowledge:**
+
+Create channels for team members to share security articles, news, and insights.
+Example: A dedicated Slack channel for security-related content.
+
+- **Recognize Vigilance:**
+
+Acknowledge and reward security-conscious behavior.
+Example: Highlight team members who identify and report potential security issues.
+
+- **Learn from Incidents:**
+
+Use security incidents (both internal and external) as learning opportunities.
+Example: After major industry breaches, conduct brief sessions to discuss what happened and how similar issues could be
+prevented in your organization.
+
+---
+
+---
+
+### PAGE: /awareness/understanding-threat-vectors
+
+# 2. Understanding Threat Vectors
+
+
+
+
+> 🔑 **Key Takeaway**: Understanding the various ways attackers can target you and your organization is essential for
+> effective defense. By recognizing common attack patterns like phishing, social engineering, and emerging threats in
+> digital spaces, you can better protect yourself and your team from potential security breaches.
+
+## 2.1. Traditional Attack Vectors
+
+### 2.1.1. Social Engineering & Phishing
+
+- **Phishing Emails:**
+
+Look for red flags like misspellings, odd URLs, and urgent language.
+**Scenario Example:** An email that claims "Your account will be locked in 24 hours" but uses a suspicious domain.
+
+- **SMS & Messaging Scams:**
+
+Attackers may use text messages or direct social media messages to bypass email filters.
+**Scenario Example:** A text message that claims to be from a delivery service asking for a confirmation code.
+
+- **Voice Phishing (Vishing):**
+
+Phone calls that pretend to be from a trusted organization, often using spoofed caller IDs.
+**Scenario Example:** A staff member receives a voicemail warning about a potential security breach and instructing them
+to call a specific number immediately.
+
+- **Pretexting:**
+
+Attackers create a fabricated scenario to steal personal information or gain access.
+**Scenario Example:** Someone pretending to be a new contractor who needs urgent access to systems or information.
+
+- **Baiting:**
+
+Offering something enticing to entrap the victim.
+**Scenario Example:** Leaving infected USB drives in public places or offering free downloads that contain malware.
+
+- **Tailgating:**
+
+Physically following authorized personnel into restricted areas without proper credentials.
+**Scenario Example:** An unknown person following an employee through a secure door by claiming they forgot their access
+card.
+
+- **Shoulder Surfing:**
+
+Observing someone's screen, keyboard, or device to gather information.
+**Scenario Example:** A threat actor monitoring your screen in a shared co-working space to capture sensitive
+information or credentials.
+
+### 2.1.2. Malware & Technical Attacks
+
+- **Ransomware:**
+
+Malicious software that encrypts files and demands payment for decryption.
+**Scenario Example:** An organization finds their critical files encrypted with a ransom note demanding cryptocurrency
+payment.
+
+- **Man-in-the-Middle Attacks:**
+
+Intercepting communications between two parties.
+**Scenario Example:** An attacker on a public Wi-Fi network intercepts unencrypted traffic to steal credentials.
+
+- **Credential Stuffing:**
+
+Using stolen username/password combinations to attempt access to multiple services.
+**Scenario Example:** After a data breach at one service, attackers try the same credentials on financial or email
+accounts.
+
+## 2.2. Web3-Specific Threats
+
+### 2.2.1. Crypto-Focused Attacks
+
+- **Crypto Drainers:**
+
+A common attack where a threat actor suggests users can participate in an airdrop by visiting a provided link.
+Unsuspecting users who click the link are directed to a counterfeit website, where they are asked to authenticate their
+wallet and sign a transaction. Once signed, the threat actor gains access to steal funds from the wallet.
+
+- **Rug Pulls:**
+
+In the context of web3 and cryptocurrencies, these scams typically involve fraudulent schemes designed to swindle
+individuals out of their digital assets. For example, an enticing new project may promise revolutionary technology and
+unprecedented returns. However, the project developers quickly vanish, leaving investors with worthless tokens and empty
+promises.
+
+- **Token Approval Exploits:**
+
+Attackers may trick users into approving smart contracts that give unlimited access to tokens in their wallet. These
+"allowances" permit the approved contract to transfer any amount of a specific token without further permission. Always
+verify what permissions you're granting when signing transactions and set specific approval limits when possible.
+
+### 2.2.2. Smart Contract Vulnerabilities
+
+- **Reentrancy Attacks:**
+
+Exploiting a contract's execution flow to repeatedly withdraw funds.
+**Scenario Example:** A malicious contract calls back into the victim contract before the first execution is complete,
+draining funds with each call.
+
+- **Flash Loan Attacks:**
+
+Using uncollateralized loans to manipulate market prices and exploit vulnerabilities.
+**Scenario Example:** An attacker borrows a large amount of cryptocurrency, manipulates a price oracle, exploits a
+vulnerability, and repays the loan in a single transaction.
+
+## 2.3. Common Indicators & Red Flags
+
+### 2.3.1. Behavioral Cues
+
+- **Inconsistencies:**
+
+Look for changes in tone or style in communications from known contacts.
+**Scenario Example:** A normally formal manager sends a casual message with unexpected requests.
+
+- **Unusual Requests:**
+
+Requests for urgent transfers of money, sensitive information, or changes in process should always trigger caution.
+
+- **Environmental Anomalies:**
+
+Spotting unexpected logins or unfamiliar devices in account activity reports can indicate compromised accounts.
+
+### 2.3.2. Technical Indicators
+
+- **Unexpected Authentication Prompts:**
+
+Sudden requests to re-authenticate without clear reason.
+**Scenario Example:** Being asked to provide credentials on a site you're already logged into.
+
+- **Browser Certificate Warnings:**
+
+Alerts about invalid or expired security certificates.
+**Scenario Example:** Your browser displays a warning that a connection is not secure when visiting a familiar website.
+
+- **Unusual System Behavior:**
+
+Slowdowns, crashes, or unexpected pop-ups.
+**Scenario Example:** Your computer suddenly runs significantly slower or displays unfamiliar advertisements.
+
+### 2.3.3. Checklist for Suspicious Communications
+
+- Does the message contain spelling errors or unusual formatting?
+- Is the sender's email or username slightly different from the norm?
+- Are there requests for urgent action without proper verification channels?
+- Does the message create a sense of fear, urgency, or excitement?
+- Is there an unexpected attachment or link?
+- Does the request bypass normal security procedures?
+
+## 2.4. Preventive Measures
+
+### 2.4.1. General Security Practices
+
+- **Double-Check Requests:**
+
+Always verify the identity of individuals requesting sensitive information, especially if the request is unusual or
+urgent.
+**Scenario Example:** If you receive an email from your CEO asking for an urgent wire transfer, call them directly using
+a known phone number to confirm.
+
+- **Use Secure Channels:**
+
+Communicate through official channels and avoid sharing sensitive information over unsecured methods.
+**Scenario Example:** Use your organization's established communication platforms rather than responding to external
+email links.
+
+### 2.4.2. Web3-Specific Protections
+
+- **Check & Remove Token Approvals:**
+
+Regularly check which smart contracts have approvals to handle funds in your wallet and revoke unnecessary approvals to
+improve your security posture.
+**Useful Tools:**
+
+- [Unrekt](https://app.unrekt.net/)
+- [Etherscan Token Approval Checker](https://etherscan.io/tokenapprovalchecker)
+
+- **Scrutinize Transaction Requests:**
+
+Never sign a transaction unless you are completely sure exactly what you are signing. Be especially skeptical of offers
+that seem too good to be true.
+
+- **Hardware Wallets for Critical Assets:**
+
+Use hardware wallets for storing significant cryptocurrency holdings.
+**Scenario Example:** Keeping your long-term investments on a hardware wallet while only maintaining small amounts in
+hot wallets for daily transactions.
+
+---
+
+---
+
+### PAGE: /encryption/partition-encryption
+
+# Partition Encryption
+
+
+
+
+## What is Partition Encryption?
+
+Partition encryption is the process of encrypting specific partitions on a storage device. This allows for selective
+encryption of data, providing flexibility in managing encrypted and un-encrypted data on the same device. Unlike full
+disk encryption, which encrypts the entire disk, partition encryption targets specific areas, making it ideal for
+protecting sensitive data without impacting the entire storage system.
+
+## Importance of Partition Encryption
+
+Partition encryption is crucial for protecting sensitive information from unauthorized access, especially in
+environments where different types of data coexist on the same device. It helps prevent data breaches in case of
+unauthorized access to specific partitions and ensures compliance with data protection regulations.
+
+## Uses of Partition Encryption
+
+- **Protecting Sensitive Data**: Ensures that sensitive information stored on specific partitions is secure.
+- **Compliance**: Helps organizations meet regulatory requirements for data protection.
+- **Data Breach Prevention**: Reduces the risk of data breaches in case of unauthorized access to specific partitions.
+- **Secure Decommissioning**: Ensures that data on encrypted partitions is not recoverable when storage devices are
+decommissioned or repurposed.
+
+## Examples of Partition Encryption
+
+- **BitLocker**: A partition encryption feature included with Microsoft Windows that provides encryption for specific
+  partitions. [Learn how to use
+  BitLocker](https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-overview)
+- **LUKS (Linux Unified Key Setup)**: A disk encryption specification for Linux that provides a standard for partition
+  encryption. [Learn how to use LUKS](https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions)
+- **VeraCrypt**: An open-source disk encryption software that can encrypt specific partitions. [Learn how to use
+  VeraCrypt](https://www.veracrypt.fr/en/Documentation.html)
+
+## Best Practices for Partition Encryption
+
+1. **Use Strong Encryption Algorithms**: Ensure that the encryption algorithms used are strong and up-to-date, such as
+  AES-256.
+2. **Enable Encryption on Sensitive Partitions**: Apply partition encryption to all partitions that store sensitive
+  information.
+3. **Regularly Update Encryption Software**: Keep encryption software and tools updated to protect against
+  vulnerabilities.
+4. **Implement Access Controls**: Use strong authentication methods, such as multi-factor authentication (MFA), to
+  control access to encrypted partitions.
+5. **Backup Encryption Keys**: Securely backup encryption keys to prevent data loss in case of key corruption or loss.
+6. **Monitor and Audit**: Regularly monitor and audit encryption settings and access logs to ensure compliance and
+  detect any unauthorized access attempts.
+
+By following these best practices and using reliable partition encryption technologies, organizations can significantly
+enhance the security of their data and protect against unauthorized access and data breaches.
+
+---
+
+---
+
+### PAGE: /encryption/volume-encryption
+
+# Volume Encryption
+
+
+
+
+## What is Volume Encryption?
+
+Volume encryption is the process of encrypting a specific storage volume or partition to protect the data it contains.
+Unlike full disk encryption, which encrypts the entire disk, volume encryption allows for selective encryption of
+specific volumes, providing flexibility in managing encrypted and un-encrypted data on the same device.
+
+## Importance of Volume Encryption
+
+Volume encryption is essential for protecting sensitive information from unauthorized access, especially in environments
+where different types of data coexist on the same device. It helps prevent data breaches in case of unauthorized access
+to specific volumes and ensures compliance with data protection regulations.
+
+## Uses of Volume Encryption
+
+- **Protecting Sensitive Data**: Ensures that sensitive information stored on specific volumes is secure.
+- **Compliance**: Helps organizations meet regulatory requirements for data protection.
+- **Data Breach Prevention**: Reduces the risk of data breaches in case of unauthorized access to specific volumes.
+- **Secure Decommissioning**: Ensures that data on encrypted volumes is not recoverable when storage devices are
+  decommissioned or repurposed.
+
+## Examples of Volume Encryption
+
+- **Partition Encryption**: Encrypts specific partitions or volumes on a disk, allowing for selective encryption of
+  sensitive data.
+- **Virtual Encrypted Disks**: Creates virtual encrypted disks within files, providing an additional layer of security
+  for sensitive data.
+
+## Known Technologies for Volume Encryption
+
+- **BitLocker**: A volume encryption feature included with Microsoft Windows that provides encryption for specific
+  volumes.
+- **LUKS (Linux Unified Key Setup)**: A disk encryption specification for Linux that provides a standard for volume
+  encryption.
+- **VeraCrypt**: An open-source disk encryption software that can create virtual encrypted disks within a file or
+  encrypt specific partitions.
+
+## Best Practices for Volume Encryption
+
+1. **Use Strong Encryption Algorithms**: Ensure that the encryption algorithms used are strong and up-to-date, such as
+  AES-256.
+2. **Enable Encryption on Sensitive Volumes**: Apply volume encryption to all volumes that store sensitive information.
+3. **Regularly Update Encryption Software**: Keep encryption software and tools updated to protect against
+  vulnerabilities.
+4. **Implement Access Controls**: Use strong authentication methods, such as multi-factor authentication (MFA), to
+  control access to encrypted volumes.
+5. **Backup Encryption Keys**: Securely backup encryption keys to prevent data loss in case of key corruption or loss.
+6. **Monitor and Audit**: Regularly monitor and audit encryption settings and access logs to ensure compliance and
+  detect any unauthorized access attempts.
+
+By following these best practices and using reliable volume encryption technologies, organizations can significantly
+enhance the security of their data and protect against unauthorized access and data breaches.
+$$
+
+---
+
+---
+
+### PAGE: /guides/account_management/discord
+
+# Discord Security
+
+
+
+
+## Summary
+
+> 🔑 **Key Takeaway for Discord:** To secure your Discord server, focus on implementing robust access controls and
+> enforcing two-factor authentication for all administrators. Regularly audit roles and permissions, and maintain
+> vigilant moderation. Educate your community about security best practices to prevent unauthorized access and protect
+> against potential threats.
+
+Discord offers a variety of security features that are essential to use. Despite these, users should stay alert to
+threats like phishing, which can target server moderators. Such threats may appear as QR code scams, fake login screens,
+or misleading direct messages pretending to be from Discord support.
+
+To enhance the security of your Discord server, take into account these suggestions. They cover important aspects like
+server settings, roles and permissions, moderation, bots, channels, invites, member screening, logging, and other
+security measures.
+
+---
+
+## For Individuals
+
+These settings apply to your personal Discord account. All team members, moderators, and admins should configure these
+on their own accounts.
+
+### Account Security Checklist
+
+- [ ] User Settings > My Account: Ensure **2FA** is enabled (authenticator app and/or security key), Remove a phone
+  number if you have one added to your account, and after 2FA is setup select **View Backup Codes**, and note down
+  your backup codes offline
+- [ ] User Settings > My Account: Ensure **SMS Backup Authentication** is **disabled**
+- [ ] User Settings > Content & Social > Social Permissions: Allow DMs from other server members > **Disabled**
+- [ ] User Settings > Content & Social > Direct Message Spam: Select **Filter all** to filter all DMs for spam
+  (encourages moderators and community members to adopt the same setting to minimize phishing DMs)
+- [ ] User Settings > Authorized Apps: Review and **Deauthorize** any unnecessary apps
+- [ ] User Setting > Devices: Review and remove unnecessary devices, or **Log Out All Known Devices**
+- [ ] User Settings > Connections: Review and remove any unnecessary connections
+
+---
+
+## For Team Members
+
+These guidelines apply to moderators and team members who help manage the server but don't have full administrative access.
+
+Team members should:
+
+- Understand the permissions their role grants using **Server Settings > Roles > View Server as Role** — this allows
+  you to see what members with a certain role can see and access
+- Be aware of the server's AutoMod rules for: Spam, Harmful Links, Mention Spam, Inappropriate Words, and any custom
+  keyword filters and exempted roles
+
+---
+
+## For Admins
+
+These settings and practices apply to server administrators with elevated privileges.
+
+### Server Settings Checklist
+
+#### Safety Setup
+
+- Safety Setup > Moderation:
+  - [ ] Require 2FA for moderation > **Enabled**
+  - This ensures all moderators have an extra layer of security
+- Safety Setup > Verification Level:
+  - [ ] Choose from: None, Low, Medium, High, Highest
+  - [ ] Set to at least **Medium** (registered on Discord for 5+ minutes) — Recommended: "Moderate" for public servers
+  - Higher levels protect against spammers and raids
+- Safety Setup > Raid Protection and CAPTCHA:
+  - [ ] Activate all relevant settings to require CAPTCHA for new user actions
+  - [ ] Activity Alerts > **Enabled**
+  - [ ] CAPTCHA suspicious accounts before they are able to join > **Enabled**
+  - [ ] CAPTCHA all accounts before they are able to join during a suspected raid > **Enabled**
+  - This protection uses machine learning to detect and block bot-driven join-raids. When activated, it sends alerts
+    to a specified channel and requires CAPTCHA verification for new users for one hour after detection.
+- Safety Setup > DM and Spam Protection:
+  - [ ] Hide DMs from suspicious users > **Enabled**
+  - [ ] Filter DMs from unknown users > **Enabled**
+  - [ ] Warn members before they visit outbound links > **Enabled**
+  - [ ] Hide all messages from and delete suspected spammers > **Enabled**
+
+#### AutoMod
+
+- Server Settings > Safety Setup > AutoMod:
+  - [ ] Set up rules for: **Spam**, **Harmful Links**, **Mention Spam**, **Inappropriate Words**
+  - [ ] Configure custom keyword filters and exempted roles
+  - [ ] Customize the response to spam (block message, send alert, timeout member)
+  - [ ] Add to the existing automod rule to block keywords in a user's name: Support, Bot, Admin, Tech, Helpdesk, etc.
+  - [ ] Create a private channel that mods, team, and admins have visibility to and set each AutoMod rule to send
+    logs to that channel for review
+
+#### Server Overview
+
+- Server Settings > Engagement > Default Notification Settings: Select **Only @mentions**
+  - Reduces potential spam notifications for members, making them more vigilant about suspicious or phishing content
+
+#### Roles
+
+- Server Settings > Roles:
+  - [ ] Review admin role members — high-privilege roles with **Administrator** permission should have **2-3 members
+    max**
+  - [ ] Review bot role permissions and confirm members list contains only the bot user
+  - [ ] Review mod role permissions and members list
+  - [ ] Review user role permissions — watch for: **Manage Channels**, **Manage Roles**, **Manage Webhooks**, **Manage
+    Server**, **Administrator**
+  - [ ] Remove any lingering or overly broad permissions, and any roles with excess or unintended members
+  - [ ] Check channel-level permission overrides on private channels
+
+> **Note on Role Permissions:** For each role, carefully review the 32 available permissions. Key permissions to
+> restrict: Administrator, Manage Webhooks, Manage Server, Manage Roles, & Manage Channels. Never give Admin or Kick
+> permissions to anyone you don't fully trust.
+>
+> **Administrator** should ideally be reserved for a single admin role with minimal members. It is recommended to have
+> no more than 2-3 admins with this privilege in order to reduce risk due to account compromise and insider threats,
+> but to retain some redundancy.
+>
+> Minimal bots actually need **Administrator** permissions. Review what permissions a bot actually needs and do not
+> default to Admin permissions just because developers request it as the easy option. If a bot does require
+> Administrator, mitigate this risk by monitoring the Discord audit logs frequently or create alerts on a private
+> channel to notify when admin permissions are exercised within the server.
+>
+> Permissions can also be set at the channel level. It is important to check your private channels for any permission
+> overrides that may have been set!
+
+#### Integrations
+
+- Server Settings > Integrations:
+  - [ ] Review each bot's permissions and remove unnecessary permissions
+  - [ ] Remove any unnecessary integrations & reevaluate necessity of integrations with excessive permissions
+- Server Settings > Integrations > Manage Bot/App > **Roles & Members** / **Channels**:
+  - [ ] Remove permissions for bots that ask for Admin or other permissions that aren't needed — use least privilege
+    with permissions at the role level and channel level
+  - [ ] Uninstall any bots that aren't actively used or needed
+  - [ ] Confirm all bots and apps are
+    [**Verified**](https://support-dev.discord.com/hc/en-us/articles/23926564536471-How-Do-I-Get-My-App-Verified)
+  - [ ] Restrict command permissions of integrations where possible (Manage > Roles & Members / Channels / Command
+    Overrides)
+- Server Settings > Integrations > Webhooks:
+  - [ ] Review and remove any unnecessary webhooks
+  - [ ] Reevaluate necessity of webhooks with excessive permissions
+
+> **Note on Integration Security:** Integrations and webhooks add 3rd party risk and permission misconfiguration risk.
+> Ensure that permissions are correct, and either remove external integrations or understand the risk they present.
+
+#### Invites
+
+- Server Settings > Invites:
+  - [ ] Review and delete unnecessary or old invites regularly
+
+#### Privacy Settings
+
+- Server Settings > Privacy Settings:
+  - [ ] Disable **Direct Messages** — this prevents users from DMing other members in this server
+
+#### Community Features
+
+- Server Settings > Community:
+  - [ ] Enable the Community Feature
+  - Unlocks tools like membership screening, server insights, welcome screen, and discovery settings. Helps maintain
+    a structured, secure environment by surfacing official rules and critical info to newcomers.
+- Server Settings > Server Insights:
+  - [ ] Enable Server Insights for detailed analytics
+  - Use this data to inform moderation strategies and server improvements
+
+> **Note on Safety Features:**
+>
+> - Activity alerts notify on anomalous DM activity, which could indicate your community is being targeted by scammers
+>   or social engineering attackers.
+> - Raid Protection and CAPTCHA can also be satisfied by a bot, if preferred over Discord's built-in functionality.
+> - Hiding/filtering DMs between server members is recommended to prevent scams, spam, and social engineering of your
+>   users.
+> - In the event of a security incident, Discord provides
+>   [**Security Actions**](https://support.discord.com/hc/en-us/articles/17439993574167-Activity-Alerts-Security-Actions#h_01HAD80CK67WF59GDGR7XGVAN8)
+>   for pausing invites and DMs to allow you to protect your community while responding to ongoing threats.
+
+---
+
+### Role Hierarchy Setup
+
+Roles should be structured with higher-privilege roles at the top. Go to Server Settings > Roles, create roles like
+Cold Admin, Team, Moderator, & Verified, and drag to reorder (higher roles override lower roles):
+
+1. Cold Admin (highest)
+2. Team
+3. Moderator
+4. Verified (lowest)
+
+**Recommended permissions by role:**
+
+| Role | Recommended Permissions |
+| ---- | ----------------------- |
+| **Moderators** | View Channels, View Audit Log, View Server Insights, Kick Members, Ban Members, Timeout Members, Send Messages and Create Posts, Embed Links, Attach Files, Add Reactions, Add External Emoji, Use External Stickers, Manage Messages, Bypass Slowmode, Read Message History, Request to Speak |
+| **Members** | View Channels, Send Messages and Create Posts, Embed Links, Add Reactions, Read Message History, Request to Speak |
+
+Use **Server Settings > Roles > [Role] > View Server as Role** to see what members with a certain role can see and access.
+
+---
+
+### Channel Management
+
+#### Organization
+
+- Use categories to group related channels
+- Suggested categories: Information, General, Voice Channels, Topic-Specific
+
+#### Per-Channel Settings
+
+(Right-click channel > Edit Channel > Permissions):
+
+- [ ] Set custom permissions for roles or members in specific channels
+
+#### Channel Settings > Overview
+
+- [ ] Slow Mode: Set appropriate cooldown (e.g., 5-30 seconds) for busy channels
+- [ ] Age-Restricted Channel: Enable for channels with mature content
+
+---
+
+### Member Screening Setup
+
+Beyond enabling in Safety Setup:
+
+- Implement a verification bot like Wick that does in-channel captcha for users to join the server
+- Require users to complete an in-channel captcha before accessing the server
+- Advance Settings: Have verification bot filter based on account age, PFP set, and timeout for incomplete captcha
+
+---
+
+### Invite Best Practices
+
+When creating invites:
+
+- Set "Expire After" (recommended: 24 hours)
+- Set "Max Number of Uses" (recommended: 50-100)
+
+---
+
+### Logging Setup
+
+- Ensure admin/mod roles have "View Audit Log" permission
+- Create a private logging channel visible only to admins/mods
+- Use a logging bot like Logger or Dyno to send detailed logs
+- Configure audit log output to a private channel for easier monitoring
+
+---
+
+### Security Bots
+
+Various third-party Discord bots offer valuable security and protection features, facilitating automated moderation
+for your server. In the sections below, we'll explore different categories of security bots and highlight popular
+options for each category.
+
+#### Anti-Impersonation Bots
+
+Set up custom rules to prevent other users from joining using the same username and PFP (profile picture) to
+impersonate you or other important members of the server. A popular bot in this category is
+[Hashbot](https://hashbot.com).
+
+#### Anti-Raid Bots
+
+To prevent spam bots from joining your server all at once, an attack known as raiding, you can also set up bots with
+particular rules. Beemo is a good example of a bot in this category.
+
+#### Anti-Nuke Bots
+
+This is a monitoring system to observe and note any changes (spontaneous or planned) that take place in your discord
+server. Some key observation markers are channel and role creation/deletions, banning or kicking members, and webhook
+creation/deletion.
+
+#### Moderation & Link Whitelisting Bots
+
+Only allows approved links to be used in the discord server. A popular bot in this category is Goodknight Bot.
+
+#### General Moderation Bots
+
+Consider bots like Dyno for advanced moderation and logging, or Carl-bot for reaction roles and custom commands. Set
+up security Bots as described above.
+
+_The bots above are not all-inclusive but rather a recommended list of bots to help protect your Discord server in
+these categories._
+
+---
+
+### Establish Clear Server Rules
+
+- Create a #rules channel
+- Use Discord's built-in rules screening feature
+- Include sections on: Behavior, Content, Moderation Actions, Appeals Process
+
+---
+
+### Regular Reviews
+
+| Frequency | Action |
+| --------- | ------ |
+| **Monthly** | Review all role permissions; use a spreadsheet to track changes and justifications |
+| **Quarterly** | Assess if server rules need updating; announce any changes in a dedicated announcements channel |
+| **Bi-annually** | Delete or archive inactive channels; remove roles that are no longer needed |
+
+Also regularly:
+
+- Ensure bots are from reputable sources and receive frequent updates
+- Review bot permissions after each significant update to avoid newly introduced vulnerabilities
+- Keep track of newly introduced features such as Threads, Scheduled Events, or Stage Channels and configure their
+  permissions carefully (e.g., who can start or join a Thread) to prevent abuse by spammers or scammers
+
+---
+
+### Cold Admin Accounts
+
+A Cold Admin account provides enhanced security because it serves exclusively as the server owner and is not used for
+everyday activities. If a regular admin account is compromised, attackers gain full access to the server or account,
+making it challenging to involve support and potentially requiring days or weeks to resolve the issue. Using a Cold
+Admin means creating a separate account dedicated solely to ownership functions, keeping it isolated from routine
+operations.
+
+#### What is a Cold Device?
+
+A Cold Device is a factory-reset device with no previous configuration. This should be a dedicated phone or laptop —
+you can use an old iPhone/Android, Windows device, or even a Chromebook to keep costs down. Everyone involved in
+setup and maintenance must ONLY access the Cold Admin account from a cold device.
+
+#### Cold Admin Setup
+
+##### Step 1: Create a dedicated email account
+
+Create a brand new Gmail account specifically for this Discord account. Do not use a VPN during this process, and
+it's best to use an incognito browser. After creating the Gmail account:
+
+- [ ] Set up 2FA immediately (authenticator app recommended, or Security Key for maximum security)
+- [ ] Ensure "Skip password when possible" is **off**
+- [ ] Do not add a phone number to the account
+- [ ] Note down the 10 backup codes **offline on paper** (DO NOT store online)
+- [ ] Write down the email, password, and backup codes on paper and store securely
+
+##### Step 2: Create the Discord account
+
+Head to [https://discord.com](https://discord.com) and create a new account using the Gmail account you just created.
+
+- [ ] Write down the email, username, password, and date of birth **offline**
+- [ ] Use a username that is not related to your project
+- [ ] Give the profile a profile picture in **My Account > Edit User Profile**
+- [ ] Go to **Content & Social** and disable DMs from server members and set spam filter to maximum
+- [ ] Set the account status to **Invisible** so no one can see if it's online (click profile in bottom left > change status)
+
+##### Step 3: Join the server and transfer ownership
+
+- [ ] Send the Cold Admin account a friend request from your personal Discord account
+- [ ] Have the Cold Admin join the Discord server and complete verification like a normal account
+- [ ] Assign the Cold Admin the highest admin role
+- [ ] Have the Cold Admin send a few messages in a private team chat
+- [ ] Wait approximately 24 hours, send a few more messages, then transfer ownership
+
+**To transfer ownership:** Go to **Server Settings > Members** > Search for the Cold Admin account > Click the three
+dots > Select **Transfer Ownership** > Input 2FA > Confirm
+
+> ⚠️ **CRITICAL:** Triple-check that you are transferring to the correct Cold Admin account. If you transfer to the
+> wrong account, recovery will be extremely difficult.
+
+#### Use of Cold Admin Account
+
+- **Do not** use the Cold Admin account for day-to-day operations
+- Log into both the Gmail and Discord account at least once a month (set a phone reminder)
+- Use only for: inviting/adding bots, making major changes only the server owner can perform
+- If an incident or compromise occurs, log into the Cold Admin to regain control — the server owner always maintains
+  full access rights
+
+---
+
+### Backup Systems
+
+- Use a bot like ServerBackup to regularly backup your server configuration
+- Store backups securely off-platform
+
+---
+
+### Additional Recommendations
+
+- Set up account leveling for new members for gradually enabling permissions
+- Regularly review server audit logs for admin and mod actions
+- Use anti-raid bots like Wick or Dyno and configure automatic lock-down settings for suspicious activity
+- Regularly review **Server Settings > Integrations** for newly added apps or link shorteners; disable suspicious
+  integrations or automate link scanning with a bot that checks URLs against known phishing databases
+
+> **Important:** Discord servers should not be used for any confidential communication (i.e., any admin discussions
+> beyond the scope of server moderation) — even restricted channels and DMs are not end-to-end encrypted.
+
+---
+
+### Stay Updated
+
+- Consult the official [Discord Moderator Academy](https://discord.com/moderation) for ongoing best practices and new features
+- Implement recommended strategies (e.g., improved spam filters, updated role recommendations)
+
+---
+
+## Additional Resources
+
+
+[... truncated ...]
+
+---
+
+### PAGE: /guides/account_management/github
+
+# GitHub Security
+
+
+
+
+## Summary
+
+> 🔑 **Key Takeaway for GitHub:** Secure your GitHub account with non-SMS two-factor authentication, enable push protection, and regularly review connected apps and sessions. For organizations, enforce signed commits, branch protection rules, and restrict member privileges to minimize supply chain attack risks.
+
+This checklist is adapted from [Auditware's W3OSC](https://github.com/W3OSC/web3-opsec-standard) standards.
+
+---
+
+## For Individuals
+
+These settings apply to your personal GitHub account. All team members and admins should configure these on their own accounts.
+
+### Individual Account Settings
+
+- Account Settings:
+    - [ ]  Public profile > Contributions & activity > Make profile private and hide activity > **On**
+    - [ ]  Password and authentication > Two-factor authentication > Enable and configure any method other than **SMS/Text message**
+    - [ ]  Sessions > Review and revoke any unrecognized or unnecessary
+    - [ ]  SSH and GPG keys > Review and remove any unnecessary
+    - [ ]  Organizations > Review and leave any unnecessary
+    - [ ]  Code security > User > Push protection for yourself > **Enabled**
+    - [ ]  Applications > Review and remove any unnecessary
+    - [ ]  Developer settings >
+        - [ ]  GitHub Apps > Review and remove any unnecessary
+        - [ ]  OAuth Apps > Review and remove any unnecessary
+        - [ ]  Personal access tokens > Review and remove any unnecessary
+
+---
+
+## For Team Members
+
+These guidelines apply to team members who contribute to repositories but don't have administrative access.
+
+Team members should:
+- Ensure their individual account settings are configured according to the checklist above
+- Enable GPG signing for commits to meet signed commit requirements
+- Be aware of branch protection rules that may require pull request approvals
+- Regularly review and rotate personal access tokens
+- Report any suspicious repository activity to organization admins
+
+---
+
+## For Admins
+
+These settings and practices apply to GitHub organization administrators with elevated privileges.
+
+### Repository Settings
+
+#### General Settings
+
+- [ ]  General > Danger Zone > Repository visibility > **Private**
+- [ ]  Collaborators and teams > Review access and remove any unnecessary
+    - [ ]  Ensure there are no more than 3 admins
+
+#### Branch Protection
+
+- [ ]  Branches > Branch protection rules > For each branch that triggers automated deployments, set the following protections:
+    - Protect matching branches > Require a pull request before merging
+        - Require approvals > **2+** recommended
+    - Rules applied to everyone including administrators > Allow force pushes > **Off**
+
+#### Repository Rules
+
+- Rules > Rulesets > New ruleset > New branch ruleset:
+    - [ ]  **Name**: EnforceSignedCommits
+        - **Targets**: All branches
+        - **Rules**:
+            - Require signed commits > **On**
+    - [ ]  **Name**: BlockForcePushes
+        - **Targets**: All branches
+        - **Rules**:
+            - Block force pushes > **On**
+
+#### Actions Security
+
+- Actions >
+    - [ ]  Actions permissions > Set minimum permissions needed
+        - **Disable actions** - if not needed
+        - **Allow organization actions and reusable workflows** - if only internal actions are used
+        - **Allow organization, and select non-organization, actions and reusable workflows** - if external actions are used
+    - [ ]  Fork pull request workflows > Run workflows from fork pull requests > **Off**
+    - [ ]  Workflow permissions > **Read repository contents and packages permissions**
+        - [ ]  Allow Github Actions to create and approve pull requests > **Off**
+    - [ ]  Access > **Not accessible**
+
+#### Security Features
+
+- [ ]  Webhooks > Review webhooks and delete any unnecessary or overly permissive
+- [ ]  Pages > Branch > **None** (to disable)
+- Code security >
+    - [ ]  Dependency graph > **Enabled**
+    - [ ]  Dependabot alerts > **Enabled**
+    - [ ]  Dependabot security updates > **Disabled**
+    - [ ]  Grouped security updates > **Disabled**
+    - [ ]  Dependabot version updates > **Disabled**
+    - [ ]  Access to alerts > No additional users (only admins)
+
+#### Access Control
+
+- [ ]  Deploy keys > Remove all [[1]](#1-deploy-keys-warning)
+- [ ]  Secrets and variables > Review secrets and variables and remove any unnecessary
+- [ ]  GitHub Apps > Installed GitHub Apps > Review configurations and uninstall any unnecessary
+    - [ ]  Review permissions are appropriate and that repository access is scoped only to relevant repositories
+
+### Organization Settings
+
+#### Member Privileges
+
+- Member privileges >
+    - [ ]  Base permissions > Any other than **Admin**
+    - [ ]  Repository creation > Public > **Off**
+    - [ ]  Repository forking > Allow forking of private repositories > **Off**
+    - [ ]  Projects base permissions > Any other than **Admin**
+    - [ ]  Integration access requests > Allow integration requests from outside collaborators > **Off**
+    - Admin repository permissions >
+        - [ ]  Allow members to change repository visibilities for this organization > **Off**
+        - [ ]  Allow members to delete or transfer repositories for this organization > **Off**
+        - [ ]  Allow repository administrators to delete issues for this organization > **Off**
+    - [ ]  Member team permissions > Allow members to create teams > **Off**
+
+#### Organization Rules
+
+- Repository > Rulesets > New ruleset > New branch ruleset: [[2]](#2-enterprise-features)
+    - [ ]  **Name**: EnforceSignedCommits
+        - **Targets > Target repositories**: All branches
+        - **Rules > Branch rules**:
+            - Require signed commits > **On**
+    - [ ]  **Name**: BlockForcePushes
+        - **Targets > Target repositories**: All branches
+        - **Rules > Branch rules**:
+            - Block force pushes > **On**
+
+#### Project and Actions Settings
+
+- [ ]  Planning > Projects > Allow members to change project visibilities for this organization > **Off**
+- Actions > General >
+    - Policies > **All repositories**
+        - [ ]  **Allow organization actions and reusable workflows** or **Allow organization, and select non-organization, actions and reusable workflows**
+    - [ ]  Approval for running fork pull request workflows from contributors > **Require approval for all external contributors**
+    - [ ]  Fork pull request workflows in private repositories > Run workflows from fork pull requests > **On**
+    - [ ]  Workflow permissions > **Read repository contents and packages permissions**
+        - [ ]  Allow GitHub Actions to create and approve pull requests > **Off**
+
+#### Security and Access
+
+- [ ]  Webhooks > Review and remove any unnecessary
+    - [ ]  For each webhook, ensure SSL verification is enabled
+- [ ]  Packages > Package creation > Public > **Disabled**
+- Authentication security >
+    - [ ]  Require two-factor authentication for everyone in the organization. > **On**
+        - [ ]  Only allow secure two-factor methods > **On**
+- [ ]  Deploy keys > **Disabled**
+
+#### Code Security Configuration
+
+- Code security > Configurations > New configuration:
+    - Dependency graph and Dependabot >
+        - [ ]  Dependency graph > **Enabled**
+        - [ ]  Dependabot alerts > **Enabled**
+    - [ ]  Code scanning > Default setup > **Enabled**
+    - [ ]  Secret scanning >
+        - [ ]  Alerts > **Enabled**
+        - [ ]  Validity checks > **Disabled**
+        - [ ]  Non-provider patterns > **Enabled**
+        - [ ]  Push protection > **Enabled**
+    - [ ]  Policy >
+        - [ ]  Use as default for newly created repositories > **All repositories**
+        - [ ]  Enforce configurations > **Enforce**
+    - [ ]  **Save configuration** and **Apply to > All repositories**
+
+#### Access Management
+
+- [ ]  Secrets and variables > Review secrets and variables and remove any unnecessary
+- [ ]  GitHub Apps > Installed GitHub Apps > Review configurations and uninstall any unnecessary
+    - [ ]  Review permissions are appropriate and that repository access is scoped only to relevant repositories
+- [ ]  OAuth app policy > Review policies and edit/deny any unnecessary
+- Personal access tokens >
+    - [ ]  **Restrict access via fine-grained personal access tokens**
+    - [ ]  **Require administrator approval**
+    - [ ]  **Restrict access via personal access tokens (classic)**
+    - [ ]  **Enroll** [[3]](#3-audit-logs)
+
+---
+
+## Notes
+
+### [1] Deploy Keys Warning
+
+Do not use deploy keys, they are possession-based access tokens that are a significant security risk. Use [GitHub Apps](https://docs.github.com/en/apps/overview) instead.
+
+### [2] Enterprise Features
+
+This is only available if you have a GitHub Enterprise plan. If you do not, you can set these same rules at the repo level instead.
+
+### [3] Audit Logs
+
+It is recommended to regularly review audit logs for your organization at Logs > Audit log.
+
+---
+
+**Related**: For repository hardening guidance, see [DevSecOps - Repository Hardening](/devsecops/repository-hardening).
+
+---
+
+---
+
+### PAGE: /guides/account_management/telegram
+
+# Telegram Security
+
+
+
+
+## Summary
+
+> 🔑 **Key Takeaway:** Stay vigilant with group chats on Telegram. Implement verification steps and secure communication
+> practices to protect against sophisticated interception attacks.
+
+While **Telegram** is widely used in the crypto community, it's crucial to understand its security limitations. Telegram
+**does not** offer end-to-end encryption (**E2EE**) by default, which means your messages could potentially be accessed
+by third parties. Additionally, Telegram's reliance on phone numbers for account creation can expose users to SIM
+swapping attacks, and its peer-to-peer call feature can reveal your IP address to other users. If **E2EE** is a
+priority, consider using [Signal](https://signal.org/).
+
+However, if you choose to use **Telegram**, the following best practices can help enhance your security.
+
+---
+
+## For Individuals
+
+These settings apply to your personal Telegram account. All team members and admins should configure these on their own accounts.
+
+### Account Security Checklist
+
+- Account Settings:
+    - Privacy & Security >
+        - Security >
+            - [ ]  Two-Step Verification > **On**
+                - Telegram does not require a login by default. However, you can set up a password that acts as a "second" 2FA method when logging in from a new device.
+                - Telegram sign-ups require a phone number, but you can also enable two-factor authentication via a password—your main protection if you're ever SIM-swapped. **Don't reuse this password anywhere else.**
+                - Do not set a password hint, do add a recovery email
+                - **SMS Codes:** Telegram sends a code via SMS, which is not secure.
+                - **Email Recovery:** Offers email recovery, which is more secure but lacks options for authenticator apps or hardware keys.
+                - **Backup Password:** If you lose this password, access to your account may be compromised. Write it down offline and ensure it is not lost.
+            - [ ]  Local passcode > **On** (recommended)
+                - This feature adds a passcode to access your Telegram app after a period of inactivity. The default setting is "away for 1 hour."
+                - **Store Passcode Securely:** Do not lose this passcode—store it offline if needed.
+                - **Unique Passcode:** Ensure it is different from your phone's unlock passcode.
+            - Active sessions >
+                - Telegram supports auto-terminating inactive sessions. You can also manually review and end any suspicious active sessions.
+                - [ ]  Review and delete all unused sessions
+                - [ ]  Terminate old sessions > **1 month**
+        - Privacy >
+            - Consider adjusting the following settings based on your country, usage, and purpose for using Telegram:
+            - [ ]  Phone Number > Who can see my phone number > **Nobody**
+                - Making your phone number visible can expose you to unwanted contact or social engineering attacks. Restricting visibility helps safeguard your personal info.
+            - [ ]  Phone Number > Who can find me by my number > **My Contacts**
+            - [ ]  Phone Number > Exceptions > Remove all
+            - [ ]  Last Seen & Online > Who can see my timestamp > **Nobody**/**My Contacts**
+            - [ ]  Last Seen & Online > Exceptions > Remove all
+            - [ ]  Profile Photo > Who can see my profile photo > **Everybody**
+                - Set to **Everybody** to stop scammers from impersonating your profile picture.
+            - [ ]  Bio > Who can see my bio > **Nobody** (depending on use of Telegram)
+            - [ ]  Date of Birth > Who can see my date of birth > **Nobody**
+            - [ ]  Date of Birth > Exceptions > Remove all
+            - [ ]  Forwarded Messages > Who can add a link to my account when forwarding my messages > **Nobody**
+            - [ ]  Calls > Who can call me > **Nobody**/**My Contacts**
+            - [ ]  Calls > Exceptions > Remove all
+            - [ ]  Calls > Peer-to-peer > Use peer-to-peer with > **Nobody**/**My Contacts**
+                
+                > **Note**: Peer-to-peer calls leak your IP address to callers. Set to **Nobody** to preserve anonymity
+                
+            - [ ]  Calls > Peer-to-peer > Exceptions > Always allow > Remove all
+            - [ ]  Groups & Channels > Who can add me to groups and channels > **Nobody**/**My contacts**
+                - This helps prevent being added to random groups that may impersonate legitimate groups and lead to scams.
+            - [ ]  Groups & Channels > Exceptions > Remove all
+            - [ ]  Voice Messages > Who can send me voice messages > **Nobody**/**My contacts**
+            - [ ]  Voice Messages > Exceptions > Remove all
+            - [ ]  Messages > Who can send me messages > **My Contacts and Premium Users** (or **Everybody**/**My Contacts** depending on use of Telegram)
+        - [ ]  New chats from unknown users > Archive and Mute > **Enabled**
+        - [ ]  Bots and website > **Clear Payment and Shipping Info**
+        - [ ]  Auto-Delete Messages > Set a time frame (e.g., 1 week) based on your risk tolerance
+            - Consider the photo you shared with a friend several months ago. While it might have slipped your mind, an attacker who gains access to your account could find such information quite valuable.
+    - Advanced >
+        - [ ]  Automatic media download > Disable all types in all cases
+            
+            > **Note**: Automatic media download leaves you exposed to advanced malware attacks
+            
+        - Version and updates >
+            - Ensure you are always using the latest version of Telegram to benefit from the newest security patches and features.
+            - [ ]  Check for Updates: Visit your device's app store regularly
+            - [ ]  Update automatically > **Enabled**
+            - [ ]  Install beta versions > **Disabled**
+
+> **Authentication Guidelines**: When establishing a secret chat, [compare the encryption keys](https://core.telegram.org/techfaq#q-how-are-secret-chats-authenticated) outside of telegram, in an established/authenticated channel, outside of telegram. When establishing a peer-to-peer (encrypted) call, [compare the emojis](https://core.telegram.org/techfaq#q-how-are-voice-and-video-calls-authenticated) in an established/authenticated channel, outside of telegram. These are your defenses against man-in-the-middle attacks. You **must** confirm these details if using Telegram for private communications. That said, it is suggested to use a secure platform like [Signal](https://signal.org/) for confidential communication.
+
+---
+
+### Device-Level Security
+
+Securing the device you use for Telegram is crucial for preventing unauthorized access to your account and messages.
+
+- [ ]  **Enable Full Device Encryption**:
+    - Ensure your device has full disk encryption enabled
+    - For iOS: This is enabled by default with a passcode
+    - For Android: Go to **Settings > Security > Encryption** and follow instructions
+
+- [ ]  **Set Strong Device Passcodes**:
+    - Use alphanumeric passwords rather than simple PINs
+    - Enable biometric authentication as a secondary measure
+
+- [ ]  **Keep Your Device Updated**:
+    - Install OS updates promptly to patch security vulnerabilities
+    - Update Telegram to the latest version regularly
+
+- [ ]  **Install Security Software**:
+    - Use reputable anti-malware software on your device
+    - Consider privacy-focused apps that detect network anomalies
+
+- [ ]  **Secure Your Backups**:
+    - Ensure any device backups containing Telegram data are encrypted
+    - Be cautious about cloud backups that might store Telegram messages
+
+---
+
+### Advanced Privacy Measures
+
+#### Consider Using a Different Phone Number
+
+Even if you implement all the recommended security measures, there are still valid reasons to use a separate phone
+number. For instance, it can help prevent your contacts from discovering your Telegram account or reduce the risk of
+accidental number exposure. This is particularly important because the **"Share My Phone Number"** option is enabled by
+default whenever you add a new contact.
+
+**Using a VoIP Number**
+
+Telegram restricts many VoIP providers, but services like [Google Voice](https://voice.google.com/) or
+[Burner](https://www.burnerapp.com/) might work. Purchase a burner number solely for Telegram if you prefer additional
+anonymity.
+
+**Using an Anonymous Number**
+
+In December 2022, Telegram introduced support for anonymous numbers purchased through its [TON](https://ton.org/)
+blockchain infrastructure. You can also check out [Fragment](https://fragment.com/) for such options.
+
+#### Use Secret Chats for Enhanced Privacy
+
+For conversations that require an extra layer of security, use Telegram's Secret Chats, which offer **end-to-end
+encryption**.
+
+1. **Start a Secret Chat**: Open the chat with the desired contact, tap on their name, and select **Start Secret Chat**
+2. **Benefits**:
+   - Messages are encrypted and can only be read by you and the recipient
+   - Offers self-destruct timers for messages
+   - Prevents forwarding of messages to other chats
+
+#### Data Settings
+
+**Go to:** Settings > Privacy and Security > Data Settings
+
+- [ ]  **Sync Contacts:** Disable (depending on use of Telegram) to prevent syncing your contacts.
+- [ ]  **Suggest Frequent Contacts:** Disable (depending on use of Telegram) to avoid unsolicited contact suggestions.
+
+---
+
+### Best Practices for Safe Use
+
+- [ ]  **Use Secret Chats:** When messaging someone, create a 'secret' chat to ensure encrypted 1:1 communication, providing end-to-end encryption for sensitive transactions.
+- [ ]  **Verify Group Invites and Authenticity:** Always triple-check group invitations and confirm the legitimacy of group chats through separate channels to avoid joining impostor groups that share malicious links.
+- [ ]  **Beware of Unsolicited DMs:** Never trust direct messages from anyone sending links or posing as "support," "exchanges," or "team" members.
+- [ ]  **Double-Check Payment Details:** Verify payment information through multiple methods before transferring funds to prevent fund redirection.
+- [ ]  **Block and Report Scammers:** Use the block function to prevent further contact, and report spammers/scammers instead of just deleting chats.
+- [ ]  **Be Cautious with Third-Party Bots and Integrations:**
+    - Third-party bots can enhance functionality but may also introduce vulnerabilities.
+    - Only add bots from reputable sources
+    - Limit the permissions you grant to bots
+    - Periodically review and remove unnecessary bots
+- [ ]  **Exercise Caution with Mini Apps:** Avoid logging in or providing information to mini apps that redirect outside of Telegram. Triple-check the username of the mini app to ensure its legitimacy, as Telegram lacks a bot verification system. Never download or run any commands from Telegram on your device.
+- [ ]  **Enhance Privacy with a VPN:** *Advanced tip:* Set up a proxy or VPN to hide your IP address while using the Telegram app.
+- [ ]  **Stay Vigilant Against Scam Ads:** Be aware that anyone can post ads in channels, with 99% being scam ads. Exercise caution when interacting with advertisements.
+
+---
+
+### Platform-Specific Risks: Man-in-the-Group Attack
+
+Attackers can exploit Telegram's group chat features to intercept and manipulate communications between two parties.
+Here's a concise example of how such an attack might occur:
+
+#### Scenario: Intercepting a Payment Deal
+
+**Step 1: Initial Communication**
+
+- **Alice** and **Bob** decide to finalize a cryptocurrency deal using a Telegram group chat named **"Crypto Deals"**.
+
+**Step 2: Attackers Create Cloned Groups**
+
+- **Attacker 1** creates **Group A** impersonating **Alice**.
+- **Attacker 2** creates **Group B** impersonating **Bob**.
+
+**Step 3: Replicating Conversations**
+
+- **In Group A (Impersonating Alice):**
+  - The attacker, posing as Alice, relays Alice's messages from Group B to maintain the conversation.
+
+- **In Group B (Impersonating Bob):**
+  - The attacker, posing as Bob, mirrors Bob's messages from Group A, acting as a middleman without altering the
+    content.
+
+**Step 4: Swapping Payment Details**
+
+- **In Group A:**
+  - Fake Alice and Bob agree to the terms of the deal.
+  - Bob shares his payment address.
+
+- **In Group B:**
+  - Fake Bob shares his swapped payment address.
+  - The conversation continues normally, with neither Alice nor Bob aware of the swap.
+
+**Step 5: Execution of the Scam**
+
+- **Alice** sends the payment to what she believes are Bob's details but are actually those of Fake Bob.
+- The attacker now controls both ends of the conversation, having successfully redirected the funds.
+
+---
+
+## For Team Members
+
+These guidelines apply to team members who help manage Telegram groups/channels but don't have full administrative access.
+
+Team members should:
+- Ensure their individual account settings are configured according to the checklist above
+- Each admin must follow the guidance for securing their individual accounts
+- Add a suffix to your username, for example: "MyName | will never DM you"
+- Understand how to verify the authenticity of admins and official messages
+- Be aware of the Man-in-the-Group Attack scenario described above
+
+---
+
+## For Admins
+
+These settings and practices apply to Telegram group/channel administrators with elevated privileges.
+
+### Channel & Group Settings Checklist
+
+#### Channel Settings
+
+- Open channel > click channel name > **Channel settings**
+    - [ ]  Sign messages > **Enable** (if non-repudiation is desired)
+    - [ ]  Administrators > Review the list and remove any unnecessary
+
+#### Group Settings
+
+- Open group > click group name > click three dots > **Manage group**
+    - [ ]  Channel type > **Private** (if public discoverability is not necessary)
+    - [ ]  Channel type > Content protection > **Enabled** (if confidentiality is needed)
+    - [ ]  Sign messages > **Enabled**
+    - [ ]  Chat history for new members > **Hidden**
+        - This is not available if Topics are enabled
+    - **Permissions:**
+        - [ ]  Send media > should be restricted appropriately
+            - At minimum, **Files** and **Embed links** should be disabled
+        - [ ]  Add members > **Disabled** (if not necessary) [[1]](#1-member-control)
+        - [ ]  Pin messages > **Disabled**
+        - [ ]  Change group info > **Disabled**
+        - [ ]  Slow mode > At least **10s**, if not obstructive
+        - [ ]  Exceptions should be restricted to valid use cases
+            - Team members should have exceptions granted to them for these rather than them being admins, when possible
+    - [ ]  **Invite links** > Review and remove unnecessary
+        - Links should be limited by time period or number of users, when not obstructive
+    - [ ]  **Administrators** > Review and remove unnecessary & review permissions of each admin
+        - Again, it is recommended to add exceptions for team members rather than add them as admins, when possible
+        - Remove unnecessary permissions, especially **Add new admins**
+        - **Aggressive Anti-Spam** > **Enabled**
+    - [ ]  **Members** > Review and remove unnecessary (If a confidential channel)
+
+---
+
+### Admin Permissions Management
+
+If you manage Telegram groups or channels, properly configuring admin permissions is crucial for maintaining security.
+
+- [ ]  **Limit Admin Privileges**:
+    - Go to your group/channel, tap the group name, select **Administrators**
+    - Only grant necessary permissions to each admin
+    - Avoid giving "Add Users" permission to untrusted admins
+
+- [ ]  **Implement Admin Verification**:
+    - Establish a verification process before promoting members to admin
+    - Use separate channels (like voice calls) to confirm admin identities
+    - Document when admin changes occur and why
+
+- [ ]  **Configure Group Settings**:
+    - Restrict member actions such as sending media or links
+    - Enable "Slow Mode" for large groups to prevent spam
+    - Use discussion groups for channels to control information flow
+
+- [ ]  **Audit Admin Activities**:
+    - Regularly review admin actions in the group
+    - Remove inactive or suspicious admins
+    - Consider using admin action logs if available
+
+- [ ]  **Handle Admin Transitions Securely**:
+    - Have protocols for transferring ownership if needed
+    - Revoke admin rights immediately when team members leave
+
+- [ ]  **Limit Group Permissions:** Restrict who can add members to groups to prevent unauthorized cloning and protect against raids.
+
+---
+
+### Additional Recommendations
+
+- [ ]  Add a disclaimer in the description and/or as a pinned message to your channel that states that you will not DM users, and that support will only be offered via the public channel and dedicated support channels [[2]](#2-security-disclaimers)
+- [ ]  Add a suffix to admin usernames, for example: "MyName | will never DM you"
+- [ ]  Each admin must follow the guidance for securing their individual accounts
+
+---
+
+### Educate Community Members on Security Practices
+
+If you're managing a community on Telegram, educating your members about security is vital for collective protection.
+
+- [ ]  **Regular Security Announcements**:
+    - Schedule periodic reminders about security best practices
+    - Pin important security announcements in your group/channel
+    - Create dedicated security FAQ channels or posts
+
+- [ ]  **Clear Verification Procedures**:
+    - Establish and communicate how official communications will occur
+    - Create verification steps for new members to follow
+    - Document how to verify the authenticity of admins and official messages
+
+- [ ]  **Threat Awareness Training**:
+    - Share examples of common scams targeting your community
+    - Post screenshots of phishing attempts (with sensitive info redacted)
+    - Explain the "Man-in-the-Group Attack" and how to avoid it
+
+- [ ]  **Incident Reporting Protocol**:
+    - Create clear guidelines for reporting suspicious activity
+    - Designate security-focused admins to handle reports
+    - Acknowledge reports publicly (without specifics) to encourage vigilance
+
+- [ ]  **Security Resources**:
+    - Develop simple, accessible security guides for members
+    - Share platform-specific security updates when Telegram releases them
+    - Create a security checklist for new community members
+
+---
+
+### Notes
+
+#### [1] Member Control
+
+Restricting the ability to add only to admins allows for revocability of invite links to stop raids or to freeze the channel if needed.
+
+#### [2] Security Disclaimers
+
+Telegram channels and groups should not be used for any confidential communication, as they are not end-to-end encrypted, except for 1:1 "secret chats" (which should not be commingled with unencrypted chats).
+
+Example disclaimer: "We will NEVER message you directly to offer support or assistance with our product. For support, please email us at support@\<company\>.com. DO NOT interact with anyone DMing and claiming to be a \<company\> member. Please report scams to reports@\<company\>.com"
+
+---
+
+---
+
+### PAGE: /opsec/appendices/case-studies
+
+# Case Studies & Exercises
+
+
+
+
+This section provides real-world case studies and tabletop exercises that organizations can use to learn from past
+incidents and test their security readiness. These examples illustrate common security challenges and effective response
+strategies.
+
+## Web3 Security Incidents
+
+### Case Study 1: Private Key Compromise
+
+#### Incident Overview
+
+A mid-sized DeFi protocol experienced a security breach when an attacker gained access to a private key used for
+deploying smart contracts. The attacker used the key to deploy a malicious contract update that drained approximately $3
+million from the protocol.
+
+#### Root Causes
+
+1. The private key was stored in a development environment with inadequate access controls
+2. The same key was used for both testing and production deployments
+3. There was no multi-signature requirement for contract deployments
+4. Monitoring systems failed to detect the unauthorized deployment
+
+#### Response Actions
+
+1. The team immediately alerted users via social media and official channels
+2. All remaining funds were moved to secure wallets
+3. A forensic investigation was initiated to determine the attack vector
+4. Law enforcement and blockchain analytics firms were engaged
+5. The team implemented a compensation plan for affected users
+
+#### Lessons Learned
+
+1. Implement multi-signature requirements for all critical operations
+2. Establish separate keys for different environments with appropriate controls
+3. Improve deployment security with additional verification steps
+4. Enhance monitoring to detect unauthorized deployments
+5. Develop and test incident response procedures specific to key compromise
+
+### Case Study 2: Social Engineering Attack
+
+#### Incident Overview
+
+A community manager for a popular NFT project had their Discord account compromised after clicking a link in a direct
+message that appeared to come from a team member. The attacker used the compromised account to post a fake minting link,
+ resulting in approximately 50 community members connecting their wallets and losing assets.
+
+#### Root Causes
+
+1. Lack of verification procedures for team communications
+2. Insufficient security awareness training for team members
+3. Absence of multi-factor authentication on critical accounts
+4. Inadequate controls for posting official announcements
+
+#### Response Actions
+
+1. The team removed the compromised account's permissions
+2. An official announcement was made warning about the scam
+3. The fake minting site was reported for takedown
+4. Affected community members were identified for potential compensation
+5. Communication procedures were revised to prevent similar incidents
+
+#### Lessons Learned
+
+1. Implement strong authentication for all team accounts
+2. Establish verification protocols for team communications
+3. Create a secure process for publishing official announcements
+4. Conduct regular security awareness training for team members
+5. Develop an incident response plan specific to community channel compromises
+
+## Tabletop Exercises
+
+### Exercise 1: Wallet Security Incident
+
+#### Scenario
+
+Your organization's multi-signature wallet has shown unusual transaction activity. A transaction that was not authorized
+by the team has been initiated, requiring one more signature to execute. The transaction would send a significant
+amount of funds to an unknown address.
+
+#### Exercise Questions
+
+1. What immediate actions would you take?
+2. How would you investigate the source of the unauthorized transaction?
+3. What stakeholders need to be notified, and what information would you provide?
+4. What steps would you take to secure your remaining assets?
+5. How would you communicate with your community or users?
+
+#### Key Discussion Points
+
+- Multi-signature wallet security procedures
+- Transaction verification processes
+- Incident response roles and responsibilities
+- Communication strategies during security incidents
+- Forensic investigation approaches
+
+### Exercise 2: Smart Contract Vulnerability
+
+#### Scenario
+
+A security researcher has privately disclosed a critical vulnerability in one of your deployed smart contracts. The
+vulnerability could potentially allow an attacker to drain funds, but it requires specific conditions that have not yet
+occurred. You have approximately 48 hours before these conditions align.
+
+#### Exercise Questions
+
+1. How would you validate the reported vulnerability?
+2. What immediate mitigation steps could you take?
+3. How would you prioritize and approach developing a fix?
+4. What stakeholders need to be involved in the decision-making process?
+5. How and when would you communicate with users and the broader community?
+
+#### Key Discussion Points
+
+- Vulnerability verification processes
+- Short-term mitigation strategies
+- Smart contract upgrade procedures
+- Decision-making during time-sensitive incidents
+- Responsible disclosure and communication
+
+### Exercise 3: Team Member Device Compromise
+
+#### Scenario
+
+A developer on your team reports that their laptop has been stolen while traveling. The laptop was used for development
+work and had access to various internal systems. The developer had logged into several services recently and is unsure
+if all sessions were properly closed.
+
+#### Exercise Questions
+
+1. What immediate actions would you take to contain potential damage?
+2. What systems and access credentials might be at risk?
+3. How would you determine if any unauthorized access has occurred?
+4. What steps would you take to restore secure operations?
+5. How would you improve security to prevent similar incidents?
+
+#### Key Discussion Points
+
+- Device security policies and procedures
+- Access revocation processes
+- Security monitoring and detection capabilities
+- Recovery procedures for compromised credentials
+- Travel security policies
+
+## Security Exercises for Teams
+
+### Red Team Exercise: Phishing Simulation
+
+#### Exercise Overview
+
+This exercise simulates a phishing attack targeting team members to test awareness and response.
+
+#### Setup Requirements
+
+1. Prepare simulated phishing emails targeting different team roles
+2. Create a safe landing page that records interactions
+3. Establish monitoring to track responses
+4. Prepare educational materials for post-exercise discussion
+
+#### Exercise Process
+
+1. Send simulated phishing emails to selected team members
+2. Monitor interactions with the phishing content
+3. Document actions taken by recipients
+4. Track if and how the incident is reported
+5. Conduct a debrief session to discuss results
+
+#### Evaluation Criteria
+
+- Percentage of team members who detected the phishing attempt
+- Time taken to report suspicious emails
+- Effectiveness of reporting procedures
+- Quality of response from security team
+- Lessons learned and areas for improvement
+
+### Security Control Assessment: Key Management
+
+#### Exercise Overview
+
+This exercise evaluates the effectiveness of cryptocurrency key management procedures.
+
+#### Setup Requirements
+
+1. Create a test environment with non-production keys
+2. Prepare scenarios that test different aspects of key management
+3. Establish evaluation criteria for each scenario
+4. Ensure safety measures to prevent actual asset risk
+
+#### Exercise Process
+
+1. Simulate routine key management operations
+2. Introduce scenarios requiring emergency access to keys
+3. Test key recovery procedures
+4. Evaluate separation of duties enforcement
+5. Assess documentation and procedure clarity
+
+#### Evaluation Criteria
+
+- Adherence to established key management procedures
+- Effectiveness of security controls
+- Time required to safely complete key operations
+- Quality of documentation and procedures
+- Identification of gaps and improvement opportunities
+
+These case studies and exercises provide practical examples and scenarios that organizations can use to learn from past
+incidents and test their security readiness. By regularly conducting such exercises, teams can identify weaknesses in
+their security posture and improve their ability to respond effectively to incidents.
+
+---
+
+---
+
+### PAGE: /opsec/control-domains/people
+
+# People & Personnel Controls
+
+
+
+
+People are both the greatest asset and potentially the greatest vulnerability in any security program. This section
+outlines controls to mitigate human-related security risks while fostering a security-aware culture.
+
+## Social-Engineering Defense
+
+Protecting against attacks that manipulate people to divulge confidential information or perform actions that compromise
+security.
+
+### Key Components
+
+1. **Awareness Training**: Educating team members about social engineering tactics
+2. **Attack Simulation**: Conducting controlled social engineering exercises
+3. **Verification Procedures**: Establishing processes to verify requestor identity
+4. **Reporting Mechanisms**: Creating clear channels for reporting suspicious activities
+5. **Response Protocols**: Developing procedures for handling potential social engineering incidents
+
+### Implementation Steps
+
+1. Develop targeted training on common social engineering tactics
+2. Implement regular phishing simulations and other controlled tests
+3. Establish protocols for verifying requests for sensitive information or actions
+4. Create and communicate clear procedures for reporting suspicious activities
+5. Regularly update training and awareness materials based on current threats
+
+### Web3-Specific Considerations
+
+1. **Community Channels**: Address social engineering in Discord, Telegram, and other platforms
+2. **Crypto-Specific Scams**: Educate about common scams like fake airdrops and giveaways
+3. **Impersonation**: Train team members to verify identity through secure channels
+4. **Public Information**: Consider the risks of publicly available information about team members
+5. **Multiple Communication Channels**: Establish out-of-band verification for critical actions
+
+## Insider-Threat Mitigation
+
+Addressing risks posed by team members who may intentionally or unintentionally compromise security.
+
+### Key Components
+
+1. **Access Controls**: Implementing least privilege and separation of duties
+2. **Monitoring**: Establishing appropriate monitoring of user activities
+3. **Onboarding/Offboarding**: Securing processes for adding and removing team members
+4. **Behavior Analytics**: Identifying unusual activities that may indicate threats
+5. **Response Procedures**: Developing protocols for addressing potential insider threats
+
+### Implementation Steps
+
+1. Implement robust access controls based on the principle of least privilege
+2. Establish monitoring for critical systems and sensitive data access
+3. Develop and enforce secure onboarding and offboarding procedures
+4. Create guidelines for identifying and reporting concerning behaviors
+5. Establish response procedures that balance security with privacy and legal considerations
+
+### Web3-Specific Considerations
+
+1. **Key Management**: Implement controls for those with access to private keys
+2. **Multi-Signature Requirements**: Use multi-signature arrangements for critical operations
+3. **Distributed Teams**: Address insider threat risks in remote and distributed teams
+4. **Pseudonymous Contributors**: Develop trust models for pseudonymous team members
+5. **Financial Incentives**: Consider unique incentives related to cryptocurrency holdings
+
+## Security Training & Culture
+
+Building a culture where security is valued and integrated into daily operations.
+
+### Key Components
+
+1. **Security Awareness Program**: Comprehensive training on security principles
+2. **Role-Based Training**: Specialized training based on job responsibilities
+3. **Security Champions**: Designated representatives who promote security within teams
+4. **Continuous Learning**: Ongoing education about emerging threats
+5. **Positive Reinforcement**: Recognizing and rewarding security-conscious behavior
+
+### Implementation Steps
+
+1. Develop a comprehensive security awareness program
+2. Implement role-specific security training for different functions
+3. Establish a security champions program to promote security within teams
+4. Create a continuous learning program with regular updates on new threats
+5. Develop recognition programs for security-conscious behaviors and reporting
+6. Integrate security into performance evaluations and team objectives
+
+### Web3-Specific Considerations
+
+1. **Crypto-Specific Training**: Educate on unique aspects of blockchain security
+2. **Open-Source Mindset**: Balance security with transparency in an open-source culture
+3. **Decentralized Teams**: Deliver effective training across distributed organizations
+4. **Rapidly Evolving Threats**: Keep training current with fast-changing Web3 threats
+5. **Community Education**: Extend security awareness to community members and users
+
+## Personnel Security Measures
+
+Ensuring appropriate security controls throughout the employment lifecycle.
+
+### Key Components
+
+1. **Pre-Employment Screening**: Appropriate background checks and verification
+2. **Security Agreements**: Confidentiality and acceptable use policies
+3. **Clear Expectations**: Defined security responsibilities for all roles
+4. **Performance Management**: Integration of security into performance evaluation
+5. **Termination Procedures**: Secure processes for departing team members
+
+### Implementation Steps
+
+1. Implement appropriate pre-employment screening procedures
+2. Develop and require security agreements for all team members
+3. Clearly document security responsibilities in job descriptions
+4. Include security considerations in performance evaluations
+5. Establish and enforce secure termination procedures
+
+### Web3-Specific Considerations
+
+1. **Pseudonymous Contributors**: Develop alternative verification approaches
+2. **Global Teams**: Navigate screening challenges across different jurisdictions
+3. **Community Contributors**: Address security for non-employee contributors
+4. **DAO Participants**: Establish security expectations in decentralized organizations
+5. **Key Recovery**: Implement procedures for key recovery when team members depart
+
+Effective people and personnel controls recognize that security is fundamentally a human issue. By addressing social
+engineering, insider threats, and security awareness, organizations can transform their people from potential
+vulnerabilities into a critical line of defense.
+
+---
+
+---
+
+### PAGE: /opsec/control-domains/physical-environmental
+
+# Physical & Environmental Controls
+
+
+
+
+Physical security is a crucial component of operational security that is often overlooked in digital-focused
+organizations. This section covers controls to protect physical assets, secure workspaces, and address travel security
+concerns.
+
+## Secure Workspace & Travel Security
+
+Implementing controls to secure physical work environments and protect team members while traveling.
+
+### Secure Workspace Components
+
+1. **Physical Access Controls**: Restricting access to facilities and sensitive areas
+2. **Visitor Management**: Procedures for handling visitors and contractors
+3. **Clean Desk Policy**: Guidelines for securing sensitive information when not in use
+4. **Environmental Monitoring**: Detection of environmental threats (fire, water, etc.)
+5. **Equipment Security**: Physical protection of hardware and devices
+
+### Implementation Steps for Workspace Security
+
+1. Implement appropriate physical access controls based on sensitivity
+2. Establish visitor management procedures and logging
+3. Develop and enforce clean desk and clear screen policies
+4. Implement environmental monitoring and response procedures
+5. Secure hardware with appropriate physical controls (locks, alarms, etc.)
+
+### Travel Security Components
+
+1. **Pre-Travel Assessment**: Evaluating security risks at destinations
+2. **Secure Travel Practices**: Guidelines for secure behavior while traveling
+3. **Device Security**: Protecting devices and data during travel
+4. **Emergency Response**: Procedures for handling security incidents while traveling
+5. **Post-Travel Measures**: Actions to take after returning from high-risk locations
+
+### Implementation Steps for Travel Security
+
+1. Develop pre-travel risk assessment procedures
+2. Create travel security guidelines for different risk levels
+3. Implement technical controls for devices used during travel
+4. Establish emergency response procedures for travelers
+5. Develop and enforce post-travel security measures where appropriate
+
+### Web3-Specific Considerations
+
+1. **Remote-First Organizations**: Addressing physical security in distributed teams
+2. **Hardware Wallets**: Securing cryptocurrency hardware devices
+3. **Conference Security**: Protecting team members at industry events
+4. **Pseudonymous Team Members**: Balancing privacy with physical security needs
+5. **Doxing Risks**: Protecting team members from having personal information exposed
+
+## Tamper-Evidence & "Evil-Maid" Attacks
+
+Protecting against physical tampering with devices and equipment, especially when left unattended.
+
+### Key Components
+
+1. **Tamper-Evident Measures**: Physical indicators of device tampering
+2. **Device Integrity Verification**: Methods to verify device has not been compromised
+3. **Secure Storage**: Protected storage for sensitive devices when not in use
+4. **Device Handling Procedures**: Guidelines for maintaining device chain of custody
+5. **Response Procedures**: Actions to take when tampering is suspected
+
+### Implementation Steps
+
+1. Implement tamper-evident measures for sensitive devices (seals, markers, etc.)
+2. Establish procedures for verifying device integrity after periods of absence
+3. Provide secure storage options for devices when not in use
+4. Develop clear device handling procedures
+5. Create response plans for suspected tampering incidents
+6. Train team members on tamper detection and response
+
+### Web3-Specific Considerations
+
+1. **Hardware Wallet Security**: Protecting cryptocurrency hardware devices
+2. **Cold Storage**: Physical security for offline key storage
+3. **Seed Phrase Protection**: Secure storage of recovery phrases
+4. **Air-Gapped Systems**: Maintaining security of isolated systems
+5. **Physical Backup Security**: Protecting backup storage media
+
+## Physical Security of Critical Assets
+
+Protecting the physical security of servers, network equipment, and other critical infrastructure.
+
+### Key Components
+
+1. **Asset Inventory**: Cataloging and tracking physical assets
+2. **Secure Facilities**: Protected locations for critical infrastructure
+3. **Environmental Controls**: Protection against environmental threats
+4. **Maintenance Procedures**: Secure processes for equipment maintenance
+5. **Disposal Procedures**: Secure disposal of equipment and media
+
+### Implementation Steps
+
+1. Maintain a comprehensive inventory of physical assets
+2. Implement appropriate physical security controls for facilities
+3. Deploy environmental monitoring and protection systems
+4. Establish secure maintenance procedures
+5. Develop and enforce secure disposal procedures for equipment and media
+
+### Web3-Specific Considerations
+
+1. **Node Security**: Physical protection of blockchain nodes
+2. **Validator Security**: Enhanced protection for validator infrastructure
+3. **Redundancy Planning**: Physical distribution of backup systems
+4. **Hardware Security Modules**: Physical protection of HSMs
+5. **Key Ceremony Security**: Physical controls for key generation events
+
+Effective physical and environmental security controls address risks that are often overlooked in digital-focused
+organizations. By implementing appropriate physical protections, organizations can prevent attacks that bypass technical
+controls through physical access or tampering.
+
+---
+
+---
+
+### PAGE: /opsec/control-domains/technical
+
+# Technical & Digital Controls
+
+
+
+
+Technical controls form the backbone of operational security, protecting systems, networks, and data from digital
+threats. This section outlines key technical controls that should be implemented as part of a comprehensive security
+program.
+
+## Device Hardening
+
+Securing devices by minimizing attack surfaces and implementing defensive configurations.
+
+### Key Components
+
+1. **Secure Configuration Baselines**: Standardized secure configurations for different device types
+2. **Endpoint Protection**: Anti-malware, application control, and other protective tools
+3. **OS Hardening**: Removing unnecessary services and securing operating systems
+4. **Patch Management**: Keeping systems updated with security patches
+5. **Local Firewall**: Controlling network connections at the device level
+
+### Implementation Steps
+
+1. Develop secure configuration baselines for each device type
+2. Implement endpoint protection solutions on all devices
+3. Remove or disable unnecessary services, applications, and features
+4. Establish an effective patch management process
+5. Configure local firewalls with appropriate rules
+6. Regularly scan for compliance with security baselines
+
+### Web3-Specific Considerations
+
+1. **Development Environments**: Securing environments used for smart contract development
+2. **Cold Storage Systems**: Hardening systems used for cryptocurrency key management
+3. **Transaction Signing Devices**: Enhanced security for devices used to sign transactions
+4. **Node Operation**: Specialized hardening for blockchain node infrastructure
+5. **Testing Environments**: Securing environments used for contract testing and simulation
+
+## Network & Communication Security
+
+Protecting data in transit and securing network infrastructure against attacks.
+
+### Key Components
+
+1. **Network Segmentation**: Dividing networks into security zones
+2. **Encrypted Communications**: Protecting data transmitted over networks
+3. **Secure Remote Access**: VPN and other secure access solutions
+4. **Network Monitoring**: Detecting suspicious network activity
+5. **Perimeter Security**: Firewalls, intrusion prevention, and other boundary protections
+
+### Implementation Steps
+
+1. Implement network segmentation based on security requirements
+2. Deploy encryption for all sensitive communications
+3. Establish secure remote access solutions with strong authentication
+4. Implement network monitoring and traffic analysis
+5. Deploy and properly configure perimeter security controls
+6. Regularly test network security through vulnerability assessments and penetration testing
+
+### Web3-Specific Considerations
+
+1. **Node Communication**: Securing blockchain node communications
+2. **API Security**: Protecting interfaces to blockchain services
+3. **RPC Endpoint Protection**: Securing remote procedure call endpoints
+4. **P2P Network Security**: Addressing risks in peer-to-peer networks
+5. **MEV Protection**: Mitigating risks related to maximal extractable value
+
+## Encrypted Storage & Backups
+
+Protecting data at rest through encryption and secure backup strategies.
+
+### Key Components
+
+1. **Full-Disk Encryption**: Encrypting entire storage devices
+2. **File-Level Encryption**: Protecting individual sensitive files
+3. **Key Management**: Securely managing encryption keys
+4. **Secure Backups**: Protecting backup data through encryption and access controls
+5. **Recovery Testing**: Verifying the ability to restore from backups
+
+### Implementation Steps
+
+1. Implement full-disk encryption on all devices storing sensitive data
+2. Deploy file-level encryption for particularly sensitive information
+3. Establish secure key management processes with appropriate access controls
+4. Implement encrypted and access-controlled backup solutions
+5. Regularly test backup recovery processes
+6. Store backup media securely with appropriate physical protections
+
+### Web3-Specific Considerations
+
+1. **Seed Phrase Backups**: Secure storage of wallet recovery information
+2. **Multi-Location Backups**: Distributing backup data to prevent single points of failure
+3. **Cold Storage Backups**: Offline backup strategies for critical keys
+4. **Smart Contract Backups**: Preserving contract source code and deployment parameters
+5. **Social Recovery Options**: Implementing secure social recovery systems for critical keys
+
+## Two-Factor & Hardware Authentication
+
+Strengthening authentication through multiple factors and hardware-based solutions.
+
+### Key Components
+
+1. **Multi-Factor Authentication**: Requiring multiple verification methods
+2. **Hardware Security Keys**: Physical devices for authentication
+3. **Biometric Authentication**: Using biological characteristics for verification
+4. **Time-Based One-Time Passwords**: Temporary codes for authentication
+5. **Single Sign-On Integration**: Centralizing and securing authentication
+
+### Implementation Steps
+
+1. Implement multi-factor authentication for all access to sensitive systems
+2. Deploy hardware security keys for high-value accounts and systems
+3. Establish backup authentication methods and recovery processes
+4. Integrate MFA with single sign-on solutions where appropriate
+5. Train users on proper use of authentication tools
+6. Regularly audit authentication configurations and access
+
+### Web3-Specific Considerations
+
+1. **Hardware Wallets**: Using dedicated devices for cryptocurrency transactions
+2. **Multi-Signature Setups**: Requiring multiple approvals for critical transactions
+3. **Air-Gapped Signing**: Using offline devices for transaction signing
+4. **Social Recovery**: Implementing secure key recovery through trusted contacts
+5. **DApp Authentication**: Securing connections to decentralized applications
+
+## Cryptocurrency-Specific Controls
+
+Technical controls specifically designed to address the unique security challenges of cryptocurrency operations.
+
+### Key Components
+
+1. **Wallet Security**: Technical measures to secure cryptocurrency wallets
+2. **Transaction Verification**: Processes to verify transaction details before signing
+3. **Key Management**: Secure generation, storage, and use of cryptographic keys
+4. **Blockchain Monitoring**: Tracking on-chain activity for anomalies
+5. **Smart Contract Security**: Technical controls for secure contract interaction
+
+### Implementation Steps
+
+1. Implement appropriate wallet solutions based on security requirements
+2. Establish transaction verification procedures with multiple checks
+3. Deploy secure key management practices and technologies
+4. Implement monitoring for blockchain transactions and activities
+5. Develop secure processes for smart contract interaction
+6. Regularly review and update cryptocurrency security controls
+
+### Web3-Specific Best Practices
+
+1. **Cold Storage**: Using offline systems for storing significant assets
+2. **Multi-Signature Wallets**: Requiring multiple approvals for transactions
+3. **Transaction Simulation**: Testing transactions before execution
+4. **Gas Limit Setting**: Controlling transaction costs and preventing attacks
+5. **Contract Interaction Verification**: Verifying contract behavior before approval
+
+Effective technical and digital controls provide a strong foundation for operational security. By implementing
+comprehensive device, network, data, and authentication protections, organizations can significantly reduce their attack
+surface and better protect their digital assets.
+
+---
+
+---
+
+### PAGE: /opsec/core-concepts/implementation-process
+
+# Operational Implementation Process
+
+
+
+
+> 🔑 **Key Takeaway**: Operational security is implemented through a practical five-phase process: critical asset
+> identification, practical threat analysis, actionable vulnerability assessment, contextual risk evaluation, and
+> targeted control deployment.
+
+## Relationship to Security Fundamentals
+
+This document outlines a practical implementation process for operational security that organizations can follow in
+sequence. This process complements the [Security Fundamentals](/opsec/core-concepts/security-fundamentals) document,
+which defines the guiding principles:
+
+- This process provides a **sequential workflow** for security teams to follow
+- The fundamentals establish **enduring principles** that shape security architecture
+
+While this process offers a concrete methodology for implementation, the fundamentals establish the ongoing security
+approaches that must be maintained throughout your systems. Both elements must work together: the fundamentals guide
+your overall approach, while this process provides the tactical roadmap.
+
+For organizations just beginning their security journey, start here with these concrete implementation steps.
+
+## 1. Critical Asset Identification
+
+Map and document the assets that would cause significant harm to your organization if compromised.
+
+> **🔗 Related Framework:** This phase integrates with [Asset Inventory](/infrastructure/asset-inventory) practices and
+> drives [Data Protection](/opsec/old/data-protection/overview) strategies.
+
+### Implementation Actions
+
+1. Conduct asset discovery across your environment using both automated tools and manual inventorying
+   - Digital assets: Use network scanning, CMDB tools, and cloud resource inventories
+   - Physical assets: Document hardware, systems and access points
+2. Apply a practical classification system with clear, actionable categories
+   - High-value assets: Direct financial impact if compromised (e.g., private keys, treasury wallets)
+   - Operational assets: Required for continued business operations
+   - Sensitive data: Includes Customer information, intellectual property, strategic plans
+3. Map information flows to understand how data moves between systems
+4. Assign specific owners responsible for each asset category
+5. Establish a sustainable review cadence based on your environment
+   - High-volatility environments: Monthly reviews
+   - Stable environments: Quarterly reviews
+   - Document trigger events that require immediate reassessment (e.g., acquisitions, new product, etc.)
+
+## 2. Practical Threat Analysis
+
+Identify specific, relevant threat actors and their tactics based on your organization's profile.
+
+> **🔗 Related Framework:** For hands-on approaches, see
+> [Understanding Threat Vectors](/awareness/understanding-threat-vectors) and [Threat Modeling](/threat-modeling/overview)
+> frameworks.
+
+### Implementation Actions
+
+1. Create a focused threat profile based on:
+   - Your industry's recent attack history (consult threat intelligence reports)
+   - Your organization's specific attack surface
+   - The value of your assets to different adversaries
+2. Document concrete adversary personas with specific capabilities:
+   - External attackers: Targeted vs. opportunistic
+   - Insider risks: Privileged users, contractors, disgruntled employees
+   - Supply chain actors: Vendors with access to your systems
+3. Map threat actors to their likely tactics using MITRE ATT&CK or similar frameworks
+4. Establish threat intelligence feeds relevant to your environment
+5. Create a lightweight process for updating threat models when new intelligence emerges
+
+## 3. Actionable Vulnerability Assessment
+
+Systematically identify and validate weaknesses in your environment through practical testing.
+
+> **🔗 Related Framework:** This aligns with the [Security Testing](/security-testing/overview) framework and includes
+> practices like [Static Application Security Testing](/security-testing/overview) and [Dynamic Application Security Testing](/security-testing/overview).
+
+### Implementation Actions
+
+1. Implement a layered vulnerability discovery program:
+   - Automated scanning: Deploy tools appropriate for your environment (infrastructure, applications, cloud)
+   - Manual testing: Conduct regular penetration tests focusing on critical systems
+   - Red team exercises: Simulate real-world attacks against your defenses
+2. Examine security processes for operational gaps:
+   - Incident response procedures: Test through tabletop exercises
+   - Access management: Audit privilege escalation paths
+   - Change management: Review for security bypass opportunities
+3. Evaluate security awareness through:
+   - Targeted phishing simulations
+   - Knowledge assessments
+   - Procedural compliance checks
+4. Document findings in a centralized vulnerability management system with clear ownership
+5. Implement a consistent vulnerability scoring system to enable prioritization
+
+## 4. Contextual Risk Evaluation
+
+Analyze identified risks in the context of your business to drive informed decision-making.
+
+> **🔗 Related Framework:** For practical approaches, see [Governance](/governance/overview) and
+> [Risk Management](/governance/risk-management) frameworks.
+
+### Implementation Actions
+
+1. Establish a practical risk calculation methodology that considers:
+   - Business impact (financial, operational, reputational)
+   - Exploitation likelihood based on real-world attack patterns
+   - Existing control effectiveness
+2. Create a prioritized risk register with clear owners and timelines
+3. Define risk acceptance criteria based on your organization's risk tolerance
+4. Develop risk narratives that translate technical findings into business impacts
+5. Implement a streamlined risk review process that:
+   - Enables timely decisions
+   - Involves appropriate stakeholders
+   - Documents rationale for future reference
+   - Triggers reassessment when conditions change
+
+## 5. Targeted Control Deployment
+
+Implement security controls that address prioritized risks while minimizing operational friction.
+
+> **🔗 Related Framework:** Implementation integrates with [Security Automation](/security-automation/overview) and
+> control frameworks like [Infrastructure](/infrastructure/overview) and
+> [Identity and Access Management](/iam/overview).
+
+### Implementation Actions
+
+1. Design a defense-in-depth strategy with layered controls:
+   - Preventive: Stop attacks before they succeed
+   - Detective: Identify attacks in progress
+   - Responsive: Limit damage from successful attacks
+   - Recovery: Restore normal operations
+2. Select controls using a balanced approach:
+   - Technical feasibility in your environment
+   - Implementation and maintenance costs
+   - Potential operational impact
+   - Coverage of multiple risks where possible
+3. Implement controls using a phased approach:
+   - Quick wins: Deploy high-impact, low-effort controls first
+   - Foundational controls: Build core security capabilities
+   - Advanced measures: Address sophisticated threats
+4. Validate control effectiveness through:
+   - Technical testing
+   - Process verification
+   - Metrics collection
+5. Document clear procedures for:
+   - Control operation
+   - Maintenance requirements
+   - Monitoring and alerting
+   - Incident response when controls fail
+
+---
+
+---
+
+### PAGE: /opsec/core-concepts/security-fundamentals
+
+# Security Fundamentals
+
+
+
+
+> 🔑 **Key Takeaway**: Effective security operations are built on five practical fundamentals: layered protective
+> measures, minimized access scopes, controlled information flows, system isolation, and continuous visibility — working
+> together to secure critical assets in dynamic environments.
+
+## Relationship to Implementation Process
+
+This document outlines the foundational security approaches that should be embedded throughout your organization's
+operations. They complement the practical
+[Operational Implementation Process](/opsec/core-concepts/implementation-process),
+which defines specific action steps:
+
+- These fundamentals establish **enduring approaches** that shape your security architecture
+- The implementation process provides a **sequential workflow** for security teams to follow
+
+While these fundamentals provide the security principles that should be consistently applied across your environment,
+the implementation process offers a structured methodology for putting security into practice. Both elements must work
+in concert - these fundamentals guide your overall approach, while the implementation process provides the tactical
+roadmap.
+
+For organizations just beginning their security journey, start with the
+[Operational Implementation Process](/opsec/core-concepts/implementation-process) for concrete steps.
+
+The ultimate goal is to prevent unauthorized access to systems and information that could cause operational, financial,
+or reputational harm if compromised.
+
+> **Practical Example: Web3 Organization**
+>
+> Consider a Web3 project managing a DeFi protocol with a treasury of $10M in assets. Practical security fundamentals in
+> action include:
+>
+> - **Layered protection**: Hardware security modules for key storage, multi-signature requirements (3-of-5) for
+> transactions, automated monitoring for unusual patterns, and regular third-party security audits
+> - **Minimal access scopes**: Deployment keys accessible only to specific DevOps team members, with different
+> permission levels strictly enforced between development, staging, and production environments
+> - **Information flow control**: Private keys for multi-signature wallets distributed among trusted team members based
+> on role, with sensitive incident response procedures restricted to the security team
+> - **System isolation**: Clear separation between development environments and production systems, with treasury
+> management isolated from day-to-day operations
+> - **Continuous visibility**: Real-time monitoring systems tracking transaction patterns, weekly security reviews, and
+> quarterly penetration tests with findings addressed in prioritized sprints
+
+## 1. Layered Protection
+
+Implement multiple overlapping security controls so that if one mechanism fails, others will continue to protect your
+assets.
+
+> **🔗 Related Framework:** This approach is reinforced in frameworks like [Infrastructure](/infrastructure/overview)
+> with [Zero-Trust Principles](/infrastructure/zero-trust-principles) and
+> [Network Security](/infrastructure/network-security).
+
+### Practical Application
+
+1. Implement multiple defensive mechanisms that protect against the same risks using different methods
+   - Example: Protect admin interfaces using network ACLs, MFA, time-limited access windows, and anomaly detection
+2. Deploy protection at each layer of your technology stack
+   - Network layer: Firewalls, network segmentation, DDoS protection
+   - Host layer: Endpoint protection, host-based IDS, secure configuration
+   - Application layer: Input validation, output encoding, API security
+   - Data layer: Encryption, access controls, data loss prevention
+3. Identify and eliminate single points of failure in your security architecture
+   - Map defense coverage to ensure overlapping protections
+   - Document security dependencies and create contingency plans
+4. Test defensive layers regularly through realistic scenarios
+   - Conduct tabletop exercises focused on specific defensive failures
+   - Use red team exercises to validate defense-in-depth effectiveness
+5. Maintain a continuous improvement cycle for each defensive layer
+   - Review and update security controls after incidents or near-misses
+   - Track industry developments to identify emerging defensive tactics
+
+## 2. Minimal Access Scopes
+
+Grant users, systems, and processes only the specific permissions they need to perform their required functions and
+nothing more.
+
+> **🔗 Related Framework:** For detailed implementation, see [Identity and Access Management](/iam/overview) and
+> [Role-Based Access Control](/iam/role-based-access-control).
+
+### Practical Application
+
+1. Implement a structured permission model that starts with zero access
+   - Default deny: Require explicit permission grants for all access
+   - Document justification for each permission granted
+   - Create standardized role templates for common job functions
+2. Establish automated processes for access lifecycle management
+   - Onboarding: Provision minimal initial access based on role
+   - Role changes: Adjust permissions when responsibilities change
+   - Offboarding: Remove all access immediately upon departure
+3. Apply time-based restrictions to elevated privileges
+   - Use just-in-time access for administrative functions
+   - Implement automatic session termination after periods of inactivity
+   - Require re-authentication for sensitive operations
+4. Conduct regular access reviews with verification
+   - Quarterly: Review all privileged accounts and service accounts
+   - Semi-annually: Audit all standard user accounts and group memberships
+   - Use automated tools to identify inactive or excessive permissions
+5. Implement technical controls to enforce minimal access
+   - Application permissions: API scopes, feature flags, entitlement checks
+   - Infrastructure permissions: IAM policies, network ACLs, resource policies
+   - Database permissions: Row-level security, column-level controls
+
+## 3. Information Flow Control
+
+Ensure sensitive information is only accessible to those with a legitimate need to know, with restrictions on how that
+information can be shared and used.
+
+{/* > **🔗 Related Framework:** This approach is supported by practices in [Data
+Protection](/opsec/old/data-protection/overview) and aspects of [Privacy](/privacy/overview). */}
+
+### Practical Application
+
+1. Implement a practical data classification system with clear handling requirements
+   - Public: Information approved for general distribution
+   - Internal: Business information for employee use only
+   - Confidential: Sensitive information requiring specific protections
+   - Restricted: Critical information with strictly controlled access
+2. Define and enforce data handling procedures for each classification level
+   - Storage requirements: Where information can be stored
+   - Transmission rules: How information can be sent/shared
+   - Processing restrictions: How information can be used
+   - Retention limits: How long information should be kept
+3. Deploy technical controls to enforce information flow policies
+   - Data loss prevention tools to monitor and block unauthorized sharing
+   - Encryption for data at rest and in transit based on sensitivity
+   - Information rights management for persistent protection
+4. Establish secure channels for different types of communication
+   - High-sensitivity: End-to-end encrypted messaging with disappearing messages
+   - Medium-sensitivity: Encrypted collaboration platforms with access controls
+   - Low-sensitivity: Standard business communication tools
+5. Train users on practical information handling procedures
+   - Provide clear guidelines with concrete examples
+   - Use realistic scenarios in training materials
+   - Conduct periodic verification checks
+
+## 4. System Isolation
+
+Segment systems and networks into isolated zones to contain security breaches and limit lateral movement.
+
+### Practical Application
+
+1. Implement network segmentation based on security requirements
+   - Create security zones with consistent trust levels
+   - Implement strict traffic control between zones
+   - Document and regularly review allowed communication paths
+2. Establish environment separation with controlled boundaries
+   - Maintain distinct development, testing, staging, and production environments
+   - Implement one-way data flows from higher to lower environments
+   - Control code promotion processes between environments
+3. Isolate high-value systems with enhanced protection
+   - Place critical infrastructure on dedicated hardware
+   - Example: Run blockchain nodes on dedicated hardware isolated from general workstations
+   - Implement jump servers or privileged access workstations for administrative access
+4. Apply micro-segmentation where appropriate
+   - Container isolation: Enforce pod security policies and network policies
+   - Application segmentation: Implement service meshes with mutual TLS
+   - Process isolation: Use containerization, virtualization, or sandboxing
+5. Monitor and enforce boundary controls
+   - Implement egress filtering to control outbound connections
+   - Deploy internal firewalls between segments
+   - Use network monitoring to detect unauthorized communication attempts
+
+## 5. Continuous Visibility
+
+Maintain ongoing awareness of your security posture through active monitoring, testing, and continuous improvement.
+
+> **🔗 Related Framework:** For implementation details, see the [Monitoring](/monitoring/overview) framework, including
+> [Guidelines](/monitoring/guidelines) and [Thresholds](/monitoring/thresholds). Also relevant is
+> [Incident Management](/incident-management/overview) for response to detected issues.
+
+### Practical Application
+
+1. Implement a multi-layered monitoring strategy
+   - System monitoring: Performance, availability, and system integrity
+   - Security monitoring: Threat detection, anomaly identification, and correlation
+   - Compliance monitoring: Policy enforcement and regulatory requirements
+   - Establish clear ownership for each monitoring domain
+2. Define actionable metrics tied to security objectives
+   - Leading indicators: Metrics that help predict future issues
+   - Example: Percentage of systems with current patches
+   - Lagging indicators: Metrics that measure past performance
+   - Example: Mean time to detect and respond to incidents
+3. Establish a regular testing cadence to validate security controls
+   - Vulnerability scanning: Weekly automated scans
+   - Penetration testing: Quarterly focused tests on critical systems
+   - Red team exercises: Annual comprehensive assessments
+4. Implement a structured incident management process
+   - Define clear incident response procedures with specific roles
+   - Conduct regular tabletop exercises to practice response
+   - Perform thorough post-incident reviews focused on improvement
+   - Create feedback loops to security controls based on incidents
+5. Maintain an active threat intelligence program
+   - Collect intelligence relevant to your specific environment
+   - Analyze and contextualize threats for your organization
+   - Disseminate actionable intelligence to appropriate teams
+   - Use threat intelligence to drive security improvements
+
+---
+
+---
+
+### PAGE: /opsec/travel/guide
+
+# Personal security travel guide — full
+
+
+
+
+Travel introduces unique security risks to your digital assets and sensitive information. Proper preparation before,
+vigilance during, and careful review after travel creates a comprehensive defense strategy that balances security
+with practical usability.
+
+When we travel, our normal security routines are disrupted, and we face elevated risks from physical theft, digital
+surveillance, border inspections, and social engineering. Web3 professionals face additional challenges when traveling
+with crypto assets or access to treasury funds. The resources in this guide provide practical guidance for maintaining
+operational security while traveling.
+
+> 🔑 Key Takeaway: Minimize data exposure by carrying only essential devices with full-disk encryption and updated
+> software. Secure accounts with backup 2FA methods, avoid biometrics at borders, use trusted networks with VPNs, and
+> never leave devices unattended. Guard against USB attacks, shoulder surfing, and hidden cameras. For crypto, use
+> strong passphrases and never travel with seed phrases. Upon returning, scan devices for malware and consider resetting
+> high-risk devices.
+
+{/* separator */}
+
+> ❗ This is not, by any means, an extensive guide on this subject or expected to be followed at its core. Its intention
+> is to guide and provide hints as to where to apply security. This will vary depending on case to case, or, in other
+> words, the risks you expose yourself to, by specifically traveling.
+
+This guide is categorized into four sections:
+
+1. **Before traveling:** All the things you could do before you depart, such as hardening some devices or making sure
+you have a backup of the data you’ll be traveling with, even letting know someone you’ll be calling in case of an
+emergency and how to identify you. This does not necessarily mean that if you’re reading this while traveling you cannot
+do anything from that list, only that it might be more challenging to execute depending on your context.
+2. **While traveling:** All the things you have to pay attention to or take care of while on the move. Is it necessary
+to connect to that conference’s WiFi? Have you checked if there is a camera that might be recording your keystrokes?
+Leaving your computer unattended or just running whatever software your hackathon teammate asks you to download in order
+for your promising project to win.
+3. **Returning home:** Not in the literal sense of it, but directed toward all the things you have to do after your
+travels. From updating your processes based on experience to wiping exposed devices before rejoining them to your
+networks.
+4. **Additional information for high-profile targets:** If you are a high-profile target, you’ll evidently realize that
+some of these initial suggestions fall short within your threat model. This section provides a hint toward profiles like
+yours.
+
+## Before traveling
+
+> 💡**Remove or securely store** any data, devices, printed files, and documents **you don’t absolutely need on the
+> trip**. The less sensitive information and fewer critical assets you carry, the lower the risk and impact if loss,
+> theft, or inspection occurs. Minimize your digital and physical footprint by leaving backups and originals securely at
+> home or in trusted locations, and encrypt what must travel with you. This principle applies to laptops, phones,
+> hardware wallets, paper backups, and any portable storage media.
+
+### **Perform a quick threat model**
+
+Even if you are already traveling, take 5 minutes to map out your risks. Identify **what assets** you're carrying
+(laptops, phones, hardware wallets, seed phrases, account access), **who might target them** (thieves, cybercriminals,
+border agents, etc.), and **how attacks might happen** (device theft, tampering, malware, coercion). For each threat,
+plan a mitigation. For example, if you're carrying a hardware wallet, a threat is pickpocketing – mitigation could be
+keeping it attached to yourself (just don't use ledger's necklace visibly) and securing it with a secure PIN/passphrase
+(no patterns, not repeated across devices).
+
+This exercise keeps security measures proportionate to your situation.
+
+### **Secure devices with encryption & updates**
+
+Enable full-disk encryption on all devices (laptops, phones, tablets) to protect data if lost or stolen. Most modern
+OSes have this by default (e.g. BitLocker for Windows, FileVault for MacOS, LUKS for Linux,or Android/iOS encryption –
+just ensure a strong password/PIN is set).
+
+Use popular devices like iPhones and Pixels. Install the latest OS and app updates since these patch security
+vulnerabilities. This does not mean that using the latest versions is the safest take, but usually there's a balanced
+trade-off when they got security patches. You can also consider to install — only trustworthy — mobile security
+applications, which try to add a layer of control and also reminds you of important security updates.
+
+**Note:** On iOS, due to sandboxing, apps can't scan the entire OS for malware, so many security apps focus on VPN,
+phishing web protection, breach alerts, etc.
+
+If you must bring high-risk confidential data, consider encrypting those files individually using tools like VeraCrypt,
+FileVault, BitLocker, LUKS/dm-crypt, and more.
+
+### **Back up and prepare for loss**
+
+Back up your devices before travel (and ensure cloud backups like iCloud/Google are up to date). This way, if a device
+is lost or confiscated, you won’t lose important information. Record device details (make, model, serial numbers, IMEI
+for phones) and keep that list separate – it will help in filing reports or remote-wipe commands.
+
+If your company uses Mobile Device Management (MDM) on phones or laptops, verify the device is enrolled and you know how
+to trigger a remote wipe or “lost mode.” Test “Find My” or equivalent device-finding services so you can use them if
+needed. Pack chargers and cables so you won’t need to borrow unknown ones (which could be malicious).
+
+### **Protect Accounts with 2FA redundancy**
+
+Plan for how you'll access accounts that use two-factor authentication if your main device is unavailable. For
+authenticator apps (TOTP codes), **export backup codes** for your important accounts and keep them **securely** in
+services like 1Password or NordPass (you can check passwordmanager.com for more information on which one to pick).
+Alternatively, consider storing them elsewhere physically. If your 2FA is tied to a phone number (SMS or voice),
+**disable SMS for 2FA**. For technologies that are unfortunately dependent on phone numbers, use a separate line
+(not your personal one) from services like Google Voice, Burner App or SLYFONE. Transfer your number to an eSIM since
+[they are harder to physically steal or swap than a physical SIM](https://support.apple.com/en-ca/118227#:~:text=Use%20eSIM%20while%20traveling%20internationally,obtain%2C%20carry%2C%20and%20swap).
+
+Ensure your password manager is accessible – many like 1Password have a *Travel Mode* that removes sensitive vaults from
+your device while you travel (you can restore them later). This limits exposure if your
+[device is searched or seized](https://www.schneier.com/blog/archives/2025/04/cell-phone-opsec-for-border-crossings.html).
+
+You can also register a backup or alternative 2FA method, like a secondary phone (the device) or a PIN-protected
+hardware key to be used as a passkey. Be responsible with the use of software passkeys, particularly in situations
+where you are using a password manager to store both your passwords and passkeys, as this creates a single point of
+failure.
+
+### **Secure your wallets and keys**
+
+**Hardware wallets (e.g. Ledger, Trezor):** Update the firmware and test the device before you leave, don't do this
+while traveling. **Do NOT bring any written seed phrases** under any circumstance – seed backups are unencrypted keys
+that are far easier to steal or copy than a hardware device. Leave seed backups in a secure place, travel only with
+your hardware wallet if necessary. Enable all security features on the device (set a strong PIN, and use a BIP39
+passphrase for
+example, if supported) so that even if the device is stolen, the amount of required information to access your crypto,
+is high. Carry hardware wallets and security keys **in your carry-on or under your sight**, not in checked luggage, to
+avoid loss or tampering.
+
+**Yubikeys and 2FA tokens:** Bring them to protect logins and make sure they're enabled on your
+critical accounts. Keep them on your person or in a separate bag from your laptop/phone so that a thief or snoop can't
+easily steal both at once. If you have a **spare hardware wallet or Yubikey**, you might leave one at home as a backup
+in case the one you carry is lost. Add, when possible, an extra layer of security to the token, such as a PIN code.
+
+### **Lock down phones**
+
+On your smartphone, take advantage of security settings **before** you travel. Set a strong passcode (not just a 4-digit
+PIN or pattern). Consider **disabling Touch ID/Face ID** if you might face situations where someone could force-unlock
+your device using your biometrics – in many jurisdictions, authorities can compel a fingerprint or face scan more easily
+than a memorized password
+[.](https://www.schneier.com/blog/archives/2025/04/cell-phone-opsec-for-border-crossings.html#:~:text=deactivate%20biometric%20security%20and%20require,10%20failed%20PIN%20unlock%20attempts)
+At a minimum, know how to quickly and
+[**temporarily disable biometrics**](https://news.ycombinator.com/item?id=43630624);
+for example, on an iPhone,
+[holding the side button and a volume button will trigger an emergency mode that requires the passcode to unlock](https://www.themacguys.com/essential-travel-security-tips-for-apple-devices/).
+On Android, use *Lockdown* mode if available (which only temporarily disables biometrics and is different
+from iOS Lockdown Mode).
+
+If you have an iPhone, enable **Lockdown Mode** (extreme protection on iOS) even if you are not at
+[high risk or traveling to a high-threat region](https://www.themacguys.com/essential-travel-security-tips-for-apple-devices/#:~:text=This%20mode%20is%20ideal%20when,or%20dealing%20with%20sensitive%20data)
+ – but be aware [it restricts many features](https://support.apple.com/en-gb/105120), though totally worth it.
+
+Disabling or restricting USB debugging on Android and using iOS USB restricted mode helps prevent unauthorized physical
+USB access and reduces risks from malicious cables or compromised charging stations.
+
+If your phone is managed by work (MDM), inform your IT team of your travel so they can assist with any location-based
+security policies and ensure you have the latest security profile. Finally, consider using a **dedicated eSIM/local
+SIM** for travel data. This can protect your primary phone number (you can keep your main line on eSIM and turn it off,
+while using a local data eSIM for mobile internet) and avoids physical SIM issues.
+
+**Configure additional phone protections:** On iOS devices, disable Control Center and Notification Center access from
+the lock screen (Settings > Face ID & Passcode) to prevent thieves from seeing notifications or enabling Airplane Mode
+without unlocking. Disable USB accessory connections when locked to prevent unauthorized connections. For device
+recovery, ensure Find My iPhone is enabled with "Send Last Location" and "Find Network" options activated so tracking
+continues even if the device is powered off.
+
+On Android, similar protections can be configured: disable notifications on lock screen (Settings > Notifications > On
+lock screen > Don't show notifications), and enable "Find My Device" with all location services.
+
+**Pay special attention apps security**: many financial apps default to PIN verification instead of biometrics, which
+means a thief who has your phone and knows your PIN could potentially access your financial accounts even if they can't
+bypass Face ID/Touch ID. Use unique PINs for banking apps that differ from your device PIN, or where possible, configure
+these apps to require biometric verification for every login.
+
+### **Minimize digital footprint & social visibility**
+
+It's not just cyber threats – **operational security** matters. **Avoid announcing your travel plans publicly**
+[on social media](https://blackcloak.io/social-media-and-travel-be-careful-of-what-you-share/) and be careful
+with real-time updates. Posts about being away from home can signal to criminals that you (and possibly valuable
+devices or even your house) are vulnerable. Consider sharing trip photos and crypto conference highlights **after**
+you return or only with trusted contacts. Ensure your social media privacy settings are tightened so strangers can't
+see your travel posts.
+
+When registering for events, use privacy-focused tools like iOS's **Hide My Email** or create burner emails through
+providers like Tuta. ProtonMail has had some controversy lately, but could still be a good alternative. If you don't
+need to keep the inbox at all, just create a throwaway mail, there are plenty of options out there. Avoid giving out
+personal details unnecessarily during registration—use minimal, generic info to reduce your digital footprint.
+
+**Discretion** is key: if possible,
+[don't advertise that you work in crypto](https://www.unchained.com/blog/7-tips-traveling-bitcoin#:~:text=,or%20clothing%20with%20bitcoin%20logos)
+or carry cryptocurrency. For example, **remove or cover any crypto stickers on laptops or bags**, and avoid wearing
+company swag or Bitcoin/Ethereum logos while in transit. These can be neon signs attracting thieves or unwanted
+attention ("I have valuable data or wallets!"). If asked about your work or luggage by curious strangers, have a
+**cover story** (e.g. "I work in finance/IT")
+rather than "I manage a crypto fund". High-profile team members might travel under pseudonyms
+or at least not list their company on luggage tags to stay low-profile. Also, be wary that you might be traveling with
+someone with these characteristics, so don't give them away.
+
+### **Plan emergency and incident responses**
+
+Before departure, know what you'll do if something goes wrong. Have a **fallback plan** in case of device loss: who will
+you notify & how (have safe words and beware of deepfakes or impersonations); how will you revoke access to sensitive
+accounts; and how will you continue working (e.g., a backup laptop or a colleague who can step in).
+
+If traveling to
+[countries with strict tech](https://www.perplexity.ai/search/countries-that-list-cryptopgra-bBSItefPSUi7HP2lTNekjA) or
+[encryption laws](https://it.cornell.edu/security-and-policy/travel-internationally-technology#:~:text=Some%20countries%20have%20restrictions%20on,Consider%20requesting%20a%20loaner%20laptop)
+(e.g., China, Russia, UAE), devices like VPNs, encrypted messaging apps (Signal, or Telegram with Secret Chats only),
+hardware wallets (Ledger, Trezor), Yubikeys, or encryption software (VeraCrypt, BitLocker) may be flagged by border
+authorities. Research local laws beforehand. Consider carrying a travel letter from your organization explaining the
+professional need for these tools, or use sanitized loaner devices to avoid issues at border controls.
+
+Share your itinerary and contact information with a trusted peer so they can assist or monitor for any issues.
+
+Finally, schedule critical work (especially high-value transactions) for **before or after** your trip if possible, so
+you’re not forced to do ultra-sensitive actions on the road. Criminals usually play with the “time-sensitive factor,”
+trying to trick you into doing something quick and urgent, by committing something reckless.
+
+## While traveling
+
+### **Network safety – avoid untrusted Wi-Fi & Bluetooth**
+
+Treat **every network as potentially hostile**. Whenever possible, use a **cellular connection or a personal hotspot**
+instead of public Wi-Fi – your mobile data is encrypted and safer than an open café or hotel network. If you must use
+public Wi-Fi (hotel, airport, conference), verify the network name with staff and
+[**disable auto-connect**](https://www.cisa.gov/sites/default/files/publications/Cybersecurity%20While%20Traveling.pdf)
+features so your devices don't join networks without prompting you.
+
+**Turn off Wi-Fi and Bluetooth** on your phone and laptop when you're not using them; this reduces the risk of
+unsolicited connections or Bluetooth-based attacks. Also, disable any device-to-device sharing like **AirDrop** or
+**Nearby Share**
+[to prevent strangers from sending you files](https://www.cypherock.com/blogs/post-safe-vacation-tips-while-traveling-with-crypto#:~:text=Switch%20off%20any%20shared%20networks).
+
+**Use a trustworthy VPN** for an extra layer of encryption for your internet traffic, although in most cases by using an
+updated device, safe hardcoded DNS records, and ensuring SSL while browsing (enforce HTTPS-only-modes or adding
+“http://*” to your uBlock list, might be enough. A reputable, non-logging VPN (or your company’s VPN) helps protect
+against snooping on public networks, especially if you’re handling highly sensitive work and using several communication
+channels.
+
+Using a personal portable router combined with a trusted VPN adds a strong layer of security when connecting to public
+Wi-Fi networks. This setup creates a private, encrypted tunnel between your devices and the internet, minimizing
+exposure to malicious actors on shared networks. Whenever possible, prefer mobile data over Wi-Fi, as cellular networks
+provide better encryption and isolation by default. If you must use Wi-Fi, disable automatic connections and ensure you
+connect only to verified, trusted networks to reduce risk.
+
+### **Device handling – keep them close and protected**
+
+Never leave your devices (laptops, phones, hardware wallets) **unattended or unsecured** in public. Keep them on your
+person or within sight whenever possible. In a conference or cafe, use a cable lock for your laptop if you must step
+away briefly, take it with you or get someone you trust to watch it over for you.
+
+In hotels/Airbnbs, **use the room safe** for small devices when you're out. These safes can easily be opened by an experienced
+thief or rogue/malicious staff. Consider a portable travel safe/bag you can lock to a fixed object. A
+[**portable door lock**](https://www.travelandleisure.com/sabre-portable-door-lock-review-7643179#:~:text=schedule%20and%20explore%20fascinating%20destinations,star%20ratings%20at%20Amazon)
+or door jammer for your room can add an extra barrier against intruders (useful in rentals without chain locks). This
+simple gadget prevents anyone (even with a key) from opening your door while you're inside, giving you peace of mind at
+night. When out and about, be mindful of pickpockets – use bags that zip and consider a subtle anti-theft backpack for
+expensive gadgets or important assets.
+
+For hardware wallets or Yubikeys, a good practice is to **separate them** from the device they authenticate: e.g. don't
+carry your Yubikey on the same keychain as your laptop bag key; keep it hidden on you. And, of course, **keep devices
+powered off** or locked when not in use –
+[enable short auto-lock timeouts](https://www.cisa.gov/sites/default/files/publications/Cybersecurity%20While%20Traveling.pdf#:~:text=%E2%80%A2%20%20%20%20,Some%20devices%20will)
+on your phone/laptop so they aren't unlocked if
+snatched[.](https://www.cisa.gov/sites/default/files/publications/Cybersecurity%20While%20Traveling.pdf#:~:text=%E2%80%A2%20%20%20%20,Some%20devices%20will)
+
+### **Beware of public USB charging**
+
+Avoid plug-and-play charging stations at airports or malls. The risk of
+["**juice jacking**"](https://www.cypherock.com/blogs/post-safe-vacation-tips-while-traveling-with-crypto?srsltid=AfmBOopuzAsUtNwqCqfUBteTEyH4MOTvIaRhoXoIUyNHH8Yv5XzILrSr#:~:text=Stay%20away%20from%20Public%20charger,stations),
+although small,
+is that a malicious charging kiosk or cable can inject malware or siphon data when you connect via USB. Depending on
+your profile risk, you might encounter technologies that mimic different kind of cables and accessories with the same
+purpose. These exist out of the box, and have been widely used by red-teamers and pentesters (re OMG cable).
+
+Stick to using your own charger plugged into a power outlet, or use a **USB data blocker** (a little adapter that
+only passes power, not data). Similarly, do not plug unknown USB drives into your laptop – if someone hands you
+a free USB stick at an event, assume it could be a trap.
+[**USBGuard**](https://github.com/USBGuard/usbguard#:~:text=USBGuard%20is%20a%20software%20framework,may%20interact%20with%20the%20system)
+software (for Linux) or equivalent can be used to restrict USB device access on your computer, allowing only
+whitelisted devices. This tool can prevent an unknown USB from automatically tampering with your system by requiring
+authorization for new devices. At a minimum, disable any "USB autorun" features and consider locking down ports if your
+OS allows.
+
+### **Screen privacy and social engineering**
+
+Practice situational awareness when working in public spaces.
+[**Shoulder surfing**](https://www.trio.so/blog/shoulder-surfing-in-computer-security)
+is a real threat – someone nearby could be
+watching you enter passwords or PIN codes. Use a **privacy screen filter** on your laptop or phone to narrow the viewing
+angle. This makes it much harder for anyone not directly in front of your screen to read it. Sit with your back to a
+wall when possible, and shield the keypad with your body or hand when typing sensitive info.
+
+In crowded conferences or airports, be cautious if someone you don't know strikes up conversation — might be trying to
+distract you or talk about crypto; scammers might engage you to glean info or even attempt to get you to unlock your
+device. **Don't log in to critical accounts in front of others** – you never know who's looking.
+
+Also be mindful of **phishing attempts**: traveling users are prime targets for fake "urgent" emails or messages.
+Double-check any unusual prompts before entering credentials, especially if you're on
+[untrusted Wi-Fi](https://www.cisa.gov/sites/default/files/publications/Cybersecurity%20While%20Traveling.pdf#:~:text=banking%2C%20or%20sensitive%20work%2C%20using,using%20a%20public%20wireless%20network)
+(use your VPN and look for HTTPS).
+
+### **Maintain OpSec in public**
+
+While traveling, **blend in and stay discreet**. Refrain from discussing sensitive matters in public areas where
+eavesdropping is possible, or directly sharing things like where you are staying to people you don't know. Even hotel
+lobbies or rideshares might not be secure for private discussions.
+
+When meeting people, don't give your phone to others to type down their socials, and remember to disable default options
+like Telegram's sharing phone number when adding a contact.
+
+Remember that **hidden cameras or microphones** could exist in unfamiliar environments. It's rare but not unheard of,
+especially in
+[Airbnbs or rented spaces](https://www.washingtonpost.com/travel/2024/05/22/hidden-cameras-airnbnb-rental-properties/#:~:text=On%20the%20kitchen%20table%2C%20he,activate%20the%20camera%20tucked%20inside)
+– malicious hosts have hidden cameras in items like smoke detectors, clock radios, or USB chargers
+[.](https://www.washingtonpost.com/travel/2024/05/22/hidden-cameras-airnbnb-rental-properties/#:~:text=On%20the%20kitchen%20table%2C%20he,activate%20the%20camera%20tucked%20inside)
+Give your accommodations a scan: look for odd or
+[extra devices plugged in](https://www.washingtonpost.com/travel/2024/05/22/hidden-cameras-airnbnb-rental-properties/)
+(especially facing beds or desks) and cover or unplug them if suspicious. You can also play ambient noise (or use a
+noise generator app) during confidential conversations to thwart any listening devices.
+
+**Keep a low profile**: as mentioned,
+[don't flaunt crypto wealth or gear.](https://www.unchained.com/blog/7-tips-traveling-bitcoin#:~:text=,or%20clothing%20with%20bitcoin%20logos)
+For example, if attending a blockchain conference, consider using an alias on your name badge that doesn't explicitly
+say your company or title, and don't display that badge outside the venue. When moving around, secure your laptop in a
+nondescript sleeve or bag (instead of one with a well-known conference brand). The goal is to avoid drawing the
+attention of both petty thieves and more organized attackers by limiting the signals that you're a high-value crypto
+target.
+
+Don't rely on security through obscurity. Going "stealth" doesn't make you immune to attacks. The suggestions in
+this section are meant to complement, not replace, the other security measures.
+
+### **Traveling with high-value crypto or duties**
+
+If you *must* make crypto transactions or access sensitive systems while on the road, do so with caution. Use trusted
+hardware and networks: e.g. if you need to send a transaction, use your hardware wallet on your own laptop (never a
+shared computer), on a secured connection.
+
+Be aware of **surveillance at events** – attackers have been known to watch for people handling sensitive info. If you
+need to access a seed or enter a recovery phrase, do it in a private, secure setting (never over public Wi-Fi or in view
+of anyone, including cameras). Consider that
+[**everyone knows you own crypto at a crypto event**](https://www.unchained.com/blog/7-tips-traveling-bitcoin#:~:text=If%20you%27re%20traveling%20to%20an,in%20your%20belongings%20while%20traveling),
+so your threat profile is
+elevated[.](https://www.unchained.com/blog/7-tips-traveling-bitcoin#:~:text=If%20you%27re%20traveling%20to%20an,in%20your%20belongings%20while%20traveling)
+Adjust your security: for instance, **enable a passphrase or a pin on any single-signature wallet** you carry so that
+even if someone obtains your hardware wallet, they can't access funds without that passphrase. For large amounts, rely
+on multi-sigs, verifying payloads before signing – you might carry one key on you and leave another key(s) with trusted
+parties so no single person has all
+signing power while traveling. In short, treat any on-trip crypto operations with more care than you would in the
+office or at home.
+
+### While presenting or doing public appearances
+
+One often overlooked risk is the exposure caused by presenting or hosting technical workshops in public. Without
+properly hardening or isolating your computer before setting up, you may unintentionally expose network services to
+hostile environments or reveal sensitive information on-screen. Always prepare a clean, minimal environment and verify
+no confidential data or open ports are accessible before connecting to unfamiliar networks or projecting your screen.
+
+### **Physical safety and common sense**
+
+Operational security also has a physical aspect. **Trust your instincts** and normal travel safety rules: stick to
+well-lit and populated areas if carrying devices at night, don’t let strangers “shoulder surf” your ATM or credit card
+PIN (check for skimmers, fake interfaces), and keep your travel documents secure since identity theft can be as damaging
+as device theft.
+
+Use hotel lockers at conferences if provided (for example, some events offer secure charging lockers – use them rather
+than leaving devices out only).
+
+Beware of the classic “evil maid” scenario in hotels (where someone might tamper with your laptop in your room): using
+tamper-evident tape or seals on your laptop case can help detect this, though it’s mostly a concern for high-risk
+targets. If you have tamper-evident stickers or tamper-evident bags, you can seal your device in them overnight – any
+attempt to open or remove the device will leave a visible trace. While not foolproof against a determined adversary, it
+raises the bar and can deter casual snooping.
+
+Petty thieves may look beyond obvious valuables. Simply locking items in a dorm safe or hiding them at home might deter
+casual theft, but savvy criminals often search inside books, behind electrical outlets, or within patterns on walls or
+furniture to find hidden stashes. Consider unconventional hiding spots and avoid predictable storage methods. Layer your
+physical security measures with tamper-evident seals or discreet decoy containers to raise the effort required for
+unauthorized access.
+
+Above all, maintain an **alert posture**: be aware of who’s around when you’re working, and if something feels off (like
+someone persistently hovering or a device acting strangely), don’t ignore it. You can always relocate, power down your
+device, or otherwise cut off exposure at the first sign of trouble.
+
+## Returning home
+
+### **Secure your accounts and passwords**
+
+Once you're back, if you suspect that any account credentials you used while abroad *might* have been exposed
+(especially if you had to log in over a hotel or conference Wi-Fi), address the issue. Change the passwords for any
+accounts you accessed unsafely during the trip – but if you don't feel is necessary, sometimes you pose a greater risk
+at doing so.
+
+Do this from a *trusted* device/network (ideally wait till you're on your home or office network, not the airport
+Wi-Fi). Use this opportunity to upgrade weak passwords and ensure 2FA is still working on those accounts. Check your
+email filters and crypto account settings for any unauthorized changes (attackers sometimes add forwarding rules or new
+withdrawal addresses if they did get access).
+
+Essentially, **rotate secrets** that may have been used under less-secure conditions.
+
+### **Inspect and clean your devices**
+
+After traveling, give your devices a thorough once-over. Run a reputable anti-malware scan on laptops and phones. Look
+for any unusual apps, processes, or device behavior (for example, unusual battery drain could indicate malware).
+
+If you were in a high-risk environment or your device was out of your control at any point, consider wiping the device
+and restoring it from your pre-trip backup (or factory-resetting a phone)
+[to ensure it's clean](https://architectsecurity.org/2017/10/mobile-device-security-for-international-travelers-part-3-how-to-clean-up-your-mobile-devices-after-international-travel/#:~:text=Assume%2C%20whether%20correct%20or%20not%2C,and%20must%20be%20rebuilt%20anew)[.](https://architectsecurity.org/2017/10/mobile-device-security-for-international-travelers-part-3-how-to-clean-up-your-mobile-devices-after-international-travel/#:~:text=The%20goal%20after%20travel%20is,to%20a%20%E2%80%9Cknown%20good%E2%80%9D%20state)
+This is especially recommended for "burner" devices used on the trip – you can safely restore your data onto your main
+device and decommission the travel device.
+
+[... truncated ...]
+
+---
+
diff --git a/scripts/data/qa-results/sfc-devops-infrastructure.json b/scripts/data/qa-results/sfc-devops-infrastructure.json
new file mode 100644
index 00000000..8ceea0c2
--- /dev/null
+++ b/scripts/data/qa-results/sfc-devops-infrastructure.json
@@ -0,0 +1,107 @@
+[
+  {
+    "controlId": "di-1.1.4",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Evaluator correctly identified partial coverage. IDE page mentions 'trusted sources' for plugins/extensions (baseline 2), but does not address: evaluation criteria for AI-powered tools, data privacy assessment, approved tool lists, restrictions on unapproved tools, or regular tool reviews."
+  },
+  {
+    "controlId": "di-2.1.1",
+    "originalCoverage": "full",
+    "qaCoverage": "partial",
+    "verdict": "downgraded",
+    "notes": "Evaluator incorrectly marked as 'full' but then listed baseline 6 (periodic access reviews) as missed. The page covers RBAC, branch protection, signed commits, multi-party review, and MFA well (baselines 1-5), but does NOT mention periodic repository access reviews. Should be partial, not full."
+  },
+  {
+    "controlId": "di-2.1.2",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Evaluator correctly identified partial coverage. CI/CD page mentions 'check for...leaked credentials' which covers automated scanning in CI/CD (baselines 1,4 partial), but no mention of pre-commit hooks or remediation procedures for discovered secrets."
+  },
+  {
+    "controlId": "di-2.1.4",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Evaluator correctly identified partial coverage. Dependency awareness page clearly covers trusted sources, vulnerability monitoring, and regular audits (baselines 1,3,5). Missing: typosquatting verification, version pinning enforcement, and changelog reviews."
+  },
+  {
+    "controlId": "di-3.1.1",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Evaluator correctly identified partial coverage. CI/CD page explicitly mentions deterministic builds with strict dependencies (baseline 5) and access controls limiting who can modify pipelines (partial baseline 1). Missing: explicit multi-party approval requirement, service accounts with minimal permissions, restriction on manual deployments, and version control of pipeline configs."
+  },
+  {
+    "controlId": "di-3.1.3",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Evaluator correctly identified partial coverage across two pages. CI/CD page mentions 'detect vulnerabilities in code and dependencies during the CI process' (baselines 1,2) and 'PR testing must pass before merging' (partial baseline 3). Security-testing page explicitly mentions SAST in CI/CD. Missing: explicit statement that security scan results are reviewed before deployment approval, and staging environment validation."
+  },
+  {
+    "controlId": "di-4.1.1",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Evaluator correctly identified partial coverage. IaC page clearly states infrastructure is managed through code (baseline 1) and mentions 'Integrate security scanning tools into the IaC pipeline' (baseline 4). Missing: explicit requirement for automated deployment pipelines and multi-party approval for infrastructure changes."
+  },
+  {
+    "controlId": "di-4.1.2",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Evaluator correctly identified partial coverage, though this is a weak mapping. The repository page discusses MFA, RBAC, and audit logging (baselines 1,3,6) but in the context of code repositories, not infrastructure access. Missing: JIT access with multi-party approval, break-glass accounts, and break-glass alerting. This mapping is questionable since control is about infrastructure but page is about repositories."
+  },
+  {
+    "controlId": "di-4.1.3",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Evaluator correctly identified partial coverage. Repository page mentions 'Regular backups' and 'secure, offsite location' for code repositories, covering baseline 4 (independent storage) and partially baseline 1 (but only for code repos, not critical systems broadly). Missing: DR plan with RTO/RPO definition, and backup/recovery testing procedures."
+  },
+  {
+    "controlId": "di-4.1.4",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Evaluator correctly identified partial coverage. Cloud page mentions 'comprehensive logging, monitoring, and threat detection' (baselines 1,4) and 'respond to security incidents in real-time' (partial baseline 2). Explicitly lists CloudTrail, Azure Monitor, Google Cloud Logging. Missing: subscription to cloud provider security notifications and multi-cloud strategy considerations."
+  },
+  {
+    "controlId": "di-1.1.1",
+    "originalCoverage": "none",
+    "qaCoverage": "none",
+    "verdict": "confirmed",
+    "notes": "Correct — no framework page addresses DevOps security ownership, accountability scope, or designated security owner responsibilities."
+  },
+  {
+    "controlId": "di-1.1.2",
+    "originalCoverage": "none",
+    "qaCoverage": "none",
+    "verdict": "confirmed",
+    "notes": "Correct — no framework page addresses a comprehensive DevOps security policy document covering environment standards, access controls, deployment procedures, code management, and supply chain security."
+  },
+  {
+    "controlId": "di-1.1.3",
+    "originalCoverage": "none",
+    "qaCoverage": "partial",
+    "verdict": "false-negative",
+    "notes": "Evaluator missed coverage. IDE page states 'Ensure that potential development environments are isolated from production environments' (addresses baseline about production credential isolation). CI/CD page mentions 'Use isolated environments for building and testing to prevent contamination' (relevant to isolation principle). Neither addresses containerization, per-repo environments, or credential restrictions explicitly, but partial coverage exists."
+  },
+  {
+    "controlId": "di-2.1.3",
+    "originalCoverage": "none",
+    "qaCoverage": "none",
+    "verdict": "confirmed",
+    "notes": "Correct — repository page mentions general code review requirements but does not specifically address external contributors, additional approval requirements for external code, tracking of external contributions, or restricting external collaborator permissions."
+  },
+  {
+    "controlId": "di-3.1.2",
+    "originalCoverage": "none",
+    "qaCoverage": "none",
+    "verdict": "confirmed",
+    "notes": "Correct — CI/CD page mentions checking for 'leaked credentials' (detection), but no framework page addresses dedicated secrets management systems, secrets never in source code, production secrets inaccessible to humans, or automated secret rotation. Detection is not the same as secrets management."
+  }
+]
diff --git a/scripts/data/qa-results/sfc-dns-registrar.json b/scripts/data/qa-results/sfc-dns-registrar.json
new file mode 100644
index 00000000..a3e430b5
--- /dev/null
+++ b/scripts/data/qa-results/sfc-dns-registrar.json
@@ -0,0 +1,114 @@
+[
+  {
+    "controlId": "dns-2.1.2",
+    "originalCoverage": "full",
+    "qaCoverage": "full",
+    "verdict": "confirmed",
+    "notes": "All baselines met. Page covers enterprise registrars with registry locks, hardware MFA (FIDO2/WebAuthn), social engineering history (GoDaddy incidents documented), and ICANN compliance checking."
+  },
+  {
+    "controlId": "dns-3.1.1",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Correctly identified gaps. Page mentions documenting personnel and quarterly access reviews but lacks actionable guidance on HOW to document authorization procedures or implement prompt revocation."
+  },
+  {
+    "controlId": "dns-3.1.2",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Correctly identified missing baseline. Page covers separate domain, non-personal, and security-exclusive use, but does NOT mention that it should be an alias notifying multiple people."
+  },
+  {
+    "controlId": "dns-4.1.1",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Correctly identified coverage. DNSSEC and CAA are fully covered. TTL is only mentioned in monitoring context (detecting drops), not as a policy to document. No guidance on consistent application based on domain classification."
+  },
+  {
+    "controlId": "dns-4.1.2",
+    "originalCoverage": "full",
+    "qaCoverage": "partial",
+    "verdict": "downgraded",
+    "notes": "Evaluator overclaimed. SPF, DKIM, DMARC with reject policy, rua monitoring, and MTA-STS are covered. MISSING: No explicit guidance that domains which don't send email should have SPF/DMARC records that reject all email (baseline #5)."
+  },
+  {
+    "controlId": "dns-4.1.3",
+    "originalCoverage": "full",
+    "qaCoverage": "full",
+    "verdict": "confirmed",
+    "notes": "All baselines met. Registry/server-level EPP locks covered, transfer locks (clientTransferProhibited) explained, and periodic verification addressed via EPP status codes and RDAP checking."
+  },
+  {
+    "controlId": "dns-5.1.1",
+    "originalCoverage": "full",
+    "qaCoverage": "partial",
+    "verdict": "downgraded",
+    "notes": "Evaluator marked 'full' but identified missed baseline, creating contradiction. DNS monitoring scope is comprehensive (NS/A/MX/TXT/CAA/DNSSEC/TTL), critical alerts trigger investigation, but MISSING actionable guidance on HOW to document alerting/escalation paths (baseline #3). Monitoring infrastructure independence not explicitly stated."
+  },
+  {
+    "controlId": "dns-5.1.2",
+    "originalCoverage": "full",
+    "qaCoverage": "full",
+    "verdict": "confirmed",
+    "notes": "All baselines met. CT monitoring services listed (crt.sh, Cert Spotter), investigation of unauthorized certificates implied, wildcard flagging explicitly mentioned."
+  },
+  {
+    "controlId": "dns-5.1.3",
+    "originalCoverage": "full",
+    "qaCoverage": "full",
+    "verdict": "confirmed",
+    "notes": "All baselines explicitly met. Auto-renewal, calendar reminders at 90/60/30/7 days, payment verification, and backup person designation all directly addressed."
+  },
+  {
+    "controlId": "dns-6.1.1",
+    "originalCoverage": "full",
+    "qaCoverage": "partial",
+    "verdict": "downgraded",
+    "notes": "Evaluator marked 'full' but identified missed baseline. Alerting system and communication plan (status page, social media) are covered. MISSING: Comprehensive guidance on pre-documenting emergency contacts. Registrar security team mentioned, law enforcement mentioned, but SEAL 911 not mentioned and legal counsel only briefly referenced."
+  },
+  {
+    "controlId": "dns-6.1.2",
+    "originalCoverage": "full",
+    "qaCoverage": "partial",
+    "verdict": "downgraded",
+    "notes": "Evaluator marked 'full' but identified missed baseline. IR plan covers key scenarios (registrar compromise, DNS hijacking, transfers), registry lock activation, regaining control procedures, and post-recovery validation (DNS baseline check, credential reset, log review). MISSING: Annual testing requirement (baseline #5) not mentioned."
+  },
+  {
+    "controlId": "dns-1.1.1",
+    "originalCoverage": "none",
+    "qaCoverage": "none",
+    "verdict": "confirmed",
+    "notes": "Confirmed no coverage. Pages do not address overall domain security ownership/accountability scope (policy maintenance, security reviews, renewal management, access control oversight, incident escalation). 'Backup person for renewals' is too narrow."
+  },
+  {
+    "controlId": "dns-1.1.2",
+    "originalCoverage": "none",
+    "qaCoverage": "none",
+    "verdict": "confirmed",
+    "notes": "Confirmed no coverage. No content about maintaining a domain inventory/registry with the required fields (domain name, ownership, purpose, expiration, registrar, DNS configs, security settings, registrar account configs)."
+  },
+  {
+    "controlId": "dns-2.1.1",
+    "originalCoverage": "none",
+    "qaCoverage": "none",
+    "verdict": "confirmed",
+    "notes": "Confirmed no coverage. Pages use term 'critical domains' but provide no classification framework (tiers, financial exposure criteria, operational impact assessment, mapping classifications to requirements). Using the word 'critical' without defining HOW to classify is insufficient."
+  },
+  {
+    "controlId": "dns-3.1.3",
+    "originalCoverage": "none",
+    "qaCoverage": "none",
+    "verdict": "confirmed",
+    "notes": "Confirmed no coverage. One bullet point says 'Implement approval workflows for critical changes' but provides no guidance on WHAT changes, HOW to notify teams, or logging procedures. Too minimal to count as partial coverage."
+  },
+  {
+    "controlId": "dns-4.1.4",
+    "originalCoverage": "none",
+    "qaCoverage": "none",
+    "verdict": "confirmed",
+    "notes": "Confirmed no coverage. Certificate Transparency monitoring detects unauthorized issuance but doesn't address certificate lifecycle management (issuance procedures, renewal automation, revocation procedures, expiration tracking)."
+  }
+]
diff --git a/scripts/data/qa-results/sfc-incident-response.json b/scripts/data/qa-results/sfc-incident-response.json
new file mode 100644
index 00000000..d7e7b448
--- /dev/null
+++ b/scripts/data/qa-results/sfc-incident-response.json
@@ -0,0 +1,86 @@
+[
+  {
+    "controlId": "ir-1.1.1",
+    "originalCoverage": "partial",
+    "qaCoverage": "no-coverage",
+    "verdict": "downgraded",
+    "notes": "Implementation checklist mentions drill reviews and regular updates, not IR team role assignments. Emergency procedures has post-incident analysis but doesn't explicitly cover annual review of IR roles/authorities. Neither page addresses incident commander, SMEs, scribe, communications personnel, legal support, or decision makers."
+  },
+  {
+    "controlId": "ir-1.1.2",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Emergency procedures shows Security Team contact and internal escalation structure. SEAL 911 guidelines define key roles (Operations, Scribe, Strategy Lead, etc.) and mention SEAL 911 as external expertise. Secure multisig practices mention incident notification. Coverage is partial as claimed - missing protocol dependency contacts, legal/PR specifics, infrastructure vendors, and quarterly review requirements."
+  },
+  {
+    "controlId": "ir-2.1.1",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "DNS monitoring page provides solid coverage of infrastructure monitoring, credential exposure detection via Certificate Transparency, and documented monitoring scope. Missing 24/7 procedures. However, monitoring guidelines page is too generic (just says 'define what to monitor') - this should arguably be excluded, but keeping partial verdict since DNS page alone justifies it."
+  },
+  {
+    "controlId": "ir-2.1.2",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Emergency procedures includes triage steps (assess scope, escalate), management notification (Security team), and escalation template. Missing automated alerting config, embedded triage guidance, time-based triggers, redundant paging, on-call schedules, and backup procedures. Correctly assessed as partial."
+  },
+  {
+    "controlId": "ir-3.1.1",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Emergency procedures has detailed key compromise playbook with immediate actions, recovery process, and role responsibilities (First Reporter, team coordination). Secure multisig practices covers signer rotation and threshold review. Missing playbooks for protocol exploits, infrastructure failures, access control breaches, supply chain, and frontend/DNS compromise. Also missing escalation criteria for leadership engagement, shutdown, public disclosure."
+  },
+  {
+    "controlId": "ir-3.1.2",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Secure multisig best practices mentions emergency drills and quarterly testing for emergency multisigs. Setup-and-configuration page has minimal relevant content. Missing cross-timezone coordination procedures, on-call integration, and escalation paths for unreachable signers. Partial coverage is correct."
+  },
+  {
+    "controlId": "ir-3.1.3",
+    "originalCoverage": "full",
+    "qaCoverage": "partial",
+    "verdict": "downgraded",
+    "notes": "Both pages provide extensive backup signing infrastructure (Eternal Safe, Squads, alternate UIs, backup RPCs, block explorers) and emergency execution procedures. However, NEITHER page addresses pre-signed or pre-prepared emergency transactions. Without pre-signed transactions for critical functions (pause, freeze, parameter changes), this cannot be 'full' coverage. Downgraded to partial."
+  },
+  {
+    "controlId": "ir-4.1.1",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Implementation checklist mentions primary/backup channels and testing. Emergency procedures describes multiple communication channels, secure communication (need-to-know, encrypted), and identity verification. Missing documented access controls/member lists, documented failover procedures, and procedures for rapidly creating war room channels. Correctly partial."
+  },
+  {
+    "controlId": "ir-4.1.2",
+    "originalCoverage": "full",
+    "qaCoverage": "partial",
+    "verdict": "downgraded",
+    "notes": "Communication strategies page mentions 'provide regular updates to stakeholders' and 'fixed schedule' but doesn't specify status update cadence BY SEVERITY LEVEL (e.g., P1 every 30min, P2 every 2hr). Also doesn't provide specific format templates or distribution lists for different stakeholder groups. Generic guidance doesn't meet the baseline requirements fully."
+  },
+  {
+    "controlId": "ir-4.1.3",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "SEAL 911 guidelines cover user communication coordination, information flow management (monitoring social media), and approval flow (External Communicator role). Emergency procedures provide one emergency notification template. Missing pre-approved templates for DIFFERENT incident types and severity levels, and specific misinformation management procedures. Correctly partial."
+  },
+  {
+    "controlId": "ir-5.1.1",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Emergency procedures describe drill schedule (quarterly, bi-annually, annually), full pipeline testing (notification, response time, process), and production alerting validation. Decentralized IR mentions quarterly red team drills and iterating framework during retrospective. Missing coverage of different incident types across exercises, structured drill documentation (participants, gaps, corrective actions), and corrective action tracking to completion."
+  },
+  {
+    "controlId": "ir-2.1.3",
+    "originalCoverage": "no-coverage",
+    "qaCoverage": "no-coverage",
+    "verdict": "confirmed",
+    "notes": "Reviewed all 10 framework pages - no content addresses log retention periods, retention adequacy for forensics, or tamper-evident logging for security events. Correctly identified as no coverage."
+  }
+]
diff --git a/scripts/data/qa-results/sfc-multisig-ops.json b/scripts/data/qa-results/sfc-multisig-ops.json
new file mode 100644
index 00000000..49062178
--- /dev/null
+++ b/scripts/data/qa-results/sfc-multisig-ops.json
@@ -0,0 +1,170 @@
+[
+  {
+    "controlId": "ms-1.1.1",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Implementation checklist mentions administrator responsibilities but does NOT teach how to establish a named owner with defined accountability scope covering all five areas (policy maintenance, signer onboarding/offboarding, documentation accuracy, periodic reviews, incident escalation). The 'Ongoing Management' section mentions 'procedures for regular reviews' but lacks comprehensive accountability framework teaching."
+  },
+  {
+    "controlId": "ms-1.1.2",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "secure-multisig-best-practices mentions 'purpose, wallet address, list of signer addresses' but missing: network, threshold, classification, controlled contracts, on-chain roles, last review date. No page teaches specific update timelines (24h/3d) or access control requirements. Implementation checklist references templates but doesn't teach requirements inline. Evaluation correctly identified gaps."
+  },
+  {
+    "controlId": "ms-2.1.1",
+    "originalCoverage": "full",
+    "qaCoverage": "full",
+    "verdict": "confirmed",
+    "notes": "Combined coverage across planning-and-classification (baselines 1,2,4,5) and secure-multisig-best-practices (baseline 3,4) achieves full coverage. Planning page teaches impact/operational assessment, classification matrix, and review cadence. Best practices page covers 3+ signers, 50%+ threshold, no N-of-N. All baselines met."
+  },
+  {
+    "controlId": "ms-2.1.2",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "setup-and-configuration covers timelocks, modules, guards, address whitelisting, invariant enforcement under 'Contract-Level Controls' section and mentions 'Do not install any other modules or guards without explicit governance approval and security review' (partial security review requirement). However, it does NOT teach: (1) systematic evaluation process tied to classification levels, (2) documentation requirements for control selection decisions including rationale for controls NOT implemented. Gaps correctly identified."
+  },
+  {
+    "controlId": "ms-2.1.4",
+    "originalCoverage": "partial",
+    "qaCoverage": "none",
+    "verdict": "downgraded",
+    "notes": "secure-multisig-best-practices 'General Rules' section does NOT substantively teach wallet segregation. The evaluator marked it partial but I cannot find teaching on segregation strategy, hot/cold separation, or treasury distribution. The page focuses on multisig configuration, not wallet segregation principles. Should be 'none' coverage."
+  },
+  {
+    "controlId": "ms-3.1.1",
+    "originalCoverage": "full",
+    "qaCoverage": "partial",
+    "verdict": "downgraded",
+    "notes": "secure-multisig-best-practices states 'Signers should verify their addresses by signing a message stating their affiliation and the multisig they intend to join' which covers message signing concept. However, it does NOT specify: (1) verification via independent tool, (2) documented proof of verification. The setup-and-configuration 'Pre-Launch Checklist' only has checkbox 'All signer addresses added and verified' without teaching the verification process. Original 'full' assessment was too generous - should be partial."
+  },
+  {
+    "controlId": "ms-3.1.2",
+    "originalCoverage": "full",
+    "qaCoverage": "full",
+    "verdict": "confirmed",
+    "notes": "secure-multisig-best-practices 'Thresholds & Configuration' states: 'All signers must use hardware wallets' (baseline 1) and 'Signers on multisigs with critical protocol configuration or security roles are discouraged from using their addresses for other purposes. They should create a brand new wallet for that purpose instead' (baseline 2). Both baselines fully met."
+  },
+  {
+    "controlId": "ms-3.1.3",
+    "originalCoverage": "full",
+    "qaCoverage": "full",
+    "verdict": "confirmed",
+    "notes": "seed-phrase-management 'Secure Storage Practices' comprehensively covers: 'Prohibited Practices' section lists never storing digitally/cloud/photographed (baseline 1); 'split seed into 3 pieces' at different secure locations (baseline 2 - geographically distributed); tamper-evident bags and multiple secure locations (baseline 3 - no single point of compromise); 3-piece split system allows recovery with any 2 pieces (baseline 4 - operator-loss resistant). All baselines fully taught."
+  },
+  {
+    "controlId": "ms-3.1.4",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "secure-multisig-best-practices 'Signer rotation' section teaches signer replacement procedures but does NOT specify: (1) removal timelines by classification (48-72h Emergency, 7d Critical, 14d others), (2) quarterly access reviews confirming signers control their keys. Gaps correctly identified."
+  },
+  {
+    "controlId": "ms-3.1.5",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "implementation-checklist 'For Signers' section covers: transaction verification training (checkbox items), emergency procedures (Emergency Preparedness section), practical skills assessment implied by checklist structure. However, does NOT specify: annual refreshers or updates within 30 days of procedure changes. The evaluator correctly noted this baseline is missing. Gap accurately identified."
+  },
+  {
+    "controlId": "ms-3.1.6",
+    "originalCoverage": "full",
+    "qaCoverage": "full",
+    "verdict": "confirmed",
+    "notes": "implementation-checklist 'Hardware & Security Setup' states: 'I have purchased recommended hardware wallet from authorized source' (baseline 2 - verified supply chains), 'I have set up my hardware wallet with proper firmware and PIN' (baseline 1 - PIN security and firmware integrity). The reference to '/wallet-security/intermediates-&-medium-funds' provides additional hardware wallet capability requirements. Both baselines adequately covered."
+  },
+  {
+    "controlId": "ms-3.1.7",
+    "originalCoverage": "full",
+    "qaCoverage": "full",
+    "verdict": "confirmed",
+    "notes": "personal-security-opsec 'Network Security' section thoroughly covers: 'Multi-sig operations must be performed on devices dedicated only to these transactions' (baseline 2 - dedicated signing devices), 'Device Security' section documents requirements like full disk encryption, endpoint protection (baseline 1 - documented and enforced). Both baselines fully met."
+  },
+  {
+    "controlId": "ms-3.1.8",
+    "originalCoverage": "full",
+    "qaCoverage": "full",
+    "verdict": "confirmed",
+    "notes": "secure-multisig-best-practices 'Strategic Signer Distribution' section teaches: 'Role Diversity: mix of executives, developers, operational roles', 'geographical separation', 'External Parties: at least 1 external to organization'. While not explicitly using the word 'classification', the guidance on role diversity, geographic distribution, and external parties for high-value wallets clearly implies diversity requirements that scale with risk/classification. Baseline met through inference."
+  },
+  {
+    "controlId": "ms-4.1.1",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "secure-multisig-signing-process covers: initiation→approval→simulation→execution→confirmation process (baseline 1 partial), independent transaction verification required (baseline 3), 'All signers must verify transaction data on at least two independent devices' and 'at least two separate communication channels' (baseline 4), 'DELEGATECALL warning' flags high risk operations (baseline 5). Missing: transaction initiation authorization framework (baseline 2), high-risk waiting periods/elevated thresholds (baseline 6), risk threshold definition process (baseline 7), private transaction submission guidance (baseline 8). Gaps correctly identified."
+  },
+  {
+    "controlId": "ms-4.1.3",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "implementation-checklist 'Transaction Verification' mentions approved tools (Safe CLI Utils, OpenZeppelin SafeUtils) implying open source/audited preference, but does NOT teach: (1) formal tool adoption process, (2) vulnerability checking, (3) ecosystem adoption as evaluation criteria. Evaluator correctly identified these gaps."
+  },
+  {
+    "controlId": "ms-4.1.4",
+    "originalCoverage": "full",
+    "qaCoverage": "full",
+    "verdict": "confirmed",
+    "notes": "backup-signing-and-infrastructure comprehensively covers: 'UI Alternatives' section (Eternal Safe, Squads, mobile) for alternate signing UI (baseline 1), 'RPC Backup Options' recommends '2-3 different RPC services' with provider diversity (baseline 2), 'Block Explorer Backup Options' lists Blockscout, explorer.swiss-knife.xyz, Solscan alternatives (baseline 3). All three baselines fully taught."
+  },
+  {
+    "controlId": "ms-5.1.1",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "implementation-checklist teaches: dedicated primary and backup channels, E2E encryption, MFA, invitation-based (baselines 1,2 met). emergency-procedures 'Communication Account Compromise' covers channel compromise procedures and backup channel switching (baseline 4 met). However, does NOT teach: (1) signer identity verification as STANDARD procedure for ALL signing operations (only mentioned for emergencies), (2) annual testing requirement for compromise response. Gaps correctly identified."
+  },
+  {
+    "controlId": "ms-5.1.2",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "emergency-procedures 'Emergency Contact Information' section states 'Protocol leadership, Technical team, Legal/compliance contacts' (baseline 1 partially - covers protocol security, external resources, legal, but not explicit backup contacts for signers). Does NOT mention: (1) personal emergency contacts for each signer (family/colleague for unreachable situations), (2) 6-month review cadence. Gaps correctly identified."
+  },
+  {
+    "controlId": "ms-6.1.1",
+    "originalCoverage": "full",
+    "qaCoverage": "full",
+    "verdict": "confirmed",
+    "notes": "emergency-procedures provides dedicated sections for: 'Key Compromise', 'Lost Key Access', 'Communication Account Compromise', 'Operational Emergency Procedures' (baseline 1 - all scenarios covered). Each scenario has clear procedures and escalation paths (baseline 2). The page teaches using multiple channels and verification methods, implying backup access independent of primary docs (baseline 3). All baselines met."
+  },
+  {
+    "controlId": "ms-6.1.2",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "planning-and-classification 'Operational Classification' table shows: Emergency <2 hours, Time-Sensitive 2-12 hours, Routine 24-48 hours (baseline 1 met). emergency-procedures mentions escalation paths (baseline 4 partially). Does NOT teach: (1) paging system establishment for all signers including external parties, (2) quarterly testing requirement. Gaps correctly identified."
+  },
+  {
+    "controlId": "ms-6.1.3",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "secure-multisig-best-practices 'Active Monitoring' mentions 'signer/threshold changes, proposed transactions, new signatures, owner changes'. setup-and-configuration 'Active Monitoring' mentions same events. However, comprehensive list missing: transfers exceeding thresholds, nonce gaps, interactions with unknown addresses, failed transactions, module/guard changes, low submitter balances (baseline 1 incomplete). Does NOT teach: alerting/escalation documentation (baseline 2), monitoring infrastructure protection (baseline 3). Gaps correctly identified."
+  },
+  {
+    "controlId": "ms-6.1.4",
+    "originalCoverage": "full",
+    "qaCoverage": "full",
+    "verdict": "confirmed",
+    "notes": "emergency-procedures 'Emergency Drill Procedures' section teaches: 'Quarterly: Communication system tests, Bi-annually: Emergency paging tests, Annually: Full emergency simulation' (baseline 1 met - annual minimum, baseline 2 implied by drill updates). 'Drill Components' lists: notification test, response time measurement, process verification, documentation review with 'date, participants, response times, issues identified, improvements made' (baseline 3 fully met). All baselines covered."
+  },
+  {
+    "controlId": "ms-2.1.3",
+    "originalCoverage": "none",
+    "qaCoverage": "none",
+    "verdict": "confirmed",
+    "notes": "FALSE-NEGATIVE CHECK: No framework page teaches exception approval process requiring documented justification, expiry date, compensating controls, remediation plan, or executive/security-lead approval for Critical-class exceptions. Correctly marked as no coverage."
+  },
+  {
+    "controlId": "ms-4.1.2",
+    "originalCoverage": "none",
+    "qaCoverage": "none",
+    "verdict": "confirmed",
+    "notes": "FALSE-NEGATIVE CHECK: No framework page teaches transaction audit trail requirements with 3-year retention, records of proposer, approvers, verification evidence, timestamps, and issues encountered. Correctly marked as no coverage."
+  }
+]
diff --git a/scripts/data/qa-results/sfc-treasury-ops.json b/scripts/data/qa-results/sfc-treasury-ops.json
new file mode 100644
index 00000000..06cdf0ee
--- /dev/null
+++ b/scripts/data/qa-results/sfc-treasury-ops.json
@@ -0,0 +1,149 @@
+[
+  {
+    "controlId": "tro-1.1.2",
+    "originalCoverage": "full",
+    "qaCoverage": "partial",
+    "verdict": "downgraded",
+    "notes": "Registration Template covers baselines 1 (registry fields) and 3 (accessibility), but baseline 2 (update SLAs: 24h for security-critical, 3d for routine) is not addressed. Cannot claim 'full' coverage when a baseline is missed. Should be 'partial'."
+  },
+  {
+    "controlId": "tro-1.1.3",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "MPC for Large Holdings section documents custody models (baseline 1) but lacks explicit discussion of technology trade-offs understood by team (baseline 2) or review triggers when treasury size/needs change (baseline 3). Partial coverage is accurate."
+  },
+  {
+    "controlId": "tro-1.1.4",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Access Change Template correctly covers baselines 2 (documented approval) and 3 (logging with justification/approver). Missing baselines 1 (scope of wallet setups/configurations/protocol integrations), 4 (SLA for registry updates), and 5 (rollback procedures). Partial is correct."
+  },
+  {
+    "controlId": "tro-2.1.1",
+    "originalCoverage": "full",
+    "qaCoverage": "full",
+    "verdict": "confirmed",
+    "notes": "Classification page comprehensively covers all 5 baselines: financial/operational/regulatory considerations (1), impact levels with percentage thresholds (2), operational types by frequency/urgency (3), control mapping matrix (4), and review triggers for significant changes (5). Full coverage confirmed."
+  },
+  {
+    "controlId": "tro-3.1.1",
+    "originalCoverage": "full",
+    "qaCoverage": "partial",
+    "verdict": "downgraded",
+    "notes": "Enhanced-controls page covers baselines 1-5 (transaction policies, hardware MFA, session controls, network restrictions, separation of duties) but baseline 6 (quarterly review of configurations) is not mentioned in this section. Cannot be 'full' with a missing baseline. Registration-documents template IS full coverage (all 6 baselines met via Security Config + Quarterly Review templates)."
+  },
+  {
+    "controlId": "tro-3.1.2",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Enhanced-controls partially covers storage (2) and isolation (3). Seed-phrase-management addresses secure storage (2) but focuses on seeds, not general credentials. Missing across both pages: comprehensive credential type coverage (1), rotation schedules (4), and access logging/monitoring (5). Partial is accurate."
+  },
+  {
+    "controlId": "tro-3.1.3",
+    "originalCoverage": "full",
+    "qaCoverage": "full",
+    "verdict": "confirmed",
+    "notes": "Quarterly Review Template clearly addresses all 3 baselines: quarterly cadence for High/Critical accounts (1), verification that users still require access (2), and actions for access removal when roles change (3). Full coverage confirmed."
+  },
+  {
+    "controlId": "tro-3.1.4",
+    "originalCoverage": "full",
+    "qaCoverage": "partial",
+    "verdict": "downgraded",
+    "notes": "Enhanced-controls Device Security covers baselines 1 (device requirements), 4 (VPN mandatory), 6 (mobile endpoint monitoring) but misses 2 (signing device storage), 3 (backup materials geographic distribution), 5 (travel procedures). Personal-security-opsec covers 1, 2, 5 well but doesn't explicitly address 6 (mobile endpoint monitoring). No single page has full coverage. Seed-phrase-management covers baseline 3. Combined partial coverage across pages."
+  },
+  {
+    "controlId": "tro-4.1.1",
+    "originalCoverage": "full",
+    "qaCoverage": "partial",
+    "verdict": "downgraded",
+    "notes": "Transaction-verification page excellently covers baselines 1-5, 7-8 (pre-execution verification, test transactions, multi-source address verification, multi-party confirmation, receiving procedures, video verification with liveness, read-aloud confirmation). However, baseline 6 (specific OTC transaction procedures) is not addressed. Should be partial, not full."
+  },
+  {
+    "controlId": "tro-4.1.2",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Implementation-checklist covers knowledge areas (transaction verification, address validation, social engineering, emergency procedures - baseline 1) and competence demonstration via test transactions (baseline 2). Refresher schedule mentions annual review but not explicit '30-day update after significant changes' (baseline 3 partially met). Baseline 4 (custody-platform-specific workflows/policy engine rules) not explicitly addressed. Partial is accurate."
+  },
+  {
+    "controlId": "tro-4.1.3",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Emergency-procedures Communication Account Compromise section covers identity verification during operations (3), anti-social-engineering protocols (4), and channel compromise procedures (5). Missing: dedicated primary/backup channels on different platforms (1), E2E encryption/MFA requirements (2), and training/testing requirements (6). Partial coverage is correct."
+  },
+  {
+    "controlId": "tro-5.1.2",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Transaction-verification page addresses baseline 1 (smart contract address verification for ERC-20 tokens, mentions token approvals in DeFi context). Baselines 2-4 (emergency exit procedures, alternative access methods for positions, unbonding timelines) are not covered. Partial is accurate."
+  },
+  {
+    "controlId": "tro-6.1.1",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Enhanced-controls Security Monitoring section covers transaction monitoring (1), account state monitoring (2), alerting with severity levels (7), and critical alert response (8). Missing: external threat intelligence (3), vendor/platform monitoring (4), compliance monitoring (5), protocol/position monitoring (6), and monitoring system integrity protection (9). Partial coverage accurate."
+  },
+  {
+    "controlId": "tro-6.1.2",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "upgraded",
+    "notes": "Emergency-procedures page covers severity levels (1), containment procedures (2), key scenarios including custody/transaction/key/vendor compromise (3), emergency contacts (4), AND includes Emergency Drill Procedures section with quarterly/annual drill schedule (6) and drill documentation requirements (7). Evaluator missed baselines 6-7. Only baseline 5 (stakeholder communication plan) is not fully addressed. Should recognize more coverage than originally claimed."
+  },
+  {
+    "controlId": "tro-7.1.2",
+    "originalCoverage": "full",
+    "qaCoverage": "full",
+    "verdict": "confirmed",
+    "notes": "Backup-signing-and-infrastructure page comprehensively covers all 4 baselines: UI alternatives documented (Eternal Safe, Squads, mobile) with setup instructions (1), RPC backup options section (2), entire page focused on operating with backup systems (3), and testing requirements including monthly practice and annual simulation (4). Full coverage confirmed."
+  },
+  {
+    "controlId": "tro-8.1.1",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Registration-documents templates provide some transaction tracking structure (Quarterly Review has transaction volume section), but comprehensive recordkeeping with categorization/documentation/authorization chain (1), reconciliation procedures (2), frequency scaling by classification (3), discrepancy resolution (4), and reporting procedures (5) are not adequately covered. Partial is accurate though even baseline 1 is only weakly met."
+  },
+  {
+    "controlId": "tro-1.1.1",
+    "originalCoverage": "none",
+    "qaCoverage": "none",
+    "verdict": "confirmed",
+    "notes": "No framework page addresses Treasury Operations Owner designation with accountability scope covering policy upkeep, security reviews, operational hygiene, access control oversight, and incident escalation. Correctly marked as no coverage."
+  },
+  {
+    "controlId": "tro-2.1.2",
+    "originalCoverage": "none",
+    "qaCoverage": "none",
+    "verdict": "confirmed",
+    "notes": "Classification page discusses account-level controls and transaction limits, but does not address portfolio-level fund allocation limits (max per wallet/provider/chain) or rebalancing triggers. Enhanced-controls discusses transaction limits, not allocation limits. Correctly marked as no coverage."
+  },
+  {
+    "controlId": "tro-5.1.1",
+    "originalCoverage": "none",
+    "qaCoverage": "none",
+    "verdict": "confirmed",
+    "notes": "Transaction-verification mentions verifying contract addresses, but does not cover protocol evaluation due diligence (audit status, team reputation, TVL history, insurance) or exposure limits per protocol/chain/category. Correctly marked as no coverage."
+  },
+  {
+    "controlId": "tro-7.1.1",
+    "originalCoverage": "none",
+    "qaCoverage": "none",
+    "verdict": "confirmed",
+    "notes": "Pages discuss custody platforms and security features, but do not address vendor security management processes: initial due diligence (SOC 2, ISO 27001, audit history, insurance), ongoing monitoring (SOC reports, incident notifications, availability tracking), or contractual security requirement verification. Correctly marked as no coverage."
+  },
+  {
+    "controlId": "tro-8.1.2",
+    "originalCoverage": "none",
+    "qaCoverage": "none",
+    "verdict": "confirmed",
+    "notes": "No framework page addresses insurance coverage for treasury assets (scope documentation, coverage amounts relative to assets, custody provider insurance evaluation). Correctly marked as no coverage."
+  }
+]
diff --git a/scripts/data/qa-results/sfc-workspace-security.json b/scripts/data/qa-results/sfc-workspace-security.json
new file mode 100644
index 00000000..1effc0fe
--- /dev/null
+++ b/scripts/data/qa-results/sfc-workspace-security.json
@@ -0,0 +1,163 @@
+[
+  {
+    "controlId": "ws-1.1.1",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Page discusses establishing ownership for monitoring domains and continuous visibility practices, but does not cover the full scope of workspace security ownership including policy maintenance, device/account standards, access control oversight, periodic reviews, and incident escalation. Partial coverage is accurate."
+  },
+  {
+    "controlId": "ws-1.1.3",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Page covers general asset discovery, classification, and assignment of owners. However, it lacks specific device inventory tracking details (make/model, OS version, encryption status, EDR/MDM enrollment), account inventory with ownership, and automated updates during provisioning/decommissioning. Gaps correctly identified."
+  },
+  {
+    "controlId": "ws-1.1.4",
+    "originalCoverage": "full",
+    "qaCoverage": "full",
+    "verdict": "confirmed",
+    "notes": "Both pages provide comprehensive coverage: Security Fundamentals defines clear classification levels (Public/Internal/Confidential/Restricted) with handling procedures for each level; Implementation Process defines classification categories and trigger events for reassessment. All three baselines met."
+  },
+  {
+    "controlId": "ws-2.1.1",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Travel guide covers full disk encryption, updates, and strong passwords. Encryption pages cover encryption guidance. However, none address automatic patching enforcement, administrative privilege separation, supply chain verification, compliance monitoring, or BYOD policy. All three refs correctly marked partial with appropriate gaps."
+  },
+  {
+    "controlId": "ws-2.1.2",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Travel guide mentions remote wipe capability (Find My, MDM) and basic procedures for lost devices. Physical-Environmental covers secure disposal. However, documented procedures for credential rotation after loss and incident escalation are not covered. Gaps correctly identified."
+  },
+  {
+    "controlId": "ws-2.1.3",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Travel guide only covers basic anti-malware scanning and looking for unusual behavior - this is post-travel cleanup, not enterprise-wide EDR/MDM deployment with alert triage, compliance enforcement, and comprehensive monitoring. Correctly marked partial with all major gaps identified."
+  },
+  {
+    "controlId": "ws-2.1.4",
+    "originalCoverage": "full",
+    "qaCoverage": "full",
+    "verdict": "confirmed",
+    "notes": "Travel guide extensively covers screen privacy, travel procedures, high-risk travel procedures, USB security, and physical device security. Physical-Environmental covers workspace requirements and access controls. Together, these pages provide comprehensive coverage of all six baselines."
+  },
+  {
+    "controlId": "ws-3.1.1",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Discord guide only covers reviewing existing role permissions and removing unnecessary members - this is maintenance, not lifecycle management. Missing account creation approval, least privilege provisioning, modification approval, offboarding procedures, and service account inventory. Gaps correctly identified."
+  },
+  {
+    "controlId": "ws-3.1.2",
+    "originalCoverage": "full",
+    "qaCoverage": "partial",
+    "verdict": "downgraded",
+    "notes": "Technical controls page covers MFA for all sensitive systems, hardware keys for high-privilege accounts, backup methods, and phishing-resistant MFA. However, it does NOT cover baseline 4: exceptions documented with justification, compensating controls, and expiry date. With 1 of 5 baselines missing, this should be partial, not full. The evaluator was inconsistent - they marked it full but then acknowledged this gap."
+  },
+  {
+    "controlId": "ws-3.1.3",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Discord guide covers security configuration standards for Discord specifically and ownership verification through admin reviews. However, it doesn't address enterprise platforms broadly (Google Workspace, Microsoft 365), social media accounts, recovery methods restricted to organizational channels, or periodic review for drift. Correctly marked partial."
+  },
+  {
+    "controlId": "ws-3.1.4",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "All three pages touch on limited aspects: travel guide mentions password managers, awareness page covers strong/unique passwords and password managers, Telegram guide mentions unique passwords. None cover the full scope including: password manager requirement for all personnel, no sharing of credentials, encrypted transmission channels, rotation schedules, enhanced controls for high-privilege, or service account inventory. Extensive gaps correctly identified."
+  },
+  {
+    "controlId": "ws-3.1.5",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Security Fundamentals covers scheduled reviews (quarterly/annually) and verifying current access needs. Discord guide covers periodic permission reviews with tracking. However, missing: access adjustment procedures when roles change, documented evidence of revocations, and insider threat damage scenario assessment during reviews. Gaps correctly identified."
+  },
+  {
+    "controlId": "ws-4.1.1",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Travel guide only mentions using privacy-focused tools (Hide My Email, Tuta, ProtonMail) for travel privacy - this is not a software evaluation and approval process. Missing evaluation criteria, data privacy risk assessment, approved software list, browser extension approval, and dependency management. All major gaps correctly identified."
+  },
+  {
+    "controlId": "ws-4.1.2",
+    "originalCoverage": "full",
+    "qaCoverage": "full",
+    "verdict": "confirmed",
+    "notes": "GitHub guide comprehensively covers all five baselines: role-based access control (collaborators/teams review), branch protection rules with required approvals, automated secret scanning enabled, push protection for secrets (pre-commit checks), and periodic security audits (sessions, SSH keys, webhooks review). Full coverage is accurate."
+  },
+  {
+    "controlId": "ws-5.1.1",
+    "originalCoverage": "full",
+    "qaCoverage": "partial",
+    "verdict": "downgraded",
+    "notes": "Travel guide covers VPN/cellular preference, Wi-Fi security standards (disable auto-connect, avoid public Wi-Fi), and cellular/hotspot over public Wi-Fi. However, it does NOT cover network segmentation (baseline 3). With 1 of 4 baselines missing, this should be partial, not full. The Technical page does cover network segmentation and should remain full."
+  },
+  {
+    "controlId": "ws-5.1.2",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "All three pages provide limited coverage: travel guide mentions safe words and deepfake awareness, Telegram covers secret chats and identity verification, Technical covers encrypted communications. However, none comprehensively address anti-impersonation protocols, email security (SPF/DKIM/DMARC), or procedures for channel compromise. Gaps correctly identified."
+  },
+  {
+    "controlId": "ws-6.1.1",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "People controls page covers pre-employment screening, security agreements, and security responsibilities in job descriptions (baselines 1, 2, partial 4). However, it does not cover the detailed security onboarding process including device provisioning, account creation, MFA setup, initial training, policy acknowledgment before access, or a documented onboarding checklist. Gaps correctly identified."
+  },
+  {
+    "controlId": "ws-6.1.2",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "None of these pages actually provide comprehensive offboarding procedures. Travel guide covers remote wipe for lost devices (not offboarding), threat vectors covers general insider threat awareness (not procedures), Discord covers removing role members (not a complete offboarding process). All five baselines are largely unmet: 24-hour revocation, device return/sanitization, credential rotation, documented checklist, involuntary departure procedures. Correctly marked partial but these pages provide minimal coverage at best."
+  },
+  {
+    "controlId": "ws-6.1.3",
+    "originalCoverage": "full",
+    "qaCoverage": "partial",
+    "verdict": "downgraded",
+    "notes": "Staying Informed page covers training topics (phishing, social engineering, device security, credential hygiene, incident reporting), annual updates, and crypto-specific risks (fake job offers, malicious extensions, clipboard hijacking). However, it does NOT cover phishing simulations conducted quarterly or follow-up training for those who fail simulations (baselines 2 and 3). With 2 of 5 baselines missing, this should be partial, not full."
+  },
+  {
+    "controlId": "ws-7.1.1",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Security Fundamentals covers general monitoring strategy, incident management process, and post-incident reviews, but not specifically workspace threats (account takeovers, unauthorized access, credential leaks, device compromise, data exfiltration) or credential leak monitoring. Case Studies covers incident response scenarios and tabletop exercises but not ongoing monitoring. Both correctly marked partial with appropriate gaps."
+  },
+  {
+    "controlId": "ws-7.1.2",
+    "originalCoverage": "full",
+    "qaCoverage": "partial",
+    "verdict": "downgraded",
+    "notes": "Minimal Access Scopes page covers least-privilege access enforcement (baseline 2 only). Insider-Threat Mitigation page covers least-privilege and monitoring, but does NOT explicitly cover damage scenarios documented for each role (baseline 1) or separation of duties for critical operations (baseline 3). With only 1 of 4 baselines fully met, this should be partial, not full."
+  },
+  {
+    "controlId": "ws-7.1.3",
+    "originalCoverage": "partial",
+    "qaCoverage": "partial",
+    "verdict": "confirmed",
+    "notes": "Both pages only touch on minimum necessary permissions and time-based access. Neither covers documented approval with scope/expiry, automatic revocation upon contract end, audit trails for third-party access, or vendor security evaluation before granting access. All major gaps correctly identified."
+  },
+  {
+    "controlId": "ws-1.1.2",
+    "originalCoverage": "none",
+    "qaCoverage": "none",
+    "verdict": "confirmed",
+    "notes": "FALSE-NEGATIVE CHECK: Reviewed all 15 framework pages. None specifically address creating, maintaining, or reviewing a workspace security policy document. While various pages cover security practices, none address the policy artifact itself covering core expectations, plain language requirements, or annual review procedures. No coverage confirmed."
+  }
+]
diff --git a/scripts/extract-cert-framework-data.mjs b/scripts/extract-cert-framework-data.mjs
new file mode 100644
index 00000000..0b213233
--- /dev/null
+++ b/scripts/extract-cert-framework-data.mjs
@@ -0,0 +1,155 @@
+#!/usr/bin/env node
+/**
+ * Extract structured data from cert MDX files and framework pages.
+ * Outputs two JSON files:
+ *   - cert-controls.json: all controls with baselines from 6 cert files
+ *   - framework-pages.json: all framework pages with titles and headers
+ */
+
+import { readFileSync, writeFileSync, readdirSync, statSync } from 'fs';
+import { join, relative, basename } from 'path';
+import { load } from 'js-yaml';
+
+const REPO_ROOT = join(import.meta.dirname, '..');
+const CERTS_DIR = join(REPO_ROOT, 'docs', 'pages', 'certs');
+const PAGES_DIR = join(REPO_ROOT, 'docs', 'pages');
+const OUT_DIR = join(REPO_ROOT, 'scripts', 'data');
+
+// ── Extract cert controls ──────────────────────────────────────────
+function extractCertControls() {
+  const certFiles = readdirSync(CERTS_DIR)
+    .filter(f => f.startsWith('sfc-') && f.endsWith('.mdx'))
+    .sort();
+
+  const certs = [];
+
+  for (const file of certFiles) {
+    const content = readFileSync(join(CERTS_DIR, file), 'utf-8');
+    const certName = basename(file, '.mdx');
+
+    // Extract YAML frontmatter
+    const fmMatch = content.match(/^---\n([\s\S]*?)\n---/);
+    if (!fmMatch) {
+      console.warn(`No frontmatter in ${file}`);
+      continue;
+    }
+
+    const fm = load(fmMatch[1]);
+    if (!fm.cert) {
+      console.warn(`No cert data in ${file}`);
+      continue;
+    }
+
+    const sections = fm.cert.map(section => ({
+      id: section.id,
+      title: section.title,
+      controls: section.controls.map(ctrl => ({
+        id: ctrl.id,
+        title: ctrl.title,
+        description: ctrl.description,
+        baselines: ctrl.baselines || [],
+      })),
+    }));
+
+    const totalControls = sections.reduce((sum, s) => sum + s.controls.length, 0);
+
+    certs.push({
+      name: certName,
+      title: fm.title,
+      sections,
+      totalControls,
+    });
+
+    console.log(`  ${certName}: ${sections.length} sections, ${totalControls} controls`);
+  }
+
+  return certs;
+}
+
+// ── Extract framework pages ────────────────────────────────────────
+function extractFrameworkPages() {
+  const pages = [];
+
+  function walk(dir) {
+    for (const entry of readdirSync(dir)) {
+      const fullPath = join(dir, entry);
+      const stat = statSync(fullPath);
+
+      if (stat.isDirectory()) {
+        // Skip certs and config dirs
+        const rel = relative(PAGES_DIR, fullPath);
+        if (rel.startsWith('certs') || rel.startsWith('config')) continue;
+        walk(fullPath);
+      } else if (entry.endsWith('.mdx') && entry !== 'index.mdx') {
+        const content = readFileSync(fullPath, 'utf-8');
+        const relPath = '/' + relative(PAGES_DIR, fullPath).replace(/\.mdx$/, '');
+
+        // Extract title from frontmatter
+        let title = '';
+        const fmMatch = content.match(/^---\n([\s\S]*?)\n---/);
+        if (fmMatch) {
+          try {
+            const fm = load(fmMatch[1]);
+            title = fm.title || '';
+          } catch {
+            // Some MDX has JSX in frontmatter
+          }
+        }
+
+        // Extract ## headers (h2 and h3)
+        const headers = [];
+        const headerRegex = /^(#{2,3})\s+(.+)$/gm;
+        let match;
+        while ((match = headerRegex.exec(content)) !== null) {
+          const text = match[2].trim();
+          // Skip JSX/component headers
+          if (text.startsWith('<') || text.startsWith('{')) continue;
+          headers.push({
+            level: match[1].length,
+            text,
+            anchor: text.toLowerCase().replace(/[^\w\s-]/g, '').replace(/\s+/g, '-'),
+          });
+        }
+
+        // Get the domain (first directory)
+        const domain = relPath.split('/')[1] || '';
+
+        pages.push({
+          path: relPath,
+          title: title.replace(/\s*\|\s*Security Alliance$/i, '').trim(),
+          domain,
+          headers,
+          lineCount: content.split('\n').length,
+        });
+      }
+    }
+  }
+
+  walk(PAGES_DIR);
+  pages.sort((a, b) => a.path.localeCompare(b.path));
+  return pages;
+}
+
+// ── Main ───────────────────────────────────────────────────────────
+import { mkdirSync } from 'fs';
+mkdirSync(OUT_DIR, { recursive: true });
+
+console.log('Extracting cert controls...');
+const certs = extractCertControls();
+writeFileSync(join(OUT_DIR, 'cert-controls.json'), JSON.stringify(certs, null, 2));
+console.log(`\nTotal: ${certs.reduce((s, c) => s + c.totalControls, 0)} controls across ${certs.length} certs\n`);
+
+console.log('Extracting framework pages...');
+const pages = extractFrameworkPages();
+writeFileSync(join(OUT_DIR, 'framework-pages.json'), JSON.stringify(pages, null, 2));
+
+// Group by domain for quick reference
+const domains = {};
+for (const p of pages) {
+  if (!domains[p.domain]) domains[p.domain] = [];
+  domains[p.domain].push(p.path);
+}
+console.log(`\nTotal: ${pages.length} pages across ${Object.keys(domains).length} domains\n`);
+for (const [domain, paths] of Object.entries(domains).sort()) {
+  console.log(`  ${domain}: ${paths.length} pages`);
+}
diff --git a/scripts/generate-eval-briefs.mjs b/scripts/generate-eval-briefs.mjs
new file mode 100644
index 00000000..f0fd2b6d
--- /dev/null
+++ b/scripts/generate-eval-briefs.mjs
@@ -0,0 +1,87 @@
+#!/usr/bin/env node
+/**
+ * Generate focused evaluation briefs per cert.
+ * Each brief contains: cert controls + baselines + ONLY the content of their top candidate pages.
+ * Much smaller than the domain-wide briefs — typically 30-80KB.
+ */
+
+import { readFileSync, writeFileSync, mkdirSync } from 'fs';
+import { join } from 'path';
+
+const REPO_ROOT = join(import.meta.dirname, '..');
+const DATA_DIR = join(REPO_ROOT, 'scripts', 'data');
+const MAPPINGS_DIR = join(DATA_DIR, 'mappings');
+const BRIEFS_DIR = join(DATA_DIR, 'eval-briefs');
+const PAGES_DIR = join(REPO_ROOT, 'docs', 'pages');
+
+mkdirSync(BRIEFS_DIR, { recursive: true });
+
+const certFiles = ['sfc-devops-infrastructure', 'sfc-dns-registrar', 'sfc-incident-response',
+  'sfc-multisig-ops', 'sfc-treasury-ops', 'sfc-workspace-security'];
+
+for (const certName of certFiles) {
+  const mapping = JSON.parse(readFileSync(join(MAPPINGS_DIR, `${certName}.json`), 'utf-8'));
+  
+  // Collect unique candidate pages (top 3 per control)
+  const uniquePages = new Map();
+  for (const ctrl of mapping) {
+    for (const cand of ctrl.candidates.slice(0, 3)) {
+      if (!uniquePages.has(cand.page)) {
+        uniquePages.set(cand.page, { title: cand.title, controls: [] });
+      }
+      uniquePages.get(cand.page).controls.push(ctrl.controlId);
+    }
+  }
+  
+  // Build brief
+  let brief = `# Evaluation Brief: ${certName}\n\n`;
+  brief += `## TASK\n\n`;
+  brief += `For each control below, evaluate whether the candidate framework pages ACTUALLY meet the baseline requirements.\n`;
+  brief += `A page must SUBSTANTIVELY address the baseline — not just mention related keywords.\n`;
+  brief += `Be strict: if a baseline says "reviewed at least annually" and the page doesn't mention review cadence, that baseline is NOT met.\n\n`;
+  brief += `## CONTROLS (${mapping.length} total)\n\n`;
+  
+  for (const ctrl of mapping) {
+    brief += `### ${ctrl.controlId}: ${ctrl.controlTitle}\n`;
+    brief += `**Question:** ${ctrl.description}\n`;
+    brief += `**Baselines (${ctrl.baselines.length}):**\n`;
+    ctrl.baselines.forEach((b, i) => {
+      brief += `  ${i + 1}. ${b}\n`;
+    });
+    brief += `**Candidate pages:** ${ctrl.candidates.slice(0, 3).map(c => c.page).join(', ')}\n\n`;
+  }
+  
+  brief += `---\n\n## FRAMEWORK PAGES (${uniquePages.size} unique)\n\n`;
+  
+  for (const [pagePath, info] of uniquePages) {
+    const filePath = join(PAGES_DIR, pagePath.slice(1) + '.mdx');
+    let content;
+    try {
+      content = readFileSync(filePath, 'utf-8');
+    } catch {
+      brief += `### PAGE: ${pagePath}\n**Could not read file**\n\n---\n\n`;
+      continue;
+    }
+    
+    // Strip frontmatter, imports, JSX tags
+    content = content.replace(/^---\n[\s\S]*?\n---\n/, '');
+    content = content.replace(/^import\s+.*$/gm, '');
+    content = content.replace(/^<(TagProvider|TagFilter|TagList|AttributionList|ContributeFooter|\/TagProvider)[^>]*>.*$/gm, '');
+    content = content.trim();
+    
+    // Truncate very long pages
+    const lines = content.split('\n');
+    if (lines.length > 400) {
+      content = lines.slice(0, 400).join('\n') + '\n\n[... truncated ...]';
+    }
+    
+    brief += `### PAGE: ${pagePath}\n`;
+    brief += `**Title:** ${info.title}\n`;
+    brief += `**Referenced by controls:** ${info.controls.join(', ')}\n\n`;
+    brief += content + '\n\n---\n\n';
+  }
+  
+  writeFileSync(join(BRIEFS_DIR, `${certName}.md`), brief);
+  const sizeKB = Math.round(brief.length / 1024);
+  console.log(`${certName}: ${mapping.length} controls, ${uniquePages.size} pages, ${sizeKB}KB`);
+}
diff --git a/scripts/generate-mapping-briefs.mjs b/scripts/generate-mapping-briefs.mjs
new file mode 100644
index 00000000..32899c0c
--- /dev/null
+++ b/scripts/generate-mapping-briefs.mjs
@@ -0,0 +1,97 @@
+#!/usr/bin/env node
+/**
+ * Generate mapping briefs for each cert.
+ * Each brief contains: cert controls + full text of candidate framework pages.
+ * Output: scripts/data/briefs/<cert-name>.md
+ */
+
+import { readFileSync, writeFileSync, mkdirSync } from 'fs';
+import { join } from 'path';
+
+const REPO_ROOT = join(import.meta.dirname, '..');
+const DATA_DIR = join(REPO_ROOT, 'scripts', 'data');
+const BRIEFS_DIR = join(DATA_DIR, 'briefs');
+const PAGES_DIR = join(REPO_ROOT, 'docs', 'pages');
+
+mkdirSync(BRIEFS_DIR, { recursive: true });
+
+const certs = JSON.parse(readFileSync(join(DATA_DIR, 'cert-controls.json'), 'utf-8'));
+const pages = JSON.parse(readFileSync(join(DATA_DIR, 'framework-pages.json'), 'utf-8'))
+  .filter(p => !p.path.includes('/old/'));
+
+// Domain mapping
+const domainMap = {
+  'sfc-workspace-security': ['opsec', 'encryption', 'privacy', 'user-team-security', 'guides', 'iam', 'awareness', 'dprk-it-workers'],
+  'sfc-dns-registrar': ['opsec', 'infrastructure', 'community-management', 'front-end-web-app', 'monitoring', 'devsecops'],
+  'sfc-devops-infrastructure': ['devsecops', 'supply-chain', 'security-automation', 'secure-software-development', 'infrastructure', 'security-testing', 'monitoring'],
+  'sfc-incident-response': ['incident-management', 'governance', 'monitoring', 'security-automation', 'multisig-for-protocols', 'wallet-security', 'infrastructure'],
+  'sfc-multisig-ops': ['multisig-for-protocols', 'wallet-security', 'opsec', 'governance', 'incident-management'],
+  'sfc-treasury-ops': ['treasury-operations', 'wallet-security', 'governance', 'multisig-for-protocols', 'monitoring', 'incident-management', 'devsecops'],
+};
+
+for (const cert of certs) {
+  const domains = domainMap[cert.name];
+  if (!domains) { console.warn(`No domain map for ${cert.name}`); continue; }
+
+  const candidatePages = pages.filter(p => domains.includes(p.domain));
+
+  let brief = `# Mapping Brief: ${cert.name}\n\n`;
+  brief += `## CERT CONTROLS (${cert.totalControls} controls)\n\n`;
+
+  for (const section of cert.sections) {
+    brief += `### Section: ${section.id} — ${section.title}\n\n`;
+    for (const ctrl of section.controls) {
+      brief += `#### ${ctrl.id}: ${ctrl.title}\n`;
+      brief += `**Question:** ${ctrl.description}\n`;
+      if (ctrl.baselines.length > 0) {
+        brief += `**Baselines:**\n`;
+        for (const b of ctrl.baselines) {
+          brief += `- ${b}\n`;
+        }
+      }
+      brief += '\n';
+    }
+  }
+
+  brief += `---\n\n## CANDIDATE FRAMEWORK PAGES (${candidatePages.length} pages)\n\n`;
+
+  let totalChars = 0;
+  for (const page of candidatePages) {
+    const filePath = join(PAGES_DIR, page.path.slice(1) + '.mdx');
+    let content;
+    try {
+      content = readFileSync(filePath, 'utf-8');
+    } catch {
+      console.warn(`  Could not read ${filePath}`);
+      continue;
+    }
+
+    // Strip frontmatter and imports for cleaner reading
+    content = content.replace(/^---\n[\s\S]*?\n---\n/, '');
+    content = content.replace(/^import\s+.*$/gm, '');
+    content = content.replace(/^<TagProvider>.*$/gm, '');
+    content = content.replace(/^<TagFilter\s*\/>.*$/gm, '');
+    content = content.replace(/^<TagList\s+.*$/gm, '');
+    content = content.replace(/^<AttributionList\s+.*$/gm, '');
+    content = content.replace(/^<\/TagProvider>.*$/gm, '');
+    content = content.replace(/^<ContributeFooter\s*\/>.*$/gm, '');
+    content = content.trim();
+
+    // Truncate very long pages to ~300 lines (keep structure, cut detail)
+    const lines = content.split('\n');
+    if (lines.length > 300) {
+      content = lines.slice(0, 300).join('\n') + '\n\n[... truncated, ' + (lines.length - 300) + ' more lines ...]';
+    }
+
+    brief += `### PAGE: ${page.path}\n`;
+    brief += `**Title:** ${page.title}\n`;
+    brief += `**Headers:** ${page.headers.map(h => h.text).join(' | ')}\n\n`;
+    brief += content + '\n\n---\n\n';
+    totalChars += content.length;
+  }
+
+  writeFileSync(join(BRIEFS_DIR, `${cert.name}.md`), brief);
+  const sizeKB = Math.round(brief.length / 1024);
+  const estTokens = Math.round(brief.length / 4);
+  console.log(`${cert.name}: ${candidatePages.length} pages, ${sizeKB}KB, ~${estTokens} tokens`);
+}
diff --git a/scripts/generate-qa-briefs.mjs b/scripts/generate-qa-briefs.mjs
new file mode 100644
index 00000000..2a17b9c3
--- /dev/null
+++ b/scripts/generate-qa-briefs.mjs
@@ -0,0 +1,124 @@
+#!/usr/bin/env node
+/**
+ * Generate QA briefs. For each cert, include:
+ * - The eval results (claims to verify)
+ * - The actual page content for every referenced page
+ * - The control baselines
+ * QA agent checks: are the coverage claims accurate?
+ */
+
+import { readFileSync, writeFileSync, mkdirSync, readdirSync } from 'fs';
+import { join } from 'path';
+
+const REPO_ROOT = join(import.meta.dirname, '..');
+const EVAL_DIR = join(REPO_ROOT, 'scripts', 'data', 'eval-results');
+const QA_DIR = join(REPO_ROOT, 'scripts', 'data', 'qa-briefs');
+const PAGES_DIR = join(REPO_ROOT, 'docs', 'pages');
+const CERTS_DIR = join(REPO_ROOT, 'docs', 'pages', 'certs');
+
+import { load } from 'js-yaml';
+
+mkdirSync(QA_DIR, { recursive: true });
+
+const evalFiles = readdirSync(EVAL_DIR).filter(f => f.endsWith('.json')).sort();
+
+for (const file of evalFiles) {
+  const certName = file.replace('.json', '');
+  const evals = JSON.parse(readFileSync(join(EVAL_DIR, file), 'utf-8'));
+  
+  // Load original cert controls for full baselines
+  const certFile = join(CERTS_DIR, `${certName}.mdx`);
+  const certContent = readFileSync(certFile, 'utf-8');
+  const fmMatch = certContent.match(/^---\n([\s\S]*?)\n---/);
+  const fm = load(fmMatch[1]);
+  
+  const baselineMap = {};
+  for (const section of fm.cert) {
+    for (const ctrl of section.controls) {
+      baselineMap[ctrl.id] = {
+        title: ctrl.title,
+        description: ctrl.description,
+        baselines: ctrl.baselines || [],
+      };
+    }
+  }
+  
+  // Collect all referenced pages
+  const referencedPages = new Set();
+  const controlsToQA = [];
+  
+  for (const ctrl of evals) {
+    if (ctrl.refs.length > 0) {
+      controlsToQA.push(ctrl);
+      for (const ref of ctrl.refs) {
+        referencedPages.add(ref.page);
+      }
+    }
+  }
+  
+  // Also include a sample of "no coverage" controls for false-negative check
+  const noCoverage = evals.filter(c => c.refs.length === 0);
+  
+  let brief = `# QA Brief: ${certName}\n\n`;
+  brief += `## YOUR TASK\n\n`;
+  brief += `Verify the evaluation claims below. For each control with refs:\n`;
+  brief += `1. Read the ACTUAL page content (provided below)\n`;
+  brief += `2. Read the control's FULL baselines\n`;
+  brief += `3. Check: does the page ACTUALLY meet the baselines claimed in "baselinesMet"?\n`;
+  brief += `4. Check: are the "baselinesMissed" correct (is there content that was overlooked)?\n`;
+  brief += `5. Check: is the coverage rating ("full"/"partial") justified?\n\n`;
+  brief += `Be STRICT. If the evaluator was too generous, downgrade. If they missed coverage, upgrade.\n\n`;
+  
+  brief += `## EVALUATION CLAIMS TO VERIFY (${controlsToQA.length} controls with refs)\n\n`;
+  
+  for (const ctrl of controlsToQA) {
+    const orig = baselineMap[ctrl.controlId];
+    brief += `### ${ctrl.controlId}: ${ctrl.controlTitle}\n`;
+    brief += `**Full baselines:**\n`;
+    orig.baselines.forEach((b, i) => { brief += `  ${i+1}. ${b}\n`; });
+    brief += `\n**Evaluator's assessment:**\n`;
+    for (const ref of ctrl.refs) {
+      brief += `- **${ref.page}** ${ref.header ? `→ ${ref.header}` : ''} — **${ref.coverage}**\n`;
+      if (ref.baselinesMet?.length) brief += `  Met: ${ref.baselinesMet.join('; ')}\n`;
+      if (ref.baselinesMissed?.length) brief += `  Missed: ${ref.baselinesMissed.join('; ')}\n`;
+    }
+    if (ctrl.gaps.length) {
+      brief += `**Gaps:** ${ctrl.gaps.join('; ')}\n`;
+    }
+    brief += '\n';
+  }
+  
+  if (noCoverage.length > 0) {
+    brief += `## FALSE-NEGATIVE CHECK (${noCoverage.length} controls marked "no coverage")\n\n`;
+    brief += `Verify these truly have no relevant framework page. If any page below partially covers them, note it.\n\n`;
+    for (const ctrl of noCoverage) {
+      const orig = baselineMap[ctrl.controlId];
+      brief += `### ${ctrl.controlId}: ${ctrl.controlTitle}\n`;
+      brief += `**Baselines:** ${orig.baselines.slice(0, 3).join('; ')}${orig.baselines.length > 3 ? ` (+${orig.baselines.length - 3} more)` : ''}\n\n`;
+    }
+  }
+  
+  brief += `---\n\n## FRAMEWORK PAGES (${referencedPages.size} pages)\n\n`;
+  
+  for (const pagePath of [...referencedPages].sort()) {
+    const filePath = join(PAGES_DIR, pagePath.slice(1) + '.mdx');
+    let content;
+    try { content = readFileSync(filePath, 'utf-8'); } catch { continue; }
+    
+    content = content.replace(/^---\n[\s\S]*?\n---\n/, '');
+    content = content.replace(/^import\s+.*$/gm, '');
+    content = content.replace(/^<(TagProvider|TagFilter|TagList|AttributionList|ContributeFooter|\/TagProvider)[^>]*>.*$/gm, '');
+    content = content.trim();
+    
+    const lines = content.split('\n');
+    if (lines.length > 400) {
+      content = lines.slice(0, 400).join('\n') + '\n\n[... truncated ...]';
+    }
+    
+    brief += `### PAGE: ${pagePath}\n\n${content}\n\n---\n\n`;
+  }
+  
+  writeFileSync(join(QA_DIR, `${certName}.md`), brief);
+  const sizeKB = Math.round(brief.length / 1024);
+  console.log(`${certName}: ${controlsToQA.length} to verify, ${referencedPages.size} pages, ${sizeKB}KB`);
+}
diff --git a/scripts/match-controls-to-pages.mjs b/scripts/match-controls-to-pages.mjs
new file mode 100644
index 00000000..ffcae7ed
--- /dev/null
+++ b/scripts/match-controls-to-pages.mjs
@@ -0,0 +1,288 @@
+#!/usr/bin/env node
+/**
+ * Match cert controls to framework pages using keyword extraction + TF-IDF-like scoring.
+ * 
+ * For each control baseline, extracts key terms and scores framework pages by relevance.
+ * Outputs candidate mappings for human review.
+ */
+
+import { readFileSync, writeFileSync, mkdirSync } from 'fs';
+import { join } from 'path';
+
+const REPO_ROOT = join(import.meta.dirname, '..');
+const DATA_DIR = join(REPO_ROOT, 'scripts', 'data');
+const OUT_DIR = join(DATA_DIR, 'mappings');
+mkdirSync(OUT_DIR, { recursive: true });
+
+const certs = JSON.parse(readFileSync(join(DATA_DIR, 'cert-controls.json'), 'utf-8'));
+const pages = JSON.parse(readFileSync(join(DATA_DIR, 'framework-pages.json'), 'utf-8'))
+  .filter(p => !p.path.includes('/old/') && !p.path.includes('/intro/') && !p.path.includes('/contribute/'));
+
+// Domain mapping — which framework domains are candidates for each cert
+const domainMap = {
+  'sfc-workspace-security': ['opsec', 'encryption', 'privacy', 'user-team-security', 'guides', 'iam', 'awareness', 'dprk-it-workers', 'community-management'],
+  'sfc-dns-registrar': ['opsec', 'infrastructure', 'community-management', 'front-end-web-app', 'monitoring', 'devsecops'],
+  'sfc-devops-infrastructure': ['devsecops', 'supply-chain', 'security-automation', 'secure-software-development', 'infrastructure', 'security-testing', 'monitoring'],
+  'sfc-incident-response': ['incident-management', 'governance', 'monitoring', 'security-automation', 'multisig-for-protocols', 'wallet-security', 'infrastructure'],
+  'sfc-multisig-ops': ['multisig-for-protocols', 'wallet-security', 'opsec', 'governance', 'incident-management'],
+  'sfc-treasury-ops': ['treasury-operations', 'wallet-security', 'governance', 'multisig-for-protocols', 'monitoring', 'incident-management', 'devsecops'],
+};
+
+// ── Build page content index ───────────────────────────────────────
+const PAGES_DIR = join(REPO_ROOT, 'docs', 'pages');
+const pageIndex = new Map();
+
+for (const page of pages) {
+  const filePath = join(PAGES_DIR, page.path.slice(1) + '.mdx');
+  try {
+    let content = readFileSync(filePath, 'utf-8').toLowerCase();
+    // Strip frontmatter and imports
+    content = content.replace(/^---\n[\s\S]*?\n---\n/, '');
+    content = content.replace(/^import\s+.*$/gm, '');
+    content = content.replace(/<[^>]+>/g, ' ');
+    content = content.replace(/```[\s\S]*?```/g, ' ');
+    
+    // Extract sections by header
+    const sections = [];
+    const headerRegex = /^(#{2,3})\s+(.+)$/gm;
+    let lastIdx = 0;
+    let lastHeader = null;
+    let match;
+    
+    while ((match = headerRegex.exec(content)) !== null) {
+      if (lastHeader !== null) {
+        sections.push({
+          header: lastHeader,
+          text: content.slice(lastIdx, match.index),
+        });
+      }
+      lastHeader = match[2].trim();
+      lastIdx = match.index;
+    }
+    if (lastHeader !== null) {
+      sections.push({ header: lastHeader, text: content.slice(lastIdx) });
+    }
+    
+    pageIndex.set(page.path, {
+      fullText: content,
+      sections,
+      title: page.title,
+      headers: page.headers,
+      domain: page.domain,
+    });
+  } catch {
+    // skip unreadable
+  }
+}
+
+// ── Keyword extraction from baselines ──────────────────────────────
+// Stop words to ignore
+const STOP_WORDS = new Set([
+  'a', 'an', 'the', 'is', 'are', 'was', 'were', 'be', 'been', 'being',
+  'have', 'has', 'had', 'do', 'does', 'did', 'will', 'would', 'could',
+  'should', 'may', 'might', 'shall', 'can', 'need', 'must', 'ought',
+  'and', 'or', 'but', 'nor', 'not', 'so', 'yet', 'both', 'either',
+  'neither', 'each', 'every', 'all', 'any', 'few', 'more', 'most',
+  'other', 'some', 'such', 'no', 'only', 'own', 'same', 'than',
+  'too', 'very', 'just', 'because', 'as', 'until', 'while',
+  'of', 'at', 'by', 'for', 'with', 'about', 'against', 'between',
+  'through', 'during', 'before', 'after', 'above', 'below', 'to',
+  'from', 'up', 'down', 'in', 'out', 'on', 'off', 'over', 'under',
+  'again', 'further', 'then', 'once', 'here', 'there', 'when',
+  'where', 'why', 'how', 'what', 'which', 'who', 'whom', 'this',
+  'that', 'these', 'those', 'i', 'me', 'my', 'we', 'our', 'you',
+  'your', 'he', 'his', 'she', 'her', 'it', 'its', 'they', 'their',
+  'if', 'whether', 'also', 'e.g.', 'e.g', 'eg', 'etc', 'ie', 'i.e.',
+  'including', 'defined', 'documented', 'procedures', 'requirements',
+  'ensure', 'maintained', 'reviewed', 'established', 'least', 'based',
+]);
+
+function extractKeyTerms(text) {
+  // Extract multi-word phrases first (2-3 word combos)
+  const phrases = [];
+  const phrasePatterns = [
+    /multi-?factor\s+auth\w*/gi,
+    /access\s+control\w*/gi,
+    /incident\s+respon\w*/gi,
+    /key\s+manage\w*/gi,
+    /key\s+rotat\w*/gi,
+    /hardware\s+wallet\w*/gi,
+    /cold\s+storage/gi,
+    /hot\s+wallet\w*/gi,
+    /smart\s+contract\w*/gi,
+    /social\s+engineer\w*/gi,
+    /supply\s+chain/gi,
+    /full\s+disk\s+encrypt\w*/gi,
+    /on-?call/gi,
+    /role-?based/gi,
+    /zero[\s-]?trust/gi,
+    /break[\s-]?glass/gi,
+    /dns[\s-]?sec/gi,
+    /ci[\s/]?cd/gi,
+    /two[\s-]?factor/gi,
+    /phishing/gi,
+    /playbook\w*/gi,
+    /escalat\w*/gi,
+    /multisig/gi,
+    /multi-?sig/gi,
+    /threshold/gi,
+    /signer\w*/gi,
+    /treasury/gi,
+    /custod\w*/gi,
+    /defi/gi,
+    /staking/gi,
+    /governance/gi,
+    /credential\w*/gi,
+    /password\w*/gi,
+    /encrypt\w*/gi,
+    /decrypt\w*/gi,
+    /backup\w*/gi,
+    /disaster\s+recovery/gi,
+    /business\s+continuity/gi,
+    /penetration\s+test\w*/gi,
+    /vulnerability\s+scan\w*/gi,
+    /code\s+review\w*/gi,
+    /branch\s+protect\w*/gi,
+    /secret\s+manage\w*/gi,
+    /log\s+retention/gi,
+    /tamper[\s-]?eviden\w*/gi,
+    /alert\w*/gi,
+    /monitor\w*/gi,
+    /paging/gi,
+    /on-?chain/gi,
+    /off-?chain/gi,
+    /time[\s-]?lock\w*/gi,
+    /registrar/gi,
+    /domain\s+lock\w*/gi,
+    /dnssec/gi,
+    /spf/gi,
+    /dkim/gi,
+    /dmarc/gi,
+    /certificate\s+transparency/gi,
+    /endpoint\s+protect\w*/gi,
+    /mdm/gi,
+    /edr/gi,
+    /device\s+manage\w*/gi,
+    /remote\s+wipe/gi,
+    /insider\s+threat/gi,
+    /security\s+train\w*/gi,
+    /war\s+room/gi,
+    /post[\s-]?mortem/gi,
+    /drill\w*/gi,
+    /tabletop/gi,
+    /simulation/gi,
+    /containment/gi,
+    /forensic\w*/gi,
+    /triage/gi,
+  ];
+  
+  for (const pat of phrasePatterns) {
+    let m;
+    while ((m = pat.exec(text)) !== null) {
+      phrases.push(m[0].toLowerCase().trim());
+    }
+  }
+  
+  // Also extract single significant words
+  const words = text.toLowerCase()
+    .replace(/[^a-z0-9\s-]/g, ' ')
+    .split(/\s+/)
+    .filter(w => w.length > 3 && !STOP_WORDS.has(w));
+  
+  return { phrases, words };
+}
+
+function scorePageForControl(pageData, controlTerms) {
+  const { fullText, sections } = pageData;
+  let score = 0;
+  const matchedSections = new Set();
+  
+  // Score phrase matches (high value)
+  for (const phrase of controlTerms.phrases) {
+    const regex = new RegExp(phrase.replace(/[-\/\\^$*+?.()|[\]{}]/g, '\\$&'), 'gi');
+    const matches = (fullText.match(regex) || []).length;
+    if (matches > 0) {
+      score += matches * 3;
+      // Find which section contains this
+      for (const sec of sections) {
+        if (sec.text.match(regex)) {
+          matchedSections.add(sec.header);
+        }
+      }
+    }
+  }
+  
+  // Score word matches (lower value)
+  for (const word of controlTerms.words) {
+    const regex = new RegExp(`\\b${word}\\b`, 'gi');
+    const matches = (fullText.match(regex) || []).length;
+    if (matches > 0) {
+      score += Math.min(matches, 5); // cap per-word contribution
+    }
+  }
+  
+  return { score, matchedSections: [...matchedSections] };
+}
+
+// ── Process each cert ──────────────────────────────────────────────
+for (const cert of certs) {
+  const domains = domainMap[cert.name];
+  if (!domains) continue;
+  
+  const candidatePages = [...pageIndex.entries()]
+    .filter(([path]) => {
+      const domain = path.split('/')[1];
+      return domains.includes(domain);
+    });
+  
+  const mapping = [];
+  
+  for (const section of cert.sections) {
+    for (const ctrl of section.controls) {
+      // Combine description + baselines for keyword extraction
+      const allText = [ctrl.description, ...ctrl.baselines].join(' ');
+      const terms = extractKeyTerms(allText);
+      
+      // Score each candidate page
+      const scored = candidatePages.map(([path, data]) => {
+        const { score, matchedSections } = scorePageForControl(data, terms);
+        return { path, score, matchedSections, title: data.title };
+      })
+      .filter(s => s.score > 5) // minimum threshold
+      .sort((a, b) => b.score - a.score)
+      .slice(0, 8); // top 8 candidates
+      
+      mapping.push({
+        controlId: ctrl.id,
+        controlTitle: ctrl.title,
+        description: ctrl.description,
+        baselineCount: ctrl.baselines.length,
+        baselines: ctrl.baselines,
+        candidates: scored.map(s => ({
+          page: s.path,
+          title: s.title,
+          score: s.score,
+          matchedSections: s.matchedSections,
+        })),
+      });
+    }
+  }
+  
+  writeFileSync(join(OUT_DIR, `${cert.name}.json`), JSON.stringify(mapping, null, 2));
+  
+  // Summary
+  const withMatches = mapping.filter(m => m.candidates.length > 0).length;
+  const noMatches = mapping.filter(m => m.candidates.length === 0).length;
+  console.log(`\n${cert.name}: ${mapping.length} controls`);
+  console.log(`  ${withMatches} with candidates, ${noMatches} without`);
+  
+  // Show top match per control
+  for (const m of mapping) {
+    const top = m.candidates[0];
+    if (top) {
+      console.log(`  ${m.controlId} → ${top.page} (score: ${top.score}, sections: ${top.matchedSections.slice(0,2).join(', ') || 'general'})`);
+    } else {
+      console.log(`  ${m.controlId} → NO MATCH`);
+    }
+  }
+}