Skip to content
Let’s talk
GREY WING SECURITY
All field notes
Compliance (GRC)

How Growing Teams Turn SentinelOne Alerts into SOC 2 Evidence

Already run SentinelOne? A simple routine for owners, cadence, and records turns endpoint alerts into SOC 2 evidence your auditor can follow.

9 min read

A lot of growing teams already run SentinelOne on their laptops and servers. The agent does its job. The gap is almost always what happens after an alert fires. Who looks at it? What did they decide? Where is the record?

Your SOC 2 auditor will ask those questions. "We have SentinelOne" is a tool, not a control. The control is the routine your team runs around the tool, and the evidence is the record that the routine happened.

This post lays out a simple operating model for the Security or IT team at a growing company. It covers which findings to handle, who owns each one, how often to look, and what to keep. We are not a SentinelOne partner or reseller, and SentinelOne has not reviewed or endorsed this post. Feature names below come from SentinelOne's public pages. What you see in your console depends on your license and console version.

What SOC 2 asks for

The AICPA Trust Services Criteria do not name any product. They describe outcomes. A few of them map cleanly to endpoint work:

  • CC6.8 says the entity "implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software." Note the words "act upon." Detection alone is not enough.
  • CC7.1 covers finding new vulnerabilities, and one of its points of focus covers "unknown or unauthorized components."
  • CC7.2 asks that anomalies be "analyzed to determine whether they represent security events." One of its points of focus is checking that your detection tools are working.
  • CC7.3 and CC7.4 cover evaluating security events and responding to real incidents through a defined plan.
  • CC8.1 covers changes, including changes to "infrastructure, data, software, and procedures." Policy changes and exclusions in your endpoint tool are changes.

Your auditor decides what evidence meets each criterion. We are a readiness helper. We do not audit or certify. Our job is to help you build a routine that leaves a clean record.

Six kinds of findings and what to do with each

1. Threats and alerts

This is the obvious one. Each alert in SentinelOne shows what the agent concluded, such as whether it was mitigated and how confident the AI is. It also gives you two fields for your own decision: an analyst verdict (true or false positive) and a status (new or unresolved, in progress, or resolved). Depending on your console version, these appear as Analyst Verdict and Incident Status, or Analyst Verdict and Alert Status. Use them every time.

For each alert, the person on point sets a verdict, adds a short note on why, and moves the status to resolved when the work is done. SentinelOne says the Timeline tab "captures every activity of the analyst, the console and the Agent that is related to the threat," including notes. That note can be part of your evidence for CC7.2 and CC7.3. A one-line note that says what you checked beats a blank field every time. A verdict is a label, not an action. Marking an alert false positive does not release a quarantined file or add an exclusion, so record those steps separately.

If an alert looks like a real incident, follow your incident response plan. If you need hands-on incident response, it comes through our partner MDR, delivered by At-Bay. Our own team does not run incident response.

Owner: the person on point that week, with a named backup.

2. Policy mode: Detect or Protect

SentinelOne agents run in one of two modes. SentinelOne's product tour says that in Detect mode "actions are taken on-demand," while in Protect mode "mitigation actions execute autonomously in real time." You can set different modes for suspicious and malicious threats.

This choice matters more for a small team than a large one. SentinelOne describes Detect as "an alert-only mode" in which the agent "does not intervene with any type of automatic protective response." A threat keeps running until someone acts. If nobody is on alert at 2 a.m., Detect mode means nobody acts at 2 a.m.

Our advice for laptops is to run Protect, at least for malicious threats. Use Detect only for a short, time-boxed tuning period, and put the end date in the ticket. Write down which groups run in which mode and why. Treat any change as a change under CC8.1: a ticket, an approver, and a date.

Owner: the Security or IT lead.

3. Exclusions

Exclusions are how teams stop false alarms on tools they trust. Each one also opens a gap in coverage. An analyst can usually add an exclusion right from the alert, which is handy and easy to forget.

Keep a short list of every exclusion with who asked for it, who approved it, and when you will review it. Review the list monthly. Remove anything nobody can explain.

Owner: the Security or IT lead approves. The requester explains.

4. Coverage gaps

A device without an agent produces no alerts, which looks the same as a quiet, healthy device. SentinelOne offers two ways to find these gaps. If your license includes it, Unmanaged Assets "informs administrators which devices on the network still require a SentinelOne agent," according to SentinelOne's Network Discovery page. Network Discovery (formerly Ranger) is a separate add-on with more detail.

Even without either feature, compare your SentinelOne device count to your HR roster and your device management list each week. Every gap needs an owner and a fix date. This supports CC7.1.

Owner: IT.

5. Agent health

An agent that stopped reporting weeks ago still sits in the console. So does an agent three versions behind. Neither one gives you the coverage you think you have. One CC7.2 point of focus is checking that your detection tools are working. This is what that looks like in practice.

Each week, pull the devices that have not checked in recently and the devices on old agent versions. Fix them or retire them, and note which one you did.

Owner: IT.

6. Vulnerabilities and installed apps (if licensed)

If you have Singularity Vulnerability Management, the same agent scans endpoints for app and operating system flaws. SentinelOne says it ranks them using EPSS scores and CISA KEV data, not CVSS alone. Its application inventory can also show software that should not be there.

Work the top of the list, not all of it. Record what you fixed, what you accepted, and who accepted it. This supports CC7.1, and app inventory supports the CC6.8 point of focus on restricting software installs.

Owner: IT for patching. The Security lead signs off on any accepted risk.

A cadence that fits a growing team

You do not need a large team to run this. You need a calendar.

Every workday. Set up alerts so new threats reach a named person by email or chat, not just the console. That person sets the verdict and status and adds a note.

Weekly. Check for open alerts older than a few days. Pull the agent health list. Compare device counts against your roster.

Monthly. Review exclusions. Confirm policy modes match what you wrote down. Review the top vulnerabilities. Export the month's records and file them.

Quarterly. Review who has access to the SentinelOne console and which role each person holds. Keep rights to change policy, exclusions, and verdicts with the named owners. Give everyone else read-only access. Remove anyone who left or changed roles.

Put each task on a calendar with an owner. A routine nobody owns tends to stop.

How to keep the records as evidence

In a Type 2 audit, your auditor checks that the routine ran across the whole review period. Often they pick a sample, such as a few alerts, a few weeks, or a few changes, and ask you to show the work. How they test is their call. Make it easy.

  • Keep one folder per month with the same files every time.
  • Date every export and screenshot. Note who made it.
  • Link each policy or exclusion change to a ticket with an approver.
  • Keep the verdict notes in SentinelOne, and save a monthly export outside it. How long the console keeps data depends on your license and may be shorter than your audit period.
  • Limit who can open the folder. Exports and screenshots can show usernames, device names, and file paths. Agree any redaction with your auditor before you share.
  • Write a one-page procedure that names the owners and the cadence above.

Twelve months of the same small record set is far more useful than one big binder made the week before fieldwork.

Where Grey Wing fits

Our Security Program runs on hours agreed in writing. We help you design the alert routing, owners, cadence, and evidence folders, and during those hours we review findings with your team. Your team keeps the SentinelOne console and makes the decisions. We are not a 24/7 SOC. Our partner MDR is delivered by At-Bay, and At-Bay describes its MDR service as 24/7.

Checklist

  • Every alert gets an analyst verdict, a status, and a short note.
  • New threats reach a named person, with a named backup.
  • Policy modes are written down, with the reason for each group and an end date for any Detect period.
  • Policy changes go through a ticket with an approver.
  • Every exclusion has a requester, an approver, and a review date.
  • Device counts match your roster and device management list each week.
  • Devices that stopped reporting or run old agents get fixed or retired.
  • Top vulnerabilities are fixed or formally accepted, with a name on each.
  • Console access and roles are reviewed each quarter.
  • Monthly evidence is filed in the same folder layout every time.

If you want help turning your SentinelOne alerts into evidence your auditor can follow, Let’s talk.

Sources

Not sure where to start?

Tell us about your systems and deadline. We’ll reply within one business day.

Let’s talkGet the vendor review checklist

Keep reading

More on compliance (GRC)

All field notes