People, HR and insider risk

By checking which devices actually connect, not only which accounts were closed. Offboarding usually removes the user account and collects the laptop, but an unreturned laptop, a personal phone with saved Wi-Fi credentials or a forgotten remote-access tool can keep connecting. Compare your list of returned devices with the devices seen on the network after the leaving date, change any shared Wi-Fi and VPN credentials the person knew, and revoke certificates issued to their devices. On every plan, the NetSenX network map lists the devices seen on monitored segments, with the name each device announces and when it was first and last seen. NetSenX does not know who left the company: HR and IT decide that, and the network view shows whether the door actually closed.

The access the person had, not only their account. A short leaver checklist for IT: disable the directory and e-mail accounts and remove multi-factor authentication tokens; collect company devices and note their names; change shared passwords the person knew, such as Wi-Fi, VPN, admin and supplier portals; remove remote-access tools they installed; revoke device certificates; and check, a few days and a few weeks after the leaving date, that none of their devices still appears on the network. Run the same checklist for contractors and interns. Agree with HR who triggers it and when. NetSenX helps with the last step: the network map, on every plan, shows each device's name and when it was last seen, so a device that should be gone stands out.

Yes, if it connects to a segment you monitor, or if it still runs the NetSenX agent. On every plan, the network map shows each device with the name it announces and when it was last seen, so a laptop that reappears after its user left is visible, and if it starts scanning, beaconing to an outside server or uploading unusually, alerts follow. A laptop used only at home or on another network, without the agent, is invisible to a network sensor. In parallel, close the other doors: disable the accounts, revoke the device's certificates and VPN profile, and use your device management tool, if you have one, to lock or wipe the laptop remotely. Recovering the device itself, and any steps against the person, are matters for HR and legal advice.

Partly: you can see unusual uploads from their computer, not the files or the person. On every plan, NetSenX compares each device's outbound traffic with that device's own normal destinations, volumes and times of day, and raises an alert when, for example, a laptop that usually sends little suddenly uploads several gigabytes to a cloud storage service at night. The alert shows the device, destination, volume and time. It does not show file names or content, because the traffic is encrypted and NetSenX never decrypts it, and it cannot see copies to a USB stick. Treat such an alert as a security event first: the laptop may also be infected. Any step towards the employee should follow your policy, the law and advice from HR and legal, not the alert alone.

Only what national employment and data protection law allows, collected for a legitimate purpose and in proportion to it. In general terms, the GDPR requires a legal basis, a specific purpose, data minimisation and transparency towards employees, and many countries add employment-law rules on monitoring and on works councils. Records you already keep for security, such as alerts about unusual uploads, may be reused only where the new purpose is compatible and the law permits it; secretly reading a person's private communications is generally off limits. Before collecting anything, involve HR, the data protection officer and legal advice, document the suspicion and the steps taken, and secure evidence through people qualified to do it. NetSenX shows device activity in alerts; it is not a tool for profiling an individual.

No. A network sensor sees connections, not files. Most uploads today travel inside encrypted sessions, and NetSenX never decrypts traffic, so it cannot read file names or content. What it can show is that a particular device sent an unusual amount of data to a particular destination at a particular time, compared with that device's normal behaviour. That narrows the question: when, from which device and to where. To learn which files were involved, you need other sources: the cloud service's own audit logs, file-server access logs, endpoint tools or data-loss-prevention (DLP) software, each used within the limits of employment and data protection law. A copy to a USB stick or a printout never crosses the network at all.

Not with NetSenX. It analyses metadata and a few protocol fields: which device connected to which address and port, when, how often and how much data moved, the server name in the TLS handshake and the answers to DNS queries. It never decrypts traffic, so the content of e-mails, chat messages, web pages and prompts typed into AI tools stays unread. Some other products do decrypt or inspect content, so ask every vendor the same question and get the answer in writing. Metadata can still be personal data, because device names and IP addresses can be linked to a person, so the GDPR applies to it. Explain this distinction to employees and the works council before you start: it answers the most common worry precisely.

About devices rather than people, but some of it can still identify a person. NetSenX records connection metadata from the segments it monitors: internal and external IP addresses, ports, times, volumes, the server names devices contact (from the TLS handshake and DNS answers) and the names devices announce on the network. From that it builds alerts and a network map. It does not record message or file content and never decrypts traffic. Because a laptop called after its user, or an address assigned to one person's computer, can point to an individual, treat these records as personal data: inform employees, keep only what you need, limit who can see it and delete it on schedule. NetSenX stores customer data in the EU and publishes its data processing agreement with the full sub-processor list.

Possibly, depending on your country and on how the monitoring could be used. In Germany, section 87(1) no. 6 of the Works Constitution Act (Betriebsverfassungsgesetz) gives the works council a right of co-determination over introducing and using technical systems designed to monitor employees' behaviour or performance; many companies agree a works agreement before deploying security tools. Other countries give employee representatives information and consultation rights, and the GDPR lets national law add rules for the employment context. Involve the works council or employee representatives early, explain that the purpose is attack detection on devices, what is and is not recorded, who sees the alerts and how long data is kept. NetSenX's published description of what it reads makes that conversation concrete; the legal assessment stays with you.

By looking at what actually connects to your network, rather than at your asset list. Personal phones, laptops and smart devices often join the office Wi-Fi or a spare network socket without anyone recording it. On every plan, the NetSenX network map lists the devices seen on monitored segments, with the name each device announces and when it was first and last seen, so unfamiliar devices stand out; if one of them scans the network or keeps contacting an unknown outside server, an alert follows. A network sensor cannot tell who owns a device or whether it is allowed: compare the list with your inventory and policy. The lasting fix is structural: a separate guest network for personal devices, and network access control on the office network where you can.

Yes, mainly because nobody knows what is on them. A personal laptop may have no endpoint protection, out-of-date software, pirated programs or malware picked up at home, and on a flat office network it sits next to payroll and customer data. It is also outside your control when the person leaves. Safer options: hand out the company laptop on the first day; if that is not possible, give temporary access through a separate guest network and a browser to cloud services, not to internal file shares; and write the rule into onboarding. If personal devices do connect, watch what they do: NetSenX shows new devices on the network map on every plan, and alerts when a device scans the network or keeps contacting an unknown outside server.

Yes, for the segments NetSenX monitors. On every plan, the network map lists each device seen there, with the name it announces and when it was first and last seen, so devices first seen this month are easy to pick out and compare with your onboarding records and asset list. The list covers only segments with a sensor: one agent on a switch's mirror port (SPAN) or a network TAP sees a whole segment, while a guest Wi-Fi or a branch office without a sensor stays out of view. Device names are what devices announce, not verified identities, and they can be changed. A device that connected only briefly and sent nothing noteworthy may appear with very little detail. For a complete inventory, combine this view with your device management and DHCP records.

Only where you can see the laptop's traffic: when it runs the NetSenX agent, or when its traffic reaches a segment you monitor, for example over the company VPN. A commercial VPN or the Tor network shows up as a long-lived encrypted connection to an outside address instead of the usual mix of destinations; NetSenX shows the destinations and volumes, and whether a destination belongs to such a service you judge from the address and the server names involved. It cannot see inside the tunnel. Remember that a private VPN is often harmless, so start with a question, not an accusation, and check your remote-work policy. Device management tools that enforce the company VPN, and identity logs that show where logins come from, cover what a network sensor cannot.

Mainly that the person may not be who they claim to be, or that their equipment is not under your control. Fraudulent applicants with borrowed or invented identities have been used to gain legitimate access to code, data and internal systems, and a laptop that only ever connects from abroad over a private tunnel is hard to oversee. Reduce the risk in hiring and onboarding: verify identity with a live video call and official documents, check references directly, ship a managed company laptop rather than allowing a personal one, give access step by step and only to what the role needs, and require multi-factor authentication. Identity checks are HR's job. Where the laptop runs the NetSenX agent, unusual tunnels, beaconing or large uploads show up as evidence or alerts for IT to review.

No: monitor the company devices and what reaches the company, not the employee's home. A home network carries the family's phones, games and private traffic, and watching it would collect personal data you have no reason to hold, which is hard to justify under the GDPR and employment law. What you can reasonably protect is the company laptop and the company network: run endpoint protection and device management on the laptop, require the company VPN for internal resources, and monitor where that traffic arrives. With NetSenX, a company laptop can run the agent itself, which watches that one device's connections wherever it is; it does not monitor other devices on the home network. Tell employees exactly what is monitored on their work device, and why.

By watching which devices talk to it and flagging new ones. A payroll or HR server normally has a small, stable set of clients: a few computers in HR and finance, a backup system, perhaps the payroll provider. When a workstation that has never connected to it suddenly does, especially at an odd hour or after scanning other machines, that is worth checking at once. On every plan, NetSenX learns each host's normal connections and raises a lateral-movement alert when sessions between devices do not match that pattern, naming the source device, the destination and the time. It does not manage permissions and does not know who sat at the keyboard: restrict access with accounts and firewall rules, and use the server's own login logs to see which account was used.

Usually the payroll and HR systems, followed by a few less obvious ones. Think of shared folders with contracts and medical certificates, the directory server that holds every account, the backup server that holds copies of everything, and the mailboxes of HR and management. Start by listing them, with who owns each one, which computers and suppliers should reach it and whether it is in-house or a cloud service. Then protect them in layers: multi-factor authentication, access only for the people who need it, encryption at rest, logs of who logged in, and backups the network cannot delete. For the systems on your own network, NetSenX helps with one layer: on every plan it raises an alert when a device that does not normally connect to them starts to, or when one of them sends unusual volumes of data out. Cloud HR services need their own audit logs.

As a security event about a device first, not as evidence against a person. An alert says that a device behaved unusually: it may be infected, used by someone else, or doing something legitimate that looks odd. IT checks the facts first: what the device did, when, whether malware is present, and whether an account was misused. HR is involved only if the facts point to a conduct issue, and then under your disciplinary policy, employment law and data protection rules, ideally with the data protection officer consulted. Keep the circle small, record each step, and do not discuss names until the facts are clear. NetSenX supports this split: its alerts describe devices, connections and destinations, and its audit log records who handled an alert and what they decided.

Only within narrow limits, and it is not what NetSenX is built for. Security monitoring is set up to detect attacks on devices; using its records to investigate a person is a different purpose, which data protection law treats as a separate question of compatibility, legal basis and proportionality, and which employment law and works-council rules often restrict further. In some cases, such as a documented suspicion of a serious offence, limited use may be lawful after legal advice. Never run a hidden investigation through a security tool on your own initiative. NetSenX is device-centric: its alerts describe what a device did on the network, not a person's browsing history, and it never reads content. Decide in advance, in writing, who may request security records for an investigation and who approves it.

Sometimes, but it depends on national law and on how the logs were collected and announced. Under the GDPR, personal data collected for one purpose, such as network security, may be used for another only where the new purpose is compatible or another legal basis applies, and employees must have been informed about the monitoring. National employment law adds its own conditions: some countries require prior notice or a works agreement, and courts in several Member States have excluded evidence gathered through monitoring that was hidden or disproportionate. So before a log is used against anyone, take legal advice, involve the data protection officer and check what employees were told. NetSenX logs describe device activity and are kept for your plan's retention period; whether they are admissible is a legal question.

By fixing the purpose, the data and the people with access before you start, and writing it down. State the purpose as detecting attacks on devices and systems, and exclude performance or behaviour monitoring. Collect metadata only, keep it for a defined period, and limit access to the few people who handle security, with a log of what they do. Tell employees what is monitored and why, involve the works council or employee representatives where they exist, and carry out a data protection impact assessment if the processing is likely to be high risk. Review the set-up once a year. NetSenX supports this by design: it watches devices and connections, never decrypts traffic, reports AI use per device and program rather than per person, and keeps an audit log of who did what in the account.

Yes, and it is often a good hiding place. A computer that nobody uses but that stays switched on and connected, such as the desk of someone on long leave, a spare PC in a meeting room or an old machine kept for one program, rarely gets updates and nobody notices if it behaves oddly. Attackers use such machines as a quiet base to scan the network, reach servers or send data out. Switch off and disconnect what is not needed, keep the rest patched, and give each machine an owner. On every plan, NetSenX raises alerts when any monitored device starts beaconing to an outside server, scanning, connecting to hosts it never used before or uploading unusual volumes, which stands out most on a machine that should be doing nothing.

By comparing what it does now with what it normally does. A computer that should be idle, because its user is on leave or it is only switched on for updates, has a very small normal pattern: a few update servers, perhaps the backup system. Anything beyond that, such as regular connections to an unknown outside server, logins to other internal machines, scanning or large uploads at night, is a strong signal. On every plan, NetSenX learns each device's own normal destinations, volumes and times of day, and raises alerts for beaconing, scanning, lateral movement and unusual outbound data volume, with the device, destination and time. It cannot see what happens inside the machine without network traffic; endpoint protection covers that. Write down which machines should be idle, so a stand-in knows.

Usually switch them off or take them in, and make sure their accounts cannot be misused in the meantime. Agree a simple routine with HR for leave of more than a few weeks, such as parental or sick leave or a sabbatical: the laptop is stored or kept switched off, desktop machines are shut down, and the account is suspended or left active only with multi-factor authentication, depending on whether the person still needs remote access. When the employee returns, update the machine before it rejoins the network. Treat this as a security step, not as a judgement on the person, and say so in the policy. If a machine must stay on, for example for a shared task, give it an owner. NetSenX alerts on every plan if such a device starts beaconing, scanning or uploading while it should be quiet.

Mostly by controlling where they can connect, and then watching what they do there. Contractors usually bring their own laptops, which you do not manage and cannot inspect. Give them a separate network or VLAN with access only to the systems their project needs, time-limited accounts with multi-factor authentication, and a contract clause on security and incident notice. Then monitor that segment. On every plan, NetSenX lists the devices seen there, with the name each announces and when it was first and last seen, and raises alerts if a contractor's laptop scans the network, keeps contacting an unknown outside server or connects to internal machines outside its usual pattern. It does not see inside the laptop or inside encrypted sessions. Tell contractors what is monitored, as you would tell employees.

Yes, where you can, because it limits what an unmanaged laptop can reach. On a flat network, a contractor's laptop sits next to payroll, file servers and production systems, so any malware it carries can try to reach all of them. A separate Wi-Fi network or VLAN that allows only the internet and the specific systems the project needs, through a firewall, turns that into a short, reviewable list of permitted connections. Remove the access when the project ends. Segmentation is done in your switches, firewall and Wi-Fi controller; NetSenX does not change network settings or block traffic. What it adds is a check that the separation works: if monitoring shows a contractor's device reaching internal hosts outside the permitted list, or scanning, it raises an alert.

Yes, on the segments NetSenX monitors: the network map shows each device's last-seen time on every plan. After a project ends, check that the contractors' devices no longer appear, and look again a few weeks later; a laptop that keeps returning after the end date means access was not fully removed, whether through a saved Wi-Fi password, a VPN profile or a remote-access tool left behind. Pair this with the administrative steps: disable the contractor accounts on the end date, change any shared credentials they were given, remove their VPN profiles and certificates, and collect any badges or hardware. The network view does not know contracts or end dates, so keep a simple list of contractor devices with the expected end date and compare it with the map.

No. Copying files to a USB stick, an external disk or a phone connected by cable happens inside the computer and never crosses the network, so no network sensor, NetSenX included, can see it. That gap is covered on the endpoint: device-control settings in your endpoint protection or operating system can block or log removable storage, data-loss-prevention (DLP) tools can watch which files are copied, and disk encryption protects company laptops if they are lost. Network monitoring helps only at a later step: if the copied data is later uploaded from a company device on a monitored network, an unusual outbound volume from that device can raise an alert. Decide which control fits, explain it to employees, and check national rules on monitoring at work before you switch on file-level logging.

An endpoint control, not a network tool. Most endpoint protection suites, and the management features built into current operating systems, include device control: you can block removable storage entirely, allow only company-issued encrypted drives, or allow read-only access, and log attempts. Data-loss-prevention (DLP) software goes further and can block copying of documents marked as confidential. Start with the simplest rule that fits the work, since a total ban often pushes people to e-mail files to themselves instead, and pair it with disk encryption on laptops. Write the rule into the IT policy and tell employees, because logging what people copy is monitoring under data protection and employment law. NetSenX does not do this; it sees only data that later crosses the network.

The upload itself, if it leaves from a monitored device or segment: the device, the destination, the volume and the time, but not the files. If someone copies data to a USB stick at the office and uploads it from home, the office network never sees the upload. If the upload happens from a company laptop running the NetSenX agent, or from a computer on a monitored segment, NetSenX compares that outbound traffic with the device's own normal pattern on every plan and raises an alert when it is unusual, for example several gigabytes to a personal cloud storage service at night. The content stays unread, because NetSenX never decrypts traffic. To find out what was uploaded, you need the logs of the cloud service or endpoint tools, used within employment and data protection law.

You can limit who has access to the security account at all, and that is the first step. Alerts can name the devices of HR, management or finance, and sometimes those names point to people. From the Starter plan, NetSenX supports team management with roles, so you can add only the few people who handle security and give each the role they need; the Free plan has a single user. Everyone with access should know that alerts are confidential. If you need finer separation, for example so that IT staff do not see alerts about the HR director's laptop, check with us what the current role model supports before relying on it, and consider handing such alerts to a small group or an outside provider. Every action in the account is recorded in the audit log on every plan.

It logs actions. On every plan, the NetSenX audit log records what users do in the account: who changed an alert's status or closed it, who recorded a decision, who changed a setting or added a team member, and when. That gives you a trail for internal reviews, auditors and works-council questions about who handled sensitive alerts. The audit log has its own retention period, which grows with the plan; the pricing page lists it. Do not assume that merely opening or reading an alert is recorded: if you need a record of who viewed what, ask us what the current version logs before you promise it to anyone. Combine the audit log with a short written rule on who may access security alerts and why.

Yes: two-factor authentication is available on every plan, Free included. It adds a second step to the login, usually a code from an authenticator app, so a stolen or guessed password alone does not open the account. Switch it on for every person who uses NetSenX, and make it part of your onboarding checklist, because a security account shows how your network is built and which devices raised alerts, and that is exactly what an attacker would like to read. The same reasoning applies to every other administrative account you hold: e-mail, cloud services, firewall, backup system and remote-access tools. NetSenX also records actions and changes in the account in its audit log, so unexpected activity in the account can be reviewed. Remove users promptly when they leave the team.

What is monitored, why, what is not, who sees it and how long it is kept, in plain words and before monitoring starts. The GDPR requires controllers to give people clear information about processing of their personal data, and employment law in many countries adds notice or consultation duties. A good notice says: we monitor company devices and network connections to detect attacks; we record connection metadata such as addresses, times, volumes and server names, not the content of messages or files; a small named team sees the alerts; records are kept for a stated period; here is whom to ask. Put it in the IT policy and the privacy notice for staff, and update it when the set-up changes. NetSenX's own description of what it reads helps you write this precisely.

No. NetSenX reports AI use per device and per program, not per person. From the Pro plan, it shows which devices reached which external AI services or local model runtimes, when, and how much data moved; where the agent runs on the computer itself, it can also name the program that made the connection. It never decrypts traffic, so it cannot show what was typed, pasted or uploaded. Linking a device to a person is a separate step that HR should take only for a clear, lawful reason, such as a suspected data breach, and with the safeguards your policy and national law require. For most purposes you do not need names: knowing that the finance department's devices send data to an unapproved service is enough to fix the policy, approve a proper tool or offer training.

Insider risk is harm caused by someone with legitimate access: an employee, contractor or supplier who misuses data or systems on purpose, makes a costly mistake, or has their account taken over. The difference from an outside attack is the starting point: an insider is already past the front door, with valid credentials and normal-looking activity, so controls built only around the perimeter miss it. Most insider incidents are mistakes rather than malice, so the best measures are simple: give people only the access their role needs, remove it when roles change, use multi-factor authentication, keep backups and train staff. NetSenX sees one part of this: unusual behaviour of a device, such as connections to servers it never used or large uploads. It cannot judge intent and does not watch people.

Yes, they can ask, because the GDPR gives every person a right of access to personal data about them. If network records can be linked to an employee, for example through a laptop named after them or an address assigned to their computer, they may request a copy and information on purposes, recipients and retention, subject to the limits the GDPR and national law allow, such as protecting other people's rights or an ongoing investigation. As employer you are the controller and answer the request within the time limit set in Article 12 of the GDPR. Prepare for it: know where security records are kept, who can export them and how to remove data about other people. NetSenX, as your processor, supports such requests under its data processing agreement, and its records concern device connections, not message content.

It should say plainly that company devices and networks are monitored for security, what that means and where the limits are. A useful section covers: the purpose (detecting attacks and protecting data, not measuring performance); what is recorded (connection metadata from company devices and networks, not message content); whether private use of company devices is allowed and how private traffic is treated; rules on personal devices, USB storage, remote-access tools and AI services; who sees alerts and how long records are kept; what happens when an alert involves an employee's device; and whom to ask. Keep it short enough to be read, have it reviewed by legal advice and, where required, agreed with employee representatives. Describe NetSenX by what it does: device and connection monitoring, without decryption.

As long as you need them for security and any legal duty, and no longer: the GDPR's storage-limitation principle requires a defined period, not keeping records just in case. There is no single EU number for network security logs, so set one yourself and write down why. Common reasons for a longer period are investigating incidents that are found late, answering auditors, insurers and authorities, and sector or national rules that ask for records; reasons for a shorter one are that the logs relate to identifiable employees and that less data means less to protect. Many companies choose a period of months for alerts and longer for incident records and decisions. NetSenX's alert history and audit-log retention depend on the plan; the pricing page lists both.

Emotion recognition at work is banned, and AI that monitors or evaluates workers is treated as high risk. Article 5 of the AI Act prohibits AI systems that infer the emotions of people in the workplace, except for medical or safety reasons, and Annex III lists AI used to monitor and evaluate the performance and behaviour of people in work relationships as high-risk, with strict duties for providers and deployers. The GDPR and national employment law apply on top, and works councils often have a say. So be careful with tools that score staff productivity, read keystrokes or analyse faces and voices. NetSenX is built differently: it watches devices and network connections to detect attacks, reports AI use per device and program, never per person, and does not evaluate employees.