SOC 2 vs NIST Cybersecurity Framework: Audit Readiness

A SOC 2 examination produces a CPA firm’s report on the controls in a defined service system. The NIST Cybersecurity Framework (CSF) helps an organization assess and manage cybersecurity risk. NIST does not issue a CSF certification, and using the framework does not produce a SOC 2 report.

For the six CSF 2.0 functions and an assessment cost range, see the NIST CSF explainer. For the other frameworks, see our compliance framework comparison.

What SOC 2 and the NIST CSF cover

SOC 2 is an AICPA reporting framework for service organizations. An independent CPA firm examines the described system and issues a report on its controls. A Type 1 report addresses their design at a point in time; a Type 2 also addresses how they operated during the period examined.

The five Trust Services Criteria are Security, Availability, Processing Integrity, Confidentiality, and Privacy. Nearly every SOC 2 examination includes Security; the others depend on the service commitments and engagement scope.

What the NIST CSF covers

The NIST CSF organizes cybersecurity risk management into outcomes. Organizations can use it to describe current practices, set targets, and prioritize gaps. It does not prescribe a SOC 2 examination. Our guide to SOC 2 for government contractors explains how SOC 2 maps to NIST 800-171 and CMMC in that setting, and SOC 2 vs CMMC covers how SOC 2 evidence maps to the 800-171 requirements that CMMC Level 2 assesses.

CSF 2.0 was published in February 2024. It added a sixth function, Govern, to make cybersecurity governance explicit alongside the existing five functions. If your control map still uses CSF 1.1 identifiers, review NIST’s transition guidance before reusing it: several category identifiers changed in 2.0.

The framework is organized around six core functions:

• Govern: Establish and monitor the organization’s cybersecurity risk management strategy, expectations, and policy.
• Identify: Understand the cybersecurity risks to your systems, assets, data, and capabilities.
• Protect: Implement appropriate safeguards to ensure the delivery of critical services.
• Detect: Develop and implement activities to identify the occurrence of a cybersecurity event.
• Respond: Take action once a cybersecurity incident is detected.
• Recover: Implement activities to maintain resilience and restore capabilities impaired by an incident.

Set the boundary for each assessment

For SOC 2, management describes the system being examined, including the people, processes, data, and technology that support the service. The report covers that system against the applicable Trust Services Criteria — Security and, when relevant, Availability, Processing Integrity, Confidentiality, or Privacy. The boundary should reflect the service commitments made to customers.

An organization can apply the NIST CSF to its enterprise or a defined part of it. The framework organizes cybersecurity outcomes across areas such as corporate IT and operational technology; applying it does not create an attestation.

What the boundary changes

An unclear SOC 2 boundary can lead to extra evidence requests and testing for systems unrelated to the service. Agree on the described system with the CPA firm before estimating effort. A broader CSF Profile can still guide risk work elsewhere in the company.

For example, a SaaS provider may scope its SOC 2 report around the hosted service and the people and systems supporting it. Corporate identity and development processes may also fall within that scope when they affect the service. The company can use a broader CSF Profile for other business systems if that helps manage risk.

Scope check: List the service commitments, supporting systems, and people in the SOC 2 description. Ask the CPA firm which controls and evidence fall within that boundary.

Include operational work in the boundary

Include the people, processes, and data supporting the service, not only its technology. For example, support escalation and incident records may matter to Security or Availability controls. Document who owns those processes and where their evidence is kept.

Where control work can overlap

Work done under a CSF Profile may also support a SOC 2 examination. Whether an artifact is useful depends on the SOC 2 system boundary, the selected criteria, and the period examined. Map the work before assuming it can be reused.

How NIST Work Becomes SOC 2 Evidence

Implementing controls while using the NIST CSF can support SOC 2 preparation, particularly for the Security Common Criteria. Risk assessments, policies, procedures, and technical configurations may also serve as audit evidence when they cover the examined system and show the controls operating. A CSF outcome alone does not establish that a SOC 2 criterion has been met.

A CSF Profile can help organize control work and evidence. It does not prescribe the exact controls a SOC 2 auditor will test; those depend on the described system, service commitments, selected criteria, and the CPA’s examination plan.

A Practical Map from NIST Controls to SOC 2 Criteria

Use the table below to find evidence worth discussing with the CPA firm. It is not a prescribed control map.

Mapping NIST CSF Functions to SOC 2 Trust Services Criteria

This table gives examples of how NIST CSF 2.0 categories can inform work against the AICPA Trust Services Criteria. The categories and criteria are not interchangeable.

These are working alignments, not one-to-one equivalences or a prescribed evidence list. The auditor determines which controls and evidence address each criterion in the system under examination. See the SOC 2 common criteria for more detail. For all six functions, with the NIST categories and the controls in our SOC 2 controls library, see the full crosswalk below.

Audit vs. Self-Assessment: The Real-World Difference

A SOC 2 engagement is a formal examination performed by a licensed CPA firm, culminating in an attestation report with the auditor’s opinion on the controls in scope.

The NIST Cybersecurity Framework (CSF) can be used for self-assessment or with outside help. NIST does not offer an official CSF certification or attestation. Organizations can document a Current and Target Profile to guide risk management and investment decisions; an independent assessment can be commissioned separately, but it is not a NIST-issued credential.

The Rigor of a SOC 2 Audit

Auditors work to professional standards set by the AICPA, so the report gives independent assurance that a self-assessment cannot. Key phases include:

• Readiness Assessment: An initial gap analysis to identify missing controls and documentation before the formal audit begins.
• Remediation: The period dedicated to implementing new controls, updating policies, and closing identified gaps.
• Evidence Collection: Gathering specific artifacts — such as system configurations, change logs, and access reviews — that prove controls are in place and operating.
• Auditor Testing: The CPA firm independently tests a sample of evidence to verify the design and (for a Type 2) operating effectiveness of each control.

The Flexibility of a NIST CSF Self-Assessment

The NIST CSF process is flexible. An organization can establish its current security posture (a “Current Profile”) and desired state (a “Target Profile”), then prioritize the gaps. An outside assessor may review that work, but NIST does not issue a CSF certification. Ask what was assessed, by whom, and against which Profile before relying on a claim of CSF alignment.

For a buyer seeking independent assurance, a SOC 2 report and a CSF Profile answer different questions. A SOC 2 Type 2 examination tests control operation over a specified period; a CSF Profile helps the organization describe and prioritize cybersecurity outcomes. Ask prospective auditors to price the actual system boundary, criteria, and reporting period. A CSF assessment may help prepare controls, but it does not replace a SOC 2 examination or establish HIPAA compliance.

If a customer asks for a SOC 2 report, a CSF self-assessment does not meet that request. Confirm the report type, system, criteria, and period the customer will accept.

What each produces

A SOC 2 engagement produces a CPA firm’s report and opinion for the stated system and criteria. A CSF self-assessment can produce a Profile, risk register, and improvement plan.

Is there a NIST CSF audit, and how do its functions line up with SOC 2?

NIST publishes the CSF and does not test anyone against it, so “NIST CSF audit” is not a defined engagement. The phrase covers several different things, and only some end in a CPA’s opinion. Below we separate them, say what mapping exists between the CSF and the Trust Services Criteria, and give our own function-by-function crosswalk to our SOC 2 controls library.

What do NIST and the AICPA say about auditing the CSF?

NIST’s CSF 2.0 FAQ (last updated August 2026) says: “NIST is not a regulatory agency, and most organizations use the CSF on a voluntary basis.” It adds that Executive Order 13800 made the framework mandatory for U.S. federal agencies and that “some companies require the CSF for their customers or within their supply chain.” On certification it is direct: “NIST does not offer certifications or endorsements of CSF-related products, implementations, or services, and there are no plans to develop a conformity assessment program.” The framework document itself, NIST CSWP 29, mentions auditors once, in its list of people who can use the CSF to guide their decisions, and describes no certification or attestation scheme.

The CPA route is separate. The AICPA’s SOC 2 Guide (October 2022) calls itself an interpretation of attestation standards AT-C sections 105 and 205 that assists CPAs in reporting on a system’s controls. So a request that mentions the CSF and an audit can mean any of these:

Training firms also sell credentials with names such as “NIST CSF 2.0 Lead Auditor.” Those are the seller’s credentials. NIST says it offers no CSF certifications or endorsements, so none of them is a NIST certification.

Is there an official mapping between the CSF and the Trust Services Criteria?

The AICPA publishes one, but it predates CSF 2.0. Mapping: 2017 Trust Services Criteria to NIST CSF is a spreadsheet that, in the AICPA’s words, “compares the requirements of NIST CSF to the relevant categories within the 2017 Trust Services Criteria.” Downloading it needs a free AICPA account. The listing is dated May 2018, says it includes March 2020 updates to the criteria, and names no CSF version. Both dates come before CSF 2.0 (February 2024), which added Govern and, in NIST’s words, moved CSF 1.1’s PR.AC to PR.AA, “revised, and re-sequenced.” Check the file’s identifiers before you reuse it: a PR.AC code means CSF 1.1.

The SOC 2 Guide says the AICPA has mapped the requirements of commonly used frameworks to the criteria and keeps those mappings on its website (footnote to paragraph 1.64). A separate AICPA listing maps the criteria to NIST SP 800-53.

NIST’s side is a catalog, not a SOC 2 mapping. CSF 2.0 Informative References are mappings from CSF outcomes to other documents, and they “may be produced by NIST or another organization” (CSWP 29, section 4). NIST’s informative references page says it does not test non-NIST mappings for correctness and that a listing does not imply NIST endorsement. As of 25 October 2026, the full CSF 2.0 reference download cites sources such as NIST SP 800-53 Rev 5, SP 800-171 Rev 3, ISO/IEC 27001:2022, PCI DSS, and CIS Controls v8.1, and has no AICPA or Trust Services Criteria entry. We know of no mapping from either body that states it covers both CSF 2.0 and the Trust Services Criteria, so the crosswalk below is ours.

How do the six CSF functions line up with SOC 2 criteria and our controls?

This is our own reading, not an AICPA or NIST crosswalk. It uses the CSF 2.0 categories in Appendix A of CSWP 29, the Trust Services Criteria, and the example controls in our SOC 2 controls library, which holds 82 controls. Each row shows evidence you may be able to reuse; confirm with your CPA firm. It does not show that meeting a CSF outcome meets a criterion, and your risk assessment decides which controls you run.

Criteria that start with A1 or C1 apply only when Availability or Confidentiality is in the report.

Read down the criteria column and the Common Criteria mostly split by function. CC1 to CC5 sit under Govern and Identify, CC6 and CC8 under Protect, and CC7 spreads across Detect, Respond, and Recover. CC9 splits: vendor risk (CC9.2) sits under Govern, and business-disruption risk (CC9.1) under Protect. SOC 2 groups criteria by area of control, while the CSF groups outcomes by what the security team is doing, so one CSF function draws on several criteria series.

Some controls count twice. LG-02 (alert triage) supports Detect and Respond, IR-03 (incident records) supports Respond and Recover, and IR-02 (the annual response exercise) supports Identify and Recover. Run each once and cite it under every row it supports. For CC6 and CC7 criterion by criterion, with the evidence an auditor samples, see SOC 2 security controls.

Processing Integrity and Privacy fall outside every row. The library’s Processing Integrity controls (PRC) and Privacy controls (PV) have no row because, in our reading, no CSF category concerns the accuracy of processing or notice and consent for personal information. If your SOC 2 scope adds Processing Integrity or Privacy, plan that evidence separately, because a CSF Profile gives you little to reuse for those criteria.

Which federal assessors also issue SOC 2 reports?

A CSF Profile is not what a federal assessor tests. CMMC Level 2 requirements are “identical to the requirements in NIST SP 800-171 R2” (32 CFR 170.14), and third-party FedRAMP and CMMC Level 2 assessments come from assessors on their own official lists. A SOC 2 opinion comes from a licensed CPA firm. Our directory counts the firms that appear on both sides:

Each count is the number of firms on that listing page, so it is not the size of the official list. Other assessors on the official lists may not issue SOC 2 reports or may not be in our directory. A federal assessment and a SOC 2 report stay separate engagements even when one firm does both, so ask each firm which legal entity signs which deliverable.

Choosing the Right Framework for Different Business Scenarios

Choose the work according to the assurance customers request and the risks the organization needs to manage. A company may use the CSF to organize security work while pursuing a SOC 2 report for a defined service.

For Early-Stage SaaS Startups

For an early-stage SaaS startup, the NIST CSF can help identify gaps in risk assessment and access controls before a formal audit. If prospective customers ask for a SOC 2 report, confirm whether a Type 1 point-in-time opinion will meet their review requirements or whether they need a Type 2 report covering a period. That answer should set the audit plan.

For Mid-Market Tech Companies

Mid-market companies may face detailed vendor reviews from large customers. When those customers require evidence that controls operated over time, a SOC 2 Type 2 report can address that request. The NIST CSF can guide risk management across the organization, including areas outside the SOC 2 system boundary, if the company chooses a broader CSF Profile.

For FinTech and HealthTech Organizations

Finance and healthcare buyers may request a SOC 2 report, another independent assessment, or evidence tied to a specific regulation. A SOC 2 engagement nearly always includes Security; Confidentiality is added when relevant to the system and service commitments. A Type 2 report can show how selected controls operated over the examination period, but it does not by itself prove HIPAA compliance. Ask the buyer which report, criteria, and system scope its review requires.

For a FinTech or HealthTech company, ask customers and regulators what assurance they require. A SOC 2 report may satisfy a vendor-review request for independent control testing; a CSF Profile can guide internal risk management. Neither automatically satisfies every regulatory obligation.

For Procurement Teams Vetting Vendors

For a procurement team, a SOC 2 report supplies a CPA’s opinion and, in a Type 2 report, the auditor’s control tests and results for the examined system. A claim of being “NIST aligned” needs context: ask for the CSF Profile, scope, and whether an independent assessor reviewed it. Neither document replaces the team’s assessment of risks outside its stated scope.

Using a CSF Profile during SOC 2 preparation

SOC 2 and the NIST Cybersecurity Framework serve different purposes. A CSF Profile can help a service organization identify risk-management gaps before a SOC 2 engagement. The CPA will still examine the controls and evidence for the described SOC 2 system against the selected Trust Services Criteria.

From Foundational Controls to Audit-Ready Evidence

Starting with a CSF Profile can expose operational gaps before a SOC 2 examination. For example, work toward Protect (PR.AA) outcomes may support controls relevant to CC6.1 on logical access. Respond (RS.MA) outcomes may inform controls relevant to CC7.3 on security-event evaluation and CC7.4 on incident response. The same artifact can support both efforts when it covers the examined system and shows the control actually operated.

Planning check: Record which CSF outcomes relate to the SOC 2 system, who owns the control, and what dated evidence exists. Ask the CPA whether that evidence supports the planned examination before estimating audit effort.

Connecting NIST Implementation to SOC 2 Audit Readiness

Using a CSF Profile can make security priorities and gaps visible. A SOC 2 opinion depends on the CPA’s findings for the stated system, criteria, and period; adopting the CSF does not predict an unqualified opinion. Before fieldwork, reconcile the Profile with the SOC 2 boundary and review exceptions, missing evidence, and control operation with the audit firm.

---

If a buyer needs a SOC 2 report, compare SOC 2 auditors on the same system scope, criteria, and reporting period before requesting quotes.