What Does Privacy Mean in ID Verification?

Identity verification is designed to answer a relatively simple question: is this person sufficiently likely to be who they claim to be for the purpose of this transaction?rn

The technology used to answer that question can be much less simple. A verification process may inspect an identity document, validate document security features, read machine-readable information, compare a selfie with a photograph on an ID, perform liveness checks, query trusted data sources, evaluate device or network signals, and send the resulting decision back to the business.rn

Each step can involve personal information. Privacy therefore has to be considered across the process rather than added at the end through a generic privacy notice.rn

A useful way to think about privacy is to separate the verification result from the evidence used to produce that result. A business might genuinely need to know that a customer is over a required age, for example. That does not automatically mean the business needs to retain a copy of the person's passport, full date of birth, facial image, home address, and identification number indefinitely.rn

Where the technology allows it, businesses should consider whether a narrower result can meet the business purpose. An answer such as “age requirement met,” “document validated,” or “identity verification passed” may create less privacy exposure than transferring every underlying identity attribute to every downstream system.rn

This distinction matters because the privacy cost of an identity system is influenced by both the amount of information collected and the number of places where that information is copied.rn

ID Verification Is Not the Same as Authentication

The terms are often used interchangeably, but they solve different problems.rn

Identity verification or identity proofing establishes confidence that a person corresponds to a claimed real-world identity. This is typically performed during onboarding, account recovery, regulated transactions, or another event where identity assurance is required.rn

Authentication determines whether someone accessing an account or service is the authorized account holder or credential user. Passwords, passkeys, security keys, authenticator apps, and other authentication factors normally operate after an identity or account relationship has been established.rn

This distinction affects privacy decisions. A business may need stronger identity evidence during an initial high-risk enrollment but should not automatically repeat full document and biometric verification every time the customer signs in.rn

Requiring users to repeatedly expose high-value identity data when a lower-data authentication method would provide sufficient assurance increases collection without necessarily creating a proportionate security benefit.rn

What Personal Data Can ID Verification Collect?

The exact information depends on the verification method, jurisdiction, industry, risk level, and provider. Businesses should map the actual data fields in their own workflow rather than relying on a provider's broad statement that it processes “identity information.”rn

Government-issued identity document data

Passport, driver's license, national identity card, or residence permit verification may expose a person's name, date of birth, address, document number, nationality, photograph, expiration date, issuing authority, document type, and other information printed or digitally encoded on the document.rn

Some of those fields may be irrelevant to the transaction. A document can contain more information than a business needs simply because the information happens to appear on the same page.rn

Images and document copies

Verification systems commonly capture photographs or scans of documents. These files deserve special attention because the raw image may contain considerably more information than the structured fields eventually extracted from it.rn

Businesses should know whether the raw document image is retained, whether cropped images are created, whether metadata survives processing, and whether copies are stored by both the verification provider and the business.rn

Selfies, video, and biometric information

A face-matching workflow can collect a selfie or video and technically process facial characteristics to compare the live person with the portrait on an identity document. Depending on the jurisdiction and processing purpose, that information may receive additional legal protection as biometric data.rn

It is important to distinguish an ordinary image from information created through biometric processing. However, businesses should not assume an image is low-risk merely because a biometric template is deleted later. The original photograph or video remains sensitive personal information and may still create meaningful privacy and security exposure.rn

Device and network information

Fraud prevention may also use IP addresses, browser attributes, device identifiers, operating-system information, approximate location, session information, velocity signals, proxy or VPN indicators, and patterns suggesting automation or device manipulation.rn

These signals may be useful for detecting fraud, but they should still have a defined purpose. Device intelligence should not silently turn a one-time identity check into unrelated behavioral tracking.rn

External data-source matches

Some verification processes compare submitted information with trusted databases, records, identity networks, mobile data, credit-related sources, or other third-party information. A business should understand whether the provider receives a simple match result or obtains additional personal information from those sources.rn

Verification and fraud results

The output itself is also data. It may include a pass/fail decision, confidence score, document authenticity result, facial similarity score, liveness result, reason codes, suspected fraud indicators, or a recommendation for manual review.rn

These outputs can affect whether a person receives access to a product or service, so businesses should protect them and consider how errors can be challenged.rn

Why Identity Verification Creates Unusual Privacy Risk

Most businesses hold personal information. Identity verification is different because it can concentrate several high-value data types in the same transaction.rn

A compromised email address can often be changed. A password can be reset. A face, date of birth, government identification number, and historical identity document are much harder—or impossible—to replace in the same way.rn

That raises the consequences of excessive collection and retention.rn

Identity theft and impersonation

Document images and identification numbers can become useful material for criminals when exposed. A database containing identity documents can therefore present a different risk profile from a database containing ordinary marketing preferences.rn

Function creep

Information collected for account verification can gradually be reused for analytics, advertising, model training, profiling, employee monitoring, or other purposes that were not part of the original user expectation.rn

The fact that the data is technically available does not mean every later use is appropriate. Purpose boundaries should be set before the system is deployed.rn

Biometric permanence

Biometric characteristics are closely associated with the individual. This makes unnecessary storage of reusable biometric templates or similar information especially sensitive.rn

False rejection

Privacy is not limited to confidentiality. An identity system can also cause harm when it incorrectly rejects a legitimate person and the business provides no realistic alternative.rn

Poor image quality, damaged documents, accessibility needs, device limitations, name changes, transliteration differences, or algorithmic performance can all create legitimate verification failures.rn

Third-party exposure

Many companies outsource ID verification. Outsourcing the technology does not make the privacy issue disappear. Personal information may pass through processors, infrastructure providers, fraud-data partners, subprocessors, customer-support tools, logging systems, and backup environments.rn

The business should know that chain before sensitive data starts flowing through it.rn

Follow the Entire Identity-Data Lifecycle

A privacy review that looks only at the upload screen will miss much of the risk. A better review follows the information from collection through deletion.rn

1. Collection

Identify every data field, image, video, device signal, cookie, identifier, and third-party lookup involved in the verification process. Document whether each element is mandatory, optional, or triggered only when fraud risk increases.rn

2. Transmission

Determine where the data travels. That includes browser-to-provider transmission, provider-to-business APIs, webhooks, customer-support systems, logging services, and any downstream business systems.rn

3. Processing

Record what happens to the data. Is OCR performed? Is a biometric template created? Is information matched with another database? Are fraud models applied? Is a human reviewer able to see the original document?rn

4. Storage

Identify exactly where raw evidence, extracted attributes, verification results, audit logs, and backups are stored. “We don't store customer IDs” may be technically true in one production database while copies remain in a vendor dashboard or support ticket.rn

5. Access

Determine who can view each data type and why. Production engineers, compliance teams, fraud investigators, support agents, contractors, and vendor personnel should not automatically receive the same level of access.rn

6. Secondary use

Check whether data can be used to improve algorithms, train models, benchmark products, build fraud networks, perform analytics, or support unrelated products. Contract language and technical settings should agree with the business's intended use.rn

7. Retention and deletion

Define when each category is deleted and what deletion actually covers. Raw document images may justify one schedule, verification outcomes another, and legally required audit records a third.rn

Which Privacy Laws Matter for ID Verification?

There is no universal privacy rule that applies identically to every identity-verification workflow. Obligations depend on where the business and user are located, the type of information involved, why it is processed, the industry, the role of each party, and whether biometric information is used.rn

The following framework is useful for issue spotting, but it should not be treated as a substitute for jurisdiction-specific legal analysis.rn

GDPR principles are particularly relevant to identity data

The GDPR's data-minimisation principle requires personal data to be adequate, relevant, and limited to what is necessary for the stated purpose. Storage limitation similarly requires businesses to avoid retaining personal information longer than necessary for the purpose for which it was collected.rn

These principles translate well into practical identity-system design. If a business needs to confirm that a person meets an eligibility requirement, it should at least consider whether it needs every attribute contained in the underlying document.rn

California treats some identity data as particularly sensitive

California's privacy framework includes categories such as certain government identifiers and biometric information processed for the purpose of uniquely identifying a consumer within its definition of sensitive personal information.rn

That makes data mapping important. A generic label such as “customer information” can conceal the fact that an ID-verification flow handles several different data categories with different risk levels.rn

Biometric laws can be more specific than general privacy rules

Illinois' Biometric Information Privacy Act is a prominent example of a state law addressing biometric identifiers and information. Among other requirements, the statute addresses notice, written release, disclosure, retention policies, and destruction.rn

Other jurisdictions can use different definitions and rules. Businesses should therefore avoid assuming that a consent flow designed for one location automatically works everywhere.rn

Biometric Privacy Deserves Separate Attention

Document verification and biometric verification are related, but they are not the same thing. A system can validate a document without comparing a person's biological or behavioral characteristics, while many remote identity flows add facial comparison to determine whether the person presenting the document appears to be its rightful holder.rn

NIST's current Digital Identity Guidelines treat biometrics used in identity proofing as an area requiring explicit privacy consideration. The guidelines address notice, consent, security, performance, retention, and privacy risk assessment in identity-proofing environments.rn

Know what the system actually creates

Asking whether a provider “uses facial recognition” is too broad. More useful questions include whether it creates a biometric template, how long that template exists, whether it is stored after comparison, whether a selfie or video remains available, whether one-to-one or one-to-many matching occurs, and whether biometric data is reused for product development.rn

One-to-one and one-to-many matching present different questions

A one-to-one verification typically compares a live sample with the image associated with a claimed identity—for example, comparing a selfie with the portrait on the person's ID document.rn

A one-to-many system may search a biometric sample against a wider database to identify a possible match or detect duplicate identities. That broader search can create additional privacy implications and should not be treated as interchangeable with simple one-to-one verification.rn

Deletion of a template is not the whole retention story

A vendor may state that a biometric template is deleted quickly while keeping the original image, video, transformed features, audit information, or other derived data for a different period.rn

Businesses should therefore ask for retention periods by data category rather than accepting a single statement such as “biometric information is not retained.”rn

Accuracy affects privacy and fairness

False matches and false non-matches are not merely technical quality metrics. They can determine whether an individual is wrongly accepted, wrongly rejected, sent to manual review, or required to submit more information.rn

Businesses should understand how a provider evaluates performance in conditions that resemble the intended user population and operating environment. They should also have a process for legitimate customers who cannot successfully complete the automated flow.rn

What Privacy by Design Looks Like in ID Verification

Privacy by design works best when it changes system decisions. It should influence the information collected, architecture, vendor configuration, user interface, support process, and deletion schedule.rn

Collect for a specific purpose

Write down why identity verification is required before choosing the technology. “Fraud prevention” can be too broad by itself. The purpose may be preventing duplicate accounts, satisfying a regulated customer-identification requirement, restricting an age-controlled service, securing account recovery, or protecting a high-value transaction.rn

A defined purpose makes it easier to determine which evidence is actually necessary.rn

Use proportional verification

Not every customer action needs the strongest available identity check. A low-risk action may justify less evidence than opening a regulated account, recovering an account after suspected takeover, or conducting a high-value transaction.rn

Risk-based workflows can reduce unnecessary collection while reserving stronger checks for situations where the additional assurance has a genuine purpose.rn

Minimize transferred attributes

Where possible, consider whether downstream systems need the complete identity record or only the outcome relevant to the decision.rn

For example, a system deciding whether an age threshold has been met may not need to expose a person's full birth date to every service involved in the transaction.rn

Separate raw evidence from business records

Raw document files and facial images generally create greater exposure than a verification status. Architectures that keep highly sensitive evidence in a restricted environment while returning only required results can reduce the number of systems that must protect the full identity record.rn

Give users meaningful notice at the point of collection

A link to a long privacy policy is rarely the clearest way to explain a sensitive verification event.rn

Before collection, users should be able to understand what they are being asked to provide, why the information is required, whether facial or biometric processing is involved, who performs the verification, and where to obtain more information about retention and privacy rights.rn

Avoid unnecessary secondary use

Identity documents collected for verification should not automatically become a convenient dataset for unrelated analytics, advertising, or product development.rn

If a provider wishes to use customer data for its own purposes, the business should understand that use before deployment and determine whether it is compatible with its privacy commitments and applicable requirements.rn

Provide redress

A person who fails verification should not necessarily be trapped in a loop that repeatedly asks for the same document and selfie.rn

Provide a reasonable path for troubleshooting or review when appropriate. Depending on the business and risk, this might involve document recapture guidance, an alternative evidence route, or human review.rn

How Long Should ID Verification Data Be Retained?

There is no single retention period that is correct for every identity-verification program.rn

The right period depends on the purpose of collection, legal or regulatory recordkeeping requirements, fraud investigation needs, contractual obligations, data category, applicable law, and whether the business can meet the same objective with less information.rn

What businesses should avoid is an undefined default such as “keep everything indefinitely unless someone requests deletion.”rn

Build retention by data category

A mature retention schedule separates information rather than treating the entire verification record as one object.rn

Retention decisions should be documented. They should also be technically enforceable. A policy stating that information is deleted after a certain period does little good if no system actually performs or verifies the deletion.rn

Security Controls for Identity Verification Data

Privacy and security are different disciplines, but identity verification makes them inseparable. A business cannot meaningfully promise privacy while leaving identity documents broadly accessible or poorly protected.rn

Appropriate controls vary with the environment, but several areas deserve close attention.rn

Encryption

Protect sensitive information during transmission and while stored. Keys, access to encrypted stores, and key-management processes matter as much as simply stating that “encryption is enabled.”rn

Least-privilege access

Employees and contractors should have access to the minimum identity information necessary for their responsibilities. Administrative and manual-review tools deserve particular scrutiny because they may expose the original ID image or selfie.rn

Strong administrative authentication

Sensitive dashboards should be protected by strong authentication and appropriate controls around privileged accounts. Shared accounts make it difficult to understand who viewed or changed a record.rn

Audit logging

Record access to sensitive identity information where appropriate, while making sure the logs themselves do not unnecessarily duplicate full identification numbers, document images, authentication secrets, or other sensitive content.rn

Secure development and testing

Production identity documents should not casually become development fixtures or sample data. Test environments can receive less operational scrutiny than production even though copied data remains sensitive.rn

Subprocessor and infrastructure controls

Review where providers host and process information, who their subprocessors are, and how changes to subprocessors are communicated. The relevant data path may be wider than the primary verification provider.rn

Deletion verification

Security teams should know whether deletion covers active databases, object storage, caches, analytics pipelines, support tools, and backups according to the applicable retention design.rn

The Federal Trade Commission's long-standing security guidance for businesses makes the same practical point from another angle: know what personal information you have, keep only what you need, protect what remains, securely dispose of data that is no longer necessary, and prepare for incidents.rn

Questions to Ask an ID Verification Provider Before Sending Customer Data

Vendor selection should go deeper than document coverage, pass rates, and API response time. A provider becomes part of the privacy architecture as soon as customer identity evidence is sent to it.rn

The following questions help reveal how the service actually handles sensitive information.rn

Data collection

• Exactly which personal data is collected for each verification method?
• Which information is mandatory and which features can be disabled?
• Does the service collect device, IP, location, behavioral, or network signals in addition to document information?
• Can the business receive a verification result without receiving unnecessary document fields?

Biometric processing

• Does the workflow create biometric templates or other derived biometric data?
• Is matching one-to-one, one-to-many, or both?
• How long do the selfie, video, template, and derived features exist?
• Are biometric samples or derived information used to train or improve models?
• How does the provider assess false-match and false-non-match performance?

Retention and deletion

• What is the default retention period for each data category?
• Can customers configure shorter retention periods?
• What information must be retained for security, fraud, legal, or contractual reasons?
• How quickly is deletion executed after a valid request or retention trigger?
• How are deleted records handled in backups?

Purpose and secondary use

• Does the provider use customer data only to provide the contracted verification service?
• Can information be used for analytics, model development, benchmarking, fraud networks, or other independent purposes?
• Are those purposes optional?

Security

• How is information encrypted in transit and at rest?
• How is employee access approved, restricted, logged, and reviewed?
• What controls protect customer dashboards and administrative interfaces?
• What independent security assessments or certifications are relevant to the service?
• How are vulnerabilities and security incidents handled?

Data location and subprocessors

• In which countries or regions can personal data be processed or stored?
• Which subprocessors can access the information?
• How are customers informed when the subprocessor list changes?

User rights and support

• How does the provider help the business respond to access, correction, deletion, or other applicable privacy requests?
• Can verification records be located without exposing more information than necessary?
• What happens when a legitimate user disputes a failed verification?

Answers should ultimately be reflected in contracts, technical settings, operating procedures, and the user-facing privacy experience. A sales presentation alone is not a privacy control.rn

Privacy Is Also a Customer-Experience Issue

Identity verification asks customers to do something unusually personal. A customer may be comfortable providing an email address to create an account but hesitate when a website suddenly requests a passport and live facial image.rn

Trust often depends on explaining the request before the camera or upload screen appears.rn

Explain why verification is required

A short, specific explanation is generally more useful than “for security purposes.” Tell users whether the check protects account recovery, meets a regulatory requirement, confirms eligibility, reduces impersonation, or secures a high-risk transaction.rn

Describe what will happen

If the customer will photograph an ID and take a selfie that is compared with the ID portrait, say so in plain language. Avoid forcing users to infer biometric processing from a lengthy legal document.rn

Set expectations about time and alternatives

Let customers know whether the process is normally automated, whether manual review may occur, and how they can obtain support when something goes wrong.rn

Design for accessibility

Camera-based identity systems can create difficulties for customers with disabilities, older devices, poor connectivity, documents that do not fit standard assumptions, or other accessibility constraints.rn

A privacy-respecting process should not respond to every failure by demanding progressively more personal information. Where appropriate, provide a controlled alternative.rn

Do not hide the identity provider

If a third party handles the verification, users should not be surprised to discover later that their document was processed by another company. The relationship should be explained at the appropriate point in the journey.rn

Plan for an Identity-Data Incident Before One Happens

Security incidents involving identity information require fast decisions because the data may be useful for impersonation or identity theft and may trigger legal, contractual, or regulatory obligations.rn

An incident plan should identify the systems containing raw documents, biometric data, extracted identity attributes, verification results, support records, and relevant logs. The response team should also know which vendors can help determine the scope of exposure.rn

At minimum, planning should address containment, evidence preservation, investigation, access-key or credential rotation where relevant, assessment of affected data types, legal and contractual notification analysis, customer communication, regulator or partner requirements where applicable, and remediation of the underlying weakness.rn

Vendor contracts should define incident-notification responsibilities before an incident occurs. A business should not have to negotiate basic access to forensic information while trying to understand whether customer identity documents were exposed.rn

Data minimisation remains one of the most effective risk controls here. Information that was never collected—or was securely deleted when no longer necessary—cannot later be exposed from that system.rn

A Practical Privacy Checklist Before Launching ID Verification

Before moving an identity-verification workflow into production, businesses should be able to answer the following questions in concrete terms:rn

• What exact business, fraud, security, eligibility, or regulatory purpose requires identity verification?
• What level of identity assurance is proportionate to that purpose?
• Which documents, attributes, images, biometric data, and device signals are collected?
• Could the same objective be met with less information?
• Which fields are returned to the business after verification?
• Where does raw identity evidence travel and where is it stored?
• Are biometric templates or other derived biometric data created?
• Is any one-to-many biometric search performed?
• What does the user see before providing sensitive information?
• Which privacy notices, consents, or other legal mechanisms are required for the relevant jurisdiction and use case?
• Which third parties and subprocessors can process the information?
• Can the provider use the information for its own analytics, training, or product-development purposes?
• How long is each category of identity information retained?
• How is deletion executed and verified?
• Who inside the business can access raw identity records?
• Are access events logged and periodically reviewed?
• What happens when the automated system rejects a legitimate customer?
• Is there an accessible support or redress path?
• How are privacy-rights requests handled when applicable?
• What security and incident-notification obligations are included in the provider contract?
• Has the organization completed the privacy, security, legal, and customer-experience assessments appropriate to the deployment?

If several of these questions cannot be answered, the project probably needs more design work before sensitive customer data is collected.rn

The Better Question Is Not “Is ID Verification Private?”

Identity verification is neither inherently private nor inherently invasive. Its privacy impact depends on how the system is designed and operated.rn

Two businesses can use similar verification technology and produce very different privacy outcomes. One may collect a document for a clearly defined high-risk event, minimize the information returned to downstream systems, promptly delete raw evidence, restrict employee access, provide transparent notice, and offer a route for legitimate customers who fail the automated check.rn

Another may collect the same document for routine activity, retain it indefinitely, duplicate it across internal systems, allow broad administrative access, reuse images for unrelated purposes, and give customers no practical way to challenge an error.rn

The technology is only part of the story.rn

For businesses, the most useful privacy principle is straightforward: ask for enough identity information to solve the real problem, but do not turn “more data” into the default measure of security.

A well-designed verification program should be able to explain what it collects, why each element is necessary, who receives it, how it is protected, how long it remains, and what a customer can do when the process fails. If those answers are difficult to obtain, privacy risk is already becoming an operational problem.rn

Frequently Asked Questions About Privacy in ID Verification

Is ID verification safe for personal data?

ID verification can be designed to protect personal data, but safety depends on the implementation. Businesses should consider data minimisation, encryption, access controls, vendor security, retention periods, deletion procedures, incident response, and whether sensitive information is reused for purposes unrelated to verification. No identity-verification method should be treated as risk-free simply because it is automated.rn

What personal information is collected during ID verification?

Depending on the method, ID verification may process a name, date of birth, address, government identification number, document image, facial image or video, biometric data, document metadata, device and network signals, verification results, and fraud indicators. A business should identify the exact data used in its own workflow rather than assuming every provider collects the same information.rn

Does ID verification always require biometric data?

No. Some identity checks validate documents, database information, digital credentials, or other evidence without performing biometric matching. Biometric processing is commonly added when a business wants to compare the person presenting an ID with the portrait associated with that identity. The appropriate method depends on the required assurance level, risk, jurisdiction, and use case.rn

Is a selfie considered biometric data?

A digital photograph is not automatically treated as biometric data in every legal context. Biometric issues commonly arise when technical processing extracts or compares physical, physiological, or behavioral characteristics for identification or verification. Because definitions vary by jurisdiction, businesses using facial comparison should determine how applicable law classifies both the image and the derived information.rn

How long should a business keep copies of customer IDs?

There is no universal retention period for every business. Retention should be based on the defined purpose, applicable legal or regulatory requirements, fraud and security needs, contractual obligations, and the sensitivity of the data. Businesses should avoid indefinite retention by default and should consider separate schedules for raw ID images, selfies, biometric data, extracted attributes, verification results, logs, and backups.rn

Should a business store the customer's ID after verification succeeds?

Not automatically. A business should determine whether retaining the raw document is necessary after the required identity attributes or verification result have been established. In some regulated situations, recordkeeping requirements may justify retention. In other cases, a limited verification record may meet the business purpose with less privacy exposure.rn

Can an ID verification provider use customer data to train its AI or algorithms?

That depends on the provider's terms, contract, configuration, and applicable law. Businesses should not assume that data submitted for verification is automatically excluded from model development or product improvement. Vendor review should establish whether customer data, document images, selfies, biometric information, or derived signals can be used for training, benchmarking, analytics, or other secondary purposes.rn

What is data minimisation in identity verification?

Data minimisation means limiting personal information to what is necessary for the defined verification purpose. In practice, that can mean avoiding unnecessary document fields, limiting transfer of raw identity evidence, returning a verification result instead of a complete identity record where appropriate, restricting employee access, and deleting sensitive data when continued retention is no longer justified.rn

Does GDPR apply to identity verification?

GDPR can apply when an identity-verification process falls within its territorial and material scope and involves personal data. Relevant considerations can include lawful processing, transparency, purpose limitation, data minimisation, storage limitation, security, processor relationships, individual rights, international transfers, and additional requirements where special-category data is involved. The correct analysis depends on the particular business and processing activity.rn

What should businesses ask an ID verification vendor about privacy?

Businesses should ask what information the provider collects, where it is processed, which subprocessors are involved, whether biometric templates are created, whether one-to-many matching occurs, how long each data category is retained, how deletion works, who can access records, how information is secured, whether data is used for model training or other secondary purposes, and how the provider supports privacy requests, incident response, and verification disputes.rn

Can a business outsource its privacy responsibilities to an ID verification company?

Using a specialist provider can transfer parts of the technical processing, but it does not automatically eliminate the business's privacy responsibilities. Depending on the jurisdiction and relationship, the business may still need to assess the purpose of processing, vendor arrangements, notices, data minimisation, retention, security, user rights, and other obligations that apply to its service.rn

What should happen when a legitimate customer fails automated ID verification?

Businesses should have an appropriate process for handling legitimate failures. Depending on the risk and service, that may include clearer capture instructions, retry limits, alternative evidence, customer support, or manual review. Repeatedly requesting additional sensitive information without explaining the problem is not a good substitute for a defined redress process.rn

Authoritative References Used for This Article

The privacy and identity concepts discussed here are informed by authoritative materials including NIST SP 800-63-4 Digital Identity Guidelines and SP 800-63A-4 Identity Proofing and Enrollment, European Commission guidance on GDPR data-processing principles, California Attorney General information concerning the CCPA, Illinois' Biometric Information Privacy Act, UK Information Commissioner's Office guidance on biometric recognition, and Federal Trade Commission guidance on protecting personal information.rn

Businesses should consult the current official text and guidance applicable to their jurisdiction because privacy, biometric, cybersecurity, identity, and sector-specific requirements can change.rn