Six months after a board signs off on a major cybersecurity investment, a material risk acceptance, or an AI deployment, a regulator asks why. The question sounds simple. For most organizations it is not, because the reasoning lived in a meeting, not in a record. Maman Ibrahim, who works across cybersecurity and internal audit, calls this the Decision Reconstruction Test, and it is a far harsher measure of framework quality than any control maturity score. Could someone who was not in the original meeting identify the evidence considered, the alternatives rejected, the risks accepted, the person authorized to decide, and the conditions that would require reconsideration? If the answer depends on finding three executives who remember the meeting differently, the framework has failed at exactly the moment it was built for. That reframing matters because the security industry has spent two decades optimizing for the wrong thing. Control counts, policy libraries, and compliance percentages all measure how well a system is described. None of them measure how an organization behaves when the pressure is on.
The Six Elements That Make A Framework Whole
Ibrahim builds comprehensive frameworks from six connected elements, and the sequence is deliberate:
- Business context: Which services and assets are critical, and how much disruption the organization can tolerate. Skip it and you protect everything equally, which in practice means protecting the most important things inadequately.
- Governance and accountability: Who owns risks, who may accept them, who can challenge a decision, and what happens when the usual decision-maker is unavailable.
- Risk and control architecture: The International Organization for Standardization (ISO) 27001 and the National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF) provide structure that must be translated into controls proportionate to real exposure.
- Operational execution: How controls work in practice, including whether they remain effective under operational pressure.
- Evidence and assurance: Whether the organization can demonstrate that controls work and that evidence supports material decisions.
- Adaptability: Whether the framework can evolve as risks, technology, and business needs change.
“A control that looks excellent in a policy but fails under operational pressure is not an effective control,” Ibrahim says.
The practical consequence is that a framework is defensible because material decisions were informed, proportionate, properly authorized, challenged where necessary, and supported by evidence available at the time. Not because it’s thorough. Boards cannot eliminate uncertainty, and pretending otherwise produces documentation rather than governance. “A good framework tells you what controls should exist,” Ibrahim says. “A defensible framework tells you why they matter, whether they work, and who is accountable when they don’t.” The distinction has teeth in a regulatory environment where the question is rarely whether something went wrong, but whether the organization could explain its own reasoning when it did.
Where Frameworks Break Under Pressure
Most failures are not missing controls. They are the gap between a documented control and a real decision. Ibrahim identifies five recurring weaknesses:
- Starting with the standard rather than the business.
- Confusing documentation with implementation.
- Fragmenting accountability.
- Measuring activities instead of outcomes.
- Never exercising the framework under realistic pressure.
The accountability failure is the most insidious, because it looks like coverage. The chief information security officer identifies a risk only the business can resolve, the business assumes technology owns it, and internal audit eventually discovers the risk has been sitting between the two for months.
Consider a multinational where a subsidiary detects suspicious privileged activity on a group-managed identity service. The subsidiary wants to isolate the affected connection immediately. Group security wants to investigate first. Both positions are defensible. Neither resolves who has authority to decide: What protective actions are permitted while approval is pending? Who accepts the business consequences of isolation? Ibrahim’s diagnostic for this is unusually cheap and equally revealing: remove the regular decision-maker from a simulated incident and give the replacement team five minutes to act. “If the team cannot establish the facts, locate its authority, or determine the next action, you’ve discovered a governance weakness no control maturity score is likely to reveal.” Framework maturity, on this reading, is measured by behavior under stress, not elegance in documentation.
Governing Decisions, Not Just Systems
Automated cross-walking across NIST, ISO, and the Digital Operational Resilience Act (DORA) has removed a genuine administrative burden, but Ibrahim is clear about its limits. “A mapped control is not necessarily an effective control, and an effective control is not necessarily a defensible decision.” He sets out four stages of maturity:
- Requirement mapping,
- Control harmonization,
- Continuous evidence and assurance, and
- Decision intelligence.
Most organizations are concentrated on the first two. The advantage sits in the third and fourth, where control posture connects to business exposure, residual risk, delegated authority, and management decisions. Two cautions apply. Cross-walking is not equivalence, since requirements that look similar may differ in scope, timing, evidence expectations, or legal consequences. And automation carries its own assurance obligations: Who validates the mappings? How are changes version-controlled? What happens when an AI-assisted interpretation is wrong?
The harder shift is what AI agents do to the authority question. Frameworks have long asked who can access a system or approve a transaction. Ibrahim adds a different question: What is this system authorized to decide or do on behalf of the organization? An agent may hold legitimate technical access across several systems and still lack the delegated authority to execute a consequential business action. That means defining permitted actions, operational boundaries, approval thresholds, escalation conditions, human intervention mechanisms, and emergency termination capabilities. It also means building explicit triggers for reopening decisions, the capability Ibrahim considers most overlooked. A board approves an AI-enabled service on a given risk assessment. Six months later, the model has changed, a supplier has added capabilities, and the service processes more sensitive information. The approval still exists. Its reasoning may not. “The strongest security frameworks will be distinguished less by the number of controls they contain and more by their ability to preserve authority, evidence, accountability, and resilience as technology becomes increasingly autonomous.”
Follow Maman Ibrahim on LinkedIn for more insights on information security governance, board-level risk decisions, and AI assurance.
