Insights
Public-Company Cyber Incident Database for Event Studies
Alphanume Team · August 18, 2026
Build cyber event studies from company disclosures and EDGAR acceptance times, not breach rumors or dates reconstructed after the market moved.
A public-company cyber incident database is useful for event studies when it preserves what the issuer disclosed, when EDGAR accepted the filing, and which facts remained unstated. Alphanume's Cyber Incidents dataset tracks material incident disclosures from Form 8-K Item 1.05 and amendments. It separates discovery, materiality, disclosure, and amendment dates so a researcher can choose an observation time without pretending every date was known together.
The source corpus begins with the Item 1.05 regime in December 2023 and is small by design because material disclosures are rare. That is a feature of the population, not evidence that missing rumors should be added. The Cyber Incidents documentation defines the fields, filters, pagination, update process, and expected sparsity.
Use disclosure time as the tradable event
For a market reaction study, filing_timestamp is the clean event clock. It includes the EDGAR acceptance time and UTC offset, which distinguishes a filing before the close from one after it. incident_discovered_date describes when the company says it found the incident. materiality_determined_date describes a later internal conclusion when stated. Neither is automatically the first public observation.
Field | Meaning | Event-study use |
|---|---|---|
filing_timestamp | Exact EDGAR acceptance time | Map to the first eligible trading session |
incident_discovered_date | Company-reported discovery date | Measure operational latency, not public awareness |
materiality_determined_date | Date materiality was determined when disclosed | Study stated compliance timing with its precision |
is_amendment | Original 8-K versus 8-K/A | Avoid counting an amendment as a new incident |
filing_url | Primary EDGAR evidence | Audit extracted facts against the filing |
Each extracted date has a precision field. A month-level statement is normalized to the first day of that month, so the normalized value is not day-level evidence. Filter on precision when a study needs exact days. The materiality date is sparse because many filings do not state it. Null means unstated, not zero days and not the disclosure date.
Retrieve a bounded incident panel
Start with originals only and a completed date range. Keep issuer identifiers even when ticker is null, because CIK is present on every row while some filers lack a listed symbol. Preserve three-state flags such as data compromise and operational disruption. A null flag means the filing did not say, which differs from an explicit zero.
GET /v1/regulatory/cyber-incidents
date_gte=2025-01-01
date_lte=2025-12-31
is_amendment=0
Keep: date, filing_timestamp, ticker, cik, accession_number, attack_type,
incident_discovered_date, incident_discovered_precision,
materiality_determined_date, materiality_determined_precision,
data_compromised_flag, operations_disrupted_flag, market_cap_at_filing,
filing_url, refused, last_updatedThe response is ordered by disclosure date and accession number. When has_more is true, pass both values from next_cursor. Poll updated_since as well as new disclosure dates because amendment linkage can update an original row after it was first served. Save raw versions if reproducibility requires reconstructing the dataset as retrieved.
Define outcomes without inventing severity
A disclosed ransomware classification or disruption flag does not measure dollars lost, downtime, negligence, or future returns. Build cohorts from documented categories, then attach separately sourced prices after the eligible session. Do not infer breach severity from headline length or assume a company that disclosed quickly suffered less. The dataset reports stated facts and conservative flags, not a latent severity score.
- Do not count original filings and their amendments as independent incidents.
- Do not treat four calendar days as the SEC's four-business-day disclosure standard.
- Do not replace ticker-null issuers with current ticker mappings unless the mapping is dated and audited.
- Do not describe refused extraction rows as incidents with negative flags.
Amendments create a second reproducibility problem. An original row can later gain amendment linkage, amendment counts, and a latest-amendment date. Those fields are valuable for studying how disclosures develop, but they were not present in the first public filing. Store a retrieval timestamp and decide whether the study asks what the database says now about an old incident or what a researcher could have retrieved then. Those are different datasets. If the latter is required, version raw responses and prohibit later linkage fields from entering the original-event feature vector. Also separate incident discovery from disclosure latency: a long interval can reflect investigation, imprecise date language, or delayed materiality determination. The database does not identify which explanation caused it.
Run one auditable event-study slice
Pull one calendar year of original disclosures, save the response pages, and map each timestamp to the next eligible session under a written before-close rule. Export an event table containing CIK, accession, timestamp, chosen day zero, attack type, flags, and filing URL. Open a sample of filings and confirm the classification. Only then attach returns and report how many events lack prices, tickers, exact discovery dates, or market cap. That exclusion table is the concrete next action.