Impact of the IIA’s Cybersecurity Topical Requirement on Third-Party Management

The IIA’s Cybersecurity Topical Requirement took effect on February 5, 2026. It sets the baseline internal auditors must follow when auditing how an organization governs, manages, and controls cybersecurity risk across the enterprise. 

But read it closely and you’ll find third-party management written right into it:

• Vendors are named as cybersecurity stakeholders. 
• Supply chain is named as part of cybersecurity risk management. 
• Organizations need a process to ensure vendor-based controls are in place and periodically evaluated. 

For procurement and third-party risk management teams, this means an internal audit focused on cybersecurity risk will most likely land on your desk. So in this article, I break down where the Cybersecurity Topical Requirement touches third-party management, where NIST CSF 2.0 fits into the picture, and what you can do to get your program ready.

What the Cybersecurity Topical Requirement Is

The Cybersecurity Topical Requirement was the first of the IIA’s Topical Requirements, a new mandatory part of its professional framework. Each one sets a minimum baseline for internal auditors when they evaluate specific areas of risk across the organization. I covered how the full series fits together in my first article on the Third-Party Topical Requirement. 

The Cybersecurity Topical Requirement is organized into 17 requirements across three components:

• Governance (4 requirements): cybersecurity strategy and board oversight, policies and procedures, roles and responsibilities, and stakeholder engagement.
• Risk management (6 requirements): how cyber threats are identified, assessed, owned, escalated, communicated, and responded to when an incident occurs.
• Control processes (7 requirements): the control processes themselves, from vendor-based controls and asset lifecycle management to network and endpoint security.

It’s mandatory for internal audit to follow these requirements for assurance engagements in three situations: when cybersecurity is the subject of an audit in the internal audit plan, when cyber risk is identified as significant during an audit of another area (like third-party management), or when someone requests a cybersecurity engagement outside the plan. Auditors must assess every one of the 17 requirements for applicability and document their rationale for any they exclude.

Where the Requirement Touches Third-Party Management

Six of the 17 requirements reach directly into third-party management, and they come together in five touchpoints. Some name vendors outright, and others land on your program through the work you already do. Here is what each one requires and what auditors may look for as evidence.

1. Vendors Are Cybersecurity Stakeholders

The governance component requires that relevant stakeholders are engaged to discuss and act on existing vulnerabilities and emerging threats, and it lists vendors alongside senior management, legal, compliance, and others. The user guide’s examples focus on strategic vendors and point to evidence like meeting minutes, reports, and emails.

This one is about the ongoing conversation between you and your vendors on threats and vulnerabilities. Working through due diligence findings and agreeing on remediation is a form of engagement, but the gap tends to be what happens between assessment cycles. When a major vulnerability is disclosed, auditors will look for evidence that you reached out to the vendors it affects, documented their responses, and followed through. That depends on knowing who owns security at each critical vendor, and on them knowing who to contact at yours.

2. Supply Chain Is Part of Cyber Risk Management

The risk management component expects cybersecurity risk to be managed across the organization, and supply chain is named as one of the areas it covers, so it applies to every organization. This one looks inward. The vendor risk ratings and assessment findings your program produces are part of the organization’s cyber risk picture, and auditors will look at how that information reaches the people managing cyber risk across the enterprise. The user guide points to a cross-functional cybersecurity team or an IT steering committee as examples of how organizations do this.

The risk management component also calls for a process to quickly escalate any cyber risk that reaches an unacceptable level. A critical vendor with serious security deficiencies is exactly that kind of risk, so the path from your team to the people who act on it needs to be defined and documented.

3. Vendor-Based Controls Are Part of Your Control Environment

The control processes component requires a process to ensure both internal controls and vendor-based controls are in place to protect the organization’s systems and data, with periodic evaluations of whether they work. The user guide gets specific here, pointing auditors to SOC report reviews before the relationship begins and throughout its term.

This is where your assessment work does its heaviest lifting. Auditors will want to see that your due diligence is aligned to your own control framework and minimum security controls, that you’ve evaluated each vendor’s controls against them, and that any residual risk sitting outside your risk appetite has been remediated.

4. Security Runs Through the Full Vendor Lifecycle

Another requirement in the same component calls for cybersecurity to be included in the lifecycle management of all IT assets, including vendor services, from selection through usage, maintenance, and decommissioning. That is your third-party lifecycle described in IT terms.

The ongoing evaluation in between falls under vendor-based controls, so the focus here is how vendors come in and how they go out. Security review belongs in selection before a contract is signed and in onboarding when access is granted, and it matters just as much in offboarding when the relationship ends. Offboarding is where we most often see programs fall short, with vendor access left open and no confirmation that data was returned or destroyed.

5. Incident Response Depends on Your Vendors

The risk management component requires an incident response and recovery process that covers detection, containment, recovery, and post-incident analysis, and it has to be tested periodically. Many incidents start at a third party, so your plan has to work when the problem sits outside your own walls. Here is what that looks like at each stage:

• Detection: You will often find out about a vendor incident from the vendor, so your contracts need clear notification terms covering how quickly they must tell you, what they must share, and who they contact. Knowing which vendors hold which data lets you size the impact quickly.
• Containment: You need to be able to cut off a compromised vendor’s access to your systems and data fast, and know who has the authority to make that call.
• Recovery: For critical vendors, know what the vendor commits to for restoring service and what your fallback is if they can’t.
• Post-incident analysis: Get the vendor’s root cause findings and use them in your next reassessment, your next contract renewal, or both.

The process also has to be tested, and the user guide points to tabletop exercises at least once a year. The simplest step is to make sure at least one scenario starts with a critical vendor and, where it makes sense, to bring that vendor into the exercise. Auditors may look for the results being reported to senior management and the follow-up actions tracked to completion.

Where NIST CSF 2.0 Fits

A question I’ve been asked by clients is how all of this relates to the NIST Cybersecurity Framework. It’s a great question, and one the Cybersecurity Topical Requirement has already considered. The IIA’s own user guide maps all 17 requirements to CSF 2.0, NIST 800-53, and COBIT 2019, and it expects auditors to reconcile any framework-based testing they already perform back to the requirement.

So if your organization has adopted CSF 2.0, much of the groundwork is already in place. The IIA’s application guidance notes that frameworks and regulations in areas like cybersecurity tend to be more detailed than the Topical Requirements, so organizations already working within them should not need significant additional effort to show alignment, as long as the linkage is documented and the coverage is checked for gaps. Internal audit can also rely on a NIST-based assessment another assurance provider has already performed, provided they document it and judge the evidence sufficient.

For third-party management, the part of the CSF that matters most is the Cybersecurity Supply Chain Risk Management category (GV.SC), which NIST moved under the new Govern function in version 2.0. It reads like a condensed version of the third-party lifecycle, covering supplier criticality, due diligence, contract requirements, ongoing monitoring, incident planning, and offboarding, and the IIA’s mapping ties several of the five touchpoints above directly to it. That gives practitioners working within CSF 2.0 a real head start on managing vendor cyber risk.

But cyber is one risk domain. The Third-Party Topical Requirement covers every type of third party and every risk that comes with them, including financial, operational, compliance, concentration, and reputational risk. A facilities contractor, a claims processor, or a distribution partner may carry little cyber exposure and still be a critical third party, and the CSF has little to say about how those relationships are governed, assessed, or monitored. 

How Third-Party Management Can Get Ready for Cyber-Related Internal Audits

Whether internal audit reaches your program through a cybersecurity audit or a third-party one, the preparation looks the same. Here are a few practical steps you can take:

• Look at your program the way an auditor will. Take the five touchpoints above and ask two questions of each: are there documented policies and procedures, and can you produce evidence they are operating as designed? Auditors assess both design and implementation.
• Define clear roles and responsibilities. Ownership of third-party cyber risk often gets fuzzy with so many stakeholders involved, from information security and IT to third-party management and the business owner. Make sure each role is clear, every party is executing its part, and someone is connecting the dots across them.
• Lock down your riskiest relationships first. Start with critical third parties that have access to your systems and sensitive data, and make sure the five touchpoints above are fully covered and documented for each of them. Internal audit takes a risk-based approach to deciding what it covers, and a program that does the same is easier to defend. When you can show your highest-risk relationships are locked down and the rest are on a documented plan, any gaps at the lower end read as a deliberate, risk-based choice.

Get Ready Before Your Next Audit

Our Internal Audit Readiness for Third-Party Management service is built for exactly this. We assess your third-party management program against all four Topical Requirements, then build a phased roadmap for closing the gaps, with a business case to take to leadership. Our three-step process includes:

• Assess: a gap assessment against all four requirements in 30 to 45 days.
• Plan: a phased roadmap and business case in another 30 to 45 days.
• Close: execution against your roadmap, at the pace that fits your organization.

You can know where you stand and what to fix first in as little as 60 days. Contact me at trogers@vendorcentric.com to talk through where your program is today.