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.

An organization setting out to structure its cybersecurity program is usually presented with a choice between the NIST Cybersecurity Framework vs ISO 27001. The pressure to choose tends to come from outside, when a board asks which one the program follows or a prospect's risk team wants evidence before signing.

That request for evidence is where the two part ways. CSF 2.0 is voluntary guidance describing cybersecurity outcomes, and NIST certifies no one against it. ISO/IEC 27001:2022 specifies requirements for an information security management system, audited and certified by a certification body. The comparison below covers how each one is structured, what each one can show, and where the two overlap.

NIST Cybersecurity Framework vs ISO 27001 at a glance

Both instruments help organizations manage security risk at an organizational level. The CSF is framed around cybersecurity risk, while ISO/IEC 27001 addresses information security. They diverge on publication model, structure, and assurance.

‍

Two differences carry most of the practical weight.

Different evidence. A CSF assessment measures current outcomes against a Target Profile and yields a gap analysis and a prioritized action plan. An ISO/IEC 27001 certification decision, based on an audit, results in a certificate issued by the certification body.

Different governance mechanics. CSF 2.0 added a dedicated Govern Function in 2024. ISO/IEC 27001 has placed leadership requirements in Clause 5 since its 2013 edition.

Simply put:

The NIST Cybersecurity Framework and ISO/IEC 27001 both support strong governance, but they are different kinds of instruments. NIST CSF is voluntary, outcome-based guidance with no NIST certification program, while ISO/IEC 27001 is a certifiable information security management system standard, with certification granted after an audit conducted by a certification body.

What the NIST Cybersecurity Framework 2.0 Actually Is

NIST published CSF 2.0 on February 26, 2024, its first major update since 2014. A minor update arrived in 2018, but 2.0 was the first to change the Core, adding Govern as a sixth Function. NIST also renamed the document from "Framework for Improving Critical Infrastructure Cybersecurity," reflecting an intended audience well beyond critical infrastructure.

Structure

CSF 2.0 organizes cybersecurity outcomes into six Functions: Govern, Identify, Protect, Detect, Respond, and Recover. Govern sits at the center and informs the other five. Those Functions divide into 22 Categories and 106 Subcategories. Version 1.1 had five Functions.

The Govern Function 

Govern is the sixth Function, added in CSF 2.0, and it speaks directly to senior leaders and boards. It addresses organizational context; risk management strategy; roles, responsibilities, and authorities; policy; oversight; and cybersecurity supply chain risk management. NIST ties Govern to enterprise risk management, treating cybersecurity risk as one of the risks an organization manages across the business. It holds 31 of the 106 Subcategories, though NIST states that the size of a Function does not imply its importance.

How Organizations Use It

The framework does not prescribe how an outcome should be achieved. The CSF has three components: the Core, Organizational Profiles, and Tiers. An organization builds a Current Profile and a Target Profile, then analyzes the gap so the actions that close it can be prioritized. Separate online resources support use of the CSF, including Implementation Examples, Informative References, Community Profiles, and Quick-Start Guides.

The Assurance Limit

NIST does not certify organizations against the CSF and has said it has no plans to develop a conformity assessment program. No single professional standard governs a CSF assessment, so third-party work usually produces an assessment report rather than a certificate. A CPA firm can go further, since an examination under the AICPA attestation standards can express a practitioner's opinion on subject matter mapped to the CSF. Private schemes such as HITRUST and the SCF Conformity Assessment Program also certify against CSF outcomes, but those are not NIST programs.

Adjacent NIST Publications

People sometimes mix these up with the CSF. SP 800-53 is NIST's catalog of security and privacy controls. SP 800-171 protects Controlled Unclassified Information (CUI) in nonfederal systems, and its Revision 2 is the baseline the Department of Defense currently assesses under CMMC Level 2 for contractors handling CUI. The NIST IR 8286 series explains how to fold cybersecurity risk management into enterprise risk management. The NIST Privacy Framework is a companion tool that shares the CSF's structure. None of these carries a NIST certification.

What ISO/IEC 27001:2022 Actually Is

ISO/IEC 27001 specifies requirements for an information security management system (ISMS), including how an organization assesses and treats its information security risks. It sits in the ISO/IEC 27000 series and is the only standard in that series an organization can be certified against.

Two Normative Sections

Clauses 4 through 10 hold the requirements an ISMS must meet, covering context, leadership, planning, support, operation, performance evaluation, and improvement. Excluding any of them is not allowed when claiming conformity. Annex A, also normative, holds 93 reference controls in four themes: organizational, people, physical, and technological. ISO/IEC 27002:2022 gives implementation guidance for each control, and ISO/IEC 27005:2022 offers optional guidance for the risk work ISO/IEC 27001 requires but does not prescribe.

The Statement of Applicability

 Risk assessment drives which controls an organization determines it needs. Clause 6.1.3 requires the Statement of Applicability to record four things: the necessary controls, the justification for including each one, whether each is implemented, and the justification for excluding any Annex A control. Those controls can come from Annex A or any other source. Because control decisions follow each organization's scope, context, and risk assessment, two certified organizations in the same industry can end up with different applicable controls.

Where Leadership Sits

Clause 5 sets three requirements on top management: demonstrating leadership and commitment, establishing an information security policy, and ensuring that responsibilities and authorities for information security roles are assigned and communicated. Governance runs wider than Clause 5, reaching into Clauses 4, 6, and 9 and the Annex A organizational controls.

The Certification Cycle

A certification body conducts a Stage 1 audit reviewing documentation and readiness, then a Stage 2 audit evaluating implementation and effectiveness. A reviewer separate from the audit team makes the certification decision. The certificate is valid for a three-year cycle, with surveillance audits in the first and second years and a recertification audit before it expires. Where the certification body is accredited, the certificate gains international recognition through the multilateral arrangement accreditation bodies operate.

Amendment 1:2024

Published in February 2024, ISO/IEC 27001:2022/Amd 1:2024 added climate change to Clause 4. Clause 4.1 now requires the organization to determine whether climate change is a relevant issue, and Clause 4.2 adds a non-normative note that interested parties can have climate-related requirements. It added no Annex A controls and took effect immediately, with no transition period.

A Note on Comparing at the Control Level

Comparing the CSF to ISO/IEC 27001 as a whole compares an outcome framework to a management system standard. For a control-level comparison, NIST SP 800-53 and ISO/IEC 27002 sit at a similar level of detail.

What the CSF and ISO/IEC 27001 Each Demonstrate

The two sections above describe how each one is built. What each one can show an outside party is a separate question.

A Third-Party Certificate

An ISO/IEC 27001 certificate records a certification body's decision that an information security management system, within a defined scope, conforms to the standard. The document shows effective and expiry dates, a unique identifier, the edition audited, and the scope. That scope deserves a close read, because a narrow one can leave out the systems a prospective customer cares about most.

An Assessment Result

A CSF assessment, whether a self-assessment or performed by a third party, measures current outcomes against a Target Profile and yields a gap analysis and a prioritized action plan. That output supports planning, executive reporting, and prioritizing investment. Since NIST runs no conformity assessment program for the CSF, the deliverable is a report rather than a certificate.

What Procurement Asks For

In the United States, third-party risk teams and security questionnaires usually ask for a SOC 2 report. Buyers in the EU and other international markets more often name ISO/IEC 27001 in their contractual requirements, and regulations such as DORA and NIS2 are driving that demand. Others accept a range: a SOC 2 report, an ISO/IEC 27001 certificate, or a completed questionnaire. Which one matters depends on who the customers are, and SOC 2 and ISO/IEC 27001 differ in more than geography.

Neighboring Instruments, Precisely Named

Precision helps when a contract or questionnaire is on the table. SOC 1 and SOC 2 engagements are examinations under the AICPA attestation standards, and they result in attestation, delivered as a report containing the service auditor's opinion. A PCI DSS assessment by a Qualified Security Assessor produces a Report on Compliance, summarized in an Attestation of Compliance. Calling an attestation a certification misstates what was actually performed.

How the CSF and ISO/IEC 27001 Map to Each Other

Organizations that adopt the CSF and also hold ISO/IEC 27001 certification usually want to know where the two line up. NIST hosts a starting point. Its National Online Informative References (OLIR) Program catalogs mappings submitted by outside parties, including entries that map ISO/IEC 27001:2022 to CSF 2.0, and the catalog is reachable from NIST's CSF 2.0 Informative References page.

What the Catalog Does and Does Not Show

NIST runs limited conformance testing of each submission against NIST IR 8278A Revision 1 and posts it for a 30-day public comment period. It does not test outside mappings for correctness, and a listing does not mean NIST endorses it. ISO has no role in the program. The entries also run in one direction, from ISO/IEC 27001:2022 to CSF 2.0, and they show that a relationship exists without saying how close it is. Using a mapping creates no conformity with either instrument.

Where the Two Overlap

CSF Govern outcomes correspond broadly to the ISO/IEC 27001 clauses on context, leadership, planning, and management review, plus the organizational controls in Annex A. CSF Protect outcomes correspond broadly to the people, physical, and technological controls, and CSF Detect outcomes to the technological controls. The correspondence is rarely one-to-one, since the CSF states outcomes while Annex A lists controls that ISO/IEC 27002 then describes in detail.

How Organizations Use Both

Some organize and report on their program using the CSF, since NIST designed the Functions to help communicate cybersecurity risk to executives and boards, and separately hold ISO/IEC 27001 certification where a customer wants independent evidence.

Two More Factors Organizations Weigh

These shape the decision alongside the points above. This is general information, not a recommendation for any one organization, and how each factor resolves depends on facts specific to that organization.

Existing management system commitments. An organization that already operates a management system certified to an ISO or ISO/IEC standard, such as ISO 9001, is likely to recognize the shared clause structure, the internal audit requirement in Clause 9.2, and the management review requirement in Clause 9.3.

Sector expectations. Some sectors and jurisdictions reference one instrument more heavily in guidance and supply chain requirements. Confirm the specific expectation against the primary source.

Comparing the CSF and ISO/IEC 27001 With the Right Question in Mind

Comparing the NIST cybersecurity framework vs ISO 27001 gets easier once the two stop being treated as competitors and the focus shifts to what each was built to do. The CSF organizes cybersecurity outcomes and supports prioritization across a program. ISO/IEC 27001 sets requirements for an information security management system that a certification body audits, with the certification decision made separately. An organization can use both, and some do, applying each for the job it was designed to do.

Securisea is a PCI SSC Qualified Security Assessor Company, a licensed CPA firm whose attest subsidiary performs SOC 1 and SOC 2 examinations, a HITRUST Authorized External Assessor, and an A2LA-accredited 3PAO recognized by FedRAMP and registered with GovRAMP. Across those engagements, the same questions recur: which controls overlap between frameworks, which evidence supports more than one engagement, and which requirements have no counterpart elsewhere.

To discuss an assessment against a framework your organization has selected, contact Securisea.

Securisea provides cybersecurity consulting and assessment services. ISO/IEC 27001 certification is issued by Securisea CB, LLC, a separate ANAB-accredited certification body that operates independently to preserve impartiality under ISO/IEC 17021-1. This article provides general education and does not advise which framework any organization should adopt.

‍

Enterprise buyers increasingly ask organizations that provide or deploy AI systems to document how those systems are governed, and to back that documentation with independent certification. Regulators are imposing documentation requirements of their own, though most stop short of requiring third-party certification. ISO/IEC 42001:2023, developed by ISO/IEC JTC 1/SC 42 and published on 18 December 2023, is the first certifiable international standard for an AI management system. 

Most explanations of ISO 42001 certification requirements enumerate the clauses and stop there. Below, we cover what the standard requires across AI governance, documented information, AI risk and impact assessment, and continual improvement, then explain how conformity of the management system to those requirements is determined during a certification audit.

ISO 42001 Certification Requirements at a Glance

Clauses 4 through 10 carry the normative management-system requirements that a certification audit tests. Annex A supplies a reference control set that an organization selects from, and the controls declared applicable in the Statement of Applicability are audited alongside the clauses. Certification applies to the AI management system rather than to any individual model or product, although the certification scope statement names the specific AI systems and functions covered.

ISO 42001 Certification Requirements, Clause by Clause

ISO/IEC 42001 uses the harmonized structure, formerly Annex SL, that also underpins ISO/IEC 27001:2022, so teams already running an ISO/IEC 27001 information security management system will recognize how Clauses 4 through 10 are organized. What changes is the subject matter, plus two AI-specific requirements with no ISO/IEC 27001 counterpart: determining the organization's AI role (Clause 4.1) and the AI system impact assessment (Clauses 6.1.4 and 8.4).

Clause 4, Context of the organization 

The organization determines the internal and external issues relevant to its purpose and to achieving the intended results of its AI management system, along with the relevant interested parties and their needs and expectations. It then determines the scope of the system, which it establishes, implements, maintains, and continually improves. 

Clause 4.1 also requires it to determine its role or roles with respect to AI systems, such as AI provider, AI producer, or AI customer as defined in ISO/IEC 22989, because role affects which requirements and controls apply. 

Scope determination is where this clause bites: AI is easy to overlook when it sits embedded in purchased software, arrives inside a broader vendor service, or is adopted by individual teams outside formal procurement, and a third-party AI system raises a scope question before any control question. 

Evidence: The scope available as documented information, evidence that interested parties and their requirements were determined, and a stated determination of AI roles.

Clause 5, Leadership

Top management demonstrates leadership and commitment to the AI management system, establishes an AI policy appropriate to the purpose of the organization, and ensures responsibilities and authorities for relevant roles are assigned and communicated. The policy must be available as documented information, communicated internally, and available to interested parties as appropriate. 

Evidence: An approved AI policy maintained as controlled documented information, assigned responsibilities and authorities, and objective evidence of top management engagement such as resourcing decisions and management review inputs.

Clause 6, Planning

The organization determines the risks and opportunities affecting the AI management system, taking account of the Clause 4.1 issues and Clause 4.2 requirements, and defines its processes for AI risk assessment, AI risk treatment, and AI system impact assessment. It sets AI objectives that are measurable where practicable and monitored in all cases, and plans any changes to the system in a controlled manner. 

Evidence: Documented AI risk assessment and risk treatment processes with AI risk criteria set in advance, a justified Statement of Applicability, documented impact assessments, and monitored AI objectives.

Clause 7, Support

The organization provides the resources, competence, awareness, communication, and documented information the AI management system needs. Clause 7.2 requires people whose work affects AI performance to be competent through education, training, or experience, and Clause 7.5 governs how documented information is created, updated, and controlled. 

Evidence: Documented information available as evidence of competence for work affecting AI performance, and controlled documented information showing review and approval.

Clause 8, Operation

Clause 8 performs what Clause 6 defines: operational planning and control under 8.1, AI risk assessment under 8.2, AI risk treatment under 8.3, and AI system impact assessment under 8.4, covered separately below. Under 8.1, the organization implements and controls those processes along with the Annex A controls that its risk treatment selected. 

Evidence: Documented information that the processes were carried out as planned, retained AI risk assessment results, the AI risk treatment plan with documented approval from designated management and acceptance of residual AI risks, and evidence that assessments ran at planned intervals and on significant change.

Clause 9, Performance Evaluation

The organization monitors, measures, analyzes, and evaluates the performance and effectiveness of the AI management system and conducts internal audits at planned intervals, and top management reviews the system at planned intervals. 

Evidence: Documented monitoring and measurement results, internal audit results, the audit program, and documented information recording management review decisions.

Clause 10, Improvement

The organization continually improves the suitability, adequacy, and effectiveness of the AI management system. When a nonconformity occurs, it reacts and corrects, evaluates whether action is needed to eliminate the cause so the nonconformity does not recur, implements any such action, and reviews its effectiveness. 

Evidence: Documented information on the nature of each nonconformity, the correction and corrective action taken, and the review of that action's effectiveness.

Annex A Controls and the Statement of Applicability

Annex A provides 38 reference controls under nine control objectives numbered A.2 through A.10, compared with 93 controls across four themes in ISO/IEC 27001:2022. The nine objectives address policies related to AI, internal organization, resources for AI systems, assessing impacts of AI systems, the AI system life cycle, data for AI systems, information for interested parties of AI systems, use of AI systems, and third-party and customer relationships.

Implementing all 38 is not required. The organization determines all controls necessary to implement its chosen AI risk treatment options, compares them against Annex A to verify that no necessary controls have been omitted, and may design controls of its own. Those controls, each with a justification for inclusion or exclusion, are recorded in the Statement of Applicability.

Exclusions draw attention during a certification audit. A control excluded from the Statement of Applicability that the organization's own risk treatment identified as necessary is an internal inconsistency, and an unjustified exclusion is typically raised as a nonconformity against Clause 6.1.3.

Why AI System Impact Assessment Has No ISO/IEC 27001 Equivalent

Clause 6.1.4 requires the organization to define a process for assessing the potential consequences of its AI systems for individuals, groups of individuals, and societies, including consequences of foreseeable misuse. Clause 8.4 requires performing that assessment and retaining the results. This is a separate obligation from the AI risk assessment, and completing one does not satisfy the other.

One looks inward, the other looks outward. Risk assessment examines consequences to the organization and its objectives. Impact assessment examines consequences to the people and communities an AI system affects, whether or not those consequences create any corresponding risk to the organization. Clause 6.1.4 then requires the impact results to feed back into the risk assessment.

Teams extending an ISO/IEC 27001 program to ISO/IEC 42001 often find no existing artifact satisfies Clause 6.1.4. Information security risk assessment centers on the organization's own information and objectives, so it does not answer who outside the organization could be harmed. Annex A control objective A.5, "Assessing impacts of AI systems," addresses the same subject on the control side.

Impact assessments generally address:

• The individuals, groups, and societies an AI system affects
• The nature and severity of potential impacts
• The deployment, intended use, and foreseeable misuse under which impacts arise
• How the findings fed the risk assessment

An impact assessment that left no trace in the risk assessment raises the question of whether it informed any decision. This is a focus area for auditors.

How Accredited Certification Evaluates Conformity

The governing rules. Accredited certification bodies operate under ISO/IEC 17021-1, the standard for bodies providing audit and certification of management systems, with ISO/IEC 42006:2025, published 7 July 2025, adding AI-specific competence and audit time requirements. Certification attests conformity of the management system to the requirements of ISO/IEC 42001, and does not substitute the auditor's judgment for the organization's decisions about how to govern its AI systems.

Stage 1 examines documentation and readiness. The audit team reviews the documented AI management system, confirms the scope is coherent, and evaluates whether the Clause 9 internal audit and management review are being planned and performed. Its findings set what Stage 2 examines in depth.

Stage 2 examines implementation, including effectiveness. The team samples records, interviews personnel beyond the compliance function, and looks for evidence that documented processes have operated as described. Effectiveness has a bounded meaning here: whether the system achieves its intended results.

Surveillance and recertification follow. A surveillance audit occurs at least once a year, and a recertification audit before the three-year certificate expires.

How ISO 42001 Relates to the EU AI Act, NIST AI RMF, and ISO 27001

The EU AI Act

ISO/IEC 42001 does not confer a presumption of conformity with the EU AI Act. That legal effect belongs only to standards and common specifications whose references appear in the Official Journal of the European Union, and ISO/IEC 42001 has none. Its adoption as a European Norm, EN ISO/IEC 42001:2026, does not change that. EN 18286:2026, the European standard written for the Act's quality management requirement, has been published but is not yet cited either, and its correspondence with ISO/IEC 42001 is one reason the two get confused. Certification can support AI Act preparation without carrying legal effect.

NIST AI RMF

A crosswalk hosted by NIST maps the AI RMF functions (GOVERN, MAP, MEASURE, and MANAGE) to ISO/IEC 42001 clauses, controls, and guidance. The AI RMF is voluntary and self-assessed, while ISO/IEC 42001 is certified by an accredited auditor. Prior AI RMF work is a strong starting point, but it does not by itself produce the Statement of Applicability, internal audit, and management review a certification audit requires.

ISO/IEC 27001

ISO/IEC 27001:2022 shares the same harmonized clause structure, so documented information, competence, internal audit, and management review transfer over with some rework. Divergence sits in Clauses 4, 6, and 8 and in the ISO/IEC 42001 Annex A controls. The broader question of how AI is reshaping cybersecurity and security compliance sits behind much of that divergence.

ISO 42001 Certification Requirements and Timing

ISO 42001 certification requirements are evaluated on whether processes are documented, implemented, operating, and supported by records. Documentation can be assembled fairly quickly. Records cannot: Clauses 9 and 10 call for monitoring results, internal audits, management review decisions, and corrective action evidence that accumulate only as the system runs. Operating history therefore sets the earliest point at which a certification audit can reach a conclusion, which makes the date an organization starts running its AI management system more consequential than the size of its documentation effort.

Questions about ISO/IEC 42001 can be directed to Securisea.

This article is educational. It describes the certification process as set out in ISO/IEC 17021-1:2015 rather than the practices of any specific certification body, and it is neither management system consultancy nor legal advice. Securisea, Inc.'s accredited certification services are provided through its subsidiary Securisea CB, LLC at securisea-cb.com. Securisea, Inc. does not provide AI management system implementation, gap analysis, or internal audit services to organizations certified by Securisea CB, LLC.