You’re the CISO at a multinational logistics company with operations across the EU. Your security team just finished investigating a phishing campaign that hit your finance department. They’ve pulled together the Indicators of Compromise (IoCs) (everything that identifies the attack): sending IP addresses, sender domains, the malicious URLs in the message body, as well as the email headers.
The team wants to push all of it to your Information Sharing and Analysis Center (ISAC), the industry group where member companies trade threat data. Your general counsel reads through the information and immediately requests a stop. He says those IP addresses and email headers are personal data under GDPR.
What do you do?
Your options:
A: Share the IoCs in full with the ISAC, since incident response qualifies as a legitimate security purpose exempt from the usual personal data handling rules
B: Document an LIA, and strip or mask personal data elements that are not necessary for threat intelligence purposes before releasing the IoCs
C: Share the IoCs under your ISAC membership agreement, which functions as a data processing arrangement satisfying third-party data sharing requirements
D: Decline to share any IoCs with the ISAC until legal counsel confirms that every data element has been formally anonymized
The most widely chosen answer is …
I use the above scenario with CISSP candidates, and the option they choose most often aligns with mitigating risk, and is also wrong. I’ll share it below, but first let’s talk about the importance of IoCs.
Why full anonymization breaks indicators
IoCs matter because they include specific detail. When you give another company the IP address associated with your phishing campaign, they can search their own mail logs for that exact address and learn whether they were hit too. So that IP provides value and helps another organization identify potential harm.
However, if the address is anonymized via a hash, truncation, or placeholder replacement, it loses that value. Sending anonymized data as an IoC is essentially sending your ISAC a package that says “we saw a bad thing,” with no way for anyone to check whether they saw it too.
Two words that sound similar
In European Union law, including the General Data Protection Regulation (GDPR), a regulation has two main parts: Articles and Recitals. Articles are the legally binding rules of the law. They dictate explicit obligations, rights, prohibitions, and penalties. Recitals are the preamble to a law. They explain the legislative background, intention, and context behind the legal articles. The GDPR has 173 Recitals. While a Recital is not a standalone enforceable command, it serves as an official interpretive guide.
We can use a couple of Recitals to better understand GDPR legislative intent, specifically regarding anonymized and pseudonymized data and how that data can be used in a scenario like ours. While both terms address data privacy and concealing true identity, they differ on whether the data can ever be linked back to an individual. Anonymization destroys that link forever, while pseudonymization keeps a key to trace the data back later.
Recital 26 puts truly anonymous data completely outside GDPR regulation. Here’s in part what it says: “The principles of data protection should … not apply to anonymous information,” meaning information that doesn’t relate to an identifiable person, or personal data rendered anonymous “in such a manner that the data subject is not or no longer identifiable.” The same recital covers the other case. Personal data that has been pseudonymized, “which could be attributed to a natural person by the use of additional information,” is still information about an identifiable person, and therefore still fully in scope.
Article 4(5) defines pseudonymization as processing personal data so that it can no longer be attributed to a specific person “without the use of additional information,” where that additional information is kept separately and protected.
Together, they clarify the picture and the choice. By anonymizing the indicator, the data falls outside GDPR’s scope, but you’ve also lost the shareable intelligence. Preserving the indicator information means you’re processing personal data, and you therefore need a lawful basis.
The six bases
Article 6 lists six lawful bases for processing personal data. The one that fits here is 6(1)(f): legitimate interests. Legitimate interests permits processing that is “necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by … fundamental rights and freedoms of the data subject.”
Then there’s Recital 49, which deserves more recognition in the cybersecurity field. It basically says that processing personal data “to the extent strictly necessary and proportionate for the purposes of ensuring network and information security” constitutes “a legitimate interest of the data controller concerned.” It gives examples, such as preventing unauthorized access to electronic communications networks, stopping malicious code distribution, and stopping denial-of-service attacks.
Writing the assessment
Article 6(1)(f) asks you to weigh three things. As you review your situation and weigh these questions, document your process and how you weighed each one. That documentation is called a Legitimate Interests Assessment (LIA), and while it doesn’t need to be long, you should create it before you share any information to preserve your reasoning.
Here are the three areas to weigh:
A legitimate purpose. Your purpose, in this scenario, is to protect your own network and other companies in your sector from an active phishing campaign. As you work through these, write down the campaign specifics rather than a general statement about security.
Necessity. Explain why a scrubbed indicator won’t adequately provide enough information. “We cannot achieve this purpose with anonymized data, because the receiving members need the exact sending address to search their own mail logs.” I’m obviously simplifying here, but even that one sentence may save you some headaches later.
The balancing test. Weigh your interest against the rights of those whose data you’re processing, and don’t assume too much. A sending address might belong to the attacker. It might just as easily belong to a small company whose mail server was compromised last week, or a home user whose router got pulled into a botnet. Recital 49 asks for processing that is “strictly necessary and proportionate,” and stopping malicious code distribution is one of the stated purposes. Reporting a compromised host is how it gets cleaned up. But you should consider whether your processing causes disproportionate interference or harm. Consult legal counsel to ensure compliance.
What is included, and what gets masked
Once you have a lawful basis, the remaining work is minimization. Article 5(1)(c) requires personal data to be “adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed.” The test is whether specific data serves a purpose, not whether the person behind it is a bad actor.
If your scenario aligns with the stated GDPR purpose, it then likely includes indicators such as IP addresses and sender domains, email headers, malicious URLs, and subject lines to help other members write detections. Just make sure to strip your internal context, for instance, recipient mailboxes and employee names in the headers, internal hostnames and internal IP ranges, and of course any other victim identification. As with documenting your process, also record what you masked and why.
What the question is really testing
Coming back to my test question, the answer most often chosen is D., and that makes sense, because, again, it’s a risk-informed answer, and the instinct behind it is right. In the scenario, counsel is correct that the data appears to be in scope. An IP address can be identifying, and email headers carry names and mailboxes. I keep using this scenario because the incorrect answer of sending anonymized data helps put the correct one in perspective.
Also, waiting or doing nothing feels safe. If you hold on to the indicators, nothing bad happens. But the cost doesn’t disappear; it simply shifts. Another company in your industry gets hit by the same phishing campaign, which may have been avoided if they were better prepared. If they understand what might be coming, they can prepare.
On the exam, this material touches Domain 1 (legal and regulatory issues) and Domain 7, where threat intelligence lives alongside logging and monitoring. In a real scenario, it may play out like a meeting where your team has something useful, and your attorney has a fair concern. If that’s the case, you need to come back with a plan: here’s our lawful basis, here’s why the indicator has to stay intact, here’s what we’re taking out, and here’s the assessment, already written.
Where to read more
All the source material I refer to above is free. The full text of GDPR is published at gdpr-info.eu with every article and recital cross-referenced. Recital 26 and Recital 49 together take about five minutes to read, and Article 6 takes another two. Your ISAC likely has its own sharing guidance written for a similar question, and it’s worth looking up.
This scenario is based on a practice question I wrote for the BalancedSec Academy. If you found this type of process helpful, consider signing up for a beta seat, where you can read my book, study concepts, and practice these types of scenario-based questions using a CAT-like test environment. That’s what the Academy is built for.
One last thing. I need to mention here that I am not an attorney, and this is not legal advice. I’m reviewing a learning scenario used by students studying for industry certification. If your organization finds itself in similar circumstances, please have your attorney evaluate your specific requirements.