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 (document type, profession, jurisdiction, party names/emails, notes) | Pro Signing account holders | 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: OpenAI (US), 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.
| 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 (OpenAI API terms); minimum data for conversions; sub-processors listed in the policy; incident register maintained. |
| 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. |