Frameworks
These are the frameworks and baseline requirements we work against most often in practice. The goal is not to drown you in control language. It is to turn real requirements into a workable plan, clear evidence, and a cleaner path to audit, insurance, or customer review.
Reference guide
Each section below covers what the framework actually expects, the controls that matter first, and which Obsidian Ridge service tiers usually close those gaps most cleanly.
Cyber insurance is not one codified framework. In practice, carriers commonly look for a short list of controls that materially reduce claim frequency and severity: strong MFA coverage, monitored endpoint protection, email security, backups, incident readiness, and employee awareness.
Most underwriting conversations now start with whether high-risk systems are protected with multi-factor authentication, especially email, admin accounts, VPNs, and remote access tools.
Legacy antivirus alone is usually not enough. Carriers increasingly expect EDR or MDR coverage that can detect and contain malicious activity quickly.
Because a large share of claims still begin in the inbox, recurring phishing simulations and short training modules are now part of the baseline conversation.
Backups need to be separated enough from production to survive ransomware and tested often enough that recovery is not theoretical.
Carriers want to see that an organization knows who makes decisions, who gets called, and how containment and communications will work under pressure.
Boundary devices, internet-facing services, and known exploitable vulnerabilities continue to show up in claims data, so exposure management matters.
Coalition reported that 56% of 2023 claims began with funds transfer fraud or business email compromise, reinforcing the importance of email and access controls.
Hiscox reported that more than half of U.S. businesses experience at least one cyber attack per year, underscoring the need for practical baseline controls.
At-Bay's 2026 findings emphasize that businesses with MDR and faster response processes have materially better outcomes after cyber events.
SOC 2 Type II is an attestation against the AICPA Trust Services Criteria. In practice, that means documented controls around security and related trust principles, plus evidence that those controls actually operated over a review period rather than existing only on paper.
You need a repeatable way to identify risks, assign accountability, and show leadership oversight of the control environment.
Logical access needs to be restricted, reviewed, and supported by stronger authentication for privileged and high-impact systems.
Material system changes should be authorized, tested, and traceable so the control environment remains stable as the business moves.
SOC 2 examiners typically expect evidence that security events are monitored, investigated, and escalated in a defined way.
CC7.2: Met via Managed tier SIEMIf vendors touch systems or data, there needs to be a process for evaluating them and managing the residual risk.
Policies matter, but Type II readiness also depends on screenshots, tickets, reviews, logs, and approvals that prove the controls operated over time.
AICPA defines SOC 2 examinations around controls relevant to security, availability, processing integrity, confidentiality, and privacy.
The Trust Services Criteria provide the underlying control criteria used in SOC 2 examinations.
The HIPAA Security Rule requires covered entities and business associates to protect electronic protected health information with administrative, physical, and technical safeguards. The goal is not box-checking alone; it is protecting confidentiality, integrity, and availability of ePHI in real operating environments.
HHS guidance starts with an accurate and thorough assessment of risks and vulnerabilities to ePHI, followed by measures that reduce them to a reasonable and appropriate level.
Someone needs to own the program, policies, and follow-through rather than leaving HIPAA security as a vague shared responsibility.
Users should have access aligned to role, and access to ePHI should be authorized, reviewed, and removed when no longer needed.
HIPAA expects practical protection for devices, workstations, removable media, and the spaces where ePHI is handled.
Organizations need security incident procedures plus backup, disaster recovery, and emergency mode operations that support care continuity.
Technical safeguards include the ability to record system activity and protect ePHI when it is transmitted.
HIPAA § 164.312(b): Met via Managed tier SIEMHHS states that the Security Rule requires administrative, physical, and technical safeguards for electronic protected health information.
HHS's summary explains the major safeguard categories and the operational expectations behind them.
OCR guidance emphasizes risk analysis as a foundational requirement for Security Rule compliance.
PCI DSS provides a baseline of technical and operational requirements designed to protect account data. Version 4.x keeps the familiar control structure but pushes organizations toward continuous security, broader MFA coverage, and risk-based validation rather than one-time checkbox activity.
The first hard problem in PCI is often scope. You need to know where account data lives, where it flows, and which systems can impact that environment.
PCI continues to require strong control over network paths into and within the cardholder data environment.
Systems handling or affecting card data need hardened builds, timely patching, and disciplined remediation of known weaknesses.
PCI DSS v4.0 expanded MFA expectations, especially for access into the cardholder data environment and administrative pathways.
Organizations need enough visibility to detect issues, validate controls, and support ongoing assessment activity.
PCI-DSS Requirement 10: Met via Managed tier SIEMPCI is not purely technical. Roles, training, documented procedures, and response preparation all matter to a clean assessment.
PCI SSC describes PCI DSS as a baseline of technical and operational requirements to protect account data and highlights v4.0's emphasis on flexibility and evolving threats.
The PCI SSC library is the canonical source for the standard, summary of changes, and supporting guidance.
CMMC Level 2 is built around protection of controlled unclassified information in the defense industrial base. In practice, it means implementing the NIST SP 800-171 security requirements, maintaining evidence, and preparing for the right kind of assessment depending on the contract and rollout phase.
CMMC readiness starts with identifying the systems, users, and vendors that process, store, or transmit controlled unclassified information.
Level 2 aligns to the 110 security requirements in NIST SP 800-171 Rev. 2, so readiness work needs to be systematic and evidence-backed.
Account lifecycle, least privilege, MFA, privileged access discipline, and boundary access all receive close attention.
Organizations need to show they can detect events, respond in a defined way, and preserve evidence that controls are operating.
CMMC AU.L2: Met via Managed tier SIEMSecure baselines, vulnerability remediation, and configuration control are central to keeping the environment defensible and assessable.
Readiness is not just technical implementation. Policies, system boundaries, SSP/POA&M discipline, and assessment preparation matter.
The DoD CIO describes the program, protected information types, and assessment expectations across levels.
The official model overview states that Level 2 focuses on protection of CUI and encompasses the 110 security requirements in NIST SP 800-171 Rev. 2.
The DoD business portal tracks current rollout details and links to the governing rules and implementation timeline.
NIST CSF 2.0 is not a checklist or certification. It is a risk-management framework that helps organizations understand current posture, define target outcomes, and prioritize work across the six functions: Govern, Identify, Protect, Detect, Respond, and Recover.
CSF 2.0 added Govern as a first-class function, which means leadership accountability, policy direction, and enterprise risk alignment are part of the model from the start.
You cannot prioritize risk well without understanding what matters, what supports it, and where the important dependencies sit.
Controls such as MFA, endpoint protection, secure configuration, and awareness training live in this function.
Detection is about telemetry, monitoring, and review processes that surface real issues before they become business-ending incidents.
NIST CSF DE.CM: Met via Managed tier SIEMCSF expects organizations to know how they will contain, communicate, and make decisions when something breaks.
Recovery planning, backup confidence, and post-incident learning are part of a credible CSF-aligned program.
NIST describes CSF 2.0 as guidance any organization can use to better understand, assess, prioritize, and communicate cybersecurity efforts.
NIST's release highlights the new Govern function and the framework's broadened applicability beyond critical infrastructure.
The overview guide explains how organizations can put CSF outcomes into action with supplemental NIST resources.
ISO/IEC 27001:2022 defines the requirements for an information security management system. That means building a repeatable way to assess risk, implement controls, assign ownership, review performance, and improve over time rather than treating security as a pile of disconnected tools.
ISO 27001 is ultimately about the management system itself: scope, leadership commitment, policies, objectives, and review cycles.
Organizations need a disciplined way to identify risks, evaluate them, choose treatments, and document decisions.
Controls need accountable owners, operating records, and review artifacts so the ISMS is demonstrable rather than aspirational.
The management system still has to land in real technical controls: identity, endpoint security, logging, backup, and secure operations.
Vendors, cloud services, and internal changes all need to be governed as part of the control environment.
Internal audits, corrective actions, and management review are part of what make ISO 27001 a living system instead of a one-time project.
ISO describes 27001 as the world's best-known standard for information security management systems and explains that it defines the requirements an ISMS must meet.
Founder
"Frameworks are useful when they force better decisions, cleaner evidence, and less confusion. They are not useful when they become a pile of controls nobody can operate once the audit or questionnaire is over."
— Kfir, CISSP | Founder
