Key Takeaways

• AI risk in regulated industries requires governance and controls that protect confidentiality, integrity, and availability of AI systems and the underlying infrastructure.

• AI systems need clear ownership, review based on risk, secure limits on data and access, human oversight for important actions, and ongoing monitoring.

• Agentic AI needs tighter safeguards because it may access enterprise data, use business systems, and take action with increasing autonomy.

Introduction

AI is moving from experimentation into the work that regulated organizations rely on every day. For example, healthcare organizations use AI systems to support documentation, communications, coding, and operations. Financial services firms apply it to fraud detection, identity verification, customer service, and internal work. Business services firms are embedding it in client delivery, research, analysis, and knowledge work.

When AI systems handle sensitive information, influence business decisions, or connect to enterprise applications, they create new cybersecurity risks and new challenges for protecting information. In simple terms, the risk increases when AI has access to sensitive data, can shape decisions, or connect to tools used to run the business. Agentic AI means AI that can do more than answer a question. It can retrieve data, use software tools, and start actions across systems with increasing autonomy, sometimes without a person approving each step.

For leaders in regulated industries, the goal is not to stop adoption. It is to understand the risk, decide what level is acceptable, and apply the right safeguards. AI governance is the way an organization decides where AI can be used, who is responsible for it, and what safeguards are required. A practical governance program should answer three basic questions: Is sensitive information protected? Can people trust the output? Will the system be available when it is needed?

AI Changes the Risk Profile

Existing privacy, cybersecurity, and oversight obligations still apply when an organization adopts AI. It does not replace these responsibilities. It changes how they need to be applied. In practice, AI can introduce new ways for sensitive information to be exposed, business information to be changed, or critical operations to be disrupted. The systems that support AI, such as identity tools, data platforms, and connected applications, also need to be governed and secured.

Confidentiality is about keeping sensitive information from being seen or used in the wrong way. It is at risk whenever sensitive information enters prompts, uploaded documents, retrieval systems, or logs. A connected system may retrieve more information than a task requires, and data may be retained in ways teams don't fully understand. Governance should make clear what data is allowed, is restricted, and prohibited, who can access it, and how use will be monitored.

Integrity is about making sure information and outputs are accurate, complete, and trustworthy. It is at risk when an AI system produces inaccurate, incomplete, manipulated, or misleading output. For example, an AI tool might rely on bad source material, misunderstand a prompt, or be manipulated by an attacker. The risk is greater if the system can update records, create communications, or change a workflow.

Availability is about keeping systems and operations working when people need them. AI systems depend on infrastructure, identity services, data sources, integrations, and applications. A cyberattack, outage, or misconfiguration can quickly become an operational problem. For higher-impact uses, organizations need continuity plans, escalation procedures, and practical ways to keep working safely when AI systems are unavailable.

What Governance Must Do

AI governance turns these decisions into consistent business practices. It starts with a simple inventory, or list, of AI systems and use cases. Organizations need to know where AI is being used, what data it touches, what decisions or actions it influences, and who is accountable for each use.

Risk tiering means grouping AI uses by how much impact they could have. An application used for graphic design is not equivalent to an AI system that processes protected health information, produces customer communications, or supports a financial decision. Higher-impact use cases should require documented approval, security and privacy review, defined human oversight, testing before deployment, ongoing monitoring, and reassessment when the system or workflow changes.

Accountability should be explicit. Each AI use should have a named business owner who is responsible for why the system is used and what outcome it is expected to support. Security, privacy, risk, legal, and compliance teams should define the limits for acceptable use. Employees need clear guidance on what they can use AI for, when they should escalate a concern, and what to do when an AI system produces unexpected results. Governance succeeds when it supports informed adoption rather than merely adding policy documents.

Cybersecurity Focus by Industry

Healthcare: AI governance and security must protect sensitive health information while preserving workflows that support care. Controls should limit exposure of protected health information, require review of AI-generated documentation, coding, patient messaging, and other outputs that may affect a record or care journey, and make sure operations can continue safely if an AI-enabled workflow or connected application is disrupted.

Financial services: Organizations must protect customer and transaction information while managing fraud and operational risk. Controls should prevent inappropriate exposure of account, identity, and transaction data, address impersonation, synthetic identity, manipulated inputs, and misleading AI-generated communications, and plan for disruption to fraud review, customer support, identity verification, and other time-sensitive activities.

Business services: Organizations must protect client trust and confidential work product. Controls should prevent client information, intellectual property, and sensitive personal information from entering unapproved AI systems, require review of AI-generated research, analysis, client materials, and changes to business records, and avoid relying on AI for critical client-delivery processes without a tested alternative.

Managing Agentic AI

Agentic AI needs more deliberate governance because it can interact with data and systems, not just generate content. Organizations must define what information an agent can retrieve, what applications it can access, and what actions it can take. They also need to decide which actions require a person’s approval, who can override or stop the agent, and whether the organization can review the records and determine what happened after an incident.

Least-privilege access is essential. This means an agent should receive only the data and permissions it needs to complete a defined task. IBM’s Cost of a Data Breach Report 2026 makes this abundantly clear. The report indicates that 92% of the organizations that experienced an AI-related breach lacked proper AI access controls!

Actions that could significantly affect customers, records, operations, or transactions should require approval before they happen. The organization should log all important inputs, actions, and outcomes. Organizations also need a tested way to disable or isolate an agent when its behavior is unsafe or unexpected.

Bring Confidence to Your AI Adoption

Strong AI risk management combines governance and security throughout the AI lifecycle, from early planning to day-to-day use. Organizations should identify AI uses, classify their risk, define what data each AI system can use and who can access it, test controls before deployment, monitor for failures and misuse, and reassess systems when their purpose, data, permissions, or connected workflows change.

Putting these practices into operation can be difficult, especially when different teams use different methods to evaluate AI risk. A common risk and security assurance approach can help create consistency.

HITRUST AI Risk Management can support this discipline by helping organizations identify and manage risks across the AI lifecycle. It provides a structured way to connect AI use to accountability, safeguards, and risks to confidentiality, integrity, and availability. HITRUST AI Security Assessment and Certification can help AI system providers demonstrate that their security controls have been independently assessed, validated, and certified.

Together, these approaches support a clear objective for regulated organizations: use AI with the confidence that it is governed, secure, accountable, and resilient. That foundation allows leaders to adopt AI systems in ways that support innovation without compromising the information and operations that matter most.

Reach out today to learn how HITRUST can help your organization manage AI risk and strengthen AI security.

The Assurance Gap: Five Questions to Ask Before Relying on an Assurance Report

A new HITRUST paper examines how third-party risk management teams can determine whether an assurance artifact provides the evidence they need for a risk decision. 

Organizations rely on assurance reports, certifications, , and questionnaires to evaluate vendors and  understand risk. but they do not all provide the same type or level of assurance. 

The assurance gap appears when an artifact does not match the decision that needs to be made. An artifact  may carry a familiar label but cover the wrong service, omit material controls, exclude key service providers, or require extensive interpretation before a team can compare it with other artifacts. 

To examine how this gap can appear in practice, HITRUST analyzed 103 SOC 2 Type 2 reports from 37 audit firms. SOC 2 reports were selected as they are a commonly accepted artifact by TPRM teams, but can be highly variable in scope and quality. A carefully reviewed SOC 2 report can provide value but only when the reader has the expertise and time to review its content. The analysis shows why recipients must understand what each report supports, what it leaves open, and where they may need supplemental evidence.  

The paper organizes that review around five questions.

1. Is the scope of the assessment appropriate? 

Before relying on an artifact, report recipients must confirm that its scope matches the relationship under review, such as the correct legal entity, product, system, environment, data, geography, review period, and dependencies. A report may cover a parent company but not the product your organization uses. It may exclude key locations, environments, or service providers. It may also cover a period that no longer reflects the vendor’s current operations. 

SOC 2 allows management to define the system, establish the system boundaries, select the applicable Trust Services Criteria, and describe the controls. That flexibility allows organizations to tailor their reports, but it also means that two reports with the same label may cover very different services and risks.

2. Does the Report Address the Expected Risks and Threats?

An assurance report can support a risk decision only when it includes and validates the controls relevant to the report recipient.

SOC 2 uses five Trust Services Criteria categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Organizations must address the common criteria within the Security category, but they can choose whether to include the other four categories.

Only 4% of the reports in the paper’s sample included all five categories. Even when an organization selected all five, the criteria mapped to 67% of the attack methods within MITRE ATT&CK. Organizations can add controls that increase coverage, but SOC 2 does not require them to do so.

The analysis also examined whether the sampled reports specified controls for several common threat actions:

• 77% of the sampled SOC 2 reports included controls requiring MFA for remote access.

• 30% of the sampled SOC 2 reports included controls requiring MFA for privileged access.

• 7% of the sampled SOC 2 reports included dedicated phishing training or simulations, while 5% included a prescriptive email-filtering control.

• 0% of the sampled SOC 2 reports included an organizational control to maintain offline or immutable backups.

These percentages reflect which controls the reports specified. They do not establish whether organizations implemented controls that their reports omitted. However, when a report omits a relevant control, the recipient cannot use that report to confirm it. The recipient must then request supplemental evidence or use another assurance mechanism that includes and tests the control.

3. Who Prepared and Quality-Reviewed the Work? 

Report recipients should consider the practitioner’s qualifications, independence, experience, licensure, testing approach, peer-review status, and quality record. They should also understand how the assurance program identifies and addresses quality concerns. 

Individual CPA firms produce and issue SOC 2 reports. The AICPA requires those firms to implement Quality Management Standards, but it typically does not review the underlying assessment or the report before issuance. 

The AICPA primarily enforces those standards through peer review. Another CPA firm performs that review after the issuing firm releases its reports, generally once every three years. The issuing firm selects its peer reviewer, and the reviewer examines only a sample of completed assessments. 

This quality model does not make SOC 2 reports inherently unreliable. It does mean that a recipient should evaluate the audit firm, especially when the organization plans to place significant reliance on the report.

4. Which Service Providers does the Report Include, and Does it Assess Them? 

Many vendors rely on cloud platforms and other service providers to deliver critical functions. An assurance report may not include the controls those providers perform. 

SOC 2 offers two methods for addressing subservice organizations. Under the inclusive method, the report includes the relevant controls of the subservice organization. Under the carve-out method, the report excludes those controls and describes how the primary service organization monitors the provider. 

In the paper’s sample, 80.4% of organizations used at least one subservice organization. Every corresponding report used the carve-out method. As a result, those reports did not cover or test the key service providers as part of the examination. 

This finding does not show that the vendors failed to manage their service providers. It shows that report recipients may need to obtain and review separate assurance reports before they can evaluate the outsourced services.

5. Can the Team Compare Two Reports through Measurable Outcomes? 

Third-party risk management teams often need to compare results across many vendors. That comparison becomes difficult when reports use different scopes, control sets, testing approaches, and presentation methods. 

SOC 2 does not use a standardized numeric cybersecurity score across reports. A team can compare two SOC 2 reports, but it must review the details and apply considerable judgment. 

All 103 reports in the paper’s sample received a clean, or unqualified, opinion. However, 40% contained at least one exception that the recipient needed to review. Among the reports with exceptions, each contained an average of 3.6 exceptions. 

A clean opinion does not mean that every test produced no exceptions. It also does not mean that two vendors with clean opinions demonstrate the same security maturity. Recipients must review the tests, results, exceptions, management responses, and available remediation evidence before drawing a conclusion.

Start with the Decision. 

The right assurance mechanism depends on the services and data in scope, the expected threats, the level of independence required, and the amount of reliance the organization intends to place on the result.

A lower-risk vendor may warrant a lighter review. A critical processor of regulated data may require precise scope, explicit controls, independent validation, and ongoing monitoring. In some cases, a reusable report or certification may provide the necessary evidence. In others, the recipient may need targeted supplemental information.

Third-party risk management teams should start by defining the risk decision and the evidence needed to support it. They can then determine whether the available artifact provides sufficient evidence or leaves an assurance gap.

A familiar label may start the review. The evidence should determine the decision.

Read The Assurance Gap for the complete analysis.

Introduction

The threat landscape is moving faster than the traditional assurance approaches, processes, and tools most organizations use to measure vendor risk that are highly static in spite of the daily changes to the threatscape. For the enterprise leaders accountable for the cyber risk and resilience of their organization, that gap has become the central challenge.

The ground is shifting faster than the map

The security and risk leader’s job has always involved managing uncertainty. What has changed is the pace and scale. The CISO’s job, at its core, is to identify and manage risk. Organizations now depend on a growing web of cloud platforms, software providers, managed service partners, payment processors, artificial intelligence vendors, and more, which dramatically increases information risk and the overall attack surface. A disruption or breach at one provider can cascade through the ecosystem.

Mandiant found that the median time between opportunistic initial access by one group and access by a secondary group fell to 22 seconds, compared with roughly eight hours in previous years. When the distance between a minor alert and a major compromise is measured in seconds, a once-a-year view of the cyber risk from third parties cannot keep up.

Accountability for cyber risk and resilience

Whoever holds the leadership role, whether a CISO in a Fortune 500 enterprise or the Head of IT in a tech startup, carries responsibility for the cyber risk and resilience of the organization. The title matters less than the accountability, and that accountability extends beyond the organization’s own walls.

The World Economic Forum Global Cybersecurity Outlook 2026 report places supply chain disruption second among CISO’s leading risk concerns behind ransomware. It also states that 99 percent of highly resilient organizations have board involvement in cybersecurity. Resilience is increasingly understood as a leadership and governance responsibility, not strictly a technical function, and one that has more board visibility and demands.

Recent HITRUST leadership perspectives sharpen that governance point. Effective third-party risk management begins with clear ownership, decision rights, risk tolerances, and escalation paths across security, procurement, legal, compliance, enterprise risk, and business teams. Technology can support a well-designed process, but it cannot correct unclear accountability.

Senior management and boards also need reporting that explains exposure, not only program activity. Vendor counts, completed reviews, and open findings show that work occurred. They do not, by themselves, show total residual information risk, concentration risk, retained risk, transferred risk, or whether exposure is within tolerance.

The problem no longer stops at direct vendors

Third-party risk now extends to n-party risk, including the vendors of vendors and the providers those parties depend on. A weakness several relationship steps away can still become your breach or disruption. Leaders are no longer simply managing a list of vendors and suppliers. They are managing an interconnected system they do not fully control and cannot fully see.

A mature view must also look beyond data sensitivity. A provider may create a risk to the organization because it supports a critical business process, holds privileged access, enables revenue, is difficult to replace, or contributes to concentration risk. Leaders therefore need to understand not only whether a vendor could be compromised, but also the operational and financial impact if the vendor became unavailable or failed to perform. A great example is a HITRUST customer in the technology space that tiers their third-party risk based on the business’ strategic dependency of the party on their operations, not just the type and amount of sensitive data held or processed.

Avoiding the problem is no longer viable. Customers, regulators, and shareholders rarely distinguish between an organization and the vendor whose failure disrupted service or exposed data. The damage lands on both.

Assurance methods being relied on were built for a slower world

Most organizations rely on self-reported security questionnaires, unvalidated SOC 2 reports, certifications such as ISO 27001, and other point-in-time evidence to assess, measure, and manage third-party risk. Each can provide useful information. As explored in our The Missing Measure in Third-Party Information Risk, the problem is that these inputs do not, on their own, provide the consistent, decision-ready measure leaders need to understand residual exposure across a changing ecosystem.

The deeper issue is not a lack of evidence. Many teams already collect more evidence than they can efficiently use and analyze. The evidence is fragmented across questionnaires, certifications, audit reports, security ratings, contracts, insurance, and exception approvals. Those inputs differ in rigor, scope, independence, timing, relevance, and confidence. Without a common decision model, different reviewers can reach different conclusions from the same vendor file. And increased evidence doesn’t necessarily result in improved risk quantification or the ability to remediate it (accept, resolve or transfer).

• Questionnaires capture what a vendor says it does at a particular moment. They may vary widely in scope, wording, and interpretation. A questionnaire completed months ago may not reflect a new acquisition, system change, product launch, or emerging threat.
• A SOC 2 report adds independent examination, but its scope is defined for the individual service and reporting period. Reports can differ substantially in coverage and detail. They remain historical evidence rather than a live measure of current exposure, and they are not designed to create one consistent measure across thousands of vendors.
• ISO 27001 certification signals that an organization has established an information security management system. That is meaningful, but it does not by itself provide a consistently scored, threat-adaptive validation of every control relevant to a customer’s specific risk decision. Like other certifications, it is one input into assurance rather than the complete answer.

The result is an assurance and measurement gap

Traditional methods share three limitations when used alone. They are point-in-time, difficult to compare consistently at scale, and may rely heavily on statements or evidence selected for a defined scope. There’s also clear evidence of artifact fatigue or check-the-box only “compliance” efforts that do little to reduce third-party risks. A vendor can satisfy documentation requirements while still remaining fragile against a current threat.

This shift also makes concentration visible. One accepted exception may be manageable. Similar exceptions across many vendors, business units, technologies, or geographies can create a material pattern that is difficult to see when each relationship is reviewed in isolation.

AI makes the timing problem even more acute. Vendor capabilities can change after approval, new model and platform dependencies can be introduced, and assurance can lose relevance as attack techniques evolve. Point-in-time evidence must therefore be paired with ongoing oversight and assurance that remains aligned with current threats.

Trust therefore has a measurement problem. A credible approach must normalize evidence, account for assurance quality, estimate residual exposure, define decision thresholds, and provide portfolio visibility. The objective is not a simplistic vendor risk score. It is a disciplined way to move from “Did we collect the evidence?” to “What does the evidence mean, what exposure remains, and what decision should follow?”

What you need to do now

The leaders who act now will define trust at scale for their industry. Those who wait will spend the next breach explaining why they did not.

Map your concentration risk before someone else finds it for you. Identify the handful of vendors and nth-party providers whose failure would halt revenue or a critical process. The organizations pulling ahead already know their top exposures by name.

Move from point-in-time evidence to continuous assurance. A questionnaire or SOC 2 from last quarter cannot see today's threat. Every month you delay is another month of blind spots.

Report exposure, not activity. Stop leading with vendor counts and completed reviews. Start showing residual risk, concentration risk, and whether exposure sits inside tolerance. Leaders need to reframe the conversation now. The HITRUST TPRM customers that are evolving in this area are focusing on the monetary financial impact on the organization from third parties, whether the discussion is about the risk of a single vendor or the aggregate amount of third-party risk being carried by the org.

Fix accountability gaps before your next incident tests them. Confirm clear ownership, decision rights, and escalation paths across security, procurement, legal, and the business. Technology cannot save an unclear process, and there is no time to sort this out mid-breach.

Put third-party risk on the board agenda. With 99 percent of highly resilient organizations reporting board involvement, it’s critical that boards are aware of the risk associated with the org’s vendor ecosystem.

The final blog in the series

Look for Part 3, The Path Forward, the final blog in this series that introduces the need for continuous ecosystem trust.