When a support team first takes on cloud security duties, the opening question is rarely technical. It is “who is going to do this?” Hire a specialist, lean on a managed provider, or split the load? This comparison walks through the three common options for CloudSecOps, using the Ops Atlas as a neutral yardstick, and ends with a short decision guide you can take into your next planning meeting.

First, agree on the job

Comparisons only work if everyone describes the same task. The Atlas, which is xOps School’s editorial glossary, frames CloudSecOps as the continuing work of building cloud controls, monitoring them and reacting when they slip. It leaves out several neighbours on purpose: security-operations-centre triage, pipeline scanning, identity-policy design, audit programmes and software vulnerability management. You can read that boundary on the Atlas’s CloudSecOps page. Keep it handy, because a managed contract that quietly includes or excludes one of those neighbours is the usual source of disappointment.

Option one: build it in-house

An internal team owns the guardrails, the scans, the exception register and the response drills. The advantage is context: your people know which storage container is meant to be public and which is a mistake. They also decide what gets automated and what stays manual.

The drawbacks are cost and coverage. A cloud estate runs around the clock, yet a small team sleeps. The Atlas’s suggested cadence, continuous scanning, daily triage of critical items, weekly exception review, monthly benchmark review and quarterly drills, is not heavy, but it needs named people who are protected from other work. If the same engineer carries the pager for application outages, the security calendar is the first thing to slip.

Option two: hand it to a managed provider

A managed arrangement gives you round-the-clock attention and a deeper bench. Providers have seen many accounts and bring tooling already tuned. For a support-minded organisation that already buys managed services in other areas, this feels natural.

Be careful about what is actually transferred. The Atlas stresses that configurations, identities and data remain the customer’s business under every service model. A provider can operate your controls, but accountability for the account’s settings remains yours. Ask for the finding owners to be named on both sides, and for evidence of closure by rescan instead of by status message. Also check the metrics you will receive. A pass percentage alone can mislead, since the Atlas notes that suppressed findings may be counted as passed. Ask for coverage, dwell time and exception debt instead.

Option three: co-managed, with a clear split

The middle path keeps decisions in-house and outsources the tireless parts, such as continuous scanning and first-line alert handling. It is often the most realistic choice for mid-sized teams. The trick is a written split of duties. Who can change a guardrail? Who approves an exception? Who may delete anything? The Atlas’s automation rule gives a useful starting clause: blocking actions can be automated freely, while automated repair is acceptable only for changes you can undo, trust and keep tightly scoped; nothing automatic should erase data or swap credentials that live systems are using.

One practical tip applies to all three options: run a short pilot before signing anything long-term. Give the candidate team or provider one account, ask them to produce a findings list with owners within the first week, and see how many items get closed and confirmed by rescan in the following month. A pilot reveals responsiveness and honesty far better than a sales deck or a polished organisation chart ever will.

Side by side

• Context: in-house is strongest, managed is weakest, co-managed depends on how well you brief the partner.
• Round-the-clock attention: managed and co-managed win; in-house needs rotas.
• Cost shape: in-house is mostly salaries and training, managed is a recurring fee, co-managed is both in smaller doses.
• Control over exceptions: in-house and co-managed keep it; managed arrangements often share it, so read the contract.
• Evidence for auditors: any option works if logs flow into a protected archive and records are kept; none works without them.

Roles to look at, whichever way you go

Even a managed route needs internal roles: an accountable owner for the cloud estate, someone who approves exceptions, and a person who reads the scorecard. If you are unsure what to call these roles, our overview of common DevOps role titles and career paths may help you name them consistently on job ads and in contracts.

Developers also have a part to play. Many findings originate in code that defines infrastructure, which is one reason we encourage engineers to pick up operational skills early in their careers. A developer who understands drift will think twice before fixing a setting by hand in the console, where the next deployment may silently revert it.

Support teams in particular should think about handover. When an incident happens at night, the person who answers needs a runbook, access that works and authority to act. Spell out those three things for every option, and test them in a drill, because a plan that has never been rehearsed tends to fail on its first real use.

When none of these is warranted

Do not forget the fourth option: do very little. The Atlas reports that for an estate of a couple of cloud accounts with just one team, Microsoft’s own guidance leans towards combining platform and security roles rather than creating a separate function. A short checklist and a quarterly review may be enough. Spending on a managed service you do not yet need is a poor trade.

A quick decision guide

1. Count active accounts and teams. Under three of either, start with a combined role.
2. Ask whether anyone is available for a daily look at critical items. If not, consider a managed or co-managed option for the scanning layer.
3. Decide who owns exceptions and write down their ninety-day limit.
4. Insist on organisation-wide logging into an archive that ordinary administrators cannot alter.
5. Pick three measures, coverage, dwell time and exception debt, and require them in every report.

Whichever option you pick, review it after a year. Needs change as accounts multiply, and the Atlas’s maturity ladder gives you a plain way to check: can you show an owner for each critical finding, a recorded benchmark edition and expiring exceptions? If so, you are past the early rungs, and the question becomes which option keeps you moving up.