Written by Mike Pearlstein, CISSP, CEO of Fusion Computing Limited. Helping Canadian businesses build and manage secure IT infrastructure since 2012 across Toronto, Hamilton, and Metro Vancouver.
The FSRA notification clock does not start when your alert fires. It starts when the brokerage determines that the incident is material, and FSRA expects the notification as soon as is reasonable, normally inside 72 hours of that determination.
That distinction decides everything. What an Ontario supervisor examines is how long you took to reach the determination, and whether you recorded why. In my experience a brokerage with no dated materiality call has no defensible start time.
So the 15 minutes in this SOP are mine, not FSRA’s. They are the internal cadence I run to move an Ontario brokerage from detection to a recorded materiality decision, which is the only clock a regulator can audit.
This is the per-incident procedure inside our FSRA-aligned cybersecurity playbook for Ontario financial brokerages. It applies to mortgage brokerages and insurance brokerages alike, because the IT Risk Incident Notification Form sits on the FSRA side of the umbrella.
Key Takeaways
- Practice 7 of FSRA’s IT Risk Management Guidance (GR0016INT, effective April 1, 2024) sets the trigger. Notify as soon as is reasonable, normally within 72 hours or sooner, after determining that an IT risk incident is material.
- The materiality determination is therefore the artifact that matters. Log who made it, when, and on what facts. That timestamp anchors the 72-hour window.
- “Material” turns on impact to clients, services, sensitive data, or the brokerage’s ability to operate. A lender-portal compromise qualifies. A bounced password-reset email does not.
- FSRA guidance MB0048INF names the channel for mortgage brokerages: the IT risk inbox at [email protected] and the Incident Notification Portal.
- The principal broker or broker-of-record signs. A managed-service provider drafts and supports, and never signs on the brokerage’s behalf.
FSRA’s mandatory IT Risk Incident Notification, explained: what the guidance requires
Read Practice 7 twice. It contains two clauses that brokerages routinely collapse into one. The first is a standard of promptness. The second is the event that starts the count, and that event is the entity’s own determination of materiality.
Collapsing them produces the two failure modes I see in Ontario. One brokerage treats detection as the trigger and files on partial facts. Another waits for a forensic report, reaches the determination late, and cannot show a supervisor when it knew.
The form is a structured intake with 7 fields that matter. Entity name and regulated activities. A short description. The detection date and time. Suspected client impact. The data and systems affected. Response steps taken. A senior accountable contact.
Filing waives nothing. FINTRAC reporting, PIPEDA breach reporting to the Privacy Commissioner, and Quebec Law 25 notification all stack on top of the FSRA filing and run on their own clocks.
One correction is worth making, because I have seen it in three Ontario brokerage binders. The 2025-26 FSRA Mortgage Brokering Supervision Plan does not single out IT risk, and never mentions the MBRCC principles. Your obligation comes from GR0016INT and MB0048INF, which stand on their own.
Material vs immaterial incidents: where the line sits
FSRA publishes no numeric materiality threshold, so an Ontario brokerage has to set its own and apply it consistently. The 6-test framework below is the one I deploy, and its value is that it exists on paper before the incident rather than being argued afterwards.
Most Ontario brokerages either over-report or under-report in their first 12 months. Under-reporting is the higher-risk failure. Over-reporting burns supervisory goodwill and exhausts a 12-person firm that has a mortgage pipeline to run.
An incident is material under our framework if any of these are true.
- Client-impacting service degradation lasting more than 4 business hours, such as Filogix down, Applied Epic locked out, or the phone system down on a renewal day.
- Confirmed or suspected unauthorized access to systems holding borrower or policyholder personal information: SIN, T4s, income documents, claims history, policy data.
- Confirmed or suspected exfiltration of any data set above 100 records.
- Ransomware deployment on any brokerage-owned or BMS-integrated system, even where the encryption was contained.
- A notification obligation triggered elsewhere: FINTRAC, the Privacy Commissioner, Law 25, a lender contract, a carrier contract, a cyber insurer clause.
- The incident-response plan is formally activated and outside counsel or a forensic firm is engaged.
An incident is immaterial when all 4 of these hold. Automated controls such as Microsoft Defender blocked it before data was reached. No client-impacting degradation occurred. No personal information was accessed, altered or exfiltrated. The matter closed inside normal IT operations.
Two grey zones come up constantly in Ontario. A broker clicked a phish but entered nothing: immaterial, though you log it and retrain. A broker clicked, entered credentials, and the attacker hit the MFA wall: I treat that as material, because valid credentials in an attacker’s hands is an impact question, not a control question.
Need help drawing the materiality line? Book a review with Mike Pearlstein, CISSP →
The 15-minute SOP: who calls, what is said, what is filed
Fifteen minutes is not enough time to file anything. It is enough time to stabilize, escalate, and reach the recorded materiality decision that starts the regulator’s 72 hours. Everything downstream depends on that decision existing in writing, which is why my cadence ends there.
| Min | Action | Owner | Output |
|---|---|---|---|
| 0-2 | Detect. Whoever sees the indicator phones the named IR contact. Voice, never email. | First responder | Timestamped incident-log entry. |
| 2-5 | Contain. Disable the account in Microsoft 365, pull the device off the network, leave it powered on. | IT lead | Containment action log. |
| 5-8 | Brief the principal broker verbally: what happened, what data is exposed, what is contained, what is unknown. | IT lead | Notification log with named recipient. |
| 8-11 | Make and record the materiality determination against the framework above. This timestamp anchors the FSRA window. | Principal broker | Signed 3-line determination memo. |
| 11-13 | If material, open the runbook and call the cyber-insurance hotline before engaging any forensic firm. | Principal broker | Counsel and carrier notification log. |
| 13-15 | Start drafting the FSRA notification and alert any lender or carrier whose data is exposed. | Principal broker | Draft form in the shared drive. |
Want this SOP rehearsed with your principal broker? Talk to Mike Pearlstein, CISSP →
Mortgage-broker-specific notification scenarios
Two scenarios recur often enough on the Ontario mortgage side to deserve their own runbook entries. Both turn on how fast the brokerage reaches a defensible materiality determination, and both carry a lender clock running beside the 72-hour one.
Scenario M1: lender-portal compromise
A Filogix or Velocity credential surfaces in a credential-stuffing campaign, or the lender reports abnormal session activity on the brokerage’s portal account. Even with no completed fraud, I treat this as material. That portal holds borrower SIN, T4s, income documents, and the full application history.
The difference against the generic SOP is the lender clock, which runs in parallel. Many Canadian lenders require notification inside 24 hours under their broker-channel contracts, which is tighter than FSRA’s 72. The FSRA filing and the lender notice should reference each other.
Rotate the credential at the platform level rather than resetting a password, audit 90 days of session activity, and run an access review across every broker account in that portal. Our FSRA-aligned cybersecurity playbook for Ontario financial brokerages covers the steady-state controls that turn this into a 90-minute fix.
Scenario M2: broker MFA bypass
A broker is phished, enters credentials, then accepts the push or loses a session token to an adversary-in-the-middle proxy. The attacker reaches the Microsoft 365 mailbox and the broker management system. Material from the moment attacker presence is confirmed, whatever data was touched.
Here the containment step expands. Revoke every active session in Entra ID, rotate the credential, audit mailbox rules for planted forwarding, review sign-in logs for the attacker IP range, and check OAuth applications the user consented to.
Insurance-brokerage-specific notification scenarios
Ontario insurance brokerages licensed by RIBO sit under the same FSRA notification umbrella, and 2 scenarios show up more often on that side. RIBO conduct matters run in parallel through the RIBO complaints process rather than through this form.
Scenario I1: broker management system compromise
An attacker reaches Applied Epic, Vertafore, EZLynx, or Power Broker. That system holds policyholder names, addresses, dates of birth, claims history, premium data, and sometimes banking details for pre-authorized debit. Even without confirmed exfiltration I treat it as material, because it is the largest concentration of personal information in the firm.
Here the impact assessment gets heavier. The brokerage must work out which carriers’ policyholders sit in the affected records, since every major Canadian carrier writes its own breach-notification clause into the broker contract. Some require 24 hours, some 72. Log each carrier notice separately.
Scenario I2: claims-data exposure by email misdirection
A broker sends a claims summary to the wrong external recipient, or a misconfigured group address fans a claims attachment across a wide internal list. This is the most common breach vector I see in Canadian insurance brokerages, and the easiest to miss as a notification trigger.
The response differs. Recall the message if Exchange Online permits, ask the unintended recipients in writing to delete it, document the request and the reply, and assess the PIPEDA real-risk-of-significant-harm threshold. Claims history usually clears it. Misdirection is not less material for being accidental.
Documentation evidence pack: the checklist FSRA actually asks for at audit
Brokerages confuse the IR runbook with the audit evidence pack. The runbook is the operational guide. The pack is what an examiner reads. FSRA does not publish a fixed contents list, so the eight items below are my assembly, built from what examiners have actually asked our Ontario clients for.
- The dated IT risk register signed by the principal broker, listing the top 10 to 15 IT risks, controls, residual risk, and review date.
- Policies: acceptable use, incident response, and AI use for insurance brokerages, each signed and dated.
- The annual tabletop after-action report showing this SOP was rehearsed end to end, with gaps and named remediation owners.
- The contemporaneous notification log for every material incident, with FSRA reference numbers and carrier timestamps.
- The materiality determination memos, which is the item most brokerages have never written and the one that proves your 72 hours.
- The access review log from the last quarter covering each BMS and lender-portal account, with retired accounts dated.
- Training completions from the last 12 months, including post-incident retraining for anyone who clicked a phish.
- Signed vendor reviews for the BMS, the lender and carrier portals, and the Microsoft 365 tenant, with data residency captured.
Freshness beats thickness every time. Everything above should carry a date inside the last 12 months, and I want the register and the access review newer than that.
Common notification mistakes: the 4-don’t list
Four mistakes account for most avoidable supervisory friction. We have run Ontario brokerage engagements since GR0016INT took effect in April 2024, and the pattern holds. Three of the four are process failures, and the fourth is forgetting that other Canadian regulators exist.
| Don’t | Why it fails | Do this instead |
|---|---|---|
| 1. Leave the materiality call undocumented. | With no written determination there is no defensible start time, so a supervisor measures your 72 hours from the earliest evidence of awareness. | Write a 3-line memo naming the decision-maker, the time, and the facts relied on. |
| 2. Let the provider file on the brokerage’s behalf. | The principal broker or broker-of-record is the accountable signatory, so a provider-signed filing is incomplete on its face. | The provider drafts. The principal broker reviews, signs, and files. |
| 3. Communicate by email only. | Email runs through the systems that may be compromised, and it is slow. | Voice for the first 15 minutes. Email and shared-drive entries are the documentation layer. |
| 4. Forget the parallel notifications. | An FSRA filing does not satisfy PIPEDA section 10.1, Law 25, FINTRAC, lender or carrier contracts, or the cyber insurer clause. | Keep a one-page parallel-notification checklist in the runbook and walk it top to bottom. |
Post-incident review and FSRA follow-up
The notification is not the end of the cycle. FSRA expects evidence of remediation and, depending on severity, a follow-up conversation. The seven steps below are what Fusion Computing runs in the 30 days after an initial filing, and they produce the three artifacts an examiner reads first.
7-step post-incident review, run in the 30 days after the initial notification.
- Forensic close-out, days 1-7. Receive the written incident report, review it with counsel, and confirm the root cause in writing.
- Affected-individual notification, days 1-10. Under PIPEDA section 10.1, notify individuals and the Privacy Commissioner. Under Quebec Law 25, notify the Commission d’accès à l’information and the affected Quebec residents.
- FSRA update, around day 5. Send what the forensic work has added and where containment stands.
- Carrier and lender close-out, days 7-14. Give each contact a written summary of what happened, what data was affected, and what controls changed.
- Control remediation, days 10-21. Implement the controls named in the forensic report, with a deployment ticket and configuration export for each, then update the risk register.
- FSRA closure, days 21-30. File the closure report with remediation evidence and the updated register entry.
- Tabletop reset, day 30. Re-run the exercise using the real incident as the scenario and update the runbook with the gaps it exposed.
FIELD NOTE FROM MIKE.
An 18-agent Mississauga insurance brokerage called me in Q1 2026 over an Applied Epic credential reset that would not take. Inside two hours I had three former-agent accounts still live 6 to 14 months after termination, two without MFA. Nothing had been touched, and the principal broker still made the right call: material, file it, run the access review.
ORIGINAL DATA, FUSION COMPUTING BENCHMARK.
Across our 2025 and 2026 financial-services incident engagements we measured the timings quoted here. A 15-minute internal cadence. A 90-minute remediation on the Mississauga access-review case. Carrier and FSRA closures at 14 and 21 days. Outcomes vary with incident class and broker-of-record decisions.
Further reading and primary sources
- FSRA IT Risk Management Guidance (GR0016INT).
- FSRA mortgage brokering regulatory framework.
- OSFI Technology and Cyber Risk Management guideline.
- PIPEDA, Justice Canada consolidation.
- CCCS, Developing Your Incident Response Plan.
HOW THIS SOP WAS ASSEMBLED.
This draws on anonymized client data from Fusion Computing’s 2025 and 2026 Ontario brokerage incident engagements, an FC internal benchmark of notification and closure timings, and first-person field observation from my own practice since 2012.
Frequently asked questions
When does the FSRA notification clock actually start?
At the materiality determination. Practice 7 of GR0016INT asks for notification as soon as is reasonable, normally within 72 hours or sooner, after the entity determines that an IT risk incident is material. Detection does not start it, which is why the written determination memo matters more than any other artifact in the pack.
Who at the brokerage signs the FSRA IT Risk Incident Notification Form?
The principal broker on the mortgage side, or the principal broker and broker-of-record on the insurance side. A managed-service provider can prepare the draft, but 1 licensed accountable individual signs, so a provider-signed Ontario filing is incomplete on its face.
What if we are not sure yet whether the incident is material?
Reach the determination anyway and write down what you knew. Filing early with a stated scope and an open assessment is stronger than an unrecorded delay, because the memo shows a supervisor exactly when your 72 hours began and on what facts.
Does filing with FSRA satisfy our other notification obligations?
No. PIPEDA section 10.1 bites where there is a real risk of significant harm. Quebec Law 25 reaches you if a Quebec resident is affected. FINTRAC covers mortgage brokers, lenders, administrators and life insurance brokers. Lender contracts, carrier contracts and the cyber insurer clause each run on their own clocks.
Where does an Ontario mortgage brokerage send the notification?
FSRA guidance MB0048INF names the channel: the IT risk inbox at [email protected], alongside the Incident Notification Portal. Put both in the runbook with the principal broker’s login, because hunting for the address during an incident is exactly how a 72-hour window turns into a 4-day one.
How does the MBRCC framework relate to the FSRA notification form?
The MBRCC Principles for Cybersecurity Preparedness set four outcome-based principles, and Principle 3 covers incident monitoring, detection and response. The FSRA form is the Ontario channel for filing under that principle. Mortgage brokerages outside Ontario follow the same four principles and file with their own provincial regulator.
Does the form apply to insurance brokerages even though RIBO supervises licensees?
Yes. FSRA regulates the insurance brokerage sector in Ontario, and RIBO is the licensee-facing channel for activities under its delegated mandate. The IT Risk Incident Notification Form sits on the FSRA side of the umbrella, while RIBO Code of Conduct matters run in parallel through the RIBO complaints process.
How often should we rehearse the 15-minute SOP?
At least annually and end to end, with the principal broker, the IT lead, the provider on-call, and 1 staff member acting as first responder. The after-action report is the document Ontario examiners ask for. Brokerages that rehearse twice a year hold the strongest examination posture.
FINANCIAL-SERVICES BROKERAGE DEEP DIVES (2026 CLUSTER)
Conclusion
The form is the visible artifact. The expectation underneath it is that an Ontario brokerage can recognize a material incident, record the determination and notify inside 72 hours of it. Brokerages that examine well are the ones whose principal broker can describe this SOP from memory.
Reviewed by Mike Pearlstein, CISSP, CEO of Fusion Computing Limited.
