Articles / Privacy Law

848 words

  • uk-law
  • uk-gdpr
  • legitimate-interests
  • security-logs
  • data-protection
  • ico

Does a Legitimate Interests Assessment Cover Your Server Monitoring?

Mostly yes, for the thing you actually wrote down, and no for everything you quietly added later. Security monitoring of your own server is one of the easiest legitimate interests to justify. The trouble is that an assessment is a snapshot of one purpose, and logs have a habit of drifting into other jobs.

This is general information on UK GDPR, not legal advice. Where I am giving opinion rather than law, I say so.

Security is a named example, not a free pass

Recital 49 of the UK GDPR says processing personal data to the extent strictly necessary and proportionate for network and information security is a legitimate interest of the controller. That is the recital, so it is interpretive text, not an operative article. The Data (Use and Access) Act 2025 went further and, as I read it, added security of network and information systems to a list of example legitimate interests in Article 6 itself.

Either way, it tells you the interest is valid; it does not tell you the processing passes the test. The ICO's three-part test still applies:

  1. Purpose: is there a legitimate interest? (Yes: keeping your server from being compromised.)
  2. Necessity: is this processing needed for that, or is there a less intrusive way?
  3. Balancing: do the individuals' interests, rights and freedoms override yours?

The ICO guidance on this is at ico.org.uk. Note the word "strictly" in the recital. It is doing real work.

Where the necessity test bites

Necessity is where most of the practical questions land. "We log everything in case" is weaker than "we log these fields because we need them to spot credential stuffing". Compare two nginx log formats:

log_format everything '$remote_addr - $remote_user [$time_local] '
                      '"$request" $status "$http_referer" "$http_user_agent"';

log_format sec '$remote_addr [$time_local] $request_method $uri $status';
access_log /var/log/nginx/access.log sec;

The second drops the query string ($uri has no arguments), the referrer and the user agent. Query strings are where tokens, email addresses and search terms end up. If your detection does not use them, your necessity argument for keeping them is thin. That is my opinion on proportionality, not a rule from the regulator.

Quick detour: is your own server even in scope?

If it is purely personal, the household exemption may apply and none of this bites. But a public blog, a service others log into, or anything run for a business or project is unlikely to be purely personal. Courts and the ICO read that exemption narrowly, so I would not lean on it for a server open to the internet. Whether it applies depends on your circumstances.

Four ways the assessment stops covering you

Here is where I see the cover run out:

  • Purpose creep. Logs kept for intrusion detection get reused for analytics, or to see which staff member visited what. That is a new purpose needing its own assessment and a compatibility check.
  • Retention. The LIA justified monitoring, not keeping the data for three years. Retention needs its own justification tied to how far back an investigation realistically looks.
  • Sharing. Shipping logs to a third-party SIEM or threat-intel feed makes the provider a processor or a controller, and you need the right terms and transparency.
  • Sensitive content. Logs can capture special category or criminal-offence data by accident (a URL that names a medical condition, say). Legitimate interests alone is not enough for those categories; they need an extra condition.

Objections and transparency still apply

Relying on legitimate interests keeps the right to object under Article 21 alive. For security monitoring you will usually be able to show compelling grounds, since you cannot realistically drop one visitor's IP from your intrusion detection and keep the protection. But you should expect to answer the objection, not ignore it.

You also need to tell people. A privacy notice that mentions server logs, what is in them, why, and how long they are kept covers this. Logs are personal data, so they can also surface in a subject access request, which I have covered separately.

What a usable assessment looks like

It does not need to be long. A page that you can point to is enough for a small setup:

  • The purpose, in one sentence (detect and block unauthorised access).
  • The exact fields logged and why each is needed.
  • Who can read them, and where they are sent.
  • The retention period and what deletes the data.
  • The balancing note: what a visitor would reasonably expect, and the effect on them (low, since logs are not used to make decisions about them).
  • A review date, and a rule that any new use triggers a fresh look.

That last item is the one that keeps it honest. An assessment written once and filed away is exactly the document that fails when someone asks what the logs are really for.

Automated blocking, such as banning an IP after repeated failures, is worth a line too. A short ban on an address is unlikely to amount to a decision with legal or similarly significant effects under Article 22, but that conclusion is mine, and it weakens if the block is permanent or tied to an identifiable person's account.

← All articles