MSPs and MSSPs

An MSP (managed service provider) runs IT for its clients; an MSSP (managed security service provider) runs their security monitoring and response. The line has blurred: many MSPs now sell security services, and clients often expect it. The difference that matters is what you promise. An MSSP usually commits to watching alerts within defined hours, often around the clock, with response times in the contract and staff trained for it. An MSP that adds a security tool but has no one watching at night is not an MSSP, and its contract should say so. Both can use NetSenX for detection: each client is its own tenant, and the partner programme covers MSSPs and resellers.

Yes. Each customer is its own tenant, kept apart in the database by row-level security, and each can start on the Free plan and move to the plan its network needs. That separation matters to your clients: their alerts, network maps and audit logs never mix with another client's. White-label reports are on the Enterprise plan, and the partner programme covers MSSPs and resellers, so you can agree terms before you roll out to many clients. Investigating alerts stays with you or your customer; NetSenX does not run a managed service. Describe your service on that basis: NetSenX detects and explains, your team decides and responds.

Each client is set up as its own NetSenX tenant, kept apart in the database by row-level security; how a partner works across those tenants is agreed in the partner programme. Separation is the point: one client's alerts, devices and audit log never appear in another client's view, which is what your clients and their auditors will ask about. Before you plan your operations around a single console for all clients, ask NetSenX how partner access works today and what is included at which plan, rather than assume. Each client tenant can start on the Free plan and move to the plan its network needs.

In a well-built tool, separation is enforced by the system itself, not only by the user interface, so a mistake or a bug in one screen cannot show one client's data to another. Ask vendors how: is every record tagged with a tenant, does the database refuse cross-tenant queries, and are staff accounts limited to the tenants they serve? In NetSenX each customer is its own tenant, kept apart in the database by row-level security, so queries only return rows of the tenant they belong to. On your side, give technicians separate accounts with multi-factor authentication, grant access per client, and remove it when someone leaves or a client ends the contract.

Yes. The NetSenX partner programme covers MSSPs, MSPs and resellers who want to offer network detection to their clients. Terms are agreed with each partner; the partners page describes the programme and how to apply. Before you start, decide which clients you would bring, which plans they would need, whether you need white-label reports, which are on the Enterprise plan, and who in your team will read alerts. Ask how partner access to several client tenants works and how billing is arranged, so you can price your service correctly. Whatever the terms, NetSenX remains detection software: the monitoring service and the response are yours.

With NetSenX, yes, on the Enterprise plan: reports under your own brand, together with multi-tenant deployment, by contract. On the other plans, PDF reports from the Starter plan carry the NetSenX name, which many MSPs use as an independent source next to their own service report. Each client is its own tenant either way, kept apart in the database. If white label is part of your offer, say so in the first conversation with NetSenX, so packaging and partner terms are clear before you sell it to clients, and check which plan each client needs for the reports you promise.

Yes, from the Starter plan: each client tenant can produce PDF reports from its own data, with the NetSenX name on them; reports under your own brand are on the Enterprise plan. A report is most useful when it is regular and short: what was monitored, which alerts were raised, what was done, what changed on the network, and what is still not covered. Clients in NIS2 scope and their auditors care more about evidence and dates than about charts. Pair the NetSenX report with your own service summary, and keep both, because the client may need them months later for an insurer or an authority. Free plan tenants do not have PDF reports.

For small clients, a model where one sensor covers a whole site usually works better, because per-endpoint pricing grows with every PC and phone and can exceed what the client pays you. Look at your client book: count the devices per client and the number of sites, and price both models for your five most typical clients before you choose a vendor. With NetSenX the unit is the device, but a device is a host running the agent, and one agent on a SPAN or TAP port counts as one device for the whole segment it watches. A typical small office is therefore one or a few devices, which may fit the Free plan's 3 devices or the Starter plan at €49 per month.

Keep the cost per client low and the work per alert short: one sensor per site, alerts that explain themselves, and a standard service you do not tailor for each client. For a client with five PCs and a printer, put one agent on a mirror port of the office switch instead of software on each machine. Standardise the onboarding, the alert routine and the monthly report, so every client is handled the same way. Price the service on the value of watching the network and the evidence you deliver, not on the tool alone. With NetSenX, one agent on a SPAN or TAP port counts as one device, and the Free plan covers 3 devices with no time limit, so the smallest clients can start without licence cost.

Yes. Each client tenant can start on the NetSenX Free plan, with no time limit and no credit card, and move to a paid plan when it needs more devices or features; plan changes apply immediately. The Free plan includes the core detections, the network map, NIS2 deadline tracking and the audit log, and keeps 30 days of alert history. Typical reasons to upgrade are PDF reports for the client, from the Starter plan, more devices, Shadow AI and OT visibility or Slack and webhooks from the Pro plan, and SIEM export from the Business plan. Starting free lets you show a client real findings from their own network before they commit to a budget.

A small, standard stack you can run the same way for every client: endpoint protection with central management, multi-factor authentication, backup with tested restores, e-mail security, and network detection where clients have local networks. Avoid tools that need per-client tuning or a dedicated analyst, because your margin disappears in the hours. Prefer vendors with published prices, simple licensing, clean separation between clients and alerts a technician can act on. Check how each tool protects the remote access it gives you, because your own tools are a target. NetSenX fits the network part of such a stack: one agent on a SPAN or TAP port per site, plain-language alerts and one tenant per client.

Sell a defined routine with a regular deliverable, not a tool: what you watch, when you look, what you do when something happens, and what the client receives each month or quarter. A clear package might include onboarding with a device inventory, alert review on working days, an agreed response for urgent alerts, a monthly summary and a quarterly review of what is still not covered. The deliverable is what clients and their insurers value: dated evidence that someone looks. Price it per client or per site, and say honestly what happens outside working hours. NetSenX supports this with detection and explanations on every plan, PDF reports from the Starter plan and one tenant per client.

Watch the traffic passively for a few days: most devices reveal themselves within hours, and the rest within days, as they request addresses, resolve names and talk to servers. Put one sensor on a mirror port of the main switch, then compare what appears with the client's own list, the router's connected devices and the switch's port table. Expect surprises: forgotten servers, personal devices, a supplier's router in a cabinet. A device that never sends traffic, or sits on a segment you do not mirror, will not appear, so walk the site too. NetSenX's network map does this on every plan, Free included: devices with their announced names, first and last seen, and who talks to whom, without probing anything.

Who and what is on the network, what is exposed, and whether the basics are in place. Build a device inventory from traffic and from a walk through the office. Check which services are reachable from the internet, such as remote desktop, file shares or old VPNs. List admin accounts and remove shared or former staff accounts. Confirm that backups run and that one copy is offline, and do a restore test. Check that multi-factor authentication is on for e-mail and remote access. Look for remote-access tools left by previous providers. Write down what you found and agree priorities with the client. NetSenX helps with the inventory and shows beaconing, scanning and unusual uploads from the first days.

Route each client's alerts to a channel your team actually watches, with the client's name in every message. With NetSenX, alerts from each client tenant go by e-mail on every plan; from the Pro plan they can also go to Slack, a webhook into your ticketing or on-call system, or your own tools through the API. Set rules for what reaches a person immediately and what waits for the morning review, and test the route with a harmless alert. Make sure two people receive urgent alerts, and that holidays are covered. Detection runs at all hours, but nobody at NetSenX watches your clients' alerts for you: the response is your service.

Yes, from the Pro plan: alerts from a client tenant can be sent to Slack or to a webhook, and from there into your ticketing system, chat or on-call tool; on every plan they also go by e-mail. Use a separate channel or tag per client, so a technician sees at once whose network is affected. Decide which alert levels create a ticket and which only notify, so the channel stays readable. Keep the full alert, with its explanation, in NetSenX, and link to it from the ticket rather than copying data around. From the Business plan, alerts can also be exported to a SIEM if you run one for your clients.

Tell them what happened, what it means for them, what you did, and what they need to do or decide, in plain words and without drama. Name the device and the time, say whether it was harmless, suspicious or an incident, and what evidence supports that. If you contained something, say how and whether anything is still affected. If the client must decide, for example to disconnect a server or inform staff, say so clearly and by when. If personal data or NIS2 reporting may be involved, point it out early, because deadlines can start at awareness. Keep a written record. NetSenX alerts give you the explanation to pass on, and the audit log keeps what was done.

Contain the damage, protect your own tools, preserve evidence, and inform the client's decision-makers, in that order and quickly. Isolate affected machines from the network without switching them off. Check whether the attacker used your remote-management or remote-access tool; if that is possible, suspend those sessions and reset the credentials for all clients, not just this one. Keep logs and alert history. Call an incident-response firm if the incident goes beyond your skills, and tell the client's management what you know and what they must decide, including possible reporting under NIS2 or the GDPR, which stays their duty. NetSenX shows the client's alert timeline, lateral movement and unusual uploads, which helps answer when it started and what left.

Yes, and attackers look for exactly that, because a remote management or remote access tool reaches every client at once. Protect those tools like crown jewels: multi-factor authentication, separate admin accounts per technician, restricted source addresses, logging of every session, and prompt updates of the tool itself. Review which clients each account can reach, and remove access that is no longer needed. On the network side, NetSenX flags unusual sessions and lateral movement inside each monitored client network, including sessions that start from the host running your remote-management agent at odd hours. Each client is a separate tenant, so their data stays apart.

Watch for remote sessions that do not match your technicians' work: unusual hours, unusual target machines, many machines in a short time, or sessions followed by new connections inside the client network. Start in the tool itself: enable its audit log, alert on new admin accounts and on scripts pushed to many devices, and review it weekly. Compare sessions with your ticket system. On the network side, a sensor in each client network sees what happens after a session starts: a host suddenly connecting to many others, scanning, or sending data out. NetSenX flags lateral movement and new sessions that do not fit a host's normal, on every plan, in each client's own tenant.

Your own sign-ins, your management tools' audit logs, and the traffic your tools create in client networks. Alert on technician logins from new countries or devices, new admin accounts, disabled multi-factor authentication, mass script deployments and API keys created outside a change. Keep those logs outside the tools themselves, so an attacker cannot erase them. Protect the servers or cloud accounts that run your tools like a client's crown jewels, and monitor their network traffic too. In client networks, watch for activity that starts from your agent's host and does not match a ticket. NetSenX can watch your own office network and each client's, as separate tenants, with lateral movement and unusual uploads raised as alerts.

Combine automated detection that runs at all hours with a small on-call rota for what is truly urgent, or partner with a provider that staffs nights. Define urgent narrowly, for example confirmed lateral movement, ransomware staging or a large upload at night, so the person on call is woken rarely and for good reasons. Route only those alerts to phones, with the rest waiting for the morning. Write a short playbook for each urgent case: how to isolate a machine and whom to call at the client. If clients need people watching around the clock, partner with an MSSP or MDR provider rather than promise it yourself. NetSenX detects at every hour and can send alerts by webhook from the Pro plan into any on-call tool.

Promise only what you staff. If software watches at night and a technician reads alerts in the morning, say exactly that: detection runs around the clock, review happens on working days, and urgent alerts reach an on-call person within an agreed time, if you have one. Do not write monitoring 24/7 when nobody responds at 03:00: insurers, auditors and courts read such words literally, and the gap can void a claim or start a dispute. State response times, what counts as urgent, and what the client must do themselves. An honest, smaller promise you keep is worth more than a large one you cannot. NetSenX detects at all hours; it is not a staffed service.

Describe the service in observable terms: which systems and segments are monitored, which tool is used, when alerts are reviewed, how fast you respond to each level, what you do and what the client does, and what is not covered. Separate detection, which runs automatically at all hours, from review and response, which happen when your staff work or are on call. Name the limits plainly: encrypted content, unmonitored segments, devices without traffic, endpoint activity. Agree what evidence the client receives and how long alert history is kept. Have a lawyer review the wording. Avoid words such as SOC, 24/7 or guarantee unless you deliver them. With NetSenX, the retention period follows the client's plan.

It depends mainly on your contract and on what you promised and did, so the answer is a legal one for each case; this is general information, not legal advice. In practice, disputes turn on a few questions: what the contract said you would monitor and when, whether you did it, whether alerts were raised and acted on, and whether the client followed your recommendations. Clear service descriptions, written recommendations the client declined, and a record of alerts and actions protect both sides. Check your professional liability and cyber insurance, and have contracts reviewed by a lawyer. NetSenX keeps alerts with timestamps and an audit log of decisions in each client's tenant, which is the record such questions need.

Put the risk and the client's decision in writing, keep the basics you can, and do not quietly take responsibility for what they declined. Explain in plain terms what could happen without the measure, such as days without systems after ransomware, and what it would cost compared with the measure. Offer a smaller first step. If the client still says no, send a short written summary of the recommendation and their decision, and keep it. That record protects you if something happens. For network detection, the cost argument can disappear: the NetSenX Free plan covers 3 devices with no time limit, so a small client can start without a licence fee, while you agree how much of your time is included.

Possibly in two ways: directly, because NIS2 lists managed service providers and managed security service providers among the sectors it covers, and indirectly, because customers in scope must manage security in their supply chain and will pass requirements to you by contract. Whether an MSP is directly in scope depends on its size and on how its country transposed the directive, so check your national law and the national authority's guidance. This is general information, not legal advice. Either way, expect security questionnaires, contract clauses on incident notification and audits, and requests for evidence. Prepare a description of your own controls, how you protect access to clients, and how you would report an incident to them.

Questions about how you protect the customer's data and access, how you handle incidents, and whether you can prove it. Typical topics: governance and who is responsible, access control and multi-factor authentication, privileged access to the customer, patching, backups, logging and monitoring, incident detection and notification times, subcontractors, data location and staff training. Answer each question truthfully and briefly, attach evidence where you have it, and mark planned improvements with a date. Do not answer yes to something you cannot show. Keep one master version and update it, because many customers ask similar questions. NetSenX can supply part of your evidence for monitoring: detection records, the audit log and PDF reports from the Starter plan.

A short, dated pack that shows the measures ran: what was monitored, which alerts were raised and how they were handled, incidents and their reporting deadlines, backup and restore tests, patch status, access reviews and open risks. NIS2 asks entities in scope for risk-management measures and incident handling; evidence that these happen regularly is what their management body and auditors look for. Keep the format the same each quarter so changes stand out, and include what is not covered. NetSenX supplies the monitoring part: alerts with timestamps and explanations, the audit log, NIS2 Article 23 deadlines tracked per incident, and PDF reports from the Starter plan. It does not decide what is reportable or submit reports.

Keep the evidence as you go rather than reconstructing it afterwards: alerts with their timestamps and explanations, what was done and by whom, and the hosts involved. Agree with each client in advance what you will deliver after an incident and how fast, and who their contact for the authority is. In NetSenX each client's alerts and audit log stay in that client's tenant, the NIS2 Article 23 deadlines are tracked per incident, and PDF reports are available from the Starter plan. Make sure the plan's alert history covers the period an investigation is likely to need. Submitting the report to the authority stays with the client.

Not always by law, but often by contract and by client expectation, so check what your clients require before you choose. Security tools handle network metadata, which can be personal data under the GDPR; transfers outside the EU are possible with safeguards, but many clients, especially in the public sector, health and finance, prefer or require EU storage and a clear list of sub-processors. Ask each vendor where data is stored, which sub-processors are used and where they are incorporated, and what you get back when you leave. NetSenX stores customer data in the EU, with the database in Ireland and the API in Frankfurt and Paris, and publishes its data processing agreement with the full sub-processor list.

From the network: which hosts connect to external AI services or locally run language-model runtimes, how often and with how much data, reported separately for each client. With NetSenX this is available from the Pro plan, in each client's own tenant, so you can give each client its own picture. It shows destinations and volumes, not what was typed or uploaded, and it does not block services by itself. That is usually what clients need to start an AI policy: which tools are in use, on which machines, and whether large amounts of data go there. Pair it with the client's own policy, staff training and, where needed, settings in the AI services themselves.

Yes, if it is passive and agreed with the people who run the machines. OT (operational technology) networks connect controllers, machines and building systems; they are fragile, rarely updated and often cannot run any security software. Passive monitoring from a mirror port reads the traffic without sending anything to the devices, which is what plant managers need to hear first. With NetSenX, from the Pro plan, the client's tenant reads Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP and S7comm passively and raises OT alerts such as unauthorised writes, Purdue-level crossings, off-hours OT activity and S7comm commands. NetSenX never probes OT devices and is not a safety system; changes to the process stay with the client's engineers.

A copy of the production network's traffic, a host for the sensor, the plant's permission, and a plan that does not touch the controllers. Find a managed switch in the production network that supports port mirroring, or use a network TAP on the link between the controllers and their engineering station or HMI. Connect a Linux host running the NetSenX agent to that mirror port, on a client tenant with the Pro plan or higher. Agree a maintenance window with the plant manager, even though passive monitoring sends nothing to the PLCs. Record which segments are covered and which are not. Then review the first weeks of OT alerts with the client's engineers, who know which writes and commands are expected.

The data belongs to the client, so plan the handover: which records they keep, which access you give up, and what gets deleted. Agree it in the contract from the start. With NetSenX, each client is its own tenant, so the client's alerts and audit log stay together and can move with the client to the next provider by changing who has access, rather than by copying data. Alerts can be exported through the API from the Pro plan and to a SIEM from the Business plan, and PDF reports are available from the Starter plan. GDPR rights such as access and erasure are not tied to a plan. Closing an account deletes its data, so export what the client needs first.