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
Important note:
Please review the system and the specific prerequisites required for the SentinelOne agent deployment before starting the deployment process. Ensuring that all prerequisites are met in advance will help prevent installation or configuration issues.
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