Third-Party and Cloud Technology Risk

Why This Topic Matters for the CRMA Exam

Modern organizations rarely operate in isolation. Payroll is outsourced, customer data sits in a software-as-a-service platform, infrastructure runs on a hyperscale cloud provider, and critical business processes depend on a web of vendors, suppliers, and service providers. When an organization hands a process or a dataset to someone else, it transfers the activity but never the accountability. The board and senior management remain responsible for the outcomes, and internal audit remains responsible for providing assurance that risks arising from those relationships are identified, assessed, and managed within the organization's risk appetite.

In the CRMA (Certification in Risk Management Assurance) syllabus, this subject falls under evaluating risk management processes. The exam tests whether you can recognize the distinctive risks created by third parties and cloud technology, understand how a mature risk management framework addresses them, and judge whether internal audit's assurance activities over these processes are adequate. Questions are typically scenario based: you will be asked what internal audit should recommend, what the most significant risk is, or which control gap is most critical. Mastering the concepts below will let you reason through those scenarios with confidence.

What Is Third-Party Risk?

Third-party risk is the potential for loss, disruption, regulatory breach, or reputational damage arising from an organization's reliance on external entities to deliver products, services, data, or processes. Third parties include vendors, suppliers, outsourcing providers, contractors, consultants, joint-venture partners, distributors, agents, franchisees, and technology providers.

Key categories of third-party risk you should be able to recognize:

Operational risk: the provider fails to deliver, delivers late, or delivers poor quality, disrupting your processes.
Information security and privacy risk: the provider mishandles, loses, or exposes confidential data, including personal data subject to privacy law.
Compliance and regulatory risk: the provider's actions cause the organization to breach laws (anti-bribery, sanctions, data protection, industry regulation). Regulators generally hold the outsourcing organization accountable, not the vendor.
Financial risk: the provider becomes insolvent, raises prices unexpectedly, or causes financial misstatement through faulty processing.
Strategic risk: the relationship no longer supports the organization's objectives, or lock-in prevents the organization from pivoting.
Reputational risk: the provider's misconduct (labor abuses, environmental damage, ethical lapses) is attributed to the organization.
Concentration risk: too many critical services rely on a single provider, a single geography, or a small cluster of providers.
Fourth-party (subcontractor) risk: your vendor relies on its own vendors, extending the chain of dependency beyond your direct visibility.
Geopolitical and country risk: political instability, legal uncertainty, or data localization rules in the provider's jurisdiction.

What Is Cloud Technology Risk?

Cloud computing is the delivery of computing resources (servers, storage, databases, networking, software, analytics) over the internet on a pay-as-you-go basis. It is a specialized and increasingly dominant form of third-party relationship, with its own vocabulary that the exam expects you to know.

Service models:
Infrastructure as a Service (IaaS): the provider supplies virtualized computing, storage, and networking; the customer manages operating systems, applications, and data.
Platform as a Service (PaaS): the provider supplies the runtime environment and development tools; the customer manages applications and data.
Software as a Service (SaaS): the provider supplies a complete application; the customer manages only its data, user access, and configuration.

Deployment models:
Public cloud: shared infrastructure operated by a provider for many customers (multi-tenant).
Private cloud: dedicated infrastructure for one organization, hosted internally or by a provider.
Hybrid cloud: a combination of public and private, often with workloads moving between them.
Multi-cloud: use of multiple public cloud providers, often to reduce concentration risk.

The Shared Responsibility Model: this is the single most tested cloud concept. The provider is responsible for security of the cloud (physical facilities, hardware, hypervisor, core network). The customer is responsible for security in the cloud (data classification, encryption key management, identity and access management, configuration, application security). The dividing line shifts with the service model: in IaaS the customer carries most of the burden; in SaaS the provider carries most, but the customer always retains responsibility for its data and its users. Many real-world breaches arise from customers assuming the provider handles something that is actually the customer's job, such as misconfigured storage buckets left publicly accessible.

Distinctive cloud risks:
Data location and sovereignty (where is the data physically stored, and whose laws apply?)
Multi-tenancy and data segregation (can another tenant access your data?)
Vendor lock-in and portability (can you extract your data and move?)
Loss of direct control and limited right to audit the provider
Identity and access management sprawl, including privileged access and API keys
Misconfiguration (the leading cause of cloud breaches)
Availability and resilience, including dependence on the provider's disaster recovery
Shadow IT: business units subscribing to cloud services without IT or risk oversight
Cost overruns from uncontrolled consumption
Provider viability and sudden service termination
Incident response coordination: who detects, who notifies, within what timeframe?

How Third-Party Risk Management (TPRM) Works

A mature TPRM program follows a lifecycle. Internal audit evaluates whether each stage exists, is applied consistently, and is proportionate to the risk of the relationship.

1. Governance and framework. The board sets risk appetite for outsourcing. Management establishes a TPRM policy, defines roles (business owner, procurement, legal, IT security, risk, compliance), and maintains a complete inventory of third parties. Without a complete inventory, nothing else works, so auditors frequently test inventory completeness first.

2. Planning and risk assessment. Before engaging a vendor, the organization assesses the inherent risk of the service: Is it critical to operations? Does it involve sensitive data? Is it regulated? What is the financial exposure? Vendors are tiered (for example, critical, high, medium, low), and the depth of due diligence and monitoring is scaled to the tier.

3. Due diligence and selection. Proportionate investigation of the vendor's financial stability, ownership, reputation, security posture, compliance record, business continuity capabilities, subcontractor use, and insurance. For technology providers this includes reviewing independent assurance reports, certifications, and penetration test results.

4. Contracting. The contract converts expectations into enforceable obligations. Key clauses you should be able to identify: service level agreements (SLAs) with measurable metrics and remedies; right to audit (or right to receive assurance reports); data ownership, protection, confidentiality, and breach notification timelines; subcontracting restrictions and notification; business continuity and disaster recovery commitments; compliance with specified laws and standards; termination rights and exit assistance; data return and destruction at termination; limitation of liability and indemnification; insurance requirements; and change management for material changes to the service.

5. Onboarding and integration. Secure data transfer, access provisioning on least-privilege principles, integration testing, and training.

6. Ongoing monitoring. Risk does not stop at signing. Monitoring includes SLA performance reporting, periodic reassessment of risk tier, review of updated assurance reports, financial health checks, news and sanctions screening, security questionnaires, site visits for critical vendors, issue and incident tracking, and escalation of breaches. Monitoring intensity must match criticality.

7. Termination and exit. A documented exit strategy for every critical vendor, tested where feasible, covering data retrieval in a usable format, secure destruction confirmation, transition to an alternative provider or in-house, and revocation of all access.

Understanding Third-Party Assurance Reports

Because organizations cannot usually audit a large cloud provider directly, they rely on independent assurance reports. The exam expects you to distinguish them.

SOC 1: reports on controls at a service organization relevant to the user entity's internal control over financial reporting. Used mainly by financial statement auditors.
SOC 2: reports on controls relevant to the Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. This is the primary report for evaluating technology and cloud providers.
SOC 3: a general-use summary of SOC 2 without detailed test results, often used for marketing.
Type 1 versus Type 2: a Type 1 report describes the design of controls at a point in time. A Type 2 report tests operating effectiveness over a period (typically six to twelve months). Type 2 provides significantly stronger assurance, and a correct exam answer will usually prefer Type 2 for critical providers.

When reviewing any assurance report, a competent reviewer checks: the report period and whether gaps exist between report periods (bridge letters cover the gap); the scope, to confirm it includes the services and locations actually used; the auditor's opinion and any qualifications; exceptions noted in testing and management responses; complementary user entity controls (CUECs), which are controls the service provider assumes the customer performs (for example, approving user access) and which the customer must actually implement; and subservice organizations that were carved out of the report, which represent fourth-party exposure requiring separate evaluation.

Other relevant certifications and standards include ISO/IEC 27001 (information security management systems), ISO/IEC 27017 and 27018 (cloud-specific security and privacy), PCI DSS (payment card data), CSA STAR (Cloud Security Alliance), and regional frameworks such as FedRAMP. A certificate alone is not sufficient; auditors should confirm scope and currency.

Internal Audit's Role in Evaluating Third-Party and Cloud Risk

Under the IIA's Global Internal Audit Standards, internal audit provides independent assurance on governance, risk management, and control processes, and third-party relationships are explicitly within scope. Internal audit's role is to evaluate, not to own, TPRM. Typical audit activities:

Assessing whether the TPRM framework is aligned with the organization's risk appetite and regulatory obligations.
Testing completeness of the third-party inventory against accounts payable, contracts, and network traffic to detect shadow IT.
Evaluating whether risk tiering is consistently applied and whether critical vendors have received appropriate due diligence.
Reviewing a sample of contracts for required clauses.
Verifying that assurance reports are obtained, reviewed, and that exceptions and CUECs are acted upon.
Testing cloud configuration controls, identity and access management, encryption, logging, and backup and recovery for critical cloud workloads.
Evaluating business continuity and exit plans for critical providers.
Assessing concentration risk and whether the board receives meaningful reporting on third-party exposure.
Including third-party and cloud risk in the risk-based audit plan and coordinating with other assurance providers (second line, external auditors, regulators) to avoid gaps and duplication.

Internal audit must also maintain independence: it should not negotiate vendor contracts, select vendors, or operate the TPRM program, because doing so would compromise its ability to provide objective assurance.

Three Lines Model Applied to Third-Party Risk

First line: business owners who select and manage vendors and own the risk.
Second line: procurement, vendor risk management, information security, compliance, and enterprise risk functions that set policy, provide tools, and monitor.
Third line: internal audit, providing independent assurance over the first and second lines.
Exam questions frequently test whether you can place a responsibility in the correct line. Remember that risk ownership never moves to the vendor or to internal audit.

Exam Tips: Answering Questions on Third-Party and Cloud Technology Risk

Tip 1: Accountability cannot be outsourced. If an answer choice implies the vendor is accountable for the organization's compliance, data protection, or outcomes, it is wrong. The organization retains accountability; the vendor has contractual responsibility. This single principle eliminates many distractors.

Tip 2: Apply the shared responsibility model. When a scenario describes a cloud incident, ask which side of the line the failure sits on. Misconfigured access, weak passwords, unencrypted data uploads, and excessive privileges are almost always the customer's responsibility. Physical security and hypervisor patching are the provider's.

Tip 3: Prefer Type 2 over Type 1, and SOC 2 over SOC 1 for technology risk. If the question is about security, availability, or confidentiality of a cloud service, the SOC 2 Type 2 report is the strongest option. If the question is about financial reporting controls at a payroll processor, SOC 1 is relevant.

Tip 4: Look for complementary user entity controls. A scenario that says management received a clean SOC report and took no further action is signaling a gap. The correct response usually involves verifying that CUECs are implemented and that carved-out subservice organizations are evaluated.

Tip 5: Proportionality is the test of a mature program. Correct answers scale due diligence and monitoring to vendor criticality and data sensitivity. An answer that applies identical heavy procedures to every vendor, or that ignores a critical vendor, is weaker than a risk-based approach.

Tip 6: Inventory completeness comes first. If asked what internal audit should do first when evaluating TPRM, the best answer is usually to confirm that a complete inventory of third parties exists and is risk-tiered. You cannot assess what you do not know about.

Tip 7: Contracts are controls. When a scenario describes a vendor problem with no remedy available, the root cause is often a missing contract clause (right to audit, breach notification, exit assistance, subcontractor approval). Recognize this pattern.

Tip 8: Watch for concentration and fourth-party risk. If several critical services sit with one provider or one region, or if a vendor's subcontractor is unknown, the most significant risk in the scenario is often concentration or lack of visibility down the supply chain.

Tip 9: Exit strategy is a control, not an afterthought. Questions about vendor lock-in, provider insolvency, or sudden service termination point to the need for documented, tested exit plans and data portability provisions.

Tip 10: Keep internal audit independent. Any answer that has internal audit selecting vendors, negotiating contracts, or running the vendor risk function is incorrect because it impairs objectivity. Internal audit evaluates and advises; it does not own.

Tip 11: Read for the keyword that defines the question. Words like most significant, primary, first, best, and least change the answer. Several choices may be reasonable; you must select the one that best fits the qualifier. Eliminate choices that are true in general but do not answer the specific question.

Tip 12: Connect to the broader risk management process. The CRMA is about risk management assurance. Frame your thinking in terms of risk identification (is the third party in the inventory?), assessment (is it correctly tiered?), response (are contract and controls adequate?), monitoring (is performance and risk reviewed?), and reporting (does the board see the exposure?). Answers that complete this cycle are stronger than answers that address a single point in time.

Quick Review Summary

Third-party risk arises whenever the organization depends on an external entity; the activity transfers, the accountability does not.
Cloud risk is a specialized third-party risk defined by service models (IaaS, PaaS, SaaS), deployment models (public, private, hybrid, multi-cloud), and the shared responsibility model.
A mature TPRM lifecycle covers governance, risk assessment and tiering, due diligence, contracting, onboarding, ongoing monitoring, and exit.
SOC 2 Type 2 reports, with attention to scope, period, exceptions, CUECs, and carve-outs, are the primary assurance tool for cloud providers.
Internal audit independently evaluates the TPRM program, tests critical relationships, and reports to the board, while never owning or operating the program.
On the exam, anchor every answer in accountability, proportionality, the shared responsibility model, contract-as-control, and internal audit independence.