Compliance Risk Analysis 2026: Framework-Specific Methodology

Last updated: 2026-06-19 — ComplianceStack Editorial Team

A compliance risk analysis is not a checkbox — it is the foundational activity that determines where to allocate limited resources, which controls matter most, and what regulators will ask about first when they arrive. The OCR, SEC, DPC, and OSHA all require documented risk assessments as a precondition for demonstrating compliance. Without one, you cannot show that your controls are "reasonable and appropriate" — the legal standard for most frameworks. This guide covers how to conduct a risk analysis that satisfies regulatory requirements across HIPAA, SOX, GDPR, OSHA, and SEC/FINRA, including the methodological differences between frameworks and how to produce a prioritized risk register that drives resource allocation.

What Is a Compliance Risk Analysis?

A compliance risk analysis is a structured assessment that identifies regulatory requirements, evaluates the likelihood and impact of non-compliance, and produces a prioritized list of risks that drive your compliance program. Unlike a gap assessment (which compares your current state to a standard), a risk analysis asks: "What could go wrong, how bad would it be, and how likely is it?"

The regulatory basis varies by framework. HIPAA requires a "risk analysis" as a standalone required implementation specification under 45 CFR 164.308(a)(1)(ii)(A). SOX requires documented risk assessment as part of the internal control environment under the COSO framework. GDPR requires a "data protection impact assessment" (DPIA) for high-risk processing under Article 35. OSHA requires a "hazard assessment" under 29 CFR 1910.132(d). Each has a specific scope and documentation requirement — but the underlying methodology is similar.

The output is a risk register: a prioritized list of risks, each rated by likelihood and impact, with mitigation plans for the highest-priority items.

HIPAA Risk Analysis: 45 CFR 164.308(a)(1)(ii)(A)

HIPAA requires a risk analysis that covers all ePHI flows — where it is created, received, maintained, or transmitted. The scope includes electronic information systems and any paper records that contain ePHI. OCR expects organizations to identify:

Threats and vulnerabilities — reasonably anticipated threats to the confidentiality, integrity, or availability of ePHI.

Probability of occurrence — how likely each threat/vulnerability combination is to actually cause a breach.

Impact — the potential harm to individuals, including the scale of the breach (number of records) and the sensitivity of the data.

Required elements (per OCR guidance): evaluation of the anticipated probability and potential impact of each threat; determination of security measures necessary to reduce risk; documentation of decisions and rationale; periodic review and update.

OCR enforces this by looking for the actual document, not a template. Templates that have not been customized to your specific ePHI flows fail OCR scrutiny — the agency looks for specificity in threat identification, analysis methodology, and resulting risk decisions.

SOX Risk Assessment: ICFR Framework

SOX Section 404 and the SEC's related rules require management to assess the effectiveness of internal control over financial reporting (ICFR). The COSO Internal Control — Integrated Framework (2013) is the standard for this assessment, and it explicitly requires a risk assessment as a component.

The SOX risk assessment has two layers:

Entity-level controls — risks that affect the overall financial reporting, including economic conditions, regulatory changes, management turnover, and IT general controls.

Process-level controls — risks that affect specific account balances and disclosures, including transaction-level threats to accuracy, completeness, and cutoff.

Management must identify the risks that could result in material misstatement, evaluate the design and operating effectiveness of controls that address those risks, and document the conclusions. PCAOB Auditing Standard 1116 (AS 1116) specifically requires auditors to evaluate management's risk assessment process, including how management identifies risks, assesses their significance, and determines how to respond.

Key risk categories for SOX ICFR: revenue recognition (ASC 606), allowance for credit losses, goodwill and intangible asset impairment, inventory obsolescence, contingent liabilities, related party transactions, IT general controls over financial reporting systems.

GDPR Data Protection Impact Assessment: Article 35

GDPR Article 35 requires a data protection impact assessment (DPIA) when processing is "likely to result in a high risk to the rights and freedoms of natural persons." The EDPB maintains a list of processing operations requiring DPIA — which includes systematic profiling with legal effects, large-scale processing of special category data, and public area surveillance.

A DPIA must include: a systematic description of processing operations and purposes; an assessment of necessity and proportionality; a full analysis of risks to data subjects; the measures planned to address risks, including safeguards and security measures.

The DPIA must be conducted before processing begins. If the DPIA identifies risks that cannot be mitigated, you must consult the supervisory authority before proceeding. The authority has eight weeks to respond (extendable).

For US companies, GDPR applies if you offer goods or services to EU data subjects (even for free) or monitor their behavior. The threshold for "high risk" is interpreted broadly by many DPAs — any systematic processing of personal data with potential for significant effect likely requires a DPIA.

OSHA Hazard Assessment: 29 CFR 1910.132(d)

OSHA requires employers to conduct a hazard assessment to determine the PPE needed to protect employees. The assessment must document the workplace hazards or operations that require PPE, and the PPE selected for each hazard.

The assessment must be updated when operations change. A one-time assessment that does not reflect current operations fails the standard.

Key documentation requirements: written certification that the assessment was performed; identification of the hazards; identification of the PPE required for each hazard; certification of employee training on proper PPE use.

OSHA enforcement uses the hazard assessment as a starting point — if the assessment is missing, inadequate, or not followed by employees, citations follow. OSHA's inspection protocol includes interviews about PPE training and observation of actual employee use. Compliance requires both written documentation and demonstrated execution.

How to Build a Risk Register

A risk register is the output of your risk analysis — a structured document that lists each identified risk, its probability and impact, and the controls that mitigate it.

Step 1: Identify assets and threats — List all systems, processes, and data that are in scope. For each, identify the threats that could exploit vulnerabilities. Use regulatory guidance, industry incident reports, and your own audit findings.

Step 2: Assess probability — Rate each threat/vulnerability combination on a scale (1=remote, 5=near certain). Consider: has this happened in your industry? Has it happened to you? What controls are in place to prevent it?

Step 3: Assess impact — Rate the potential impact on a scale (1=negligible, 5=catastrophic). Consider: financial cost, regulatory exposure, operational disruption, reputational harm, and legal liability.

Step 4: Calculate risk score — Multiply probability by impact (P × I = Risk Score). Prioritize risks by score. A score above 15 is typically critical; above 8 is high; above 4 is medium.

Step 5: Identify mitigation controls — For each high-priority risk, identify the controls that reduce probability, impact, or both. Document who is responsible, what the control looks like, and when it was implemented.

Step 6: Review and update — Risk registers go stale. Regulatory changes, new systems, and incident findings all shift the risk landscape. Quarterly reviews are minimum; annual full updates are required by most frameworks.

Common Risk Analysis Mistakes

Generic templates — A risk analysis that says "hacker attacks" without identifying which systems, what data is at risk, and how the attack vector works will not satisfy OCR, SEC, or any other regulator. The analysis must be specific to your environment.

Treating compliance as binary — Risk is not "compliant" or "not compliant." Many organizations check boxes on a gap assessment without actually understanding whether their controls are effective in reducing risk. A control can be "in place" but ineffective.

Ignoring emerging risks — AI tools, third-party integrations, and remote work create new threat vectors that are not in the old templates. Your risk analysis must account for the actual technology environment, not just the compliance infrastructure.

Documentation gaps — Regulators rarely accept "we did it but did not document it." Every assessment decision, every control choice, every review cycle must be documented with date, name, and reasoning.

Missing the scope boundary — HIPAA risk analyses that omit systems receiving ePHI from third parties, SaaS vendors, or cloud providers will fail OCR audits. The scope must include all ePHI flows, not just your own servers.

undefined

undefined

undefined

More Multi-framework Resources

Assess Risk Now →
Free compliance alerts — join 13,000+ professionals ✓ You're in!