Cloud Security Services for a Company With No Cloud Team

Two proposals for cloud security land in the same week. One is a fixed-price assessment: six weeks, a report, findings ranked by severity, a closing call. The other is a monthly retainer with a platform name in it and a price per cloud account. Both say cloud security services across the top. Neither explains which one the company in front of them needs.

The answer depends on a question neither vendor asked. Cloud security work splits into finding problems, fixing problems, and watching for new ones. Providers are staffed and priced very differently across those three, and a company with no cloud team usually needs all three while budgeting for one. The assessment that produces 140 findings is worth nothing if nobody inside the company has time to close them, and the monitoring retainer is worth very little on top of an environment that was never hardened in the first place.

So the useful way to read a cloud security proposal is not as a capability list. It is as an answer to one question: after you sign this, who does the work?

What Are Cloud Security Services?

Cloud security services is an umbrella phrase covering two different purchases that share a name. One is a project: somebody comes in, looks at your AWS, Azure, Google Cloud or Microsoft 365 environment, and tells you what is wrong with it. The other is a subscription: somebody watches those environments continuously and does something when they see a problem. Most firms sell both, usually in that order, and the assessment is often priced as a way into the retainer.

Underneath either shape you are renting four things, and very few providers are strong at all four.

Tooling. A posture scanner that reads your cloud configuration through the provider's API, log collection, and somewhere for findings to live. Sometimes the provider brings its own platform, sometimes it operates the one you already pay for as part of your cloud subscription.

Configuration judgment. Deciding that a storage bucket open to the internet is a marketing site and fine, while the one next to it holds exports of your customer database and is an emergency. Every scanner produces hundreds of findings. The value is in the ranking, not the list.

Watching. Somebody reading cloud audit logs at three in the morning, when a new administrator role appears in a tenant nobody was supposed to be changing.

Authority. What the provider is allowed to change in your cloud accounts without asking. This is the single largest difference between two proposals that use identical words, and it lives in the contract rather than in the technology.

A managed security contract can include all four for your on-premises estate and none of them for your cloud accounts, which is a gap buyers discover late and usually during an audit.

What Cloud Security Services Cover

Scope varies by firm and by tier, but the market has settled into six recognizable blocks of work. A proposal that does not clearly land inside these blocks is a proposal you cannot compare with another one.

Cloud posture and configuration review. Continuous or periodic inspection of how your accounts are set up: public storage, unencrypted volumes, permissive network rules, disabled logging, root accounts without hardware keys, regions nobody is using but everybody can deploy into. This is the block sold as cloud security posture management, and it is where an engagement almost always starts because it needs nothing but read access.

Identity and entitlement work. Who can do what, and how much of it they do not need. Cloud identity is the perimeter now, and the work here is inventorying human and machine identities, cutting standing privilege, enforcing multi-factor authentication on every account that supports it, and finding the service principals and access keys that nobody has rotated since the year they were created.

Workload and container protection. Agents or agentless scanning on virtual machines, containers and serverless functions, looking for vulnerable packages, exposed secrets in images, and behavior that does not belong. This is the block that overlaps most with what you may already own on your laptops and servers.

Data protection and key management. Finding where sensitive data actually sits across accounts, confirming it is encrypted, and deciding who holds the keys. CISA and the NSA published five joint information sheets on cloud security, and two of the five are about exactly this: secure cloud key management practices, and securing data in the cloud. The other three cover identity and access management, network segmentation and encryption, and the risks that come with using a managed service provider at all.

Detection, logging and response. Cloud audit logs, identity provider logs and workload telemetry collected somewhere they can be correlated, with rules that fire on things like a new federation trust or a mass export. Bought on its own this is managed detection and response with cloud sources connected, and the distinction that matters is whether the provider watches your cloud control plane or only your endpoints.

Compliance evidence. Control mappings, retention that satisfies a framework, and answers to the cloud questions on a customer security questionnaire. For a company carrying HIPAA, PCI DSS or a SOC 2 commitment, this block is frequently the reason the contract gets signed at all.

Two adjacent services get sold alongside these and are separate purchases with separate scopes: vulnerability scanning of what you run, and cloud penetration testing, where somebody attacks the environment under rules of engagement your cloud provider also has to agree to.

What Cloud Security Services Do Not Cover

None of the exclusions below are unreasonable and all of them are standard. They become a problem only when a buyer assumed otherwise, which happens constantly because the proposals are written in the language of outcomes and delivered in the language of findings.

Fixing what the assessment found. This is the big one. A provider will hand you a prioritized list of misconfigurations and, at the higher tiers, a remediation plan. Somebody with production access still has to change the network rule, break the application that depended on it, and explain the outage. Assessment without an internal owner for remediation produces the same report twice a year with the same findings on it.

Change approval and release engineering. Turning off a permissive rule that a deployment pipeline recreates every night is a development task, not a security task. If your infrastructure is defined in code, the fix belongs in the code, and that repository usually belongs to a team the provider has no relationship with.

Identity lifecycle. Providers monitor identity events and will tell you that a former employee's account is still active. Creating accounts, removing them on the last day, and reviewing who holds administrator rights is your joiner, mover and leaver process, and it stays yours.

The cloud bill. Cost is not in scope, but it interacts with security more than people expect. Full audit logging, longer retention and higher-tier native security features are chargeable, and a provider recommending them is recommending an increase to an invoice they do not pay.

Accounts nobody disclosed. A cloud security service covers the subscriptions and tenants it was given read access to. The developer sandbox on a personal card, the marketing team's separate Google Workspace, the acquired subsidiary still running its own AWS organization: none of it is covered, and none of it will appear as a gap unless somebody asked for an inventory first.

Regulatory notification and legal work. State breach notification deadlines, regulator filings and customer letters. A provider supplies forensic facts. The filing and the liability are yours, and if you want somebody on contract to run the technical side of an incident, that is a separate incident response retainer with its own hourly rate.

Accountability. You can outsource the work. You cannot outsource the consequence, and your customers, your regulator and your insurer will address their questions to you.

Who Is Responsible for What in the Cloud

Every cloud provider publishes a shared responsibility diagram, and all of them are redraws of one twenty-page definition. NIST's definition of cloud computing sets the boundary for each of the three service models, and it is worth reading in the original because it is written in the negative: it says what the consumer does not manage or control.

In infrastructure as a service, the consumer does not manage the underlying infrastructure but has control over operating systems, storage and deployed applications, plus possibly limited control of select networking components. In platform as a service, the consumer does not manage the network, servers, operating systems or storage, but controls the deployed applications and possibly the configuration of the hosting environment. In software as a service, the consumer does not manage or control any of that, or even individual application capabilities, with the possible exception of limited user-specific configuration settings.

Read that third one carefully, because it is the one most companies live in. In a SaaS platform you control almost nothing except who has access, how the tenant is configured, and what data you put in it. That sounds like a small surface. It is also precisely the surface every large SaaS compromise of the past two years has attacked.

The pattern is that the boundary moves but the last three items never do. Identity, configuration and data are yours in every model, and they are what a cloud security service is actually hired to look after.

How Cloud Security Differs From On-Premises Security

Four differences change the shape of the work, and a firm that treats a cloud account as a data center with a different address will miss all four.

The control plane is an API. An attacker with the right credential does not need to be on your network, walk past a receptionist, or move laterally through anything. They make an authenticated call. There is no inside.

Identity is the perimeter. Zero trust started as an architectural argument and became the literal operating condition of a cloud tenant, where the only thing standing between a stolen session token and your customer database is what that identity is permitted to do.

A mistake is instant and global. One change to a storage policy exposes every object in a bucket in the time it takes an API call to return. The same mistake in a data center needs a firewall change, a routing change and somebody not noticing.

Logging is opt-in and billed. Most of what you need to reconstruct an incident is not recorded by default, is retained for a short window, and costs money to keep longer. The month you need the logs is the month you find out which setting was never turned on.

CISA and its partner agencies documented how state actors adapt to exactly this environment in an advisory on cyber actors gaining initial cloud access. The techniques are not exotic. They target service accounts, which are often highly privileged and cannot use multi-factor authentication. They target dormant accounts left enabled after employees leave. They steal system-issued access tokens so no password is needed. They use MFA bombing, repeatedly pushing prompts until somebody accepts one. They route traffic through residential proxies so it appears to come from ordinary broadband ranges. And once inside, they enroll their own device into the tenant as a trusted one.

Verizon's 2026 Data Breach Investigations Report found that vulnerability exploitation now starts 31 percent of breaches, passing stolen credentials for the first time in nineteen years, and that breaches involving a third party reached 48 percent of the total after a 60 percent jump in a single year. Both numbers point the same way for a cloud buyer. Your exposure is a function of what you run and who you connect, and cloud makes it trivially easy to add more of each without telling anybody.

What a Cloud Security Engagement Looks Like

Vendor pages describe capabilities. Nobody describes the calendar, and the calendar is what decides whether the first year is worth the money.

Read access comes before anything else. A competent firm asks for a scoped read-only role in each account rather than an administrator credential, and a firm that opens by asking for global administrator has told you something about how it works. Expect to spend real time on this if your accounts were created ad hoc by different teams, because somebody has to find them all first.

The assessment finds more than you expected and less than the tool reported. A posture scanner on an environment that has never been reviewed will return hundreds of findings, most of them low severity and many of them false in context. What you are paying a human for is the twelve that matter and the sentence explaining why.

The remediation backlog is where engagements stall. Findings arrive faster than an internal team can close them, and the list becomes wallpaper. The fix is deciding, before the assessment starts, who will do the work: your engineers with the provider advising, the provider's engineers with change approval from you, or a jointly staffed sprint with a fixed end date.

Tuning is noisy and finite. Once monitoring begins, the first month produces alerts about your own backup automation, your own deployment pipeline and your own administrators. Thirty to ninety days is normal. The company that abandons the service in week three abandons it right before it starts working.

Drift is the quiet failure. New subscriptions, new SaaS tools and new integrations appear all year. If nobody reconciles them against the monitored list at each quarterly review, coverage narrows while the invoice stays the same.

How Cloud Security Providers Differ From Each Other

Capability lists converge. These differences are checkable, and each one is a question with a verifiable answer.

Platform depth. A firm that has done a hundred AWS engagements and three Azure ones is not equally good at both. Ask how many engagements they have run on your primary platform in the past year, and who specifically will do the work.

Whose tooling. Some firms run their own posture platform, some resell one, some operate the native security services your cloud subscription already includes. The third option is cheaper and leaves nothing behind when the contract ends. The first is often better and creates a dependency.

Report or remediate. The largest price difference in the market. Advisory firms find and explain. Engineering-led firms will make the change themselves under a change process. Both are legitimate and they are not the same product.

Identity coverage. Whether the scope includes your identity provider and single sign-on configuration or stops at infrastructure. Given how cloud intrusions start, a scope that excludes identity excludes the attack.

SaaS or infrastructure only. Many providers cover AWS, Azure and Google Cloud and quietly exclude Microsoft 365, Google Workspace, Salesforce and the rest of the applications where your data actually lives. Ask which tenants are in scope by name.

Attestations you can read. A SOC 2 report, ISO 27001 certification, a cloud provider partner competency, CREST accreditation for testing work. A firm asking for a privileged role in your production accounts should be able to hand you a current report without a negotiation.

Response authority. Notify only, act with approval, or act first and report after. Three different products under one heading, and in cloud the difference is stark, because acting means changing a live configuration.

Named experience in your sector and your compliance regime. A firm that has produced cloud evidence for a HIPAA audit or a PCI assessment knows what the assessor will ask for. Ask for the framework, the year and the outcome.

What to Ask Before You Hire a Cloud Security Provider

Take the same questions to every firm on the shortlist. The differences in the answers are the differences in the service.

The answers that should slow you down: a scope described as "your cloud" rather than as a list, a request for global administrator on day one, an attestation that is "in progress", a deliverable nobody will show you even redacted, and any reluctance to say in writing whether remediation is included.

Cloud Security Contract Terms That Matter

The industry sells on capability and delivers on contract language. These clauses decide what you actually bought.

The privileged role and its limits. Exactly which role the provider holds in which accounts, whether it is read-only or can make changes, whether access is standing or requested per task, and who approves it. CISA's guidance on cloud environments treats managed provider access as its own risk category, and it is the term to negotiate hardest, because the provider's access is now part of your attack surface.

Tooling ownership and tenant exit. If the posture platform is the provider's, find out now what happens to it at termination: whether findings history is exportable, in what format, and how long you have. A scanner tenant that evaporates on the last day of the contract takes your only record of what was fixed with it.

Remediation, defined. Whether "remediation support" means writing a ticket, writing the code, or making the change. Put an example in the contract if the answer is ambiguous, because it will be ambiguous.

Assessment credit and price protection. Many firms credit some or all of an assessment fee against the first months of a managed contract. Ask before the assessment, not after, and get the managed price in the same document so the second quote cannot float.

Data residency, log retention and access. Where your logs and findings are stored, how long they are kept, and whether you can pull them yourself. For a company with a data residency obligation, this clause is the whole deal.

Notification of incidents at the provider. How and when the provider tells you about a compromise of its own systems. A firm holding privileged roles across dozens of tenants is a supply chain target for exactly that reason.

Term, notice and auto-renewal. Multi-year terms with 90 day notice windows are common, and a missed window renews the contract. Where the provider's licenses are bundled, check whether they survive the relationship.

Liability. Caps are usually a multiple of monthly fees, which is a fraction of what a breach costs. Read this clause next to your cyber insurance policy, not on its own.

How Much Do Cloud Security Services Cost?

Published prices are rare and the variables move the number more than the vendor does. Assessments are usually fixed price against a scope: accounts, workloads, platforms, whether identity and SaaS are included. Managed cloud security is priced per cloud account or subscription, per workload, per user, or per gigabyte of log data ingested, and the ingestion model is the one that surprises people, because connecting the log source that finally gives you visibility also raises the bill.

What moves a quote: how many accounts and tenants are in scope, whether SaaS platforms are included, whether identity is included, whether the provider remediates or only reports, log retention, response authority, and whether compliance evidence for a named framework is a deliverable.

The comparison that actually decides it is not vendor against vendor. It is the contract against hiring, and a cloud security engineer who can operate across AWS, Azure and identity is one of the more expensive people in the market, needs tooling, and cannot cover nights alone.

Two things in that data are worth holding a quote against. The cost gap between public cloud and on premises is real but modest, so a provider selling cloud as uniquely catastrophic is selling harder than the evidence supports. And identity work sits in the top three cost reducers, which is an argument for spending the first engagement on entitlements and MFA rather than on a platform license.

Do You Need Cloud Security Services?

The service solves a knowledge problem more than a staffing one. If your problem is something else, this is the wrong purchase.

If you land on "not yet", there is work worth doing at no cost. CISA's Secure Cloud Business Applications project publishes secure configuration baselines for Microsoft 365 and Google Workspace, along with the ScubaGear and ScubaGoggles tools that assess a tenant against them, and CISA states the tools and baselines are available to private sector organizations as well as agencies. Running one takes an afternoon, and its output makes a far better opening document for a conversation with a provider than a blank page does.

How to Choose a Cloud Security Provider

Shortlist three firms of comparable size. Take the ten questions to each. Ask every one of them to write the in-scope account and tenant list into the contract as an appendix, and treat a refusal as the answer to a different question. Then compare the three answers on remediation, because that is where the proposals diverge and where the money goes.