Most security controls are built and run by teams that report to the CIO or the CTO, yet many organisations still write security accountability as if the CISO did the work. The result is familiar: a CISO held responsible for a production platform they do not control, an engineering organisation that treats security findings as someone else's backlog, and gaps where enterprise IT and product engineering each assume the other owns cloud accounts, CI/CD or service accounts. This guide sets out what the CIO and the CTO should own for security across platform, engineering, the software development life cycle and infrastructure, where the CISO sets the standard and checks the result, and how to agree and measure the split. It is for CIOs, CTOs, CISOs and the executives who design their mandates. Role definitions and incident ownership are covered in CISO vs CSO vs CIO; this page goes into the technology leaders' side of the line.
Key takeaways
- Whoever runs the system owns its controls in operation. The CIO owns security of enterprise IT, the CTO owns security of the product and the platform it runs on, and the CISO owns the standard, the risk view and independent verification.
- The CTO owns secure development, not just delivery speed. Secure design, dependency management, CI/CD integrity and vulnerability remediation in code are engineering outcomes; CISA's Secure by Design material says ownership of customer security outcomes must be taken at the executive level.
- Cloud and identity are where CIO and CTO boundaries fail. Corporate cloud and production cloud, workforce identity and service accounts, each need one named accountable executive.
- Regulation reaches the whole management body. NIS2 Article 20 and DORA Article 5 place approval and oversight of cyber and ICT risk on management bodies, so technology leaders cannot treat security as a delegated specialism.
- Write it down as a RACI with one A per row. Then measure it with metrics the CIO and CTO report themselves, not metrics the CISO reports about them.
Why technology leaders carry security accountability
Three ideas from current frameworks and regulation set the boundary.
- Leadership is accountable, not just the security function: NIST CSF 2.0 GV.RR-01 states that organisational leadership is responsible and accountable for cybersecurity risk, and GV.RR-02 that roles, responsibilities and authorities are established, communicated, understood and enforced. The CIO and CTO are part of that leadership.
- Management bodies approve and oversee: NIS2 Article 20(1) requires the management bodies of essential and important entities to approve the cybersecurity risk-management measures, oversee their implementation and be liable for infringements; Article 20(2) requires their members to follow training. In financial services, DORA Article 5(2)(a) gives the management body ultimate responsibility for managing ICT risk, including approving the digital operational resilience strategy and setting ICT risk tolerance.
- Control functions are independent of delivery: DORA Article 6(4) requires ICT risk management and oversight to sit in a control function with sufficient independence to avoid conflicts of interest, separated from internal audit, under the three lines of defence or an equivalent model. In practice the CIO and CTO organisations are the first line that runs controls; the CISO is often the second line that sets and checks them.
- Executive ownership of product security: CISA's Secure by Design programme says every technology provider must take ownership at the executive level and claim ownership of customers' security outcomes, treating security as a core business requirement rather than a technical feature. For a software company, the executive who owns the product and engineering organisation is usually the CTO.
- Boards expect named owners: the UK Cyber Governance Code of Practice (8 April 2025) asks boards to agree senior ownership of cyber security risks (action A2) and to define roles and responsibilities, including ownership at executive and non-executive level (action E1). See the UK Cyber Governance Code of Practice Guide.
The three mandates compared
Titles vary between organisations; the table describes the most common split in an organisation that has a CIO, a CTO and a CISO who is a peer of both or reports to the CEO, COO or CRO.
| Aspect | CIO | CTO | CISO |
|---|---|---|---|
| Estate | Enterprise IT: end-user devices, corporate network, collaboration and business SaaS, ERP, workforce identity, data centres | Product and production: application code, production cloud accounts, CI/CD, platform engineering, customer-facing APIs | No estate of its own beyond security tooling; covers both |
| Security role | Builds and runs controls on enterprise IT | Builds security into products and runs controls on the production platform | Sets policy and control standards, assesses risk, verifies, leads incident command |
| Typical line | First line | First line | Second line in larger or regulated organisations |
| Owns the budget for | Enterprise security controls embedded in IT platforms (EDR deployment, patching, backup) | Product security engineering capacity, secure pipeline tooling, production hardening | Security operations, assurance, testing, specialist tooling |
| Evidence they produce | Patch compliance, access review completion, backup restore tests | Remediation times for code and container findings, pipeline integrity, threat models per release | Risk register, control test results, exceptions log, board reporting |
| Main conflict of interest | Availability and cost against hardening | Release velocity against security work | Independence if reporting to the CIO or CTO |
Where the CISO reports to the CIO or CTO, independence weakens because the person who sets the standard reports to a person measured on delivery; see Where Should the CISO Report.
Ownership RACI: platform, engineering, SDLC and infrastructure
A is accountable (exactly one per row), R responsible, C consulted, I informed. "Business owner" is the executive who owns the service or product line. Adapt the rows, but keep one A.
| Domain and decision | CIO | CTO | CISO | Business owner |
|---|---|---|---|---|
| Security architecture standards for all technology | C | C | A | I |
| Secure design and threat modelling of product features | I | A | C (method, review of high-risk designs) | C |
| Secure coding standard and developer training | I | R | A (standard) | I |
| SAST, SCA, secrets scanning in pipelines: running and fixing | I | A | C (tool choice, thresholds) | I |
| CI/CD integrity: build systems, signing, pipeline credentials | I | A | C | I |
| Remediating vulnerabilities in product code and containers | I | A | R (verification, SLA tracking) | I |
| Production cloud accounts, landing zone and guardrails | C | A | C | I |
| Corporate cloud and business SaaS configuration | A | I | C | C |
| Patching servers, endpoints and network devices in enterprise IT | A | I | R (verification) | I |
| Workforce identity, SSO and MFA | A | C | C (standard) | I |
| Service accounts, API keys and workload identities in production | I | A | C | I |
| Logging pipeline to the SOC from enterprise IT and production | R (enterprise sources) | R (production sources) | A (coverage requirements) | I |
| Backup and recovery of enterprise systems | A | I | C | C (recovery priorities) |
| Resilience and recovery of the production platform | I | A | C | C |
| Technology supplier security due diligence | R (IT suppliers) | R (engineering suppliers, open source) | A (method) | C |
| Accepting a security exception on enterprise IT | A | I | C (records challenge) | C |
| Accepting a security exception on product or production | I | A | C (records challenge) | C |
| Penetration testing scope and remediation | R (fix) | R (fix) | A (scope, independence) | I |
Exceptions are split by estate so each row keeps a single A, within the risk appetite the business owner and board have set. For the operational version of this matrix covering patching, accounts, keys, logging and backups at system level, use the IT and Security RACI Template.
What the CTO owns in the software development life cycle
NIST SP 800-218, the Secure Software Development Framework (version 1.1, February 2022), groups practices into four areas. Each maps to a CTO-run activity, with the CISO in a standard-setting and verification role.
| SSDF practice group | CTO owns | CISO contributes | Evidence the CTO should be able to show |
|---|---|---|---|
| Prepare the Organization (PO) | Engineering roles, toolchains, secure environments for development | Security requirements and policy | Named security champions per team, toolchain inventory |
| Protect the Software (PS) | Source code access control, build integrity, release signing, archives of releases | Requirements for signing and provenance | Branch protection settings, signed release artefacts, build provenance |
| Produce Well-Secured Software (PW) | Secure design, code review, testing, secure defaults, third-party component choices | Threat modelling method, test standards | Threat models for significant changes, test coverage, SBOM per release |
| Respond to Vulnerabilities (RV) | Fixing and releasing patches, root cause analysis in code | Disclosure policy, severity rating, verification | Remediation time by severity, recurrence rate |
The practice detail is in the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide, and the difference between protecting applications and owning product security outcomes is in Application Security vs Product Security.
Infrastructure and platform: drawing the CIO and CTO line
- Corporate versus production cloud: assign each cloud organisation, account, subscription or project to one executive at creation. A common split gives the CIO everything that hosts internal business systems and the CTO everything that serves customers, with shared guardrails (organisation policies, logging, identity federation) owned by whichever platform team runs the cloud organisation root.
- Platform engineering: internal developer platforms concentrate privilege, because the platform team holds the credentials that deploy everything. The CTO owns the platform and its paved-road defaults; the CISO sets the controls the paved road must enforce. See Platform Engineering Security.
- Shared services: DNS, certificates, network edge and the SIEM are often consumed by both estates. Give each one owner and publish a service catalogue entry with the security responsibilities of consumers, following the same logic as a cloud provider's model in the Shared Responsibility Models Guide.
- Mergers and new products: a new estate must be assigned to the CIO or CTO before integration starts, otherwise it stays unowned for years.
Where identity fits
Identity is the clearest test of whether the split works. Workforce identity usually sits with the CIO; production service accounts, deployment credentials, API keys and agent identities are created by engineering and usually have no owner at all. Assign the CTO accountability for non-human identities in production, the CIO for those in enterprise IT, and the CISO for the standard (rotation, scoping, inventory). Record an owner for every non-human identity at creation using the NHI Ownership RACI.
Decision guidance by organisation shape
| Shape | Typical split | Watch for |
|---|---|---|
| Start-up without a CISO | CTO is the de facto security owner for both product and corporate IT | No independent check: use an external assessor or vCISO for verification and get board sight of risk |
| Scale-up with CTO and a first CISO | CTO owns product and production, CISO owns standards and security operations, IT reports to the CTO or COO | CISO reporting to the CTO; agree an escalation route to the CEO or board |
| Enterprise with CIO and CTO | CIO owns enterprise IT, CTO owns digital products, CISO is a peer of both | Cloud, identity and shared services falling between CIO and CTO |
| Enterprise with CIO only | CIO owns all technology including in-house software | Software security treated as an IT project rather than an engineering discipline; name a head of product security under the CIO |
| Regulated financial entity | CIO and CTO as first line, CISO or ICT risk function as second line, internal audit as third | DORA Article 6(4) independence if the CISO sits inside the CIO organisation |
How to agree the split: a phased approach
- Inventory estates: list every platform, cloud organisation, pipeline, shared service and class of non-human identity, with its current de facto owner.
- Draft the RACI: start from the table above; the CISO drafts, the CIO and CTO each mark rows they dispute.
- Resolve disputes at executive level: the CEO or COO decides contested rows; do not let rows stay with two As.
- Write it into mandates: add security outcomes to the CIO and CTO role descriptions and objectives, and security capacity to their budgets, consistent with GV.RR-03 on adequate resources.
- Pilot for one quarter: run exceptions, vulnerability SLAs and access reviews under the new split, and log every case where ownership was unclear.
- Adjust and publish: fix the unclear rows, publish the matrix and link it from the security policy.
- Review annually and on change: reorganisations, acquisitions and new product lines trigger a review. If a split fails in practice, revert the affected rows to the previous owner while the dispute is resolved rather than leaving them unowned.
Measuring whether the split works
- Critical vulnerability remediation within SLA, by estate: reported by the CIO for enterprise IT and by the CTO for product, verified by the CISO.
- Percentage of cloud accounts and pipelines with a named accountable executive: target 100%.
- Non-human identities with a recorded owner: percentage in production and in enterprise IT.
- Open security exceptions past expiry, by accountable executive.
- Share of significant releases with a completed threat model.
- Incidents or audit findings where root cause included unclear ownership: should trend to zero.
Report these through the board pack rather than as a CISO scorecard of other executives; see the Board Cyber Risk Reporting Guide.
Common failure patterns
- The CISO as default owner: every risk lands on the CISO, who cannot fund or change the systems, so findings age and the CISO is accountable for decisions taken elsewhere.
- Security findings as a separate backlog: engineering treats vulnerabilities as security team tickets instead of product defects, so they lose every prioritisation against features.
- Unowned production cloud accounts: accounts created by individual teams outside the landing zone with neither the CIO nor the CTO accountable.
- Pipeline credentials owned by nobody: CI/CD tokens and deployment keys with broad reach, created by engineers who have since left, with no rotation.
- Two As on shared services: DNS, certificates or identity federation run jointly, so changes and incidents stall while owners negotiate.
- Mandates without budget: security outcomes added to CIO and CTO objectives with no capacity, so they are traded away at the first deadline.
Framework mapping
| Framework | Reference | Relevance to the CIO and CTO split |
|---|---|---|
| NIST CSF 2.0 | GV.RR-01, GV.RR-02, GV.RR-03 | Leadership accountability, defined roles and authorities, adequate resources |
| NIST CSF 2.0 | GV.SC-02 | Roles and responsibilities for suppliers, customers and partners |
| NIST SP 800-53 Rev 5 | PM-2, PM-29 | Information security programme and risk management programme leadership roles |
| NIST SP 800-53 Rev 5 | SA-3, SA-8, SA-15 | System development life cycle, security engineering principles, development process and tools, owned by engineering |
| NIST SP 800-53 Rev 5 | PS-9 | Security roles written into position descriptions |
| NIST SP 800-218 | PO, PS, PW, RV | CTO ownership of secure development practices |
| NIS2 | Article 20 | Management body approval, oversight, liability and training |
| DORA | Articles 5 and 6(4) | Management body responsibility for ICT risk; independent control function |
| UK Cyber Governance Code | A2, E1 | Senior ownership of cyber risks; executive ownership in the governance structure |
Practitioner checklist
- Publish a security RACI covering platform, engineering, SDLC and infrastructure with exactly one A per row.
- Assign every cloud organisation, account and pipeline to the CIO or the CTO at creation.
- Write security outcomes and capacity into CIO and CTO role descriptions, objectives and budgets.
- Make the CTO accountable for vulnerability remediation in product code and the CIO for enterprise IT, with CISO verification.
- Give production non-human identities an accountable executive and a recorded owner.
- Give each shared service (DNS, certificates, federation, SIEM) a single owner.
- Check the CISO's reporting line and escalation route for independence from delivery.
- Report ownership metrics to the board through the risk report, owned by each executive.
- Review the split annually and after every reorganisation or acquisition.
Standards and references
- EUR-Lex: Directive (EU) 2022/2555 (NIS2)
- EUR-Lex: Regulation (EU) 2022/2554 (DORA)
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-218 Secure Software Development Framework Version 1.1
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- CISA: Secure by Design
- GOV.UK: Cyber Governance Code of Practice
Related NHI Mgmt Group resources: CISO vs CSO vs CIO · CISO Guide: First 90 Days · Where Should the CISO Report · DevSecOps Guide