Introduction: OSFI Guideline B-13 (Technology and Cyber Risk Management)
OSFI Guideline B-13, Technology and Cyber Risk Management, sets out the prudential expectations of the Office of the Superintendent of Financial Institutions (OSFI) for how federally regulated financial institutions (FRFIs) in Canada should manage technology and cyber risks. Issued in July 2022 and effective from 1 January 2024, B-13 marks OSFI's move from principles buried in older operational-risk guidance to an explicit, outcomes-based framework covering governance, technology operations, cyber security and the wider technology-and-cyber risk lifecycle. It is deliberately outcomes-focused rather than prescriptive: OSFI states the desired outcome for each domain and expects each FRFI to implement controls proportionate to its size, complexity, risk profile and business model.
This CyberSigma Knowledge Center deep-dive is written for two audiences at once: the auditor or assessor who must evaluate a FRFI's conformance to B-13's expected outcomes, and the implementer, Chief Information Security Officer (CISO), Chief Technology Officer (CTO) or risk lead who must build the control environment and evidence base. It enumerates every domain and expected outcome of the guideline, provides an auditor-grade master assessment checklist mapping 'what to verify' to 'typical evidence', explains scoping and proportionality, lays out a phased implementation approach, and maps B-13 to adjacent frameworks (OSFI B-10, E-21, Technology and Cyber Security Incident reporting, NIST CSF, ISO 27001 and others). Throughout, we use OSFI's own terminology: domains, expected outcomes, third-party arrangements, technology resilience, cyber resilience and the risk-based approach.
Copyright and source note
OSFI Guideline B-13 and related OSFI advisories are Crown-copyright works published by the Office of the Superintendent of Financial Institutions, Government of Canada. This guide is original CyberSigma commentary and interpretation written for educational and readiness purposes. It paraphrases and does not reproduce OSFI's copyrighted text. FRFIs and assessors must always work from the authoritative guideline and any subsequent OSFI advisories, letters and revisions (including alignment with Guideline B-10 on third-party risk and E-21 on operational resilience). Nothing here is legal, regulatory or supervisory advice.
What is OSFI B-13?
OSFI B-13 is a supervisory guideline that articulates OSFI's expectations for sound technology and cyber risk management. It is not a certifiable standard and there is no B-13 'certificate'; instead, it is a lens through which OSFI's supervisory teams assess whether a FRFI is managing technology and cyber risk in a manner that supports its safety, soundness and operational resilience. Failure to meet the expected outcomes can result in heightened supervisory attention, findings, remediation requirements, staging under OSFI's supervisory framework, and in serious cases regulatory intervention.
The guideline is organised around three domains, each with a set of expected outcomes and supporting principles. The three domains are: (1) Governance and Risk Management; (2) Technology Operations and Resilience; and (3) Cyber Security. B-13 replaced the older and narrower 2013 Cyber Security Self-Assessment expectations by embedding cyber security within a broader technology risk framework and connecting it to enterprise governance, third-party risk (Guideline B-10) and operational resilience (Guideline E-21).
- Issuer: Office of the Superintendent of Financial Institutions (OSFI), the prudential regulator of federally regulated banks, insurers, trust and loan companies, and federally regulated private pension plans in Canada.
- Instrument type: Prudential guideline (supervisory expectation), outcomes-based and risk-proportionate rather than prescriptive.
- Published: 13 July 2022. Effective: 1 January 2024.
- Scope: Technology risk, cyber risk, technology resilience, cyber resilience, and the governance and lifecycle wrapped around them.
- Companion instruments: Guideline B-10 (Third-Party Risk Management), Guideline E-21 (Operational Resilience), and OSFI's Technology and Cyber Security Incident Reporting advisory (24-hour notification expectation).
- Enforcement: Supervisory — findings, ratings, remediation, staging; not a fine-based regime, though consequences flow through OSFI's supervisory framework.
Who must comply / scope of applicability
B-13 applies to all federally regulated financial institutions (FRFIs). This is broad: it captures banks (including foreign bank branches operating in Canada), trust and loan companies, and federally regulated insurance companies, as well as bank holding and insurance holding companies. Federally regulated private pension plans are subject to related OSFI expectations but B-13 itself is framed around FRFIs. Provincially regulated institutions (for example, credit unions regulated by a provincial authority) are not directly in scope, though many adopt B-13 as good practice or because provincial regulators reference it.
| Institution / entity type | In scope for B-13? | Notes on applicability |
|---|---|---|
| Domestic banks (Schedule I) | Yes | Full application; proportionate to size and complexity, but D-SIBs held to the highest expectations. |
| Foreign bank branches / subsidiaries (Schedule II/III) | Yes | Applies to Canadian operations; branches may rely on group frameworks but must evidence local applicability and OSFI expectations. |
| Trust and loan companies (federal) | Yes | Full application, proportionate to risk profile. |
| Federally regulated insurers (life, P&C) | Yes | Full application, including reinsurers operating federally. |
| Bank / insurance holding companies | Yes | Group-level governance and oversight expectations apply. |
| Federally regulated private pension plans | Indirect | Governed by related OSFI operational-risk and cyber expectations rather than B-13 directly. |
| Provincially regulated credit unions / caisses | No (directly) | Out of OSFI's jurisdiction; often adopt B-13 voluntarily or under provincial guidance. |
| Fintechs / service providers to FRFIs | Indirect | Not FRFIs, but flow-down expectations reach them through B-13 and B-10 third-party arrangements. |
Proportionality is central. OSFI expects every FRFI to meet the expected outcomes, but the depth, formality and sophistication of controls should be commensurate with the institution's size, ownership structure, nature, scope and complexity of operations, corporate strategy and risk profile. A domestic systemically important bank (D-SIB) will be held to materially more rigorous expectations than a small monoline insurer.
Structure of OSFI B-13
B-13 is structured into three domains, each containing expected outcomes and supporting principles. The guideline states an outcome (the 'what') and leaves the FRFI to determine the controls (the 'how') proportionate to risk. The following table summarises the domains and their principal expected-outcome areas.
| Domain | Principal expected-outcome areas | Purpose |
|---|---|---|
| Domain 1 — Governance and Risk Management | Accountability and organisation structure; Technology and cyber strategy; Technology and cyber risk management framework (RMF) | Ensure clear board and senior-management accountability, a strategy aligned to business objectives, and a formal, integrated risk framework covering the full technology-and-cyber risk lifecycle. |
| Domain 2 — Technology Operations and Resilience | Technology architecture; Technology asset management; Technology project management; System development lifecycle (SDLC); Change and release management; Patch and vulnerability management (operational); Technology incident and problem management; Technology resilience, availability and recovery (including disaster recovery, backups, RTO/RPO) | Ensure a reliable, scalable, resilient technology environment that is managed through disciplined lifecycle processes and can recover from disruption within tolerances. |
| Domain 3 — Cyber Security | Cyber security posture and defence-in-depth; Identity and access management (IAM); Data security; Cyber security operations, monitoring and detection; Threat and vulnerability management; Cyber incident response and recovery; Cyber resilience testing (including scenario testing and threat-led testing) | Ensure the confidentiality, integrity and availability of technology assets and data through layered controls, continuous monitoring, and tested response and recovery capability. |
Wrapped around these three domains are two cross-cutting connections OSFI expects FRFIs to make explicit: third-party technology and cyber risk (governed jointly with Guideline B-10, which took effect in May 2024) and operational resilience (Guideline E-21), where technology and cyber disruptions are a primary driver of the ability to deliver critical operations within tolerances. B-13 also connects to OSFI's incident-reporting advisory, which sets the expectation to notify OSFI of a reportable technology or cyber security incident within 24 hours.
Master assessment checklist
This is the core of the guide. Each expected-outcome area below is presented with an h3 heading and a two-column table mapping what an auditor should verify to the typical evidence a FRFI should be able to produce. No control area is skipped. Use these tables as the working assessment programme; tailor depth to the FRFI's tier and materiality.
1.1 Accountability and organisation structure (Governance)
| What to verify | Typical evidence |
|---|---|
| The board of directors provides oversight of technology and cyber risk and approves the technology/cyber risk appetite. | Board and risk-committee mandates, minutes evidencing technology/cyber discussion, approved risk-appetite statement with technology/cyber metrics. |
| Senior management is clearly accountable for technology and cyber risk with defined roles (e.g. CIO/CTO, CISO). | Organisation charts, role mandates/job descriptions, accountability (RACI) matrices, delegation-of-authority documents. |
| Independent oversight exists via a second-line risk function and third-line internal audit (three lines model). | Risk-function charter, internal-audit plan covering technology/cyber, independence confirmations, committee reporting lines. |
| Technology and cyber risk is integrated into enterprise risk management (ERM) and reported to the board. | ERM framework referencing technology/cyber, board reporting packs, risk dashboards, escalation records. |
| Sufficient resourcing, skills and budget are allocated to technology and cyber functions. | Headcount and skills matrices, training records, budget allocations, resourcing plans, use of external specialists. |
1.2 Technology and cyber strategy
| What to verify | Typical evidence |
|---|---|
| A technology and cyber strategy exists and aligns with the enterprise business strategy and risk appetite. | Approved multi-year technology/cyber strategy document, board approval, alignment mapping to business plan. |
| The strategy addresses current-state, target-state, transition roadmap and key risks (e.g. legacy, technical debt, cloud, AI). | Current/target architecture summaries, roadmap, technical-debt register, cloud and emerging-technology plans. |
| Strategy is reviewed and updated on a defined cadence and in response to material change. | Version history, annual review evidence, change triggers, updated roadmaps. |
| Emerging technology risks (cloud, AI/ML, quantum, third-party concentration) are considered. | Emerging-technology risk assessments, horizon-scanning notes, AI governance policy where applicable. |
1.3 Technology and cyber risk management framework (RMF)
| What to verify | Typical evidence |
|---|---|
| A formal RMF defines the taxonomy, appetite, identification, assessment, response, monitoring and reporting of technology/cyber risk. | Approved RMF/policy suite, risk taxonomy, risk-and-control self-assessment (RCSA) methodology. |
| Risks are identified and assessed across the full lifecycle and inventory of technology assets. | Risk register, RCSA outputs, control library, key risk indicators (KRIs) linked to appetite. |
| Risk-appetite thresholds and tolerances are defined, monitored and breaches escalated. | Appetite statement with quantitative thresholds, breach logs, escalation and remediation records. |
| Issues and findings are tracked to closure with root-cause analysis. | Issue-management system extracts, remediation plans, ageing reports, root-cause records. |
| Third-party technology/cyber risk is integrated per Guideline B-10. | Third-party inventory, criticality tiering, due-diligence and contract clauses, concentration analysis. |
2.1 Technology architecture
| What to verify | Typical evidence |
|---|---|
| A defined, documented and governed technology architecture supports business needs and manages complexity. | Architecture standards, reference/target architectures, architecture-review-board (ARB) minutes. |
| Architecture decisions consider resilience, scalability, security-by-design and interoperability. | Design-review records, security-by-design checklists, non-functional requirements, exception approvals. |
| Legacy and end-of-life technology risk is identified and managed with remediation plans. | End-of-life/end-of-support registers, remediation roadmaps, compensating-control approvals. |
2.2 Technology asset management
| What to verify | Typical evidence |
|---|---|
| A complete, accurate and current inventory of technology assets (hardware, software, data, cloud, services) is maintained. | CMDB/asset-inventory extracts, reconciliation reports, discovery-tool outputs, coverage metrics. |
| Assets are classified by criticality and mapped to business services and critical operations. | Asset-criticality classification, service-to-asset mapping, business-impact links. |
| Asset lifecycle (acquisition, maintenance, decommissioning, disposal) is governed. | Lifecycle procedures, decommissioning records, secure-disposal certificates. |
| Software and licensing (including open-source) is inventoried and governed. | Software bill of materials (SBOM), licence registers, open-source policy and scans. |
2.3 Technology project and portfolio management
| What to verify | Typical evidence |
|---|---|
| Technology projects follow a governed delivery methodology with risk and control considerations. | Project-governance framework, stage-gate approvals, risk registers per project, PMO reporting. |
| Business cases, funding and prioritisation are governed and traceable. | Business cases, portfolio prioritisation records, investment-committee minutes. |
| Post-implementation reviews assess whether objectives and control expectations were met. | Post-implementation review reports, benefits-realisation tracking, lessons-learned logs. |
2.4 System development lifecycle (SDLC) and secure development
| What to verify | Typical evidence |
|---|---|
| A defined SDLC embeds security and quality gates from requirements through deployment. | SDLC policy, secure-coding standards, gate checklists, DevSecOps pipeline configuration. |
| Security testing (SAST, DAST, dependency/SCA, penetration) is performed proportionate to risk. | Test reports (SAST/DAST/SCA), pen-test reports, remediation tracking, release sign-offs. |
| Environments are segregated (dev/test/prod) with controlled promotion and no production data misuse. | Environment-segregation evidence, data-masking policy, promotion approvals. |
2.5 Change and release management
| What to verify | Typical evidence |
|---|---|
| Changes to production are assessed for risk, authorised, tested and documented. | Change-management policy, change tickets, CAB minutes, approval and back-out plans. |
| Emergency changes follow a controlled expedited process with post-hoc review. | Emergency-change records, retrospective approvals, exception logs. |
| Segregation of duties prevents unauthorised or self-approved changes. | Access reviews on change tooling, SoD control evidence, deployment-approval separation. |
2.6 Patch and vulnerability management (operational)
| What to verify | Typical evidence |
|---|---|
| Vulnerabilities are identified through scanning and threat intelligence and remediated within risk-based SLAs. | Scan reports, vulnerability register, remediation SLAs by severity, ageing and exception reports. |
| Patches are tested and deployed within defined timeframes; exceptions are risk-accepted and tracked. | Patch cadence records, deployment coverage metrics, risk-acceptance approvals with expiry. |
| Coverage extends across on-premises, cloud, endpoints and third-party managed assets. | Coverage dashboards, cloud-configuration scans, endpoint compliance reports. |
2.7 Technology incident and problem management
| What to verify | Typical evidence |
|---|---|
| Technology incidents are detected, classified by severity, escalated and resolved through a defined process. | Incident-management policy, incident tickets, severity matrix, escalation and communication logs. |
| Problem management addresses recurring incidents and root causes. | Problem records, root-cause analyses, permanent-fix tracking, trend analysis. |
| Reportable incidents trigger OSFI notification within the expected 24-hour window. | Incident-reporting procedure referencing OSFI advisory, notification records, timelines, post-incident reports. |
2.8 Technology resilience, availability and disaster recovery
| What to verify | Typical evidence |
|---|---|
| Availability and recovery objectives (RTO/RPO) are defined for critical systems and aligned to operational resilience tolerances. | RTO/RPO register, business-impact analysis (BIA), mapping to E-21 impact tolerances. |
| Backups are performed, protected (including immutable/offline copies) and periodically restore-tested. | Backup schedules, immutability configuration, restore-test results, retention policy. |
| Disaster-recovery and failover capabilities exist and are tested on a defined cadence. | DR plans, DR/failover test reports, results versus RTO/RPO, remediation of test gaps. |
| Resilience against destructive/ransomware scenarios is designed and tested (recovery from a compromised state). | Ransomware-recovery runbooks, isolated-recovery-environment evidence, scenario-test results. |
3.1 Cyber security posture and defence-in-depth
| What to verify | Typical evidence |
|---|---|
| A layered (defence-in-depth) control set protects assets across network, endpoint, application and data layers. | Security-architecture diagrams, control-coverage matrix, segmentation design, zero-trust roadmap. |
| Security baselines/hardening standards are defined and enforced. | Hardening standards (e.g. CIS benchmarks), configuration-compliance reports, drift alerts. |
| Cyber posture is measured and reported to management with a maturity view. | Posture metrics, maturity assessments, control-effectiveness reporting. |
3.2 Identity and access management (IAM)
| What to verify | Typical evidence |
|---|---|
| Access is granted on least-privilege and need-to-know, with joiner-mover-leaver processes. | IAM policy, provisioning/de-provisioning records, access-request approvals, leaver-timeliness metrics. |
| Multi-factor authentication (MFA) protects remote, administrative and privileged access. | MFA coverage reports, VPN/SSO configuration, admin-access MFA enforcement evidence. |
| Privileged access is managed via PAM with session monitoring and just-in-time access. | PAM configuration, privileged-session logs, credential-vaulting evidence, JIT-access records. |
| Periodic access recertification (user and privileged) is performed and exceptions remediated. | Recertification campaigns, attestation records, removed-access evidence, orphaned-account reports. |
3.3 Data security and protection
| What to verify | Typical evidence |
|---|---|
| Data is classified and protected commensurate with sensitivity throughout its lifecycle. | Data-classification policy, data inventory/mapping, handling standards by classification. |
| Encryption protects data in transit and at rest; key management is governed. | Encryption standards, TLS/cipher configuration, key-management policy, HSM/KMS evidence. |
| Data loss prevention (DLP) and controls over exfiltration channels are in place. | DLP policy and rules, DLP alert/response records, egress-control configuration. |
| Data retention, minimisation and secure disposal are enforced. | Retention schedules, disposal certificates, minimisation reviews. |
3.4 Cyber security operations, monitoring and detection
| What to verify | Typical evidence |
|---|---|
| Continuous monitoring (SIEM/SOC) covers critical assets with defined use cases and log sources. | SIEM use-case catalogue, log-source coverage, SOC operating model, alert-triage runbooks. |
| Threat detection tooling (EDR/XDR, network detection) is deployed and tuned. | EDR/XDR coverage reports, detection-rule tuning records, false-positive management. |
| Threat intelligence informs detection and defensive priorities. | Threat-intel feeds/subscriptions, intel-to-detection mapping, threat briefings. |
| Detection effectiveness is validated (e.g. detection engineering, purple-team exercises). | Detection-validation results, MITRE ATT&CK coverage mapping, purple-team reports. |
3.5 Threat and vulnerability management (cyber)
| What to verify | Typical evidence |
|---|---|
| A cyber threat and vulnerability management programme prioritises by exploitability and business impact. | TVM programme documentation, risk-based prioritisation methodology, KEV/threat-context enrichment. |
| Attack-surface and external-exposure management is performed. | External attack-surface reports, asset-exposure inventory, shadow-IT discovery. |
| Penetration testing and red-team assessments are conducted proportionate to risk. | Pen-test/red-team scopes and reports, remediation tracking, retest evidence. |
3.6 Cyber incident response and recovery
| What to verify | Typical evidence |
|---|---|
| A cyber incident response plan (CIRP) defines roles, severity, containment, eradication and recovery. | CIRP document, playbooks by scenario, RACI, contact trees, legal/comms/regulatory workflows. |
| OSFI notification (24-hour expectation) and other regulatory/privacy obligations are embedded. | Reporting matrix (OSFI, privacy commissioners, law enforcement), notification templates, timelines. |
| Response capability is exercised via tabletop and technical simulations, with lessons applied. | Tabletop/simulation records, exercise reports, corrective-action tracking, plan updates. |
| Recovery restores services within tolerances and validates integrity before return to service. | Recovery runbooks, integrity-validation steps, return-to-service approvals, post-incident reviews. |
3.7 Cyber resilience and scenario / threat-led testing
| What to verify | Typical evidence |
|---|---|
| Severe-but-plausible cyber scenarios (including destructive attacks) are tested against resilience objectives. | Scenario catalogue, severe-but-plausible test plans, results versus impact tolerances. |
| Threat-led/intelligence-led testing is considered for significant FRFIs. | Threat-led test scope, intelligence inputs, red-team engagement reports, board reporting of results. |
| Test findings feed remediation and continuous improvement of resilience. | Findings registers, remediation roadmaps, re-test evidence, trend of resilience maturity. |
Cross-cutting: Third-party technology and cyber risk (with B-10)
| What to verify | Typical evidence |
|---|---|
| Third-party and cloud arrangements supporting technology/cyber are inventoried and risk-tiered. | Third-party inventory, criticality tiering, cloud-service register, concentration/nth-party mapping. |
| Due diligence, contractual controls, right-to-audit and exit/portability are in place for critical providers. | Due-diligence assessments, contracts with security/audit/exit clauses, SOC 2/ISO reports, exit plans. |
| Ongoing monitoring of provider security posture and SLAs is performed. | Provider performance/security reports, SLA monitoring, issue tracking, attestations. |
| Concentration and systemic (cloud/vendor) risk is assessed and reported. | Concentration-risk analysis, board reporting, contingency arrangements for critical dependencies. |
Scoping and materiality / tiering
B-13 does not impose fixed tiers, but proportionality demands that a FRFI scope its programme against the criticality of its technology assets and business services. In practice, scoping combines three lenses: institution-level proportionality (size, complexity, D-SIB status), business-service criticality (which services, if disrupted, breach operational-resilience tolerances under E-21), and asset criticality (which systems, data and third parties underpin those services).
- Determine institution proportionality tier — from small/monoline to internationally active D-SIB — to set the baseline rigour of governance, testing and reporting.
- Identify critical operations and services (aligned with E-21) and their impact tolerances.
- Map the technology assets, data and third parties that support each critical service, and classify by criticality.
- Assess inherent technology/cyber risk per asset and service, factoring in threat exposure, interconnectivity and third-party concentration.
- Set control expectations and testing depth proportionate to criticality and residual risk; document exceptions and risk acceptances.
- Re-scope on material change (new products, cloud migration, M&A, significant incidents) and at least annually.
Implementation approach
A pragmatic B-13 implementation runs across five phases. Each phase below lists key activities and the deliverables an auditor would expect to see.
Phase 1 — Mobilise and assess (0–3 months)
- Activities: Establish programme governance and sponsorship; perform a B-13 gap assessment against all three domains; confirm proportionality tier; align with E-21 critical operations and B-10 third-party inventory.
- Deliverables: Programme charter and RACI; current-state gap assessment and heatmap; prioritised remediation backlog; board/committee briefing.
Phase 2 — Design and govern (3–6 months)
- Activities: Draft/refresh the technology and cyber RMF, risk appetite, strategy and policy suite; define asset-criticality and data-classification schemes; design the target control set and testing regime.
- Deliverables: Approved RMF, risk-appetite statement, strategy, and policy/standard library; classification schemes; control framework and control-to-outcome mapping.
Phase 3 — Build and remediate (6–15 months)
- Activities: Close priority gaps — asset inventory/CMDB, IAM/PAM/MFA uplift, SIEM/SOC and EDR coverage, patch/vulnerability SLAs, backup immutability and DR uplift, secure SDLC/DevSecOps, third-party clauses.
- Deliverables: Remediated controls with evidence; updated CMDB; monitoring coverage dashboards; DR and backup test results; secure-pipeline configuration.
Phase 4 — Test and validate (12–18 months)
- Activities: Run DR/failover tests, ransomware-recovery tests, tabletop and technical incident simulations, penetration and (for significant FRFIs) threat-led testing; validate detection coverage.
- Deliverables: Test reports and findings registers; resilience scenario results versus tolerances; detection-coverage (ATT&CK) mapping; corrective-action plans.
Phase 5 — Embed and continuously improve (ongoing)
- Activities: Operationalise KRIs/KPIs and board reporting; run continuous control monitoring and periodic recertifications; maintain issue closure; re-scope on change; refresh strategy annually.
- Deliverables: Recurring board/risk reporting; KRI/KPI dashboards; recertification and audit trail; refreshed strategy and roadmap; maturity trend.
Maturity / capability model
B-13 does not define its own maturity scale, but OSFI supervisors and internal-audit teams commonly assess FRFIs against a five-level capability model. The following illustrative model helps FRFIs benchmark and target improvement across the three domains.
| Level | Descriptor | Characteristics against B-13 outcomes |
|---|---|---|
| 1 | Initial / Ad hoc | Controls informal and reactive; no formal RMF; incomplete asset inventory; limited monitoring; recovery untested. High supervisory concern. |
| 2 | Developing | Some policies and controls exist but are inconsistent; partial coverage; reactive patching; DR plans exist but rarely tested. |
| 3 | Defined | Formal RMF, strategy and policies in place; asset inventory largely complete; risk-based SLAs; DR and incident processes documented and periodically tested. |
| 4 | Managed / Measured | Controls monitored with KRIs/KPIs; risk-based, metrics-driven decisions; regular DR, resilience and threat-led testing; strong third-party governance; board-level reporting. |
| 5 | Optimised / Resilient | Continuous improvement; automated monitoring and response; proven recovery from severe scenarios; anticipatory threat management; resilience embedded in strategy and culture. |
Assessment and audit approach
Whether performed by internal audit, an independent assessor (such as CyberSigma), or in preparation for OSFI supervisory review, a B-13 assessment should follow a structured, evidence-based method.
- Define scope and objectives: confirm the FRFI's proportionality tier, critical operations (E-21) and the domains/outcomes in scope.
- Establish the control-to-outcome mapping: map the FRFI's controls to each B-13 expected outcome and to relevant reference frameworks (NIST CSF, ISO 27001).
- Collect and review documentation: policies, RMF, strategy, registers, test reports and reporting (use the evidence-request list below).
- Conduct interviews and walkthroughs: with board/committee members, CISO/CTO, risk, internal audit, SOC, and third-party management.
- Perform control testing: design-effectiveness (does the control exist and is it well-designed) and operating-effectiveness (does it work over a period), including sampling.
- Assess resilience and testing evidence: DR, backup restore, ransomware recovery, incident simulations and threat-led testing results versus tolerances.
- Evaluate third-party and concentration risk: coverage, contracts, monitoring and exit arrangements.
- Rate maturity and identify gaps: against the capability model and expected outcomes; classify findings by severity.
- Produce findings and remediation roadmap: with owners, priorities, timelines and residual-risk statements.
- Report to management/board and, where relevant, prepare for OSFI engagement: with a clear, evidence-backed position and remediation commitments.
Evidence request list
The following categorised list is the evidence an assessor should request. It doubles as an implementer's checklist of artefacts to maintain.
- Governance: board/committee mandates and minutes; approved risk-appetite statement; organisation charts and RACI; delegation-of-authority.
- Strategy and framework: technology and cyber strategy and roadmap; technology/cyber RMF; policy and standard library; risk taxonomy.
- Risk registers: enterprise and technology/cyber risk registers; RCSA outputs; KRI/KPI dashboards; issue-management and remediation tracking.
- Asset and data: CMDB/asset inventory; asset-criticality classification; data-classification policy and data mapping; SBOM/licence registers.
- Operations: change-management and CAB records; SDLC and secure-coding standards; patch and vulnerability reports and SLAs; incident and problem records.
- Resilience: BIA and RTO/RPO register; DR and backup test results; ransomware-recovery runbooks; resilience scenario-test reports.
- Cyber: security architecture and hardening standards; IAM/PAM/MFA coverage; SIEM/SOC use cases and coverage; EDR/XDR reports; DLP and encryption evidence.
- Testing: penetration-test and red/purple-team reports; threat-led testing results; detection-validation (ATT&CK) mapping; remediation and retest evidence.
- Incident and reporting: incident-response plan and playbooks; OSFI 24-hour notification procedure and past notifications; post-incident review reports.
- Third party: third-party inventory and tiering; due-diligence assessments; contracts (security, audit, exit); concentration analysis; provider assurance reports.
- Assurance: internal-audit reports and plan; prior external assessments; management-response and closure evidence.
Roles and responsibilities
| Role | Primary responsibilities under B-13 | Line of defence |
|---|---|---|
| Board of Directors | Approve technology/cyber risk appetite; oversee strategy and framework; challenge management; ensure resourcing. | Oversight |
| Board Risk / Technology Committee | Detailed oversight of technology and cyber risk; review reporting, incidents and resilience testing outcomes. | Oversight |
| CEO / Senior Management | Set the tone; ensure the RMF is implemented and resourced; accountable for outcomes. | First line |
| CIO / CTO | Own technology operations, architecture, resilience, DR and lifecycle processes. | First line |
| CISO | Own cyber security strategy, operations, monitoring, incident response and cyber resilience. | First line |
| Technology / cyber operations teams | Execute controls: patching, monitoring, IAM, backups, change, SOC operations. | First line |
| Second-line risk (ERM / technology & cyber risk) | Set framework and appetite; independent challenge; aggregate reporting; monitor KRIs. | Second line |
| Compliance / regulatory reporting | Ensure OSFI notification and other regulatory obligations are met on time. | Second line |
| Internal Audit | Independent assurance over design and operating effectiveness of technology/cyber controls. | Third line |
| Third-party / vendor management | Govern third-party technology/cyber risk with B-10 alignment; monitor concentration and exit. | First/second line |
KPIs / metrics to track
- Percentage of critical assets in the CMDB with current, reconciled records (inventory completeness).
- Mean time to detect (MTTD) and mean time to respond (MTTR) for cyber incidents.
- Percentage of critical/high vulnerabilities remediated within SLA and vulnerability ageing.
- MFA coverage across privileged, administrative and remote access; privileged-account count and JIT usage.
- Patch compliance rate across on-premises, cloud and endpoints.
- Backup success rate and restore-test pass rate; percentage of critical systems with immutable/offline backups.
- DR/failover test results versus RTO/RPO; number of systems meeting recovery objectives.
- Percentage of critical services tested against severe-but-plausible scenarios within tolerances.
- Access-recertification completion rate and orphaned/stale-account counts.
- Number and severity of reportable incidents; percentage of OSFI notifications made within 24 hours.
- Third-party critical-provider assurance coverage and open third-party findings.
- Open technology/cyber audit and risk findings by severity and ageing beyond due date.
- Risk-appetite breaches by KRI and time-to-remediate.
Readiness checklist
- Board-approved technology/cyber risk appetite and clear senior-management accountability are in place.
- A formal technology and cyber risk management framework, strategy and policy suite exist and are current.
- A complete, criticality-classified asset inventory (CMDB) maps assets to critical services.
- Critical operations and impact tolerances are defined and aligned with Guideline E-21.
- IAM controls enforce least privilege, MFA on privileged/remote access, and PAM with recertification.
- Data is classified, encrypted in transit and at rest, with DLP and key management governed.
- Continuous monitoring (SIEM/SOC) and EDR/XDR cover critical assets with tuned detections.
- Risk-based patch and vulnerability SLAs are met and tracked with exception governance.
- Change, release and secure SDLC processes enforce segregation of duties and security gates.
- Backups are immutable/offline and restore-tested; DR and failover are tested against RTO/RPO.
- Ransomware and destructive-scenario recovery is planned and tested.
- A cyber incident response plan embeds the OSFI 24-hour notification and is exercised regularly.
- Third-party/cloud arrangements are tiered, contracted (security, audit, exit) and monitored per B-10.
- KRIs/KPIs are reported to the board and issues are tracked to closure.
- Internal audit provides independent assurance over technology and cyber controls.
Common gaps and findings
- Incomplete or stale asset inventory, leaving unknown or unmanaged assets outside the control perimeter.
- Risk appetite defined qualitatively with no measurable thresholds, so breaches are not detected or escalated.
- DR plans that exist on paper but are rarely or never tested, with no evidence of meeting RTO/RPO.
- Backups that are not immutable/offline and not restore-tested, leaving the FRFI exposed to ransomware.
- MFA gaps on legacy systems, service accounts or administrative access; weak privileged-access management.
- Vulnerability and patch backlogs with unmanaged risk acceptances and no expiry review.
- Third-party concentration (especially cloud) not assessed; missing right-to-audit, exit and portability clauses.
- Incident-response plans not exercised; unclear ownership of the OSFI 24-hour notification obligation.
- SIEM/SOC coverage gaps and untuned detections producing alert fatigue and missed detections.
- Weak alignment between B-13, E-21 (operational resilience) and B-10 (third-party) creating fragmented governance.
- Board reporting that lacks depth on technology/cyber risk, resilience-testing outcomes and residual risk.
- Insufficient testing of severe-but-plausible and destructive scenarios; no threat-led testing at significant FRFIs.
OSFI B-13 mapped to other frameworks
B-13's outcomes align closely with established control and resilience frameworks, which FRFIs can leverage to structure and evidence their programmes. The mapping below is indicative, not authoritative.
| B-13 domain / outcome area | Related framework / control area | Nature of relationship |
|---|---|---|
| Governance and Risk Management | NIST CSF (Govern, Identify); ISO 27001 clauses 4–10 and ISO 27005; COBIT | Governance, risk framework and accountability align to CSF Govern/Identify and ISO ISMS clauses. |
| Technology Operations and Resilience | ISO 22301 (business continuity); NIST SP 800-34; ITIL (change/incident/problem); OSFI E-21 | Resilience, DR and lifecycle map to continuity standards, ITIL practices and OSFI operational resilience. |
| Cyber Security | NIST CSF (Protect, Detect, Respond, Recover); ISO 27001/27002; CIS Critical Security Controls | Defence-in-depth, monitoring and response map to CSF functions, ISO Annex A and CIS Controls. |
| Third-party technology/cyber risk | OSFI B-10; NIST SP 800-161 (supply chain); SOC 2 / ISAE 3402 | Third-party governance aligns with B-10 and supply-chain and service-assurance standards. |
| Incident reporting (24-hour) | OSFI Technology and Cyber Security Incident Reporting advisory; PIPEDA breach reporting | OSFI supervisory notification complements privacy breach-reporting obligations. |
| Resilience / scenario testing | OSFI E-21; CBEST/TIBER-style threat-led testing; NIST CSF Recover | Severe-but-plausible and threat-led testing align with operational-resilience and intelligence-led test regimes. |
| Data security | NIST CSF Protect; ISO 27001 Annex A; PIPEDA / provincial privacy law | Data classification, encryption and DLP support both security outcomes and privacy compliance. |
How CyberSigma helps
CyberSigma helps FRFIs achieve and evidence conformance to OSFI B-13 end to end. As a CERT-In empanelled and PCI QSA-led advisory, we run a domain-by-domain B-13 gap assessment across Governance, Technology Operations and Cyber Security, aligned with E-21 operational resilience and B-10 third-party risk. We build or refresh your technology and cyber risk management framework, risk appetite and policy suite; uplift IAM/PAM/MFA, SIEM/SOC detection, vulnerability management, backup immutability and disaster recovery; and design and run DR, ransomware-recovery, incident-simulation and threat-led testing against your impact tolerances. Our platform tracks controls, KRIs/KPIs, evidence and remediation in one place, produces board-ready reporting, and prepares you for OSFI supervisory engagement — including your 24-hour incident-notification readiness. Talk to CyberSigma to move from gap assessment to a tested, audit-ready and resilient technology and cyber risk programme.
Frequently asked questions
Who must follow OSFI B-13?
Federally regulated financial institutions in Canada — banks, insurers and federally regulated trust and loan companies.
Official documents
CyberSigma resources
Need help with OSFI B-13?
CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.