SOC 2 Type II is an independent audit standard that measures a service provider's security controls over a period of time — typically six to twelve months — not at a single point. Most Ontario MSPs advertise “enterprise-grade security.” Very few complete a Type II audit. This page explains what SOC 2 Type II actually attests to, what most MSPs are quietly not doing, and how to verify a provider's report before you sign.
Need something fixed today instead? See IT support in Toronto
SOC 2 (System and Organization Controls 2) is a reporting framework developed by the AICPA — the American Institute of Certified Public Accountants — that evaluates a service organisation's controls against five Trust Services Criteria: security, availability, processing integrity, confidentiality and privacy. It is not a product, a badge you can buy, or a self-assessment. A qualified independent CPA firm has to audit your environment, observe your controls, and issue a signed opinion. Type I attests that controls are designed appropriately at a single moment. Type II attests that those controls actually operated as designed across a defined period. Type II is the harder one. It is also the one buyers should ask for.
Prefer responsive, day-to-day help without a monthly agreement? See IT support in Toronto. Weighing a move from your current provider? We handle the whole changeover — see switching IT providers.
A Type II report evaluates whether a provider's stated controls were operating effectively over the audit period. That is not a self-declaration. Every control tested has to have evidence — access-review logs, backup test records, patch histories, incident tickets, change-approval records, joiner-mover-leaver documentation — and the auditor sampling proves the controls fired as intended, in production, over months. Below are the categories a Type II auditor tests in an MSP's environment.
The default criteria set every SOC 2 report includes. Auditors test logical access (MFA enforced, role-based permissions, joiner-mover-leaver evidence), physical access to production systems, change management (every change approved, tested, documented), incident response (runbooks that exist, get followed, and produce tickets you can pull months later), and system monitoring. Type II verifies these ran continuously over the audit period — not just on the day the auditor visited.
Optional criteria added when a provider's uptime is contractually meaningful. Auditors test capacity planning, redundancy, environmental protections, backup rotation, and — crucially — evidence of tested restores across the audit period. “We have backups” is not the same as “we restored them on a schedule and the restore worked.” Type II wants the log.
Optional criteria that verifies processing is complete, accurate, timely and authorised. Relevant for MSPs whose services touch client transactions or ticket workflows. Auditors sample ticket handoffs, escalation paths, and the reconciliation between what a client asked for, what got done, and what was billed.
Optional criteria applied when the MSP is entrusted with confidential client data (which, for an MSP, is essentially always). Auditors test data classification, encryption in transit and at rest, secure disposal, and access reviews. Every user account that ever had elevated privileges gets sampled; the auditor wants to see it was authorised, used only for what it was authorised for, and revoked when no longer needed.
Optional criteria applied when personal information is collected, used, retained or disclosed on behalf of the client. Auditors test notice, choice and consent processes, collection minimisation, retention policies, and — for Canadian MSPs — alignment with PIPEDA and Quebec's Law 25. A privacy scope means the MSP is willing to be measured on how it handles client PII, not just its own.
Every change to production — a firewall rule, a group policy, an M365 conditional-access change, a new admin — has to have an approval trail, a tested-in-a-lower-environment trail, and a rollback plan. Type II auditors pull a sample of production changes across the audit period and trace them backward through the trail. Missing any step in the sample is a finding.
MSPs run on subprocessors — EDR, RMM, PSA, email security, backup platforms, cloud infrastructure. Type II examines whether the MSP has a documented process for selecting them, reviewing their own SOC 2 or ISO 27001 reports at least annually, and dropping any that fail the standard. Passing your own audit but relying on a subprocessor whose audit lapsed is the kind of finding that shows up in a qualified opinion.
The oversight layer. A board or leadership function reviews the risk register, security incidents, control failures and remediation status. The auditor wants minutes, decisions, and evidence that the leadership team is actually reading what security shows them. “We meet quarterly” does not survive a Type II unless there is a document trail attached.
A Type II audit is expensive, disruptive, and takes twelve to eighteen months from decision to signed report. The audit itself is only the last step. Before you can pass one, you have to formalise policies, deploy the tooling that produces evidence, train everyone on the disciplines the auditor will sample, and run all of it in production long enough for the auditor to see it consistently. Most small and mid-sized MSPs decide the return doesn't justify the cost. They rely on “SOC 2 aligned,” “SOC 2 in progress,” or a vendor's SOC 2 report as a proxy. None of that is the same as a signed Type II opinion in the MSP's own name.
| Ad-hoc or hourly support | Managed agreement | |
|---|---|---|
| What triggers work | You notice a problem and call | Monitoring, scheduled maintenance, and your tickets |
| Cost behaviour | Rises in your worst months | Fixed monthly, quoted before you sign |
| Commercial incentive | The provider bills more when things break | The provider absorbs the cost when things break |
| Documentation | Lives in the technician's head | Maintained in our system and handed to you on request |
| Security posture | Reviewed when something happens | Baselined at onboarding, reviewed on a set cycle |
| Patching | When someone gets to it | Scheduled, with a maintenance window you agreed |
| Budgeting | Reactive purchase orders | Forecast in the vCIO review |
| Escalation | Whoever answers | Defined path by priority, named account contact |
The Type II audit measures whether the MSP itself has security discipline, day in and day out, over months. That is the question that matters when you are handing them your credentials, your data, and administrative access to your environment. It cannot be answered by the security posture of the tools they resell.
Anyone can print “SOC 2” on a website. Verifying it takes five questions. Ask them, in writing, before signing an agreement.
A Type II report covers a defined window — usually six or twelve months. Read the cover page. “Period from 1 January to 31 December 2025” is a real, current window. “As of 15 September 2023” is a Type I. “Period from 1 January to 31 December 2022” is a stale Type II — fine as history, not fine as current assurance. Ask when the next report is scheduled.
An auditor's opinion is either unqualified (clean) or qualified (they found things). Read the exceptions section. Every real audit has some findings — the question is whether they were minor and remediated, or systemic and unresolved. “Clean, with three minor exceptions all remediated within the period” is a healthy report. Fifteen exceptions in change management is not.
The five questions to ask before signing with any MSP that claims SOC 2. Ask them in the order below. Any ‘no’ answer is a clarifying signal, not automatically a disqualifier — but a Type II auditor's signed report should be non-negotiable at the size of engagement most Ontario businesses now sign.
That last item is not a technicality dressed up as fine print. If a client declines MFA, or keeps a legacy server that cannot be patched, we will document it, propose the alternative, and record the accepted risk. We will still help. It simply sits outside the fixed fee, and you will know that in advance rather than afterwards.
Both models run on the same agreement structure, the same tooling, and the same SOC. The difference is who holds which responsibilities.
We are your IT department. We hold the helpdesk, the infrastructure, the security operations, the vendor relationships, and the strategy. This suits businesses with no internal IT staff, or with an office manager who has quietly inherited IT alongside their actual job.
You keep your internal IT person or team, and we take the layers that are hard to staff for: the after-hours coverage, the security operations centre, the patching and monitoring platform, the escalation path for problems outside their specialism, and the holiday and sick-leave cover. Your team keeps the user relationships and the application knowledge that is genuinely theirs. More detail on co-managed IT.
If your internal person is spending their week on password resets and printer queues rather than the projects you hired them for, co-managed usually returns more value than either replacing them or hiring a second. If IT is currently nobody's actual job, fully managed is the cleaner answer. We will say which one we think fits after the assessment, including when that means recommending the smaller engagement.
Signing an agreement does not make an environment supportable. Onboarding is where a managed relationship is made or lost, so ours is a defined project with a named lead, not a handover email.
We deploy monitoring and management agents, take a full inventory of hardware, software, licences, and identities, and document network topology, firewall rules, backup jobs, and administrative credentials. We meet your team so they know who they are calling. Anything urgent found in this window is dealt with immediately rather than queued behind the plan.
We work through the findings from discovery in risk order: unsupported operating systems, missing or failing backups, absent MFA, over-privileged accounts, unpatched firmware, expired warranties, shared administrator credentials. Items inside the agreement are simply done. Items that are genuinely projects were flagged and priced at quoting stage, so you are approving something you already saw.
Security baselines are applied and confirmed, backup restores are tested and recorded, documentation is completed, and the escalation path and maintenance windows are agreed in writing. You receive your first full reporting pack and hold your first review with the virtual CIO, which sets the roadmap and budget forecast for the year ahead.
If you have an incumbent provider, we manage the handover: credential transfer, licence and tenancy ownership, DNS and domain control, backup data, and documentation. Tenancy and domain ownership should sit with you, not with any provider, and if it currently does not, correcting that is part of onboarding.
A managed agreement that nobody reviews becomes an invoice nobody questions. Ours has a governance rhythm attached.
Tickets are classified by business impact, from a full outage affecting the whole company down to routine requests. Each priority carries a response target set out in your agreement, along with the escalation path if it is not met. Priority definitions are written in plain terms describing business impact, so classification is not a matter of interpretation after the fact.
You receive a regular reporting pack covering ticket volume and type, response performance against target, patch and backup status, security events handled, and asset changes. It is written to be read by a business owner rather than a systems administrator.
Scheduled reviews with your virtual CIO cover what the reporting is showing, the current risk register, the budget forecast, licence and warranty renewals coming up, and the projects worth planning. This is where recurring problems get addressed structurally instead of being closed as tickets forever.
Changes to your environment follow an agreed approval process, and you have a named account contact who knows your business rather than a general enquiries queue. Changes to scope — sites, users, systems — are recorded as schedule amendments so the agreement stays an accurate description of reality.
Terms are agreed up front. If the relationship ends, your documentation, credentials, tenancy ownership, and backup data are yours and are handed over. We would rather be kept because the work is good than because leaving is difficult.
Security is not a line item you add to a managed agreement in Toronto. It is the reason most of the agreement exists.
Every managed client is brought to a defined security baseline: managed endpoint detection and response, enforced multi-factor authentication, conditional access policies, managed firewall and email filtering, privileged account separation, and backups held so that an attacker with access to production cannot reach them. Our Security Operations Centre triages alerts around the clock and escalates to your named contacts under the process agreed at onboarding.
We are SOC 2 Type 2 attested. That means an independent auditor examined how we handle client data and administrative access over a period of time, not on a single day. It is an attestation, not a certification, and we describe it accurately because the firms that ask us about it — legal, financial, healthcare — know the difference.
For regulated and contractually obligated clients, we support the evidence side of compliance: access reviews, log retention, documented controls, and completed security questionnaires for your clients, your regulator, or your cyber insurer. More on our compliance work.
We do not publish uptime figures or guarantees. Availability depends on your hardware, your carriers, your cloud providers, and your budget for redundancy, and a number on a marketing page tells you nothing about any of them. What we will do is state, in your agreement, what we monitor, what we maintain, how we respond, and how it is reported.
The agreement structure is consistent. What changes by sector is the baseline, the compliance evidence, and the applications we need to support.
Practice management and imaging systems, PHIPA obligations, workstation hygiene in operatories, and backups that are provably restorable. Multi-site practices get consistent standards across every location. See managed IT for dental practices.
Document management, matter confidentiality, retention and access controls, client security questionnaires, and law society expectations around data handling.
Privileged access control, audit logging, retention, and the security evidence that institutional clients and regulators request.
ERP and warehouse systems, plant floor equipment on networks that were rarely designed with security in mind, and separation between operational technology and the corporate network.
Site connectivity, mobile and rugged devices, and project teams that appear and disband as jobs start and finish.
Constrained budgets, donor and member data obligations, high volunteer turnover, and licensing programmes worth actually using.
We work remote-first because it is faster for the majority of issues, and on-site when a problem needs hands on hardware. What matters under an agreement is that this is written down rather than negotiated each time: your agreement states how often scheduled on-site attendance is included and how additional visits are handled.
Our Toronto office is at 401 Bay Street, 16th Floor, with a second office at 141 Main Street N in Markham. Managed clients are supported across Toronto, North York, Scarborough, Etobicoke, Markham, Vaughan, Richmond Hill, Mississauga, Brampton, and Oakville.
Our local presence, the districts we attend, and how day-to-day support works if you are not on an agreement are set out on our IT support in Toronto page. This page covers only how on-site attendance is scheduled and charged inside a managed agreement.
Seven questions that separate real SOC 2 Type II attestation from marketing language. Ask them in writing before signing.
Type I is a snapshot of control design at a single moment. Type II is evidence that controls operated over months. If the report you are shown is Type I, the MSP has started the journey but is not yet audited on how they actually operate day to day.
Security is mandatory in every SOC 2. Availability, Processing Integrity, Confidentiality and Privacy are optional. A report scoped only to Security is defensible but narrower than one that also includes Confidentiality and Availability. Ask what is in the scope of the specific report you are being shown.
“We are SOC 2 certified” without a willingness to share the report is a red flag. The whole point of a SOC 2 is that the report is shareable with clients and prospects under an NDA. If a provider will only share “a letter,” or asks you to trust the badge on their footer, keep asking.
The auditor must be a licensed CPA firm; SOC 2 is an AICPA framework. Look up the firm. A signed opinion from a legitimate CPA firm is a different artefact from a SOC 2 “readiness assessment” issued by a consultancy that is not a CPA firm.
Type II is an annual rhythm. A report from three years ago is history, not assurance. Ask when the current audit window ends and when the next report is expected.
An unqualified opinion is clean. A qualified opinion means the auditor found something material. Neither is automatically disqualifying — what matters is what the exceptions were and whether they were remediated. Ask for the exceptions section specifically.
An MSP's own audit does not attest to their subprocessors' controls. Ask what platforms hold your data on the MSP's behalf (EDR, RMM, backup platform, cloud tenant) and whether the MSP reviews those providers' SOC 2 reports at least annually. The answer should be yes, and the reviewer should be a named role.
SOC 2 (System and Organization Controls 2) is a reporting framework maintained by the American Institute of Certified Public Accountants (AICPA). It evaluates a service organisation's controls against five Trust Services Criteria: security, availability, processing integrity, confidentiality and privacy. A qualified CPA firm has to audit the organisation and issue a signed opinion.
Type I attests that controls were designed appropriately at a single point in time. Type II attests that those controls actually operated as designed across a defined period, usually six to twelve months. Type II is the stronger assurance and the one buyers should ask for.
From the decision to a signed Type II report, plan for twelve to eighteen months. Most of that is not the audit itself — it is formalising policies, deploying evidence-producing tooling, and running the controls in production long enough for the auditor to sample them.
No. SOC 2 is an American attestation framework produced by the AICPA. ISO 27001 is an international certification standard maintained by the ISO. They overlap heavily in control content — an organisation with strong ISO 27001 processes is well-positioned for SOC 2 — but they are separate reports issued by different bodies. Most North American buyers ask for SOC 2; many European buyers ask for ISO 27001.
Annually is standard. Ask for the current period's report during procurement and again at every renewal. If your own clients or insurers ask you to evidence supplier controls, you need the current report on file.
SOC 1 examines controls relevant to a client's financial reporting. SOC 2 examines security, availability, processing integrity, confidentiality and privacy — the general trust criteria most technology buyers care about. SOC 3 is a public summary version of a SOC 2 that can be posted on a website. For an MSP, SOC 2 Type II is the standard buyers ask for.
For most Canadian mid-market buyers, yes — sharing a current Type II report often replaces or dramatically shortens the vendor security questionnaire. Regulated verticals and enterprise customers may still require questionnaires, but the SOC 2 speeds every conversation.
Yes. NetFusion Designs holds a current SOC 2 Type II attestation covering the security, availability and confidentiality Trust Services Criteria. The report is available to clients and prospects under NDA. Ask us and we will share it.
SOC 2 is not a substitute for PIPEDA or Law 25 compliance — those are legal obligations. But a SOC 2 report with Privacy in scope evidences that the provider has documented controls for how personal information is collected, used, retained and disposed. For Quebec businesses in particular, an MSP with Privacy in the SOC 2 scope is materially easier to accept under Law 25.
Available under NDA. Send us your name, work email and business — we reply within one business day, and if you are just doing due diligence rather than actively buying, that is fine to say too.
We will reply within one business day. If a managed agreement is not the right fit for where you are, we will say so.
We respect your privacy. We will not send you marketing you did not ask for.
%20(1).avif){kind=logo}
%201.avif)
