What should a SOC visibility checklist include after CISA’s red team findings?
A practical SOC visibility checklist should include alert tuning, baseline behavior, asset ownership, escalation authority, cloud identity monitoring, token revocation procedures, log retention, and evidence collection. CISA’s August 2026 red team findings show that detection tools only matter when people can separate real signals from noise and act fast enough to contain activity.
On August 25, 2026, CISA published A Tale of Two SOCs: Insights From Two Red Team Assessments, a cybersecurity advisory based on simultaneous assessments at two critical infrastructure organizations.1 In both environments, CISA’s red team achieved full domain compromise and reached sensitive business systems and cloud resources. The difference was not whether attackers could find a path. The difference was whether defenders detected initial activity, isolated affected systems, and forced the assessment into an assume-breach model.
That is the right news hook for municipal agencies, healthcare groups, K-12 districts, financial teams, and mid-market companies that already own EDR, SIEM, firewall, identity, and cloud tooling but still cannot answer a blunt executive question: “Would we know quickly enough if someone was moving through our environment?” If the answer is uncertain, the next step is not buying another dashboard. It is building a visibility and response operating model around the tools already in place.
Why did the CISA advisory turn SOC visibility into an executive issue?
CISA’s advisory turns SOC visibility into an executive issue because both assessed organizations were technically compromised, but their response maturity produced different outcomes. Organization A missed activity amid alert noise and silos. Organization B isolated compromised workstations within minutes, disrupting command-and-control and changing the attacker’s operating assumptions.1
Detection without authority is theater
The most useful detail in the advisory is operational, not exotic. CISA reported that Organization A’s SOC received medium- and low-severity EDR alerts related to red team activity but did not respond because thousands of false positives and routine alerts obscured the signal.1 The problem was not simply missing technology. The problem was a system that had normalized noise.
For lean IT teams, this is where Datapath sees visibility programs fail. Teams collect events from endpoints, Microsoft 365, firewalls, identity providers, cloud consoles, backup systems, and vulnerability scanners, but they do not define which alerts require action, who owns the asset, who can isolate a host, and what evidence must be preserved. A noisy console can make leadership feel covered while attackers keep moving.
Siloed teams lose time during the only window that matters
CISA also highlighted organizational silos and bureaucratic hurdles. In Organization A, multiple SOCs and multiple EDR tools created fragmented visibility. Staff lacked communication, standard escalation procedures, and authority to resolve ownership questions quickly.1
That matters for organizations that outsource some IT, retain some internal IT, and rely on specialized vendors for EHR, student information systems, finance platforms, line-of-business apps, or OT-adjacent systems. If no one knows whether a system belongs to infrastructure, security, an application owner, or a vendor, the alert will wait while the attacker does not. Our managed IT services model treats ownership and escalation paths as core controls, not administrative cleanup.
Cloud compromise changes the response playbook
The advisory also shows why cloud identity cannot sit outside the SOC visibility checklist. CISA described activity involving Microsoft Entra applications, elevated Microsoft Graph application permissions, client secrets, access tokens, refresh tokens, and primary refresh tokens.1 Those are not edge cases for modern businesses. They are normal cloud identity primitives that can become high-impact compromise paths when unmanaged.
This is why related work such as an Entra ID access review checklist for privileged accounts and a Microsoft 365 cloud logging checklist for security teams belongs in the same operating conversation as endpoint detection. Attackers do not respect the org chart between endpoint, identity, SaaS, and cloud.
What should your first 30 days of SOC visibility work cover?
The first 30 days should produce a defensible baseline: what assets matter, which alerts are actionable, who has authority to respond, which cloud identities are high risk, what logs are available, and how leadership will see open gaps. The deliverable should be a short operating packet, not a theoretical maturity model.
Build the asset and alert baseline together
Start with the systems whose compromise would materially disrupt operations, expose regulated data, or create public accountability. For Datapath clients, that often includes Microsoft 365, Active Directory or Entra ID, EDR-managed endpoints, firewalls, VPN or ZTNA access, backup platforms, EHR systems, student information systems, financial applications, and sensitive databases.
Then map the alerts that matter to those systems. Do not tune alerts in isolation from asset criticality. A medium-severity alert on a random test workstation is different from a medium-severity alert on a finance user’s machine, a domain controller, a backup server, a clinic workstation, or a city system connected to public services.
| Visibility item | Question to answer | Evidence to keep |
|---|---|---|
| Critical asset list | Which systems would create operational, legal, or public impact if compromised? | Inventory export, owner list, data classification notes |
| Alert baseline | Which alerts are expected, noisy, actionable, or emergency-level? | SIEM/EDR tuning log, sample alerts, closure reasons |
| Escalation path | Who can isolate a host, disable an account, revoke a token, or call a vendor? | Runbook, contact matrix, approval thresholds |
| Cloud identity risk | Which apps, service principals, workload identities, secrets, and permissions are high impact? | Entra exports, app permission reviews, exception register |
| Logging coverage | Can the team reconstruct what happened across endpoint, identity, firewall, email, and cloud? | Log-source map, retention settings, test queries |
| Leadership reporting | What does the business need to decide this week? | Open-risk summary, owners, dates, accepted exceptions |
A checklist like this complements a broader vulnerability remediation SLA template because alerts and vulnerabilities should not live in separate worlds. If an exploited vulnerability appears on a critical asset and endpoint telemetry shows suspicious behavior, the response priority changes.
Reduce alert noise without hiding real risk
CISA’s lesson is not “turn down noisy alerts until the dashboard looks clean.” It is to establish and continuously maintain a baseline, then tune alerts so defenders can find meaningful deviations.1 Bad tuning hides risk. Good tuning preserves high-value signals and removes repetitive events that have a documented benign explanation.
For regulated teams, every tuning decision should carry an owner, reason, date, and review cadence. If a detection rule is suppressed because it fires constantly on a known application, document the compensating signal that would still catch misuse. If an alert is downgraded, record what would cause it to become urgent again. Our security alert triage services are built around that discipline: reduce noise, preserve signal, and keep evidence for later review.
Give responders authority before the incident
Organization B’s defenders isolated affected workstations within 10, 2, and 20 minutes after payload execution generated medium-severity alerts.1 That did not happen because someone wrote a beautiful policy after the fact. It happened because the operational path allowed defenders to act.
Mid-market and public-sector teams should define pre-approved response actions for common scenarios:
- Isolate an endpoint from the network.
- Disable or reset a user account.
- Revoke sessions and refresh tokens.
- Remove a risky OAuth or enterprise application grant.
- Block an external IP, domain, or sender.
- Escalate to legal, compliance, communications, or executive leadership.
- Contact a vendor when a managed or hosted system is involved.
This authority should be scoped and documented. The goal is not reckless action. The goal is to prevent a medium-severity alert from waiting in a queue while the attacker turns a workstation foothold into cloud, identity, or sensitive business system access.
How should cloud identity and logging fit into the checklist?
Cloud identity and logging should be treated as core SOC visibility work because modern compromise paths often move from endpoints into SaaS, tokens, application permissions, and cloud resources. CISA’s advisory specifically calls out workload identities, excessive or unused permissions, access and refresh token procedures, and cloud compromise response.1
Review workload identities and application permissions
Microsoft Entra applications and service principals can hold powerful Microsoft Graph permissions. Some permissions can read mail, read files, access Teams messages, add secrets, or grant additional permissions. If those permissions are not inventoried and reviewed, the organization may have a quiet privilege path that sits outside normal user conditional access assumptions.
At minimum, review:
- Applications with high-impact Microsoft Graph application permissions.
- Service principals with stale owners, unused credentials, or long-lived secrets.
- Workload identities excluded from conditional access or monitoring.
- Admin-consented permissions that no current owner can justify.
- Token revocation and secret rotation procedures after suspected compromise.
This is adjacent to Microsoft 365 identity security services and managed cybersecurity services, not a one-time admin cleanup. The checklist should become a recurring review because cloud permissions drift every time a vendor app, automation, integration, migration, or departmental tool is added.
Use CISA’s logging guidance as a benchmark, not a federal-only document
Five days before the red team advisory, CISA released its Logging Reference Architecture for federal agencies and said critical infrastructure entities and state, local, territorial, and tribal governments should review it to benchmark their own logging and monitoring plans.2 That matters because logging is where security aspirations become provable.
A practical logging plan should answer whether the team can reconstruct endpoint execution, identity sign-ins, privileged role changes, firewall flows, email security events, cloud admin activity, SaaS audit events, backup job changes, and data access. It should also define retention, ownership, query access, evidence export, and who reviews failed coverage tests.
For healthcare and local government environments, this work connects directly to HIPAA-compliant IT services and government IT services. Incident response is weaker when logs exist technically but are not retained long enough, centralized consistently, or accessible to the people expected to investigate.
Test the controls against specific attacker behavior
CISA recommends validating the security program against the MITRE ATT&CK techniques described in the advisory: select a technique, align technologies, test performance, analyze results, and repeat.1 That is the right way to move past tool ownership into control performance.
A lean team does not need to test every technique in one month. Start with a few behaviors that map to real risk:
- Phishing payload execution on a workstation.
- Suspicious Active Directory discovery.
- New or unusual enterprise application secret creation.
- High-impact Microsoft Graph permission changes.
- Credential files found on workstations or file shares.
- Abnormal access to sensitive business systems.
- Unexpected administrative access to backup or endpoint management systems.
The test is not complete when the tool fires. It is complete when the team proves who saw the signal, what they did, what evidence was preserved, and what changed after the finding.
Why Datapath for SOC visibility checklist work?
The CISA red team findings point to the exact accountability gap Datapath helps regulated and mid-market organizations close. A business can own good tools and still lack tuned alerts, cloud identity review, escalation authority, logging coverage, and leadership-ready evidence. A SOC visibility checklist makes those dependencies explicit.
Datapath helps organizations connect endpoint, identity, firewall, cloud, backup, and incident-response workflows into one operating model. We support internal IT teams, co-managed environments, and outsourced IT relationships where the business needs more than generic monitoring. For broader planning, compare this checklist with our ransomware incident response plan for mid-market businesses and our Datapath resource guides.
Need a defensible SOC visibility review?
Datapath can help your team tune alert noise, validate logging coverage, review Microsoft 365 identity risk, and define responder authority before the next incident.
Frequently asked questions
What is a SOC visibility checklist?
A SOC visibility checklist is a practical control list that proves whether a security team can detect, investigate, escalate, and document suspicious activity across endpoints, identity, cloud, network, email, and critical business systems. It should include tools, owners, logs, procedures, response authority, and evidence requirements.
Why does alert tuning matter after the CISA red team advisory?
CISA reported that one organization received alerts related to red team activity but did not respond effectively because false positives and routine alerts obscured the signal. Alert tuning matters because defenders need a baseline that reduces noise without suppressing the events most likely to indicate compromise.
Should small and mid-market teams run a full SOC?
Not always. Many mid-market teams get better results from a co-managed or outsourced security model with clear escalation rules, tuned alert queues, identity monitoring, and executive reporting. The important question is whether somebody is accountable for triage, containment, and evidence, not whether the org chart says “SOC.”
What cloud identity items belong in SOC visibility work?
Cloud identity visibility should include privileged users, service principals, enterprise applications, workload identities, high-impact application permissions, client secrets, refresh tokens, conditional access coverage, and procedures for revoking access after suspected compromise. These items often sit outside traditional endpoint-only monitoring.
How often should a SOC visibility checklist be reviewed?
Quarterly is a practical baseline, with additional review after major incidents, audit findings, insurance renewals, cloud migrations, new EDR or SIEM deployments, mergers, vendor changes, or significant Microsoft 365 permission changes. High-risk exceptions should have shorter review dates and named business owners.
Sources
- CISA: A Tale of Two SOCs: Insights From Two Red Team Assessments
- CISA: Logging Reference Architecture announcement
- CISA: Logging Reference Architecture
- MITRE ATT&CK Enterprise Matrix
