Our team focused on governance, and what stood out in this case is how completely it failed despite strong NIST documentation. No one owned the vendor credentials, escalated the anomalies, and no committee reconvened after the breach. The culture treated cyber as an IT problem, not an enterprise risk, which meant roles, accountability, and challenge were missing at every stage. The main takeaway is that having frameworks is not enough for governance if people do not actually follow them.
In the cybersecurity case, one theme that stood out is how governance failures create systemic amplification of technical issues. My question is: how does a CRO practically verify that the CISO’s control dashboards reflect true residual risk rather than activity metrics that create a false sense of security? In other words, what does ‘effective challenge’ look like for cybersecurity when the CRO is not a technical expert, but still owns the risk?
Suppose the CISO says we deployed the XYZ system and the ABC procedures, and this has reduced the residual risk by X. They probably wouldn't phrase it that way, but after a few back and forth steered by the 2nd line, the 2nd line could say something like this. “Did I get this right. IT has deployed, deployed the XYZ system and the ABC procedures, and this has reduced the residual risk by X”. IT may then fine tune the statement. but once you have a version that is accurate, you can ask them what tests have been run, or industry evidence is there that supports the residual risk conclusion. Since IT doesn’t, usually think in terms of residual ri…
a bank can be “NIST compliant” yet still operationally fragile. The breach wasn’t caused by one bad control — it came from small execution failures stacking together: a shared vendor credential, inactive MFA governance, missing API logs, and an outdated playbook. These gaps made it impossible to detect the scope of the incident or respond confidently.
To me, the real lesson is that cyber risk management only works when controls, resilience, and governance reinforce each other. If logging, escalation, and accountability don’t work in practice, a perfect framework on paper won’t prevent repeated breaches.
After studying the ECRG structure, this is the first special case we went through together: Cyber Security, what i found interesting was how powerful the MECE structure we studied is. No mater what the situation is, we can rely on the MECE for Exposures and Controls! We learnt CIA for cyber security. C: confidentiality, I: integrity, A: availability, these are not new exposures. they are one level above, they are what causes the exposure. But they all map to the MECE 6 of exposures, depending on the situation. lets take an example, if a cyber attack caused the data leakage, this could lead to client claims, regulatory claims. Similarly for controls, we learn: Access, Authentication, Authorization, Audit Trail. All of…
What stood out to me most in this case is how a cybersecurity program can look mature from the outside yet fail almost completely in practice. Every group could point to a framework—NIST tiers, generic playbooks, access management policies—yet none of them produced the basic outcome the Board kept asking for: confidence that risks were understood, controlled, and recoverable. What is striking is the gap between documentation and capability. Controls existed, but credentials weren’t revoked; a playbook existed, but it wasn’t updated; governance existed, but no one owned escalation when the breach began.The case shows that cyber maturity is not measured by how many frameworks a firm adopts, but by whether people challenge assumptions, update processes, and act quickly under…
Our team focused on governance, and what stood out in this case is how completely it failed despite strong NIST documentation. No one owned the vendor credentials, escalated the anomalies, and no committee reconvened after the breach. The culture treated cyber as an IT problem, not an enterprise risk, which meant roles, accountability, and challenge were missing at every stage. The main takeaway is that having frameworks is not enough for governance if people do not actually follow them.
In the cybersecurity case, one theme that stood out is how governance failures create systemic amplification of technical issues. My question is: how does a CRO practically verify that the CISO’s control dashboards reflect true residual risk rather than activity metrics that create a false sense of security? In other words, what does ‘effective challenge’ look like for cybersecurity when the CRO is not a technical expert, but still owns the risk?
a bank can be “NIST compliant” yet still operationally fragile. The breach wasn’t caused by one bad control — it came from small execution failures stacking together: a shared vendor credential, inactive MFA governance, missing API logs, and an outdated playbook. These gaps made it impossible to detect the scope of the incident or respond confidently.
To me, the real lesson is that cyber risk management only works when controls, resilience, and governance reinforce each other. If logging, escalation, and accountability don’t work in practice, a perfect framework on paper won’t prevent repeated breaches.
After studying the ECRG structure, this is the first special case we went through together: Cyber Security, what i found interesting was how powerful the MECE structure we studied is. No mater what the situation is, we can rely on the MECE for Exposures and Controls! We learnt CIA for cyber security. C: confidentiality, I: integrity, A: availability, these are not new exposures. they are one level above, they are what causes the exposure. But they all map to the MECE 6 of exposures, depending on the situation. lets take an example, if a cyber attack caused the data leakage, this could lead to client claims, regulatory claims. Similarly for controls, we learn: Access, Authentication, Authorization, Audit Trail. All of…
What stood out to me most in this case is how a cybersecurity program can look mature from the outside yet fail almost completely in practice. Every group could point to a framework—NIST tiers, generic playbooks, access management policies—yet none of them produced the basic outcome the Board kept asking for: confidence that risks were understood, controlled, and recoverable. What is striking is the gap between documentation and capability. Controls existed, but credentials weren’t revoked; a playbook existed, but it wasn’t updated; governance existed, but no one owned escalation when the breach began.The case shows that cyber maturity is not measured by how many frameworks a firm adopts, but by whether people challenge assumptions, update processes, and act quickly under…