Cybersecurity Compliance Checklist: Every Framework in One Place

This cybersecurity compliance checklist covers the five major frameworks your organization is most likely to face: SOC 2, HIPAA, ISO 27001, NIST CSF, and PCI DSS. Most organizations subject to cybersecurity compliance requirements must satisfy more than one framework simultaneously. A healthcare SaaS company might need HIPAA compliance, SOC 2 for enterprise customers, and NIST CSF for federal contracts. The good news: roughly 60 to 70% of controls across major frameworks overlap. Implementing them in parallel is far more efficient than treating each as a separate project.

This guide gives you a unified compliance checklist covering the five most common frameworks, identifies which controls are truly shared, and provides a decision framework for figuring out which certifications your organization actually needs.

Which Framework Do You Need? A Decision Guide

The right answer depends on your industry, your customers, and the type of data you handle. This is not a question of preference; most frameworks are driven by legal requirements, contractual obligations, or customer demand.

You need HIPAA if you are a covered entity (healthcare provider, health plan, healthcare clearinghouse) or a business associate that creates, receives, maintains, or transmits protected health information (PHI) on behalf of a covered entity. HIPAA is federal law. There is no opt-out.

You need PCI DSS if your organization stores, processes, or transmits payment card data. The requirement comes from the card brands (Visa, Mastercard, Amex) through your merchant agreement, not from a government regulator. Validation level depends on transaction volume.

You need SOC 2 if your enterprise customers (particularly in North America) require a third-party security attestation before signing contracts. SOC 2 is demand-driven rather than legally mandated for most companies, but for B2B SaaS companies it functions as a de facto requirement at the enterprise tier.

You need ISO 27001 if you are selling to European enterprise customers, government agencies in countries that recognize ISO standards, or if your sales team needs a globally recognized certification. ISO 27001 from the International Organization for Standardization (ISO) carries more weight internationally than SOC 2.

You need NIST CSF if you work with U.S. federal agencies or if you want a structured risk management framework to organize your security program. NIST CSF (Cybersecurity Framework) from the National Institute of Standards and Technology is voluntary for the private sector but mandatory for many federal contractors and increasingly referenced in state regulations. Version 2.0, released in 2024, expanded coverage to supply chain risk and governance.

You likely need multiple frameworks if you are a SaaS company in healthcare, financial services, or government contracting. The overlap between frameworks means this is less painful than it sounds, but you do need to plan your controls architecture to satisfy all requirements simultaneously.

The Shared Foundation: Controls That Satisfy Every Framework

Before addressing framework-specific requirements, implement this shared control set. These controls appear in SOC 2, HIPAA, ISO 27001, NIST CSF, and PCI DSS. Building them once satisfies requirements across all five.

Identity and Access Management

Every framework requires restricting access to systems and data based on job function, and verifying who is accessing what.

[ ] Unique user accounts for every person (no shared credentials, no group logins)
[ ] Multi-factor authentication (MFA) enforced on all systems that store or process sensitive data
[ ] Role-based access control (RBAC): access permissions defined by job function, not individual request
[ ] Formal access provisioning process: access granted only after manager approval, documented
[ ] Access deprovisioning within 24 hours of role change or termination
[ ] Quarterly access reviews: review all user accounts, remove unnecessary access, document decisions
[ ] Privileged access (admin rights) restricted to named individuals with a documented business need
[ ] Privileged access reviewed monthly or more frequently
[ ] Service accounts (non-human accounts) inventoried and reviewed quarterly

Data Protection and Encryption

Encrypting data at rest and in transit is a baseline requirement across all five frameworks.

[ ] All sensitive data encrypted at rest using AES-256 or equivalent
[ ] All data transmission encrypted using TLS 1.2 or higher
[ ] Encryption keys managed separately from encrypted data
[ ] Key rotation policy documented and implemented (annual minimum)
[ ] Data classification policy: data categorized by sensitivity level (public, internal, confidential, restricted)
[ ] Sensitive data inventory: documented record of where sensitive data is stored, processed, and transmitted
[ ] Secure data disposal procedures: data sanitized or destroyed when no longer needed, with documentation

Risk Management

Every framework requires a formal process for identifying, evaluating, and treating security risks.

[ ] Annual risk assessment conducted and documented
[ ] Risk register maintained: threats, vulnerabilities, likelihood, impact, and treatment decisions recorded
[ ] Risk treatment plans assigned to owners with target completion dates
[ ] Risk assessment methodology documented (consistent scoring across assessments)
[ ] Risk tolerance/acceptance criteria defined and approved by leadership

Vulnerability Management

Identifying and fixing vulnerabilities before attackers exploit them is a universal requirement.

[ ] Asset inventory: all hardware, software, and cloud resources documented
[ ] Automated vulnerability scanning of all in-scope systems, at minimum monthly
[ ] Critical and high vulnerabilities remediated within 30 days of discovery
[ ] Penetration testing conducted annually by a qualified external firm
[ ] Patch management policy: patch timelines defined by severity level, compliance tracked
[ ] Software composition analysis (SCA) for third-party libraries in your codebase

Security Monitoring and Logging

Detecting and investigating security events requires centralized, tamper-resistant logs.

[ ] Logging enabled on all in-scope systems: authentication events, admin actions, data access, errors
[ ] Logs centralized in a SIEM or log management platform (Splunk, Datadog, AWS CloudWatch, etc.)
[ ] Log retention for minimum 12 months (90 days hot/accessible, 12 months total)
[ ] Automated alerts for: failed login attempts, privilege escalation, large data exports, admin account usage
[ ] Log integrity controls: logs stored in a location where the system being monitored cannot modify them
[ ] Security monitoring reviewed daily or via automated alerting

Incident Response

Every framework requires a documented process for detecting, containing, and recovering from security incidents.

[ ] Incident response plan documented with: severity definitions, roles, escalation paths, communication procedures
[ ] Incident response plan tested annually (tabletop exercise at minimum)
[ ] Security incidents logged and tracked to closure with root cause documented
[ ] Customer/regulator notification procedures defined (including required timeframes)
[ ] Post-incident review process: lessons learned documented and fed back into controls

Vendor and Third-Party Management

Supply chain risk is addressed by every major framework, and became a prominent focus after high-profile supply chain attacks.

[ ] Complete inventory of all vendors with access to your systems or data
[ ] Security assessment process for critical vendors before onboarding
[ ] Contractual security requirements (security clauses, right-to-audit) in vendor agreements
[ ] Annual vendor security reviews documented
[ ] Vendor breach notification requirements included in contracts
[ ] Software supply chain: source code dependencies reviewed for known vulnerabilities

Security Awareness Training

Human error remains the leading cause of security incidents. Every framework requires employee training.

[ ] Annual security awareness training for all employees with completion tracking
[ ] Phishing simulation exercises conducted at least quarterly
[ ] Role-specific training for high-risk roles: developers (secure coding), IT admins (privileged access), executives (social engineering)
[ ] New employee security training included in onboarding within first 30 days
[ ] Training content updated annually to reflect current threat landscape

Business Continuity and Disaster Recovery

Ensuring operations can continue after a disruption is a shared requirement across all frameworks.

[ ] Business continuity plan (BCP) documented
[ ] Disaster recovery plan (DRP) documented with Recovery Time Objective (RTO) and Recovery Point Objective (RPO)
[ ] Automated, encrypted backups with defined retention periods
[ ] Backup restoration tested at least annually, results documented
[ ] Critical system recovery procedures tested annually
[ ] BCP/DRP reviewed and updated annually

Physical Security

Physical access controls appear in every framework, though cloud-native companies can largely satisfy this via their infrastructure provider's SOC 2/ISO 27001 reports.

[ ] Physical access to facilities housing sensitive systems is restricted and logged
[ ] Visitor access procedures documented and enforced
[ ] Clean desk policy: sensitive data not left unattended
[ ] For cloud-only companies: document reliance on AWS/GCP/Azure physical security controls and retain copies of their compliance reports

Framework-Specific Additions

The following controls are required by specific frameworks and are not fully covered by the shared foundation above.

HIPAA-Specific Requirements

HIPAA is administered by the U.S. Department of Health and Human Services (HHS) and enforced through the Office for Civil Rights (OCR). Penalties range from $100 to $50,000 per violation, with a maximum of $1.9 million per violation category per year.

Administrative Safeguards:

[ ] Designated HIPAA Privacy Officer and Security Officer
[ ] Workforce authorization procedures: formal process for granting access to PHI
[ ] Sanction policy: documented consequences for employees who violate HIPAA
[ ] Privacy practices notice (NPP) provided to patients, posted publicly
[ ] Business Associate Agreements (BAAs) executed with every vendor that handles PHI

Technical Safeguards:

[ ] Automatic logoff from systems containing PHI after a defined period of inactivity
[ ] Encryption and decryption of PHI documented as an addressable standard (required if risk assessment determines it is reasonable and appropriate)
[ ] Audit controls: hardware, software, and procedural mechanisms to examine access to ePHI
[ ] Person or entity authentication: procedures to verify the identity of users accessing ePHI

Physical Safeguards:

[ ] Workstation use policies: documented rules for appropriate use of devices that access PHI
[ ] Device and media controls: procedures for the disposition of electronic media containing PHI
[ ] Facility access controls: procedures to limit physical access to electronic information systems

Breach Notification:

[ ] Breach notification procedure for patients within 60 days of discovery
[ ] HHS notification: breaches affecting 500+ individuals require notice to HHS within 60 days; smaller breaches reported annually
[ ] Media notification for breaches affecting 500+ individuals in a state or jurisdiction

PCI DSS-Specific Requirements

PCI DSS is maintained by the PCI Security Standards Council (PCI SSC). Version 4.0.1 is the current standard as of 2026. Requirements vary by merchant level based on annual transaction volume.

Network Security:

[ ] Network segmentation: cardholder data environment (CDE) isolated from other network segments
[ ] Firewall rules documented, reviewed quarterly, and restricting inbound and outbound traffic to the CDE
[ ] No direct public internet access to any system in the CDE
[ ] Wireless network security: WPA3 or WPA2-Enterprise on all wireless networks in scope

Payment Card Data:

[ ] Primary Account Numbers (PANs) masked when displayed (show only last four digits)
[ ] PANs encrypted at rest using strong cryptography
[ ] Cardholder data retention policy: retain only what is legally required, purge the rest
[ ] Prohibition on storing sensitive authentication data (CVV, PIN) after authorization

Application Security:

[ ] Web application firewall (WAF) deployed in front of public-facing web applications
[ ] Secure software development lifecycle (SDLC) with security testing before production deployment
[ ] Annual code review or application penetration test for custom code in the CDE

Monitoring:

[ ] File integrity monitoring (FIM) on critical system files in the CDE
[ ] Daily log review for all CDE systems (automated or manual)

ISO 27001-Specific Requirements

ISO 27001 from the International Organization for Standardization (ISO) requires certification by an accredited certification body. The 2022 revision (ISO/IEC 27001:2022) restructured the Annex A controls into four themes and 93 controls.

Statement of Applicability (SoA):

[ ] Statement of Applicability prepared: all Annex A controls listed, each marked as applicable or not with justification

Information Security Management System (ISMS):

[ ] ISMS scope formally defined and documented
[ ] Information security policy approved by top management
[ ] Information security objectives established and tracked
[ ] Internal ISMS audit conducted annually
[ ] Management review of the ISMS conducted annually
[ ] Continual improvement process documented

ISO 27001:2022 New Controls (not covered by shared foundation):

[ ] Threat intelligence: process for gathering and analyzing threat intelligence relevant to your organization
[ ] Information security for cloud services: formal policy and controls for cloud service use
[ ] ICT readiness for business continuity: technology-specific continuity requirements documented
[ ] Physical security monitoring: monitoring of physical perimeter and sensitive areas
[ ] Configuration management: formally documented and enforced configuration baselines
[ ] Information deletion: procedures for secure deletion meeting legal and contractual requirements
[ ] Data masking: masking of sensitive data in non-production environments
[ ] Web filtering: controls to restrict access to malicious or inappropriate external websites

NIST CSF 2.0-Specific Requirements

NIST CSF 2.0, released in 2024, introduced a sixth function, Govern, alongside the original five: Identify, Protect, Detect, Respond, and Recover.

Govern (new in CSF 2.0):

[ ] Cybersecurity risk governance structure: roles, responsibilities, and accountability for cybersecurity decisions formally defined
[ ] Organizational cybersecurity strategy documented and approved by leadership
[ ] Cybersecurity risk integrated into enterprise risk management (ERM) processes
[ ] Cybersecurity supply chain risk management (C-SCRM) program formally established

Identify:

[ ] Business environment analysis: critical business functions, dependencies, and supporting assets documented
[ ] Cybersecurity risk tolerance defined and communicated to stakeholders

Protect:

[ ] Data security controls implemented and tested for effectiveness
[ ] Protective technology deployed (endpoint detection and response, email security, network segmentation)

Detect:

[ ] Anomalies and events: baselines of normal network activity established; deviations trigger investigation
[ ] Detection processes tested for effectiveness

Respond:

[ ] Response planning: incident response plan aligned to NIST SP 800-61
[ ] Communications: information sharing with law enforcement, ISACs, or relevant government agencies defined

Recover:

[ ] Recovery planning: documented recovery procedures for critical systems
[ ] Improvements: recovery lessons learned fed back into risk management and response plans

Mapping Controls Across Frameworks

When you implement these controls as an integrated program rather than separate projects, the efficiency gains are significant. Here is where the major overlaps fall:

| Control Area | SOC 2 | HIPAA | ISO 27001 | NIST CSF | PCI DSS | |---|---|---|---|---|---| | Access Controls | Required | Required | Required | Required | Required | | Encryption | Required | Required | Required | Required | Required | | Risk Assessment | Required | Required | Required | Required | Required | | Incident Response | Required | Required | Required | Required | Required | | Vulnerability Mgmt | Required | Addressable | Required | Required | Required | | Security Training | Required | Required | Required | Required | Required | | Vendor Mgmt | Required | Required | Required | Required | Required | | Business Continuity | Required | Required | Required | Required | Required | | Audit Logging | Required | Required | Required | Required | Required |

Controls that are unique to individual frameworks, such as HIPAA's BAA requirements, PCI DSS's network segmentation around the CDE, or ISO 27001's formal ISMS documentation structure, represent approximately 30 to 40% of each framework's total requirements.

Building an Integrated Compliance Program

The most cost-effective approach for organizations subject to multiple frameworks is a unified control set with framework-specific extensions, rather than separate compliance programs running in parallel.

Start with the shared foundation above. This satisfies the majority of requirements across all five frameworks. Then layer in the framework-specific additions relevant to your situation.

Document each control once, with annotations that map it to the specific requirement IDs in each applicable framework (e.g., SOC 2 CC6.1, HIPAA 164.312(a)(1), ISO 27001 Annex A 8.2, NIST CSF PR.AC-1, PCI DSS Requirement 7). This cross-reference documentation simplifies audits and prevents redundant evidence collection.

GRC platforms such as secureframe/">Drata, Vanta, Secureframe, and LogicGate support multi-framework mapping and can help automate evidence collection for overlapping controls. For organizations managing three or more frameworks, the efficiency gains from a GRC platform typically justify the subscription cost.

Frequently Asked Questions

What is the difference between a compliance framework and a security certification? A framework is a structured set of guidelines and best practices, such as NIST CSF, which is voluntary for most organizations and does not result in a credential. A certification or attestation involves a formal third-party review and produces a document you can share: SOC 2 produces an auditor's report, ISO 27001 produces a certificate from an accredited registrar, and PCI DSS produces a Report on Compliance (ROC) or Self-Assessment Questionnaire (SAQ). HIPAA compliance is verified through OCR audits or enforcement actions, not a certificate. The distinction matters for what you can show customers or regulators.

Can implementing one framework reduce the effort to achieve another? Substantially, yes. SOC 2 and ISO 27001 share approximately 70 to 80% of their control requirements. Companies that have achieved SOC 2 Type 2 can typically achieve ISO 27001 certification with 20 to 30% additional effort. HIPAA shares significant overlap with both. PCI DSS has the most unique requirements because of its focus on the cardholder data environment, but still overlaps heavily on access control, logging, and vulnerability management. Building with the shared foundation in mind from the start is the single highest-leverage decision for organizations pursuing multiple frameworks.

How often do compliance frameworks get updated and what happens to our certification? Major frameworks update every 3 to 7 years. When a new version releases, certification bodies and auditors typically define a transition period (usually 1 to 3 years) during which organizations can continue operating under the old version before being required to transition. PCI DSS 4.0 required transition by March 2025. ISO 27001:2022 required transition by October 2025. NIST CSF 2.0 released in 2024 with no mandatory deadline for private sector organizations. SOC 2 is continuously updated by the AICPA through Trust Services Criteria revisions. Monitoring framework updates is a continuous compliance responsibility.

What is the fastest framework to achieve compliance with? SOC 2 Type 1 is typically the fastest formal third-party attestation, achievable in 3 to 6 months for a well-prepared organization. NIST CSF has no certification process and can be self-assessed immediately. PCI DSS compliance can be achieved in 3 to 6 months for merchants with a narrow, well-defined cardholder data environment. HIPAA has no certification timeline, as it requires continuous operational compliance. ISO 27001 certification typically requires 6 to 18 months due to the formal Stage 1 and Stage 2 audit process required by accredited registrars.

Do small businesses need to comply with these frameworks? It depends on your industry, customers, and data. Size does not exempt you from legal requirements: a 5-person medical practice is subject to HIPAA, and a small e-commerce company that accepts card payments is subject to PCI DSS (typically at a lower validation level). For voluntary frameworks like SOC 2 and ISO 27001, the relevant question is whether your customers require them. Enterprise B2B customers commonly require SOC 2 regardless of vendor size. Small businesses should prioritize the shared control foundation above because it reduces their risk profile even if formal certification is not immediately required.