CRISC IT Risk Identification Practice Question
A company is implementing a risk identification process for third-party risks. Which THREE factors should be considered when identifying risks from a critical software vendor?
⚠ Common exam trap
CRISC often tests the distinction between risk identification inputs (compliance, incident history, financial stability) and downstream contractual/operational artifacts (SLAs) or irrelevant size metrics (employee count), causing candidates to select SLAs because they sound risk-related.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Vendor's compliance with relevant regulations
Option B is correct because a critical software vendor's compliance with relevant regulations (e.g., GDPR, HIPAA, PCI DSS, SOX) directly determines legal, contractual, and data-protection exposure, and non-compliance is itself an identifiable third-party risk. Option D is correct because a documented history of security incidents (breaches, ransomware, vulnerabilities, downtime) is a concrete indicator of the likelihood and impact of future third-party risk. Option E is correct because the vendor's financial stability affects continuity of service, ability to remediate vulnerabilities, and the risk of sudden insolvency or acquisition that could disrupt critical software support. Option A does not belong because headcount alone is not a meaningful risk indicator — a small vendor can be highly secure and a large one poorly controlled. Option C does not belong because SLAs are contractual performance terms used to manage or transfer risk after identification, not a factor for identifying the risk itself.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Number of employees at vendor
Why it's wrong here
Headcount does not indicate risk exposure; a small vendor may be critical while a large one is peripheral. Identification considers factors such as data access, financial stability, subcontractor reliance and business dependency. Vendor size is tempting because it superficially suggests resilience and capability, and it would be relevant when assessing operational capacity during due diligence.
- ✓
Vendor's compliance with relevant regulations
Why this is correct
Regulatory non-compliance by the vendor creates legal, contractual, and reputational exposure for the organisation, particularly where the vendor processes regulated data. Assessing the vendor's adherence to applicable regulations identifies compliance-driven third-party risk, one of the factors required when identifying risks from a critical software vendor.
- ✗
Service level agreements (SLAs)
Why it's wrong here
SLAs are contractual performance commitments, not risk-identification inputs; they document agreed service levels after risk treatment. The stem asks which factors reveal third-party risk, such as vendor financial stability, data handling and dependency concentration. SLAs are tempting because they underpin ongoing vendor monitoring and would be the correct artefact when assessing whether agreed controls are being met.
- ✓
Vendor's history of security incidents
Why this is correct
A vendor's record of past security incidents reveals the effectiveness of its controls, patching cadence, and incident response maturity. Reviewing this history identifies likelihood-based third-party risk, since prior breaches indicate weaknesses that could recur and affect the organisation's data or services.
- ✓
Vendor's financial stability
Why this is correct
Financial instability can cause a vendor to cut security investment, reduce support, or cease trading, disrupting the software the organisation depends on. Evaluating financial stability identifies continuity and viability risk, a required factor when identifying third-party risks from a critical software vendor.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CRISC question from scratch — 1,062 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official ISACA exam blueprint
This CRISC practice question is part of Courseiva's free ISACA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CRISC exam.