BTW Media Intelligence

Summary

Public records describe a security incident involving National Public Data, but the largest figures in the public debate refer to alleged rows or records, not a verified count of distinct people. State notices and company-reported notification groups use different denominators and cannot be combined into a single global total.
A data broker can hold identity records about people who did not open an account with it and may not recognize its name. That absence of a direct relationship makes provenance, purpose, retention, authentication, access, correction, deletion and notice part of the security control system rather than secondary privacy questions.
A defensible remedy must be demonstrated across the full lifecycle. A notice, credit freeze, policy revision, registration fine, bankruptcy event or company statement can be relevant, but none by itself proves that affected records were accurately reconstructed, corrected or deleted, that exposed copies ceased to circulate, or that durable operational repair was completed.

The first control is the denominator

The National Public Data record begins with a measurement problem. Reports discussed datasets containing billions of rows or records. Congressional materials repeated claims associated with data offered or released by criminal actors. Those figures created an understandable sense of scale, but they did not establish a deduplicated population. A row can represent an address, an earlier address, a name variation, a historical record, a relative, or another field associated with a person who appears elsewhere in the same collection.

Several rows can describe one person, and one row can contain fields whose accuracy or subject relationship is uncertain.

That distinction is not a technical footnote. It changes what can responsibly be said about exposure, notice and remedy. Senator Charles Grassley's August 2024 letter said a hacker known as Fenice claimed a released version contained 2.7 billion records, while a lawsuit attributed to USDoD a claim involving 2.9 billion individuals. Representative Ritchie Torres's September report separately described USDoD as offering 2.9 billion rows of records for sale. None of those figures is evidence that the same number of distinct people were affected. A threat actor's description is not the company's verified denominator.

A number repeated in a complaint, oversight letter or congressional report remains bound to that procedural context. Even a company notification count answers only a narrower question: how many people the company says it identified for a particular notification group under the method it used at that time.

The public record contains several such measures. The Maine attorney general entry reports 1,300,000 total persons affected and 2,760 Maine residents. A Massachusetts annual report lists 28,761 Massachusetts residents for Jerico Pictures doing business as National Public Data and marks Social Security numbers among the exposed data. South Carolina's index reports 8,051 affected residents and a September 30, 2024 report date. The company response published by Senator Charles Grassley's office describes work on notifications to two groups, one containing 109 individuals and another containing 1,350,684 individuals.

These numbers do not share one definition merely because they concern the same incident. A state resident count, a national total submitted to a state, a notification workstream and an alleged leaked-row count can differ in date, scope, deduplication method, legal threshold and evidentiary basis. Adding them together would manufacture a denominator. Treating the smallest as the final incident scope would be equally unsound.

Accountability therefore starts with a data dictionary. For every number, an operator should be able to state what was counted, which date the count represents, which files were examined, how duplicates were handled, what confidence attached to identity matching, which jurisdictional rules applied, and which records remained unresolved. Without that discipline, the most visible number will dominate even when it is the least suitable measure of affected people.

A chronology with important gaps

The company notice published by the California attorney general uses cautious language. It says there appeared to have been a security incident involving a third-party bad actor trying to access data in late December 2023. It refers to potential leaks in April 2024 and summer 2024. It identifies suspected information including names, email addresses, telephone numbers, Social Security numbers and mailing addresses. It also says National Public Data investigated, cooperated with law enforcement and government investigators, reviewed potentially affected records, and implemented additional security measures.

Those statements establish a public notice chronology, not a complete forensic chronology. They do not reveal an independently verified intrusion path, the earliest successful access, the exact duration of access, every affected storage system, the state of encryption and key protection for each store, or the point at which each record left company control. The difference between an attempted access date, a leak date, a discovery date, a confirmed access date and a notification date matters. Each describes a different control event.

The Maine record lists December 30, 2023 as both the incident and discovery date and August 10, 2024 as the consumer-notification date. California's index identifies December 29, 2023 as the breach date and later publication of the notice. Other state records carry their own report and resident figures. These entries should be read as official records of what was submitted within each state process. They do not, on their own, reconcile every operational milestone.

That leaves several accountability questions open. What signal first indicated suspicious activity? Which owner had authority to isolate systems? When did the company determine that personal information may have left its environment? What changed between the late-December event and the potential April and summer disclosures? How did investigators connect a file or field to a person? What testing showed that access had ended? Which records could not be confidently attributed to a person or jurisdiction?

The absence of public answers does not prove that the company lacked answers internally. It does mean that outside readers cannot treat the notice as a forensic report. A credible public reconstruction should separate what the company represented, what state records show, what criminal actors alleged, what congressional offices reported, and what remains unknown. That separation is the basis for evaluating delay, not an obstacle to it.

Why a broker is different from an account provider

The central accountability issue is not simply that identity data was exposed. It is that a data broker can collect and combine records about a person who never opened an account, accepted terms or learned the broker's name. The FTC's 2014 data-broker report described an industry that assembles information from many sources and supplies products for marketing, identity verification, fraud prevention and other uses, often with limited consumer visibility. That structure creates a control problem before any breach occurs.

An account provider normally has a direct channel to its customer. It can identify an account, authenticate a person using established credentials, show account data and send a notice through a known relationship. Those controls may still fail, but the relationship provides a starting point. A brokered-record system may have no comparable channel. The person may not know which broker has a record, which supplier provided it, which fields are current, which customers obtained it, or how to prove that the record belongs to them without disclosing more sensitive information.

This changes the meaning of security. Confidentiality controls still matter, but so do provenance, purpose, accuracy, retention and contestability. If a broker cannot trace an acquired field to its source, it may struggle to determine whether the field is current or who should be notified. If it cannot explain why a record was retained, it cannot demonstrate that the exposure surface was proportionate to a legitimate use. If it lacks a workable access and correction route, an affected person may have no way to identify an error that could frustrate notification or amplify downstream harm.

The missing relationship also shifts cost. After a breach, an account provider can often place a control on an account or reset a credential. A person represented in a broker database may have to discover the broker, verify the incident, inspect credit reports, place freezes, monitor accounts and contest information across multiple institutions. The broker's acquisition model can therefore leave the person with a response burden even though the person did not choose the relationship that created it.

That is why a broker incident should be examined as a lifecycle failure test. The relevant chain begins when a record is acquired, not when an intruder appears. It continues through matching, retention, product design, customer access, system protection, logging, scope analysis, notice, correction, deletion and evidence of repair. A breach makes that chain visible, but it does not create the underlying responsibilities.

Provenance is operational evidence

Provenance answers a deceptively simple question: where did this field come from? For a sensitive identity record, a useful answer requires more than naming a supplier. It should identify the acquisition date, authority or permissible purpose, original field definition, transformation history, confidence in the person match, quality checks, downstream products and retention rule. When a broker combines several sources, provenance should survive the combination.

That evidence becomes critical during incident reconstruction. Suppose a file contains a name, an address and a Social Security number. Investigators need to know whether those fields arrived together, whether they were joined later, whether the address is current, whether the identifier was complete or partial, and whether the same person appears elsewhere. A notification system that treats every row as a person can overcount. A system that collapses records too aggressively can undercount or attach the wrong notice to the wrong person.

Provenance also defines the remediation path. If a person disputes an address, the broker should be able to locate the field, identify its upstream source, correct or annotate the downstream record, and determine which products or customers received the earlier version. A correction that changes only one display while leaving derived records untouched is not a complete correction. A deletion request that removes a current profile but leaves historical exports, development copies or reconstituted matches may not deliver the result the person reasonably expects.

Public sources do not establish the complete provenance design used by National Public Data. The responsible conclusion is not that every such control was absent. The correct question is what evidence would demonstrate that the company could reconstruct the origin and movement of affected fields. That evidence might include source inventories, ingestion logs, match rules, field-level lineage, supplier contracts, retention schedules, export records and deletion propagation tests.

Provenance is sometimes treated as a privacy or data-quality function separate from cybersecurity. The National Public Data record shows why that separation is artificial. During an incident, lineage determines scope. Scope determines notice. Notice determines who receives practical mitigation. Correction and deletion determine whether errors or unnecessary holdings remain after containment. If lineage is weak, every later control inherits uncertainty.

Purpose, access and retention define the exposure surface

A broker's database can serve multiple customers and products. That makes purpose limitation and access design central to risk. The accountable question is not merely whether a user had a valid login. It is whether the requested data, purpose, volume, method and time were consistent with an authorized use.

Controls at this layer can include customer vetting, contractual purpose restrictions, product-specific entitlements, rate limits, bulk-export controls, anomaly detection, approval for unusually sensitive queries and periodic review of dormant access. Technical logs should be detailed enough to connect an actor, credential, query, dataset and output. Those controls must also cover administrators, developers, contractors and service providers, not only customers.

Retention determines how much information remains available to be exposed. A broker may have legitimate reasons to preserve history, resolve identities or support regulated uses, but those reasons should be documented at field and product level. Keeping a sensitive identifier indefinitely because storage is inexpensive is not a retention policy. A defensible policy states why the information is needed, when that need ends, which exceptions apply and how deletion is verified across production, development, backup and exported environments.

National Public Data's response to Senator Grassley, as published by his office, contains relevant company representations. It says the company stored data in two Florida data centers and describes policies, firewalls, encryption tools, network segregation, physical controls, blocked ports, software protection, logs, passwords, monitoring and access limitation. It also refers to limited data in a development database under construction. These statements should not be ignored, but they should not be converted into independent audit findings.

The correct follow-up is evidence. Which data classes were encrypted, at what layer, with which key separation? Did the described segregation prevent one credential or network path from reaching several environments? Was sensitive production data present in development, and if so, under what minimization and masking rules? What logs existed before the event, how long were they retained, and could they support the scope conclusions? Which controls were tested after changes were made?

An accountability assessment should resist two easy extremes. It should not assume that a list of controls proves effective operation. It should also not infer from the incident that every listed control was absent or useless. Design, deployment and effectiveness are different propositions. Public confidence depends on showing how each important control was configured, tested and connected to the incident record.

Company statements must remain company statements

The company response is valuable because it places specific representations into the public record. It says an ongoing FBI investigation limited the information the company would provide. In response to a question asking whether reports that the data was unencrypted were accurate, it says various reports were inaccurate and that National Public Data used encryption tools for data; it does not identify which reports were inaccurate or establish the encryption state of every affected copy. The response also refers to limited data in a development database.

It says the database at issue was not for sale and that the company was not aware of federal agency contracts. It describes work with a third-party information-technology consultant, reduced processing, updated policies and additional safeguards.

Each statement narrows or contests part of the public narrative, but attribution is essential. Official publication by a senator's office shows that the response was received and made public. It does not independently verify the technical claims. A firewall description is not a penetration-test result. A statement about encryption does not identify the encryption boundary, key management or every copy of a dataset. A statement about no known federal contracts does not resolve every possible government-related record or downstream customer relationship.

A statement that a database was not for sale does not answer how the data was acquired, retained or exposed.

The response also illustrates the difference between investigation confidentiality and public accountability. Law-enforcement limits may justify withholding details that could compromise an active investigation. They do not eliminate the need for a later account of scope, control changes and remedy. A mature disclosure process can identify which facts are temporarily constrained, who owns their release, and when the public record will be updated.

The same rule applies to remediation claims. Hiring a consultant, reducing processing, changing a policy or adding safeguards can be meaningful actions. Their effectiveness depends on scope and verification. Which systems did the consultant assess? Which processing stopped? Did the change reduce sensitive holdings or merely pause a service? Were policies translated into technical settings? Did an independent test verify that the original access path, if known, was closed? Did the company examine development, backup and exported copies?

Responsible reporting therefore preserves three categories. The first is a public record fact, such as the existence of a response or a state filing. The second is a company representation within that record. The third is an independently verified finding. Blurring those categories creates false certainty. Keeping them separate allows the company record to inform accountability without granting it more evidentiary weight than it carries.

Scope reconstruction is a repeatable method, not a headline

After containment, the central operational task is to determine what was accessed and whom it concerned. For a broker, this is unusually difficult because rows, files and people are not interchangeable. A reliable method must define each unit and show how investigators moved between them.

The process might begin with affected systems and time windows. Investigators identify storage locations, access paths, logs, exports and suspicious activity. They then identify candidate files and data fields. Next comes identity resolution: linking rows to people, detecting duplicates, handling historical addresses and separating records that cannot be confidently matched. Jurisdictional rules then determine which people require which notices. Each transition should preserve uncertainty rather than forcing every record into a false binary.

The public figures demonstrate why this matters. An alleged multi-billion-row dataset, the Maine total, state-specific resident counts and the two notification groups described by the company may all be accurate within their stated definitions and still differ substantially. A credible reconciliation would explain the relationships among them. It would say whether one figure superseded another, covered a subset, used a later deduplication method, represented a separate file, or reflected a different legal threshold.

Repeatability is the standard. Another qualified analyst should be able to apply the documented method to the same inputs and understand why a person was included, excluded or left unresolved. That does not require publishing personal data. It requires publishing enough methodology to test the logic: match criteria, duplicate handling, confidence thresholds, jurisdiction mapping, review procedures and quality checks.

The unresolved population deserves explicit treatment. Records may lack a current address, contain conflicting identifiers or represent deceased people, relatives or historical household members. Those cases should not disappear from the report merely because notice is difficult. The operator should state how many records remained unresolved, what work continued, which safeguards applied in the meantime and whether later discoveries would trigger supplemental notice.

Scope reconstruction is therefore both a forensic and a governance control. It measures whether the broker knew its own data well enough to account for it under pressure. The output should be more than a final number. It should be a traceable explanation of how that number was produced and what it leaves uncertain.

Notice can transfer work without repairing the record

The California notice recommends monitoring accounts, obtaining credit reports, placing fraud alerts or credit freezes, and using IdentityTheft.gov if misuse occurs. Those measures can reduce some forms of downstream risk. They do not recover a leaked dataset, prove that exposed copies no longer circulate or correct the broker's underlying record.

This distinction matters because notice is often treated as the end of an incident response. From the recipient's perspective, it can be the beginning of unpaid work. A person may need to verify that the message is authentic, learn what National Public Data is, determine which information was involved, place controls at several credit bureaus, monitor accounts, preserve documents and respond to later misuse. The burden can be especially high when the person never chose the broker relationship.

Maine's record states that identity-theft protection services were not offered. That is a specific filing field, not a universal account of every support channel or every later action. It nonetheless highlights the difference between warning and assistance. A notice can tell a person to act while offering limited help with the cost, time and complexity of that action.

An accountable notice should answer more than what happened in general. It should identify the broker and its role, the data categories reasonably associated with the recipient, the period covered, the basis for the recipient determination, practical contact routes, available support, and how the person can inspect or challenge the underlying record. It should avoid inflated global figures that obscure the recipient's actual situation. It should also state uncertainty where the company cannot determine whether a particular field was accessed.

Notice quality should be measurable. Useful measures include delivery rate, returned-mail rate, language accessibility, call response time, authentication failure, correction requests, dispute resolution time, deletion requests, fraud-support cases and supplemental notices. These measures connect communication to outcome. Without them, an operator can report that notices were sent without showing whether people could use them.

A credit freeze is one tool, not a remedy for the brokered record itself. It may limit new-account activity, but it does not tell the person where the data came from, whether it is accurate, who received it or how long it will remain in broker systems. Durable repair requires those questions to have an answer.

Access, correction and deletion are incident controls

The FTC's data-broker report emphasized transparency, access and correction because errors in brokered profiles can affect people who have little visibility into the process. A security incident strengthens the case for treating those functions as operational controls. If the company cannot show a person the record connected to a notice, the person cannot identify a mismatch. If it cannot correct an error across linked systems, future notices and products may repeat it.

Authentication is the difficult part. A broker should not expose more personal information while trying to verify a request. Yet a person without an account cannot rely on an existing credential. The system needs a proportionate method that protects against impersonation, supports people with thin or changing records, allows appeal, and records why a request was accepted or rejected.

Correction requires propagation. A field may exist in a current profile, a historical table, a development copy, a customer export or a derived score. An operator should define which entities can be corrected, which must be preserved for legal reasons, how corrections flow downstream and how the person is informed. If an upstream supplier caused the error, the broker still needs a route to contain the error while the supplier dispute proceeds.

Deletion has similar complexity. The applicable right can depend on law, data type, purpose and exemption. The existence of exceptions does not justify treating every request as impossible. An accountable system records the request, identifies the governing rule, removes data where required, prevents automatic reacquisition where appropriate, verifies propagation and explains any retained elements. It should distinguish deletion from suppression, archival retention and a temporary processing pause.

Public sources do not establish how National Public Data handled every access, correction or deletion request before or after the incident. The relevant accountability standard is evidence of a usable route. How many requests were received? How were people authenticated? How long did decisions take? How often were requests rejected, and on what grounds? Were downstream products and recipients updated? Could an individual appeal a mismatch?

These are not peripheral service metrics. They test whether a broker can restore control to a person whose information entered the system without a direct relationship. In that sense, access, correction and deletion are part of incident recovery. They reduce the chance that an inaccurate or unnecessary record continues to create risk after technical containment.

Oversight questions are not findings

House and Senate letters in August 2024 asked about the scope of the incident, data storage, encryption, government exposure, sales, known vulnerabilities, retention and remediation. Those questions identify legitimate areas of concern. They do not establish the answer by being asked.

The distinction is important because oversight documents often compress allegations, press reports and constituent concerns into a request for information. A responsible account should attribute each proposition and track the response. Where the company supplied an answer, the answer remains a company representation. Where it declined or deferred because of an investigation, the gap remains open. Where no public response is available, speculation should not fill it.

Representative Ritchie Torres later released an investigative report with claims and policy conclusions about the National Public Data incident. The report is part of the oversight record and can be compared with state notices and the company response. Its references to dataset scale and timing still require the same denominator discipline. Congressional publication does not convert a criminal actor's row count into a verified population.

Oversight is most useful when it produces a traceable issue register. Each question should have an owner, response status, evidence basis and closure condition. Questions about encryption should distinguish data at rest, data in transit, application-layer protection and key management. Questions about retention should identify data class and purpose. Questions about government exposure should define whether the concern is a contract, an employee record, a public-record source or another relationship.

That structure also protects against selective closure. An operator might answer that no federal contracts were known while leaving open whether federal employees' records appeared in a dataset. It might describe firewall controls without explaining the access path. It might report a notification total without reconciling unresolved records. Each answer should close the precise question it addresses and leave other questions visible.

The purpose of oversight is not to guarantee a dramatic finding. It is to make responsibility and evidence legible. Questions that remain unresolved can still improve accountability if their status is explicit and if a later update shows what changed.

Litigation establishes allegations and procedure, not automatic liability

The federal court record confirms the existence and caption of Hofmann v. Jerico Pictures. The available GovInfo document addresses a procedural extension. It does not adjudicate the factual allegations in the complaint. That boundary must be preserved.

Litigation can bring important claims into public view, including allegations about how a person learned of exposure and how a dataset was described. But a complaint is one party's pleading. A procedural order may set deadlines or manage a case without deciding whether the alleged conduct occurred, caused harm or violated a duty. Reporting that collapses those stages can misstate both the evidence and the legal process.

The accountability analysis does not depend on predicting a case outcome. The public record already supports operational questions about provenance, retention, security, scope and remedy. Litigation adds another route through which evidence may be requested and tested, but the existence of that route is not proof of liability or compensation.

This discipline also applies to individual loss. Identity data exposure can create serious risk, but public sources do not establish that every person associated with a record suffered fraud or that a particular later event was caused by this incident. Claims of misuse require their own evidence. Population-level risk should not be turned into an unsupported individual causal statement.

Procedural precision is part of accountability because it prevents remedy from becoming rhetorical. A filed claim, a pending case, a settlement framework, a judgment and a paid recovery are different events. The public should be able to see which occurred and what question it resolved. If a case later establishes findings or produces relief, that later record should update the analysis. Until then, allegations remain allegations.

Registration is a separate accountability track

The California Privacy Protection Agency's record concerns data-broker registration. In February 2025, the Enforcement Division alleged that Jerico Pictures registered as a California data broker on September 18, 2024, 230 days after the January 31 deadline and only after the division contacted the company during an investigation. In May, the agency said its board issued a default order after the company failed to challenge those allegations and ordered the company to pay a $46,000 fine for failing to register and pay the annual fee.

The agency explicitly treated this as a Delete Act registration matter separate from the data breach. That separation prevents two errors. The first would be to ignore registration as irrelevant. A registry can help people and regulators identify a broker, understand its declared business and locate a route for rights or complaints. Public identifiability matters when a person has no direct relationship with the company.

The second error would be to convert the registration order into a finding about breach causation or technical security. A late registration does not prove how an intruder obtained access, whether a particular control failed, or which data was exposed. The default order addressed the registration obligation before it, not every issue raised by the incident.

This is a useful model for layered accountability. Security, privacy rights, registration, litigation and financial proceedings can involve the same company while applying different standards and evidence. Each track should state its jurisdiction, question, findings and remedy. Combining them into one narrative of guilt may be rhetorically simple but analytically weak.

Registration also has an operational dimension. A current registry entry can establish contact details, ownership information and a public declaration that survives ordinary marketing changes. It can support notice, deletion mechanisms and regulator coordination. Its value depends on accuracy, timeliness and enforcement. A registry that people cannot use or that remains outdated after organizational changes offers limited accountability.

The CPPA record also refers to a bankruptcy claim and says the bankruptcy petition was dismissed. A bankruptcy filing, dismissal, regulatory claim and administrative fine are distinct legal events. None proves that affected people were compensated, that a technical repair was completed or that residual identity risk ended.

The CFPB proposal is a withdrawn policy record, not current law

In December 2024 the Consumer Financial Protection Bureau proposed changes under Regulation V concerning data brokers and the Fair Credit Reporting Act. Its materials described brokers that collect, aggregate, sell, resell, license or otherwise share consumer information. They discussed identifiers, financial and background information, permissible purpose, file access and dispute rights.

The proposal did not become a final rule. The Bureau withdrew it in May 2025. Any account written after that withdrawal must state both facts. Presenting the proposal as current binding law would be wrong. Omitting the withdrawal would leave readers with an inaccurate procedural picture.

The withdrawn proposal still has limited analytical value as a dated policy record. It identifies control surfaces that also appear in the National Public Data incident: who qualifies as a broker, when information functions as a consumer report, what purpose permits access, how a person can see a file, and how disputes are handled. Those questions can guide an accountability assessment without being described as legal obligations created by that withdrawn rulemaking.

The distinction between law and control design matters. A company may face duties from several statutes, state laws, contracts and enforcement regimes. The available record does not resolve which rule applies to every record or use. The accountability question is what evidence a responsible broker should be able to produce to explain acquisition, purpose, retention, access, accuracy and remedy. Some evidence may be legally required in a specific context; other evidence may be necessary to support a public claim of durable repair.

The FTC's earlier report offers a broader transparency context. Together, the FTC record and the withdrawn CFPB proposal show sustained policy concern about a market in which people can be represented without direct visibility. They should not be merged into one current mandate. They are separate records that help define the practical questions a broker incident exposes.

Remedy must be divided into distinct outcomes

The word remediation can hide several different activities. Immediate containment seeks to stop unauthorized access. Technical repair changes systems and controls. Consumer mitigation reduces the likelihood or impact of downstream misuse. Data repair corrects, deletes or limits records. Regulatory compliance satisfies an obligation such as registration. Financial remedy compensates or supports affected people. Governance repair changes ownership, testing and reporting so that improvements persist.

These outcomes should not substitute for one another. A credit freeze can help with some new-account fraud but does not remove data from a broker database. A policy update does not prove deployment. A fine enforces a registration rule but does not show that access controls were fixed. A bankruptcy event does not compensate people by itself. A notice can inform while leaving the recipient to carry most of the work.

The company described additional safeguards, reduced processing and work with a consultant. A credible closure report would connect those actions to measured outcomes. It would state which systems changed, which data was removed or segmented, which tests were run, what exceptions remained, and who independently reviewed the result. It would also state what could not be verified.

Consumer outcomes require similar evidence. How many people received notice? How many notices were returned? What support was offered? How many people requested access, correction or deletion? How quickly were requests resolved? Did the company identify records after the first notification groups and issue supplements? Were people told when their record could not be confidently reconstructed?

Residual risk should be explicit. An operator cannot credibly promise that every exposed copy has been recovered unless it has evidence to support that claim. It can describe steps to reduce future misuse, monitor known dissemination, improve affected-person support and reduce its retained data. Acknowledging residual risk is not an admission that repair is pointless. It is a condition of honest repair.

Accountability is strongest when each remedy has an owner, deadline, metric and verification method. That structure lets the public distinguish activity from completion. It also prevents an impressive action in one track from obscuring an unresolved failure in another.

What measurable repair would look like

A durable repair program for brokered identity records would begin with an inventory that connects every sensitive field to an origin, purpose, owner, product and retention rule. The inventory would identify transformed and derived data rather than treating them as disconnected copies. It would support review of suppliers and downstream customers and show when a record should no longer be used.

Security evidence would include segmentation between production and development, minimization of sensitive data in non-production systems, encryption with documented key separation, privileged-access controls, customer and administrator logging, export monitoring, anomaly detection and retention of the logs needed for reconstruction. Testing would cover both design and operation. Exceptions would have owners and expiration dates.

Scope evidence would document affected systems, time windows, files, fields, row counts, identity-resolution methods, duplicate handling, jurisdiction mapping and unresolved records. The method would be reproducible. Changes to the denominator would be versioned and explained rather than silently replacing earlier figures.

Notice evidence would connect a person determination to a delivery result and support channel. It would measure returned notices, accessibility, call response, authentication failures and supplemental communications. It would explain which fields were involved without revealing more sensitive information.

Rights evidence would show that people can discover the broker, authenticate proportionately, inspect records, dispute errors and request deletion where available. Metrics would include request volume, completion time, rejection grounds, appeal outcomes and propagation to derived records or downstream recipients. The process would distinguish a lawful retention exception from an unexamined refusal.

Governance evidence would identify accountable executives and control owners, independent test results, board or senior-management review, regulator status, registry currency and public follow-up dates. A company should be able to show not only that a change was announced but that it remained effective after ordinary operations resumed.

No public source proves that all of these controls were absent at National Public Data or that all were later completed. They are the evidence tests that follow from the public record. That qualification is important. Accountability analysis should not invent an internal failure merely because the evidence needed to verify a repair is not public. It should identify the gap and state what would close it.

Responsibility follows practical control

Responsibility in a broker ecosystem is distributed, but it is not therefore ownerless. The broker controls acquisition choices, matching, retention, product design, customer access, security architecture, logging, scope analysis, notice and the route for individual requests. Data suppliers control parts of provenance and accuracy. Customers control purpose and downstream use. Service providers may operate infrastructure. Regulators define and enforce particular obligations. Credit bureaus and financial institutions operate some mitigation tools.

The fact that several actors participate does not mean each has the same knowledge or authority. An accountability map should assign each control to the actor able to change it. A supplier cannot configure the broker's access logs. A recipient cannot delete the broker's retained source file. A regulator does not operate the company's incident response. A person placing a freeze cannot correct the broker's lineage.

This mapping matters when organizations rely on third parties. A contract can allocate tasks, but it cannot erase the operational dependency. The party choosing a service or supplier remains responsible for verifying whether the arrangement protects the data and supports reconstruction. The service provider remains responsible for the controls it operates. Evidence should show how their logs, incident roles and notification duties connect.

The company response's reference to a third-party consultant should be assessed in this framework. A consultant can provide expertise and independent challenge, but the scope, evidence and authority of the engagement matter. A review limited to one environment cannot support a claim about every store. A recommendation does not prove implementation. Management retains responsibility for deciding, funding and verifying the change.

Responsibility also continues after the public attention fades. Retention schedules, access reviews, registry updates, deletion mechanisms and control tests are recurring functions. A one-time response cannot substitute for them. Durable accountability means that an auditor can return later and find the same control chain operating with current evidence.

The accountability standard

The National Public Data record should not be reduced to a contest over the largest number. The allegation of billions of rows is important because it signals the potential scale and complexity of the dataset. It is not a verified affected-person count. The state records and notification groups provide more specific measures, but they remain bounded by their definitions. A responsible account holds those measures apart until a documented reconciliation connects them.

The more enduring issue is the broker relationship that many people may never have recognized. A person can be represented, matched, retained and exposed without an account through which to see or correct the record. That makes provenance, purpose, retention, access and contestability part of the security architecture. It also means a notice can arrive without the context or relationship needed to make it usable.

The public company response, oversight record, state notices, litigation file, CPPA action, FTC report and withdrawn CFPB proposal each answer a different question. None should be asked to carry more weight than it can. Company claims require attribution. Oversight questions are not findings. A procedural order does not decide allegations. Registration enforcement is separate from breach causation. A withdrawn proposal is not current law.

The final test is whether practical control produced verifiable repair. Can the broker trace a field to its source? Can it justify retention? Can it show who had access and what left the environment? Can it reproduce the method that moved from rows to people and notices? Can a person inspect, correct or delete a record through a usable process? Can independent testing show that technical and governance changes persisted? Can the public distinguish completed work from residual risk?

If those answers exist only as assurances, accountability remains incomplete. If they exist as durable, reviewable evidence, the response can begin to repair more than an incident. It can repair the control relationship between a broker and the people whose identities give the brokered records their value.

Sources

Access checked: 2026-07-24