Provider Evidence Requests: What to Verify at Handover

Use provider evidence requests to check exception handling, account control and acceptance tests before automation handover, with a practical worksheet.

Guide by the Otomatzia editorial team · checked against official sources on 2026-10-22

Editorial illustration for Provider Evidence Requests: What to Verify at Handover — Otomatzia editorial illustration

What should I ask a shortlisted provider to show?

Ask for a workflow inventory, an exception demonstration, a control check, a failure detection exercise and an operating handover record, each tied to the workflow you are buying rather than a generic demo. Provider evidence requests work when every claim names the artifact that proves it, who checks it, and the uncertainty it leaves behind.

This guide proposes the following worksheet. It is an editorial tool, not a certification, a standard or a legal test. Published guidance does support its direction: NIST calls for planning and due diligence before a formal supplier relationship and for critical suppliers to be assessed before acquisition NIST, Cybersecurity Framework 2.0, GV.SC-06 and ID.RA-10, February 26, 2024.

The NCSC recommends building security assurance into supply chain management, retaining a right to audit and establishing key performance indicators for security management practice UK NCSC, The principles of supply chain security, III. Check your arrangements, February 14, 2019.

CISA's Software Acquisition Guide provides a supplier questionnaire organized into five sections and supports acquisition discussions with software suppliers CISA, Software Acquisition Guide supplier questionnaire, July 2024. Those sources cover security and acquisition in general. The handover questions below, about exceptions, control and detecting wrong results, are this guide's narrower application of them.

Each request has a different job. The inventory tells you what you are actually taking on. The exception demonstration shows what happens when an input does not fit. The control check shows who can change, pause or remove the workflow after the provider steps back. The failure detection exercise shows whether anyone would notice a wrong result. The handover record shows whether another operator can run it from the documentation alone.

Workflow inventory: every step, integration, credential and data flow the workflow touches, with an owner named for each.
Exception demonstration: a rehearsal of an input that does not match, run by an operator who did not build the workflow.
Control check: proof that your organization holds administration, billing visibility, connection access and configuration exports.
Failure detection exercise: an agreed deliberate mismatch, with the expected alert or rejection written down before the run.
Operating handover record: documentation, the maintenance owner, the exception queue process and the exit arrangements.

Set the workflow boundary before requesting evidence

A proof request only means something when both sides agree what is being proved. Before you ask for any artifact, write down the business outcome the workflow must produce, the systems it connects, the input variations it must handle, the actions that cannot be undone, the person who will operate it and the environment where a rehearsal is safe. Without that boundary, a provider can show you a working demo of a different workflow and both sides will believe the evidence applies.

NIST says supplier roles and responsibilities should be established and coordinated, and cybersecurity requirements should be integrated into contracts and other agreements NIST, Cybersecurity Framework 2.0, GV.SC-02 and GV.SC-05, February 26, 2024. For a handover, the practical version is a short written boundary that both the provider and your operating owner sign before any evidence is requested.

Agree what correct behavior means

Correct behavior is a business state, not a green execution. A hypothetical invoice workflow can run without error and still post an amount to the wrong customer account. Write the expected end state in business terms: which record exists, which field holds which value, which message was or was not sent. Then list the input variations that must still reach that state: a missing reference, a duplicate submission, a late arrival, a currency the workflow does not expect.

Mark every action the workflow can take that cannot be reversed by your team: sending a message to a customer, charging a card, deleting a record, updating an external ledger. These are the points where a rehearsal must stop, and where the handover record must show a confirmation step or an approval step. Agree this list in writing so the rehearsal has a known stopping line.

Choose safe inputs and record dependencies

Use representative inputs with sensitive information removed, and agree the expected outcome for each input before the rehearsal. An input whose expected result is decided after the run proves nothing, because any result can be explained afterwards. Keep the inputs in the worksheet so the same set can be run again after a change.

Record every dependency as part of the boundary. NIST calls for inventories of software, services, systems and supplier-provided services, plus maintained representations of network communications and data flows NIST, Cybersecurity Framework 2.0, ID.AM-02 through ID.AM-04, February 26, 2024. For a single workflow, that means listing each connected platform, each credential, each lookup table or mapping and each account that the workflow runs under, with the organization that owns it today.

Write the business outcome of the workflow in a sentence a non-technical owner can verify.
List every connected system, credential, mapping and account, and name who owns each today.
List the input variations the workflow must handle, including the ones that should be rejected.
Mark every action that cannot be undone and decide where the rehearsal must stop.
Name the operating owner who will run the workflow after handover.
Agree a test environment where fabricated inputs cannot reach a real customer, payment or record.
Agree the expected result for each test input before anyone runs it.

Build a request-to-proof worksheet

The worksheet turns a conversation about trust into a record of claims and checks. Each row holds a claim, requested artifact, environment, evidence date, business owner, independent check, expected result, observed result, limitation, decision, builder help required, remediation owner and next check date. Download the editable Provider Evidence Request and Operator Rehearsal Worksheet. Its columns match the table below.

Keep the observed result column empty until someone on your team has seen the behavior. A row that is filled from the provider's description is a claim, not an observation, and the worksheet should make that difference visible. The limitation column is the most useful field: it records what the artifact cannot tell you, which is where the next request comes from.

CISA's supplier questionnaire supports acquisition discussions with software suppliers CISA, Software Acquisition Guide supplier questionnaire, July 2024. The worksheet is narrower and complements that kind of questionnaire: it records how a single workflow behaves at handover rather than how the supplier runs its business. The row below is a fabricated example and does not describe any real provider, customer or test.

Claim	Requested artifact	Environment	Evidence date	Business owner	Independent check	Expected result	Observed result	Limitation	Decision	Builder help required	Remediation owner	Next check date
Hypothetical example: unmatched orders are routed to a review queue	Operator rehearsal with a fabricated unmatched order	Safe test environment with fabricated data	Record the actual capture or observation date once evidence exists	Buyer-side operations role	Operator who did not build the workflow runs the rehearsal	Item appears in review queue with a reason and no external message	Leave blank until observed	Test environment does not exercise production payment or messaging	Unresolved pending rehearsal	Leave blank unless help is requested	Assign if unresolved	Set after rehearsal

Rendered request-to-proof worksheet with fabricated values and unresolved fields — Hypothetical worksheet record with no observed provider result

Check what each artifact actually proves

A screenshot, an exported workflow, a successful execution log and an independent operator rehearsal answer different questions, and treating them as interchangeable is how a handover goes wrong. Record, for each artifact, the claim it supports and the uncertainty it leaves. The limitation column of the worksheet exists for exactly this.

A screenshot alone does not establish when it was captured, whether the configuration remains current or whether the workflow behaves correctly. It can support an observed configuration when the buyer witnessed or corroborated the capture, but it is not execution evidence.

An exported workflow definition shows structure: which steps exist, which connections are referenced, which branches handle which conditions. It supports the inventory that NIST calls for in its asset management outcomes NIST, Cybersecurity Framework 2.0, ID.AM-02 through ID.AM-04, February 26, 2024, but it does not show that the workflow behaves as the structure suggests under real inputs.

A successful execution log can show that the platform recorded a run as completed without a platform error. It does not by itself show that the business result was correct; depending on the workflow and platform, a completed run may still write an unintended value. NIST calls for log records to be available for continuous monitoring NIST, Cybersecurity Framework 2.0, PR.DS-11, PR.PS-04 and RC.RP-05, February 26, 2024, which makes logs a useful artifact, but they must be checked against the expected business state.

An independent operator rehearsal shows whether someone other than the builder can run the workflow and handle the agreed exception. Request it explicitly. Agree the rehearsal and any continuing audit rights in the contract. NCSC guidance recommends retaining a right to audit; it does not create that right by itself UK NCSC, The principles of supply chain security, III. Check your arrangements, February 14, 2019.

Artifact	Claim it can support	What it leaves uncertain	Record in the worksheet as
Screenshot	A configuration was visible when captured	Capture time, current state and runtime behavior unless separately corroborated	Observed configuration or claim, with the evidence basis and limitation recorded
Exported workflow definition	The steps, connections and branches that exist	Behavior under real inputs, correctness of mappings	Inventory evidence
Successful execution log	The platform completed a run without error	Whether the business result was correct	Execution evidence, not acceptance
Independent operator rehearsal	Another operator can run it and handle an agreed exception	Behavior for exceptions that were not rehearsed	Observed result with the rehearsal record attached

Rehearse an unmatched item with another operator

The rehearsal is the center of this method. Take a hypothetical unmatched order: a fabricated order arrives whose customer reference matches nothing in the fabricated customer list. An operator who did not build the workflow must recognize that the exception occurred, locate its record, identify the person responsible for resolving it, select an authorized resolution and verify the resulting business state. Everything happens in the safe test environment agreed earlier, and the rehearsal stops before any real external action.

This exercise is the guide's proposal, not a published standard method. It follows the direction of NIST's call for coordinated supplier roles and responsibilities NIST, Cybersecurity Framework 2.0, GV.SC-02 and GV.SC-05, February 26, 2024, because an exception that nobody is assigned to handle is a responsibility gap, and the rehearsal is where that gap becomes visible before it costs anything.

Give the operator the documentation

Hand the operator only what the provider has delivered as handover documentation, and nothing from the builder's memory. If the operator needs to ask the builder a question, that question is a finding: record it in the worksheet's Builder help required field, assign a remediation owner and set the next check date. Treat it as a documentation defect to fix, not as a one-off. The rehearsal record should show expected behavior, the operator's actions, the observed behavior and every point where the builder had to step in.

Use the inventory from the boundary step as the operator's map. If the inventory does not tell the operator where the exception record lives, the inventory is incomplete, and that is recorded against the inventory row of the worksheet rather than against the operator.

Record each intervention and unresolved dependency

Every intervention is written down as it happens: who stepped in, what they did, and whether the operator could have done it from the documentation. Also record every dependency the rehearsal could not exercise. In the hypothetical example, if the sandbox has no live payment connector, the payment branch stays unverified, and the worksheet says so rather than marking the row as passed.

Keep the record factual and separate from judgement. Expected behavior was agreed before the run, observed behavior is what happened, and the decision comes afterwards. Mixing them in a single note is how an unresolved dependency quietly becomes an assumed success.

Confirm the intended business outcome

The rehearsal ends by checking the business state, not the execution status. In the hypothetical, the operator opens the fabricated review queue, confirms the unmatched order is there with a reason the operator can understand, confirms no fabricated customer message was generated and confirms the fabricated order record shows the status the boundary step defined. If any of these cannot be checked in the test environment, record which ones and why.

Place a fabricated unmatched order into the agreed test environment and note the time the operator starts.
Ask the operator to recognize that an exception occurred using only the delivered documentation.
Ask the operator to locate the exception record and name the person responsible for it.
Ask the operator to choose an authorized resolution from the documented options and stop before any action that would reach a real system.
Record every question to the builder and every dependency the environment could not exercise.
Check the resulting fabricated business state against the expected state agreed before the run.
Attach the rehearsal record to the worksheet row and leave the decision unresolved if any check could not be completed.

Rendered operator rehearsal record for a fabricated unmatched item — Hypothetical operator rehearsal record with unresolved dependency fields

Assign ownership of mappings and business rules

Mappings and business rules can become wrong without an obvious platform error when the business changes. A new product code, a renamed field in a connected system, a changed approval threshold or a new exception type each require someone to notice, decide and update. Handover documents describe the workflow as built and do not by themselves assign ownership of later changes.

NIST says supplier roles and responsibilities should be established and coordinated NIST, Cybersecurity Framework 2.0, GV.SC-02 and GV.SC-05, February 26, 2024, and that supplier risk should be monitored during the relationship NIST, Cybersecurity Framework 2.0, GV.SC-07, GV.SC-08 and GV.SC-10, February 26, 2024.

For a workflow, the concrete form of that monitoring is a named person reviewing the exception queue and a named person approving rule changes. The inventory of systems and data flows that NIST calls for NIST, Cybersecurity Framework 2.0, ID.AM-02 through ID.AM-04, February 26, 2024 is the list of things those people must watch.

The table below names the maintenance tasks and the decisions attached to each. Frequency and capacity are left for the parties to agree because they depend on the workflow's volume, the rate of change in connected systems and the staff available.

Maintenance task	Who proposes the change	Who approves it	Evidence kept	Frequency	Capacity needed
Mapping changes, such as a new product code or renamed field	To be agreed, provider or buyer	Buyer business owner	Change record with before and after values	To be agreed by the parties	To be agreed by the parties
Business rule approvals, such as a changed threshold	Buyer business owner	Buyer business owner with provider review of impact	Approved rule text and the date it took effect	To be agreed by the parties	To be agreed by the parties
Exception queue review	Buyer operating owner	Not applicable, this is routine operation	Operational exception log recording reviewer, action, escalation and outcome	To be agreed by the parties	To be agreed by the parties
Documentation updates after any change	Whoever made the change	Buyer operating owner	Updated handover record with a change note	After every approved change	To be agreed by the parties
Escalation when a resolution is not documented	Buyer operating owner	Buyer business owner	Escalation record naming who decided and what was done	As exceptions arise	To be agreed by the parties

Verify control after the proposed transfer

Control is practical, not contractual. A contract can say the workflow belongs to you while the administration account, the connected credentials, the billing relationship and the ability to export the configuration all sit with the provider. This guide proposes a permissioned control rehearsal: with the provider's agreement, your team checks each of these in the actual platform and records what it can and cannot do.

NIST says identities and credentials are managed by the organization, and access permissions are defined, enforced and reviewed using least privilege and separation of duties NIST, Cybersecurity Framework 2.0, PR.AA-01 and PR.AA-05, February 26, 2024. At handover, the organization in that sentence should be yours. If the provider's staff hold the only administrative identity, the credential is managed by the provider, whatever the contract says.

Transfer mechanics differ by platform and change over time. One documented example: Microsoft says a Power Automate cloud flow owner has authority to make changes and has a central role in management, control and maintenance Microsoft Learn, Change the owner of a cloud flow in Power Automate, updated September 25, 2026. That describes ownership of a flow in that product.

That Microsoft page establishes the authority attached to cloud flow ownership in that product. It does not establish the transfer state of every dependency or describe other platforms. Check current documentation and the actual account state for every dependency before relying on a transfer step.

List what must remain under organizational control

Write down what your organization must hold directly after handover: the administrative role in the automation platform's environment or tenant, visibility of the billing relationship, access to each connection the workflow uses, the ability to export the configuration and the ability to pause or disable the workflow. For each, record which account holds it today and which account must hold it after transfer. An item that must stay with the provider for a technical reason is recorded as a dependency with a named owner, not left blank.

Record platform limits and missing permissions

During the rehearsal, record every action your team could not perform and why: a role the platform does not expose, a permission that was not granted, a connection tied to an individual's account, an export that the platform does not offer. These are findings, not failures of the provider, and they need a decision: accept the dependency, change the account structure or choose a different arrangement. Platform limits are documented by the vendor, so cite the vendor's current documentation in the worksheet rather than a verbal assurance.

Confirm the next operator can perform the agreed task

The last part of the control rehearsal is practical: a named operator on your side performs an agreed task in the platform, such as pausing the workflow in the test environment, opening the run history or exporting the configuration, without the provider doing it for them. If the task requires the provider's hands, control has not transferred for that task, and the worksheet records it as unresolved.

List the administrative, billing, connection, export and pause capabilities your organization must hold after handover.
Record which account holds each capability today and which account must hold it after transfer.
Ask the provider to grant the agreed roles in the test environment and record the date granted.
Have a buyer-side operator attempt each capability and record what succeeded, what the platform does not allow and what permission is missing.
Cite the platform's current documentation for each limit found, rather than a verbal explanation.
Have the operator perform the agreed task, such as pausing the workflow or exporting its configuration, without provider assistance.
Mark each capability as held, dependent on the provider with a named owner, or unresolved.

From 07:32, a practitioner example of agreeing account location and responsibility before handover; this is not policy or proof of an Otomatzia test. YouTube channel: Elliot Gherardi

Test whether an acceptance check detects incorrect behavior

A workflow that completes every run is not the same as a workflow that produces correct results, and an acceptance check that cannot tell them apart gives false comfort. This guide proposes a negative control in the safe test environment: introduce an agreed mismatch, write down the rejection or alert you expect, run the check and record whether it detected the problem. The exercise is the guide's proposal. The published sources below support logging, audit rights and restore confirmation; they do not establish this exercise as a standard method.

NIST calls for tested backups, log records available for continuous monitoring and confirmation of restored systems and services after recovery NIST, Cybersecurity Framework 2.0, PR.DS-11, PR.PS-04 and RC.RP-05, February 26, 2024.

The NCSC recommends establishing key performance indicators for security management practice and retaining a right to audit UK NCSC, The principles of supply chain security, III. Check your arrangements, February 14, 2019. Together these make the point that detection needs logs to look at and a baseline to compare against, which is what the negative control produces.

Agree one deliberate mismatch

Pick a mismatch that reflects one plausible business error, not a platform crash. For the incorrect-total check, use an otherwise valid fabricated order with a matching customer reference and a total that does not match the sum of its fabricated line items. Run the unmatched-reference case separately. Before each run, write the specific detection you expect, the alert or rejection, who should receive it and where the record should appear. Record which check triggered in each case. If the parties cannot say what should happen, the acceptance check is not yet defined, and that is the finding.

Keep the mismatch inside the test environment and inside the stopping line from the boundary step. The point is to see whether detection works, not to see how far a wrong value can travel.

Record detection and recovery separately

Detection and recovery are different questions. Record whether the mismatch was detected, by which check, and how the result was presented to the operator. Then, as a separate check, confirm that the test environment was returned to its agreed baseline afterwards and that the fabricated wrong record did not remain. If the observation field is blank because the run has not happened, leave it blank or mark it as illustrative. Do not fill it with what the provider says would happen.

Choose a mismatch that represents a realistic business error and can be fabricated in the test environment.
Write the expected detection before the run: the check, the alert or rejection, the recipient and the record location.
Run the workflow with the mismatched input inside the agreed stopping line.
Record whether the mismatch was detected, by which check and how the operator saw it.
Record separately whether the test environment was restored to its baseline and the wrong record was removed.
Mark the row as observed only after a buyer-side person saw the result, and otherwise leave it unresolved.

Rendered acceptance record for a fabricated deliberate mismatch — Hypothetical acceptance record with observation and recovery left unresolved

Measure the manual work that remains

Automation moves work rather than removing all of it, and the exception queue is where the remaining work lives. During pre-handover testing, a rehearsal record makes that work measurable instead of assumed. During early operation after handover, use a separate operational exception log. In either record, capture the exception type, reviewer, elapsed review time, escalation, corrective action and what prevents the same exception from being created again.

Keep the measurement columns empty until the data is collected in the rehearsal or in early operation. This guide does not offer a target review time or a savings figure, because no published source gives one for a generic workflow, and a number invented here would end up in a business case. NIST's call for coordinated supplier roles and responsibilities NIST, Cybersecurity Framework 2.0, GV.SC-02 and GV.SC-05, February 26, 2024 applies: the reviewer and the escalation path are named roles, and the log is how you check they are staffed.

The NCSC's recommendation to establish key performance indicators for security management practice UK NCSC, The principles of supply chain security, III. Check your arrangements, February 14, 2019 is about security management, but the same discipline applies to the exception queue: agree what you will measure before the workflow is live, and measure it from the rehearsal onwards. The rows below are fabricated examples with no collected values.

Exception type	Reviewer	Elapsed review time	Escalated	Corrective action	Duplicate prevention
Hypothetical example: unmatched customer reference	Fictional operations reviewer	Not yet collected	To be recorded	To be recorded	To be recorded, for example a reference validation rule
Hypothetical example: order total does not match line items	Fictional operations reviewer	Not yet collected	To be recorded	To be recorded	To be recorded, for example a pre-submission total check
Hypothetical example: duplicate submission of the same fabricated order	Fictional operations reviewer	Not yet collected	To be recorded	To be recorded	To be recorded, for example an idempotency key on submission

Separate defects from maintenance and new requests

After handover, classify each change request against an agreed baseline before deciding responsibility, response or price. The baseline is the set of agreed requirements and approved changes in force on the handover date. Record demonstration status and accepted deviations separately, because an unresolved or accepted-risk worksheet row does not redefine the requirement.

NIST says cybersecurity requirements should be integrated into contracts and other agreements NIST, Cybersecurity Framework 2.0, GV.SC-02 and GV.SC-05, February 26, 2024. The same applies to change handling: the contract or statement of work should say which class each kind of request belongs to and what response and pricing terms apply.

The NCSC adds that supplier security requirements should be minimum requirements that are justified, proportionate and achievable UK NCSC, The principles of supply chain security, II. Establish control, January 28, 2018, which argues for a short classification both sides can apply rather than an exhaustive rulebook.

Compare the request with the accepted baseline

For each request, ask whether the behavior in question is required by the agreed baseline. A failure to meet that baseline is a defect subject to the contract, whether or not the same case was previously rehearsed. A mapping that was correct at handover and must change because the business changed is maintenance. A rule that did not exist at handover is a new request. A change forced by a connected platform is a category the parties must agree, because responsibility depends on who committed to track that platform.

Record responsibility before agreeing extra work

Before any extra work is agreed, record who decides the class, what evidence supports the classification and where the response and pricing terms are written. If the terms are not written anywhere, that is the first thing to resolve, and the worksheet should carry it as an unresolved row rather than letting the work proceed on assumptions. The examples below are hypothetical.

Hypothetical request	Class against the baseline	Who decides	Evidence needed	Where terms must be agreed
An agreed, rehearsed result is now wrong for the same fabricated input	Defect	Buyer business owner, with provider review	The worksheet row marked observed at handover and the current failing run record	Warranty or support terms in the contract
A product mapping must change because a fabricated product code was added	Maintenance	Buyer business owner	The change request and the before and after mapping	Maintenance terms and the ownership table
A new approval rule is added for fabricated orders above a threshold the business sets	New request	Buyer business owner	The rule text approved by the business owner	A new statement of work or a change order
A connected platform changed its interface and the workflow stopped	To be agreed by the parties	Both parties per the contract	The platform's change notice and the failing run record	Contract clause on third-party platform changes

Request recovery and exit evidence

Every handover should include evidence that the workflow can be recovered and that the relationship can end without losing control of the workflow or the data. NIST says plans should cover activities after the relationship ends and that relevant suppliers should be included in incident work NIST, Cybersecurity Framework 2.0, GV.SC-07, GV.SC-08 and GV.SC-10, February 26, 2024. For a single workflow, that means asking for backup and restoration evidence, usable exports, complete documentation, a named owner for access removal and a named exit owner.

Recovery evidence is more than a statement that backups exist. NIST calls for tested backups and for confirmation of restored systems and services after recovery NIST, Cybersecurity Framework 2.0, PR.DS-11, PR.PS-04 and RC.RP-05, February 26, 2024. Ask the provider to show, in the test environment, that an exported configuration can be restored and that the restored workflow behaves as the baseline describes. Record what was restored, what was checked afterwards and what could not be tested.

Access removal is part of exit. NIST says identities and credentials are managed by the organization, with access permissions defined, enforced and reviewed using least privilege NIST, Cybersecurity Framework 2.0, PR.AA-01 and PR.AA-05, February 26, 2024. The exit plan should name who removes the provider's access to each system in the inventory, and who confirms it was removed.

Data handling at exit depends on where you and your data are. As one jurisdiction's example, the UK ICO says a processor contract must require the processor, at the controller's choice, to return or delete personal data at the end of the contract UK ICO, What needs to be included in the contract?, accessed October 22, 2026. Record which option the parties select and how completion will be confirmed.

That describes a UK GDPR contract term. The rules that apply to your data and contracts may differ, so check them with whoever advises you on data protection, and record the requirement you adopt in the worksheet rather than assuming a retention rule. This guide does not assert compliance with any law.

Request a demonstration in the test environment that an exported configuration can be restored and behaves as the baseline describes.
Request exports of the workflow configuration, mappings and documentation in a format your team can open without the provider.
Name the person who removes the provider's access to each system in the inventory at exit, and the person who confirms removal.
Name the exit owner on your side who holds the exports, the documentation and the access removal record.
Record the data return or deletion requirement that applies to your contract, checked against the rules for your jurisdiction.
Mark each recovery and exit item as demonstrated, documented only, or unresolved.

Decide what is ready and what remains unresolved

The worksheet ends in a decision per row, not a single verdict for the provider. For each requested claim, record whether the behavior was demonstrated by a buyer-side observation, what proof is missing, what limitation the evidence carries, who owns remediation and when the next check happens. Agree release-blocking contractual, legal and safety conditions before testing. Documented risk acceptance can cover only a gap that the responsible owner has authority to accept; every other unresolved row remains a blocker.

The NCSC's recommendation to build assurance into supply chain management and retain a right to audit UK NCSC, The principles of supply chain security, III. Check your arrangements, February 14, 2019 is what makes the next check possible after handover. CISA's supplier questionnaire supports acquisition discussions with software suppliers CISA, Software Acquisition Guide supplier questionnaire, July 2024; use it for the supplier-level questions and keep this worksheet for the workflow-level ones.

Record a decision for each requested claim

Use a small set of decision values and apply them consistently: demonstrated, documented only, unresolved, or accepted risk. Demonstrated means a buyer-side person observed the behavior in the agreed environment. Documented only means the provider described it and no observation exists. Unresolved means the check could not be completed. Accepted risk means the business owner chose to proceed knowing the gap. Every value other than demonstrated needs a remediation owner and a date for the next check.

Use published guidance without implying customer results

Nothing in this guide reports a tested customer workflow or a provider's measured performance. The examples are hypothetical, and the worksheet is an editorial tool. This guide is deliberately narrower than supplier selection and covers only the evidence requested at handover. The public /providers collection is a research starting point, not a certification or endorsement service; confirm availability, languages, service coverage, experience and terms directly with each provider. A starting checklist for a first automation is at /guides/first-automation-checklist.

Assign a decision value to every worksheet row: demonstrated, documented only, unresolved or accepted risk.
Name a remediation owner and a next check date for every row that is not demonstrated.
Ask the business owner to sign the accepted risk rows in writing.
Attach the rehearsal record, the control rehearsal record and the acceptance record to the worksheet.
If the contract includes an audit right, schedule the next check under those agreed terms and record who runs it.

Questions about provider evidence and handover

These are the objections that come up when a buyer asks for evidence instead of a demo. None of the answers below offers a guarantee, a score or an endorsement of any provider.

Is a successful demo enough?

No. A demo shows that the workflow completes for inputs the builder chose, and it says nothing about an input that does not match, about who can change the workflow afterwards or about whether a wrong result would be noticed. NIST calls for log records available for continuous monitoring NIST, Cybersecurity Framework 2.0, PR.DS-11, PR.PS-04 and RC.RP-05, February 26, 2024; a demo without logs and an exception rehearsal leaves those questions open.

Does owning the workflow mean we control every dependency?

No. Ownership is defined by each platform. Microsoft says a Power Automate cloud flow owner has authority to make changes and a central role in management, control and maintenance Microsoft Learn, Change the owner of a cloud flow in Power Automate, updated September 25, 2026, but that is about a flow in that product.

The Microsoft page establishes the authority attached to cloud flow ownership, but it does not establish the transfer state of every dependency. Check connections, credentials, billing and the environment separately in current documentation and the actual account. NIST expects identities and credentials to be managed by your organization NIST, Cybersecurity Framework 2.0, PR.AA-01 and PR.AA-05, February 26, 2024, so check each dependency separately.

What if a provider cannot share a customer example?

Accept it, and ask for a rehearsal in your own test environment instead. Confidentiality can prevent a provider from showing another customer's workflow, and a reference you cannot verify is weak evidence anyway. A rehearsal with your fabricated inputs, run by your operator, tells you more about your workflow than any customer story. CISA's supplier questionnaire supports acquisition discussions with software suppliers CISA, Software Acquisition Guide supplier questionnaire, July 2024 for the supplier-level questions.

Must every small workflow use the same checks?

No. The NCSC says supplier security requirements should be minimum requirements that are justified, proportionate and achievable UK NCSC, The principles of supply chain security, II. Establish control, January 28, 2018. Scale the worksheet to the consequences: a workflow that can send a customer message or move money earns the full rehearsal, control check and negative control. A workflow that only tags internal records can use a shorter version, as long as the decision and the owner are still recorded.

Does a directory listing certify a provider?

No. Otomatzia's public /providers collection is a research starting point, not a certification or endorsement service. Confirm availability, languages, service coverage, experience and terms directly with each provider. A listing tells you a provider exists and what it says about itself. The evidence requests in this guide are how you check what it can show for your workflow.

Takeaways before you accept the handover

Treat the worksheet as a decision record, not a certificate. It records what was demonstrated to your team, what remains unproven and who owns the gap. If you have a defined project and want to describe it, use the /request form. The public /providers collection remains a research starting point and does not certify or endorse providers.

Request specific proof for each claim and write the limitation of every artifact in the worksheet, in line with NIST's call for due diligence before a formal supplier relationship NIST, Cybersecurity Framework 2.0, GV.SC-06 and ID.RA-10, February 26, 2024.
Rehearse an exception with an operator who did not build the workflow, in a safe environment, and record every intervention by the builder.
Verify practical control in the platform itself, so that identities and credentials are managed by your organization NIST, Cybersecurity Framework 2.0, PR.AA-01 and PR.AA-05, February 26, 2024, and check transfer mechanics against current vendor documentation.
Test whether the acceptance check detects a deliberate mismatch, and record detection and restoration separately.
Name the maintenance owner for mappings, rules and the exception queue, and keep the right to audit that the NCSC recommends UK NCSC, The principles of supply chain security, III. Check your arrangements, February 14, 2019.

Sources to check next

Vendor features and prices change. Confirm details on the linked official pages before you rely on them.

What to read next

Send a project request