9 min read

Section 07

Risk Assessment Frameworks

Frameworks provide structured, repeatable processes for conducting risk assessments. This section covers the major frameworks in depth — their processes, outputs, strengths, and when to use each one. Use the decision tree at the end to select the right framework for your TRA engagement.

Framework Comparison

Framework Effort Main Output Best Regulatory Fit Tool Support
NIST 800-30 Medium Risk assessment report with semi-quantitative scores FISMA, FedRAMP, NIST CSF Medium (CSRC templates)
NIST RMF High Authorization to Operate (ATO) package FISMA, FedRAMP, DoD High (eMASS, OSCAL)
ISO 27005:2022 Medium Risk treatment plan aligned to ISO 27001 ISO 27001, GDPR, SOX Medium (GRC platforms)
OCTAVE Allegro Low-Medium Asset-centric risk profiles with worksheets General (any regulation) Low (worksheet-based)
CORAS Medium UML-based risk models and threat diagrams EU, safety-critical systems Low (CORAS tool, Eclipse)
TARA Medium Threat matrix with countermeasure mapping Defense, critical infrastructure Medium (MITRE tools)

NIST SP 800-30 Rev 1

The most widely referenced risk assessment guide for information systems. Defines a four-phase process with detailed guidance on threat source identification, vulnerability analysis, likelihood and impact determination.

NIST 800-30 Process

Phase 1: Prepare

  • • Purpose: Why the assessment is being conducted (new system, periodic review, incident response)
  • • Scope: System boundaries, inherited controls, shared services
  • • Assumptions: Threat environment, trust relationships, data sensitivity levels
  • • Risk model: Qualitative (L/M/H), semi-quantitative (1-100), or quantitative (FAIR)
  • • Sources: Identify information sources — architecture docs, prior assessments, CTI, scanning results

Phase 2: Conduct

Task 1: Identify Threat Sources. Categorize using NIST's taxonomy: adversarial (individuals, groups, nations), accidental (user errors), structural (equipment failure), environmental (natural disasters).

Task 2: Identify Threat Events. Map threat sources to specific threat events relevant to the system. Use ATT&CK and industry-specific catalogs from Section 03.

Task 3: Identify Vulnerabilities. Map conditions that could be exploited — technical vulnerabilities, process weaknesses, architectural gaps.

Task 4: Determine Likelihood. Assess based on threat source capability, intent, targeting, and vulnerability severity. Use the NIST likelihood scale (Very Low to Very High).

Task 5: Determine Impact & Risk. Combine likelihood and impact into a risk determination. Document in the risk assessment results table.

Phase 3: Communicate

Present results to decision-makers with risk-ranked findings, recommended responses, and a risk register. Tailor communication level to audience (technical team vs executives vs governance board).

Phase 4: Maintain

Monitor risk factors for changes, update the assessment when triggers occur (new threats, control changes, architectural updates, incidents). Define review cadence and change triggers.

NIST RMF (SP 800-37 Rev 2)

The Risk Management Framework is a comprehensive lifecycle approach for federal information systems. While 800-30 focuses on assessment, RMF covers the full lifecycle from categorization to continuous monitoring.

NIST RMF Lifecycle

RMF + OSCAL = Automation

The Open Security Controls Assessment Language (OSCAL) enables machine-readable RMF artifacts. System Security Plans, assessment results, and POA&Ms can all be expressed as structured JSON/XML and validated automatically — essential for continuous ATO (cATO) programs.

ISO 27005:2022

The 2022 revision of ISO 27005 aligns with ISO 27001:2022 and provides guidance for risk assessment within an Information Security Management System (ISMS). Key update: shifted from asset-based to event-based approach as the primary option.

Event-Based Approach (New Default)

  • • Starts from operational risk scenarios
  • • "What can go wrong?" perspective
  • • Maps events to business impact
  • • Better alignment with enterprise risk management
  • • More natural for stakeholder communication

Asset-Based Approach (Legacy)

  • • Starts from asset inventory
  • • Identifies threats per asset, then vulnerabilities
  • • More thorough for technical environments
  • • Better for detailed control mapping
  • • Can be combined with event-based approach

OCTAVE Allegro

OCTAVE Allegro (developed by CMU/SEI) is a lightweight, asset-centric approach designed for organizations without dedicated risk management teams. Uses structured worksheets.

octave-allegro-process.txt 
OCTAVE Allegro — 8-Step Process
════════════════════════════════

Step 1: Establish Risk Measurement Criteria
  → Define impact areas: financial, reputation, productivity,
    safety, regulatory, customer
  → Set scoring scales (1-3 Low/Med/High per area)
  → Weight impact areas by organizational priority

Step 2: Develop Information Asset Profile
  → Identify critical information assets
  → Document: owner, custodians, security requirements
  → Define CIA requirements for each asset

Step 3: Identify Information Asset Containers
  → Where is the asset stored, transported, processed?
  → Technical containers: databases, file shares, apps
  → Physical containers: paper records, removable media
  → People containers: who has knowledge/access

Step 4: Identify Areas of Concern
  → Brainstorm threats to each container
  → Use structured scenarios: actor + motive + outcome
  → Cover: deliberate, accidental, system failure, natural

Step 5: Identify Threat Scenarios
  → Formalize concerns into detailed threat scenarios
  → Map each scenario to affected assets and containers
  → Document preconditions and attack paths

Step 6: Identify Risks
  → For each scenario: determine impact on each impact area
  → Calculate risk score = Likelihood × Impact
  → Document in risk register worksheet

Step 7: Analyze Risks
  → Rank risks by score across all scenarios
  → Identify risk clusters and patterns
  → Flag risks exceeding organizational risk criteria

Step 8: Select Mitigation Approach
  → For each significant risk: mitigate, transfer, accept, avoid
  → Document rationale for treatment decision
  → Define specific mitigation actions and owners

CORAS & TARA

CORAS

Model-driven risk analysis using UML-style diagrams. Strong in safety-critical and embedded systems.

  • • Uses specialized UML diagrams for risk modeling
  • • Graphical threat and risk analysis
  • • Workshop-facilitated with structured diagramming
  • • Strong traceability from assets to threats to controls
  • • Popular in European automotive and aerospace
  • • Open-source CORAS tool (Eclipse-based)

TARA

MITRE's Threat Assessment & Remediation Analysis. Systematic countermeasure selection.

  • • Catalogs TTPs from MITRE ATT&CK
  • • Systematic countermeasure identification
  • • Cost-benefit analysis for each countermeasure
  • • Outputs a prioritized countermeasure list
  • • Used in defense and critical infrastructure
  • • Integrates with MITRE tooling ecosystem

Framework Selection Guide

Framework Selection Decision Tree

Section Summary

Key Takeaways

  • • NIST 800-30 is the most widely referenced — 4-phase process (Prepare/Conduct/Communicate/Maintain)
  • • NIST RMF is the full lifecycle for federal systems, producing ATO packages
  • • ISO 27005:2022 now favors event-based over asset-based approach
  • • OCTAVE Allegro is lightweight and worksheet-based — good for smaller teams
  • • Select frameworks based on regulatory context, org size, and required output

Next Steps

Evidence to Capture

The artefact is a framework-conformant assessment: the required steps recorded, the input behind each rating, and the mapping from finding to framework output.

Framework and revision: The framework and the revision applied. Guidance between revisions is not interchangeable, and assessors and auditors ask which one was used.

Required inputs and their sources: For each step the framework mandates — threat source, vulnerability, likelihood, impact — the input used and where it came from.

Scale definitions as applied: What makes a likelihood likely under the scale you used. Each framework defines its own scales and they are not comparable across frameworks.

Output mapping: Findings mapped to the framework output: register entry, authorisation package, treatment plan or threat matrix row, with the identifier for each.

Assessor and approver: Who performed the assessment, who reviewed it for quality, and who accepted the result, with dates.

Tailoring decisions: Where the framework was adapted and why, recorded so the deviation is deliberate rather than discovered during an audit.

Framework False Positives

Following a framework produces compliant artefacts. It does not guarantee that what came out is a risk.

  • Framework output relabelled as risk: A control deficiency or an authorisation finding is not a risk until an event and a consequence are named against an asset.
  • Non-compliance as risk: A non-compliant rating states a requirement gap and says nothing about likelihood or impact in this environment.
  • Scores compared across frameworks: A relative score from one method and a semiquantitative rating from another do not share a scale. Presenting them side by side implies a comparison that does not exist.
  • Completed worksheets: Every row filled is not the same as a system analysed. A fully populated template with unsourced inputs is still an unassessed system.
  • Inherited authorisation as coverage: An authorisation package covers the boundary it was issued for. Components added inside that boundary are not automatically assessed.
  • Mandated category with no element: A category the framework requires, with nothing applicable in the architecture, is documented as not applicable rather than counted as a finding.

Framework Treatment and Review Cycle

Treatment plus the framework review cycle: apply the treatment step the framework prescribes, then reopen when the framework, the scope or the authorisation boundary changes.

Follow the treatment step

  • • Map each risk to the treatment option the framework defines: reduce, retain, avoid or share
  • • Record residual risk against the framework acceptance authority
  • • Keep the evidence trail the framework requires for audit

Keep the mapping maintainable

  • • Store the input-to-rating trace so a revision can be re-scored rather than rewritten
  • • Record scale definitions inside the assessment, not in a document that drifts away from it
  • • Document tailoring per assessment

Review trigger

  • • Framework revision published
  • • Change to the authorisation boundary or system category
  • • An auditor or reviewer disputes an input