Vendor Review Checklist for Automation Projects

Access, credentials, data handling, testing, and handoff

Use this in a discovery call or IT review before you grant access.

 If you’re hiring an automation partner, your biggest risk is not bad code. It’s unclear access, sloppy credential handling, and a messy handoff that leaves you dependent on the vendor.

This is a practical checklist you can use in a discovery call, IT review, or procurement process. It’s written to get clear answers fast.

Direct answer

Use a security checklist to vet an automation partner before you grant access. You want clear answers on who will access your systems, how credentials are handled, what data is stored and where, how failures are tested, and what you receive at handoff. A reliable partner will provide documentation, training, and a defined support path.

Print-and-use checklist

1) Access and permissions

• Can you list every system you need to access for this project?
• Can you list the exact roles and permissions you need in each system?
• Do you default to least-privilege access?
• Can we avoid admin access unless it’s truly required?
• Will access be tied to individual accounts, not shared logins?

Look for:

• A permissions plan by system.
• Role-based access where the platform supports it.
• A clear owner on your side approving access changes.

Red flags:

• “We’ll need admin to make it easier.”
• “Just give us a shared login.”

2) Credentials and secrets

• How do you handle API keys, tokens, and service accounts?
• Where are secrets stored during the project?
• Do you ever ask clients to send passwords by email or chat?
• What is your offboarding process for credentials at the end?

Look for:

• No passwords in docs, tickets, or message threads.
• A clear method that aligns with your IT policy.
• A specific offboarding checklist.

Red flags:

• Copying credentials into spreadsheets, notes, or emails.
• No clear answer on where secrets live.

3) Data handling and retention

• What data will the workflow touch?
• Where does data flow from and to?
• Is any data stored outside our systems of record?
• What data is retained in logs, exports, backups, or monitoring tools?
• How long is anything retained?

Look for:

• Minimize retention.
• Keep data in your systems of record when possible.
• Sanitized or minimal test data when practical. (Assumption: depends on your environment and tools.)

Red flags:

• Vague answers like “we don’t really track that.”
• Exporting full datasets as a normal practice.

4) Delivery quality and testing

• What do you test besides the happy path?
• What happens when a step fails?
• How do you handle retries, exceptions, and duplicate events?
• How do you validate outputs, especially for finance or approvals?
• How are changes tracked and reviewed?

Look for:

• Edge-case testing.
• Clear acceptance criteria.
• A defined go-live plan that matches risk.

Red flags:

• “We’ll test it as we go.”
• No plan for failure behavior.

5) Documentation and handoff

• What documentation is included by default?
• Who is trained, and what’s covered in training?
• Who owns admin access at the end?
• Can our team maintain this without you?
• What is your closeout and offboarding process?

Look for:

• Documentation that explains the workflow in plain language.
• A named internal owner on your side.
• Training for that owner.
• Clean transfer of ownership and access.

Red flags:

• Documentation is “extra.”
• Training is not included.
• Ongoing dependency is treated as normal.

6) Support and ownership after go-live

• Is there a stabilization window after go-live?
• How do we request changes after launch?
• What’s your response time expectation?
• What issues are included vs out of scope?

Look for:

• A defined support path.
• A clear escalation route for high-impact issues.
• A straightforward change request process.

Red flags:

• “Email us if something breaks.”
• No clarity on what happens post-launch.

7) People and accountability

• Who is on the delivery team, by role?
• Who is accountable for security and quality?
• Are team members background-checked?
• Will any subcontractors have access?
• Where is the delivery team located?

Look for:

• Named roles and accountability.
• Written disclosure if subcontractors are involved.

Red flags:

• “Our team will handle it” with no specifics.
• Subcontractors are introduced after access is granted.

8) Procurement proof points

• Can you provide proof of insurance?
• Do you have a vendor packet or security overview?
• Can you provide references?
• Can you share sanitized documentation samples?

Look for:

• Fast, organized responses.
• A professional services posture.

Red flags:

• “We don’t have that.”
• Everything requires a custom contract negotiation.

If you’re evaluating ProsperSpark

ProsperSpark’s stated standards include a documented handoff protocol, full system documentation, and “Power User” training to reduce ongoing dependency. ProsperSpark is based in Omaha, Nebraska and states it is BBB-accredited, fully insured, and staffed with background-checked U.S./Canada-based consultants.

How to run this checklist in 20 minutes

1. Copy the checklist into your vendor review doc.
2. Ask the partner to answer in writing, not just on a call.
3. Require a permissions plan by system before access is granted.
4. Require a credential handling plan that matches your IT policy.
5. Require a data flow summary, including retention.
6. Define “done” as documentation plus training plus ownership transfer.
7. Confirm support expectations before go-live.