The CISO Who Reports to the CIO

A direct line to the CEO is neither necessary nor sufficient, and on its own it may be counterproductive. Reporting lines matter because they determine whether the security function can escalate without its own budget or delivery commitments being compromised. Here the conflict is real: the CIO owns the cloud migration and application delivery, so any security position that delays a release is a position against the CIO's own objectives. But moving security to the CEO can isolate it from the delivery machinery it must influence and simply relocate the conflict.

A more defensible structure is a functional reporting line to the board risk committee (or its chair) for assurance and escalation, with an administrative line to the CIO or COO for day-to-day management, supplemented by guaranteed private access to the audit or risk committee. Whichever variant is chosen, document it in a charter that states who the CISO escalates to, on what triggers, and within what timeframe.

The changes that actually create oversight are less about org charts than about the instruments of governance:

• Approve a risk appetite statement at board level with quantified tolerances, so oversight becomes a comparison against a standard rather than a commentary on activity.
• Rewrite the steering committee's terms of reference so it decides on risk acceptance, exceptions and funding, and delegates project status reporting elsewhere. A committee that only receives status updates is a briefing, not a control.
• Define escalation triggers - for example any exception beyond 90 days, any crown-jewel system below the patching threshold, any incident with regulatory notification potential - so 'no surprises' becomes a mechanism rather than an aspiration.
• Give the board a small number of risk-based metrics with thresholds and named owners, and use the quarterly slot for one deep-dive risk rather than a general update.
• Apply three-lines discipline: the CISO sets framework and provides independent challenge; business units own their risks and accept them in writing.

The test of the redesign is whether a decision would have changed. If the board still sees only patch percentages and no one has authority to accept or reject residual risk, the reporting line has bought nothing.

The patched-endpoint figure fails on four counts: the denominator is unspecified, it does not distinguish crown-jewel systems from low-value ones, it measures activity rather than exposure, and it has no threshold attached, so no number would ever trigger a question. A board metric needs a defined data source, an owner, a target derived from risk appetite, and a trend.

A defensible set of five to six measures, each paired with an appetite threshold:

1. Percentage of crown-jewel systems meeting the critical vulnerability remediation SLA, plus the count of overdue criticals. This replaces an asset-count metric with one that reflects where harm would actually occur. A low count on unimportant servers is not reassuring.
2. Median and 90th-percentile time to remediate critical vulnerabilities. The 90th percentile exposes the tail that averages hide; a good median with a bad tail is how long-lived exploitable holes persist.
3. Percentage of workforce and privileged accounts protected by phishing-resistant or MFA-enforced authentication, reported separately for administrators. Separating administrators prevents a high workforce average from masking weak privileged protection.
4. Number of risk exceptions past their expiry date, with the names of accepting executives. This is a direct measure of whether the risk process is real; expiring exceptions accumulating is the clearest symptom of governance decay.
5. Percentage of critical third parties with current assurance evidence (SOC 2 review, penetration test, or completed assessment within the last 12 months).
6. Material incidents in the period, with mean time to detect and contain. Lagging, but the measure the board most needs to interpret the rest.

Two supporting choices matter as much as the metrics. First, each metric must be presented as value against threshold with a stated consequence - for example, two consecutive quarters above the overdue-critical threshold requires a funded remediation plan at the next committee. Second, retire any metric whose owner cannot explain the data source on request; a metric nobody can trace is a metric nobody can challenge, and the board will learn to ignore it. Keep the set short enough that each item gets a question, and rotate deep-dives rather than adding slides.

The discovery is a governance opportunity, and treating it as a disciplinary matter will destroy the visibility just obtained. The first step is triage, not prohibition: classify the 140 applications by the data they touch, whether single sign-on is available, whether the vendor offers a security attestation, and who owns the business process. Roughly, expect a small number to be high-risk because they hold customer or health data, a middle band that is acceptable with conditions, and a long tail of low-consequence tools.

For the high-risk group, act immediately and individually: confirm data categories, require SSO and contractual terms or migrate to an approved equivalent, and where the business refuses, record a formal, time-bound risk acceptance signed by the accountable executive - not by the security team.

For the rest, the durable fix is to make the approved path faster than the workaround:

• A pre-approved catalogue of applications that can be adopted with SSO and standard terms, self-service and without a security ticket.
• A tiered intake process with published turnaround targets: low-risk tools auto-approved in a day, regulated-data tools requiring assessment in, say, ten working days. Shadow IT exists largely because the official route is slow.
• A procurement hook: expense and card-spend categories that suggest software trigger an automated request to the requester and to security. This converts discovery from an annual surprise into a routine signal.
• SSO federation as the default control, because it provides both access governance and an inventory that maintains itself.

The governing principle is that business units own the risk of the tools they adopt, within a framework that makes the safe option the easy one. Measure the programme on time-to-approval and on the proportion of spend passing through the process, not on the number of applications blocked. Blocking drives usage underground and forfeits the very visibility that made the problem visible.