Cloud Consulting Services: What Should You Own When They Leave?

Most cloud consulting services end the way they began: with a deck. This one says the landing zone is live, the pipelines are green and the runbooks are in Confluence. Three months later somebody needs to add a region, and the Terraform state is in a bucket nobody on your side can list, in an AWS account the consultancy owns.

That is the shape we see most often when we take over an account another firm built. Not bad work. Work that was never handed over, because nobody wrote down what handing over meant.

Our position: judge a consultancy by what is in your name on the last day, not by the deck on the first. Four things must be yours before the final invoice is paid: the management account, the audit trail, the state bucket and the commit history. Put them in the statement of work as acceptance criteria and the rest tends to sort itself out.

Why is the last day of cloud consulting services the one that matters?

Because a consultancy leaves and a managed service provider stays, and most fintechs buy the first while thinking of the second. The vendor that stays gets in through a role you own; that argument is in the post on how an AWS managed service provider should get into your account. A consulting engagement has an end date, and on that date the people who know how the account works walk out of it. Whatever only they could do is now something nobody can do.

The regulator has noticed. The RBI's 2025 outsourcing directions for NBFCs put "cloud computing services" and "IT infrastructure management" in scope (paragraph 5(1)), require "essential capacity with required skillsets within the NBFC for proper oversight of outsourced services" (paragraph 63(vii)), and require an exit strategy whose alternatives may include "performing the service by a different service provider, or by the NBFC itself" (paragraphs 84 to 86). Read those against a landing zone only the consultancy can change. The contract side is in the RBI outsourcing contract post; this is the engineering that makes those clauses true.

Who owns the management account?

You do, or the engagement has already gone wrong. AWS's best practices for the management account say to "periodically review the personnel within your business who have access to the email address, password, MFA, and phone number associated with it". Your business. If the root email is at the consultancy's domain, or the MFA device is in a drawer in their office, that review fails before it starts.

So the root email of every account is a group address at your domain, and the root MFA is a hardware key held by your finance or security lead, not by anyone who deploys. Then the SCP that stops member accounts walking out of the organisation. The same page says organisations created through the console after 10 July 2026 get a deny on organizations:LeaveOrganization and account:CloseAccount at the root automatically; anything older, or created by CLI or CloudFormation, has to attach it by hand. Most fintech organisations are older than July.

Where does the audit trail land, and who can switch it off?

In a bucket in your logging account, in ap-south-1, written by an organisation trail. The CloudTrail documentation is specific about why: users in member accounts "do not have sufficient permissions to delete organization trails, turn logging on or off, change what types of events are logged, or otherwise change an organization trail in any way". So the trail the consultancy's engineers worked under is one they could not quietly pause, and it keeps logging after they leave, because it is attached to the organisation rather than to a person.

A trail per account does neither of those things, and it is how you end up paying for CloudTrail twice, the first line item in the post on reducing a fintech's AWS bill. One organisation trail, multi-region, in your logging account, is the deliverable.

Whose account holds the Terraform state?

The state file is the account. Whoever can read it sees every resource and, unless someone has been careful, every secret that passed through a resource attribute; whoever can write it can make the next apply destroy production. HashiCorp's S3 backend documentation recommends bucket versioning "to allow for state recovery in the case of accidental deletions and human error", server-side encryption, and locking with use_lockfile rather than the DynamoDB table, which is now deprecated.

None of which helps if the bucket is in the consultancy's account. We have taken over engagements where the handover of the state consisted of being told the bucket's name. The state bucket lives in your account, encrypted with your key, versioned, with the lock file next to it, and the consultancy's role is one more principal on the bucket policy that you remove on the last day. The pipeline is the same: it runs in your repositories and reaches AWS through a role in your account, so the last engineer leaving does not stop Monday's deploy. The OIDC shape for GitHub Actions is in the checkout-change post.

Whose name is on the commits?

This is the one nobody puts in a statement of work, and it predicts the rest. Count the author domains in the infrastructure repository. If every commit is from the consultancy, your team has not reviewed a change in months and could not, on the last day, say why any of it is the way it is. The knowledge left with the authors.

The fix is a review rule, not a training day. From the first week, every infrastructure change needs an approval from someone at your company, and the consultancy does not merge its own pull requests. That is slower. It is also the only way the capacity in paragraph 63(vii) comes to exist, because reviewing a change is how a person learns an account. A consultancy that pushes back on this is telling you what it thinks of handover.

Has the DR drill been run, or only designed?

Designed is the usual answer. A second region exists in the Terraform, the snapshots are copied, and the runbook says "fail over". Nobody has done it. The RBI Cybersecurity Directions 2026 want, for Chapter V NBFCs, DR drills at least half-yearly (paragraph 129), with the DR site run as primary for a full working day (paragraph 131); what that looks like on AWS is in the post on the 2026 direction.

The first drill is the acceptance test for the DR work, and it belongs inside the engagement, not after it. It always finds things: a Lambda that hard-codes the region, a KMS key that was never replicated, a DNS TTL of an hour. Those are cheaper to find while the people who built it are still on the contract. Ask for the drill report, with timings, as a deliverable.

What should the statement of work say?

Acceptance criteria, each one checkable by your team without the consultancy present. Ours, for a fintech landing zone on AWS:

• Every root email is at the client's domain; root MFA is a hardware key held by a named client employee.
• An SCP at the organisation root denies organizations:LeaveOrganization and account:CloseAccount.
• One multi-region organisation trail, delivered to the client's logging account in ap-south-1, retained for CERT-In's 180 days.
• Terraform state in a client-owned bucket: versioned, encrypted with a client-owned KMS key, locked with use_lockfile.
• Pipelines run in the client's repositories and assume roles through OIDC. No access keys in CI secrets.
• A client engineer has approved every infrastructure pull request since week one.
• One DR drill run to completion, with a report of what broke and what was fixed.
• On the last day the client removes the consultancy's roles and bucket policy entries, and the credential report shows nothing left behind.

Eight lines. A consultancy that has done this before will add to the list rather than argue with it.

What can you run on Monday?

Four commands with read access to the organisation, and one against the repository:

aws organizations describe-organization \
  --query 'Organization.[Id,MasterAccountId,MasterAccountEmail]' --output text

aws cloudtrail describe-trails --include-shadow-trails \
  --query 'trailList[].[Name,IsOrganizationTrail,IsMultiRegionTrail,S3BucketName]' \
  --output table

aws s3api get-bucket-location  --bucket "$STATE_BUCKET"
aws s3api get-bucket-versioning --bucket "$STATE_BUCKET"

git log --format='%ae' | sed 's/.*@//' | sort | uniq -c | sort -rn

The first prints the management account's email; if the domain is not yours, start there. The second lists every trail, including the organisation trail copied into this account; you want one row with True in both flags and a bucket you own. If either bucket command is denied, the state is not yours, and that is the finding. The last is the commit histogram; if your domain is not on it, the handover has not started, whatever the deck says.

When is a consultant leaving nothing behind the honest answer?

When the engagement is advice, and was bought as advice. A two-week review that produces a findings document and a prioritised list is a legitimate consulting engagement; our own audit is exactly that. The list above applies when the consultancy builds something. It also does not fit the team of three with nobody to review pull requests yet, the case in the hire-or-partner comparison. There the honest answer is a retained partner, not a project that ends on a date with nobody to hand to.

The short version

Before you sign for cloud consulting services, write the last day into the statement of work. The management account, the organisation trail, the state bucket and the pipelines are in your name, and your engineers have approved every change since the first week. The DR drill has been run, not designed. Then run the commands above on the last day, before the final invoice, and remove the consultancy's access yourself.

If a proposal in front of you has a start date, a deck and no acceptance criteria, that is the finding. We will sign the list above as written; ask the others to.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.