“We use Microsoft 365, so Microsoft handles the security.”

I hear versions of this fairly often from business owners, and the assumption is understandable. Microsoft, Amazon and Google operate some of the largest and most sophisticated technology environments in the world. They spend enormous amounts of money securing their datacenters, networks, software and cloud infrastructure. A small or midsize business could never build anything comparable on its own.

But there is an important distinction between Microsoft being secure and your Microsoft 365 environment being secure.

The same is true of Amazon Web Services, Google Cloud and virtually every other cloud platform. The provider can do an excellent job protecting the infrastructure underneath your business while your accounts, permissions, applications, data and configurations inside that environment still leave you exposed.

There is another important difference between the cloud and the traditional office environment. Many cloud services are intentionally designed to be reached from anywhere. Your employees can access email, files and business applications from the office, home, airport or hotel. That's one of the reasons businesses love the cloud, but it also means security can no longer depend primarily on being inside an office network protected by a firewall.

A criminal on the other side of the world doesn't need to get physically near your office to try to log into Microsoft 365. The login page is supposed to be available from anywhere.

That doesn't make the cloud inherently insecure. It means that identity, permissions, configuration and monitoring have become part of your new security perimeter. Those responsibilities should be managed as part of a broader cybersecurity program.

And those responsibilities don't disappear simply because Microsoft, Amazon or Google provides the platform.

Is the Cloud More Secure Than Keeping Everything in the Office?

There isn't a simple yes-or-no answer.

A major cloud provider can protect physical datacenters, networks, servers and underlying platforms at a level most small businesses could never economically reproduce. Moving to the cloud can therefore eliminate many risks and responsibilities a business previously had to manage itself.

At the same time, cloud services make company resources available in ways that traditional on-premises systems often weren't. An accounting server sitting behind an office firewall with no direct connection from the internet may have very little exposure to someone trying to reach it from another country. Microsoft 365, by design, needs to let legitimate employees attempt to sign in from almost anywhere.

The risks are different.

With traditional on-premises technology, the company owns much more of the infrastructure and therefore has more to secure. With cloud technology, the provider takes responsibility for more of the infrastructure, but identity, access, permissions and configuration become increasingly important.

So the useful question isn't whether cloud or on-premises is universally more secure.

It is:

What is the provider securing, what are we still responsible for, and who is actually doing our part?

The Short Version: What Your Cloud Provider Still Expects You to Handle

Moving to the cloud transfers a tremendous amount of responsibility to the cloud provider, but it doesn't transfer everything. Exactly where the line falls depends on what you are buying. Microsoft 365, for example, puts much more responsibility on Microsoft than simply running your own Windows server as a virtual machine in Azure.

Microsoft's own shared-responsibility guidance says that even with cloud services, customers retain responsibility for their data, identities and users, configurations and settings, and access management.

In everyday business terms, somebody still has to handle these things:

The technology behind these responsibilities can get complicated. The question for an owner doesn't have to be:

How do all these security systems work?

It can be much simpler:

Who is actually doing these things for us?

If the answer isn't clear, being “in the cloud” hasn't eliminated the security responsibility. It may simply have made it less visible.

A Security System That Nobody Set Up

A home alarm system is a useful way to think about this.

Imagine buying a house and discovering that the previous owner installed a sophisticated security system. There is a control panel, cameras, door sensors, motion detectors and a video doorbell.

Having all that equipment doesn't necessarily mean the house is well protected. You might discover that nobody is paying for monitoring, two sensors were disabled because they caused false alarms, the previous owner's access code still works, the back-door camera was never configured and nobody receives an alert when the alarm goes off.

You haven't bought a bad security system. You have security capabilities that nobody is properly operating.

Cloud security can work much the same way.

Microsoft can provide multifactor authentication, access controls, administrative roles, email protection, security alerts, device management, audit logs and many other protections. Some are enabled by default. Others aren't. Some require additional licensing. Others require decisions about how aggressively they should be applied. Together, these protections create a layered approach to cybersecurity.

One of the best examples is something Microsoft calls Conditional Access.

Microsoft Can Recognize You. Someone Still Has to Decide Whether You Should Be Let In.

The name Conditional Access sounds technical. The business idea behind it isn't:

Just because someone has the correct username and password doesn't mean your company should automatically let them in.

Microsoft can consider additional information when somebody tries to access company systems. Who is the person? What device are they using? Where are they connecting from? What are they trying to access? Does Microsoft see indications that the activity may be risky?

Consider a few examples.

An employee signs in from the company laptop they normally use. Everything looks normal.

The same employee's account suddenly attempts to sign in from another country using an unfamiliar computer. The company may want stronger verification or may want to block the attempt.

An employee tries to access company information from an unmanaged personal computer. Perhaps the company is comfortable allowing certain access but doesn't want sensitive information downloaded to that computer.

An administrator signs in. Because that account has considerably more power than an ordinary employee account, the company may want stricter requirements.

Microsoft provides the technology capable of enforcing those decisions. But it doesn't know the right decisions for every company.

Blocking foreign logins might make sense for a local business whose employees never travel internationally. The same rule could create problems for a consulting company whose executives regularly travel overseas. Requiring every computer to be company-managed might be appropriate for one organization and prevent legitimate contractors from working at another. These decisions are also central to secure remote access.

Microsoft itself describes Conditional Access as a policy engine that helps organizations balance two goals: protecting company assets while allowing employees to remain productive.

That balance has to reflect the way the particular business actually works.

Why Doesn't Microsoft Just Turn Everything On?

If Microsoft knows these protections make companies safer, why doesn't it simply enable the strongest possible security settings for everybody?

Because security affects usability.

A stronger authentication requirement can prevent an older application from connecting. A restriction on unmanaged computers can stop an employee from working from home. A tighter sharing policy can interfere with collaboration with a client. A location restriction can lock out an executive who is traveling.

At Microsoft's scale, a security change that works perfectly for most customers could still disrupt an enormous number of businesses.

Microsoft does provide baseline protections. Microsoft 365 business subscriptions include Security Defaults, for example, and Microsoft 365 Business Premium includes the more flexible Conditional Access capability. But Microsoft's own documentation distinguishes the simple baseline from Conditional Access, which is customizable around an organization's requirements.

This isn't a weakness in Microsoft's security. Microsoft cannot know enough about every customer's employees, applications and business processes to make every security-versus-usability decision for them.

Be Careful Who Gets the Master Keys

You need someone capable of managing the environment, but giving someone administrative access creates risk of its own.

Imagine a 25-person company using Microsoft 365 with six people holding powerful administrative privileges. One is the owner. Another originally set up Microsoft 365. One belongs to an outside consultant who finished a project two years ago. Two belong to employees who needed administrative access at some point. Nobody is quite sure what the sixth account is for.

That's already a problem because there are too many master keys.

But the number of administrators isn't the only issue. The people holding the keys need to know what they're doing.

An administrator can change security policies, grant access to sensitive information, create accounts, connect applications, modify authentication requirements and potentially weaken or disable security controls.

Sometimes the dangerous change isn't malicious at all. An employee complains that a security policy is preventing them from working, so someone with administrative access finds the setting and turns it off. The immediate problem disappears, but the setting may have been preventing employees from accessing company information from unmanaged computers.

Or someone creates a broad exception because one executive is having trouble logging in. They solve the executive's problem while unintentionally creating an exception affecting many other people.

A third-party application might be authorized without understanding how much company information it can access. A security policy might be changed without understanding what else depends on it.

These are well-intentioned mistakes, but they can still make the company less secure.

Administrative access is therefore both a privilege and a responsibility. The goal isn't merely to have fewer administrators. Administrative authority should be given only to people who need it, at the level they need, and who understand how to use it safely.

Microsoft provides the master keys.

It cannot determine whether the person you hand them to is qualified to use them.

The Same Problem Applies to Every User

Suppose an employee leaves the company on Friday. Unless your organization has a process connecting that business event to the technology, the employee's accounts and permissions may remain exactly as they were on Thursday.

The cloud platform provides the ability to disable the account, revoke sessions and remove access. It doesn't know the employee resigned.

The same issue appears when people change positions. A person moving from accounting to sales may no longer need financial access. Someone promoted to management may need information they couldn't previously see. A temporary contractor may need access for three months and no longer need it afterward.

These are business decisions expressed through technology, and somebody has to make sure the technology changes when the business does.

A Security Alert Is Not the Same as a Security Response

Suppose Microsoft detects unusual activity in an employee's account at 2:13 on Saturday morning.

That's valuable, but what happens next?

Perhaps Microsoft blocks the activity automatically. Perhaps it generates an alert. Perhaps the activity looks suspicious but isn't conclusive enough to automatically disable a legitimate employee's account.

Is anyone receiving the alert? Does someone determine whether the employee is actually traveling? If the account is compromised, who disables it? Does someone determine what the attacker accessed or whether anything else was changed?

Modern cloud platforms increasingly use automation and AI to analyze activity and can take certain actions automatically. That's a major improvement.

But the ability to create an alert isn't the same thing as having someone responsible for the outcome of that alert.

That responsibility may belong to internal IT, an IT provider, a specialized Security Operations Center, automated systems, or some combination. For a business owner, the organizational chart matters less than knowing the answer to one question:

Who is watching? A documented incident-response plan should define what happens next.

Microsoft Itself Says Small Businesses May Need Help

This isn't simply the opinion of IT providers.

Microsoft's own guidance says small and midsize businesses often don't have the capacity or expertise for a dedicated security operations team. Microsoft says these businesses may need help with setup and configuration, managing security, and addressing alerts or detected threats—and explicitly states that Microsoft partners can help.

Microsoft also provides technology specifically so MSPs and other partners can manage customer security settings, view threats, receive alerts, investigate incidents and take remediation actions.

Microsoft's guidance is available here:

Microsoft: Resources for partners working with small and medium-sized businesses

There is a practical reason for this. Microsoft builds and operates Microsoft 365, but it doesn't operate as the IT department for every company using it.

Microsoft doesn't know that your CFO is traveling this week. It doesn't know that your controller resigned yesterday. It doesn't know whether an employee should be allowed to download client information onto a personal computer. And when a security control prevents somebody from doing legitimate work, Microsoft doesn't understand that person's job and your business process well enough to decide whether the activity should be allowed. This is why it helps to understand how to structure the right IT team and why one IT person can't cover every modern IT discipline.

For a large organization, internal security and IT teams may perform those functions. Smaller businesses often use an MSP or other specialists to provide some or all of that expertise. The important point isn't whether those people are employees or an outside provider.

It's that somebody is responsible.

Secure Today Doesn't Mean Secure Next Year

Even a cloud environment that is configured securely today won't simply remain that way indefinitely.

Part of the problem is normal business activity. Employees join and leave. Applications are added. Permissions change. Vendors are connected. Exceptions are made. Licenses change. Somebody receives temporary administrative access and nobody remembers to remove it. Over time, these changes can cause a secure configuration to drift away from what was originally intended.

But there is another reason: the definition of “secure” changes.

Attackers discover new vulnerabilities. Researchers identify weaknesses. Criminals develop new techniques. Vendors release new protections and change their recommendations. Something considered reasonable protection a few years ago may no longer be considered sufficient today.

AI is accelerating both sides of that cycle. Microsoft's 2026 Digital Defense Report describes attack timelines compressing as AI makes sophisticated capabilities more accessible and automates more of the attack chain. Microsoft reports that nearly 40,000 publicly reported vulnerabilities were published during the first half of 2026, while AI is also accelerating vulnerability discovery.

AI helps defenders too. Cloud providers and security companies increasingly use it to identify weaknesses, analyze alerts and automate portions of the response.

The important implication for a business owner is that “we secured Microsoft 365 when we set it up three years ago” isn't a security strategy.

Microsoft, Amazon and Google continuously improve the portions of the platform they control. They also release new capabilities and recommendations for the portions customers control. They can't necessarily apply every new restriction automatically because they don't know what it might disrupt.

Someone still needs to evaluate whether a new protection applies, whether it can be enabled without breaking an important application, whether a newly discovered vulnerability affects the business, whether old exceptions are still necessary, and whether current recommendations have changed.

This means your company can become less secure relative to the threats around it without anybody changing a single setting.

Nothing necessarily broke.

The world simply changed around it.

What About Files in SharePoint, OneDrive or Google Drive?

A secure platform and secure use of the platform can be very different things.

Suppose an employee puts a confidential spreadsheet into SharePoint and accidentally shares it with the wrong person. Microsoft may have securely stored and transmitted the information exactly as instructed. The problem is that the instruction itself was wrong.

Businesses therefore need to determine who can share information, what can be shared externally, whether sensitive information requires additional controls and how unusual activity will be identified.

Cloud platforms provide capabilities to help enforce those decisions, but the rules have to reflect the company's information and business relationships.

“It's in the Cloud” Also Doesn't Answer the Backup Question

Another assumption often accompanies cloud computing:

“If it's in the cloud, it's backed up.”

Cloud providers build tremendous redundancy into their platforms. That protects against many hardware failures and service disruptions and is one of the reasons businesses move to the cloud.

But service availability and your company's ability to recover its information aren't necessarily the same thing.

What happens if an employee deletes important information? What happens if a compromised account removes or alters data? How long is deleted information retained? What if synchronized files are encrypted or damaged? What happens if you discover the problem after the provider's normal recovery window has passed?

The answers depend on the service and its configuration.

The useful question isn't simply, “Does Microsoft have another copy?”

It is:

If something happens to our information, can we restore what we need, to the point we need, within the amount of downtime our business can tolerate? Answering it is a core part of business-continuity planning.

And when a cloud provider hosts a virtual server, there is another important distinction. Restoring the data alone may not restore the operating system, applications, configuration, permissions and dependencies needed to get the business running again.

Backup and recovery are related.

They aren't the same thing.

Microsoft, Amazon and Google Aren't Your IT Department

Microsoft's job is to operate Microsoft 365 and Azure. Amazon operates AWS. Google operates its cloud platforms.

They provide extraordinary infrastructure and increasingly sophisticated security capabilities, but none of them runs your business.

They don't decide which employee should see payroll information. They don't know when your controller leaves the company. They don't decide how long your business can survive without a critical application. And they aren't normally the helpdesk your employees call when a security control interferes with legitimate work.

For a large company, internal teams may handle all of this. A smaller organization may rely on an IT provider, MSP or outside security specialists working with management. Often it is a combination.

Regardless of the structure, someone should be able to answer:

Who configures our cloud security?

Who reviews administrative access?

Who adds and removes users?

Who decides what information can be shared?

Who patches the operating systems and applications on our cloud servers?

Who monitors security alerts and responds when something suspicious happens?

Who reviews new security recommendations and vulnerabilities?

Who helps employees when security controls interfere with legitimate work?

Who periodically verifies that our environment is still configured the way we think it is?

And ultimately, who owns the outcome when something goes wrong?

If those answers aren't clear, the fact that your infrastructure belongs to one of the world's largest technology companies doesn't solve the problem.

Start With What Your Business Needs, Not With What the Cloud Provider Sells

There are hundreds of cloud security capabilities available, and the list changes constantly. Trying to build a security program by working through every feature Microsoft, Amazon or Google offers quickly becomes overwhelming.

A better approach is to start with an established cybersecurity framework and the risks of the business.

For many small and midsize organizations, the CIS Controls provide a practical structure. CIS Implementation Group 1 contains 56 foundational safeguards that CIS describes as essential cyber hygiene and a starting point for defending against common attacks.

Once you know what protections the business needs, you can ask a much more useful set of questions:

Which responsibilities does our cloud provider already handle?

Which security capabilities does the provider give us but expect us to configure and operate?

What protections do we still need outside the platform?

That is very different from assuming that purchasing Microsoft 365, Azure, AWS or Google Cloud automatically checked the cybersecurity box.

The Cloud Changed IT Security. It Didn't Eliminate It.

The cloud has been a tremendous improvement for many businesses. It can provide resilience, sophisticated security capabilities, rapid innovation and infrastructure that would be impractical for a smaller organization to build on its own.

But the cloud didn't eliminate the need to manage security.

It changed what needs to be managed.

You may no longer be responsible for protecting the physical server running your email system, but you are still responsible for deciding who can access the email. You may no longer maintain the storage hardware containing your files, but someone still has to determine who can share those files. You may no longer own the physical server running an application, but if that server is simply a VM in the cloud, someone may still have to patch and protect its operating system and applications.

And you may have access to sophisticated identity protection, Conditional Access, security monitoring and AI-driven threat detection, but those capabilities still have to be configured, reviewed and operated in a way that fits your business.

Microsoft secures Microsoft's part. Amazon secures Amazon's part. Google secures Google's part.

Your business still needs someone responsible for yours.