OSFI B-13 Detection and Monitoring: What Section 3.3 Asks For

This guide is a plain reading of one part of one guideline. It quotes the text, marks where we are interpreting rather than quoting, and ends with what it does not cover. It is not legal or compliance advice, and it does not say that any product, ours included, satisfies the guideline.

Source: OSFI Guideline B-13, Technology and Cyber Risk Management and the letter announcing the final guideline. We read both on October 23, 2026.

What is OSFI Guideline B-13 and who does it apply to?

B-13 sets OSFI's expectations for technology and cyber risk management. It is organized into three domains: governance and risk management, technology operations and resilience, and cyber security. Section 3 of the guideline is the third domain, Cyber Security, which is organized into four parts:

The guideline states that it is "applicable to all federally regulated financial institutions (FRFIs), including foreign bank branches and foreign insurance company branches." OSFI also says it "should be read, and implemented, from a risk-based perspective". The letter that released it gave an effective date: "Guideline B-13 will be effective on January 1, 2024, to provide FRFIs sufficient time to self-assess and ensure their compliance with this new guideline."

What does Section 3.3 Detect actually say?

Principle 16 frames the section:

FRFIs design, implement and maintain continuous security detection capabilities to enable monitoring, alerting and forensic investigations.

Three expectations follow. Quoted in full:

3.3.1 Continuous, centralized security logging to support investigations. "FRFIs should ensure continuous security logging for technology assets and different layers of defence tools. Central tools for aggregating, correlating and managing security event logs should enable timely log access during a cyber event investigation."

3.3.2 Malicious and unauthorized activity is detected. "FRFIs should maintain security information and event management capabilities to ensure continuous detection and alerting of malicious and unauthorized user and system activity."

3.3.3 Cyber security alerts are triaged. "FRFIs should define roles and responsibilities to allow for the triage of high-risk cyber security alerts to rapidly contain and mitigate significant cyber threat events."

Within section 3.3, the text does not name a product, a retention period, a staffing model or a service level. Those are choices the institution makes and has to be able to explain.

What capability does each expectation point to?

The first two columns below are from the guideline. The last two are our reading, so treat them as a starting point for your own mapping, not as OSFI requirements.

How does Section 3.3 connect to the rest of Section 3?

Three neighbouring expectations shape how an examiner might read 3.3:

• 3.1.5 Situational awareness. "FRFIs should maintain continuous situational awareness of the external cyber threat landscape and its threat environment."
• 3.1.6 Threat modelling and hunting. "FRFIs should use manual techniques to proactively identify and isolate threats which may not be detected by automated tools." This is where hunting appears, not in 3.3.
• 3.4.5 Forensic investigations and root cause analysis are conducted, as necessary. Principle 16 itself names forensic investigations as something detection should enable.

Reading these together, detection in B-13 is not only an alert feed. It is expected to support investigation afterwards and to be complemented by human-led hunting for what automation misses.

How can you self-assess against Section 3.3?

OSFI publishes its own technology and cyber risk management self-assessment tool; use it as the authoritative checklist. The questions below are ours, derived directly from the three expectations:

1. Can you list every technology asset and defence tool in scope, and the log source for each?
2. How do you find out that a log source has stopped sending?
3. Where are security event logs aggregated, correlated and managed, and who can reach them during an investigation?
4. For your last investigation, how long did it take to get the logs you needed?
5. Which detections run continuously, and what do they cover?
6. What happens when an alert fires: who sees it, and in what time?
7. Which roles triage high-risk alerts, and who covers them outside business hours?
8. Where would an investigator say "we could not see this"? Is that written down?

Where does behavior-level evidence fit?

We build a behavior-level representation of security activity, so we will say where it touches this section and where it does not. 3.3.1 asks that logs be available during an investigation, 3.3.2 asks for detection of malicious activity, and 3.4.5 asks for forensic investigation and root cause analysis. A behavior record, such as the one FACE-EO describes, keeps the detection, its supporting telemetry and the explicit "not observed" state together, so the question "what did you see, and what could you not see" is answered by the record itself. That is a design intent, described on our FACE-EO page. We have not measured whether it reduces the effort of preparing evidence, and B-13 does not ask for a representation of this kind.

What does this guide not cover?

• Anything outside section 3.3, except the three neighbouring expectations quoted above. Domains 1 and 2, and sections 3.2 and 3.4 beyond their headings, are not discussed.
• Legal interpretation, examiner practice, or what OSFI will accept as evidence. The evidence column above is our reading.
• Incident reporting obligations and third-party risk guidance.
• Whether any specific product or service, including ours, meets the guideline. We have made no such assessment.
• Organizations that are not federally regulated. The guideline's stated scope is FRFIs.
• Measured outcomes. We have not published results from using any approach in this guide.