Metrics & Reporting
May 15, 2026 · Last updated on May 19, 2026
Getting Your Peers on Your Side
How to get technical teams to share the data you need
Ant Davis
Here's a situation most awareness practitioners will recognise.
You want to build a proper picture of where human-related risk sits in your organisation and you know that the data probably exists somewhere. It could be incident logs and phishing platform results broken down by team. Maybe it’s the volume of help desk tickets and SOC alert patterns. But you're not exactly sure what’s available, who owns it or how easy it would be to access.
Sometimes you know what you need and you just need someone to share it. Maybe you don't know what they have and you need to find that out first. Either way, you’ll likely hit the same obstacle at some point. You find yourself confronted by a team that doesn't have time, isn't sure they should be sharing what you want or doesn't understand why you need it at all.
This is one of the most common and least talked about challenges in security awareness. It's not a measurement problem but more of a people problem. The way through it isn't to push harder on the data request, but to change the conversation entirely.
Sell the mission before you ask for anything
The mistake most practitioners make is leading with the ask. Can you share your incident logs from the last twelve months? Can you break down the phishing results by department?
To someone in IT or the SOC who doesn't know you well and is already stretched, that sounds like more work for unclear reasons. Their instinct is to be cautious or to deprioritise it.
The conversation you actually need to have is a different one. It starts not with what you need but with what they're dealing with. What does their week look like? What's taking up most of their time? What are the recurring security issues that land on their desk that they'd love to see less of?
Because the honest answer, in most organisations, is that a significant chunk of what makes their life hard has a human behaviour component. They could be credential compromises that start with a phishing click or incidents that could have been reported earlier but weren't. They could be help desk calls from people who don't know what to do when something feels off. These are awareness problems as much as they are technical ones.
Once they can see that, the data conversation changes. You're not asking them to do you a favour. You're telling them that you're trying to solve a shared problem, and that their data is the thing that helps you point your efforts at the right places.
What do they have that you want?
Sometimes you don't know what to ask for yet. You know you need data but you don't know what they have, how it's stored, or whether any of it would actually be useful. If that’s the case, the first conversation isn't the ask, it's the discovery.
That's actually an easier conversation to have as there's no commitment being asked for, no sensitivity concern triggered and no workload being created. You're just curious. What do you collect, what does it tell you, and what patterns have you noticed? More importantly, you're not asking them to do anything yet. You're finding out what exists before you decide what you need.
Discovery conversations often surface things you wouldn't have thought to ask for. It could be a log that the SOC has been running for two years that nobody outside the team has looked at. Maybe there is a pattern the help desk has noticed but never had reason to flag. It could be data that's easy to share once someone understands why you'd want it. If you go in with open questions rather than a list of requirements, you'll often come out with more than you expected.
Once you know what's available, you can then come back with the specific ask, and you have already started building that relationship.
Be clear about what you're asking for and why
Whether you've had a discovery conversation first or you already know exactly what you need, by the time you're making a request for data, it needs to be specific. Vague requests get cautious responses. If you go into this conversation without a well-defined ask, you'll walk away with nothing.
Know exactly what you need before you sit down. Which data, covering what time period, at what level of granularity, and in what format. The more specific you are, the easier it is for someone to say yes, and the easier it is for them to see that what you're asking for is reasonable.
Then be equally clear about how you'll use it. You're looking for patterns, not individuals. You want to understand which parts of the organisation are carrying the most human-related risk so you can build targeted interventions for those populations. You're not building a performance management tool and you’re definitely not going to name individuals in a report. You're trying to make the programme smarter.
That distinction matters. A lot of resistance to sharing data comes from a fear that it will be used to call people out or assign blame. If you address that concern directly, before it gets raised, you remove one of the most common barriers before it becomes a conversation.
What's in it for them
This is the part of the pitch that closes it.
If your awareness programme works, if it actually shifts behaviour in the populations that matter most, then the downstream effect is fewer incidents for the SOC to investigate, fewer credentials to reset, fewer phishing reports clogging the queue, and fewer help desk calls from people who clicked something and panicked. There will be less noise, less reactive work and they’ll have more time for the things that actually require their expertise.
That's not a overly optimistic outcome, either. It's a direct, practical outcome that makes their job easier. You need to make that connectionand make sure to tell them that what you're building together, if it works, reduces the pressure on their team. Because it does.
The data they share with you now is an investment in that outcome and framing it that way changes the dynamic from a request to a partnership.
When you hit a wall
Sometimes the conversation goes well and you still don't get what you need. There could be competing priorities or concerns that need escalating. You may have a team lead who isn't willing to make the call without cover from above.
It's at this moment when you need backing and support. It’s not to go over anyone's head in a way that damages the relationship, but to make it clear that what you're asking for has organisational support behind it.
A conversation with your CISO, your CRO, or whoever owns the security function can change the dynamic quickly. Don't frame it as a directive but more of a visible signal that the awareness function's access to this data is considered legitimate and important at a senior level. You'll find that most of the time, that's enough to unblock things.
However, a word of caution. If you are going to use this lever, use it carefully. The relationship with your technical peers is a long-term asset and you want them to feel like partners in the end, not people who were overruled.
Building the relationship for the long term
The data conversation is easier the second time than the first, and easier again the third time. The practitioners who consistently get access to what they need aren't necessarily the ones who made the best pitch but they're the ones who built genuine working relationships with the teams they depend on.
This means showing up before you need something. Do you have relevant threat intelligence that you can share with the SOC. Make sure you let the help desk know when a campaign is running so they understand the context of calls coming in. If you close the loop when you use someone's data, telling them what you found and what you did with it, they’ll be more willing to help you again in the future.
These habits build the kind of trust that make it a conversation rather than a negotiation. Then, you have positioned the awareness function as a legitimate, credible part of the security operation rather than a team out on the edge that occasionally asks for things.
Before you have this conversation
There's a companion worksheet for this post called the Peer Data Access Prep Sheet, which walks you through the preparation before you sit down with a technical team. Even without it, there are three things you need to be clear on before you walk in.
What exactly are you asking for? We’re not talking about a general sense of it but more the specific data, the time period, the level of detail, and the format. Vague requests often get cautious responses.
How will you use it and what won't you do with it? The reassurance matters as much as the request. Patterns not individuals, smarter targeting not performance management, and shared outcomes not surveillance.
What gets better for them if this works? That's the close. Will they have fewer incidents to investigate, less noise in the queue, and less reactive work. If you make that connection explicit, you've turned a data request into a partnership conversation. That could be gold!
Back to the Collection
Next: Turning Data Into a Programme Narrative
Like
Comments (0)
Popular
