EZ PDF Editor (the “Service”) is a web application for opening, filling, signing and converting PDF documents. The core editor, OCR and form-filling run client-side in the user’s browser (files stay on the device). A small set of features send data to our server and, in limited cases, to contracted sub-processors:
| Data element | Whose | Purpose | Basis | Retention |
|---|---|---|---|---|
| Email, salted-hashed password, verification/reset tokens, 30-day sign-in token | Account holders | Account access & security | Consent / contract | While the account exists |
| Name, address, contact details (autofill profile) | Account holders | Faster form-filling | Consent | While the account exists |
| Documents (uploaded, edited, saved), final signed PDFs | Account holders & signers | Providing the Service; e-signature workflow | Consent / contract | While the account/session exists; erased on deletion |
| Signer name, email, occupation, phone, city, province | Signing guests | Invitation, compliance audit trail, contacts | Consent | While the session/contact exists |
| Signature images, IP address, time zone, timestamps | Signing guests | Fraud evidence & audit trail | Consent | With the session records |
| Video/audio streams & recordings | Host & guests in a VSR | Live signing; recording retained by the host for their professional records | Explicit consent (recorded in the audit trail) | Per the host’s records policy (see §9) |
| Government-ID photos & selfies (IDV) | Signing guests (when a session requires it) | Identity verification by the host against live video | Explicit consent (recorded in the audit trail) | Destroyed when the verification purpose ends (see §9) |
| AI drafting inputs (title, profession, document type, compliance type, jurisdiction, province, notes; and for each selected party: name, email, occupation, city, province) | Signed-in account holders on any plan who use the AI Document Wizard (2 free generations; unlimited on Pro and Pro Signing) & the contacts they select as parties | Generating draft legal documents | Consent | Not stored by us; token-count metadata only |
| Billing identifiers & totals; subscription status | Pro / Pro Signing account holders | Payment & plan management (Stripe, RevenueCat) | Contract | Per tax-law requirements |
| Analytics (IP, user agent, page/tool, referrer); optional Google Analytics | All visitors | Service improvement, rate-limiting, abuse prevention | Legitimate interest / consent (GA is opt-in) | Logs rotated ~90 days; GA only with consent |
Law 25 requires that personal information be collected only where it is necessary for the stated purpose, and that a privacy assessment weigh that necessity against the intrusion. This section records the alternatives that were considered before the identity-verification feature was designed, and why the current approach was chosen. Identity verification is the most intrusive collection the Service performs, so it is assessed here in full; the remaining processing (documents, signatures, account details) is minimised by design, as set out in the section on mitigations.
| Alternative considered | Assessment |
|---|---|
| Collect nothing — rely on the private invite link alone | Adopted as the default. Identity verification is off unless a host enables it for a particular session, so the majority of signings collect no identity documents whatsoever. This is the least intrusive option and it is the standard state. |
| Host confirms identity personally, on live video | Adopted and supported in the product. A host who already knows the signer, or who is satisfied by the recorded video, can confirm identity without any image being uploaded. This is the “walk-in” path and it collects no biometric-adjacent data. |
| Government ID only, no selfie | Adopted. The selfie is optional and at the host’s discretion. Where the live video already shows the signer’s face, a separate selfie adds little and is not requested. |
| Retain identity images for a fixed period after verification | Rejected as the default. The images exist to support a single decision; once it is made, continued retention adds risk without serving the purpose. They are destroyed on decision. A host under a professional record-keeping obligation may opt in per submission and must record the reason, which is written to the audit trail. |
| Automated facial recognition or liveness detection | Rejected as disproportionate. It would generate biometric identifiers where none exist today, engaging section 44 and the section 45 disclosure obligation of the Act to establish a legal framework for information technology, and creating a category of information materially more sensitive than the photographs it would replace. It would also introduce documented accuracy disparities across skin tone, age and gender into a determination that a qualified professional already makes on the record. The added assurance does not justify the added intrusion or the added risk of an incorrect automated outcome. |
| Outsource verification to a third-party identity provider | Adopted in a limited, optional form. Full outsourcing is still rejected: the host’s judgement remains the decision. What is permitted is an automated check of the ID document alone — is the card genuine, do its printed details agree with its machine-readable data — performed by Didit only when a host switches it on, and off by default. The provider returns a verdict about the document, never about the person: no facial recognition, no liveness detection and no face matching is performed for us, so no biometric identifier is created by this route either. Where the check is not used, no image is disclosed to any processor. |
Conclusion. The collection is limited to what a human reviewer needs to make one decision; it is optional, it has a no-collection alternative that is the default, and the information is destroyed once the decision is made. No biometric identifier is generated at any point. Details are published in the Identity Verification & Biometrics Policy.
The Service’s primary infrastructure is in Canada. The following controlled transfers occur and are disclosed in our privacy policy: DeepSeek (People’s Republic of China, AI legal drafting — default engine, only when a signed-in user generates an AI document), OpenAI (US, voice form-fill and AI drafting fallback or chosen engine), SendGrid (US), Stripe (US/Canada), ConvertAPI (EU/US), RevenueCat (US), Google Analytics (US, opt-in only), and Didit (outside Canada, ID document authentication — only when a host enables the optional automated check). Under PIPEDA we remain accountable for personal information transferred for processing; for Law 25 purposes this assessment documents those transfers so they can be reviewed or filed if required.
Information processed in another country is subject to that country’s laws and may be accessible to its courts, law-enforcement and national-security authorities. This matters most for the DeepSeek transfer: DeepSeek’s privacy policy states that it collects, processes and stores personal data in the People’s Republic of China. The risk and its mitigations are assessed in §8.
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Unauthorized access to the database | Low | High | HTTPS/TLS everywhere; password hashing; bearer tokens; Canada-hosted infrastructure; least-privilege admin; backups. |
| Link to a signing session is shared/forwarded | Medium | Medium | Per-session passcode (optional) that guests must enter before joining; host can kick any guest; participant_removed is audited. |
| Identity fraud / wrong person signs | Medium | High | Host-led IDV: government-ID photo + selfie compared with live video, with Verify/Reject recorded; host can confirm identity personally with a logged reason. |
| Recording or IDV images accessed by unauthorized parties | Low | High | IDV images stored server-side under a session-scoped path, served only to the authenticated host; recordings are client-side (host downloads); access is audit-logged. |
| Breach of a sub-processor | Low | Medium | Only necessary data is transferred; no training use for OpenAI (its API terms) — DeepSeek’s Open Platform terms contain no equivalent commitment (see the next row); minimum data for conversions; sub-processors listed in the policy; incident register maintained. |
| Cross-border transfer of AI drafting inputs to the People’s Republic of China (DeepSeek): the information becomes subject to Chinese law, may be accessible to authorities there, and is handled under DeepSeek’s own terms | Medium | High | AI drafting is optional and limited to signed-in accounts (2 free generations per account, unlimited on Pro and Pro Signing), with a 250-character heading cap and at most 3 requests per account every 10 minutes; the transfer, the provider and its location are disclosed in the privacy policy; only the form fields are sent (title, profession, document type, compliance type, jurisdiction, province, notes, and the selected parties’ name, email, occupation, city and province) — no PDFs, saved documents or other files are sent for drafting; users can leave out parties and notes; the per-account “Turn off all AI features” switch is enforced server-side; the administrator can set OpenAI as the primary engine; inputs are not stored by us (token-count metadata only); per-IP daily limit. Residual risk: DeepSeek’s Open Platform terms are governed by the laws of mainland China and do not commit to excluding API inputs from model training. |
| Consent not given or withdrawn | Low | Medium | Explicit consent modal before joining/signing (recorded in the audit trail); optional features can be declined; client-side tools need no data. |
| Over-retention of personal information | Medium | Medium | Retention table in the privacy policy; account deletion purges VSR/IDV data; IDV images destroyed when the purpose ends. |
| Non-consensual tracking/analytics | Low | Medium | Analytics are first-party only by default; Google Analytics loads solely after explicit opt-in via the consent banner. |
| Automated decisions affecting an individual | Low | Medium | AI outputs are suggestions presented as editable text; no consequential decision about a person is made automatically. |
Retention limits are set out in the privacy policy and enforced by the Service where it controls the data. Video recordings are downloaded by the host and retained by them for their professional records (as applicable notarial practice requires); IDV photos/selfies are destroyed once the verification purpose ends or the session records are deleted. The organization will document its exact notarial record-keeping period and enforce automatic deletion where feasible.
If a security incident creates a real risk of significant harm, affected individuals and the OPC (and, for Quebec residents, the CAI) are notified as soon as feasible. A confidential register of confidentiality incidents is maintained as Law 25 requires.
This PIA is reviewed whenever the Service changes materially (new data processing, new sub-processors, changed flows) and at least annually. Version history is kept below. This page is the public copy; the organization keeps the working version and any CAI filing.
| Role | Name / status | Date |
|---|---|---|
| Prepared by (engineering) | AICS Solutions engineering team | 2026-08-19 |
| Reviewed by (legal) | Pending — qualified legal review recommended | — |
| Approved by (Privacy Officer) | Marcin Migdal | 2026-08-19 |
| Version | Date | Change |
|---|---|---|
| 1.0 | 2026-08-19 | Initial assessment covering accounts, e-signature, Video Signing Room, IDV, AI legal drafting, billing and analytics. |
| 1.1 | 2026-09-17 | AI legal drafting: DeepSeek (People’s Republic of China) added as the default engine, with OpenAI (US) as the automatic fallback or an optional engine; data inventory, data map, cross-border transfers and risk assessment updated. Same day: AI drafting opened to every signed-in plan (2 free generations per account; unlimited on Pro and Pro Signing) with per-account rate limits; data inventory and risk mitigation updated. |