SOC 2 (System and Organization Controls 2) is an auditing framework developed by the AICPA (American Institute of Certified Public Accountants). It is not government legislation or a certification scheme but a voluntary attestation standard — however, it has become a de facto market requirement for any technology company, cloud service provider, or SaaS vendor serving enterprise customers, particularly in the US. A SOC 2 report is produced by an independent CPA firm that evaluates an organization’s controls against the AICPA’s Trust Services Criteria (TSC), organized in five categories: Security (mandatory for all SOC 2 reports, covering Common Criteria CC1–CC9), Availability, Processing Integrity, Confidentiality, and Privacy (each optional depending on the organization’s services and customer commitments). The Common Criteria (CC1–CC9) are derived from the COSO Internal Control Framework and cover control environment, risk assessment, monitoring, logical/physical access, system operations, change management, and risk mitigation. There are two report types: Type I (evaluates control design at a point in time) and Type II (evaluates both design and operating effectiveness over 6–12 months — the standard enterprise customers demand). SOC 2 reports are restricted-use documents shared with customers under NDA. While not legally mandatory, major enterprises, financial institutions, and regulated industries routinely require SOC 2 Type II reports from their vendors before signing contracts, making it an essential market-access requirement for technology service providers.
NIST Special Publication 800-53 is published by the National Institute of Standards and Technology (NIST), a US federal agency within the Department of Commerce. The current version is Revision 5 (September 2020, updated December 2020), which defines over 1,000 security and privacy controls organized in 20 control families (Access Control, Audit and Accountability, Configuration Management, Incident Response, System and Communications Protection, Supply Chain Risk Management, etc.). NIST 800-53 is mandatory for US federal agencies and their contractors under FISMA (Federal Information Security Modernization Act) and serves as the control baseline for FedRAMP (cloud), CMMC (defense contractors), and many state/local government programs. Beyond the US, it is widely adopted internationally as a comprehensive reference catalog — organizations in finance, healthcare, and critical infrastructure worldwide use NIST 800-53 as their control framework. The standard defines three baselines (Low, Moderate, High) corresponding to the potential impact of a security breach. NIST 800-53 is not a certification itself but the control catalog against which systems are assessed; formal authorization (ATO — Authority to Operate) is granted by an authorizing official after an assessor verifies control implementation using NIST SP 800-53A assessment procedures. The companion OSCAL (Open Security Controls Assessment Language) standard, also from NIST, provides machine-readable formats for expressing 800-53 controls and assessment results.
The Health Insurance Portability and Accountability Act (HIPAA) is a United States federal law enacted in 1996 and enforced by the Department of Health and Human Services (HHS) Office for Civil Rights (OCR). HIPAA is not a voluntary standard or certification — it is mandatory US law with civil and criminal penalties for non-compliance (fines up to $1.5M per violation category per year, and criminal penalties including imprisonment). HIPAA applies to covered entities (health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically) and their business associates (any entity that creates, receives, maintains, or transmits Protected Health Information — PHI — on behalf of a covered entity). The law’s security requirements are defined primarily in two rules: the Privacy Rule (what PHI can be used and disclosed) and the Security Rule (administrative, physical, and technical safeguards required to protect electronic PHI — ePHI). Key technical requirements include access controls, audit controls, integrity controls, transmission security (encryption), and contingency planning. Unlike prescriptive standards (like CIS or DISA STIG), HIPAA’s Security Rule is flexible and scalable — it defines required outcomes but allows organizations to determine the specific technologies used. The Breach Notification Rule requires reporting unauthorized disclosures to HHS and affected individuals within 60 days. HIPAA has no “certification” — compliance is demonstrated through documented risk assessments, policies, and technical controls.
FIPS 140 (Federal Information Processing Standard, Publication 140) is the US and Canadian government standard that defines security requirements for cryptographic modules — the hardware, software, or firmware components that perform cryptographic operations (encryption, decryption, hashing, signing, key management). It is published by NIST (National Institute of Standards and Technology) and jointly administered with CCCS (Canadian Centre for Cyber Security) through the Cryptographic Module Validation Program (CMVP). The standard has two active versions: FIPS 140-2 (published 2001, no longer accepting new submissions since April 2022) and FIPS 140-3 (effective September 2020, the current standard for all new validations). FIPS 140-2 certificates remain valid until 21 September 2026, after which they move to the Historical list — meaning only FIPS 140-3 validated modules will be accepted for new federal procurements. FIPS 140 defines four security levels (Level 1 through Level 4), with Level 1 being the baseline for software modules and Level 4 requiring physical tamper-active hardware. Compliance is mandatory for all US federal agencies and their contractors under FISMA, for Canadian federal systems, and is widely adopted by regulated industries (finance, healthcare, critical infrastructure) globally. Non-validated cryptography is treated as providing no protection — effectively plaintext — regardless of the algorithm strength. Validation is a formal, lab-based process: vendors submit modules to accredited Cryptographic and Security Testing (CST) laboratories, which test against the standard and submit results to CMVP for certificate issuance.
The Federal Risk and Authorization Management Program (FedRAMP) is a US government-wide program, codified into law by the FedRAMP Authorization Act of 2022, that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services used by federal agencies. FedRAMP is administered by the General Services Administration (GSA) and is mandatory — any cloud service (SaaS, PaaS, IaaS) that stores, processes, or transmits federal data or metadata must achieve FedRAMP authorization before it can be used by US government agencies or their contractors. The program defines three impact levels: Low (limited adverse effect), Moderate (serious adverse effect), and High (severe or catastrophic effect — applies to law enforcement, emergency, financial, and health systems). Each level maps to NIST SP 800-53 Rev 5 control baselines: FedRAMP High requires implementation of approximately 421 controls. Authorization is achieved through either an Agency ATO (a specific agency sponsors the assessment) or the newer FedRAMP 20-X experimental accelerated path. Once authorized, cloud service providers (CSPs) must maintain continuous monitoring — monthly vulnerability scans, annual penetration testing, and Plan of Action & Milestones (POA&M) reporting — or risk revocation. Authorized services are listed on the FedRAMP Marketplace.
DISA STIGs (Security Technical Implementation Guides) are published by the Defense Information Systems Agency (DISA), the US Department of Defense (DoD) agency responsible for IT infrastructure security standards. STIGs provide extremely prescriptive, line-item security configuration requirements for specific technology products — each STIG contains hundreds of individual “findings” (rules) specifying exact settings, permissions, and configurations required to harden a system. Unlike flexible frameworks (NIST 800-53) or guideline-oriented benchmarks (CIS), STIGs are mandatory for all DoD information systems and are referenced by the broader US federal government, defense contractors (via CMMC), and intelligence community systems. Each finding is categorized by severity: CAT I (high — failure could directly lead to loss of confidentiality, integrity, or availability), CAT II (medium), and CAT III (low). Systems must achieve full CAT I compliance and substantially address CAT II/III findings to receive an Authority to Operate (ATO). DISA publishes STIGs for hundreds of products and regularly updates them (typically quarterly). STIGs are developed in collaboration with the vendor — Red Hat, for instance, works directly with DISA to produce the RHEL STIG — and are made available to the public through DoD Cyber Exchange (public.cyber.mil). STIG compliance is verified using DISA’s STIG Viewer or automated tools like OpenSCAP that consume the machine-readable XCCDF/SCAP content.
