What belongs in the archive?
Cyber incidents affecting Louisiana state and local agencies, law enforcement, courts, public education and private critical infrastructure, including healthcare, emergency medical services, energy, utilities and transportation. A documented Louisiana connection is required.
The archive currently contains 13 curated incident and claim records. It is not a statewide census, a live outage map or a measure of an agency’s present security posture. A parish without a record is not assumed to be unaffected. Multi-state providers can appear when their Louisiana presence is established; the record does not imply that every affected person lived in Louisiana.
Incident status and attacker claims are separate.
The organization or an official authority acknowledged an event, directly or through attributable reporting. This confirms the event, not every claim about its cause, attacker, ransom or stolen data.
Credible reporting describes an event, but the selected evidence does not establish an attributable acknowledgment by the organization or an authority.
A threat actor alleges an attack or theft without established independent confirmation in this record. These records are excluded from any count labeled confirmed attacks.
An agency can confirm that its network was disrupted while an attacker separately claims to have stolen files. The disruption may be confirmed while the theft, quantity and attribution remain unverified.
Dates describe different parts of the story.
We distinguish occurrence, discovery, disclosure, article publication and threat-intelligence listing dates. An observed leak-site listing is never automatically used as the attack date. Month-only dates and uncertain windows retain that uncertainty.
Articles and official updates attach to an incident rather than becoming extra attacks in the count. Different events at the same organization remain distinct. An organization or domain match does not establish that two claims describe the same event.
Affected-person figures, exposure totals, payments, costs and recovery milestones are included only with a source and clear scope. Provider credential counters may be independent historical records; they do not establish the entry point or count compromised vendors. Missing information does not mean zero.
Different sources answer different questions.
| Source | What it contributes | What it cannot establish alone |
|---|---|---|
| Official notices and audits | Attributable acknowledgments, documented impacts, findings and response statements. | That every initial assessment is complete or unchanged. |
| Independent reporting | Interviews, public records, follow-up investigations and community impact. | Official attribution when an article is only repeating an attacker claim. |
| Ransomware.live | A provider-recorded claim, claimant and listing observation date. | Verified intrusion, stolen-data scope or root cause. |
| Third-party research | Broader trends, control priorities and practical reference material. | A Louisiana-specific rate or the cause of an individual local event. |
| Fortinet documentation | Product mechanisms, supported deployment options and constraints. | Independent proof that a product would have prevented a historical breach. |
Organization websites may support identity or service scope. They are not treated as incident acknowledgments unless they contain a relevant statement. Links identify the original publisher; the site summarizes reporting and does not reproduce stolen records or full articles.
Search the source libraryHow the connected source watch updates
Ransomware.live API results are checked against a reviewed Louisiana organization directory. The site stores minimal claim summaries and safe provider links. The API token remains on the server. An exact workbook listing match requires the same Ransomware.live record ID and reviewed organization; matching a ransomware group name is insufficient.
A linked cloud task loads the source watch every hour, including when no one visits. A visit can also refresh a stale snapshot. The server permits one refresh attempt per UTC clock hour across visitors and task runs, preventing duplicate upstream requests. Scheduled execution may be delayed; the displayed timestamps show actual checks. The displayed time is the last successful API check. If a refresh fails, the prior snapshot remains visible with a warning. The feed is not guaranteed to be complete or real time.
New organizations, incident confirmations and security assessments receive editorial review. The connected watch also checks GDELT headlines and SEC Item 1.05 filings hourly; HHS public exports, HIBP breach metadata, CISA KEV and FIRST EPSS are checked daily. Sources keep their own successful-check timestamps and retain prior records after a failed check. Cloudflare Radar is pending separate credentials and network mappings. A source notice never automatically becomes a confirmed incident or inherits a product recommendation.
Publication filters require a reviewed organization identity and documented Louisiana public-sector or critical-infrastructure presence. GDELT headlines must name that organization and describe a cyber incident; they remain reporting leads. SEC records require an 8-K or amendment containing Item 1.05. Louisiana-serving operators are labeled when local impact is not established. HHS rows require both State LA and an exact reviewed healthcare alias; report-submission dates and full-report person counts retain their original meaning. The public HHS export covers the current-investigations view, not all historical breaches. An inconsistent geography is excluded pending review.
HIBP uses only verified public breach-catalog metadata matched to an official domain, with attribution. No email or account queries are performed. KEV and EPSS are joined only to explicitly referenced incident CVEs. Neither a KEV entry nor an EPSS probability demonstrates a current vulnerability at a Louisiana agency. The reviewed directory intentionally excludes unknown organizations; an empty feed does not mean no incidents occurred.
How a security gap becomes a recommendation
- Start with the evidence. Identify documented service disruption, exposure or a known technique. Keep unknown entry points unknown.
- Map the organization and listing. Preserve the workbook’s evidence ID, account row and listing row, including any limits on event linkage.
- Explain the control. Describe the protective technology in plain language and link current vendor documentation.
- Validate the fit. State which devices, applications, accounts or data paths must be covered. Explain what the product will not establish or protect by itself.
The reference workbook is Five_State_Ransomware_Fortinet_Positioning.xlsx, October 8, 2026 snapshot. 9 archive organizations have reviewed Louisiana account matches. The remaining 4 records use separately labeled technical assessments. Internal sales tiers, owners and account-planning fields are not published.
The workbook’s lead recommendation is preserved and conditional follow-ons are identified. FortiRecon provides exposure intelligence and needs human remediation; it is not an endpoint ransomware blocker. FortiGate, FortiWeb and other appliance-capable families are distinguished from software and cloud services. Specific appliance models require traffic, inspection, availability and capacity sizing, which the incident record cannot supply.
These are present-day examples, not findings that the affected organization lacked a product, used it incorrectly or could certainly have avoided the incident. Historical product availability and detection rules matter. No recommendation changes an incident’s evidence status. The Fortinet layer is educational and is not a comparative test or an exclusive list of effective controls.
Explore security gaps & technologyTransparency, privacy and corrections
Bayou Breach is a personal, noncommercial awareness project curated by Weston Merriott. It is not an official government resource, and inclusion does not imply an agency’s endorsement. Fortinet technology examples are clearly identified. Conversation requests are addressed to Weston.
We do not host stolen records, ransomware samples, personal victim datasets or direct stolen-data downloads. Conversation forms create a draft in the visitor’s email app. The website does not send that message or store the entered form details. Hosting infrastructure may process routine access logs.
For a correction, provide the incident name, the statement in question and a public source supporting the change. We review the evidence and update the affected brief and its sources. An active incident should be handled through established response and law-enforcement channels.
Submit a correction or new source