Scope working example

Step 1. Regulatory check

The compromised user dlin has read access to a cloud finance platform that processes payment data. That triggers PCI DSS implications. The platform also stores personally identifiable information for vendors, which brings GDPR into scope for any EU-resident vendor records.

Decisions: Document PCI exposure now. Engage compliance early so any breach-notification clock can run in parallel with the technical investigation. Tag the case as both PCI and GDPR relevant.

Step 2. Time window

The alert is a phishing-driven intrusion that fired today. The Subject phase did not find slow-burn signals. The default window for this threat type is 24 to 72 hours of historical review, with a 4-week look at the primary entities to confirm no prior staging.

Decisions: Set primary window at 72 hours pre-alert through current time. Set extended check at 4 weeks for dlin’s account specifically. Note that endpoint telemetry has 90-day retention, identity telemetry has 1 year, both are sufficient.

Step 3. Entity boundaries

Subject’s entity map gets categorized:

• Primary: dlin (user), laptop-finance-09 (host), dlin’s cloud identity.
• Secondary: The service account dlin authenticates against. The two other finance users who opened the same email. The external sender.
• Out of scope (for now): Other finance team members who received but did not open the email. Their inboxes still get a baseline check, but no full investigation unless something new surfaces.

Decisions: Primary entities get full investigation depth. Secondary entities get baseline comparison and are upgraded only on a signal.

Step 4. Infrastructure check

What can the SOC see for this case?

• In scope: EDR on the laptop, cloud identity logs, firewall logs, proxy logs, mailbox audit.
• Limited: The cloud finance platform’s in-app activity is in the vendor’s logs; the SOC sees authentication and gross API calls only. A vendor request is needed for deeper investigation.
• Gaps: If the user worked from a personal phone via the cloud platform’s mobile app, that activity may not show up in corporate telemetry.

Decisions: Note the cloud-platform gap explicitly. If Uncover needs deeper data, request from the vendor now so it arrives in parallel.

Step 5. Hand off to Uncover

The Scope deliverable is a one-page boundary statement Uncover can pin above their query window:

• Threat type: phishing-driven intrusion.
• Time: 72 hours primary, 4 weeks extended for dlin.
• Primary entities: dlin, laptop-finance-09, cloud identity. Full depth.
• Secondary entities: service account, 2 other finance users, external sender. Baseline depth.
• Regulatory: PCI and GDPR triggers active. Compliance engaged.
• Infrastructure gaps: mobile app activity on the cloud platform may be invisible; vendor request submitted.

Step 1. Time scope

The Cursor case has a narrower time horizon than the finance-team intrusion. Subject’s reads were all clean; there is no expanding pattern to chase. The boundary is sized to validate the false-positive hypothesis, not to investigate a compromise.

• Primary window: alert minus 1 hour through alert plus 4 hours. Five-hour total, enough to capture the IDE session that produced the alert and any follow-on behavior.
• Comparison window: the same user’s prior 14 days of IDE activity, used only for behavioral baselining, not for incident reconstruction.
• Extension trigger: if Uncover surfaces any signal inconsistent with the false-positive read (new persistence, unexpected network destinations, credential access), the time window expands to 24 hours pre-alert and the case is escalated within Risk.

A short window is the correct call when Subject’s reads agree. Extending it preemptively would burn time investigating absence of compromise.

Step 2. Subject scope

Subject’s per-entity assessment is the input. Scope translates it into investigative boundaries that don’t expand the entity list.

• Primary subject: the developer’s laptop and the Cursor Helper (Plugin) binary. Full process telemetry, file activity, and network behavior for this host during the time window.
• User context: the named frontend engineer. Authentication and authorization checks for the period; no peer-group expansion required because Subject’s relationship-dimension read was clean.
• Excluded: other developer laptops, other engineers on the team, the vendor’s infrastructure beyond observable DNS and TLS. Subject’s read was conclusive on these surfaces; Scope does not re-open them.

What over-scoping would look like: pulling every developer laptop running Cursor into the investigation, or expanding to investigate Anysphere as a vendor. Both are tempting because the binary is the focal artifact. The methodology says no: Subject already validated the binary and the trust chain. Re-opening that question is wasted work.

Step 3. Environment scope

The environment for a single managed developer workstation is genuinely narrow, and Scope keeps it that way.

• In scope: the laptop’s EDR telemetry, the corporate egress proxy logs for this device, the developer’s SSO authentication events, the MDM compliance record for the laptop.
• Conditionally in: internal source-control access logs for the user’s repositories during the window (read-only, no payload reconstruction).
• Out of scope: peer laptops, the vendor’s own infrastructure beyond DNS / TLS observability, any system the laptop did not actually reach during the window.

Step 4. Data sources and tooling

The Cursor case has fewer data sources than the finance-team intrusion because the subject surface is genuinely smaller. Scope names them precisely so Uncover does not improvise.

• EDR (CrowdStrike on macOS). Primary. Process tree, file activity, network sockets, signing-status events.
• Corporate egress proxy. Outbound destinations, TLS metadata, byte counts. Used to corroborate that the network signal mapped to vendor inference endpoints, not staging infrastructure.
• Identity provider logs. Authentication events for this user during the window. No password reset, no MFA bypass, no anomalous geographies.
• MDM compliance record. Confirms the laptop is enrolled, encrypted, OS-current, and reporting normally.
• Threat intelligence. Passive only. Confirm the vendor and inference endpoints have no prior incident associations. No active hash pivots, no speculative attribution.

Step 5. Boundary statement

The Scope deliverable for the Cursor case is deliberately compact:

• Time: alert minus 1h through alert plus 4h. Comparison window: prior 14 days for behavioral baselining only.
• Subject: one laptop, one engineer, one binary, the vendor’s documented endpoints. No expansion.
• Environment: EDR, corporate egress proxy, identity provider, MDM. Source-control reads conditional.
• Data sources: as above. Threat intel passive only.
• Regulatory: none triggered. The source code on the laptop is sensitive but is not regulated data; no PCI/PII/PHI in scope.
• Infrastructure gaps: macOS full-packet capture not available; USB monitoring not deployed on this host class. Uncover will note these as bounded confidence reductions, not as expansion triggers.
• Escalation trigger: any Uncover finding inconsistent with the false-positive read expands the time window to 24 hours pre-alert and bumps the case to the Risk phase for re-evaluation.

Uncover starts inside narrow rails. The case is shaped to confirm or refute the false-positive read efficiently, not to manufacture a compromise narrative from absence of evidence.