Who is accountable when a phishing attack bypasses prevention and the affected apps do not provide usable logs?

Accountability sits with the security function that owns detection, response, and identity governance, because the failure is often a visibility and control gap rather than a single missed alert. Teams should define which logs are required, which apps are in scope, and how rapidly suspicious sessions, credentials, and connected apps must be contained.

Why This Matters for Security Teams

When phishing bypasses prevention and the affected apps cannot produce usable logs, the failure is no longer just email security. It becomes an identity, detection, and response problem: teams cannot prove what happened, cannot scope blast radius quickly, and cannot confidently contain connected sessions or tokens. That is why accountability normally lands with the security function that owns detection, response, and identity governance, not with the user who clicked.

This is also where visibility gaps become operationally dangerous. NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now notes that only 5.7% of organisations have full visibility into their service accounts, which is a warning sign for any environment that depends on app-level telemetry to investigate compromise. In practice, many security teams encounter account takeover only after access has already been used to move laterally or trigger downstream abuse, rather than through intentional detection.

Current guidance suggests treating missing logs as a governance defect, not an excuse. If an application cannot support incident reconstruction, the security owner must define compensating controls, including identity-layer telemetry, session revocation, and strict containment playbooks. The broader pattern is echoed in The 52 NHI breaches Report and reinforced by CISA cyber threat advisories, which consistently show that detection gaps turn routine credential theft into enterprise-scale incidents.

How It Works in Practice

In a mature operating model, accountability is assigned to the team that can actually answer four questions: what was accessed, which identity or token was used, what connected systems were touched, and what must be revoked immediately. That means detection cannot depend solely on the compromised application’s logs. Instead, organisations should instrument identity providers, endpoint telemetry, network signals, and PAM or session controls so the incident can still be investigated when the app itself is silent.

Practical containment usually starts with identity actions: disable the suspicious session, revoke refresh tokens, rotate exposed secrets, and review any delegated app grants tied to the affected user or workload. Then the security owner should map the event to the required evidence set and document where the evidence was missing. For app owners, this is often a control gap: no audit trail, no session history, no event export, or logs retained too briefly for incident response. For security leadership, this means defining minimum logging requirements in policy and making them part of procurement, integration, and risk acceptance.

• Require identity provider logs even when SaaS or internal apps are weak on auditability.
• Set a minimum retention period for authentication, admin, and token-issuance events.
• Use NIST SP 800-53 Rev 5 Security and Privacy Controls to anchor logging, access, and incident response expectations.
• Correlate phishing reports with token use, device posture, and unusual API activity.

This aligns with the attacker behavior documented in Anthropic — first AI-orchestrated cyber espionage campaign report, where rapid abuse of compromised access made speed and visibility decisive. These controls tend to break down in heavily outsourced SaaS estates because the organisation cannot force consistent logging or timely revocation across every provider.

Common Variations and Edge Cases

Tighter logging and containment often increases integration overhead, requiring organisations to balance rapid response against application complexity and vendor constraints. That tradeoff becomes more pronounced when the affected system is legacy, externally managed, or embedded in a business process that cannot tolerate aggressive session invalidation.

There is no universal standard for this yet, but current guidance suggests the security function still remains accountable even when the app owner controls the platform. The app owner may own remediation of the missing logs, while security owns the incident process, evidence requirements, and cross-system containment. That distinction matters when executives ask who failed: the root cause may be an application design choice, but the inability to detect, scope, and contain is a security governance issue.

One important edge case is delegated access. If phishing compromises a user that can approve OAuth consent, create API tokens, or grant connected-app access, the incident often spreads beyond the original mailbox or application. In those situations, the question is not only who clicked, but who controls token governance, consent boundaries, and revocation workflows. NHIMG’s JetBrains GitHub plugin token exposure is a useful reminder that compromised tokens can outlive the initial phishing event and create a longer investigation window. Where logs are absent, accountability should be documented as shared operational ownership, with security retaining final responsibility for containment and evidence preservation.

Related resources from NHI Mgmt Group

• Who is accountable when a web application leaks sensitive files or bypasses access controls?
• What is the difference between attack surface management and NHI governance?
• How should security teams make NHI best practices usable across the business?
• Who is accountable when a help-desk style phishing attack reaches SaaS data?