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.

Almost no service organization operates alone. Cloud hosting, managed detection, and payment processing sit inside the systems your customers rely on, and each of those dependencies has to be accounted for somewhere in your SOC report.

Two methods handle that: a carve-out method and an inclusive method. The carve-out method excludes a subservice organization's controls from both the system description and the examination scope. The inclusive method brings them inside both. Both of these methods exist in SOC 1 and SOC 2 examinations and work the same in each, but what your report needs to disclose differs between the two.

Deciding between the SOC 2 carve-out method vs inclusive method determines how much of your service delivery chain the service auditor's opinion actually covers. Service organization management makes that decision, and the considerations behind it deserve careful review well before scoping begins. The sections below walk through the factors management weighs, what each method requires operationally, and how the choice shows up in the finished report.

SOC 2 Carve-Out Method vs Inclusive Method at a Glance

Note: Throughout, "description" means management's description of the service organization's system.

Is the Vendor Actually a Subservice Organization?

A subservice organization performs part of the service you deliver to your user entities. In a SOC 1 examination, that work is likely to be relevant to those user entities' internal control over financial reporting. In a SOC 2 examination, its controls are necessary to achieve your service commitments and system requirements. 

The test has two parts. Does the vendor's work fall inside the system you describe to your customers? And are its controls necessary, working alongside your own, to achieve your control objectives or your service commitments and system requirements? If your controls alone are enough, you have a vendor to assess for risk rather than a subservice organization. That determination belongs to management, which defines the system.

In our experience, most vendors do not meet that test. A janitorial service and the tool that runs your own back-office expense reports sit nowhere near the system your customers depend on. An infrastructure host, a managed security operations provider, and a payment processor usually sit right in the middle of it. A vendor can also matter for some trust services criteria and not others.

Misclassification in either direction can have serious consequences. Naming an ordinary vendor as a subservice organization clutters your description with disclosures and monitoring obligations your customers do not need, and it expands testing and cost if you use the inclusive method. Missing a real one produces a description that does not fairly present the system, which can lead to a modified opinion and mislead the people relying on your report.

What Changes When a Subservice Organization Is Carved Out

Under the carve-out method, your description tells readers what the subservice organization does and the types of controls you expect it to run. Its own specific controls stay outside the description and outside the examination.

Complementary subservice organization controls (CSOCs) are the required disclosure that makes that work. CSOCs are the controls you assumed the subservice organization would implement when you designed your system, and that are necessary alongside your own to provide reasonable assurance that your control objectives in a SOC 1, or your service commitments and system requirements in a SOC 2, are achieved. When you carve out, the description has to identify the types of controls you assume it has implemented and that your own controls rely on. That disclosure shows readers which controls you rely on the subservice organization to perform rather than performing yourself.

CSOCs and CUECs are easy to conflate and are not interchangeable. CSOCs sit at the subservice organization. CUECs sit at your user entity, usually your customer. Both have to be disclosed, and the objectives your report covers depend on both actually operating, though neither is tested by your service auditor. A description that mixes them up misstates who is responsible for what.

Carving out the controls does not carve out your responsibility for the relationship. You still need controls over how you select, monitor, and respond to the providers you depend on, and your description has to present those controls. In a SOC 2 examination, this maps most directly to trust services criterion CC9.2, which addresses vendor and business partner risk. In a SOC 1, the duty comes from AT-C section 320. Expect the service auditor to look at vendor due diligence, your review of the subservice organization's SOC report at a frequency you set based on risk, and how you follow up when that report shows exceptions.

What the Inclusive Method Requires

Management chooses the inclusive method, but that choice only exists when the prerequisites can be met. If they cannot, the decision is made for you.

Using it requires all of the following:

• The subservice organization agrees, before the engagement begins, to be included in the service auditor's examination procedures.
• It provides its own written assertion, which appears just after yours in the SOC report.
• It provides written representations to the service auditor in a signed representation letter.
• It gives the service auditor access to the records, documentation, and personnel needed for testing.
• The service auditor is independent of the subservice organization, not only of you.

No written assertion means no inclusive method. If the subservice organization will not provide one, carve-out is usually the remaining path, and finding that out late in planning costs time you may not have.

There is a coordination cost even when everyone agrees. Two organizations have to settle on how the subservice organization's controls are described, align testing windows, deliver evidence on a shared schedule, and handle deficiencies inside the same period covered by the report. Much of that work sits with management on both sides, though the service auditor coordinates the testing.

In our experience, the inclusive method is uncommon. Large infrastructure providers run their own SOC programs and generally will not participate in a customer's examination, which in practice makes the method unavailable for the dependencies most service organizations care about. AICPA guidance notes that the inclusive method is generally feasible only where the two organizations are related or where their contract provides for it, which is why it tends to appear between affiliated entities or a parent and subsidiary.

SOC 2 Carve-Out Method vs Inclusive Method: Effects on the Report Itself

Choosing the carve-out or inclusive method changes both the work the service auditor performs and the content of the SOC report your customers receive.

• Description and opinion. Under the carve-out method, management's system description identifies the services the subservice organization performs, and the service auditor's report states that those controls were not part of the examination. The opinion covers your system description, the design of your controls, and, in a type 2, whether they operated effectively over the period. Under the inclusive method, the subservice organization's description, relevant controls, testing, and opinion coverage all extend to that organization, too.
• Assertions. The carve-out method needs one written assertion, yours. The inclusive method adds a separate written assertion from each included subservice organization's management. All appear in the report.
• Type 1 and type 2. Either method works with either report type, though the AICPA guides illustrate the inclusive method with type 2 reports. In a type 2 inclusive examination, the subservice organization's controls are tested for operating effectiveness throughout the specified period, and those results appear in the description of tests of controls and results alongside yours, with each organization's controls clearly identified.
• You can mix the two methods in one report. If you rely on several subservice organizations, you can carve out some and include others. In our experience, that matters most when one provider will participate and another will not.

What a Carve-Out Report Means for Your Customers

Everything above concerns how the report gets built. This is what your customer, and often your customer's own auditor, has to work through.

A carve-out report covers your controls but not the controls at your subservice organization. To see assurance over those, your customer reviews the subservice organization's own SOC report. Carve-out is standard and fully compliant. It does add a review step for your customer, so it helps to make that step easy.

A report user will check that second report for deviations, any management response to them, whether the opinion was modified, whether the CUECs in the subservice organization's report are ones you have implemented, whether its scope covers the services you rely on, and whether the period it covers lines up with yours.

Expect vendor risk teams to ask focused questions about your subservice organizations and how you monitor them. Keep the subservice organization's current report for your own review. Because SOC reports are restricted-use, direct customers to the subservice organization for their own copy rather than forwarding yours. That documentation, along with evidence of your monitoring, shows how you manage the controls sitting outside your examination scope.

When a Carve-Out Gets Complicated

Not every case is straightforward. Once you carve out a subservice organization, a few situations call for closer judgment about the assurance you can offer.

• The subservice organization has no SOC report. The carve-out method still works mechanically, though this is often a reason to consider the inclusive method instead. If you carve out, your monitoring controls become your main source of assurance, and you may lean on site visits, reconciliations of the reports you receive, periodic reviews, or your audit rights under the contract to support them.
• Its report shows deviations, or the opinion is modified. A carve-out removes the controls from your report scope. It does not remove the risk from your business. It helps to document how you evaluated the deviation against the commitments and control objectives your report covers, and which of your own controls reduce the risk.
• The report periods do not line up. When the subservice organization's report period ends before yours, the intervening months sit outside any examined report. A bridge letter from the subservice organization is the usual stopgap, typically covering three months or less, though no standard sets a limit, and some auditors will not accept longer. A bridge letter is a management representation rather than an examined deliverable, so it carries less weight than the report itself.
• The relationship changes mid-period. Adding a provider, switching providers, or bringing a function back in-house all change the system, and a type 2 report has to disclose significant changes during the period. Depending on timing, the change may also affect which method you can use.

Working Through the Decision With Your Service Auditor

Your service auditor does not choose the method. You do, and you make that call with your auditor's input. The description of your system is yours, so the decision about what it covers is yours too. Your auditor is involved from the start, first evaluating whether it can accept the engagement, then planning and examining whether the description is fairly presented and whether your controls are suitably designed. For a type 2 report, the auditor also tests whether those controls operated effectively over the period. Under the inclusive method, that work extends to the subservice organization.

Knowing where that line sits makes for a more productive planning conversation. Ask how each method would change your scope and your SOC report, what the description criteria require either way, and what the inclusive method would actually involve.

Ask early, ideally before the period covered by the report begins. The inclusive method hinges on a third party agreeing to participate, providing its own written assertion, and granting access to its records, with the auditor independent of that provider as well as of you. In our experience, none of that comes together quickly. Learn during the examination that a provider will not cooperate, and you are reworking your description into carve-out form, which calls for different content rather than a simple deletion, along with a fresh assertion and a later report date.

Bringing Subservice Organizations Into Examination Scope

Choosing between the SOC 2 carve-out method vs the inclusive method is a scoping and reporting decision. It is driven by whether your subservice organization will participate, what your user entities need to see in one report, and how much of your system, including subservice organizations, is brought into the examination. Under either method, you retain responsibility for monitoring the providers you depend on.

Securisea's SOC examinations are performed by our affiliated licensed CPA firm, Securisea Attest, P.C. Securisea Attest performs examinations under both methods, including the independence evaluation, written assertion, and coordinated testing that the inclusive method requires of a subservice organization. Management makes the election. The requirements that constrain it are worth establishing during planning, before the reporting period begins. This overview is general information and does not replace the AICPA standards.

Learn more about SOC examinations at Securisea, or contact us to discuss the scope of an upcoming examination.