Laravel development for Montreal businesses under Quebec privacy rules

Quebec's privacy regime asks a backend for things most privacy work does not, and two of them are features rather than policies.

A Montreal business has to be able to hand somebody their data in a form another system can actually read, and it has to be able to explain a decision that software made about a person. Neither can be retrofitted convincingly, because both depend on information being recorded at the time rather than reconstructed afterwards.

Montreal portability is a Laravel feature with a schema

An export is not the same as portability. A PDF of somebody's account is an export and satisfies nothing, because the requirement is a structured format in common use that another system can consume.

That makes it a real piece of work with design decisions in it. The field names have to be stable and documented, because a format that changes shape between releases is not a format. The content has to distinguish between data the person provided and data the business derived - the first is in scope and the second generally is not, and conflating them either under-delivers or discloses internal scoring.

And it has to be produced on request rather than assembled by an engineer each time. A portability feature that requires a developer is a feature the business will quietly stop honouring at scale.

Privacy by default is a Laravel migration, not a settings screen

The requirement that defaults be the most protective option sounds like an interface concern and is mostly a database one.

When a column is added to control whether something is shared, three things have to agree: the column's default is the restrictive value, existing rows are backfilled to the restrictive value, and the factory or seeder used in development does the same. If any of the three disagrees, a user who never opens a settings page ends up in the permissive state.

The failure that recurs is a boolean named for the permissive condition - is_public defaulting to false reads as safe, while is_private defaulting to false is the opposite, and a column named share_profile tells you nothing about which way false points. Naming the column for the restriction makes the safe default also the obvious one.

A decision made by code has to be explainable

If software approves, declines, prices or ranks a person, the business has to be able to say why - to that person, later.

A score alone cannot do that. What is needed is the decision stored with its inputs, the version of the rule set or model that produced it, the threshold applied and the outcome. Stored, not recomputed, because recomputing answers today's version of the question and the person is asking about March.

This is the same structural point as versioned pricing rules elsewhere: a system that derives the past from the present cannot account for itself. Here it has a specific consequence, which is that a customer service representative can answer a question without a developer reconstructing a decision from logs.

Scoping a Montreal breach quickly

The reporting obligation has a clock on it, and what consumes the clock is not the notification - it is establishing who was affected.

Answering that depends on whether the system knows which records existed in which state, who accessed what, and where copies live. Those are schema decisions taken long before any incident, and they are the difference between an answer in an afternoon and a fortnight of inference. The related reading is a soft delete is not a delete, because a record that is hidden rather than removed is still a record that was exposed.

The country-level ground - federal privacy law, French-language obligations, invoicing - is on the Canada market page.

A Montreal privacy assessment is a question about the schema

The assessment arrives as a document with questions in it, and every question has an answer that lives in the database rather than in a policy.

What personal information is collected. For what purpose. On what basis. How long each item is kept. Who inside the organisation can read it. Where it is processed and by whom. Those are not abstractions - they are a list of columns with a sentence against each, and the organisations that answer quickly are the ones that keep that list in the repository beside the migrations rather than in a document somebody wrote once.

Keeping it there has a second effect worth more than the first. A new column without an entry is visible in review, which turns the assessment from an annual exercise into something that stays true. The failure mode of the document approach is not that it is wrong on the day it is written; it is that it is eighteen months stale by the time anybody needs it.

Retention is the field most often left blank and the one with the most teeth. "As long as necessary" is not an answer a regulator accepts and it is not an answer a system can implement. A number of months against each category, with a scheduled job that acts on it and a record of what it deleted, is both the answer and the evidence.

Laravel transfers out of Quebec are records, not a diagram

The obligation is to know where the data goes before it goes there, and an architecture diagram is the wrong instrument because it does not change when the configuration does.

Every destination outside the province is a record - the recipient, the purpose, the categories of data, the region it processes in, and the assessment that was done before it was used. That includes the obvious ones and, more importantly, the ones nobody thinks of as destinations: the exception reporting service, the transactional email provider, the file conversion API, the analytics tool somebody added to a template.

The useful discipline is to make the list the thing the application reads from rather than a description of it. Outbound integrations are configured from the registry, so a destination that is not in it is a destination the application cannot reach, and adding one is an action with a review attached rather than an environment variable set on a Friday.

Breach notification depends on the same registry, which is the argument that tends to land with a board. When an incident happens, the questions are what data, whose, where it went and who else holds it - and the organisation either answers in an afternoon from a list or spends a week reconstructing it from code while a notification deadline runs.

Commercially

Scope fixed in writing before work starts, priced per project.

Invoiced by Codefacture Yazılım A.Ş. in Türkiye, in Canadian or US dollars by bank transfer, with no Turkish VAT under the export-of-services exemption.