Clustered 2 filings across 1 jurisdiction · filing window Mar 11, 2026 → Apr 9, 2026. View entity profile → Other incidents for this victim →
incident inc_6528fe0830d340c3 · merge_method deterministic · confidence 35%
Discovered → first regulatory filing
Range of discovered_at dates across filings
FEDERAL
Discovery to SEC materiality determination
Materiality determination to SEC 8-K filing
Time between earliest and latest filing
Not recorded for this incident
Leak precedence — no leak-site claim in this cluster.
all SEC 8-K
Earliest sighting first · deep chronology in Litigation Timeline
Mar 11, 2026
When the intrusion reportedly occurred, per the linked filings
Mar 11, 2026
Reported by SEC 8-K filings
Mar 11, 2026
Registrant determined the incident material — starts the SEC 4-business-day clock
Stryker Corporation (CIK 0000310764) filed an 8-K on March 11, 2026, reporting a cybersecurity incident affecting its global Microsoft environment. The Company activated its response plan and engaged external advisors. No ransomware or malware was identified, but the incident caused global disruptions. The Company believes the incident is contained, though the full scope and financial impact remain unknown.
On March 11, 2026, Stryker Corporation identified a cybersecurity incident that disrupted its business operations. The Company worked with third-party experts and law enforcement to contain and neutralize the incident and restore operations. In this Amendment No. 1 to the Original 8-K, Stryker determined the incident had a material impact on first-quarter 2026 operations and financial results, but is not reasonably likely to materially affect 2026 full-year guidance. As of filing, the Company is fully operational; investigation remains ongoing.
About this clustering
DisclosureLens links filings into incidents through layered matchers: deterministic rules (same source document, multistate filings of one breach, tight-window same-victim pairs), a weighted-similarity scorer for cross-source candidates, and an operator review queue for everything uncertain. Each link records its own method and confidence — shown per filing in the timeline below. The system defaults to NOT merging when uncertain, because a false merge (collapsing two unrelated breaches) is more harmful than a false split (showing related filings separately); uncertain pairs route to human review instead of auto-merging. Filing summaries shown in the timeline are AI-generated extracts — verify each against its linked source.