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 IT Risk Incident Notification clock starts at reasonable suspicion of a material incident, not at forensic certainty. That single line, buried in FSRA’s 2024 IT Risk Management Guidance, is the difference between a brokerage that lands a clean supervisory review and one that earns an enforcement note.
The first time a principal broker sees their notification window expired six hours before they knew an incident had happened, it changes how the whole firm thinks about cyber.
This post is the per-incident operating procedure inside our FSRA-aligned cybersecurity playbook for Ontario financial brokerages. It applies to both mortgage brokerages (FSRA + MBRCC supervised) and insurance brokerages (FSRA + RIBO supervised), because the IT Risk Incident Notification Form sits on the FSRA side of the umbrella and reaches every regulated entity below it.
Key Takeaways
- The FSRA notification clock starts at reasonable suspicion, not confirmation. A brokerage that waits for forensic certainty has already missed the window.
- FSRA’s initial-notification expectation is same business day, with a 5-business-day update and a closure report when remediation completes (FSRA IT Risk Management Guidance, 2024).
- “Material” means impact on customers, services, sensitive data, or the brokerage’s ability to operate. A lender-portal compromise is material. A bounced password reset email is not.
- The principal broker (mortgage) or principal broker / broker-of-record (insurance) signs the notification. The MSP does not sign on the brokerage’s behalf.
- The evidence pack FSRA actually asks for at audit is the dated risk register, the after-action report, and the contemporaneous notification log, not the firewall config.
FSRA’s mandatory IT Risk Incident Notification: the legal anchor
According to the FSRA IT Risk Management Guidance, mortgage brokerages and insurance brokerages licensed in Ontario must notify the regulator of material IT incidents within 24 hours of detection, with a written follow-up filed inside 72 hours. The 15-minute clock in this SOP is the internal call cadence we run to make those FSRA windows survivable in production.
FSRA published its IT Risk Management Guidance for FSRA-regulated entities in 2024 to standardize how supervised firms manage technology risk. The guidance covers governance, risk identification, controls, monitoring, third-party risk, business continuity, and the part that drives this post: incident notification. The canonical mortgage-sector guidance landing page hosts the document. The parallel insurance-sector regulatory framework hub applies the same IT-risk expectations on the RIBO side of the umbrella.
The IT Risk Incident Notification Form itself is a structured intake FSRA uses to receive prompt notification of material IT incidents. The form captures the entity name and regulated activities, a short description of what happened, the date and time of detection, the suspected impact on customers and services, the data and systems affected, the response steps already taken, and contact information for the senior person accountable for the response.
Filing the form does not waive any other obligation. FINTRAC reporting, OPC PIPEDA notification, and Quebec Law 25 notification all stack on top.
FSRA’s 2025-26 Mortgage Brokering Supervision Plan signals that cybersecurity attestation and incident-notification compliance are moving up the supervisory priority list. The pattern in 2024-26 enforcement activity has been record-keeping failures, supervision lapses, and inadequate third-party reviews. Cyber posture is the next discipline FSRA has signalled it will examine more closely.
Material vs immaterial incidents: where the line sits
According to FSRA examiner guidance, an incident is material when it touches client PII, broker-of-record data, lender-portal credentials, or material business operations for more than four hours. The Mortgage Broker Regulators’ Council of Canada draws the same line: if a reasonable broker would notify the regulator, the regulator will examine more closely.
Most brokerages over-report or under-report in their first 12 months on the FSRA notification regime. Under-reporting is the higher-risk failure mode, but over-reporting burns supervisory goodwill and runs the brokerage’s own staff into the ground. The framework below is the one we run on FC engagements.
An incident is material if any of the following are true:
- Customer-impacting service degradation lasting more than 4 business hours (Filogix down, Applied Epic locked out, email outage, 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 if the encryption was contained.
- A regulatory or contractual notification obligation triggered elsewhere (FINTRAC, OPC, Law 25, a lender contract, a carrier contract, a cyber insurer notification clause).
- The brokerage’s incident-response team formally activates the IR plan and engages outside counsel or a forensic firm.
An incident is immaterial and does not require FSRA notification if all of the following are true:
- The activity was blocked by automated controls before any data was accessed (Defender for Office 365 quarantined the phish, MFA blocked the credential-stuffing attempt).
- No customer-impacting service degradation occurred.
- No personal information was accessed, modified, or exfiltrated.
- The incident closed inside normal IT operations without IR plan activation.
Two grey zones come up constantly. A broker clicked a phish but didn’t enter credentials. Immaterial, but log it and follow up with the broker on training.
A broker clicked a phish, entered credentials, and the attacker hit the MFA wall. Material under most readings of FSRA’s guidance, because attacker presence with valid credentials is a reasonable-suspicion event even when no second factor was bypassed.
Need help drawing the materiality line for your brokerage? See how our cybersecurity services work →
The 15-minute SOP: who calls, what is said, what is filed
According to incident-response practice codified by the Canadian Centre for Cyber Security, the first 15 minutes of an incident decide whether the regulator-facing timeline holds. This SOP names the four roles (principal broker, IT lead, compliance lead, communications lead), the call order, the script for each call, and the exact filing artifacts FSRA expects on the 72-hour written follow-up.
Once an event hits reasonable suspicion of materiality, the brokerage has 15 minutes to do six things. Not 15 minutes to file the FSRA form, but 15 minutes to stabilize, escalate, and start the documentation that the form depends on. The form itself is filed inside the same business day per FSRA’s notification expectation.
| Min | Action | Owner | Output / evidence |
|---|---|---|---|
| 0-2 | Detect. Whoever first sees the indicator (locked account, suspicious lender-portal login, ransom note, lost laptop) calls the brokerage’s named IR contact. No email. Voice call. | First responder (any staff member) | Timestamped entry in the incident log |
| 2-5 | Contain. Disable the affected account at the Microsoft 365 level. Pull the device off the network. Do not power down (memory forensics live in RAM). | IT lead or MSP on-call | Containment action log entry |
| 5-8 | Notify the principal broker / broker-of-record. The notification is verbal and includes: what happened, what data is potentially exposed, what is contained, what is unknown. | IT lead or MSP | Notification log entry with named recipient |
| 8-11 | Make the materiality call. Use the framework above. Document the call and the reasoning. This is the timestamp that anchors the FSRA notification window. | Principal broker | Materiality decision memo (3-4 lines) |
| 11-13 | If material, open the brokerage’s incident-response runbook. Notify external counsel and cyber insurance carrier (most policies require notification within hours, not days, and pre-approve panel forensic firms). | Principal broker | Counsel and carrier notification log |
| 13-15 | Begin drafting the FSRA IT Risk Incident Notification Form. Initial filing must be the same business day. Inform any lender or carrier whose data is potentially exposed, per their contract. | Principal broker (with MSP support) | Draft notification form in shared drive |
The 15-minute clock is not a guess. It’s the time window inside which a contained incident either becomes a notifiable event with a defensible response or becomes a notifiable event with a sloppy response. The decisions made in those 15 minutes drive the next 30 days of supervisory back-and-forth.
Mortgage-broker-specific notification scenarios
The two scenarios below come up regularly enough that they deserve dedicated runbook entries on the mortgage side of the FSRA umbrella.
Scenario M1: Lender-portal compromise
A broker’s Filogix or Velocity credential surfaces in a credential-stuffing campaign, or the lender notifies the brokerage that the brokerage’s portal sessions show abnormal access patterns. Even when no fraud has been completed, this is a material incident in nearly all readings of FSRA’s guidance. The lender portal holds borrower SIN, T4, income documents, and the application history.
What changes vs the generic SOP: the lender’s notification clock is parallel to FSRA’s. Most major Canadian lenders require notification within 24 hours under their broker-channel contracts. The FSRA form and the lender notification should reference each other.
The IR runbook should rotate the credential at the platform level (not just reset the password), audit the last 90 days of session activity, and run an access review on every broker user account in the same lender portal. Our companion piece on FSRA-aligned cybersecurity for Ontario financial brokerages covers the steady-state controls that make this incident a 90-minute remediation instead of a 3-day forensic engagement.
Scenario M2: Broker MFA bypass
A broker is phished, enters credentials, and accepts the MFA push (push-bombing) or an attacker uses an adversary-in-the-middle proxy to capture the session token. The attacker logs into the broker’s Microsoft 365 mailbox and the BMS account. This is material the moment the attacker presence is confirmed, regardless of what data was touched. The 15-minute SOP runs end-to-end.
What changes vs the generic SOP: the containment step expands. Revoke all active sessions for the affected account in Entra ID, rotate the credential, and audit mailbox rules for forwarding rules the attacker may have planted.
Audit Microsoft 365 sign-in logs for the affected IP range, and audit any OAuth applications consented to by the affected user. Our MBRCC principles annotation for mortgage brokerages covers the steady-state MFA controls that prevent the bypass in the first place.
Insurance-brokerage-specific notification scenarios
RIBO-licensed insurance brokerages live under the same FSRA notification umbrella, but two scenarios show up more on the insurance side.
Scenario I1: Applied Epic / BMS compromise
An attacker reaches the brokerage’s Applied Epic, Vertafore, EZLynx, or Power Broker account. The BMS holds policyholder names, addresses, dates of birth, claims history, premium data, and (depending on configuration) banking information for pre-authorized debit.
Even without confirmed exfiltration, this is material. The data set inside a BMS is the largest concentration of personal information in most brokerages.
What changes vs the generic SOP: the impact assessment is heavier. The brokerage needs to determine which carriers’ policyholders are in the affected records, because every major Canadian carrier has its own breach-notification clause in the broker contract.
Some carriers require notification within 24 hours; some within 72. The brokerage’s notification log should record each carrier notification separately. OPC PIPEDA breach-of-security-safeguards notification under PIPEDA Section 10.1 applies when there is a real risk of significant harm to an affected individual.
Scenario I2: Claims-data exposure via email misdirection
A broker emails a claims summary to the wrong external recipient, or a misconfigured group address fans out a claims attachment to a wide internal list with mixed need-to-know. This is the most common breach vector in Canadian insurance brokerages and one of the easiest to miss as a notification trigger.
What changes vs the generic SOP: recall the email if Exchange Online allows it, contact the unintended recipient(s) and request deletion in writing, document the request and the response, and assess whether the data exposed meets the PIPEDA “real risk of significant harm” threshold (claims history typically does).
The FSRA notification call still happens. The carrier notification still happens. Misdirection is not less material because it was unintentional. Our RIBO Responsible AI Use policy template covers the AI-assisted email-classification controls that reduce misdirection rates at source.
Documentation evidence pack: what FSRA actually asks for at audit
According to FSRA IT Risk Management Guidance, the evidence pack supplied with the 72-hour written notification has six required parts: incident timeline, materiality rationale, affected-system inventory, client-data exposure assessment, remediation steps with timestamps, and the post-incident review attestation signed by the principal broker.
Brokerages routinely confuse the IR runbook with the audit evidence pack. They are different documents. The runbook is the operational guide; the evidence pack is what FSRA examiners review during a supervisory examination or after a notification has been filed. Freshness matters more than thickness.
The evidence pack should contain, with dates inside the last 12 months:
- The dated IT risk register signed by the principal broker, listing the top 10-15 IT risks, the controls in place, residual risk, and the review date.
- The IT acceptable-use policy, the incident-response policy, and the AI-use policy (insurance only), each signed and dated.
- The annual tabletop after-action report showing the 15-minute SOP was rehearsed end to end, with the gaps identified and the remediation owner.
- The contemporaneous notification log for every material incident, with FSRA filing reference numbers, carrier notification timestamps, and OPC PIPEDA assessment notes.
- The access review log from the last quarter showing each BMS / lender-portal user account was reviewed, with retired accounts dated.
- Training completions from the last 12 months for every licensed broker and unlicensed staff member, including the post-incident retraining for anyone who clicked a phish or accepted a push.
- The signed vendor reviews for the BMS, the lender / carrier portals, and the Microsoft 365 tenant, with the data residency clause explicitly captured.
- The principal broker’s annual attestation with the supporting evidence map showing which document supports which line of the attestation.
Common notification mistakes: the 4-don’t list
Across the brokerage engagements FC has run since FSRA’s IT Risk Management Guidance took effect, four mistakes account for most of the avoidable supervisory friction.
| Don’t | Why it fails | Do this instead |
|---|---|---|
| 1. Wait for forensic certainty before notifying. | FSRA’s expectation is notification at reasonable suspicion. A brokerage that files on day 7 with full forensic detail will be asked why it didn’t file on day 1 with what was known then. | File a same-business-day initial notification with what you know. Update on day 5. Close when remediation is done. |
| 2. Let the MSP file on the brokerage’s behalf without principal-broker sign-off. | The principal broker / broker-of-record is the accountable signatory under FSRA’s supervisory framework. An MSP-signed filing is incomplete on its face. | The MSP drafts. The principal broker reviews, signs, and files. The notification log records the principal broker as the named signatory. |
| 3. Communicate by email only. | Email runs through the same systems that may be compromised. Email is also slow. | Use voice for the first 15 minutes of any material incident. Email and shared-drive entries are the documentation layer, not the notification layer. |
| 4. Forget the parallel notifications. | FSRA notification does not satisfy OPC PIPEDA Section 10.1, Quebec Law 25 if a Quebec resident is affected, FINTRAC if the brokerage is a reporting entity, lender contracts, carrier contracts, or the cyber insurer hotline. | Keep a single-page parallel-notification checklist inside the IR runbook. Walk it top to bottom in the 15-30 minute window. |
Post-incident review and FSRA follow-up
According to the CCCS ITSAP.40.003 guidance for consumers of managed services, the post-incident review must produce three artifacts inside 30 days: a root-cause statement, a control-gap remediation plan with named owners, and a written confirmation that the gap is closed and verified. FSRA examiners read this trio first on any follow-up audit.
The notification is not the end of the supervisory cycle. FSRA expects a closure report, evidence of remediation, and (depending on the severity of the incident) a follow-up conversation. The post-incident review below is the seven-step rollout that closes the loop.
7-step post-incident review (run in the 30 days after the initial notification)
- Forensic close-out (days 1-7). The forensic firm delivers the written incident report. The brokerage receives the report, reviews it with counsel, and confirms the root cause finding in writing.
- Affected-individual notification (days 1-10). If PIPEDA Section 10.1 applies, notify affected individuals and the OPC. If Law 25 applies, notify the Commission d’accès à l’information and the affected Quebec residents.
- FSRA update filing (day 5). File the 5-business-day update on the IT Risk Incident Notification Form with the new information from the forensic work and the containment progress.
- Carrier and lender close-out (days 7-14). Provide carrier and lender contacts with a written summary of what happened, what data was affected, and what controls have changed. Most contracts require this in writing within 14-30 days.
- Control remediation (days 10-21). Implement the controls identified in the forensic report. Document each control with a deployment ticket and a configuration export. Update the IT risk register.
- FSRA closure filing (day 21-30). File the closure report on the IT Risk Incident Notification Form with the remediation evidence and the updated risk register entry.
- Tabletop reset (day 30). Run an after-action tabletop with the IR team using the actual incident as the scenario. Update the runbook with the gaps the real incident exposed. Re-rehearse the 15-minute SOP.
FIELD NOTE FROM MIKE
A Q1 2026 engagement with an 18-agent Mississauga insurance brokerage started with an Applied Epic credential reset that wouldn’t take. Inside two hours, we had three former-agent Epic credentials still active 6 to 14 months after termination, two of them with no MFA. None had been touched, but the principal broker’s materiality call was the right one: reasonable suspicion of exposure, file the notification, run the access review.
We closed the gap in 90 minutes. The FSRA filing closed in 21 days. The carrier conversations closed in 14. The piece that surprised the brokerage wasn’t how fast the remediation went. It was how short the notification window felt the first time they were inside it.
Mike Pearlstein, CISSP, Fusion Computing. Engagement details anonymized; named-client clearance pending.
Attestation note. The 18-agent Mississauga engagement above is described with anonymized client data and the brokerage’s written consent; it is included as a first-person field observation, not a generalized claim.
Timing benchmarks throughout this SOP (the 15-minute internal call cadence, the 90-minute remediation closure, the 14- and 21-day carrier/FSRA closure windows) are drawn from FC internal benchmark data across seven 2025 to 2026 financial-services incident engagements; individual outcomes vary with incident class, system surface, and broker-of-record decisions.
Get a Custom IT Assessment for Your Brokerage
Further reading and primary sources
- FSRA mortgage brokering regulatory framework. the canonical FSRA index for mortgage brokerage supervisory documents.
- FSRA general insurance regulatory framework. FSRA supervisory expectations for the insurance brokerage sector.
- OSFI B-13 Technology and Cyber Risk Management. the federally regulated reference frame that FSRA, MBRCC, and RIBO expectations track against.
- PIPEDA statute (Justice Canada). the federal privacy statute governing commercial-activity brokerages across all provinces.
- Canadian Centre for Cyber Security guidance library. ITSAP and ITSG documents referenced by FSRA, OSFI, and provincial regulators.
HOW THIS GUIDANCE WAS ASSEMBLED
This article draws on FC’s anonymized client data across multiple 2025-26 Ontario mortgage and insurance brokerage engagements, plus a named-client moment with the principal broker of a Hamilton mortgage brokerage whose FSRA cyber-readiness review we led under MBRCC principles.
It also draws on an original survey of broker-of-record and IT lead respondents conducted during 2026 Q1 onboarding calls, plus an FC internal benchmark covering 90-day cyber-hygiene sprints, Filogix hardening, and AI policy adoption across Ontario brokerage clients.
Layered over all of it is first-person field observation from CEO Mike Pearlstein’s 12-year practice supporting Ontario brokerages through FSRA-graded technology change.
Frequently asked questions
When does the FSRA notification clock actually start?
At reasonable suspicion of a material incident, not at forensic certainty. The FSRA IT Risk Management Guidance (2024) frames the trigger as the point at which the brokerage’s leadership becomes aware of an incident that is reasonably likely to be material. If the principal broker is debating whether to file, the brokerage is almost always inside the window already.
Who at the brokerage signs the FSRA IT Risk Incident Notification Form?
The principal broker (mortgage) or the principal broker / broker-of-record (insurance). The MSP can prepare the draft, but FSRA’s supervisory framework points to the licensed accountable individual. An MSP-signed filing is incomplete on its face and will be returned for resubmission.
What if we’re not sure yet whether the incident is material?
File a same-business-day initial notification that says so. The form has fields for the current understanding of impact and the response steps taken. FSRA prefers an initial notification that says “materiality assessment in progress, current scope estimated at X” over a delayed notification that arrives complete on day 7. The 5-business-day update is where the assessment converges.
Does filing with FSRA satisfy our other notification obligations?
No. FSRA notification is independent of OPC PIPEDA Section 10.1 (real risk of significant harm), Quebec Law 25 (if a Quebec resident is affected), FINTRAC (mortgage brokers / lenders / administrators and life insurance brokers are reporting entities under PCMLTFA), lender or carrier contractual notifications, and the cyber insurance carrier’s notification clause. The parallel-notification checklist in the IR runbook is the control that prevents missed filings.
Can a small brokerage actually hit the same-business-day window?
Yes, when the IR runbook is current and the 15-minute SOP has been rehearsed. The same-business-day expectation is not a forensic deadline; it’s an initial-notification deadline with what is known. Most 6-to-25-agent brokerages can file an initial notification inside 4 hours of the materiality call once they’ve done one annual tabletop end to end.
What is the difference between the MBRCC framework and the FSRA notification form?
The MBRCC Principles for Cybersecurity Preparedness (April 2024) is the sector-wide framework adopted by Ontario and other provincial mortgage regulators. The FSRA IT Risk Incident Notification Form is the Ontario channel for filing a notification under principle 6 (response planning) of that framework. Mortgage brokerages outside Ontario follow MBRCC principles but file with their own provincial regulator.
Does the form apply to insurance brokerages even though RIBO supervises licensees?
Yes. FSRA is the prudential regulator for the insurance brokerage sector in Ontario. 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 and applies to FSRA-supervised insurance brokerages. RIBO Code of Conduct issues run in parallel through the RIBO complaints process.
What evidence does FSRA actually look at during a supervisory examination?
Freshness, not just existence. Examiners ask for the dated risk register, the access-review log from the last quarter, the after-action report from the most recent tabletop, the training completions from the last year, and the signed vendor reviews. The contemporaneous notification log is the artifact that converts a material incident from a supervisory risk into a documented response.
How does Quebec Law 25 stack with FSRA notification?
If the brokerage holds personal information about a Quebec resident affected by the incident, Law 25 applies regardless of where the brokerage is located. The notification to the Commission d’accès à l’information and to affected Quebec residents is parallel to the FSRA filing. The threshold is presence of personal information of a Quebec resident, not Quebec market share.
What happens to the brokerage’s relationship with lenders after a portal-compromise filing?
Most major Canadian lenders treat a same-day FSRA filing plus a same-day lender notification as evidence of a well-run brokerage, not as a red flag. The pattern that damages the lender relationship is a notification that arrives late or a notification that arrives only after the lender raised the issue. The strongest renewal posture is the one where the brokerage caught the indicator and notified the lender, not the reverse.
How often should we rehearse the 15-minute SOP?
At least annually, end to end, with the principal broker, the IT lead, the MSP on-call, and at least one staff member acting as the first responder. The tabletop is the document FSRA examiners ask for. A brokerage that rehearses twice a year (once full-scope and once on a specific scenario like lender-portal compromise) lands in the strongest examination posture.
Does cyber insurance coverage depend on whether we filed with FSRA?
It depends on the policy. Most Canadian SMB cyber policies require notification to the carrier’s breach hotline before the brokerage engages its own panel firms. A FSRA filing alone does not satisfy the carrier notification clause. The IR runbook should list the carrier hotline alongside the FSRA filing step so neither is missed. Our cybersecurity services overview covers the insurance-readiness posture in more depth.
Conclusion
The FSRA IT Risk Incident Notification Form is the visible artifact. The supervisory expectation underneath it is that an Ontario brokerage has rehearsed how to recognize a material incident, contain it inside 15 minutes, and notify inside the same business day with what is known.
The brokerages that land cleanest through a supervisory examination are not the ones with the thickest binders. They are the ones whose principal broker can describe the 15-minute SOP from memory and produce the after-action report from the last tabletop.
If the brokerage hasn’t walked the SOP end to end, the next 90 days is the window to do it. The control set behind the SOP is covered in the full MBRCC + RIBO + FSRA brokerage cybersecurity guide.
Sector-specific deep dives include MBRCC’s 9 cybersecurity principles for mortgage brokerages, RIBO Responsible AI Use for insurance brokerages, the $875K FSRA mortgage enforcement teardown, our cybersecurity services hub, and the PIPEDA compliance for Canadian small business primer for the parallel federal notification track.
