Risk Assessment and Assurance Processes
This section covers Domain 4: risk assessment and assurance processes. The exam tests how application risk drives control selection, how validation produces evidence, and how assurance differs from compliance.
Core rules
Application security risk assessment considers the application's business context, data sensitivity, users, interfaces, threats and potential impact. Risk is typically evaluated as likelihood and impact, with organization-defined criteria from the ONF. The result determines which ASCs are selected, how strict they must be, and how much validation evidence is needed. Risk assessment is iterative: changes in architecture, data flows, suppliers or threat landscape trigger reassessment.
Assurance is justified confidence, based on evidence, that the application meets its security objectives. Validation is the process that generates and evaluates evidence that selected ASCs are implemented and effective. Evidence can include test results, configuration reviews, code analysis, audit records and operational monitoring. Assurance is not a yes-or-no certificate; it is a claim with scope, assumptions and limitations. ISO/IEC 27034-4 addresses application security validation, and Part 7 addresses an assurance prediction framework.
Worked example
A customer mobile app stores payment tokens. The team rates unauthorized token access as high impact and moderately likely. The ONF risk criteria require stronger controls for high-risk apps, so the ANF selects encryption at rest, tokenization, MFA for account changes and enhanced logging. Validation combines configuration review, penetration testing and log review. The resulting assurance claim states: within the tested release and defined threat model, selected ASCs were implemented and effective; residual risk is accepted by the business owner. The reasoning: risk sets control depth; validation supplies evidence; the claim records scope and residual risk.
Traps
Compliance with a checklist is not assurance; evidence of effectiveness is needed. Do not perform risk assessment once at project start and never revisit it. Do not treat validation as only final penetration testing; it spans the lifecycle. Do not state assurance without scope, assumptions or residual risk.