After the FTC’s Log4j warning, the response record was the defense
The FTC’s January 2022 warning tied Log4j remediation to its reasonable-security standard. Reasonableness is judged later, from records, so the decisive work was documenting the response while it happened, including what vendors said and when.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
The week
On January 4, 2022, the Federal Trade Commission published a statement urging companies to remediate the Log4j vulnerability disclosed the previous month. The FTC said that failing to take reasonable steps to mitigate known software vulnerabilities could violate laws including the FTC Act and the Gramm-Leach-Bliley Act. It said it intended to use its full legal authority against companies that failed to protect consumer data from exposure through Log4j or similar known vulnerabilities. The statement cited the FTC’s earlier action against Equifax, whose 2017 breach followed a failure to patch a known flaw. It also pointed companies to CISA’s guidance and asked them to pass information to downstream users of their software. Regulators rarely address a single vulnerability by name, and this statement was unusually direct.
The FTC did not tell companies how to fix Log4j. CISA and the software makers had done that. What the commission added was a reminder of how it would judge the response afterward. Its standard is reasonable security, assessed in light of the data held, the size of the business and the risks it faces. An investigation into a breach that happens months later can only test that standard against what the company can show. So the practical effect of the warning fell on records: who knew what, when, and what they did about it. We look at three parts: who the warning reached, what a reasonable response to a known vulnerability looks like, and what record proves it.
Who the warning reached
Section 5 of the FTC Act covers unfair or deceptive practices by most commercial businesses. It does not generally reach banks, savings associations or federal credit unions, which answer to their own regulators, and it reaches few nonprofits. It does cover non-bank financial firms through the Safeguards Rule, for-profit health care companies, health and wellness apps, and the large population of software and service vendors that sell into regulated industries.
That last group carries the warning back to banks, health systems and agencies. A core processor’s subsidiary, a patient engagement platform, a payments startup or a document management vendor may sit under FTC jurisdiction even when its client does not. If such a vendor left Log4j exposed and lost client data, the vendor faced the FTC and the client faced its own examiner, who would ask how the vendor had been overseen. The same event could open two inquiries with two standards. Organizations should check with counsel which regulator covers each entity in their group and each critical vendor.
What a reasonable response looks like
The FTC has never required perfect security. Its orders over two decades describe a program: risk assessment, access controls, patch management, monitoring, vendor oversight and someone accountable for all of it. Applied to a single vulnerability, the standard breaks into a sequence. Did the organization learn of the flaw promptly? Did it search for affected systems in proportion to the risk, starting with internet-facing services and those holding consumer data? Did it remediate or mitigate on a timeline that matched the exposure? Did it ask vendors and follow up when answers were vague?
None of those steps requires that every instance be fixed on day one. Log4j made that impossible for most large estates, since the first fixed release was itself incomplete and further releases followed within weeks. Consider a company that patched its public web applications in days, mitigated the rest with configuration changes and network rules, and worked through its vendor list over January. It is in a very different position from one that waited for a quiet moment. The gap between those two companies is visible only in their records.
Reasonableness also has a forward edge. Each step depends on capabilities that cannot be built during an incident. They include an asset inventory that includes software components, a vendor list ranked by data access, and a channel for receiving security statements. A company that lacked them in December 2021 could still act reasonably in January by building them and recording that it had. A company that lacked them again a year later would have a harder argument.
What record proves it
In December 2021 much of the work happened on calls and in chat. Spreadsheets were edited and overwritten. Vendor answers arrived in individual inboxes, some from account managers rather than security teams. Three months later, few organizations could say with confidence when a given server was patched or which vendor statement they had relied on. That is the record a regulator, auditor, plaintiff or insurer would ask for.
A defensible record has a small number of parts. It needs a dated log of when the organization learned of the flaw and who was assigned. It needs the scope of the search and its method, such as repository scans, file-system scans and vendor inquiries, with what each found. Each remediation or mitigation needs a date, an owner and a verification step. Exceptions need someone who accepted the risk and a date to revisit it. Vendor inquiries need the date sent, the answer received, its source and any follow-up.
The simplest way to produce that record is to run any major vulnerability response as a declared incident. It belongs in the same tracking system used for intrusions, not in the change queue as a patching project. That brings a named lead, a single ticket hierarchy and a closing summary. The trade-off is overhead. Declaring incidents for every critical vulnerability would bury the team, so the trigger should be explicit: active exploitation plus broad presence, or a regulator naming the flaw.
The vendor record has a second use. It shows which suppliers answered quickly, completely and with version-level detail, and which did not. That evidence belongs in renewal discussions and in the risk tier assigned to each vendor. It also supports a reasonable contract ask: a vulnerability statement within a set number of days of a widely exploited disclosure.
With hindsight
As far as public records show, the FTC never brought a prominent case based specifically on Log4j. The statement still described where enforcement went. In October 2022 the commission’s order against the alcohol delivery company Drizly bound its chief executive personally to security obligations, including at future companies. Later orders required specific controls such as multifactor authentication and data retention limits, and from 2023 the FTC enforced its Health Breach Notification Rule against health apps. Other regulators moved the same way. The SEC’s 2023 disclosure rules made the timing of a materiality determination something companies must be able to show. By this point in 2026, running major vulnerability responses as tracked incidents is common practice in regulated firms, partly because they expect to be asked for the record. The January 2022 statement was an early, plain signal that the record would decide how a response was judged.