A business has made genuine security investments. Microsoft Defender is deployed. Endpoint protection is running on every device. MFA is enabled. Email security is configured. Backups are running. The IT provider has set everything up correctly.
Then the question: if something suspicious happened in that environment tonight, who would know?
Who would see the alert? Who would determine whether it represents a genuine threat or a false alarm? Who would trace whether an unusual sign-in was a staff member working late or an attacker using stolen credentials? Who would check what the account accessed before the session ended? Who would look for related activity across other systems? And who would do any of this at 11pm on a Tuesday?
For many NZ businesses, the honest answer is: nobody would, until somebody checked in the morning. And by morning, an attacker who moved at the speed the current data suggests they do could already be somewhere else in the environment entirely.
This isn't a failure of security technology. The tools are working. The gap is in what happens when those tools produce information - and whether anyone is there to act on it.
The distinction between security tools and security monitoring is one that matters enormously in practice and gets very little attention in most security conversations.
Security technology - endpoint protection, Microsoft Defender, email filtering, firewalls - does something important and real. It detects known threats, blocks malicious files, generates alerts, and logs activity. These capabilities have genuine value. None of them are automatic substitutes for investigation.
A security alert is information. It says that something happened that the system considered worth flagging. What it doesn't say is whether that something is a serious attack, a false positive, user behaviour that looks unusual but is entirely legitimate, or a low-level probe that requires no immediate action. Answering that question requires someone to look at the alert, understand the context, investigate what preceded it, connect it to activity elsewhere in the environment, and decide what happens next.
That process - monitoring, investigation, triage, and response - is security operations. And it's separate from security technology in the same way that a hospital's monitoring equipment is separate from the clinical staff who interpret what it shows.
The NCSC's Q1 2026 Cyber Security Insights Report recorded 437 incidents of phishing and credential harvesting in a single quarter - the most common incident type by volume. Q2 2026 saw a 20% increase in incidents requiring specialist technical support, with unauthorised access alone linked to approximately $1.3 million in financial losses. These aren't dramatic breaches. They're the ordinary consequence of credential theft, a category of attack that begins when someone's login details are captured and used - typically through a sign-in that looks, to an uninvestigated alert, like most other sign-ins.
The difference between that credential theft becoming a minor incident and becoming a significant one is frequently how quickly it's detected, investigated, and contained. And that depends entirely on whether someone was watching.
To understand why monitoring matters, it helps to understand what a security alert actually is and what the journey from alert to resolution looks like.
When suspicious activity occurs in a Microsoft 365 environment - an unusual sign-in from an unfamiliar location, a large volume of files accessed in a short period, an email forwarding rule created on an account - the security tooling generates an alert. That alert sits in a queue. In Microsoft Defender, in the security portal, in whatever monitoring console the business uses. It's there. Whether anyone sees it, reads it, or acts on it is a separate question.
In environments with dedicated security operations, that alert enters a triage process. An analyst reviews it, determines its severity, investigates the context - what account, what device, what preceded the activity, what happened after - and makes a decision. Is this a genuine threat? Does it require immediate action? Does it connect to other alerts that together suggest a pattern? Should the account be isolated? Should the business be notified?
In environments without dedicated monitoring, the alert exists. It may be seen when someone next opens the console. It may be lost in the volume of other alerts that have accumulated. It may be reviewed at the end of the week as part of a periodic check. It may trigger an email notification that goes to an inbox nobody checks continuously.
The gap between those two outcomes is the security monitoring gap.
Layer3 NZ's 2026 threat landscape analysis captures what makes this so consequential in the NZ context: "For many businesses, the breach no longer starts with a dramatic 'hack.' It starts with a password reset, an MFA change, a convincing phishing email." These are events that generate exactly the kind of alerts that sit uninvestigated. And the time available to detect and contain them is shrinking.
CrowdStrike's 2026 threat research found that the average attacker breakout time - the time between gaining access to a first system and moving to a second - has fallen to 29 minutes. Less than half an hour after a credential is compromised, an attacker can be in a different part of the environment. An alert that's reviewed the following morning is being reviewed after the attacker has already had the night.
Security monitoring isn't technically complex to understand. It's operationally difficult to deliver.
Modern Microsoft 365 environments generate significant volumes of security signals. Sign-ins across multiple users from multiple locations. Email activity. SharePoint and OneDrive access. Device activity. Application connections. Identity changes. Each security tool adds its own alert stream. Microsoft Defender for Endpoint generates alerts. Microsoft Defender for Office 365 generates alerts. Microsoft Entra ID generates sign-in risk alerts. The aggregate is a substantial volume of information that requires constant attention to separate the meaningful from the routine.
The problem isn't that any individual alert is hard to understand. The problem is volume, context, and correlation.
Volume: a busy Microsoft 365 environment can generate hundreds of security signals in a week. Many of them are false positives - legitimate activity that matches a pattern the detection rules were designed to flag. Investigating a high volume of alerts to determine which are genuine requires time that most lean IT teams simply don't have.
Context: a single unusual sign-in in isolation is ambiguous. The same sign-in, combined with a forwarding rule created two hours later and a large email export the following day, is a recognisable pattern - but only if someone is connecting those three events across different alert queues and timelines. This correlation work is what distinguishes an investigation from a single alert review.
After-hours coverage: the NCSC data consistently shows that attacks don't respect business hours. Ransomware, in particular, is routinely deployed outside business hours - specifically because detection and response capability is reduced. An alert generated at 11pm in a business with no after-hours monitoring is functionally invisible until the following morning.
This is not an argument that IT teams are doing something wrong. It's an acknowledgement of what a small IT function is actually being asked to do.
A typical NZ SME's IT function - whether internal or outsourced - manages employee devices, Microsoft 365 administration, network infrastructure, new system implementations, software updates, user support, and the dozens of operational requests that arrive daily from a business that depends on its technology to function. Security monitoring is one responsibility among many, and it's one that competes for time with responsibilities that are immediately visible and pressing.
The operational reality: continuously monitoring security alerts, investigating suspicious activity, correlating events across multiple systems, hunting for threats that don't produce obvious alerts, and maintaining after-hours coverage are each individually demanding. Together they constitute a security operations function - and a security operations function requires dedicated capability, specific expertise, and continuous attention.
Expecting an IT manager who is also managing devices, supporting users, and administering Microsoft 365 to simultaneously operate a security operations function is not a staffing decision most businesses have made consciously. It's a consequence of how responsibilities have accumulated as environments have grown.
The question worth asking is not whether the IT team is capable or committed. It's whether the security operations function that the business needs is realistically possible within the capacity available.
These are leadership questions - not technical ones. They're worth putting to the IT provider or internal IT team in a specific, direct conversation.
What security tools does the business currently have? Not a broad description - a specific list of what's deployed and what it does.
What does each tool actually monitor, and what are its limitations? Microsoft Defender for Business, for example, provides endpoint detection and response capability. It generates alerts based on suspicious endpoint behaviour. Understanding what it covers - and what it doesn't - is the starting point for knowing where the gaps are.
When an alert is generated, what happens next? Who receives it? How quickly is it reviewed? What's the process for determining whether it's a genuine threat? Who makes that determination?
Is monitoring continuous, or does it happen periodically? A weekly alert review is different from continuous monitoring. Both represent a form of oversight. Understanding which one the business has is important context.
Who is responsible when something suspicious is found? Who has the authority to isolate a compromised account? Who contacts the business leadership? Who coordinates the response? If the answer to any of these involves uncertainty, that uncertainty is the gap.
What happens outside business hours? If a significant security event occurred at 2am on a Saturday, what would the detection and response process look like? Who would know, and how quickly?
How are events connected across systems? An unusual sign-in, a large file access, and a new email forwarding rule each appear in different places in a Microsoft 365 environment. Who is responsible for connecting those events and determining whether they represent a coordinated attack?
Does our IT provider's agreement include security monitoring, or IT management? These are different services, and the distinction matters. Managing a Microsoft 365 environment and continuously monitoring its security events are different responsibilities - even when they're delivered by the same organisation.
These questions don't have wrong answers. They're designed to produce clarity - a clear picture of what's covered, what's not, and where accountability sits.
MDR - Managed Detection and Response - is the service designed to close the gap between having security tools and having security operations.
It's worth being precise about what MDR is and isn't. It's not a security tool. It's a service that combines security technology - endpoint detection and response, identity monitoring, Microsoft 365 security signals, network visibility - with a team of security analysts who monitor those signals continuously, investigate alerts, correlate activity across systems, and take action when they find something that requires a response.
The distinction TPx's July 2026 analysis makes is useful: "EDR gives visibility and response capability. It does not automatically solve the human capacity problem. MDR adds the human layer. With MDR, security analysts monitor alerts, investigate suspicious activity."
What that human layer specifically changes, in business terms:
Alerts are investigated, not just received - When something suspicious happens, a security analyst reviews it - not eventually, but as part of a continuous monitoring process. They determine whether it's a genuine threat, a false positive, or something that warrants escalation to the business.
Events are correlated across systems - An MDR team isn't reviewing individual alerts in isolation. They're looking at activity across endpoints, identity, email, and cloud applications simultaneously - connecting the events that individually look ambiguous but together describe an attack pattern.
Investigation happens after hours - Ransomware is routinely deployed outside business hours. An MDR service provides coverage when the business's internal team isn't available - because attackers don't schedule their activity around IT support hours.
Response has clear ownership - When a genuine threat is confirmed, the MDR team has the authority and the process to take immediate action - isolating a compromised account, blocking a suspicious connection, containing the activity before it spreads - and the business is notified at the same time, not after.
Unanswered questions get answered - When a suspicious event is identified and investigated, the business doesn't have to live with uncertainty. Was the account compromised? What did the attacker access? Are they still active? Were other systems affected? These questions have answers when someone has investigated properly.
Eye Security's January 2026 analysis of 630 incidents found that MDR environments reduced business email compromise dwell time from 24 days to under 24 minutes - a reduction of 99.9%. The significance isn't the specific numbers. It's what dwell time represents: every day an attacker spends undetected in an environment is another day of potential access, data exfiltration, and preparation for whatever their ultimate objective is. Shrinking that window from weeks to minutes is the operational value of having someone who is actually watching.
For NZ SMEs specifically, MDR resolves a structural problem: the businesses that most need continuous security monitoring are the ones least likely to have the internal resources to deliver it. A team of one or two IT staff cannot realistically provide 24/7 security operations while also running the helpdesk, managing devices, and administering Microsoft 365. MDR provides the monitoring capability those businesses need without requiring them to build - and staff, and train, and retain - a security operations function.
The central point of this article isn't that NZ businesses have bad security. It's that security monitoring is a function that requires a clear owner, and that owner needs to be identified explicitly rather than assumed.
If the business assumes its IT provider is monitoring security events and the IT provider considers security monitoring a separate service from IT management - both of which are common, reasonable positions - there is a gap. Nobody is wrong. The responsibilities simply haven't been mapped clearly enough to identify where the gap is.
NSP's Managed Detection and Response service provides that explicit ownership. The NSP MDR service is built for NZ SMEs - businesses that are using Microsoft 365, have security tools in place, and need continuous monitoring and response capability without building a security operations centre internally. It provides 24/7 monitoring across endpoints, identity, email, and cloud activity; alert investigation and triage by security analysts; threat hunting; and a clear escalation and response process that means the business always knows what's being watched, what happens when something is found, and who is responsible for the response.
The goal isn't to add another layer of security technology. It's to ensure that the security technology already in place is backed by someone who is actively watching it.
Your business may have invested genuinely in cybersecurity. The tools are deployed. The controls are in place.
But if something suspicious happened in your environment tonight - a credential used from an unfamiliar location, an endpoint behaving in a way that suggests compromise, an email forwarding rule appearing on an account that shouldn't have one - the question worth having a clear, direct answer to is:
Who would see it? Who would investigate it? What would they do? And how quickly?
If the answer is uncertain, the monitoring gap is the gap worth closing.
Talk to NSP about MDR for your NZ business →
Or call us: 0508 010 101
What is the difference between having security software and having security monitoring?
Security software - endpoint protection, Microsoft Defender, email security - detects threats and generates alerts. Security monitoring is the ongoing process of reviewing those alerts, investigating what they mean, and deciding what to do about them. The software produces information. Monitoring is what transforms that information into action. A business can have comprehensive security software with no active monitoring - alerts generated but nobody consistently reviewing or investigating them.
Does Microsoft Defender monitor alerts automatically?
Microsoft Defender provides significant automated detection capability - it blocks known threats, generates alerts based on suspicious behaviour, and in some configurations can take automated response actions. What it doesn't provide is the human investigation and decision-making that determines whether an alert represents a genuine attack, how far it has spread, what the affected account accessed, and whether broader investigation or response is needed. Those are the functions security operations - or MDR - add.
What is MDR and how is it different from antivirus or EDR?
Antivirus detects known threats based on signatures. EDR (Endpoint Detection and Response) adds behavioural monitoring and generates alerts on suspicious endpoint activity. MDR (Managed Detection and Response) adds the human layer: security analysts who monitor alerts from EDR and other security tools, investigate suspicious activity, correlate events across multiple systems, and respond when a genuine threat is confirmed. MDR is a service, not a product - it's the combination of security technology and continuous human expertise.
Can a small IT team realistically monitor security alerts continuously?
For most lean NZ IT teams, no - not while also managing devices, user support, Microsoft 365, and operational IT responsibilities. Continuous security monitoring requires dedicated capacity, specific expertise, and after-hours coverage that a generalist IT function typically can't provide alongside its other responsibilities. This is the problem MDR is designed to solve: providing the monitoring capability businesses need without requiring them to staff a security operations centre.
What happens outside business hours without dedicated monitoring?
Attacks - particularly ransomware deployments - are routinely timed for outside business hours, specifically because detection and response capability is reduced. A security event that occurs at 11pm may not be seen until the following morning. CrowdStrike's 2026 research found the average attacker breakout time is 29 minutes - meaning the window between initial compromise and lateral movement to other systems is less than half an hour. Without after-hours monitoring, that window is wide open.
What questions should we ask our IT provider about security monitoring?
The most important questions are: What security tools are deployed and what do they monitor? When an alert is generated, who reviews it and how quickly? Is monitoring continuous or periodic? What happens outside business hours? Who has authority to take response action - isolate an account, block a connection - when a genuine threat is confirmed? And is security monitoring included in the current agreement, or is it a separate service? These questions produce clarity about what's covered and where the gaps are.
When should a business consider MDR?
When it has security tools in place but no clear owner for what happens when those tools generate alerts. When the internal IT team doesn't have capacity to monitor continuously alongside its other responsibilities. When after-hours coverage is a gap. When the business has been through a security incident and doesn't want to repeat the experience of finding out after the fact. And when leadership can't comfortably answer the question: if something suspicious happened tonight, who would know?