The Compliance Conversation You’re Avoiding Will Eventually Find You

I had a chat recently with a business owner who runs a tidy operation — about fifteen staff, healthy margins, the sort of place that quietly does well without ever making noise. Halfway through, I asked how they were tracking on privacy and security obligations. The answer was a laugh and a wave of the hand. “Mate, we’re too small for anyone to care about that.”

I’ve heard that line more times than I can count. And I understand why people say it. When you’re flat out keeping the lights on, compliance feels like a problem reserved for the big end of town — banks, hospitals, listed companies with legal departments. The trouble is, that comfortable assumption is quietly expiring, and most small businesses haven’t noticed.

The rules are walking towards you, not away

For years, smaller organisations sat below the threshold of most privacy regulation. That gap is closing. Governments around the world are tightening data protection laws and shrinking the carve-outs that used to let small businesses off the hook. Here in Australia, the conversation about extending privacy obligations to organisations that were previously exempt has been building for a while, and it isn’t going to reverse.

So the question isn’t whether regulation reaches your business. It’s whether you’ll be ready when it does, or scrambling because you assumed it never would.

What strikes me is how avoidable the scramble is. A lot of what compliance asks for is simply knowing what data you hold, where it lives, who can touch it, and what happens if it walks out the door. If you’re running Microsoft 365, you already have the tools to answer those questions. Microsoft Purview can show you where sensitive information sits across your tenant and flag where it’s being shared in ways it shouldn’t be. That’s not a future purchase. For most small businesses, it’s sitting in a licence you already pay for and have never switched on.

Cyber insurance is doing the regulating for now

Here’s the part that catches people off guard. While the laws are still catching up, your insurer has already arrived. The renewal questionnaire for cyber insurance has become a de facto compliance audit, and it’s getting longer every year.

Do you enforce multi-factor authentication? Do you have email filtering? Are backups tested? Who has administrator access? I’ve watched owners stare at these forms with genuine surprise, because nobody warned them that a policy renewal would turn into a security interrogation. And the consequences are real — answer loosely, suffer an incident, and you may find the claim contested because the controls you ticked weren’t actually in place.

This is where I tell people to stop treating the questionnaire as paperwork and start treating it as a checklist worth acting on. Turn on MFA through Entra. Tighten who holds admin rights. Confirm your data is actually backed up, not just assumed to be. None of this is exotic. It’s the same hygiene the regulators will eventually demand, so you may as well do it now while an insurer is the one asking.

Where to start when it feels like too much

The reason this conversation gets avoided is that it feels enormous — like you’d need to stop everything and become a compliance expert overnight. You don’t. You need to start, and starting is smaller than you think.

This is one of those tasks where I’ve found Copilot genuinely useful. Ask it in Word to draft a plain-English data handling policy based on what your business actually does, then refine it. Ask Copilot to summarise the key obligations from a privacy guidance document you’ve been meaning to read for six months. Use it to turn that intimidating insurance questionnaire into a list of specific actions, each owned by someone, tracked in Planner. Suddenly the mountain is a series of steps, and steps are doable.

The point isn’t to achieve perfect compliance by Friday. It’s to be able to show, honestly, that you’ve thought about this and you’re doing something — because “we’re too small to matter” is not a defence that ages well.

The compliance conversation you’re avoiding doesn’t disappear when you ignore it. It just waits, and it tends to introduce itself at the worst possible moment — mid-breach, mid-claim, mid-audit. Far better to have the conversation now, on your own terms, with a coffee in hand and nothing actually on fire. That’s a much nicer way to meet it.

Intune compliance policies + Conditional Access integration

Most people I speak to think the work of locking down devices in Microsoft 365 is creating the Intune compliance policy. They tick the boxes — BitLocker on, minimum OS, no jailbreaks — hit Save, and walk away feeling secure.

They aren’t.

A compliance policy on its own does precisely nothing to a sign-in. It’s a label. Intune looks at a device, decides “compliant” or “not compliant”, and writes that state back to Entra ID. That’s it. Nothing is blocked. Nothing is challenged. The policy is information, not enforcement.

The enforcement lives somewhere else entirely. It lives in Conditional Access.

If you’re not wiring those two things together, you’ve done half a job. And the half you skipped is the half that actually protects the tenant.

What is an Intune compliance policy, really?

Think of a compliance policy as a health check that runs on the device and ships the verdict back to your tenant. Encrypted? Patched? Joined to your tenant? Defender running? Out comes a true/false, and Entra ID writes it onto the device record.

That verdict is now available as a signal. Anything that can read Entra signals — and Conditional Access is the big one — can use it to make access decisions.

So the compliance policy is the sensor. Conditional Access is the gate. You need both, or you have neither.

Step-by-Step: wiring compliance to Conditional Access

Portal only. No PowerShell. This is what I do on every Business Premium tenant I touch.

Fix the tenant default first

Open the Intune admin center, go to Devices > Compliance > Compliance policy settings.

Find the setting Mark devices with no compliance policy assigned as. It ships set to Compliant.

Change it to Not compliant. Save.

That one setting is the difference between “any device in my tenant counts as good” and “a device has to earn it”. You’d be amazed how many tenants I audit where this is still on the default.

Build the compliance policy

Same portal. Devices > Compliance > Policies > Create policy. Pick Windows 10 and later (start there — do iOS and Android next).

Use the settings catalog options to set sensible rules — require BitLocker, a minimum Windows build, Defender real-time protection on, Defender signatures up to date. Don’t try to be heroic on day one. Set what you can defend with a straight face. Microsoft’s own walkthrough is the canonical reference.

In Actions for noncompliance, do not leave the default of “Mark device noncompliant: 0 days”. Give yourself a grace window — 1 to 3 days — and add a Send email to end user action a day earlier. People deserve a heads-up before they’re locked out of email.

Assign to a pilot user group. Not all users. A pilot group.

Build the Conditional Access policy

Now flip over to the Entra admin center: Entra ID > Conditional Access > Policies > New policy.

Users: include your pilot group. Exclude your break-glass account. Always.

Target resources: All resources.

Grant: Require device to be marked as compliant. Save.

And here’s the critical bit — set Enable policy to Report-only. Not On. Report-only.

Users:       Pilot group
Exclude:     Break-glass account
Resources:   All resources
Grant:       Require device to be marked as compliant
Enable:      Report-only

Notice what’s missing? MFA. That belongs in a separate policy. One policy, one job. Stack them, don’t fuse them.

Watch report-only for a week

Sign-in logs > Report-only tab. You’re looking for users who would have been blocked and shouldn’t have been — usually a missing enrollment, a personal device that needs the App Protection path instead, or a service account.

When the report-only data is clean, flip the toggle to On. Microsoft’s compliant-device CA template walks the same path.

Why this actually changes behaviour

“But MFA is already on. Isn’t that enough?”

It isn’t. MFA proves the user. Compliance + CA proves the device. Token theft doesn’t care about your MFA prompt — it cares whether the device the token landed on is one you trust. This is the bit MFA-only tenants are missing.

It also collapses three messy conversations down to one. “Is this laptop ours? Is it patched? Is it encrypted?” All of it rolls into one signal — compliant, or not. Conditional Access reads that one signal and decides. No more inventory spreadsheets. No more guessing.

And if you’re an MSP, this is the most defensible artefact you can show a client during an incident. The device was non-compliant. Access was blocked. That’s a finished sentence.

A compliance policy isn’t there to make a list of bad devices. It’s there to make sure they never sign in.

DLP and Sensitivity Labels for SMBs: A Practical Copilot Readiness Playbook

Most SMB data protection projects fail for one reason: teams optimize the label taxonomy before fixing access control. That creates a “labeled mess” instead of a governed environment. In practical terms, a “Confidential” label cannot compensate for a SharePoint site still shared with broad legacy permissions.

A safer and faster implementation sequence is: Permissions cleanup -> Sensitivity labels -> DLP tuning -> Copilot enablement. This order aligns with real-world Copilot risk patterns, where oversharing is usually the primary exposure pathway.

The Category Error to Avoid

The common debate in SMB projects is “How many labels should we deploy?” (for example, 4 vs 8 vs 12). That is the wrong first question. The first technical question is: “Are current permissions precise enough for labels to have security meaning?”

If broad groups, stale sharing links, and inherited permissions still expose sensitive locations, adding more labels mostly increases administrative overhead and user confusion. Copilot does not create this condition, but it can reveal it quickly by making discoverable content easier to surface through natural language prompts.

Reference Architecture for SMB Tenants

Use a minimal, repeatable baseline that can be implemented and operated by small IT teams.

1. Permissions Layer (Foundational)

Identify and remove broad default access patterns (for example, “Everyone except external users” where inappropriate).
Review high-risk SharePoint and Teams locations first: HR, Finance, Leadership, M&A, Legal, payroll artifacts.
Remove stale members from privileged Microsoft 365 groups and Teams.
Expire or revoke old anonymous or org-wide links where business value no longer exists.
Document approved sharing patterns by site type (departmental, project, external collaboration).

2. Label Layer (Classification)

Start with a compact taxonomy, then expand only with evidence.

Public – content approved for unrestricted internal and external use.
Internal – default business content for internal sharing.
Confidential – restricted business-sensitive data.
Highly Confidential (optional) – strongest controls, often encryption-backed.

Keep label names plain and user-comprehensible. If users cannot predict where a label applies, adoption and accuracy collapse.

3. DLP Layer (Policy Enforcement)

Deploy DLP in audit mode first (recommended: 60 days).
Prioritize high-confidence detections first (payment card data, national identifiers, banking information).
Monitor policy hits weekly and triage false positives with business owners.
Move to staged enforcement with user notifications before hard blocking where possible.

4. Copilot Layer (Consumption)

Enable Copilot only after oversharing findings are remediated to an agreed threshold. Treat Copilot enablement as a controlled release with explicit go/no-go criteria, not a licensing event.

Why Copilot Changes the Risk Visibility Model

Traditional oversharing could remain hidden for years because users had to know exactly where to look. Copilot lowers search friction by translating intent into broad retrieval across accessible content. This can expose latent permission mistakes quickly.

Oversharing is best treated as an access-control debt problem, not a labeling deficiency.

In practical operations, Copilot acts like a continuous discovery mechanism for permissions debt. If the tenant is clean, Copilot is productive. If not, Copilot surfaces the debt immediately.

60-Day Implementation Runbook

Phase 0 (Week 0): Scope and Governance

Define data protection owner, security owner, and business escalation path.
Agree target controls and business exceptions process.
Set Copilot readiness criteria before technical work begins.

Phase 1 (Weeks 1-2): Permissions Remediation

Run oversharing assessment on SharePoint and Teams-connected sites.
Rank findings by impact: executive, financial, personal data, contractual data.
Remediate critical sites first and verify effective permissions after each change.
Capture exception approvals where broad sharing must remain.

Phase 2 (Weeks 2-3): Label Deployment

Publish 3-4 labels to a pilot user group.
Validate user understanding with short examples and FAQ guidance.
Adjust label descriptions and policy tooltips based on pilot confusion points.

Phase 3 (Weeks 3-8): DLP Audit Mode

Enable DLP in monitor-only mode.
Collect incidents and tune detection thresholds/rules weekly.
Present day-30 report to stakeholders with false-positive and true-positive analysis.
Issue day-45 enforcement impact notice to users and managers.

Phase 4 (Week 9+): Staged Enforcement and Copilot Rollout

Turn on enforcement for highest-confidence policies first.
Enable Copilot for low-risk pilot cohort.
Review user prompts/incidents for unintended access outcomes.
Expand rollout only when no critical oversharing regressions are detected.

Operational Metrics That Matter

Track leading indicators, not just policy counts.

Permissions hygiene: number of high-risk overshared sites before vs after remediation.
Classification adoption: percentage of newly created docs with valid user-applied labels.
DLP quality: true-positive to false-positive ratio per policy.
Readiness confidence: unresolved critical findings at Copilot go-live.
User impact: helpdesk tickets per 100 users post-enforcement.

Common Failure Modes and Corrective Actions

Failure Mode 1: Label Proliferation

Symptom: taxonomy grows to 8-40 labels with low usage consistency.
Correction: reduce to behaviorally distinct labels users can apply accurately.

Failure Mode 2: Permanent Audit Mode

Symptom: policies remain non-enforcing for months or years.
Correction: define enforcement date at project kickoff and publish milestone reports.

Failure Mode 3: Copilot Before Cleanup

Symptom: sensitive content appears in valid-but-unexpected prompt responses.
Correction: block rollout until critical permissions findings are remediated and re-tested.

Practical MSP Packaging

The most successful SMB engagements package this work as Copilot Readiness and Data Access Hardening, not as a one-time “label deployment” project.

Deliverable 1: Oversharing assessment and remediation log
Deliverable 2: Compact label taxonomy and end-user guidance
Deliverable 3: DLP audit report at day 30 and day 60
Deliverable 4: Copilot go-live risk sign-off
Deliverable 5: Quarterly policy and permissions review cadence

Key Data Points to Use with Clients

Purview Suite for Business Premium add-on was announced at $10/user/month (September 2025).
Combined Defender + Purview Suites for Business Premium add-on was listed at $15/user/month.
Working SMB implementations commonly succeed with 3-4 labels, not large taxonomies.
A 60-day DLP audit window is a common practical baseline before enforcement.
Published incidents show that Copilot oversharing exposure typically traces back to legacy permissions.

Conclusion

For SMB tenants, the winning strategy is not maximum policy complexity. It is disciplined sequencing and operational follow-through. Start with permissions. Add a minimal label model. Run DLP in time-boxed audit mode. Enforce in stages. Then enable Copilot.

If you remember one line, use this: Clean access first, classify second, enforce third, accelerate last.

DSPM: The End of Guessing About Your Sensitive Data

Most Microsoft 365 tenants I walk into are flying blind on data.

The sensitivity labels exist. A couple of DLP policies exist. Someone once turned on Insider Risk Management because a consultant said so. And then nothing. Nobody knows what’s working, what’s exposed, or which sensitive files are sitting wide open in a SharePoint site shared with half the planet.

That’s not a security posture. That’s a guess.

The tool that finally ends the guessing is Microsoft Purview Data Security Posture Management. If you’ve got E5 or the Purview Suite and you’re not showing this to your clients, you’re leaving value on the table.

What is DSPM, really?

DSPM is the dashboard that tells you, in plain English, where your sensitive data is sitting unprotected and which users are handling it carelessly. It pulls signals from the tools you already pay for — DLP, Information Protection, Insider Risk Management, Adaptive Protection — and stitches them into one view.

The clever bit is the correlation. Before DSPM, you’d open five different blades, cross-reference three different reports, and still miss half of it. Now the findings and recommendations land on one page, with a one-click path to spin up the matching policy.

That’s not a report. That’s a to-do list with context.

Step-by-Step: turning DSPM on

Portal only. Stay in the GUI — easier for you, easier to hand off to the next admin.

Open the Purview portal

Sign in to the Microsoft Purview portal as a member of the Data Security Management role group, an Insider Risk Admin, or a Compliance Administrator. Global Admin works too, but please don’t use it if you can help it.

Open the DSPM solution

From the home page, go to Solutions → Data Security Posture Management → Overview.

Turn on analytics

On the Overview page, click Turn on analytics. That one switch also enables DLP analytics and Insider Risk analytics behind the scenes if they aren’t already on. One click, three switches. The full checklist is in the Get started with DSPM article.

Wait

Yes, really. The automated scan across your tenant can take up to three days on anything larger than a handful of users. Walk away. Brew a coffee. Come back on Thursday.

Review the recommendations

Back on the DSPM dashboard, open Recommendations. Each one tells you what was found, why it matters, and offers a one-click path to create the DLP or Insider Risk policy that fixes it. You don’t start from a blank policy screen anymore — you start from your tenant’s real gaps.

Track trends over time

Use the Analytics and Reports tabs in client reviews. A trend line of risky activity going down beats any invoice justification I’ve ever tried to write.

Why this actually changes behaviour

“Are we protected?”

That’s the question every SMB owner asks. Most of us have been answering with vibes. Good vibes, educated vibes, but vibes.

DSPM changes the answer. You can point at a number. You can point at a recommendation you actioned last month and the unprotected file count that dropped because of it. You can show, not tell.

For MSPs, that’s a QBR slide that sells itself. For internal IT, it’s the evidence you need when the CFO asks what the Microsoft Purview licence is actually doing for the business.

And if Copilot is already in the tenant — which, let’s be honest, it increasingly is — then DSPM for AI is your next stop. Same lens, pointed at what people are pasting into Copilot prompts and what’s flowing back out.

Copilot doesn’t slow down. Neither does your data sprawl. Use something that keeps up.

DSPM isn’t there to create more work. It’s there to stop the guessing.

Are We Copilot‑Ready?

A practical readiness checklist for SMBs using Microsoft 365

Purpose:
Microsoft 365 Copilot works only within the permissions, data, and policies you already have. This checklist helps confirm whether your tenant is ready—or whether Copilot will simply surface problems faster.

You don’t need to score 100%. You do need to know where the risks are.

1️ Identity & Access (Foundation)

✅ We have Entra ID (Azure AD) accounts for all staff
✅ Multi‑factor authentication (MFA) is enforced for all users
✅ Admin roles are limited and reviewed periodically
✅ Former employees and guest users are removed promptly
✅ Conditional Access is in place for risky sign‑ins or devices

If “No” appears here:
Copilot will still work—but with higher security risk.

2️ Licensing Reality Check

✅ We understand the difference between:

Copilot Chat (Basic)
Microsoft 365 Copilot (Paid / Premium)

✅ We know which roles actually need Copilot licences
✅ We are not assuming “everyone gets it for free”
✅ Business Premium (or E3/E5) is in place for users handling sensitive data

If unclear:
Expect confusion, helpdesk tickets, and poor adoption.

3️ SharePoint & OneDrive Permissions (The Big One)

✅ SharePoint sites have clear owners
✅ Access is based on need, not convenience
✅ “Everyone” or “Anyone with the link” sharing is controlled
✅ Old project sites are archived or cleaned up
✅ We’re comfortable with Copilot summarising what users can access

Reality check:
Copilot doesn’t break permissions—it makes them obvious.

4️ Sensitivity Labels & Data Classification

✅ Sensitivity labels exist (even if only a few)
✅ Labels are applied to key documents and libraries
✅ Staff understand “Public vs Confidential” at a basic level
✅ We know Copilot respects sensitivity labels
✅ We are aware auto‑labelling may change labels automatically

Minimum viable setup:
Public / Internal / Confidential is often enough to start.

5️ Data Loss Prevention (DLP) Basics

✅ DLP is enabled for email and files
✅ Alerts or user warnings exist for sensitive data sharing
✅ We accept that Copilot follows the same DLP rules
✅ IT monitors DLP incidents (not just blocks them)

Without DLP:
Copilot can still answer—but may summarise data you’d rather it didn’t.

6️ Devices & Work Locations

✅ Devices are managed (Intune or equivalent)
✅ We know which devices are corporate vs personal
✅ Business data access is restricted on unknown or unmanaged devices
✅ Staff regularly work from approved locations

Why this matters:
Copilot uses the same trust signals as Outlook, Teams, and SharePoint.

7 Governance & Change Management

✅ Someone owns Copilot decisions (not “everyone”)
✅ We have user guidance for:

What Copilot is
What Copilot is not ✅ Staff know they remain responsible for final output
✅ We are prepared to say “not yet” to some AI use cases

Copilot readiness is organisational, not just technical.

8 Helpdesk & User Expectations

✅ Helpdesk knows Copilot behaviour changed in April 2026
✅ We can explain “why Copilot looks different now”
✅ We know where Copilot is expected to work (and where it won’t)
✅ We’ve set expectations around quality, limitations, and review

Silence here = frustration later.

✅ Copilot‑Ready Summary

Mostly ✅ → You’re ready to enable Copilot safely
Several ⚠️ → Fix fundamentals first
Many ❌ → Copilot will amplify risk and confusion

Rule of thumb:

If you wouldn’t be comfortable with an intern reading and summarising your Microsoft 365 data, Copilot isn’t the problem—your tenant is.

GRC in a Nutshell – And How Microsoft 365 Actually Makes It Practical

GRC is one of those acronyms that gets thrown around a lot, usually right before everyone in the room quietly switches off.

Governance, Risk Management, and Compliance sounds like paperwork, policy binders, and audit pain. But done properly, GRC is none of those things. It’s simply the mechanism that turns business intent into repeatable, defensible security outcomes.

And this is where Microsoft 365 quietly does a lot more heavy lifting than most organisations realise.

GRC isn’t about eliminating risk

Let’s get this out of the way early.

The goal of GRC is not to eliminate risk. That’s impossible. If your business uses email, cloud services, mobile devices, or people, risk exists.

What GRC is really about is:

Understanding what level of risk the business is willing to accept
Translating that appetite into practical controls
Measuring how well those controls are working
And getting explicit agreement on the residual risk that remains

That last point is critical. Security isn’t an IT problem — it’s a business decision. GRC gives the business a way to make that decision consciously, instead of by accident.

Governance: turning intent into guardrails

Governance is where most organisations stumble, because it’s often confused with documentation.

In reality, governance is simply the process of answering:

“How do we want things to work around here?”

In Microsoft 365, governance is expressed through configuration, not policy PDFs.

Examples:

Conditional Access defines who can access what, from where, and under what conditions
Intune defines how devices must be configured before they’re trusted
Sensitivity labels define how information is classified and handled
Retention policies define how long data should exist — and when it shouldn’t

This is governance as code. Once it’s configured, it applies consistently, silently, and at scale. No training session or reminder email can compete with that.

Risk management: making security measurable

Risk management is where GRC starts to pay for itself.

Instead of vague statements like “we take security seriously”, Microsoft 365 gives you evidence:

Secure Score shows how your tenant compares to recommended security baselines
Defender surfaces real‑world attack activity, not theoretical threats
Compliance Manager maps controls to recognised frameworks and highlights gaps

This matters because risk that isn’t measured can’t be discussed meaningfully with the business. Microsoft 365 turns risk into dashboards, trends, and improvement actions — which means security conversations can finally move beyond fear and anecdotes.

Compliance: a by‑product, not the goal

One of the biggest mistakes I see is organisations chasing compliance as the end goal.

Compliance should be the output of good governance and risk management, not the driver.

Microsoft 365 reflects this approach well. Whether you’re aligning to Essential Eight, ISO, or internal standards, the same core controls keep showing up:

Strong identity protection
Device compliance
Data classification and protection
Logging, auditing, and retention

When these are in place, compliance reporting becomes far less painful — because you’re proving what you already do, not scrambling to justify what you don’t.

Residual risk: the most important conversation

Here’s the part that rarely happens, but should.

After controls are implemented and compliance is measured, there will always be risk left over. Budget limits, usability trade‑offs, legacy requirements — they all create gaps.

GRC forces the right question:

“Are we comfortable accepting this remaining risk?”

Microsoft 365 makes that conversation possible because it provides clarity:

What’s protected
What isn’t
And what it would take to close the gap

That enables informed decisions instead of hand‑waving. Sometimes the answer is “yes, we accept that risk”. And that’s perfectly valid — as long as it’s a conscious choice.

Why this matters now

With Copilot, automation, and cloud‑first operations accelerating, risk is no longer something that can be managed annually or ad‑hoc.

Microsoft 365 gives organisations a living GRC platform:

Governance enforced through configuration
Risk surfaced through telemetry
Compliance evidenced continuously

The organisations that thrive won’t be the ones chasing perfect security. They’ll be the ones who understand their risk, manage it deliberately, and can explain — clearly — why they’ve made the choices they have.

And that, in a nutshell, is what GRC is supposed to do.

GRC mapped to Microsoft 365 (at a glance)

GRC Element	What it means in plain English	How Microsoft 365 supports it
Governance	Define how the business wants security, access, and data handling to work.	Conditional Access and identity controls set who can access what and under which conditions. Intune enforces device standards. Sensitivity labels and retention policies define how data is classified and handled across Exchange, SharePoint, OneDrive, and Teams.
Risk Management	Identify, measure, and prioritise real security risks.	Secure Score and Defender telemetry expose gaps and active threats. Intune and Entra ID reporting provide visibility into configuration drift and access risk. Microsoft Sentinel and Defender XDR (where used) correlate signals to show material risk rather than noise.
Compliance	Demonstrate alignment to standards, regulations, or internal controls.	Microsoft Purview Compliance Manager maps controls to frameworks and tracks implementation status. Audit logs, eDiscovery, and retention provide evidence without manual data gathering. Built-in compliance reporting supports regulatory and contractual requirements.
Residual Risk	Explicitly accept what remains after controls are applied.	Microsoft 365 reporting clarifies what is protected and what isn’t, allowing business leaders to make informed trade-offs between usability, cost, and security.

New Publication–Achieving SMB1001:2026 with M365 Business Premium

https://directorcia.gumroad.com/l/smb10012006

Unlock Your Path to SMB1001:2026 Certification—The Definitive Guide for Modern Cybersecurity Excellence

Are you ready to elevate your business’s cybersecurity posture and achieve the new SMB1001:2026 standard? This publication, Achieving SMB1001:2026 Compliance with Microsoft 365 Business Premium, is your essential roadmap to mastering the latest requirements from Dynamic Standards International (DSI), released in September 2025.

Why Choose This Guide?

Comprehensive Coverage of the Latest 2026 Standard: Stay ahead with detailed explanations of all new controls, refinements, and tier changes introduced in SMB1001:2026. Learn how to implement advanced requirements like DMARC email authentication, Endpoint Detection & Response (EDR), AI governance, and enhanced supplier security—features not found in previous editions1.
Step-by-Step Implementation: Benefit from practical, actionable guidance for every control across Bronze to Diamond levels. Each section provides clear instructions for leveraging Microsoft 365 Business Premium tools—Intune, Defender for Business, Purview, and more—to meet compliance efficiently and confidently.
Gap Analysis & Control Mapping: Instantly identify what’s changed from SMB1001:2025 to 2026. The publication includes side-by-side tables and checklists, so you can pinpoint new, relocated, and updated controls, ensuring your compliance journey is audit-ready and future-proof1.
Real-World Solutions: Discover how to use Microsoft 365’s integrated security features to satisfy every requirement—from patch management and password hygiene to advanced backup strategies and supplier trust programs. Includes tips for evidence collection, policy documentation, and ongoing compliance management.
Focused on the Latest Threats: The 2026 standard responds to today’s evolving cyber risks, including email-based attacks, AI misuse, and supply chain vulnerabilities. This guide shows you how to implement controls that directly address these challenges, protecting your business from costly incidents and regulatory penalties.
Accelerate Your Certification: Whether you’re starting at Bronze or aiming for Diamond, this publication provides a clear, phased roadmap. Achieve certification faster, reduce audit stress, and gain a competitive edge with a security posture aligned to global best practices.

Who Should Buy This Guide?

IT Managers, MSPs, and Security Professionals seeking a practical, up-to-date reference for SMB1001:2026 implementation.
Business Owners and Executives wanting to understand the value and process of certification, and how it strengthens business resilience.
Compliance Officers and Auditors needing authoritative guidance on evidence collection, policy updates, and audit preparation.

Key Benefits

Save Time and Resources: Avoid costly trial-and-error with proven, step-by-step instructions and ready-to-use checklists.
Reduce Risk: Implement controls that directly mitigate ransomware, phishing, and supply chain threats.
Future-Proof Your Business: Stay compliant with the latest cybersecurity standard, ensuring your organization is prepared for evolving regulations and threats.

Don’t settle for outdated guidance—choose the publication that’s fully aligned with SMB1001:2026 and unlock your path to certification and cyber resilience.

SMB1001:2025 is available here – https://directorcia.gumroad.com/l/smb1001-2025?layout=profile

See all the titles available at – https://directorcia.gumroad.com/

ASD iOS Compliance policy check script

I’ve taken the iOS Compliance policy settings recommendations from the ASD Blueprint for Secure Cloud and created an online JSON settings file here:

https://github.com/directorcia/bp/blob/main/Intune/Policies/ASD/ios-compliance.json

I’ve then created a PowerShell script here:

https://github.com/directorcia/Office365/blob/master/asd-ioscomp-get.ps1

with documentation here:

https://github.com/directorcia/Office365/wiki/ASD-iOS-Compliance-Policy-Check

that reads the online JSON file (or uses a local version if you want to use that) and compares the recommended ASD settings to those in your own Intune environment. Note, the script makes NO CHANGES to your environment, it simply reads the current settings.

It then produces the console output you see above and a HTML report like this:

You can refer to this page I also created:

https://github.com/directorcia/bp/wiki/iOS-Compliance-Policy-Settings-%E2%80%90-Security-Rationale

as to why these settings are important to the security of your M365 environment.

Look out for more scripts like this coming soon. I welcome any suggestion about improving this.