.svg)
.svg){kind=icon}
What Is a SOC2 Exception, and What Does It Mean To My Business?
When undergoing a SOC 2 audit, many organizations aim for a clean report, but even the most prepared companies can encounter exceptions. A SOC 2 exception highlights areas where controls did not fully operate as intended, raising potential concerns for stakeholders. But what exactly does this mean for your business? In this post, we'll break down what a SOC 2 exception is, why it happens, and what steps you can take to address these findings to ensure your organization remains on track for compliance and security.
A SOC 2 exception doesn’t necessarily indicate a failure, but rather an area where controls didn’t function as expected during the audit period, possibly for an entirely legitimate reason. These exceptions can vary in severity, ranging from minor deviations to more significant issues that may require immediate attention. The key is understanding the nature of the exception and determining whether it poses a material risk to your organization’s security, availability, or data privacy. In many cases, exceptions are manageable and can be addressed with corrective actions, helping your organization strengthen its overall control environment.
Types of SOC 2 Exceptions
There are typically two types of SOC 2 exceptions: control deficiencies and deviations.
- Control deficiencies occur when the control was in place but didn’t operate effectively. For example, if an organization has a control for monitoring access logs but failed to review the logs during a certain period, that would be considered a control deficiency.
- Deviations happen when a control did not operate as documented. An example would be a policy stating that users must watch a security awareness training by a certain deadline, but a small number did not watch the video until a week after the deadline, perhaps because they went on vacation shortly before the final reminder was sent.
Understanding the type of exception helps your organization prioritize remediation efforts and prevent similar occurrences in the future.
Why Do SOC 2 Exceptions Happen?
SOC 2 exceptions can occur for several reasons, including human error, system malfunctions, or process misalignment. In some cases, exceptions may result from a temporary breakdown in communication between departments, leading to missed compliance steps. Other times, they stem from inadequate documentation or outdated policies that no longer reflect the current operations or risks the company faces.
It’s essential to perform a root cause analysis when exceptions arise to identify the underlying issues. This allows organizations to apply targeted corrective actions rather than short-term fixes.
The Impact of SOC 2 Exceptions
The impact of a SOC 2 exception depends on its severity and relevance to the scope of the audit. For example, a minor exception might not affect the overall audit opinion and could be seen as a learning opportunity. However, more significant exceptions could lead to a qualified opinion, which might cause concerns for clients, partners, or regulators.
A qualified opinion doesn’t necessarily mean your organization is not secure, but it may indicate weaknesses in certain areas that need attention. Clients and partners might request additional information to understand the risk posed by the exception and what steps are being taken to resolve it.
How to Address SOC 2 Exceptions
If your SOC 2 report identifies exceptions, the most important thing is to respond proactively. Here are steps you can take to manage and resolve exceptions effectively:
- Understand the exception: Work with your auditor to understand the specific nature of the exception. Is it a process failure, human error, or system issue?
- Perform a root cause analysis: Identifying the underlying conditions that enabled and/or caused the exception is important in order to identify likely corrections.
- Implement corrective actions: Develop a plan to remediate the exception. This could involve updating policies, improving employee training, or enhancing technical controls to ensure the issue doesn’t recur.
- Communicate with stakeholders: Transparency is key when exceptions are identified. Inform relevant internal and external stakeholders about the nature of the exception, your remediation plan, and the expected timeline for resolution.
- Monitor and document progress: Keep track of the remediation efforts and document each step. This not only helps with the current issue but also serves as a valuable record for future audits.
Preventing SOC 2 Exceptions
While exceptions can happen, there are proactive steps organizations can take to reduce the likelihood of encountering them in future audits:
- Regular internal audits: Conduct internal audits to catch potential issues before the SOC 2 audit. This allows you to address any gaps in controls proactively.
- Ongoing employee training: Ensure your staff is well-versed in the policies and procedures required for SOC 2 compliance. Regular training can help prevent human errors and process deviations.
- Keep policies up to date: As your organization grows or changes, your policies should evolve too. Regularly review and update your procedures to reflect your current operations and risks.
Final Thoughts
SOC 2 exceptions are a common part of the auditing process, but they don’t have to derail your compliance efforts. By understanding the nature of exceptions, implementing corrective actions, and continuously improving your controls, your organization can strengthen its security posture and maintain trust with clients and partners. Embracing these opportunities for improvement will not only help you pass future SOC 2 audits but also ensure you’re better equipped to handle the complex cybersecurity landscape.
About Securisea
Securisea provides audit support for organizations of all sizes, from startups to some of the world’s largest, most complex, and most security-minded technology companies. We are one of only a handful of audit firms in the world certified to provide CSA STAR, ISO27001 and 27701, SOC2, SOC1, PCI DSS, FedRAMP/StateRAMP 3PAO, HITRUST & HIPAA assessments all under one roof. Partnering with Securisea means you have access to experienced, senior security experts focused on delivering the solutions you need.
Latest posts
NIST Cybersecurity Framework vs. ISO 27001
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.
ISO 42001 Certification Requirements: What Organizations Should Expect
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.
AI Governance and Compliance: Beyond AI Policies
In its 2026 AI Impact Survey of 950 senior executives, Grant Thornton found that 78 percent lacked full confidence that their organization could pass what it called an independent AI governance audit within 90 days. The number points to a wider problem. AI adoption has outrun the governance meant to control it, and most organizations only find the gap when someone asks for evidence. This piece takes an assessor's view of AI governance and compliance. It walks through six governance decisions any organization deploying AI has to make, shows where each one commonly goes wrong, and explains what independent review expects to see.
Six Areas That Shape AI Governance and Compliance
The confusion tends to cluster in the same six places. Each one looks settled on paper and comes apart under review.
Someone Has To Answer for What the AI Does
The first question an assessor asks about any control is: Who owns it? For AI, the answer is too often a diagram instead of a person. When accountability is spread across a committee, a function, or "the team," no single individual can be held answerable once a model produces a harmful or non-compliant result.
Assessments look for something narrower and harder to fake. There should be a named person who answers for AI outcomes and who holds the authority and resources to act on that responsibility. ISO/IEC 42001, the AI management system standard, requires that roles, responsibilities, and authorities be defined, assigned, and communicated, so that accountability for AI outcomes is traceable to a decision-maker rather than diffused across a committee.
A named owner matters little, though, if the rules they own do not match how people are actually using AI.
Your Acceptable Use Policy Probably Does Not Match Reality
This is where most acceptable use policies fall. They are among the first documents an organization produces and among the least likely to reflect what is happening. The ISACA 2026 AI Pulse Poll, drawn from more than 3,400 digital trust professionals, captures this mismatch: 90 percent believe employees are using AI, yet only 38 percent have a formal, comprehensive policy governing that use, up from 28 percent a year earlier. The rest are relying on rules that are partial, silent, or unread.
What grows in that gap is “shadow AI”, meaning tools adopted without security review that can quietly carry sensitive data into systems no one has vetted. Many organizations cannot enforce limits on how AI tools are used or reliably shut one down when it misbehaves.
So when a review reaches acceptable use, the policy text is only the starting point. Reviewers look for evidence that the policy actually operates: monitoring for unsanctioned tools, a route for staff to get AI use approved, and records showing the organization responds when the rules are crossed.
Even organizations that take their policies seriously tend to make one further assumption, and it is usually wrong: they assume the compliance credentials they already hold extend to their AI.
SOC 2 and ISO 27001 Do Not Automatically Cover AI
A mature SOC 2 report or a current ISO 27001 certificate feels like broad coverage, so surely it reaches the AI systems, too, right? Wrong. It rarely does, and the reason why lies in what those instruments were built to do.
- SOC 2 rests on the AICPA Trust Services Criteria. Those criteria are deliberately technology-neutral and contain no AI-specific requirements. AI can be brought inside a SOC 2 examination, but only through how the system is scoped and how controls are designed, never automatically.
- ISO/IEC 27001:2022 governs an information security management system. It protects the confidentiality, integrity, and availability of information, and it does not address model behavior, fairness, bias, or explainability, because those concerns sit outside its subject matter.
An organization can therefore hold a clean SOC 2 report and a current ISO 27001 certificate while its AI systems stay ungoverned in every respect that those frameworks were never meant to address. ISO/IEC 42001:2023 exists to close that gap. Its Annex A adds 38 AI-specific controls across nine objectives, numbered A.2 to A.10, covering areas such as AI policy, impact assessment, the AI system life cycle, data for AI systems, and third-party relationships.
You Cannot Outsource Your AI Compliance Obligations to a Vendor
Most organizations deploy models and features supplied by someone else, which raises another question that many deployers get wrong: whose obligations are these?
The EU AI Act draws a firm line between the provider, who develops and places an AI system on the market, and the deployer, who uses it under their own authority. The two carry different duties. A deployer takes on provider obligations only in specific situations, such as putting its own name on a high-risk system, substantially modifying it, or repurposing it so that it becomes high-risk. Short of those triggers, a vendor's compliance does not settle the deployer's responsibilities.
The same holds for general-purpose AI. Provider obligations for general-purpose AI models sit in their own part of the Act and operate at the model level. They do not flow down to the organizations deploying those models. So when a vendor points to its own model-level compliance, it is describing its obligations rather than yours.
The review expects an AI inventory that captures third-party and embedded AI, along with evidence that vendor AI passes through a governed assessment rather than being accepted on a supplier's word. But make no mistake, under the EU AI Act and other forthcoming regulations and laws, the responsibility will still be on you, not the vendor, to be compliant in the use of their AI systems.
Regardless of if the AI was built in-house or purchased, the same test applies to the policy governing it.
Writing the Policy is Only One Piece of the Puzzle
In immature programs, the pattern repeats. The policy exists, it reads well, it has been approved, and then nothing downstream connects to it. No decisions cite it, no reviews test it, no records show it changing anything.
A policy is where governance starts. What proves governance is operational, and that is what the review goes looking for: risk assessments that were genuinely performed, decisions made and recorded, reviews held on schedule, exceptions raised and resolved. However well drafted, a document with no operating record behind it does not demonstrate that anything is being governed.
Even a program that operates well at approval will not stay that way on its own.
AI Systems Change, and Governance Has To Keep Up
AI systems change after they go live. Models get retrained, inputs shift, vendors update their services, and use cases expand. Governance fixed at the moment of approval decays as the system drifts from the conditions under which it was signed off on.
What review expects instead is sustained oversight: monitoring, scheduled review, a working escalation path, and change management that treats a material change to an AI system as a governance event rather than a silent update.
The ground outside the organization keeps moving too, which is another reason programs cannot stand still. The EU AI Act now runs on a revised timeline. Under the Digital Omnibus on AI, in force since 27 July 2026, the obligations for high-risk systems apply from 2 December 2027 for standalone systems listed in Annex III and from 2 August 2028 for AI embedded in products covered by Annex I. The bans on prohibited practices, in force since February 2025, and the obligations for general-purpose AI models, in force since 2 August 2025, were not deferred, and the transparency obligations still take effect on 2 August 2026. In the United States, the state-level picture keeps shifting as legislatures add, narrow, and repeal AI requirements. A program built for a single fixed moment will not hold.
Keeping pace also means being clear about what your credentials actually certify, because in a market this new, the instruments get blurred together.
What an ISO 42001 Certificate Does and Does Not Prove
An organization that thinks it holds one kind of assurance when it holds another is exposed in ways it cannot see.
An ISO 42001 certificate demonstrates that an organization operates a conforming AI management system. As of August 2026, it does not yet harmonize with the EU AI Act, but the harmonized standard is currently being developed, so organizations should expect it to be on the horizon.
Three distinctions do most of the work here:
- The NIST AI Risk Management Framework (NIST AI RMF) is voluntary. Its four functions, Govern, Map, Measure, and Manage, are a structure for managing AI risk, and there is no certification against it. An organization can align with it and say so, but no one issues a NIST AI RMF certificate.
- ISO/IEC 42001 certifies a management system, not an individual AI product. It certifies that an organization runs a conforming AI Management System (AIMS), which is a different thing from product-level compliance.
- An accredited AIMS audit has defined limits. Under ISO/IEC 42006:2025, accreditation to audit and certify against ISO 42001 qualifies a body for exactly that. It does not by itself make that body an algorithm auditor, a bias auditor, or a notified body performing EU AI Act conformity assessment. Those are separate activities requiring separate competencies and, for notified-body work, separate designation.
This is also why an assessment firm describes what an assessment or review tests rather than prescribing how an organization should build its program. Independent assessment or review is only worth something when that separation holds.
Evaluating Your AI Governance and Compliance
AI governance and compliance is an operating discipline, not a document exercise or a byproduct of certifications already held; independent review tests whether it operates. The organizations that struggle are rarely the ones with weak intentions or bad policies. They are the ones whose governance was written but never run, scoped for the systems they used to have rather than the AI they now depend on, and assumed to be covered by frameworks built for something else.
Seeing this from the assessor's side comes with an advantage, which is knowing which evidence holds up. Securisea's teams assess AI where it appears across PCI DSS, SOC 2, HITRUST, and GovRAMP engagements, and Securisea's wholly owned subsidiary, Securisea CB, LLC, is an ANAB-accredited certification body for ISO/IEC 27001. If you want to know where your AI governance program would stand under review, that is the conversation we are built for.
To learn more about our assessment practice, talk to an expert.
Why choose Securisea?
