Vendor Due Diligence After the Contract Is Signed: A 10-Day Recovery Plan

TL;DR

• A signed contract is a commercial fact, not a completed risk decision. Separate signature, access, data transfer, pilot, and production approval.
• In the first 10 business days, establish the real data flow, contain material exposure, run focused diligence, and force every gap into a decision.
• Record the process failure separately. Fixing this vendor does not fix the procurement route that bypassed Risk.

The DocuSign email arrives at 4:47 p.m.: “Good news—we signed. Can Risk approve the vendor by tomorrow?”

That is not a normal onboarding request. It is a recovery job.

A useful vendor risk assessment checklist for this situation does not pretend the clock can be rewound. It establishes what has already happened, prevents signature from turning into automatic production access, and creates an honest decision trail around whatever exposure remains.

The regulatory baseline is clear even if the operating failure is common. The 2023 Interagency Guidance on Third-Party Relationships, transmitted by OCC Bulletin 2023-17, describes risk management across the third-party relationship lifecycle and says practices should be commensurate with the bank’s risk profile, complexity, and the criticality of the supported activity. The Federal Reserve transmitted the same guidance in SR 23-4. Neither source creates a “contract is signed, therefore approve” exception.

First: determine what “signed” actually changed

Do not start by sending a 150-question spreadsheet. Start with facts that can change today’s decision.

The human wrinkle: the business sponsor may describe a planned launch date as immovable because changing it is embarrassing. That is different from a contractual obligation. Ask Legal to identify the actual consequences of delay; ask Product to identify the operational consequences. Keep those answers separate.

Create a chronology with the actual dates: request initiated, vendor selected, contract sent, contract signed, Risk notified, credentials issued, data first transferred, and service launched. Never backdate the assessment.

Days 1–2: contain exposure without declaring war on the deal

The immediate objective is a bounded operating state while the review runs.

Choose controls based on what the service does:

• Do not issue production credentials until access design is reviewed.
• Keep the integration in a sandbox with synthetic or de-identified data.
• Disable transaction initiation, auto-send, deletion, or administrative permissions.
• Restrict the pilot to named users and a defined customer-free use case.
• Route outputs to human review before they affect a customer, account, or regulatory record.
• Block secondary data use until the agreement and technical configuration are reconciled.
• Establish an immediate stop contact in Product and Engineering.

This is where ownership gets messy. TPRM can recommend restrictions, but Engineering operates access controls, Product owns the workflow, Security reviews architecture, Privacy evaluates data use, and Legal interprets the agreement. Put each temporary control in a recovery register with an owner, implementation evidence, test, and failure response.

Example control language:

Until review ID TPRM-2026-041 is closed, the vendor may operate only in the test tenant using synthetic records. No production API key, customer identifier, payment instruction, or automated customer communication is permitted. Engineering owns enforcement through environment and role restrictions. Any production connection suspends the pilot and escalates to the CISO and Head of Compliance.

The example is a starting point, not a universal requirement. Scope it to the service and verify the restriction against logs rather than relying on a ticket marked “done.”

Days 2–4: run a focused vendor risk assessment checklist

Now assess the relationship, not the vendor in the abstract. The federal banking agencies’ May 2024 Third-Party Risk Management: A Guide for Community Banks defines due diligence as assessing whether the third party can perform as expected, follow the bank’s policies, comply with applicable laws, and operate safely and soundly. It also says that when desired information cannot be obtained, a bank may consider alternative information, controls, or monitoring.

That does not mean “accept any substitute.” It means evaluate whether the substitute supports the specific conclusion.

The first-pass evidence set

Use the evidence-substitute guide when a SOC 2 is unavailable. Use the questionnaire review method to classify each material answer. Do not duplicate that work with a decorative overall score.

Days 4–6: compare the contract with the diligence findings

Late diligence often reveals that the agreement protects the commercial relationship better than it protects the operating company.

The 2024 agencies’ guide says that in difficult negotiations, including when a bank has limited leverage, the bank should understand resulting limitations and consequent risks. Its contract section specifically asks whether the agreement provides timely information needed for monitoring, compliance, and regulatory requests, and whether termination and continuity provisions are adequate.

Build a clause-to-finding table:

Do not call an amendment a control until it is executed. Do not call an unsigned redline “mitigation.” Track interim restrictions separately from contractual remediation.

Days 6–8: force each gap into one decision

Every material gap needs one disposition:

1. Closed by evidence — the assertion is supported and relevant.
2. Closed by customer-side control — your organization can reduce and verify the exposure.
3. Contract remediation — the vendor must provide a right, restriction, deliverable, or commitment.
4. Restricted use — the relationship proceeds within named boundaries.
5. Time-bound risk acceptance — an authorized person accepts stated residual exposure and an expiry.
6. Pause or terminate — the proposed use cannot proceed safely or lawfully.

“Business accepts” is incomplete. Name the individual or committee, delegated authority, approved scope, rationale, expiry, monitoring, and reopening events. A product sponsor does not automatically have authority to accept privacy, cybersecurity, consumer-compliance, or resilience risk.

Potential launch blockers include unknown production access, prohibited data use, no viable incident-notification path, no recovery route for a critical process, an unresolved legal obligation, or a vendor refusing enough information to make a decision. Calibrate blockers to the service; do not turn the list into an industry-ban checklist.

Days 8–10: issue the recovery decision package

A clean package lets someone who missed every meeting understand the result.

Include:

• factual chronology;
• service description and approved use;
• risk tier and rationale;
• data and access diagrams;
• evidence index and reviewer conclusions;
• open findings and dispositions;
• executed and pending contract changes;
• temporary and ongoing controls;
• residual risk and approval authority;
• launch restrictions and stop triggers;
• remediation dates and validation requirements;
• monitoring and reassessment schedule;
• exit path;
• root-cause issue for the bypass.

A realistic decision statement is specific:

Approve a 45-day internal pilot for named Operations users. No customer communication, transaction authority, or production credential is permitted. Customer identifiers must be removed before upload. Production consideration requires executed data-use and incident-notification amendments, completion of the architecture review, and validation of deletion testing. Any production connection, vendor security incident, or missed remediation date suspends the pilot and returns the decision to the Technology Risk Committee.

The 45-day period is illustrative. Set duration from the actual remediation plan and your delegated-authority framework.

Fix the route that allowed the bypass

Closing the vendor review leaves the process defect open. Create a separate issue with root cause and corrective action.

Look for:

• procurement tooling that allows signature without a TPRM record;
• spend thresholds that ignore data, access, customer, or operational risk;
• renewal and expansion flows outside onboarding gates;
• employees authorized to sign without required reviews;
• intake forms that ask vendor category but not use case;
• emergency procurement with no retrospective deadline;
• contract repositories that do not feed the vendor inventory.

The correction should be testable. “Retrain Product” is weak. “Configure the contract workflow to require a TPRM ID for any vendor receiving company data, production access, transaction authority, or critical-process dependency; sample signed agreements monthly against the vendor inventory” is stronger.

That inventory reconciliation is the anti-gaming check. A beautiful workflow proves little if teams can still sign outside it.

So What?

On day one, do three things: freeze new access, draw the real data flow, and get the executed agreement. By day ten, produce a decision that says exactly what may operate, what remains prohibited, who owns every condition, and what shuts the service down.

Then open the separate process issue. The goal is not to punish the team that moved fast. It is to make sure the next “good news—we signed” email reaches Risk before the signature.

The Third-Party Risk Management (TPRM) Kit includes risk tiering, due-diligence, contract-review, monitoring, and offboarding artifacts for building that gate without starting from a blank workbook.

Sources

• OCC Bulletin 2023-17, Third-Party Relationships: Interagency Guidance on Risk Management
• Federal Reserve SR 23-4, Interagency Guidance on Third-Party Relationships: Risk Management
• Federal banking agencies, Third-Party Risk Management: A Guide for Community Banks (May 2024)