SEC EDGAR Full-Text Search for Breach 8-Ks

TL;DR: SEC EDGAR's Full-Text Search (FTS), at sec.gov/edgar/search with an API backing it at efts.sec.gov/LATEST/search-index, can surface 8-K filings with material cybersecurity incidents (Item 1.05). It is not the same tool as the older /cgi-bin/browse-edgar company browse endpoint, which looks up one company's filing history rather than searching text across all filings. Keyword-only queries will miss incidents described in hedged language, forward-looking statements, or attachments, so treat any keyword list as a starting point, not a complete capture. Use quoted phrases like "cybersecurity incident" or "material cybersecurity incident" alongside a Form 8-K filter, respect the SEC's published 10 requests/second rate limit, and always cross-reference against the actual filing text, not a summary or abstract.

What is SEC EDGAR Full-Text Search, and why does it matter for breach monitoring?

The SEC's Electronic Data Gathering, Analysis, and Retrieval (EDGAR) system houses every public company's filings. The Full-Text Search (FTS) tool, at sec.gov/edgar/search, lets you search the actual text inside filings, not just browse by company. It indexes filings from 2001 to the present; filings older than that exist on EDGAR but have to be located through the company browse tool instead. This matters for cybersecurity and IR teams because:

Mandatory Item 1.05 disclosures: Public companies must file a current report (8-K) within four business days of determining a cybersecurity incident is material.
Raw language, not summaries: EDGAR FTS indexes the actual filing text, not SEC abstracts or curated metadata, so you catch the precise incident description.
Structured API access: The SEC provides a public API behind the search UI (no authentication required, but a declared User-Agent header is required) so you can automate breach monitoring without manual EDGAR scraping.

Without FTS, you're limited to browsing filings company by company, missing incidents described under subsidiary/acquisition disclosures or buried in risk-factor updates that you didn't know to look for.

How do you search EDGAR for "material cybersecurity incident" disclosures?

Use the SEC's EDGAR Full-Text Search, either through the browser UI at sec.gov/edgar/search or its underlying JSON API at https://efts.sec.gov/LATEST/search-index.

Through the UI:

Go to sec.gov/edgar/search.
Enter a quoted phrase, such as "material cybersecurity incident".
Filter the form type to 8-K, and set a date range.
Optionally add a specific company (by name, ticker, or CIK) to narrow results.

Through the API, the same search can be made programmatically:

https://efts.sec.gov/LATEST/search-index?q=%22material+cybersecurity+incident%22&forms=8-K&dateRange=custom&startdt=2026-01-01&enddt=2026-07-01

This is the real API backing the search page; it returns JSON with the matching filings, including the CIK, filer name, accession number, filing date, and (where present) the Form 8-K item numbers tagged on that filing. This is a different tool from /cgi-bin/browse-edgar, which is EDGAR's older company-lookup endpoint for browsing one company's filing history by name, ticker, or CIK; it does not search text across all filings.

Pro tip: Exact-phrase searches ("material cybersecurity incident") are strict but tend to be more precise; broader keyword searches (data breach ransomware) cast a wider net and will surface more false positives (insurance vendor disclosures, historical incident references, and similar noise). The SEC does not publish a precision or false-positive rate for either approach, so treat any specific percentage you see quoted for this, including in earlier versions of this guide, as unverified. Always open the actual filing and read the item text before treating a hit as a real disclosure.

What search strings catch the most real breaches without false positives?

The SEC doesn't enforce a standard lexicon for breach disclosures, so companies use varied language. EDGAR full-text search does not publish per-query precision statistics, and BreachTrigger does not have a verified, sourced figure for how often any of these specific phrases produce a false positive, so treat the notes below as qualitative guidance, not measured precision:

Query String	What it tends to catch
`"material cybersecurity incident"`	The SEC's own phrasing from Item 1.05; a close match to the regulatory language itself.
`"unauthorized access"`	Access-related disclosures, but this also appears in unrelated contexts like failed login reporting.
`"ransomware"` or `"extortion"`	Ransomware-specific incidents; relatively distinctive language.
`"exfiltration"` or `"exfiltrated"`	Data-theft-specific incidents; fairly precise but will miss incidents that don't use this exact term.
`"incident" AND ("cybersecurity" OR "cyber security")`	A broad net that also catches things like phishing simulation results, vendor incidents, and unrelated risk-factor boilerplate.
`"breach" AND ("personal information" OR "sensitive data")`	Disclosures that describe personal or sensitive data exposure.

Broader terms to use with caution, since they catch more noise:

"cyberattack", which also appears in references to attacks on third parties or industry peers, not just the filer.
"security incident", which is generic enough to include policy changes and routine software patching language.
"hack", which is colloquial and rarely appears in formal 8-K language.

Example boolean formula to narrow results:

("material cybersecurity incident" OR "ransomware" OR "data exfiltration")
AND NOT ("alleged" OR "potential" OR "potential risk")

The NOT clauses are a starting point for filtering out forward-looking, hedged statements, but verify the results manually; a boolean exclusion like this will also filter out some genuine disclosures that happen to use hedged language.

What are the rate limits and gotchas when querying the SEC API?

The SEC's FTS and EDGAR APIs are free and public but subject to rate limits:

10 requests/second per IP: This is the SEC's published current maximum access rate, monitored to preserve equitable access for all users. The SEC does not publish an exact block duration for exceeding it; expect requests to be throttled or temporarily managed, and design your client to back off rather than retry aggressively.
No authentication: The SEC doesn't issue API keys, so every query comes from your origin IP.
User-Agent requirement: Always declare a User-Agent header identifying your organization and a contact address, in the format the SEC's own documentation recommends: Sample Company Name AdminContact@<sample company domain>.com. Requests without one risk being flagged as an undeclared automated tool.

Rate-limit gotchas:

Parallel requests add up fast: Firing many concurrent queries at once is the easiest way to exceed the 10 requests/second limit and get temporarily managed as automated traffic. Use a queue with a delay between requests instead of firing everything at once.
Always declare your User-Agent: The SEC's own developer guidance gives this sample format: User-Agent: Sample Company Name AdminContact@<sample company domain>.com. Requests without a declared user agent risk being blocked as an "undeclared automated tool."
Respect robots.txt and the fair access policy: See the SEC's own Accessing EDGAR Data page for the current rate limit and access policy before building an automated scraper.

Code example (Python, using the real full-text search API and respecting rate limits):

import requests
import time

headers = {'User-Agent': 'Sample Company Name AdminContact@example.com'}
queries = ['"material cybersecurity incident"', '"data exfiltration"']

for q in queries:
    response = requests.get(
        "https://efts.sec.gov/LATEST/search-index",
        params={
            'q': q,
            'forms': '8-K',
            'dateRange': 'custom',
            'startdt': '2026-01-01',
            'enddt': '2026-07-01',
        },
        headers=headers
    )
    print(response.json().get('hits', {}).get('total'))
    time.sleep(0.2)  # Stay comfortably under the 10 requests/second limit

Why do simple keyword searches miss material cybersecurity incidents?

The SEC does not publish a miss rate for keyword search, so don't quote a specific percentage here. What is true, structurally, is that company counsel often softens breach language using:

Forward-looking statements: "We experienced an incident that may impact customer data" (reported as potential, not confirmed).
Passive voice and hedge words: "An incident believed to involve personal information" vs. "A breach exposed personal information."
Subsidiary/acquisition framing: Disclosures buried in acquisition risk or integration sections, not in Item 1.05 directly.
Acronyms and abbreviations: "Ransomware variant (RW-2026)" or "Unauthorized access (UA)", not caught by plain English queries.
PDF attachments and exhibits: Some companies attach detailed incident reports as Exhibits; FTS indexes filing text but may miss exhibit text depending on SEC OCR quality.

Example miss:

Query: "breach"
Actual 8-K text: "As disclosed in our acquisition of Acme Corp., Acme experienced an incident on June 1, 2026, potentially affecting customer records. We are investigating."
Result: False negative. The query doesn't find the disclosure because it says "incident," not "breach," and hedges with "potentially."

Solution: Use compound queries (e.g., "incident" AND ("cybersecurity" OR "ransomware" OR "unauthorized access")) and manually review abstract text for risk-factor language, not just Item 1.05 headings.

How do you get the full filing text, not just the abstract?

Once you've found a hit via FTS, you need the actual filing document to verify the incident, rather than relying on the search snippet. Full-text search results link directly to the filing, but if you're building this yourself from the API response:

Take the CIK and accession number from the search result (the API returns both).
The filing's index page follows this pattern: https://www.sec.gov/Archives/edgar/data/[CIK]/[ACCESSION-NO-DASHES]/[ACCESSION-WITH-DASHES]-index.htm, where the CIK has no leading zeros and the accession number appears both with and without dashes in the path.
From the index page, open the .htm document listed for the 8-K itself to read the full filing text.

Pro tip: Under the SEC's final rule, Item 1.05 disclosures must be tagged in Inline XBRL starting with filings on or after December 18, 2024, but the human-readable narrative is still in the HTML document itself; read that rather than trying to parse the XBRL tags for the incident description.

What tools and services automate EDGAR breach monitoring?

Manual EDGAR queries are tedious for continuous monitoring. Several options:

SEC EDGAR API wrappers (free): Python libraries like sec-edgar (GitHub) wrap the FTS API with rate-limiting built in.
Specialized breach-disclosure services (paid): BreachTrigger monitors material cybersecurity incidents across public companies, parsing 8-K filings in real time and alerting IR, MSSP, and cyber-insurance teams to new disclosures. This is aimed at reducing false positives and the time teams spend on manual monitoring.
DIY monitoring: Use the queries above + cron jobs to check EDGAR daily. Simple, but prone to alert fatigue and false positives without NLP filtering.

Legal disclaimer

This post is informational only and is not legal, financial, or investment advice. All SEC EDGAR data is public and freely available. When using FTS to monitor cybersecurity disclosures, verify findings against the original SEC filing and consult your legal and compliance teams before acting on any incident disclosure. The accuracy and completeness of EDGAR FTS results depend on SEC indexing and filing-submission timeliness; BreachTrigger and this guide do not guarantee complete or error-free discovery.

What's next?

For a structured, real-time view of material cybersecurity incidents across your portfolio or competitive set, consider:

How to Monitor SEC 8-K Filings for Data Breaches: end-to-end monitoring workflow for IR and risk teams.
What is SEC 8-K Item 1.05 Cybersecurity Disclosure?: understand the mandatory disclosure rule and timeline.
8-K Cybersecurity Incident Disclosure Examples 2026: annotated example disclosures.

Or explore BreachTrigger to automate the monitoring, filtering, and alerting, no manual EDGAR queries needed. We also track trademark and domain squatting for IR teams via TrademarkSignal.

Keywords: SEC EDGAR, full-text search, 8-K filings, cybersecurity disclosure, material incident, API, data breach monitoring

Last updated: August 5, 2026. Endpoints and rate limits verified against sec.gov/edgar/search, efts.sec.gov, and the SEC's own developer documentation at sec.gov/os/accessing-edgar-data.