This document provides a structured, best-practice approach for deploying SentinelOne in a controlled and predictable manner. By following these phases, customers can reduce operational risk, minimize false positives, and ensure a smooth transition to full endpoint protection while maintaining business continuity.
Phase 1: Pre-Deployment Planning
Identify endpoint groups
Workstations
Servers
High-risk / business-critical systems
Identify applications known to trigger EDR detections
Legacy apps
Admin tools
Custom scripts
Review any existing whitelist/exclusions (treat as reference only)
Confirm console access & role-based permissions (Admin vs SOC vs Read-only)
Review tenant settings & global defaults before agent deployment
Define alert ownership & response SLAs
Decide on pilot scope
Small user group
Non-critical systems first
Recommendation: The pilot group should consist of 5–10% of the total installed base, with a varied user mix. Participants should be resilient and understanding, preferably internal staff.
Define success criteria for pilot exit (e.g., FP rate, performance impact, SOC confidence)
Confirm rollback / emergency policy change process
Phase 2: Initial Deployment (Detect Mode)
Deploy SentinelOne agents using Deploying SentinelOne via Guardz: Best Practices & Installation Guide
Define ‘Policy Mode’: Protect - Detect
Protect on malicious, Detect for suspicious
Note: in Detect mode, nothing is blocked or killed.
Customers can operate in Detect-only mode; however, this is recommended only if an alternative EDR solution is already deployed.
Do not preload exclusions unless absolutely required
Monitor:
Behavioral detections
Suspicious tools flagged as malware
Agent connectivity
Missed check-ins
OS compatibility warnings
Perform console workflow familiarization
Classify alerts:
True positive
False positive
Needs further investigation
Phase 3: Exclusion / Whitelist Tuning
Create exclusions only after validation
Scope exclusions narrowly to a specific site, not global
When exclusions are configured via the SentinelOne console, they can be applied to specific groups and endpoints.
Prefer exclusion types in this order:
Hash-based
Signer / certificate-based
Process + exact path
Avoid:
Folder-wide exclusions
Wildcards
User profile directories
OS directories
It is recommended to document the following information:
Reason
Business justification
Approver
Review date
Tag exclusions as ‘Temporary’ or ‘Permanent’
Refer to SentinelOne Exclusions Overview to explore more about exclusions
Phase 4 – Transition to Protect Mode (if Required)
This step applies only in scenarios where Detect-only mode was enabled during endpoint deployment (Phase 2).
SentinelOne Protect mode always includes Kill & Remediation
Move pilot endpoints only to Protect
Keep:
Servers
Mission-critical systems in Detect longer if needed
Monitor closely:
Unexpected kills
Application interruptions
Performance issues
Adjust exclusions only if validated
Phase 5: Full Protect Enforcement
Expand Protect mode to all endpoints
Enable additional mitigations gradually, one at a time:
Kill
Quarantine
Remediation
Rollback (where supported)
Consider enabling additional mitigation actions:
Automatic Remediate
Automatic Rollback
Disconnect device from network (device isolation)
Use caution when enabling aggressive actions in Protect mode:
Legitimate applications may be falsely detected as malicious
Automatic remediation or rollback may leave applications in an irreparable state
Carefully enable network quarantine (optional)
Confirm SOC/MDR response workflows
Schedule:
Quarterly exclusion reviews
Policy health checks
Ongoing Operational Best Practices
Review exclusions quarterly
Remove exclusions tied to decommissioned software
Keep SentinelOne agent & policies updated