Managed M365 Security vs DIY: An Honest Decision Framework

What "DIY M365 security" actually requires

The pitch for DIY is simple: you already pay an IT person, M365 is included in your seats, the documentation is on Microsoft Learn, so why pay outside money? It's a fair question. The answer depends on what's actually involved, not on the marketing.

Securing a Microsoft 365 tenant to a defensible baseline is not a single skill. It's at least five overlapping ones, and the people who do it well usually picked them up over a couple of years of focused work:

• Conditional Access design. Knowing how to scope policies so you block legacy auth and risky sign-ins without locking out the CFO at 6am from her hotel Wi-Fi. There's a real craft to ordering policies, choosing controls (block vs require MFA vs require compliant device), and excluding break-glass accounts safely.
• Intune compliance and device policy. Compliance policies, configuration profiles, app protection, autopilot enrollment, the difference between corporate-owned and BYOD trust paths. Most generalists touch Intune to push a Wi-Fi profile and stop there.
• Defender for Office 365 tuning. Anti-phishing impersonation lists, Safe Links policy scoping, attachment detonation thresholds, the rules around allow-lists that quietly bypass them. The defaults are not tuned. They never are.
• PowerShell for Exchange Online, Microsoft Graph, and Entra. A surprising amount of M365 hardening still lives in PowerShell rather than the GUI. If you can't run a script, you can't audit half the controls you set.
• Audit log forensics. Knowing what to look for in the unified audit log, how to spot a malicious inbox rule, what a token replay looks like, why a sign-in from a "trusted" country is sometimes the worst alert in your queue.

For a 30-person tenant starting from defaults, the honest initial-effort range is 80 to 120 hours. That covers the discovery audit, Conditional Access build and pilot, Intune baseline, Defender tuning, audit log retention work, and the documentation you need afterward, all measured against the controls in the CIS M365 small business checklist. It's not theoretical. It's how long a competent generalist actually takes when the work is done in real-world conditions, around tickets and meetings and the printer that's making weird noises.

Then it's 4 to 8 hours a month to keep it from drifting. Microsoft ships changes constantly. New Conditional Access conditions, new Defender features, new defaults. If nobody owns the review cycle, the baseline you set on Tuesday is a baseline you no longer have by next quarter. The full standalone baseline a 30-person business should run is laid out in secure Microsoft 365 for small business.

What gets missed when one IT generalist runs it part-time

The 80 to 120 hours assumes the person doing the work has the skills above. If they don't, the hours don't shrink; they just produce something that looks finished and isn't.

The pattern we see in tenants that came in for a second-look review after a self-build:

• MFA enabled per-user instead of via Conditional Access, which means one toggled-off account silently weakens the whole control.
• Conditional Access set up but legacy auth never blocked, leaving the IMAP and SMTP-AUTH bypass wide open. Detail on that specific gap and the fix is in the post on how to block legacy authentication in Microsoft 365.
• Defender policies inherited from preset templates without tuning. Impersonation protection list empty. No SafeLinks for Teams.
• Audit log retention left at the 90-day default, which is too short for any serious incident reconstruction.
• No drift monitoring. The tenant is "fine" until someone disables a policy to debug something and forgets to flip it back.

None of that is a knock on internal IT. It's a knock on asking a generalist to do specialist work in 90-minute windows between password resets and printer drivers. The same person who's brilliant at keeping your line-of-business app patched is rarely the same person who's spent 2,000 hours inside Conditional Access. That's not a failing. It's the math of being a one-person IT shop.

What "managed M365 security" actually means

"Managed" is one of the most overloaded words in the IT-services market. The same word covers an MSP that does a one-time deployment and walks away, a co-managed model where they ride alongside your team, and a full outsource where they own everything. Before you can compare it to DIY, you have to know which version is on the table.

A defensibly-scoped M365 security engagement, written as deliverables, looks roughly like this:

• Deployment. A baseline build against a named standard (CIS M365 Foundations Benchmark, the Microsoft Secure Score recommendations, a custom hardening list, or a combination). With a documented configuration register that says exactly what was set and why.
• Ongoing monitoring. Named alert criteria, not vague "we watch your tenant." Things like: alert if Conditional Access policy is disabled, alert if a global admin role is assigned, alert if an inbox forwarding rule is created with an external destination.
• Drift detection. Scheduled checks (weekly or monthly) that compare current tenant state to the agreed baseline and flag deviations. Not just dashboards; actual diffs.
• Incident response. A defined response on what happens when something fires. Who calls whom, what the first 60 minutes look like, what the customer is expected to do.
• Quarterly review. A scheduled session where the configuration is checked against the latest Microsoft changes, new threats, and any business changes on the customer side. New hires, departed admins, new offices, new line-of-business apps.

What's typically not included, and you want to know going in:

• Helpdesk. Password resets, mailbox-permission changes, user setup. That's IT support, not security.
• License management. Buying, assigning, and reconciling M365 licenses sits with whoever owns the Microsoft commercial relationship.
• End-user training. Phishing simulations are sometimes bundled, but real awareness programs are usually their own line item.
• Non-M365 controls. Network firewalls, endpoint EDR, the rest of your stack. A managed M365 service owns the tenant; not your whole security posture.

When you read a managed-service proposal, look for those five deliverables and those four exclusions to be written in. If they're not, you're either looking at a half-defined scope or at a retainer that's mostly hours on a clock.

When DIY actually makes sense

DIY is the right call more often than the managed-services industry would have you believe. The honest set of conditions:

• You have a named internal IT lead with recent M365 administrator certification or equivalent practical experience. Not "they manage Microsoft stuff." Specifically: they've configured Conditional Access in another tenant, they can write a Graph script, they read the Microsoft message center.
• You're in a non-regulated industry. No HIPAA, no PCI in scope, no SOC 2 audit on the calendar, no cyber insurance carrier sending a 40-question security questionnaire.
• Your risk profile is genuinely low. Small dollar amounts moving through email, no sensitive client data in OneDrive, no attractive industry vertical.
• The owner is willing to absorb a learning curve and accept that the first version of the baseline will not be the last.
• There's enough slack in the IT person's calendar to actually carve out the 80 to 120 hours. If they're already at 95 percent capacity, "find time" is not a plan.

If those five are true, run it yourself. The Microsoft documentation is good, the CIS Benchmark is free, and the controls are not exotic. You'll learn a tenant deeply, and the institutional knowledge stays in the building.

Where managed earns its fee

The conditions flip. Managed is the right call when:

• You're in a regulated industry, or your customers' contracts impose security obligations you have to evidence in writing.
• You don't have a named M365 specialist internally. Your "IT person" is a generalist, your CFO is the de facto IT lead, or you outsource break-fix to an MSP who doesn't do security.
• Your timeline is driven by an audit, an insurance renewal, or a contractual obligation. You don't have 12 weeks to learn Conditional Access from scratch when the carrier wants proof in 30 days.
• The business is multi-site or multi-tenant, which multiplies the configuration surface. Two M365 tenants is more than twice the work of one.
• You've already had a near-miss or a small incident and the next one will be the one that ends up in regulatory reporting. The cost of the second event makes the cost of managed look small.

Insurance is the most common forcing function. Carriers ask for evidence of MFA, evidence of email security controls, and evidence of access reviews. If you can't produce that on a 5-business-day turnaround, you find out fast that the documentation half of the work is most of the work. The link between specific controls and what underwriters expect is in this case study on a cyber insurance implementation.

When neither pure DIY nor pure managed works

A lot of 30 to 100-person businesses sit in the middle. They have an IT person who's competent and engaged, but not a full-time security specialist. They have audit pressure, but not enough to justify a $4,000-a-month retainer. They have institutional knowledge they don't want to give up, but they also don't want their one IT person to be a single point of failure.

The hybrid that works for most of them: managed deployment plus quarterly review, internal monitoring and first-response in between.

What that looks like in practice. The managed engagement does the initial baseline build, produces the documentation, and trains the internal IT person on the configuration. After that, the internal team handles monitoring (because the alerts come to their inbox first, where they can be triaged in context) and first-response. Every 90 days, the managed team comes back, does a fresh audit against the baseline, and produces a delta report. New Microsoft features get evaluated, drift gets corrected, and the documentation gets updated.

That model gives you specialist depth at the moments specialism actually matters (the build, and the cyclical review) and keeps the day-to-day in the hands of the people who know your business. It also caps the spend, because the quarterly engagement is bounded scope rather than open-ended retainer time.

How the hybrid fails (and how to avoid that)

The hybrid pattern has two reliable failure modes. Both are avoidable.

Failure one: handoff that never happens. The managed team finishes the deployment, hands over a 60-page document, and the internal team never reads it. Three months later, a Conditional Access policy fires and locks out a VP, and nobody internal can debug it because they were never trained on the configuration. The fix is to require a working session at the end of the deployment where the internal admin reproduces three or four common operations against the documented baseline. If they can do them, the handoff happened. If they can't, schedule another session before sign-off.

Failure two: drift between reviews. The 90-day cadence is long enough that a meaningful misconfiguration can land and sit. Someone disables a policy "for an hour" to fix a Teams issue, gets pulled into another meeting, never re-enables it. Two months go by. The fix is automated drift detection running between reviews, with alerts wired to a channel both teams watch. Even a simple weekly script that compares Conditional Access state to the baseline closes most of this gap.

The real cost comparison for a 30-person business

The "DIY is free" myth is durable because the costs don't show up on a single invoice. They show up as IT-person time the business already pays for, which is treated as if it had no opportunity cost. It does.

Honest math, with a senior IT generalist's loaded cost (salary, taxes, benefits, software, overhead) at $100 to $150 an hour:

• DIY initial build: 80 to 120 hours at $100 to $150 = $8,000 to $18,000 in loaded labor cost.
• DIY ongoing: 4 to 8 hours per month at the same rate = $400 to $1,200 per month, or roughly $4,800 to $14,400 per year.
• Managed deployment (flat fee): Typically $5,000 to $15,000 for an initial baseline against a named standard, with documentation and a 30-day support tail.
• Managed monitoring (optional ongoing): Typically $300 to $1,200 per month for the monitoring, drift detection, and quarterly review pattern.

Two things jump out when you put those numbers next to each other. First, the cost ranges overlap substantially. DIY at the high end is more expensive than managed at the low end, and vice versa. The honest answer to "which is cheaper" is "depends on which end of each range your situation actually sits at." Second, neither is free. A 30-person business should plan to spend somewhere between $10,000 and $30,000 in the first year on M365 security regardless of approach. That's the real number.

The decision is rarely "save money by going DIY." It's "where do I want my money going: into salaried hours that build internal knowledge, or into a fixed-scope engagement that delivers documentation faster?" Both are legitimate answers. They produce different organizations.

The 5 things DIY rollouts most commonly skip

Across the tenants we've reviewed after a self-build, the same five gaps come up. Each is the difference between "good on paper" and "actually defended."

1. Drift detection. The baseline gets set on day one and then degrades silently. There's no scheduled check that compares current state to the documented baseline, so the first time anyone notices a policy is off is during the next incident or audit. A 20-line PowerShell script run weekly closes most of this — the M365 quarterly drift-check playbook walks through the queries and the 90-minute review that catches it.

2. Named admin separation. Day-to-day admin work is being done from the same account that holds Global Admin. Best practice (and the cyber insurance expectation) is two accounts per privileged user: one normal-rights for daily work, one elevated for admin tasks, with PIM activation on the elevated one.

3. Audit log retention beyond the default. The 90-day default is usually too short. By the time most incidents are spotted, the activity that matters is older than 90 days. A 1-year retention bump (free in most E5 SKUs, paid in E3) is one toggle and a meaningful upgrade in your forensic capability.

4. Sensitivity-label rollout. Information-protection labels for SharePoint and Teams content are some of the highest-value controls in M365, and almost nobody enables them in a self-build because the rollout requires a content-classification conversation that's outside the comfort zone of pure infrastructure IT.

5. Incident-response tabletop. The plan exists as a Word doc nobody has rehearsed. The first time the team works through "user reports their account is hijacked, what do we do in the next 60 minutes" is during the actual event. A two-hour tabletop once a year is one of the highest-leverage time investments in security and gets skipped almost universally in DIY shops. There's relevant context on how email-driven incidents play out in this BEC prevention case study.

A drift check a managed service would catch

Concrete example. One of the most common silent-drift events is a Conditional Access policy getting flipped from "On" to "Report-only" or "Off" during a debugging session and not flipped back. A weekly script that lists every CA policy, its state, and when it was last modified takes care of this.

Connect-MgGraph -Scopes "Policy.Read.All"

$cutoff = (Get-Date).AddDays(-7)

Get-MgIdentityConditionalAccessPolicy |
  Select-Object DisplayName, State, ModifiedDateTime |
  Where-Object {
    $_.State -ne "enabled" -or
    $_.ModifiedDateTime -gt $cutoff
  } |
  Sort-Object ModifiedDateTime -Descending |
  Format-Table -AutoSize

Run that weekly. Anything in the output is either a policy that's not currently enforcing (state isn't "enabled") or a policy somebody touched in the last seven days. Both are worth a 30-second look. A managed service runs this kind of check (or its equivalent) by default and tells you when it fires. A DIY shop adds it to the maintenance backlog and gets to it eventually.

What "good managed" looks like, and what "bad managed" looks like

Once you've decided managed is the right call (or part of the right call), the next question is who. The market is uneven. Some red flags and green flags:

Green flags:

• The proposal is written as deliverables, not as retainer hours. "We will configure these 38 controls and produce this documentation" beats "We will provide 20 hours of consulting per month."
• Monitoring scope lists named alert criteria. You can read the proposal and predict what would trigger an alert.
• The configuration is documented in a register that's transferable. If you fire them next year, you can hand the register to the next provider.
• There's a clear deprovisioning path. Removing the provider's access at the end of the engagement is documented and tested.
• No proprietary lock-in. The controls are standard M365 features, not the provider's bespoke tooling layered on top.

Red flags:

• Scope is "managed M365 security" with no list of what that includes.
• Pricing is per-user with no clear deliverables tied to the per-user fee.
• Monitoring is described in marketing words ("24x7 SOC visibility") without naming what gets watched and what triggers alerts.
• The provider wants Global Admin permanently rather than time-bound elevated access via PIM.
• Documentation isn't included in the deliverables, or it's described as "ongoing" rather than produced as an artifact.
• Exit terms are vague. If you ask "what happens to the configuration if we leave," the answer is hand-wavey.

A surprising number of mid-market managed-services proposals fail half the green-flag list. That's not a reason to give up on managed; it's a reason to read the proposal carefully and ask for the specifics in writing.

A simple decision frame

If you want one short test rather than a matrix, this one works for most 30-person businesses:

1. Do you have an in-house person who can name three Conditional Access conditions off the top of their head and has time this quarter to do the work? If yes, DIY is genuinely viable.
2. Is there an audit, insurance renewal, or contractual deadline within 90 days? If yes, managed (or at minimum a managed deployment with internal handoff afterward) is almost certainly the right call.
3. If you went DIY, who would notice a Conditional Access policy getting disabled at 4pm on a Friday? If the honest answer is "nobody until Monday," you need either drift monitoring you can rely on, or a managed partner that has it built in.

Most decisions land naturally after those three questions. The companies that struggle are the ones that try to make the call by feel, without working through any of them. The ones that pick well usually wrote the answers down. The same plain-English framing that helps with this decision shows up across the rest of the M365 security space — there's a broader version in the M365 security FAQ.

Common questions

Can we start DIY and switch to managed later if it doesn't work?

Yes, and this is actually a reasonable path if your timeline allows it. The cost is that the managed team will spend the first part of their engagement undoing or reworking some of your initial build, which adds hours. To minimize that cost, document everything as you go. Even a rough register ("we set this control on this date, here's why") makes the eventual transition cheaper. The version that goes badly is "we did some stuff a year ago, nobody remembers what." That requires a discovery audit before any real work can start.

If we go managed, what's our internal team's job?

More than people expect. Internal IT owns user lifecycle (onboarding, offboarding, role changes), license assignment, the helpdesk, and first-response triage when an alert fires. They also own the relationship with the business: knowing which users matter most, which apps are critical, which sites are running which workflows. Managed handles the configuration depth and the security expertise; internal handles the context. The engagements that work best are the ones where both halves are explicit.

How do we know if a managed provider is actually doing the work?

Ask for the artifacts, not the dashboards. Monthly drift report. Quarterly configuration review with a delta from the previous quarter. Audit-log search results from the named alert criteria. Specific tickets and how they were handled. A provider doing real work will produce these without prompting. One that's billing for monitoring without monitoring will give you logos and uptime stats. If three months in you're not seeing artifacts, raise it. If six months in you're still not seeing them, switch.

What about co-managed: our IT lead plus an outside specialist as a fractional resource?

That's the hybrid pattern by another name and it works well at the 30 to 100-person scale. The trick is keeping the swim lanes clear. Internal owns the day-to-day; the fractional specialist owns the configuration depth and the formal review cadence. Without clear lanes, both sides assume the other is handling something and gaps open.

Does managed security replace cyber insurance?

No, and the framing is wrong. Insurance covers financial loss after an incident; managed security reduces the likelihood and severity of incidents. They're complementary. In practice, a documented managed-security program also makes the insurance cheaper and the renewal questionnaire faster, because the questionnaire is mostly questions about controls a managed program already evidences in writing.