WEBVTT 1 00:00:00.120 --> 00:00:02.200 Have you ever found yourself, you know, struggling with a 2 00:00:02.240 --> 00:00:05.519 really complex industry standard. You see all the requirements the once, 3 00:00:05.879 --> 00:00:08.839 but you just wish someone would clearly lay out the hows. 4 00:00:09.240 --> 00:00:13.279 Yeah, that's a common frustration, absolutely, and today that's exactly 5 00:00:13.320 --> 00:00:17.120 what we're diving into information security and specifically how you 6 00:00:17.160 --> 00:00:22.000 actually implement ISOIE two seven thousand and one point two 7 00:00:22.160 --> 00:00:22.960 zero one. 8 00:00:22.839 --> 00:00:26.199 Team, the big standard for information and security management systems 9 00:00:26.440 --> 00:00:27.359 or an isms. 10 00:00:27.480 --> 00:00:31.280 Right, it's the benchmark. It's comprehensive, really critical stuff, but 11 00:00:31.359 --> 00:00:34.159 it often leaves people asking, Okay, great, but how do 12 00:00:34.200 --> 00:00:35.560 we do this in practice? 13 00:00:35.799 --> 00:00:38.039 That is the key question, isn't it? ISOSO one two 14 00:00:38.079 --> 00:00:40.200 seven zero one tells you what you need to do 15 00:00:41.159 --> 00:00:44.640 perform risk assessments, produce that statement of applicability, But it's 16 00:00:44.679 --> 00:00:45.759 not prescriptive on the how. 17 00:00:45.920 --> 00:00:48.799 It describes the destination, not the root precisely. 18 00:00:48.960 --> 00:00:50.840 And that's where our source for today comes in doctor 19 00:00:50.920 --> 00:00:53.960 David Brewer's book. It's incredibly valuable because he offers this 20 00:00:54.840 --> 00:00:59.039 really fine tune, actionable methodology. It fills in those practical gaps. 21 00:00:59.280 --> 00:01:02.399 Okay, So our mission today is to unpack doctor Brewer's 22 00:01:02.439 --> 00:01:05.040 approach for you. We want to take what can feel 23 00:01:05.079 --> 00:01:07.799 like a daunting list of rules and turn it into 24 00:01:07.879 --> 00:01:11.719 a clear, confident way to manage your information security risks. 25 00:01:12.280 --> 00:01:14.400 So you walk away knowing the practical how to. 26 00:01:14.560 --> 00:01:18.319 Exactly ready to tackle this with real clarity. So let's 27 00:01:18.319 --> 00:01:22.640 just ground ourselves again ISOIE twenty seven sous or one 28 00:01:22.719 --> 00:01:26.319 point two zero one team. It's all about helping organizations 29 00:01:26.359 --> 00:01:30.480 put controls in place to get information security risks down 30 00:01:30.519 --> 00:01:31.640 to an acceptable level. 31 00:01:31.760 --> 00:01:35.239 Right. But the thing is every organization is different. 32 00:01:35.079 --> 00:01:37.920 Your business, your environment, the tech you use. It all 33 00:01:37.920 --> 00:01:38.400 means your. 34 00:01:38.359 --> 00:01:41.719 Risks are unique, absolutely, and the standard reflects that. It 35 00:01:41.760 --> 00:01:45.040 requires you to define your risk appetite basically, how much 36 00:01:45.120 --> 00:01:46.079 risk are you okay with? 37 00:01:46.200 --> 00:01:47.760 That's your threshold exactly. 38 00:01:48.000 --> 00:01:49.879 Then you do a risk assessment to figure out which 39 00:01:49.959 --> 00:01:52.879 risks go over that threshold. Then you start risk treatment, 40 00:01:53.400 --> 00:01:55.079 applying controls to bring those. 41 00:01:55.000 --> 00:01:57.359 Risks down, and the end result of that is the 42 00:01:57.400 --> 00:01:58.640 statement of applicability. 43 00:01:58.760 --> 00:02:02.719 The SOA at your documental list of controls, and doctor 44 00:02:02.719 --> 00:02:05.480 Brewer's method gives you a really systematic way to get 45 00:02:05.519 --> 00:02:08.680 through all that, offering practical steps where you know other 46 00:02:08.719 --> 00:02:10.800 guidance might be a bit theoretical. 47 00:02:10.280 --> 00:02:12.639 Okay, But before we jump into the how of doctor 48 00:02:12.639 --> 00:02:15.120 Brewer's method, let's just get really clear on what we 49 00:02:15.199 --> 00:02:16.080 mean by risk here. 50 00:02:16.240 --> 00:02:20.400 Good idea doctor Brewer uses the definition from ISO thirty 51 00:02:20.400 --> 00:02:24.360 one thousand. Risk is the effect of uncertainty on objectives. 52 00:02:24.560 --> 00:02:28.479 Uncertainty on objectives and effect here doesn't just mean bad stuff. 53 00:02:28.520 --> 00:02:31.680 Correct An effect is just a deviation from what you 54 00:02:31.759 --> 00:02:33.520 expect to be positive, could be negative. 55 00:02:33.879 --> 00:02:36.240 Risk can have an upside, But for today, for ISO 56 00:02:36.360 --> 00:02:39.000 twenty seven and thirty zero one, we're mostly focused on 57 00:02:39.120 --> 00:02:40.400 managing the negative side. 58 00:02:40.439 --> 00:02:43.759 That's our focus here, Yes, managing those potential negative impacts, 59 00:02:43.919 --> 00:02:46.520 which leads us nicely into doctor Brewer's preferred way to 60 00:02:46.520 --> 00:02:50.000 do the risk assessment, the event consequence method. His approach 61 00:02:50.039 --> 00:02:53.240 is also backed by ISO thirty one thousand and BS 62 00:02:53.479 --> 00:02:56.360 seven seven ninety nine three point two zero one team, 63 00:02:56.759 --> 00:02:59.039 and honestly, it's a big improvement over older ways of 64 00:02:59.039 --> 00:02:59.599 doing things. 65 00:03:00.120 --> 00:03:02.599 A big improvement. You say, what was wrong with the 66 00:03:02.639 --> 00:03:06.199 old asset threat vulnerability method that was common in say 67 00:03:06.240 --> 00:03:09.080 the two thousand and five version of ISO twenty seven 68 00:03:09.159 --> 00:03:11.919 thousand and one. What made this shift necessary? 69 00:03:12.840 --> 00:03:15.919 Well, it had some real drawbacks. For one, it really 70 00:03:15.960 --> 00:03:19.120 struggled with things like zero day vulnerabilities. 71 00:03:18.439 --> 00:03:21.520 Because you wouldn't know the vulnerability existed yet exactly. 72 00:03:21.560 --> 00:03:23.680 The model kind of implied you needed to know the 73 00:03:23.759 --> 00:03:27.439 vulnerability to assess the risk related to it, which isn't realistic. 74 00:03:27.680 --> 00:03:30.960 It also tended to frame risk in very technical language, 75 00:03:31.080 --> 00:03:31.599 making it. 76 00:03:31.560 --> 00:03:35.159 Hard for maybe senior management to connect. 77 00:03:34.759 --> 00:03:38.719 With precisely, hard to grasp the actual business impact sometimes, 78 00:03:39.039 --> 00:03:43.120 and it could miss broader risks, societal things, operational issues 79 00:03:43.240 --> 00:03:46.199 that didn't fit neatly into that ATV model. The event 80 00:03:46.240 --> 00:03:48.800 consequence method is simpler. It focuses on things that can 81 00:03:48.800 --> 00:03:51.960 actually happen, events and what the fallout would be, the consequences. 82 00:03:52.000 --> 00:03:55.039 It's much more relatable, much more comprehensive for everyone involved. 83 00:03:55.120 --> 00:03:57.960 That makes a lot of sense. Accessibility is key. So 84 00:03:58.000 --> 00:04:00.919 how does this event consequence method work? You at four steps? 85 00:04:01.280 --> 00:04:06.280 Yes, four steps, pretty straightforward. First, you identify risks. You 86 00:04:06.360 --> 00:04:08.599 do this by pairing an event with its potential consequence. 87 00:04:08.639 --> 00:04:09.520 Okay, give us an example. 88 00:04:09.560 --> 00:04:12.879 Doctor Brewer uses this one. A laptop is stolen. That's 89 00:04:12.919 --> 00:04:18.279 your event. The consequence undesirable disclosure of personally identifiable information PII. 90 00:04:18.480 --> 00:04:22.519 Okay, clear, event consequence, got it? What's step two? 91 00:04:22.560 --> 00:04:27.480 Step two, assess the severity of that consequence. Doctor Brewer 92 00:04:27.519 --> 00:04:32.600 suggests using a monetary scale, but crucially a logarithmic one logarithmic. 93 00:04:32.639 --> 00:04:36.079 Why logarithmic because it lets you handle a huge range 94 00:04:36.120 --> 00:04:38.759 of impacts consistently. You could have a ten pound consequence 95 00:04:39.160 --> 00:04:41.759 or one hundred million one. A log scale lets you 96 00:04:41.800 --> 00:04:45.240 map both onto a single comparable scale. Value like ten 97 00:04:45.319 --> 00:04:46.839 k might be a three to one million might be 98 00:04:46.879 --> 00:04:49.560 a five. Even values in between like four point seven 99 00:04:49.600 --> 00:04:51.120 for five hundred pounds are meaningful. 100 00:04:51.240 --> 00:04:53.600 Ah okay, So it compresses the range but keeps the 101 00:04:53.680 --> 00:04:56.639 relative differences meaningful. It makes very different scales of impact 102 00:04:56.639 --> 00:04:57.720 comparable exactly. 103 00:04:57.800 --> 00:05:00.720 It ensures you can properly compare and priority whether it's 104 00:05:00.759 --> 00:05:03.319 a small hit or a catastrophe. Step three you assess 105 00:05:03.360 --> 00:05:05.439 the likelihood of the event happening the full four row 106 00:05:05.480 --> 00:05:06.279 frequency or likely? 107 00:05:06.399 --> 00:05:07.560 And is that logarithmic two? 108 00:05:07.959 --> 00:05:11.800 Yes, also a reciprocal time logerowidth mix scale. Think about it. 109 00:05:11.800 --> 00:05:15.279 How else do you consistently compare something that might happen 110 00:05:15.319 --> 00:05:18.959 once a century versus something happening I don't know, thousands 111 00:05:19.000 --> 00:05:19.800 of times a second. 112 00:05:19.920 --> 00:05:21.199 Right, that's a vast difference. 113 00:05:21.319 --> 00:05:23.959 This scale gives you that range. Once a year might 114 00:05:23.959 --> 00:05:27.560 be scale value two, every minute could be seven point eight. 115 00:05:28.079 --> 00:05:32.600 It standardizes frequency assessment across wildly different scenarios. 116 00:05:32.639 --> 00:05:35.839 That standardization seems really powerful for making comparisons. 117 00:05:35.920 --> 00:05:39.160 It is, and it leads directly to step four to 118 00:05:39.279 --> 00:05:42.160 termine the risk level. Because you're using log scales, you 119 00:05:42.160 --> 00:05:45.279 don't actually multiply likelihood and severity in the usual sense. 120 00:05:45.519 --> 00:05:46.920 You just add their scale values. 121 00:05:47.000 --> 00:05:48.040 Oh, a simple addition. 122 00:05:48.160 --> 00:05:50.879 Simple addition, a likelihood of three plus a consequence of 123 00:05:50.879 --> 00:05:54.160 two equals a risk level of five. Super easy to 124 00:05:54.199 --> 00:05:56.720 calculate and compare different risks across the board. 125 00:05:56.879 --> 00:05:59.480 Now, to make this really practical for you, doctor Brewer 126 00:05:59.600 --> 00:06:03.800 doesn't leave it there. He actually identifies twelve standard events. 127 00:06:04.199 --> 00:06:07.839 These aren't just abstract, they cover common, realistic scenarios. 128 00:06:07.879 --> 00:06:10.879 You need controls for things you're actually worry about, right. 129 00:06:11.000 --> 00:06:14.079 Like S one theft or loss of mobile devices. It's 130 00:06:14.079 --> 00:06:21.120 a classic S nine hacking, obviously S three acts of God, vandals, terrorists, 131 00:06:21.160 --> 00:06:23.959 and maybe S eight fraud or error. Things like that. 132 00:06:24.199 --> 00:06:27.560 And he even helps categorize how you determine likelihood. Category 133 00:06:27.600 --> 00:06:30.199 are for random events you can't influence like acts of 134 00:06:30.240 --> 00:06:33.319 God E where you have little influence but some experience 135 00:06:33.360 --> 00:06:37.560 maybe like common malware, and O for opportunity dependent events like. 136 00:06:37.519 --> 00:06:40.519 How often a laptop actually leaves the building. That influence 137 00:06:40.600 --> 00:06:42.920 is the likelihood of it being stolen outside exactly. 138 00:06:43.000 --> 00:06:46.319 It adds consistency to assessing likelihood and all this data. 139 00:06:46.399 --> 00:06:49.920 These scales, they allow for what doctor Brewer calls risk squares. 140 00:06:50.279 --> 00:06:53.000 Risk squares like a graph Yeah, basically. 141 00:06:52.639 --> 00:06:55.199 A graphical way to plot your risks likelihood on one 142 00:06:55.199 --> 00:06:57.759 access consequence on the other, both using those log scales. 143 00:06:58.000 --> 00:07:00.360 This lets you visually represent that huge range we talked 144 00:07:00.360 --> 00:07:02.600 about once a century to thousands of times a second, 145 00:07:02.759 --> 00:07:05.560 ten pounds to one hundred million, all on one chart. Wow, okay, 146 00:07:05.759 --> 00:07:09.240 And you get these lines of constant risk. You can 147 00:07:09.279 --> 00:07:12.720 color code them green for acceptable, yellow for borderline, red 148 00:07:12.759 --> 00:07:16.560 for unacceptable. It gives you this immediate visual snapshot of 149 00:07:16.600 --> 00:07:19.839 your risk landscape. Very powerful for communication. 150 00:07:20.120 --> 00:07:24.040 That sounds incredibly useful, especially for talking to management and 151 00:07:24.120 --> 00:07:26.959 throughout this whole assessment. You're not just getting numbers, you're 152 00:07:27.000 --> 00:07:29.279 also identifying the risk owners. 153 00:07:29.120 --> 00:07:32.040 Right, absolutely critical. You need to know who has the 154 00:07:32.079 --> 00:07:36.759 actual accountability and the authority to manage each specific risk. 155 00:07:36.920 --> 00:07:39.480 So if that risk happens, everyone knows who's responsible for 156 00:07:39.519 --> 00:07:40.720 dealing with it. No confusion. 157 00:07:40.839 --> 00:07:43.120 Precisely, it assigns clear responsibility. 158 00:07:43.160 --> 00:07:46.120 Okay, so we've identified the risks, we've quantified them, we 159 00:07:46.199 --> 00:07:48.519 know who owns them. Now we need to figure out 160 00:07:48.519 --> 00:07:51.759 what to do about the unacceptable ones risk treatment. And 161 00:07:51.800 --> 00:07:55.319 this is where doctor Brewer gets quite creative with his 162 00:07:55.480 --> 00:07:56.879 tell it like a story method. 163 00:07:56.959 --> 00:08:01.279 Yes, it's a brilliant intuitive approach. The idea is, for 164 00:08:01.360 --> 00:08:04.399 each of those twelve standard events, you imagine it like 165 00:08:04.439 --> 00:08:07.759 a short movie playing out in three scenes. Yeah. Scene 166 00:08:07.800 --> 00:08:10.920 one is preventative. What measures do you have to stop 167 00:08:10.920 --> 00:08:15.480 the event from happening in the first place? Think strong building, security, 168 00:08:15.680 --> 00:08:17.759 clear policies, good training. 169 00:08:17.959 --> 00:08:19.480 Okay, stop it before it starts. 170 00:08:19.600 --> 00:08:23.360 Scene two is detective. If prevention fails and the event 171 00:08:23.439 --> 00:08:27.240 does happen, how do you detect it quickly? That's your alarms, 172 00:08:27.240 --> 00:08:30.240 your monitoring systems, your audit logs catch it in the act. 173 00:08:30.560 --> 00:08:34.039 And Scene three is reactive. Once you've detected it, what 174 00:08:34.120 --> 00:08:37.720 do you do to limit the damage the consequences? Data backups, 175 00:08:38.000 --> 00:08:41.639 encryption on stolen data, your incident response plan kicking. 176 00:08:41.360 --> 00:08:43.200 In prevent, detect, react. 177 00:08:43.360 --> 00:08:45.879 It's a sequence, it is, and this ties into something 178 00:08:45.879 --> 00:08:48.399 doctor Brewer calls the time theory, which is I think 179 00:08:48.480 --> 00:08:50.240 quite profound time theory. 180 00:08:50.480 --> 00:08:50.720 Yeah. 181 00:08:50.759 --> 00:08:53.120 It basically says that an effective control system is all 182 00:08:53.159 --> 00:08:56.840 about time. It's about detecting opportunities for bad things or 183 00:08:56.879 --> 00:08:59.720 the bad things themselves early enough to do something positive 184 00:08:59.720 --> 00:09:04.320 about them. Okay, So preventive detective controls they operate before 185 00:09:04.320 --> 00:09:06.600 the full impact. They give you a time window to 186 00:09:06.679 --> 00:09:10.080 change a likelihood. Reactive controls they happen after detection to 187 00:09:10.279 --> 00:09:11.240 lessen the severity. 188 00:09:11.559 --> 00:09:14.120 So it forces you to think about the timing of 189 00:09:14.159 --> 00:09:17.120 your controls, not just whether you have them. That really 190 00:09:17.120 --> 00:09:18.559 does shift the perspective. 191 00:09:18.720 --> 00:09:22.720 It does. It's about building resilience through timely intervention. 192 00:09:23.120 --> 00:09:25.840 Let's make that concrete with the stolen laptop story again 193 00:09:26.240 --> 00:09:30.200 using this three scene approach. Okay, preventative might be say 194 00:09:30.480 --> 00:09:35.320 a strict policy no company laptops leave the main office 195 00:09:35.639 --> 00:09:37.720 period enforced at the door. 196 00:09:37.840 --> 00:09:39.360 Good preventive control. 197 00:09:39.399 --> 00:09:43.360 Detective could be maybe a GPS chip in the laptop 198 00:09:43.399 --> 00:09:46.000 that sends an alert if it crosses a defined boundary, 199 00:09:46.000 --> 00:09:47.279 a geofence. 200 00:09:46.879 --> 00:09:50.039 Quick detection if the prevented control fails or is it used. 201 00:09:49.799 --> 00:09:52.279 And react it well. That's things like having strong encryption 202 00:09:52.360 --> 00:09:54.159 on the hard drive so the data is useless to 203 00:09:54.200 --> 00:09:57.039 the thief, or having the ability to remotely wipe the 204 00:09:57.080 --> 00:09:58.799 device once you confirm it's gone. 205 00:09:58.919 --> 00:10:01.639 Exactly you're writing script for how you'll handle that specific 206 00:10:01.679 --> 00:10:02.679 event seen by scene. 207 00:10:02.759 --> 00:10:03.919 It makes it very practical. 208 00:10:04.039 --> 00:10:07.240 And he goes further categorizing how different controls behave within 209 00:10:07.320 --> 00:10:11.440 these stories. There are in factor controls like passwords. Their 210 00:10:11.480 --> 00:10:14.000 strength depends on how hard they are to guess. They 211 00:10:14.080 --> 00:10:17.120 reduce likelihood by a factor of n. Then there's excess. 212 00:10:17.559 --> 00:10:20.000 That's where we replace one consequence with a smaller one, 213 00:10:20.480 --> 00:10:23.799 like insurance paying out after a theft. You still have 214 00:10:23.879 --> 00:10:27.360 the disruption, maybe a deductible, but the main financial loss 215 00:10:27.399 --> 00:10:28.120 is covered, right. 216 00:10:28.159 --> 00:10:31.039 You swap a big loss for a smaller, manageable one. 217 00:10:31.360 --> 00:10:34.960 And strangulation. This is where a control works fine up 218 00:10:34.960 --> 00:10:37.600 to a point, but gets overwhelmed if the event happens 219 00:10:37.639 --> 00:10:41.120 too often or too intensely. Think of one person trying 220 00:10:41.120 --> 00:10:44.360 to handle a sudden flood of security alerts. They just 221 00:10:44.399 --> 00:10:47.120 can't keep up. The control effectively fails. 222 00:10:47.799 --> 00:10:51.840 Understanding those failure points is crucial, so doctor Brewer calls 223 00:10:51.879 --> 00:10:54.440 this storytelling the optimum approach. 224 00:10:54.639 --> 00:10:57.639 Yes, because you use it as a design tool. You're 225 00:10:57.679 --> 00:11:01.240 proactively designing your response, constantly asking okay, but what if 226 00:11:01.279 --> 00:11:02.639 this part fails, what's next? 227 00:11:02.799 --> 00:11:05.080 It sounds like it really builds security awareness across the 228 00:11:05.159 --> 00:11:08.120 organization much better than just ticking boxes on a control list. 229 00:11:08.360 --> 00:11:12.600 Absolutely foster's genuine understanding of how security works in your context. 230 00:11:12.759 --> 00:11:14.879 The goal is always that happy ending where the risk 231 00:11:14.960 --> 00:11:17.279 left over after your story plays out, the residual risk 232 00:11:17.559 --> 00:11:18.799 is actually acceptable to you. 233 00:11:19.080 --> 00:11:21.600 Okay, so you've done the assessment, You've designed your treatments 234 00:11:21.679 --> 00:11:23.919 using these stories. How do you package all this up? 235 00:11:24.279 --> 00:11:25.960 That brings us back to the statement of a peck 236 00:11:25.960 --> 00:11:28.200 capability the SOA exactly. 237 00:11:28.440 --> 00:11:31.679 The SOA is the formal output. It's your comprehensive catalog, 238 00:11:32.279 --> 00:11:36.440 your inventory of all your information security controls. It's a 239 00:11:36.480 --> 00:11:39.919 mandatory document for ISO twenty seven thousand zero one. 240 00:11:40.120 --> 00:11:41.200 And what has to be in it. 241 00:11:41.480 --> 00:11:45.000 Several key things. All the necessary controls you decided you 242 00:11:45.039 --> 00:11:48.039 needed based on your risk treatment stories. Okay, you need 243 00:11:48.200 --> 00:11:51.360 justification for why you included each one. You need to 244 00:11:51.399 --> 00:11:54.600 state clearly whether each control is actually implemented or not right. 245 00:11:54.639 --> 00:11:58.039 Status is important, and crucially, if you decide not to 246 00:11:58.080 --> 00:12:01.120 implement any of the controls listed in and of the standard, 247 00:12:01.519 --> 00:12:03.480 you have to justify those exclusions too. 248 00:12:03.799 --> 00:12:07.279 Let's just quickly clarify ANXA for anyone who might not 249 00:12:07.360 --> 00:12:08.399 live and breathe this stuff. 250 00:12:08.480 --> 00:12:12.480 Good point. ANNXA is basically ISO twenty seven thousand zero 251 00:12:12.519 --> 00:12:16.039 one's big reference list of common security controls. Think of 252 00:12:16.080 --> 00:12:19.519 it as a library of good practices, covering everything from 253 00:12:19.519 --> 00:12:22.480 access control to cryptography to physical security. 254 00:12:22.519 --> 00:12:24.840 It's the standard's baseline checklist, right. 255 00:12:25.320 --> 00:12:28.600 It provides that common language a solid starting point, but 256 00:12:28.720 --> 00:12:32.240 relying only on NXA has a weakness, which is, if 257 00:12:32.279 --> 00:12:36.600 your risk assessment, your storytelling identifies a control you absolutely need, 258 00:12:36.960 --> 00:12:40.519 but that control just doesn't happen to be an ANXA, 259 00:12:40.639 --> 00:12:43.600 just comparing your list to ANNEXA won't tell you you're 260 00:12:43.600 --> 00:12:45.519 missing something important from your own assessment. 261 00:12:45.600 --> 00:12:48.840 Ah. I see ANNXA is a reference, not the definitive 262 00:12:49.000 --> 00:12:52.200 list of your necessary controls. So how does doctor Brewer 263 00:12:52.440 --> 00:12:54.440 handle that potential gap? 264 00:12:54.600 --> 00:12:57.440 Through what he calls the cross checking process. It's vital 265 00:12:57.720 --> 00:13:00.960 you take the necessary controls you identified yourself through your 266 00:13:01.000 --> 00:13:03.320 event consequence analysis and storytelling. 267 00:13:03.399 --> 00:13:04.960 Your optimum approach. 268 00:13:04.639 --> 00:13:08.000 List exactly, and you compare that list against NXA. It's 269 00:13:08.000 --> 00:13:11.480 not about replacing your list with ANXA. It's about validating 270 00:13:11.480 --> 00:13:11.960 your list. 271 00:13:11.840 --> 00:13:14.200 Against NXA, like checking your work. 272 00:13:14.279 --> 00:13:18.200 Precisely a smart cross reference. And during this you might 273 00:13:18.240 --> 00:13:21.120 find different types of controls. You'll have your necessary controls 274 00:13:21.159 --> 00:13:23.320 that do map do NXA. Yeah, you might have custom 275 00:13:23.360 --> 00:13:26.120 controls ones you need that just aren't in NXA at all. 276 00:13:26.320 --> 00:13:30.039 You might find obviated controls. This is interesting. Say you 277 00:13:30.080 --> 00:13:34.679 implement a really strong custom control, like completely banning removable media. 278 00:13:35.200 --> 00:13:38.600 That custom control makes the standard ANXA control about managing 279 00:13:38.679 --> 00:13:41.879 removable media unnecessary or obviated. 280 00:13:42.159 --> 00:13:45.080 Right, Your custom control super sees it exactly. 281 00:13:45.320 --> 00:13:47.559 And then you have variants which are just your specific 282 00:13:47.600 --> 00:13:50.080 way of implementing a general ANXA control. 283 00:13:50.320 --> 00:13:54.000 That level of detail ensures a really accurate picture. And 284 00:13:54.080 --> 00:13:56.879 I remember you mentioning. Doctor Brewer goes even further with 285 00:13:56.960 --> 00:13:58.840 a reference control superset. 286 00:13:59.000 --> 00:14:01.960 Yes, this is really forward thinking. He doesn't just use 287 00:14:02.080 --> 00:14:06.000 NXA as the reference. His superset includes controls from NXA, 288 00:14:06.200 --> 00:14:09.480 but also anticipates controls likely to appear in future versions 289 00:14:09.519 --> 00:14:12.480 of related standards, like ISO twenty seven thousand, and two, 290 00:14:12.759 --> 00:14:15.399 and it fills in gaps he identified in the current standards, 291 00:14:15.600 --> 00:14:17.679 especially around detective and reactive measures. 292 00:14:17.720 --> 00:14:21.039 So using his superset makes your ISMS more robust now 293 00:14:21.080 --> 00:14:23.879 and potentially saves you work when the standards update later. 294 00:14:24.240 --> 00:14:27.480 That's the idea, better security for you now and less 295 00:14:27.480 --> 00:14:31.720 rework down the line. And importantly, using these extra reference 296 00:14:31.759 --> 00:14:35.600 controls doesn't add burden to your SOA documentation because you 297 00:14:35.639 --> 00:14:38.559 only need to justify excluding controls that are actually in 298 00:14:38.840 --> 00:14:40.399 the current NXA. Got it. 299 00:14:40.840 --> 00:14:43.559 So the SOA itself, how does it look? Does it 300 00:14:43.600 --> 00:14:45.960 have to follow the NXA structure? 301 00:14:46.159 --> 00:14:49.399 Not necessarily it can. That's the traditional layout, but you 302 00:14:49.440 --> 00:14:52.120 can also use a more modern layout, maybe grouping controls 303 00:14:52.159 --> 00:14:56.399 by pillars like organizational people physical tech controls. The key 304 00:14:56.399 --> 00:15:00.279 thing is clarity and accuracy because remember auditors, they view 305 00:15:00.279 --> 00:15:02.279 your SOA not just annexday and isolation. 306 00:15:02.559 --> 00:15:04.840 The SOA is the real evidence of your system, it 307 00:15:04.879 --> 00:15:05.240 really is. 308 00:15:05.279 --> 00:15:08.960 It's accuracy that justifications. That's what demonstrates your conformity. 309 00:15:09.240 --> 00:15:12.399 So you've built the system, you've documented it in the SOA. 310 00:15:12.519 --> 00:15:15.559 What about keeping it alive? An ISMS isn't a one 311 00:15:15.600 --> 00:15:16.720 time project. 312 00:15:16.360 --> 00:15:19.799 Right, absolutely not. It's a continuous cycle. Maintaining and improving 313 00:15:19.840 --> 00:15:20.440 it is crucial. 314 00:15:20.480 --> 00:15:21.240 What does that involve? 315 00:15:21.480 --> 00:15:25.399 The standard requires regular reviews, scheduled reassessments of your risks. 316 00:15:25.720 --> 00:15:29.200 But also you need to react quickly to significant. 317 00:15:28.720 --> 00:15:32.879 Changes like new tech, new services, maybe new regulation. 318 00:15:32.600 --> 00:15:36.679 Exactly anything that can materially change your risk landscape. And 319 00:15:36.759 --> 00:15:39.919 there's a fascinating aspect here. The isms kind of has 320 00:15:39.960 --> 00:15:41.399 a self healing. 321 00:15:41.080 --> 00:15:44.039 Property self healing how so well think about it. 322 00:15:44.080 --> 00:15:47.279 If a review shows changes are needed, maybe a control 323 00:15:47.360 --> 00:15:49.840 isn't working, or risks have changed and you don't make 324 00:15:49.879 --> 00:15:54.360 those necessary updates, that inaction itself creates a non conformity 325 00:15:54.519 --> 00:15:58.799 against the standards requirement for maintenance and documented information being accurate. 326 00:15:58.919 --> 00:16:02.559 Ah, So estimate itself forces you to fix it to 327 00:16:02.600 --> 00:16:03.440 stay compliant. 328 00:16:03.519 --> 00:16:07.200 Right. It pushes you to ensure your documented system always 329 00:16:07.200 --> 00:16:09.720 reflects the reality on the ground. It's a built in 330 00:16:09.799 --> 00:16:11.399 driver for keeping things up to date. 331 00:16:11.720 --> 00:16:14.559 And that ties back to doctor Brewer's approach being future proof. 332 00:16:14.759 --> 00:16:19.600 Yes, especially using his broader reference control superset. By thinking ahead, 333 00:16:19.879 --> 00:16:23.799 anticipating changes, addressing gaps, now you're better prepared for when 334 00:16:23.879 --> 00:16:27.240 ISOI E seven thousand zero one gets its next revision 335 00:16:27.720 --> 00:16:31.120 it should mean less frantic scrambling for you later. 336 00:16:30.919 --> 00:16:33.840 You're building on a more solid, forward looking foundation. 337 00:16:34.000 --> 00:16:34.519 That's the goal. 338 00:16:34.759 --> 00:16:38.159 Okay, well, we have certainly taken a deep dive today. 339 00:16:38.200 --> 00:16:42.519 We've unpacked isoie C twenty seven hours zero one, seeing 340 00:16:42.519 --> 00:16:46.879 how doctor Brewer's methodology really tackles that how to problem 341 00:16:47.080 --> 00:16:47.519 head on. 342 00:16:47.759 --> 00:16:50.679 From the event consequence method for risk assessment to that. 343 00:16:50.639 --> 00:16:54.679 Really intuitive tell it like a story approach for designing 344 00:16:54.759 --> 00:16:56.039 risk treatments. 345 00:16:55.600 --> 00:16:59.399 And understanding how the SOA becomes your living blueprint for security. 346 00:16:59.480 --> 00:17:03.799 The takeaway for you listening is hopefully real clarity, an actionable, 347 00:17:04.000 --> 00:17:07.759 structured way to get a better handle on your information security. 348 00:17:07.359 --> 00:17:09.640 Making it less daunting, more manageable. 349 00:17:09.799 --> 00:17:12.440 Definitely. And as we wrap up, maybe here's a thought 350 00:17:12.440 --> 00:17:14.960 to leave you with, Building on that idea of proactive design. 351 00:17:15.759 --> 00:17:19.160 As threats keep changing, how much is your organization really 352 00:17:19.240 --> 00:17:21.079 thinking beyond just prevention? 353 00:17:21.319 --> 00:17:24.759 Yeah? Are you actively designing systems not just to block attacks, 354 00:17:25.039 --> 00:17:27.559 but assuming some things might get through and focusing on 355 00:17:27.680 --> 00:17:30.680 robust detection, swift reaction, effective response. 356 00:17:30.720 --> 00:17:33.799 It's that whole story. Prevent, detect, react, It's not just 357 00:17:33.839 --> 00:17:36.440 about what you managed to stop, but how well prepared 358 00:17:36.440 --> 00:17:38.599 you are to handle what you don't something to definitely 359 00:17:38.680 --> 00:17:40.799 mull over. Thank you so much for joining us on 360 00:17:40.799 --> 00:17:44.240 this deep dive today. Keep learning, keep questioning, and stay 361 00:17:44.279 --> 00:17:46.119 proactive out there. We'll catch you next time.