Incident and Breach Response Policy

Draft for legal review, 12 October 2026. This policy says what JOLIVE Labs Inc., 95 King William Court, Cambridge, Ontario N3C 4J3 ("SourceSecure", "we") does when the security of information we hold fails or may have failed: who decides, who is told and how quickly, and what we keep a record of. It is the policy the Data Processing Agreement refers to in section 6 and Schedule B.

1. What this covers

1.1 An incident is anything that may have put information we hold at risk: a lost or stolen device or credential, access by somebody who should not have had it, a fault in our code that sent or showed information it should not have, a mistake that sent information to the wrong person, an attack on our servers, or a report from one of our subprocessors that something of this kind happened to them.

1.2 A breach is an incident where personal information was actually lost, or was accessed, used or disclosed without authority. Canadian law calls this a breach of security safeguards (PIPEDA); Quebec's law calls it a confidentiality incident. This policy uses "breach" for both.

1.3 It covers everything SourceSecure runs or relies on: our servers and database on Google Cloud in Montreal, the website and the team page, the browser extension, the accounts we administer them with, the support mailbox, and the companies listed at sourcesecure.ca/subprocessors.

1.4 A fault in the extension that lets a client detail leave a person's computer when it should not have is an incident under this policy, even though the detail was never on our servers.

2. What we hold, which sets the limits of a breach

2.1 What a breach of our servers could expose is limited by what is there. We hold staff email addresses, team and seat records, a masked record of each detail caught (its kind, and the last few digits of a number or the initials of a name), when protection was paused, daily counts, what a firm's admins typed for the whole firm (word lists, the firm profile and the firm playbook, which can include client names an admin chose to type), each firm's billing name and address, and the versions of our terms each firm agreed to.

2.2 We do not hold message text, attached files, AI replies, card numbers or passwords. Each person's vault and Living Vault are kept on their own computer and are never on our servers. The Privacy Policy at sourcesecure.ca/privacy says what is kept and for how long.

3. Who is responsible

3.1 SourceSecure's privacy officer, Jacob Oliveira (support@sourcesecure.ca), leads the response to every incident and makes the decisions this policy calls for: whether an incident is a breach, whether it creates a real risk of significant harm, who is told, and when.

3.2 SourceSecure is a small company and the privacy officer is also the person who operates the service. There is no second responder today. If that changes, this policy will name them.

3.3 Anybody working for SourceSecure who notices or suspects an incident must tell the privacy officer at once, and must not wait to be sure.

4. How we find out

We learn of incidents from reports sent to support@sourcesecure.ca (the address in our security.txt), from firms and their staff, from our subprocessors, from our own logs and automated checks, and from people who research security in good faith under the policy at sourcesecure.ca/security#report. The moment the privacy officer has enough to believe a breach of personal information has happened is the moment we "learn of" it, and the 72 hours in section 6 run from then.

5. What we do, in order

5.1 Record it. An entry is opened in the breach register (section 8) as soon as an incident is suspected: when it was noticed, by whom, and what is known. The entry is added to as the response goes on. An incident that turns out not to be a breach is still recorded, with why.

5.2 Contain it. Stop it getting worse before anything else: revoke or replace the credential or key involved, switch off the part of the service affected, remove the access, suspend the account or seat involved, and, where the fault is in the extension, publish a corrected version to every store. Nothing is deleted that would be needed to understand what happened.

5.3 Assess it. Work out what information was involved and whose: which firms, which people, how many, how sensitive, for how long, and who could have obtained it. Then decide whether there is a real risk of significant harm to any individual, weighing how sensitive the information is and how likely it is to be misused. For people in Quebec the question is whether there is a risk of serious injury, weighing the same things. The reasoning is written in the register whichever way the decision goes.

5.4 Tell the firms affected (section 6).

5.5 Tell regulators and individuals, where that is ours to do (section 7).

5.6 Fix the cause and review. Find why it happened, fix it, test the fix, and within 30 days write a short review into the register: what happened, what was done, and what has changed so it does not happen again. If the review shows this policy was wrong or incomplete, the policy is changed.

6. Telling firms

6.1 If a breach involves personal information we handle for a firm, we notify that firm's admins and Guard Enterprise team heads without undue delay and in any case within 72 hours of learning of it, as the Data Processing Agreement (6.1) requires. We do not wait until everything is known.

6.2 The notice is an email to each affected firm's admins and team heads, sent with the same tool we use for other notices to admins, which records who was told and when. If our own email service is what failed, we send it from another mailbox and record that.

6.3 The notice says, as far as is known at the time: what happened and when; what information was involved and whose; what could follow from it; what we have done and are doing; what the firm can do to protect itself and its people; and who to write to. Later emails add what we learn, until the incident is closed.

6.4 We cooperate with the firm's own assessment, and help it notify regulators and individuals where the law requires it to. The firm controls the personal information of its staff and clients, so that decision is the firm's.

6.5 Telling a firm about a breach is not an admission of fault.

7. Telling regulators and individuals

7.1 Where a firm is responsible for the information (its staff's and clients' personal information, which we handle on its behalf), the firm decides whether to report to a regulator and whether to notify individuals. We give it what it needs to do so, and we report or notify directly only if the firm asks us to or the law requires it of us.

7.2 Where we are responsible for the information (for example the account details of the people who buy and administer SourceSecure, and anything a visitor sends us), and we decide there is a real risk of significant harm to an individual, we will, as soon as feasible:

• report the breach to the Office of the Privacy Commissioner of Canada, in the form it requires;
• notify the individuals affected, directly, in plain words, saying what happened, what information was involved, what we have done, what they can do, and how to reach us and how to complain to the Commissioner;
• tell any other organization or government body that may be able to reduce the harm.

7.3 Where the breach involves a person in Quebec and presents a risk of serious injury, we will also notify the Commission d'accès à l'information and the person concerned, with diligence.

7.4 Where the privacy laws of Alberta or British Columbia apply, we follow their requirements as well.

8. The breach register

8.1 We keep a record of every breach of security safeguards involving personal information under our control, whether or not it created a real risk of significant harm, and of every incident investigated under this policy.

8.2 Each entry records: the date or estimated date of the breach and the date we learned of it; what happened; the kind of information involved; which firms and roughly how many individuals; the assessment of risk and the reasons for it; what was done to contain and fix it; whether firms, individuals and regulators were told, and when; and the review in 5.6.

8.3 Entries are kept for at least 24 months after the day we determined the breach occurred, as PIPEDA requires, and for at least five years where the incident involves a person in Quebec. We will give the register to the Privacy Commissioner or the Commission d'accès à l'information on request.

8.4 The register is kept by the privacy officer, outside our source code and separate from customer records, because an entry can name people. Only the privacy officer has access to it.

9. Our subprocessors

Our contracts with the companies that handle information for us require them to tell us of a breach affecting it. Their notice to us is treated as an incident under this policy from the moment we receive it, and the 72 hours in section 6 run from when we learn that personal information we handle for a firm was involved.

10. Keeping this policy current

The privacy officer reviews this policy at least once a year and after every breach. The date at the top shows the last change.

11. Contact

To report an incident, or to ask about this policy, write to support@sourcesecure.ca with "Security" in the subject.