Three Principles That Close the Post-Detection Accountability Gap

In Part 1 of this series, we met Anika, James, and Rachel. Anika is a skilled Salesforce admin who closed a case after EzProtect blocked a trojan, without knowing she needed to investigate further. James is a Security Lead who mentally marked the incident as handled. Rachel is a VP of Security who discovered 90 days later that she had nothing to show a SOC 2 auditor. The detection worked. The accountability did not.

This second part of the series introduces three principles that close the gap, and shows what happens when the same threat enters the same Salesforce environment with Argus in place.

The system rewards speed of closure, not quality of resolution

Before introducing the solution, it is worth understanding why capable people like Anika and James produce incomplete responses.

Anika operates inside a system that incentivizes throughput. Open cases demand attention. Closed cases do not. The standard reporting on Anika’s Experience Cloud community tracks case volume, resolution time, and customer satisfaction, and none of those metrics distinguish between a case that was closed and an incident that was properly investigated. Every minute Anika spends confirming whether a file hash appeared in another Salesforce application through a different path is a minute not spent on the next open case. James operates under similar pressure. Every incident James keeps open for a thorough investigation is one that drags his metrics. Both are rational actors working inside a system that incentivizes closing tickets quickly and does not penalize closing them incompletely.

The ISC2 2025 Cybersecurity Workforce Study found that 88% of organizations experienced a security event tied to a skills shortage. But the issue is not just skills. Even skilled people will cut corners when the surrounding process does not catch them, does not guide them, and does not validate the quality of the work. Security maturity is not something you hire into. It is an outcome of a process that compensates for the pressure teams are actually under.

What happens with Argus in place

EzProtect catches the trojan uploaded through the Experience Cloud portal, quarantines the file, and publishes the scan result to Salesforce Data Cloud. Data Cloud creates an incident in Argus. Argus classifies the severity based on five dimensions (threat type, actor, reach, data exposure, and scanner confidence), notifies Anika and James, and opens the first milestones.

Anika opens Argus and sees a milestone with a clear instruction: “Verify no internal users accessed the file before EzProtect blocked it. Check the ContentVersion access log for the window between upload timestamp and quarantine timestamp. Attach the log export showing zero access events, or list any users who accessed the file with timestamps.” Anika knows Salesforce deeply. She knows exactly how to pull a ContentVersion access log. The gap was never her platform skills. The gap was that no system ever told her this step existed.

In parallel, Argus creates a blast radius milestone for every other Salesforce application registered in the Argus Application Registry and assigns each to that application’s owner. Each owner checks whether the same file hash appeared in their environment and reports back. The containment phase does not open until every blast radius check is approved. If a match is found, Argus creates a child incident for that application with its own full response lifecycle, linked to the parent.

Not every detection requires a full investigation. When EzProtect blocks a file that turns out to be a false positive, such as a legitimate installer incorrectly flagged, or a policy violation with no security impact, Argus classifies it at P4 with minimal milestone requirements. The Security Lead can downgrade severity at any point with a written justification. The investigation scales to the threat, not the other way around.

Principle one: hard gates between phases

An incident response follows a natural sequence: detect, analyze, contain, clean up, recover, learn. Argus enforces phase gates between each one. Nothing advances from detection and analysis to containment until every detection milestone is approved with evidence attached. Nothing advances from containment to cleanup until both the Security Lead and the Application Owner have signed off that containment is complete.

The gates do not add work. They make the existing work visible and provable, and they produce the audit trail as a by-product.

Principle two: the person who does the work cannot approve it

Every Argus milestone has a named Author, Reviewer, and Approver, and the Author can never be the Approver. When Anika submits her evidence, Argus’s AI evaluates it before James sees it. The AI checks whether the description names the specific action, system, person, and time. If Anika writes “checked access logs,” Argus tells her what is missing: which log, which file, which time window, what result. Anika can update the evidence or record a justification. Both the feedback and the resolution are captured in the audit trail. James then reviews. A separate Approver signs off. The milestone locks.

Under NIS2, management accountability is personal. Individual managers can be fined, suspended, or banned. The person signing off on containment needs to understand the weight of what they are signing.

Principle three: AI assists within a hard boundary

Argus uses AI to classify severity, validate evidence, draft communications, and enrich incidents with VirusTotal threat intelligence at the point of incident creation. But AI hallucinates. Argus only auto-decides where the check is deterministic, corroborated by three or more independent sources, and the system’s assessed risk of being wrong is below 1%. Root cause analysis, containment completeness, and regulatory determinations belong to named humans. AI proposes. Humans decide. The decision and the decider’s identity are locked into the immutable timeline.

How Argus drives the work and accountability forward

Here is what escalation actually looks like in practice. James is the Approver on the containment completeness milestone, but James is on a bridge call for a separate incident in another org. The containment milestone hits 50% of its SLA window and Argus sends James an in-app nudge. James does not see it. At 75%, the escalation accelerates because the Approver pool is small and the Author cannot be reassigned as Approver. Argus skips the intermediate tier entirely and engages Rachel, James’s manager, with full context via email: the milestone name, the incident severity, the time remaining, and a direct link to approve or reassign.

Rachel sees the email. She knows James is on the other bridge. She reassigns the approval to the secondary Security Lead, who reviews the evidence Anika submitted, confirms the containment is complete, and signs off. The escalation closes with an audit entry that reads “Escalation resolved by reassignment.” James was not penalized. The system routed around the obstacle. The milestone advanced. And the breach record, the fact that this milestone exceeded its SLA, stays in the incident timeline permanently. It does not disappear when the work resumes. If another milestone on this same incident breaches, the cumulative breach count triggers automatic Emergency Response Team activation. The system tracks accountability across the entire lifecycle, not just one milestone at a time.

This same pattern handles another common scenario. Suppose the Application Owner for the firm’s Sales Cloud org receives a blast radius milestone and misses the 30-minute SLA because the owner is in a customer meeting. The milestone breaches. The manager is engaged. The Application Owner submits the blast radius findings 20 minutes later. Argus accepts the late submission, advances the milestone to the Reviewer, and starts a fresh SLA clock for the review phase. The breach that occurred during the investigation phase remains in the timeline and counts toward the incident’s overall accountability record. A breach that was real does not vanish when work resumes.

If a single Approver has three or more milestones approaching breach simultaneously, Argus escalates the person rather than each milestone individually. The manager and the Security Lead are notified to redistribute the approval workload. This prevents the notification fatigue that causes real escalation systems to fail.

What changes for Anika, James, and Rachel

Anika’s workload does not increase. The time she used to spend not knowing what to do becomes time spent following clear, step-by-step instructions that leverage her deep Salesforce expertise. The documentation that used to be an afterthought happens as part of the work itself. James stops being the person who manually chases every milestone. Argus chases for him and surfaces only what needs his judgment. Rachel stops wondering whether incidents were handled properly. The audit trail builds itself while the team is doing the work, and it is already there when the auditor arrives.

Part 1 explored why the accountability gap exists. This second part showed how Argus closes it with hard gates, separation of duties, AI within a strict boundary, and escalation that routes around obstacles instead of punishing people.

But Anika, James, and Rachel’s firm is based in the United States and serves three customers in EU member states. Rachel has a SOC 2 audit in 90 days. She also has GDPR exposure she has not yet quantified. In Part 3, a support agent on Anika’s team clicks a phishing link inside a customer case before EzProtect flags it. The agent may have entered credentials. The regulatory clocks start. And the question is no longer whether the team can respond. The question is whether Rachel can prove they did.

Let’s close your team’s accountability gap. Book an Argus demo and run your own scenario. See EzProtect block a threat, Argus assign milestones with plain-language instructions, validate the evidence your team submits, and route around a bottleneck when someone is unavailable.

 

Frequently Asked Questions

Why do security incidents stall even when someone is assigned to them?

Incidents stall because the systems people work in reward speed of ticket closure, not quality of resolution. A Salesforce admin has no incentive to spend an extra hour checking blast radius across other applications. A Security Lead has no incentive to keep an incident open for a thorough investigation. Argus by EzProtect solves this by enforcing phase gates that prevent an incident from advancing until evidence is submitted and reviewed, validating evidence quality with AI before human review, and escalating automatically when work stalls so that capable people are supported by a system that catches gaps instead of ignoring them.

What is blast radius in Salesforce security, and why does it matter?

Blast radius is the question of whether a threat detected in one Salesforce application also appeared in other connected Salesforce environments. If a malicious file is uploaded to an Experience Cloud community, the same file hash could exist in a connected Service Cloud org or Sales Cloud instance. Checking blast radius means querying every registered application to confirm the threat is isolated. Without this check, an organization can contain a threat in one application while the same payload sits undetected in another. Argus automates this by creating a tracking milestone for each registered application and blocking the containment phase until every check is resolved.

What is the NIST incident response lifecycle and do I need to know it?

NIST SP 800-61 is a six-phase framework used by federal agencies and enterprises: prepare, detect and analyze, contain, clean up, recover, and learn. It is the industry standard for incident response. You do not need to memorize it. Argus implements the lifecycle as a workflow with plain-language instructions at every step, so your team follows the framework without studying it. The framework enforces discipline. Argus translates that discipline into actionable tasks.

How do SLA escalation thresholds work in incident response?

Effective escalation uses progressive thresholds tied to the percentage of time remaining on a deadline. A well-designed system sends a reminder at 50% of the SLA window, an urgent alert at 75%, and triggers formal escalation with a permanent audit record at 100%. The specific recipients change based on who holds the bottleneck, and the system should detect when one person is overloaded across multiple milestones and escalate the person rather than each item individually. Argus by EzProtect implements exactly this model, with severity-specific response windows and automatic tier-jumping when a notified party does not respond, so no incident ever sits unattended.