Third-Party Risk Management Program: The Full Lifecycle

Third-party risk management is the program most organisations believe they have and fewest can show. There is a vendor list somewhere, a questionnaire that goes out at onboarding, a folder of SOC reports nobody has read past the opinion page, and a procurement policy that says the word “risk” twice. What there is not, usually, is a lifecycle: a single set of decisions that starts before a supplier is chosen, runs through contracting and monitoring, and ends with an exit that was planned rather than improvised. This guide sets out that lifecycle end to end, with the tiering model that decides how much of it applies to a given relationship, the contract clauses that matter, the monitoring cadence, the exit mechanics, and the governance around all of it, and closes with an internal audit program mapped to the IIA’s Third-Party Topical Requirement, which takes effect today, 15 September 2026, and a worked example from a regional bank.

The sources are the ones supervisors and assessors will hold you to. The US banking agencies’ Interagency Guidance on Third-Party Relationships: Risk Management (June 2023) supplies the life-cycle vocabulary and the due-diligence factors; the IIA’s Third-Party Topical Requirement supplies the seventeen conformance requirements internal auditors must now assess (see the requirement mapped for 15 September); the EU’s DORA, the EBA outsourcing guidelines, the PRA’s SS2/21 and the UK’s Critical Third Parties regime supply the regulated-sector specifics; NIST SP 800-161 and ISO/IEC 27036 supply the supply-chain security controls. The program below is written to conform to all of them at the level of design, because a program that satisfies the strictest of them satisfies the rest.

In this guide

What the program has to satisfy: the regimes and what each demands
The lifecycle in seven stages, mapped to the Topical Requirement
Risk-based tiering: the decision that sizes everything else
The contract clauses that matter, and what to test in each
Ongoing monitoring: cadence, indicators and the review that is not a questionnaire
Termination and exit: the stage nobody plans
Governance: inventory, ownership, independent review and reporting
The internal audit program: fifteen tests mapped to the requirement
Worked example: a regional bank rebuilds its program before the examiners return
Related guides

What the program has to satisfy: the regimes and what each demands

Most TPRM programs were built to satisfy one regulator and then patched as others arrived, which is why so many have three vendor inventories and two definitions of “critical”. The regimes below overlap heavily on substance. Read together, they describe one program: a complete inventory, a risk-based tiering, due diligence proportionate to tier, contracts with specific protections, monitoring through the life of the relationship, a planned exit, and governance that includes independent review. The differences are in scope, in vocabulary, and in how prescriptive each is about evidence.

Regime	Who it binds	What it demands of the program	Status and dates
Interagency Guidance on Third-Party Relationships: Risk Management (FRB, FDIC, OCC)	US banking organisations of all sizes, applied in proportion to risk and complexity	A life cycle of planning, due diligence and third-party selection, contract negotiation, ongoing monitoring and termination; governance through oversight and accountability, independent reviews, and documentation and reporting; fourteen named due-diligence factors; heightened attention to “critical activities”	Issued 6 June 2023 (OCC Bulletin 2023-17, SR 23-4, FIL-29-2023); replaced the OCC’s 2013 bulletin and 2020 FAQs and the Fed’s 2013 outsourcing letter
IIA Third-Party Topical Requirement	Internal audit functions conforming with the Global Internal Audit Standards, whenever third-party management is the subject of, or arises in, an assurance engagement	Seventeen requirements across Governance (A to D), Risk Management (A to D) and Control Processes (A to I), covering strategy and policy, roles, risk assessment, due diligence, contracting, inventory, onboarding, monitoring, escalation, renewal and offboarding	Issued 15 September 2025, effective 15 September 2026; see the Topical Requirements explainer for how the requirements bind
DORA (Regulation (EU) 2022/2554) and its technical standards	EU financial entities and their ICT third-party providers	ICT third-party risk as part of the ICT risk framework; a register of information for all ICT contractual arrangements; mandatory contract terms (Article 30); subcontracting rules; exit strategies for services supporting critical or important functions; oversight of critical ICT providers	Applies from 17 January 2025; register template ITS 2024/2956; subcontracting RTS 2025/532; nineteen critical providers designated 18 November 2025; see DORA for internal auditors
EBA Guidelines on outsourcing (EBA/GL/2019/02) and PRA SS2/21	EU and UK banks, investment firms and payment institutions	Outsourcing register, materiality assessment, pre-outsourcing analysis, contractual requirements including audit and access rights, exit plans for critical or important functions, notification to supervisors	EBA guidelines apply since 30 September 2019; SS2/21 in force since March 2021 with implementation by March 2022
UK Critical Third Parties regime	Providers designated by HM Treasury; indirectly every UK financial firm that depends on them	Direct oversight of designated providers’ resilience by the Bank of England, PRA and FCA; firms remain responsible for their own outsourcing arrangements	Rules in force 1 January 2025; first designations on 10 July 2026 (Amazon Web Services EMEA SARL, Google Cloud EMEA Limited, Microsoft Ireland Operations Ltd, Oracle Corporation UK Limited), oversight from 13 July 2026
NIST SP 800-161 Rev. 1 and ISO/IEC 27036	Voluntary; the reference for supply-chain security controls in any sector	Cybersecurity supply-chain risk management practices across the acquisition life cycle; supplier relationship security requirements	SP 800-161r1 published May 2022; ISO/IEC 27036 parts revised through 2023

Two points of scope decide a great deal. First, every regime above defines the relationship broadly: the interagency guidance covers “any business arrangement between a banking organization and another entity, by contract or otherwise”, and the Topical Requirement reaches an external party’s own suppliers where they matter. A program scoped to “vendors with a purchase order” misses affiliates, agents, joint-venture partners, fintech partners, open-source dependencies and the auditors’ own co-source firm. Second, every regime is risk-based. None of them asks for the full lifecycle on every relationship; all of them ask for a defensible way of deciding which relationships get it, which is the tiering model below.

The lifecycle in seven stages, mapped to the Topical Requirement

The interagency guidance names five stages; the Topical Requirement’s control-process requirements imply nine activities; most programs run somewhere between. We use seven stages, because two decisions that the guidance folds into “planning” and “ongoing monitoring” deserve their own owners and their own evidence: the tiering decision that sizes everything else, and the onboarding step where a signed contract becomes a working arrangement with access, data flows and a named relationship owner. The table shows each stage, the decision it exists to make, the artefact that proves the decision was made, and where the stage lands in the two frameworks auditors will be asked to map to.

Stage	The decision	The artefact	Interagency stage	Topical Requirement
1. Planning and the make-or-buy decision	Should this activity be performed by a third party at all, and what would failure cost?	Business case with a risk section; inherent risk assessment before any supplier is approached	Planning	Governance A (formal approach); Control Processes A (due diligence and business case)
2. Tiering and inherent risk	How critical is this relationship, and how much of the lifecycle applies?	Tier assignment with the criteria scored; the tier drives every later stage	Planning (critical activities)	Risk Management A to C (standardised assessment, criticality, downstream risk)
3. Due diligence and selection	Can this specific supplier do the work, survive the contract term, and protect what we give it?	Due-diligence file proportionate to tier; the fourteen interagency factors for the highest tier	Due diligence and third-party selection	Control Processes A
4. Contracting	What rights, obligations and remedies does the organisation need in writing?	Contract negotiated against a clause standard, reviewed by legal and the risk function, approved at the right level, stored where it can be found	Contract negotiation	Control Processes B and C (contracting per policy; contracts reviewed, approved, signed, stored)
5. Onboarding	What has to be true before the supplier starts: access, data, integration, training, relationship owner?	Onboarding checklist signed off; inventory record complete	Ongoing monitoring (start)	Control Processes D (inventory) and E (onboarding)
6. Ongoing monitoring	Is the supplier still performing, still solvent, still secure, still the supplier we contracted with?	Monitoring calendar by tier; performance, risk and compliance evidence; issues escalated and tracked; renewal decisions taken in time	Ongoing monitoring	Control Processes F (monitoring), G (corrective action and escalation), H (expiration and renewal)
7. Termination and exit	How does the relationship end without losing data, service or control?	Exit plan for higher tiers written before it is needed; offboarding checklist executed; access removed, data returned or destroyed, inventory closed	Termination	Control Processes I (offboarding)

The mapping matters for a practical reason. When an internal auditor assesses the program under the Topical Requirement, every one of the seventeen requirements has to be assessed for applicability and either evidenced or excluded with a rationale, and the applicability record is itself evaluated in external quality assessments. A program organised by the stages above produces that evidence as a by-product; a program organised around a questionnaire tool produces it only under duress, in the week before the audit.

Risk-based tiering: the decision that sizes everything else

Tiering is where TPRM programs succeed or fail, because the tier decides how much diligence, which contract clauses, how often to monitor, and whether an exit plan is required. Two failure modes recur. The first is tiering by spend, which puts the stationery contract above the free API that authenticates every customer login. The second is tiering by questionnaire, in which the supplier’s own answers set the tier, so the least honest suppliers get the least scrutiny. Tiering has to be done by the organisation, before the supplier is asked anything, on the inherent risk of the activity being sourced. The criteria below are the ones every regime above recognises, and the four tiers are a default; a smaller organisation can run three, and a bank with several thousand relationships may need five.

Tier	Criteria (any one qualifies)	Due diligence depth	Contract standard	Monitoring cadence	Exit plan
Tier 1: critical	Supports a critical or important business service; failure would breach an impact tolerance, a regulatory obligation or a customer commitment; holds or processes sensitive personal or financial data at scale; is hard to substitute within the recovery time objective; sector-wide concentration (cloud, core processing, payments, market data)	Full: all fourteen interagency factors, on-site or virtual assessment, financial analysis, security testing evidence, subcontractor map, resilience test results, key-person and location review	Full clause set including audit and access rights, regulator access, subcontracting consent, exit and transition assistance, data return, resilience obligations, incident notification within a fixed period	Quarterly performance and risk review; annual full reassessment; continuous external signals (financial, cyber, adverse media); annual site or control assessment	Mandatory, tested, with a named substitute or in-house option and a realistic transition period
Tier 2: significant	Supports an important process without breaching tolerances on failure; moderate data sensitivity; substitutable within weeks to months; meaningful spend or contractual commitment	Standard: financial condition, security assurance report review, compliance screening, references, resilience plan existence, subcontractor disclosure	Standard clause set with audit rights, data protection, notification, termination for cause and convenience	Semi-annual performance review; annual reassessment; external signals monitored	Documented approach, not necessarily tested
Tier 3: managed	Routine services or goods with limited data and limited operational dependence; readily substitutable	Light: legal existence, sanctions and adverse-media screening, insurance, basic security attestation where data is touched	Standard terms and conditions; data protection addendum if any data is processed	Annual confirmation the relationship is still needed and still compliant; performance managed by the business owner	None beyond notice and data deletion
Tier 4: transactional	One-off or low-value purchases with no data, no access and no dependence	Screening only	Purchase order terms	None; inventory entry closed at completion	None

Three rules keep tiering honest. The tier is assigned by the business owner and confirmed by the risk function, never by procurement alone and never by the supplier. Any relationship that touches production systems, customer data or a regulated process starts at Tier 2 regardless of spend and must be argued down, not up. And the tier is revisited whenever the scope changes, because the supplier engaged for a pilot in one department is, three years later, running a critical process for the whole company, still carrying the tier it was given as a pilot. The same drift is described from the control side in the vendor master audit guide, where the master file is the record that should catch it.

The contract clauses that matter, and what to test in each

A contract is the only stage of the lifecycle where the organisation’s leverage is at its peak and its knowledge at its lowest, which is why the clause standard has to exist before negotiation starts and why the interagency guidance devotes more words to contract negotiation than to any other stage. The table gives the clauses that decide outcomes when a relationship goes wrong, the reason each exists, and the test an auditor runs against a sample of executed contracts. The test is rarely “is the clause present”; it is “is the clause specific enough to be enforced, and has anyone ever used it”.

Clause	Why it matters	What the auditor tests
Scope and service description with performance measures	Without measurable service levels there is nothing to monitor and nothing to enforce	Service levels are quantified, reported by the supplier, and reconciled by the organisation; remedies for breach are stated and have been invoked or waived deliberately
Right to audit and access to information	The organisation, its auditors and, in regulated sectors, its supervisors need access to the supplier’s premises, systems and records relevant to the service	The right extends to internal audit and regulators, is not limited to a SOC report, and has been exercised at least once for Tier 1 relationships
Information security and data handling	Defines the controls the supplier must operate, the data it may hold, where, and what happens to it at the end	Security obligations reference a standard or the organisation’s own requirements; data location and cross-border transfer are specified; deletion and return obligations are time-bound and certified
Incident notification	The organisation’s own regulatory clocks (72 hours under GDPR, four business days under the SEC’s Item 1.05, DORA’s classification and reporting deadlines) start when it learns of an incident, so the supplier’s notification period has to be shorter than the organisation’s	A fixed notification period in hours, not “promptly”; a named channel; evidence of any notifications received and the elapsed time
Subcontracting	The supplier’s suppliers inherit the risk without the contract; DORA and the EBA require consent or notification for subcontracting of critical functions	Subcontracting of the critical part of the service requires consent; a current subcontractor list has been provided; flow-down of security and audit obligations is contractual
Business continuity and resilience	The supplier’s recovery objectives have to be at least as tight as the organisation’s tolerance for the service	Recovery time and point objectives are stated and match the organisation’s; test results, not test policies, are provided annually; the guide on business continuity and resilience covers the evidence standard
Termination rights and exit assistance	The ability to leave is the ultimate control; without transition assistance and data return the right to terminate is theoretical	Termination for cause, for convenience and on regulatory direction; a transition period long enough to migrate; assistance obligations priced or included; data return in an open format
Compliance with laws and regulatory cooperation	Regulated organisations cannot outsource their obligations; the supplier must comply with the laws that apply to the service and cooperate with the organisation’s supervisors	The clause names the applicable regimes; the supplier’s own compliance evidence has been requested and reviewed
Liability, indemnity and insurance	Allocates the financial consequences of failure; caps set too low make the other clauses hollow	Caps are proportionate to the exposure assessed at tiering; insurance certificates are current and match the required cover
Change and renewal	Scope creep and auto-renewal are how a Tier 3 contract becomes a Tier 1 dependency without anyone deciding	Material changes require re-assessment; renewal dates are in the inventory with a decision point before the notice deadline

One rule for auditors: read the executed contract, not the template. In every program we have assessed, the template was adequate and a material share of the executed Tier 1 contracts departed from it, usually in the audit rights and liability clauses, usually because the supplier’s paper was used instead of the organisation’s. The departure is not a finding by itself; an undocumented departure with no risk acceptance is.

Ongoing monitoring: cadence, indicators and the review that is not a questionnaire

Monitoring is where TPRM programs quietly collapse into an annual questionnaire. The questionnaire has its place, but a supplier’s answers about itself are the weakest evidence in the file, and a relationship changes between questionnaires: the supplier is acquired, loses its key engineer, moves the service to a new subcontractor, has a breach it does not mention, or starts missing service levels that nobody reconciles. Monitoring that works has four strands, each with its own cadence set by tier. Performance monitoring reconciles the supplier’s service-level reporting to the organisation’s own experience, monthly for Tier 1. Risk monitoring refreshes the assessment on a calendar, annually for Tier 1 and 2, and on trigger for everyone: a change of ownership, a breach, a regulatory action, a material change of scope. Compliance monitoring re-runs the screenings that were done at onboarding, sanctions and adverse media at least annually and continuously where a tool exists. And assurance monitoring reads the assurance reports properly, which means the method in how to review a SOC 1 report and how to review a SOC 2 report, complementary user entity controls included, rather than filing the PDF.

Key risk indicators turn monitoring from a calendar into an early-warning system. The useful ones are few: service-level breaches per quarter by Tier 1 supplier; overdue due-diligence refreshes as a share of Tier 1 and 2; contracts past renewal date without a decision; open supplier-related issues past their due date; suppliers with a material adverse signal (financial, cyber, regulatory) in the period and the days to the organisation’s response; and inventory completeness, measured by reconciling the register to payments, as described under governance. Each indicator needs an owner and a threshold that triggers escalation, which is what the Topical Requirement’s Control Processes G requires and what most programs lack: a defined route from “the monitoring found something” to “someone with authority decided what to do”.

Termination and exit: the stage nobody plans

Exit is the stage every regime requires and almost no program has evidence for, because exits are rare, unpleasant and usually urgent. There are two kinds. A planned exit, at the end of a term or on a sourcing decision, is a project with a transition period, and its risks are data migration, knowledge transfer and the double-running cost; the clause work above is what makes it possible. A stressed exit, when the supplier fails, is acquired by a competitor, suffers a breach the organisation cannot tolerate, or is directed out by a regulator, is the case exit planning exists for, and it is why DORA requires exit strategies for ICT services supporting critical or important functions and the EBA and PRA require exit plans for critical or important outsourcing. The plan for a Tier 1 relationship answers five questions in writing before anything has gone wrong: what would we do tomorrow if this supplier stopped, for how long could we operate without the service, who else could provide it or could we bring it in-house, what data and configuration would we need back and in what format, and what would the transition cost and take. A plan that has never been tested, at least as a walkthrough with the business owner, is an assertion; the resilience guide on whether you can actually recover applies the same test to the organisation’s own systems.

Offboarding is the operational tail of exit and the part auditors can test on every terminated relationship in the period: access removed from every system on the day the service ended, not at the next quarterly review; data returned or destroyed with a certificate; keys, badges, tokens and integrations revoked; final invoices reconciled to the contract; the inventory record closed; and the lessons recorded for the next sourcing decision. Control Processes I of the Topical Requirement makes offboarding a named control for the first time in a mandatory standard, and the evidence most programs cannot produce is the first item, because terminated suppliers’ accounts live on in directories for years. The privileged-access findings in the IAM audit guide and the external-account population in the worked example below are the same problem seen from two sides.

Governance: inventory, ownership, independent review and reporting

The interagency guidance’s governance section has three headings, oversight and accountability, independent reviews, and documentation and reporting, and the Topical Requirement’s Governance domain adds strategy, policy and defined roles. In practice governance comes down to four things an assessor will ask for on day one. A complete inventory: one register of every relationship in scope, with tier, owner, contract dates, data classification, subcontractors and the status of each lifecycle stage; completeness is tested by reconciling the register to twelve months of payments and to external accounts in the identity directory, and the result is the single most revealing number in any TPRM assessment. Named ownership: a business owner for every relationship, a program owner for the framework, and a committee that sees the Tier 1 population, the indicators and the exceptions on a fixed cadence. Independent review: internal audit assessing the program against the requirements on a risk-based cycle, with the Topical Requirement now setting what that assessment must cover; the guide to GIAS Domain III covers the board’s side of that arrangement. And reporting: a periodic report to senior management and the board that shows the risk profile of the third-party population, not the activity of the TPRM team, which is a distinction most board packs miss.

The internal audit program: fifteen tests mapped to the requirement

The program below is written for a first assurance engagement over the TPRM program as a whole, sized for a mid-sized organisation at 350 to 500 hours, and each test carries the Topical Requirement reference it evidences so that the applicability record writes itself. Sample sizes follow the conventions in the sample size guide; for Tier 1 populations under forty, test the whole population.

Governance (TR Governance A to D). 1. Obtain the third-party strategy or sourcing approach, the policy and the framework; confirm they are approved, current, cover the full definition of a third party, and assign roles for every lifecycle stage. 2. Confirm the oversight committee has met on its stated cadence with the Tier 1 population, indicators and exceptions on its agenda, and that decisions are minuted with owners. 3. Confirm senior management and the board have received reporting on the third-party risk profile in the period, and that the reporting reconciles to the inventory.
Risk management (TR Risk Management A to D). 4. Reconcile the inventory to twelve months of accounts payable and to external identities in the directory; compute completeness by count and by spend; investigate every unlisted paid provider and every orphan account. 5. Re-perform tiering for a sample of twenty relationships across tiers against the stated criteria; identify relationships tiered by spend or by supplier questionnaire, and relationships whose scope changed without re-tiering. 6. Confirm the risk assessment covers downstream (fourth-party) risk for Tier 1 relationships: a subcontractor list exists, is current and has been assessed. 7. Confirm concentration has been assessed: the organisation knows which single providers, and which providers’ providers, underlie multiple critical services.
Control processes (TR Control Processes A to I). 8. For a sample of Tier 1 and Tier 2 relationships onboarded in the last two years, test that due diligence was performed at the depth required for the tier before contract signature, and that findings were resolved or accepted by someone with authority (A). 9. For the same sample, test the executed contract against the clause standard, confirm legal and risk review, approval at the right level and storage in the contract repository; list departures and whether they were accepted (B, C). 10. Test the inventory record for the sample: complete, accurate, current, with tier, owner, dates and data classification (D). 11. Test onboarding evidence: access provisioned as approved, data flows documented, relationship owner named, checklist signed (E). 12. Test monitoring for Tier 1: service levels reconciled, annual reassessment done on time, assurance reports reviewed with complementary controls mapped, screenings re-run, external signals acted on (F). 13. Trace every supplier-related issue and adverse signal in the period to an escalation decision within the defined threshold and to a tracked corrective action (G). 14. Test contracts expiring in the next twelve months for a renewal decision before the notice deadline, and contracts renewed in the period for a re-assessment (H). 15. For every relationship terminated in the period, test offboarding: access removal date against service end date, data return or destruction certificate, inventory closure, final settlement (I); for all Tier 1 relationships, confirm an exit plan exists and has been walked through with the business owner.

Report the results as a program conclusion by domain, then as findings, then as the applicability record, because the three audiences differ: the board wants the conclusion, management wants the findings with owners and dates, and the quality assessor wants to see that all seventeen requirements were considered. The rating discipline in the finding severity guide applies; a 63 per cent inventory is High on any scale, however good the rest of the program looks.

Worked example: a regional bank rebuilds its program before the examiners return

Lakeshore Bancorp is a 9-billion-dollar public regional bank with a 22-person internal audit function, a core banking platform hosted by a service organisation, an in-house digital channels team, a mortgage subsidiary, a wealth subsidiary and a cloud estate that, when audited, held 62 accounts against 48 anyone knew about. Its third-party program had grown the way most do: a procurement register, a vendor management tool bought for the questionnaires, a security team that reviewed SOC reports for the vendors it knew about, and a policy last revised when the 2013 guidance was current. At the previous examination the bank had received an observation that the inventory could not be reconciled to payments and that the core provider had no tested exit plan. The chief audit executive put a 440-hour program audit into the plan for the year the Topical Requirement took effect, and the second line began a rebuild in parallel, which is the example.

The inventory came first, because everything else is sized by it. Reconciling twelve months of payments to the register produced 1,140 paid providers against 690 registered, and the identity directory held 58 external accounts belonging to providers on neither list, most of them former contractors’ staff. Tiering the reconciled population against the criteria in this guide, by the business owners with the risk function confirming, produced 41 Tier 1 relationships, 210 Tier 2 and the rest in Tiers 3 and 4. The Tier 1 list contained the expected names, the core provider, the card processor, the digital banking vendor, the mortgage loan origination system, the wealth custodian, the managed security service and the two cloud providers, and three the bank had not been treating as critical: the statement printing and mailing provider, the payroll provider, and a small firm that hosted the bank’s online account-opening flow, which had been tiered as a marketing vendor when it was engaged for a pilot four years earlier.

Internal audit’s fifteen tests ran against the rebuilt population, and the results fell where the lifecycle predicted. Due diligence had been refreshed within the calendar for 24 of the 41 Tier 1 relationships; the other 17 were between fourteen months and four years old. Fourteen Tier 1 contracts were on the supplier’s paper and lacked regulator access rights or a fixed incident-notification period, none with a documented acceptance. Subcontractor lists existed for 12 of 41; for the core provider the list was two years old and did not show that the provider had moved its disaster-recovery site to a public cloud region, which meant the bank’s largest concentration was one it did not know it had. Exit plans existed for 9 of 41 and had been walked through for 2. Offboarding was the strongest area on paper and the weakest in evidence: the 58 orphan accounts were the population, and 31 of them belonged to relationships terminated more than a year earlier. Monitoring reconciled service levels for the core provider and the card processor and for nobody else.

The report rated the program Needs Improvement with three High findings (inventory completeness, contract standard departures without acceptance, exit planning for critical relationships), four Medium and two Low, eleven actions with owners and dates, and an applicability record showing all seventeen requirements assessed with none excluded. Management’s response was the rebuild plan: the reconciled register as the single inventory, a quarterly reconciliation to payments and the directory as a standing control, contract addenda for the fourteen Tier 1 departures within six months, exit plans for all Tier 1 within twelve months with the core provider’s plan tested first, and a monitoring calendar by tier. The audit committee asked one question, which was whether the bank had known about the core provider’s cloud move, and the honest answer, that it had not, did more for the program’s budget than the findings did. The concentration side of that discovery is the subject of the fourth-party and concentration guide, and the due-diligence depth by tier that the rebuild adopted is set out in vendor due diligence by risk tier.

Comments

Leave a ReplyCancel reply

Financial Statement Fraud: How the Numbers Get Cooked, and Who Should Catch It

Procurement Fraud Schemes: Bid Rigging, Kickbacks and Phantom Vendors, and How to Find Them

When Internal Audit Finds Fraud: The First 48 Hours Protocol

The Field Desk Series

Third-Party Risk Management End-to-End: The Full Lifecycle Program