Implementing a successful information security change

22 Dec Implementing a successful information security change

I often get asked the question, “How do you successfully integrate information security requirements into your organisation’s processes?”. In most organisations, information security controls need to be integrated across the whole business, making them a high impact change. This is what makes this question so valid.  If a change is positive, you are reducing risk, but if not, not only are you leaving risk unmitigated but you are very possibly causing disruption to the business that could impact revenues.

In this post I’ve summarised some recommendations on how to enact a positive change when implementing your information security controls. The below is not a step-by-step guide, but pointers to think about if you are planning, driving or implementing an information security change. The points do not need to be followed consecutively.

• Understand the problem you are trying to fix

This will grant you focus. It will allow you to not do things just for the sake of best practice. Understanding the risk you are trying to mitigate, and more importantly the organisational impact you are trying to avoid if this risk comes into play, will guide your decisions when planning, prioritising and implementing the change.

• Understand the people, processes and  departmental objectives that you are impacting with this change

This is definitely a key part of a successful change. Take the time to understand the processes into which you will be putting your control, understand the main goals of the departments and people that need to effect the change, so that you may make sure that their objectives are not impacted by your change but only protected by it.

Say for example you want to kick off a vulnerability management process, requiring a change in behaviour by your developers and your product people. It will require your devs to understand the vulnerability, to fix the vulnerability and your product teams to prioritise it accordingly. Before writing up a long policy, highlighting due dates, CVSS scores and requirements for prioritisation – take the time to understand how these teams work, and make sure your new requirement does not disrupt how they work, but compliments it and integrates easily to it.

This way, you are a partner to the department/s being impacted. A partner that understands their objectives, and is simply trying to secure them as they work towards these goals.

• Start small

One new requirement might seem small for you, because you understand it and you know why it is needed, but you probably do not need to implement it in your every day work. Therefore it is key that you start small, allow the teams impacted to understand the change, to get accustomed to it and to start making it their own.

Take the time to explain why the change is needed and ask their feedback on it, before formalising it. Then make sure you are there as it is implemented, ready to answer any questions and to adapt the requirement if it is not fully working out. Ideally break the change down into small parts, by teams, processes or systems. So if for example, you have more than one product, do not implement the vulnerability management process on all of the verticals at once. Start with one, implement, adapt and then continue on to the next.

This also give you and your team time to implement the change diligently, to observe its impact and to swiftly adapt if required.

• Communicate

Make sure to communicate any controls you want to put into place, well in advance. Take into account that your requirement needs other teams’ collaboration and time. Respect that and let them know what and when something is required.  Communicate what is being done, what will change, stakeholders impacted, the reason behind the change and most importantly when its kicks off make sure to appreciate everyone’s collaboration on moulding the requirement into something that can mitigate risk, without disrupting operations.

• Re-assess and iteratively improve

As you initiate the change, check in regularly to understand if it is working and hence mitigating risk. Set targets for the change, a plan identifying which teams and processes will be impacted and when. As you are implementing the change across the organisation, always find the time to reflect, gather feedback and iteratively improve your process as you go along. It is important that the process introduced matures with time. You should have targets for your risk mitigation, and your process should change and improve, to ensure appropriate risk mitigation. As the teams get more acquainted to the process, plan to then improve it and build it up. Starting small, does not mean staying small. Your process needs to mature with the business, and continue to mitigate risk to an acceptable level.

• Measure

As you set targets for your new controls, it definitely helps to set key performance indicators (KPIs) to measure these targets. It is through measuring a process that you can note if a change is having the desired impact, allowing you to make informed decisions when adapting your change. A good indicator for a vulnerability process for example is noting the amount of vulnerabilities being introduced decrease with time, as your process increases awareness, and your time to resolve decrease with time, as your product team aligns better to your due dates and starts prioritising vulnerabilities accordingly.

Hope this helps – if you have any questions, please do not hesitate to contact me on strategicsecurity@dianeabela.com.