← Back to Cybersecurity News Center
Severity
HIGH
Priority
0.150
Executive Summary
Board-level cybersecurity oversight is now a regulatory requirement, not a best practice. SEC disclosure rules, CIRCIA's advancing rulemaking, and FDIC examination frameworks create direct accountability for directors who cannot demonstrate active engagement with cyber risk strategy. Organizations in financial services, critical infrastructure, and supply-chain-dependent sectors face the highest compliance and reputational exposure if governance structures lag behind these expectations.
Technical Analysis
This item is a governance and compliance development, not a discrete vulnerability.
No CVE, CVSS score, or patch applies.
The relevant threat vectors driving regulatory pressure map to MITRE ATT&CK as follows: T1566 (Phishing) and T1078 (Valid Accounts) reflect AI-amplified social engineering and credential attacks; T1195 (Supply Chain Compromise) and T1199 (Trusted Relationship) reflect third-party and software supply chain risk; T1486 (Data Encrypted for Impact) reflects ransomware campaigns against critical infrastructure.
Regulatory instruments in scope: SEC cybersecurity disclosure rules (17 CFR Parts 229 and 249, effective December 2023 for material incident disclosure, June 2024 for annual reporting); CIRCIA (Pub. L. 117-58, Div. Y), with CISA's proposed rule under active rulemaking as of early 2025; FDIC 2025 Report on Cybersecurity and Resilience; DHS AI-Critical Infrastructure Safety and Security Guidelines (April 2024). No exploitation mechanics to report.
Action Checklist IR ENRICHED
Triage Priority:
URGENT
Escalate immediately to legal counsel and the CISO if a regulatory filing deadline (10-K, 8-K material incident disclosure) is within 30 days and governance gap assessment reveals undisclosed board oversight deficiencies, or if the organization has experienced any cyber incident in the prior 12 months that may qualify as a CIRCIA-reportable event under proposed covered entity definitions but was not reported.
Step 1: Governance Gap Assessment. Map your current board oversight structure against 17 CFR §229.106 and §249.1906 requirements (Regulation S-K Item 106, Regulation S-X Item 1906). Confirm whether your proxy statement and 10-K annual report describe board-level cyber expertise and oversight processes as required. Identify any disclosure gaps before your next filing cycle.
Preparation
NIST 800-61r3 §2 — Preparation: Establishing IR capability, policies, and governance structures aligned to organizational risk posture
NIST IR-1 (Policy and Procedures)
NIST IR-8 (Incident Response Plan)
NIST CA-1 (Assessment, Authorization, and Monitoring — Policy and Procedures)
CIS 7.1 (Establish and Maintain a Vulnerability Management Process)
Compensating Control
A 2-person team can conduct this gap assessment manually using SEC EDGAR to pull the organization's most recent 10-K and DEF 14A proxy filing, then compare Item 1C (Cybersecurity) disclosures against the SEC Rule 33-11216 disclosure checklist published by the SEC in July 2023. Build a side-by-side gap matrix in a spreadsheet: column A lists required disclosure elements (board expertise, oversight process, materiality assessment methodology), column B maps current proxy language, column C flags missing or insufficient language. No commercial tooling required.
Preserve Evidence
Before conducting the gap assessment, preserve a timestamped snapshot of all current public SEC filings (10-K, 10-Q, 8-K) from EDGAR that reference cybersecurity — these establish the pre-assessment baseline for any regulatory examination. Additionally, collect internal board meeting minutes, committee charters (especially Audit and Risk committee), and any prior FDIC examination reports referencing IT/cyber governance, as SEC and FDIC examiners will cross-reference disclosed governance structures against actual documented board activity.
Step 2: CIRCIA Readiness Check. Determine whether your organization qualifies as a covered entity under CIRCIA's critical infrastructure sector definitions. Review CISA's proposed reporting timelines (72-hour incident report, 24-hour ransom payment report) and verify your current incident response plan meets those thresholds. Flag gaps to legal and compliance.
Preparation
NIST 800-61r3 §2 — Preparation: Ensuring IR plans and detection capabilities meet defined reporting and response time thresholds before an incident occurs
NIST IR-4 (Incident Handling)
NIST IR-6 (Incident Reporting)
NIST IR-8 (Incident Response Plan)
CIS 7.1 (Establish and Maintain a Vulnerability Management Process)
CIS 7.2 (Establish and Maintain a Remediation Process)
Compensating Control
Map your organization's primary NAICS code against CISA's 16 critical infrastructure sector definitions using CISA's published sector roster (available at cisa.gov/topics/critical-infrastructure-security-and-resilience). Then run a tabletop clock drill: simulate a ransomware encryption event at T+0 and walk through your current IR runbook step-by-step, logging actual elapsed time for detection confirmation, internal escalation, legal notification, and external CISA report generation. If any phase exceeds CIRCIA's 72-hour window by more than 25%, document the bottleneck (e.g., no 24/7 SOC coverage, legal approval delay) and flag it as a gap. Free IR plan templates from CISA's Cyber Essentials Toolkit can serve as a baseline for small teams.
Preserve Evidence
Before this readiness check, pull your existing IR plan version history and any incident tickets from the past 24 months to establish documented mean-time-to-detect (MTTD) and mean-time-to-report (MTTR) baselines — these are the metrics CISA examiners will request to validate whether your 72-hour reporting capability is realistic. Also collect any ransomware payment records or cryptocurrency wallet transaction logs if a prior payment event occurred, as CIRCIA's 24-hour ransom payment reporting requirement creates retrospective exposure if prior incidents went unreported.
Step 3: Third-Party Risk Visibility. Audit whether your third-party risk management (TPRM) program produces board-visible reporting. Map critical vendors to MITRE T1195 and T1199 exposure. Verify contracts include breach notification requirements aligned to CIRCIA and SEC timelines.
Preparation
NIST 800-61r3 §2 — Preparation: Identifying external dependencies, establishing visibility into supply chain risk, and ensuring third-party reporting obligations are contractually defined prior to an incident
NIST IR-4 (Incident Handling)
NIST IR-6 (Incident Reporting)
NIST SA-12 (Supply Chain Protection)
NIST SR-6 (Supplier Assessments and Reviews)
CIS 1.1 (Establish and Maintain Detailed Enterprise Asset Inventory)
Compensating Control
Using a spreadsheet, build a tiered vendor criticality matrix: Tier 1 = vendors with code or update delivery pipelines into production systems (T1195 — Supply Chain Compromise: Software Supply Chain); Tier 2 = vendors with trusted remote access to your network (T1199 — Trusted Relationship). For Tier 1 vendors, verify software bill of materials (SBOM) availability and cross-reference vendor package names against CISA's Known Exploited Vulnerabilities catalog using a free Python script calling the NVD API. For Tier 2, audit Active Directory or VPN logs for vendor service account logon events — on Windows, query Security Event Log for Event ID 4624 (Logon Type 3 or 10) filtered to vendor-associated accounts — to confirm actual access scope matches contracted scope.
Preserve Evidence
Before the audit, collect network flow logs or firewall egress logs showing all outbound connections to vendor IP ranges over the prior 90 days — this establishes a baseline of actual vendor connectivity that may exceed what is documented in contracts. Also preserve any vendor-sent software update packages with cryptographic hash values, as T1195 attacks (e.g., SolarWinds-style supply chain compromise) leave forensic evidence specifically in update delivery mechanisms: installer binary hashes, update server URLs in software configuration files, and signed certificate chains in delivered binaries. Pull these before the audit modifies any vendor access controls.
Step 4: AI Threat Integration. Incorporate AI-enabled phishing and social engineering risk (T1566, T1078) into your current risk register and board risk appetite statement. Reference DHS AI-CI Safety and Security Guidelines (April 2024) for critical infrastructure-specific control guidance. Update tabletop exercise scenarios to include AI-augmented social engineering.
Preparation
NIST 800-61r3 §2 — Preparation: Updating threat models, training scenarios, and detection capabilities to address emerging AI-augmented attack vectors before they are exploited against the organization
NIST IR-2 (Incident Response Training)
NIST IR-3 (Incident Response Testing)
NIST SI-4 (System Monitoring)
NIST RA-3 (Risk Assessment)
CIS 6.3 (Require MFA for Externally-Exposed Applications)
CIS 6.5 (Require MFA for Administrative Access)
Compensating Control
Deploy Gophish (free, open-source) to run an internal AI-augmented spear-phishing simulation: use publicly available LinkedIn and corporate website data to craft hyper-personalized lures mimicking the quality of LLM-generated phishing (T1566.001 — Spearphishing Attachment or T1566.002 — Spearphishing Link). Measure click rates and credential submission rates as a baseline board-reportable metric. For T1078 (Valid Accounts) detection without a SIEM, deploy Sysmon with SwiftOnSecurity's config and write a PowerShell query against Windows Security Event Log filtering for Event ID 4648 (Explicit Credential Use) and Event ID 4625 (Failed Logon) from accounts that appear in your privileged account inventory — anomalous patterns (off-hours access, new source IPs) are the primary T1078 forensic indicator.
Preserve Evidence
Before updating the risk register, collect the last 90 days of email gateway logs (header analysis, sender IP reputation, DKIM/DMARC pass/fail records) to establish a baseline of current phishing volume and detection rate — AI-generated phishing (T1566) is specifically characterized by low-volume, high-personalization campaigns that bypass keyword-based filters, so DMARC failure rates and user-reported phishing counts are the relevant pre-exercise metrics. Also pull MFA bypass or push-fatigue events from your identity provider logs (e.g., Azure AD Sign-In logs, Okta System Log event type 'user.mfa.factor.deactivate') as T1078 exploitation of AI-assisted credential theft will appear here first.
Step 5: ERM Integration and Board Reporting Cadence. Confirm cyber risk is formally embedded in enterprise risk management (ERM) frameworks with defined risk appetite thresholds. Establish or validate a quarterly board reporting cadence that covers threat landscape changes, third-party risk posture, incident metrics, and regulatory compliance status. Document this process; SEC examiners and FDIC examiners will ask for it.
Post-Incident
NIST 800-61r3 §4 — Post-Incident Activity: Translating incident metrics, lessons learned, and threat landscape intelligence into board-level risk reporting and governance process improvements
NIST IR-4 (Incident Handling)
NIST IR-5 (Incident Monitoring)
NIST IR-8 (Incident Response Plan)
NIST AU-6 (Audit Record Review, Analysis, and Reporting)
CIS 8.2 (Collect Audit Logs)
Compensating Control
A 2-person team can produce a board-ready quarterly cyber risk report using freely available inputs: (1) CISA's weekly Cybersecurity Advisories RSS feed for threat landscape narrative; (2) a manually maintained incident ticket log in a shared spreadsheet tracking incident count, classification (per NIST IR-5), and days-to-close for the quarter; (3) the vendor criticality matrix from Step 3 for third-party posture; and (4) a compliance checklist mapped to SEC Rule 33-11216 and CIRCIA readiness items. Store each quarterly report with a version-controlled filename (e.g., CyberRiskReport_Q1-2026_v1.0.pdf) and maintain a distribution log showing board member receipt — this document trail is specifically what SEC and FDIC examiners request during governance examinations.
Preserve Evidence
Before establishing the new cadence, collect and archive all prior board and audit committee meeting minutes that reference cybersecurity topics, along with any existing risk committee reports, to establish a documented governance history baseline. SEC Rule 33-11216 examinations specifically look for evidence of ongoing board engagement rather than one-time disclosure — the absence of prior documented cyber discussion in board minutes is itself an examiner finding. Also preserve any prior FDIC IT examination reports (for financial institutions) as these will be referenced against the new reporting cadence to demonstrate improvement trajectory.
Recovery Guidance
Because this is a governance risk rather than a technical incident, 'recovery' means closing documented compliance gaps before the next SEC filing cycle or FDIC examination window. After completing all five steps, conduct a final read-through of the updated 10-K Item 1C draft against the SEC Rule 33-11216 disclosure checklist and have outside securities counsel review language describing board cyber expertise and oversight process — inaccurate or overstated disclosures carry greater regulatory risk than conservative ones. Monitor CISA's CIRCIA rulemaking docket quarterly, as final rule publication will trigger new covered-entity determination and reporting timeline obligations that may require immediate IR plan updates.
Key Forensic Artifacts
SEC EDGAR filing history (10-K Item 1C, DEF 14A proxy statements, 8-K material incident disclosures) — establishes the documented public disclosure record that regulators will compare against internal governance evidence
Board and audit/risk committee meeting minutes referencing cybersecurity agenda items — primary evidence for SEC and FDIC examiners assessing whether board oversight is active and substantive versus nominal
Incident ticket log or IR tracking system exports covering all security events in the prior 24 months — used to validate whether CIRCIA-reportable incidents occurred without contemporaneous reporting, and to calculate MTTD/MTTR metrics for CIRCIA threshold compliance assessment
Vendor contract repository with breach notification and IR timeline clauses — cross-referenced against CIRCIA 72-hour and SEC 4-business-day material incident disclosure windows to identify contractual gaps that would prevent timely downstream notification
Identity provider and VPN access logs for vendor and third-party service accounts (Windows Security Event ID 4624 Type 3/10, Azure AD Sign-In logs, or equivalent) — establishes actual third-party access scope for T1199 (Trusted Relationship) exposure mapping and provides evidence of access control posture for TPRM board reporting
Detection Guidance
This item does not produce technical IOCs.
Detection focus is compliance and governance posture rather than network or endpoint indicators.
For the threat vectors referenced: T1566 phishing detection, review email gateway logs for AI-generated spear-phishing patterns (high personalization, low volume, clean infrastructure); enable DMARC/DKIM/SPF enforcement and monitor for policy failures.
T1195 supply chain, monitor software build pipelines for unexpected dependency changes; review vendor access logs for anomalous authentication patterns tied to T1078 and T1199 . T1486 ransomware precursors, alert on large-scale file rename operations, shadow copy deletion (vssadmin, wmic), and lateral movement from external-facing systems. For governance compliance monitoring: track SEC 8-K filing timelines against internal incident classification dates to identify potential disclosure lag. Log and timestamp all board-level cyber briefings for regulatory audit readiness.
Compliance Framework Mappings
T1195
T1486
T1078
T1566
T1199
SA-9
SR-2
SR-3
SI-7
CP-9
CP-10
+11
164.308(a)(7)(ii)(A)
164.308(a)(5)(i)
MITRE ATT&CK Mapping
T1195
Supply Chain Compromise
initial-access
T1486
Data Encrypted for Impact
impact
T1078
Valid Accounts
defense-evasion
T1566
Phishing
initial-access
T1199
Trusted Relationship
initial-access
Guidance Disclaimer
