Data Management & Privacy · THE NO-PANIC PLAN
Clean phone-number records without changing what they mean
A tidy phone number is not necessarily a correct phone number, and a format check does not show that a line is active or belongs to the person in your record. This workflow is for authorized contact-data maintenance: keep a protected source copy, choose the correct numbering region for every value, normalize carefully, and review uncertain matches before import. Do not use cleanup to add people to a marketing list or change consent, opt-out, or contact-purpose fields. The ITU's E.164 recommendation defines an international public numbering plan; local numbering rules and special service numbers still need region-aware handling.
MISSION Normalize authorized phone-number records using an explicit region, preserve original values and record identity, and review exceptions without treating formatting as proof that a number is assigned, reachable, or approved for contact.
Review and normalize an authorized copy while preserving original valuesTHE REAL-WORLD BIT
What happens outside this browser tab?
Confirm the approved purpose and minimize the records in scope; protect a source copy and identify the applicable region and field rules; normalize a separate copy with an explicit region and retain the source value; review invalid or ambiguous inputs against their owner-provided source; deduplicate only after normalization with human review of shared lines; validate import behavior and privacy/contact controls; then document exceptions, access, and the retention or deletion decision.
YOUR CHECKLIST, WITH FEWER DRAMATIC SIGHES
One step at a time.
Follow the order below. If a step names a Nirmion tool, its link is right there with it.
- 01
Set the cleanup purpose and limit the records in scope
Write down why the phone fields need cleanup, which system and records are authorized for the job, who will review changes, and where the result will be imported. Include only the fields needed to perform and validate the cleanup; avoid copying names, addresses, account notes, or full customer profiles if a record ID and number are sufficient. Confirm the work follows your organization's privacy, access, retention, and contact-preference rules. A standardized number does not create consent to call or text, remove a suppression request, or establish a lawful purpose. The FTC recommends scaling down personal information to what the business needs and protecting what it keeps; apply your own jurisdiction's rules and policy.
- 02
Protect a source copy and classify each input region
Export through an approved path, store the untouched original in the permitted location, and work on a restricted copy. Keep a stable record ID so the cleaned value can be traced back without matching on names. Determine the country or numbering region from a trusted source such as the record's verified address or account setting; do not guess it from the phone digits or the computer's locale. A PII Detector can flag common personal-data patterns in a minimized sample before handling, but it is heuristic and cannot certify an entire contact file or identify every sensitive field. Do not upload raw customer records to an unapproved service, and restrict local files and temporary exports to authorized staff.
- 03
Normalize a separate copy with the explicit numbering region
For each record, retain the exact source value in a protected original-value field and create a separate normalized field. Use the verified region as parsing context; preserve an explicit international country code when the source already provides one, and handle extensions in a separate field if the receiving system supports them. The Phone Number Formatter can help review individual values, but check its displayed assumptions and output before applying them to your full dataset. ITU-T E.164 describes the international numbering structure, while domestic dialing prefixes and national formats are region-specific. Do not silently prepend a default country code, strip meaningful digits, or change an ambiguous number just to make it pass a format check.
- 04
Review exceptions instead of inventing missing digits
Separate values into clear groups: successfully normalized, missing region, incomplete, ambiguous, short code or service number, and unsupported format. Ask an authorized data owner to verify uncertain entries from the source system or with the person through an approved channel. Google's libphonenumber guidance distinguishes a possible number from a valid number range and explicitly says its metadata cannot determine whether a number is currently assigned to a specific user or reachable; actual verification requires an appropriate contact step. Its FAQ also notes that some short numbers are outside the main library's scope. Do not use repeated digits, a local area code, a directory lookup, or a format library to infer ownership. Preserve unresolved entries with a review status rather than guessing.
- 05
Deduplicate only after canonicalization and inspect shared lines
After normalization, compare exact canonical values while retaining each stable record ID and source value. Treat a potential exact match as a review candidate, not automatic proof that two people are the same: households, shared reception desks, caregivers, and organizations can legitimately use one number. Never merge people, delete a record, or overwrite contact preferences based only on a matching phone field. Have an authorized owner approve each merge or keep both entries, and record which source records were affected so you can reverse a mistaken change. Avoid fuzzy matching on partial numbers because it can combine unrelated records or expose more personal data than the cleanup requires.
- 06
Check the cleaned file against the receiving system
Compare input and output row counts, confirm stable record IDs remain unique, and account for every exception and approved merge. Import a small authorized test set first and confirm the receiving application preserves the leading plus sign, country code, extension, original-value field, and intended text type; spreadsheet applications can reinterpret phone strings as numbers or formulas. Confirm unrelated fields such as consent, marketing status, do-not-contact flags, and notes were not altered. Have a reviewer compare representative records with the source. If any change cannot be traced or a count does not reconcile, stop the import, restore the protected original, and investigate before proceeding.
- 07
Record exceptions and apply access and retention rules
Document the source system, date, region assumptions, normalization method, reviewer, exception counts, and approved changes without copying the entire phone list into the audit note. Keep the mapping between original and normalized values only as long as the business purpose and applicable policy require. Restrict access to the working copy, remove temporary exports from unauthorized locations, and provide a process for people or data owners to correct a wrong number. ICO guidance for organizations within its scope says personal data should be adequate, relevant, and limited to what is necessary, and that accuracy should be considered in light of the purpose. Apply the relevant local rules and your approved retention schedule rather than assuming UK GDPR applies everywhere.
THE HELPER CREW
Tools for the fiddly bits.
These are the currently published Nirmion tools matched to this guide. Open a tool page for its accepted inputs and limits.
RECEIPTS, PLEASE
Sources & review notes
Each source is linked to the steps it supports. Open it to check its scope and current guidance.
Source checked 2026-10-10