Auditen
Home / Frameworks / ISO 27001 / Risk assessment and risk treatment
ISO 27001 · Clause 6

Risk assessment and risk treatment

Clause 6 requires you to establish a formal process for identifying, analyzing, and evaluating information security risks. Once identified, you must decide how to handle these risks (treatment) and document which security controls from Annex A—or other sources—will be implemented to mitigate them.

What it means

The intent of this clause is to ensure that your security investments are based on actual threats rather than guesswork. Instead of implementing every possible security tool, you identify where your specific organization is vulnerable and prioritize resources toward the highest risks to confidentiality, integrity, and availability.

In practice, this means defining a consistent "risk appetite." You must decide what constitutes a "high" or "low" risk for your business so that assessments are objective and repeatable across different departments or systems.

Risk treatment is the actionable phase following the assessment. For every risk that exceeds your acceptable level, you must choose one of four paths: treat (apply controls), tolerate (accept the risk), terminate (stop the activity causing the risk), or transfer (e.g., insurance).

How to meet it

Evidence an auditor asks for

  • The Risk Assessment Methodology (the "rulebook" used to score risks).
  • The Risk Register or Risk Assessment Report showing identified risks and their calculated levels.
  • The Risk Treatment Plan (RTP) detailing the actions taken to mitigate high-priority risks.
  • The Statement of Applicability (SoA), signed and dated.
  • Records of management approval for risk acceptance (evidence that leadership knows which risks they are "tolerating").

Common pitfalls

  • Treating the assessment as a one-time project rather than a living process that is updated when the business changes.
  • Creating a Statement of Applicability that simply says "Yes" to all Annex A controls without documenting the actual justification or link to a risk.
  • Using overly complex scoring matrices that are too subjective for different staff members to use consistently.
  • Failing to document why certain controls were excluded from the SoA, which is a mandatory requirement of the standard.