A Leader’s Guide to Insecure Software

A practical guide for boards and executive teams on software security risk management, vulnerability prioritisation, secure software procurement, software supply-chain risk, regulatory exposure and operational resilience.

Executive summary

Insecure software is an enterprise risk because it underpins customer journeys, operational processes and strategic transformation. A weakness in an internet-facing application, an overlooked open-source component, a supplier update or a poorly configured cloud service can interrupt revenue, expose personal data, compromise safety and undermine confidence in management. Effective software security risk management does not attempt to eliminate every vulnerability, which is neither realistic nor economically sensible. It identifies where insecure software could cause material harm, reduces the likelihood and impact of that harm, and demonstrates that decisions are informed, proportionate and accountable.

This guide is intended for boards, chief executives, chief information officers, chief information security officers, risk leaders, general counsel, procurement leaders and business owners. It translates software security into decisions about risk appetite, investment, ownership, suppliers, resilience and assurance. Its evidence base combines recognised security guidance and prioritisation resources from the UK National Cyber Security Centre, the US Cybersecurity and Infrastructure Security Agency, the US National Institute of Standards and Technology, MITRE, FIRST and the Information Commissioner’s Office; official NIS2 and Cyber Resilience Act texts; the British Library’s cyber-incident review and its 2023–24 and 2024–25 annual reports; and the US Federal Trade Commission’s Equifax case record.

The central message is simple: treating vulnerabilities as a queue of technical defects is inadequate. Leaders need a business-risk system that connects software assets to critical services, ranks weaknesses by likely exploitation and consequence, prevents recurring defects, sets explicit remediation expectations, imposes security requirements on suppliers, responds effectively to suspected compromise, tests recovery and reports exceptions in language the board can act upon. The six decisions below translate that system into an executive agenda.

Six decisions for senior leaders

1. Define material exposure. Identify the services, data, transactions and safety outcomes that would matter most if software failed or was compromised.
2. Prioritise using context. Combine technical severity with evidence of exploitation, external exposure, asset criticality, available controls and business impact.
3. Make ownership explicit. Assign accountable executives for critical services and require documented acceptance of material exceptions.
4. Build and buy secure software. Apply secure-by-design practices throughout the development lifecycle, and put vulnerability disclosure, support, transparency, update and incident obligations into procurement and contracts.
5. Design for failure and compromise. Segment systems, constrain privileges, preserve usable evidence, maintain recoverable backups, rehearse executive decisions and verify that important services can be restored to a trusted state.
6. Measure outcomes and confidence. Report material exposure, the age of unresolved risk, remediation performance, unsupported technology, supplier assurance, recovery capability and gaps in inventory or scanning coverage, not simply the number of vulnerabilities found.

1. Why software security risk is an enterprise risk

Software security is often presented as a contest between attackers and technical teams. That framing is too narrow. The more useful executive question is: which business outcomes depend on software behaving as intended, and what would happen if that trust were lost? The answer may include an unavailable customer portal, manipulated operational data, fraudulent payments, halted production, delayed clinical services, loss of intellectual property or an inability to meet contractual and regulatory obligations.

Modern organisations rarely control the whole technology stack. They depend on commercial applications, cloud platforms, managed services, open-source packages, application programming interfaces, embedded software and automated deployment pipelines. This creates scale and speed, but it also distributes control. A product can be securely configured and still inherit risk from a vulnerable dependency. A supplier can have strong corporate controls while a compromised build system distributes malicious code. A critical service can be well defended but still fail because an unsupported component cannot be patched.

Four forms of business harm

Operational disruption. Exploitation can make systems unavailable, corrupt data or force precautionary shutdowns. The immediate costs include lost transactions, idle staff, delayed services and emergency remediation. The larger cost can be the time required to establish whether systems are trustworthy before operations resume. Leaders should therefore consider maximum tolerable outage, manual workarounds, system interdependencies and recovery evidence when setting priorities.

Financial and contractual loss. Costs can arise from incident response, external advisers, customer support, restoration, compensation, litigation, higher insurance deductibles and lost sales. Contractual service levels, notification duties and warranties may create additional exposure. Financial modelling should not rely on a single average breach figure. It should use credible scenarios based on the organisation’s services, concentration risk, revenue dependencies and recovery capability.

Regulatory and legal exposure. UK data protection law requires appropriate technical and organisational measures for personal data. The ICO’s guidance on the data protection principles places integrity, confidentiality and accountability at the heart of compliance, while joint NCSC and ICO guidance emphasises resilience, restoration and regular testing. Within the EU, the NIS2 Directive includes governance, risk-management and supply-chain expectations for in-scope entities. The Cyber Resilience Act establishes lifecycle cybersecurity requirements for many products with digital elements. Applicability and duties vary, so legal advice should be based on the organisation’s role, markets, products and sector.

Strategic and reputational damage. A serious event can delay product launches, weaken a transaction, consume leadership attention and call executive judgement into question. Trust is affected not only by the incident, but by the quality of preparation and response. Organisations that cannot explain which systems were affected, what data was at risk, why controls failed or when services will recover create avoidable uncertainty for customers, regulators, investors and partners.

The British Library ransomware attack: business harm in practice

The 2023 ransomware attack on the British Library illustrates how an access-control weakness can combine with ageing technology to magnify business harm. The Library’s incident review records that attackers exfiltrated about 600GB of files, including personal data. They also encrypted data and systems and destroyed some servers, leaving the organisation without viable infrastructure on which to restore important services. The review also explains that the complexity and obsolescence of parts of the technology estate made recovery more difficult, with some applications unable to be restored on the replacement infrastructure. The Information Commissioner’s Office subsequently stated that the incident escalated because an administrator account lacked multi-factor authentication. The Library’s 2023–24 annual report describes the attack as a profound shock with a deep impact on the institution and its users, while its 2024–25 report confirms that continued recovery helped define the following year. For leaders, the lesson is that weaknesses in privileged access, legacy technology, service dependencies and recoverability can combine to turn an intrusion into a prolonged enterprise crisis.

The lesson from Equifax

The Equifax breach remains a useful leadership case because it connects vulnerability management to governance and consequence. The US Federal Trade Commission’s case record states that Equifax agreed to pay at least US$575 million, potentially up to US$700 million, in a settlement concerning allegations that it failed to take reasonable steps to secure its network. Separate FTC settlement information records that the incident exposed the personal information of 147 million people. The lesson is not simply “patch faster”. It is that discovery, asset ownership, escalation, verification and executive accountability must work together. A policy can require patching while unclear ownership, incomplete inventories or weak assurance leave exposure unresolved.

What good leadership looks like

Executives should expect software risk to be handled through the organisation’s established governance rather than isolated within security operations. Critical exposures should be visible alongside other enterprise risks. Decisions to defer remediation should name the accountable owner, business rationale, compensating controls, expiry date and escalation route. Significant software acquisitions should receive security and resilience scrutiny before commercial commitment. Product teams should be rewarded for reducing recurring classes of weakness, not only for shipping features quickly. Internal audit should periodically test whether reported controls and metrics reflect operational reality.

2. How to implement risk-based vulnerability management

Most large organisations can identify more vulnerabilities than they can remediate immediately. This is not necessarily a control failure. The failure occurs when prioritisation is arbitrary, driven only by a severity score, or disconnected from the business service at risk. A high technical score on an isolated laboratory system may matter less than a moderate weakness on an internet-facing identity service supporting a critical operation.

Risk-based vulnerability management prioritises remediation by combining technical severity with evidence of active exploitation, exploit likelihood, asset exposure, business criticality, potential impact and the effectiveness of compensating controls. This approach directs urgent action towards weaknesses that create the greatest credible business risk, rather than treating every technical finding as equally important.

The CISA Known Exploited Vulnerabilities Catalogue is designed to inform vulnerability-management prioritisation by identifying vulnerabilities with evidence of exploitation. The FIRST Exploit Prediction Scoring System estimates the probability that a published vulnerability will be exploited in the next 30 days. The MITRE CWE Top 25 looks beneath individual vulnerabilities to common and consequential weakness classes. Used together, these sources support better decisions, but none replaces knowledge of the organisation’s own assets and consequences.

A practical executive triage model

1. Is exploitation confirmed? Treat vulnerabilities on authoritative exploited lists, or linked to credible threat intelligence relevant to the organisation, as urgent until assessed.
2. Is the affected asset reachable? Identify internet exposure, privileged pathways, remote-access routes and connections to less trusted environments.
3. What business service depends on it? Link the asset to service owners, data, customers, safety obligations, revenue and recovery objectives.
4. What could an attacker achieve? Consider code execution, authentication bypass, privilege escalation, data access, service disruption and persistence.
5. Are effective mitigations available? Confirm whether configuration changes, feature disablement, access restrictions or monitoring materially reduce risk while a patch is tested.
6. How reliable is the evidence? Distinguish verified deployment and control data from assumptions, stale scans and vendor claims.

Service-level targets should reflect this model. For example, an exploited vulnerability on an internet-facing system supporting a critical service may require immediate containment and rapid remediation. A high-severity vulnerability on an internal, segmented system may have a longer target if there is no practical attack path. Exceptions should not become permanent. They need an owner, a defined control, a review date and an exit plan.

Asset and dependency visibility

Prioritisation fails without knowing what software is in use, where it runs and which services depend on it. Leaders should sponsor a minimum viable inventory that connects business services, applications, infrastructure, cloud resources, software components, suppliers, owners and support status. Perfect configuration data is not a prerequisite for action, but gaps covering critical services should be treated as risk.

A software bill of materials, commonly abbreviated to SBOM, is a structured inventory of the software components and dependencies contained in a product. It can help an organisation determine whether a newly disclosed vulnerability affects software it develops, buys or operates.

Used well, an SBOM can improve transparency, but it is not a certificate of security. Its value depends on accuracy, freshness, component identifiers, version information and the ability to map a newly disclosed vulnerability to deployed products. Procurement teams should ask how suppliers create, validate and update this information, and how quickly they can determine customer exposure.

Remediation means more than installing a patch

Patching can close a vulnerability, but it cannot be assumed to remove an attacker who exploited it beforehand. Where there is evidence of exploitation, the response may require forensic investigation, credential rotation, persistence checks, integrity validation and restoration from trusted sources. Leaders should require the response process to distinguish vulnerability closure from incident eradication. They should also ensure that emergency changes are tested for operational consequences, with rollback plans and clear authority to act.

For systems that cannot be patched promptly, management choices include restricting access, disabling vulnerable functions, isolating the asset, increasing monitoring, replacing the product or accepting a time-bound risk. Unsupported software deserves particular attention because the organisation may be unable to obtain a reliable remedy. A funded retirement plan is usually more credible than an indefinite exception.

3. Reduce software risk through secure-by-design practices and secure procurement

Vulnerability management often concentrates on defects already in production. That is necessary, but expensive. A stronger strategy also reduces the rate at which serious weaknesses are introduced. The NIST Secure Software Development Framework groups practices around preparing the organisation, protecting software, producing well-secured software and responding to vulnerabilities. The NCSC secure development guidance covers development environments, repositories, build pipelines, testing and planning for security flaws. CISA’s Secure by Design programme argues that manufacturers should take ownership of customer security outcomes and make secure defaults a core product requirement.

For executives, secure by design means treating customer security as a core product outcome rather than a tooling programme or a final technical check. Product and technology leaders define security requirements before architecture and delivery decisions become costly to change. Engineering teams use protected repositories, controlled build systems, peer review, automated testing, managed secrets and supported vulnerability-reporting processes. Proportionate security checks are integrated into normal product governance at design, release and major change points.

Reduce recurring weakness classes

Leaders should ask whether the same types of flaw repeatedly appear across products. The MITRE CWE Top 25highlights weakness classes such as injection, missing authorisation, path traversal and memory-safety errors. Repeated defects indicate a systemic problem in architecture, frameworks, training, testing or incentives. Treating each finding as an isolated ticket misses the opportunity to remove an entire class of risk.

Actions may include standardising approved authentication and authorisation components, adopting safer libraries, enforcing parameterised queries, improving input validation, strengthening code review and using memory-safe languages where proportionate. Rewriting all legacy software is rarely practical. A sensible roadmap begins with exposed, privileged and safety-critical components, and with new development where safer choices have the lowest transition cost.

Make the build environment part of the control system

A secure application can be compromised through the systems used to build and release it. The NCSC guidance on build and deployment pipelines recommends trusted pipelines, peer review and controls that protect code integrity. Senior leaders should therefore treat developer workstations, source repositories, package stores, signing keys, continuous integration platforms and deployment credentials as high-value assets.

Expected controls include strong authentication, least privilege, protected branches, review requirements, separation of duties for sensitive releases, tamper-evident logs, controlled dependencies, reproducible build practices where feasible and secure management of signing material. The objective is not bureaucracy. It is to make unauthorised changes difficult, visible and reversible while preserving delivery speed.

Turn procurement into a risk control

Many organisations inherit more software risk through purchasing than through internal development. Procurement should therefore evaluate security alongside functionality, price, service and financial stability. Requirements should be proportionate to the product’s role, connectivity, privileges and data access. A payroll platform, industrial control component and low-risk productivity tool should not receive identical scrutiny.

For important products and services, buyers should seek verifiable, and preferably audited, evidence on:

• secure development practices aligned with recognised guidance, such as the NIST SSDF;
• supported versions, security-update mechanisms and the minimum support period;
• secure default configuration, multi-factor authentication, logging and administrative separation;
• a public vulnerability disclosure process and clear routes for customer notification;
• dependency governance and the supplier’s ability to identify affected customers quickly;
• protection of source code, build pipelines, signing keys and release infrastructure;
• independent assurance relevant to the service, while recognising that certification is not proof of product security;
• incident notification, investigation support, evidence preservation and cooperation duties;
• subcontractor and cloud dependency transparency;
• data return, portability, transition assistance and secure deletion at exit.

Contracts should specify outcomes, evidence and remedies, not simply require the supplier to follow “industry best practice”. Useful clauses cover remediation targets, notification timeframes, supported versions, customer access to security advisories, audit rights, material changes to subcontractors and responsibility for emergency mitigations. Commercial teams should involve security and legal specialists early enough to influence the deal.

Prepare for changing product regulation

The European Commission’s overview of the Cyber Resilience Act explains that the regime introduces lifecycle cybersecurity duties for many hardware and software products made available in the EU. The Act includes essential requirements for design, development, production and vulnerability handling. Since 11 September 2026, manufacturers have been required to report actively exploited vulnerabilities and severe incidents affecting products with digital elements; the main obligations apply from 11 December 2027. Organisations that manufacture, import, distribute or substantially modify covered products should establish a cross-functional readiness programme involving product, engineering, legal, compliance, quality, incident response and market teams. Buyers should also anticipate that the regime will influence supplier evidence and market expectations beyond strict legal scope.

4. Manage software supply-chain risk and strengthen operational resilience

Software supply-chain risk arises when the development, delivery, maintenance or operation of software depends on components, systems or organisations that can introduce compromise or disruption. It is not confined to malicious updates. It also includes unsupported components, opaque dependencies, fragile update services, compromised developer accounts, concentration in a single provider and suppliers that cannot answer basic questions during an incident. The executive task is to understand where dependency creates systemic exposure and to avoid relying on contractual assurance alone.

Segment suppliers by business consequence

A tiering model should consider the service supported, data accessed, privileges held, connectivity, substitutability and recovery complexity. Critical suppliers merit deeper due diligence, named internal owners, current contacts, regular assurance and exercised incident arrangements. Lower-risk suppliers can receive streamlined review. The aim is to concentrate effort where supplier failure or compromise would have material impact.

Questionnaires are useful for initial screening, but they can encourage formulaic answers. Stronger assurance combines documentation, technical evidence, contract terms, external intelligence and operational testing. Where a supplier provides a critical service, leaders should know who can make decisions during an incident, how quickly the supplier will notify customers, what evidence it will share, whether logs are available, how updates are authenticated and what happens if the supplier itself becomes unavailable.

Manage concentrations explicitly

An organisation may have dozens of suppliers but still depend heavily on a small number of identity, cloud, endpoint, network or managed-service platforms. These concentrations can create common-mode failure across otherwise separate business services. Risk registers should identify such dependencies, including fourth parties that are material but not directly contracted.

Mitigation does not always require multiple suppliers. Dual sourcing can add complexity and may not be viable. Alternatives include stronger recovery arrangements, offline administrative access, tested data exports, independent backups, contractual priority during crises, architectural separation and the ability to operate essential processes in a degraded mode. The chosen treatment should be explicit and funded.

Assume preventive controls will sometimes fail

No software estate will be free of defects, and some attacks will succeed. Resilience therefore belongs in the software-security strategy. Network and identity segmentation can restrict lateral movement. Least privilege can reduce the value of stolen credentials. Application isolation can limit the reach of a compromised component. Protected, tested backups can support restoration. Central logging and synchronised time can improve investigation. Manual workarounds can preserve essential transactions while systems are recovered.

The NCSC and ICO security outcomes emphasise resilience, restoration and regular testing as elements of appropriate security. Leaders should ask for evidence that important services can be restored within agreed objectives, not merely that backups completed. Restoration exercises should include dependencies, credentials, configuration, data integrity, supplier availability and business acceptance.

Exercise technology failure as a business crisis

Exercises should involve executives, operations, technology, security, legal, communications, people teams and relevant suppliers. Scenarios might include an exploited edge device, a vulnerable enterprise application with no immediate patch, a compromised software update, a cloud service outage or discovery that a critical component is unsupported.

A useful exercise tests decisions, not just technical response. Who can isolate a revenue-generating platform? What business impact justifies emergency downtime? Who decides whether customer notification is required? Can the organisation determine affected products and versions? Does management have an alternative communication channel if normal collaboration tools are unavailable? Can the business operate safely while evidence is preserved? What information will the board need during the first day?

Lessons should become funded actions with owners and deadlines. Repeated findings, such as incomplete inventories, inaccessible logs or unclear authority, indicate governance failure rather than exercise administration. The board should receive confirmation when material actions are closed and independently verified.

Connect software risk to enterprise resilience

Software security should align with business continuity, operational resilience, crisis management and disaster recovery. Critical service mapping provides a shared foundation. It helps leaders understand which applications, suppliers, data flows and people support a business outcome. It also reveals where vulnerability remediation, continuity plans and recovery priorities are inconsistent.

A resilient organisation may still experience a security incident, but it can contain harm, make informed decisions, communicate credibly and restore essential services. That capability is a business asset. It reduces the leverage of attackers, limits the consequences of supplier failure and gives management more options than paying, improvising or remaining offline.

5. Establish software security governance, accountability and assurance

Resilience depends on governance that turns technical evidence into accountable business decisions. Good governance does not require the board to review vulnerability tickets. It requires the board to set expectations, ensure accountabilities are clear, challenge material exposure and confirm that management has credible resources and evidence. The chief information security officer may design and oversee the programme, but service owners, product leaders, technology executives, procurement and suppliers all control parts of the risk.

Allocate decision rights

A practical governance model distinguishes responsibility for finding weaknesses, assessing business impact, implementing remediation, validating closure and accepting residual risk. The person accepting a significant exception should have authority over the affected business outcome and should understand the consequence of delay. Security teams should advise and challenge, but they should not silently own risks created by another executive’s service or investment decision.

Material exceptions should specify the affected service, vulnerability or weakness, plausible impact, current exposure, compensating controls, remediation plan, accountable owner, approval date and expiry. Extensions should require fresh evidence and higher escalation where deadlines are repeatedly missed. This creates a disciplined alternative to informal deferral.

Report what leaders can act upon

A board dashboard should be concise but should not disguise uncertainty. Useful measures include:

• the proportion of critical services with verified asset, dependency and owner information;
• exploited vulnerabilities affecting critical or internet-facing assets, including age and containment status;
• remediation performance against risk-based targets, with trends and material exceptions;
• unsupported or end-of-life technology supporting important services;
• recurring software weakness classes and progress against prevention plans;
• critical suppliers lacking current assurance, incident contacts or contractual obligations;
• coverage and results of restoration, incident and crisis exercises;
• security debt that is increasing because of delayed modernisation or sustained delivery pressure;
• confidence in the underlying data, including scanning and inventory gaps.

Counts without context can reward the wrong behaviour. An increase in discovered vulnerabilities may reflect improved visibility rather than deterioration. A high closure rate may conceal a small number of severe, long-running exposures. “Zero overdue critical vulnerabilities” may be meaningless if assets are not comprehensively discovered. Metrics should therefore combine volume, consequence, age, coverage and confidence.

Use assurance to test the system

Management assurance should verify that critical applications are inventoried, scanning reaches the expected environment, prioritisation rules are working, exceptions are authorised, patches are truly deployed and supplier claims are supported. Internal audit can test governance, sampling evidence from discovery to closure. Independent technical testing can assess exposed services and important applications, while red-team or threat-led exercises can evaluate whether combined controls prevent or contain realistic attack paths.

Assurance should also test prevention. Product reviews can examine whether recurring weaknesses are reducing, high-risk code receives appropriate scrutiny and build controls cannot be bypassed. Procurement sampling can test whether required clauses and supplier evidence are present before contracts are signed. The objective is not to produce more reports; it is to identify where management’s picture differs from reality.

Fund the right capabilities

Investment decisions should balance immediate exposure reduction with long-term prevention. Scanning tools without asset ownership create queues. Application testing without engineering capacity produces backlogs. Supplier assessments without contractual leverage generate observations. Patch management without maintenance windows or redundancy creates operational conflict. Leaders should therefore fund the complete control system, including people, service mapping, engineering time, testing environments, modernisation, supplier management and recovery exercises.

Risk reduction should be visible in business terms. A proposal may reduce the window during which an exploited vulnerability leaves critical services exposed, remove unsupported technology from a revenue process, strengthen recovery from a compromised update or reduce recurring defects in a product family. Such outcomes are more valuable than tool deployment alone.

Regulation is a baseline, not the operating model

Software security regulation is a baseline for risk management, not a substitute for it. The NIS2 Directive includes governance and cybersecurity risk-management duties for covered entities, including supply-chain considerations. UK data protection requirements focus on measures appropriate to risk and the ability to demonstrate compliance. Product regulation such as the Cyber Resilience Act increases expectations for manufacturers and other economic operators. A control can meet a documented requirement and still be ineffective for a particular critical service.

Legal, compliance and security teams should maintain a common obligations map linked to controls, evidence, incidents and accountable owners. This reduces duplicate activity and helps the organisation explain its decisions. Where obligations differ by jurisdiction or product role, the organisation should identify the highest-impact gaps rather than assume one global statement covers every case.

6. A 90-day software security risk management plan

The preceding sections define the governance, prioritisation, procurement and resilience capabilities required to manage software risk. Leaders do not need to wait for a multi-year transformation before putting them into practice. The following 90-day plan creates immediate visibility and accountability while establishing foundations for a sustainable programme. It should be adapted to the organisation’s size, sector, architecture and risk appetite.

Days 1 to 30: establish the risk picture

1. Name an executive sponsor and accountable service owner Confirm who can resolve conflicts between operational availability, commercial priorities and urgent remediation.
2. Identify the most important services. Start with a manageable set tied to revenue, safety, regulated data, essential operations or significant customer commitments.
3. Map the supporting software and suppliers. Identify internet-facing assets, identity systems, privileged tools, remote-access paths, unsupported products and material dependencies.
4. Review active exposure. Compare the estate with the CISA Known Exploited Vulnerabilities Catalogue, relevant vendor advisories and credible sector intelligence. Confirm containment and remediation for affected critical assets.
5. Find urgent governance gaps. Look for exceptions without owners, critical systems without maintenance routes, suppliers without incident contacts and backups that have not been restored in testing.
6. Agree escalation thresholds. Define which conditions require immediate executive notification, such as confirmed exploitation, exposure of a critical service, inability to patch or evidence of compromise.

Days 31 to 60: strengthen control and accountability

1. Approve a risk-based remediation standard. Combine exploitation, reachability, criticality, impact and control effectiveness. Set target times and exception rules.
2. Create a critical-service dashboard. Include material exposures, the age of unresolved risks, unsupported technology, supplier gaps, recovery confidence and data-quality limitations.
3. Test one end-to-end remediation path. Trace a significant finding from discovery through ownership, change approval, deployment, verification and closure. Correct broken hand-offs.
4. Review priority supplier contracts. Add or plan security-update, notification, support, evidence, audit, subcontractor and exit provisions where risk justifies them.
5. Protect development and release systems. Verify strong authentication, privileged access controls, repository protection, code review, signing-key security and trustworthy build pipelines.
6. Select recurring weakness classes for reduction. Use internal findings and the CWE Top 25 to choose a small number of systemic prevention initiatives.

Days 61 to 90: prove resilience and set the roadmap

1. Run an executive exercise. Use a scenario involving exploited software or a compromised supplier update. Test operational, legal, customer and board decisions.
2. Restore a critical service from trusted sources. Validate recovery time, data integrity, credentials, configurations, supplier dependencies and business acceptance.
3. Review unsupported and unpatchable technology. Approve funded replacement, isolation or risk treatment plans with firm milestones.
4. Establish quarterly assurance. Sample critical vulnerabilities, exceptions, supplier evidence and application-security outcomes. Report discrepancies, not only compliance.
5. Approve a 12 to 24-month roadmap. Balance urgent exposure reduction with asset visibility, engineering prevention, platform modernisation, supplier assurance and workforce capability.
6. Communicate expectations. Make clear that secure software is a product-quality, service-resilience and business-accountability issue, not an obstacle owned by the security team.

Ten software security questions every board should ask

These questions should not be answered through unverified dashboards, periodic attestations or informal assurance. The board should expect evidence generated through controlled, auditable workflows; records that are reconciled to authoritative sources; automated decisions that can be traced and challenged; and independent validation that reported controls operate continuously and accurately. Each question should be directed to the named accountable leader, with corroboration from the relevant control and assurance functions.

1. Which business services would suffer the greatest harm from exploited or unavailable software, and when was that assessment last validated against current operations, dependencies and recovery objectives? Ask the chief operating officer and accountable business service owners, with challenge from enterprise risk and business continuity. Board cadence: quarterly, with annual formal revalidation and immediate reporting after a material service, dependency or risk change.
2. Can we continuously identify the software, components, suppliers and critical dependencies supporting those services, and what independent validation confirms that the underlying records are complete, current and accurate? Ask the chief information officer and enterprise architecture or configuration-management lead, with validation from internal audit or an independent assurance function. Board cadence: quarterly coverage and data-quality reporting, supported by continuous reconciliation, monthly management review and annual independent validation.
3. Do controlled, automated workflows continuously detect known exploited vulnerabilities on critical or internet-facing assets, create traceable remediation actions and verify closure against deployed reality rather than ticket status alone? Ask the chief information security officer and head of vulnerability management, with confirmation from technology operations and service owners. Board cadence: quarterly trend and exception reporting, with continuous monitoring, monthly executive review and immediate escalation of confirmed exploitation or overdue material exposure.
4. Who is authorised to accept a material remediation delay, and does the workflow create an auditable record of the rationale, evidence, compensating controls, approval, expiry and subsequent review? Ask the accountable business executive and chief risk officer, with oversight from the chief information security officer, legal and compliance. Board cadence: quarterly reporting of active material exceptions and ageing, with immediate escalation of any exception outside risk appetite or approaching expiry without an approved treatment.
5. Which critical products are unsupported, difficult to patch or dependent on a single supplier, and how do we verify continually that lifecycle, ownership and dependency records match the technology actually in use? Ask the chief information officer, chief technology officer and accountable service owners, with evidence from asset, procurement and supplier-management records. Board cadence: quarterly reporting of material exposures and funded treatment plans, supported by monthly management review and immediate escalation if support ends or a critical dependency becomes unavailable.
6. What continuously refreshed and independently tested evidence shows that critical suppliers can identify customer exposure, issue trustworthy updates, preserve relevant records and support us effectively during an incident? Ask the chief procurement officer and supplier-risk lead, with challenge from the chief information security officer, legal and internal audit. Board cadence: quarterly reporting on critical-supplier assurance and exceptions, annual deep-dive review, and immediate notification of a material supplier incident or adverse assurance finding.
7. Have we repeatedly tested restoration of an important service after compromise, and do auditable results verify that data, configurations, credentials and dependencies can be restored to an accurate and trusted state within agreed objectives? Ask the chief operating officer and chief information officer, supported by business continuity, disaster recovery, security operations and the relevant service owner. Board cadence: quarterly reporting on exercise coverage, unresolved findings and recovery confidence, with at least annual testing of each critical service and immediate escalation of failed tests or material recovery gaps.
8. Which recurring software weakness classes are we preventing, and what validated trend data demonstrates that recurrence is falling across products, releases and suppliers rather than merely being recorded differently? Ask the chief technology officer and product or engineering leaders, with independent analysis from application security and quality assurance. Board cadence: quarterly trend reporting for material products and services, supported by monthly engineering review and annual independent validation of measurement methods and outcomes.
9. What continuous, independently validated evidence proves that reported patches, configurations and compensating controls are deployed, effective and accurately reflected in our systems of record? Ask the chief information officer and chief information security officer, with verification from control owners, security testing and internal audit. Board cadence: quarterly assurance reporting, supported by continuous control monitoring, monthly exception review and annual independent testing of a representative risk-based sample.
10. Where do commercial, delivery or incentive structures encourage teams to defer security work, and what auditable governance workflow detects, escalates and corrects those conflicts before risk accumulates? Ask the chief executive, chief financial officer, chief operating officer and chief people officer, with evidence from portfolio governance, enterprise risk and internal audit. Board cadence: quarterly portfolio and risk review, annual remuneration and incentive-design review, and immediate escalation where a material delivery or commercial decision would move exposure outside risk appetite.

Conclusion

Insecure software is a foreseeable enterprise risk. Its consequences can cross operations, finance, legal duties, customer trust and strategy in a matter of hours. The response is not to demand that every defect be fixed immediately or to purchase another dashboard. It is to build the coherent system described in this guide: identify what matters, prioritise credible threats, allocate ownership, build and buy more secure software, prevent recurring weaknesses, assure suppliers and preserve the ability to operate when controls fail.

The strongest organisations will treat software security as an expression of product quality and operational resilience. They will expect manufacturers and suppliers to provide secure defaults, transparent support and timely vulnerability handling. They will give engineering teams the time and platforms needed to prevent defects. They will make risk acceptance explicit, temporary and evidence-based. Above all, they will measure whether critical services are becoming less exposed and more recoverable.

The board’s role is not to manage patches. It is to ensure that management can answer three questions with credible evidence: where could insecure software cause material harm, what is being done about it, and can the organisation continue to deliver its most important services if prevention fails?

References and further reading (much more here)

References and Further Reading (much more here)

The following sources are referenced in the article and provide authoritative guidance for leaders, technology teams, risk functions and procurement professionals.

• UK National Cyber Security Centre, Secure development and deployment guidance. Eight principles covering secure development environments, code repositories, build pipelines, testing and planning for security flaws.
• UK National Cyber Security Centre, Secure the build and deployment pipeline. Practical guidance on trusted pipelines, code integrity, peer review and secure deployment.
• UK National Cyber Security Centre and Information Commissioner’s Office, GDPR security outcomes.Outcomes for appropriate technical and organisational measures, resilience, restoration, testing and accountability.
• Cybersecurity and Infrastructure Security Agency, Secure by Design. Executive ownership, secure defaults and shifting responsibility towards technology manufacturers.
• Cybersecurity and Infrastructure Security Agency, Known Exploited Vulnerabilities Catalogue. An authoritative input for prioritising vulnerabilities with evidence of exploitation.
• National Institute of Standards and Technology, Secure Software Development Framework, SP 800-218.High-level practices for preparing organisations, protecting software, producing secure software and responding to vulnerabilities.
• MITRE, CWE Top 25 Most Dangerous Software Weaknesses. A strategic view of recurring weakness classes that can guide investment and prevention.
• Forum of Incident Response and Security Teams, Exploit Prediction Scoring System. A data-driven estimate of the probability that a published vulnerability will be exploited in the following 30 days.
• Information Commissioner’s Office, Guide to the data protection principles. UK guidance on integrity, confidentiality, accountability and the wider data protection principles.
• European Union, Directive (EU) 2022/2555, NIS2. The official legal text covering governance, cybersecurity risk management, supply-chain security, reporting, supervision and enforcement for in-scope entities.
• European Union, Regulation (EU) 2024/2847, Cyber Resilience Act. The official legal text establishing cybersecurity requirements for products with digital elements and vulnerability-handling obligations.
• European Commission, Cyber Resilience Act overview. A plain-language summary of policy objectives, timing and lifecycle duties.
• British Library, Learning lessons from the cyber-attack. The Library’s incident review covering the attack, exfiltration, technology impact, recovery constraints and lessons learned.
• Information Commissioner’s Office, statement on the British Library cyber attack. The regulator’s account of the identity-control weakness that enabled the incident to escalate.
• British Library, Annual Report and Accounts 2023–24. The official annual report describing the attack’s profound impact on the institution, its users and operations.
• British Library, Annual Report and Accounts 2024–25. The official annual report confirming that cyber recovery and technology transition remained defining organisational priorities.
• US Federal Trade Commission, Equifax case record. Primary regulatory material concerning the settlement following the 2017 breach.
• US Federal Trade Commission, Equifax Data Breach Settlement. Primary FTC information confirming that the breach exposed the personal information of 147 million people and summarising consumer relief.

Disclaimer

This article provides general information and leadership guidance. It is not legal, regulatory, financial or technical advice for a particular organisation. Requirements and appropriate controls depend on jurisdiction, sector, product role, contractual commitments, architecture and risk. Organisations should obtain professional advice for their circumstances and verify the current status of laws, guidance and threat information.