NAS with Audit Logging: EU Compliance Requirements

Leo · 2026-10

NAS with audit logging means an on-premises appliance records who accessed which file, when, and through which account, and keeps those records under the organisation’s own control rather than a vendor’s. For European buyers the requirement rarely starts in the IT department.

It arrives from a client questionnaire, an insurer, or a supervisory authority asking how access to personal data can be demonstrated. This article sets out what the record has to contain, how long to keep it, and how to test it before you buy.

Here is the awkward part. Plenty of organisations own a storage appliance and cannot answer the question when it is put to them.

The appliance holds the files. It may hold access records too. The difference between those two statements is the difference between passing a customer review and promising to look into it.

Accountability under the General Data Protection Regulation asks a controller to be able to demonstrate that its measures are appropriate to the risk. A log is one of the few artefacts that does that work rather than merely asserting it.

What should an on-premises NAS audit log contain?

A usable record contains five fields per event: the account, the timestamp, the object touched, the action taken, and the outcome.

Anything less and the record cannot answer the two questions a review actually asks, which are who had access, and what they did with it. A timestamp without an account is a diary. An account without an object is a rumour of activity.

The event categories worth insisting on are these:

• Sign-in and sign-out, including failed attempts against named accounts.
• File operations that create, read, modify, move or delete content.
• Permission and group changes, which are the events most likely to be questioned later.
• Administrative actions, including account creation and configuration changes.
• Sharing actions, when a file is exposed beyond the internal network.

Why do administrative actions belong in the same log as user activity?

Because permission changes decide who can reach what, and a record that omits them cannot answer the first question an auditor asks. That question is rarely about an ordinary member of staff. It is about who altered access to the folder that holds the client files.

An audit trail that covers users but not administrators describes the traffic while leaving the roadworks undocumented.

Setting a retention period for access records

European data protection law does not set a single retention period for access logs, and any supplier who quotes one as a legal requirement is simplifying generously. The European Data Protection Board publishes general guidance on how security measures are assessed, and it does not attach a number to any of them.

Retention follows purpose instead. A log kept because it answers client questions should be kept for as long as those questions can be asked. That is the part of NAS with audit logging buyers most often leave undecided.

The practical rule we suggest to buyers is to align log retention with the retention period already applied to the data being logged, then add one full audit cycle on top. If the client files are kept for six years, keeping their access records for six years and one review cycle means the evidence exists for every period the files themselves exist.

There is a second half to this that buyers often skip. A log with no documented purpose and no end date is itself a data-protection question, because it holds personal data about staff behaviour indefinitely. Documenting why the records exist, and how they are deleted at the end of that period, turns an accidental archive into a defensible one.

How much storage do access logs actually consume?

Log data is usually measured in gigabytes while the media it describes is measured in terabytes, which is why the capacity objection rarely survives the arithmetic.

Log storage (GB) = events per day u00d7 bytes per record u00d7 retention days u00f7 1024u00b3

Take a 40-person office generating 10,000 file events a day. Recorded at roughly 1 KB per event over 365 days, that needs about 3.5 GB. Widen each record to 4 KB and the same year needs roughly 14 GB.

The published capacity ceiling for the two-bay S2 platform is 60 TB, so log data stays a rounding error against it. Logs get switched off because nobody owns the decision, not because the disks are full.

Inside a small professional practice

Consider a hypothetical nine-partner law firm in Lyon with 34 staff, which moved its client case files off a consumer cloud drive and onto an appliance in its own server room the previous year.

The trigger arrives in the form of a corporate client’s own compliance review. The client asks the firm to evidence who accessed a specific client folder over the preceding eighteen months, as part of a supplier assessment. On the cloud drive that question would have been answered with a promise to enquire. On the appliance it is answered with a filter.

The trade-off the firm faced was between recording everything and recording the operations that answer the question. Recording every read of every file produces a volume that nobody reviews. Recording sign-ins, permission changes and file modifications produces a set that a partner can actually read before a client meeting.

The firm’s decision, reached in an afternoon, was to log administrative and permission events permanently and file modifications for the retention period of the matters themselves.

Requirements worth writing into a supplier specification

Write these as requirements rather than wishes, because a specification that says the appliance should “support auditing” can be met by almost anything.

• Access control per named account, rather than one shared administrator login for the office.
• Access records held on the appliance itself, so the organisation keeps custody of its own evidence.
• Export of a defined date range into a readable format, without a vendor portal in the path.
• Administrative and permission events captured alongside user activity.
• Log deletion only through a documented procedure with a defined retention trigger.
• An option to run the whole deployment without any outbound connection.

A thirty-minute acceptance test before purchase

Ask for a demonstration unit or a sample appliance and run this acceptance test. It takes about half an hour and settles more questions than a specification sheet does.

1. Create three accounts with different permission levels.
2. Sign in with each account and open a shared file.
3. Change one permission while signed in as an administrator.
4. Export the records covering the previous hour.
5. Confirm each action appears with account, timestamp and object name.
6. Delete a test file and check the deletion is recorded.

Two outcomes end the evaluation quickly. If a permission change does not appear in the export, the log will not survive a real review. If the export only exists inside a vendor portal, your organisation does not hold its own evidence.

How the requirements compare in practice

The table below starts from the questions a reviewer asks and works back to the evidence that answers them.

Each entry in the last column is something a buyer can rule out in a demonstration, rather than something to take on trust.

What should you put to a supplier in writing?

Five questions cover the substance of it. Where are access records stored, and who can delete them? Which events are captured? Can records be exported for an arbitrary date range? What happens at the end of the retention period? Can the deployment operate with no outbound connection at all?

The answers to the first and last of those questions decide whether the appliance functions as a custodial system or as a convenience.

woCyber states that its platforms support localised deployment and access auditing. woCyber’s published description of the S1 appliance records that each member gets an isolated storage space on the unit, which covers the account separation half of the problem. What a buyer can put to the test is custody: if the records live on the appliance, the organisation can produce them without asking anyone’s permission. The products hub lists the capacity ceiling of each platform for buyers sizing both the files and the records that describe them.

Where the deployment also has to serve several teams with different access levels, the products/x4-nas-server platform is the one we point administrators towards, because per-bay activity indicators make it possible to see which drive is being written to without opening a management console. Buyers drafting their own acceptance test may find the verification points in ai-nas-security-features-to-verify-before-deployment a useful starting list.

Gaps that appear in almost every first deployment

Switching logging on after the incident is the first. Records that would have answered the question were never created, and no configuration change can recover them.

Treating the log as an IT artefact is the second. Someone outside the IT team has to be able to read it and explain it to a client, and that person is usually not the administrator.

Confusing account isolation with an audit trail is the third. Isolation limits who can reach the data. Logging shows who did. A buyer needs both, and neither one substitutes for the other.

Start with administrative and permission events if only one setting can be changed. They are the events an audit begins with, and the ones an organisation is least likely to notice in daily use. A specification that names them explicitly is far harder to satisfy superficially than one that asks for auditing in general.