Breach Response Procedure

Version 0.1.0 (draft) · text fingerprint f1fbad04e4d1

DRAFT: not legal advice, requires review by a Canadian lawyer before use with real customers.

Breach Response Procedure

Public summary

If something goes wrong with your information, we will act fast. We contain the problem, work out whether you could be seriously harmed, and tell you and the Privacy Commissioner of Canada if so. We keep a record of every security breach, even small ones. Where a harvester fishes counts as sensitive information. Questions: [PRIVACY CONTACT EMAIL].

Internal runbook

Who does what

• Privacy officer [PRIVACY OFFICER NAME]: owns the decision, the record and the notices.
• Engineer on call [ENGINEER ON CALL]: contains the problem and fixes it.
• Anyone on the team who suspects a breach reports it at once.

What counts as a breach

A breach of security safeguards is any loss of, unauthorized access to, or unauthorized sharing of personal information. Examples: a leaked key, a wrong person seeing a position they should not, a lost laptop, an email sent to the wrong address, a database opened to the internet. Report it even if you are unsure it counts.

Steps

1. Report. Tell the privacy officer immediately. Do not wait to be sure.
2. Contain. Stop the harm first (see "Rotate first" below).
3. Assess real risk of significant harm. Look at two things.
   • Sensitivity. Position data about where a harvester fishes is sensitive. So are names with contact details.
   • Probability of misuse. Who got it, did they mean harm, was it encrypted, can it be linked to a person?
4. Notify, if the risk test is met. As soon as feasible: [LAWYER: confirm the test, the reporting form and the timing.]
   • the Office of the Privacy Commissioner of Canada
   • the affected people
   • other organizations that can reduce harm
   • the affected group, under the Data Processing Addendum [72] hour term
5. Record every breach of security safeguards, even if you do not notify. Keep each record for 24 months from the date it was determined.
6. Review within 14 days. Fix the cause. Write down what changed.

How to contain

• Stop the access: revoke sessions, disable the leaking route, or take the service offline if needed.
• Keep evidence: save logs and timestamps before changing anything.
• Do not delete data to hide a problem. Do not message the person who caused it before the privacy officer agrees.
• Write down the time you noticed, the time you contained it, and who did what.

What the record holds

• date
• what happened
• what data
• how many people
• the risk decision and why
• who was told and when
• what was fixed

Fix and learn

At the 14 day review, answer: why did it happen, what stopped us noticing sooner, what is the smallest change that prevents it, and who does it by when. Add a test or a check where you can. Update this procedure if a step was missing.

Rotate first

1. Clerk keys and active sign-in sessions.
2. Database credentials.
3. Hosting, email and AI service keys.
4. Webhook secrets.
5. Revoke device sessions.

Contact list

Notice to individuals checklist

The notice must say, in plain words:

• ☐ what happened and when
• ☐ what information was involved
• ☐ what we have done about it
• ☐ what you can do to protect yourself
• ☐ who to contact with questions, and how
• ☐ that you can complain to the Privacy Commissioner of Canada

Send it directly to each person. Do not bury it in a general notice. Do not blame anyone.