Incident response

Regular connections from a workstation to a new outside server, one host scanning internal ranges for SMB, RDP or database ports, new administrator sessions to many servers, and a large upload to cloud storage from a server that normally sends little. They usually come in that order, before any file is encrypted.

Often, because the steps before encryption cross the network: command-and-control check-ins, scanning, lateral movement and data theft. That is the window in which an attack can still be stopped. Not every attack shows all of them, and an attack confined to one machine gives the network little to see.

No. NetSenX alerts on the network behaviour that usually comes before ransomware, so your team can act while there is still time. Isolating hosts, removing the attacker and restoring data stay with your team, your endpoint protection and your backups.

Disconnect the affected hosts from the network, keep their logs, reset the credentials used on them and call your incident-response provider. If your organisation is in scope of NIS2, the 24-hour early warning starts when you become aware of a significant incident.

Disconnect the affected machines from the network, at the switch or by unplugging the cable and switching off Wi-Fi. Keep them powered on if you can, because memory holds evidence, unless you cannot isolate them any other way. Do not contact the attackers or pay anything before taking advice. Call your incident-response provider, your cyber insurer's hotline if you have one, or your national CSIRT. Change administrator passwords from a clean device, check that your backups are intact and disconnected, and start a written log of what you see and do, with times. If NIS2 applies to you, the 24-hour early warning runs from the moment you become aware of a significant incident, so involve whoever handles reporting from the start.

Roughly this order, adjusted to your situation. One: isolate affected machines from the network without switching them off, and stop the spread at the switches or firewall. Two: call your incident-response provider, the insurer's hotline and, if needed, a lawyer, and start an incident log. Three: secure evidence and check whether backups are intact and offline. Four: find out how the attackers got in, which systems they reached and whether data left, and assess reporting duties under NIS2 and the GDPR, with their deadlines. Five: decide what to tell staff, customers and partners. Six: remove the attacker, reset credentials and close the way in. Seven: rebuild and restore in priority order from clean backups. Eight: watch closely for weeks and hold a lessons-learned review. NetSenX helps at steps four and eight, with network evidence and continued detection.

That is a business and legal decision, and law-enforcement agencies advise against paying: it funds the attackers, does not guarantee that the files come back or that stolen data is deleted, and paying a sanctioned group can be illegal. Decide with your incident-response provider, your insurer and your lawyers, and report the incident to the police and, where it applies, to your CSIRT. NetSenX does not negotiate or restore data; it helps you see earlier what the attackers did on the network.

Paying does not undo the theft. You would be paying criminals for a promise to delete data they have every reason to keep, and law-enforcement agencies, Europol and national police forces among them, advise against paying; there are reported cases of data being published or sold after payment. Paying a sanctioned person or group can also be illegal. The decision belongs to management, with your incident-response provider, insurer and lawyers. Before deciding, establish the facts: what really left, whether it contains personal data, which notifications are due regardless of payment, and what you will tell the people affected. Under the GDPR, a personal data breach is assessed on what happened, not on whether a ransom was paid. NetSenX does not negotiate; it helps with the facts, through alerts that show which hosts sent unusual volumes out and when.

A ransomware negotiator is a specialist, often provided by an incident-response firm or through the insurer's panel, who communicates with the attackers on the victim's behalf. Their job is to buy time, obtain proof of what was taken, test whether a decryption tool works and, if the company decides to pay, check sanctions lists and handle the terms. Using one does not mean you have decided to pay: talking can gain days in which to restore from backups. Do not open the attackers' chat or reply to their e-mail yourself before taking advice, because what you say can weaken your position. Ask your insurer first, since policies often require their chosen firm, and keep every message as evidence. NetSenX plays no part in negotiation; its alerts help establish what actually left the network, which matters when the attackers' claims are being tested.

Look at what left the network, and when: firewall and proxy logs, cloud storage audit logs and the logs of the machines involved. Large uploads to cloud storage or to an unfamiliar address in the days before encryption are the usual sign. Ask your incident-response provider to compare the volumes with what each server holds, and preserve the logs before they are overwritten. If the attackers publish a sample on a leak site, it tells you something about what they took, though rarely everything, and their claims are not proof either way. NetSenX keeps its alerts for unusual outbound data volume per host, with time, destination and volume, which helps you size a transfer. It does not see file names inside encrypted sessions.

Look for the transfer, not the claim. Attackers sometimes exaggerate to raise pressure, and sometimes they did take everything they say. Check firewall and proxy logs for large outbound transfers in the days before encryption, especially to cloud storage or to addresses nobody else uses, and note which internal hosts sent them. Compare the volume with what those servers hold. Request a proof sample only through your responder, and look at what it contains. Cloud storage and SaaS audit logs can show mass downloads. If the evidence shows no significant outbound transfer, that helps the decision and any notification, but absence of evidence on one path does not prove that nothing left by another. NetSenX keeps alerts for unusual outbound data volume per host, with time, destination and volume; it does not see the file names in encrypted transfers.

Often, if the logs from that time still exist. The published files give clues: their newest modification date sets the earliest possible theft date, and the folders they came from point to the servers involved. Then look in your firewall, proxy and cloud audit logs for large outbound transfers from those servers around that time, and for the first regular contact with an unknown outside server, which often marks the start of the intrusion. Ask your incident-response provider to do this, and do not download the leaked data from the site yourself: involve your responder and lawyer, because handling stolen data carries its own risks. Report the publication to the police. NetSenX keeps alerts for unusual outbound volume per host, with time and destination, for your plan's alert history, which can narrow the window considerably.

No. NetSenX analyses flow metadata and a few protocol fields, and it never decrypts traffic. When data leaves through an encrypted connection, which is almost always the case, it sees which host sent how much, to which destination and when, but not the names or content of the files. That is still useful: it tells you which server to examine, how large the transfer was and when it happened, which is often enough to narrow down what could have been in it. To know which files were taken, combine it with sources that see files: audit logs of file servers and cloud storage, endpoint detection and response (EDR) telemetry, data loss prevention tools, or a forensic examination of the server. If the attackers publish samples, those also indicate which folders were involved.

They try, if they kept a way in: stolen passwords, a forgotten remote-access tool, a new account, a scheduled task or a VPN that was never patched. Some criminals also sell or pass on access, so a second attack can come from someone else using the same door. After an incident, reset every credential that may have been exposed, service accounts included, remove remote-access tools nobody approved, close the way in, rebuild affected machines from known-good images and watch the network closely for weeks. Renewed connections to the attacker's servers are a typical sign; NetSenX flags command-and-control beaconing on every plan, Free included, and the indicators in your incident report can be searched for in your firewall and DNS logs.

Incident response is the organised way a company detects, contains and recovers from a security incident, and learns from it. It covers the technical work, such as isolating machines, removing the attacker and restoring systems, and the decisions around it: who leads, who is told, when to call outside help, what to report to regulators, insurers and customers. A small company does not need a security team to do it well. It needs a short written plan, phone numbers that work when e-mail does not, someone who is allowed to make decisions at night, and evidence that shows what happened. NetSenX helps with the evidence and the timing: it detects network behaviour that often marks an intrusion, explains each alert and tracks the NIS2 Article 23 deadlines per incident. It does not remove attackers or restore systems.

The best-known model has six: preparation, identification, containment, eradication, recovery and lessons learned, from the SANS incident handler's handbook. NIST's earlier guide, SP 800-61 Revision 2, grouped the same work into four phases. In April 2025, NIST replaced it with SP 800-61 Revision 3, which ties incident response to the six functions of its Cybersecurity Framework 2.0: govern, identify, protect, detect, respond and recover. All of them carry the same message: most of the work happens before the incident, in preparation, and after it, in improvement. For a small company the practical order is simple: notice, limit the damage, remove the cause, get back to work safely, and change whatever let it happen. Writing that sequence down for your own systems is the most useful first step.

By deciding now what you would otherwise improvise in the middle of the night. Write a one-page plan: who leads, who may shut systems down, who talks to customers, insurers and regulators. Keep phone numbers on paper and in a second channel, because e-mail and chat may be down or compromised. Know your three or four most important systems and the order in which you would restore them, and test a restore from backup. Agree terms with an incident-response provider before you need one, and check whom your cyber insurance requires you to call first. Make sure the logs you would need exist and are kept long enough: firewall, VPN, directory and network history. NetSenX contributes the network history and explained alerts, and PDF reports from the Starter plan make an evidence pack easier to hand over.

Less than most templates suggest, as long as it works under stress. The essentials fit on two or three pages: who leads and who deputises, the phone numbers of the people and providers you will call, when you isolate a system or cut the company off from the internet, where the backups are and how to restore the most important systems, and who decides on reporting to the CSIRT, the data protection authority, insurers and customers, with their deadlines. Add a short checklist for the first hour and a template for the incident log. Print it, because the file server holding the plan may be the one that gets encrypted. Review it after every incident and at least once a year. NetSenX tracks the NIS2 Article 23 deadlines per incident and keeps an audit log of alerts and analyst decisions, which supports the reporting part of the plan.

Fewer people than you think, but with clear roles. One person leads and makes decisions, usually the managing director or someone they appoint, with a named deputy. One person does or directs the technical work: your IT administrator, your managed service provider or an external incident-response firm. One person handles communication with staff, customers and suppliers, and one tracks the legal and reporting side, often with the data protection officer and a lawyer. In a company of 30 people these may be three people wearing several hats. What matters is that each role is written down, that the leader can decide at night without waiting for a meeting, and that the external numbers are agreed in advance. From the Starter plan, where team management is included, NetSenX gives each of them their own account, so alert reasons and decisions are visible to the whole team.

A retainer is an agreement with an incident-response firm, signed before anything happens, that guarantees you a response within an agreed time and fixes the price and the terms. Without one, you are searching for a provider, negotiating a contract and granting access while the attacker is still active. Many cyber insurers have their own panel of response firms and expect you to call them first, so check your policy before signing anything separately. A small company may not need a paid retainer if the insurer's hotline covers this, but it does need to know whom to call, what that firm needs on day one and how it will reach your systems. NetSenX is not an incident-response firm. It gives the firm you call explained alerts and a network history from before the incident, which is usually the evidence that is hardest to reconstruct afterwards.

A tabletop exercise is a meeting in which the people who would handle an incident talk through a realistic scenario step by step, without touching any system. A facilitator presents the situation in stages: an alert late in the evening, a ransom note on Monday morning, a journalist calling, the backup turning out to be encrypted too. At each stage the team says what it would do, who would decide and whom it would call. Ninety minutes with the managing director, IT, communications and whoever handles legal matters is enough. The value lies in the gaps you find: a phone number nobody has, a decision nobody is allowed to take, a log nobody keeps. Write them down and fix them, then repeat the exercise once or twice a year. A scenario based on a real alert or on a past incident teaches more than a generic one.

They are rungs on a ladder. An event is anything that happens and can be recorded: a login, a connection, a file change. An alert is an event, or a pattern of events, that a tool flags because it may matter, such as a workstation contacting a new outside server every few minutes. An incident is what you declare after looking at one or more alerts and concluding that security has actually been, or is being, compromised: an attacker is inside, data was stolen, a service was disrupted. The difference matters because obligations attach to incidents, not alerts: the NIS2 reporting deadlines start when you become aware of a significant incident, not when a tool raises an alert. NetSenX produces alerts with a plain-language reason; whether they form an incident remains your judgement, and that decision is recorded in the audit log.

By checking the alert against what you know, quickly and in the same order every time. Ask four questions: is the device and its owner known, is there a business reason for this behaviour, is the destination or account familiar, and has anything else unusual happened on the same host or at the same time? A backup job, a software update or an administrator working late explain many alerts within a few minutes. Something nobody can explain, that touches several hosts or that follows another alert deserves escalation. Write down what you checked, even when it was harmless, so the next person does not start from zero. NetSenX explains on every alert which network features drove it, names the MITRE ATT&CK technique where one applies, and lets you mark a false positive, with the decision kept in the audit log.

By its effect on the business, not by how alarming it looks. A simple scale works: low when one device is affected and contained, medium when an account or several devices are involved, high when important systems or personal data are at risk, and critical when operations stop or data has left the company. Ask what is affected, how many systems and people, whether personal or customer data is involved, whether it is spreading, and whether services you provide to others are disrupted. The answer decides who is called, how fast, and whether reporting obligations may apply: NIS2 works with the notion of a significant incident and the GDPR with a personal data breach, each with its own tests. Agree the scale in advance and write it into your plan. NetSenX shows on each alert what was seen and on which hosts, a starting point for this judgement rather than a replacement for it.

One named person, with a named deputy and the authority to act without a meeting. Decisions in an incident are urgent and uncomfortable: cutting the company off from the internet, stopping a production system, calling the police, telling customers. If nobody is clearly allowed to take them, hours are lost waiting for agreement. In most small companies the decision-maker is the managing director, advised by IT and an external responder; in larger ones an incident manager acts for the board within agreed limits. Write down which decisions this person may take alone and which need the board, and make sure the deputy can be reached when the leader is travelling. NIS2 also makes the management bodies of covered entities responsible for approving and overseeing cybersecurity risk-management measures, so the board should know the plan before it is needed.

Usually five things. Whether to isolate systems or the whole site, accepting the interruption that brings. Whom to bring in: an incident-response firm, the insurer's hotline, a lawyer. Whether the incident may be reportable, to the national CSIRT under NIS2 or to the data protection authority under the GDPR, and who prepares the notification. What to tell staff, customers and partners, and when, without promising what is not yet known. And how to keep the business running: manual processes, alternative communication, which customers to call first. None of these is technical, which is why a technical team cannot make them alone. Prepare them as options in your plan. NetSenX gives management a factual starting point: which hosts showed which behaviour and when, and the NIS2 Article 23 deadlines tracked for the incident.

Move the incident discussion to a channel the attacker cannot read before you say anything about your plans. Attackers who control a mailbox or the directory often read the response team's messages and adapt. Agree in advance on an out-of-band channel: phone calls, a messaging group on devices that do not use company accounts, or a separate collaboration space with its own logins. Keep a printed contact list, because the address book may be unavailable. Ask your insurer, bank and key customers to confirm any request from you by phone, because criminals sometimes send fake messages in the middle of an incident. Once the directory and mail are rebuilt and credentials reset, move back. NetSenX alerts live in their own dashboard, which you can open from a clean device, so the network picture does not depend on company e-mail.

Because memory fails under stress, and everyone will later ask what happened when. A simple log records the time, what was observed, what was decided, by whom and why, and what was done. It lets a second person take over at night without starting again, shows the insurer and the regulator that you acted promptly and deliberately, and is the basis for the timeline in a NIS2 report or a GDPR notification. It also protects decision-makers: a choice that looks wrong afterwards was often reasonable with what was known at the time, and the log shows that. Keep it outside the affected systems, on paper or in a shared document reachable from a clean device, and note all times in one time zone. NetSenX contributes timestamped alerts and an audit log of analyst decisions that you can attach to your own record.

Cut the network, not the power, and copy before you clean. Isolating an affected machine at the switch port, at the firewall or through the endpoint tool stops the attacker from using it, while memory, running processes and open connections stay intact for investigation. Before you reimage machines, delete files or remove accounts, export the relevant logs, note suspicious accounts and files and, where specialists advise it, take a memory capture and a disk image. Block the attacker's destinations at the firewall, but record which ones and when. If you must choose between speed and evidence, for example because encryption is spreading, speed wins: stop the damage first. Network evidence is the easiest to lose, because many devices keep only a short history; NetSenX keeps its alerts with time, hosts and destinations for the history your plan includes.

Unplug it from the network, but leave it switched on unless you have a reason not to. Pulling the cable and turning off Wi-Fi stops the attacker controlling it and stops it spreading, while memory keeps evidence that disappears at shutdown: running programs, network connections, sometimes encryption keys that help recovery. Switching off is the right choice when you cannot isolate the machine any other way and damage is spreading fast, or when specialists ask for it. Do not log in as an administrator to look around, run cleaning tools or reboot before taking advice, because each step changes the evidence. Note the time and what you did. If the machine is a server others depend on, isolate it at the switch or firewall rather than pulling cables at random. A network sensor such as NetSenX keeps the record of what the machine did before you disconnected it.

A short list of common mistakes. Do not wipe or rebuild machines before evidence is saved, or you lose the means of finding out how the attacker got in. Do not reset passwords one by one while the attacker is still watching; plan containment and do it in one go. Do not discuss the incident over e-mail or chat that may be compromised. Do not contact or pay the attackers without advice from your responder, insurer and lawyer. Do not restore from backups before you know they predate the intrusion. Do not announce publicly what you do not yet know, and do not promise customers that no data was affected before you have checked. Do not miss deadlines: a NIS2 early warning or a GDPR notification can be sent with incomplete facts and completed later. And do not stop watching the network once systems are back.

Work backwards from what you know, using timestamps. Start with the machine where the incident was noticed, ask which other host first connected to it in an unusual way, then repeat for that host. Endpoint logs show logins and new programs; directory logs show which account was used from which computer; firewall and VPN logs show the first outside connections. The earliest regular check-ins with an attacker's server often mark the first infected machine. Patient zero matters because it tells you how they got in, which you must close before recovery. Keep in mind that the first machine you find is often not the first one infected. NetSenX alerts carry times, hosts and destinations, and from the Pro plan network-wide correlation links scanning, new sessions and beaconing across hosts into one story, which shortens this search.

A forensic image is an exact, verified copy of a disk or of a computer's memory, made so that investigators can examine it without changing the original. It is taken with dedicated tools, fingerprinted with a hash such as SHA-256 so that any later change can be detected, and stored with a record of who handled it. You need one when the incident may lead to a legal dispute, an insurance claim, a police case or questions from a regulator, and when you want to know how the attacker got in before rebuilding the machine. Ordinary backups are no substitute, because they leave out deleted files, memory and system areas. Let a specialist take it if you can. Network evidence complements it: NetSenX records what crossed the network, which a disk image of a single machine cannot show.

Chain of custody is the written record of who collected a piece of evidence, when and how, and who has had it since. For a disk image, a log export or a network capture it means noting the source, the date and time, the method or tool used, a hash value that proves the copy has not changed, where it is stored and every person who accessed it. Without that record, a court, an insurer or a regulator may doubt that the evidence is what you say it is. A small company can keep it simply: one sheet per item, copies on write-once or access-controlled storage, and no work on the originals. NetSenX keeps an audit log of alerts, analyst decisions and configuration changes, and from the Starter plan a proof trail, which supports this record for the network side of an incident.

Export them as soon as an incident is suspected, before you change anything else. Many devices keep logs only for days or until a size limit: firewalls, VPN gateways, switches and some cloud services overwrite the oldest entries first, and an active attacker may try to delete them. Make a list in advance of the logs that matter, typically firewall, VPN, directory and authentication, e-mail, endpoint console and DNS, and how to export each one. During the incident, copy them to storage outside the affected systems, record the time and a hash of each file, and raise retention on the devices if you can. Ask your cloud providers how far back their audit logs go. NetSenX stores its alerts in its own service for the alert history your plan includes, 30 days on Free and longer on paid plans, whatever happens to your devices.

Eradication is removing the attacker's presence completely before you bring systems back. It includes deleting malware and tools, closing the way in, removing accounts, scheduled tasks and remote-access software the attacker created, resetting every credential that may have been exposed, and patching the vulnerabilities they used. In practice, rebuilding affected machines from clean images is often more reliable than cleaning them, because it is hard to prove that every change has been found. Eradication fails when it is partial: attackers who keep one foothold come back, sometimes weeks later. It should be planned from the evidence of your investigation, not guessed. Watching the network afterwards tests whether it worked: NetSenX flags renewed beaconing to known or new outside servers and new lateral sessions, on every plan.

From a clean device, in a planned order and within one short window. Start with the accounts that control everything: domain and cloud administrators, the backup system, remote access, and service accounts with broad rights. In Active Directory, the Kerberos ticket-signing account (krbtgt) is reset twice, with time for replication in between, so that forged tickets stop working. Then reset ordinary users, revoke active sessions and tokens in cloud services, and require multi-factor authentication (MFA) wherever it is missing. Do not send new passwords by e-mail that may be compromised. If you reset too early, while the attacker still has a foothold, they simply capture the new passwords, so contain first. Identity changes are outside a network sensor's view; NetSenX shows whether the attacker's machines keep reaching out afterwards.

You cannot know for certain, but you can build reasonable confidence. Check that you understand how they got in and that the way is closed, that every account and tool they created has been removed, and that credentials have been reset. Then look for the absence of activity: no connections to their known servers, no new administrator accounts, no unexplained logins, no scanning between hosts. Search your logs and endpoints for the indicators from your investigation, such as IP addresses, domains and file hashes. Keep a heightened watch for at least several weeks, because some attackers wait. A compromise assessment by an outside firm gives an independent view. NetSenX supports the absence test from the network: beaconing, scanning, lateral movement and unusual outbound volume are flagged on every plan, Free included, so silence on the segments it monitors means something.

Usually the hardware, yes, but not the installation. Ransomware and the tools that come with it change the operating system, add accounts and leave persistence that is hard to find, so the reliable approach is to wipe and reinstall affected machines from known-good images, then restore data from a backup taken before the intrusion. Keep the disks, or images of them, of machines needed for the investigation before you reuse them. Infections at firmware level exist but are rare; your responder will say if there is a reason to replace hardware. Unaffected machines still need checking, because attackers often touch more systems than they encrypt. Before reconnecting rebuilt machines, make sure the way in is closed. The NetSenX network map shows which hosts talked to the affected ones during the incident, which helps you decide what else to check.

In a controlled order, on a clean foundation and with your eyes open. First make sure the attacker's way in is closed and their accounts and tools are gone. Rebuild the core first: the directory, administrator accounts, the backup system and the firewall, with new credentials. Then restore systems in order of business priority, from backups you have checked were taken before the intrusion and scanned before use. Bring each system back on a monitored network segment before giving everyone access, and keep users on new passwords with multi-factor authentication (MFA). Tell staff what to report if something looks wrong, and expect recovery to take longer than the attack did. Keep watching the network closely for weeks; NetSenX flags renewed beaconing, scanning and lateral movement on every plan, which is often how an incomplete clean-up is noticed.

Often partly, if you planned for it. Decide in advance which processes are critical and how they run without IT for a few days: paper order forms, phone lists of customers and suppliers, manual delivery notes, a spare laptop that has never been on the company network. Isolating affected systems may let others keep working, which is why good segmentation pays off during an incident, not only before. Be careful with shortcuts: connecting personal devices or a home laptop to the damaged network can spread the problem or destroy evidence. Communicate with staff through a channel outside the affected systems and tell them clearly what not to do. Insurers and customers both value a company that kept serving them. NetSenX shows which segments and hosts are involved, which helps you decide what can safely stay online.

At least several weeks, and longer after a serious intrusion. Attackers who kept a foothold often wait until the response team relaxes, and access sold to others may be used much later. During this period, review alerts daily, look for connections to the indicators from your investigation, check for new administrator accounts and remote-access tools, and confirm that backups keep running and are not being touched by unusual hosts. Treat any repeat of the original pattern as a new incident, not as noise. Decide in advance who reviews what, and when the heightened watch ends. NetSenX flags beaconing, scanning, lateral movement and unusual outbound volume on every plan, Free included, and its alert history, 30 days on Free and longer on paid plans, lets you compare the weeks after the incident with the weeks before.

It is a meeting, held within a few weeks of the incident, in which everyone involved goes through what happened and what to change. Use the incident log to rebuild the timeline, then ask four questions: what went well, what went badly, what did we not know or not have, and what will we change, with an owner and a date for each change. Keep it blameless: the aim is to fix systems and procedures, not to find someone to punish, otherwise people hide mistakes the next time. Typical outcomes are a closed remote-access path, MFA where it was missing, a backup that is now offline, a phone list that works, a log that is kept longer. Feed the results into your plan and your next tabletop exercise. NetSenX alerts and the audit log give the review a factual timeline for the network side.

Decide the rule in advance, because a small company rarely has a night shift. Write down which alerts justify waking someone, who that person is and what they may do alone: for example, isolate one workstation, but not shut down the ERP server. Everything else waits until morning, with a check at a fixed time. If you outsource monitoring, agree the same rules with the provider in writing. Make the first steps simple enough for a non-specialist: disconnect the device from the network, note the time, call the named number. Test the call chain once. NetSenX sends alerts with a plain-language reason and the hosts involved, so the person woken up can tell quickly whether it is a backup job or a workstation calling a new outside server in the small hours. It does not staff a night shift for you.

Often, yes, because encryption is the last step of a longer sequence. Before it, attackers usually have to get in, contact their own server, look around, reach the file servers and backups and, in most current attacks, copy data out. Those steps often take days and cross the network: a workstation calling a new outside server at regular intervals, one host scanning internal ranges, new administrator sessions to servers, a large upload at night. Attackers pick weekends and holidays because nobody is watching, not because the earlier steps were invisible. The useful question is whether anything recorded those signs and whether anyone would have seen the alert. NetSenX flags beaconing, scanning, lateral movement and unusual outbound volume on every plan, Free included; whether an alert on Friday evening is acted on before Monday depends on your call chain.

It varies too much for one number to be useful: from hours, when an automated group exploits an exposed system, to weeks, when access is bought from someone else or the attackers take their time to find backups and copy data. What is consistent is the sequence: access, contact with the attacker's server, discovery, movement to servers, data theft, and only then encryption. Each stage is a chance to notice. Plan as if you have little time: keep backups offline so they survive, make sure remote access requires multi-factor authentication (MFA), and decide in advance who isolates a host at night. Treat any sign of the early stages, such as a workstation scanning internal ranges, as urgent. NetSenX alerts on the network behaviour of those stages on every plan, and that is where the time to act comes from.

In two ways. A drive can carry the malware itself, which runs when someone opens a disguised file, and some malware copies itself onto every drive it finds so that it travels between computers and sites. And a drive that is connected when encryption starts is simply encrypted with everything else, which is why a backup on a permanently attached USB disk does not protect you from ransomware. Disable automatic running of programs from removable media, scan unknown drives on a dedicated computer, allow only company-issued devices where you can, and disconnect backup drives after each run. Spain's INCIBE has published a real case in which ransomware spread as infected devices were connected. A USB transfer does not cross the network, so a network sensor does not see it; NetSenX sees what the infected computer does next, such as scanning or calling an outside server.

Keep everything that shows what happened, when and what you did, without altering it. That means the incident log with times and decisions; exports of firewall, VPN, directory, e-mail and endpoint logs; the ransom note and any messages from the attackers; screenshots of what users saw; forensic images where specialists made them; and records of the costs incurred. Note a hash, the storage place and who handled each file. Insurers usually need the timeline and the cost evidence; the police need the attackers' messages, payment demands and indicators; regulators want to know what data was affected and how you responded. Ask each of them early what they need, and keep copies outside the affected systems. NetSenX alerts, with times, hosts and destinations, and its audit log can be part of this pack, with PDF reports from the Starter plan.

For the alert history of your plan: 30 days on Free and longer on each paid plan, with the exact periods on the pricing page. Alerts are stored with their time, the hosts involved, destinations, volumes and the reasons that drove them, together with analyst decisions in the audit log. If an incident may lead to a claim, questions from a regulator or a court case, do not rely on retention alone: export what matters while the incident is fresh, with PDF reports from the Starter plan, and keep the export with your other evidence. Think about the period you need before an incident happens: dwell times can be weeks, so a short history may end before the intrusion began. Your firewall, VPN and directory logs have their own retention, often shorter, which is worth checking today rather than during an incident.

Handle the first hour yourselves, and bring in a firm for anything beyond a contained single device. Your own team knows the systems, so it should isolate machines, start the log and preserve evidence. An outside firm brings what a small team rarely has: forensic tools and experience, knowledge of attackers' habits, contacts with law enforcement, and credibility with insurers and regulators. Call one when an attacker may still be active, when servers or many devices are affected, when data may have left, or when the incident may be reportable or lead to a claim. Check first whether your cyber insurance names a firm, since using another can affect cover, and agree in advance what access they will need. NetSenX is not an incident-response firm; the explained alerts and network history it keeps are what that firm will ask for on day one.

Honestly, specifically and only with what you know, then update them. Say what happened and when, which categories of their data were involved, what you have done, what you are still investigating, what they should do, such as watching for phishing that uses their details, and whom to contact. Avoid saying that no data was affected before the investigation supports it; a correction costs more trust than a careful first message. Agree the wording with your lawyer and data protection officer, because notifying individuals can be a legal duty with its own required content, and with your insurer. Send it through a channel that is not compromised, and warn customers that fake follow-up messages may circulate. Evidence makes the message precise: NetSenX alerts show which hosts sent unusual volumes out and when, which helps you say which systems, and so which customers, are concerned.

Partly. Network records can show that a particular server, the one holding that customer's data, sent no unusual volume out during the period, and that no new outside destination received data from it. That is meaningful evidence, especially if the server normally sends little. It is not proof on its own: data could have been copied to another internal machine first and sent from there, sent in small amounts below obvious thresholds, or taken through a channel the sensor does not watch, such as a cloud service accessed directly or a segment that is not monitored. Present it to the customer as what it is: evidence of absence on the paths you monitor, combined with server and cloud logs. NetSenX keeps per-host alerts on unusual outbound volume, and its network map shows which hosts talked to that server.

Your national CSIRT or cybersecurity agency is the first free call in most EU countries, and several run services for small businesses. Spain has INCIBE's free helpline 017; Poland has CERT Polska, which takes incident reports; Germany has the BSI and the police cybercrime units of the federal states; France has the national Cybermalveillance platform for businesses, and the ANSSI for regulated entities; Italy has CSIRT Italia at the ACN; the Netherlands has the Digital Trust Center for businesses and the NCSC for vital sectors. They can give guidance, sometimes indicators and contacts, but they do not usually do the recovery work for you. Your cyber insurer's hotline, if you have one, is the other early call, and crimes should be reported to the police. NetSenX does not provide incident response, but its alerts give whoever you call a factual starting point.

Yes, in most cases. Ransomware, extortion, fraud and data theft are crimes, and a police report helps investigators link cases, sometimes leads to decryption keys from law-enforcement operations, and is often required by insurers for a claim. Reporting to the police is separate from any regulatory notification to your CSIRT or data protection authority; you may need to do several. Many countries have specialised cybercrime units or online reporting for businesses, and your national CSIRT can tell you where to go. Bring the facts: the timeline, the ransom note and messages, payment demands, indicators such as IP addresses and domains, and the costs so far. Reporting does not mean losing control of your recovery, and it does not usually make the incident public. NetSenX alerts, with times, hosts and destinations, can be part of what you hand over.

Sometimes, from the side effects rather than the intent. Spain's INCIBE has published a real case in which an employee introduced malicious code and stole a million euros. Cases like this rely on access the person already has, so prevention lies in process: separation of duties for payments, approval by a second person, code review for changes to financial systems, and prompt removal of access when roles change. Technical signs can still appear: a workstation contacting an unfamiliar outside server, new connections to the payment or ERP system from a machine that never used it, unusual uploads. NetSenX watches devices and connections, never people: it can flag that behaviour on the network, on every plan, but it does not judge intent and does not see what happens inside an application. Investigating a person is a matter for HR and lawyers, and for the works council where one exists.

Check the ordinary causes first, then look for the signs of an attack. Many outages come from an expired certificate or domain, a full disk, a failed update or a problem at the hosting provider. Ask your provider and check its status page, then look at the web server's logs: a sudden flood of requests from many addresses points to a denial-of-service attack; changed pages, new administrator accounts or unknown files point to a compromise of the site itself; a changed DNS record points to an attack on your domain registration. Keep the logs before restarting anything. If the site holds customer data or takes payments, treat a compromise as a possible data breach. NetSenX does not protect public websites hosted outside your network; if the web server sits in your network, it shows unusual outbound connections and data volume from it.

No, and the difference is where each works. A distributed denial-of-service (DDoS) attack floods your website, VPN or internet line with traffic from many machines until it can no longer answer. Stopping it needs capacity in front of you: your internet provider, a content delivery network or a scrubbing service that absorbs and filters the flood before it reaches your line. Network detection inside your company, such as NetSenX, watches the behaviour of your own hosts to find intruders, beaconing, scanning, lateral movement and data leaving; it neither blocks traffic nor has the bandwidth to absorb a flood. Ask your provider what DDoS protection your line has today, and for public services consider a protected hosting setup. Some DDoS attacks serve as a distraction, so check that nothing else is happening inside while the outage lasts.

Evidence and timing, not extra hands. During an incident NetSenX gives you alerts for beaconing, scanning, lateral movement and unusual outbound data volume, on every plan, each with a plain-language reason, the hosts involved, destinations, volumes and times, and the MITRE ATT&CK technique where one applies; the network map of who talks to whom; an audit log of alerts and analyst decisions; and tracking of the NIS2 Article 23 deadlines, with a GDPR Article 33 notification prepared for your data protection officer while submitting stays with you. From the Starter plan you add PDF reports and response recommendations, and from the Pro plan correlation of hosts into one story. It does not remove attackers, restore data or negotiate, and it does not see inside encrypted sessions or on segments you do not monitor. Your responder, endpoint tools and backups cover that ground.

Close their door first, then ask questions. Suspend the supplier's accounts, VPN access and remote-support tools on your systems until they confirm what was affected, and rotate any shared credentials or API keys. Ask them in writing what happened and when, which of their systems were involved, whether your data or access details were exposed and which indicators of compromise they have, then search your logs for those indicators. Check what their access could reach: which servers, which data. Treat payment-related e-mails from them with caution, because stolen mail threads are reused for invoice fraud. If your data was exposed through them, you may have notification duties of your own. Review the contract for security and notification clauses. NetSenX flags beaconing and unusual sessions from hosts the supplier used, and its network map shows what those hosts actually talked to.

Because the clean-up is different. A compromised account means someone has a user's password or session, usable from anywhere: the fix is to reset credentials, revoke sessions, review mailbox rules and enforce multi-factor authentication (MFA), and the evidence is in identity and service logs. A compromised device means someone controls the machine itself, often with malware: the fix is to isolate and rebuild it, and the evidence is on the endpoint and in its network traffic. Many incidents involve both, such as passwords stolen from an infected laptop, or an account used to install tools on a server. Find out which you have before choosing actions, or you will reset passwords on a device that captures the new ones. NetSenX sees the device side on the network: a machine calling an outside server, scanning or opening new sessions. Account misuse from outside your network belongs to identity logs.