Text version of this lessonExpand
An overseas phone number is not about looking international. It is an account identity asset for payments, ads, email, support, and platform recovery.
The previous lesson answered one earlier question: whether cash or time can carry one validation round. It leaves a startup cash runway sheet, and it may only say to narrow the test or pause first.
That sheet did not prove that you need an overseas number, or that payment, payout, cards, entity, orders, or funding are ready. It used the same 20oz commuter tumbler and $8,000 only as a launch-pressure calculation, not as ad budget, a real balance, or an approval.
Enter this lesson only when reliable identity, 2FA, or a recovery route is the earliest current blocker. The output is a phone identity and recovery checklist, not a conclusion that a phone, payment, or platform account is ready.
Treat the overseas phone number as an account identity asset
Temporary numbers feel convenient at the start, but they become dangerous when verification, renewal, transfer, or account recovery is needed later.
This lesson separates phone use into registration, verification, support, and recovery. Critical accounts need a number you can control, renew, and recover.
Decision lens for this lesson
- Identity entry: The phone or contact point platforms use for verification, notices, and recovery.
- Recoverability: Whether the account can be safely recovered after device, staff, or provider changes.
- 2FA: Two-factor authentication; useful only when backup methods are also controlled.
Lesson output: phone identity and recovery checklist. Use this output to decide whether the lesson is truly complete.
Start with a real account-recovery scenario
Treat a backend security number as a verification entry that the business can control for the long term. It is not a public customer number or a one-time code tool. It helps the team prove control when signing in to Shopify, changing payment settings, recovering domain email, or restoring an ad account.
Consider a new store selling 20oz tumblers in the United States. Shopify admin, the payment service, Google or Meta ads, and domain email are already in use. If each is bound to a temporary number or one person's private phone, a lost device, expired number, or staff change can remove login, verification, and recovery access at the same time while customers may keep placing orders and requesting refunds.
This lesson starts with the backend security number because its failure has the biggest impact. Whether that role suits you depends on which backends your business currently ties to the number. Give one long-term controlled number the job of securing the backends and add an authenticator, recovery codes, and a backup admin. Treat customer-facing and temporary testing numbers separately. The order follows the current risk. It does not recommend a UK number, a particular provider, or binding every backend today.
You do not need to buy a SIM or click anything now. Read and check the four steps below first; the later tables and steps expand each one.
Read these four things first
Write the number role down first. It only decides which risk the number must carry; it does not choose a phone type. A backend-security number must stay controlled, renewable, and recoverable, while a customer-facing or temporary testing number must not slip into that recovery path just because it is convenient.
Then compare a physical SIM, eSIM, and virtual number. The next judgment is not which one costs least, but whether it meets the renewal, access, and recovery requirements of the role you just defined.
How this connects: phone asset belongs with email and access control
An overseas phone number is not only for codes. It is part of account recovery, team continuity, and backend security, so connect it to domain email and system integration.
- Identity route: domain and business email to keep email, DNS, phone number, and recovery path in one identity asset map.
- System route: system integration to confirm which systems the number protects, who owns access, and when to retest.
Manage the overseas number as an account recovery asset
An overseas number is not a cosmetic sign that the team is international. It supports account registration, two-step verification, support contact, and risk recovery. The job today is to define who controls the number, who renews it, which backup methods exist, and which core accounts depend on it.
| Use location | What to record | Risk if ignored |
|---|---|---|
| Platform registration | Whether Shopify, payment, ads, and email are bound to this number | If the number fails, verification codes cannot be received |
| Customer support display | Whether it is public, service timezone, scripts, and forwarding rules | Customers may expect real-time phone support that the team cannot provide |
| Recovery mechanism | Renewal date, backup email, 2FA recovery codes, and responsible person | After a staff change, nobody can explain who controls the number |
Completion standard
You can list which accounts this number binds, who renews it, and how recovery works if it is lost. Otherwise, it is not an asset; it is a future login risk.
Phone asset sheet: record bindings, recovery, and freeze boundaries first
The risky part of an overseas number is that it looks like a small tool, but it can control store, payment, ad, email, support, and banking access. Do not only record "we bought a UK number." Turn it into a phone asset sheet: what it binds, who controls it, how it stays active, and which backend must be recovered first if it fails.
This does not need a complex system. A table is enough at the beginning. Update it whenever you add a binding, change devices, change the responsible person, switch eSIM, or add 2FA. Otherwise the number stack grows until nobody can explain which number protects which backend.
| Record module | Fields to record | What it proves | Where failure blocks you | Where to store it |
|---|---|---|---|---|
| Number basics | Number, country/region, SIM or eSIM, provider, login email, PIN/PUK storage status, current holder. | The number is not a temporary code tool. It can be renewed, handed over, and recovered. | Number migration, provider login, SIM replacement, eSIM reinstall, team handover. | Phone asset sheet plus password-manager item. Do not expose full sensitive values in public docs. |
| Core backend bindings | Whether Shopify, payment gateway, PayPal, Google, Meta, email, bank, or virtual account is bound to the number. | Which backends depend on this number and which one must be recovered first. | Login codes, payment settings, payout, ad assets, Pixel / tag management, email recovery. | Backend binding matrix with path, binding date, lead, and latest review date. |
| 2FA and recovery methods | Primary factor, backup factor, recovery-code storage, backup admin, backup email, security key or authenticator status. | SMS is not the only entry. A lost phone still has a verifiable recovery chain. | Shopify Payments, ad account, email, payment backend, password manager. | Secure access record. Store secrets in a password manager; keep only status and custodian in the sheet. |
| Keep-alive and renewal | Latest valid call / SMS / data / top-up date, 90-day reminder, 150-day reminder, next keep-alive action. | The number will not be recycled because nobody used it, and keep-alive is not memory-based. | Missing verification codes, inactive number, provider account closure, core backend lockout. | Team calendar, phone asset sheet, and provider status record. |
| Support display boundary | Whether it appears on Contact page, WhatsApp, email signature, or support templates; timezone, forwarding rule, response promise. | Security number and support number are not mixed, and customers do not expect real-time phone support if you cannot provide it. | Support expectation, policy promise, complaint, chargeback dispute, team coverage. | Policy-page version log, support-template version, and forwarding rule. |
| Incident and recovery record | Loss time, affected backends, first recovery action, recovery code used, ticket ID, review time, and blocked actions. | Recovery is not a random rush; control is restored in order and can be reviewed later. | Payment, ads, email, admin permissions, payout, domain, and password manager. | Incident log reviewed with system integration, payment gateway, and domain email lessons. |
Minimum acceptance standard: you can explain which backends the number binds, who holds it, when the next keep-alive action happens, which backend to recover first if the phone is lost, and which actions stay frozen until recovery is accepted. If you cannot explain that, do not bind a new backend to this number.
Define how Pixel relates to the phone number
Many beginners see Pixel and assume it is directly tied to the phone number. It is not. A Pixel is tracking code from an ad or analytics platform that records actions such as page view, add to cart, checkout start, and purchase. You usually see it in Shopify apps, Meta Events Manager, Google tag, GA4, ad accounts, or theme and checkout settings.
Why this lesson covers Pixel
The Pixel itself does not need a phone number, and you are not binding a phone to the Pixel. The real link is identity verification for the ad account, Business, Shopify admin, and domain email. When the number fails, the risk is not that Pixel data becomes worse by itself. Ad asset recovery, event-tool repair, and proof of backend control get stuck. The overseas number is not a marketing decoration. It is part of your ability to maintain Pixel, ad accounts, and payment settings.
Start with the job: why do you need an overseas number?
Many founders jump straight to buying a UK SIM, but the real jobs are different: platform verification, team operations, and customer communication. Each one has different requirements. If your only goal is receive SMS somehow, you'll usually create avoidable risk later in payments, ads, or store administration.
The 4 most common jobs of an overseas number
- Platform verification - Receiving login or security codes from Shopify, PayPal, ad platforms, and SaaS tools
- Account recovery - Serving as one recovery path when email, password, or device access changes
- Team operations - Supporting shared business systems instead of relying on one person's private mobile number
- Customer contact - Providing a more local-looking business contact point for calls or WhatsApp
SMS should not be your final security design
The more resilient 2026 setup is to use SMS as a backup, not the primary factor. Shopify officially supports authenticator apps, security keys, built-in authenticators, Shopify mobile prompts, and SMS. In practice, mobile prompts and non-SMS backup methods are usually safer than relying on texts alone.
Choose the type first: physical SIM, eSIM, or virtual number
You do not need to default to a UK physical SIM every time. A better model is to segment by risk and usage frequency: use a long-term controlled number for high-value accounts, and keep virtual or routed numbers for lighter customer-facing communication.
Physical SIM
Best for long-term accounts, payment back offices, and important SMS verification. It is easier to understand, store, and hand over, but it does require shipping and physical handling.
eSIM
Good when your device supports eSIM and you want fewer physical dependencies. It is faster and cleaner, but more dependent on device compatibility, app-based setup, and stable internet.
Virtual / VoIP number
Useful for call routing, public-facing support, or lower-risk communication, but not ideal as the only security anchor. Some platforms restrict VoIP ranges for verification; a bigger problem appears when the number expires, is recycled, or cannot provide account-ownership proof for Shopify, Meta, or payment admin recovery.
Practical recommendation for new founders
- Running one store - Start with one long-term UK physical SIM or eSIM for core verification
- Working with a team - Keep security numbers and customer-facing numbers separate
- Changing devices often - Prioritize authenticator apps, recovery codes, and backup methods before expanding your number stack
Why this guide still recommends a UK number
For Chinese-speaking founders building independent stores, UK numbers often strike the best balance between availability, setup friction, and compatibility. giffgaff remains a popular starting point not because it is magical, but because the ordering, activation, and maintenance logic is relatively clear and well documented. Start with the premise: giffgaff is a UK mobile operator running on the O2 network. You are getting a UK number, not a US, Canadian, or global local number.
It can be used in places such as the USA and Canada through roaming or travel data add-ons, but that is not the same as having a local US or Canadian carrier number. Before binding Shopify, Google, Meta, or a payment backend, run real SMS, call, roaming, and top-up tests, then add an authenticator, recovery codes, and a backup admin path.
Why UK numbers stay practical
- There is a large body of operator knowledge and troubleshooting experience
- Both physical SIM and eSIM routes are available, so you can switch later
- It works well as basic account-security infrastructure before you adopt a larger comms stack
- For a team that only needs one core business number, cost and maintenance remain manageable
When giffgaff is a good starter choice
If your goal is one maintainable UK business number, giffgaff is still a common starting option, but do not treat international shipping as guaranteed for every country. giffgaff's current help page says free SIM delivery outside the UK is limited to Australia, Japan, and Spain; the wider free-SIM page still gives broad timing guidance of 3-5 business days in Europe and 5+ business days for the rest of the world where delivery is available. Activation can be fast, eSIM switching can take up to 24 hours at busy times, and numbers can be deactivated after 6 months of no usage.
Mainland China users should not treat direct official shipping as a short-term path
For mainland China addresses, physical giffgaff SIM delivery can be unreliable and slow. If you need the number soon for store setup, payment setup, or ad-account verification, do not put "wait for direct official shipping" on the critical path; the wait can be very long, and extreme cases can stretch close to a year.
If the number is urgent, consider trusted in-stock cards, a known person who can receive and forward the SIM, or a marketplace route only when the physical card can be handed over cleanly. Do not buy a number with unclear provenance. Check real-name or control boundaries, card source, activation state, login email, future keep-alive responsibility, and whether the number can be transferred. Mainland China has been tightening management of overseas phone numbers, so short-term workarounds need clearer compliance, recovery, and handover records.
5 signs giffgaff fits your current stage
giffgaff setup: how to choose physical SIM or eSIM
If this is your first setup, decide the format before ordering. A physical SIM is easier to understand and hand over. An eSIM is cleaner, but only if your device, app flow, and network conditions are stable enough.
Physical SIM setup flow
eSIM setup flow
Which route should you pick?
- Choose physical SIM for stability - Best when handover and long-term custody matter
- Choose eSIM for convenience - Only if you understand device and app migration properly
- If you are travelling or switching devices - Delay the eSIM move until you have stable Wi-Fi and a controlled environment
Do not bind every platform on day one
Many risk problems are caused less by the number itself and more by aggressive usage patterns. A new number that is used to verify too many sensitive systems too quickly can look suspicious. A staged rollout is safer.
Recommended first-month binding order
Phone asset recovery checklist: every backend needs a backup path
Receiving SMS is only the minimum bar. The real acceptance test is whether Shopify, payment, ads, email, and finance backends can recover through a non-SMS path when the number fails. This table can go directly into the copyable lesson notes.
| Asset | Phone use | Backup recovery path | Failure signal | Acceptance evidence |
|---|---|---|---|---|
| Shopify admin control | Login verification, staff permissions, Shopify Payments security prompts, and critical setting changes. | Authenticator or security key, 10 recovery codes, backup admin, and accessible domain email. | SMS is the only path; after phone loss, payment settings, staff permissions, and admin login all stall. | Sign in once without SMS, then save security settings, recovery-code location, and backup-admin test screenshots. |
| Payment and payout backend | Payment login, payout changes, chargeback/refund handling, and platform re-verification. | Provider recovery path, backup email, bank name, entity records, and proof that payout details were not changed. | After number failure, only support tickets remain, and entity, bank, email, and order ownership cannot be proven together. | Run one backup-login or support-recovery evidence drill, then save ticket fields, proof list, and stop line. |
| Ad account and Pixel control | Google / Meta ad admins, Pixel / tag management, event diagnostics, and ad-asset authorization. | At least two admins, business records, backup verification, ad asset IDs, Pixel / tag admin location, and recovery email. | Only the media buyer phone receives codes; after staff change or phone loss, Pixel fixes, ad authorization, and appeals stall. | Backup admin can log in and view ad account, Pixel / tag, event diagnostics, and business records. |
| Domain email and DNS entry | Email login, password reset, DNS management, billing notices, and platform recovery emails. | Backup email, offline recovery codes, backup admin, password-manager record, and DNS provider recovery entry. | Email recovery depends on the failed number, while number recovery depends on the locked email. | Prove email and DNS have at least one recovery path that does not depend on the same phone. |
| Banking, billing, and finance systems | Bank or virtual-account verification, ad billing, subscription billing, supplier payments, and finance notices. | Finance lead, billing email, backup verification, emergency freeze contact, and latest payment or charge proof. | The number sits on a former staff phone, and nobody can explain charge, withdrawal, or supplier-payment recovery. | Finance lead can independently explain number, email, 2FA, freeze contact, and next review date. |
Write back to copyable lesson notes: choose the highest-risk asset, then record its backup recovery path, first evidence, stop line, and next review date. Do not add new bindings to a backend whose recovery path cannot be explained.
Account recovery evidence checklist: write five incident paths before they happen
2FA, recovery codes, ad accounts, payment accounts, temporary virtual numbers, and staff departure can look like separate problems. In an outage they ask the same question: who can prove account control, and which high-risk changes must freeze before recovery is accepted?
| Incident | Trigger | First action | Evidence pack | Stop line |
|---|---|---|---|---|
| Lost 2FA device | The phone is not recovered, the authenticator is on the same device, and Shopify, email, or payment admin asks for two-step verification. | Look for a logged-in device, backup admin, offline recovery codes, or security key first. Do not immediately reset passwords or remove the old device. | Recovery-code location, backup-admin login screenshot, 2FA reset record, maintainer of new recovery codes, and review date. | Before recovery is accepted, do not change payout, ad assets, domain email, staff permissions, or old admin permissions. |
| Ad account verification failed | Google or Meta asks for verification, codes only go to the media buyer phone, and Pixel, ad account, or tag control is blocked. | Confirm whether Business / MCC / ad account has a second admin, then save ad asset IDs, Pixel / tag location, and business records. | Second-admin login screenshot, ad account ID, Pixel / tag ID, business records, recovery email, and latest permission-change record. | Before verification recovers, do not replace the Pixel, remove admins, or create a temporary Business to bypass existing assets. |
| Payment SMS blocked | Payment admin, payout change, chargeback handling, or KYC follow-up asks for SMS verification, but the number cannot receive it or sits with a former staff member. | Freeze payout and bank-detail changes first, then confirm entity records, bank name, backup email, provider ticket path, and recent order proof. | Payment provider, login email, entity records, bank name, order/refund proof, ticket fields, and freeze lead. | Before the recovery chain works, do not submit new payout, receiving account, refund-policy, or high-risk review changes. |
| Temporary virtual number expired | An early shortcut tied Shopify, Meta, or payment admin to a one-off virtual number; later the number expires or is recycled, and the platform asks for SMS, provider billing, or account-control proof. | Check backup admin, domain email, recovery codes, payment records, provider billing, and recently logged-in devices before binding another temporary number. | Old virtual-number provider record, expiry or recycling time, bound-backend list, migration screenshot, ticket ID, and responsible person for the new long-term number. | Before account control is proven, do not change payment, ads, email, Pixel, payout, or old-admin permissions. |
| Staff departure handover | A media buyer, support agent, finance operator, or ops lead leaves while the number, authenticator, recovery codes, email, and ad/payment access still sit on personal devices or email. | List which backends this person can access, then migrate recovery methods in payment, email, ads, Shopify, and support-system order. | Permission list, old number/email, migrated backend, regenerated recovery-code record, backup-admin login test, and old-access removal date. | Before handover is accepted, do not delete the user, change passwords, cancel the number, or factory-reset the old device. |
Decision rule: recovery is not just getting a code back. It must prove account control, freeze risky moves, refresh recovery codes, and record the responsible person and next review date.
Shopify account security: the phone number is a backup layer
Shopify currently supports authenticator apps, security keys, built-in authenticators, Shopify mobile prompts, and SMS for two-step authentication. For payment-related admin access, Shopify explicitly requires two-step authentication. The more resilient setup is to demote the overseas phone number into a backup factor instead of using it as the only gateway.
Primary factor
Use an authenticator app, built-in authenticator, or security key as the main method. That keeps you from being locked out when SMS is delayed or a number changes.
Backup factor
Add Shopify mobile prompts, alternate methods, and recovery codes. Shopify officially supports multiple backup methods and explicitly tells users to save recovery codes.
Recovery records
Document which account uses which number, which authenticator, and who stores the backup codes. Operational resilience comes from records, not from buying one more SIM.
The practical limits of SMS
- Delivery can lag or fail - Roaming, network conditions, and sending policy all matter
- Device changes are the common failure point - Especially if SMS is your only access path
- Not every platform loves VoIP - Keep customer-facing numbers separate from security-critical ones
Ongoing maintenance: keep-alive, recharge, and incident handling
giffgaff's official help center states that a SIM can be treated as inactive after 6 months without usage. To prevent deactivation, at least once every 6 months you should complete a valid action such as making a call, sending a text, using mobile data, or purchasing airtime credit or a plan.
Operating checklist to put in place
- Maintain a number asset register with the SIM, assigned lead, linked platforms, keep-alive date, and recovery method
- Set reminders at both 90 days and 150 days instead of waiting for the 180-day edge
- Every time you bind a critical system, save the admin settings path, status record, timestamp, and assigned lead
- If you rely on eSIM, prepare a backup device or alternate recovery route in case the primary device fails
How to troubleshoot issues in the right order
Cost thinking: do not only count the monthly plan
The real number cost is not only the plan price. What matters more is whether you built the operational layer around it. For an independent store, the expensive event is not paying a few more pounds per month. The expensive event is losing access to your store, payments, or ad accounts because one unmanaged number quietly failed.
The 4 cost buckets you should actually budget
- The number itself - SIM or eSIM, base plan, top-ups, and keep-alive actions
- Device cost - Whether a dedicated device is needed for the SIM or eSIM
- Security cost - Authenticator apps, password manager, recovery code storage, and role separation
- Management cost - Documentation, reminders, handover, and incident response time
A practical setup path for your current stage
If you are still in the early phase of an independent-store business, the most practical path is usually not buy more numbers. It is to make one core number system actually reliable: one stable number, one primary 2FA method, one backup path, and one clean operations record. Add support numbers, ad-related numbers, or multi-region routing only after your business complexity really demands it.
Recommended execution path
Lost phone recovery drill: recover control in a 60-minute order
This step is not about buying another number. It trains the order to recover backend control when the phone is actually lost. Many teams change passwords, remove admins, swap numbers, and contact platforms at the same time. That can make a recoverable chain harder to explain. A safer order is to freeze high-risk changes first, then recover Shopify, email, payment, and ad backends.
| Time window | Recovery action | Evidence to keep | Stop rule |
|---|---|---|---|
| 0-10 minutes | Pause payout, payment-method, ad asset, domain email, and admin permission changes. Do not change passwords, remove admins, or swap numbers while searching for the phone. | Loss time, last logged-in device, currently logged-in backends, assigned lead, and frozen backends. | If you do not know which backends are still accessible, do not touch payment, ads, email, or old-admin permissions. |
| 10-25 minutes | Use a logged-in device, authenticator, security key, backup admin, or recovery code to enter Shopify. Then confirm staff permissions, payment settings, and recent logins. | Admin security-settings path, available verification method, recovery-code use record, backup-admin test, and record that payment settings were not changed. | If recovery codes are missing, backup admin cannot enter, or payment settings cannot be confirmed, do not continue changing Shopify Payments or payout. |
| 25-40 minutes | Check domain email, Google/Microsoft email, backup email, and password manager. Confirm email recovery does not depend on the lost phone. | Email security-settings path, backup email, recovery codes, DNS admin entry, and password-manager record location. | If email and phone recovery depend on each other, create backup admin access or offline recovery codes before number migration. |
| 40-60 minutes | Confirm 2FA, backup admin, and support-ticket paths for PayPal, Stripe/Shopify Payments, Google, Meta, bank, or virtual account. | Payment-backend recovery record, ad-account admin list, payout-unchanged record, support ticket ID, and next review time. | Until payment and ad recovery chains are accepted, do not add gateways, change payout, or remove old admins. |
My suggestion is to write this table into the copyable lesson notes before an incident happens. Phone recovery is not whether SMS arrives. It is whether Shopify, email, payment, and ad control can be recovered in a clear order.
Recovery continue-or-pause practice: decide whether the number chain can keep operating
A recovery drill tells you what to check. A continue-or-pause practice tells you whether work should continue. When the phone number, 2FA, recovery codes, or assigned lead are not accepted, pause payment, ad, email, and core admin changes until the first evidence is clear.
The rule is simple: protect backend control first, then fix the number. A common mistake is to keep changing passwords, removing old admins, swapping payout details, or rebinding ad assets while SMS is failing. That can turn one verification problem into payment, ads, and email lockout at the same time.
| Pressure scenario | Unsafe move | Continue condition | First evidence | Stop line |
|---|---|---|---|---|
| Shopify Payments requires 2FA but SMS is unstable | Keep SMS as the only method or let one person control every verification entry | Continue only after authenticator or security key, backup method, and 10 recovery codes are saved | Shopify security page, recovery-code storage record, backup admin or backup email | Do not change payout records or remove the old admin before backup access is accepted |
| The number is close to 6 months unused | Dismiss the warning and wait until the number is deactivated | Perform a valid keep-alive action, then review every core binding and backup login path | Call, SMS, data, or top-up record plus the next 90-day and 150-day reminders | Do not bind this number to new payment, ad, email, or banking backends until active status is clear |
| The team wants to switch eSIM while travelling | Switch on weak Wi-Fi without a spare physical SIM or logged-in recovery device | Proceed only after app login, stable network, backup recovery, and old-SIM impact are confirmed | giffgaff app login state, eSIM support proof, spare physical SIM, and backup login path | Do not run an eSIM switch that affects core recovery while abroad or on unstable Wi-Fi |
| The assigned lead changes | Change only passwords and assume the recovery chain is still safe | Remove old access only after a real recovery drill and updated copyable lesson notes | Permission list, regenerated recovery codes, backup-admin login test, and provider login record | Do not delete old recovery methods or add core bindings until the new assigned lead can explain the path |
Manage the phone number as account-recovery infrastructure
An overseas phone number is not a temporary verification-code tool. It is part of account recovery for Shopify, payments, ads, email, and banking. NIST SP 800-63B frames authentication as confirming control of authenticators; for a team, the practical rule is that phone, email, and 2FA should not depend on one fragile person or device.
Phone-number acceptance path
Copyable lesson notes: overseas phone recovery record
If Shopify, PayPal, Google, Meta, Pixel admin, and email are tied to different temporary numbers, the real cost is not the phone bill. It is future account lockout.
Your copyable notes should include these 6 fields
- Current pressure: Unstable SMS, SIM inactivity risk, eSIM transfer, responsible-person change, or no access to Pixel / ad admin.
- First evidence: Admin security-settings path, recovery-code storage record, provider status, keep-alive record, backup-admin login test.
- This-week action: Migrate core bindings, add authenticator, save recovery codes, run one recovery drill, update reminders.
- Stop action: Before recovery is accepted, do not change payment, ads, email, Pixel, payout, or old-admin permissions.
- Review window: 90-day test, 150-day keep-alive, staff-change-day review, and review after adding a core backend.
- Next route: Domain email, system integration, payment gateway, or entity boundary based on the biggest current risk.
When you share these notes with the next operator, the point is not proving that you bought an overseas number. The point is making clear which systems it protects, what must not change yet, and what the next recovery drill should inspect.