as a risk mitigtion stragegy, would it help to, instead of collecting the most sensitive data, account #‘s, passwords, etc… We develop a report system where we provide say a pdf report with placeholder for all their accounts, etc… and leave it up to the client to fill in their own data and store it safely - it might also help them get a comfort level with us that we’re not asking for that information.
That’s a smart instinct — and yes, it materially changes your risk profile. Let me break down exactly what it does for you.
What it changes
| Risk Area | Collecting it yourself | Report + client fills in offline |
|---|---|---|
| Breach severity | Catastrophic — attacker gets account numbers, passwords, credentials for every household | Dramatically reduced — you hold names, relationships, asset descriptions, but not the keys to the vault |
| PIPEDA sensitivity classification | Maximum — financial credentials are among the most sensitive categories | Still sensitive (financial descriptions, health info) but missing the highest-damage data |
| Cyber insurance premium | Higher — underwriters see credential storage as concentrated risk | Lower — removing credential storage removes the most dangerous line item |
| Criminal Code exposure (s.342.1) | If breached, stored credentials enable unauthorized access to third-party accounts — potential negligence liability chain | No stored credentials means no chain |
| Zero-knowledge architecture | Required — expensive to build and maintain | Not required for this category |
| User trust at onboarding | Friction — “why do you need my bank password?” | Lower friction — “we don’t want your passwords, we want to make sure your executor can find them” |
The report model
What you’re describing is essentially a guided template approach:
- Focura collects the structural information — what exists, where it is, who it’s for, how it flows
- Focura generates a personalized PDF report with placeholders for the sensitive details the executor will need — account numbers, login credentials, PINs, safety deposit box locations
- The client prints it, fills it in by hand, and stores it in their own secure location (safety deposit box, fireproof safe, with their lawyer)
- Focura never sees, stores, or transmits the most dangerous data
The report becomes part of their “death dossier” — which is exactly what your father built and what started this whole thing. It closes the loop beautifully.
What you’d still collect (and what you wouldn’t)
| You collect (in Focura) | You DON’T collect (client fills in offline) |
|---|---|
| Asset descriptions (type, institution, approximate value) | Account numbers |
| Ownership and beneficiary designations | Login credentials / passwords |
| Insurance policy existence, type, coverage amount | Policy numbers |
| Bank name, branch, relationship manager | Online banking credentials |
| Crypto asset existence and type | Private keys, seed phrases, wallet passwords |
| Contact information for institutions | PINs, security questions, 2FA recovery codes |
| Location references (“safety deposit box at TD on Main St”) | Safety deposit box key location, access codes |
What it does to your regulatory posture
PIPEDA: You still need express consent for what you collect — financial descriptions and health information are still sensitive. But you eliminate the most dangerous category entirely. If the Privacy Commissioner ever investigates, the fact that you chose not to collect credentials is a powerful demonstration of the Limiting Collection principle (Principle 4).
UPL risk: No change — this is a data architecture decision, not an advice question.
Breach notification: A breach is still reportable if it meets the RROSH threshold, but the harm analysis changes dramatically. Leaking “Tim has an RRSP at BMO worth approximately $400K” is bad. Leaking “Tim’s BMO login is tim@email.com / password123” is catastrophic. You move from catastrophic to manageable.
Cyber insurance: This is where you’ll see the most tangible benefit. Removing credential storage from your risk profile could easily knock 20–30% off your premium, and it simplifies the underwriting conversation significantly.
The trust angle is real
You identified something important: asking for passwords on Day One is a trust barrier. The client is thinking “I barely know you and you want my bank login?” The alternative message is much stronger:
“We don’t want your passwords. We don’t store them, and we don’t need them. What we do is make sure your executor knows where to look and who to call. The sensitive details — the account numbers, the credentials — those stay with you, in your own secure location. We’ll give you a report with exactly what to fill in and where to keep it.”
That’s a differentiator. Most competitors in this space try to be the vault for everything. You’re saying: “We’re smarter than that. We organize the picture. You keep the keys.”
One thing to think through
The tradeoff is completeness at the point of death. If the client fills in the PDF and stores it in a safety deposit box, and the executor can’t find the key, or the client never fills it in, or it’s ten years out of date — the executor is back to detective work for the sensitive details.
Mitigation options:
- Periodic nudge: Focura reminds the client annually — “Have you updated your secure details report? Here’s a fresh copy.”
- Executor briefing: The executor checklist in Focura tells them where the report should be and who to call if they can’t find it
- Dual copy guidance: Suggest the client give a sealed copy to their lawyer and keep one in their home safe
You’re not solving the completeness problem perfectly — but you’re solving it well enough while eliminating the most dangerous data from your servers. That’s the right tradeoff for your stage.
Should you update the retention policy?
Yes — if you go this route, the retention and deletion policy simplifies. The entire “zero-knowledge credential vault” architecture, the 90-day post-death credential deletion, and the HSM key management requirements all become unnecessary. I can update it once you’ve decided.