Change management and security go hand in hand in modern banking. In this interview, Sanjay Shah, Senior IT Audit Consultant at Emirates NBD, shares insights from his 40-year career in financial services. Starting as a customer service executive in 1980, Sanjay's career spans roles in back office operations, finance, SWIFT operations, data center management, IT service delivery, and information security.
Robert: Thank you to everyone in the audience for joining us today. Today, we will be speaking with Sanjay Shah. He is a senior IT audit consultant for one of the largest bank groups in the Middle East Emirates, NBD.
Thank you so much for joining us, Sanjay.
Today we're going to discuss several topics. We're going to have an intriguing discussion about change management, cybersecurity, and maybe even a little compliance.
However, to kick things off, and so our audience can get to know you a little bit better, can you tell us a few things about yourself and your background?
Sanjay: First of all, thank you for giving me this opportunity to speak about my favorite subject, change management. Let me give a brief about myself. I'm a finance graduate with a diploma in banking from the Indian Institute of Bankers. I have 40+ years of financial service industry experience and have worked with many global multinational banks in various roles.
I started my career as a customer service executive in 1980, then worked in a bank back office, finance department, SWIFT operation, data center operation, IT service delivery, IT service management, information access management, and information security. I'm currently working as a senior manager of cybersecurity and information systems in banking.
Other than my bachelor's degree, I have various security, audit, and control-related certifications like CISA, CISM, CISSP, CRISC, Seagate, Project Management, ITIL Framework (ITIL2, ITIL3), and ISO 27000 certifications. I believe learning never stops - the environment is very dynamic and keeps changing. You have to keep pace with new technologies, risks, threats, vulnerabilities, tools, and technologies.
Robert: Amazing. I really do think you embrace the concept of lifelong learning. I think in our last conversation, you mentioned you're actually working on your cloud technology certifications, is that correct?
Sanjay: Yes.
Robert: See, that's amazing.
Sanjay: GSP certification on cloud.
Robert: Very good. Well, let's talk a little bit about change management. How do you define change management, at least in the context of IT security? And why do you feel that change management is so essential for protecting an organization?
Sanjay: The only thing constant in IT environment is change. It's getting very complex, very dynamic, with new threats, vulnerabilities, and risks emerging every day.
For organizations to protect their data, they need to focus on three core aspects: confidentiality, integrity, and availability. Change management is very important because every change brings new risk. It has an impact on confidentiality, integrity, and availability. If these aspects aren't assessed properly before implementing change, there will be serious impact to the organization.
When implementing new changes, the change management process must ensure changes happen properly, impact assessment is done, and there's a rollback plan. Various stakeholders impacted by the change must be involved. They need to understand the change details, infrastructure impact, server impact, application impact, and risks.
Everything should be properly documented from a security perspective - how confidentiality, integrity, and availability will be impacted. Various approvals and assessments are needed. It's about collaborating with all teams to ensure changes are implemented as intended without risk. If the change fails, there must be a proper rollback plan to avoid impact on confidentiality, integrity, and availability.
Robert: Very good. So another foundational element. Every single compliance or regulatory standard seems to have change management as one of those core controls. Speaking of effectiveness, what measures or indicators do you use to determine whether change management is truly strengthening your security posture?
Sanjay: Looking at key performance indicators, we check several parameters:
- Number of unauthorized changes implemented
- Number of high-impact service requests implemented without proper change requests
- Percentage of changes that are backed out (rolled back)
- Change acceptance rate
- Schedule variance - changes scheduled for a particular time but delayed or not implemented as scheduled
- Number of incidents occurring after change implementation
- Percentage of changes completed on time
These parameters help measure the effectiveness of the change management process.
Robert: Understood. Very good. And you mentioned sometimes you have to rollback changes and take other actions. How do you approach emergency changes while maintaining integrity in your security process and ensure people aren't using that opportunity to violate the change management process?
Sanjay: Emergency changes are inevitable. You cannot avoid them. But implementing emergency changes doesn't mean you don't follow the process. You have to expedite the process of change management - take necessary approvals, ensure you have a rollback plan, and maintain proper communication and coordination.
It's teamwork. Get senior management involved in the process. When you implement, you test and update senior management and stakeholders regularly about the status. With emergency changes, you must follow the process but expedite it while ensuring necessary approval and documentation.
If you don't get proper approval and the change fails or isn't implemented as intended, there can be huge business impact. It can affect availability, confidentiality, integrity and lead to reputational loss. Take proper precautions with processes, approvals, documentation, and communication. After implementation, prepare a lessons learned document.
Robert: That makes sense. Now, could you share your experience with automated tools in change management? What approaches have you found most effective?
Sanjay: I just wanted to clarify - are you speaking about file integrity management tools or change management tools?
Robert: I'm talking about change management.
Sanjay: I have worked with various tools like BMC Remedy, ManageEngine and other ITSM service management tools. These are workflow-based tools. From logging the change to implementation and post-implementation review, everything follows a built-in workflow. Every stakeholder must be involved.
When a change analyst logs a change into the system, they do impact analysis, gather information, update the assessment, involve respective teams, get details and feedback, then schedule the change. They take necessary approvals and security is one of the key stakeholders in the change management process. They have to look at the security impact, including if privileged access is required.
Then it goes to the implementer of the change. They implement it and the final beneficiary verifies the change is implemented properly. It's all workflow-based process management.
I've worked with various tools, but in my view, you can have the best tools, technology, and processes, but if you don't have trained and motivated people, it won't work. People risk is the highest risk. You need mature processes because the best tools won't give results if not supported by robust processes and trained people.
Most tools today try to give too many features that aren't needed. It's like Microsoft Excel - if I ask colleagues how much of Excel's capability they're using, people hardly use 15-20% of its capability. Same with other tools - we have many features but don't use them.
That's why I believe usability is more important - security and usability need balance. Provide the key features required and make sure it's easy to use and implement. Automated processes will have a lower failure rate once configured properly, but will always need some manual intervention.
Robert: Good advice. Security and usability, top of the list, top priority, and it's also interesting you can have the best tools in place, but ultimately people can be the largest problem that you have.
Sanjay: Awareness training and motivated people are key. Many organizations spend a lot of money on nice tools but don't get return on investment because they aren't utilized properly. They can't get the benefit no matter how good the tools are.
Robert: Thank you. Well, you brought up FIM tools. Based on your background, do you view them primarily through a security lens, or through a compliance lens? And what do you think is preventing integrity monitoring from reaching its fullest potential throughout enterprises?
Sanjay: Integrity monitoring tools serve both security and compliance purposes. The most important challenge is knowing what key things you want to check. Take a risk-based approach. Compliance requirements are mandatory.
When configuring FIM tools, be clear about what you want to protect to avoid false positives and noise. This needs to be fine-tuned based on organizational requirements, regulatory requirements, and risks.
Use the 80/20 rule - 20% of your infrastructure operations pose 80% of the risk, so focus there. Look at regulatory requirements and prioritize assets you want to monitor.
Tool vendors initially provide support during implementation, but organizations must ensure proper handover, training, and regular maintenance. They need to know what they want, buy the right tool, configure it properly, and use it effectively with a risk-based approach. This gives maximum return on investment.
Robert: That makes sense. Identifying your scope, taking a risk-based approach. And based on your comments, that usability you described is incredibly important because ultimately ownership belongs with the customer, with that enterprise.
Sanjay: Yes, if they take ownership and implement properly, they get the best return on investment. Otherwise, they blame the tool, saying they spent so much money but it's not good. It's easy to blame the vendor. If you don't know what you want, you won't get what you want. Buy tools based on your requirements, not what's available in the market.
Robert: Very true. Let's talk about system resiliency. Rollback plans are fundamental to change management in any IT environment. Can you explain how you view the role of rollback plans and ability to roll back in maintaining system integrity?
Sanjay: Rollback plans are very important. If changes fail, you must ensure you can rollback to the previous state without impact. Sometimes when rollback plans aren't done properly, you have double impact. You need proper version control, backups taken before implementing changes, and documented, tested plans.
If you can't rollback properly, it creates data integrity issues. In financial or healthcare industries, you have higher risk because you're dealing with sensitive information. You must be very careful with rollbacks, ensuring proper documentation, testing, backups, and approvals.
After access control and change management, resilience is a top subject for auditors, especially with recent cybersecurity threats like ransomware. We must ensure proper resiliency plans and up-to-date business continuity and disaster recovery plans that are regularly tested.
Robert: I'm curious, over the last few years, have you seen increased emphasis on resiliency in audits and audit-related expectations?
Sanjay: Recently, cybersecurity has become one of the top ten organizational risks. Because of that, resiliency, business continuity, and disaster recovery are high priority. It's challenging because organizations often don't understand how much to spend on disaster recovery.
You need to assess impact through business impact assessment and implement controls accordingly. It's cost versus benefit - if your risk is $100,000 but controlling it costs $200,000, you won't incur that cost. You'll take the risk.
Robert: That makes sense.
Sanjay: But with regulatory requirements, you don't have that option. You must achieve compliance within reasonable cost.
Robert: Let's speak about zero trust. It's become a significant focus in our industry lately. Do you find it's possible to align change management principles with zero trust philosophy? Are they related?
Sanjay: Zero trust is a recent buzzword in this dynamic technology environment. The concept existed before - don't trust anything, validate everything, give minimum access. But now it's more emphasized and important.
In change management, we take a risk-based approach. We have different types of changes - emergency, standard, medium, and regular. Based on risk, if there's a critical change, we need zero tolerance, adopting the zero trust approach.
For example, if making changes to healthcare equipment or airplane engines, you can't trust anything - everything must be 100% perfect. Similarly, with cybersecurity risks in systems today, critical changes must follow zero trust approach - proper authentication, least privilege access, aligned with change management.
But again, it's risk-based. You implement controls based on risk because controls cost money. More risk means more controls. If your house has nothing valuable, you don't need a lock. If it has millions in valuables, you need a safe. For low-risk changes, you can have slightly relaxed controls. It's about balance between security and usability - too much control creates bottlenecks and operational overhead.
Robert: Let's switch to risk management. In many organizations and probably in your bank, you have ops team, security team, risk department, internal audit. How do you ensure alignment between change management practices and broader security and risk management objectives?
Sanjay: Current technology has become complex and collaboration is key. It requires proper governance because roles and responsibilities often overlap. Organizations need governance structure, clearly defined policies, and change management policies specifying who does what.
Change management has many stakeholders - security, IT infrastructure, operations, risk management, business owners. Define roles and responsibilities through documented, approved, regularly reviewed change management policies.
All audits examine change management policies, looking at implemented changes, success rates, failures, emergency changes. They look at how teams collaborate, communicate, document, learn lessons, and handle post-implementation review and closure.
These are key aspects of governance structure and ensuring change management process alignment.
Robert: It's a great answer and also a testament
to your political acumen because I had you navigate between multiple departments there with that answer.
So you mentioned documentation and it truly does play a critical role in risk reduction.
What strategies do you employ to ensure that it remains both comprehensive, practical and up to date?
Sanjay: Now, documentation is is a key challenge for small size and medium size organizations because documenting the key policies like change management policy on, say, information security policy or access control policy.
I see that organizations are struggling - they don't have the proper skill set to write policies or prepare their documentation.
In my view, there are some specialist consultants (I don't promote any specific consultant), but I think there are specialists who can help organizations. They should hire a specialist one time to get their policies, procedures and documentation in place. Then they can establish a process where, once it's properly documented and written, regular review and updates can be done by the organization themselves.
Poorly documented policy and processes will have a significant impact on how organizations follow critical controls. My suggestion is that key policies and critical policies should be written one time by subject matter experts, because it's not always possible for organizations to have that kind of skill set to write perfect policies and procedures. This is a big challenge.
Documentation is very important. If you look at key processes like change management, business continuity process and disaster recovery - it's all about documentation. If your first set of documentation isn't perfect, you cannot keep it up to date and properly managed.
My view is that you should get it perfectly done once, then set up and establish processes within the organization. Then you can regularly review, update and make sure documents remain current to reflect changes. It's easy to maintain if it's done properly the first time.
In mature organizations, they have a policy governance framework or separate team who manages all policies and procedures. They ensure documents are regularly updated, reviewed and approved. Many organizations lack proper structure around who will approve policies, who is authorized, who prepares them, who reviews them, and who approves them. Some main policies need senior management approval, while others require board approval.
As an auditor working with many organizations, I see a lot of awareness missing around this. I often find gaps in this area.
Robert: You know, there always seems to be confusion for some organizations on even what policies need board approval versus which can be internally approved policies.
Sanjay: Yes, and organizations struggle with determining which policies they actually need. There are so many policies out there - understanding which ones are required for them specifically. There's also confusion about the hierarchy: framework, policy, procedure, and guideline. It's a pyramid structure.
Standards and policies are mandatory. Procedures are flexible - you can choose different routes as long as you achieve the destination. But standards are configuration mandates, so policies must be properly written. People are still confused about frameworks, policies, standards, and guidelines.
In the technology domain or IT division, people often forget about documentation. Documentation remains an area with many challenges and gaps.
Robert: Well, you know, my final question is regarding security breaches. The IBM Ponemon report indicates that it takes an average of 204 days before an organization realizes that they've been breached. We find that's an absolutely concerning amount of time. How can a robust change management or integrity monitoring tools, like CimTrak, help organizations improve their detection and response capabilities?
Sanjay: This is very, very important question because if you don't detect the breach on time, then it's all this effort wasted if you don't detect on time. But we have to understand that most SIEM solutions and these things, they are detection tools, not prevention.
So along with the technology, you have to build the processes also properly. First of all, you need to configure these tools, the change management tool properly to understand what you want to detect. So changes how you detect the changes, how you detect changes in the critical infrastructure or critical file or critical area.
And then you have to have that your incident management robust incident management process. So as soon as you detect you have alert goes, you have a right process set up, who will address and then make sure that that alert which is generated or identified, it's properly addressed and risk mitigated to the acceptable level.
Because once breaches happen, only thing you can do is you can minimize the risk. So you can proactively if you have the indication of risk or indication of breaches happening. So if that is again, it's how you configure your tool, how we have processes.
You establish the processes and not only design but operating effectiveness also because you design the process very nicely, that okay, as soon as my file integrity manager tool detects there is some threat there is some incident. So it goes to, it identifies based on the rules you define use case or rule you define that okay. This rule is the incident.
So you define the process also. But then actual when incident happen and that process is not followed as designed, again there will be a delay in the same. So it is not one solution for it. It is complete end to end solution.
So to reduce breach detection time, you have to have, first of all, good solution. It should properly test it. It should properly configured. You have built the processes around it. You have an incident management. And you have a layered, layered security.
Nowadays we have a layered defense. So, sometimes you have, you can detect the change. If you have change management processes configured properly, you can detect in your file integrity management that there is some change. And this looks like that is some indication of data breach and something.
So you can integrate the FIM and SIEM also. You can integrate the different solution to be more effective. So it is about how you integrate the things with the robust processes based on again risk based approach. Because there are so many alerts, so many false positive also comes so you have to configure it properly so you get the right alerts. Right indication. Right change detection, unauthorized change.
Prevention is better than cure. To focus on more preventative before and then try to put a control. Then you can reduce the time to I think 204 days is for me it looks too much. It's a long time to detect a breach. If it takes 204, then I think we need to work more on it.
Robert: We feel the same way. You want to focus on taking that 204 days and shrinking it to just seconds. That's really our mission here at Cimcor.
Sanjay: Because it's scary. Just think about it. Too scary what they do in 204 days is scary. And it's no use of detecting that breach.
Robert: Yeah, that's a good point. At that point, what's the point?
Sanjay: Nowadays we are talking about zero days, zero day concept. So you have to detect within a few days because people will run away with the money and you will not find them.
Robert: Well, I mean, it's almost a misnomer because now your zero day is really a -204 days ago attack instead of a zero day attack. That's what it really is, a -204 day attack.
Well, this has been very insightful and a pleasure to have you on with us from Dubai. Thank you so much, Sanjay, for sharing your experience, knowledge and certainly your wisdom. I think you've given us a lot to think about, especially double downing on using that risk based approach as our framework for making decisions.
Not forgetting about scoping, embracing that usability is what it's going to take to help things stay sustainable as part of the processes in your organization. And of course, whatever you do, document it. Whether it's in policies, and make sure that they're up to date. So there's a lot to unpack here, but a lot of great advice that I think our audience would love to hear. So, thank you so much for your time, Sanjay.
Sanjay: Thank you very much for giving me this opportunity to share whatever knowledge I have, and I hope this is useful because I believe in practical approach. As an internal auditor, I have learned two things: risk reward and cost control. I always say that you look at the risk and you look at the reward. How much? Because every control is a cost, and you can keep on spending money on controls. But we have to look at how much risk you are protecting through spending that money.
That is why risk assessment is an area where I still feel that proper risk assessment is not being done. If you assess your risk, then it will be easier for you to decide how much risk you have to, how much control you need to put. But risk assessment is the area where most organizations struggle to do it right.
I always keep on saying that - assess risk assessment, assess your risk. Unless you assess your risk rightly, you're not going to control it.
Thank you very much for giving me this opportunity, and I hope this helps. And I am more than happy to leverage my experience and share my thoughts on any of these topics.
Robert: Sage advice, ladies and gentlemen, Sanjay Shah. Audience, if you have any questions, reach out to us or reach out to Sanjay. Thank you so much.
Tags:
Podcast.png?width=50&height=50&name=Kayla%20%20(1).png)
February 7, 2025
