Who is accountable when a defense supplier cannot demonstrate required cybersecurity controls to a customer or assessor?

Why accountability for missing cybersecurity evidence sits above the security team

When a defence supplier cannot show required cybersecurity controls to a customer or assessor, the issue is usually larger than a failed audit packet. Accountability sits with the organisation that claims the control environment, because evidence, funding, ownership, and maintenance are management responsibilities. Security teams can assemble artefacts, but they cannot substitute for leadership decisions about scope, investment, and operational discipline. For defence work, that distinction matters because contract eligibility and trust often depend on demonstrable control performance, not just stated intent.

That is why a missing control demonstration is often treated as a governance failure as well as a technical one. If leadership has not assigned control owners, required testing, or evidence retention, the organisation may still have tools in place but no defensible proof that those tools work. For a customer or assessor, absence of evidence can be functionally equivalent to absence of control. CISA cyber threat advisories show how quickly control gaps become operationally meaningful when threats and exposure converge. In practice, many defence suppliers discover that control accountability was never clearly owned until a customer asked for proof, not while the programme was being run.

What “accountable” means in a defence supply chain assessment

Accountability in this context means more than being blamed after the fact. It means a named part of the organisation must be able to explain the control objective, produce evidence, and show that the control is operating as intended. Program leadership typically owns the commitment to the customer, executive leadership owns the resourcing and governance, and control owners own the implementation and evidence trail. Security operations may support all three, but they are rarely the sole accountable party.

The practical test is whether the organisation can answer three questions without improvising: what the control is supposed to prove, who owns the proof, and how that proof is maintained over time. If a supplier can only point to tools, screenshots, or a one-time assessment, that is not the same as sustained assurance. Defence customers and assessors usually care about repeatability, not just a point-in-time claim.

• Controls must be mapped to an owner who can explain both operation and evidence.
• Evidence must show maintenance, not just deployment.
• Leadership must back the control with funding, change management, and retention practices.
• Exceptions should be documented before the assessment, not discovered during it.

The guidance is strongest when the issue is a missing or weak control demonstration, but it becomes less clear when accountability is split across prime contractors, subsidiaries, and shared service providers.

Where supplier accountability becomes contested or breaks down

Tighter assurance requirements often increase administrative overhead, so organisations have to balance customer confidence against the effort needed to keep evidence current. The most common edge case is a supplier that operates controls through a managed service provider or group function and assumes that outsourcing also outsources accountability. It does not. The supplier still needs to show who owns the control, who reviews the evidence, and who can respond when the assessor asks follow-up questions.

Another frequent ambiguity appears when a programme owner believes cybersecurity is “owned by security” while the security function believes business leadership owns the customer obligation. That split creates a gap between operational control and contractual accountability. Guidance versus consensus also matters here: some organisations treat the CISO as accountable by default, but that is an internal convention rather than a universal rule. In defence supply chains, accountability usually follows the contractual promise and the management chain behind it, not the org chart alone.

ISO/IEC 27002:2022 Information Security Controls is useful here because it reinforces that control ownership, policy, and evidence need to be managed as part of the security programme, not improvised during assessment. Where the supplier cannot show a stable evidence trail, the assessment problem is often really an operating model problem. The guidance breaks down when accountability is undocumented, controls are inherited without review, or no one can explain who must fix a failed control before the next customer review.

Practitioner Guidance

What to prioritise: Identify the named owner for each control the customer or assessor expects to see, then separate operational ownership from executive accountability. The fastest way to reduce ambiguity is to tie each required control to a person or function that can answer evidence questions without escalation.

What to verify: Confirm that each control has current evidence for design, operation, testing, and retention. If the only proof is a tool screenshot or a passed scan, treat that as incomplete until a reviewer can trace it back to the business process, review cycle, and exception record.

Common mistake: Treating cybersecurity evidence as a security-team task instead of a programme obligation. That shortcut usually fails when a customer asks how the supplier knows the control still works after change, staffing turnover, or outsourcing.

Practitioner takeaway: In a defence supply environment, the failure to demonstrate controls is usually a management-control problem first and a tooling problem second, so the accountable party is the one with authority to fund, assign, and enforce proof.

Related resources from NHI Mgmt Group

• Who is accountable when a service provider cannot demonstrate adequate controls over customer data?
• What happens when a Microsoft supplier cannot demonstrate compliance with the required DPR controls?
• Who is accountable when a startup misses required cybersecurity controls for cyber insurance underwriting?
• What is the difference between human IAM controls and NHI governance?