Cyber Incidents
See what a public company actually told investors after it was hacked: the kind of attack, the systems hit, whether data was taken, and how long it waited before disclosing. Every 8-K filed under SEC Item 1.05 since the rule took effect, plus every amendment that revises one, as one row per filing.
Event-study the disclosure, not the headline.
filing_timestamp is the EDGAR acceptance time, so you know whether the market learned about a breach before or after the close.
Separate the breach from the outage.
data_compromised_flag and operations_disrupted_flag split data loss from business interruption, and attack_type names the method.
Measure how long the company sat on it.
days_discovery_to_disclosure and days_determination_to_disclosure size the gap between finding out and telling the market.
Which public companies have told investors they were hacked badly enough to disrupt the business, and how did the stock trade in the days after they said so?
Your agent translates this into the attack-type and disruption filters, the exact acceptance timestamp of each filing, and the reaction window around it.
The breach disclosure the SEC made mandatory.
Item 1.05 is the section of Form 8-K where a US public company reports a cybersecurity incident it has judged material to investors. Before it existed, breach news arrived through press releases and buried risk factors; now it lands in one standard place on EDGAR, on a clock.
This dataset is every Item 1.05 filing since the rule took effect, plus every 8-K/A that updates one, turned into structured fields. Amendments are separate rows linked back to the original they revise, so the record stays point-in-time: you can see what the company said on day one and what it corrected later.
Each row includes:
- Four dates kept in separate roles: discovered, determined material, disclosed, amended, each with its own precision label.
- An attack-type label and a one-sentence plain-language description of what happened.
- Seven flags covering data loss, operational disruption, vendor origin, containment, restoration, investigation status, and law enforcement.
- The company's own stated reason the incident was material.
- Amendment linkage back to the original 8-K, with the reason the amendment was filed.
- Market cap and shares outstanding as of the session before the filing.
The flags say only what the filing said. 1 means the company stated yes, 0 means it stated no, and null means it never addressed the question. Silence is null, not no, so the yes and no counts will never add up to the total.
Price the difference between a data leak and an outage.
The direct use is event studies with the timestamp attached. Measure the price and volatility reaction to a breach disclosure, then condition on what the filing actually said: a ransomware event with operations disrupted is a different trade than a vendor data breach with no business interruption. Market cap at filing sits on the row, so small-cap reactions separate cleanly from mega-cap noise.
The subtler angle is timing. Disclosure latency runs from days to months, and a long gap can mean a deeper investigation or a bigger problem. Amendments are their own signal: an incident that keeps getting amended is one whose story kept changing, and amendment_reason says why. Because this is the complete population rather than a sample, base rates are honest and the denominator can be trusted.
- Event-study the disclosure-day and next-day reaction, split by attack_type and data_compromised_flag.
- Screen for long disclosure latency (days_discovery_to_disclosure) as a proxy for incident severity.
- Track amended incidents: amendment_count above 1 flags stories that kept changing.
- Compare operational-disruption events against pure data-loss events; the P&L shape differs.
- Watch third_party_incident_flag for vendor and supply-chain contagion across multiple filers.
Read out of the filing, never out of the news.
The source is SEC EDGAR. A nightly job finds every new 8-K and 8-K/A reporting Item 1.05, then a labeling step reads the filing text and extracts the dates, the attack type, the incident flags, and the company's stated materiality reasoning. Nothing is inferred from news reports or outside sources.
Filing dates, accession numbers, and amendment status come straight from EDGAR metadata and are never model-generated, and every row links to the filing index on sec.gov so any extracted value can be checked. A separate sweep rewrites the amendment linkage fields as new 8-K/As arrive, so cached clients should poll updated_since rather than the disclosure date alone.
The fields that date the incident and describe the damage.
The headline fields below are a subset. Every field, with exact types and semantics, is documented in the API reference.
| Field | Type | What it tells you |
|---|---|---|
| filing_timestamp | string | EDGAR acceptance timestamp with UTC offset. Decides whether the disclosure landed before or after the close. |
| attack_type | string | Taxonomy: data-breach, unauthorized-access, ransomware, business-email-compromise, other, or unstated. |
| data_compromised_flag | integer | Whether the filing states data was compromised. |
| operations_disrupted_flag | integer | Whether the filing states operations were disrupted; separates business interruption from pure data loss. |
| third_party_incident_flag | integer | Whether the incident originated at a vendor or third party; the supply-chain screen. |
| incident_discovered_date | string | When the company discovered the incident, as stated in the filing. |
| materiality_determined_date | string | When the company decided the incident was material; this starts the SEC disclosure clock. |
| days_discovery_to_disclosure | integer | Total disclosure latency in calendar days, from discovery to the 8-K. |
| days_determination_to_disclosure | integer | Calendar days from the materiality call to disclosure; the SEC deadline is four business days. |
| materiality_basis | string | The company's own stated reason the incident is material. |
| amended_flag | integer | On an original 8-K: 1 means it has since been amended. The revised-story screen. |
| market_cap_at_filing | float | USD market cap as of the last session before the filing, for sizing the reaction. |
One call returns the incident, the timeline, and the amendments.
One key works across the REST API, the hosted MCP server, and this dashboard. Every response is JSON with a { count, data } envelope.
import requests
url = "https://api.alphanume.com/v1/regulatory/cyber-incidents"
params = {
"attack_type": "ransomware",
"is_amendment": "0",
"api_key": "alp_abc123"
}
r = requests.get(url, params=params)
print(r.json())curl "https://api.alphanume.com/v1/regulatory/cyber-incidents?attack_type=ransomware&is_amendment=0&api_key=alp_abc123"{
"count": 1,
"data": [
{
"record_id": "0001104659-26-061234",
"date": "2026-05-12",
"filing_timestamp": "2026-05-12T17:05:12-04:00",
"ticker": "ACME",
"cik": "1234567",
"company_name": "Acme Industrial Corp.",
"accession_number": "0001104659-26-061234",
"form": "8-K",
"is_amendment": 0,
"event_date_reported": "2026-05-08",
"incident_discovered_date": "2026-05-02",
"incident_discovered_precision": "day",
"materiality_determined_date": "2026-05-08",
"materiality_determined_precision": "day",
"disclosed_date": "2026-05-12",
"incident_description": "Ransomware attack encrypted internal IT systems and disrupted order processing.",
"attack_type": "ransomware",
"third_party_incident_flag": null,
"systems_affected": "internal IT systems and order processing applications",
"data_compromised_flag": 1,
"operations_disrupted_flag": 1,
"materiality_basis": "expected impact on results of operations from disrupted order fulfillment",
"investigation_ongoing_flag": 1,
"law_enforcement_notified_flag": 1,
"days_discovery_to_determination": 6,
"days_determination_to_disclosure": 4,
"days_discovery_to_disclosure": 10,
"amended_flag": 0,
"amendment_count": 0,
"market_cap_at_filing": 2140000000.0,
"filing_url": "https://www.sec.gov/Archives/edgar/data/1234567/000110465926061234/0001104659-26-061234-index.htm",
"refused": 0,
"last_updated": "2026-05-13"
}
]
}What this data does not claim.
- The whole corpus is roughly 80 filings. That is the entire population of Item 1.05 disclosures, not a sample, so a thin slice is a real count rather than a coverage gap.
- Sparsity is expected, not broken: materiality_determined_date appears on roughly 14% of rows, incident_discovered_date on roughly 83%, market_cap_at_filing on roughly 79%. The intervals that depend on the materiality date are equally sparse.
- Rows with refused = 1 carry null extracted fields because the labeler declined the filing text, not because the filing was silent. The disclosure event is still real.
- days_determination_to_disclosure counts calendar days while the SEC deadline is four business days, so a value above 4 is not automatically a late filing.
- Imprecise dates are normalized to the first day of the stated period. Check the companion precision field before treating a date as day-exact.
Asked by researchers, answered plainly.
What is SEC Item 1.05?
It is the 8-K item the SEC created for material cybersecurity incidents, adopted in July 2023 and effective on December 18, 2023. Before that date there was no dedicated place for cyber disclosure, which is why the dataset starts there and why comparisons with earlier breach data are not apples to apples.
Do companies have to disclose every cyber attack?
No. Item 1.05 covers only incidents the company determines are material to investors, so routine intrusions never appear. Scope here is Item 1.05 filings, which means an incident disclosed some other way, in a press release or under a different 8-K item, falls outside it.
How fast must a company disclose a material cyber incident?
Generally within four business days of determining the incident is material, not four days from the attack. A company can spend weeks investigating before making that call, which is why the two clocks are stored separately: days_discovery_to_determination for the investigation, days_determination_to_disclosure for compliance.
What does an 8-K/A amendment add to a cyber incident?
It is how the story changes after day one, and amendment_reason records why it was filed. Watch the two similar fields: is_amendment marks a row that is itself an 8-K/A, while amended_flag marks an original that was later amended. amended_flag is null on amendment rows, and that null does not mean never amended.
Free to evaluate. Full history with Pro.
A free key returns a rolling 30-day window of delayed data, enough to test the workflow end to end. Pro unlocks the full point-in-time history, real-time access, and every standard dataset as it launches.