In security, we used to think about our adversaries operating in days and weeks and months. And in today's world, we now think about those adversaries moving in hours and minutes. Right? It's it's as expensive as it's ever been. There's there's new threats. There's new VOLNs. There's new intel, that GRC teams and SOC teams need to be aware of. So it's really critical that, teams are aware of this information, this data as soon as it's available, and that most importantly, they work with other internal stakeholders on those threats, on that data so they so they could take action. You know, segregated teams really can't keep up with the pace in which our adversaries are moving at today. When I think about how SOC and GRC can no longer operate as separate functions, I think about how, you know, you think about a risk register and you think about a a CVE fee. Right? And one is important to SOC and one is important to GRC. And I think if you're not sharing that data, you're you're gonna have blind spots. And and even worse, you're gonna have a lot of duplicated effort because these teams are sort of working towards a lot of the similar and same goals. As as Paul said that both teams are working towards the same goal. They're helping out the organization. They're sharing a lot of the same tooling nowadays with the communication tools, and supporting that each team complements each other. So silos create the most friction, in my opinion, in workflows. That silos lead to slower speeds. Slower speeds leads to slower remediation times possibly. If there's a silo, the teams need to work together in the same communication channel, in the same reporting structure ideally, and they're they're doing the same the same work. There can be a lot of frustration that exists where security is going out and doing a lot of really good work, and they're they're handling these vulnerabilities and these critical CVEs. The GRC team is not reflecting that in their risk register. And I think, you know, on the on the opposite side, mirroring that, GRC has a lot of priorities with their risk registers and their vendor diligence. Right? But that doesn't always align with what security is doing if you guys are truly operating in in separate silos. The friction isn't just it it it's not just personal. It becomes kinda structural, and it it gets worse over time because you really feel like a lot of the work you're doing doesn't necessarily matter to another team that may be reporting different information up or down the chain. Premium rate dot com. The best first steps to bridging the gap is to sit down and have a conversation. Right? Don't get too far ahead of yourself. Sit down with the stakeholder from from GRC or from security and start with the conversation of, you know, two questions really is how do you measure measure success on your team and what does critical mean to you? You wanna understand each other. You wanna both sit down at the table to learn each other's priorities, to learn each other's, you know, KPIs, SLAs, the goals, the workflows, to understand what you're each are working towards. I think there's a lot of opportunity to break down walls and silos and have these teams working together more often and and work towards the same goal. And I I guarantee you that there's gonna be so much commonality between between you and them in terms of what success looks like and and how to define critical. Don't try to do all of it at once. Don't try to automate the entire process. Meet first. Understand what the current process is. Understand what each of your goals are. It's that getting to know the other party. It's understanding what what success is like for them and and how you can help there. Right? Walk would be maybe build the initial draft of the automation of the workflow and and document it. And then the run phase really is business as usual. You understand the problems. You understand the common goals. You now have a a automated bidirectional sync. You're starting to trust your counterpart and some of the information that they provide as well as lean on lean on them for a lot of the information you never had before. Right? And the the run phase will never stop. You will continue to run, for forever. But once you get there, it becomes a lot easier. Shared context can really change the response. Low hanging fruit I see is is vendor diligence. And I think about my GRC team and, you know, everyone does vendor diligence as we onboard and we we ask a lot of those questions. But when we think about vendor diligence and apologize to to my GRC people out there, but vendor diligence is sort of an archaic way in which we perform that that diligence today. Right? We we send a questionnaire out to a third party, and then they have someone go and answer those questions from that questionnaire. And by the time we get it back, the data we have is already stale. It's already a day old, a week old, maybe the assessment or documentation that they're providing is three or six months old. So from from GRC's perspective, they have it. They're checking that box. They're performing their assessment on potentially stale data. And having shared context, right, having real time data on that vendor can change the whole outcome and and how you really risk rank a vendor. For responses to different alerts regarding, you know, cyber threat intelligence specifically, I think it relates a lot to priority and prioritization and shared common goals between the teams and understanding, criticality and tiers. So I I think it's really important to have the right context that complements both teams to get some background on on the threat, on the vendor, on the resource that's involved because it impacts prioritization for both teams. And that's when it goes back to the the automation of the workflow is where we can if we can quarterback it and assign it at SLA and criticality as early as possible, it helps both teams with resource allocation and management. So strong strong coordination, communication, working relationships are are absolutely needed during a real incident. And if we take a step back, we want to address that before an incident ever happens. We want to establish a a continuous working relationship, a rapport, and understanding of both teams where where where they collaborate, where they're using the same tooling, same communication channel, same practice, and simulated exercises before a real incident ever happened. Coordination converts a chaotic response into really a managed one and and and a singular response from the business, and I don't think that that comes naturally. I think that that's built on trust and the the the relationship that you build between SOC and GRC. Having that coordination, having the understanding of where your battle station is and what you're responsible for during an incident is really key because because during a real incident, time is of the essence. You don't want to have a a debate or a discussion on, oh, what's my role? What do I do? Yeah. Ryan and my response is gonna be the same for for this one for sure. In terms of exercises that you can do, a tabletop is is the best that you can go through. You know, sit down, create a scenario, whether it's just with GRC and SOC, though I would encourage you to bring in other stakeholders from the business as well and simulate an incident that has either already happened within your business or come up with one that you think is likely to happen. Yes. For for activities exercises that both teams can do, a tabletop would be at the top of my list, whether that's internally hosted or externally hosted by a third party. You know, there's no such thing as a bad tabletop, whether that you do whether you do a light session or a full session involving your executive team, PR team, legal team, I think practice makes perfect. And I think involving the relevant stakeholders and getting the the greater team exposed to it is really important. It's okay to fail on these. No tabletop will ever go one hundred percent the right way, and that's that's a good thing. If you finish a tabletop and everything's great, you guys probably didn't quite get into the nitty gritty you want. You wanna have an after action plan from it and learn from it and understanding what both parties are responsible for. So I'm I'm a big fan of them. At BidSight, we've had a few tabletops over over several years, and we've we've reiterated and and we've ensured them each session based on employee feedback. I don't think that alignment is a state in which you can put a button on or plant a flag and stay and say, you know, we have achieved this. I think that it's a little bit more of a a practice in which you can observe and feel and understand and and work towards to improve upon. For both teams, alignment does not happen overnight. And alignment, you know, as Paul mentioned, should never be an end goal. It should be a continuous thing that you're working towards, whether that's different meetings on different cases, you know, like I said earlier, shared tooling, instant response exercises, understanding each other, having having common goals. So alignment to me is is is touching base, keeping each other updated, monitoring the threat landscape, monitoring the trends, and and getting ahead of the curve for both teams. But it's sort of a state in which you will feel as you trust your your other part. Like, trust Ryan and his GRC team today, and I think that that's the approach that that I take in terms of alignment between SOC and GRC. PremiumBeat dot com. So when I think about leadership and what they care about, it's really two things is where does risk exist and how quickly can we resolve that risk or or eliminate that risk. So I think if you can start to pull together some of the metrics around identification to remediation and how these tools, you know, this information can really shrink that time tremendously. I think that is, you know, those are some of the easy metrics to roll up as you start to integrate more of these tools into your arsenal as a security or GRC professional. And those metrics that Paul just mentioned are really are are a testament and a and a scale on how well the teams align and are working together. They're complimenting complimenting each other, especially that that stat about initial notification to remediation. Right? When something comes in in in the front door, how soon till we can remediate that and and and close it? And that comes down to both teams having their processes, workflows, building that relationship, building that rapport, throughout the year. So there's a, an automated process that's that that's followed when, when when the time comes and and senior leadership would be very interested in understanding those stats and it shows the the growth and maturity of the relationship between both teams is the is the time to remediation, the time to notification, and all the other stats related to that.