Adding security services to your portfolio: the good, the bad, the ugly

Rūta Jašinskienė is a cybersecurity capacity-building expert at NRD Cyber Security who specialises in the establishment of security teams, such as CSIRTs and SOCs. She has helped many security teams to develop their service composition, select appropriate tools and put relevant practices and procedures in place. We invited her to share her insights and experiences on successfully adding security services as an additional business line.

Adding Security Monitoring Services: the obvious things we often overlook

Adding Managed Security Services (MSS) or Security Operations Centre (SOC)-as-a-Service to an existing portfolio may seem deceptively simple. If a company already works with enterprise customers, manages infrastructure or cloud environments, and provides IT or cybersecurity consulting, adding security monitoring may seem like a logical next step. Furthermore, there is a demand for it: regulations are pushing organisations to improve their security capabilities, IT environments are becoming more complicated, and it is not getting easier to find people with the right skills. So why not add security monitoring to the portfolio? Sounds easy, right? Then reality kicks in.

I would like to make one thing clear from the outset: I’m definitely not trying to frighten you or limit your choices. Our company has been through this process itself, and I remember how painful and time-consuming some parts of it were, and how much easier it would have been to have had someone to help us along the way.

Let’s cover several points that may seem obvious, but which are surprisingly easy to overlook or not examine closely enough.

First, decide what you are actually selling

Don’t build the SOC first and then try to figure out what you’re selling. ‘MSS/SOC services’ can mean almost anything. It could involve monitoring business hours or providing a 24/7 service. It could focus on SIEM monitoring, endpoint security, network traffic, cloud environments, or a combination of these. It could include alert triage, investigation, threat hunting, incident response or vulnerability management, or it could be something else entirely. There is no standard MSS package that can simply be activated.

So, define the service first. The more precisely the service is defined, the easier it is to build the operation behind it. Vague promises lead to expensive operations.

The service definition affects almost everything that comes afterwards, including staffing, technology, processes, pricing, and eventually the cost of delivering the service.

The team comprises more than just analysts

The question of what constitutes the ‘right’ SOC team usually arises quite quickly. There is no magic number. The operational models of a small business-hours monitoring service and a 24/7 service are completely different.

Security analysts and detection engineers are obvious requirements. Other roles are less obvious: someone must manage customer relationships, service expectations and reporting. Someone also needs to take ownership of the service as a product, including what is and isn’t included, how it is delivered, how it changes, and whether it is profitable.

It’s tempting to want to build every capability on day one: threat hunting, forensics, penetration testing, intelligence gathering and incident response. All of these are useful. However, none of these need to be full-time from day one. The important thing is to understand what customers are buying now, and which capabilities will genuinely be needed to deliver it. Everything else can come later.

Technology can become expensive surprisingly quickly

There’s no shortage of platforms promising better detection, automation, and AI-powered everything, such as SIEM, XDR, EDR, NDR, SOAR, and whatever else is trending. However, choosing technology should come after defining the service, not before. The technology must support what you have promised to deliver, and it must also work with your customers’ environments, not just yours. More importantly, it shouldn’t be an impressive technology stack that solves problems your customers don’t have. The goal isn’t to have a technically impressive SOC; it’s to deliver a defined security service that is both high-quality and cost-effective.

Another magic word is SOAR and AI — it seems they can solve everything. This time, I won’t talk about AI—I’ll leave that to the vendors’ marketing teams. Automation is one of the most attractive aspects of modern security operations. It can genuinely help. However, automation doesn’t remove the need for a process. In fact, it quickly exposes poor processes. SOAR is only as good as the process it automates. For example, if you don’t know who is authorised to isolate an endpoint, automating endpoint isolation won’t solve the governance problem — it will just allow the unresolved decision to happen faster. The same logic applies to alert enrichment, ticket creation, escalation and response actions. Before automating anything, ask yourself: do we actually have a clear, repeatable process that is worth automating? If not, perhaps the first purchase shouldn’t be more automation.

Also, don’t underestimate the time it takes to select and negotiate with vendors. Believe me, marketing material rarely reflects how a product actually behaves in a real operational environment.

Can policies, processes and procedures really save money?

The whole point of technology is that it saves money. However, technology only saves money if it is used consistently by everyone. This is not a technology problem, but a process problem. Take onboarding, for example. How long does it take? How much tuning does it require? How much custom reporting is requested? How much of it is manual work that someone has to oversee? None of these factors are determined by the SIEM you bought; they are determined by whether onboarding follows a defined, repeatable process or is reinvented for every customer. If adding a new customer results in almost proportional operational effort, your fancy technology isn’t saving money anymore. It’s just generating alerts and manual work on a large scale. Scaling up then becomes a slow-motion problem rather than a growth story.

This is why standardisation, automation and clearly defined service boundaries are not just technical ‘nice-to-haves’ – they determine whether your technology investment pays off. Process is what turns a tool’s theoretical capability into consistent, repeatable savings. Without them, you’re not automating a service — you’re just automating chaos, customer by customer.

Therefore, the honest answer is that technology and process are not two competing priorities to balance. Technology sets the ceiling on what’s possible. Process determines how much of that potential you actually realise. The funny thing is that machines don’t solve governance issues; people and processes do.

How do we convince customers to buy it?

Having a SOC does not automatically generate demand for your MSS service. Nobody buys an SOC. They buy an outcome. Customers need to understand the problem you solve, what they will receive, what they will be responsible for, how you differ from the alternatives and why outsourcing this makes commercial sense for them.

Even a technically impressive proposal can be commercially weak. Therefore, the value proposition should focus more on the outcome than the technology.

Security monitoring is a shared responsibility

One of the most important things to agree on before launching an MSS is the point at which the provider’s responsibility ends. While the provider can monitor, analyse, investigate and escalate issues, they cannot control everything that happens within the customer’s environment. Logs still need to flow. Endpoint agents need to function. Access must be available. Vulnerabilities still need to be fixed. Furthermore, someone on the customer side must be responsible for decisions that the provider cannot make on their behalf. These boundaries must be clearly defined in the service description and service agreement. Otherwise, the customer may believe that they have outsourced security, whereas the provider may believe that they have only outsourced monitoring. This difference can lead to uncomfortable situations during an incident.

Finally, bear in mind that you are not the first to create an MSS portfolio

Don’t be shy to ask help from outside, you are not the first who builds this business line. For sure it is possible to do it on your own but if you want to skip a lot of burden and jump more quickly to the real service delivery – try to turn others mistakes to your benefit because launching MSS was never about building a SOC. It’s about turning security monitoring capabilities into a repeatable, trusted, and commercially sustainable service.

The images for this article have been generated using AI in Art Deco style (similar to the early 20th century painter Tamara de Lempicka).