A passport scan is not a friendly attachment. It is a durable identity record, useful long after a travel date has passed. A responsible visa service should be slightly inconvenient about collecting it and very precise about why.
Data minimisation by stage
Different stages need different facts.
| Stage | Normally needed | Normally not needed |
|---|---|---|
| Public route check | Citizenship, purpose, stay, entries | Name, passport number, image, email |
| Initial enquiry | Trip facts, application location, contact reply address | Full passport scan, payment data |
| Invitation preparation | Necessary passport-identical data and itinerary | Portal password, card PIN, unrelated financial records |
| E‑visa review | Relevant application fields and images by agreed method | Account password, email code, remote device access |
| Support after delivery | Order or document reference and disputed field | Re-sending all documents by default |
If a service cannot explain the need for a field, it should not collect the field because a future workflow might enjoy having it.
Credential boundaries
Never send a private assistant:
- official portal password;
- email password;
- one-time authentication code;
- card PIN or full card security credentials;
- remote-control access to the device;
- recovery codes.
In a guided e‑visa session, enter credentials yourself with screen sharing paused where appropriate. The assistant can review the application without owning the account.
Payment safety
Payment should occur through a named, secured payment channel. The amount, currency, merchant and service should be visible before confirmation.
Do not put card data in email, ordinary chat or an invitation-order notes field. Russian Visa Letter does not need a photograph of the card used to verify a traveller’s identity.
Document exchange
When a passport image becomes necessary:
- Confirm the service and quote first.
- Use the designated secure upload or exchange channel described for the order.
- Check that the destination domain and recipient are correct.
- Send only the requested page or file.
- Avoid public social messages and shared workplace channels.
- Keep the order reference separate from unnecessary identity details where possible.
Metadata can reveal information too. A phone image may contain location data; a PDF may retain author names or editing history. Systems handling documents should remove unnecessary metadata where it is not needed.
Access and retention principles
Sensitive records should be accessible only to people and processors who need them for the stated service. Access should be role-limited and revocable.
Retention should be tied to:
- delivering the service;
- supporting a defined correction or dispute period;
- legal, accounting or fraud-prevention obligations;
- a documented deletion schedule.
“Forever, in case you return” is not a useful retention policy for passports.
The designated application inbox
The current workflow sends submitted form applications to the designated Global Voyage inbox. A paid application email can contain the typed biographical fields needed for the order, including passport number and dates. It never contains passport scans, uploaded files, card details, passwords or one-time codes.
This inbox must use multi-factor authentication, named staff access, access revocation and the published deletion schedule. Do not forward full application emails into personal or group mailboxes. Use the order reference in replies, minimise quoted history and move passport or portrait images through the later protected document channel rather than attaching them to the email thread.
Children and group travel
Children’s identity data deserves the same protection, plus careful control over who is authorised to provide and receive it. A group coordinator should distribute only the minimum information each party needs.
Do not circulate a spreadsheet of entire passport records among every traveller and supplier. Separate operational itinerary information from identity-document data.
Recognising impersonation
Be suspicious of a message that:
- creates a new payment destination without explanation;
- asks for password or one-time code;
- uses a slightly misspelled domain;
- pressures immediate passport upload;
- offers guaranteed visa approval;
- changes the merchant or issuer after payment;
- attaches an unexpected executable or archive.
Verify through the contact details opened independently from this site, not by replying to the suspicious message.
Incident reporting
If you believe data was sent to the wrong recipient, credentials were exposed or a message impersonates the service:
- Stop further sharing.
- Change affected passwords through the official service; do not send the new password to us.
- Contact your bank directly if payment credentials may be compromised.
- Report the incident with time, channel and non-sensitive evidence.
- Preserve suspicious headers or URLs.
Do not paste active credentials into an incident report. Security support should reduce exposure, not collect a second copy.
The form’s technical boundary
The public route checker calculates in the browser and sends no identity record. Submitted quote requests and complete typed tourist-invitation or e‑visa applications can be delivered through Cloudflare Email Sending to the fixed Global Voyage service inbox. The server requires a confirmed delivered-or-queued response before it marks the application accepted. If configured email delivery fails, the request fails closed; a private authenticated intake can serve only as the documented fallback when email transport is absent. Paid passport data is never placed in the copy-to-chat fallback.
The site form accepts typed biographical fields for a defined application, but no passport upload and no payment-card data. Payment takes place on the named payment provider’s hosted page after the amount and currency are confirmed. The applicant keeps the official e‑visa account, password, one-time codes and final submission under their own control.
These boundaries reduce exposure; they do not replace HTTPS across the deployed domain, secure headers, protected server secrets, role-limited receiving-system access, backups, payload-safe logging and an incident procedure. Those controls must be tested in the actual production environment, not inferred from a padlock icon in a design.