Two Jobs, One Chair — Builder and Risk Officer

This module is about the structural fact that distinguishes the technology executive from every other C-suite role: two mandates that pull in opposite directions, and — in most companies below a billion dollars of revenue — one person paid to hold both.

The builder mandate is the CIO's: deliver capability, ship the platform, migrate the ERP, make the business faster than it was. The risk-officer mandate is the CISO's: preserve capability, keep the platform from becoming the breach, make the business slower than it wants to be in the specific places where speed is how companies die. In a large enterprise these are two people with a reporting line between them, and the reporting line is a design decision with evidence behind it. In an SMB, an MSP or a mid-market company they are one person, and the "reporting line" runs through that person's own head.

Three things are taught here. What the research says about where the CIO should report — more than most people think, and conditional on strategy. What it says about where the CISO should report — much less than the conference circuit implies, and we will not pretend otherwise. And how to design decision rights so that the combined CIO/CISO can be honest with themselves: which means keeping the argument they are not currently making alive, in writing, where someone else can see it.

In the Effectiveness Equation — Traits × Behaviors × Organizational Context × Current Moment — this module changes the Organizational Context term. The reporting line and the decision-rights design are context, and for the technology executive, context is a term of the equation rather than a footnote.

The builder and the risk officer are not two personalities; they are two arguments, and the company needs the loser of each argument to be recorded.

A CIO who builds without a risk officer's argument ships the breach. A CISO who preserves without a builder's argument preserves a company that stops growing. Separate people with separate reporting lines keep both arguments alive by structure; the combined CIO/CISO has to keep them alive by discipline, and the discipline is mechanical — written cases, owned risk acceptances, a standing second opinion — because nobody wins an argument with themselves fairly under deadline.

Where the CIO reports, and why it depends

RESEARCH FINDING Banker, Hu, Pavlou and Luftman (2011) argued and showed, on longitudinal firm-level data covering 1990–1993 and 2006, that a firm's strategic positioning should be the primary determinant of where the CIO reports. Firms pursuing differentiation performed better when the CIO reported to the CEO; firms pursuing cost leadership performed better when the CIO reported to the CFO. The authors state this alignment should hold "independent of whether IT plays a key strategic role in the firm." What it supports: the "right" reporting line is conditional on the problem the company is solving — evidence that structure should follow strategy, not a universal rule. What it cannot: a cloud-era prescription (the data predate today's CIO), or causation — endogeneity of the reporting choice was addressed statistically, not experimentally.

RESEARCH FINDING Chatterjee, Richardson and Zmud (2001) ran an event study on announcements of newly created CIO positions and found that "for firms competing in industries undergoing IT-driven transformation, announcements of newly created CIO positions do indeed provoke positive reactions from the marketplace." A market reaction measures investor belief, not subsequent performance, and the effect is conditional on industry context. What it supports: creating the role sends a signal that investors read as value in the right context — not that the role delivered it.

RESEARCH FINDING Peppard (2010), from interviews, argued that CIO performance is largely a function of organizational context — especially "the IT savviness of the CEO and the leadership team" — and that blaming CIOs for disappointing IT returns misplaces accountability. Qualitative, no outcome data. It is the contextual account of CIO performance this module builds on.

The CIO–top-team relationship as mechanism

RESEARCH FINDING Preston and Karahanna (2009), using 243 matched CIO–top-management-team pairs, found that shared understanding between the CIO and the top team about the role of IS was a significant antecedent of IS strategic alignment, and that shared language, shared domain knowledge and formal "systems of knowing" influenced shared understanding — while informal social interaction and CIO–TMT experiential similarity did not significantly affect it. Cross-sectional, self-reported, US, alignment rather than performance as the outcome. What it supports: formal mechanisms and shared knowledge, not socializing, are associated with the understanding that alignment rests on.

RESEARCH FINDING Karahanna and Preston (2013), with matched responses at 81 US hospitals, found that the structural, cognitive and relational dimensions of CIO–TMT social capital facilitated knowledge exchange; cognitive and relational social capital directly influenced alignment; and "IS alignment significantly influences the firm's financial performance and mediates the relationship between CIO–TMT social capital and performance." One sector, 81 organizations, partly perceptual performance, correlational with alignment as mediator. What it supports: relationship quality as a mechanism, measured in one industry.

RESEARCH FINDING Gerow, Grover, Thatcher and Roth (2014) meta-analyzed the IT–business alignment literature and found "all mean corrected correlations between dimensions of alignment and dependent variables were positive," concluding "there is not much of an alignment paradox." The underlying studies are largely cross-sectional surveys; corrected correlations are modest and heterogeneous. What it supports: pooled across the literature, alignment is positively associated with performance on every dimension examined.

Governance as decision rights

RESEARCH FINDING (Tier 3). Weill and Ross (2004), in a research-based practitioner book from MIT's Center for Information Systems Research studying about 250 enterprises, defined IT governance as the framework of decision rights and accountabilities for IT decisions and reported that "firms with superior IT governance have more than 25% higher profits than firms with poor governance given the same strategic objectives." Not peer-reviewed; the ">25%" figure is a descriptive comparison with the authors' own selection of top performers; the book's taxonomy of decision domains and governance archetypes is a framework, not a finding. What it supports: governance framed as a design choice about who decides what — useful language, not proof that governance causes profit.

FACT Since February 2024 the NIST Cybersecurity Framework 2.0 has included a Govern function alongside Identify, Protect, Detect, Respond and Recover, treating executive and board accountability for cyber risk as co-equal with the technical functions (NIST, 2024). The framework is voluntary and outcome-focused; it does not prescribe a reporting line and is not evidence of effectiveness.

What the CISO literature adds — and does not

RESEARCH FINDING Maynard, Onibere and Ahmad (2018) found through systematic review that the CISO's strategic role is under-theorized and proposed a competency set for the CISO as strategist; no outcome test. Peer-reviewed research has examined CISO appointments and reporting positions in relation to breach events (Karanja, 2017), but the abstract could not be retrieved and no finding is cited. RESEARCH FINDING (Tier 3). In the IANS and Artico Search (2026) survey of more than 600 security leaders, 64% of CISOs reported to IT leaders (CIO or CTO) and 36% to non-IT leaders (CEO, COO, general counsel or chief risk officer), and executive-level CISOs were about twice as likely as VP-level CISOs to report to business leaders. Self-selected, commercially interested; a base rate.

RESEARCH FINDING Two archival studies are adjacent rather than direct. Haislip, Lim and Pinsker (2021) found the presence of a CIO on the top management team "significantly associated with reduced DSBs of all types examined" over 2005–2017; Higgs, Pinsker, Smith and Young (2016) found that over 2005–2014 firms with board-level technology committees were more likely to have reported breaches, and that the committee's presence mitigated negative abnormal returns from external breaches. Both use reported breaches, which conflate occurrence, detection and disclosure; both are associations. What they support: where technology sits in the top team and the board is associated with breach outcomes and with how breaches are reported and priced.

Where the evidence is weak

The CIO reporting-line evidence is real but old and conditional; the mechanism evidence is cross-sectional and, in the strongest study, single-sector. For the CISO reporting line there is no peer-reviewed outcome study in this library — no paper that compares CISO-to-CIO with CISO-to-CEO or CISO-to-general-counsel on breach outcomes, cost or anything else. The IANS figures describe prevalence, and the archival studies describe the top team and the board, not the CISO's box on the chart. Everything this module says about where the CISO should report is therefore INTERPRETATION, reasoned from the CIO evidence and from the logic of whose argument reaches the decision.

Two mandates, five collisions

FRAMEWORK The builder mandate is to increase what the business can do: capability, speed, reach, margin. The risk-officer mandate is to protect what the business can do from the ways it can be lost: breach, outage, regulatory penalty, the loss of a client's trust. Both are legitimate; both are measured; and they collide at five predictable points.

The go-live. The platform is ready, the pen-test remediation is not, and the date has been announced. The builder says ship and patch; the risk officer says the findings are the reason not to. The access decision. The sales team wants the CRM open from any device; least privilege says no. The vendor decision. The fast vendor has not completed the security questionnaire; the compliant one is three months slower. The budget. Every dollar on controls is a dollar not on features, and the CEO can see the features. The incident. The engineers know what happened; legal wants to wait; the builder half wants the platform back up before the risk-officer half has finished scoping.

In a large enterprise, each collision is a meeting between two executives. Below that scale it is a conversation the combined CIO/CISO has with themselves, usually at 11pm, usually under a date. The problem is not that one argument is wrong. It is that under deadline the argument with the CEO behind it wins by default, and the other one is never written down.

What the evidence says about the CIO's reporting line

INTERPRETATION The CIO evidence is more useful than it looks, because it is conditional. Banker, Hu, Pavlou and Luftman (2011) found that differentiation-strategy firms did better with the CIO reporting to the CEO and cost-leadership firms with the CIO reporting to the CFO. Read as a rule, that is a curiosity from the 1990s. Read as a principle — structure follows the problem — it is the whole module. A company whose competitive problem is building something new needs the builder's argument in the room where strategy is set; a company whose competitive problem is cost needs the builder's argument disciplined by the person who owns cost. Neither is "right." Each is right for a problem.

The mechanism studies say how the reporting line does its work. Preston and Karahanna (2009) found that formal systems of knowing and shared domain knowledge — not informal socializing — were associated with the shared understanding that alignment rests on; Karahanna and Preston (2013) traced social capital through alignment to performance in 81 hospitals; Gerow et al. (2014) found alignment positively associated with performance across the literature. INTERPRETATION The reporting line matters because it is the primary formal mechanism by which the technology executive's argument reaches the decision — and Peppard (2010) adds the limit: a CEO who does not understand technology bounds what any CIO can do, wherever the CIO reports.

The CISO reporting-line debate, honestly

Here the evidence stops and the arguing starts. There are three positions, and each is held by intelligent people.

INTERPRETATION CISO reports to the CIO. The majority case (64% in IANS, 2026 — a base rate, not a recommendation). The argument for: security is mostly implemented in technology, and a CISO inside the technology organization has the access, the budget line and the engineers. The argument against: the builder is grading the builder's homework. When the go-live collision arrives, the risk-officer argument reaches the decision through the person who most wants to ship.

CISO reports to the CEO. The argument for: the risk argument reaches the decision unfiltered, and the CISO has the standing Ashenden and Sasse's (2013) interviewees said they lacked. The argument against: the CEO already has too many direct reports, most CEOs are not equipped to arbitrate technical risk, and a CISO with a seat at the table but no engineers is the IT Advisor profile — capability without authority (Preston, Leidner & Chen, 2008) — in a different chair.

CISO reports to the general counsel or chief risk officer. The argument for: security becomes an enterprise risk like any other, priced alongside legal and financial risk, with disclosure decisions where disclosure expertise lives. The argument against: the CISO drifts into a compliance function, measured on audit findings rather than on whether the company is actually hard to attack, and loses the engineers entirely.

What the research can say. That structure should follow the problem (Banker et al., 2011). That formal mechanisms carry the argument (Preston & Karahanna, 2009). That top-team and board placement of technology is associated with breach outcomes and reporting (Haislip et al., 2021; Higgs et al., 2016). That governance is a design of decision rights (Weill & Ross, 2004 — Tier 3) and that a national framework now names it a function (NIST, 2024 — FACT). What it cannot say: which CISO reporting line produces fewer breaches, lower cost or better decisions. No such study is in our library. Anyone who tells you the CISO "must" report to the CEO is stating a preference.

INTERPRETATION The honest conclusion is a test rather than a rule. The reporting line is right if the risk-officer argument reaches the person who decides without passing through the person who most wants to overrule it — and if the overruling, when it happens, is written down by the person who did it. That is the Reporting Line term of the extended Fit Equation: Industry × Scale × Lifecycle × Strategy × Governance × Problem × Reporting Line = CIO/CISO Fit. A company in a post-breach turnaround, under a consent order, or selling into regulated clients may need the CISO's argument to reach the board directly; a 200-person software company building fast may be fine with the CISO inside technology, provided the exception log is real. Personality × Power applies: the same CISO is a different executive on each line, because discretion is granted by structure (Hambrick & Finkelstein, 1987).

Decision rights for the combined chair

Now the case that matters most for this course's first learners: one person, both jobs, an SMB or MSP or mid-market company where "reporting line" is a metaphor.

FRAMEWORK The design goal is to reproduce by mechanism what the enterprise reproduces by structure: two arguments, both recorded, the loser visible. Six decision rights do it.

1. Both cases in writing before any collision decision. A one-page build case and a one-page risk case, each written as if by an advocate. The combined CIO/CISO writes both. The discipline is not the document; it is having to argue the side you are about to overrule.
2. Risk acceptance owned by the business, not the technologist. When the risk case loses, the executive who chose the build — CEO, client principal, PE operating partner — signs the acceptance in the risk case's own words. The technology executive never accepts a risk on the business's behalf. This is the first sentence of the Risk Corollary made into paper.
3. A standing second opinion. Somebody outside your head — a peer vCISO on retainer, an external auditor, the MDR provider's lead, a board member with security experience — who sees the risk case before the decision and can say the technologist has under-priced it. The SMB/MSP Player's dominant danger is the absence of exactly this.
4. Separation of duties at the three points where it matters. Who approves control exceptions; who can disable a control; who can declare an incident closed. The combined CIO/CISO should hold at most one of the three alone.
5. An escalation path that skips you. Engineers and account managers must be able to raise a risk to the CEO or the client without going through the person who owns both the build and the control.
6. A quarterly reading of the exception log by someone who did not write it. The log of accepted risks is the company's true security posture. If nobody reads it, the second decision right was theater.

INTERPRETATION This is Weill and Ross's (2004) idea — governance as decision rights and accountabilities — scaled down to a company where the "IT steering committee" is three people and a client. It is also what NIST's Govern function asks for at the outcome level (NIST, 2024). And it is where the Maturity Model's third level lives for the technology executive: letting the business own its risk. A Player-stage CIO/CISO who cannot let the business sign for a risk is not being careful; they are keeping a decision that is not theirs.

The dials, and the two jobs at each scale

FRAMEWORK The builder default runs aggression, urgency and innovation; the risk-officer default runs caution, patience and operational discipline. Holding both jobs is not averaging the dials — an average ships nothing and secures nothing. It is moving them by decision: aggression on the migration architecture, caution on the cutover weekend; urgency on the MFA rollout, patience on the vendor's questionnaire. The Overuse Ladder's two rungs for this chair are rigor → bureaucracy (the security review that ships nothing) and urgency → recklessness (the go-live that becomes the breach), and the combined role can climb both in the same quarter.

Player → Coach → Architect changes what "both jobs" means. The Player holds both hands-on and needs the six decision rights as scaffolding. The Coach has hired a security lead and a platform lead and needs the two of them to argue in front of the Coach rather than to the Coach separately. The Architect has two organizations and a reporting line to design, and the evidence above is finally about them.

Fictional composite. Brightwater Foods is a specialty food distributor in Rochester, New York: $420 million in revenue, 1,100 employees, eleven warehouses, owned by a mid-market private equity fund since 2022. Marcus Bell has been CIO since 2020 and added the CISO title in 2023 when the fund's operating partner asked who owned security and found the honest answer was "nobody, exactly." He has 34 people, a managed detection provider, and a cloud ERP migration that is eight months in and two weeks from cutover.

The pen test came back in week thirty. Three high findings: an API gateway that accepts a legacy authentication path, a warehouse-management integration that runs with a shared service account, and a backup configuration that has not been restore-tested since the migration began. Remediation is estimated at five weeks. Cutover is scheduled for the Columbus Day weekend, when order volume is lowest; the next comparable window is Presidents' Day, four months out. The fund's value-creation plan has ERP go-live in the third quarter, and the operating partner has mentioned it on two board calls.

Bell notices the argument forming in his head and notices which side is winning: the builder's. The findings are "manageable," the legacy path is "rarely used," the service account "has been there for years." Every phrase is true and every phrase is the CIO overruling the CISO in private. So he writes both cases, one page each, as advocates.

The build case: a four-month delay costs roughly $600,000 in parallel-running licenses and contractor retention, defers $2 million of planned working-capital benefit, and breaks a commitment made to the board. The risk case: the three findings are precisely the mechanisms by which distributors get ransomed — an unauthenticated path into the order system, a shared credential into the warehouse, and backups nobody has proven. Bell prices it: perhaps one chance in ten of a material incident in the four-month exposure window if they ship now, against one in fifty after remediation, with a plausible cost of $3–8 million and eleven warehouses idle for a week. He shows both pages to the MDR provider's lead engineer, who reads the risk case and says the one-in-ten is optimistic.

Then he takes both pages to the CEO and the operating partner and says both sentences. "Yes — we can cut over on Columbus Day, and here is the risk we're accepting, priced; if we do it, I need one of you to sign this page." And: "No — I'd recommend not, and here is what would change my answer: the API path closed and the service account replaced before cutover, which is eleven days of the five weeks, and the restore test done the weekend before. The backup finding I can carry for a month with daily manual verification."

The operating partner asks the question the module exists to produce: "What does the eleven days cost?" A cutover slipped from Columbus Day to the following weekend, one extra week of parallel running, and a board note. Brightwater cuts over eight days late with two of three findings closed and the third under a written acceptance the CEO signed. INTERPRETATION The combined chair did not become two people. It produced two documents, let someone outside Bell's head read one of them, and made the person who wanted the build sign for the risk of it.

Same pen test, same weekend, four archetypes in Bell's chair.

The Technical CISO stops the cutover. Three high findings is three high findings; the migration waits for remediation and the next window is Presidents' Day. The gain is a clean go-live and no exposure window. The cost is $600,000, a broken board commitment, and — more expensive — a fund that now regards its CIO/CISO as the reason the value-creation plan slipped. The Technical CISO has not lost the argument; they have declined to have it, and the operating partner will hire someone to have it for them.

The Business-Risk CISO ships on schedule with a risk acceptance and compensating monitoring. The gain is the date and a reputation for enablement. The cost depends entirely on whether the acceptance was priced honestly or priced to fit the weekend; if the one-in-ten was written as one-in-a-hundred to make the signature easy, the Business-Risk CISO has converted the risk case into a formality. The second opinion in decision right three exists to catch exactly this.

The Transformation CIO was hired by the fund to deliver the migration and sees the findings as noise in the last mile. The gain is momentum and a board that gets the date it was promised. The cost is that the Transformation CIO's discretion is high and short-lived, the findings are the ransomware playbook, and nobody in the room is being paid to say so. This is the archetype for whom the six decision rights are least natural and most necessary.

The Regulated-Industry CIO/CISO, imagine Brightwater were a broker-dealer or a hospital, would have had the pen test findings on the audit committee's agenda before the cutover question arose, because in those industries the risk argument has a structural path to the board. The gain is that the decision is never made at 11pm. The cost is that the same structure makes the four-month delay the default and the operating partner's question — what does the eleven days cost — is never asked. Institutional paranoia as job description works until the job is to ship.

The two-jobs chair fails when one argument stops being made, and the Overuse Ladder describes each direction.

INTERPRETATION When the builder swallows the risk officer, the rungs are urgency → recklessness and optimism → delusion. The go-live ships with the findings open, the exception log fills with acceptances the technologist signed for the business, and the company learns that "we'll fix it after cutover" is a category of work that never starts. When the risk officer swallows the builder, the rungs are rigor → bureaucracy and caution → paralysis: the security review that ships nothing, the vendor questionnaire that outlasts the vendor, the CISO who is never breached because nothing is ever deployed.

The reporting line has failure modes of its own. A CISO under the CIO whose overrulings are never written down is a control the builder can switch off silently. A CISO under the general counsel who is measured on audit findings becomes a compliance function that is compliant on the day it is breached. A CISO reporting to the CEO without engineers is an advisor whose advice arrives after the build.

HYPOTHESIS The subtlest failure for the combined chair is that the two arguments merge into one voice that sounds balanced and is not. The CIO/CISO who says "it's a manageable risk" about everything has stopped writing the risk case; the one who says "we need to be careful" about everything has stopped writing the build case. Balance is not a tone. It is two documents.

Early warning signs, for the executive or the CEO watching:

• The exception log has not been read by anyone except its author in two quarters, or every acceptance in it is signed by the technology executive.
• Remediation items deferred at go-live are still open at the next go-live.
• The security lead and the platform lead never disagree in front of the CIO; they disagree to the CIO separately, and the CIO decides in private.
• Nobody can name the last time the risk argument won a collision — or the last time the build argument did.
• The CEO cannot say who is allowed to overrule the CISO and what they have to write down when they do.

1. Take your last go-live, vendor selection or access decision. Write the build case and the risk case now, one paragraph each, as advocates. Which was easier to write? Which one did you actually make at the time?
2. Who signed the last risk you accepted? If it was you, whose risk was it?
3. Name the person outside your head who sees your risk cases before decisions. If there is nobody, what is the decision-rights design you are relying on instead?
4. Where does the risk argument in your company reach the decision — through you, past you, or not at all? Who can overrule it, and do they have to write it down?
5. If you report to a CIO: when did they last overrule you in writing? If you are the CIO with a CISO under you: when did you last lose an argument to them, and does anyone else know?
6. At your scale, are you a Player holding both jobs, a Coach with two leads, or an Architect with two organizations? Which set of decision rights are you actually running, and which set does your scale need?

• The builder mandate and the risk-officer mandate collide at five predictable points — go-live, access, vendor, budget, incident — and under deadline the argument with the CEO behind it wins by default unless the other is written down.
• For the CIO, the evidence says structure should follow strategy: CIO-to-CEO was associated with better performance in differentiation firms and CIO-to-CFO in cost-leadership firms (Banker et al., 2011); formal mechanisms, not socializing, carry the argument (Preston & Karahanna, 2009); alignment is associated with performance across the literature (Gerow et al., 2014).
• For the CISO, no outcome study in the library compares reporting lines. Use the test, not a rule: does the risk argument reach the decision without passing through the person who most wants to overrule it, and are overrulings recorded?
• The combined CIO/CISO keeps both arguments alive by mechanism — both cases in writing, risk accepted by the business, a standing second opinion, separation of duties at three points, an escalation path that skips you, and an exception log someone else reads.
• Holding both jobs is not averaging the dials; it is moving them by decision, and the loser of every collision should be visible to someone other than you.