Frequently asked questions
Every question we get asked on first calls — from how we're structured, to what Azure landing zones actually involve, to the way we price engagements. Grouped by topic so you can jump straight to the section that matters.
About Rosebud Cloud Solutions
Who we are, where we work, and how we engage.
What does Rosebud Cloud Solutions actually do?
Two things. We stop criminals sending email as your organisation, with products you can buy today from this site: a free domain check, a £50 report, and done-for-you protection from £29 a month. And we build and run secure Microsoft cloud for organisations in regulated sectors: set-up, security, cost control, advice and ongoing management.
Which industries and client sizes do you typically work with?
Our email security products are built for organisations without a security team, such as housing associations, and are priced so any UK business can buy them. Our consulting clients are mostly regulated: banks, public sector bodies, legal firms and retailers. The common thread is work where getting it wrong has real consequences.
Are you genuinely Microsoft-certified, and what does that mean for clients?
Yes. We are a Microsoft Solutions Partner for Data & AI, Digital & App Innovation, and Infrastructure on Azure. That is a company-level status that has to be earned with proven client results. Our architects also hold individual Microsoft certifications. For you, it means our designs follow Microsoft's own reference standards, and we can escalate directly into Microsoft when a problem is genuinely hard.
Where are you based and where can you work?
We are based in the UK and work mainly with UK clients. We also work with international organisations whose UK arm leads the engagement. Delivery is usually remote, with on-site time for workshops, clearances or critical incidents. Data handling follows UK and EU rules by default.
What is the best way to start a conversation?
For email security, check your domain free first. It takes about 30 seconds and shows you where you stand. For anything else, the contact page is fastest: tell us your situation in a sentence or two and we reply within one working day. First conversations are free and carry no obligation. If someone else is better placed to help, we will say so.
What makes Rosebud Cloud Solutions different from other Azure consultancies?
We only do Azure and the Microsoft cloud stack. Depth over breadth. We hold Microsoft Solutions Partner designations for Data & AI, Digital & App Innovation, and Infrastructure, and every senior engineer carries individual Microsoft certifications earned on real delivery. Nobody learns on your time, and we turn down work outside what we are genuinely expert in.
What does your team look like?
Small and senior: Azure architects, cloud security specialists and automation engineers, each with years of delivery in regulated sectors. Engagements are led by the people who actually understand your environment, not handed to a junior team after the pitch. If you want to know who will do the work, ask on the first call.
Do you have references or client case studies?
Yes. Our case studies page covers real engagements across financial services, public sector, legal and retail. For named references, we arrange introductions directly with clients who have agreed to act as referees, usually once an engagement is being seriously discussed.
How long has the company been working on Azure?
The company was built specifically for Azure delivery, and the team's Azure experience goes back to the platform's early enterprise years. Several of us were building on Azure before its current tooling existed. That is useful because we have seen which designs age well and which collapse at scale.
How should I decide whether to engage Rosebud?
If you want senior, independent Azure expertise and would rather talk to engineers than a sales team, we are probably a good fit. If you need a generalist covering every cloud, we are not. Our how we work page explains the engagement model, and a 30-minute call is the fastest way to find out.
How we work
Our delivery model, engagement shape, and working principles.
How do you typically structure an engagement?
Three phases. A short discovery to understand your environment and what you are deciding. A design-and-plan phase with clear deliverables. Then delivery with defined checkpoints. We prefer fixed-scope blocks to open-ended billing: both sides stay honest about what is being delivered and when. Scope changes happen explicitly, never by drift.
Do you work remotely, on-site, or both?
Mainly remote, with on-site time where it genuinely adds value: workshops, security clearances, critical incidents, new-client kick-offs. Remote is not a compromise. It is how senior engineers stay focused and how we keep costs proportionate. If you need full on-site delivery, we will discuss it openly.
How do you handle handover so our team is not left stranded?
Handover is built in from the start, not tacked on at the end. We document as we go, work alongside your team during delivery, and run knowledge-transfer sessions before we close out. If your team does not understand what we built by the last day, the engagement was shaped wrong.
What does your delivery approach actually look like day-to-day?
Weekly written progress updates. A log of every architectural decision. The build kept as written, repeatable blueprints in your own repository from day one. Regular working sessions with your team. You see the work take shape and can challenge it early, because surprises at the end are the expensive kind.
How do you measure whether an engagement has been successful?
Against criteria we agree with you at the start: specific and measurable. For a platform build, that is typically completeness, rule compliance and a documented handover. For cost work, it is measured savings with no loss of reliability. We report against those criteria rather than marking our own homework.
Will we be working with a sales team or with the engineers?
With the engineers, from the first technical conversation. We have no dedicated sales function. Your first call is with the people who would lead your engagement, so the conversation is honest from the start. If your problem is not a good fit, you will hear that directly.
Azure landing zones
Foundations, governance, and platform architecture on Azure.
What is an Azure Landing Zone and do we actually need one?
It is the secure, well-organised set-up that sits underneath everything you run in Azure: who can do what, how things are grouped, how the network is laid out, and what gets logged. Microsoft calls this a landing zone. If you plan to run more than a handful of systems in Azure, building it early prevents the mess that is much harder to fix later.
What's the difference between a landing zone and Microsoft's Cloud Adoption Framework?
The Cloud Adoption Framework (CAF) is the method: Microsoft's full guidance for moving to Azure responsibly. A landing zone is what you build by following it. We design and deploy the real thing, not a slide deck about it.
Can you retrofit a landing zone onto an existing Azure environment?
Yes. We start by mapping what you already have: subscriptions, rules, network layout, sign-in set-up. Then we design the target and move existing workloads into it in phases. It is slower than starting fresh, but nothing in production gets rebuilt from scratch.
How is the landing zone actually deployed - Terraform, Bicep, or something else?
Everything is built from written, repeatable blueprints (infrastructure as code, in Terraform or Bicep depending on what your team already uses). The blueprints live in a Git repository with proper change control. That means the platform can be rebuilt, audited and improved. Nothing depends on someone having clicked the right buttons.
How long does a landing zone engagement typically take?
A full enterprise set-up takes four to eight weeks to design and deploy. Smaller or single-region environments can complete in two to four weeks. Most of that time goes on decisions, not deployment. Once the decisions are made, the build itself is largely automated.
Do landing zones handle multi-subscription governance automatically?
Yes. That is much of the point. The rules about who can do what, which regions are allowed, and what must be logged are set once, at the top. Every new subscription inherits them by default. Adding one becomes routine rather than a manual checklist.
Cloud security & compliance
Controls, standards alignment, and Defender-led hardening.
What does Rosebud's Cloud Security & Compliance service cover?
The whole picture: who can get at what, the rules that keep things safe, threat alerts through Microsoft Defender for Cloud, encryption, and ongoing checks against known standards. The goal is one set-up the platform enforces on its own. No person has to remember to check.
How is this different from adding security to an existing Azure environment later?
Security added later tends to be patchy. Some things get covered, others get missed, and it all slips over time. We build security into the platform itself. Everything new inherits the same protection by default. The platform does the enforcing, not a yearly audit.
Which security standards and frameworks do you align to?
The ones that matter to you. Typically ISO 27001, NIST CSF, CIS and the Microsoft benchmark, plus sector rules such as FCA guidance for finance or NCSC principles for the public sector. We check all the time, not once a year.
How does Microsoft Defender for Cloud fit into what you deliver?
It is one part of the answer, not all of it. We set it up to watch your whole estate for threats and weak spots, tune what it flags, and feed its alerts into your monitoring. We will also tell you plainly where Defender alone is not enough.
What does a typical cloud security engagement look like?
Most start with a review. We check your set-up against the Microsoft benchmark and your target standards, then hand you a fix list in priority order. We can make the fixes, or hand your team the playbooks. Ongoing cover comes through our Managed Cloud service.
How do you keep an Azure environment compliant over time, not just at point of delivery?
It slips the moment the project ends. So we set up rules and alerts that surface a problem the day it happens, not six months later in an audit. Where it is safe, the rules go further: a bad change is blocked or fixed on its own, so it never takes hold.
DevSecOps
Security embedded in Azure DevOps and GitHub Actions pipelines.
What does DevSecOps actually mean in an Azure context?
It means security checks are built into the way software is released, not bolted on afterwards. In Azure that covers automatic rule enforcement, passwords and keys kept in a vault, scanning code for known weaknesses, and compliance checks before anything reaches production. Security becomes part of the release, not a separate review.
How is DevSecOps different from regular DevOps?
DevOps is about releasing software quickly and reliably. DevSecOps keeps that speed and adds security at every stage. In practice, the security tools run automatically alongside every build. Problems are caught by the developer the moment they appear, not by a security team weeks later.
Which CI/CD platforms do you work with?
Mainly Azure DevOps and GitHub Actions, which covers most Azure teams. The patterns we set up are portable, so the same approach moves with you if you change tools later. We adapt to what your team already uses rather than making you switch.
How do you handle secrets and credentials in pipelines?
Passwords and keys live in Azure Key Vault and are supplied only at the moment they are needed. They are never stored in files, settings or code. Access is limited to the minimum required and every use is logged. This all but removes the whole category of leaked-password incidents.
What vulnerability scanning and policy enforcement do you typically set up?
The standard set: code checked for weaknesses, open-source libraries checked against known problems, container images scanned, infrastructure blueprints validated against your rules, and a scan that catches passwords committed by mistake. A release with a critical finding cannot go to production without an explicit, logged override.
Can you integrate with existing pipelines, or do we need to rebuild?
We work with what you have wherever possible. Most engagements add security stages to your existing releases one at a time, so your team keeps shipping while the controls mature. A full rebuild is only needed when the existing set-up is fundamentally unsuitable, which is rare.
Cloud optimisation & FinOps
Reducing Azure spend without compromising reliability.
Does cloud optimisation mean cost reduction, performance tuning, or both?
Both, and they are usually linked. Cutting cost means right-sizing machines, paying less for capacity you know you need, and removing things nobody uses. Improving performance means fixing the expensive design mistakes. The same inefficiencies cause both problems, so a well-tuned environment usually costs less and runs better.
What kind of Azure cost reduction is realistic?
Most untuned Azure environments carry 20 to 40 percent of avoidable spend: idle resources, oversized machines, unused storage, missed discounts. The first pass recovers most of that within a few weeks. Beyond that, a further 10 to 20 percent usually comes from redesigning the most expensive workloads.
What is FinOps and how does it fit in?
FinOps is the routine that keeps cloud costs under control after the clean-up: finance, engineering and operations sharing one view of what is being spent and why, built into everyday work. The one-off optimisation removes today's waste. FinOps stops the next round from building up. Without it, costs tend to climb straight back.
How quickly can we expect to see savings?
The first wave usually shows up in your next bill, often within four weeks: right-sizing the obvious waste, applying discounts, removing orphans. The deeper, design-level savings take one to three months as workloads are reworked. We do the quick wins first so they pay for the deeper work.
Can you reduce costs without affecting reliability or performance?
Yes, when it is done properly. Every change is reviewed and tested against your performance and availability baselines before it ships. We never save money by removing back-ups, shrinking capacity below real demand, or weakening resilience. A saving that creates operational risk is not a saving. It is a deferred incident.
Managed cloud & security support
Ongoing operations, monitoring, and platform improvement.
What does your managed cloud service actually cover?
The day-to-day running of your Azure platform: watching it 24/7, handling incidents, patching, backups, security upkeep, cost control, and steady improvements. You get a stable platform that keeps getting better, without doing the work in-house. You pay for what you need.
How is this different from a traditional managed service provider?
Most providers wait for something to break, then fix it. We keep improving the platform so things break less often. Safe fixes get automated. Every incident becomes a lesson that makes the set-up stronger. Running it, plus improving it, not just break-fix.
What SLAs do you offer?
Response times are put in writing, by severity. A critical incident is answered within 15 minutes. A major one within an hour. Routine requests within one business day. Fix times depend on the problem, so we agree those with you rather than making generic promises. We report against it all monthly.
Do you replace our internal team or work alongside them?
Either. Some clients have us run the whole platform. Others keep their own team and use us for out-of-hours cover, specialist input, or extra hands in busy periods. We agree the split at the start, so who owns what, and who calls whom, is never in doubt.
Can you manage an environment you didn’t build?
Yes. Most of our managed work starts with a platform someone else built. We begin by mapping it: find the risks, write the runbooks, connect our monitoring. Anything serious we find is raised openly, with a plan to fix it. Nothing gets quietly buried.
How do you handle incident response out of hours?
An on-call rota covers every hour of every day, and the right engineer is woken for the right problem. Every incident is logged and looked into, with a written review for anything serious. Your call goes to an engineer who knows your set-up, not a generic help desk.
Advisory & consulting
Strategic input without open-ended implementation.
What does Azure advisory actually cover?
Advice rather than building. Cloud strategy, big design choices, how your team should run, which suppliers to pick, and honest reviews of what you already have. We are the senior second opinion for IT leaders who want direction before they commit.
How is advisory different from your other services?
Our other services deliver things: a secure Azure set-up, a security baseline, a managed platform. Advisory delivers decisions. It fits when the next step is not "build something" but "decide something": which way to go, whether a design will hold, what the risks are.
Who do you typically work with inside the client organisation?
The people who own the decision: IT directors, CTOs, heads of platform, architects, programme leads. We can present to a board, and we can go deep with your technical people. The work is shaped around wherever the decision sits.
Are you genuinely independent, given you are Microsoft-certified?
Yes. The certification proves skill, not a sales deal. We earn nothing for recommending Microsoft products, and we often advise against parts of the Microsoft stack when they are the wrong fit. We start from your goals. The tools follow.
What does a typical advisory engagement look like?
Short, focused blocks. A two-to-four-week design review, a six-week strategy piece, or an on-call arrangement for questions as they come up. You get a written report, plus sessions to test the conclusions with your team. Nothing open-ended, nothing that drifts.