Topics in this domain
- IT Governance vs. IT Management
- Board and Senior Management Roles
- IT Steering Committee
- IT Strategy and Business Alignment
- Balanced Scorecard
- COBIT
- ITIL
- ISO 27001/27002
- COSO: ERM and Internal Control
- Policies, Standards, Procedures, Guidelines
- IT Organizational Structure and Key Roles
- Segregation of Duties in IT
- Enterprise Architecture (Zachman, TOGAF)
- Risk Management Process
- Qualitative vs. Quantitative Risk Assessment
- Risk Responses: Mitigate, Transfer, Avoid, Accept
- Risk Appetite and Residual Risk
- Maturity Models (CMMI)
- KPIs and KGIs
- Outsourcing: Benefits and Risks
- Vendor Selection, Contracts, SLAs, Right to Audit
- Cloud and Offshore Governance
- Portfolio and Resource Management
- HR: Hiring, Training, Termination
- Legal and Regulatory Compliance
- Quality Management
Vendor Selection, Contracts, SLAs, Right to Audit
Choosing a vendor
Choosing an IT vendor is like hiring a builder for a big job. Get it wrong and you live with the consequences for years. So you work out exactly what you need, get several quotes, compare them fairly, check references, and sign a proper contract before any work starts.
- Define requirements: business, technical, security, privacy, regulatory and support needs.
- Issue a request for information (RFI) or request for proposal (RFP).
- Evaluate responses against weighted criteria agreed in advance, with demos, site visits and references.
- Due diligence: financial stability, security posture, certifications, sub-contractors, legal history.
- Negotiate the contract, with legal review, and get approval at the right level.
The auditor checks the process was documented and objective, and that the chosen vendor actually met the criteria.
The contract
| Clause | Why it matters |
|---|---|
| Scope of services | Avoids arguments about what’s included |
| Service levels | Measurable targets, how they’re measured, reporting, penalties |
| Security and privacy | Controls the vendor must keep; breach notification times; where data is stored |
| Confidentiality | NDAs for vendor staff and sub-contractors |
| Ownership of data and IP | The customer owns its data; it’s returned or destroyed at the end |
| Right to audit | The customer, its auditors and regulators may audit, or the vendor must provide independent reports |
| Liability and indemnity | Who pays when things go wrong; insurance |
| Sub-contracting | Needs approval; the same obligations pass down |
| Business continuity | The vendor’s disaster recovery and testing |
| Termination and exit | Rights to end the contract, transition help, data handover |
| Escrow | Access to source code if the vendor fails |
Service level agreements
An SLA turns expectations into measurable promises. A usable SLA defines:
- the services covered and the hours they’re provided
- targets: availability, response and fix times, capacity
- how performance is measured, and by whom
- reporting and review meetings
- what happens when targets are missed (service credits, escalation, termination)
- what each side is responsible for
Inside the organisation, operational level agreements between IT teams and underpinning contracts with suppliers must support the SLA’s targets.
Software escrow
When an organisation depends on a vendor’s software, a source code escrow agreement places the code with an independent agent. If the vendor goes bust or stops supporting the product, the code is released to the customer so they can keep it running. It’s only useful if the deposit is complete, current, and checked to actually build.
Example. A hospital’s patient scheduling system comes from a small vendor with shaky finances. The auditor recommends escrow, with a yearly check that the deposited code can be compiled, because no replacement could be put in quickly.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| First step in vendor selection | Define requirements |
| Clause that lets the auditor review vendor controls | Right to audit |
| Protection if a software vendor goes out of business | Source code escrow |
| The SLA has no measurement method | It can’t be monitored or enforced |
| Who owns customer data held by a vendor? | The customer; the contract should say so explicitly |
In short
- Vendor selection follows a process: requirements, RFI or RFP, evaluation against weighted criteria, due diligence, and approval.
- Contracts should cover scope, service levels, security and privacy duties, confidentiality, data and IP ownership, liability, right to audit, sub-contracting and termination.
- An SLA sets measurable service targets, how they're measured and reported, and what happens if they're missed.
- A right-to-audit clause lets the customer, its auditors and regulators check the vendor's controls.
- Source code escrow protects the customer if a software vendor fails or stops support.
- Legal should review contracts before signing; changing them later is harder and costlier.
Exam traps
- The first step in choosing a vendor is defining requirements, not inviting bids.
- An SLA with no defined way to measure it can't be enforced.
- Escrow only helps if the deposited code is complete, current and verified.
- Ownership of data must be stated clearly, including its return and destruction on exit.
- Penalties don't restore service; SLAs must be actively monitored.
Slides
Click the slide and use the arrow keys. F toggles full screen.
Choosing a vendor
Choosing an IT vendor is like hiring a builder. Get it wrong and you live with the consequences for years. So the process matters: know what you need, compare options fairly, check the vendor out, and get a solid contract.
Software escrow