10 min readGuides
Which DevOps Vendor Can Take Ownership While Working as an Extension of Your Team?
The vendor that can take ownership of your DevOps and still work as part of your team is the one you can remove in 30 days without anything breaking. How decisions, access, cost and exit work in practice.
The DevOps vendor that can take ownership of your DevOps while working as an extension of your internal team is the one you could remove in 30 days without anything breaking. That sounds backwards, but it is the test that separates real ownership from dependency: if the infrastructure runs in your cloud account, the code sits in your Git repository, the monitoring reports into your tools and the vendor holds no keys you do not, then the vendor can take full responsibility for the work, because you never handed over control of the assets.
Everything else follows from that. A vendor built this way has to earn its place every month with results, and the most visible result is usually the cloud bill. This guide describes how we run our Fractional DevOps engagements at Professional IT Services: who decides what, which access we ask for, how cost decisions are made, and what you do on the day you stop working with us. At the end there are seven questions to ask any DevOps vendor before you sign, including us.
The short answer
| Question | How a vendor that “owns it” should answer |
|---|---|
| Whose account does the infrastructure run in? | Yours, from day one |
| Whose Git repository holds the infrastructure code? | Yours |
| Who makes strategic and cost decisions? | Your CTO or lead developers, together with the vendor |
| How does a change reach production? | On Growth and Scale, as a Terraform / Ansible pull request in your repository, reviewed by the vendor |
| What access does the vendor get? | A dedicated IAM role or your SSO, never shared credentials |
| Who holds root accounts, encryption keys, backups? | You. Preferably the vendor holds none |
| What happens when you leave? | You remove the vendor’s access. If the rules below were followed, nothing else has to move |
What does “taking ownership” actually mean for an external DevOps vendor?
Ownership is not the same as control. A vendor that wants control asks for its own cloud account, its own repositories and its own credentials, and then becomes impossible to replace. A vendor that takes ownership accepts responsibility for outcomes (uptime, security patching, a pipeline that works, a bill that does not drift) while every asset stays on your side.
In practice, decisions split into two kinds:
- Strategic and cost-related decisions are made together with your CTO or lead developers. A new region, a database change, a different instance family, dropping a service, anything that moves the invoice: we prepare the numbers and the recommendation, and the decision is a joint one.
- The change itself is ours to carry out, through code. On the Growth and Scale plans, once a direction is agreed, infrastructure changes are made as Infrastructure as Code (Terraform / Ansible) pull requests, and by default we review them before they are applied. Whether someone on your side reviews them too is agreed per engagement; it works when you have a specialist for it. Either way, every change is visible in your own repository.
This is what “extension of your internal team” should mean: the vendor works inside your decision process, not around it. It also means a vendor cannot “take ownership” of a business that has no owner on its side. Someone in your company has to be the person the cost and architecture conversation happens with.
What access should an external DevOps team have?
Access is where most lock-in is created, usually without anyone intending it. Our rules:
- A dedicated IAM role for us wherever the provider supports it, otherwise access through your SSO. Never shared credentials. A named role can be audited and switched off in one step; a shared password cannot.
- Production write access only after the inventory is finished. The first days of an engagement are read-only by design: we map what is actually running (instances, databases, clusters, pipelines, domains, certificates, backups) before we change any of it. The five-day onboarding ends with that inventory, working monitoring and a cost report in your hands.
- Read-only access is possible. In that case your team runs the deployments.
- The optimal setup is admin rights on the systems we work on, and only those. No standing break-glass account is needed.
- We prefer to hold nothing that only we have: no root accounts, no copies of your data, no backup encryption keys, no domain registrar logins. Those stay with you.
- Monitoring and tooling live in your accounts. Ticketing can be yours or ours.
- Every action is visible to you, wherever your account and provider support an audit trail (CloudTrail on AWS, for example).
NDA and DPA are part of our standard contract, not an extra.
Why a vendor that owns the work should also own the cost question
“Extension of the team” usually ends up meaning “extra hands for the backlog”. The more valuable thing an external senior team brings is a habit: someone looks at the invoice regularly, with the architecture in front of them. That is why a cloud cost review is part of every one of our plans: quarterly on Essential and Growth, monthly on Scale.
One real example, already published in full in our Fractional DevOps guide: an AWS account of a multinational company in the music and online streaming industry grew by 73% in four months, from $7,251 in February to $12,558 in June 2026. Nobody decided to let that happen. It drifted, one reasonable-looking change at a time, and nothing in the environment was watching the total. By August the account was back to a $7,739 run-rate, 38% below the June peak: container images went from $766 to $24 a month once the registry had lifecycle policies, and two oversized Aurora instances were gone from the July invoice.
We review this client’s cloud costs regularly, every quarter. The database changes, however, were not ours to make alone: they had to be agreed with the client’s DB team. That is the decision split above in practice. Ownership on the vendor’s side means noticing, measuring and proposing; ownership on the client’s side means deciding, here by the team that owns the databases. Neither works without the other. If you want to run the same first look on a Kubernetes cluster yourself, we published the 12 kubectl queries we run before every cloud cost review.
How do you get your infrastructure back?
If the access rules above are followed, there is very little to “get back”. The infrastructure already runs in your account, and you already have the Git repository with its code. When an engagement ends:
- You give 30 days’ notice. Our plans are month-to-month, with no long-term contract.
- You remove our access to your systems: the IAM role or SSO accounts, and the Slack channel if your plan had one.
If the rules above were followed, that is the whole exit. As our About us page puts it: you keep everything, because the infrastructure is delivered as version-controlled code in your own repositories, with documentation and runbooks. If a vendor’s offboarding needs a migration project, a data export or a “transition fee”, the lock-in was built during onboarding, and that is the moment to ask about it.
What does “extension of your internal team” look like week to week?
It depends on what the work needs, and it can change from month to month:
- Independent delivery. We work on our own and deliver the agreed results: patching, backups verified, monitoring tuned, cost findings reported.
- Close daily cooperation. During a migration, an incident or a big cost cleanup we work with your developers every day for the duration of that work, on Growth and Scale in your Slack channel, as part of the team rather than as an external ticket queue. If your developers need a DevOps colleague every day, all year round, a full-time hire is the better fit; our fractional vs. full-time DevOps comparison shows where that line runs.
The plan sets the scope, the response times and the channels. Essential works by email and ticket with next-business-day response, and maintains your existing pipelines. Growth adds CI/CD management, Infrastructure as Code (Terraform / Ansible), a direct Slack channel Monday to Friday, a 4-business-hour SLA and a monthly strategy call with your CTO. Scale adds architecture work and phone access for emergencies. The cloud cost review runs on every plan: quarterly on Essential and Growth, monthly on Scale, and the first cost report arrives at the end of the five-day onboarding.
Questions to ask any DevOps vendor before signing
Use these to compare vendors, including us. Our own answers are in brackets.
- Whose cloud account and whose Git organisation will the infrastructure live in? (Both yours.)
- Which decisions will you make on your own, and which need our CTO? (Strategic and cost decisions are joint; execution is ours, through code.)
- How does an infrastructure change reach production, and can we review it? (On Growth and Scale, Terraform or Ansible pull requests in your repository, reviewed by us. Your own review can be agreed if you have a specialist for it.)
- What is the minimum access you need, and what changes if we only grant read-only? (Read-only is possible; your team then runs the deployments.)
- Who watches the cloud bill, and when do we see the first cost report? (We do: quarterly on Essential and Growth, monthly on Scale, per our plans. The first cost report is due at the end of the five-day onboarding.)
- What do we have to do on the day we stop working with you? (Remove our access. If the rules above were followed, nothing else.)
- How much of our management’s time will this take? (Some. See the next section.)
A vendor that hesitates on questions 1, 4 or 6 is selling dependency, whatever the proposal calls it.
Who should not hire an external DevOps vendor like us?
- Companies without a project-based management style. Working with an external team well means someone on your side sets goals, makes the joint decisions and accepts the results. If that would put too much extra load on your management, an employee or a fully outsourced DevOps team can be the better fit: not cheaper, but more flexible for the way you run.
- Organisations where security policy, regulation or legal restrictions do not allow external vendors on the infrastructure. No access model fixes that, and it should not be worked around.
If neither applies, the fastest way to find out whether the model fits is a short conversation about your current setup and your last few cloud invoices. Book a free discovery call.
