ImmiPractice is served only over HTTPS, so data moving between a browser and its servers is encrypted with TLS. Client data at rest, including database records, uploaded documents and backups, is encrypted. Mailbox passwords a firm connects for automations are encrypted with an application key before storage, card details are handled by Stripe, and no login passwords are stored at all.
- ImmiPractice is served only over HTTPS, so data in transit is encrypted with TLS.
- Database records, uploaded documents and backups are encrypted at rest.
- No login passwords are stored; connected mailbox passwords are encrypted with an application key.
- Files you download are outside ImmiPractice and need your firm’s own device encryption.
What does "encrypted in transit and at rest" actually mean?
Encryption protects data in two different situations, and a vendor should cover both.
- In transit means while data travels across the internet, for example when a client uploads a passport scan from their phone or a case worker opens a file at the office. Without it, anyone on the same Wi-Fi or network path could read the traffic.
- At rest means while data sits on disks: the database, the file store and the backups. Encryption at rest protects against someone obtaining the storage itself.
Neither one protects against a person who signs in legitimately. That is the job of authentication and roles, which is why encryption is one layer among several, not the whole story.
Encryption in transit
ImmiPractice is served only over HTTPS. Every page of the app at app.immipractice.com, the Form Menu, the client portal and signing links travel over TLS, the same protocol your browser shows with the padlock icon. This covers staff browsers, client phones and uploads of documents and payment proofs.
Encryption at rest
Client data is encrypted at rest. That includes:
| Data | Encrypted at rest |
|---|---|
| Database records (client profiles, cases, leads, agreements, invoices) | Yes |
| Uploaded documents and payment proofs | Yes |
| Backups | Yes, and stored in Canada |
Uploaded files are also kept in a private location that blocks direct web access, and are served only through handlers that check the viewer's permission. Encryption protects the storage; the permission check protects the individual file.
What about stored credentials?
Two kinds of secrets are worth asking any vendor about:
- Login passwords. ImmiPractice does not store any. Staff and clients sign in with a 6-digit one-time code sent by email. See passwordless sign-in explained.
- Connected mailbox passwords. When a firm connects its own mailbox so automations can send from it, that mailbox password is encrypted with an application key before it is stored.
Card details for your ImmiPractice subscription are handled by Stripe and are never stored by ImmiPractice.
What encryption does not cover
Be clear-eyed about the limits, because they shape what your firm should do:
- Downloaded files. Once a staff member downloads a passport scan or a filled IRCC PDF to a laptop, protecting that copy is up to your firm. Use full-disk encryption on office computers and avoid leaving copies in Downloads folders.
- Email and WhatsApp content. Messages you send leave ImmiPractice and are handled by the recipient's provider or by Meta. Send sensitive documents through the client portal rather than as email attachments where you can.
- A signed-in session. If someone signs in with a stolen code, encryption does not stop them. Protect work email with MFA.
Questions for your vendor review
If you are documenting safeguards for a privacy assessment, the facts above are what ImmiPractice states today. Detailed technical specifications, such as cipher configuration and key-management procedures, will be documented as part of our SOC 2 work. For anything you need now, email sales@immipractice.com. See also infrastructure and PIPEDA.