The 190-control mobile release at a retail bank
A retail bank operates a mobile banking app with 2.1 million active users and releases every two weeks. Its application security control library contains 220 controls. The security architecture team has decided that, because the app is 'high risk', every release must select 190 controls from the library. Twelve architects review each release; the average release is delayed by nine days. In the last quarter, 14 releases used an emergency hotfix path that skipped the review. A risk assessment shows that payment and authentication functions carry high fraud impact, while store locator, marketing preferences and branch appointment booking have low impact. The head of mobile asks whether the control selection is defensible and what a better approach would look like without weakening payment security.
1. Is selecting 190 controls for every release defensible under ISO/IEC 27034? Explain your reasoning.
Read the worked answer
It is not defensible merely because the app is labelled high risk. ISO/IEC 27034 expects controls to be selected through an application security risk assessment and tied to security requirements, not applied as a blanket proportion of a library. A 190-of-220 selection means most controls are treated as mandatory for every change, including changes to the store locator or marketing preferences. That dilutes reviewer attention, creates long delays and makes the emergency bypass route attractive. The bypass is itself evidence that the process is not producing effective assurance. The selection could be defensible only if each control were traceable to a specific risk or requirement, if verification were proportionate, and if the ANF distinguished high-impact from low-impact components. The bank should define a minimum baseline for the whole app and risk overlays for payment and authentication, then tailor the ANF by component and release scope.
2. Propose a risk-based selection and verification approach for the next release, including how to handle the low-impact functions and what evidence to retain.
Read the worked answer
Segment the app into business functions and data flows. For each component, assess fraud impact, data sensitivity, exposure and change scope. Use the ONF to select controls for the payment and authentication components that address input validation, session management, transaction integrity, logging and fraud monitoring. For low-impact functions, apply the organization's minimum baseline plus automated checks, with lighter manual review. The ANF should state which controls apply to which component and why. Verification should match control risk: automated tests and code analysis for repeatable checks, targeted manual testing for high-impact logic, and review evidence for exceptions. Retain the risk assessment, the ANF version, traceability from requirements to controls, verification results, reviewer sign-off and any accepted residual risk. This approach does not weaken payment security because the strongest controls remain concentrated where fraud impact is highest, while low-impact changes no longer consume the same review capacity.