IT Sourcing:
A Complete Guide to IT Vendor Evaluation
IT vendor evaluation for software, cloud, and managed services - with security gates built into the process, not checked at the end.
Course Overview
What you will learn.
This guide covers how to run structured IT vendor evaluation across software and SaaS, IT infrastructure and cloud, managed services and outsourcing, cybersecurity vendor selection, and ERP and enterprise applications - the specific process challenges unique to IT decisions, the 8-step framework, evaluation criteria that include security as a gate not a score, and why IT sourcing requires use-case specific demos rather than general product walkthroughs.
IT sourcing requires more than finding the lowest-priced vendor who passed the demo. Selecting the right IT vendor depends on technical fit, security posture, implementation risk, and commercial terms across a full contract term - and standard procurement process tends to break down here for three specific reasons: incompatible vendor pricing models prevent direct cost comparison, security evaluation arrives too late to function as a real gate, and multi-stakeholder requirements are gathered informally rather than structured before the brief is written. This guide gives you the framework to run it properly.
01 - The Challenge
Why IT sourcing resists standard process
Incompatible pricing models make direct cost comparison impossible without a mandatory pricing template. IT vendors price on incompatible structures - per user, per seat, per API call, per feature tier, per compute unit. A direct cost comparison across three shortlisted vendors requires all three to quote against the same usage parameters. Without a mandatory pricing template that specifies your actual volume and usage profile, proposals describe structurally different costs and the comparison relies on each vendor's pricing presentation rather than consistent data.
Security evaluation typically arrives too late to function as a real gate. Once a preferred vendor has emerged through demo and functional scoring, security concerns become objections to manage rather than criteria to apply. A security issue that would have removed a vendor from the shortlist if discovered during pre-qualification instead becomes a negotiation problem after the business has already decided who it wants. Security and compliance evaluation must be a gate at the beginning of weighted scoring - not a final check at the end.
Multi-stakeholder requirements are gathered informally and too late. IT requirements span IT architecture, information security, finance, and the business teams who will use the system. These requirements are frequently gathered informally - through conversations that happen after a vendor demo rather than before the brief is written. Requirements gathered after a preferred vendor has emerged are shaped by what that vendor offers rather than what the organisation actually needs. Cross-functional input must be structured and collected before the market is engaged.
02 - The 6 Categories
IT procurement is six distinct sourcing motions
Each category shares the same broad structure but differs meaningfully in what you are actually evaluating and how hard vendor claims are to verify. Treating all six the same way is a common cause of mismatched, hard-to-compare proposals.
Software and SaaS
Evaluating software vendors where subscription pricing models, switching costs, and integration dependencies are all material. The procurement challenge is that vendors price on incompatible models - per user, per seat, per API call, per feature tier - making direct cost comparison impossible without a mandatory pricing template that specifies your actual usage parameters. Without it, you are comparing structurally different numbers.
IT Infrastructure and Cloud Services
Sourcing cloud infrastructure and platform services where the technical architecture evaluation is complex and the commercial terms are long. The comparison must cover both technical fit - architecture alignment, performance requirements, regional coverage - and commercial structure: committed spend minimums, pricing at scale, data egress costs, and exit provisions that determine how reversible the decision is.
IT Managed Services and Outsourcing
Evaluating managed service providers and IT outsourcing partners where the service quality comparison requires more than reading a proposal. The gap between what a provider says they can do and what they actually deliver at comparable scale is usually accessible through structured reference conversations - but only if the questions are written to surface delivery failures, not just general satisfaction.
Cybersecurity Vendor Selection
Sourcing security products and services where vendor claims are especially hard to verify without specialist involvement. Every shortlisted security vendor should provide: current relevant certifications, a completed security questionnaire, penetration testing results, and a data processing agreement. Security vendor selection that relies on sales materials and a demo is not security vendor selection.
ERP and Enterprise Applications
Evaluating ERP and enterprise application vendors where implementation risk is as material as the software capability. The relevant comparison is not just functional fit - it is the combined risk of a complex, multi-year implementation across the vendor's capability, their implementation partner's track record, and your own internal change management capacity. All three need to be in the evaluation.
IT Category Management
Managing an existing IT vendor portfolio requires ongoing licence compliance monitoring, renewal management, software rationalisation, and periodic re-competition on major contracts. Without this motion, IT spend accumulates in auto-renewed contracts, shadow subscriptions, and unused licences that were never reviewed against the original business case.
03 - The Process
The 8-step IT vendor selection process
This process applies across software, cloud, managed services, cybersecurity, and enterprise application selection. Step 06 - security and compliance evaluation as a gate - is the most commonly collapsed or skipped step in IT procurement.
Define functional and technical requirements
What business problem does this IT solution need to solve, and what are the technical constraints? Both must be defined before any vendor is contacted. IT RFPs frequently fail because requirements are stated at a business level without specifying integration needs, data architecture, security requirements, or compliance obligations - leaving vendors to interpret them differently.
Use a three-part requirements structure: functional requirements (what the system must do, by process), technical requirements (integration, data model, performance, security), and compliance requirements (industry regulations, data residency, audit obligations). Separate sections produce comparable vendor responses.
Gather cross-functional input
IT decisions involve IT architecture, security, finance, and the business teams who will use the system. Gathering their requirements after a preferred vendor has already been identified means requirements are shaped to fit the preferred solution. Cross-functional input must happen before the market is engaged - not after the shortlist is set.
A structured intake form with separate sections for IT, security, finance, and business stakeholder input produces a complete requirements picture faster than chasing individual conversations. It also creates a documented record of who contributed which requirements.
Identify and shortlist vendors
Match the shortlist to the category. For established software categories, three to five credible vendors is typically sufficient. For niche or emerging categories, an RFI stage is usually necessary to identify which vendors can actually meet the technical and compliance requirements before issuing a full RFP.
For cybersecurity and regulated IT categories, include certification and compliance confirmation in the RFI. A vendor who cannot confirm specific certifications or compliance capabilities should not be on the shortlist for the full RFP regardless of market reputation.
Run a structured RFP
Issue the RFP simultaneously to all shortlisted vendors with a mandatory pricing template and a technical questionnaire. The pricing template should cover all cost elements: licences at actual user volume, implementation, training, ongoing support, and renewal pricing mechanisms. The technical questionnaire should ask vendors to describe integration approach, data architecture, security controls, and compliance certifications.
Open a Q&A window and publish all questions and answers to all vendors simultaneously. Questions vendors ask often reveal gaps in the brief that affect every vendor's response - a private Q&A process means some vendors quote against different information than others.
Run use-case specific demos
A vendor demo should demonstrate capability on your actual business use cases and integration scenarios, not a curated feature walkthrough. Provide scenarios and test data in advance and ask each vendor to demonstrate the same scenarios in the same sequence. This makes the functional comparison meaningful rather than subjective.
Score demos on the same evaluation criteria as the written response. Use a shared scoring sheet with all evaluators present or watching simultaneously. Separate demos on different days with different evaluators produce scores that reflect the evaluators' recall as much as the vendors' capability.
Evaluate security and compliance posture
IT security evaluation must be a distinct gate, not a criterion in the weighted score. Get IT security's assessment of each shortlisted vendor's security posture before commercial scoring begins. Vendors who do not meet security or compliance requirements are removed from the shortlist - they do not progress to weighted scoring regardless of functional fit or price.
Ask for ISO 27001 or SOC 2 certification evidence, a completed security questionnaire in your standard format, penetration testing reports dated within 12 months, and a data processing agreement draft. Gaps or refusals in any of these are material findings.
Score proposals against weighted criteria
Set weighting with sign-off from all evaluation stakeholders before proposals arrive. IT scoring typically involves separate evaluators for different domains: IT scores technical fit, security scores compliance, finance scores commercial terms, business scores functional fit. Aggregate independently, surface divergences, and hold a consensus session before any vendor is contacted about the outcome.
Get agreement on weighting before the RFP goes out, not after preferred vendors have emerged. The weighting sign-off is itself an audit document - it shows the decision criteria were set before the proposals were seen.
Award, negotiate, and document
Commercial terms for IT contracts are not standard and are negotiable before signing: licence terms and exit provisions, data portability and destruction on termination, price adjustment mechanisms at renewal, SLA financial remedies, and implementation milestone commitments. The evaluation score selects the preferred vendor. Commercial negotiation determines what you actually get for what you pay.
Award rationale must document: weighted scores by evaluator and criterion, security evaluation outcome, demo scoring, implementation risk assessment, and the specific reasons the selected vendor was preferred over the runner-up. A rationale that simply names the winner does not support an audit or a stakeholder challenge.
04 - Writing the Brief
Writing a brief that gets comparable IT proposals
A brief that produces comparable IT proposals defines, at minimum: functional requirements by business process and user role, technical requirements including integration approach and data architecture constraints, security and compliance obligations, user volume and access patterns, existing system dependencies the new solution must connect to, and budget range across the full contract term including implementation and support costs.
A structured intake process that separates functional, technical, and compliance requirements into distinct sections produces more complete input than a free-text brief. It also makes it much harder to accidentally omit a requirement category - and it means every vendor is responding to exactly the same structured set of inputs rather than interpreting a narrative description differently.
An IT brief should include at minimum:
05 - Evaluation
Evaluation criteria for IT vendor selection
Generic scoring criteria do not capture what actually predicts a good long-term IT vendor relationship. Lock the weighting across these five dimensions before proposals arrive, and keep every scorer's individual ratings on record. Security and compliance posture functions as a gate, not a weighted criterion.
Technical Fit and Integration
Does the solution meet the technical requirements and integrate with existing systems as the brief specifies? Verify integration claims in a demo against your actual systems or a representative sandbox, not against a generic integration description.
Security and Compliance Posture
Verified certifications, security questionnaire responses, penetration testing evidence, and data processing agreement terms. A pass/fail gate before commercial scoring begins rather than a dimension in the weighted score.
Commercial Terms and Total Cost of Ownership
All-in cost across the contract term: licence fees at actual volume, implementation, support, and renewal pricing. Exit cost and data portability terms are commercial provisions with long-term value that are frequently underweighted at evaluation time.
Implementation Risk and Vendor Track Record
Implementation track record with comparable deployments in terms of scale and complexity, not just general capability claims. References who can speak to delivery performance against timeline and budget commitments, not just post-go-live satisfaction.
Support and SLA Quality
Support SLA response and resolution times, escalation path, customer success model, and references who can speak to support quality during and after implementation. Support quality gaps in IT deployments typically surface six to twelve months after go-live when the account is no longer in the implementation team's priority queue.
Free Template
Category Evaluation Criteria Worksheet
Pre-built scoring criteria for 13 spend categories - editable weightings, sub-criteria anchors, and a 1-5 scoring scale. Free Excel download.
06 - Stakeholders
Managing a multi-stakeholder IT decision
IT decisions involve stakeholders who each evaluate a different dimension and who are often evaluating sequentially when they should be evaluating in parallel. IT and architecture evaluate technical fit and integration. Security evaluates compliance and data handling. Finance evaluates total cost and commercial terms. Business stakeholders evaluate whether the system actually solves the problem they have. When any of these evaluations arrive late, the process either waits or proceeds with an incomplete picture.
The fix is not picking one owner and sidelining the rest. It is assigning domains clearly - so each stakeholder evaluates the dimension they own, independently, against the same criteria, before scores are aggregated and divergences are discussed. Conflict that surfaces during the consensus session is healthy. Conflict that surfaces after a preferred vendor has been informally told they have won is not.
IT and Architecture
- Technical requirements and integration design
- Security and compliance gate
- Vendor technical questionnaire review
- Implementation risk assessment
Business Stakeholders
- Functional requirements by process
- Demo evaluation and use-case scoring
- User adoption considerations
- Post-implementation performance requirements
Procurement
- Process design and brief coordination
- RFP documentation and Q&A management
- Evaluation coordination across stakeholders
- Award rationale and sign-off documentation
07 - Using Nvelop
What changes when you run IT sourcing in Nvelop
The 8-step process above can be run manually. The failure points are not the steps themselves - they are in the execution: RFP documents and pricing templates sent by email without a consistent format, Q&A managed in individual email threads where not every vendor sees the same information, demo scores captured in separate spreadsheets by different evaluators, and award rationales assembled after the preferred vendor has already been told they have won.
Nvelop structures the IT sourcing process from brief to award. The RFP is built with a mandatory pricing template that requires every vendor to quote against the same usage parameters - licences at actual volume, implementation, training, ongoing support, and renewal pricing. A technical questionnaire asks vendors to describe integration approach, data architecture, and security controls in a structured format that makes responses directly comparable. The RFP is published simultaneously to all shortlisted vendors, and all Q&A is visible to every participant through a shared portal.
The security gate is built into the evaluation workflow. IT security completes their assessment - certifications, security questionnaire review, penetration testing evidence, data processing agreement review - before commercial scoring begins. Vendors who do not pass the security gate do not appear in the weighted evaluation regardless of their functional or commercial score. Use-case demo scoring runs on a shared evaluation sheet with all evaluators scoring simultaneously against the same pre-defined criteria, making the demo comparison consistent rather than subject to recall variation across separate sessions.
Award documentation is produced as a byproduct of the process. Weighted scores by evaluator and criterion, security gate outcomes, demo scores, implementation risk notes, and pricing comparisons are all captured throughout the evaluation. The award rationale is assembled from the documented record - not created from scratch after the decision has been made. Debrief conversations with unsuccessful vendors draw from the same documentation.
08 - Common Mistakes
Common mistakes in IT vendor selection
These are process failures, not vendor failures. They appear consistently regardless of the quality of the vendors shortlisted or the size of the IT decision.
Allowing vendor demo quality to drive the decision
IT vendors invest heavily in demo and presentation capability. A demo is evidence of sales effectiveness, not necessarily product quality at your integration depth or use-case complexity. Demo scoring needs to be anchored to your specific scenarios and weighted against the technical and commercial evidence in the written proposal.
Security evaluation happens after the preferred vendor has been identified
Once a preferred vendor has emerged through the demo stage, security concerns become objections to manage rather than criteria to apply. Security evaluation must be a gate at the beginning of weighted scoring - not a final check after the commercial and functional picture has already formed.
Pricing models not standardised before the RFP goes out
IT vendors price on incompatible models. Without a mandatory pricing template that specifies your actual usage volume and requires every vendor to quote against the same parameters, proposals will not be directly comparable. The comparison then relies on each vendor's pricing presentation rather than consistent data.
Implementation risk is not part of the evaluation
For complex IT deployments - ERP, infrastructure migrations, enterprise applications - implementation risk is as material to the decision as software capability. A vendor with a strong product and a poor implementation track record at your scale and complexity is not the same as a vendor who is strong on both. References should specifically address implementation performance, not just post-go-live satisfaction.
Evaluation weighting finalised after proposals are received
Weighting agreed before proposals arrive is an audit document. Weighting adjusted after a preferred vendor has emerged is a rationalisation. Lock criteria and weights with stakeholder sign-off before the RFP is issued. Any post-submission change is an audit risk that undermines the integrity of the whole process.
09 - FAQ
Frequently asked questions
Keep learning
Related Courses
How to Write an RFP
The complete 8-step guide to writing an RFP that gets useful vendor responses - with templates, evaluation criteria, and common mistakes to avoid.
RFX Explained
When to use RFI, RFP, RFQ, and RFS - and how to run each type of sourcing event.
Technology Sourcing
How to run structured vendor evaluation across software, AI, cloud services, and technology partners.
Nvelop for IT Procurement
Run structured IT vendor evaluation with security gates and full audit documentation
Requirements gathering, RFP management, security evaluation workflow, use-case demo scoring, and audit-ready award documentation - built into one platform.