 In case you missed my name, it's Pacing. I have all this blah blah stuff on the second line. Currently I am with, I'm an independent consultant with organization really silencing management but I'm not here to sell anything alright. And I also work with the business continuity chapter of the Singapore Computer Society as the ex-co-secretary. So in case, and I highly encourage you to sign up as a member, please call me. Again, I'm not selling anything, only if you want it. You may experience some technical glitches today. I am very new to Ubuntu but I'm learning how to use it on this little baby. And as you can see I'm also trying out some other tools. So are you guys good? And I proceed. So the idea today is to talk about audit, how an auditor looks at DevSecOps. But it is not an instinctive kiss or kill decision because the same with us, with me as auditor looking at DevSecOps. The audities themselves are also looking at the auditor coming through the door and then they have to decide should I kill this person, silence her or maybe I try and hug it out with him or her or whatever it is. So if you talk to an auditor about DevSecOps, this is actually their first reaction. And then because we are more used to hearing stuff like this. But it's not important for you to read everything in there so that's why it's all jumbled up. But the idea of it, why we got a is that it's not defined. It's a cloud, it's a bunch of smoke and we really need something that is a bit more structured so that we know okay what are we trying to compare it to because that's what the audit is about. So for purpose of today's for the next hopefully 10 to 15 minutes. We need to talk about it in a context. So I have taken the liberty to choose one and it's this. Anyone not familiar with what this thing is? So just a quick one for those. This is the information security management standard published by ISO which is International Standards Organization. And as with all international standard organizations, they are in Switzerland. It gives you not only a management system framework, it gives you in the index a whole host of domains where you should look at as hygiene factors for your security controls. So that's the quick and easy of 14 pages. The reason I pick 27,000 is that as with all ISO management standards, this is their ancestor, a Deming Cycle. Coincidentally, the ancestry of agile also comes from Deming Cycle. So we are not that far away. At least we established we used to come from the same place. Okay, so I want to just introduce the people who are not yet familiar with this term management system. In 27,000 or in any of the ISO management standards, we don't deal with systems in terms of always an email system. This is a chat system, blah, blah. We don't think of system at this level. We are talking about management system for the whole organization. Meaning other than this, okay, is that these processes that interact with each other, they are established. So someone has an idea or there is a clear idea of what it is. It is implemented, put into jobs and maintained and continually improving. So this is like the basic requirement that any ISO management standard will have. So I think on the first or second section of every standard, you will also see them mention something about process approach. So many years ago when this was first mentioned in ISO standards, it was because we wanted to solve this problem. The different departments, they were doing things on their own and those processes that span departments were not performing. They were not flowing well. When they passed from one department to another department, it gets stuck. So the whole idea of looking at the organization as a management system is just that for those processes that span departments, the walls are taken down. And from the input to the output, the very end of the process, there is some communication throughout and you have your product produced at the very end which has some value added to it. So this argument is not so strange for if you have been to DevOps conferences or talks, it's nothing new but weirdly it's coming from a standard that's supposed to pull you down. So what do standards see themselves as? What kind of a doorways? Because this is actually taken from ISO as well, you might see it. The standard pins, what is the minimum of the benchmark? If you read standards, normally they won't say, you must have password security, your password must be minimum, eight characters, Alfa New Mary, complex, blah, blah. Usually they don't say that. They just say look at password security. So there is a specification of the minimum and with every revision of the standard, it tries to push the benchmark a little higher, a little higher and a little higher and hopefully all the organizations that subscribe to this standard, they get pushed upwards as well. But of course it's a long time. So back to this thing about auditing DevSecOps. Let's say I'm forced to audit DevSecOps for whatever reason. As auditor, my instinct is to go look at what are the processes that happen in DevSecOps. But is it really any different? Do you not have change management? Do you not have service updates? Or is it that you do not have any kind of authentication? It's not that. So mostly to auditors without a lack of any kind of a framework that's being defined for DevSecOps, these are the things that we instinctively go for. And we would ask you what exactly is the audit reference you want me to take? So it's as if it's very simple. You go out, every SDLC has many, many things. So yeah, every face has their own processes. Not a problem. But I know I'm making it sound very easy. For those who have gone through ISMS audits, you'll be like, this girl is trying to smoke me. Things are not so easy. I still get a whole load of findings. What's the deal? So if you take a closer look at the findings, this is what you might find. The standard, like I say, it gives you a public benchmark. Am I blocking? Maybe I should come over here. And what you get mostly that most people understand from audit report are things that they say, oh, the standard says this, but you didn't do this. So that belongs to this category of findings. But you also get another category that most auditors actually find. So that would be your procedures say this, but you only do this. They don't match up. Or your procedure says, oh, I'm going to get 100% of something, but you only get 80%. So these are the kind of findings most of the time you will see in the audit report. Something that doesn't come up on the audit report, but sometimes is suggested from when the auditor writes AOIs, area of improvements or suggestions or something like that, which for you as audit, you don't necessarily have to agree on or have to put into action is this one. Reality and standards are not the same. Simply because by the time someone gets through thinking about something, that reality is over. And standards themselves, they have a very, especially the ones on the global scale. They have a very long update cycle. For example, ISO 27001 that we are talking about, review cycle is five years. But the voting, the redrafting, the review going through the different countries, getting a new standard published takes about anywhere between six to eight years. So by the time a standard is actually published, you are probably looking at some time capsule thing that was almost 10 years ago. But it's how it works because on a global scale, I can't just say, all right, I see it happening in Singapore. It doesn't matter. So Singapore is working good in Singapore. I put it in the standard. It doesn't work this way because they have to think about on a bigger scale, how can they make things better at the bottom line. But there is also one last kind of findings that is quite irritating to auditors and auditors. And that is Nielsen's findings. Seriously, I am an auditor and I can tell you there are always potential Nielsen's findings. These are findings that happen on the audit report. You see people write, write, write, write. But no matter how you go for it, no matter how you dig, no matter how you ask, no matter how you investigate, no good comes out from it. There's no value that you can reap from trying to find out why this thing happened. And such findings, I can give you an example. Very often is an auditor asks an engineer, do you have a process for managing your system? And the engineer says, yes, yes, yes, yes. And he proceeds to dig his files for something. And then he realized he doesn't know where it is. And the auditor says, never mind, take your time. I'll be here until tomorrow. You can always give it to me before I write the report. And he says, fine, fine, fine. And two days later, still cannot find that particular document. And no choice. Auditor puts it down as, oh, evidence is not present. But the day after the auditor leaves, a colleague of the engineer comes back to work and says, huh, it's here, right in my drawer. So what kind of good will come out if you try to correct? You know, if you try to dig, dig, dig something like this. Maybe just that these guys don't have a proper documentation sharing platform. But really, is it that or is it that you need to educate people more on how and what to do? So sometimes you do get nuisance findings. Audities who get too nervous and then they jam up. And then after that, no choice. Auditor also don't like to give this kind of findings because one year later or half a year later when we come back and we realize that we have to close the finding, we feel quite stupid about it. All right. So another form of nuisance finding actually come from something we call loss in translation. And this actually happens quite a lot in IT. It's when we ask for, for example, this particular one that I'm trying to show is that I'm asking for how do you set up and operate your system. And then as the engineer, he comes out and see my network diagram, my architecture diagram. See, very nice. All well drawn, you see. Even has branch A, branch B. And then as the auditor, I stand there and I'm like, okay, I'm very good architecture. I like your drawing. It's very nice. So how do you run it? How did you set this up? How do you know you should have branch A with this and you have branch A or branch B with that. And then the engineer jams up because he really doesn't know what to say, right? Because whatever he says, he's afraid that I might say something wrong because suddenly he's confronted with a piece of thing that he was so confident in actually tells the auditor very little, right? So this is really one of the common problems. In fact, I myself experienced when I was auditing in my last company. And it doesn't just happen that auditing has a problem. It also happens the other way. An auditor steps into an environment and he is lost because systems nowadays are so massive, so complicated. Instead of sitting down to audit, he probably takes the better half of a day to just find out, to just understand what the business is about, what the engineer is trying to do with the things that in his charge. So that in actual fact takes up a lot of his time and takes up a lot of his brain power. And some auditors do get very flustered by it. So in this war against your auditor, may or may not, who is your real ally? It is your compliance department. If you have one, if you don't have one, then it is your product owner. Because these are the people that can give you a direction on what to do, what not to do, and why should we not do something. The idea, sorry. So when you say product owner is responsible for compliance, let's say product owner is not aware about what is the requirement for the compliance, then what? Okay, you see that is the thing. You are talking about a case where I don't have a compliance person. And then my product owner is the kind that I look at the spec. If the spec doesn't say, we don't do kind of thing. Then I would say, do point number two. Bring competencies up to par. Bring them to SMU, talk to Angela, talk to Amelia. Understand what it is that they really need to do, need to go and learn. Because there is nothing bad about learning. And there is nothing bad about going to school. Especially when school is so nice in the middle of Singapore, see what Angela goes like. So it is okay. Someone just has to take up this role of ensuring that the compliance part of it is being looked at. You don't want someone to be in charge of auditing. That is really not a value-added job. I'm an auditor. But when you are doing production, you are doing deployment, audit is not really a value-added job. And also, if you guys were listening to Amelia just now, she was also talking about having many service providers, having many tools. It's easy to get lost. You swim in them is very likely that if you have not been swimming intelligently, you will be flooded. And when you get to the point that you have to explain to someone how this big architecture of yours was where some portions you have asked a tub provider to build for you, or you have implemented something open source, or if you have put in people to come and support you in your operation processes, it's difficult. And it takes time and it takes patience. So it's not always smooth sailing. That doesn't contribute to a very nice audit experience. When actually all the auditor once is sit down with a cup of coffee, look at staff, finish his coffee and walk out the door. Just end up with a report. And basically what you see in Purple is extract from the manifesto. And something that I think really, really makes sense. It is not, if you read the whole of the manifesto, nowhere does it say that you should do audit. And the worst thing that you can potentially do is if you treat audit like activity that you can revolutionize like all the other activities in the SDLC like testing, like integration. Now the trend is what? Continuous testing, continuous integration, continuous deployment. But nowhere you can do continuous audit. No such thing. It doesn't help you in your deployment cycle. It will just slow you down. Anyways, if you go for audit, you will have findings. So are you going to be always looking at your findings, trying to fix them before you deploy? It doesn't make sense. We are going backwards, right? So we are approaching the end, bear with me. Some of the auditors new to DevOps, we sometimes feel this way. So I'm glad I get the chance to speak. And I'm thankful that everybody gives me a chance to learn. So maybe, just maybe, we do have a chance to hug it out with the rest of the DevOps community. And I hope I have convinced you about this. Again, the auditor, we are really the ones that see the work at the last. The developer sees it, the tester sees it, product owner sees it, customer sees it. But when does the auditor actually get to see the results of that work? We are actually the very last. And in fact, when you have a system that is gone to the end of the lifecycle, the auditor could be potentially the last person to look at it just before you kill it. Just to have historical records, see how it was made, but that's it. So if you want to be proactive, the auditor is not the guy to talk to. And so I'm very really at the end of my talk. I hope I haven't been too fast. And this is a personal call out to everybody. Compliance folks do need some love. And we have empty space, as you can see. So at the next DevSecOps meetup in June, please bring someone. Bring someone from your compliance party. If you don't have someone from a compliance party, bring someone who will be audited. It's easy, just bring them. It's a bit like marriage counseling. You have a misunderstanding or you have something with the other party and you bring them to this group and we can do some group therapy together. So that's it from me. So now back to what you guys were helping me with learn. If you need to look for me, by the way, send this another QR code for my LinkedIn. Let's go back to that survey. So we had already had this. So let's see. I'm on air. Okay. I actually have some interesting things to... I will make this available to organizers. Okay, so... Alright, let me see. Do you guys get the next... Do you guys get the next question? No? So you can vote on the next question now. Where is my continuous testing tool? Good? Getting this? Yeah. So the reason I'm asking this question is that these are... This group of people, they are not involved with product design. They are not involved with building the product and they are not involved with the compliance or even... These group of people probably don't even see. But if they don't move their ass, you can't work. So do we bring these people into this group therapy session? I know in a lot of... I mean, I was from a fairly big company myself. Procurement always seems to be in the way. They always have something to complain about. Here, if we want to have a sharing culture, collaborative culture, do we bring them? Good? Let's have a look. Wow. Okay. So you guys also know what to do. If you cannot find a compliance person, you cannot find an auditee. Some guy who's going to be audited, you bring one from procurement. Okay. And most of the time, procurement are nice ladies. You can bring. All right. Okay. Is that it? Okay. Seems like it's very difficult for no to catch up. Let's go on to the next question. Okay. Do I have? Question three is on air. Okay. This question is more because I'm interested. You know, Asian culture has a reputation for being a little bit close when it comes to adopting new things and talking because we don't like our bosses or our colleagues to think that we made a mistake. We didn't do things good. Or we are just plain stubborn. So maybe a quick vote here. Let's have a look. Really? Really? Really? Really? I mean, this is pretty interesting, right? This is pretty... Refresh? Oh, okay. Yay. Okay. Who... I mean, what did you vote for? Yes? No? It's the most difficult places on the board and I'm traveling all around. Okay. And yourself? What do you think? Why is it? Why does the local culture make things a little bit... I think we have different companies. Younger or, I don't know... I think we are also hiring DevOps people. Yeah, I think we are always hiring DevOps people. Suman? Yeah, I voted no first of all. Yeah, just give a reason. It's not about the local culture that's been to US, Canada and China also. It's not the local culture, but it's the development culture more... make a behavior change, you know? So the way development works, or the way operation works all around the world, it's the same. So when you are trying to implement DevOps, DevOps, what do you say? It's not about the local people culture. It's all about the technical culture. I would say how they used to develop the software, how they used to deploy the software, how they used to operate the software side. So I think it's more about the technical culture rather than the local culture. I think that is also quite true. Because for teams, maybe you have different teams and every team, no matter how small, they have their own little culture because they are their own little clique. Yeah, that means it's difficult. It's not about the local culture, that's what I'm saying. It's not about the local culture, that's what I'm saying. It's about the organization culture or the technical culture, how you have in your organization. So if we extend from there, it also means that regardless of where your business operates, you can push this cultural thing. I talked to some people at DevOps days I was at recently and they'd say, DevOps, this movement is bottom up. It tries to make all the people come together and then that bubbles up to management or bubbles up to the rest of the world. So really, I think this just by way of extension proves that it can be done because the scores are very close. Last refresh, let's see. Okay. Alright, so can I just take questions on anything that I mentioned? Yes, please. My dear colleague. So I just wanted to understand something from the auditor perspective. I'm not auditor but I'm trying to understand how auditors work. Yeah, because you are trying to satisfy the auditor. Yeah, because I'm a product developer. So you talked about ISO 27001 and other standards that you guys follow. So I am pretty sure I can understand from your presentation that you cannot go through all the steps mentioned over here. So what are the basic compliance steps that you follow while you audit an engineering IT system team or a development team? Like the basic three or four points that is a must from your perspective. Well, if given anything and says pacing go audit, first of all, like I mentioned, I need to know what I'm comparing against. It's a process of comparison, right? So we usually in the process we will look for what we call objective evidence. This evidence must not be something that someone just wrote down five minutes ago. It has to be some artifact from your work. So perhaps you have a design, you have architecture, you have some meeting minutes of your team members going at each other and then you arrive at a decision because of what, what, what. So it's your logic, it's your reasoning how you arrive at doing something that we definitely want to have. It doesn't have to be pages and pages. Okay. And how do you get to the, so one of your slides, a couple of the slides talked about standard and benchmarking. Yes. Yeah. So I mean, like as you said, right? It takes like, your ISO takes like around a few years, more than like half a decade to come up and like as far as I know, right? Waterfall to agile to DevOps happened in the last seven or eight years. So in that sense, like how do you even do a standardizing? How do you get a benchmark? Yeah. So if you read, if you look at, in this context of the ISO management standards, right? If you read the standard, you'll realize it doesn't tell you what to do. Right, exactly. Or how to do. It just tells you, look at this area, look at this area, look at this area. But the how and what to do about it you decide. So any one who wants to subscribe to such a system, they will say, okay, I just need to make sure I hit this domain, hit this domain, hit this domain. I need to document how my processes interact with each other definitely. Because it is the concept of your organization. Does that answer your question? Yes, I mean, so that answers the question, right? But again, like, I mean, every organization, like someone just talked about, right? They have their different development culture, engineering culture, processes and all. So in that case, how does this, how are you able to implement like an industry standard? Very good question. Because industry standard, there is no standard that audits culture. But every standard aims to become culture. It's the same. If you look at it, no matter you're talking about information security, or you're talking about environmental management, you're talking about carbon emissions, you're talking about business continuity, they always say the best outcome is if the spirit of the standard becomes part of your organization culture. They are not looking for hard compliance. If I say A, you have A, B, you have B. They're not looking for this. Rather, auditors want to see that the spirit of a recommended control has been internalized by the group as a whole. You will always not see perfection. It's difficult. Anyways, the process of auditing is if you are facing an external auditor, they are only with you for a certain number of days. And within those days, they have to check a huge spectrum of domains, which is not easy. So they will do a sampling process. Of course, this sampling process will be a reasonable sample size for enough for them to write, to have that confidence to write in their report. We've sampled so much. And it does indicate that the process is within the control limits. That's it. But on the other hand, the topic of today's speech, which we were talking about, internal auditor, right? Internal auditor plays a different game. Because internal auditor is someone in a unique position to understand what this organization is doing. Because they are part of the organization. They are familiar with the business. They are familiar with the business objectives that we want to achieve. So for them, usually they will do a more in-depth check. And they don't sample areas. Normally they check every area. But sample each process. I hope that helps you. Thank you so much. And the last one is I am just... I need some feedback loop, right? So if you guys sample it, just the last one. So if you like my talk, please give me a star. If not, then I thank you for your attention and for your participation. Yes, sorry. Oh, you have a question. So sorry. I'm so sorry. Yes. I have a simple one. I'm coming from a world of proof that I live in every day. I do something, it works, proof. And if someone wants something, I was a developer for a long time. I'm an economist by profession. So it's always that we like to see things as if they were real. Then there comes the audit and we don't know do we turn left, do we turn right? What is it that they want? What is going on? And one day I had this understanding. It didn't last very long but I had this understanding that okay, so if there's a standard then it imposes some thoughts on the company. Same, okay. Our business deals with customer login data. We have to do something about this login data. We have to decide how we want to deal with this. So you create kind of a white ball of white balls and you write on those balls. We have to solve the values. We have to save them in a secure location. We have to make sure that physically nobody can run off with the hard disk that they are stored on things like that. And that is actually the work that you don't need to do yourself. There are frameworks out there that come with bunches and bunches and balls with balls inside and then you just have to sit down and say, okay, take this ball, do we do it or don't we do it? And that's a management decision. The management decision that I have learned, managers often run away from because this implies security. This implies risk for their own position. So they don't really want to take a decision there. But then you get into this trouble because there are now balls that running around, that roll around between the balls and put them in, we implement, don't implement. If we implement, how do we do it? We have to write it down, how do we do it? And we do it that way that we decided to implement it. It's becoming pretty easy. But the problem arises from the fact that we can't see what other fucking balls that they are giving us, what are they about? How big? In a way, that also implies that certain managers have no b**ch. Oh, yeah. Why do you get rid of them? Okay, I mean they... Interesting, interesting afterwards. Is this one to quickly... You're on your last slide of conclusion. Yes. Did I read it right? It looks like you made a bold stance of no audit for DevSec Pups. No audit. No continuous auditing. You continuously comply at some point, at all points of your STLC. Do not keep... Because the idea of audit is I check whether something has been done in a certain way. So it's like a double check. So why would you want to keep checking for something that you should have already performed correctly at the very beginning? You get why me? I mean it depends. If you look at a very traditional view of how audits are done today and agree there is no defined process for DevSec Pups today, it's evolving and I think all organizations are trying to establish an effective auditing methodology. How to know whether the organization's DevOps community are doing the right things, are in a controlled fashion and things like that. So it's evolving and I get that. But if you look at audit as a human-driven activity, then yes, you know, you can't do this continuous audit. You can't have a person in every step of the day. And anyway, the episode would be very depressing. I think that just with the concept of automation in DevOps, right? I think the way you need to look at audit is different in DevSec Pups, as far as you demonstrate that you have tested that control in an automated manner and I've produced a result that can be verified. Does it have to be done by a human auditor? It can be proven that controls exist and that's the essence I believe in automation, that I don't need gates of approvals, right? But you need to know, right, if the automation is correct or not. So for example, you will see the recent Volkswagen scandals, right? So it was a completely an automation framework that was developed in the late 90s to take care of the entire emission cycle. And the programmers of the framework actually were told to put in certain mechanisms to escape the entire environmental regulation. Yeah, but automation doesn't mean no one should check, right? So what he said, right, we were talking about the DBS Bank, right? Still at the end of the day that goddamn AI that DBS Bank is using is programmed by a human being, right? Everything is programmed by a human being. Yeah, so if an auditor is not, auditor is basically what I understand from her, right? Is a human being who is interjecting in the process, which is handled by a bunch of human beings, which is the developers, the managers, everyone, right? So she is just like trying to reflect a mirror as to whether we are following the proper processes or not, right? So if you say, like, we are doing automation as a developer, I can write, like, 10,000 lines of code and I can make some gaps in the automation framework according to the company's requirement, right? The business requirement. So how does it comply with the regulations? Like, say, if these methods were probably followed to, or I would say, like, if there were proper auditing mechanisms from automation framework, right? So Volkswagen would be following the problem they're trying to do, right? So what do you say, right? I would disagree, because... I don't think... There is, I mean... Automation has... Just because things are automated doesn't mean they cannot be audited. Which I actually agree as to one. I want to add one point here. It's a nice presentation, first of all, because obviously I can see that recently we have gone through ISO 27.1 audit and because we are completely moved to DevSecOps or DevOps, so how auditors are basically doing the actual audit what you are pointing out is, right? It's not whether it's automation or whether it's a manual process, but auditors, as you said, it's a one-nine statement. You should be doing performing security code review or something, right? So when auditors ask us, they ask us to give us the evidence which shows that in DevSecOps what you have implemented, you are getting the security code review generated with the daily build or the weekly build or the monthly build, but give us the evidence that your automation is working fine. And those kind of evidence, basically auditors, we are pointing to auditors for ISO 27.1. Okay, okay. You need to be clear of the definition of controls in any process, right? Any process. And if the controls are defined and you've demonstrated a way that you are testing those controls, then it is done by human or automated process, it shouldn't matter. It doesn't matter. Okay, somebody might need my help. Okay. I have a very short one. I get to this by asking can we audit agile or do we audit the scrum process? So with agile, we have many different frameworks that we can apply and then we can say, okay, yeah, we do scrum, but we don't have a backlog. You run it down, you have a process, you can audit that. In DevSecOps, we don't have that yet. There is no... That's not actually... That's not bad. And it's not... I mean, audit agile, you are auditing the results of... Yeah, I do that. You know, there's a purpose behind driving agility in your organization. So how fast you're doing you, you need to audit whether it's working for you, right? So if the results show that it's not working, that means you're not doing agile the right way. Just saying, just saying that there we have a framework. Thank you. Hattini, please. Sorry, I couldn't wait. I can swing it on the screen. So I couldn't wait. Please continue. I would like to add to what you're saying. So I'm working in a somewhat rigid and very strict setup right now for... They've got... This is one of the first HR, you know, it's a pathfinder project for them. And for a group where they go live once in one and a half years, we've been going live once in a week. These people, they have the foresight to bring in the auditors right in the design phase. That's very good. And I just walked her through our entire process. So she went through the traditional setup of show me which is your, you know, how you build and who's the deployant, role segregation and random questions. So I said, okay, time out. Come to our place. And I showed her the entire pipeline right from how we create stories until we go live forward traceability and reverse traceability. It took her, she just... The only other question she really asked was you have all these controls. Can you show me an audit trail whenever these controls change? I said, okay, that sounds good. We showed her that. Michael was with me in that project. Traceability is the key word. And you know, we're done. We've been going live. We can today click a button we want in the middle of a working week. And as long as we are... We practice what's called continuous delivery. And one of the messages I've pushed is continuous delivery does not mean continuous deployment. We do have an in-house pentester. He does pentest whatever we are going live with. We do show change logs of every infrastructure automation that we do. And all features, functionality, it's all traced back to requirements. And the auditors, in our thing, we just breeze through in about 45 minutes when they come out months and years. So I like your point. Traceability is the key. Exactly. We have to show... And we have to start at the beginning. Very quickly. Not the end. That's why you should not... I really don't think it's a good idea to focus on audit. Rather, you focus on complying. Yes, yes. And, of course, to comply, you must first know what is the requirement. And that should be... That's why I say product owner, because this is the guy holding all the requirements and he better be clear about what he wants. I think not just in all auditors' different design stage, I'm sure most banks also invite regulators. Because whenever you introduce new ways of doing things, you need consensus for everyone. Regulators' hair starts standing. You engage them up front and not be scared of them. Then it's okay. So do they have any kind of tools or is it still a human process where you perform the same checks that you mentioned on the slide? Regulators, they send in auditors. Do they have any kind of automation tools or is it... I don't think that space is... In my opinion, I could be wrong. What I have observed, it hasn't matured enough. Everyone is trying to get there. It's really an evolving stage. But automation in auditing and in compliance, really I've seen a lot of applications, like Mushroom up in the last few years. But you really have to see what kind of compliance you're going for. If you are trying to comply to, let's say a coding standard, that is something I think you can totally automate. Because you just have a robot who through the lines and some simple logic follows that finish. If you are looking at something that is at the level of managing or setting processes, setting policies, no robot can do that for you. It has to be a person looking at it and asking the correct questions about does this fit the risk appetite of the organization? Is it something that the organization is comfortable to live with for a certain period of time before their next change? Or does it even match what this organization wants to achieve? If I want to deploy fast as one of my big organization objectives, I wouldn't say that there shall only be two environments, one development and one task. No such thing. You will probably want to give as much tools as possible to your developers to get their work going along. I would like to answer your question and also maybe an example is supporting what you said that organization, it invites regulators. I work with ThoughtWorks and we enjoy a lot of these things actually. We help make sure that we speed up things for a client. So one of our clients was, still is actually, a ticketing company in the UK called the Train Lines. It's a published case study. So the Train Lines helps you book tickets and a lot of their competitors are today their clients. So they just white label it and if you book a ticket, a train ticket in the UK, mostly you're on the platform you built. Now we have to work with an organization called the NRS. They are in charge of ticket reservations and our ticketing company is doing the right thing. So one of the obstacles that we hit to deploying regularly was, NRS, one of the regulations was, NRS has to make sure your build is right and all the rules are in compliance and citizens don't lose out or customers don't lose out by bad logic or whatever. So what we did was we understood what is it that they check for. We built a tool. It was a BDD sort of tool where you can type in an English sort of thing. We invited their regulators and the auditors over, showcased our intent to them and we worked and developed this with them and today whenever we have a build, I did the whole build-piking automation so I can talk about this build. So all that I had to do was have an NRS where the build is auto-deployed, have our framework pop up and run through all the compliance checks and just have a compliance report. And all that we had to prove... So what were those compliance checks then? These were all the nitty gritties of if you have this kind of a ticket booking and is there a price-ricking war going on or what. So they had a lot of... So at the logic level you were doing this. These are requirements. In fact, all you need to prove in this case is that you have validated the logic of you are doing this automation and that the results are consistent and repeatable. Go in and put in. And when the rule set, we had a revision control of it and it always, the test reports say this has been validated against this rule set of the solution number. That's why that's... So we would deploy about three, four times a day and it was just fine. Guys, sorry to disturb you. I think we can... Conquer. Yes. Thank you. Thank you. Thank you.