SOC Monitoring Explained: How a Security Operations Center Detects and Responds to Threats 24/7

Security tools raise alerts all day, but alerts only protect a business when someone reads them, works out which ones matter and acts before damage spreads. That is the job of SOC monitoring. This guide explains how a security operations center watches a Microsoft 365 estate around the clock, how it turns alerts into action, what it costs and how to decide between building one and buying one.

‍

What Is SOC Monitoring?

SOC monitoring is the continuous work of a security operations center: collecting security data from across your business, spotting threats in it, and investigating and responding to them, usually 24 hours a day. It is a process run by people, not a product you install.

Tools do the collecting. A SIEM (security information and event management) platform such as Microsoft Sentinel gathers logs from across the business, and Microsoft Defender XDR (extended detection and response) watches endpoints, email, identities and cloud apps. Analysts do the judging. They decide which alerts describe a real attack, close the rest with a recorded reason, and act on the ones that matter.

In a Microsoft 365 estate, that means identity, email, endpoint and cloud signals landing in one incident queue, watched by analysts on shift rather than read the next working morning.

SOC Monitoring vs Threat Monitoring vs Security Monitoring

The three terms overlap, and providers often use them as if they mean the same thing. The difference is how much human work sits behind the alerts.

• Security monitoring is the broadest term. It covers any watching of systems for security events, including automated alerts that nobody reviews.
• Threat monitoring looks specifically for signs of an attack, and is often sold as 24/7 threat monitoring.
• SOC monitoring is threat monitoring carried out by a SOC team, which adds triage, investigation and response to the alerts.

Where SOC Monitoring Fits in Security Frameworks

NIST CSF 2.0, released on 26 February 2024, organises security into six functions: Govern, Identify, Protect, Detect, Respond and Recover. SOC monitoring delivers the Detect function and much of Respond, the two that matter once preventive controls have been bypassed. The UK’s NCSC guidance on building a SOC puts the purpose plainly: a SOC exists to “limit the damage to an organisation by detecting and responding to cyber attacks”.

Monitoring and response are still two different jobs. Monitoring decides whether an alert is real. Incident response takes over once it is. Some providers stop at monitoring and hand you the alert, while others contain the threat themselves, and that difference is worth checking before you sign anything. The trade-off is covered in monitoring-only vs response-driven SOC models.

CyberQuell is a managed security provider that runs a 24/7 SOC for small and mid-market businesses and MSPs in the United States, the United Kingdom and the United Arab Emirates. Its analysts work on Microsoft Sentinel, Splunk or the SIEM a client already runs.

‍

What Is a Security Operations Center (SOC) and What Does It Do?

A security operations center (SOC) is a team of analysts, working to documented processes with security tools, that detects, investigates and contains attacks across a business’s endpoints, email, identities, cloud and network. The team, the processes and the tools only work together: a SIEM with nobody watching it is not a SOC.

A security operations center can be a room of analysts inside one company, a service run by a provider for many clients, or a mix of the two. The job is the same in every model: find attacks that got past preventive controls and stop them before they spread.

Who Works in a Security Operations Center?

Most SOCs organise analysts into tiers, so routine alerts are handled quickly and harder cases reach people with more experience.

• Tier 1 analysts triage incoming alerts. They check each one against context, close false positives with a reason and escalate anything that looks real.
• Tier 2 analysts investigate escalated alerts. They work out how an attacker got in, how far they spread and what they touched, and they start containment.
• Tier 3 analysts and detection engineers hunt for threats no alert has caught, write and tune detection rules, and handle the most complex incidents.
• A SOC lead or manager runs the shift rota, owns the escalation process and reports to the business on incidents and performance.

In a small team one analyst may cover more than one tier, but every role still has to be filled on every shift.

What Processes Does a SOC Run?

Tools generate alerts, and processes make sure the response is the same at 3 PM on a Tuesday as at 3 AM on a Sunday. A working SOC runs four core processes.

• Playbooks: written, step-by-step responses for common incidents such as a phishing compromise or a suspicious sign-in. Many steps can run through automated SOAR playbooks, with an analyst approving the actions that carry risk.
• Escalation paths: agreed rules for who is told about what, how fast and through which channel, from the analyst on shift to your named contact.
• Shift handover: a documented hand-off of every open case, so an investigation started at night carries on in the morning without a gap.
• Post-incident review: a short write-up after each significant incident covering what happened, what worked, and which rule or playbook needs to change.

What a SOC Does Not Do

A security operations center is easier to buy, or build, when its limits are clear. A SOC does not:

• Replace your IT team. It does not manage devices, fix application bugs or answer help desk tickets.
• Change your environment without agreement. Firewall changes, patching and policy updates stay with your IT team unless they are written into the scope.
• Guarantee you will never be breached. No service can promise that. A SOC shortens the time an attacker goes unnoticed and limits what they can do.
• Work without your input. Your team still approves major business decisions, such as resetting every user’s password or taking a server offline.

‍

What Does a SOC Monitor? Data Sources, Tools and the Look-Back Window

A SOC monitors identity sign-ins, email, endpoints, cloud apps and network traffic through SIEM, XDR and EDR tools, and it can only investigate as far back as those logs are kept. What it can see depends on which data sources are connected and how long each one is retained.

SIEM vs XDR vs EDR vs SOAR vs SOC

These terms describe different layers of the same job. Only the last one includes the people who act on what the tools find. For how a managed detection service compares, see MDR vs SOC.

What a SOC Watches in Microsoft 365

In a Microsoft 365 estate, most attacks show up first in identity and email, so those are the signals a SOC watches most closely:

• Microsoft Entra ID sign-ins: who signed in, from where, with which method, and whether the sign-in was flagged as risky.
• Risky users and directory changes: new admin role assignments, MFA method changes and other suspicious account activity, the core of identity threat detection for Microsoft 365.
• Inbox rules and mailbox activity: hidden forwarding or delete rules, a common sign of business email compromise.
• OAuth app consents: third-party apps granted access to mail or files, which survive a password reset.
• Defender for Endpoint and Defender for Office 365 alerts: malware, suspicious processes and phishing that reached an inbox.
• SharePoint and OneDrive access: unusual downloads or sharing of sensitive files.

Some of these sources cost nothing to send to Microsoft Sentinel. Office 365 audit logs, Azure Activity logs and security alerts from the Defender products are free to ingest, while raw Microsoft Entra ID and Defender logs are charged.

How Far Back Can Your SOC See?

Retention does not stop a SOC detecting a new attack: today’s malicious sign-in raises an alert today. What retention limits is the investigation afterwards, meaning how far back analysts can trace the first access, find what the attacker left behind and work out what was taken.

For a business on Microsoft 365 Business Premium, which includes Entra ID P1, that means about 30 days of sign-in history unless the logs are streamed into Sentinel or another store. Retention is not retroactive either. Upgrading a licence after an incident does not bring back logs that have already expired.

Book a call with CyberQuell to see which of your Microsoft 365 logs a SOC can use today, and how far back it can look.

‍

What Is 24/7 Threat Monitoring, and Why Does Part-Time Coverage Fail?

24/7 threat monitoring means trained analysts watch and respond to alerts every hour of every day, including nights, weekends and public holidays. Part-time coverage leaves about three-quarters of the week unwatched, and that is when most attacks reach their damaging stage.

A week has 168 hours. A business-hours team working 8 hours a day, 5 days a week, covers 40 of them. For the other 128 hours, roughly 76% of the week, alerts sit in a queue until someone comes back.

Attackers plan around that gap. Sophos found that 88% of ransomware payloads were deployed outside business hours, and 79% of data exfiltration happened off-hours, across 661 incident response and MDR cases between November 2024 and October 2025. Mandiant puts the global median dwell time at 14 days, so every hour an intrusion goes unnoticed gives the attacker more room to spread.

Monitoring After Hours Is Not the Same as Responding After Hours

Many part-time setups keep their tools running overnight. Alerts still fire and get logged. What stops is the human work: triage, investigation, escalation and containment. An alert nobody reviews until Monday does not reduce risk. It only records when the attack started.

A typical failure looks like this. A stolen password is used to sign in at 11 PM on a Friday. The attacker creates a hidden inbox rule, registers a new MFA method and starts reading finance emails. The alerts fire within minutes, but in an 8x5 model they wait in the queue. By Monday morning, the attacker has had more than 50 hours inside the mailbox. With 24/7 coverage, an analyst on shift reviews the same alert that night, revokes the sessions and removes the rule.

24/7 SOC vs 8x5 Monitoring vs On-Call

What “24/7 SOC With Live Human Analysts” Should Mean

Plenty of providers say 24/7. What matters is what happens at 3 AM. Before you trust the label, check three things:

• A named analyst is on shift every hour, not just an automated alert that emails you.
• The response time is written into the contract, and the contract says when the clock starts.
• The analyst can contain an attack without waking you, within limits you agree in advance.

CyberQuell’s 24/7 SOC monitoring commits to a 15-minute response SLA on critical and high-severity alerts, with nights, weekends and public holidays included.

‍

How Does SOC Monitoring Work? From Log to Alert to Incident

SOC monitoring turns raw logs into action in six steps: collect, correlate, detect, triage, investigate and escalate. Tools handle the first three at machine speed, and analysts own the last three.

1. Collect

Connectors send logs from identity, email, endpoints, cloud apps and network devices into the SIEM. The SOC also watches the connectors themselves, because a source that goes silent leaves a blind spot nobody notices. Microsoft Sentinel’s Table insights shows when each table last received data, which is how a silent connector gets caught.

2. Correlate

Single alerts rarely tell the whole story. Microsoft defines an incident as a container of related alerts that tells the full story of an attack, and Defender XDR builds those incidents automatically. A phishing email, the sign-in that followed and the inbox rule created afterwards become one incident instead of three separate tickets.

3. Detect

Detection uses three methods side by side:

• Analytics rules that look for known attacker behaviour, mapped to MITRE ATT&CK, a public knowledge base of attacker tactics and techniques based on real-world observations.
• Threat intelligence that flags known-bad IP addresses, domains and file hashes.
• Anomaly detection, such as Sentinel’s user and entity behaviour analytics (UEBA), which learns what normal looks like for each user and device and flags anything out of the ordinary.

4. Triage

Triage decides which alerts are real. Automated filtering removes known false positives first. Then an analyst checks what remains against context: who the user is, what the device does, and whether the activity fits their normal pattern. Ranking alerts by asset criticality puts a finance director’s mailbox ahead of a test laptop.

Every alert ends with a recorded verdict. In the Defender portal, analysts classify each incident as a true positive, informational expected activity, or a false positive. That record feeds back into tuning so the same noise does not return. Repetitive triage steps are usually the first thing a SOC automates.

5. Investigate

For confirmed incidents, analysts build the timeline: how the attacker got in, which accounts and devices they touched, what they changed and what data they reached. This is where hunting queries across the last 30 days of Defender data, or longer in Sentinel, answer the questions a single alert cannot.

6. Escalate

The incident gets a severity (high, medium, low or informational), a named owner and, where the agreed scope allows it, containment. For the clearest attacks, Defender’s automatic attack disruption can contain a compromised account before an analyst even opens the incident. Your named contact is then told what happened, what has been done and what decision is needed from you. From this point, the work moves from monitoring to incident response.

‍

How Does SOC Incident Response Work?

When an alert is confirmed as an incident, the SOC contains it, removes the attacker’s access, helps you recover and writes up what happened, following limits agreed before the incident. Speed matters, but so does authority: a SOC that has to ask permission for every action loses the time it was hired to save.

NIST’s incident response guidance, SP 800-61 Revision 3, published in April 2025, folds incident response into an organisation’s wider cyber risk management, aligned with CSF 2.0. In practice, a mature SOC still works through the six incident response phases, from preparation to lessons learned.

What Containment Looks Like in Microsoft 365

Containment means cutting off the attacker’s access before they can do more. In a Microsoft 365 estate, that usually involves five actions:

• Disable the account and revoke its sessions. Revoking stops Microsoft Entra ID from issuing new tokens, but access tokens already issued stay valid until they expire, one hour by default, so a SOC disables the account at the same time.
• Remove inbox rules and forwarding. Hidden rules that forward or delete mail are a common way attackers keep watching a mailbox.
• Remove malicious app consents. An OAuth app granted access to mail or files keeps working after a password reset, which is why identity threat detection for Microsoft 365 watches app consents as closely as sign-ins.
• Isolate affected devices through Defender for Endpoint device isolation, so a compromised laptop cannot reach the rest of the network.
• Block the indicators: sender domains, IP addresses and file hashes tied to the attack.

Skipping any one of these is how attackers come back. In one CyberQuell investigation into a four-month business email compromise, session token theft and malicious Outlook rules had survived multiple remediation attempts until a forensic review found and removed them.

Who Is Allowed to Act, and When

Most delays in incident response come from unclear authority, not slow analysts. Agree in writing what each severity level allows the SOC to do without asking you:

CyberQuell’s SOC monitoring and response service commits to having an analyst engaged and actively working on containment within 15 minutes of a confirmed threat, at any hour, with response times tracked and reported monthly.

The Incident Report

Every significant incident closes with a written report covering the timeline, how the attacker got in, what they reached, every action taken and what needs to change. Leadership needs a shorter version focused on business impact and decisions, and executive reporting during a cyber incident is a different document from the technical one. Both depend on decisions made before anything goes wrong, so write the severity limits above into your incident response plan.

‍

Microsoft 365 Specialist SOC vs General-Purpose SOC

A Microsoft-specialist SOC catches identity, email and endpoint attacks inside Microsoft 365 with less integration work, because Defender XDR already correlates those signals into one incident. A general-purpose SOC fits better when much of the risk sits outside Microsoft.

Microsoft also ships detections for the attacks that matter most in Microsoft 365. They include anomalous tokens, suspicious inbox forwarding, suspicious inbox manipulation rules and suspicious credential additions. Most of them need Entra ID P2 for full detail, and a SOC that knows the stack knows which licence turns on which detection.

When a General-Purpose SOC Is the Better Choice

A Microsoft-first SOC is not the right fit for every business. Look beyond it if:

• A non-Microsoft EDR, such as CrowdStrike Falcon, is your main endpoint tool.
• Significant workloads run in AWS or Google Cloud.
• Identity runs on Okta or another non-Microsoft provider.
• You need to monitor OT or IoT environments.
• Most of your telemetry is on-premises network traffic.

The choice is rarely all or nothing. CyberQuell’s analysts work most deeply in managed Microsoft Sentinel and Defender, and also run Splunk, an existing SIEM or CrowdStrike Falcon where a client already uses them. If you are weighing Microsoft’s own managed service against an outside provider, Defender Experts vs third-party MDR covers the licensing side of that decision.

‍

What Is Threat Hunting, and How Is It Different From Monitoring?

Threat hunting is analysts searching your data for attackers that no rule has flagged yet. Monitoring reacts to alerts, while threat hunting looks for what the alerts missed.

The two work together. Detection rules catch known patterns quickly, but an attacker who uses a valid account, a legitimate tool or a new technique can stay below every alert threshold. Hunting assumes something may already be inside and goes looking for it.

How a Threat Hunt Works

Microsoft describes a hunt in Microsoft Sentinel as four moves: create a hypothesis, search the data, validate the hypothesis and act on what you find. In practice:

1. Start with a hypothesis. An analyst picks a likely attacker behaviour, often a technique from MITRE ATT&CK, recent threat intelligence or a pattern seen at another client. For example: “An attacker who phished a user last quarter set up mail forwarding that nobody noticed.”
2. Search the data. The analyst writes queries in Kusto Query Language (KQL) across Defender’s advanced hunting tables and the Sentinel workspace, looking for evidence that proves or disproves the hypothesis.
3. Validate the findings. Most hunts find nothing malicious, and that result is recorded too, because it confirms a gap is covered.
4. Act and improve. A real finding becomes an incident. Either way, a query that proved useful becomes a new custom detection rule, so the same behaviour raises an alert on its own next time.

A Threat Hunting Example in Microsoft 365

Take the forwarding hypothesis above. Here is how it plays out in a typical hunt. The analyst searches the Office 365 audit log for inbox rules created in the last 90 days that forward mail to external domains, and compares them with what each user would normally set up. One rule stands out: created at 2 AM, forwarding every email that contains “invoice” to a free webmail address, on an account that has never forwarded mail before.

That single finding opens an investigation into how the account was compromised, what else the attacker changed and whether any payment emails were intercepted. The same query is then saved as a scheduled rule, so any similar forwarding rule raises an alert the moment it is created.

How Often Should a SOC Hunt?

Microsoft’s guidance is to run threat hunting queries against the data you collect at least once a week. A mature SOC goes beyond that minimum:

• Scheduled hunts on a fixed rhythm, working through the ATT&CK techniques most relevant to your estate.
• Intelligence-led hunts when a new campaign or vulnerability is published that could affect your environment.
• Post-incident hunts after any confirmed attack, to check the attacker left nothing else behind.

Threat hunting is only as good as the intelligence behind its hypotheses, and the different types of cyber threat intelligence feed different kinds of hunts.

‍

How Do You Measure SOC Monitoring? MTTD, MTTR and Response Time

MTTD (mean time to detect) is how long an attack runs before the SOC flags it, and MTTR (mean time to respond) is how long it takes to contain it. Judge a SOC on those two numbers, its false positive rate and how much of your estate it can actually see.

MTTD matters because time is what attackers need. Mandiant’s global median dwell time of 14 days is the baseline a 24/7 SOC exists to shorten. MTTR matters because a fast detection is wasted if containment waits for business hours.

The most useful question is how a provider defines the clock. “Response time” can start when the alert fires, when an analyst opens it or when the threat is confirmed, and the same incident can produce very different numbers depending on which one is used. For a fuller scorecard, see how to measure managed SOC effectiveness.

What These Numbers Look Like in Practice

In its first six months, a CyberQuell white-label SOC serving one MSP’s small-business portfolio, which grew from 38 to 43 clients, detected and contained 127 incidents with a reported average response time of 8 minutes. Three of them:

Read these figures for what they are: self-reported results from one portfolio, not an industry benchmark. They also measure something different from CyberQuell’s 15-minute response SLA, which runs from a confirmed threat to an analyst working on containment. Ask any provider for the same three things: the incident count, the number of clients behind it, and exactly where their clock starts.

‍

How Does SOC Monitoring Support Compliance?

Most security frameworks require continuous monitoring and reviewed logs, and SOC monitoring produces the records auditors ask for. It supports compliance, but it does not certify you: the certification or attestation still comes from your auditor.

The part auditors check most closely is not whether a tool was switched on but whether anyone acted on what it found. For SOC 2 Type 2 in particular, that means evidence across the full audit period, which is covered in detail in how continuous monitoring produces SOC 2 Type 2 evidence.

For UAE businesses, CyberQuell’s SOC as a service in the UAE includes NESA T8 monitoring support, and NESA compliance services cover the wider control set. Financial free zones bring their own rules, which are covered in how a managed SOC helps UAE businesses meet DIFC and ADGM requirements.

‍

In-House SOC vs Managed SOC: Which Model Fits Your Business?

Build an in-house SOC when you can staff and keep a 24/7 rota and need tight control of your own tooling. Use a managed SOC when you need round-the-clock cover sooner than you can hire for it.

The deciding number is staffing. Covering one analyst seat for all 168 hours of the week takes more than four full-time people working 40-hour weeks, before holidays, sickness, training and turnover. A SOC also needs more than one seat, because one analyst cannot triage, investigate and contain at the same time.

Hiring those people is the hard part. In the ISC2 2025 Cybersecurity Workforce Study of 16,029 security professionals, 95% said their team has at least one skills need, and 72% agreed that cutting security staff significantly increases the risk of a breach.

Outsourcing does not hand over responsibility, though. NIST’s guidance on building a small business cybersecurity team is direct: “You are ultimately responsible for protecting your systems and data.” CISA makes the same point in its risk considerations for managed service provider customers: outsourcing does not remove an organisation’s own risk management duties and can add third-party risk. A managed SOC changes who does the work, not who is accountable.

A hybrid model, sometimes called co-managed, splits the work between an internal team and a provider. It can work well, but only when everyone knows who owns each alert at 3 AM.

Which Model Suits a Small or Mid-Sized Business?

For most businesses of 50 to 500 people, a managed SOC is the practical route to 24/7 cover. The maths of a round-the-clock rota rarely works at that size, and smaller firms face the same attacks as larger ones. Before you sign, check that:

• The provider runs 24/7 with analysts on shift, not on call.
• It works with the tools you already pay for, rather than adding a new platform.
• Pricing is predictable, so a busy month does not produce a surprise bill.
• There is a short pilot, so you can test the fit before committing.

CyberQuell’s managed SOC services run on Microsoft Sentinel, Splunk or the SIEM you already have, priced on monitored devices at a fixed monthly fee, with a 30-day pilot before any term. If you have internal IT, CyberQuell works as an extension of that team. For a closer look at where each model breaks under pressure, see managed SOC vs in-house SOC. For what stays your job after you outsource, see what stays your responsibility after you hire an MSSP.

‍

What Does SOC Monitoring Cost?

SOC monitoring cost depends on how many devices and log sources are watched, the hours of coverage and how much response is included. An in-house SOC adds salaries, tooling and staff turnover on top of that.

What Drives the Price of a Managed SOC

Five things move the price more than anything else:

• Scope: the number of endpoints, servers, users and cloud accounts being monitored.
• Log volume and sources: some providers price on data volume, which makes the bill rise in a busy month.
• Hours of coverage: 24/7 with analysts on shift costs more than business hours with an on-call number.
• Response included: containment and investigation cost more than alert forwarding, and they are worth more.
• Platform costs: if the SOC runs on Microsoft Sentinel, Microsoft charges separately for the data you ingest. Office 365 audit logs and Defender alerts are free, and the first 90 days of retention are included.

Ask every provider which of these their quote covers, and which ones can change from month to month.

What an In-House SOC Really Costs

Running your own SOC means paying for the full rota, not one analyst: more than four people to fill one seat around the clock, plus a lead and detection engineering. Add the SIEM and XDR licences, data ingestion and storage, training to keep skills current, and the cost of replacing people who leave. Salaries are the visible part, and the rest is easy to underestimate.

What Not Monitoring Costs

The other side of the calculation is the cost of a breach. IBM’s Cost of a Data Breach Report 2026 puts the global average at USD 4.99 million, a 12% rise on the previous year and a record high. Organisations that used security AI and automation extensively saw costs USD 1.93 million lower than those using none, and that kind of automated triage and response is part of how a well-run SOC works.

How CyberQuell Prices SOC Monitoring

CyberQuell prices managed SOC on monitored devices, meaning endpoints and servers, rather than log volume, so the monthly figure is fixed and predictable. There are no setup or onboarding fees. You get a firm price after a 15-minute scoping call, and a 30-day pilot on one environment before committing to a term.

For the full breakdown of internal costs, see the true cost of running an internal SOC. If you are weighing SOC monitoring against paying for incident response only when something goes wrong, what cloud incident response actually costs covers retainers and hourly rates.

‍

How to Choose a SOC Monitoring Provider: 8 Questions to Ask

Ask any provider who is on shift at 3 AM, what they may do without calling you, how fast they respond to a critical alert and what you get in writing. The answers separate a working SOC from a dashboard with a phone number.

1. Who is on shift at 3 AM on a Sunday? A good answer names live human analysts on a 24/7 rota, not an on-call engineer or an automated email.
2. What is your response SLA, and when does the clock start? Ask for the figure in the contract and the exact event that starts it.
3. What can you do without asking us? Look for agreed containment limits, such as disabling an account or isolating a device, written down before any incident.
4. Which of our tools will you run? A provider that works with your existing SIEM and endpoint tools saves you paying twice for the same coverage.
5. Which log sources will you connect, and how far back can you see? The answer should list sources and retention periods, not just say “everything”.
6. What will we receive each month? Expect the incidents handled, response times, false positive trends and the detection changes made.
7. What happens if we leave? Check the notice period, and who keeps the detection rules, playbooks and case history.
8. What evidence will you give our auditors? For ISO 27001, SOC 2 or NESA, that means monitoring records and incident reports covering the whole audit period.

For a deeper checklist, see how to evaluate SOC providers beyond tool coverage. For what the first weeks should look like once you sign, read what to expect in the first 60 days of a managed SOC. If you are comparing providers side by side, managed SOC service providers covers how to shortlist them. MSPs that want to resell SOC monitoring under their own brand can use a white-label SOC for MSPs.

‍

Final Thoughts

SOC monitoring is only as good as what happens after an alert fires. The tools you already license can collect the signals, but protection depends on analysts watching all 168 hours of the week, the authority to contain an attack without waiting for permission, and logs that reach back far enough to show what an attacker did. Start by checking those three things against your current setup. If the gaps are coverage hours or staffing, managed SOC monitoring and response closes them faster than building a team from scratch, and it lets you keep the Microsoft tools you already pay for.

Book a call with CyberQuell to map the gaps in your SOC monitoring and get a firm monthly price after a 15-minute scoping call.