Technology governance, risk and compliance

Control frameworks, risk reporting, and third-party oversight that hold up when someone asks to see the evidence — sized for your organization, not a bank’s program handed to a firm of twelve. Built by someone who spent a decade running this discipline inside one of Canada’s five largest banks.

Three situations

Who we work with

Firms with a regulator in the room

Smaller federally regulated institutions, credit unions, portfolio managers, insurers and MGAs facing OSFI B-13 technology risk expectations, provincial equivalents, or supervisory findings — without an enterprise risk function to absorb them.

Firms with an institution in the room

Fintechs, servicers and technology providers whose largest clients are banks and insurers. Their B-10 third-party risk obligations arrive at your door as questionnaires, audit clauses, and contract schedules.

Firms with an auditor in the room

Companies whose external audit, SOX 404 / ICFR programme, or internal audit function keeps surfacing the same IT general control deficiencies year after year — and who want them designed out rather than re-remediated annually.

Why firms call us

You’re probably here because of one of these.

  • OSFI B-13, or your provincial regulator’s equivalent, applies to you — and your current “framework” is a folder of policies written by a predecessor that nobody follows.
  • A regulatory finding or external audit management letter named IT general controls, access management, change management, or third-party oversight, and the remediation deadline is real.
  • Your board or audit committee asked for a technology risk report and what they got was a status update on IT projects.
  • A major client’s vendor risk team sent a questionnaire with two hundred questions, and your answers are being drafted by whoever is least busy.
  • You’ve grown past the point where technology risk can live in the CTO’s head, and everyone knows it.

Every one of these is a governance problem wearing a different costume. The fix is the same discipline, sized correctly.

What we deliver

Where we help

Technology risk and control framework design

A control framework built on COBIT and COSO that maps your actual technology risks to actual controls with actual owners — not a copied control library that audits badly and operates worse. Includes the process, risk and control documentation that lets an auditor, regulator or client trace a risk to its mitigations and evidence.

OSFI B-13 readiness and gap assessment

Where you stand against OSFI’s technology and cyber risk management expectations — governance, technology operations, resilience, and cyber security — with a risk-ranked remediation roadmap proportional to your size. Equally applicable as a benchmark for provincially regulated firms whose supervisors are converging on the same expectations.

Risk appetite, KRIs and board reporting

The discipline of saying how much technology risk you’re willing to run, measuring against it, and reporting it in a form a director can act on. Risk appetite statements, key risk indicator suites, issue and remediation tracking, and committee reporting packs. See a worked example of what this looks like sized for a firm your size.

Issue management that closes issues

An intake, triage, ownership and escalation process with enough teeth that findings get remediated rather than re-dated. Including the independent challenge routine — someone empowered to ask a remediation owner “why is this late?” and log the answer.

Third-party technology risk management

Risk-tiered vendor assessment, onboarding due diligence, ongoing monitoring, and contract control schedules aligned to OSFI B-10 — whether you’re the institution that must run this process, or the vendor who must survive it. If your exposure is specifically AI or model vendors, see our AI governance advisory, where the same B-10 obligations meet OSFI E-23.

IT general controls design and remediation

Access, change, operations and SDLC controls designed to be operable by the team you actually have — and to produce evidence as a by-product of normal work rather than as an annual archaeology project before the audit. For the independent review side of this work, see internal controls and IT audit review.

Governance operating model

Three-lines-of-defence design scaled honestly for smaller firms (where the second line may be one person and part of a job description), committee terms of reference, decision rights, and the meeting cadence that makes it real.

Engagement shapes

Typical engagements

Gap assessment

2–4 weeks · Fixed fee, quoted at proposal

Your control environment against B-13, COBIT, or a client’s requirements — whichever ruler matters to you. Findings ranked by risk, roadmap sized by effort.

Framework build

8–14 weeks · Fixed fee, quoted at proposal

Full technology risk and control framework: policy set, control library, risk appetite and KRIs, issue management process, and reporting scaffolding — built with your team, handed over as working documents you own.

Remediation support

Scoped per finding set · Fixed fee, quoted at proposal

You have the findings; we design the fixes and the evidence trail. Typically follows a regulatory exam, external audit, or a failed client assessment.

Fractional technology risk leadership

Monthly retainer · Quoted at proposal

A standing second line for firms that need the capability but not the headcount: committee attendance, report preparation, challenge of remediation owners, and a direct line when something lands unexpectedly.

Fluency, not jargon

Standards and frameworks

Canadian regulatory

  • OSFI B-13 (Technology and Cyber Risk Management)
  • OSFI B-10 (Third-Party Risk Management)
  • OSFI E-21 (Operational Risk and Resilience)
  • Provincial equivalents, where applicable

Control and governance

  • COBIT 5
  • COSO Internal Control and ERM frameworks
  • Three lines of defence
  • SOX 404 / ICFR, for listed entities

Security and resilience reference points

  • NIST Cybersecurity Framework
  • ISO 27001, where clients are certified or pursuing certification

Why Hosmak

We’ve run this discipline, not just advised on it.

There is a difference between a consultant who has written technology risk frameworks and one who has operated them — who has maintained the control library through three reorganizations, defended the KRI thresholds in committee, and chased the remediation owner on the issue that slipped twice.

Our founder spent eleven years at PwC and EY delivering technology governance, IT risk and controls engagements to financial services clients — over fifty engagements spanning ITGC audits, SOX 404 programs, framework design and ERP implementation reviews. Then nearly a decade inside one of Canada’s five largest banks doing the operating side: building the enterprise Technology Process, Risk and Control framework, owning the T&O risk appetite statement and KRI suite, running the governance committee routines, and designing the risk reporting that went to executive and board risk committees.

That combination matters for one practical reason: everything we build for you is designed to survive contact with real operations. We know which controls die of neglect, which reports boards actually read, and which framework elements exist only to impress an assessor — because we’ve watched all three happen from the inside.

Credentials

Questions

Common questions

We already have policies. Isn’t that a framework?

Policies are the easiest third. A framework is policies plus controls that map to them, owners who operate them, evidence that accumulates as they run, and reporting that tells someone when they fail. Most “we have a framework” firms have documents; the gap shows up the first time someone asks for evidence.

B-13 doesn’t apply to us — we’re provincially regulated. Why benchmark against it?

Because it’s the clearest articulation of what Canadian supervisors expect, provincial regulators are converging on it, and your institutional clients and insurers already treat it as the reference point. Meeting a proportionate version of B-13 answers most other rulers you’ll be measured against.

How is this different from what our IT team already does?

Your IT team operates technology. This discipline governs it: deciding how much risk is acceptable, checking whether controls actually work, and telling leadership the truth about both. Doing that credibly requires some independence from the team being assessed — which is precisely why it’s hard to grow internally in a small firm.

Can you work with our existing auditors?

Yes, and the framework is built to make their work cheaper: controls documented in a form auditors can test, evidence produced as a by-product of operations. Note that we act as advisors — we design and build; we don’t issue assurance opinions on our own work, and you wouldn’t want an advisor who offered to.

How much of our time does this take?

Less than doing it without help, more than zero. Expect a few hours a week from the people who own the processes — the framework has to reflect how you actually work, and only your team knows that.

What does the board see at the end?

A one-page risk posture view they’ll actually read, backed by the appetite statement, KRIs and issue tracking behind it. If the board pack we build needs a consultant to explain it, we’ve failed.

This page describes general regulatory expectations and industry practice, not legal advice. Firms should confirm their specific obligations against the source instruments and with their own advisors.

Start with a conversation

Bring the finding, the questionnaire, or the board question. Thirty minutes, no cost, and you’ll leave knowing what it would take to answer it properly — whether or not you work with us.

Book a 30-minute consultation

Or email hello@hosmaksolutions.ca