Yosef Levine

My name is Yosef Levine. I'm from the East Coast region of the United States, particularly the New Jersey part of New York. I've been with Deloitte for 20 years. I'm a financial auditor by trade. I've taken many companies public, worked on a bunch of retail and technology type of audits of companies that you're very familiar with. Over the past six or seven years, as a global audit business, we've gone through a significant transformation of how we deliver services to our clients, really rethinking about our entire service delivery capabilities in terms of people, process, and the technology that enables us to do what we do. In my current role, I'm deeply involved in supporting that transformation at a global level.

I'm responsible for all the technology controls, confidentiality, and privacy for all of the technology we use to serve all of our clients at a global level for Deloitte. And here with me today is my esteemed colleague, John.

John Waters

Sure. Thanks, Yosef, for the introduction. I'm John Waters. I'm an associate director with Deloitte Global, leading cloud architecture for the global audit and assurance function. And as Yosef's mentioned, he's my partner in crime here as we've taken a journey to bring audit to the cloud, which has certainly been an interesting journey given that audit historically can be viewed as a bit of a risk-averse organization. It's been a lot of fun for us over the past few years, taking the organization on that journey to the cloud, and we're excited to talk to you today about some of the things that we've seen that have been really key to support that journey with both balancing DevOps and controls as we made that journey.

Yosef Levine

And being a financial auditor that's somewhat more digitally savvy, it helped it from my perspective. I was able to influence our leaders and our colleagues to understand the value proposition of the cloud and DevOps early on, being able to articulate that appropriately with John and others from a technical side. When we started out, and this is a story we like to tell, four or five years ago, we couldn't call it the cloud. We had to call it a hosting platform. People were scared of the cloud. Thank you, Amazon. Thank you, Microsoft. Thank you, Google, for your marketing dollars in airports. Cloud is no longer a dirty word. We could say it and be very forthright.

But that's just an example that we had internally. We were scared that cloud is a dirty word, and it would scare our clients. And fast-forward three, four years, five years, perception has changed. And like any organization that's going through a transformation, we have to innovate, otherwise we're not going to be a going concern anymore. We're not going to exist as an audit business, as a professional services firm, or whatever organization you're associated with. So being able to embed that culture of courage, knowledge, and build up confidence and not being scared about trying something new, we've been doing that together hand-in-hand with a lot of others that have really helped us go on the journey.

So, let's dive into it. We want to keep some time at the end to have an open dialogue, maybe five minutes for questions. We're going to be back here after lunch, where you guys could ask us anything you want. Okay, we're auditors. I'm an auditor by trade. We didn't have all the answers. The answers that we have today to manage our risks from a security standpoint or from a data privacy standpoint, we didn't necessarily have those same answers six months ago or even three months ago. The technology changes so fast that you have to understand what your principles are and what your standards are and be able to adapt appropriately and take a lot of others on that meaningful journey at the same time.

So John, should we go straight in?

John Waters

Sure, let's dive right in. Thanks. So let's talk a little bit about the journey that we've been on to enable transformation through DevOps, as well as partnering through controls along that journey here. When we started out that journey a few years ago, we looked at the challenges of historical hosting and operations with a new way to do it in the future through cloud-based hosting as well as DevOps practices. And we found a meaningful difference between where organizations have been and where they are or can be through DevOps and the cloud. So historically, some organizations had what we'd call inefficient deployment of solutions. I'm sure all of you here have been or know someone who back in the day logged onto a server, clicked something, Next, Next, Next, Finish, hop onto the next server, rinse, lather, repeat until you had deployed it, then followed by a bunch of manual testing.

But now today with DevOps practices, we've automated that out. We now have a repeatable process, and we have automated testing that occurs with that. It's truly a differentiator now, especially from a controls perspective, because we can demonstrate repeatability.

Yosef Levine

And from a controls lens, when we view the cloud, well, there's one control that repeats itself in an automated fashion everywhere. So when you're testing controls just from a bandwidth of the amount of people you need in an audit department, a machine could do it and the number of actual work to get to that level of comfort and precision is actually a lot lower based on the automation that exists. And we're currently thinking about, well, can a machine do that? Can a machine do the auditing and just give us the exceptions, and the job of the auditor is making sure that the exception management process is being followed appropriately by the business?

And that's an evolution.

John Waters

That's right. We've also seen for large multinationals that in certain locations, they've had an inconsistent set of tools. Certain innovations may be available to pockets across the organization, but getting those out to a broad global population has taken time. However, through DevOps and cloud hosting practices, now we can provide those innovations in a consistent global fashion in ways that organizations couldn't do before. Some businesses also didn't have the technology expertise to operate solutions that really differentiated them from their competitors. When we talked about big data solutions, cognitive type solutions, and we talked about the technologies that went behind that, some organizations wanted to get there, but just didn't simply know how to make that journey given all the new technologies that came in place.

When you start looking at some cloud providers, software as a service, platform as a service, those now become key accelerators to adopting that, and your DevOps teams are focusing on a lot closer to deploying what matters to the business rather than the core technologies that are underpinning them.

Yosef Levine

Last week, John and I had the privilege to present to a lot of our risk leadership team in the APAC region of Deloitte. And we spend a lot of time taking our risk leadership on the journey so they could appreciate a little bit about DevOps. We do what's called the DevOps Primer. If you could imagine the following scene, 50 risk management professionals, maybe there's a few technologists in there. There's about 35% are lawyers, another 35% may be an auditor, and we have to get them to all speak DevOps language. Because in order to risk manage what it means to be operating in a DevOps capability, you actually have to understand what DevOps is, but most importantly, what it is not.

It's not a reckless disregard of security and controls. So baselining that very important stakeholder group, and there's this one story, and then John, you'll let me tell this story.

John Waters

Sure.

Yosef Levine

Old way, okay? If we are working with our clients as an auditor and we actually have to send a request to the auditor that says, "Hey, AP manager, we need to have a certain number of documents sent to us for us to perform audit procedures." We would typically, in the old world, email that to an AP manager at our clients and maybe CC the AP clerk and some other people on our audit engagement team. They would duly respond to the request, sending over the documents needed. Then what we would do is we would take those documents, and there's probably multiple people on a thread, so now everybody has the confidential information, and it's in multiple Outlook servers for multiple individuals on our client side and on our side at the same time, and then doing what everybody does is you click on the attachment in an email because you have to see it, because you want to make sure that they sent you the right thing so you could hit rejection or get the right information quickly.

So you have a temporary file that's now created on everybody's machine. And then if it's a good document, you'll actually save it locally and then import it into a secondary software. And then you have backups of all those individual copies that are replicated in a decentralized manner on multiple machines, on ours and our clients'. Forget about the cost of space. From a confidentiality standpoint, even if something is passworded, no entity, just for pure operations, wants to have data replicated multiple times. So when we tell that story to our risk leaders and we say, "What about a future where data exists once and only once, and you don't have that data multiplying itself?" So when you think about the risks of the cloud, and when you think about the risks of continuous delivery and constant change of how we approach risk, well, what's the risk of not doing it, where you have data replicated so many times from a confidentiality risk standpoint?

When we tell that story, the room is silent, and all of a sudden everybody wants to listen to the power of DevOps and what it means for organizational transformation, just to help you manage risks more effectively.

John Waters

Thanks, Yosef. After the focus on quality here, another area that we focused in on was financial. And again, depending upon your organization, especially in global organizations, there's what we call decades of muscle memory. I had my data in my data centers operated by my people because when organizations started this journey years ago, that was really the only way to do it. But technology has matured. Connectivity has improved. Encryption has improved. DevOps practices have emerged. The cloud platforms have emerged. There's a way to do it better and ultimately reduce IT cost by removing some of that duplicate spending and allocating it elsewhere to areas of value through the business.

In addition, through DevOps, we can get value out to the business faster, and that can be significant to the business in terms of defending or winning engagements or new business competing opportunities. So DevOps truly does matter to the business. As well as part of what you'll hear us talk about today is doing that in a controlled fashion can become a differentiator for your organization because organizations will ask you about the security, and we'll talk about that in the next section here.

Yosef Levine

One of the key consideration when you think about not just the cost savings, but the regulatory landscape changes consistently in a very different way at a global scale. Businesses today are global. There's no discussion of just what matters in your local jurisdiction. Suppliers, customers are located everywhere in the world, and there's a wide variety of regulatory concerns that any global organization has to adapt to. In an on-prem world or a world without constant delivery in an agile framework, it's very difficult to be responsive to the regulatory needs of suppliers and customers so you could actually have your business grow. So that's another lens that we try to articulate with business leadership for them to help understand the value proposition of how DevOps could actually enhance and grow business.

John Waters

Moving to our next section here, though, security and technology were also key areas of focus for us, and I just touched on that earlier. But something that we've seen is increased scrutiny from either our clients, regulators into businesses saying, "Tell us about the protections of my data in your environments or the data of my clients in your environments." And it's important to have a-Positive, accurate, timely, and consistent response, especially for global organizations that may have a distributed footprint. How does DevOps provide that? Again, it's that repeatability. Build once, deploy many throughout your entire organization. Those practices historically weren't there, could've been fragmented in large organizations.

When you think about that as an element of change, from a qualitative lens, consistency is golden. The faster any organization can get to a consistent approach to any elements of operations, that opens value, saves money, and allows the adaptability of the changing business trends that may exist in the marketplace. Thanks, Yosef. So let's dive in a little bit deeper here. As part of this, we came up with a reference operations model to help enable some of that transformation we spoke about in the previous slide here. And we won't linger too long on this here, but there are a few different layers that are part of this. First is our DevOps and our enabling technologies here.

These are your tools that store your source code, your product backlogs, your CI/CD tools that are out there to deploy to your systems here. The foundations, if you will, of a DevOps enterprise from a tooling perspective, but certainly only the start of that journey. The next area is what we'll call our cloud architecture platform. These are individuals that are focusing on the big picture, creating the solutions from an infrastructure as a service, platform as a service perspective, stitching those together from a networking perspective, focusing in on high availability, disaster recovery. But also, these aren't standalone items. These are components that require orchestration, and your DevOps teams enable that orchestration and need the tooling, as well as the services to bring that all together to deliver value.

Underpinning all of this now is our DevOps teams that are embracing those solutions that were prescribed in the architecture in the previous area here. Whether we get incidents that are coming from the field, whether we get incidents that are coming from our monitoring systems externally, or escalations within the organization, those DevOps teams are operating those systems on a day-to-day basis and have support behind them in the case of escalations. But what really starts to become different now is the areas we see on the sides here. And not to say that they're pushed to the sides, but rather they're cross-cutting, where your security teams now have a dedicated architecture discipline that is looking all the way from those enabling areas at the beginning of technology we talked about, through the cloud architectures, as well as day-to-day operations.

They're in turn paired by the controls organizations, and we don't necessarily mean external auditors. With us, we have a team that operates internally that helps us get prepared for SOC 2 certifications, ISO 27001 certifications, so that we have that kind of internal dry run, put on our best foot forward when we're getting ready for that. And let's talk a little practically about what these teams do. So the security teams can also play a prescriptive role in saying the architecture needs to look like this, factor it in the cloud architecture, as well as operational role in terms of collecting some of that telemetry into SIEMs. In your control organization, they're involved even at the beginning.

Some of those enabling technologies we talked about. For example, who started an R&D project and said, "Oh, we just need a small repo. It can be public. It's just for some POC." But over time, that became something that was an R&D project to something that started to represent value to the business and became a differentiator for you. But it wasn't brought into the fold. Now you have to have concerns around what's the authentication on that? Who owns that account? What if they leave the organization? And your controls team can have a focus in on that vendor relationship management as well.

Yosef Levine

And from a risk perspective, and I heard this theme talked about in one of the main sessions earlier today, there's multiple levels of how you manage risk in terms of experiments, in terms of progression of project development, based on where you are in your life cycle. Experimentation does not mean no controls. There's different baselines depending on where you are in that life cycle. Another key element that John did talk about that I like to call out for what it is, when you think about DevOps, there's almost a duality of skill sets that are concentrated on two different elements. One is the investment to build out DevOps capabilities, those patterns, the cloud architecture, the security.

That's how you actually do DevOps. On the other side is the actual operational capabilities where the DevOps teams are doing this day in and day out, putting all the configurations into environments, setting up environments, taking them down, being responsive to the needs of the business. So what we've learned from our organization going on that journey is we thought one group of people could do both at the same time. We learned quickly that the build out of DevOps capability, while the skill set is the same as operations, you really have to have two different groups that work harmoniously with one another. So the capabilities get handed off to the operations.

John Waters

So now, let's take what you've seen in the previous slide and now peel back that layer of the onion one more layer. And as I was coming here earlier this week, I came out and I saw the signage on the side of the hotel that said, "Get together, go faster." And that really resonated quite a bit with me because that's really what we're talking about when we bring controls teams and DevOps teams together. Get together early on in the process and go faster. Because otherwise, who hasn't been here where the controls teams come in, you're close to releasing your product, you think you're just a few weeks away, maybe one, one and a half sprints away, and now the controls teams come in and ask some really good but hard questions.

And you start to realize how far away you might truly be. By bringing the controls folks in earlier on in the journey, getting yourself together, you'll be prepared much sooner, and you're not making that 90-degree turn when you're getting close to release because of all the considerations that you haven't factored in yet. So we really call this a holistic ecosystem of DevOps, where our control individuals, our business risk individuals, lawyers that are taking a look at licenses for OSS software that the coders are bringing in, this is all happening every day in real time. We don't want to be functioning in any sort of inclination of a development shop that looks like Waterfall.

It has to happen all the time. When we do testing on controls, it's iterative, it's ongoing.

Q&A

Can you talk about what applications are running in the cloud that are supporting the audit and assurance practice?

Yosef Levine

Okay. So our business, we are a cloud-first business. We have about eight or nine applications running in the cloud. We happen to be using Azure. We're an Azure shop from the global audit Deloitte business. We tell our clients that story. We're not ashamed. It's a very positive story on security posture that we repeat. By moving to the cloud, we feel that we could offer a lot more in terms of data security. Our future audit platform that we're spending a lot of time building today is on the cloud, and on the cloud only. There is currently no other option. We're navigating the challenges as it relates to a variety of data residency challenges. By having that build once, deploy to many environment, we can spin up environments wherever Azure is located, assuming these services are there.

Even China, where there's a national cloud that we're working on at the same time.

Q&A

I'm sorry, one last question. But can you speak briefly, generally, about what application of business processes those applications are in?

Yosef Levine

Sure. So our main client collaboration tool, which is called Deloitte Connect, you could go to deloitte.com and type in audit innovation and see a listing of products that we use to deliver our audit. The majority of tools you see on that are actually hosted in the cloud. So our main collaboration tool, our clients love it. It really transforms, and gives deep insight to how the audit process works. And we have over, what is it, 300,000- That's right ... active users in the platform going to the cloud. Really have not had a significant amount of, I'll call it, tissue rejection from our clients. Typically, I get concerned from an audit lens if our clients have a problem with it.

That means we have to help and educate them quickly on the cloud before they become extinct. So that's a value-add opportunity where I talk to our lead client service partners and I say, "Hey, listen, we need to get your IT group and the business into a cloud lab quickly." Tell them, understand why it's imperative for them to be more cloud-savvy and understand what it means from a business transformational lens.

John Waters

So keeping an eye on time here. What you'll see here is a few different areas we talk about by design, and that really means getting the controls teams and DevOps teams together at the beginning so that these are given consideration early in their development life cycle. In addition, we're talking about doing that in a consistent fashion so that this isn't a response that's for one individual solution within your organization, but rather the response for simply how you develop and deliver value to the business. So it's not a variable response by application, but rather principles that you're using for all of your solutions that you're delivering.

That makes it a heck of a lot easier for you then to respond to regulators and clients because you have one response for all that you're doing, and not a patchwork of different solutions for different applications. We often get requests from our clients because we're a third-party vendor, although we are their auditor. They want to treat us from a vendor management perspective like any other vendor, and that's a part of COSO 2.0. So when they treat us like a vendor, well, they're doing their job, and we know because we're a part of it. Often, there's a request, "Give us a listing of all of the applications that you're using, where their data is." We go through that process, but we try to change the dialogue.

The dialogue is not application by application, it's what's your holistic posture that governs your secure software delivery life cycle? Do you have a technology operating model that provides a consistent way that your applications are built? What's the guardrails that exist within your organization? What's your management plans in place in case something goes wrong, and how do we know? And how do you communicate to us if there is an issue? So we really try to have a healthy dialogue on all that posture, but it's not application by application. It's the Deloitte way in which we manage our clients' data. Thanks, Yosef. Looking at time, I won't go into detail on all of these, but we do have a session later this afternoon for a fireside chat for those of you who are interested in and maybe want to dive a little bit deeper into some of these areas.

And one of the items you heard this morning, too, is MVC, minimum viable controls. You need to right-size these for your organization. What's the type of data that you're dealing with? What are the type of regulations in your environments? What is the impact of not having a particular control at a given point in time? But overall, we've, over time, these weren't big bang introductions, introduced these steadily and steadily, and they now have become part of our response, our integrated controls framework that you'll see on the next slide, for responses to clients, responses to regulators. One big theme that you'll see in here, though, is a lot of use of automation.

And that's not new, but DevOps. But what is new is the concept of taking some of those DevOps practices and making them part of the controls journey, the controls story. So, for example, if I need to collect evidence around who accessed an environment at a given time. We have a privileged access management system. Someone goes in there, checks out a privileged account, provides a business justification for why they are requesting privileged access, and then within a period of time, those credentials are automatically revoked, and if they need to continue that, they go in and re-justify that. That might sound onerous, but once you start to walk the walk there, not just talk the talk, it actually becomes part of how you do DevOps, how you deliver services, as well as creating a great audit log to give to your controls auditor.

So that's just one of the examples here that you'll see on the slide.

Yosef Levine

So one thing that we did early on is there's control standards everywhere. The good thing about control standards is when you take them and map them, they tend to relate to common objectives. So what we did when this came about and we were thinking about how do we rationalize all of the controls and regulatory requirements that we have, we created not just a holistic software development life cycle, but we created an integrated controls framework where we've taken all the different controls that are out there at a global level. We ingested them, we think about them, we map them, because when you think about what's the responsibility of an external auditor to comply with standards everywhere, how do you do that?

You need some sort of GRC tool that provides a way to do this. I've seen a lot of even our audit clients that try to manage this through Excel. It just doesn't work. There's just so much out there. You need a tool. When we sat down and rationalized all the different control standards that are out there within our integrated controls framework, we realized that there's a lot of common principles that underpin all the control objectives and the controls that we have and that we're consistently updating based off of different paths and other types of services that come from the cloud provider. But there's common principles, and when we rationalize things down to common principles, that's a business vernacular.

When you talk about controls from a principle-based perspective with the business and with our clients, it changes the dynamic of the discussion. It's not just about DevOps, it's about value. So we look at principles as a way to communicate the value in terms of how we approach security and controls and being in an appropriate steward of our clients' data. So when you go on this journey of managing DevOps and trying to have rapid transformation, and everybody knows this, but you got to repeat it again, it's a complicated web. Tone from the top is important. The bottom up isn't enough. But what if you brought all these stakeholders, your regulatory leadership, your legal leaders, your privacy leaders, you bring them into a room at the same time.

They all have a very important voice, and we're not going to make detrimental decisions or do anything foolish or be irresponsible. But these now become business requirements in terms of our DevOps posturing. Now, business requirements are not functional requirements, and that's a very important distinction that we learned internally. While the risk stakeholders, they have their rules, how we implement them for us to be responsive, that becomes a deep technological discussion where you need a control savvy auditor or a security person that understands the regulation to help come up with a common, scalable approach to manage the needs of these very important, critical people in our organizations.

They may need hand-holding. You may have to have a lot of touch points with them, but rest assured, they will come on the journey with you. We have some of our lead lawyers in our US and global organization that says the audit function for Deloitte gets it. They took us on the journey. Everybody feels that we are doing the right thing, to be responsive to the needs of our clients and to safeguard our clients' data. You have to make those important investments, and you have to have an individual who's not just bought into the concept, but deeply understands it and could almost translate it with the appropriate business and risk context, so it's understood by these very important people.

Imagine on everybody's transformation journey in delivering DevOps, you could have a lawyer cheering for you in the hallway. It was hard, but that's where we came to. It took us a lot of time to build that respect, but when your lawyers and your risk people are cheering you on because they see the value of DevOps in the cloud as a way to protect the organization, that is a true transformation.

John Waters

With our last minute or so here, we're going to just go through a few items on myths, and at the risk of introducing yet another slide around DevOps and myths, we hope we're bringing some unique perspectives to it by talking about controls specifically. So here, we've heard it's not possible to have agility by introducing controls and DevOps, and really we feel it's much the opposite. Rather, if you don't have DevOps practices and you haven't embraced those by design principles from upfront, it becomes very difficult over time to be agile, to be responsive to the business. When some of your wins for your engagements are based off of client inquiries around what are the controls in your environment, how is security being dealt with, what is the repeatability of your processes.

DevOps can mean dev manages production. This is a bit at the risk of a cop-out, an it depends item. What is the nature of your environment? What is the nature of the data you're dealing with? What are the needs of your regulators? Some environments, especially financial related, will look for that segregation of duties between personnel for development and operations. But what's most important is you bring the best of both disciplines together when there are production incidents, if it is needed to have that type of segregation. And we'll talk a little bit about this a little bit more in our fireside chat this afternoon, as I know people are pretty interested in this topic.

I see a lot of heads nodding to that one, John. Yeah. We've talked a lot about the cloud here, but some people say, "Okay, is that saying now that you can only really get a compliant organization through the cloud?" No, but the cloud can be part of that story. You may still be hosting on- premise, but you can use technologies from the cloud to help you deliver that software, CI/CD, monitoring, et cetera, but still maintain that on-prem. And that might be the first step towards your journey long-term for the cloud. Sometimes you've got to date before you get married, right? There you go.

John Waters

Thank you, Yosef.

Controls slow down CI/CD. They can, but it really comes about how do you adopt them? You don't want to be in a spot, again, where you're making that last-minute introduction of heavy controls. If I have a database server in production, I want to have a very, very pinpoint firewall rule on that server saying what can connect to it. But in my development environment, my data's different, the nature of change is much higher. The controls on that can be relaxed. But it's important that I have at least the groundwork there. Maybe I'm providing a large CIDR range for my development environment, but at least I have the framework so that as I'm promoting from dev to QA and further up the life cycle, I'm gradually layering in more controls, so I'm practicing that from day one, and it's not something that becomes an unnatural change at the last minute.

And the architects and the developers, they have to know to code for that optimization because it is coming. It's a question of when. And for our last one, I think this is Yosef's favorite one here, DevOps introduces organizational risk.

Yosef Levine

Biggest BS concept. DevOps allows us to respond quickly and fast. Every organization has had opportunities to increase value, to grow, to obtain new clients, to get new versions of market to product, irrespective of the industry sector or sub-sector. DevOps is a way to accelerate all of the types of business needs. When you talk about DevOps as an accelerator for business growth and being able to pivot, it's just a different experience when you're dealing with the people that have the keys to the pocketbook to do the further investment in DevOps. So everybody today, all of our clients, everyone's a technology company, that's fine. But we have to understand how do we take the technology to deliver the value for the business?

And that's a dialogue, that's an educational process. But I know our time is up. We hoped that we gave you some words of wisdom that will entice you to come back after lunch to have more meaningful dialogue. Thank you very much and have a good day.

John Waters

Thank you.