A commentary published on SuspectFile by security researcher Marco A. De Felice argues that the healthcare and broader security community spends disproportionate energy attributing attacks to specific threat actors while paying insufficient attention to the conditions that make those attacks damaging in the first place. The piece focuses on what De Felice calls structural fragility — the accumulated risk created when organizations collect more data than they need, centralize it in ways that create high-value targets, and retain it long past any operational or legal requirement.

The structural problem

De Felice's argument is not that threat actor attribution is worthless. It is that attribution alone does not prevent the next incident, because the vulnerabilities being exploited are often secondary to a more fundamental problem: organizations have built environments where a single successful intrusion can expose enormous volumes of sensitive records.

For healthcare specifically, this pattern is familiar. Covered entities and business associates routinely aggregate patient records across systems for operational convenience, analytics, or legacy workflow reasons. That aggregation inflates the blast radius of any breach — ransomware, credential compromise, or insider misuse alike. The attacker's identity becomes almost incidental when the architectural conditions ensure that whoever succeeds will succeed at scale.

Root causes versus incident attribution

The piece distinguishes between incident response — what happened, who did it, how did they get in — and root-cause discipline, which asks why the organization held the data it did, in the configuration it did, with the retention schedule it did.

Under HIPAA's minimum necessary standard, covered entities are already obligated to limit data collection and access to what is required for a specific purpose. In practice, compliance with that standard is uneven. Audit logs, legacy databases, and redundant backup repositories frequently contain years of records that no longer serve any active clinical or administrative function. Those stores represent liability without corresponding operational value, and they rarely appear on remediation checklists after a breach.

What this means for incident response planning

De Felice's framing suggests that organizations conducting post-incident reviews should add a category of questions that is often absent from standard after-action reports:

• Data minimization audit. Did the affected system hold records beyond what current operations required? Could a narrower retention schedule have reduced exposure?
• Centralization review. Was sensitive data aggregated in a single environment for convenience rather than necessity? Would a more distributed or segmented architecture have limited the scope of the incident?
• Retention schedule enforcement. Are automated deletion or de-identification processes actually running, or are they documented on paper and dormant in practice?

What this signals for compliance operations

The argument carries a specific implication for HIPAA compliance programs that prioritize access controls and encryption — both necessary — while treating data inventory and retention governance as lower-priority annual checkbox exercises. If structural data accumulation is itself a risk driver, then retention governance belongs in the same operational tier as access control reviews and vulnerability management.

OCR's audit protocol already evaluates data retention practices under the HIPAA Privacy Rule, but enforcement actions on retention specifically are less frequent than those involving access failures or breach notification delays. De Felice's analysis suggests the gap between regulatory requirement and operational practice on data minimization is wider than enforcement activity alone would indicate — and that closing it is a prevention measure, not merely a compliance one.