Who has access to which personal information, and since when?
This is the first question asked in a review, and the one most organizations struggle to answer. Access accumulates without anyone taking it away: departed employees whose accounts still exist, permissions granted “just for this project” two years ago, shared accounts nobody can attribute to a person any more.
The technical work comes down to three moves. Build the inventory of systems that actually hold personal information — the list is almost always longer than expected. Cut every access back to what the role genuinely needs. Then set a recurring review, because a cleanup done once undoes itself within months.
This is not a project with an end date; it is a routine. The cybersecurity page covers this ground in more detail.
How long do you keep it, and can you actually delete it?
The law expects personal information not to be kept indefinitely, and expects you to act on a deletion request. Two difficulties surface as soon as you try.
The first: the retention period is written down nowhere. Everyone has an approximate idea, no two are the same, and nothing enforces any of them.
The second is more serious. Deletion is almost always partial. The record disappears from the main application but survives in an export, a shared spreadsheet, a test environment fed from a copy of production — and in the backups. That is the part most organizations discover too late: a restored backup brings back exactly what everyone believed had been erased.
The work is to set a retention period per category, to enforce it with a mechanism rather than with good intentions, and to document the backup situation honestly, rotation cycle included. The data page deals with that kind of cleanup.
Would you be able to tell that an incident happened?
Law 25 introduces the obligation to keep a register of confidentiality incidents and, where the risk of serious harm warrants it, to report them. But you can only record what you detect.
Without access logs kept long enough, an incident leaves no usable trace. Plenty of organizations do have logs — with a few days of retention, or in a format nobody has ever opened. Discovering an unusual access three weeks after the fact is then impossible, not through negligence, but because the evidence no longer exists.
The technical work: log access to the systems that carry personal information, keep those logs for a useful period, know who reviews them and how often, and prepare the register ahead of time rather than under pressure. The register template is the easy part — provided you do not wait for an incident to write it.
Where is the information hosted, and who can technically read it?
Before personal information is communicated outside Quebec, an assessment is expected. Technically, it starts with a factual answer: which services process personal information, in which region, and which subcontractors can reach it.
The exercise tends to surprise people. A customer support tool, an analytics module, an email platform, a backup service: each one may hold a copy of something. The list cannot be guessed; it has to be built.
The work is to inventory those services along with their hosting region, then keep the list current. It is precisely the document a client, an insurer or a review will ask you to produce.
What technical work cannot settle
Designating the person responsible for the protection of personal information, drafting and publishing policies, managing consent, running the required assessments, deciding whether an incident must be reported and to whom: none of this is solved by a configuration change.
That work belongs to governance and, depending on the situation, to legal counsel. Optigm does not provide it, and says so up front. What technical work can contribute is making those decisions enforceable — and verifiable.
Where to start
One thing, before any plan: the list of systems that hold personal information, with who accesses each one, how long it is kept and where it is hosted.
Four columns are enough. Until that table exists, everything else — policies, timelines, budgets — rests on assumptions. If it surfaces more grey areas than expected, the express assessment starts from exactly that point.