How to run a TPRM gap assessment before your next audit

A gap assessment belongs to the second line. The head of third-party risk, or the compliance or operational risk lead who owns the TPRM policy, runs it, because that person owns the controls and owns the remediation that follows. The business lines contribute as control operators and the owners of the relationships. Internal audit does not run it.

That last point matters more than it used to. A third party risk management audit performed by internal audit under The IIA's Third-Party Topical Requirement is the independent assessment. If audit runs your gap assessment, it is assessing its own work in the fieldwork that follows, and the Interagency Guidance separates the two for a reason: it calls for periodic independent reviews of the adequacy of third-party risk management processes as a distinct governance element from management's own oversight. Ask audit to agree the scope and the standard with you, then let them stay out of the room until the report is done.

Give the independent reviewer real work. A reviewer who only reads the finished report will approve it. A reviewer who re-performs five of the control tests and challenges the three highest scores will catch the gap you rated Medium because the fix was expensive.

A compliance gap assessment is only as defensible as the standard it uses. Pick the one your auditor will pick, and when more than one applies, map them to a single control set so each gap is scored once. For most regulated enterprises the candidates are these.

Read the standard itself, not a summary of it. The Federal Reserve SR letter states that the guidance replaces each agency's earlier general guidance and applies to all banking organizations the Federal Reserve supervises. The guidance's own words set the test your program faces: due diligence "commensurate with the level of risk and complexity of the third-party relationship," ongoing monitoring "throughout the duration of a third-party relationship," and a sound methodology for designating which activities and third parties receive more comprehensive oversight. Those three phrases will reappear in your gap register as the criteria behind most of the findings.

Scope varies, so confirm it. The guidance applies to banking organizations, DORA to financial entities as defined in its Article 2, and the EBA guidelines to the institutions within the EBA's remit. A life sciences company or a defense prime with no banking charter still finds the Interagency Guidance useful as a description of what good looks like, and its auditors will say so. Where asset size, entity type or jurisdiction changes what binds you, settle it with counsel before the assessment starts, because changing the standard halfway through means rescoring every gap.

One more criterion belongs on the list if your program uses or plans to use AI in screening, pre-fill or adjudication. Auditors will ask how model outputs are reviewed, how rationale is recorded and who can override a decision. Certa's TPRM program AI readiness resource lays out the questions to answer before that conversation happens in fieldwork.

Before you test a single control, write down what the TPRM program actually consists of. Not the org chart version. The real one, with the spreadsheets, the shadow questionnaire in SharePoint, the monitoring feed nobody reads and the 400 vendors who were onboarded through an acquisition and never tiered.

Your inventory has two halves. The first is the third parties: every active relationship with business owner, inherent risk tier, the activity it supports and whether that activity is critical. The guidance leaves the definition of critical activities to each banking organization but names the characteristics: activities that could cause significant risk if the third party fails, that have significant customer impact, or that significantly affect financial condition or operations. DORA asks for the same distinction in its register of information, which must separate ICT services supporting critical or important functions from those that do not. If your inventory cannot answer "which of these are critical" in one query, that is your first gap.

Half two is the program itself. For each lifecycle stage, record the control, the system it runs in, the owner, the trigger and the evidence it leaves behind. A third party risk management program built over ten years rarely has one answer per row. Expect to find three intake paths, two tiering models and a monitoring process that differs by region.

• Third-party count by tier, by criticality and by business unit, with the number that have no tier at all
• Subcontractors and fourth parties recorded for critical relationships, which the guidance lists as appropriate to the risk presented
• Systems of record for intake, due diligence, contracts, monitoring and issues, and whether they reconcile to each other
• Control owners by lifecycle stage, with the date each procedure was last approved
• Open findings from prior audits and exams, with status and evidence of closure
• Reporting that reaches the board or its risk committee, with frequency and the last date sent

Count the systems too, because that number is itself a finding. One web-infrastructure leader that moved its program onto Certa consolidated from 6 systems to 1, bringing 8 to 10 teams onto one platform. Whatever the tool, an auditor who has to reconcile six exports to see one vendor's full picture will write that down, and so should you.

This is the week that decides whether the assessment is worth anything. Testing means pulling a sample of real relationships and following each one through the lifecycle, checking what the control produced against what the standard requires. Reading the procedure and ticking "present" is a document review, and your auditor will not stop there either.

Sample by tier. Pull every critical relationship, a random ten percent of high-risk ones and a handful of low-risk vendors to confirm the light path stays light. For each sampled relationship, test the stages below. The structure follows the guidance's lifecycle, and Certa's TPRM framework components post walks through what each stage should contain in a well-built third party vendor risk management program.

Record the result of each test as one of three outcomes: the control operated as the standard requires, it operated but below the standard, or it did not operate. Attach the evidence reference to every result. A gap with no evidence reference is an opinion, and opinions get argued down in the remediation meeting.

A list of forty gaps with no ranking will be remediated in the order people find convenient. Score each one on two axes and let the product of the two set the order.

Severity asks how much harm the gap allows: what could go wrong with a critical third party if this control stays as it is. Audit exposure asks how likely the gap is to become a finding: whether the standard names the control explicitly, whether the auditor tested it last cycle, whether a prior finding already covers it. The matrix below is the scoring core of a gap assessment template you can reuse every cycle.

Two rules keep the scores honest. Severity is set by the control operator's domain reviewer and challenged by the independent reviewer, never by the owner who will have to fix it. Audit exposure is set from the standard's text and the prior reports, not from a feeling about what the examiner cares about this year. A repeat finding is automatically a 4 on exposure. Regulators treat an open repeat finding as evidence that management's response was not prompt or thorough, which is the language the guidance uses for what it expects.

Where the gap is about capability rather than a single control, score it against a maturity scale instead. A program that still screens by hand will not close a "continuous monitoring" gap with a procedure update. Certa's TPRM maturity model for AI gives a four-stage scale you can borrow for those rows, so the register shows the stage you are at and the stage the fix requires.

The gap assessment report has one job: to let a reader who was not in the room see every gap with score, owner and date on one page, and find the evidence behind any row in under a minute. Write it as a register with a short cover note, not as a twenty-page narrative. Auditors read registers. Boards read cover notes.

A cover note carries five things: the standard used and why, the sample tested, the count of gaps by priority band, the three gaps the committee has to decide on, and the independent reviewer's sign-off. Everything else lives in the register. A sample of the register, with illustrative rows, looks like this.

Your remediation plan is the same register with three more columns: the fix, the milestone dates and the evidence that will prove closure. Be specific about closure evidence at the time you write the plan. "Policy updated" closes nothing. "Semiannual monitoring events logged for every Tier 2 vendor in the two cycles after the change" closes G-02. Written this way, the report doubles as a third party risk management program template for the next cycle, because the standard, the controls and the evidence expectations are already mapped.

Where the fix is the audit trail itself, say what the trail must contain. Certa's platform captures every screen, adjudication and disposition with documented rationale, citations and timestamps, immutable and exportable on demand, and its By Exception model records the auto-dispositions alongside the rows that surfaced for review, so the reviewer sees the whole population and not just the exceptions. That is the shape of evidence an examiner can test: who decided, on what, when, and why.

A gap assessment that happens once, in a panic, before one audit, will be repeated in a panic before the next. This last step turns it into a third party risk management audit program: a standing cycle with an owner, a calendar and a control library, so the next assessment starts from the last register instead of from a blank workbook.

1. Keep the control library. Every control you tested, with its standard reference, test procedure and evidence expectation, becomes a row in a library maintained by the TPRM owner. New regulation maps to new rows, not a new assessment.
2. Set the cadence by tier and by standard. Critical relationships and any control with an open finding get tested every cycle. Lower tiers rotate. DORA's annual reporting on the register of information and the board's periodic reporting under the Interagency Guidance set two fixed dates for the calendar already.
3. Track remediation to closure evidence, not to status. A finding closes when the closure evidence named in the plan exists and the independent reviewer has seen it.
4. Agree the standard with internal audit for the year ahead, so their Third-Party Topical Requirement work and your self-assessment use the same control set and the same sample logic.
5. Report the trend. Count of gaps by band at each cycle, time to closure, repeat findings. A board that sees the count fall and the repeats disappear funds the program. One that sees a fresh crisis every year does not.

Transparency with the auditor is part of the program, not a concession. Sharing the register, the control library and the evidence index before fieldwork shortens the audit and moves the conversation from "what do you have" to "what are you fixing." Certa's audit transparency steps cover how to set that up without exposing the program to every passing question.