Who is accountable when exposed assets are left without WAF protection?

Accountability should sit with the team that owns the asset and the security function that governs external exposure standards. If the asset is absent from inventory, accountability has already failed at the governance layer. The fix is ownership assignment, exception tracking, and regular exposure reconciliation.

Why This Matters for Security Teams

When exposed assets are left without WAF protection, the issue is rarely just a missing control. It is usually a breakdown in asset ownership, security gating, and change governance. A WAF is one layer in a broader exposure management model, but if a public-facing service is deployed without it, the organisation has already lost control of how that service entered production. The accountability question matters because gaps often persist between infrastructure teams, application owners, and central security, with each assuming someone else validated the exposure path.

This is where governance frameworks help translate a technical miss into an accountable process. The NIST Cybersecurity Framework 2.0 emphasises governance, risk management, and protection outcomes that should be mapped to externally reachable services. In practice, that means asset inventory, risk acceptance, and compensating controls need named owners before internet exposure is approved. Security teams also need to recognise that modern attacks increasingly target exposed application layers quickly after discovery, as highlighted in the Anthropic report on an AI-orchestrated cyber espionage campaign, which reinforces the operational cost of leaving edges unprotected.

In practice, many security teams discover missing WAF coverage only after an asset has already been indexed, probed, or abused, rather than through intentional exposure review.

How It Works in Practice

Accountability for WAF coverage should be assigned at two levels: the asset owner is responsible for ensuring the service meets the organisation’s external exposure standard, and the security or platform team is responsible for defining and enforcing that standard. Those responsibilities are different. The owner should know whether the service is internet-facing, what data it processes, and whether exceptions are approved. The security function should set the baseline, verify enforcement, and escalate deviations.

Operationally, the cleanest model is to treat WAF protection as a required control for defined exposure tiers, not as an optional add-on. That usually means:

• Maintaining a reliable inventory of public assets and their owners.
• Mapping each asset to an exposure policy, including mandatory WAF use where applicable.
• Recording exceptions with expiry dates, compensating controls, and named approvers.
• Rechecking exposure after deploys, DNS changes, cloud migrations, and acquisitions.
• Logging control failures so they can feed incident response, risk reporting, and remediation tracking.

NIST control guidance in NIST SP 800-53 Rev. 5 Security and Privacy Controls is useful here because it ties together asset management, boundary protection, monitoring, and configuration enforcement. In practical terms, the point is not that every workload must use the same WAF product, but that every externally exposed asset must be reviewed against an approved protection standard before it is live.

Where identity intersects, the same accountability model should apply to service identities, API gateways, and automation accounts that create or publish exposure. If an automated pipeline can spin up a public endpoint, then the pipeline owner and the platform security team need explicit controls around policy checks, exception handling, and rollback. These controls tend to break down when cloud teams can create internet-facing services outside central release gates because exposure tracking lags behind deployment speed.

Common Variations and Edge Cases

Tighter exposure control often increases deployment friction, requiring organisations to balance faster release cycles against stronger pre-production checks. That tradeoff is real, especially in engineering environments that rely on self-service infrastructure and frequent releases.

There is no universal standard for this yet, but current guidance suggests the answer changes depending on why the WAF is missing. If the asset was never classified as internet-facing, the failure is usually inventory and discovery. If the asset was classified but not protected, the failure is policy enforcement. If a WAF was intentionally bypassed for testing or performance reasons, the failure is exception governance.

Some environments also complicate accountability:

• Shared platforms: a central platform team may operate the gateway, but individual product teams still own the risk of their workloads.
• Managed services: a cloud provider may support edge filtering, yet the customer remains accountable for policy decisions and review.
• API-only services: the control may be an API gateway or bot protection layer rather than a traditional WAF, but the accountability model is the same.
• Merged estates: after acquisitions, ownership often breaks down because inventories, routing, and security tooling are not aligned.

The practical test is simple: if no named owner can explain why an exposed asset is outside the WAF standard, accountability has not been assigned correctly. The right remediation is not only technical deployment, but ownership correction, exception expiry, and continuous exposure reconciliation.

Related resources from NHI Mgmt Group

• Who is accountable when a shared device is left signed in and data is exposed?
• Who is accountable when seized digital assets are moved without authorisation?
• Who is accountable when an internet-exposed service is left reachable after change?
• Who is accountable when a privileged appliance login path is left exposed?