YOU VERIFIED THE ID. WHY DID YOU KEEP THE COPY?

An identity check is usually sold as a moment. Show the document. Prove the age. Match the name. Open the door. Complete the transaction. The person leaves believing the exchange is over.

The machine may experience something else entirely. It reads a barcode or machine-readable zone, converts it into text, maps fields into an application, perhaps captures document images, writes a timestamped log, synchronizes the record to a cloud account and leaves exportable data behind. A ten-second verification becomes a data lifecycle that can outlive the purpose, the customer relationship and the device that performed the scan.

IDScan.net's September 4 breach notice makes that lifecycle impossible to treat as an abstraction. The company says it learned on or around September 1 that certain data may have been accessed without authorization. It engaged third-party specialists and secured its systems. Its ongoing investigation determined that an unauthorized party may have accessed or copied certain customer information stored within customer accounts in the IDScan.net cloud. The information may include full names and driver's-license or other government-issued identification numbers.

The notice does not publish a final count. It does not say every customer was affected. It does not say that every record contained an image of an identity document. It does not identify the access path, the duration, the responsible actor, the encryption state or the customers whose retention choices placed information in the affected environment. Those are not minor omissions to fill with rumor. They define the incident's actual scope.

Before IDScan.net posted the notice, the public story began with a dark-web marketplace. Reuters reported on September 2 that the FBI was examining a report that tens of millions of U.S. and Canadian driver's licenses were for sale. Journalist Brian Krebs said he verified records with nine people and found his own license offered as a sample. The seller also claimed other identity cards, travel documents and medical records. Reuters could not establish the source of the data at that stage, and the marketplace disappeared after the reporting.

The later company notice is important evidence. It is not permission to merge every seller claim into a confirmed IDScan.net breach inventory. The notice confirms a possible unauthorized access or copying event involving customer information in IDScan.net's cloud and identifies some possible fields. It does not adopt the marketplace's counts or full menu of document categories. A defensible investigation keeps those ledgers separate until technical findings connect them.

That restraint still leaves a hard question for every identity-verification system: after you proved the thing you needed to prove, why did you keep the underlying identity data?

Verification and retention are different operations.

IDScan.net's own product documentation is unusually useful because it lays out the mechanism. A scanner or phone camera reads the barcode on a driver's license or the machine-readable zone on a passport. The service parses the encoded material into fields. For driver's licenses, the available field list can include name, street address, date of birth, physical descriptors, expiration date and ID number. The product can analyze barcode structure and, when images are captured, other security features. Parsed fields can then be sent into another application.

None of that inherently requires permanent storage. A system can process information transiently, produce a decision and discard the source. “Over 21: yes,” “document not expired,” “name matched account,” or “visitor credential valid until 5 p.m.” are derived results. They are not the same thing as retaining a document image, a raw barcode string and every parsed field.

IDScan.net says its VeriScan and DIVE products let customers set retention lengths and field-level policies. It also advertises timestamped scan logs that can be queried and exported. Those capabilities do not establish how any affected customer configured the service. They establish that retention is a controllable part of the system rather than an unavoidable consequence of scanning.

This distinction matters because businesses often bundle four different purposes under one word: verification. One purpose is eligibility—whether someone is old enough or holds a valid credential. Another is transaction evidence—whether the business can later show that it performed a required check. A third is account identity—whether a continuing customer is the same person. A fourth is investigation—whether a suspicious event needs preserved evidence. Each purpose can justify a different record. None automatically justifies keeping everything the scanner can read.

The minimum record follows the claim.

Suppose a venue needs to establish that a patron met an age threshold. The operational claim is not the patron's full date of birth, home address, height, weight and license number. It is that an approved method produced an age-over-threshold result at a particular time, perhaps with an audit reference and device identity. If local law requires more, the business should be able to name the rule and the additional field it requires. “The scanner collected it” is not a retention purpose.

Visitor management is similar. A facility may need a name, host, arrival time, authorization state and an expiring badge. It may need to compare the presented document with the visitor. That does not mean the facility needs a reusable copy of the driver's license after the visit closes. A high-security site may have stronger evidentiary duties, but stronger stakes call for a documented schedule and access controls—not an unbounded default.

Financial onboarding and regulated identity checks can require more. Institutions may need to retain specified evidence for a defined period, investigate fraud and answer audits. The proper question is not whether retention is ever legitimate. It is whether each retained element is tied to an actual duty, isolated to that purpose and deleted when the duty ends. A legal requirement to preserve proof is not a universal order to keep a high-resolution document image in every operational database and backup.

Fraud review creates a genuine exception path. A suspicious document may need to be preserved for an active case, dispute or law-enforcement request. The exception should be visible as an exception: case-bound, authorized, time-limited and auditable. If every ordinary scan is retained indefinitely because one future record might become interesting, the exception has silently become the architecture.

The practical test is simple enough to be uncomfortable. For every field, ask what decision it supports, who can use it, where it travels, when the need ends and what process proves deletion. If the answer is a vague mixture of analytics, convenience and “just in case,” the organization is accumulating identity risk without a measured return.

A copy multiplies into a system.

Deleting the obvious database row is not the same as deleting the data. Identity information can exist in the original image, parsed fields, raw barcode output, validation results, application logs, support tickets, exports, analytics tables, caches, replicas and backups. SDK customers may send the record into their own software, adding another retention regime outside the scanning provider's direct control. A customer can configure a short cloud retention period and still keep an exported spreadsheet forever.

This is why a retention policy must describe data flows rather than merely announce a number of days. The clock needs a start event. Deletion needs to cover derived and duplicate stores according to their purpose. Backups need an expiration model that prevents a deleted identity warehouse from reappearing during restoration. Exports need controls and owner attribution. Service providers and customers need to know which side is responsible for each copy.

Encryption matters, but it does not answer the retention question. Strong encryption at rest can reduce exposure from stolen storage media and some classes of infrastructure compromise. It may do little when an intruder gains application-level access that legitimately decrypts records for an authenticated user. Tenant isolation matters for the same reason: compromise of one customer's credentials should not expose another customer's archive. The public notice does not currently provide enough information to evaluate either control.

Derived assertions can reduce the prize, but they need competent design. A business can store an age-threshold result instead of a birth date, a document-expiration state instead of the whole number, or a transaction-bound verification token instead of a reusable image. If it needs to recognize repeated use of the same identifier, a keyed cryptographic transform may be safer than plaintext. A plain unsalted hash of predictable license numbers can often be guessed; changing the representation without changing its recoverability is not minimization.

The goal is not to make a breach harmless. Names, timestamps and access events can still be sensitive. The goal is to make the breach reveal no more than the business genuinely needed to remember.

The strongest case for keeping data is operational—and incomplete.

Vendors and customers have reasonable objections to aggressive deletion. A retained record can help reverse fraudulent transactions, resolve chargebacks, demonstrate compliance, investigate a banned patron, maintain a visitor history or improve detection models. Immediate deletion can frustrate legitimate audits. Fragmented local storage can be less secure than a professionally managed cloud. A configurable platform can give customers a better way to enforce policy than improvised spreadsheets and photocopies.

All true. None supports indefinite, undifferentiated retention. The benefits differ by use case and decay over time. A transaction dispute has a window. A visitor credential expires. An investigation closes. A statutory record period ends. Model improvement can often use redacted, sampled or separately consented material rather than the live identity archive. The burden is to connect the retained record to the benefit and show that a less dangerous representation will not do the job.

Centralization also has two directions. It can concentrate professional security controls, monitoring and expertise. It concentrates the reward for an attacker at the same time. The correct comparison is not “cloud secure, local insecure” or its reverse. It is the full architecture: amount retained, tenant boundaries, privilege model, key management, detection, export control, deletion and the number of identities exposed by one successful path.

The breach review needs a retention ledger.

A conventional incident report will ask how the actor entered, what systems were reached, when access began, what was taken and whether persistence remains. This incident needs another table beside it. For each affected customer and record class: what purpose caused collection, which fields or images were stored, what retention setting applied, whether the setting was enforced, where exports went and how many records would have been absent under the customer's stated policy.

That last number is the preventable exposure. It separates the harm created by intrusion from the harm magnified by accumulation. An organization may not be able to prevent every breach. It can decide whether a successful intruder finds last week's necessary records or a decade of identities nobody remembered to delete.

The public also needs a reconciled account of the dark-web claims. Which samples match affected IDScan.net tenants? Do timestamps, document formats or internal fields establish provenance? Were records current because the access was continuing, because customers kept uploading, or because the seller combined multiple sources? Did the dataset contain document images, parsed fields or both? Until those questions are answered, maximal numbers belong under REPORTED, not KNOWN.

For potentially affected people, IDScan.net offers credit monitoring and identity-protection services and recommends watching credit reports and account statements, placing fraud alerts or freezes where appropriate, and using Federal Trade Commission resources. Those steps can reduce some financial identity-theft risk. They cannot rotate the biographical data printed on a driver's license as easily as a password. That durability is another reason the collection decision deserves more scrutiny than an ordinary credential reset.

What would change this assessment?

A final forensic report could narrow or broaden the event. The important evidence includes the affected record count, exact fields and images, access dates, authentication path, tenant scope, encryption and key exposure, export logs, deleted-record status and the relationship to the marketplace samples. Customer-specific notices should distinguish records retained by configuration from records retained for platform operations or backup.

Evidence that the affected environment held only recent, purpose-bound records with enforced deletion would show minimization containing the blast radius. Evidence that customers had selected short retention but old records remained would move the problem toward platform enforcement. Evidence of long default retention, uncontrolled exports or broad cross-tenant access would make accumulation a central cause of harm. The notice does not yet let us choose among those models.

The question in the headline is therefore not a verdict on every copy. It is an audit demand. Verification proves something at a moment. Retention creates a continuing liability. Every organization that scans an identity document should be able to explain the bridge between the two in field-level, time-bound terms.