Your Security Stack Is Impressive. But Who's Watching It at 3 AM?

I suspect some organizations spend more time choosing a security platform than deciding who will operate it.

Microsoft, CrowdStrike, Palo Alto Networks, SentinelOne, and others offer capable security technologies. Organizations buy them to improve detection, visibility, and response. The harder question is whether they have the people, processes, and authority to act on what those technologies find.

Buying the platform creates a responsibility to operate it. That means reviewing alerts, investigating incidents, tuning detections, maintaining integrations, and carrying out response actions. A completed deployment does not tell us whether any of that happens reliably outside business hours.

How much of the stack are we actually operating?

An established security environment can produce endpoint detections, suspicious sign-ins, email threats, cloud findings, data loss prevention events, insider risk alerts, and vulnerability reports. AI applications and agents add further questions about identities, permissions, and data access.

These findings need different treatment. A vulnerability may belong in a remediation queue. A policy violation may require a business or compliance review. An active compromise may require immediate containment. Sending everything to the same queue does not resolve those differences.

I would start with an inventory of the capabilities already deployed and ask who reviews each type of finding, during which hours, and with what authority. Where the answer is unclear, there is an operating gap to resolve before adding another source of alerts.

An unattended queue and an unassigned response action are more useful findings than another report showing how many security products have been enabled.

Does the platform support a complete investigation?

There is value in bringing related evidence together. Microsoft Defender XDR and Sentinel can support a shared investigation experience in the Defender portal, helping an analyst follow activity across connected security services.

I tend to favour Microsoft because it is the ecosystem I know best. That familiarity does not make the full stack straightforward to operate. Defender, Sentinel, Entra, Defender for Cloud, and Purview still involve different configuration decisions, permissions, and operational responsibilities.

Some Purview alerts can be surfaced in the Defender portal. That does not mean every insider risk or data protection case should follow the same response process as an endpoint compromise. The appropriate investigation may involve privacy, legal, HR, or data owners, with access restricted accordingly.

Putting five consoles behind one login does not demonstrate a complete response process. The useful test is whether an analyst can follow the evidence, identify who needs to act, and complete the approved response without losing time to missing access or unclear ownership.

I would ask the same questions of any vendor. A demonstration should include the handoffs and permissions involved in a realistic investigation, including what happens when an integration or escalation fails.

What happens at 3 AM?

Consider an overnight incident: suspicious authentication activity is followed by an endpoint detection suggesting credential theft, while unusual access to sensitive information appears in another service.

The products may have detected each part of the activity. Somebody still needs to decide whether the events are related, assess the impact, and act.

Who receives the initial notification? Can that person access the relevant identity and endpoint evidence? Are they authorized to isolate a device or request session revocation? If disabling an account could interrupt a critical service, who can make that decision and who is available to approve it?

Response authority needs agreed limits. The answer is not to give every overnight analyst unrestricted administrative access. It is to define the actions they can take, the circumstances that require escalation, and a reachable owner for decisions outside their authority.

If identity, endpoint, and data teams each assume another team owns the incident, the delay can persist even when all three products are working as intended.

What does the managed service actually cover?

A managed detection and response provider can supply expertise and coverage that an internal team cannot sustain on its own. The contract and the technical implementation need to describe the same service.

Review which products, tenants, workspaces, devices, and alert types are included. Establish whether coverage means continuous monitoring, investigation, advice, or the authority to carry out specific response actions. Check what the provider does when telemetry stops arriving or an integration loses access.

Endpoint and identity monitoring should not be assumed to include every Purview workflow, cloud posture finding, external vulnerability, or AI-related risk. Some findings may reasonably remain with another team, provided the handoff and review schedule are explicit.

A notification-only service can be useful, but it relies on a customer team that can respond. If nobody on the customer side is available overnight, that dependency needs to be understood before an incident tests it.

Automation still needs an owner

AI-assisted investigations and automation can reduce some manual work. Their value needs to be demonstrated against the tasks the team actually performs, including the effort required to validate results and handle exceptions.

Before enabling a response action, establish what triggers it, which accounts or assets it can affect, where approval is required, and how an incorrect action can be reversed. Somebody also needs to maintain the permissions, integrations, and detection logic on which it depends.

Automating a notification does not resolve an escalation path that nobody answers. Automating containment without understanding its business impact can create another problem. I would rather see a smaller set of tested actions with clear owners than a long list of enabled workflows nobody has exercised.

Ask for evidence before the next renewal

The number of products, alerts, and enabled features says little about whether the organization can respond effectively. Before the next renewal, I would ask the security team and its provider to work through an agreed scenario and record:

• When the first relevant signal became available and when somebody reviewed it.
• Which evidence was accessible, which was missing, and who assembled the incident view.
• When a response decision was made, who authorized it, and when containment took effect.
• Which handoffs delayed progress, including unanswered escalation attempts.
• Which findings remain outside continuous monitoring and who reviews them instead.

A tabletop exercise can expose ownership and approval gaps. A controlled technical exercise can then test whether notifications, access, and response actions behave as expected. Set the response expectations around the incident's severity and business impact, and investigate the reasons for missed targets.

I would rather see an organization get reliable use from the security technology it already owns than continue purchasing capabilities while those gaps remain unresolved.

If the stack detects an attack at 3 AM but nobody can investigate or contain it until 9 AM, that delay belongs in the security investment discussion.