Source boundary: Statements attributed to OSFI summarize Guideline B-13 and related official material. The diagrams, review questions, seven-step flow and 90-day application are ByteDefender practical interpretation—not an OSFI assessment method or statement of compliance.
Technology and cyber risk can become fragmented inside an organization. A security team tracks vulnerabilities and alerts. Technology teams manage assets, changes and recovery. Risk functions monitor appetite and exceptions. Senior leaders receive summaries from each area, but may still lack a clear answer to the most important question:
Can the organization keep its critical services within risk tolerance when technology fails, changes or comes under attack?
OSFI Guideline B-13, Technology and Cyber Risk Management, addresses that management problem for federally regulated financial institutions (FRFIs). The guideline applies to the institutions and branches within its stated scope and is intended to support greater resilience to technology and cyber risk. It also rejects a one-size-fits-all implementation: the institution’s size, operating model, complexity and risk profile matter. [1]
B-13 was published in 2022 and took effect on January 1, 2024. OSFI later issued consequential amendments clarifying how B-13 applies to foreign branches. In November 2025, OSFI released a voluntary technology and cyber risk management self-assessment tool aligned with B-13 and described B-13 as the primary guideline for this risk area. [2] [3] [4]
This article explains what B-13 says, then adds a separate ByteDefender interpretation for leadership and operating teams. The interpretation is educational; it is not an OSFI assessment method, legal opinion or statement of compliance.
The article in one minute
- Governance and risk management establish accountability, strategy, risk appetite, oversight and reporting.
- Technology operations and resilience manage architecture, assets, change, incidents, service performance and recovery.
- Cyber security identifies, defends against, detects, responds to, recovers from and learns from cyber threats and incidents.
- The three domains become useful when they meet around a critical service, an accountable owner, defined tolerance and evidence that supports a decision.
What B-13 is designed to accomplish
B-13 defines technology risk broadly. It includes risk arising from inadequacy, disruption, destruction, failure, unauthorized access, modification or malicious use involving technology assets, people or processes that support business needs. The consequences may include financial loss and reputational damage. [1]
OSFI organizes the guideline into three domains and gives each a desired outcome:
- Technology and cyber risks are governed through clear accountability, structure, strategy and a comprehensive framework.
- The technology environment is stable, scalable and resilient, supported by sustainable operating and recovery processes.
- The institution maintains a secure technology posture that protects the confidentiality, integrity and availability of technology assets. [1]
The domains are distinct, but they are not independent. Governance sets direction and tolerance. Operations create and sustain the technology service. Cyber security manages the threat-facing control cycle. Evidence from all three informs management decisions.
Domain 1: Governance converts exposure into an owned decision
What OSFI says
Senior management should assign responsibility for technology and cyber risk to senior officers, support an appropriate organizational structure, and provide adequate people, financial resources, expertise and training. Senior management should also include people with sufficient understanding of technology and cyber risk, while the institution promotes a culture of risk awareness. [5]
B-13 expects strategic technology and cyber plans to align with business strategy. Those plans should be approved, measurable and capable of evolving as the internal and external environment changes. The guideline also expects a technology and cyber risk management framework aligned with enterprise risk management. The framework should address risk appetite, measurement, taxonomy, control domains, policies, exceptions, emerging risks, monitoring and reporting. [5]
ByteDefender practical interpretation
Governance is not complete because a committee exists or a policy was approved. It becomes operational when the institution can show:
- a named accountable role for a material exposure;
- a decision forum with authority to act or accept risk;
- a defined tolerance, threshold or recovery expectation;
- an escalation route when the exposure exceeds that tolerance;
- evidence that the decision was implemented and reviewed.
A useful management statement is not merely “this is a cyber issue.” It is:
This exposure affects a named service, exceeds—or may exceed—a defined tolerance, has an accountable owner, and requires a decision supported by specific evidence.
That statement connects technical facts to governance without asking senior leaders to become security analysts.
Domain 2: Technology operations make resilience observable
The second domain covers the operating system behind resilience: architecture, asset management, technology projects, the system development life cycle, change and release management, patching, incident and problem management, service measurement and disaster recovery. [1]
Architecture, assets and dependencies
B-13 expects technology architecture to support business, technology and security goals. It also expects an updated inventory of technology assets supporting business processes or functions. Assets should be categorized by factors such as criticality or classification, and important interdependencies should be documented where appropriate. The asset-management process should cover configuration integrity, secure disposal and technology currency. [6]
This is where a technology record becomes a resilience record. An application name alone is not enough. The institution needs to understand the service it supports, the data it handles, the identity and network paths it depends on, its third parties, and the recovery capabilities required when any of those components fail.
Development, change and patching
B-13 expects security requirements to be embedded through the system development life cycle. Acquired systems should also be assessed for risk. Production changes should be documented, assessed, tested, approved, implemented and verified; segregation of duties and change traceability are part of that control environment. Patching should be timely and controlled, with clear responsibilities and testing before production deployment. [7]
That creates a real management trade-off. Delayed remediation may preserve exposure. An uncontrolled change may create an outage. The organization needs a treatment decision that considers both cyber exposure and service continuity—and records why the chosen approach is proportionate.
Incidents, problems and recovery
B-13 expects incident and problem processes that support identification, escalation, restoration, recovery and root-cause resolution. It points to impact-based incident prioritization, communication triggers, plausible-scenario exercises, third-party testing and post-incident learning. [8]
For disaster recovery, the guideline expects an enterprise programme aligned with business continuity management. It should define accountability, identify technology services and key dependencies, establish recovery capabilities, and address backup, storage and testing. Severe-but-plausible scenarios should test recovery strategies, backup processes and critical third-party integrations. [9]
A recovery plan describes intended behaviour. A test supplies evidence about whether people, technology, dependencies and procedures can work through disruption.
A practical service review
Choose one important service and identify its accountable owner, technology assets, data, upstream and downstream dependencies, third parties, recovery objective, fallback method and last verified recovery evidence. Gaps in that map are risk information—not merely documentation defects.
Domain 3: Cyber security operates as a continuous cycle
B-13’s cyber-security domain is organized around identifying, defending, detecting, responding, recovering and learning. [10]
Identify
Institutions should assess current and emerging threats, conduct risk-based testing, identify and rank vulnerabilities, classify data, maintain situational awareness, support information sharing, conduct threat modelling and hunting where feasible, test awareness and reporting, and maintain a current cyber-risk profile. [10]
The vulnerability section is particularly important for decision-makers. B-13 expects vulnerabilities to be assessed and ranked using threat severity and the risk exposure of affected technology assets. It also notes that multiple vulnerabilities may create a high-risk exposure when combined, regardless of their individual ratings. [10]
Defend
The defensive expectations include secure-by-design practices, cryptography, enhanced controls for critical and external-facing assets, layered security, network segregation, data protection, vulnerability remediation, identity and access management, configuration baselines, application testing and physical security. [11]
Controls are not static inventory items. Their continued effectiveness depends on configuration, monitoring, ownership, maintenance and the service context in which they operate.
Detect
B-13 expects continuous detection capabilities and centralized security logging that support timely investigation. It warns against forensic work being delayed by disaggregated, inaccessible or missing critical logs. The guideline also expects malicious or unauthorized activity to be detected and high-risk alerts to be triaged through defined roles and responsibilities. [12]
This is a useful distinction: logging is not the same as detection, and detection is not the same as a response decision. The operating chain needs usable events, defined triage, an accountable responder and a path to containment.
Respond, recover and learn
Cyber response should align with technology incident management, crisis management and communications. Institutions should maintain an incident taxonomy, playbooks and continuous response capability. Where warranted, forensic investigation and root-cause analysis should identify remediation actions and lessons across people, process, technology and data. [13]
From a technology signal to a management decision
A scanner finding, service outage, audit observation, exception request or threat-intelligence report is not yet a complete risk decision. It is an input.
ByteDefender’s practical flow is:
- Receive the signal or change. Record the source, timing and uncertainty.
- Validate applicability. Confirm the affected asset, configuration and evidence.
- Connect the business context. Identify the service, data, customers, obligations and dependencies involved.
- Compare with tolerance. Consider exposure, impact, recovery needs, limits, thresholds and exceptions.
- Own the action. Choose a treatment, accountable owner, deadline, fallback and escalation path.
- Verify and report. Test the result, record residual risk and communicate to the right forum.
- Learn. Update scenarios, controls, standards, indicators and strategy.
This is a ByteDefender application model based on the relationships within B-13. OSFI does not prescribe this exact seven-step sequence.
What evidence should reach decision-makers?
Senior management does not need every technical detail. It does need enough evidence to understand the service, exposure, decision and follow-through.
| Decision question | Useful evidence | Warning sign |
|---|---|---|
| Who owns the risk? | Named accountable role, decision forum and escalation path | The ticket has an assignee, but no accountable decision-maker |
| What service is affected? | Service map, assets, data and material dependencies | The finding is ranked without confirming business context |
| What tolerance applies? | Limits, thresholds, recovery objectives or exception criteria | “High” or “critical” is used without an institutional threshold |
| What treatment was chosen? | Remedy, compensating control, deadline, change plan and fallback | Action is delayed without an owner, rationale or review date |
| How was it verified? | Test result, recovery evidence, monitoring outcome and residual risk | Closure is based only on a completed task or elapsed date |
| What changed afterward? | Updated control, scenario, standard, metric or strategy | Post-incident lessons are recorded but not assigned |
Using the 2025 OSFI self-assessment tool responsibly
OSFI’s 2025 technology and cyber risk management self-assessment tool is voluntary. OSFI says it is aligned with B-13 and may help institutions assess maturity, gauge preparedness, identify gaps and strengthen risk-management practices. OSFI also states that B-13 remains the primary guideline. [4]
A maturity score can support discussion, but it should not replace evidence. Two processes with the same rating may create very different exposure depending on the service, dependency, threat environment and operating context.
A stronger use of the tool is to pair a maturity observation with:
- the service or risk outcome it affects;
- the evidence supporting the rating;
- the owner of the improvement;
- the target state and due date;
- the trigger for escalation or reassessment.
A 90-day leadership application
The following sequence is ByteDefender’s suggested application, not an OSFI implementation timetable.
Days 1–30: choose and map one critical service
Confirm the owner, customers or stakeholders, data, assets, third parties, operating dependencies, recovery objective and material technology/cyber risks.
Days 31–60: test one decision path
Select one plausible disruption or cyber scenario. Walk a signal from detection through escalation, treatment, change, communication, recovery and management reporting. Record points where ownership or evidence becomes unclear.
Days 61–90: close one meaningful gap
Assign the improvement, define the evidence of completion, set a review date and show how the result changes the service’s risk profile or recovery confidence.
This is deliberately narrower than trying to “implement B-13” as one large checklist. It creates an evidence trail around an important service and exposes where the three domains do—or do not—connect.
The practical takeaway
The attached infographic summarizes B-13 as three domains and one stronger foundation. The deeper lesson is that the foundation must support a management system:
- governance establishes accountability, strategy and tolerance;
- technology operations sustain services and recovery capability;
- cyber security identifies, reduces, detects and responds to threats;
- evidence and learning keep decisions current.
The most useful leadership question is therefore not:
“Do we have the controls?”
It is:
“Can we demonstrate how ownership, technology operations and cyber security work together to keep one critical service within tolerance—and recover it when those controls are not enough?”
Connect guidance to an evidence-backed review
Explore ByteDefender’s Risk Assessment service to connect business context, risk tolerance and evidence, or Security Advisory for governance, roadmap and readiness support. These services support decision-making; they do not constitute an OSFI determination or guarantee compliance.
Sources and further reading
- Office of the Superintendent of Financial Institutions. Guideline B-13 — Technology and Cyber Risk Management, July 31, 2022. Purpose and scope, definitions, structure and outcomes, pp. 1–4. Attached source reviewed October 9, 2026; current official publication page also reviewed.
- OSFI. OSFI releases final Guideline B-13 — Technology and Cyber Risk Management, July 13, 2022. Effective date: January 1, 2024.
- OSFI. Consequential amendments to Guidelines B-10 and B-13 related to foreign branches, February 22, 2024.
- OSFI. Technology and cyber risk management self-assessment tool, November 3, 2025. Voluntary tool aligned with B-13; B-13 remains the primary guideline.
- OSFI Guideline B-13. Sections 1.1–1.3, governance, strategy and risk-management framework, pp. 5–7.
- OSFI Guideline B-13. Sections 2.1–2.2, architecture and technology asset management, pp. 7–9.
- OSFI Guideline B-13. Sections 2.4–2.6, SDLC, change and release management, and patch management, pp. 10–12.
- OSFI Guideline B-13. Section 2.7, incident and problem management, pp. 12–13.
- OSFI Guideline B-13. Section 2.9, disaster recovery and scenario testing, pp. 14–15.
- OSFI Guideline B-13. Section 3.1, identify, pp. 16–18.
- OSFI Guideline B-13. Section 3.2, defend, pp. 18–21.
- OSFI Guideline B-13. Section 3.3, detect, pp. 21–22.
- OSFI Guideline B-13. Section 3.4, respond, recover and learn, pp. 22–23.
This article is educational guidance. It does not constitute legal, regulatory or compliance advice; it is not an OSFI assessment methodology; and it does not establish that any organization meets B-13.