Skip to content
Office: (416) 621-6611
Emergency: (855) 561-4675
info@balanced.plus
Submit Support Ticket

Month: September 2026

Why User Offboarding Doesn’t End When an Employee Leaves

Posted on by Artemy

Disabling a user account is often treated as the last step in an employee’s departure. It is really the first. Effective offboarding keeps going after the account goes dark, through Active Directory reviews, licence checks, and access audits that catch what the original checklist missed.

This article covers what a complete offboarding process looks like, why the work continues long after someone’s last day, and how regular audits keep an environment organized and accurate.

Offboarding does not end when an account is disabled because accounts, licences, group memberships, and mailboxes all outlive the person they were created for. A user can be blocked from signing in while their Microsoft 365 licence stays assigned, their mailbox stays live with no owner, and their security group memberships stay in place. Regular Active Directory and Microsoft 365 audits are what catch those leftovers and turn offboarding from a one-day task into a maintained process.

Disabling the account is step one, not the finish line. The environments that stay clean are the ones where account reviews, licence checks, and group audits happen on a schedule, not during an occasional cleanup project.

User offboarding

User offboarding is the full set of IT tasks that follow an employee’s departure: disabling accounts, blocking sign-in, reclaiming or reassigning licences, reviewing group memberships, handling the mailbox, updating distribution lists, recovering devices, and documenting all of it. It also includes the ongoing reviews that confirm each of those steps actually stuck.

Why does user offboarding matter?

Every organization has departures. Retirements, role changes, contract endings, and resignations all land on IT, and IT decides whether the transition is clean or whether it leaves debris behind.

Offboarding is much more than removing access. Email accounts, licences, shared resources, group memberships, and company devices all need to be reviewed and handled.

Without a consistent process, organizations accumulate inactive accounts, outdated permissions, and unused resources. None of it breaks anything on the day it happens, which is exactly why it builds up. A year later, nobody can tell which accounts are real.

What happens when an employee leaves?

Most IT teams work from a checklist. Depending on the organization, the common tasks are:

  • Disabling Active Directory and Microsoft 365 accounts
  • Blocking sign-in access
  • Removing or reassigning software licences
  • Reviewing security group memberships
  • Managing email and mailbox access
  • Updating distribution lists
  • Securing company-owned devices
  • Documenting what was done

These steps protect business continuity and close off access to company systems. For the mechanics of the Microsoft 365 side, we walk through it step by step in how to decommission accounts in Microsoft 365.

For most organizations, though, that checklist is only the first phase.

Why doesn’t offboarding end with disabling an account?

In an ideal environment, every account, permission, and licence would be handled the day someone leaves. In practice, organizations are always changing, and details get missed.

An account gets disabled correctly, but the licence stays assigned. A mailbox is still sitting there months later with no owner. A security group still lists members who no longer need access.

As environments grow, these small gaps get harder to spot without a periodic review. That is why many IT teams run Active Directory and Microsoft 365 audits on a set cadence. The audits confirm the offboarding steps were completed and surface anything that needs a second look.

Important:

The point of an audit is not to delete things. It is to understand what exists, decide whether it is still needed, and make sure it is being managed by someone.

How do Active Directory audits uncover forgotten accounts?

Active Directory is the central record of who is who for most organizations. Over time it collects entries as people join, leave, transfer between departments, and come in for short projects.

A regular audit surfaces:

  • Inactive user accounts
  • Disabled accounts that need a decision
  • Duplicate user records
  • Test accounts nobody removed
  • Legacy service accounts
  • Outdated department information
  • Inaccurate contact details

Most of these started as legitimate business needs. They just stayed in the environment long after the reason for them expired.

Reviewing account activity and status on a schedule keeps the directory cleaner and the data more accurate. On the Microsoft 365 side, Entra ID reports on inactive user accounts using last sign-in activity, which gives you a defensible starting list rather than guesswork. A well-maintained directory also makes troubleshooting easier, because administrators can trust what they are looking at.

Why should Microsoft 365 licences be reviewed?

Licensing is one of the most common findings in an audit, and the easiest one to put a dollar figure on.

Licences get assigned during onboarding. They do not always come off when they are no longer needed. Staffing changes, role transitions, and short-term projects all leave assignments behind.

Common examples:

  • Departed employees who still hold an assigned licence
  • Duplicate user accounts, each with its own licence
  • Temporary project users
  • Accounts sitting on premium licensing they no longer need

Reviewing assignments lets you reclaim unused licences, cut unnecessary cost, see what you are actually paying for, and simplify the next round of onboarding. In many cases the licences recovered in an audit cover the next few hires, so no new purchase is needed at all.

Run the licence review a week or two before your renewal date, not after. Seat counts are easiest to adjust at renewal, and a review done at the wrong point in the term means you keep paying for what you just found.

What else should IT teams look for?

User accounts and licensing are only part of a healthy environment. A complete review also covers the shared resources that quietly outlive their owners.

Security groups

People change roles, departments, and responsibilities. Reviewing group membership keeps access lined up with what someone actually does today, rather than what they did three roles ago.

Shared mailboxes

Shared mailboxes routinely outlive the person who set them up. A periodic review confirms the mailbox is still needed and that the right people have access to it.

Distribution lists

Outdated distribution lists cause missed communication and confusion. Verifying membership is a small job that prevents a lot of small problems.

Service accounts

Applications rely on service accounts for automated tasks and integrations. Auditing them keeps each one documented, owned, and still necessary.

User information

Accurate job titles, departments, contact details, and manager assignments make reporting, administration, and day to day user management work properly across the organization.

How do you build a repeatable offboarding process?

The environments that stay clean do not rely on occasional cleanup projects. They fold the review into normal IT operations, so the work is small and constant instead of large and rare.

Document the checklist: Write the offboarding steps down and use the same list every time, so completion does not depend on who handled it.

Review inactive accounts on a schedule: Pull accounts with no recent sign-in activity and decide on each one rather than leaving them in place by default.

Audit licence assignments: Match assigned licences against active users, and time the review to your renewal date.

Validate group memberships: Confirm security groups reflect current roles, not historical ones.

Confirm shared mailbox ownership: Every shared mailbox and distribution list should have a named owner who still works there.

Keep user records current: Update titles, departments, and manager assignments as organizational changes happen, not once a year.

Document as you go: Record what was reviewed and what was decided, so the next audit starts from a known position.

Small, consistent reviews beat large cleanup efforts run every few years. When maintenance is routine, issues get caught while they are still minor.

The bottom line

User offboarding does not end when an employee leaves. Disabling the account is an important first step, but keeping a healthy environment takes ongoing review and verification.

Active Directory audits, Microsoft 365 licence reviews, and access checks surface inactive accounts, reclaim unused resources, and keep user information accurate. That makes administration simpler and the environment easier to work in for everyone.

Key takeaways

  • Effective offboarding goes well beyond disabling user accounts.
  • Active Directory audits surface inactive and outdated accounts.
  • Microsoft 365 licence reviews recover unused seats and cut cost.
  • Security groups, shared mailboxes, and distribution lists need regular review.
  • Ongoing maintenance keeps environments organized, accurate, and easier to manage.

For IT support teams, this kind of proactive maintenance happens quietly in the background. It is also one of the most valuable things you can do to keep systems running smoothly as an organization grows. If account and licence hygiene keeps slipping down your list, our Microsoft 365 management and identity and access management teams run these reviews as part of ongoing service. Get in touch if you want a second set of eyes on your directory.

Sources

SOC 2 Compliance: A Canadian Business Guide

Posted on by Paul Thresher

The request almost never arrives as a strategy decision. It arrives as a line in a contract. An enterprise customer, a bank, or a US buyer sends over a vendor security questionnaire, and somewhere in it is a sentence asking for your current SOC 2 report. Suddenly a compliance framework you had never budgeted for is standing between you and a signed deal.

This guide covers what SOC 2 actually is, what it costs and takes in Canada, what your managed IT provider can carry versus what stays on your desk, and how to tell whether you are ready to call an auditor.

SOC 2 compliance means an independent CPA firm has examined your company’s controls over customer data and issued a report on whether those controls are designed properly (Type I) and operating effectively over time (Type II). It is not a certification and there is no pass mark. It is an audit opinion, valid for the period it covers, built around five trust services criteria set by the AICPA. Most Canadian mid-market companies pursue it because a customer contract requires it, not because a regulator does.

SOC 2 is a customer-driven audit, not a legal requirement in Canada. Budget 6 to 12 months and CAD $40,000 to $120,000 all-in for a first Type II, expect roughly 70 percent of the work to be evidence and process rather than technology, and start by scoping which of the five trust services criteria your contract actually demands.

SOC 2

SOC 2 (System and Organization Controls 2) is an attestation report in which an independent CPA firm examines a service organization’s controls relevant to security, availability, processing integrity, confidentiality, and privacy. The framework is maintained by the American Institute of Certified Public Accountants and is also published for Canadian practitioners by CPA Canada.

What is SOC 2 compliance, and who actually needs it?

You need SOC 2 when another company’s procurement process says you do. It is a business-to-business trust document: your customers hand your report to their own auditors as evidence that outsourcing work to you did not weaken their control environment. No Canadian statute requires it, and no privacy commissioner will ask for it.

In the GTA, the companies that get pulled into SOC 2 tend to fall into a narrow set: SaaS and fintech vendors selling into banks and insurers, payroll and HR platforms, healthcare technology firms holding patient data, and managed service providers like us. If you host, process, or can access someone else’s data, you are a service organization, and eventually someone will ask.

The mistake we see repeatedly is treating SOC 2 as a security project. It is an evidence project. The controls themselves are usually things a competent IT team already does. What kills timelines is that nobody was writing down that they did them.

Good to know:

SOC 2 sits alongside, not instead of, your privacy obligations. PIPEDA still requires you to report qualifying breaches to the Office of the Privacy Commissioner and to keep a record of every breach for 24 months, whether or not you hold a SOC 2 report.

SOC 2 Type I vs Type II: what is the difference?

Type I asks whether your controls are designed correctly on a single date. Type II asks whether they actually ran as described across a window of time, usually 3 to 12 months. Type I is a snapshot; Type II is a video. Almost every customer that matters wants the video.

Type I is still useful as a staging step. It gets a document into a stalled sales cycle within a few months and forces you to finish your control descriptions before the observation window starts. The trap is stopping there. A Type I on its own tells a buyer that you wrote good policies once.

FactorType IType II
What it testsControl design at a point in timeControl design plus operating effectiveness over a period
Period coveredOne date3 to 12 months of observation
Typical time to report2 to 4 months9 to 15 months for a first report
Evidence burdenPolicies, diagrams, configuration screenshotsEvery ticket, access review, and change record across the window
Accepted by enterprise buyersSometimes, as an interimYes, this is the default ask
Relative costRoughly 40 to 60 percent of a Type IIBaseline

What are the five trust services criteria?

SOC 2 is built on five trust services criteria: security, availability, processing integrity, confidentiality, and privacy. Security is mandatory in every SOC 2 engagement. The other four are optional and you include them only when the service you sell and the data you hold make them relevant.

  • Security (required): Protection against unauthorized access, both logical and physical. This is the common criteria set that everything else builds on.
  • Availability: The system is available for operation and use as committed. Include it if you sell an uptime commitment.
  • Processing integrity: Processing is complete, valid, accurate, timely, and authorized. Relevant to payments, payroll, billing, and transaction platforms.
  • Confidentiality: Information designated as confidential is protected and disposed of properly. Common where clients share IP or contract data.
  • Privacy: Personal information is collected, used, retained, and disclosed in line with your stated commitments. The heaviest add-on, and the one most companies over-scope.

Before you agree to a scope, read the actual contract clause that triggered this. Nine times out of ten it says “SOC 2 Type II” with no criteria named, which means security alone satisfies it. Adding privacy and processing integrity because they sound thorough can add months and tens of thousands of dollars to an audit nobody asked for.

Is SOC 2 the same as CSAE 3416?

No, and this is the single most common point of confusion in Canadian procurement. CSAE 3416 is the Canadian standard for reporting on controls at a service organization that are relevant to a customer’s internal control over financial reporting. That is a SOC 1 engagement. SOC 2 covers security and the other trust services criteria, which is a different question entirely.

We have watched a Canadian client spend six weeks and a five-figure quote chasing a CSAE 3416 report because a customer’s legal team wrote “Canadian equivalent of SOC 2” into a contract. There is no such thing. The customer wanted assurance about data security, which is SOC 2. A Canadian CPA firm can issue a SOC 2 report, and CPA Canada publishes its own SOC 2 guide for practitioners. You do not need a US auditor.

Warning:

If a contract asks for CSAE 3416 or SOC 1 but the underlying concern is data breaches rather than financial statement accuracy, get it corrected in writing before you engage an auditor. A SOC 1 report will not answer a security questionnaire, and you will pay twice.

What does SOC 2 cost in Canada, and how long does it take?

For a Canadian mid-market company of roughly 50 to 200 staff, a first SOC 2 Type II lands somewhere between CAD $40,000 and $120,000 all-in, spread across the auditor’s fee, compliance tooling, readiness work, and internal staff time. Annual maintenance after that typically runs 40 to 60 percent of year one. The audit fee alone is the smaller half of the number.

$20K to $60K

Typical fee range for the SOC 2 Type II audit engagement itself, before readiness, tooling, or internal time (Drata, SOC 2 audit cost analysis, 2026)

The cost driver most companies underestimate is not the auditor. It is the readiness phase. Firm size matters too: a compliance-focused specialist firm will quote a fraction of what a Big Four practice charges for the same scope, and for a first SOC 2 the specialist is almost always the right call.

PhaseTypical durationWhere the money goes
Scoping and gap assessment4 to 6 weeksConsultant or MSP time, control mapping
Remediation2 to 5 monthsTooling, MFA and logging rollout, policy writing, staff hours
Observation window (Type II)3 to 12 monthsOngoing evidence collection, monitoring platform licences
Fieldwork and reporting4 to 8 weeksCPA firm audit fee
Annual renewalContinuousAuditor fee plus maintained evidence

A realistic first-time end-to-end timeline is 9 to 15 months if you start from a normal, uncertified IT environment. Companies that already run centralized identity, endpoint monitoring, and ticketed change management can compress that toward the low end. Companies still running shared admin accounts and email-based approvals cannot.

What does your MSP handle, and what stays with you?

A managed provider can carry the technical control layer and most of the recurring evidence generation. It cannot carry your governance, your HR processes, or the decisions only your leadership can make. Assuming otherwise is how companies arrive at fieldwork with a hardened network and no risk assessment.

Control areaMSP can ownStays with you
Access managementMFA enforcement, privileged access tooling, quarterly access review exportsApproving who should have access, and signing the review
Monitoring and loggingSIEM, alerting, 24/7 SOC coverage, log retentionDefining what counts as a security incident for your business
Change managementTicketing workflow, approval gates, change recordsChange advisory decisions and release sign-off
Vulnerability managementScanning, patch cycles, remediation reportingAccepting residual risk on what cannot be patched
Backup and recoveryBackup execution, restore testing, evidence of testsRecovery time and recovery point targets
Policies and proceduresDrafting technical policies against the criteriaFormal approval, publication, and enforcement
HR controlsProvisioning and deprovisioning executionBackground checks, onboarding, security awareness completion
Risk assessment and vendor managementInput on technical riskOwning the annual risk assessment and vendor reviews

We took our own security operations centre through SOC 2, so the evidence burden here is not theoretical for us. The controls were the easy part. What took discipline was the boring monthly rhythm: pulling access review exports on schedule, closing tickets with enough detail to be evidence later, and keeping the offboarding checklist honest. The gap in almost every readiness assessment we run is offboarding, not the firewall.

If you want the operational side handled while your leadership keeps the governance, that is the shape of our IT compliance services, backed by managed SIEM for the logging and monitoring criteria and policy and procedure development for the written control set.

How do you know if you are ready to call an auditor?

You are ready when you can produce evidence for the last 90 days without asking anyone to reconstruct it from memory. Run this checklist before you spend money on fieldwork. If you fail more than two of these, you need a readiness phase first, and the auditor will tell you the same thing at a higher hourly rate.

Confirm the actual ask: Get the contract clause in front of you. Type I or Type II, which criteria, and by what date. Scope from the clause, not from a template.

Draw the system boundary: Name every system, environment, and third party inside scope. Anything you cannot draw, you cannot audit.

Prove identity control: MFA on every account including service and admin accounts, no shared logins, and a documented quarterly access review with a name on it.

Test your offboarding: Pick three people who left in the last six months and trace every access removal with a timestamp. This is where most first attempts fail.

Check your logging retention: Confirm you retain security logs across the full observation window and can produce them on request, not just view them in a dashboard.

Complete a written risk assessment: Dated, approved, and covering the systems in scope. Auditors ask for this early and it cannot be backdated.

Show a tested restore: A backup that has never been restored is not a control. Produce a restore test record from the last quarter.

Assign an owner: One accountable person internally, with authority to approve policies. Distributed ownership is the reason SOC 2 projects stall past month six.

Tip:

Start your Type II observation window the month after remediation closes, not the month you decide to pursue SOC 2. Every week of window that runs while controls are still being fixed becomes an exception in the final report.

SOC 2 rewards operational discipline, not spending. The companies that get through a first Type II cleanly are the ones that fixed access reviews, offboarding, logging, and change records before the observation window opened. Scope to the contract, pick a specialist CPA firm, and treat the report as a byproduct of running IT properly rather than a project with an end date.

If a customer contract has put SOC 2 on your roadmap and you are not sure how far you are from ready, a gap assessment is the cheapest possible first step. We run readiness assessments for GTA mid-market companies, map your current state against the criteria in scope, and tell you plainly what has to change before an auditor sees it. Start with our compliance readiness service, or read our broader guide to IT compliance for business leaders if you are still mapping the landscape. Our own security operations centre holds SOC 2, which is why the evidence rhythm is something we can hand you rather than invent.

Sources