The question usually arrives as a whole sentence rather than a term: "what happens to our infrastructure knowledge if a fractional devops contract ends". It is asked by a founder or a first engineering lead who has already worked out that a fractional arrangement is cheaper and faster than three hires, and who is now looking hard at the other side of the deal. If one person outside the company holds the working picture of how production runs, what is left standing on the day that person stops answering messages?
Most vendor content will not answer it. The usual reply is a reassurance about documentation and a sentence about partnership, which is not an answer because it cannot be checked. A reassurance you cannot test on a Tuesday afternoon is worth nothing on the Tuesday afternoon you need it.
So this post answers it as nine artefacts, each one a thing that either exists in your own systems or does not. Every item carries the same test: it still works after the vendor's access is revoked and nobody answers the phone. Where I am giving a practitioner read rather than citing a document, it is labelled inline.
Quick context: the risk is not that they leave, it is where the work was kept
Every infrastructure arrangement ends. A hire resigns, a managed service provider gets replaced at renewal, a fractional retainer runs its term. The difference between an ending that costs a week and one that costs a quarter is not loyalty or notice period. It is whether the work accumulated inside your accounts and repositories, or inside someone else's laptop and head.
Which makes this a day-one question rather than a last-day one. Almost every artefact below is free to demand at the start and expensive to reconstruct at the end. A vendor who builds the right way produces them as a side effect of the work; one who does not will correctly tell you that writing them retroactively is a separate invoice.
What happens to our infrastructure knowledge if a fractional DevOps contract ends
If the engagement was built correctly, nothing happens to it, because the vendor never held it. The knowledge lives as nine artefacts inside systems your company owns: the infrastructure definition in your repository, the cloud accounts under your organisation, vendor access as a role you can delete, a credential inventory with last-used evidence, a runbook per paging alert, decision records explaining the estate, monitoring defined as code, a processor contract where personal data is involved, and an exit clause with a handover window.
1. The infrastructure definition is in your repository, the state is in your account
The estate should be described in code living in a repository inside your version control organisation, not the vendor's, and the state that code works against should sit in storage inside your cloud account. The second half is the one people miss.
HashiCorp's backend documentation is blunt about what state is: accessing remote state generally requires credentials because state data contains extremely sensitive information, and the local .terraform directory may itself hold backend credentials, which is why it should not be committed to version control. The same page recommends backing state up manually before migrating to a new backend (HashiCorp, Terraform backend configuration).
If state lives in the vendor's bucket or their own Terraform Cloud organisation, then on the last day you own a repository full of code that no longer knows what it created. Practitioner opinion: run the test quarterly, not at the end. Your own engineer, on their own laptop, clones your repository, authenticates to your account, runs a plan, and gets a clean no-changes result.
Takeaway: ask where the state lives before you ask what the code covers.
2. The accounts, and the root of them, belong to the company
Cloud accounts have an owner of record, and it is startlingly common for that to be a personal email address belonging to whoever set things up first. AWS documents that you can remove a member account from an organisation only if it carries the information required to operate standalone: a chosen support plan, verified contact information and a current payment method, none collected automatically for accounts created through the Organizations console or API.
Two further details from that page belong in a contract. An account acting as delegated administrator for any service must hand that role to an account which is staying before it can leave. And removing an account does not delete the IAM roles the management account created for access into it, so cutting that access is a manual deletion you perform yourself (AWS Organizations user guide, removing a member account).
Practitioner opinion: the management account is yours, billing is yours, root emails are on your domain in a shared mailbox, and the vendor was never owner of record for anything.
Takeaway: root email on your domain and management account in your organisation, before the first deployment.
3. The vendor's access is a role you created and can delete in one action
How a fractional team reaches your infrastructure decides how long offboarding takes. Insist on a role in your own account that the vendor assumes, with an external ID in the trust policy. AWS documents the external ID as an identifier whose primary function is to prevent the confused deputy problem, which it describes as an entity without permission to perform an action coercing a more privileged entity into performing it (AWS IAM, the confused deputy problem).
Two specifics are easy to get wrong. The external ID is not a secret: AWS states it does not treat it as one and that anyone permitted to view the role can see it. And Well-Architected guidance advises a randomly generated unique value such as a UUID, because an ID reused across a vendor's customers gives away the protection it exists to provide (AWS Well-Architected, SEC03-BP09, and AWS IAM on third-party access).
What this buys at the end is a one-line offboarding. The anti-pattern is a named IAM user with long-lived access keys, because then offboarding is a hunt you can never be sure finished.
Takeaway: if revoking vendor access takes more than deleting one role, the access was built wrong.
4. A credential inventory, with last-used evidence rather than an assurance
The exit conversation always includes a sentence like "there is nothing of ours left in your account". Ask for the artefact that proves it. AWS can generate a credential report listing, per access key, the date it was last used and the service and Region it was used against.
Read it knowing the limits AWS documents. The last-used fields show N/A when the key does not exist, has never been used, or was last used before tracking began on 22 April 2015. When a key is used more than once within fifteen minutes, only the first use in that window is recorded. And the report covers IAM users, not roles, so it is one half of the picture (AWS IAM, credential reports).
Practitioner opinion: demand a report generated after the handover date, read with a list of the roles the vendor could assume. A dated report showing no vendor credential used after handover is a finding you can hand to an auditor or a customer's security reviewer.
Takeaway: closure is evidenced by a dated credential report, not by a confirmation email.
5. One runbook for every alert that actually pages a human
Documentation requests fail because they are unbounded. "Please document everything" produces either nothing or a wiki nobody opens. A bounded version works: for every alert that wakes somebody up, a page saying what it means, the first three checks, the safe mitigation, and when to escalate. The count is the specification. Twelve paging alerts means twelve runbooks.
Google publishes the on-call chapter of its Site Reliability Workbook free (sre.google, The Site Reliability Workbook), the best public starting point for what operational readiness means on a small team. Practitioner opinion on shape: a runbook is written for the person who did not build the system and is reading it at 02:00, so no unexplained acronyms and exact commands rather than descriptions of commands.
The test is not that the files exist, it is that someone on your side who did not write them can follow one to the end during a drill. Run it while the vendor is still engaged, when a gap is cheap to fix.
Takeaway: count your paging alerts, then demand that many runbooks and one drill.
6. Decision records, because the configuration does not explain itself
Infrastructure as code tells you what the estate is. It rarely tells you why, and why is the expensive part to lose. Six months after an engagement ends, the question that stalls your new hire is whether the odd-looking thing in front of them is load-bearing or leftover.
The established answer is an architecture decision record: a short file per significant decision, with a status, the context, the decision and its consequences. The format comes from Michael Nygard's 2011 article and is now widely adopted, including as published guidance in the UK government's engineering standards (GDS Way, architecture decisions, and adr.github.io). Statuses in Nygard's template include proposed, accepted, rejected, deprecated and superseded, which is what lets a reader tell a live decision from a dead one.
Practitioner opinion: a small estate needs ten to twenty, not a hundred, in the same repository as the code so they move with it. The ones worth recording had a visible alternative.
Takeaway: ask for records of decisions that had a plausible alternative, and nothing else.
7. Monitoring and alerting defined as code, in your tenancy
Dashboards built by hand in a console are the most common piece of infrastructure knowledge that silently belongs to whoever built them, because they are invisible in the repository.
The fix is that alerting rules and dashboards are text files in your repository, applied by your pipeline, pointed at monitoring under your own billing. Prometheus alerting rules, for instance, are plain configuration files loaded from paths listed in the server's config (Prometheus, alerting rules), so every threshold is reviewable in a pull request and recoverable from version control.
Practitioner opinion: the day-one question is whose account receives the alert. If pages route through the vendor's tooling, then on the last day the estate goes quiet rather than healthy, and quiet is far more dangerous than noisy. Route to your own on-call tool from the start, with the vendor added as a responder, never the owner.
Takeaway: if you cannot see an alert rule in a pull request, you do not own it.
8. A processor contract, if any of this touches personal data
Infrastructure work usually means access to systems holding customer data, which drags the arrangement into data protection law. For an Indian company the instrument is the Digital Personal Data Protection Act, 2023, whose section 8 is headed general obligations of Data Fiduciary in the official text on India Code (Act No. 22 of 2023). Indian law-firm readings of section 8(2) are consistent that a Data Fiduciary may engage a processor only under a valid contract, so a purchase order silent on personal data does not satisfy it, and that accountability for the whole chain stays with the Fiduciary (Treelife on fiduciary and processor duties). Verify against the Act and Rules before a negotiation.
The exit-relevant part is deletion. A processor contract silent on what happens to data at termination leaves the question you most need answered unanswered. A published summary of the Monetary Authority of Singapore's outsourcing notices records that on termination, customer information should be disposed of or rendered unusable (PwC Singapore on the MAS notices).
Takeaway: write the deletion obligation into the contract, and collect the dated confirmation at exit.
9. The exit clause: a handover window, and a definition of done
This is the artefact that makes the other eight enforceable. Most fractional contracts carry a notice period and nothing else, so the commercial relationship has an ending and the operational one does not.
Regulators who have thought hardest about this treat the exit plan as a standing document rather than a termination step. The Reserve Bank of India's Master Direction on Outsourcing of Information Technology Services, RBI/2023-24/102 dated 10 April 2023, carries a dedicated chapter headed Exit Strategy at paragraph 22 (RBI Master Direction). In the European Union, Article 28(8) of Regulation (EU) 2022/2554 requires exit plans that are comprehensive, documented, and sufficiently tested and reviewed periodically, and requires that a firm can exit without disruption to its business activities, without breaching regulatory requirements, and without detriment to continuity and quality of service to clients (Regulation (EU) 2022/2554). ISO/IEC 27001:2022 control 5.20 covers supplier agreements, and practitioner summaries of its guidance list handover procedures, information destruction and termination provisions among its suggested topics (ISMS.online on control 5.20). SOC 2 criterion CC9.2 asks an entity to assess and manage vendor risk, with terminating the relationship among its published points of focus (AICPA).
None of those rules binds an unregulated seed-stage startup, which is why they are useful: four independent bodies writing for institutions that cannot afford a bad exit landed on the same structure, and you can copy it for the price of a clause.
A vague exit clause against a usable one
The difference is testability. The decision rule: a clause that does not name a deliverable, an owner and a date will not survive a bad ending.
| Vague clause | Usable clause |
|---|
| "Reasonable assistance with transition." | "A 30-day handover window after notice, delivering the artefacts in Schedule A." |
| "Documentation will be provided." | "One runbook per paging alert, plus decision records, in the client's repository." |
| "Access will be removed on termination." | "Client deletes the vendor role; vendor provides a credential report dated after the handover date." |
| "Data will be handled appropriately." | "Dated written confirmation of deletion of client data held outside client systems, within 14 days." |
| Nothing about readiness until termination. | "One handover drill per quarter, run by a client engineer, findings logged." |
Takeaway: a clause without a deliverable, an owner and a date is a sentiment, not a protection.
The nine artefacts, and how to test each one
| Artefact | Where it must live | The test you can run today |
|---|
| Infrastructure as code | Your version control organisation | Your engineer runs a plan, gets no changes |
| Infrastructure state | Storage in your cloud account | You can list the state object yourself |
| Account ownership | Your organisation, root email on your domain | No delegated admin or billing with the vendor |
| Vendor access | A role in your account with an external ID | Deleting one role removes all vendor access |
| Credential inventory | Generated from your account | A credential report dated after handover |
| Runbooks | Your repository, one per paging alert | Your engineer completes a drill unaided |
| Decision records | Your repository, alongside the code | A new hire tells live decisions from dead ones |
| Monitoring and alerting | Code in your repository, your tenancy | Alert thresholds visible in a pull request |
| Processor contract and exit clause | Signed, with a schedule of artefacts | The clause names a deliverable, owner and date |
What to insist on at your stage (practitioner opinion)
Pre-seed, under ten people. Four items and no more, because asking for nine on a small retainer buys documentation instead of engineering. Code and state in your accounts, account and billing ownership in your name, vendor access as one deletable role, and a runbook per paging alert. That covers the failure that actually hurts at this size: a production incident nobody in the building can work through.
Seed, with paying customers and a first security questionnaire. Add the credential inventory, the processor contract, and the exit clause with a handover window. Customer security reviews start asking who has access to their data and what happens when that changes, and a signed clause with a schedule is the fastest honest answer.
Series A, or regulated from the start. All nine, plus the quarterly drill and a dated review of the exit plan, because this is where the expectations above start applying to you directly, or through a customer already bound by them.
If you want this checked rather than read, MatrixGard runs a free 20-minute review for early-stage founders: which of the nine artefacts your setup actually has, where the single-person dependency sits, and what to put in the next contract. No NDA for the first conversation. Send a note.
Avinash S is the founder of MatrixGard. Fractional DevSecOps for early-stage startups, funded or bootstrapped across India, the GCC, the UK, and the US. Almost a decade of building, breaking, and securing cloud infrastructure for fintech, healthtech, and SaaS workloads.
Methodology note. This post answers what happens to our infrastructure knowledge if a fractional devops contract ends by listing artefacts and a test for each, not by citing any engagement of ours. Terraform state behaviour is from HashiCorp's backend documentation. The standalone-account requirements, the delegated administrator condition and the fact that removal does not delete IAM roles created by the management account are from the AWS Organizations user guide. External ID behaviour is from the AWS IAM confused deputy and third-party access pages and Well-Architected SEC03-BP09. Credential report fields, the 22 April 2015 tracking start and the users-not-roles scope are from the AWS IAM credential reports page. The DPDP section heading is from the India Code text of Act No. 22 of 2023; the reading of section 8(2) is Indian law-firm commentary, labelled as such. The ISO 27001 control 5.20 guidance topics and the MAS disposal expectation come from practitioner summaries rather than the primary texts and are attributed inline; check both before relying on them. Artefact counts, drill cadence, stage sequencing and the clause comparison are practitioner opinion. No client outcome, price or testimonial appears in this post.
