Jonathan Smart

[0:28] So as you know, technology is evolving really fast, and the old security concepts, such as walled gardens, are now obsolete. The new security concepts, such as the software-defined boundaries, require time to learn. There are too many regulations, and they are often in conflict. Risk communities keep arguing. It leads to escalation. There is lack of transparency, slow resolution, and lots of closed-door discussions. It's a witch hunt. It's always someone to blame. We have ISO 9000 that says we should treat these exceptions as learning experiences, but that doesn't happen.

[1:03] It's always a complete blame culture around trying to find the individual that's gone wrong. One of the challenges we have is that our leadership have a deep academic competence, but they don't have a hacker mindset. Staying secure means studying your adversaries and looking forwards, preempting their next move. We've got a lot of siloed behavior, and it is really frustrating for me. Product teams do not care about safety, and the safety teams do not care about performance or costs or quality, and so their interests are misaligned, and I really need them to work together.

[1:40] Lots of stress for the risk teams, which prevents us to partner, to work collaboratively. There is this us versus them culture. We're unable to innovate, and it leads to lots of inefficiencies. It's incredibly duplicative. Everyone's answering the same questions because things are constantly being deferred onto somebody else. There's no collective objective. There's no incentivization for the risk team to actually say yes to any kind of innovation. They're only incentivized to say no. My name's John Smart, and I am going to talk to you about risk and control is dead, long live risk and control.

[2:18] Those were genuine word for word quotes from people whose job is compliance. There wasn't a lot of positive in there. Who in this room is in a compliance role full time? One half, two half hands going up. Just do that again. Who's in a compliance role? Hand all the way up. Two, three. Okay, three or four. Not very many. Interesting. So we had a hypothesis. Our hypothesis is that there is a lack of safety in safety. Previously, I was leading ways of working at Barclays, 80,000 people, 327 years old. And in financial services and in any industry, trust is a huge part of being in business. And it has to be speed and control, not speed or control. Not speed with a lack of control or control with a lack of speed. So we did a deep dive on this topic.

[3:18] We interviewed lots of people. So what I'm going to share with you, anti-patterns and patterns, are based on my own learning the hard way, us making mistakes and course correcting, and also interviews with other people and other companies that we're now working with. I'm getting a little bit of feedback on the mic. So the risk and compliance, as we're hearing more and more about at the moment, is a key factor which will either enable agility, better, sooner, safer, happier, or it will prevent agility.

[3:53] So there's been a lot in the press very recently about this topic. So just doing some research for this talk, just in July alone, this is what I came up with, and I was triggered by an alert on my phone. British Airways faces a record 183 million pound fine for a data breach. That was half a million people whose personal details, including their credit card details, were breached, were made available. That was through a fraudulent website that you got redirected onto.

[4:23] That was on the 8th of July. On the 9th of July, headline on the BBC News, UK watchdog plans to fine Marriott 99 million pounds. That was 300 million customers lost their personal details, were breached from 2014 to 2018. This was a guest reservation system that was available through the internet. It was publicly accessible, and it was being breached for four years before Marriott realized. It was actually part of the acquisition of Starwood. They inherited some cybercrime. My screen has just gone blank on the monitor down here. There we go. Thank you.

[4:59] So that was about 334 million people lost their personal details, including their credit card details. Equifax, well known about. This was in the summer of 2017. And 22nd of July, the headline was, "Equifax to pay up to 700 million US dollars to settle their data breach." That was 150 million people lost their details in that one. And then 30th of July, our dear friends and thought leaders at Capital One, data breach just shows it can happen even to the best in the room, through insider access. Data breach, 106 million people's details were stolen by an ex-AWS employee who managed to breach the perimeter for AWS.

[5:51] When you look at the size of the fines, that graph on the right, this is in the UK. Previously, the maximum fine that could be given in the UK was 500,000 pounds, half a million pounds. In red now, that red circle at the bottom, that's the British Airways GDPR legislation, that's the GDPR fine, 183 million pounds. And as I'm sure a lot of you in this room know, whilst the GDPR legislation is European legislation, it's not limited to European companies. For any of the companies you work for, if you have any personal data of any European citizens, you are also liable to the GDPR legislation. That fine could have been 4% of the annual turnover. That amount, that 183 million, is actually only 1.2%. So it could have been closer to half a billion pound fine.

[6:45] So clearly the stakes are high on this topic. The NotPetya virus. So who here are familiar with the NotPetya attack that happened fairly recently? What do you think the estimated total damages were of that virus? Take a guess. 500 million. 500 million. $10 billion. And that's from the White House. The US White House estimated the total damage from the NotPetya virus at $10 billion. Interestingly, as I was doing a bit of research for this, the NotPetya virus, it actually builds upon a vulnerability in Windows, which the US NSA knew about for five years and didn't tell Windows, didn't tell Microsoft, because the US NSA was stockpiling vulnerabilities to use.

[7:39] Unfortunately, it got out there, and then it was used as an alleged Russian state-sponsored attack on the Ukraine. When you look at the damage from that virus spreading, Merck, it cost them $870 million. It cost FedEx $400 million. It cost Maersk $300 million, and it's probably higher than that. For Maersk, as is well-publicized, they didn't know where a single shipping container was on the planet. They had a complete wipe-out. So all of their PCs basically blacked out. Their phones were IP phones, so they couldn't call each other, and their phones wiped themselves because they had a synchronization back to the server. And because the server had no contacts, all of the contacts in people's phones were wiped before then losing contact.

[8:33] It was a total annihilation. Ships were turning up at ports. The port authorities couldn't download the manifest from the ship, so they couldn't unload the cargo. Some of the middle companies that sit between Maersk and the people who are receiving the goods resorted to pen and paper in terms of the manifest. The manifest, sorry. Not the manifest, the manifest for the ship. So, and good old trusty Excel as well. The only way that Maersk were able to recover the details of their shipping containers and where everything was globally was because the data center in Ghana had a power cut.

[9:14] True story. So therefore, those disks had not been infected. So somebody then had to get the data off of those disks onto a hard drive. Because of the visa situation, couldn't fly from Ghana to, in this case, Maidenhead in the UK. That's where their head office is for this, where IT are based. They couldn't go straight there, so someone had to fly out from the UK out to Nigeria. Someone from Ghana to Nigeria, where they handed over a hard drive. True story.

[9:43] Also, the CIO for Maersk didn't leave the office for three months. He slept in the office. Four hospitals were taken out by the NotPetya virus attack. Six power companies. There was a blackout in the Ukraine. Two airports were taken out. 22 banks were taken out. The ATMs weren't working. You couldn't spend money unless you had physical cash. I don't know about you, but I don't really use physical cash anymore. And 300 companies were affected by the NotPetya virus. So the stakes are quite high when it's taking out hospitals and airports and ATMs, basically.

[10:22] As every day goes by, we are more and more and more reliant upon information technology. Risk and control has to reinvent itself to stay one step ahead when the implications are this severe. And this is not governments issuing fines. This is allegedly state-sponsored attacks. So the question to ask yourselves and in the companies you're working in is what are you optimizing for? Think very consciously, what are you optimizing for in your companies? Because you can choose to optimize for various things.

[10:56] People are tribal. People will always be in a silo. Think for yourself, what tribal identity, what silos are we optimizing for in our company? Anti-pattern number one. I've had this hypothesis that there's a lack of safety within safety. What I mean by that is a lack of psychological safety, a lack of behavioral safety within people whose job is safety, a lack of psychological safety within governance, risk, and compliance. You heard that in the quotes at the beginning. That video, again, like I said, those were word for word interviews with professionals in GRC type roles.

[11:35] There is a lack of psychological safety in a lot of companies, a lot of traditional companies. So the quote, "It's a witch hunt. There's always someone to blame. The ISO 9000 series says treat exceptions as learning experiences, but it doesn't happen." It's a witch hunt. There's a blame culture. It's not my problem, and the hole's on their side of the boat, not my side. Professor Sidney Dekker, he did a great talk on the topic of safety at the DevOps Enterprise Summit in 2017 in San Francisco. For any of you that are interested in further research on this topic, I highly recommend you watch that talk.

[12:14] So let's just assume you decided you were going to fly somewhere new. You hadn't flown there before. Forget about air miles. Forget about that. And if you could choose an airline to fly with, would you choose an airline that had a high level of incidents? Or a low level of incidents? What would you choose? Low. Low. I heard more lows than high. So it turns out that the airlines with the highest levels of reported incidents have the lowest mortality rate because they have a culture of safety. Because they're open and they're honest and they talk about it.

[12:50] The airlines with the lowest level of reported incidents have the highest level of mortality. So I'm going for the one with the highest level of incidents. There is an inverse correlation, and Professor Dekker is a professor. He spent his entire career, I believe, on this topic. In fact, so much so that he went, to quote him, he went ops and he learnt how to become a co-pilot on a Boeing as a commercial airline pilot to experience it firsthand. There's an inverse correlation between the number of incidents reported, honesty, and things that actually go wrong, and that isn't just airlines, that outs every industry.

[13:26] That's every industry sector. This is about a culture and behavior. So the question is: Is your risk and control culture keeping your organization safe? That's a question to ask yourselves and your company and others in your organization. Is it safe to learn? Is it safe to say, "I don't know"? Is it safe to say, "I'm not sure"? Is it safe to say, "Well, actually, the policy doesn't cover this situation, so let's explore something different"? Is bad news buried? A lot of companies that I'm working with at the moment, bad news is most definitely buried.

[14:00] You go just two levels up an organization, and everything is green and hunky-dory. Hunky-dory, does that translate in the US? Is that an English saying? Yes. Good. Everything's fantastic. Is there safety within safety? Is there psychological safety within safety? Because if there isn't, it's not going to be very safe. Anti-pattern number two, role-based silos. So within DevOps, of course, we know this. This is obvious. We don't want to have role-based silos. It isn't so obvious in the governance, risk, and compliance profession and roles, where it is still, in my experience, very role-based.

[14:40] So imagine that blue box is your project using old terminology. That's your Gantt chart with a left and a right. That's your project in that box. And then you have some handoffs. You have some role-based organization. Those different colored people represent different roles. Then in your Gantt chart, you've got the word "sprint" about 10 times. Little parts of your work breakdown structure, just label them sprint. We're agile. It's scary how often that's the case. The solution is predetermined, big up-front design, BUFD.

[15:19] The risks are predetermined up front. BUFR. BUFD and BUFR, they're not dating apps. And it's at the point that least is known. We know the least about the risks, the least about the users, the least about the context, the least about the domain, the least amount of people who are trying to be criminal and attack what we're doing. There are handoffs, there's time slicing, and there's context switching. So in my previous role, as I was working with our GRC colleagues on this topic, in fact, actually go back to that, all of my previous roles when I'm, as a business technologist trying to deliver value, I picked the phone up to information security. It was always somebody different who I spoke to.

[16:00] It might be Mary, Jane, Joe, Steve. They didn't know my context. They didn't know what I was doing, and every single time I had to start from the beginning again and explain what my context was and what I was seeking advice on. Generally, I was told to RTFM, read the manual. The manual was a case of typing in policy slash into a browser and then searching through 300 standards to try and find the information security standard to then search through 200 pages, section 3.4.1.2.1, to try and find encrypt data at rest. Oh, there we go.

[16:35] However, it was pretty much up to me to decide which ones applied in my context and which ones didn't. It wasn't really very much in control. It didn't feel like it, to be honest. And there was so much context switching all of the time. The first learning comes in at the end when you actually put something into a production environment. The risk is backloaded. There's unplanned work. So a true story, learning through failing. One of our lighthouse initiatives that we had previously, fanfare, the lights are shining on it, the exec are looking at it. The exec all came to one particular office, one particular location, and we had to announce that there were six months of unplanned work because of information security.

[17:18] So we learnt that experiment. Ultimately, it kind of failed, but there's no such thing as a failed experiment because you're learning from experiments. We learnt from that one. We're like, "Oh, we forgot about infosec." And they weren't in the continuous everything life cycle. So we got a great learning from that failed lighthouse initiative. And then there's a big bang, literally a big bang. Yes. So the question to ask yourself is, what are you optimizing for, dear organization? And ask that question of your colleagues as well.

[17:52] Anti-pattern number three is a fixed mindset to risk. So this is partying like it's 1911. Building Ford Model Ts off a factory line. Treating risk and compliance like it's like this, like it's predictable, like it's tick box, checkbox. And again, RTFM, page 200. Read the manual, section 3.4. All your questions are answered there. It is one size fits all. In my personal experience, it's one size fits all. It's lowest common denominator. It's the most risky, the most stupid, the most risk-prone environment. Here are all of the controls that need to apply. Now, it doesn't matter what you're developing, what product you're releasing, you have to do all of these controls. Even if it's the restaurant menu application.

[18:45] And who cares if that's hacked? Because then you'll find out what we're having for dinner on Tuesday. It's maximum possible compliance, #MPC. So I believe there is a better way than maximum possible compliance. To quote Adam Banks, the CIO of Maersk, "You need a perimeter to keep criminals out, and you need to think wider." You have to assume the increasing number of alleged state-level attacks. I'm saying alleged so that I don't disappear unexpectedly. Missing after DevOps Enterprise Summit 2019. You have to assume the increasing number of state-level attacks are all going to be 100% successful. So this is a bit like ITOps going through the journey of not to try to avoid failure, but to expect failure and to deal with it gracefully.

[19:39] Mean time between failure, mean time to recovery, MTTR over MTBF. Same thing for risk and compliance. Expect to be breached. Don't build the moat and the walls and then as soon as someone gets over that perimeter, they've got free rein, which is exactly what happened with NotPetya. Once they got over the perimeter, all it took was one machine that had this particular vulnerability, was to do with Windows storing passwords unencrypted in memory. Soon as you got an elevated privilege on the network, boom, you're done.

[20:14] You're all over all the rest of the computers on that network. So you have to assume people are going to get in. I understand that Microsoft at the moment are running AI to do exactly this. So from the research I was doing, apparently Microsoft are, and come and speak to me afterwards if you work at Microsoft and you know more about this, are running AI to check for behavior within the perimeter to shut it down really quickly if it looks like it's of a malintent.

[20:44] So those are the anti-patterns. So I'm going onto the patterns now. What do you want to optimize for? Because your organization may not be set up to optimize for the right things. Obviously, goes without saying, better value, sooner, safer, happier is what I would advise you should be optimizing for. That's quality, lead time, throughput, flow efficiency. Safety is agile, not fragile. Happier is happier colleagues, customers, citizens, and climate because it's not at any expense to society or the planet. So we're doing a double-click here on safer, which is on the right there. Double-click on agile, not fragile.

[21:25] And it's people, process, tooling in that order. It is not tooling, process, people. Most companies approach this with tooling, process, people. My view on this is it's people, process, tooling. In fact, it's 90% people first. So pattern number one, people, psychological safety. Safety within safety. To quote Professor Dekker at the DevOps Enterprise Summit 2017 from, again, as an academic and not just an academic, but a practitioner, from lots of studies around safety across industries, what they found is there are a number of factors in things that go wrong.

[22:07] Those factors are human error, guidelines not followed, communication failures, miscalculations, and procedural violations. Human error, not following the process. Typical. I think we should fire some of these people. So then they looked in the factors in things that go right, and the case study he talks about is at a hospital. But again, this is across many industries. So the factors in things that go right: human errors, guidelines not followed- ... communication failures, miscalculations, and procedural violations. Dear me. Good job we didn't fire those people.

[22:51] They're the same factors in things that go wrong and things that go right are the same factors. So just be careful when you're spending too much time on your root cause analysis, because it isn't about what's going wrong, it's about what's going right. To quote Professor Dekker, "The difference between things going wrong and things not going wrong is not in the absence of negatives, it's in the presence of positives." It's not in the absence of negatives, it's in the presence of positives.

[23:23] Or it's in the absence of positives when things go wrong. So there are certain positive traits and then, again, this is across industry. Those things are, number one, the ability to say stop. Number two, past success is not taken as a guarantee of future success. Number three, diversity of opinion and dissent. Number four, keeping discussion on risk alive. Those is a distillation. They are a distillation of the factors for things that go right. Now, none of those are process or tooling.

[24:03] All of those are behavior. They're people. It's how people show up. It's how they behave. It's how they're incentivized to behave. The ability to say, "No, boss, you're wrong. I disagree. This is risky. I don't think we should be doing this." Or the ability to say, "I know this went right 100 times before, but something doesn't feel right about this to me. This is ever so slightly different," or, "This is not covered by our policy. I've RTFM'd, but it's not covered by the FM."

[24:32] "So therefore, I think we need to do something different here because I can't just apply 3.4.2 anymore." Diversity of opinion, dissent. "No, boss, you're wrong. I think you're wrong. I have a hypothesis you're wrong."Keep discussion on risk alive. Well, in this context, I think we might need to try this, this, this, or this. It's all about behavior. So there's a thing here around called safety one and safety two. Again, if you're interested in doing a double click on this topic, I recommend doing some research on safety two.

[25:00] Safety one is about root cause analysis, trying to fix the thing that went wrong. Safety two is more about the things that also go right. So spend your time on the things that go right in your company. Do your root cause analysis for success for where things go right, and try to pull out some of those learnings, which Professor Dekker has handily done for us here. Pattern number two, people, safety teams. So at my previous place of work and with other companies at the moment, what we did is we went from the previous role-based silos for information security, data privacy, anti-money laundering, fraud, compliance.

[25:41] We also included enterprise architecture in there as well. We had these role-based silos who were not speaking to each other. There was incentivization within the silo, and we pivoted from those to long-lived, multidisciplinary safety teams. And these complement the product development teams. These are not part of the product development teams. They complement them as like a secondary team. Bless you. So these safety teams, they're multidisciplinary, they're small, they're long-lived, they are value stream aligned. They are not project aligned. They are product and value stream aligned.

[26:20] And the point around them being long-lived is you go through forming, storming, norming, performing, and you stay together. And you know where the bodies are buried because you buried them there. Pattern number three, people, shared purpose. So safety team, like I said, is aligned to a value stream. This is product over project, long-lived products on long-lived value streams. And so therefore, there's a shared purpose because this value stream has a series of shared missions, OKRs, objectives and key results, business outcomes. So collectively, the identity here in financial services could be mortgages. It could be lending.

[27:00] For Adidas, it could be trainers. It could be mobile phone, digital app, et cetera. So whatever your long-lived product is, you have a shared purpose and shared outcomes. You have a shared accountability. So no longer is this the intent here, and it takes time to get there. It's not about the holes on their side of the boat. It's like we're all in the boat together, the hole's in the boat. So let's fix this together. And it's team over individuals. This is about aligning for a tribal identity around the value stream. Our identity is mortgages, lending, savings, trainers, trench coats, helicopter engines, healthcare, whatever it is your company does.

[27:43] You're customer aligned, so you get to understand the unarticulated needs of the customer. It's context sensitive, so you can apply not everything in the manual, but you apply what's necessary in your context. It's optimized for learning. So you succeed or fail together. I'll just pause there while some of the cameras go up. So pattern number four is intelligent control. So note there were three patterns there on people before we even got to process. Pattern number four, process, intelligent control. So this is the process that we implemented at my previous place of work. This is 100% of change at my previous place of work now goes through this process.

[28:28] There's a change about every, I think, about every eight seconds, in a highly regulated environment globally. And this is also what we are doing with some other companies as well. So you have your business outcomes coming in on the left. Those are OKRs, objectives and key results. They're your three-month outcome hypotheses. We believe that doing some work on the mobile phone app will allow us to sell more trainers. We know it's successful when, number one, number two, number three. You have your product teams and you have your safety team, and there's a handshake.

[28:59] So the trigger here is on an OKR. So once every three months, there's a trigger for a conversation. There's an engagement point, and you set the frequency. So if you're developing the restaurant menu application, the frequency will be very low. Like, I'll see you again in three months' time. We don't need to speak. If you're developing an internet-facing payments processing application with a high attack surface, we're going to speak every day. So we set the context-sensitive level of human interaction. Could be daily, weekly, monthly, quarterly.

[29:31] We then have evolutionary artifacts. So this was Wiki, for example, Confluence. So you've got emerging design, emergent technology architecture, data architecture, business architecture, et cetera, and GRC, and it's emergent. It's not Word documents. You have a GRC catalog. So we went through 300 standards, and we created risk stories. So we took section 3.4.1, and we created risk story number 10. We wrote it in a structured format with acceptance criteria. So we had a standard GRC catalog. We then automated the pushing of those into Jira or Rally or VersionOne or whatever tool an organization is using. So it's not 10 Excel spreadsheets on 10 different SharePoint sites like it used to be.

[30:15] They can be customized to your context. Must do, should do, could do. The must do risk stories were tagged to a given future release, which meant you couldn't put the functionality that would potentially cause a risk issue into production until you had implemented your mandatory risk stories. Other functionality unrelated to that, you still could be doing 100 deploys a day. This was really about addressing the risks of the software you're about to put into production. We got an automatic callback when a risk story was moved to done in Jira or tool of your choice. We got a callback back up into the control tool. So it went from red to green. We had a continuous everything process with a heartbeat and that health indicator at the top there. We had a virtual andon cord.

[31:01] Anybody at any point could press a button and a light would flash up in red, which everybody could see that red. So if information security were, for example, not engaging on the value stream, the product team on the value stream could press that button, big red flashes up, and the group CIO got a summary of those reds, as did the heads of the risk and compliance functions. So then you have a human-to-human conversation around, well, why is there a lack of interaction? Why is there a problem here? And then you solve it.

[31:31] So then you have DevSecOps, then we have automated testing, and we have the validate of the release. We have a red and a green. Then the product owner presses a button which says, "I attest that this is now ready to go into production, and these mandatory risk stories have been implemented and tested." At which point it goes into production, and then you can do 100 deploys a day from that point on. I'm just going to pause while the phones go up.

[31:58] So this is the process. Like I said, this is live for 100% of change at my previous place of work, for like I said, about a change every eight seconds or so. And we had control reporting, which detected left to right and right to left. Things that were going left to right into production that didn't have the mandatory risk stories implemented, that shows up on a formal report, part of the control environment. Right to left, someone's put a binary in production, and we can't trace it back to this process.

[32:25] That shows up on a report as well. And that's what the group CIO reviews as part of a formal control mechanism, which keeps the regulators happy. Pattern number five, install traceability. So this is from DevSecOps to SecDevSecOpsSec. DevSecOps is not enough. You've got to have a conversation about security before you write a single line of code. It's not DevSecOps. So you've got your portfolio outcomes and your GRC catalog. You've got your work, for example, in Jira. You've got security scanning, SAST and DAST, static and dynamic security scanning. You've got ops. You've got SRE, site reliability engineering.

[33:07] And then you've got security at the end as well. And security at the end is red teaming, for example. Chaos monkey. Infect monkey. Ethical hacking. People who are trying to take down your company and your IT systems, and it's ethical hacking. It's friendly hacking. You've employed a hacking team to see how well they do. I was doing, I think it was an article that was forwarded to me this morning, where there's one company who have staycations, and there's certain people who are told to give wrong answers to questions.

[33:41] They're deliberately told to delay responding to emails and to give the wrong answers to questions as part of the ethical hacking in the company to create a bit of chaos. I love that. That's awesome. It's great. And by the way, that's tooling. So we implemented an intelligent control layer, which was a light layer. It didn't really master any data, but it joined together the systems from portfolio management to the GRC catalog to where the work is done through to ServiceNow or other system for the path to production.

[34:16] So we had a view across all of them. Six things to getting started. Number one, start small, learn fast. Think big, start small, learn fast. Number two, engage leaders. Engage leaders within governance, risk, and compliance. So go to the head of InfoSec, the head of data privacy. You'll have innovators. You'll have early majority, late majority, and laggards. Not everybody will go, "hell yes." Some will say, "hell yes." Some will say, "hell no." Find the hell yes, start with them. Invite the first value stream and the first safety team, the rule of one.

[34:48] Nail it before you scale it. One team, one location, one experiment. Get it working before you go to the second team and the second experiment. Don't big bang it. People, focus on effective conversations. Process, small safe-to-learn experiments. And then tooling, minimal viable tooling to start with. Again, think big, start small on all of this stuff. And coming up next is a video, a one-minute video with quotes from, again, genuine quotes from people who have lived that journey that I've just described, that pivot in ways of working. So here are some quotes from people who are in that way of working.

[35:30] Now it feels like 80% of my time is on proactive work that keeps our customers safer. I feel like I'm adding more value and my personal engagement here is higher, so I can see how I'm helping. It was a bit of a learning curve at first. I had to understand the team's work, the products they were working on, and then I could understand the risks, and they got to understand the risks that are out there that might affect them. And they also now understand the mitigations they can put in place to make those things safe for the business and for the users.

[36:01] So now I'm really confident they'll do the right thing, and the evidence that we need about how they've mitigated those things will just be collected as part of their normal way of working. This year, we've made good progress, and our management is now prepared to trust intelligent control as a proven method for managing risk. It's very efficient. So we've adopted a new approach to staffing our risk and control functions, where individuals rotate from delivery teams into safety teams. That's really improved communication and mutual understanding, actually, and created a culture of collaboration rather than conflict around managing risk.

[36:39] So in summary, learn fast, stay safe together. Thank you.