10.1 Enterprise Risk Committee Decision Lab

Committee Scenario: The Backlog Is Bigger Than the Budget

A global manufacturer has just completed an enterprise risk assessment. The security team reports three major issues: unsupported operating systems in a plant network, weak third-party access to a supplier portal, and missing encryption for archived customer records. Each issue has a different owner, budget path, and business effect. The chief operating officer wants production uptime protected. The general counsel wants privacy exposure reduced. Finance wants to defer capital spending until the next quarter.

The CISSP task is not to declare every item critical and demand immediate funding. The task is to help the committee make a defensible risk decision. A defensible decision identifies the asset, threat, vulnerability, impact, likelihood, existing controls, proposed treatment, residual risk, owner, deadline, and review trigger. The committee should also test whether a proposed action matches the organization's risk appetite and legal obligations.

Risk appetite is the amount and type of risk the organization is willing to pursue or retain in support of objectives. Risk tolerance is the acceptable variation around a specific objective or metric. A company may tolerate short outages in a development analytics system but have almost no tolerance for a safety event in a production plant. The same vulnerability can require different treatment when it affects safety, regulated data, financial reporting, or public trust.

The unsupported plant systems create operational and safety concerns. A patching answer may be technically correct but operationally unsafe if the production line cannot be stopped without validation. The committee may choose compensating controls such as network segmentation, strict allow lists, offline backups, vendor support escalation, monitoring, and a migration plan. The risk owner should be an operations executive, not only the security team, because production constraints drive the treatment path.

The supplier portal weakness creates supply chain and identity risk. If suppliers use shared accounts and no MFA, the organization lacks accountability and has weak resistance to credential theft. The treatment may include unique identities, federation standards, contractual access requirements, monitoring, and recertification. Procurement and legal should be involved because the vendor relationship and contract language affect enforceability.

The unencrypted archive raises asset security, privacy, and retention questions. The committee should ask whether the data still has a business purpose, who owns it, what classification applies, how it is stored, who can access it, and whether retention rules require preservation or disposal. Encryption may be one control, but data minimization, destruction, key management, and access review may reduce risk more directly.

The committee should not confuse control implementation with risk treatment completion. A firewall rule may be installed, but the residual risk remains unclear until the rule is tested, monitored, and tied to an owner. An encryption project may finish, but if keys are stored beside the data or access is still broad, the risk is only partially reduced. Governance requires evidence that the control objective is met.

When funds are limited, prioritization should use business impact rather than emotional labels. A useful method is to score each issue across safety, regulatory exposure, financial loss, operational disruption, exploitability, control maturity, and time sensitivity. This does not replace judgment. It gives leadership a common language for comparing unlike risks and documenting why one treatment is funded before another.

Risk acceptance must be explicit. If the committee accepts the supplier portal risk for 90 days while federation is implemented, the minutes should record the residual risk, interim controls, accepting authority, expiration date, and review condition. Passive delay is not risk acceptance. It is unmanaged risk. A CISSP answer should usually prefer documented acceptance by an accountable business owner over informal deferral.

Ethics also matter. If a risk could harm customers, employees, partners, or the public, the committee should consider more than cost. Security governance is not a way to justify avoidable harm. It is a way to align protection duties with business objectives, legal requirements, and professional responsibility. The committee should surface when a proposed decision would hide material risk from those who need to know.

Committee Workflow

1. Define the business process, asset, data, and stakeholder harmed by failure.
2. State the threat scenario in plain business terms.
3. Identify current controls and known gaps.
4. Estimate likelihood and impact using agreed criteria.
5. Select treatment: avoid, mitigate, transfer, or accept.
6. Assign an accountable owner, due date, funding path, and evidence requirement.
7. Record residual risk and schedule review.
8. Escalate if risk exceeds appetite or involves legal, safety, or ethical duties.

The best committee output is a living risk register, not a slide deck. Each entry should connect risk decisions to policies, standards, projects, exceptions, tests, incidents, and audit evidence. When the next assessment occurs, leadership should be able to see whether residual risk decreased, increased, or was knowingly retained. That is the difference between governance theater and security management.