Publish date
November 11, 2026
{x} minute read

Eight Cyber Controls Under the New IIA Requirement: What Security Teams Need to Know

Written by
Reviewed by
Table of contents

You've assessed the vendor, reviewed their security questionnaire, and documented the risks. But can you show internal audit how you made those decisions, how you validate vendor controls, and what happens when you find gaps?

From September 15, 2026, the Institute of Internal Auditors' (IIA) new Third-Party Topical Requirement gives internal auditors a more prescriptive baseline for assessing third-party governance, risk management, and controls during applicable assurance engagements. 

For security teams, that means greater scrutiny of the processes behind vendor risk decisions and the evidence you use to demonstrate they’re working.

We’ve grouped the requirements’ cyber-relevant expectations into eight controls. For each one, you’ll find the control objective, a sample control statement, how auditors might evaluate it, what a finding looks like, and the evidence to retain.

What the IIA requirement changes for TPRM teams

The IIA Third-Party Topical Requirement binds internal audit, not your vendor program. But your team owns most of the controls under test, so every gap becomes a finding with your name on it.

For cybersecurity teams who own many of the controls under review, the requirement means greater accountability for demonstrating how you identify, assess, and monitor vendors, and for proving those controls work.

What this guide leaves out

The requirement spans the full third-party lifecycle and 11 risk categories, from financial to geopolitical. Business cases, contract signatures, payment controls, and service-level penalties belong with procurement and legal. The eight controls below are where cyber risk lives, and where auditors will ask you for evidence.

The eight cyber controls your auditors will scrutinize

Each control below reads as it would in your control library, followed by how auditors will evaluate it and the finding you’ll receive if it fails.

1. The third-party inventory is complete and current

Maps to: IIA Third-Party Controls D, NIST CSF 2.0 GV.SC-04, ISO 27001:2022 A.5.19‍

  • Control objective: Every third party with access to company systems or data is known, owned, and in scope for risk management.
  • Control statement: The TPRM team maintains a single third-party inventory with a named business owner for every vendor. Every new vendor enters through intake before contract signature. The team reconciles the inventory against accounts payable, procurement, and SSO records, and resolves any gaps within 30 days.
  • How an auditor might evaluate it: 
    • Pull a sample of vendors paid in the last 12 months and confirm each one appears in the inventory (completeness). 
    • Pull a sample from the inventory and confirm each relationship is active and has an owner (accuracy). 
    • Inspect the latest reconciliation for a date and a sign-off.
  • What the finding looks like: “The third-party inventory is incomplete. Nine of 40 vendors sampled from accounts payable were not recorded, including two with access to customer data.”
  • Evidence to retain: Your inventory export, add-and-remove procedure, dated reconciliations, and the discrepancy log.
  • How UpGuard supports it: UpGuard Vendor Risk keeps your inventory in one place. Add vendors by domain or in bulk via CSV, then organize them with tiers, labels, custom attributes, and portfolios. On paid plans, you can store vendors you don’t actively monitor, so lower-risk relationships still stay on the list. The Vendor Onboarding Portal also routes new requests to security before anyone signs.
A woman using a laptop to visit UpGuard Vendor Risk's product tour

2. Third parties are tiered by risk, including fourth parties

Maps to: IIA Third-Party Risk Management B and C, NIST CSF 2.0 GV.SC-04 and GV.SC-07, ISO 27001:2022 A.5.19 and A.5.21

  • Control objective: Every vendor carries a risk tier that reflects its inherent risk, and that tier sets the depth of scrutiny it receives.
  • Control statement: The TPRM team tiers every vendor against documented criteria, such as data access, operational criticality, financial materiality, and planned subcontracting. The business owner completes an intake questionnaire to establish inherent risk, and the analyst records residual risk once the assessment closes. The team reviews tiers annually and whenever the scope of a relationship changes. The team also identifies and ranks the fourth parties that support critical vendors.
  • How an auditor might evaluate it:
    • Inspect the tiering methodology for defined criteria and an approval date.
    • Re-perform tiering for a sample of vendors and compare the result with the recorded tier (consistency).
    • Confirm each sampled critical vendor had a tier review in the last 12 months.
    • Request the list of fourth parties supporting critical vendors and the basis for their ranking.
  • What the finding looks like: “Tiering criteria are inconsistently applied. Six of 25 vendors sampled carried a lower tier than the documented criteria support, and no one had assessed fourth-party dependencies for any critical vendor.”
  • Evidence to retain: Your tiering methodology, completed intake questionnaires, tier change history, and your fourth-party dependency register.
  • How UpGuard supports it: Vendor Risk can auto-assign tiers and labels from the Vendor Relationship Questionnaire. Tiers then set assessment depth, and Vendor Risk records each tier change. For downstream risk, the concentration risk view shows which fourth parties appear most often across your vendors.

3. Security due diligence is complete before contract signature

Maps to: IIA Third-Party Controls A, NIST CSF 2.0 GV.SC-06, ISO 27001:2022 A.5.19

  • Control objective: No vendor reaches contract signature until security has assessed it at the depth its tier requires.
  • Control statement: Security completes a tier-appropriate assessment before procurement issues a contract. For critical and high-risk vendors, the assessment covers the vendor’s cybersecurity controls and independent assurance reports, such as SOC 2 Type II reports. Any vendor that proceeds before the assessment closes needs a documented exception approved by the CISO.
  • How an auditor might evaluate it: 
    • Pull a sample of contracts signed in the period and compare each signature date with the assessment completion date. 
    • Confirm the assessment depth matches the vendor’s tier. 
    • Inspect exception approvals for any vendor contracted before its assessment closed. 
    • Trace each sampled assessment back to the intake request that triggered it.
  • What the finding looks like: “Security due diligence was completed after contract execution for seven of 30 new vendors sampled. No exception approval was on file for any of them.”
  • Evidence to retain: Intake requests, dated assessments, contract signature dates, and exception approvals.
  • How UpGuard supports it: The Onboarding Portal gives business stakeholders a single intake flow that captures what security needs to set a vendor’s tier and assessment depth, and keeps it in one centralized, secure record. The AI-powered Security Profile pre-fills 49% of NIST CSF 2.0 checks and 46% of ISO 27001:2022 checks for the 100 most monitored vendors. Across UpGuard customers, onboarding requests close a median of five days after questionnaire submission, so due diligence keeps pace with the business, and stakeholders have less reason to work around security.

4. Information vendors provide is verified

Maps to: IIA Third-Party Controls F, NIST CSF 2.0 GV.SC-07, ISO 27001:2022 A.5.22

  • Control objective: Risk decisions rest on vendor claims that someone has checked against independent evidence.
  • Control statement: Analysts validate questionnaire responses from critical vendors against supporting evidence, such as SOC 2 reports or external scan results. For each SOC 2 report, the analyst reviews the scope, audit period, noted exceptions, and complementary user entity controls. Each control conclusion records the evidence relied on and the reviewer who signed off on it.
  • How an auditor might evaluate it: 
    • Select a sample of assessed vendors and trace control conclusions back to supporting evidence. 
    • Check that each SOC 2 review addresses exceptions and covers a current audit period. 
    • Look for vendor claims that conflicted with evidence and confirm the analyst followed up. 
    • Confirm a reviewer sign-off sits with each conclusion.
  • What the finding looks like: “Vendor self-attestations were accepted without validation. For five of 20 critical vendors, the assessment relied on questionnaire answers alone, and two SOC 2 reports on file covered periods ending more than 12 months earlier.”
  • Evidence to retain: Assessments with evidence citations, SOC 2 review notes, follow-up correspondence on conflicting answers, and reviewer sign-offs.
  • How UpGuard supports it: Upload a SOC 2 report or virtually any other security document, and the Security Profile maps it to control frameworks such as NIST CSF 2.0 and ISO 27001:2022 in minutes. AI flags contradictions between documents, a cross-check that’s slow to do manually, and surfaces the risks the evidence reveals. It also shows which checks no evidence covers. Citations show the reasoning behind each result, and reviewers can override it or adjust the evidence in scope.

5. Monitoring results update vendor risk between assessments

Maps to: IIA Third-Party Controls F and Risk Management B, NIST CSF 2.0 GV.SC-07 and DE.CM-06, ISO 27001:2022 A.5.22

  • Control objective: Material changes in a vendor’s security posture reach the TPRM team quickly and change the vendor’s risk rating when they should.
  • Control statement: The TPRM team continuously monitors critical and high-risk vendors for posture changes and reported security incidents. Analysts triage alerts above a defined severity threshold within five business days, and any material change triggers a reassessment or tier review. The team also re-evaluates a prioritized vendor’s tier when its contract changes or comes up for renewal.
  • How an auditor might evaluate it: 
    • Inspect monitoring coverage to confirm every critical vendor is in scope. 
    • Pull a sample of alerts and check that analysts triaged each one within the defined timeframe.
    • Trace at least one material alert through to a reassessment or tier change. 
    • Check that vendors coming up for renewal received a tier review first.
  • What the finding looks like: “Monitoring results are disconnected from the risk assessment process. Of 14 high-severity alerts raised during the period, none triggered a reassessment, and three critical vendors sat outside monitoring scope.”
  • Evidence to retain: A monitoring scope list, an alert log with triage dates, reassessment records linked to alerts, and pre-renewal tier reviews.

6. Vendor incidents and open issues are escalated to closure

Maps to: IIA Third-Party Risk Management C and D, IIA Third-Party Controls G, NIST CSF 2.0 GV.SC-08, ISO 27001:2022 A.5.24 and A.5.27

  • Control objective: Vendor incidents and open findings reach resolution or formal risk acceptance on a defined timeline.
  • Control statement: Analysts log vendor incidents and assign a severity rating that sets the escalation path and response deadline. High-severity incidents get a post-incident review with root cause analysis. Every remediation request carries an owner and a due date, and overdue items escalate to the CISO after 30 days. Accepted risks above tolerance need a documented justification and approval at a level set by severity, and each one expires for review after a set period.
  • How an auditor might evaluate it: 
    • Pull a sample of vendor incidents and check severity ratings and escalation timing against the procedure.
    • Confirm high-severity incidents have a post-incident review with a documented root cause.
    • Inspect remediation requests past their due date for evidence of escalation.
    • Review accepted risks above tolerance for an approver with the right authority and a current expiration date.
  • What the finding looks like: “Escalation of vendor issues is undocumented. Of 37 open remediation requests, 11 were more than 90 days overdue with no escalation record, and four accepted risks had no approver or expiration date.”
  • Evidence to retain: An incident log with severity ratings, post-incident review reports, a remediation tracker with escalation history, and the risk acceptance register.
  • How UpGuard supports it: You can turn any finding in Vendor Risk straight into a remediation request, with automated reminders. For scanning findings, on-demand rescans confirm the fix without waiting on the vendor. Risk waivers record the justification and approval behind each accepted risk, and they can carry an expiration date while staying tied to the original finding. Post-incident reviews and root cause analysis stay with your incident response process.

7. Offboarding revokes access and recovers data

Maps to: IIA Third-Party Controls I, NIST CSF 2.0 GV.SC-10, ISO 27001:2022 A.5.11, A.5.18, A.5.19, and A.8.10

  • Control objective: When a relationship ends, the vendor and any downstream subcontractors lose all access to your systems, data, or facilities, and return or destroy your data or assets.
  • Control statement: The business owner starts an offboarding checklist at least 30 days before the contract ends, or immediately upon termination for cause. IT revokes the vendor’s accounts and credentials, including API keys. The vendor provides written confirmation of data return or destruction, covering any downstream subcontractors that hold company data. The TPRM team marks the vendor inactive once the checklist is complete.
  • How an auditor might evaluate it: 
    • Pull a sample of vendors offboarded in the period and check for a completed checklist.
    • Compare offboarding dates with access logs to confirm IT revoked the credentials.
    • Inspect written confirmation of data return or destruction.
    • Confirm the inventory shows each offboarded vendor as inactive.
  • What the finding looks like: “Vendor offboarding is inconsistently performed. Three of 12 terminated vendors retained active accounts more than 60 days after contract end, and none of the 12 files held confirmation of data destruction.”
  • Evidence to retain: Offboarding checklists, access revocation records, data destruction certificates, and inventory status changes.
  • How UpGuard supports it: Access revocation happens in your identity and IT systems. If a vendor completed a Vendor Relationship Questionnaire at onboarding, you already have the relationship details the business recorded to help plan what to revoke and recover. While monitored, its assessment and remediation history sits alongside it for the exit.

8. The board receives timely reporting on prioritized vendors

Maps to: IIA Third-Party Governance D, NIST CSF 2.0 GV.OV-03 and GV.SC-09, ISO 27001:2022 clauses 9.1 and 9.3

  • Control objective: The board and senior management see where vendor risk sits and how it’s moving, with remediation status for the vendors that matter most.
  • Control statement: The TPRM team reports quarterly to senior management and at least twice a year to the board or its risk committee. Reports cover prioritized vendors’ risk ratings and trends, open high-severity findings and their remediation status, accepted risks above tolerance, and any vendor breaches of laws or regulations. The team draws report data from the system of record and reconciles it before distribution.
  • How an auditor might evaluate it: 
    • Inspect board and committee minutes for third-party risk reporting at the stated frequency.
    • Trace figures in a sample report back to the system of record.
    • Confirm reports include remediation status for prioritized vendors.
    • Check that material vendor incidents reached the board within the timeframe the protocol requires.
  • What the finding looks like: “Board reporting on third-party risk is incomplete. The risk committee received one third-party update during the year, and its figures could not be reconciled to source data.”
  • Evidence to retain: Board and committee submissions (dated and version-controlled), minute extracts and board actions, report source data, and the reporting protocol.
  • How UpGuard supports it: Vendor Risk has over 14 built-in reports, including a prebuilt board summary that you can run on demand or on a schedule. Trend data, such as 12 months of average vendor ratings and your most- and least-improved vendors, shows the board where your program is reducing risk over time.

Give internal audit what it needs without the extra work

The IIA requirement gives internal audit a fixed checklist for your vendor program, and every gap they find lands with the control owners. Spreadsheets and inboxes can hold the work. Proving it happened takes a record auditors can follow.

UpGuard Vendor Risk supports the cyber side of the requirement: inventory, tiering, verified evidence, continuous monitoring, remediation, and board reporting, all in one record. When internal audit asks, you’ll have the evidence ready. Take a Vendor Risk tour to see how it supports meeting your internal control requirements.

A man wearing glasses and headphones visiting the Upguard Vendor Risk product tour

Related posts

Learn more about the latest issues in cybersecurity.