An IT director at a company employing a few hundred people receives a one-sentence instruction from the board: “if we cannot afford our own security team, let us buy that SOC service”. The instruction sounds sensible and usually is. The trouble starts a few months later, at two in the morning, when the provider’s analyst sees a domain administrator authentication in the logs from an address that has never appeared there before and dials the duty number given in the contract. The person who picks up has no authority to switch anything off.
This text does not compare the cost of building your own security operations centre with the price of a service — that is a separate subject, set out in the analysis of in-house and managed model costs. What interests us here is the question that appears least often in offers and decides the value of the whole service: what stays on your side once you have bought the SOC. The reference point is NIST SP 800-61r3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management (April 2025) — a document that describes incident handling as a function of the organisation rather than as a product — together with Directive (EU) 2022/2555 (NIS2), which does something non-obvious when you outsource: it makes your provider part of your supply chain.
What exactly are you buying when you order SOC as a service?
You are buying the capacity to handle events: people on shifts, correlation tooling, a procedure and working hours. You are not buying the incident response function as a whole, because that function also covers decisions, legal competences and knowledge of the company that no provider has or can have.
NIST SP 800-61r3 puts it plainly when it lists three ways of staffing the incident handler role: an in-house team, a contract with an external party — the document explicitly names here the outsourcing of a security operations centre to a managed security services provider — and support reachable on demand — from a parent company, from a business partner, or from law enforcement. It adds that many organisations combine these routes: they handle basic events with their own resources and reach for external ones for selected categories of incident.
For a mid-sized company the practical consequence is that ordering the service splits the function into two parts with different owners. The provider takes the observational and analytical part. You are left with the decision-making, contextual and regulatory part. If the contract describes only the first, the second does not disappear — it simply has no owner, and that is the worst possible state.
The second thing worth settling at the outset is the scope of observation and the hours. The phrase “round the clock” covers at least three different arrangements: an analyst on the night shift, an on-call duty with a defined time to reach the console, and automated correlation where a human appears only in the morning. Each of them is honestly described as a round-the-clock service and each looks different at three in the morning. One question settles it: who is sitting where at the moment the highest-priority event arrives. This article settles how to choose and contract such an arrangement; what each of them costs in detection time is written out separately in the article on how to reduce mean time to detect (MTTD).
The third thing is the data sources, because they define the boundary of what can be seen. The service observes only what reaches it: logs from the identity system, mail, workstations, edge devices, critical applications. Each of those sources carries an onboarding cost — not always financial, more often in the form of your team’s work on configuration and on keeping the forwarding alive. An offer that does not name the sources describes a scope that cannot be verified.
That is why the first thing to establish when reading an offer is not the technology but the verbs. Does the provider “inform” or “respond”? Does it “recommend disconnection” or “disconnect”? Does it “prepare material for the notification” or “notify”? Three pairs of verbs, three entirely different services, and three different levels of work left on your side after go-live.
Box — three questions worth asking before signing
- What exactly happens between detection and contact with my company — who classifies the event and against whose criteria?
- Which containment actions will the provider perform on its own, and for which does it wait for my approval?
- Who on my side answers the phone at night, and what decision-making authority do they hold?
Why is the “own SOC or a service” question the wrong one for a mid-sized company?
Because it assumes you are choosing between two complete solutions, whereas in reality you are choosing a dividing line inside a single function. Even an unusually broad service leaves on your side a set of obligations that cannot be transferred — and a very frugal in-house model still needs external support during a serious incident.
NIST SP 800-61r3 describes the arrangement with a provider as “a shared responsibility model in which the organization transfers some of its responsibilities to a provider” — with the stress on some. The document adds a sentence worth reading twice: „These responsibilities should be clearly defined in a contract, and the incident response team should be aware of the division of responsibilities, including information flows, coordination, and authority to act on behalf of the organization” (NIST SP 800-61r3, section 2.2).
Note the last element. “Authority to act on behalf of the organisation” is not a piece of legal boilerplate added for good order — it is the only thing that, at two in the morning, separates a service from a subscription to notifications. If the contract does not contain it, the provider will call and wait, and the clock will keep running.
Two neighbouring questions are set out separately so that we do not duplicate content. If you are looking for the economics of both models, the right text is our cost analysis of the in-house and managed models — it breaks down the cost items, while this article deliberately gives no price ranges at all. If, on the other hand, you already run a SIEM platform and are wondering whether the service complements it or replaces it, that thread is carried by the article on why a SIEM without a SOC does not work, which looks at the same fork from the tooling side. Those two texts and this article describe the same decision from three different angles: cost, tooling and responsibility.
Which obligations stay on your side even if you buy the full service?
Five groups remain, each for a different reason. The first is high-impact decisions. NIST SP 800-61r3, describing incident response roles, assigns to the organisation’s leadership the oversight of incident response and the allocation of funding, and notes that leadership may have decision-making authority over high-impact response actions — it gives, as examples, shutting a critical service down and rebuilding one. The provider can prepare and justify those decisions. It cannot take them for you, because it does not bear their business consequences.
The second group is knowledge of the company. The same document lists asset owners — of systems, of data and of business processes — among the roles, as people holding valuable insight into response and recovery priorities, and as people who have to be told where the work stands as it progresses. The provider knows your logs. It does not know that halting one application will stop dispatch from the warehouse while halting another will merely delay the monthly report.
The third group covers obligations towards the regulatory and legal environment. NIST singles out the role of legal experts, who look at supplier and third-party agreements for whatever they imply about handling an incident, and the role of media relations. In Polish conditions the NIS2 reporting obligation is added on top, and we return to it in a separate section.
The fourth group is the execution of technical changes. NIST lists among the roles the technology professionals — architects, engineers and administrators of systems, networks and cloud, as well as software developers — as people involved in response and recovery. Someone on your side installs the patch, rebuilds the server and changes the firewall rule. A SOC provider can say what to do and confirm that it worked; it does not replace the operations team, and in a mid-sized company that team is usually the same team that runs the service desk.
The fifth group is the one most often omitted from offers: human resources and physical security. NIST lists human resources practices — pre-employment screening, onboarding, offboarding and position changes — as well as the situation in which suspicion of causing an incident on purpose falls on an employee. The document also notes that some incidents run through a physical security breach and that the response team may need access to facilities. None of that can be bought together with monitoring.
How do you set out a responsibility matrix between the company and the provider?
The simplest way is a table in which the third column matters more than the first two. The “provider” and “us” columns are easy to fill in and usually match the offer. Only the “what happens if nobody agrees it” column shows where the hole in the contract is — because an obligation without an owner does not disappear, it comes back to you at the worst possible moment.
| Activity | Who performs it in a typical offer | What must stay on your side | Consequence of leaving it unsettled |
|---|---|---|---|
| Collecting and correlating events | provider | naming the log sources and keeping them flowing | the service monitors a slice of the environment and the report looks calm |
| Classifying an event as an incident | provider, against its own criteria | approving the criteria and significance thresholds for your business | an incident rated “high” by the provider may be irrelevant to you, and the reverse |
| Containing an attack (blocking an account, isolating a workstation) | depends on the contract | written authority and its limits | the analyst calls and waits; the clock runs |
| Deciding to shut down a production service | never the provider | a named duty decision-maker with authority | the decision is taken in the morning, after the attack has finished |
| Notifying the competent authority | never the provider | a notification process and an accountable person | the NIS2 deadline runs whether or not anyone remembers it |
| Informing customers and partners | never the provider | a prepared communication scenario | the statement is written under pressure, without legal sign-off |
| Restoring a system from backup | usually your team or your IT provider | agreeing the restoration order | two teams restore in opposite dependency order |
| Establishing the root cause | provider | giving access to the context of changes and deployments | the analysis ends at “unknown vector” |
| Lessons learned and configuration change | jointly | an owner for the change and a deadline | the same incident returns next quarter |
| Monitoring the provider itself | nobody, unless you agree it | reviewing its access and its actions | see the supply chain section |
It is worth filling in this table before choosing a provider and then holding it against every offer as a sieve. An offer that fills the first column generously and leaves the third one empty is not cheaper — it is simply unfinished, and you will do the remaining work yourself, only without a plan.
Who decides to disconnect a system in the middle of the night?
Someone you name, with a deputy, and to whom you give written authority. That sentence sounds trivial until you set it against the way most deployments look: the duty number leads to a round-the-clock IT service desk, and the service desk has no right to stop anything running in production.
NIST SP 800-61r3 treats this point as a matter for the contract, not for internal organisation. Among the restrictions the contract should place on the provider it explicitly lists making and implementing operational decisions — giving as an example the immediate deactivation of certain services in order to contain an incident. In other words: that authority is either granted to the provider in writing or withheld from it. There is no third option, and its absence from the contract means “not permitted” by default.
The practical arrangement that works in companies without their own security team is prior authorisation of a narrow catalogue of actions. Not “the provider may do anything” and not “the provider may do nothing”, but a list: blocking a user account — yes, without asking; isolating a workstation from the network — yes, with notification; blocking an administrative account — after contacting the decision-maker; shutting down a production system — never without a decision on your side. Four levels are enough, and each of them needs its own sentence in the contract.
The second thing to settle is the time window. If the duty decision-maker does not answer, what happens next? The contract should answer that with a number of minutes and an escalation path, not with the phrase “the provider will attempt to make contact”. Our deployment experience shows that it is precisely this clause — not the monitoring scope and not the class of tooling — that most often decides whether the service genuinely shortened the incident or merely documented it.
Box — four levels of authorisation for containment actions
- Level 1 — the provider acts alone and informs afterwards: blocking a user account, revoking sessions, blocking an address at the network edge.
- Level 2 — the provider acts alone and informs immediately: isolating a single workstation from the network.
- Level 3 — after contacting the duty decision-maker: blocking a privileged account, cutting off a network segment.
- Level 4 — a decision on your side only: halting a production system, rebuilding the environment, external notification.
The last element of this section concerns the record. Every decision taken during an incident — including the decision not to act — should land in a single register shared by both sides, with the time, the author and the justification. This is not a formality: when the final report for the authority is drafted and the board asks for an account, reconstructing the timeline from the memory of two teams that worked through the night is a task nobody performs well. A register kept live by the provider, with your access to it, costs one sentence in the contract.
Who reports the incident to the authority, and why will the provider not do it for you?
The entity covered by the obligation reports it, which means your company. Directive (EU) 2022/2555 (NIS2) places the reporting obligations in Article 23 on essential and important entities, not on their service providers. The schedule has three steps: an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report within one month of the notification.
The SOC provider is both very useful and entirely unaccountable here — in the legal sense, not the colloquial one. Useful, because it holds the factual material: the time of first observation, the range of affected systems, a preliminary assessment of the vector. Unaccountable, because Article 20 of NIS2 places responsibility for cybersecurity risk management with the management bodies of the entity — they approve the measures and oversee their implementation, and it is on them that the directive provides for liability for breaching those obligations.
The operational conclusion is simple and rarely drawn at the procurement stage. A SOC service contract should contain a clause on the deadline and format for handing over the material for the notification, calculated so that it leaves your team time to decide. If the provider undertakes to deliver an incident description “without undue delay” while you have a day for the early warning, the risk of missing the deadline is entirely yours.
A separate matter is who assesses whether the incident crossed the significance threshold at all. Article 23(3) of the directive treats an incident as significant where it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned, or where it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. Neither criterion is technical — both refer to a business consequence the SOC provider does not know. Assessing the threshold is therefore your company’s task, performed on material supplied by the provider, and it is worth having a written way of doing it ready instead of improvising on the day of the incident.
It is also worth settling in advance who drafts the text of the notification. Technical material from the provider and a notification to the authority are two different documents written in two different languages. Companies that did not separate them usually discover the difference on the day they have the least time.
What will the provider not learn about your company unless you tell it?
It will not learn anything that leaves no trace in the logs — and that is precisely the knowledge that separates an alert from an incident. The provider can see that the svc-integration account started reading a resource at three in the morning that it had never read before. It does not know whether that is a new process deployed yesterday by an integrator or the beginning of exfiltration.
The material that has to be handed over when the service starts is finite and fits into a single document. It consists of an inventory of systems with a business owner for each, a dependency map (“what stops working if we halt X”), a calendar of maintenance windows and deployments, a list of technical accounts with a justification for each, a register of suppliers holding remote access, and a description of the seasonality of the business. Without the last item the provider will escalate elevated traffic during the sales peak as an anomaly, and in the following season will stop doing so because it has learned to ignore it — and will then miss the real one.
That same material has to be maintained, not merely handed over. NIST SP 800-61r3 treats asset owners as permanent participants in the process who need to be kept informed about the status of response and recovery, not as a one-off source of input data. In practice that means one quarterly review: what has been added, what has disappeared, whose remit has changed.
Services bought outside the IT department need separate handling. In a company employing a few hundred people there are almost always several subscription applications that marketing, HR or sales launched on their own and that hold data genuinely material to the business. From the SOC provider’s point of view those systems do not exist until somebody names them and routes logs out of them. A review of corporate card invoices is often a more effective inventory tool here than a network scan.
There is one more element that offers pass over in silence and that is decisive in manufacturing and logistics companies: the operational technology environment. Controllers, operator panels and industrial networks rarely fit within the standard scope of the service, and even more rarely may a typical containment action be performed on them. If you have such a part of the infrastructure, it has to be described separately in the contract — together with a prohibition on automatic isolation.
What should the contract require so that the service can be held to account?
Six things, none of which concerns technology. The first is the split of roles described in the previous sections, together with the “authority to act on behalf of the organization” and its limits. The second is information flows and coordination rules — NIST lists them in the same breath as the split of responsibilities, because without them the split is a declaration.
The third is the disclosure obligation. The NIST SP 800-61r3 profile for the CSF 2.0 framework, in subcategory GV.SC-05 on requirements integrated into contracts with suppliers, recommends that those requirements cover cybersecurity performance as well as vulnerability, threat and incident disclosure together with information sharing. Translated into contract language: the provider tells you about incidents at its own end, not only about incidents at yours.
The fourth is restrictions. The same document indicates that the contract should define what the provider may not do — it lists here the sharing of sanitised incident information with other customers and the making of operational decisions. The first can work in your favour, because a provider correlating events across customers detects faster than a single organisation could; NIST records that explicitly as an advantage of the service model. But it is you who decides in what form your data enters that correlation.
The fifth is evidence for the auditor. A monthly report containing the number of tickets handled and nothing else is evidence of nothing. A useful set comprises a register of events with their classification, case histories with a timeline, a list of the detection rules running in your environment together with the date each was last changed, and a record of escalation path tests. The last item is testable — and should be tested at least once a quarter, as an unannounced exercise.
The sixth is the right to verify. In a service where the provider holds privileged access to your systems, the right to audit and to test the response path is not a privilege — it is the only way to establish that the service works before an attacker establishes it for you.
One thing in this contract should not be taken on trust: response times. Timing parameters have value when they are written down together with a definition of the moment the clock starts, a catalogue of exclusions and a consequence for missing them. A number in marketing material, without those three elements, is not a commitment. Our deployment experience shows that the conversation about the definition of the starting moment is often harder than the conversation about the number itself — and it is that conversation which reveals how the provider understands its own service.
Why does the SOC provider itself become part of your supply chain?
Because the directive says so, and because it follows from the technical facts. Article 21(2)(d) of Directive (EU) 2022/2555 lists supply chain security among the minimum risk-management measures, including security-related aspects concerning the relationships between the entity and its direct suppliers or service providers. A SOC provider is a direct service provider in the most literal sense: it has access to your logs, often to your systems, and in a model with containment actions also to your administrative consoles.
NIST SP 800-61r3 names this risk directly. Service providers often hold privileged access to the organisation’s systems and frequently reach its sensitive data as well, so two risks have to be weighed and answered: a hostile insider on the provider’s payroll, and the provider itself being breached. As tools the document points to non-disclosure agreements and contracting clauses.
Moreover, that document’s profile for the CSF 2.0 framework assigns subcategory DE.CM-06 — the monitoring of external service provider activities and services for potentially adverse events — a high priority, the same one held by the core detection categories. The recommendation attached to that subcategory names “remote and on-site administration and maintenance activities that providers perform on organizational systems”, as well as deviations from the expected behaviour of services.
For a mid-sized company this means a task that looks absurd at first glance: you have to monitor your own SOC. This is not about a second team of analysts. It is about three mechanisms: a register of the provider’s accounts reviewed whenever its team composition changes, logging of administrative sessions on your side (not only on its), and a quarterly review of whether the scope of access still matches the scope of the service. None of these mechanisms requires a new tool — each requires an entry in the contract and in the calendar.
On top of this comes the provider’s own supply chain. A SOC service is rarely delivered in full by a single entity: the correlation platform may belong to someone else, the night shift may run from another country, and malware analysis may be subcontracted further. The contract should impose a duty to disclose such subcontractors and to report changes among them, because your obligation under Article 21(2)(d) concerns the relationship with the direct service provider — but the risk flowing through that relationship travels a longer road. The question worth starting from is this: from which jurisdiction and through which account does someone actually log in to my console?
Subcategory GV.SC-08 of the same profile adds an element that is easy to forget: suppliers and other third parties are to be included in incident planning, response and recovery. Which means that an exercise testing the response plan without the participation of the SOC provider tests a plan that does not exist in reality.
How do you plan the exit from the service before you order it?
By writing four things into the contract you are signing now — not into an annex you will sign on the day of termination. The NIST SP 800-61r3 profile for the CSF 2.0 framework points to this in subcategory GV.SC-10, which requires supply chain risk management plans to cover what has to happen once a partnership or a service agreement ends.
The first thing is the data. Logs collected while the service ran, case histories with timelines and the actions taken, analysis results — all of it is evidence you may need long after the relationship ends, whether before a regulator or in a dispute. The contract has to define the handover format and the deadline, and a format of “access to the portal for thirty days after termination” is not a handover of data.
The second is the detection rules built for your environment. This is an area where the parties’ interests diverge and it is better settled at the start: a rule describing your business processes is closer to your property than to the provider’s know-how, but without a clause in the contract it leaves with the provider.
The third is the transition period. Handing the service over between providers, or to an internal team, requires parallel monitoring, because otherwise a window without observation appears — and that is exactly the moment when an attacker does not have to be particularly skilled to walk in unnoticed.
The fourth is deletion of the data on the provider’s side, with confirmation. Without that clause your logs remain on someone else’s infrastructure indefinitely, and you lose control over them while retaining responsibility for them.
What scope of protection is realistic for a company without its own security team?
One that matches the organisation’s actual maturity rather than the declarations in an offer. A good reference point is the division into implementation groups in the CIS Critical Security Controls. The first group (IG1) is described as essential cyber hygiene and comprises a set of 56 safeguards; a typical enterprise in that group is small or medium-sized and has limited IT and cybersecurity expertise. The second group (IG2) adds a further 74 safeguards, and CIS describes its typical enterprise in these words: “an IG2 enterprise employs individuals who are responsible for managing and protecting IT infrastructure”.
That distinction translates directly into the purchase of a SOC service. Monitoring does not create safeguards — it observes the ones that exist. If the environment lacks an asset inventory, control over privileged accounts and backups verified by restoration, a SOC service will give you reliable knowledge of what an attack looks like in an organisation without those safeguards. The knowledge will be true. It will also be late.
The practical order for a company employing a few hundred people is usually this: first close the basic hygiene of the first implementation group, in parallel start the service within a narrow, well-described scope (identity, mail, workstations, the network edge), and tie every extension of the scope to the maturity of the next area. The reverse order — a broad monitoring scope over an immature environment — produces a stream of tickets nobody can act on and ends with rules being muted.
The order does not have to mean delay. Closing basic hygiene and starting a narrow service can run in parallel, provided you establish in advance which safeguard must be in place before which log source is switched on. A rule of thumb that works in practice: a source enters monitoring only once it has an assigned owner and a documented way of responding to the most frequent alert from it. Without those two things you are adding a stream of tickets, not a detection capability.
It is also worth saying honestly what the service does not change. It does not change the fact that somebody has to patch systems, keep a change register and answer the phone. It changes who is watching and who classifies — and in a company without its own security team that is a change large enough to be worth buying. Provided it is bought with open eyes.
When does the service model make no sense — and how do you check before signing?
When one of the boundary conditions is unmet in a way the contract will not repair. The table below gathers the signals worth going through before the decision — each of them can be checked in a single afternoon, without involving a provider.
| Signal to check | How to check it | What a negative result means | What to do instead of signing |
|---|---|---|---|
| A current inventory of systems with business owners exists | ask for the list and check the date it was last changed | the provider will monitor a slice nobody can describe | rebuild the inventory; it is a precondition, not a stage |
| A duty decision-maker with authority to halt a service is named | ask who took the last such decision and when | the service will end at notifications | designate the role and write down its limits |
| Someone can answer the phone outside working hours | make a test call on a Saturday | the cost of a night service buys time you will not use | start with a working-hours scope |
| Logs from key systems are complete and retained | check one system for gaps over the last quarter | detection will be nominal | tidy up the sources before starting the service |
| Law and contracts allow data to leave for the provider | review with the legal team and with customer contracts | the regulatory risk outweighs the benefit | a local model or a restricted scope |
| The environment is not mostly operational technology | count the share of industrial systems | a typical service will not cover the core of your risk | a specialised service, separate scope |
| The company is ready to maintain business context | establish who owns the quarterly review | detection quality will fall after a few months | assign the role before go-live |
If all seven rows come out positive, the service model is a rational solution for a mid-sized company — and usually the only attainable one. If rows one, two and four come out negative, signing the contract is not a bad decision but a premature one: you are buying observation of an environment you have not described, and a response capability you have nobody to hand over to.
Box — one sentence worth writing into the decision note
A SOC service moves watching and classifying to the provider. It leaves the decision, the context and the obligation towards the regulator with you — and it is the quality of those three elements, not the scope of monitoring, that determines whether the first serious incident ends in a report or in downtime.
If you want to set the criteria above against a specific scope of service, the description of our security monitoring in the SOC 24/7 model shows where the dividing line in this matrix runs on our side — including what remains on the customer’s. It is worth holding the same table against it that you hold against every other offer; if any column comes out empty, that is exactly the question to raise at the meeting.
