SOC 2, ISO 27001, and NIST CSF: The Trio

Three frameworks, three different origins, one overlapping goal. If you work in GRC, you will reference all three within your first month.

SOC 2 came from American accountants. ISO 27001 came from international standards bodies. NIST CSF came from a US presidential executive order. They were designed by different groups, for different audiences, with different enforcement mechanisms. Yet walk into any mature security program and you'll find all three influencing how controls are built.

This lesson breaks each one down — what it actually is, who asks for it, and how the three connect. By the end, you'll know which framework to reach for in a given situation and why experienced GRC engineers use NIST CSF as the map that ties the other two together.

SOC 2: The attestation report

Origin and structure

SOC 2 was created by the American Institute of Certified Public Accountants (AICPA). It is not a certification. It is an attestation report — a CPA firm examines your controls, tests them, and writes an opinion letter saying whether those controls are designed effectively and, in the case of Type II, whether they operated effectively over a period of time.

This distinction matters. You don't "get SOC 2 certified." You engage an audit firm, they examine your controls against the Trust Services Criteria, and they produce a report. That report is what your customers receive.

The five Trust Services Criteria

SOC 2 organizes controls around five categories:

1. Security (required) — the baseline. Also called the Common Criteria. Covers logical and physical access, system operations, change management, and risk mitigation.
2. Availability — system uptime commitments, disaster recovery, backup processes.
3. Processing Integrity — data is processed completely, accurately, and in a timely manner.
4. Confidentiality — protection of information designated as confidential (distinct from privacy).
5. Privacy — collection, use, retention, disclosure, and disposal of personal information.

Every SOC 2 audit includes Security. The other four are optional — you select the ones relevant to your service commitments.

The CC numbering system

The Security criterion is broken into Common Criteria, numbered CC1 through CC9. This is the numbering system you will reference constantly:

Trust Services Criteria: Security (Common Criteria)
────────────────────────────────────────────────────

CC1   Control Environment
CC2   Communication and Information
CC3   Risk Assessment
CC4   Monitoring Activities
CC5   Control Activities
CC6   Logical and Physical Access Controls    ◄── IAM lives here
CC7   System Operations
CC8   Change Management
CC9   Risk Mitigation

────────────────────────────────────────────────────
Optional Criteria:
A1    Availability
PI1   Processing Integrity
C1    Confidentiality
P1    Privacy

CC6 is where most GRC engineers spend the bulk of their time. CC6.1 specifically addresses logical access controls — how users are provisioned, how access is restricted based on role, how privileged accounts are managed. When a customer asks "how do you handle IAM?", the answer maps to CC6.

Concrete example: CC6.1 requires that logical access to information assets is restricted. For a GRC Engineer, that means the Okta configuration that enforces MFA on all users, the AWS IAM policies that restrict cross-account access, and the Terraform module that provisions both — all of that is CC6.1 evidence.

Type I vs Type II

• Type I — point-in-time. The auditor examines whether controls are designed effectively as of a specific date. Useful for startups getting their first report.
• Type II — period of time. The auditor examines whether controls operated effectively over a window (typically 6 or 12 months). This is what enterprise buyers actually want.

Type I is the starter report. Type II is the real thing. Most companies do a Type I first to get through initial procurement conversations, then move to Type II within a year.

Who requires SOC 2

US-based SaaS buyers. Enterprise procurement teams. If you sell B2B software in the United States, SOC 2 Type II is table stakes. It's the first compliance question in most security questionnaires.

ISO 27001: The certification

Origin and structure

ISO 27001 is published by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). Unlike SOC 2, it is a certification. An accredited certification body audits your Information Security Management System (ISMS) and, if it meets the requirements, issues a certificate valid for three years (with annual surveillance audits).

The standard has two parts:

1. Clauses 4-10 — the management system requirements. These define how your organization plans, implements, operates, monitors, reviews, and improves its ISMS. They cover things like leadership commitment (Clause 5), risk assessment methodology (Clause 6), competence and awareness (Clause 7), and internal audit processes (Clause 9).

2. Annex A controls — a catalog of 93 controls (as of the 2022 update) organized into four themes: Organizational, People, Physical, and Technological. You don't have to implement every Annex A control. You perform a risk assessment, decide which controls are applicable, and document the rest in a Statement of Applicability (SoA) explaining why they're excluded.

The 2022 update

The previous version (ISO 27001:2013) organized Annex A into 14 domains with 114 controls. The 2022 revision restructured this into four themes and reduced the count to 93 controls by merging overlaps and adding 11 new controls covering areas like threat intelligence, cloud services security, and data masking.

If you encounter references to "Annex A.9" in older documentation, that was the 2013 access control domain. In the 2022 version, access control is spread across several controls in the Technological theme (A.8.x series), but the substance is the same.

Concrete example

Under the 2013 structure, Annex A.9 (Access Control) required documented policies for access management, user registration and de-registration, privilege management, and password management. For a GRC Engineer, this maps to the same territory as SOC 2 CC6.1 — your IAM provider configuration, your RBAC model, your JML (Joiner-Mover-Leaver) automation, your access review process.

Under the 2022 structure, the equivalent controls include A.8.2 (Privileged access rights), A.8.3 (Information access restriction), A.8.5 (Secure authentication), and A.5.15 (Access control policy). The control IDs changed. The engineering work didn't.

Who requires ISO 27001

European customers and enterprise buyers. EU-based companies default to asking for ISO 27001 the way US companies default to asking for SOC 2. Government procurement in many countries lists ISO 27001 as a prerequisite. If you're selling into EMEA, Japan, or Australia, ISO 27001 certification is often non-negotiable.

NIST Cybersecurity Framework: The Rosetta Stone

Origin and purpose

The NIST Cybersecurity Framework (CSF) was created by the National Institute of Standards and Technology, a US government agency. It originated from Executive Order 13636 in 2013, which directed NIST to develop a voluntary framework for improving critical infrastructure cybersecurity.

The key word is voluntary. NIST CSF is not a standard you get certified against. No auditor issues a NIST CSF report. No accredited body grants a NIST CSF certificate. It is a framework — an organizing structure for thinking about cybersecurity risk management.

So why does every GRC engineer need to know it? Because NIST CSF functions as the translation layer between other frameworks. When you need to explain how SOC 2 CC6.1 relates to ISO 27001 A.8.3, NIST CSF gives you a shared vocabulary.

The core functions

NIST CSF organizes all cybersecurity activities into core functions that form a lifecycle. CSF 1.1 defined five functions; CSF 2.0 (released February 2024) added a sixth, Govern:

┌──────────────┐
                  │   IDENTIFY   │
                  │  Asset mgmt, │
                  │  risk assess │
                  └──────┬───────┘
                         │
            ┌────────────┼────────────┐
            │            │            │
            ▼            │            ▼
   ┌────────────┐        │     ┌─────────────┐
   │  PROTECT   │        │     │   DETECT    │
   │  Access    │        │     │  Anomalies, │
   │  control,  │        │     │  continuous │
   │  training, │        │     │  monitoring │
   │  data sec  │        │     └──────┬──────┘
   └────────────┘        │            │
            │            │            │
            │     ┌──────┴───────┐    │
            │     │   GOVERN*    │    │
            │     │  (CSF 2.0)   │    │
            │     │  Oversight,  │    │
            │     │  strategy,   │    │
            │     │  supply chain│    │
            │     └──────────────┘    │
            │                         │
            ▼                         ▼
   ┌────────────┐            ┌────────────┐
   │  RESPOND   │◄──────────►│  RECOVER   │
   │  IR plans, │            │  Restore,  │
   │  comms,    │            │  lessons   │
   │  analysis  │            │  learned   │
   └────────────┘            └────────────┘

* CSF 2.0 (2024) added Govern as a sixth function.
  The original five remain the operational core.

Each function breaks down into categories and subcategories. The subcategory level is where the mapping to other frameworks happens. For example:

• PR.AC (Protect: Access Control) — covers identity management, authentication, access permissions, and network integrity.
• PR.AC-1 — "Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users, and processes."

That subcategory maps directly to SOC 2 CC6.1 and ISO 27001 A.8.2/A.8.3/A.5.15. Same engineering work. Same Terraform. Same Okta configuration. Three different control IDs.

The NIST CSF 2.0 update

In February 2024, NIST released CSF 2.0, which added a sixth function — Govern — to address organizational context, risk management strategy, roles and responsibilities, and supply chain risk management. The original five functions remain the operational core. Govern wraps around them as the strategic oversight layer.

For GRC engineers, the most practical addition is the explicit supply chain risk management coverage and the expanded guidance on integrating CSF with other frameworks — exactly the cross-mapping use case that makes CSF valuable in the first place.

Why NIST CSF matters even when it's not required

No customer will ever ask you for a "NIST CSF report." But NIST CSF categories give you a taxonomy to organize your internal control library. When your SOC 2 auditor asks about CC6.1 and your ISO auditor asks about A.8.3, you can point them to the same internal control — filed under PR.AC in your control framework — with different evidence packages for each audit.

This is why experienced GRC engineers call NIST CSF the Rosetta Stone. It doesn't replace SOC 2 or ISO 27001. It connects them.

How the three relate

The relationship is straightforward once you see the pattern:

• SOC 2 and ISO 27001 are audit standards. They result in deliverables (a report or a certificate) that external parties use to evaluate your security posture. They are driven by customer and market requirements.
• NIST CSF is an organizing framework. It provides the taxonomy and structure for your internal security program. It is driven by your own need for coherence.

In practice, a mature GRC program works like this:

1. Build your internal control library organized by NIST CSF categories (Identify, Protect, Detect, Respond, Recover, Govern).
2. Map each internal control to the SOC 2 Common Criteria it satisfies.
3. Map the same control to the ISO 27001 Annex A controls it satisfies.
4. When audit season arrives, pull the relevant evidence for each framework from the same underlying controls.

This is why GRC engineers who understand all three frameworks are so valuable. You don't build three separate compliance programs. You build one program and map it three ways.

Cross-mapping example: Access control

Four rows in a spreadsheet. One Terraform module. Three satisfied auditors.

When to use which

The decision depends on your market, your customers, and your regulatory environment:

Selling B2B SaaS to US companies — Start with SOC 2 Type II. It's the first item on every enterprise security questionnaire. Most US procurement teams won't move forward without it.

Selling to European or international enterprise — Start with ISO 27001. European buyers treat ISO 27001 the way American buyers treat SOC 2. Many EU government procurement processes explicitly require it.

Government or critical infrastructure — NIST CSF is the foundation, often alongside more specific NIST publications (800-53, 800-171) and, for cloud services, FedRAMP. NIST CSF gives you the structure; the other NIST pubs give you the specific control baselines.

Selling globally at scale — You need all three. SOC 2 for US customers, ISO 27001 for international customers, and NIST CSF as the internal framework that keeps your program coherent across both audits.

Startups with no compliance program yet — Use NIST CSF categories to organize your security controls from day one. Even before you engage an auditor, structuring your controls around Identify/Protect/Detect/Respond/Recover means you'll have a natural mapping when SOC 2 or ISO 27001 comes up.

What to remember

The trio isn't three competing standards. It's three layers of the same discipline:

• NIST CSF gives you the map — the categories and functions that organize your security program.
• SOC 2 gives you the US market proof — an attestation report that satisfies American enterprise buyers.
• ISO 27001 gives you the international proof — a certification that satisfies global enterprise and government buyers.

The engineering work underneath all three is identical. The Terraform module, the Okta configuration, the CloudTrail monitoring — none of that changes based on which framework you're satisfying. What changes is how you document it, how you present evidence, and which auditor reads the report.

That's the core insight of GRC engineering: the frameworks are different lenses on the same underlying controls. Learn the controls once, map them three ways.