Generative AI for compliance in financial services has become an industry priority. Bankers, lenders, and asset managers are increasingly moving AI tools from beta-tested projects towards being a part of everyday operations. Below, we outline how third-party risk, governance, and model risk management all fit together and where financial institutions need to expand their existing governance while adding new controls that respond to how generative AI is actually being used.

Key Regulatory Frameworks at a Glance

What Generative AI Compliance in Financial Services Requires Today

Generative AI is rarely limited to only one tool or project within a financial institution. It usually has multiple sources, ranging from customer service platforms and document review tools to underwriting support systems, vendor software, and more. Because of this, different AI tools may already fall under an existing rule or system, meaning teams should focus less on writing new rules specifically for generative AI. Instead, they should identify where pre-existing programs already apply and where they fall short.

Extending Third-Party Risk Management to AI Vendors

Often, generative AI comes through a vendor relationship instead of an internal tool. With that in mind, financial institutions should treat AI vendors as an extension of their third-party risk program. This means adding AI-specific questions to due diligence, like how the vendor trains its models, what happens to data submitted through the tool, or how the vendor deals with model updates or version changes that could alter the tool’s behavior unexpectedly.

Additionally, the language used in contracts is extremely important here. Data use rights, model training restrictions, reporting and audits, and notification of AI-derived incidents or changes should be specifically enumerated in the contract before an AI software goes live.

Applying Data Governance to AI Inputs and Outputs

A large determining factor of what generative AI compliance will involve for each financial institution is what data goes in and out of the model. This is part of data management and data governance, and it goes beyond knowing where files are stored. It involves ensuring that only data that must be processed by the model is given to it, especially regarding nonpublic personal customer information. By minimizing the data processed to only what’s necessary for a particular task, this cuts down on data leakage risks.

These obligations to data governance are not new. They draw a straight line from existing safeguards that many institutions already maintain under GLBA. This means that financial institutions already following guidelines like the Interagency Guidelines for banks or the FTC Safeguards Rule for lenders mostly just have to extend their controls and add AI-specific controls to deal with new risks like training data provenance and output leakage.

Where Generative AI Sits Outside Model Risk Management

In 2026, federal banking regulators issued a non-binding guidance that narrowed formal model risk management to only apply to traditional models and non-generative and non-agentic AI. However, this doesn’t mean that generative AI should go unregulated. Instead, it means that accountability for governing these generative and agentic models now rests with the broader risk management and governance practices of an institution instead of with only the model risk function.

This distinction is important for how a program is created. Many institutions build targeted controls instead of folding generative AI into model risk inventories and validation cycles designed for traditional models. However, some financial institutions prefer to extend their existing model risk programs instead.

Building Targeted Controls Where Gaps Remain

For the areas where generative AI sits outside of formal model risk scope, institutions are addressing those gaps with specific, purposeful controls instead of rebuilding governance programs from scratch. For example, use-case approval steps (intake and approval gates) confirm that a proposed application of generative AI is reviewed before deployment. Output review checkpoints catch mistakes or inappropriate content before a customer sees it. Escalation paths give staff members a clear way to flag unusual or unexpected AI behavior, even when no formal model validation process exists.

Practical Steps Compliance Teams Can Take Now

No matter how big or complex an institution’s AI footprint is, there are a few actions that compliance teams can take to start building a foundation for generative AI compliance:

• Construct an inventory of generative AI use cases across all business lines, including tools that are embedded in vendor or third-party software.
• Send AI vendors through already established third-party risk workflows and add AI-specific language and due diligence before formally contracting each vendor.
• Record what data goes in and out of AI tools and review them against data governance and GLBA obligations.
• Benchmark the current security posture against NIST AI RMF or ISO/IEC 42001, since these frameworks are increasingly being treated as a reference point for AI governance and compliance.

Generative AI for Compliance in Financial Services Moving Forward

Generative AI for compliance in financial services will continue to evolve as regulators refine guidance and institutions become more familiar with using these tools. The organizations adapting with the most ease are those handling governance as a continuation of programs they already run, while adding dedicated new controls where generative AI falls outside existing guidelines. Securisea helps regulated organizations strengthen that foundation through independent assessment and advisory support. 

Contact our team to discuss where your program stands today.

In March of 2025, the General Services Administration (GSA) announced that a major overhaul of the federal cloud authorization program, FedRAMP, was coming down the pike. In late June 2026, FedRAMP launched its Consolidation Rules for 2026, and on August 3, 2026, the new FedRAMP 20x certification type took effect with Class A opening that same day. On August 31st, Classes B and C formally opened as well. All three of these developments are now shaping how cloud service providers (CSPs) plan their certification strategies if they want to pursue work with the federal government.  

In part, the goals of these changes are to reduce timelines and barriers to authorization, and the new structure also allows the framework to be updated each year to keep pace with the rapid clip of modern technology. This piece walks through what changed and what organizations should prepare to demonstrate as they move forward.

Understanding the FedRAMP 20x Changes to Certification Classes

FedRAMP previously used labels such as Low, Moderate, and High, but under the new FedRAMP 20x changes, those have been replaced with lettered certification classes. The previous labels described a system's sensitivity. Class A, B, C, or D, however, shows how much assurance information a CSP commits to sharing with agency customers. 

Certification Classes Under CR26

Note: Certification classes apply to both Rev5 and 20x, but the evidence required to earn a given class differs between the two, and the highest class currently runs only through Rev5. Rev5 requires an independent assessor for every class, including A. The "not required" column applies specifically to the 20x certification type. 

One update from this change alone that may interest CSPs is the introduction of Class A, which gives smaller CSPs a faster path to entering the FedRAMP Marketplace. Under rule FRC-CLA-ASF, Class A requires proof of a completed assessment under an “approved alternative security framework” garnered in the last 12 months. 

One of these approved security frameworks is SOC 2. If your organization already has a current SOC 2 Type II report issued in the past 12 months, you won’t have to build an entire security program from scratch. That said, you will still have to meet roughly 25 additional mandatory FedRAMP-specific rules that are not covered by SOC 2.

Key Security Indicators Change What Counts as Evidence

One of the major changes under FedRAMP 20x is what counts as evidence. While Rev5 requires that providers submit a written plan describing how a control is implemented, and then have an assessor test that implementation and document the results in their report, FedRAMP 20x now places more of that onus on the CSP. It asks CSPs to pull data from their own systems and demonstrate that a security outcome holds up on a recurring schedule, not just once a year.

These new required proof points are referred to as Key Security Indicators (KSIs). FedRAMP defines 46 KSIs, 41 of which apply to Class B and all 46 to Class C. The indicators are sectioned off into families like:

• Identity and access management
• Cloud native architecture
• Monitoring, logging, and auditing
• Incident response
• Change management
• Recovery planning

Here’s an example of what this shift may look like in practice: let’s take the federal MFA control. Under Rev5, a provider would document how it meets that control in its system security plan by describing what safeguards it had in place. But under 20x, the matching KSI requires the provider to produce evidence, drawn from its production systems, that phishing-resistant MFA is actually enforced and functioning for user logins. These hard, measurable outcomes do not leave room for interpretation the same way a written description might, which also makes the assessment clearer.

Persistent Validation and Automation Expectations

Because FedRAMP 20x treats compliance as ongoing, there are several revalidation points that organizations must comply with. For example, servers, software, and other technical systems must be revalidated at least every 3 days for Class C. Policies and other non-technical requirements must be revalidated at least every 3 months, regardless of class.

The evidence to meet these points (at least the technical requirements) comes directly from the tools providers are already using, such as identity providers, cloud platform logs, and configuration management systems. For technical systems, the idea is to turn the data that they already have into a repeatable feed that they can map to the right KSI, enabling them to produce evidence on schedule. 

Policy and governance requirements are the exception. Those often require new, ongoing processes built from scratch, since there's no existing system that generates that evidence automatically.

FedRAMP's rules set a handful of clear expectations for providers to plan around:

• Every KSI at class C requires automated checks, with a minimum of two automated methods per KSI.
• The provider’s official record must address every applicable KSI, regardless of whether the underlying item is automated or manual.
• Evidence must exist in a summary readable by humans, as well as in a machine-readable format that the assessor’s tools can process.

Where Independent Assessment Comes In

Just as the FedRAMP framework changes under 20x, so does the assessor’s job. With Rev5, the assessor's job was to examine, interview, and test. They reviewed narratives and sampled supporting evidence, they validated scans, and they ran penetration tests. 

Now, under 20x, more of the assessor’s time goes to confirming that a provider’s automated evidence does, in fact, reflect what’s happening in production. This shift calls for a different combination of skills, including API testing and code review.

Additionally, providers can now ask their assessor for input on improving their security posture or evidence quality during an assessment. This is explicitly allowed by FedRAMP, provided it does not compromise the assessor's objectivity and integrity. To be clear, an assessor cannot design the controls; they can only give feedback. Organizations can use this to gather insightful feedback without running afoul of independence rules.

Key Transition Dates for FedRAMP 20x and Rev5

If your organization has already commenced a Rev5 assessment, you are not yet required to switch to 20x. FedRAMP still accepts new Rev5 applications until June 11, 2027. For now, both certification paths are valid. Still, organizations should bookmark these upcoming dates and use this time to deliberately plan how they will need to alter their current processes to meet these deadlines.

What Organizations Should Prepare to Demonstrate

Before deciding on a certification type, it may be helpful for organizations to consider these questions:

• Which certification class fits your agency customers? This depends on the level of assurance those agencies expect, not on how sensitive your data is.
• Where do you stand against the applicable KSIs today? An internal readiness review, scored as full, partial, or no coverage, for example, could be a useful starting point.
• What evidence sources do you already have? Review what your existing tools and systems already track and produce before assuming you need to add something new to your stack. 
• Can your current documentation support persistently validated evidence, or only a point-in-time snapshot? This indicates how much engineering work you may need to add.
• When does an independent assessor need to be involved? Once you know what class you need, look into when they require you to make this decision.

How Securisea Can Help

Securisea is a FedRAMP Recognized independent assessor (formerly known as a 3PAO) with direct experience assessing cloud service providers across the FedRAMP program. We help organizations map their current environment against the applicable Key Security Indicators, determine which certification class and type make sense for their agency customers, and serve as the independent assessor for FedRAMP 20x Certification Packages.

If your organization is weighing FedRAMP 20x against a Rev5 certification already in progress, our team can walk through the classes, the KSIs, and the assessment requirements that apply to your specific situation.

Learn more about our FedRAMP assessment services, or contact our team to discuss your certification strategy.

Oftentimes, the Complementary User Entity Controls in a SOC report get treated like boilerplate. They rarely get the attention they deserve, even though your control objectives depend on them just as much as they depend on the controls you run yourself. When those entries get copied forward year after year without review, they stop matching what your system actually assumes, and controls that nobody performs turn into gaps your report will never surface. Below, we explore why teams misread SOC Complementary User Entity Controls, what it costs when customers do not act, and how to write disclosures that work.

Complementary User Entity Controls are the controls a service organization assumes its customers will implement, necessary alongside the service organization's own controls to achieve the objectives of a SOC report.

What are SOC Complementary User Entity Controls?

A CUEC records a control your customer performs, by design. When management designs the system, it necessarily makes assumptions about what customers will handle, and SOC Complementary User Entity Controls are where those assumptions get written down.

The standards define the term twice, and the wording differs in a way that matters later. Under AT-C 320.08, a SOC 1 CUEC is a control that management assumes will be implemented by user entities (your customers) and that is necessary to achieve the control objectives stated in management's description of the service organization's system. Under the SOC 2 description criteria in DC section 200, a CUEC is one that is necessary, in combination with controls at your organization, to give reasonable assurance that your service commitments and system requirements are met.

SOC 1 anchors to control objectives, while SOC 2 anchors to service commitments and system requirements. Because of that, the two report types treat CUECs quite differently, which is where a good deal of the confusion begins.

Comparing CUECs, CSOCs, and User Entity Responsibilities

Most CUEC problems start as a labeling problem. Two neighboring concepts tend to get pulled into the same list, even though they answer to different rules. Complementary Subservice Organization Controls (CSOCs) point at your vendors instead of your customers, and how you report them depends on whether you use the carve-out or inclusive method. User entity responsibilities do point at your customers, but they serve a different purpose entirely and carry no CUEC disclosure requirement. Sorting the three correctly is the first discipline worth building, because a report that blurs them ends up telling customers considerably less than it appears to.

One test separates the first row from the third: if your objectives or criteria can still be met even when the customer performs the activity imperfectly, then what you have on your hands is a responsibility rather than a CUEC.

Why Organizations Misread Their CUEC Obligations

The most common error promotes an ordinary responsibility into a CUEC. The AICPA's own example draws the line clearly. Suppose a customer has to give you a complete and accurate list of authorized users, which sounds like a control and gets listed as one in plenty of reports. If that customer submits a list mistakenly including someone who left the company, your organization has still done exactly what it committed to do, because you provisioned access according to the list you received. Your criterion was satisfied, and the consequence landed with the customer instead.

That makes it a user entity responsibility. It still matters, and it belongs in your onboarding material, but because it is not necessary to achieve your objectives, it does not meet the definition of a CUEC.

Over-listing carries a second cost that gets far less attention. Every responsibility promoted into the CUEC list dilutes the disclosure, so a customer facing forty entries, most of them general security advice, has no practical way to tell which three actually determine whether your controls achieve their purpose. Vendor risk teams reviewing your report then have reason to skim the section, which defeats the purpose it was meant to serve.

What Happens When a Customer Never Implements the Control

A CUEC can be correctly identified, clearly written, properly disclosed, and still be incomplete. That’s because the control only comes into existence once the customer implements it, and nothing in your report makes that happen on its own.

When it does not happen, several things tend to follow:

• The customer carries a gap it has not recognized. Your system assumed a control that is not operating anywhere, and neither party is watching that space.
• The customer's own auditor raises it. During a financial statement audit, the user auditor examines whether relevant CUECs have been implemented at the customer, so gaps surface there, in front of your customer, attached to your report. Anyone reviewing a SOC report on the receiving end is looking for exactly this.
• Incidents trace back to the assumption. Post-incident reviews can land on a configuration the provider reasonably believed the customer had handled, which is a difficult conversation to have after the fact.

What makes all of this easy to overlook is an asymmetry in how the examination works. Because the service auditor does not test controls at user entities, a customer that never implements your CUECs produces no deviations in your report and no change to your opinion. Your report can therefore be perfectly clean while the control objective it describes goes unachieved in practice.

That distance between a technically accurate report and a genuinely working control environment is what makes CUECs worth real scrutiny, since a CUEC is ultimately worth only what customers actually implement.

SOC 1 Versus SOC 2: Why CUECs Are Common in One and Should Be Rare in the Other

The two report types treat CUECs differently, and the reason sits in their definitions. SOC 1 control objectives address a customer's internal control over financial reporting. Those objectives routinely depend on activities the customer performs, such as reviewing output reports, reconciling balances, or authorizing transactions before submission. CUECs are therefore expected in SOC 1, and a SOC 1 report carrying none at all would be unusual.

SOC 2 runs the other direction. Because your service commitments and system requirements are yours to set, the AICPA's guidance observes that a service organization can usually achieve them without depending on CUECs at all, since it limits those commitments to matters that are its own responsibility and that it can reasonably perform. Scoped that way, most SOC 2 criteria should be satisfied by your controls alone.

In practice, though, SOC 2 reports vary widely. Practitioners report seeing reports with zero CUECs alongside reports carrying more than seventy-five, and both extremes deserve a second look:

• A long list usually signals mislabeling, because general security advice and ordinary user responsibilities have been swept into the CUEC section.
• An empty list is not automatically correct either. If your system genuinely depends on customer-side controls, DC6 requires the disclosure, and staying silent does nothing to remove the dependency.

Rather than counting entries, ask whether each one is truly necessary to achieve a specific criterion, and whether you can name the criterion it supports.

One note on the standards, since the codification confuses people: a SOC 1 examination runs on AT-C 105 and AT-C 205 together with AT-C 320, and recent amendments including SSAE No. 23 leave the CUEC concept unchanged.

Who Owns CUECs, and What the Service Auditor Actually Does With Them

Management identifies CUECs, and the service auditor does not. That division is more than a formality, since confusion about it tends to create real problems once planning is underway.

• Management owns the disclosure. Your management team determines which customer-side controls the system design assumes, and CUECs are a required disclosure in the description of the system.
• They live in the description rather than the opinion. CUECs appear in neither the service auditor's report nor management's assertion. Published reports place them in different sections depending on how the report is organized, because the description criteria set no prescribed format for the description, so any section numbering you have seen is convention rather than requirement.
• The practitioner evaluates suitability of design. During planning, the service auditor works to understand which controls management assumes customers perform, reviews contracts and user guides, and evaluates whether those CUECs, combined with your own controls, are suitably designed to achieve the objectives or criteria.
• The practitioner does not test at your customers, so no fieldwork takes place inside your customers' environments.

Report type changes what the examination covers. A Type 1 report addresses fair presentation of the description and suitability of design at a single point in time, while a Type 2 report adds operating effectiveness over a period. In both cases the CUEC question remains a design question, asking whether these controls, taken together with yours, hold up. Operating effectiveness testing still covers your own controls rather than your customers'.

Settling all of this before fieldwork begins saves meaningful rework, because late changes to the description tend to be expensive ones.

Communicating CUECs So Your Customers Can Act on Them

By the time a CUEC reaches your report, the decisions it describes have usually already been made. A customer reading Section 3 is looking at implementation choices that were settled months earlier, which means the communication that matters has to happen much closer to where customers actually configure things.

Four places are usually the most significant:

• Contracts and service agreements. Customer obligations that your control design depends on belong in the terms themselves, rather than only in a report the customer may open once a year.
• Onboarding and implementation guides. This is the point where a CUEC turns into an action, and a control that appears in the report but never in onboarding is one most customers will never implement.
• Product defaults and guardrails. Often the strongest move is to remove the dependency altogether, because a control you can enforce in the platform stops being a CUEC at all.
• Renewal and account reviews. Recurring checkpoints catch drift, particularly after a customer reorganizes or turns over staff.

Under AU-C section 402, a customer's financial statement auditor must first determine whether the CUECs you identified are relevant to that customer. From there, the auditor obtains an understanding of whether the customer has designed and implemented them, and tests them, relying on operating effectiveness in a Type 2 report. Vague or recycled disclosures push cost onto that process, and the friction tends to return to you as questionnaires and follow-up calls.

Interpretation No. 1 of AU-C section 402, issued in December 2022, concluded that a SOC 2 report is unlikely to meet the intent of the AU-C 402 requirements. The reason is that a SOC 2 description may not cover all the services, processes, and controls relevant to a customer's internal control over financial reporting. A SOC 1 report is therefore preferred for that purpose, though the interpretation does allow that when a SOC 1 report is unavailable, a user auditor may still draw relevant information from other attestation reports.

How This Maps to the Cloud Shared Responsibility Model

Cloud-native teams meet this same idea constantly under a different name. Shared responsibility models divide security of the cloud from security in the cloud. The provider secures the underlying platform while the customer configures and secures whatever it builds there. This division shapes how SOC 2 works for SaaS companies in particular. AWS draws the connection to SOC reporting explicitly in its 2025 guide on SOC 2 compliance, which describes CUECs as controls customers cannot treat as optional.

The two ideas overlap without being interchangeable, since shared responsibility describes an operating model while a CUEC is a formal disclosure documenting your design assumptions for a specific criterion. Neither one transfers legal responsibility, and both parties keep their own controls.

How CUECs Get Written Badly

Most weak CUECs fail on one of four counts:

• Too vague to implement or test, which leaves the customer unsure what to do and their auditor unable to tell whether they did it.
• Copied forward, so last year's list carries into this year's report without anyone checking whether the system design still depends on those controls.
• Used to shift your own responsibilities, which happens whenever a CUEC reassigns something your platform actually controls, and experienced report readers tend to notice.
• General best practice dressed up as a CUEC, meaning sound advice that is not necessary to achieve any specific criterion and belongs somewhere else.

What usually separates a weak CUEC from a workable one is specificity:

Read each entry and ask which control objective or criterion would fail if the customer did nothing at all, because an entry without a clear answer to that question is not a CUEC.

Write CUECs Your Customers Can Act On

Getting SOC Complementary User Entity Controls right means scoping them to specific criteria, separating them from ordinary user entity responsibilities, and communicating them where customers configure things. A short, accurate list does more for your report than a long one nobody reads.

Securisea Attest, P.C. is a licensed CPA firm performing SOC 1, SOC 2, and SOC 3 examinations. We evaluate the CUECs your management team identifies against the objectives and criteria they support. Explore our SOC examination services or contact us.