A look inside the process: How to ‘shift left' security and compliance in financial services

Financial services companies—from global banks to emerging fintechs—face significant pressure from all sides when it comes to their digital products and experiences. 

Consumers want a simple, seamless, and secure experience. C-suite and product leaders demand accelerated speed to market, high quality, and differentiated products and releases. Regulators are heavily scrutinizing for compliance with requirements and appropriate controls.  

The result? In most cases, it means a stressful software development and security compliance journey marked by colleagues that feel more foe than friend, the implementation of ineffective controls, and a lack of visibility across the organization. 

But financial services companies don’t have to accept this as a norm.  

By incorporating the concepts of “shift left” to the organization and the software development life cycle (SDLC), those same customer, leader, and regulator demands can go from competing to complementary.

At any given moment, a financial services company may be updating or developing hundreds of applications. So, when a company is continually receiving audit or exam findings around products or applications, it can range from disruptive to debilitating.  

This was the issue one large bank was facing when they called West Monroe. We were asked to evaluate a suite of products under the organization’s technology office to understand the root cause of the findings, how current findings could be resolved, and how to proactively identify and solve the issues in the future. 

The audit findings were causing major business challenges. Engineers and architects were constantly focused on putting out security and compliance fires rather than on planned development—creating inefficiencies and delays.  

Through a multidisciplinary approach that brought together the product owner, architecture, engineering, risk, and security teams, we developed a more optimized and secure process that reduced audit findings and improved quality and speed to market. Here was our process: 

1. Assess end-to-end process controls

The company was aware of some of their challenges. But we understood the importance of stepping back and analyzing the big picture any time a breakdown occurs in one part of a process. 

In this case, it was clear that the company had a control applicability problem. Security audit findings right before launch were creating unplanned and distracting fire drills for engineers. This slowed down the process and created organization-wide tension.  

By shifting testing left—or earlier in the process—security and engineering teams could align early and reduce major headaches and delays. But it’s easier said than done. 

2. Align leaders and teams 

C-suite and department accountability are critical, but too often one department’s goals appear—or actually are—in conflict with others. 

This was the case here. Business leaders were looking to complete releases and enhancements quickly, but compliance teams were tasked with protecting stability and security across the organization by leveraging restrictive security controls—often pushing out deadlines or launches.  

In fact, we often hear of the destructive friction between engineers (whose job it is to build) and security teams (whose job it is to test or even break in some cases) breeding distrust. 

Fixing this begins at the top of the organization. The CTO and product owners should not only be aligned with the CIO and CISO but also have an understanding and empathy for each other’s challenges. Friction between teams should ultimately be constructive—leading to a better work product. 

From there, it’s critical to ensure visibility. The bank’s executives wanted to avoid surprises, and the best way to do that is with open lines of communication, multidisciplinary teams and partnerships, and clear reporting. 

3. Add the right resources at the right time 

Once there’s alignment at the top, the next step is building a multidisciplinary team. 

In the bank, this meant creating a new organizational model to embed security experts and security minded developers into the product team.  

The idea is simple: When people with different areas of expertise work side by side, they’re likely to absorb each other’s knowledge and appreciate the challenges that different teams face.  

The product team hadn’t understand the controls—they questioned the value and weren’t given the flexibility to work outside of a strict set of parameters. Now, when the product is being designed, the business and security perspectives are embedded in product team and can be built into the design from the onset. 

We also brought in specialists with knowledge of complex regulatory areas to consult and help product teams meet rules and requirements. 

4. Create new controls 

The bank faced a few critical issues related to their controls. In addition to a lack of understanding on the value of controls, some controls had been “over-automated,” which led to a check-the-box approach and complacency.  

On the flip side, the company needed to establish new and updated controls that aligned with their new offerings and emerging technology. Even the best engineers aren’t experienced with applying controls to emerging or modern technology. How could they be? There’s no roadmap or policy to rely on, so it’s critical to seek outside expertise or help.  

5. Integrate controls into the product 

Once controls are established, it’s critical to embed them into the design from the beginning and not think about them as an afterthought or security problem. 

In discussions with the bank, we learned that some controls were so rigid, engineers learned over time it wasn’t worth a fight to suggest alternatives. They would check the box and move forward instead of understanding the security objective and working with the security team to modify the control to align to the new technology.  

To rectify this issue and begin breeding wider ownership of security, the bank established a control framework by enabling an approach that leverages guardrails instead of overly prescriptive controls. Controls are then implemented as policy-as-code to ensure the right controls are in place, active, and compliant. 

They enabled better and faster compliance visibility by integrating controls governance, risk, and compliance (GRC) tooling to monitor, audit, and report continued adherence to regulatory compliance.  

6. Understand your risk appetite 

Every company will need to determine their appetite for risk and where they have to be rigid vs. where there’s flexibility.  

A more agile controls process keeps guardrails or third-rail protections firm but allows for flexibility in runtime policies that cascade across the organization.   

The rigid areas of a bank may be tied to fraud or security risks or areas that impact capital markets. For other financial services companies, it could be related to fiduciary duties or data privacy. The point is that if everything is a priority, nothing is a priority—and both engineering and security teams need to be in lock-step on what the true red lines are.  

Where can shifting left lead your organization?  

For the bank we worked with, the benefits were clear: increased speed to market, healthier and happier teams, reduced risk, and more loyal customers. But these processes also create lasting value that builds and scales over time. 

While every financial service organization is different and will see benefits and changes specific to their unique needs, there are three consistent outcomes you can expect: 

Risk identification and solutioning: Preserving value and avoiding costly adverse findings are made possible because of the developed ability to know what risks you’re facing, their size, and where they are. Being able to initiate proactive resolutions in real-time—without disrupting other priorities—should be the new expectation. 

Embedded proactive risk management from experts: Having this proactive risk approach embedded into organizations—with a board of security and compliance experts to serve as the foundation of daily operations—can help situate and direct the organization to be better able to flag or prevent threats in real-time without conflicting interests. 

Defined digital strategy, design, and build: When you need to integrate new or cloud-based technologies, design and build security guardrails within the process to mitigate risk and support your digitally-forward operating model and compliance program. This can be developed hand-in-hand with the team of experts leading the proactive risk initiatives.  

How to begin shifting left 

In a highly regulated industry, it’s important to be pragmatic. 

Benchmark yourself against peers your size and in your industry. Netflix is often held up as a best-in-class example for releases, but the Netflix SDLC model shifts right on security. Their “deploy fast, fix later” approach doesn’t work in financial services because the security profile of the product and customer base is entirely different. Determine the best-in-class model that suits your company’s unique stakeholder needs and make progress toward that end state.