SEC-01
Least-privilege access
Each integration gets the narrowest scope that lets the work function. Nothing more.
Stage 04 · RunManaged cloud
Someone has to own the infrastructure at 3am
Cloud is not a service you buy once. It is an ongoing set of decisions about cost, access, capacity and recovery — and it degrades quietly when nobody is making them.
- Access stays in your accounts
- Every change on record
- Written, auditable deliverables
- C01Inventory what existsIn scope
- C02Fix access before anything elseIn scope
- C03Monitor what a customer would noticeIn scope
- C04Prove the restoreIn scope
- C05Patch on a rhythmIn scope
- C06Review cost as an operational habitIn scope
In short
Managed cloud means someone is accountable for the infrastructure a business runs on: monitoring and alerting, patching and dependency upgrades, backups with restores that are actually tested, access control and secrets, capacity and cost, and incident response when something breaks. The distinguishing question is not which provider you are on — it is whether a specific person is responsible when a restore is needed, and whether anyone has proved the restore works.
- 5
- Warning signals
- that say this is the work
- 6
- Controlled steps
- each ships something you keep
- 4
- Written refusals
- lines we do not cross
Self-audit
Signals this is the work
Tick the ones that are true where you are. Nothing is sent anywhere — the answer is for you, not for us.
If more than one of these is true today, the problem is usually further along than it looks from the outside. That is not a sales line; it is what the cost of waiting does.
Readiness checklistManaged cloud
0 of 5 true
Nothing ticked yet.
How we do it
The sequence
Each step ships something you keep. You can stop after any of them and still be better off than when you started.
Start with step one- 01
Step 1 of 6
Inventory what exists
Every running resource, what it costs, what depends on it and whether anything still needs it. This alone usually pays for itself.
- 02
Step 2 of 6
Fix access before anything else
Named accounts, least privilege, secrets out of code and config, and an offboarding path that has been walked through once.
- 03
Step 3 of 6
Monitor what a customer would notice
Alerting on the symptoms that matter, tuned to the point where an alert firing means something. A noisy monitor is worse than none.
- 04
Step 4 of 6
Prove the restore
Backups are verified by restoring them, on a schedule, into a working environment. Until that has happened the backup is an assumption.
- 05
Step 5 of 6
Patch on a rhythm
Predictable maintenance rather than emergency response, with a rollback path for each change.
- 06
Step 6 of 6
Review cost as an operational habit
Right-sizing, commitments, unused resources and storage tiers reviewed regularly, with the savings shown rather than claimed.
Assurance
Secured and auditable by default
These controls apply to every engagement, including this one. They are engineering decisions, not a certificate on a wall — and you can check each of them.
SEC-02
Credentials in your name
Accounts and keys live in your tenancy. You can revoke any of them without asking us.
SEC-03
Every change logged
Changes, deployments and incidents leave a written trail you can audit.
SEC-04
Restores tested, not assumed
A backup only counts once it has been restored. We test, and we report the result.
SEC-05
Separate environments
Development never touches production credentials or unmasked customer data.
SEC-06
A documented exit
Runbooks written as we go. Leaving means revoking our access — nothing is held back.
What we will not do
The refusals
The things we turn down are a better description of how we work than the things we sell.
Standing commitmentsManaged cloud
- 01
We will not: Migrate to a different provider to fix a problem that is about how the system is built.
- 02
We will not: Run Kubernetes because it is expected, on a workload that does not need it.
- 03
We will not: Report uptime while backups have never been restore-tested.
- 04
We will not: Mark up cloud spend. Your accounts, your billing relationship, our fee separately.
Questions
Before you ask
Anything else, ask on the first call. There is no charge for working out whether this is the right fit.
Talk about a problemDo you replace our internal team?
Usually not. The common arrangement is that we cover the operational floor — monitoring, patching, backups, incidents, cost — so an internal team can spend its time on the product rather than on keeping the lights on. Where there is no internal team, we can be the whole function.
Which cloud providers do you work with?
AWS, Azure and Google Cloud, and ordinary virtual machines where that is genuinely the right answer. Provider choice matters far less than most vendors suggest; how the system is built and operated on it matters far more.
What does managed cloud cost?
Cloud spend stays in your own accounts at cost, with no markup, so you keep the billing relationship and the visibility. Our fee is separate and scoped to the environment: how many systems, what recovery expectations, and whether there is out-of-hours cover. You see both numbers separately, which is the only way to tell whether either is reasonable.
Can you take over a system you did not build?
Yes, and it is a large part of what we do. It starts with an assessment: what is running, what the risks are, and what has to be fixed before we can responsibly say we are covering it. That assessment is honest about anything we would want changed before taking responsibility.
Tell us what isn’t working.
One process, one system, one decision you are stuck on. An engineer replies within one working day with how we would approach it, and whether it needs building at all.