CISO vs CSO vs CIO: Who Owns Security Risk and Incidents

When a serious incident lands, many organisations discover that the CISO, the CSO and the CIO each assumed one of the others owned the decision. The three titles overlap, mean different things in different companies, and are often defined only by an organisation chart that says nothing about who declares an incident, who accepts a risk or who tells the regulator. This guide compares the three roles on scope, accountability, decision rights and incident ownership, shows how the split changes in common organisation shapes, and explains where identity and AI risk tend to land. It is written for CEOs, boards and the executives in these roles who need to agree the split in writing before an incident forces it. Reporting line options are covered separately in Where Should the CISO Report; this guide focuses on who owns what. Regulatory references were checked on their official sources on 14 November 2026.

Key takeaways

• The titles describe scope, not seniority. A CIO runs technology delivery, a CISO owns information and cyber security risk, and a CSO usually owns security in the wider sense, often physical, personnel and cyber together. None of the three is automatically senior to the others.
• Accountability must be written, not inferred. NIST CSF 2.0 GV.RR-02 expects roles, responsibilities and authorities for cybersecurity risk to be established, communicated, understood and enforced. A job title satisfies none of that.
• Incident ownership splits into four decisions. Declaring and running the incident, restoring services, deciding materiality and notification, and speaking externally belong to different people; the failure is when nobody holds one of them.
• Regulators hold the board and senior management to account, and expect a named security lead. NIS2 Article 20 makes management bodies approve and oversee measures; NYDFS 500.4 requires a designated CISO reporting to the senior governing body; SEC Item 106 requires a public description of management's role and expertise.
• Identity and AI risk fall into the seams. Service accounts, API keys and AI agents are run by IT and engineering but are security risk; without an explicit owner they stay unreviewed.

The short answer

• CIO (Chief Information Officer): accountable for technology strategy, delivery and operations: infrastructure, applications, the service desk, IT suppliers and service availability. Owns restoring systems during an incident.
• CISO (Chief Information Security Officer): accountable for the information and cyber security programme: risk assessment, policy, security architecture standards, detection and response, and reporting cyber risk to the board. Owns declaring and running a cyber incident.
• CSO (Chief Security Officer): the most variable title. In many organisations it is the senior security executive over physical security, personnel security, investigations and business protection, sometimes with the CISO reporting into it (a converged model). In others, especially technology companies, CSO is simply another name for the CISO. Always check the mandate, not the acronym.

Which is higher depends entirely on the organisation. A converged CSO typically sits above the CISO; a CISO in a large bank may report to the Chief Risk Officer and be a peer of the CIO. Asking "which is higher" is less useful than asking "who can overrule whom, and how is that recorded".

Side-by-side comparison

The CSO column assumes a converged role. Where CSO is used as a synonym for CISO, read it as the CISO column. ASIS International publishes an American National Standard on the Chief Security Officer organisational model, revised in 2014, which frames the role as a senior security executive whose scope the organisation sets by identifying what each function owns, what it is accountable for and what is shared. For converged models in depth, see the Physical and cyber security convergence guide.

Accountability: what each role owns and what it cannot own

A useful test is the difference between being responsible for doing something and being accountable for the outcome. Three principles hold across most well-run organisations.

• Risk owners are business executives, not the CISO. The CISO assesses and reports cyber risk and sets the control standard, but the executive who owns the business process or system decides whether to fund the fix or accept the risk within appetite. If the CISO is the default owner of every risk, the business has outsourced its decisions and the CISO is accountable for things they cannot change.
• The CIO owns the control in operation. Patching, configuration, backups, access provisioning and logging on IT-run platforms are executed by IT. The CISO defines what good looks like and verifies it; the CIO delivers and evidences it. This is the classic first and second line split described in the Three Lines Model for Cyber Risk Guide.
• The board owns oversight and appetite. NIS2 Article 20 requires management bodies of essential and important entities to approve cybersecurity risk-management measures, oversee their implementation, and allows them to be held liable for infringements; members must also follow training. The UK Cyber Governance Code of Practice asks boards to agree senior ownership of cyber risks (action A2) and to define ownership of cyber at executive and non-executive level (action E1).

Decision rights matrix

The table uses A for accountable (one per row), R for responsible, C for consulted and I for informed. It reflects a common split where the CISO is a peer of the CIO and the CSO runs physical and personnel security; adjust it, but keep one A per row.

A template version of this matrix for incidents is the Incident Response RACI Template.

Incident ownership: the four decisions

Most incident disputes come from treating "owning the incident" as one thing. It is four.

1. Command. Declaring the incident, setting severity, appointing the incident commander and directing containment. For cyber incidents this sits with the CISO or a delegate. The incident commander role itself is described in the Incident Commander Role Guide.
2. Recovery. Rebuilding, restoring from backup and bringing services back in business priority order. This is the CIO's job, with the CISO confirming that systems are clean before reconnection.
3. Disclosure. Deciding whether the incident triggers a legal duty and filing on time. Under NIS2 Article 23 an entity sends an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours and a final report within one month of the notification. US listed companies must determine materiality without unreasonable delay and, if material, file Form 8-K Item 1.05 generally within four business days of that determination. NYDFS 500.4 requires the CISO to inform the senior governing body or senior officers promptly of material cybersecurity issues such as significant events. The CISO supplies facts; legal and executive leadership decide.
4. Communication. Staff, customers, media and investors. Usually led by communications and legal, with the CSO involved where safety or physical access is affected and the CIO where service status is the message.

Write these four into the incident response plan by name and role, with deputies. NIST SP 800-53 Rev. 5 IR-8 expects an incident response plan that defines roles and responsibilities, and CIS Controls v8.1 Safeguard 17.1 asks organisations to designate personnel to manage incident handling, with a backup.

Where incidents cross the three roles

The help desk scenario is not hypothetical. In the MGM Resorts breach, attackers said they gained initial access by phoning the IT help desk and impersonating an employee, then reached the identity platform; the lesson is that a process run by IT can be the decisive security control.

Typical organisation shapes

CISO reports to the CIO

Common in mid-sized organisations. Security is close to the engineers who fix things, so remediation is fast. The cost is independence: the CISO must report on the estate of their own manager. Banking supervisors have long flagged this conflict, as set out in Where Should the CISO Report. If you keep this shape, give the CISO a written right of direct access to the board or its risk or audit committee.

CISO and CIO as peers

The CISO reports to the CEO, COO, Chief Risk Officer or General Counsel. Challenge is stronger, but the CISO depends on influence and agreed service levels to get work done in IT. The decision rights matrix above matters most in this shape.

Converged CSO over CISO

Physical, personnel and cyber security sit under one executive. This helps with insider threat, site resilience and crisis management, where the evidence spans badge logs, CCTV and system logs. The risk is that a CSO from a physical background treats cyber as one workstream among many; mitigate by giving the CISO direct board reporting on cyber risk.

CSO as the CISO's title

One executive owns information security, and physical security sits with facilities or operations. This is a naming choice, not a structural one. Make sure contracts, policies and regulatory filings use the title consistently, because rules such as NYDFS 500.4 expect a designated CISO and will look for the person performing that function.

Small organisations and virtual CISOs

Small firms often have only a head of IT, with security as part of the role or bought from a provider. NYDFS 500.4 allows the CISO to be employed by an affiliate or a third-party provider, but the covered entity keeps responsibility and must assign senior staff to oversee the provider. The vCISO Guide covers how to set that arrangement up.

For the full set of structural options and their safeguards, see the Security Operating Model and Organisation Design Guide.

Where identity and AI risk land

Identity is the clearest example of a risk that is operated by one role and owned by another. The CIO's teams run the directory, the identity provider, the service desk and most service accounts; engineering teams create API keys, tokens and workload identities; the CISO is accountable for the identity security standard and for detecting misuse. Non-human identities are where this breaks most often: they have no line manager, so unless an owner is recorded at creation, nobody reviews or retires them.

• Human identity lifecycle: CIO and HR run joiner, mover and leaver processes; the CISO sets the standard and reviews evidence.
• Privileged access: CIO runs the tooling; CISO owns the policy and monitors use.
• Non-human identities: a named business or engineering owner per identity, with the CISO accountable for the inventory and review standard. See the NHI Ownership Guide.
• AI agents and models: ownership is often split between a CIO or Chief Data Officer running platforms, product teams building agents and a CISO securing them. Agents act with credentials, so treat each as an identity with an owner. Governance options are in the AI Governance Guide.
• Physical and logical access together: a converged CSO can tie badge revocation to account revocation at leaving, which closes a common gap.

The 2016 Uber breach shows both seams at once: an AWS access key exposed in a code repository was an engineering credential problem, and the handling of the extortion demand, paid through a bug bounty and not disclosed until a year later, became a question of who had authority over disclosure.

Decision guidance

• Choose a converged CSO when physical assets, people safety and insider risk are material (retail, logistics, energy, manufacturing, hospitality) and investigations regularly cross badge and system evidence.
• Keep the CISO separate from the CIO when a regulator expects independence (banking, insurance, regulated critical infrastructure), when the CISO's main job is oversight and challenge, or when audit findings on IT stay open for long periods.
• Keep the CISO under the CIO only when the CISO mainly runs security engineering and operations, remediation speed is the priority, and you add direct board access and a recorded overrule process.
• Use one title consistently if CSO and CISO are the same person; mixed usage confuses contracts, regulators and incident plans.
• In small organisations, name one accountable security lead even if the role is part time or outsourced, and keep the CIO from being the only person who signs off their own security.

How to agree the split: a phased approach

1. Inventory current reality. List who actually made the last ten security decisions and handled the last three incidents. The gap between the chart and practice is your starting point.
2. Draft the decision rights matrix. Use the table above, one accountable role per decision, and include identity, AI and third-party decisions explicitly.
3. Agree it at executive level. CEO, CIO, CISO, CSO, General Counsel and Chief Risk Officer sign it off. Disagreement here is cheaper than during an incident.
4. Write it into the instruments. Role descriptions, the incident response plan, the risk acceptance procedure, the security policy and the board terms of reference.
5. Test it in an exercise. Run a tabletop that crosses all three roles, such as ransomware with a physical access element. The UK Cyber Governance Code asks for exercises at least annually (action D2).
6. Review after every major incident and reorganisation. Change the matrix when people or structures change; if a key person leaves, see CISO Succession.

To roll back a change that is not working, keep the previous matrix on file and revert one decision row at a time rather than restructuring again.

Measuring whether the split works

• Time to declare: minutes from first credible alert to a declared incident with a named commander.
• Unowned risks: percentage of risk register entries without a named business owner (target zero).
• Overrules recorded: number of security decisions overruled, each with a documented risk acceptance by the accountable owner.
• Ageing findings by owner: open audit and security findings on IT-run platforms past due date.
• Non-human identity ownership: percentage of service accounts, keys and agents with a current named owner.
• Exercise actions closed: percentage of tabletop actions closed by the agreed date.

Common failure patterns

• The CISO as default risk owner. Every risk lands on the CISO, who cannot fund or change the systems concerned, so risks age and the business never sees them.
• Recovery overriding containment. The CIO restores quickly under pressure before scoping is complete, and the attacker returns.
• A CSO title with no defined cyber scope. Regulators, auditors and incident responders cannot tell who the designated security lead is.
• Disclosure decided by whoever is in the room. No predefined materiality process, so the clock runs while executives argue.
• Service desk processes outside security review. Password resets and MFA re-enrolment are run as IT efficiency processes and become the attack path.
• Machine identities with no owner. Keys and service accounts outlive the projects that created them because no role was accountable for retiring them.

Framework mapping

Practitioner checklist

• Confirm what CSO means in your organisation and use the title consistently in policies and filings.
• Publish a decision rights matrix with one accountable role per security decision.
• Name the incident commander, recovery owner, disclosure decision owner and communications lead, each with a deputy.
• Pre-agree a materiality and notification process with legal, mapped to NIS2, SEC or sector deadlines that apply.
• Give the CISO a written right of direct access to the board or a board committee.
• Record every overruled security decision as a risk acceptance by the accountable owner.
• Assign named owners to service accounts, API keys and AI agents, and review them.
• Bring service desk verification and reset processes under security review.
• Exercise a cross-role incident at least annually and track the actions.

Standards and references

• EUR-Lex: Directive (EU) 2022/2555 (NIS2), Articles 20 and 23
• NYDFS: 23 NYCRR 500.4 Cybersecurity governance
• US SEC: Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure fact sheet
• UK Government: Cyber Governance Code of Practice
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• Security Magazine: ASIS releases revised Chief Security Officer standard

Related NHI Mgmt Group resources: Where Should the CISO Report · CISO Guide: First 90 Days · Path to CISO Career Guide · Incident Response Guide · Physical and cyber security convergence