How Arbiter supports your GDPR Article 32 obligations
GDPR Article 32 requires you to implement appropriate technical measures to secure personal data, including the networks it travels across. Network access control can form part of those measures. This page explains what Arbiter provides, what it doesn't and how to pull the right artefacts for your DPO or auditor.
What Article 32 actually asks for
Article 32 of the GDPR requires controllers and processors to implement "appropriate technical and organisational measures" to ensure a level of security appropriate to the risk. It names four specific examples:
- Pseudonymisation and encryption of personal data
- The ability to ensure ongoing confidentiality, integrity, availability, and resilience of processing systems and services
- The ability to restore access to personal data in a timely manner following an incident
- A process for regularly testing, assessing and evaluating effectiveness
Network access control sits inside the second point: confidentiality, integrity and availability of systems. An uncontrolled network, where any device can connect and move laterally, is a direct threat to all three. A compromise originating from an unmanaged device may become a reportable personal data breach under Article 33 depending on impact and risk.
Arbiter doesn't make you compliant. It provides the access-control layer that your DPO and auditors are looking for as part of your overall Article 32 posture.
Six Article 32 controls in one layer
Each control below maps to a specific GDPR obligation. This is the table your DPO can pull directly into a DPIA or Article 32 assessment.
Device authentication before access
802.1X with EAP-TLS and certificate-based authentication. Devices protected by 802.1X policy must authenticate before network access is granted. Phishing-resistant in practice because certificate-based EAP-TLS does not rely on reusable passwords.
Art. 32(1)(a): confidentiality
Network segmentation by identity and device type
RADIUS policies assign devices to appropriate VLANs based on certificate identity and device classification. Personal data systems sit on isolated segments. RADIUS policy can restrict unmanaged or guest devices from reaching those segments.
Art. 32(1)(b): integrity
Audit-ready access logs
Full RADIUS accounting records every access decision with timestamp, device identity, policy applied and VLAN assigned. Exportable in JSON and CSV formats. Configurable retention per tenant.
Art. 32(1)(d): testing and evaluation
Policy evidence, not just policy claims
Every access decision is tied to the rule that produced it. When an auditor asks "how do you enforce that only managed devices reach your HR system?", the answer is a log query, not a conversation.
Art. 5(2): accountability
Data minimisation in the product itself
Arbiter records the metadata standard RADIUS carries (timestamps, device identities, VLAN assignments, accounting attributes) plus the DHCP fingerprint attributes you choose to forward (Options 12, 55, 60, 61, 82). It does not capture network payloads. We log what happened at the access layer, not what was in the packets. This is the default, not a configuration option.
Art. 5(1)(c): data minimisation
Authentication anomaly monitoring
MAC address spoofing detection, failed authentication tracking and per-tenant alerting on unusual patterns. Early signals for your incident response process.
Art. 33: breach response input
Three things to pull out for an Article 32 assessment
If your DPO or external auditor is running an Article 32 assessment and asks what network controls are in place, here is exactly what to hand them.
1. The access policy export
From the Arbiter management portal, export your RADIUS policy configuration as a PDF or JSON. This shows the rules that govern which devices reach which segments. It's the documentary evidence that segmentation is configured and enforced, not aspirational.
2. The accounting log for the audit period
RADIUS accounting logs are available for export from the portal filtered by date range, device type or policy. For a GDPR audit this typically means the last 90 days. The log shows every access decision: device, policy applied, VLAN assigned, timestamp. This supports evidence of ongoing assessment and evaluation under Article 32(1)(d).
Cloud-side retention defaults to 90 days, set deliberately low by reference to GDPR Article 5(1)(e) storage limitation. For longer trails (NIS2 incident investigation, DORA operational resilience evidence, APT review where a question surfaces about access from twelve or eighteen months ago) tenants have two options. The cloud retention window is configurable per tenant up to 365 days. And the authentication log, accounting log and audit log can be streamed to your own SFTP destination on a daily schedule for permanent archiving in your own data lake. The records are append-only by design and exported in JSON or CSV, so they ingest cleanly into Splunk, Elastic, Sentinel or a plain S3 bucket. Retention beyond your cloud window then becomes your own decision under your own controller responsibilities, not a limit Arbiter imposes.
3. This page, as a vendor statement
You can reference this page directly in a DPIA or procurement questionnaire as evidence of Arbiter's GDPR posture. For the corresponding processor-side transparency statement (lawful bases, sub-processors, retention, DPA terms), see our data protection page.
Need a DPIA support pack (data flows, data categories, retention, TOMs)? Email privacy@arbiter.ie and we will generate one for your specific deployment.
Where NAC is not enough on its own
We find it more useful to be clear about what Arbiter doesn't do than to let you discover it during a procurement or incident. A complete Article 32 posture requires multiple layers. Here is what you still need alongside NAC.
Endpoint detection and response (EDR)
Arbiter controls which device connects to which network. It does not monitor what happens on the device after it connects: file access, process execution or outbound connections. You still need EDR for that layer.
Data Loss Prevention (DLP)
NAC enforces access at the network layer. It doesn't inspect data in motion, whether a file is being uploaded to a personal cloud drive or otherwise. DLP tools sit at the application or proxy layer.
User and Entity Behaviour Analytics (UEBA)
Arbiter logs access decisions. It doesn't build behavioural baselines for users or entities over time. Spotting patterns like unusual data volumes is the domain of SIEM/UEBA tooling.
Encryption of data in transit beyond the access layer
Arbiter enforces that a device authenticates before joining a VLAN. What happens on that VLAN is not Arbiter's scope. TLS for application traffic, email encryption and data-at-rest encryption are separate controls.
Breach detection
NAC provides anomalous access signals: unusual device behaviour, failed authentications and unexpected MAC addresses. These are inputs to a breach-detection process, not breach detection itself. Arbiter complements SIEM tooling; it does not replace it.
If a vendor tells you their single product covers all of Article 32, ask them to show you the log where their NAC detected the exfiltration. We prefer honest claims.
Technical and organisational measures
Arbiter forms part of a broader set of technical and organisational measures (TOMs) used to protect personal data within customer environments. Arbiter is typically deployed alongside:
- Endpoint security and EDR on managed devices
- Least-privilege identity and access management
- Encrypted application traffic (TLS) and data-at-rest encryption
- Vulnerability management and patch management processes
- Tenant-scoped access controls and logical segregation between customer environments
- Centralised logging and SIEM monitoring
- Security awareness training and acceptable use policy
Auditors and DPOs asking for a TOMs summary can request a deployment-specific document from privacy@arbiter.ie. We typically turn these around within 48 hours.
What Arbiter collects about your end-users
When Arbiter is deployed on your network, the data that flows through the platform about your end-users (employees, visitors, students) is the metadata standard RADIUS carries plus the DHCP attributes you choose to forward for device profiling. Concretely:
- RADIUS authentication and accounting: device MAC address, User-Name (an email or certificate subject for 802.1X, the MAC for MAB), NAS identifiers, session start and stop timestamps, authentication result, VLAN assignment, standard accounting attributes (Acct-Session-Id, octets in and out, session duration).
- DHCP discovery, when you forward it: the device MAC, DHCP Option 12 (hostname), DHCP Option 55 (parameter-request-list, a vendor fingerprint), DHCP Option 60 (vendor class identifier), DHCP Option 61 (client identifier), DHCP Option 82 (relay agent information, when present) and the relay IP. DHCP forwarding is something you turn on at your switches or relay agent. If you do not turn it on, Arbiter never sees DHCP.
We do not capture network payloads. We don't see what websites are visited, what files are transferred or what applications are used. The access layer is what we log, not the activity layer.
What we do not transmit outside our infrastructure: DHCP Option 12 hostnames are deliberately excluded from every sub-processor payload because that field is the one most likely to contain a user-chosen name. Our only third-party fingerprinting sub-processor (Fingerbank) receives an anonymised MAC (first four bytes only, device-unique suffix replaced), the Option 55 fingerprint and the Option 60 vendor class. Nothing else.
Retention defaults to 90 days and is configurable per tenant up to 365 days. Tenants that need a longer trail (NIS2 incident review, DORA evidence, forensic look-back) can configure daily SFTP export of the authentication log, accounting log and audit log into their own data lake for permanent archiving. You are the controller for this data; we are the processor. Your end-users' rights should be handled by you as the controller.
The full processor-side transparency statement, including our lawful bases, sub-processors, breach notification SLA and your Data Processing Agreement terms, is on our data protection page.
Need a DPIA support pack for your procurement process?
We can produce a deployment-specific data flow diagram, data category summary, retention schedule and TOMs document. Email us, usually with a 48-hour turnaround.
Last updated May 2026. For questions about this page, contact privacy@arbiter.ie.