Once the definitive risk hierarchy is established, the organisation must actively design the specific mechanisms needed to change the risk profile. ISO/IEC 27005 outlines several distinct risk treatment options: risk modification (also known as mitigation), risk retention (informed acceptance), risk avoidance (halting the risky activity entirely), and risk sharing (transferring the financial impact via cyber insurance or contractual outsourcing).

When an organisation opts for risk modification for critical operational systems, it must systematically determine all the information security controls necessary to implement the chosen treatment. The standard mandates a critical, formal safety check in this process: the determined controls must be cross-referenced against the comprehensive control catalogue found in ISO/IEC 27001:2022, Annex A. This comparative analysis ensures that security architects have not inadvertently overlooked essential technical, organisational, physical, or human-centric controls during the design phase.

Controls are categorised by their operational intent and are used together to build a resilient, defence-in-depth posture. Preventive controls are intended to prevent information security events that could lead to negative consequences (e.g., firewalls, access control lists, encryption). Detective controls are intended to detect an event as it occurs or shortly thereafter (e.g., Intrusion Detection Systems, log monitoring, SIEM alerts). Corrective controls are intended to limit the consequences of an event and restore normal operations (e.g., incident response plans, data backups, failover sites). The ISO 27005 guidance correctly notes that detective controls are ultimately ineffective if their notification does not result in appropriate, timely action, emphasising the need for a balanced control portfolio.

A major challenge in determining security controls is the shift to Zero Trust Architecture (ZTA) and the protection of highly decentralised, cloud-native environments. The traditional perimeter-based security model, in which implicitly trusted internal networks were protected by robust external firewalls, has collapsed due to remote work, multi-cloud deployments, and API-driven SaaS integrations. Implementing Zero Trust controls requires a fundamental paradigm shift to "never trust, always verify," utilising identity, rather than network location, as the new perimeter. However, selecting and integrating these modern controls is immensely complex. Legacy applications, which often form the backbone of enterprise operations, frequently lack the technical compatibility to support granular, identity-based micro-segmentation or modern federation protocols (e.g., SAML/OIDC).

Furthermore, security architects face a delicate balancing act: over-engineering preventive controls (such as requiring excessive, repetitive multi-factor authentication prompts for mundane, low-risk tasks) severely hampers user productivity and organisational agility. This operational friction invariably drives employees to adopt "Shadow IT" solutions to bypass the cumbersome security mechanisms, inadvertently creating vast new, unmonitored attack surfaces. Therefore, when determining controls, architects must prioritise solutions that are "secure by design," embedding invisible, automated governance mechanisms into the underlying infrastructure to maintain high security efficacy without degrading the user experience.