For the board and finance

With what you can show, not with a guess. A useful answer has three parts: what your monitoring shows today (open alerts and incidents, and the devices behind them), what it covers (which sites, network segments and devices are watched), and what it cannot see (the content of encrypted traffic, activity that never crosses the network, segments nobody monitors). A confident “no” that later proves wrong costs more credibility than an honest “nothing seen on the parts we watch”. NetSenX gives you that picture in plain language: on every plan, Free included, it flags beaconing to command-and-control servers, scanning, lateral movement and unusual outbound data volume, and it shows which segments its sensors watch. It cannot prove that nothing happened elsewhere.

No. No tool can prove the absence of an intrusion; it can only show that it found no sign of one in what it observes. Attackers who use stolen passwords and ordinary administration tools can look like normal staff, and a device that stays silent shows nothing at all. What a board can reasonably expect is evidence that the main ways in and out are watched, that alerts are read and decided on, and that the gaps are known and written down. Combine several views: endpoint detection on computers, identity and e-mail logs, and network detection for the traffic between devices. NetSenX covers the network part and says plainly which segments it does not watch. Treat any vendor that promises certainty with caution.

What happens between computers, which antivirus does not watch. Antivirus and endpoint detection and response (EDR) look inside each machine for malicious files and behaviour. A network sensor looks at the connections instead: a PC that contacts an unknown server every few minutes, a workstation that suddenly logs in to many others, a server that sends far more data out at night than it usually does. Those are the steps attackers take after getting in, often with legitimate tools that antivirus lets pass. NetSenX reports them on every plan, Free included, and explains each alert in plain language. It does not replace antivirus or EDR: it cannot see a file being encrypted inside a laptop or a folder being copied to a USB stick. The two views together leave fewer blind spots.

Usually a short pack of documents and records. It typically includes your security policies, a list of incidents in recent years and how each was handled, the results of penetration tests or audits, any certifications you hold, your cyber insurance, your data processing agreements and a description of how you monitor for intrusions. A buyer prices what you cannot document, through a lower price, an escrow or an indemnity clause, so records count for more than assurances. Start collecting before a sale is on the table: an incident register, the decision taken on each serious alert, and the date monitoring began. NetSenX keeps an alert history and an audit log of your team's decisions on every plan, with PDF reports from the Starter plan; how far back the history goes depends on the plan.

It depends on the plan: the Free plan keeps 30 days of alert history, paid plans keep it longer, and the Enterprise plan keeps alert history without a time limit. The audit log, which records what your team did with each alert and every change of settings, has its own retention period, which also grows with the plan; the pricing page lists both. Choose a plan with the evidence you may need in mind: a buyer, an insurer or an auditor may ask about the past year, and history that was never kept cannot be recovered later. If you need records for longer than your plan keeps them, export PDF reports from the Starter plan, or alerts through the API from the Pro plan, and archive them under your own retention policy.

Yes, in a form that depends on the plan. From the Starter plan, NetSenX produces PDF reports of detections that you can hand to a buyer, investor or auditor; from the Pro plan, alerts can be exported through the API, and from the Business plan they can be sent to a security information and event management (SIEM) system. The audit log of decisions is kept on every plan. Before you share anything, check what the report contains: device names and internal addresses reveal how your network is built, and device names sometimes contain employees' names, so share under a non-disclosure agreement and remove what the reader does not need. An export shows what NetSenX saw; it says nothing about segments or systems it did not monitor.

A few numbers the board can check and compare over time, not a long technical report. Useful ones are: open incidents and how long they have been open; serious alerts and how quickly someone looked at them; which sites, segments and devices are monitored and which are not; the date of the last successful restore test of backups; the share of accounts protected by multi-factor authentication (MFA); overdue critical patches; and incidents reported to authorities, with deadlines met or missed. Each number should have an owner and a one-line comment on what changed. NetSenX supplies the network part: alert and incident counts, deadline tracking for NIS2 incident reports and the list of monitored segments. Backup tests, MFA and patching figures come from other systems.

Rarely. A single score mixes things that cannot be added up, such as missing backups, an unpatched server and an untrained finance team, and its precision is usually false: nobody can defend why the company is a 62 and not a 58. Once a number appears in board minutes, it is quoted for years, and it hides which problem actually moved. A small set of plain facts serves the board better: what is monitored, what is open, what was tested and what is overdue, each with a trend and an owner. If you are given a rating by an insurer or a supplier portal, ask how it is calculated and what it leaves out. NetSenX helps with the network part of those facts: alert and incident counts, and the list of monitored segments.

Describe outcomes and decisions, not technology. Instead of “we saw C2 beaconing from a host in VLAN 20”, say “one accounting PC kept contacting an unknown server every five minutes; we isolated it on Tuesday, found malware, cleaned it and changed the passwords it held”. For each item, give what happened, what it could have cost, what you did and what you need from the board: a decision, a budget or nothing. Keep a standing page with the same few metrics each quarter, so changes are visible at a glance. End with what you still cannot see and what closing that gap would take. NetSenX writes each alert in plain language, which you can reuse, and its PDF reports, from the Starter plan, can go into the board pack as an annex.

Mostly proof that the basics run and that someone owns them. Typical investor checklists ask who is responsible for security, whether you have written policies, how you control access (including multi-factor authentication), how you back up and restore data, whether you have had incidents and how you handled them, where customer data is stored and under which contracts, and whether you monitor for intrusions. Early-stage investors rarely expect certifications, but they do expect honest answers that match your documents. Prepare a short pack: a named owner, the policies, an incident register, your data processing agreements and a one-page description of monitoring. NetSenX can supply part of it: an alert history, an audit log of decisions and, from the Starter plan, PDF reports; customer data stays in the EU.

Increasingly yes, but as a question rather than a fixed requirement. Technical due diligence asks how you would notice an intrusion, and “we would hear it from a customer” is a weak answer. Investors are usually less interested in the product name than in whether alerts reach someone, whether that person acts, and whether there is a record of it. A monitored network with an alert history and documented decisions answers the question; an unused tool does not. If you start monitoring shortly before a round, say so: a short history stated honestly is better than an implied long one. NetSenX's Free plan has no time limit, so you can start building a record well before due diligence begins and move to a paid plan when you need longer history or reports.

Yes, without a security team. Investors want to see that monitoring exists, that someone receives the alerts and that decisions are recorded. A company of 30 people can do this with one sensor: a NetSenX agent on a switch's mirror port (SPAN) or on a network TAP watches the traffic of a whole segment and counts as one device. Alerts arrive by e-mail on every plan, each explained in plain language, so an office manager or an outside IT provider can read and act on them. Write a one-page description of what is monitored and who responds, and attach a PDF report from the Starter plan. Be clear about limits: a network sensor does not replace endpoint protection, backups or multi-factor authentication, which investors usually ask about as well.

Truthfully, with facts and with what changed, within your legal and contractual limits. First agree internally what counts as an incident for this answer: a blocked phishing e-mail is not one, a compromised account usually is. Then answer with dates, scope, whether customer data was affected, which authorities were informed and what you improved afterwards. If an incident is still under investigation or covered by confidentiality, say what you can and when you will say more. A vague or evasive answer tends to cost more trust than a well-handled incident. Records make this easy: an incident register, the alerts behind it and the decisions taken. NetSenX keeps the alert history and the audit log of decisions for the retention period of your plan.

Often yes, and sometimes you must. Under the GDPR, people must be told about a personal data breach that is likely to result in a high risk to them, NIS2 can require you to inform the recipients of your services about significant incidents, and contracts often add notification duties of their own. Beyond what is required, disclosure is a business decision: customers who learn of an incident from a journalist or a leak site rarely forgive the silence, while a clear account of what happened and what you changed can strengthen trust. Agree a disclosure line with management, legal advice and your insurer before an incident, not during one. Keep the facts ready: when it started, what was affected and what was done.

An incident register and the evidence behind each entry. For each incident, record when it started, when it was detected and by whom, what was affected (systems, data, customers), how it was contained, whether it was reported and to whom, the root cause and what changed afterwards. Keep the supporting material too: alerts, logs, tickets, decisions and messages to authorities or customers. The GDPR already requires controllers to document every personal data breach, including those not reported, and auditors and buyers will ask for the same facts. NetSenX contributes the network part: alerts with time, devices and destinations, the audit log of who decided what, and NIS2 deadline tracking per incident. Keep the register itself somewhere you control.

That it is usually the largest cost of a cyber incident, and one you can estimate yourself. A day without systems means lost sales or production, staff paid to wait, overtime to catch up, contractual penalties and customers who go elsewhere. Ask finance to estimate one day for your own company from revenue, payroll and key contracts, then ask IT how many days a full restore would really take; the product of the two is a better guide than any industry average. That figure helps the board judge backups, recovery plans and insurance limits. What NetSenX changes is the timing: it can surface the steps that usually come before ransomware locks systems, such as lateral movement and data leaving, while there is still time to act. It does not restore systems.

Questions that can be answered with facts. Five that work well: How would we know today if someone were inside our network, and who would receive the alert at night on a Sunday? When did we last restore a complete system from backup, and how long did it take? Which accounts can still log in without multi-factor authentication? Which suppliers can reach our systems, and how? What can we not see, and what would it cost to see it? Ask for the answers in writing and come back to them each quarter. Good answers name a person, a date and a document; a weak one is “we have a tool for that”. NetSenX helps answer the first and the last question for the network: who receives alerts, and which segments are and are not monitored.

Enough to judge risks and decisions, not to configure systems. Good board training covers the main ways companies are attacked (stolen passwords, phishing, unpatched systems, suppliers), what an incident does to the business and which deadlines start running, the board's own duties under laws such as NIS2, how to read the security metrics it receives, and what to do in the first hours of an incident. A short tabletop exercise, in which the board walks through a realistic incident, teaches more than slides. Under NIS2, the members of the management bodies of entities in scope must follow training, and national laws set the detail. Keep attendance records: they are part of the evidence. NetSenX does not provide training, but its plain-language alerts make good real examples.

One named person at management level, even if others do the work. In a small company that is often the managing director or the finance director, with an IT manager, a lone administrator or an outside IT provider doing the day-to-day tasks. Ownership means setting priorities and budget, receiving the quarterly picture and being the person who is called when an incident starts. Without a named owner, tasks fall between IT, finance and the provider, and nobody notices until something breaks. Write down who owns what, including who may decide to disconnect systems or call the insurer. Under NIS2, responsibility for approving and overseeing the security measures sits with the management body, whoever does the work. No tool can own the risk for you.

Take a few decisions quickly and leave the technical work to the people doing it. Confirm who leads the response and who speaks for the company. Call your insurer's incident line early, because many policies require prompt notice and name the response firm they will pay for. Bring in legal advice, and the data protection officer if personal data may be involved. Start the clocks: under NIS2 the early warning is due within 24 hours of becoming aware of a significant incident, and under the GDPR a breach is notified to the authority within 72 hours where feasible. Do not let anyone wipe systems before evidence is secured, and do not pay or contact the attackers without advice. NetSenX tracks the NIS2 deadlines per incident and keeps the alerts showing what crossed the network.

The management body, advised by lawyers, the insurer and the incident-response firm, and never one person alone under pressure. Before any decision the company needs facts: can systems be restored from backup, and how fast; did data actually leave, and how much; is a payment lawful at all, given sanctions on some criminal groups; and what does the insurance policy say. Attackers often claim to have copied data to raise the pressure, so test that claim against evidence. Agree in advance who takes this decision and who must be consulted. Paying guarantees neither working decryption nor deletion of stolen data. NetSenX does not advise on payment; it can show whether unusual uploads left monitored devices in the days before the attack, and to which destinations.

Process controls in finance, because this fraud happens in e-mail and on the phone, not on the network. The controls that work best cost nothing: confirm every change of a supplier's bank details by calling a number you already have on file, never one taken from the e-mail; require two people to approve payments above a set amount and any first payment to a new account; and let staff refuse an urgent request from a manager, without consequences, until it is verified. Add technical measures for e-mail: multi-factor authentication on mailboxes, and DMARC, a standard that stops others from sending mail in your domain's name. NetSenX does not filter e-mail and cannot see a fraudulent request; it helps only if the fraud starts with malware that then calls out over the network.

Yes, written as business risks rather than as one technical line. Describe each risk in terms the board recognises: production stopped by ransomware, customer data stolen, payment fraud, a key supplier hacked, a fine for a missed reporting deadline. For each one, note the likely impact, the controls in place, who owns it and what is still missing. That makes cyber risk comparable with other risks when budgets are set, and it gives auditors and insurers a clear trail. Review the register at least once a year and after every serious incident. NIS2 expects entities in scope to base their measures on a risk analysis, and ISO/IEC 27001 is built around one. NetSenX does not keep a risk register; it supplies evidence for the detection controls listed in it.

By linking each item to a risk it reduces and a result it should produce. Ask for the budget in three parts: what keeps the basics running (backups, patching, multi-factor authentication, endpoint protection), what closes known gaps (for example, nobody watching the network at night), and what is optional. For each line, ask what happens if it is dropped and how you will know it works. Compare the total with your own estimate of what a day without systems costs, rather than with industry averages. Prefer tools with published prices and no long lock-in, so the cost is known in advance and can be stopped. NetSenX publishes its prices, from a Free plan with no time limit up to the Enterprise plan; the pricing page lists what each plan includes.

An alert is a signal; an incident is a confirmed event that harms or threatens the business. A monitoring tool raises an alert when it sees something unusual, such as a PC contacting an unknown server at regular intervals. Someone then checks it: many alerts turn out to be harmless, while some reveal a real problem. When one alert, or several together, show that systems or data were actually affected, there is an incident, with an owner, a response and possibly a duty to report it. For the board, the useful numbers are incidents and how quickly alerts were checked, not the raw count of alerts. NetSenX lets your team track incidents together with the alerts behind them and their NIS2 reporting deadlines; deciding whether an incident is significant stays with you.

Mostly through what is undocumented rather than through the incident itself. Buyers ask about past incidents in due diligence. One that was detected, contained, reported on time and followed by improvements usually becomes a line in the disclosure letter. One that surfaces late, or that the seller cannot explain, tends to lead to a lower price, an escrow, special indemnities or a delayed closing, because the buyer cannot tell what else may be hidden. Insurers on the buyer's side ask similar questions. Prepare by keeping an incident register, evidence of monitoring and the decisions you took on each serious alert. NetSenX keeps the alert history and an audit log of decisions for the retention period of your plan, and you can export them as evidence.

It is the amount and kind of cyber risk the board is willing to accept in order to run the business, written down so others can act on it. It turns into concrete statements, for example: production may stop for no more than one day; customer data must never leave the EU; we accept that a laptop is occasionally lost, but never an unencrypted one. Such statements let IT and suppliers make decisions without asking the board each time, and they show where money is needed: if a full restore takes five days and the limit is one, there is a gap to close. Keep the statement short and review it yearly. It is a management decision that no tool can make. NetSenX helps measure one side of it: how quickly unusual network activity is seen.

Both, for different purposes. Internal reports from IT or the security owner give the regular picture: metrics, open issues and decisions needed. An independent view, from an auditor, a penetration test or an outside adviser, checks every year or two that the internal picture is accurate. Relying only on internal reports means the people responsible mark their own homework; relying only on outside reports leaves long gaps between snapshots. Ask both to use the same few metrics, so their findings can be compared. Where possible, let the board see raw evidence as well, such as an alert report, not only slides. NetSenX reports come from your own network traffic, so they can support either kind of review, but they cover only what its sensors watch.

Ask for evidence on a few points and check some of it yourself. Your contract should say what the provider monitors, who responds at night and at weekends, how quickly, and how incidents are reported to you. Then ask each quarter for the patch status of servers, the result of the last restore test, the accounts without multi-factor authentication, and the incidents and how they were handled. If the provider has wide remote access to your systems, ask how that access is protected, because attackers target providers to reach their clients. Independent visibility helps: alerts from your own monitoring show whether problems are found before you hear about them. From the Starter plan, NetSenX supports several users, so your provider and someone in your company can both see the alerts.

Someone who can confirm the answers are true, usually the security owner, with management aware of the important ones. In practice, questionnaire answers become part of the contract: a customer who relied on a “yes” that was not true may claim damages or end the contract after an incident. So answer for what is in place today, not what is planned, and say “partly”, with a short explanation, where that is the truth. Keep the evidence behind each yes in one folder, so the next questionnaire takes hours instead of weeks. Review the answers whenever something changes, such as a new supplier or a dropped tool. For questions on intrusion detection, NetSenX supplies concrete evidence: which segments are monitored, alert history, the audit log and data stored in the EU.

Early, factually and through one voice. Prepare a short holding statement before you need it: what happened in plain words, what you are doing, what customers should do (for example, watch for fake invoices in your name) and when you will update them. Do not speculate about the attacker or the scope, and do not promise that no data was affected unless you can show it. Coordinate the wording with legal advice, your insurer and, where personal data is involved, your data protection officer, and keep it consistent with what you report to authorities. Name one spokesperson. Facts make honest communication possible: NetSenX alerts show when unusual traffic started, which devices were involved and whether data left the monitored segments.

Yes, quickly, with what they need to do and nothing that harms the investigation. Employees notice when systems go down and they talk about it, so silence produces rumours and sometimes a post on social media. Tell them what is known, what they should and should not do (do not switch affected machines back on, report strange e-mails, refer press questions to the spokesperson) and where updates will come from. If employees' own data may be affected, they may also be entitled to a notice under the GDPR. Thank the person who reported the first suspicion: people who are blamed stop reporting. Network evidence helps target the message to the departments and devices actually involved, without naming individuals before the facts are clear.

A tabletop exercise is a guided discussion of a realistic incident, and yes, the board should take part at least once a year. A facilitator describes a scenario step by step, for example a ransom note on every screen on Monday morning, and the participants decide what they would do: who leads, who calls the insurer, when to report to authorities, whether to stop production, what to tell customers. No systems are touched. The value lies in finding gaps while they are cheap to fix: missing phone numbers, unclear authority to take decisions, backups nobody has tested. Write down the findings and who fixes each one. Real NetSenX alerts, with time, devices and destinations, make a good starting point for a scenario that fits your own network.

Through notification duties, service levels and liability clauses you may already have signed. Many contracts require you to tell the customer about a security incident within a set time, to meet availability levels and to protect their data to a stated standard; customers that fall under NIS2 or DORA often write such duties into supplier contracts. A missed notice can be a breach of contract on its own, separate from the incident. Before anything happens, list your largest contracts and their incident clauses, and add that list to the incident plan so the right people are told on time. Check whether your insurance covers contractual liability. NetSenX evidence helps answer the questions customers ask afterwards: when it started, which devices were involved and what left the network.

Usually not as a full-time hire, but it needs someone to do the job. A chief information security officer (CISO) owns security strategy, risk and incident response. In a company of a few dozen to a few hundred people, those tasks are often shared: a manager owns the risk, an IT person or provider runs the controls, and an outside adviser or a part-time “virtual CISO” helps with policies, audits and questionnaires. What matters is that every task has a name next to it and that management receives a regular picture. As the company grows or customers demand more, a dedicated role becomes worth it. Tools reduce the watching, not the judging: NetSenX explains each alert so a non-specialist can triage it, but a person still decides what to do.

By deciding in advance what must keep working, and how to run it without the systems that may be down. A business continuity plan lists the critical activities (taking orders, paying staff, shipping goods), the systems each depends on, and a manual or alternative way to run each one for a few days. It includes contact lists on paper, a way to communicate if e-mail is gone, and the order in which systems are restored. Backups must be kept where an attacker who controls the network cannot delete them, and restores must be tested. Practise the plan once a year. NIS2 lists business continuity, backup management and crisis management among the required measures. NetSenX does not restore systems; it can give earlier warning so the plan is started sooner.

Which risk it reduces, who will use it, and what it will not do. Ask the vendor and your IT team: which problem on our risk list does this address; who reads its output and when, including at night; how long until it is useful; what is the full yearly cost, including staff time; what data does it collect, where is that data stored and under which contract; and how do we leave and take our data with us. Ask for the limits in writing: a vendor that says what its product does not see is easier to trust. Prefer a trial on your own network to a slide deck. NetSenX has a Free plan with no time limit, publishes its prices and states plainly what a network sensor cannot see.

The ones about money moving and money at risk. Who can change supplier bank details, and how is a change verified? Which computers can make payments, and is anyone watching them? What would one day without systems cost, and what does our insurance cover, with which conditions and exclusions? Are our answers on the insurer's questionnaire still true today? What do our security tools cost per year in total, including staff time, and what risk does each reduce? Which contracts carry penalties for downtime or data loss? These questions turn security into figures a board can weigh. NetSenX helps with one of them directly: on every plan it flags a payment PC that starts contacting an unknown server at regular intervals, a common sign of banking malware.

At least every quarter as a standing item, and immediately after any serious incident. A quarterly review keeps the same few metrics in front of the board, records decisions and shows trends: open incidents, monitoring coverage, backup tests, overdue patches and reporting deadlines met. Once a year, go further: review the risk register and risk appetite, the incident plan and the insurance cover, and hold a short exercise. Under NIS2, the management body of an entity in scope approves the security measures and oversees their implementation, which is hard to show without regular minutes. Keep the minutes and papers: they are evidence that oversight happened. NetSenX PDF reports, available from the Starter plan, can serve as the network annex to each quarterly pack.

Ask a few concrete questions, put the answers in the contract and limit what the supplier can reach. Before giving a supplier remote access or your data, ask how it protects its own systems (multi-factor authentication, patching, monitoring), whether it has had incidents, who on its side can reach your systems, and how it will tell you if it is breached. Write a notification duty into the contract. Then grant the least access needed, for the time needed, and remove it when the work ends. Supplier risk is real: Verizon's 2025 Data Breach Investigations Report found third-party involvement in 30 % of breaches, up from 15 %. NetSenX shows the connections a supplier's remote session makes inside your network and raises an alert if it starts moving from device to device.