Security Frameworks & Compliance

Why Frameworks Exist

The Prioritization Problem

Every organization that builds a security program faces the same starting problem: there are hundreds of possible controls, limited budget, and no obvious order to implement them in. Frameworks exist to solve that problem by encoding decades of collective experience into a repeatable structure. Instead of a CISO inventing a program from first principles, they adopt a framework that already reflects what thousands of other organizations learned, often the hard way, about what actually reduces risk.

A Shared Vocabulary

Frameworks also create a common language. When a security team says they have mapped their controls to NIST CSF, an auditor, a board member, a cyber insurance underwriter, and a new hire can all understand roughly what that means without a lengthy explanation. That shared vocabulary matters more than it sounds like it should.

Security programs get evaluated constantly, by regulators, by acquirers during due diligence, by insurers setting premiums, and a framework gives everyone involved a reference point instead of a one-off narrative that has to be re-explained each time.

Legal and Reputational Value

There is also a legal and reputational dimension. If an organization suffers a breach and gets sued or investigated, being able to demonstrate alignment with a recognized framework is evidence of reasonable care. Courts and regulators do not expect perfection, but they do expect organizations to have followed generally accepted practice.

An organization with no framework and no documented rationale for its security decisions has a much harder time defending itself than one that can point to NIST CSF or ISO 27001 alignment and show where gaps were identified and being worked.

Frameworks Are Not Interchangeable

None of this means frameworks are interchangeable or that adopting one is a finish line. Different frameworks serve different purposes: some are voluntary guidance meant to shape strategy, some are certifiable standards meant to prove a management system exists, and some are prioritized control lists meant to tell a small team what to do first with limited resources.

Picking the wrong one for the situation, or treating a framework as a checklist to complete once rather than a structure to operate continuously, wastes the exercise entirely.

NIST Cybersecurity Framework

The NIST Cybersecurity Framework (CSF), first published in 2014 and updated to version 2.0 in 2024, is a voluntary framework built around a small set of core functions that describe the full lifecycle of managing cybersecurity risk. It was originally developed for US critical infrastructure but has since been adopted far beyond that scope, across industries and countries, because the structure is genuinely useful and not tied to any specific regulatory regime.

NIST CSF does not tell an organization exactly which controls to implement. It gives a taxonomy for organizing whatever controls it chooses.

Why Govern Was Added

For most of its life, CSF organized everything under five core functions: Identify, Protect, Detect, Respond, and Recover. CSF 2.0 added a sixth function, Govern, sitting conceptually above the other five.

Earlier versions treated governance, things like risk strategy, roles and responsibilities, and supply chain risk management, as scattered subcategories rather than a first-class concern. NIST concluded that cybersecurity risk management fails without explicit executive-level ownership and policy structure driving the rest.

What Each Function Covers

• Identify covers understanding the organization's assets, risks, and business context: asset inventories, risk assessments, and understanding what actually needs protecting and why.
• Protect covers the safeguards that limit or contain a security event: access control, awareness training, data security, and protective technology.
• Detect covers the activities that identify a cybersecurity event is occurring: continuous monitoring, anomaly detection, and the detection engineering work most SOC analysts spend their day in.
• Respond covers the actions taken once an event is detected: incident response planning, communications, analysis, mitigation, and improvements.
• Recover covers restoring capabilities and services impaired by an incident: recovery planning, improvements, and communications during restoration.

Using CSF as a Maturity Model

The functions are deliberately non-linear. An organization does not march through Identify, then Protect, then Detect once and finish. All six operate continuously and simultaneously.

CSF is meant to be revisited as a maturity model, with organizations scoring themselves against implementation tiers from partial to adaptive. For a SOC analyst, the practical value of CSF is mostly as an organizing lens: when leadership asks whether the team has coverage in a given area, mapping current tooling and processes against these functions gives a fast, defensible answer.

Quick reference for the same six functions:

ISO 27001 and ISMS Basics

ISO 27001 is an international standard published jointly by ISO and IEC that specifies the requirements for an Information Security Management System, or ISMS.

What an ISMS Actually Is

An ISMS is not a piece of software or a single document. It is the overall system of policies, processes, risk assessments, and controls an organization uses to manage information security, treated as a living management discipline rather than a one-time project. ISO 27001 defines what that management system has to include for the organization to claim conformance.

Certifiable, Not Just Voluntary

The key structural difference between ISO 27001 and NIST CSF is certifiability. NIST CSF is voluntary guidance; there is no such thing as being "NIST CSF certified" by an accredited external body, only self-assessed or attested alignment.

ISO 27001 is a certifiable standard. An organization can hire an accredited certification body to conduct a formal audit, and if the audit passes, the organization receives an ISO 27001 certificate that is valid for a defined period, typically three years, with annual surveillance audits in between. That certificate becomes a marketable, verifiable claim that customers, partners, and procurement teams can check.

How the Standard Is Structured

The standard itself is built around a risk-based approach. Organizations are required to define the scope of the ISMS, conduct a formal risk assessment identifying threats and vulnerabilities to their information assets, and select controls to treat those risks.

Annex A of the standard (aligned with ISO 27002) lists a catalog of controls across categories like access control, cryptography, physical security, supplier relationships, and incident management. Organizations must produce a Statement of Applicability documenting which controls apply to them and why, or why others were excluded.

What an Audit Actually Checks

A certification audit does not check whether every possible control is perfectly implemented. It checks whether the management system itself is functioning: are risk assessments actually being performed and kept current, are the selected controls actually operating as documented, is there evidence of internal audits and management review, and is there a working process for corrective action when something fails.

This is why an organization can be ISO 27001 certified and still have security gaps. The certification attests that the management system for identifying and treating risk is real and operating, not that every risk has been eliminated.

CIS Controls

The CIS Controls, maintained by the Center for Internet Security, take a different approach entirely. Rather than a governance framework or a certifiable management standard, they are a prioritized, concrete list of defensive actions, currently 18 controls in version 8, ranked roughly by the impact they have on stopping real-world attacks.

Why Asset Inventory Comes First

The project's origin was pragmatic: security practitioners and analysts of actual breach data asked what a defender should do first if they could only do a few things. The answer became Control 1, Inventory and Control of Enterprise Assets, and Control 2, Inventory and Control of Software Assets, because you cannot protect what you do not know you have.

The 18 controls run from foundational asset and software inventory, through account and access management, data protection, secure configuration, vulnerability management, log management, malware defenses, network monitoring, security awareness training, and incident response, up through penetration testing at the top. Each control is broken down into specific, testable safeguards rather than abstract principles, which is a large part of why practitioners find the CIS Controls easier to act on day-to-day than NIST CSF or ISO 27001. A safeguard reads like "establish and maintain an inventory of enterprise assets," not "achieve appropriate visibility into organizational risk."

Implementation Groups: IG1 to IG3

CIS also recognizes that not every organization has the resources to implement all 18 controls at full depth immediately, so version 8 introduced Implementation Groups, IG1 through IG3, as a maturity on-ramp.

One List, Different Audiences

Because the CIS Controls map cleanly onto specific tools and specific SOC workflows, many teams use them as an internal roadmap even while formally reporting compliance posture against NIST CSF or ISO 27001 for external audiences.

A gap analysis against CIS Controls tends to produce a concrete backlog of engineering tickets; a gap analysis against NIST CSF tends to produce a strategic conversation about program maturity. Both are useful, but they answer different questions, and a mature security program typically references more than one framework depending on the audience.

Compliance Overview: PCI-DSS, HIPAA, and GDPR

Frameworks are voluntary, or at most contractually required. Regulations are legally mandatory, and getting them wrong carries fines, lawsuits, and in some cases criminal exposure.

Three of the regulations SOC analysts run into most often are PCI-DSS, HIPAA, and GDPR, and each covers a different category of data with a different enforcement mechanism.

PCI-DSS: Payment Card Data

PCI-DSS, the Payment Card Industry Data Security Standard, applies to any organization that stores, processes, or transmits cardholder data, regardless of size, from a small retailer to a global payment processor. It is not a government law but a contractual requirement imposed by the major card brands (Visa, Mastercard, American Express, and others) through the acquiring banks and payment processors merchants work with.

One requirement analysts encounter directly is log retention: PCI-DSS Requirement 10 requires audit logs for events related to cardholder data environments to be retained for at least one year, with at least three months immediately available for analysis. An analyst investigating a card-present fraud case who finds the relevant logs were purged after 30 days is looking at a compliance failure, not just an operational gap.

HIPAA: US Health Information

HIPAA, the Health Insurance Portability and Accountability Act, applies to US healthcare providers, health plans, healthcare clearinghouses, and their business associates who handle protected health information, or PHI. Its Security Rule requires administrative, physical, and technical safeguards for electronic PHI.

The requirement analysts hit most directly is the Breach Notification Rule: a covered entity that experiences a breach affecting 500 or more individuals must notify the affected individuals, the Department of Health and Human Services, and in many cases the media, without unreasonable delay and no later than 60 days after discovery. That 60-day clock starts the moment the breach is discovered, which is exactly why fast, accurate incident scoping by the SOC has legal consequences, not just operational ones.

GDPR: EU Personal Data

GDPR, the EU General Data Protection Regulation, applies to any organization, regardless of where it is headquartered, that processes personal data of individuals in the EU. It defines personal data broadly, covering anything that can identify a natural person, not just financial or health data.

The requirement most relevant to incident response is Article 33's 72-hour breach notification rule: a data controller must notify the relevant supervisory authority within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in risk to individuals' rights and freedoms. Seventy-two hours is not a lot of time to determine scope, root cause, and affected data categories, which is why GDPR incident response playbooks are built around getting a preliminary notification out fast and supplementing it with detail later, rather than waiting for a complete investigation.

Quick reference for all three:

Framework vs Compliance: a Common Confusion

The single most important distinction in this chapter is that compliance is a floor, not a ceiling. A compliance requirement defines the minimum set of controls an organization must have in place to avoid legal or contractual penalty.

It says nothing about whether those controls are sufficient against the specific threats the organization actually faces. An attacker does not care whether the environment they are breaching passed its last audit.

Why the Gap Exists

This gap exists for structural reasons, not just sloppy implementation. Compliance requirements are written to be broadly applicable and objectively auditable, which means they tend to specify things that can be checked at a point in time: does a firewall exist, is a password policy documented, was a risk assessment performed in the last twelve months.

An auditor working from a checklist has limited ability to evaluate whether the security team's detection logic is actually good, whether the incident response process holds up under a real attack, or whether the organization's threat model matches its actual adversaries. Those questions require judgment that compliance frameworks are not designed to capture at scale.

Compliance Is a Snapshot, Not a Guarantee

There is also a timing mismatch. An audit is a snapshot. A PCI-DSS assessment or ISO 27001 surveillance audit certifies a state of controls as of the audit date, but environments change constantly: new systems get deployed, configurations drift, employees change roles and retain access they should have lost.

An organization can be fully compliant on the day of its audit and materially less secure three months later without any single dramatic failure, just accumulated drift that no interim audit catches.

What This Means for Analysts

The practical takeaway for analysts is to treat compliance status and security posture as two separate questions that happen to be related. When a compliance requirement drives a control, like log retention under PCI-DSS, use it, but do not assume the requirement itself represents the ceiling of what good practice looks like.

Good SOC teams routinely exceed minimum retention windows, monitor beyond the specific data types a regulation names, and build detections for TTPs no regulation mentions, because the regulation was never trying to describe a complete defense.