SaaS Vendor Management: Intake, Risk Tiering, SOC 2 Review, and Exit Planning

Most companies manage their software vendors in two moments: the purchase and the renewal. In between, the vendor changes its subprocessors, has an outage, gets acquired, or loses a security certification, and nobody outside the vendor's own status page notices. Vendor management is the routine that covers the gap: intake, a review sized to the risk, monitoring, and a tested way out.

This guide is about that routine and about vendor risk. Negotiating the terms is in our SaaS contract negotiation guide, and finding unused licenses and tracking renewals is in our SaaS spend management guide. This is general information, not legal or compliance advice.

A lifecycle that fits software

The bank regulators' June 2023 interagency guidance on third-party relationships is the most widely copied lifecycle. It names five stages: planning, due diligence and third-party selection, contract negotiation, ongoing monitoring, and termination. It applies to banks supervised by the Federal Reserve, FDIC, and OCC, and the FDIC's notice says it replaces each agency's earlier guidance. Nothing stops other companies from using the same shape. For SaaS it helps to split the first stage in two:

1. Intake: who wants the tool, what data it will touch, and whether an existing tool already does the job.
2. Tiering and due diligence: how much scrutiny the vendor gets.
3. Contract: the terms in our negotiation guide.
4. Onboarding: single sign-on, provisioning, data classification, and an owner.
5. Monitoring: service performance, security notices, financial and ownership changes, and renewal.
6. Termination: data export, deletion confirmation, and cutting off access.

Intake and risk tiering

The intake form needs only a few answers: the business owner, what data the tool will hold, whether it connects to other systems, what it costs, and what happens if it is down for a day. Those answers set the tier. A workable scheme has four:

• Tier 1: holds regulated or sensitive data, or an outage stops revenue or operations.
• Tier 2: holds internal confidential data, or runs an important workflow with a workaround.
• Tier 3: limited data, and you could replace it in a few weeks.
• Tier 4: no company data and low spend.

The point of tiers is effort. Illustration: a company with 200 SaaS vendors, split 10, 30, 60, and 100 across the four tiers. The hours are our assumptions, not benchmarks: 40 hours to onboard a Tier 1 vendor and 16 a year to review it; 12 and 4 for Tier 2; 3 and none for Tier 3; 30 minutes for Tier 4.

Tiering costs about 12% of the hours for onboarding and 9% for annual reviews, and puts 40% of the onboarding time on the ten vendors that matter most. The counts and hours are yours to set. What matters is that a single process for every vendor either stalls purchasing or gets skipped.

Due diligence: reading the evidence

Vendors will hand you a stack of documents. The useful ones are the audit reports, the data processing agreement, and the answers to specific questions about your use.

SOC 2 reports

A SOC 2 report is an examination by a CPA firm of a service organization's controls against the AICPA's trust services criteria. A Type 1 report covers whether the controls were suitably designed at one date. A Type 2 report also tests whether they operated over a period. Buyers of critical vendors normally ask for Type 2. When the report arrives, read:

• The auditor's opinion, and who signed it.
• The period covered, and whether it ends within the last year. If there is a gap between the end of the period and today, ask for a bridge letter.
• The system description: is the product you use in scope, or only a different one?
• Which trust services categories are covered. Security is always included; availability, confidentiality, and privacy are optional.
• Exceptions in the test results, and the vendor's response to each.
• Subservice organizations, such as the vendor's cloud host. The report may exclude their controls, leaving you to review their reports separately.
• The user entity controls the report expects you to run yourself.

Report quality is an open concern. The Journal of Accountancy's February 2026 article says CPAs who perform SOC examinations worry that tool vendors' marketing of fast, cheap reports is pressuring firms to cut corners, and notes that some promise "compliance," a term never used in SOC 2 examinations. That does not make a fast report bad, but it is a reason to read the report and not just file it. Our SOC 2 Type 2 guide covers the audit from the vendor's side.

Questionnaires

The Cloud Security Alliance's CAIQ is a spreadsheet of yes/no questions mapped to its Cloud Controls Matrix, and vendors can publish theirs in the CSA STAR registry. CSA notes that the questionnaire itself is not a certification. Shared Assessments publishes the SIG, a licensed, standardized questionnaire that comes in shorter and longer versions. Both record what the vendor says about itself. Asking a Tier 3 vendor for a long questionnaire mostly tests its patience, and asking a Tier 1 vendor for one without also reading an audit report tests nothing.

Privacy and data

If the vendor processes personal data for you, you need a data processing agreement, a list of subprocessors, a breach notice commitment, and a clear answer on where data is stored. Our SaaS data privacy compliance guide covers the regulations, and our SaaS security guide covers the technical controls to verify.

Concentration and exit risk

Two incidents show the two ways a vendor can fail you.

The first is a shared dependency. Amazon's summary of the October 2025 event says the disruption in its US-EAST-1 region ran from 11:48 PM PDT on October 19 to 2:20 PM PDT on October 20, about 14.5 hours, and began with a latent defect in DynamoDB's automated DNS management. Some SaaS vendors run there. If three of your Tier 1 vendors share a cloud region, you have one risk that looks like three. Ask each vendor which cloud and region hosts your data, whether it can fail over to a second region, and what its documented recovery time objective is.

The second is the vendor's own mistake. Atlassian's post-incident review of April 2022 says a deletion script run with the wrong mode and list of IDs removed 883 sites, belonging to 775 customers, between 07:38 and 08:01 UTC on April 5. Restoration began on April 8, and all sites were restored by April 18, so some customers waited up to 14 days. No regional failover helps in that case, because the vendor deleted the data on purpose. The questions that matter are how long restoring a single customer takes, and whether the vendor has tested it.

From those two, an exit plan for each Tier 1 vendor should cover:

• A recent export of the data you could not recreate, stored outside the vendor.
• The systems that depend on the vendor, and the manual process you would run in the interim.
• The alternative vendor, and how long a move would take.
• The contract terms that let you leave: termination rights, data return, and transition help. See the negotiation guide.

If you are a bank or an EU financial entity

Banks supervised by the Fed, FDIC, or OCC should map their SaaS process to the interagency guidance above. It says using third parties does not reduce the bank's responsibility for safe operation and legal compliance. It also scales expectations to risk instead of setting minimum standards, which matches the tiering approach here.

Financial entities in the EU face a specific record-keeping duty under the Digital Operational Resilience Act. The European Banking Authority describes the register of information on ICT third-party arrangements as central to their risk framework and to the designation of critical ICT providers. The ESAs' timeline notice told national authorities to report the registers by 30 April 2025, and DORA applies from 17 January 2025. Every SaaS tool that supports a business function may need a line in that register, so intake should capture the fields it requires. Whether DORA covers your firm is a question for compliance counsel.

A scorecard for reviews

A scorecard is useful mainly for comparing vendors on the same measures and for having a reason to hold a review. Weight only what you will collect evidence for.

Illustration: four criteria, weighted 30% for value delivered, 25% for service performance against the SLA, 25% for security posture, and 20% for commercial terms, each scored 1 to 5.

Vendor A's users like it, but its service score of 2 is the problem to raise at the quarterly review. The score is not a decision. The uptime figure you use should be measured: 99.9% allows 43.2 minutes of downtime a month, about 8.8 hours a year, so a vendor with two long incidents may have missed its commitment while still describing itself as reliable.

Review Tier 1 vendors quarterly, Tier 2 yearly, and the rest at renewal. Between reviews, watch for changes that should trigger one early: a security incident, an acquisition, a new subprocessor, a price restructure, or a lapsed audit report.

Offboarding

Termination is the stage that most often gets skipped. Cut off single sign-on and API keys on the end date, confirm the export arrived and opens, get written confirmation of deletion, and remove the vendor from your data inventory and subprocessor list. Our spend management guide covers the offboarding gap that keeps paying for unused licenses.

Limits

A small company with 20 tools does not need four tiers or a scorecard. A spreadsheet with owner, data, renewal date, and the reports you collected is enough, and the discipline is in checking it. Tiering also hides shadow purchases, since a tool nobody logged has no tier. Discovery through expense reports and single sign-on logs comes first.

This guide is for informational purposes only and is not legal, audit, or compliance advice. Regulatory requirements and vendor practices are as of September 2026 and change; the hour and scoring figures above are illustrative assumptions. Consult qualified professionals about your obligations.