Quebec Law 25 Privacy Impact Assessments: What a Document Platform Project Must Map

A document platform concentrates personal information from many business processes. The privacy impact assessment therefore needs more than a hosting-region answer. It should map how documents and extracted data move through intake, storage, search, workflow, AI processing, support, backup, and connected systems.

Distinguish the project assessment from an outside-Quebec assessment

This guide focuses on enterprises subject to Quebec’s private-sector privacy Act, as amended by Law 25. Section 3.3 requires a privacy impact assessment for an acquisition, development, or overhaul project involving an information system or electronic service delivery system and personal information. Consult the person in charge of personal-information protection from the outset. Public bodies and health-sector organizations need an assessment of their own applicable legal framework.

A PIA, or évaluation des facteurs relatifs à la vie privée (EFVP), should be proportionate to sensitivity, intended use, quantity, distribution, and storage medium. A list of services and regions is an input to the assessment; it does not by itself establish that the project’s privacy risks are acceptable.

The CAI’s private-sector guidance explains the assessment required before communicating personal information outside Quebec or entrusting an outside-Quebec party to collect, use, communicate, or keep it on the enterprise’s behalf. This includes other Canadian provinces as well as other countries. The assessment must support adequate protection, and the communication needs a written agreement. Resolve these questions before enabling the affected flow; a general project PIA should not silently stand in for analysis of a new destination or provider.

Scope reviewed: November 9, 2026. The examples below are implementation exercises. The enterprise’s privacy owner determines the applicable obligations and records the legal and risk decisions.

FormKiQ’s point of view: follow the information beyond the repository

We see deployment ownership as a way to make privacy controls inspectable. Choosing the primary storage region is useful, but the assessment also needs to follow extracted text, metadata, embeddings, generated documents, support exports, and recovery copies. A copy outside the main repository can carry the same personal information and create a different access or retention risk.

Connect each approved assumption to an owner, a configured control, and evidence that it works. FormKiQ provides the document and integration context; the organization remains responsible for deciding which information is necessary, which processing is permitted, and which risks require treatment before release.

Start with business processes, not infrastructure

List the processes that will use the platform: employee records, customer applications, contracts, claims, case files, correspondence, supplier documents, and public submissions. For each process, identify the people involved, purpose, the applicable collection and use basis, document types, sensitivity, and expected lifecycle. Record whose interests could be affected and what harm an unnecessary disclosure, incorrect inference, or excessive retention could cause.

This prevents a generic assessment from overlooking that the same repository may contain routine business records and highly sensitive health, financial, identity, or employment information.

Map every processing location

Document where each data category is processed or copied:

• primary object and metadata storage;
• OCR, classification, extraction, translation, and summarization;
• full-text or vector indexes;
• email, SFTP, scanner, and cloud-storage gateways;
• identity and access-management services;
• logs, metrics, alerts, and support records;
• backups, disaster-recovery copies, and test environments;
• eSignature, CRM, ERP, HRIS, and case-management integrations.

A document stored in Quebec can still be processed or accessed elsewhere through an AI service, support workflow, index, or integration. Record the service, operator, configured processing location, support access locations, data sent, copies retained, and downstream recipients. “Canada” is not the same boundary as “Quebec,” and a provider’s head-office address is not a complete processing-location record.

Assess each outside-Quebec flow before enabling it

For a proposed destination, the CAI’s PIA guide identifies sensitivity, purpose, safeguards including contractual measures, and the destination’s legal framework as assessment factors. Record the supporting information, the risks identified, and the resulting protection assessment. Link the written agreement to the assessed service and activities, including the agreed risk-reduction measures.

A contract alone is not proof that the deployed flow matches the assessment. Verify the actual endpoint, service settings, recipients, access controls, and copy handling. Keep notice, consent, and any applicable legal exception as separate questions for the privacy owner; an approved architecture diagram does not resolve them automatically.

Record purpose and minimization at field level

Schemas and attributes can make personal information easier to find and automate. They can also create unnecessary structured profiles. For each field, record why it is needed, who uses it, whether it can be derived instead of retained, and when it should be deleted.

Avoid copying entire source-system records into document metadata when a stable identifier is sufficient. Derived text and embeddings should be included in the inventory rather than assumed anonymous. For troubleshooting, prefer synthetic examples or a minimized support package over exporting a whole live case file.

Turn the flow map into risk decisions

For each material flow, describe the privacy risk, affected people, likelihood and impact, proposed safeguard, and remaining risk. Assign an implementation owner and decision authority. Record conditions that must be satisfied before release, evidence still missing, and the reasons for accepting or rejecting the proposed design.

For example, a support export may expose more information than the ticket requires. Minimize the fields and documents, restrict the destination and recipient, limit access duration, and define deletion evidence. If the destination or recipient cannot be established, keep that path disabled while the assessment remains unresolved.

Verify access and lifecycle controls across the copies

Test representative access and denied-access cases through search, previews, exports, and document retrieval. Include revocation, support roles, and temporary links. The assessment should describe actual behavior and any token or cache window rather than equating a policy file with effective access control.

Map retention and deletion to originals, extracted text, indexes, generated outputs, integration copies, and backups. Define how applicable holds affect disposal and how restored data is reconciled with later deletion decisions. Test access, correction, and export workflows for the person concerned, including the structured-format capability required for relevant computerized information under section 3.3.

Make the assessment an operating control

The PIA should be revisited when a new document type, region, AI model, gateway, subprocessor, support path, or integration changes the risk. Keep the assessment version, approved scope, unresolved actions, supporting agreements, decision authority, and reassessment triggers connected to the deployment change process. Define which changes require privacy review before activation.

For example, if restricted documents may only use an assessed AI-processing path, constrain the allowed model endpoint or inference profile and the data sent. Evaluate document excerpts, prompts, responses, provider retention, and logging as part of that flow. Test that a disallowed configuration is blocked; do not assume the repository’s region constrains every model request.

Worked example: adding AI summaries to a Quebec case file

Illustrative configuration exercise, not a legal conclusion or reported customer deployment.

1. 1. Describe the proposed use

   A case team proposes summaries of personal-information-heavy submissions. Identify the necessary fields and excerpts, intended users, model service, configured processing route, retained responses, and logs.

2. 2. Assess the new flow

   The original repository assessment did not cover this processing route. The privacy owner reviews the destination and provider activities, determines the applicable assessment and agreement requirements, and records the risks and proposed safeguards.

3. 3. Configure and test the conditions

   Limit eligible document categories and outgoing content, allow only the assessed processing route, restrict access to summaries, and set the approved retention rules. Use synthetic documents to test both permitted requests and blocked attempts.

4. 4. Retain the decision and monitor changes

   Connect the assessment, agreement references, configuration, test evidence, and release decision. A new model, inference profile, support route, or retained data category triggers the defined review before use.

How FormKiQ supports the evidence model

A customer-managed FormKiQ deployment gives the operator control of the AWS account and selected supported region for the document platform. Attributes and schemas can represent document classifications and business context; configured access policies, records controls, and audit activity can supply evidence for the assessment. Confirm the capabilities, modules, and operating responsibilities in the selected deployment.

Scope the data-flow inventory, privacy assessment, agreements, technical restrictions, and verification as implementation and governance work. Review AI processing, KnowledgeBase retrieval, signing providers, support access, and connected systems separately from primary storage. Customer-controlled deployment makes the resources more inspectable; compliance depends on the assessed activities and the controls actually operated.

A document-platform PIA drill buyers can run

• Trace one sensitive submission. Locate its original, metadata, extracted text, index entries, generated copies, and support or integration exports.
• Challenge the location claim. Identify the configured processing routes and remote-access locations, including any outside Quebec.
• Try a disallowed processing path. Verify that the deployed controls enforce the assessment’s conditions.
• Revoke access. Check search, previews, temporary links, downloads, and integration copies against the expected behavior.
• Exercise correction and disposal. Trace changes through derived data and copies, with holds and backup handling recorded.
• Change a provider or model. Confirm that reassessment, agreement review, and required approvals occur before activation.