TL;DR: Financial institutions need to demonstrate that security controls are effective in production and that security investments reduce business risk. Across regulatory frameworks including NYDFS, OSFI, DORA, MAS and APRA, verified control evidence helps institutions demonstrate resilience and support accountable risk decisions. Aquasec connects runtime enforcement with FAIR based financial risk modeling, helping security leaders assess protection, quantify potential risk reduction and prioritize additional investment.
During a customer penetration test, testers progressed through an attack path using exec access to running containers. A control capable of restricting that activity was available, but it was not enforced. The team enabled it and repeated the test without changing the other variables. The testers could no longer progress through the same step to reach their original objective.
For a financial institution, that is useful evidence. It shows how an operational change affected a tested attack path. The next questions concern coverage and business impact: which services depend on those workloads, where else is the control enforced and what exposure remains? Answering those questions requires connecting technical control evidence with regulatory expectations and the financial consequences of cyber risk.
What do financial regulations require institutions to demonstrate about cybersecurity controls?
Across five major regulatory regimes, financial institutions are expected to demonstrate effective management of technology risk and operational resilience. The requirements differ by jurisdiction, but they share an emphasis on accountable management, appropriate controls and evidence that those controls work.
United States: NYDFS Part 500
NYDFS Part 500 connects cybersecurity safeguards with executive accountability. For covered entities subject to the relevant provisions, annual submissions must be supported by evidence of material compliance or an acknowledgment identifying noncompliance and remediation. The regulation also addresses vulnerability management, access controls and tested incident response and recovery.
Runtime evidence can contribute to that record when it shows how an applicable control operated.
Canada: OSFI
OSFI B-13 sets expectations for technology and cyber risk management, including control testing, asset inventories, preventive defenses and recovery.
E-21 connects that work to critical operations, dependencies, disruption tolerances and scenario testing. Full adherence was expected by September 1, 2026, with scenario testing for all critical operations to be completed by September 1, 2027. B-10 retains the institution’s accountability for third party arrangements.
A blocked container action becomes more useful when the institution can connect it to the critical operation it protects.
European Union: DORA
DORA places ultimate responsibility for ICT risk with the management body. Its requirements cover ICT risk management, incident reporting, resilience testing and third party risk.
For financial entities subject to Article 24, appropriate tests must cover ICT systems and applications supporting critical or important functions at least annually. Control results should therefore inform remediation and the wider assessment of operational resilience.
Singapore: MAS
MAS combines binding technology risk and cyber hygiene notices with supervisory guidance on technology risk, outsourcing and business continuity. For banks, the relevant notices are FSM-N05 and FSM-N06.
MAS emphasizes recoverable critical IT systems, customer information protection and critical business services with external dependencies.
A consultation on further technology risk management notice amendments ran from June 10 to July 31, 2026. Those proposals should be distinguished from requirements already in force.
Australia: APRA
The Australian Prudential Regulation Authority places control effectiveness and operational resilience under board oversight.
CPS 234 requires information security controls proportionate to the information assets they protect, with systematic testing of effectiveness. CPS 230 connects operational risk to critical operations, disruption tolerances, tested continuity plans and oversight of material service providers.
For a payment service, runtime test results can help demonstrate which supporting workloads are protected, alongside evidence that the service can continue or recover within its tolerances.
How can international banks establish a common control baseline?
International banks can reduce duplicated assurance work by identifying common requirements across these five regulatory regimes and establishing a shared control baseline.
The objective is to apply security best practices continuously across regions, rather than treating individual regulatory minimums as the limit of protection.
Shared controls, consistent testing and reusable evidence can support multiple regional obligations. Institutions still need to map those controls to local requirements and maintain the reporting each jurisdiction requires.
How do NIST, MITRE and other security frameworks support regulatory assurance?
Regulatory obligations establish expectations, while technical frameworks help institutions translate those expectations into security practices that can be implemented and tested.
NIST CSF 2.0 provides a structure organized around Govern, Identify, Protect, Detect, Respond and Recover. NIST SP 800-190 adds container security guidance, while CIS Benchmarks and NSA/CISA Kubernetes hardening guidance help teams assess configuration, least privilege and network separation.
MITRE ATT&CK for Containers helps security teams identify relevant attacker techniques and design tests that determine whether controls interrupt specific attack paths.
Software bills of materials identify components, while SLSA, Supply chain Levels for Software Artifacts, provides a framework for assessing build integrity and provenance.
For AI applications, the OWASP Top 10 for LLM and Agentic Applications identifies risks including Prompt Injection, Excessive Agency and Identity and Privilege Abuse.
These frameworks are applicable beyond financial services, but banks can use them to establish testable controls that also support regulatory assurance.
For example, a bank could map an enforced runtime policy to a MITRE technique, document the observed test result and connect that evidence to its internal control framework. The mapping would still require validation against the actual workload and applicable obligations.
Why does production change how financial institutions assess control effectiveness?
Cloud native applications change continuously. Containers are replaced, new images are deployed and a vulnerability disclosed today may affect an image that passed its security checks yesterday.
Scanning and patching remain essential, but they cannot establish whether protections continue to operate against threats affecting workloads in production.
During triage and remediation, runtime enforcement can restrict particular unauthorized behaviors or interrupt tested attack paths. Institutions should validate those controls against relevant threats and document the exposure that remains while a permanent fix is developed.
AI applications introduce additional considerations around workloads, identities, data access and agent permissions. Runtime controls can address relevant workload behavior, while model governance and assessments of intended use remain separate responsibilities.
For financial institutions, demonstrating control effectiveness therefore requires evidence that reflects the environment currently running, rather than relying solely on assessments completed before deployment.
What evidence demonstrates that a runtime security control is effective?
Control effectiveness should be assessed in the context of the business service being protected.
Consider a payment service. The institution should identify its supporting workloads and dependencies, then establish which controls apply during image assessment, admission and runtime.
Each policy should be evaluated according to its scope and operating mode. An audit event supports investigation and response, while a policy configured for enforcement can prevent a supported unauthorized action from completing.
Testing the same attack with and without enforcement helps demonstrate whether a control changes the outcome. In the demo below, a running Kubernetes workload is exposed to unauthorized software execution, a reverse shell and interactive container access. Enabling the corresponding Aquasec Runtime controls blocks the tested actions, showing the difference an enforced policy makes under the same conditions.
Testing should document the policy version, affected workloads, timestamps and observed results. Coverage must be evaluated alongside effectiveness because a successful test on one workload does not establish protection across the entire payment service.
Operational resilience also requires evidence that recovery procedures work and that critical supplier dependencies are understood. Institutions need to assess how security controls behave during failures and whether recovery remains possible within established tolerances.
How does Aquasec connect runtime enforcement with financial risk quantification?
Aquasec combines runtime intelligence and enforcement with FAIR based financial risk modeling to help financial institutions understand how security controls affect business exposure.
Aquasec Enforcers operate inside running workloads at the kernel layer, where they can deny supported unauthorized actions at the point of execution when the appropriate policies are enforced.
This provides operational evidence of where policies are active and how they perform against specific behaviors.
FAIR, or Factor Analysis of Information Risk, provides a structured method for expressing cyber risk in financial terms. Annual Loss Expectancy combines estimated loss event frequency with estimated loss magnitude.
The Aquasec FAIR Risk Dashboard extends container security data into that financial view. It groups containers by Line of Business using Aquasec Application Scopes and company.lob.* labels, calculates Annual Loss Expectancy for workloads and surfaces the estimated risk reduction associated with available policies that are not enforced.
The dashboard organizes controls across Image, Network, Runtime and Access layers. It accounts for overlap within each layer and combines the estimates into an overall view of potential risk reduction.
For a CISO, this creates a practical basis for comparing decisions. A vulnerable workload supporting payments may carry significantly different financial exposure from a development workload with a similar vulnerability severity score.
The institution can evaluate the estimated exposure associated with payment services and determine how enforcing an existing control could change its financial risk.
Gartner makes a related point in Forecasting the $41 Billion CNAPP Opportunity, noting that quantitative frameworks such as FAIR can help teams report “the financial risk reduction achieved per dollar spent.”
These estimates should remain transparent about business assumptions, coverage and uncertainty. A modeled reduction in Annual Loss Expectancy supports an investment decision, while realized savings require separate evidence.
What are the common mistakes when demonstrating control effectiveness?
Assuming a deployed policy provides effective protection. Institutions need to distinguish between controls that are available, controls operating in audit mode and controls actively enforcing restrictions.
Treating a successful penetration test as proof of complete coverage. Test results establish effectiveness within the tested conditions. They do not automatically demonstrate protection across other workloads or policy exceptions.
Presenting modeled financial risk reduction as realized savings. FAIR estimates help compare scenarios and guide investment, but institutions should retain the assumptions and uncertainty underlying those calculations.
What should financial institutions do next?
Choose a critical business service and review the workloads supporting it. Identify available policies that are not enforced, test relevant attack paths and document coverage and exceptions.
Confirm the service’s recovery requirements and critical supplier dependencies, then use the FAIR Risk Dashboard to estimate the financial effect of proposed enforcement changes.
The result should support a clear management decision to enforce an existing control, fund additional protection, remediate a gap or explicitly accept the remaining risk, supported by tested evidence and financial analysis.
No. Aqua runtime enforcement provides compensating protection for supported behaviors while institutions continue to assess vulnerabilities and deploy permanent remediation.
Aqua can provide evidence showing how relevant policies operated in production. Institutions can use that evidence within their broader assurance processes, but it does not independently establish compliance with a particular regulatory framework.
FAIR provides a structured financial model for estimating potential losses and comparing risk reduction scenarios. Aqua’s FAIR Risk Dashboard connects workload and control information to that analysis, helping leaders evaluate the potential financial impact of enforcement decisions.