Chapter 7: The Adoption Doctrine

The first principle

First American, a title-insurance company, built its own application, EaglePro, for sharing document images between the parties to a property transaction.¹ The application had a vulnerability that exposed more than eight hundred million title and escrow document images going back to 2003, including social security numbers and financial information. The company's own information security personnel had already found the vulnerability, in a manual test, about five months earlier. They had written it up. It was not remediated in line with the company's own policy, and senior executives were not told. The SEC charged the company not over the breach but over the controls: it found the firm had violated the requirement to maintain disclosure controls and procedures, and ordered a penalty of about four hundred and eighty-seven thousand dollars.

A bespoke component sat at the centre. Around it the firm ran a private control, its own testing and its own remediation policy, and the private control failed silently: the finding went in one end and nothing came out the other, and no external tripwire caught the gap. Under an externally audited standard such as ISO 27001, a known, documented, unremediated vulnerability of that severity is exactly what the audit is designed to surface, and the certificate is exactly what the firm would have had to keep by fixing it. The bespoke component was the weakness. The private control was the cover that let the weakness sit.

Never invent what can be adopted. When a control, a standard, a contract, or a piece of infrastructure already exists as a maintained public artifact, the practitioner adopts it and does not build a private version. This is the adoption doctrine. It sounds modest, close to an admission that the work is unoriginal. Originality is a liability here.

The instinct it corrects is a strong one and an honourable one. A capable person who has just built a working agent, who watched it do in an afternoon what used to take a department a week, is primed to keep building. The same generative capability that produced the agent will just as readily produce a risk-scoring model, a bespoke access-control scheme, a home-grown audit format, a custom incident taxonomy. All of it will work, in the sense of running and producing output. That is exactly the trap. The question a control has to answer is whether anyone else has any reason to believe it.

The adoption that has already happened

Adopt, select, tailor: the verbs assume a decision still to be made. On the office platforms most firms already run, much of that decision has been made in the licence. Microsoft's Copilot Chat, with metered access to agents, requires no Copilot licence,² and the same Microsoft 365 tenants allow any user to create agents by default, the first agent created for a team provisioning a data environment of its own to hold what it builds.³ Google ships Gemini switched on by default in Workspace's enterprise editions; what the administrator holds is the power to turn it off.⁴ None of this reached the firm through anything it would recognise as an adoption decision. The capability arrived with the seat, at a licence renewal nobody read as a systems change.

So the first step, for most firms, is an inventory rather than a selection: the tenant read as it is configured, not as anyone remembers deciding it should be. A firm whose last deliberate platform decision was a renewal holds agent capabilities it never evaluated, running under defaults it never chose, and the first deliverable of an adoption exercise is the list of them. Salesforce shows the other shape: its hosted MCP servers ship inactive, and go live only when an administrator enables them in setup.⁵ Where the default is off, the enabling action is the adoption decision, and it leaves a record. Where the default is on, there is no record to find, and the inventory is reconstructing a decision nobody made.

Why the self-built component is the standing weakness

What failed at First American was not competence. The person who builds a private control may be more capable than the committee that wrote the standard. What the private control lacks is everything outside the builder. It cannot be benchmarked against peer practice, because it is a population of one: there is no answer to whether it is normal, generous, or negligent. It carries no record of prior failures, so every way it can fail has to be discovered live, on the practitioner's own clients, rather than inherited from everyone who has failed that way before. And when an auditor, an insurer, a court, or a client's risk team asks why the control is adequate, the standard-based answer points outward, to a published document maintained by a standing body, while the self-built answer points inward, to the builder, and asks to be trusted. An assurance practice exists precisely for the moment when its own say-so is not enough, and the self-built control has nothing else.

The same defect shows up in gentler form wherever a practitioner names a standard on the cover of the work and then does something bespoke inside it without saying so. A published risk-assessment case study is candid about this in a way most are not. It names ISO 27001, ISO 17799 (the predecessor to ISO 27002), and NIST as its reference frameworks. Then it computes its actual risk scores with a custom formula whose numbers, the authors say plainly, are not fixed on any known standard but are set by the organisation's own interpretation as it sees fit.⁶ The frameworks are on the letterhead. A private model is doing the deciding. It is a harder failure to see than the outright breach, because from the outside the work looks standards-based.

An analysis of the data-security enforcement actions the United States Federal Trade Commission has brought reads the expectation straight off the record. Companies are expected to use the standard assessment methods: vulnerability and penetration testing, security architecture reviews, code reviews, the ordinary and appropriate ways of checking a system.⁷ The regulator looks for the methods everyone in the field already agrees on, and treats their absence as the finding. From the enforcer's chair, a bespoke method is one more thing that has to be explained.

The work is assembly, not invention

The craft, then, is selection and combination: choosing the right published standards and fitting them to the specific system in front of you. It is real work and not lesser work, but it is different work from invention; mistaking one for the other is how practitioners end up building the liabilities the last section describes.

The United States government does not let its agencies invent their own control frameworks. NIST Special Publication 800-53 hands every agency the same mandatory baseline and a large catalogue of controls, with explicit tailoring guidance: the agency applies the baseline, then adjusts the controls to fit its own mission and operating environment, and its own risk assessment decides whether anything beyond the baseline is needed.⁸ The division of labour is the lesson. You do not invent the foundation; you adopt it whole, because it is the part thousands of others have already stress-tested. You tailor at the edges, and the tailoring is where judgment is spent and where it is worth something.

NIST's AI Risk Management Framework is built to be used that way. It is written to be voluntary, rights-preserving, not specific to any sector, and agnostic to the use case, so that it can flex to organisations of any size.⁹ A framework that general is not a checklist you tick. It is a base you tailor, and it hands you the tailoring on purpose. The generality that can read as vagueness is the standard doing its job: it supplies the structure everyone can share and leaves the fitting to the practitioner who knows the specific system. That fitting is why assembly is a craft and not clerical work.

The map of what there is to adopt

Here is the territory, by domain. The job is to know, for a given client, which squares are in scope. Most of them will be familiar to anyone who has been near a security or compliance function. That familiarity is the feature. Boring and well-known is the point.

*Information security.* The base layer is ISO 27001, the information-security management standard, and SOC 2, the service-organisation reporting framework, adopted together because they answer different audiences. ISO 27001 is externally audited on a cycle: Microsoft's public compliance record shows Azure audited once a year by a third-party accredited certification body, which is what gives the certificate its independent validation.¹⁰ The certificate itself is issued against a specific revision of the standard for a fixed window, Microsoft's current one against ISO 27001:2022 runs 2024 to 2027, so it is a maintained relationship and not a badge you earn once and keep.¹¹ What the standard supplies, beyond the controls, is the form for stating your own boundary. Derbyshire County Council's published scope document defines its information-security management system functionally, by physical locations, authorised mobile workers, and network endpoints. It states its exclusions explicitly, in that case carving out schools while covering everything else, all tied to a separate statement of applicability.¹² Writing a defensible scope, saying just what is and is not covered, is one of the harder things a practitioner does, and the standard hands over a tested template for doing it rather than leaving each firm to improvise the shape.

Alongside it sits SOC 2, whose criteria run across five named categories: security, availability, processing integrity, confidentiality, and privacy.¹³ The important property is who owns them. The criteria are established and maintained by a standing committee of the AICPA, the American accountancy body, for use by auditors reporting on an organisation's controls.¹⁴ The firm being examined does not own the yardstick it is measured against. Someone external does. That is the property adoption buys, expressed as a report a buyer already knows how to read.

*The local and regional layer.* Every market wraps this invariant core in its own law, and the standards map has to be completed, per client, with a local overlay the practitioner inventories rather than invents. In South Africa the data-protection statute is the Protection of Personal Information Act; in Europe and for anyone touching European data it is the General Data Protection Regulation; most jurisdictions now have their own, and many are adding emerging AI-specific rules on top.¹⁵ The practical instruction is to keep a checklist of the kinds of local law that attach to agent work, data protection, sector regulation, professional-body rules, employment and equality law where hiring or staff monitoring is in scope. Then run that checklist against each client's jurisdiction and industry. The named international standards are the constant. The local layer is the variable, and the discipline is the habit of always asking which local variable applies before assuming the constant is enough.

*AI management.* There is now ISO 42001, a management-system standard specifically for artificial intelligence, specifying requirements for establishing, maintaining, and continually improving an AI management system inside an organisation.¹⁶ Certification against it is underway: Microsoft's compliance page lists eight AI products in scope, GitHub Copilot and Microsoft 365 Copilot among them, though the same page's prose describes progress towards certification rather than a certificate held.¹⁷ Adopting it is not about being early. The standard for governing an AI management system already exists, maintained by ISO, the same body that maintains ISO 27001, so a practitioner who builds a private AI-governance scheme is now inventing something that has a published, audited alternative.

The companion is NIST's AI Risk Management Framework, document AI 100-1, published on 26 January 2023, which matters because a framework you cite by number and date is one an auditor can pull and check.¹⁸ It was directed by federal statute, the National Artificial Intelligence Initiative Act of 2020,¹⁹ and developed through a public process of a formal request for information, three widely attended workshops, and public comment on a concept paper and two drafts of the framework.²⁰ That process is the point. A framework with a statute behind it and a public comment record behind it carries the external audit trail the self-built framework lacks. There is a documented history of who objected to what and how it was resolved.

*Continuity.* For the question of what happens when the system is disrupted, there is ISO 22301, the business-continuity standard, defining continuity as the organisation's capability to keep delivering its products and services within acceptable timeframes, at a predefined capacity, during a disruption.²¹ It has a maintained edition history, a first edition and a later one that refactored the text without changing the substance: the standard is looked after by someone whose job is to look after it.²² Continuity is chapter 10's territory in detail. Here it is one more square on the map.

*Sanitization and exit.* On 26 September 2025, NIST withdrew Revision 1 of its media-sanitization guideline, Special Publication 800-88, which had stood since December 2014, and published Revision 2 the same day.²³ A practitioner who had cited the standard by its old number was, as of that day, citing withdrawn guidance. The guideline is the map's square for the end of an engagement: when a system is retired, data has to be destroyed in a way that can be shown to have worked, and 800-88 defines sanitization as rendering access to the target data infeasible for a given level of effort.²⁴ The withdrawal is the point here. An adopted standard maintains itself, on its own schedule, and the practitioner has to track the version. Citing a standard is a live relationship, and keeping it current is a small and known price next to the open-ended, private burden of maintaining an invented control alone.

*Contracts.* The commercial layer is adoptable too. There are open contract libraries built the same way a good standard is. Common Paper publishes commercial agreements drafted and maintained by a committee of dozens of attorneys, drawn from technology vendors, procurement teams, boutique firms, and large law firms, released free to use and modify under an open Creative Commons licence.²⁵ Another, OpenAgreements, publishes more than forty templates, cloud service agreements, non-disclosure agreements, employment documents, financing papers, under the same open licence.²⁶ These have the property adoption looks for. An external drafting body stands behind them. Adopting one means adopting a document many parties already recognise, rather than presenting a counterparty with a private draft they have to have their own lawyers reconstruct from scratch. The practitioner's contract work becomes selection and light tailoring on top of an adopted base.

*Risk transfer.* The last square is insurance, which is adoption in its purest commercial form. The market began writing cover for the AI case specifically in February 2026, when the first policy backed by an AI-agent standard went live and a coordinated structure launched the same month with dedicated AI aggregate limits of twenty-five million dollars or more.²⁷ The practitioner does not model the tail risk privately and self-fund it. They transfer it to a market whose business is pricing risk against prior losses. Cyber and professional-indemnity cover is how the residual risk that no control fully closes gets carried by a party built to carry it, and buying the cover is adopting the insurer's actuarial judgment instead of substituting your own.

The map also argues for keeping the number of adopted components low. Every adopted component carries a standing obligation: terms re-read on a cadence, a version tracked, facts that go stale between readings; the sanitization revision above is one instance. That work scales with the number of components rather than their size, so each additional sanctioned vendor is another set of terms someone must own and another set of facts that can go stale unnoticed. Standardising on fewer components is a verifiability argument before it is a cost argument. A firm can only govern the components it can keep known, and the short list is what makes that possible. Chapter 10 takes up the risk a short list carries, concentration on a few suppliers, and the portability that keeps leaving possible.

Why adoption is defensibility

The buyer of chapter 6, the person whose name is on the risk, purchases defensibility. Adoption is how defensibility is manufactured.

The clearest statement is in securities law, in the structure of the due-diligence defense. Under Section 11 of the Securities Act of 1933, the parties who prepared a registration statement, the underwriters, officers, and directors, can defend themselves against liability for a misstatement by showing they reasonably investigated and had reasonable grounds to believe the statements were accurate. The issuer itself cannot use this defense and faces strict liability.²⁸ It is not made of being right. It is made of having followed a reasonable process and being able to show it. The law offers a shield to the party who can demonstrate diligence and withholds it from the party who cannot, and diligence here means the process a reasonable professional would run, documented well enough to prove after the fact.

And the courts fill in "reasonable process" with reference to standard practice. In the analysis of underwriter liability, industry standards are treated as relevant to the reasonableness inquiry. An SEC advisory committee is on record that documenting standard processes for making professional judgments, with criteria for evaluating them after the fact, may provide an environment that promotes consistent evaluation among regulators.²⁹ The way you show you were reasonable is by showing you followed the standard method and kept the record. A practitioner who invented a private method has, at exactly the moment it matters, no standard to point to and no external practice to be measured as reasonable against. They are back to their own say-so, in the one room where their own say-so counts for least.

The market is starting to make adoption not merely defensible but mandatory. In the United States defense supply chain, the Cybersecurity Maturity Model Certification is becoming the condition of doing business at all: every entity in the chain is required to hold at least Level 1, issued by the Cyber-AB, by 2026.³⁰ Where that has happened, the self-built alternative does not lose an argument about adequacy. It never gets into the room, because the gate is the certificate. Adoption stops being the defensible choice and becomes the only choice, and the practitioner who built a private scheme has built something that cannot be presented where it counts.

The substrate doctrine

The adoption rule reaches past standards and contracts, all the way down to the infrastructure the practice runs on, and at that level it takes a specific and slightly counter-intuitive form. Call it the substrate doctrine. The infrastructure and tooling a practice builds on should be maximally boring and maximally standard, chosen for how legible they are rather than how capable they are. In particular, choose a clean programmatic surface: an ordinary application interface and a command-line interface, that can be read, scripted, and logged.

This cuts against the instinct to pick the most powerful or most modern tool. Pick the most ordinary one that does the job, the one with the longest track record, the widest documentation, the largest population of other people who have already hit its edges. Legibility beats capability at the substrate layer, because everything above it inherits the substrate's properties.

Legibility here serves three audiences at once. It serves the client, who is owed a system whose behaviour can be explained to them in terms that do not require trusting the practitioner blindly. It serves the auditor, who can only give assurance over what can be inspected, and who inspects logs, configurations, and interfaces, not intentions. And, newly, it serves the agent itself. The flagship agentic tools are built for exactly these surfaces: Anthropic documents Claude Code as an agentic tool in the terminal that reads files, runs commands, and chains with other tools in the ordinary composable way.³¹ The same clean programmatic surfaces that make a system legible to an auditor make it operable and constrainable for an agent. A boring, standard, well-documented substrate is the one a human can audit and an agent can drive. The opaque tool that is convenient for a person clicking through it is illegible to both.

The substrate choice is made once, early, and everything else, the controls, the evidentiary record, the continuity plan, is built on top of it. Get it right and the later chapters have a foundation. Get it wrong and every control above it is fighting the ground it stands on.

The principle underneath Part III

The chapters that follow apply this one principle to one control surface each, and they will not restate it. Closure controls, in chapter 8, apply it to the perimeter: agent scoping, least privilege, non-human identity, data boundaries, all adopted from established security practice rather than reinvented for the AI case, because the AI case is new but the controls that close its perimeter mostly are not. The evidentiary layer, in chapter 9, applies it to the record: durable attributed logs, replay, sampled review, reconciliation, built on standard logging and standard formats so the record is legible to the auditor it exists for. Continuity and exit, in chapter 10, apply it to the end of the engagement, using the continuity and sanitization standards mapped above.

A reader who has this chapter in hand can read each of them as a worked example: the surface, what already exists to cover it, how to adopt and tailor it, the residual left to manage. The discipline is assembled from parts that already have bodies of practice behind them, so that every claim the practitioner makes about a client's system points outward, to something an outsider can check, rather than inward, to the practitioner's own word. That is what makes the work defensible, and defensibility is the whole of what is being built.

---