#compliancecorner – 370 Security Blog

Exploring The Advantages and Disadvantages of Centralized vs. Decentralized Teams

This blog post is part of the Compliance Corner Series developed in partnership with Milan Patel. This series includes a variety of discussion topics around the intersection of security and compliance. The series includes blog posts, live web streams (with Q&A) and podcasts.

What is more effective – A decentralized or centralized security and compliance team? What are the factors you need to consider, what are the pros and cons of each model, does company size matter, are they simply analogs of organizational maturity or should leaders consider one model over another model for their org?

When leaders are creating or maturing their organization should they consider a centralized or decentralized organization structure?

Lee: If you have the opportunity to create or modify your organization I personally prefer a centralized organization structure. This is because it concentrates the roles, responsibilities and authority for security into a single function that can offer governance and all of the additional expertise expected of a security organization. The rest of the business knows where to go and who to talk to for all security issues. I have seen problems arise in both decentralized and heavily matrixed organizations because it confuses the roles and responsibilities of the function. Who is actually responsible for making security decisions if major parts of security are spread out across the organization? Sharing resources doesn’t really work very well because it is confusing for the individual team members and when sharing resources one side typically loses out to the other side. I have also seen shared resources get mis-used or repurposed for things other than security. This doesn’t mean the security team can’t place resources in different parts of the org, but they should report into and be owned by the security function. In my opinion whoever is responsible for the budget and the headcount truly controls that resource and decentralizing the budget and headcount causes problems.

Milan: Business leaders must first consider what role they want their compliance organizations to have. Will their compliance team actually offer governance, or just auditing? Are they going to cover corporate policies, or just audit frameworks that attest to customer reports? These are important scope questions to answer before setting up (or maturing) a compliance organization. It can drastically change how you fund and scope skills for the team, and whether a decentralized team will meet the overall risk management and corporate goals.

Investment size must also be considered, I get that question all the time, “How much should a business invest in compliance?”. I have seen everyone from flat personnel-project based funding, to actual percent of overall business operations spend. I focus on scope first, as then you can directly cost out what the deliverables/responsibilities are. Governance will drive a big factor of centralized or decentralized teams. Governance requires authority, charter, and appropriate level of independence to actually hold teams accountable. In a decentralized model, governance becomes much more difficult, as the fox ends up guarding the hen house.

Does company size, organizational maturity or other factors influence the decision to have a centralized vs. decentralized organization?

Lee: Company size can definitely influence the initial decision to create a centralized or decentralized function. Smaller organizations or startups may not be able to justify the initial cost of a dedicated security leader and may lump this responsibility under the CIO, CTO or Chief Counsel. As a result the security function may initially grow as a decentralized function until the organization decides it is either time to offload the original leader or they realize they need more specific security leadership and it is time to build out a dedicated function.

Organizational maturity can also impact the decision. Immature organizations may struggle to effectively use decentralized resources and so the weaker the organizational culture the more a centralized security organization will make sense. However, in really large organizations it is common to see a hybrid approach which I like to call a federated model. In a federated model you have a centralized security organization that sets policy, governance, manages risk, makes decisions and has all the authority for anything security. Business units within the large company then staff specific security resources based on expertise for specific industries or to help navigate their specific security and regulatory requirements. This can be advantageous in terms of presenting a single view of overall risk, consolidating processes and leveraging economies of scale for purchases to get a better price for tools or contracts used for security across the organization.

Milan: Company size, and breath of products, can definitely influence the model. In smaller companies, there will likely be less resourcing (and complexity) to consider, which makes a centralized model more affordable and practical. You are not going to have much ability to fund a larger team (and wouldn’t likely need it), so a centralized model pretty much is the only option.

In larger companies, decentralization is used (and we’ll talk about advantages and disadvantages later), but the better model is hub and spoke. A strong central team, chartered with governance, but small “spoke” compliance teams that are the boots on the ground in the team. Small presence that can keep engineering on track, participate in design reviews, threat model reviews, and know enough to ensure that engineering teams and products are on the right track from the start. They also can drive best practices for that team, but they are based on the central team requirements, and can escalate to the central team (that ideally has a governance charter) to ensure adherence at the right senior level.

What are the advantages and disadvantages of each model?

Lee: Centralized models offer consolidation of budget, resources, governance, responsibility and authority. It presents a single function that the rest of the business can go to for anything security related. Centralized models are typically more efficient because it avoids each group having to create and duplicate resourcing, tooling and processes. The one downside of a centralized model is if the security organization forgets that the rest of the business is their customer then it can become extremely difficult to interact with that group who effectively becomes a gatekeeper for business progress.

Decentralized models can offer some initial advantages when companies are extremely small. This is typical during startups or when you are operating in a mode where everyone is doing a lot of different jobs. However, this usually isn’t sustainable long term. I also find people who operate in this mode usually can’t scale to a larger organization where more governance is required. Decentralized models are also more prone to duplication of resources, technology and processes because there isn’t a single leader coordinating strategy and investment. Decentralized functions can also run into problems where the resources are misused or go “native” and stop performing the intended security role. Decentralized functions may end up with different levels of maturity across the different groups in the organization, which can make it difficult to obtain compliance certifications or to standardize processes and technology for a unified approach to security.

Milan: In general, a centralized structure offers the best overall coverage and governance. You can set consistent policies and practices across multiple organizations, which inherently will reduce risk as it’s easier to ensure consistency, and accuracy with one process vs many. You also can provide more controls to validate continuously that processes are working, plus attest much easier. Continuous compliance in a cloud environment is basically the norm now, but not all organizations, especially those with a decentralized model, can effectively ensure compliance of many regulations that come in and now must be enforced at the corporate level, and not just at the product level.

You also reduce cost, as having one set of compliance experts is cheaper, and can provide more optimization of skills. In a decentralized model, you end up having to hire more individuals, as you must replicate specialized skills in multiple areas.

One aspect that is often overlooked in centralized vs decentralized is pricing power. For compliance, for instance, you can collective bargain auditing to drive better prices in a centralized model. In a decentralized model, every team is determining it’s own bidding and metrics, which basically allows for suppliers to cost every team as individuals, reducing the overall negotiating power of the company. In a decentralized model, you usually also have more junior leaders (as the team and overall scope is smaller), and that dilutes the overall governance credibility, as they are not truly objective, as again, this can give the impression of the fox guarding the hen house.

Is there a clear winner here or is this more of a dogmatic approach / “it depends” type of answer?

Lee: Obviously there is always an “it depends” type of answer, but I personally think a centralized team offers far more advantages than a decentralized team. I have operated in decentralized teams, startups, and heavily matrixed organizations and they have all had incredible inefficiencies, process problems, lack of technological standardization and contention between the leaders in control of the different resources. While anyone can demonstrate leadership, the reality is there can only be one leader for a function. If you want to build a strong and effective security organization my personal recommendation is to avoid the decentralized model and strongly advocate for a consolidated, centralized function for all of the reasons I listed above.

No matter what size your company is, at some point your business will get big enough that it will either need to transition to or will need to build a centralized security org. Even when your company gets truly massive a centralized security organization will offer tremendous advantages for coordinating the rest of the functions across the business. This doesn’t mean you can’t have specific expertise embedded within the different lines of business, but there should be one overarching function that sets strategy, governance and has the authority to coordinate everything related to security across the organization.

Milan: I am going to lead off with a “it depends”, but “it depends” on what the SLT wants the function of the Compliance team to be, and how they want them to operate. For example, if they want what they “should” want. Corporate SLT should want an independent compliance organization that has the charter and weight to actually drive governance and accountability. Any decisions made by an engineering leader where the compliance team reports directly to them will be suspect if there is an issue, as how can compliance be seen as impartial if the decision can be overturned by the product or engineering leader directly? Did the right conversation happen, does that decision align with similar decisions with other product groups/lines of business? It can be a real problem if there is an issue and companies have to explain.

That is very difficult in a decentralized model. In a decentralized model where the compliance team, which has to drive hard messages and needs to engineering leaders, are they truly independent and will they speak up, as they tend to be mostly more junior, without any real organizational or peer power with the teams they are supposed to govern? The answer I’ve seen is rarely. I’ve seen and worked with many compliance teams that are frankly afraid to raise issues, or particularly escalate (and if they would escalate, who would they escalate to, as it would be their own management that signs their pay stubs). I’ve seen it both on the compliance and security side, where even mid level leaders will not raise or push issues, as they are worried for their jobs. It’s very difficult to find compliance teams and leaders that can truly be “politically unencumbered” in terms of raising issues, when they report to the fox that likely already doesn’t like having to do compliance work.

I believe that a strong and chartered central team, made up with the right personnel that understand engineering and can translate, and govern engineering compliance practices is the overall best option, particularly for larger organizations where standardization and efficiency must be improved. In a large company, compliance “spokes” with specific charter are important, as it’s the only way to scale the appropriate knowledge down to the teams.

Compliance Corner Series: Building A Successful Security & Compliance Program

What are the primary factors, considerations, and challenges that a security leader needs to consider to build a successful security and compliance program?

If you were starting a security and compliance program from scratch where would you start?

Lee: I’ve written about starting security programs from scratch in past blog posts, but in my opinion a security leader needs to first select what security controls framework they want to use to inform their strategy, initial assessment and planning. It is rare that a security leader will enter an environment that has zero security and so my suggestion for any leader is to conduct an initial baseline assessment for how well the organization is meeting the security controls within the framework they select. Two of the most popular security control frameworks in the United States are the CIS Top 18 Critical Security Controls and the NIST Cybersecurity Framework. Both of these are excellent frameworks that cover everything a comprehensive security program needs to have along with a recommended prioritized order. It will be difficult for a security leader to start a compliance program without baselining and mapping their environment to a security controls framework because this is the equivalent of never practicing a sport, yet going out and trying to play in a game. Security is the practice and discipline that sets the foundation for successful compliance programs i.e. the sport you are playing. Your security strategy will inform the what skillsets you need to hire, what tooling you need to build or buy and what processes you need to establish to make your security program successful.

Once you have selected a security control framework and have a strategy in place, my recommendation is to then evaluate your business for the markets it addresses, the geographic regions it operates in and the customers or partners it serves. This will inform your compliance team what compliance frameworks and audits they need to consider to make the business successful. For example, if you are a consumer based business and process credit card payments, then you will need to plan to comply with and pass a PCI-DSS audit or if you plan to serve the U.S. Federal Government you may need to achieve some level of FedRAMP. Understanding the business drivers, customer demand and regulatory environment is extremely important to setting up a successful compliance program that enables the business.

Milan: I definitely agree that you must start with a baseline assessment of where you are, but also with what your business goals are. Are you going into financial spaces and require SOC1 Type 2? Do you want to baseline your core expectations with SOC2? What about healthcare, HIPAA anyone? We won’t even get into FedRAMP if you want to sell to government agencies, so I suggest that you need to really understand, and baseline, your business goals in terms of verticals, industries, even governments/regions you want to sell into. The compliance leader will need to balance out these requirements (including privacy, accessibility, etc), to ensure that for whatever region/country/industry you want to go into, you can cover the core baseline controls.

Once you have that, you need a way to track and ensure you can meet those controls. Like we talked about before, and as I talk about now, integrating this with engineering and the appropriate metrics are key. This includes how to “pre-audit” your services for new frameworks/certifications so you can minimize issues during an actual audit. If you don’t do this from the start, retro-fitting it in after the fact is difficult and costly.

You also then need personnel that understand these controls and requirements, and importantly how to translate and negotiate these with engineering. If the people you hire cannot do that, then you fall into the same old challenge of friction between engineering and compliance that introduces risk. Having the right personnel that can translate and bring harmony among the pillars required for compliance (compliance, engineering, security, and operations) will be key to standing up a successful compliance team.

2. What if you inherit a security and compliance program that has been established by your predecessor? What advice do you have for leaders when adopting and continuing a program established by someone else?

Lee: Congratulations if you have been promoted or landed a new role as the leader of a security or compliance program! In my opinion the fundamentals don’t change whether you are starting a program from scratch or inheriting an existing program. I think it is critically important for a leader to baseline and understand what is already in place, what gaps exist and then build their strategic plan to address those gaps. The big difference when you inherit a program is it may take longer for the business to shift priorities towards the new plan due to organizational momentum and budget cycles. Technologically and practically, it may not actually take that long to do the things on your plan, but psychologically the organization will need to adjust and adapt. This means you will need to spend more time building alliances, getting teams on board, changing processes and shifting the culture to support your new vision. Keep in mind that closing the gaps in security control frameworks or compliance activities may take a significant amount of time because the organization may need to procure new tools, hire new talent or create new processes to satisfy a specific control. This has a knock on effect to your compliance program because most compliance audits have both readiness audits and the actual audit themselves. Both of these can take months to complete and so expectations need to be set for timelines, critical paths and when objectives will be met. If the business is expecting to get FedRAMp or HyTrust overnight, that is unrealistic because there are robust processes and timelines that need to be followed to pass those compliance activities.

Milan: I still agree that it doesn’t really change much from standing up a new compliance program, other than you may have a bit more work to change the culture from bad practices to new ones. The key is still to align your compliance strategy with engineering goals/metrics. Inheriting a program that doesn’t align to engineering requires immediate attention, as until you can align it, it will be difficult to help the cultural and behavioral changes needed to more closely align priorities and drive the actual execution.

As you say, it will likely still take time to close gaps, hire individuals, build tooling, but if the actual metrics and success criteria isn’t aligned with what engineering will need to have to actually change priorities, then most of that work may become “wasted” as while it may get you through a single audit, it won’t be efficient or at scale. I would still suggest that new compliance org leaders take a deep look at how the compliance team articulates and aligns success metrics first, before doing anything else, and change/align them to engineering first otherwise they will continue to have friction, and risk, with executing the compliance programs that require engineering (or even operations and security) changes.

3. What challenges can a leader expect to face when building or maturing a security and compliance program and what advice do you have to overcome these challenges?

Lee: There are a few challenges that I have run into over the course of my career. The first challenge is mis-alignment of expectations between stakeholders. This could be a mismatch from the board, from other C-Suite executives or from the rest of the business (like sales). In these cases, it is imperative for the security leader to work closely with these stakeholders to align expectations. You are the expert in this field and you need to help these other leaders and teams understand what good looks like and when they can expect to achieve it.

Expectation mis-alignment is also closely related to cultural mis-alignment. For example, if the technical culture is extremely permissive and allows teams to do whatever they want, then the security leader will need to spend time explaining the advantages of increased security control and how that can actually accelerate the business, while reducing risk. Culture mis-alignment is often the biggest challenge I’ve run into over the course of my career and it can be very time consuming to fix. Security leaders are often brought in to improve a security program, when in reality the culture is at issue. This often means the security team becomes a cultural change agent and they cannot change the culture alone. Security leaders will burn out or leave extremely quickly if the culture is not aligned and they don’t have the support of other executive leaders to achieve the security goals specified in the security strategy.

Finally, one of the other issues I’ve run into is budgetary. This can come in two forms – first, the security team struggles to get appropriate funding and second, the business insists the security or compliance team performs activities that may not actually make sense financially (like achieving a specific compliance audit). The first budgetary issue – not getting appropriate funding can be a real problem for the security team if the business arbitrarily cuts budgets instead of choosing to fund the security team based on risk. This funding issue is closely related to a mismatch of stakeholder expectations and a cultural misalignment. The second budgetary issue is often an issue between sales teams and the security and compliance team. Often, the sales teams insist a specific security control is necessary or a certain compliance framework is required in order to exist in a certain market or achieve a sale. While this can often be the case, it is important the security leader has the support to be able to push back on these requests where it makes sense. If a security and compliance activity is insisted on by the sales team, I always require a minimum threshold of business to cover the cost of the control and compliance activity. This should be written into the sales teams number, tied to their comp and ultimately they should be held accountable for justifying the need.

Milan: I still think the biggest challenge for compliance leaders is building credibility. I talk about how leaders look at all companies as “making money, saving money, or costing money”, and compliance has always been put into “costing money”. So how does a compliance leader build their individual and team credibility with the engineering teams (the main control owners), that they are just not a pain in their collective engineering sides “costing money”?

Compliance leaders must start from the beginning showing engineering how they are “helping them”, which mainly to me is “saving money” (engineering/operations/security time). Time is the key metric that is tracked by most engineering leaders (sprint and engineering time), so it’s incumbent on compliance leaders to show them how they are efficient, or even saving time based on their previous compliance experience. Compliance leaders must be able to show, on paper with metrics, that the compliance work is efficient (I use first time resolution as a critical metric), and how we continuously drive for the ultimate metric, of removing engineering completely from the evidence collection flow via automation, etc.

If you cannot build that trust, then you will always just be a leader that doesn’t understand the engineering priorities, cost them money (i.e. time) by being inefficient, and having no credibility and influence as they have no real reason to engage with you. It all starts with the ability to develop and agree on metrics that actually help engineering minimize the time it takes to do auditing/etc, and providing that value back to the actual engineers.

You get risk mitigation by default with the right metrics, as the evidence is clear and concise, and once first time resolution is high, you can now automate it. We have seen that the risk (and the deviations) have gone way down as we negotiate and approve with external auditors the evidence that will pass that QA for review, we have less “drift” with bad evidence, which reduces overall risk (and actually increases predictability and timeliness in audits).

I also believe that the requirements “accepting” of new frameworks requires a much more detailed review and acceptance than I’ve generally seen. There is no point gaining new certifications if sales doesn’t have a solid plan to get the ROI with customers. It’s costly to go through the certifications, and without appropriate sales to support the cost, it can become wasted work. If the cost/benefit numbers and plans for sales are good, then it becomes much easier to justify the compliance work. Also, if the success metrics and tracking of workload for compliance is also detailed, then justifying resourcing for new projects becomes easier. Compliance teams must continuously run compliance “like a business” being able to show metrics that detail out the work, down to the team and individual level, otherwise justifying new resources becomes challenging.

Compliance Corner Series: Compliance Landscape 2023

This blog post is part of the Compliance Corner Series developed in partnership with Milan Patel. This series will include a variety of discussion topics around the intersection of security and compliance. The series will include blog posts, live web streams (with Q&A) and video blogs.

“How has globalization, increasing regulatory requirements from governments and industries change how Security and Compliance must operate internally”

Growing Regulatory Requirements – Impact To The Whole Company vs Single Business Unit

Lee – From a security perspective, it is difficult to standardize security controls and baselines across the whole company vs. a single business. Business lines have different requirements, customers and industries, which are unique to their product lines and customer base. Mandating the entire company meet a global regulatory requirement (like PCI-DSS, FedRAMP or HIPAA) can be costly for those lines of businesses that don’t have customers in those industries where these regulations apply. While the security program may be effectively managing risk for their particular line of business, the difference in regulatory requirements can lead to gaps in customer expectations across product lines or lines of business. It can also be costly to maintain compliance programs since you typically have to audit and produce evidence for each product. This puts a burden on development teams and can take time away from improving the security of their products, vs. generating sufficient evidence to pass audits. For smaller lines of businesses this can be difficult to justify the cost to keep up with global regulations, certify audits and maintain levels on par with the rest of the company.

It is possible to centralize compliance activities across the company, but it also requires every part of the company to standardize their security controls, risk management practices and reporting principles. This may work well for small to medium sized companies that have grown organically or who have done a good job of homogenizing their organization. For larger organizations that have grown via acquisition and have dozens of lines of businesses and product lines, centralizing compliance and security activities may be impossible.

Milan – For compliance, the issue is that many of these new requirements have no “corporate” baseline expectations. They have not been translated (and sometimes agreed to), by individual lines of business. Without a standard “bar” to execute against, it’s very difficult for individual compliance teams to attest that it’s being met. In many cases, these items have no tests, or have not even been implemented. It becomes a real issue at scale, as these are yet another new compliance item that engineering will have to meet, which will continue to compete with their feature development time requirements.

My experience is that it’s challenging for many of the central compliance/legal teams (that try to set these requirements for engineering teams), from both a positional authority, as well as a credibility perspective. There are few engineers on these central compliance teams that are experienced with translating these regulations to actual engineering practices. Also, there is a lack of organizational authority to enforce it uniformly across all business groups. This just increases the challenge as it adds more time to negotiate and drive priority, especially with the speed of these incoming regulations.

2. Security and Compliance Practices – What Has Changed?

Lee – For security, there has been an increasing trend in transparency as well as a reduction in time to fix security vulnerabilities and report security incidents. Often these regulations or new compliance practices have good intent, but will be so costly to implement that they are impractical or are technologically impossible. These problems are further compounded by modern software development practices like DevOps that move incredibly quickly and can amplify deployment of internet scale products across cloud providers. Software supply chain security and reporting for compliance reasons is particularly challenging due to the complexity of modern software libraries that have multiple interlinking dependencies. Third party libraries and open source software is even more difficult because you don’t always know if you can trust the source code of that library. Providing an accurate software bill of materials (SBOM) can be a significant burden on the business to develop and maintain for compliance reporting purposes. Additionally, the priority of the business can sometimes take precedence over other activities like solving tech debt or modernizing technology stacks. Technical debt can not only hold back the business from optimizing and becoming more efficient, but can also make security and compliance activities challenging.

Milan – I’ve been doing this for a long time, on the engineering side with a large multi-billion dollar software product, and more recently on the compliance side across many products. What I can say is that while engineering has changed… DevSecOps, updating features/software monthly, instead of yearly… or even every 5 years when hardware went “end of life” (yes, I’m totally aging myself here), compliance practices basically have not changed internally.

Even major companies are still trying to “throw money” at the problem. The internal compliance teams know that the SLT has to pay for compliance… but I believe the days of the compliance “bat” and “blank checkbook” are gone. It doesn’t scale. I will never get more bodies to manually collect and review evidence for large amounts of controls and services (and not regulatory requirements) that we will have to test and account for. Spreadsheets and email won’t work anymore. Compliance needs to change, and be run more like a business. Even the third party auditors didn’t have incentive to be more efficient… remember, they mostly bill hours… So the more inefficient and longer it takes for a company to do an audit, the more money they make. We’ve changed that quite a bit at Oracle, but it’s still early in the journey.

3. Looking Ahead: How Must Security and Compliance Practices Change?

Lee – For security, teams need to shift to a continuous compliance model. Instead of periodically assessing the business once a year (or some other interval) teams need to implement security controls and reporting mechanisms that can automate and continuously evaluate how the security controls meet the various regulatory requirements required for the business. By moving to a continuous compliance model it will force the business to modernize their Software Development Life Cycle (SDLC), modernize their technology stacks and resolve technical debt, which will ultimately benefit security programs. A continuous compliance program will allow security teams to tackle security at multiple points across the technology stack. First, it will evaluate, report and control how software is written. Second, it will evaluate, report and control how infrastructure is deployed and third, it will evaluate, report and control how security posture changes over time so teams can react to security drift.

Security and compliance practices must also change by holding the rest of the business accountable for their decisions. It is impossible for a security or compliance team to be successful without support from the rest of the business because the security and compliance teams don’t “own” the infrastructure and products the business uses to make money. Therefore, there needs to be support at the highest levels of executive leadership to hold the lines of business accountable and tie performance and incentives to how these businesses satisfy their security and compliance requirements.

Milan – Well, I think it must happen on two levels. First level is central oversight and governance.

Without a strong central compliance function that can translate, and negotiate requirements, enforce and govern equally with the engineering leaders, it won’t scale effectively. The main challenge now is that the “fox is guarding the hen house” so to speak. When the engineering team compliance is solely under engineering leaders in the product group, there is the ability (or even just the appearance) that decisions are made without compliance “equality” of decision making. If a compliance item isn’t resolved, who questions whether that amount of risk is acceptable to the senior product leader? Even if accepting the risk is “OK”, any external party can question whether the right level of compliance leadership made that decision, and not just an engineering leader who may prioritize compliance lower than say… a feature request.

This mostly only becomes an issue after the fact. A compliance issue happens, then the questions of “Who made that decision… why was that compliance issue not escalated… etc? Escalate to who? While it’s a great idea that a compliance leader (buried usually multiple levels down in an organization), will be “politically unencumbered” and rise up and strongly disagree with an issue with their senior leader (who by the way signs their checks). My experience is that it can be difficult, as being seen as an antagonist is not great for one’s career in this space. I’ve noticed that compliance positions that have high turnover, this has been one of the main indicators of how effective the compliance leader is in the organization feels they are. If they feel they cannot speak up, or they do and are dismissed “for higher priorities”, they feel they are not effective, or will become the scapegoat if there is an issue.

The second level is that compliance needs to change their success metrics, and run like a business.

Most senior leaders I know, including myself, put everything into three buckets… You’re making money… saving money… or costing money… Compliance has always been seen as “overhead” and costing money. Even today, I’ve had to battle that, until we made some major changes in how we operate, and what metrics we track for success. So the question is, if I’m always seen as “costing money”, how do I change that, and what do I change it to? I realized that while compliance does “make money” (new frameworks open new markets), I don’t really get to claim that. I’m not out there hustling deals… So I realized years ago I could “save money”, but not in the traditional sense. I had to change my compliance principles and metrics. First, everyone accepts that compliance is important, but why did they hate it so much? As an engineer doing this on a large project, the compliance team never understood that my metric was “completing the audit” or “collecting XXX number of evidence pieces”.

My engineering metric of success was TIME.

As a development operations, release manager, and development compliance owner for the large project, I only had so many engineering hours, so I needed to minimize time I spent on each engineering function, including compliance.

So in compliance, I changed the success metric to First Time Resolution (FTR) for audit evidence. Everyone knows you have to collect at least one, but we had so many “kickbacks” for many reasons.. Either the engineering team didn’t provide what was asked for, or the evidence instructions were incomplete or unclear (remember what I said earlier for “billable hours” from the auditors)? I put at least 30 min per kickback. I used to own 1000 pieces of evidence, sometimes I could resolve them in 5 min, sometimes it took days. By raising the FTR up to a goal of 95% (makes it through the first time), I can show, on paper… how much money I’m saving the engineering team (in time). I was able to show this year, saving millions of dollars in audit costs (by going with an efficient auditor, that didn’t bill me for all those hours), and saving Tens of Thousands of engineering hours by eliminating the “unplanned work” of kickbacks.

By changing the metrics to what the engineers care about, it built trust and transparency, and increased the overall value of compliance, plus their willingness to look for more efficiencies.

Needless to say there are a lot more details to talk about for the journey to get here, but the engineering leaders saw, with hard metrics, that compliance “saved money” (via time) for them to use on other features, bug fixing, etc. And more importantly, it built trust with them that the compliance team was a good steward of their currency, which is time.

4. Where do we go from here?

Lee – Milan, it’s been great discussing how we evolved to this state, and some great ideas and positions on what has to change in our respective security and compliance areas. There is so much to discuss here I’m looking forward to continuing this series to dive into topics around the intersection of compliance and security.
Milan – Yes Lee, it’s been great discussing these topics. For me, I feel like this is the beginning of another Industrial Revolution for Compliance, we have seen the change in the engineering and globalization, and we’re on the verge of revolutionizing the Security and Compliance space. We didn’t even really get into the overall governance and continuous security/compliance versus point in time. Maybe that’s the next discussion!