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 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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.