Yes, and this is one of the few places the regulation nearly says so outright. Recital 49 treats processing strictly necessary and proportionate for network and information security as a legitimate interest of the controller. So the basis is not the hard part. The hard part is that security monitoring in a real company watches employees as well as attackers, and the balancing test changes completely at that boundary.
This article covers what Recital 49 supports, where the balancing test gets difficult, the line between securing systems and monitoring staff, why scope and retention decide the outcome, and what this looks like across an actual stack.
Recital 49 Does Most Of The Work
Recital 49 identifies processing to the extent strictly necessary and proportionate for ensuring network and information security as constituting a legitimate interest. That covers resisting unauthorised access, preventing damage to systems, stopping denial-of-service attacks, and detecting malicious code.
Two words in that formulation carry the weight: strictly necessary and proportionate. It is not a general authorisation to collect anything security-flavoured. It supports processing that is genuinely needed for the security purpose and no more.
The three-part assessment for legitimate interests — purpose, necessity, balancing — still has to be run and documented, and that page covers how each part works. What Recital 49 gives you is an unusually strong starting position on the purpose test, and a reasonable expectation that people anticipate their service provider defends its systems. It does not pre-answer necessity or balancing, and those are where real assessments fail.
Where The Balancing Test Actually Gets Difficult
Against external attackers the balance is straightforward. The data subject is often an unauthenticated party attempting something unauthorised, the intrusion is minimal, and the interest is obvious.
It gets harder in three places.
Your own users. Fraud and abuse detection processes ordinary customers as well as bad actors, because you cannot tell them apart in advance. Everyone is assessed so that a few can be identified. That is defensible and it is a real intrusion, and the assessment has to say so rather than pretending only the guilty are processed.
Your own staff. Access logging, endpoint monitoring and anomaly detection produce a detailed record of what individual employees did and when. The employment relationship carries an imbalance of power that weakens reasonable expectations as a justification.
Scope creep. A system built for security acquires a second audience. Access logs get used to settle a performance question. Endpoint data answers a productivity query. The moment security telemetry is used for a non-security purpose, the Recital 49 argument stops covering it — you have a new purpose, needing its own basis and its own assessment.
The Line Between Securing Systems And Monitoring People
This is the distinction the whole subject turns on, and it is worth drawing precisely.
Securing systems asks whether something is wrong: unusual access patterns, credential stuffing, exfiltration signatures, privilege escalation. Individuals appear because activity has to be attributable, not because anyone is the subject of interest.
Monitoring people asks what a named individual is doing: keystrokes, screen contents, application time, productivity scoring. The individual is the point.
Systems built for the first can be operated as the second without any technical change, which is why the boundary needs writing down and enforcing rather than assuming. Monitoring employees at work is a distinct subject with a different analysis, its own transparency requirements, and in many jurisdictions a works council or consultation dimension. Recital 49 does not reach it, and a security justification stretched over it is the specific move that fails.
The practical test: could you explain this system to the people it watches, in plain terms, and would they recognise the description? If the honest answer involves not mentioning a capability, the capability has outgrown the basis.
Scope, Retention And Access Decide The Outcome
Because the purpose test is easy here, assessments live or die on necessity and proportionality — which come down to three operational decisions.
Scope. Collect the fields the detection actually uses. Full request payloads, message bodies and screen contents are rarely necessary for security and enormously expand the intrusion. Necessity is assessed against what the security purpose needs, not what the tooling can capture.
Retention. Security data has a genuine investigative half-life, and it is shorter than most defaults. Ninety days serves most detection and forensics; multi-year retention of everything is a storage-limitation problem wearing a security justification, and it converts a monitoring system into a standing archive of employee behaviour.
Access. Who can query it, whether queries are logged, and whether anyone outside security can reach it. An unrestricted log platform that the whole engineering team can search is a different proposition from a controlled one, and it is the version that fails a balancing test.
Get those three right and the assessment writes itself. Get them wrong and no amount of Recital 49 saves it.
What This Looks Like Across A Real Stack
Most of this data does not sit in a system labelled "security." It sits in application logs, cloud provider audit trails, endpoint agents, identity provider records and CI pipelines — and the personal data in the last of those is rarely where anyone expects to find it.
Three things follow. Every one of those systems belongs in your record of processing activities with the security purpose and the legitimate interests assessment attached. Your privacy information has to state that you rely on legitimate interests and describe them, because transparency is independent of basis. And people retain the right to object under Article 21, which for security monitoring will often be refused — but refused with reasoning that was written down beforehand rather than improvised.
Third-party security vendors are processors and need Article 28 terms, and they belong on your subprocessor list. That is where a security tool most often goes unregistered, because it was adopted by the team least likely to be asked for a vendor form.
Common Mistakes With Security Monitoring Assessments
Treating Recital 49 as the whole assessment. It gives you a strong purpose test and nothing else. Necessity and balancing still have to be worked through and written down, and those are the parts a regulator reads.
Letting security telemetry answer non-security questions. Using access logs to settle a performance dispute creates a new purpose with no basis. The technical capability is identical, which is exactly why the rule has to be organisational.
Collecting full payloads because the tool can. Capturing everything and filtering later inverts the necessity test. Proportionality is assessed on what you collect, not on what you look at.
Setting retention by default rather than by decision. Most logging platforms ship with a retention period nobody chose. For security data that period is a decision about how long you keep a behavioural record of your staff, and it should be made deliberately.
Not telling anyone. Legitimate interests removes the need to ask permission, not the need to be open. Undisclosed monitoring fails on transparency even where the basis itself would have held.
FAQ
Do we need consent from employees for security monitoring?
No, and consent would be the wrong basis. In an employment relationship consent is rarely freely given because of the imbalance of power, and monitoring that stops when someone declines is not a security control. Legitimate interests is the appropriate basis, supported by a documented assessment and clear notice to staff.
Can someone object to being security-monitored?
They can object under Article 21, and you must consider it on their particular circumstances. For genuine security monitoring the objection will often be refused, because you can usually demonstrate compelling legitimate grounds. What matters is that the refusal follows a real reassessment and is explained, rather than being a form response.
Does this cover fraud detection as well as intrusion detection?
Broadly yes — fraud prevention is widely accepted as a legitimate interest and the reasoning parallels network security. Note the difference in who is processed: fraud detection assesses your own customers rather than external attackers, so the balancing test carries more weight and the transparency obligation is more visible.
How long can we keep security logs?
There is no fixed period. Keep them as long as the security purpose genuinely needs, decided by you and written down with a reason. Most detection and investigation work happens within weeks, so long default retentions usually reflect a platform setting rather than a judgement. If the honest reason is "in case we need it," that is not a retention period.
Closing Thought
Security monitoring is unusual among GDPR questions because the lawful basis is the easy part and the discipline is the hard part. Recital 49 hands you a purpose almost no supervisory authority will argue with, and that generosity is precisely what makes the failure mode subtle: an assessment written once, a system whose scope quietly expands, a retention period nobody set, and a capability that was built to catch intruders being used to answer a question about an employee. None of those is a basis problem. All of them are the reason the basis stops covering what the system does.
The durable version is narrow scope, a retention period someone chose, controlled access, and a written boundary about what the data may not be used for. ComplyDog hosts a compliance portal on your own domain with your DPA, subprocessor list, data subject request forms and a security page — which is where the security posture you have built becomes something a buyer can check. It does not scope your logging, set your retention or write your balancing test; those stay with whoever runs the systems.
