Outsourcing software development from Vermont

Vermont outsourcing at a glance

This table is operating triage, not a conclusion that a particular company, product, supplier, dataset, transaction, or incident is covered. The current statute uses defined terms and activity-specific exclusions. Act 138 changes that framework on a future effective date. A qualified reviewer should apply the enacted text to the real facts; the delivery system should preserve those facts without making the supplier the final legal authority.

The distinct Vermont model: a data-provenance and purchaser-purpose gate

Many outsourcing questionnaires begin too late. They ask whether a provider encrypts “customer data” after the team has already accepted a dataset, connected an enrichment API, copied a public-record file, or enabled an AI feature that sends content to another system. Vermont’s data-broker framework suggests an earlier and more useful operating question: where did the information come from, who has the relationship, and what is this purchaser or user actually allowed to do with it?

Build one gate with four inputs:

1. First-party relationship data. The buyer collected the information through a real customer, user, worker, applicant, donor, investor, contractor, or other relationship. Record the relationship and the notice, permission, contract, expectation, and sector context that support the proposed use.
2. Buyer-provided operational data. A client, affiliate, partner, or internal team supplied it. That fact does not prove unrestricted use. Record ownership or licensing, instructions, purpose, restrictions, onward-transfer authority, residency, and the return or deletion state.
3. Public business or professional information. Current Vermont law excludes publicly available information from “brokered personal information” only to the extent it relates to a consumer’s business or profession. “Found online” is not a universal permission. Record the source, the field, the public context, the collection method, terms, accuracy, proposed combination, and applicable law.
4. Brokered, licensed, inferred, or enriched data. Identify the upstream broker or source, original collection, categories, derivation, license, chain of recipients, consumer relationship, credentialing, stated use, prohibitions, rights, retention, and incident route before the data enters a product, model, campaign, or decision.

Each input produces a dataset source card. The card reaches an identity-and-purpose checkpoint before data is available to an international team or AI system.

The gate can approve, approve with constraints, quarantine for more evidence, or reject. It should never convert an unknown source into an approved source because a sprint deadline is close. A purpose change, new purchaser, new model provider, added field, expanded geography, or different downstream disclosure reopens the gate.

Classify the actual data operation, not the provider’s label

“AI vendor,” “research partner,” “lead generation company,” “analytics platform,” “public-data provider,” and “software development agency” are commercial labels. They do not decide whether a business or business unit knowingly collects and sells or licenses brokered personal information about Vermont consumers with whom it lacks a direct relationship.

The current § 2430 definition points to facts. Examples of a direct relationship include a past or present customer, client, subscriber, user, registered user, employee, contractor, agent, investor, or donor relationship. The current text also lists activities that do not qualify a business as a data broker when collection and sale or licensing are incidental to those activities, including specified platform, directory, professional-public-information, and health or safety alert activity. Its “sells or licenses” definition also contains stated exceptions.

Do not stretch an example into a conclusion. Prepare a role memo for each entity and unit:

• legal entity, affiliate, business unit, product, domain, and contracting party;
• categories and approximate Vermont-consumer population method;
• how information is collected, created, inferred, purchased, received, combined, and updated;
• what is sold, licensed, disclosed, accessed, or made available, to whom, and for what value;
• the direct relationship, if any, for the consumer and the exact entity conducting the activity;
• every possible statutory exclusion and the facts supporting or limiting it;
• whether the activity is ordinary conduct or merely incidental;
• supplier, subprocessor, model, and purchaser roles;
• current registration search and filing evidence where applicable; and
• reviewer, decision date, assumptions, open questions, and triggers for reassessment.

An outsourcing provider might only build buyer-controlled software with synthetic data. It might instead license enrichment data into its own service, assemble training data for multiple customers, operate a reusable audience product, or permit customers to query a shared dataset. Those patterns are materially different. Contract language should follow the real pattern rather than asserting that every provider is “only a processor” regardless of its independent collection or use.

Registration is a lifecycle, not a badge

Under current § 2446, a person that met the data-broker definition during a year registers annually with the Vermont Secretary of State on or before January 31 of the following year, pays the stated $100 fee, and provides the listed information. Current disclosures address business contact information, available opt-outs, activities or sales from which consumers cannot opt out, whether purchaser credentialing is implemented, prior-year breaches and affected consumers if known, and practices concerning minors when the broker has actual knowledge it possesses their brokered information.

The Secretary of State’s maintained Business Services portal exposes a Data Broker Search. A buyer can use it as evidence, but a search result is not a universal endorsement of a product, provider, dataset, security program, contract, or proposed purpose. It is one dated fact.

For a provider that may be covered, assign:

• a role owner who monitors product, dataset, relationship, and transaction changes;
• a renewal calendar and evidence repository;
• an owner for every public disclosure and its supporting operation;
• purchaser-credentialing documentation and periodic tests;
• incident and minors-data reporting inputs;
• change review when a new source, customer type, use, country, API, model, or affiliate is added; and
• a buyer communication path when registration status or a material disclosure changes.

The 2027 transition changes this lifecycle substantially. Keep those changes in the dated transition section below.

Translate Vermont’s data-broker security program into outsourced delivery

Current § 2447 requires a covered data broker to develop, implement, and maintain a written comprehensive information security program with administrative, technical, and physical safeguards appropriate to the business, resources, stored data, and need for security and confidentiality. Its minimum features are unusually operational for supplier governance.

The current text includes designated employees; foreseeable-risk identification and assessment; ongoing training including temporary and contract employees; compliance; failure detection; policies for storage, access, and transportation outside business premises; disciplinary measures; terminated-employee controls; reasonable selection and retention of capable third-party service providers; contractual security requirements for those providers; physical restrictions; regular monitoring and upgrades; at least annual and material-change review; incident documentation; and mandatory post-incident review. Computer-system requirements address authentication, access controls, encryption, monitoring, portable devices, firewalls, patches, security software, and related safeguards to the extent technically feasible.

Turn that into a delivery control matrix.

The contract should require outcomes and evidence, not merely “industry-standard security.” A small provider may use different tooling from a large one, but the buyer still needs to know which system enforces each safeguard, who receives an alert, what happens when a control fails, and how the end state is proven.

Keep the supplier alert faster than the legal conclusion

Current Vermont breach operation distinguishes the data collector that owns or licenses information from a collector that maintains or possesses information it does not own or license. Under § 2435, the maintainer path calls for notice to the owner or licensee immediately following discovery of a security breach, subject to the text’s law-enforcement provisions. The owner or licensee path addresses consumer notice in the most expedient time possible and without unreasonable delay, with a 45-day outer limit under the stated conditions. The regulator path includes a preliminary description within 14 business days of discovery or consumer notice, whichever is sooner, with the Attorney General or Department of Financial Regulation selected as the statute specifies.

Those are legal paths, not good supplier alert SLAs. A provider should alert the buyer on a credible agreed signal—potential unauthorized access, suspicious export, lost device, exposed credential, integrity loss, misdirected dataset, or compromised subprocessor—without waiting to declare that Vermont law applies. The buyer retains the qualified decisions about breach, ownership, residents, scope, regulator, law enforcement, consumer notice, content, and timing.

Use a progressive incident capsule:

1. Signal capsule: discovery time and time zone, reporter, system, identity, initial behavior, containment already taken, and urgent authority needed.
2. Scope capsule: affected environments, fields, dataset versions, locations, accounts, processors, logs, preservation state, and Vermont-resident hypothesis.
3. Acquisition capsule: evidence relevant to access, acquisition, possession, copying, use, exposure, encryption, credential impact, and uncertainty.
4. Decision capsule: owner/licensee and maintainer roles, qualified decision owners, regulator route, affected population method, law-enforcement status, notices, customer commitments, insurer, and communications.
5. Recovery capsule: clean-state evidence, credential and secret rotation, corrected controls, restoration, monitoring, customer action, after-action findings, and retained artifacts.

Do not put the phrase “within 45 days” in a supplier contract as if it were permission to wait. The Attorney General’s guidance emphasizes that the statutory outer limit does not replace the requirement to act in the most expedient time possible and without unreasonable delay. The provider alert should create decision time, not consume it.

Build the January 1, 2027 Act 138 transition separately

Vermont H.211 became Act 138 after gubernatorial approval on June 16, 2026. The enacted effective-date section makes sections 1 and 4 effective January 1, 2027; the study and appropriation sections take effect July 1, 2026. This guide therefore treats the substantive data-broker amendments as future requirements during 2026.

Act 138’s enacted section 1 changes the information and relationship perimeter, adds a purchaser/user control in § 2431, adds a separate data-broker security-breach operation in § 2436, and changes registration. Among the enacted changes for January 1, 2027 are:

• a broader brokered-personal-information concept that includes derived data and unique identifiers linked or reasonably linkable to a person, device, or household, while retaining the stated public business/profession treatment;
• clarification of the direct-relationship concept, including that directly collecting information does not by itself necessarily establish the relationship described in the amended text;
• a requirement for a data broker to obtain a prospective purchaser’s or user’s identity and intended use, require certification, independently verify identity, and prohibit disclosure when the prospective use is illegal or materially different from the stated purpose;
• a separate data-broker breach section with its own consumer, Attorney General, law-enforcement, fact, and no-misuse-determination operation;
• registration within 30 days after meeting the definition and annually by July 1, a $900 registration fee, and a $20,000 bond;
• expanded registration disclosures, including categories, specified prior-year sharing or sale recipients, whether information was shared or sold to a developer of a generative AI system, privacy and bond information, deletion or opt-out access, and Fair Credit Reporting Act status; and
• a Secretary of State public downloadable spreadsheet described by the enacted text.

Read the exact enacted text for qualifications and defined terms. Do not turn this summary into a checklist detached from the statute.

A five-workstream transition calendar

Workstream 1: classification and lineage. By design review, inventory raw, observed, purchased, inferred, scored, linked, device, household, professional, and public elements. Reassess direct relationships for the exact entity and operation. Identify business units that could independently meet the definition. Map datasets used for model training, retrieval, evaluation, personalization, fraud, identity, sales, recruiting, advertising, analytics, and customer support.

Workstream 2: purchaser identity and stated purpose. Create a workflow that verifies the prospective purchaser or user, captures a specific intended use, collects certification, evaluates legality and policy, blocks materially different use, and retains the evidence. API keys and payment cards are not sufficient identity or purpose verification by themselves. Connect contract purpose, technical scopes, query controls, output restrictions, monitoring, and account enforcement.

Workstream 3: registration and public truth. Prepare the changed timing, fee, bond, categories, recipient classes, generative-AI developer disclosure, privacy policy, deletion or opt-out page, FCRA statement, and downloadable-public-record consequences. Every public field needs an operational owner and source of truth. Rehearse correction when a disclosure becomes inaccurate.

Workstream 4: separate data-broker incident operation. Map the future § 2436 route independently from current § 2435. The enacted text contains a 45-day consumer outer period, a preliminary Attorney General notice within 14 business days after discovery, population and notice-copy delivery when consumer notices are sent, law-enforcement delay treatment, and a no-misuse determination path subject to Attorney General review. Build the evidence and decision workflow before the effective date; do not apply the future section to a 2026 event merely because software is ready early.

Workstream 5: supplier and AI controls. Update provider terms, dataset source cards, model and subprocessor registers, purchaser verification, intended-use enforcement, prohibited use, monitoring, audit evidence, incident cooperation, deletion, and exit. Test whether a supplier can introduce a new dataset, model endpoint, enrichment provider, or secondary purpose without reopening approval. It should not be able to do so silently.

Design AI work around provenance, not a “public data” shortcut

AI projects magnify lineage problems because data may be copied, normalized, embedded, labeled, augmented, cached, evaluated, or used to tune a system. A provider may describe the source as “public,” “licensed,” “customer supplied,” or “synthetic,” but the buyer needs field-level proof and a defined purpose.

For each AI dataset or connector, record:

• source entity, source URL or agreement, acquisition date, collection method, version, and license;
• raw fields, inferred or derived fields, identifiers, linkage, household or device relationships, and sensitive elements;
• whether business or professional public information is separated from other personal information;
• direct-relationship facts for the buyer, provider, source, and downstream user;
• training, retrieval, evaluation, safety testing, analytics, support, and retention uses independently;
• model and tool providers, regions, logging settings, human review, prompt and output storage, and secondary use;
• quality, representativeness, freshness, correction, dispute, opt-out, deletion, and suppression processes;
• who may purchase, query, export, or receive results and what identity and purpose controls apply;
• attack surfaces such as prompt injection, poisoned data, membership inference, credential exposure, and unauthorized bulk extraction; and
• disposition of raw data, derived features, embeddings, fine-tuned weights, caches, logs, evaluation sets, and backups at exit.

A source that is permitted for one research purpose may not be permitted for sales targeting, automated decisions, model training, publication, or resale. A purpose statement such as “business analytics” is too broad to constrain engineering. Write a falsifiable purpose: named user, named dataset, named operation, named output, prohibited consequences, duration, and acceptance test.

Use a buyer-controlled AI release gate:

1. provenance and license accepted;
2. field and relationship classification accepted;
3. purchaser/user and purpose accepted;
4. privacy, sector, export, security, and customer-contract review complete;
5. restricted environment, identities, models, tools, and logs configured;
6. quality, abuse, leakage, rights, and deletion tests passed;
7. human and automated decision authority documented;
8. release canary and rollback approved; and
9. evidence and exit packet complete.

The Oregon outsourcing guide uses a complementary purpose-and-evidence model for processor operations. Vermont’s distinct contribution is the upstream source, relationship, broker, purchaser, and future-use gate.

Choose an international delivery model that preserves buyer authority

Country selection should follow the work package. It should not substitute a national stereotype for named-person and system evidence.

Vermont uses the America/New_York IANA zone. Record each contributor city and maintained zone; do not write “Eastern time” or “five hours ahead” as if offsets never change. Colombia can provide practical overlap for discovery and incident collaboration. Mexico offers multiple location-specific zones and should be scheduled by city. Poland can support a morning handoff into Vermont. India or the Philippines can create an overnight build-and-review rhythm if instructions, evidence, and authority are strong. These are planning hypotheses, not promises about a country or provider.

For each named contributor verify capability, employment or contracting chain, legal entity, location, sustainable schedule, communication, language, tool access, data role, security, retention, continuity, price, intellectual-property assignment, and exit. Use destination-country primary sources and qualified advice for employment, tax, export, privacy, and IP questions. A Vermont choice-of-law clause does not automatically resolve assignment or enforceability in every place work occurs.

Write the RFP around evidence-generating scenarios

Ask candidates to demonstrate a small scenario rather than respond “yes” to broad controls.

Include these requirements:

• the exact legal entity, business units, delivery locations, named roles, employment chain, and subprocessors;
• all provider-supplied, buyer-supplied, licensed, public, inferred, synthetic, and model-related data sources;
• the provider’s direct-relationship and data-broker classification process without asking it to give the buyer legal advice;
• current Vermont registration evidence if the provider represents that registration is applicable or complete;
• written security-program controls relevant to the actual work, including supplier flow-downs;
• unique identities, least privilege, MFA, devices, repositories, build and deployment paths, encryption, logs, monitoring, and vulnerability handling;
• immediate operational alert, evidence preservation, update cadence, owner/licensor support, and regulator/consumer decision assistance;
• a separate January 1, 2027 transition answer for Act 138 if the engagement will continue across the date;
• purchaser identity, intended-use, verification, certification, prohibited-use, and change-control design where applicable;
• AI model, training, retrieval, logging, region, secondary-use, human-review, and exit details;
• intellectual-property chain, third-party materials, open-source policy, provenance, acceptance, and escrow or continuity needs; and
• return, deletion, derivative, embedding, backup, access, secret, subprocessor, and restoration evidence at exit.

Run at least these scenarios:

1. A developer finds a prospect dataset in an online repository and wants to use it in a demo.
2. An enrichment provider adds inferred attributes and changes its upstream source.
3. A model provider changes prompt or output retention and secondary-training terms.
4. A purchaser proposes a materially different use after account verification.
5. A Vermont consumer record is disputed across source, buyer, provider, cache, and model index.
6. Suspicious export occurs near the end of the Vermont workday while the owner/licensor question is unresolved.
7. A temporary contractor leaves during an active incident investigation.
8. The same service crosses January 1, 2027 and the registration and incident workflows must switch without mixing clocks.
9. A provider fails, is acquired, or exits while data and derived artifacts remain in several regions.

Score the provider on the evidence it produces, the accuracy of its unknowns, and the buyer’s ability to stop or reverse the work. The provider scorecard can structure the comparison, while the outsourcing RFP guide helps convert requirements into verifiable responses.

Start with a representative paid pilot

A useful Vermont pilot is not a marketing mockup built on mystery data. Choose a narrow workflow that exercises source, purpose, engineering, security, incident, and exit controls.

For example, build a synthetic-data customer-support retrieval service with one approved public business-information connector and one simulated licensed enrichment source. Require:

• one source card per input and derivative;
• a verified purchaser identity and specific intended-purpose record;
• a quarantined path for an unknown source;
• a controlled repository, reproducible build, tests, dependency record, and buyer release;
• role-based access, encryption, logging, export limits, and monitored privileged action;
• an opt-out or deletion propagation test across source, cache, index, output, and backup schedule;
• an upstream source-change event that reopens approval;
• an incident exercise beginning with a provider signal and producing progressive buyer evidence;
• a 2026/current-law playbook and a separately labeled 2027/Act 138 future-state playbook; and
• a full exit showing repository, infrastructure, credentials, data, derivatives, logs, documentation, and recovery.

Pilot acceptance should include functionality, security, data quality, lineage accuracy, accessibility, performance, observability, documentation, IP provenance, cost, maintainability, incident response, rights support, and exit. Reject the pilot if the provider cannot explain where data came from, who may use it, or how to remove it—even when the interface looks complete.

Contract clauses must map to the operating system

An outsourcing agreement should state:

• entities, services, systems, environments, datasets, users, work locations, and order of precedence;
• owner, licensee, maintainer, independent-use, data-broker, purchaser, user, processor, and subprocessor facts without forcing inaccurate labels;
• documented instructions and a prohibition on unapproved collection, enrichment, combination, sale, license, disclosure, model use, or purpose change;
• dataset source cards and evidence required before acceptance;
• identity and intended-purpose controls, including future-state changes that activate on the agreed date where applicable;
• security-program outcomes, named responsibility, training, identity, access, encryption, monitoring, patching, devices, physical controls, continuity, and annual/material-change review;
• immediate operational incident alert, preservation, containment authority, scheduled facts, cooperation, communication control, and post-incident action;
• buyer ownership of Vermont applicability, regulator, law-enforcement, consumer, customer, insurer, and public-notice decisions;
• registration, disclosure, bond, or public-record obligations only when supported by the applicable facts and dates;
• subprocessor approval, flow-down, location, source, model, tool, and control changes;
• deliverable ownership, background IP, third-party materials, open source, training data, model artifacts, moral-rights treatment, and assignment evidence;
• service levels, acceptance, defects, vulnerabilities, cost changes, audit evidence, insurance, liability, indemnity, and survival; and
• suspension, transition, repository and infrastructure transfer, data return or destruction, derivative treatment, backup aging, access revocation, secret rotation, restoration test, and final acceptance.

Do not promise “Vermont compliance” as a single deliverable. Specify the facts, operations, evidence, decision owners, and review dates that make the relationship governable.

Common Vermont outsourcing mistakes

• Treating anything viewable online as unrestricted “public data.”
• Assuming direct collection automatically creates the relevant direct relationship.
• Calling a provider a processor while permitting independent enrichment, reuse, licensing, or model training.
• Searching the data-broker registry once and treating the result as certification or permanent status.
• Asking whether purchaser credentialing exists without testing identity, purpose, verification, rejection, and change.
• Quoting Act 138’s 2027 registration, bond, disclosure, or breach operation as current during 2026.
• Using the current 45-day outer period as the supplier’s incident-alert deadline.
• Letting an international provider decide Vermont breach applicability or contact consumers without buyer authority.
• Listing encryption without identifying data paths, devices, keys, logs, exceptions, and recovery.
• Approving an AI model while leaving dataset lineage, prompt/output retention, secondary use, or embeddings undefined.
• Allowing a new source, field, purchaser, purpose, model, subprocessor, or country without reopening approval.
• Assuming a globally distributed team is resilient without testing personnel, cloud, identity, telecom, and decision concentration.
• Accepting a low rate without modeling management, security, data licensing, rework, continuity, transition, and exit cost.
• Ending an engagement by deleting accounts but not proving the state of raw data, derivatives, features, embeddings, caches, backups, secrets, or recovery dependencies.

Frequently asked questions

Can a Vermont company outsource software development overseas?

Yes. The decision depends on the actual project, data, systems, industry, customers, contracts, security, export, employment, tax, IP, and destination-country facts. Use named work locations, limited access, buyer-controlled release, evidence, and exit rather than assuming every international project has the same risk.

Is every software or AI provider a Vermont data broker?

No. Current law uses defined collection, sale or licensing, brokered-information, consumer, direct-relationship, entity, and activity facts. A provider building buyer-controlled code with synthetic data differs from a provider independently licensing a reusable personal-data product. Classify the actual entity, unit, source, relationship, and operation with qualified review.

Does publicly available information fall outside Vermont’s current definition?

The current definition states an exclusion for publicly available information to the extent it relates to a consumer’s business or profession. That is not a general license for all information found online or for every collection, combination, use, disclosure, or jurisdiction. Preserve the exact source, field, context, terms, method, purpose, and review.

What must a covered Vermont data broker do about outside service providers?

Current § 2447 includes reasonable steps to select and retain third-party service providers capable of maintaining appropriate security measures and requiring them by contract to implement and maintain appropriate security. The wider security program also contains training, access, monitoring, encryption, incident, and review features that should be traced into the actual delivery system.

When should an outsourced provider report a possible incident?

At the agreed earliest credible operational threshold—before a final legal conclusion. Current Vermont law contains separate owner/licensee, maintainer, regulator, consumer, and law-enforcement provisions. An immediate provider-to-buyer alert preserves time for the buyer’s qualified analysis and any applicable statutory path.

Is Vermont Act 138 already effective?

It is enacted. The substantive amendments in sections 1 and 4 take effect January 1, 2027; the study and appropriation sections took effect July 1, 2026. During 2026, prepare the transition but do not describe the future purchaser-purpose, registration, bond, disclosure, or separate data-broker-breach provisions as current obligations.

Why does Act 138 matter to an AI outsourcing project?

The enacted amendments address derived data, identifiers, purchaser or user identity and intended use, verification, prohibited disclosure for illegal or materially different use, and registration disclosure concerning sharing or sale to a developer of a generative AI system. An AI project should therefore make dataset lineage, model use, purchaser purpose, change control, and exit technically enforceable before the effective date where applicable.

Which country is best for a Vermont software team?

There is no universal best country. Compare named people and locations against capability, overlap, communication, data access, security, retention, continuity, total cost, IP chain, and exit. Nearshore teams can support live collaboration; a carefully designed offshore team can support an asynchronous cycle. The architecture and evidence matter more than the label.

Should the provider receive production data during the pilot?

Usually begin with synthetic, minimized, masked, or otherwise approved data. If production data is necessary, document why, limit fields and identities, isolate the environment, monitor access and export, test deletion, and require buyer acceptance. A pilot should reduce uncertainty rather than create an untracked production copy.

How often should the Vermont control model be reviewed?

Review it on a scheduled cadence and after material changes: new datasets, purchasers, purposes, models, APIs, subprocessors, countries, systems, mergers, incidents, or law. A possible covered data broker should also align review with its security-program and registration lifecycle. Act 138 requires a specific transition review before January 1, 2027.

A practical buyer checklist

• Name the buyer, contracting provider, affiliates, business units, contributors, cities, legal relationships, and subprocessors.
• Create a source card for every material dataset and derivative.
• Record the consumer relationship for the exact entity and operation.
• Classify provider and buyer activities against current Vermont definitions and exclusions.
• Verify current registration facts where applicable and retain dated evidence.
• Translate the written security program into supplier selection, contract, access, encryption, monitoring, incident, review, and exit proof.
• Establish an immediate supplier alert and progressive evidence capsule.
• Keep buyer authority over role, breach, regulator, law-enforcement, consumer, customer, insurer, and public decisions.
• Build a separate January 1, 2027 Act 138 crosswalk and transition calendar.
• Test purchaser identity, intended purpose, certification, verification, rejection, purpose change, and evidence retention for the future state where applicable.
• Record AI dataset, model, logging, training, region, human-review, and derivative disposition facts.
• Run source-change, rights, incident, contractor-exit, transition-date, and provider-failure scenarios.
• Pilot representative work with synthetic or approved data and buyer-controlled release.
• Verify assignment, third-party materials, open source, and destination-country IP evidence.
• Complete an exit exercise covering code, infrastructure, raw and derived data, embeddings, logs, backups, access, secrets, subprocessors, restoration, and acceptance.

Decision rule

Proceed when the buyer can trace every material dataset from source to approved purchaser and purpose; explain the direct relationship and provider role; verify current registration and security-program facts where applicable; receive an immediate, decision-ready incident capsule; keep current § 2435 and future § 2436 operations separated by effective date; and recover or end the service without depending on hidden supplier access, data, or knowledge.

Pause when source, relationship, license, purchaser, purpose, model use, work location, access, registration status, security control, incident authority, effective date, IP chain, or exit state is unknown.

Reject when a provider relies on opaque data, resists purpose limits, introduces unapproved sources or models, treats a registry entry as certification, quotes future law as current, waits for legal certainty before alerting the buyer, cannot produce control evidence, or cannot prove the return or deletion of data and derivatives.

The strongest Vermont outsourcing arrangement is not the one that promises access to the most data. It is the one in which the buyer can prove where information came from, who may use it, for what purpose, under which dated rules, through which controlled system, with what evidence, and how that authority ends.