CDW Blog

Building Effective Security Programmes: Part 6 – The Interdepartmental Integration Domain

29 March, 2024 / by Greg Van Der Gaast


Welcome back to our series on building security programmes; a series we hope helps you better secure your organisation, but also highlights CDW’s commitment to help customers approach security holistically and effectively with their unique business contexts in mind.  

In this instalment I want to cover a part of my frameworks that I’ve ended up calling the Interdepartmental Integration Domain.  

This domain started out as a HR Integration domain when I wanted to define security-relevant things HR would need to be involved in, such as signing off on an Acceptable Use Policy, the definition of job roles for automated access provisioning purposes, a disciplinary process, guidelines on investigations into employees, pushing improvements to culture, security training, identity checks, and so forth. 

It then grew to include the Legal department, due to some legal issues and concerns around the above. That relationship with Legal grew to include GDPR, compliance, contractual issues with purchases, incident disclosure, making sure we considered any [security] liabilities in customer contracts, and generally reviewing anything the business was undertaking from a security liability perspective. 

More than just dealing with potential legal issues, having an open dialogue with the legal department also made us aware of a lot of things going on in the business due to them often being involved in some capacity while we were not. 

As a bonus, the General Counsel tends to have a seat at Board/ExCo level and gets listened to. A good relationship with them and their team can be a huge help getting traction and support for your programme.  

In my last organisation, with a strong B2B focus and enormous multi-national customers, we started working closely with Sales and Product teams too to make sure that our delivery matched our commitments and to help guide what we (our business, not our security team) could achieve in terms of commercial promises around anything relevant to security. 

I’ve found that helping commercial teams answer technical concerns from customers (especially time-sensitive ones) to win business can really help build support for the security teams from a commercial perspective.  

It won’t surprise you to find that being seen as a contributor to the top line is a lot better than a drain on the bottom one. It started making sense to collaborate with both Sales and Product; not just because we could contribute to the business, but because it gave us a level of support and influence around our security concerns. Thus, those activities were added to the HR and Legal ones in our framework. 

All this to say that the purpose of this domain is to define the interactions, relationships, roles, and responsibilities between non-technical departments in delivering on the security strategy, which should include helping the business.  

Currently, I allow the technical parts/aspects of the business, such as IT, their own domains in my framework for ease of management purposes, due to there being more items at play. 

So far, for me, this domain has focused on HR, Legal, Product, and Sales, but you may find benefit to including other areas, or to give those other areas their own dedicated domains like the next few I’ll cover in the following chapters. 

Make sure to read our next instalment, which focuses on one of those larger dedicated domains: IT Operations. 

As always, if you feel we can support you in any way with building or running your programme, please get in touch. We’d love to help.