Speaker 1: Have you ever found yourself, you know, struggling with a
Speaker 1: really complex industry standard. You see all the requirements the once,
Speaker 1: but you just wish someone would clearly lay out the hows.
Speaker 2: Yeah, that's a common frustration, absolutely, and today that's exactly
Speaker 2: what we're diving into information security and specifically how you
Speaker 2: actually implement ISOIE two seven thousand and one point two
Speaker 2: zero one.
Speaker 3: Team, the big standard for information and security management systems
Speaker 3: or an isms.
Speaker 1: Right, it's the benchmark. It's comprehensive, really critical stuff, but
Speaker 1: it often leaves people asking, Okay, great, but how do
Speaker 1: we do this in practice?
Speaker 3: That is the key question, isn't it? ISOSO one two
Speaker 3: seven zero one tells you what you need to do
Speaker 3: perform risk assessments, produce that statement of applicability, But it's
Speaker 3: not prescriptive on the how.
Speaker 1: It describes the destination, not the root precisely.
Speaker 3: And that's where our source for today comes in doctor
Speaker 3: David Brewer's book. It's incredibly valuable because he offers this
Speaker 3: really fine tune, actionable methodology. It fills in those practical gaps.
Speaker 1: Okay, So our mission today is to unpack doctor Brewer's
Speaker 1: approach for you. We want to take what can feel
Speaker 1: like a daunting list of rules and turn it into
Speaker 1: a clear, confident way to manage your information security risks.
Speaker 3: So you walk away knowing the practical how to.
Speaker 1: Exactly ready to tackle this with real clarity. So let's
Speaker 1: just ground ourselves again ISOIE twenty seven sous or one
Speaker 1: point two zero one team. It's all about helping organizations
Speaker 1: put controls in place to get information security risks down
Speaker 1: to an acceptable level.
Speaker 3: Right. But the thing is every organization is different.
Speaker 1: Your business, your environment, the tech you use. It all
Speaker 1: means your.
Speaker 3: Risks are unique, absolutely, and the standard reflects that. It
Speaker 3: requires you to define your risk appetite basically, how much
Speaker 3: risk are you okay with?
Speaker 1: That's your threshold exactly.
Speaker 3: Then you do a risk assessment to figure out which
Speaker 3: risks go over that threshold. Then you start risk treatment,
Speaker 3: applying controls to bring those.
Speaker 1: Risks down, and the end result of that is the
Speaker 1: statement of applicability.
Speaker 3: The SOA at your documental list of controls, and doctor
Speaker 3: Brewer's method gives you a really systematic way to get
Speaker 3: through all that, offering practical steps where you know other
Speaker 3: guidance might be a bit theoretical.
Speaker 1: Okay, But before we jump into the how of doctor
Speaker 1: Brewer's method, let's just get really clear on what we
Speaker 1: mean by risk here.
Speaker 3: Good idea doctor Brewer uses the definition from ISO thirty
Speaker 3: one thousand. Risk is the effect of uncertainty on objectives.
Speaker 1: Uncertainty on objectives and effect here doesn't just mean bad stuff.
Speaker 3: Correct An effect is just a deviation from what you
Speaker 3: expect to be positive, could be negative.
Speaker 1: Risk can have an upside, But for today, for ISO
Speaker 1: twenty seven and thirty zero one, we're mostly focused on
Speaker 1: managing the negative side.
Speaker 3: That's our focus here, Yes, managing those potential negative impacts,
Speaker 3: which leads us nicely into doctor Brewer's preferred way to
Speaker 3: do the risk assessment, the event consequence method. His approach
Speaker 3: is also backed by ISO thirty one thousand and BS
Speaker 3: seven seven ninety nine three point two zero one team,
Speaker 3: and honestly, it's a big improvement over older ways of
Speaker 3: doing things.
Speaker 1: A big improvement. You say, what was wrong with the
Speaker 1: old asset threat vulnerability method that was common in say
Speaker 1: the two thousand and five version of ISO twenty seven
Speaker 1: thousand and one. What made this shift necessary?
Speaker 3: Well, it had some real drawbacks. For one, it really
Speaker 3: struggled with things like zero day vulnerabilities.
Speaker 1: Because you wouldn't know the vulnerability existed yet exactly.
Speaker 3: The model kind of implied you needed to know the
Speaker 3: vulnerability to assess the risk related to it, which isn't realistic.
Speaker 3: It also tended to frame risk in very technical language,
Speaker 3: making it.
Speaker 1: Hard for maybe senior management to connect.
Speaker 3: With precisely, hard to grasp the actual business impact sometimes,
Speaker 3: and it could miss broader risks, societal things, operational issues
Speaker 3: that didn't fit neatly into that ATV model. The event
Speaker 3: consequence method is simpler. It focuses on things that can
Speaker 3: actually happen, events and what the fallout would be, the consequences.
Speaker 3: It's much more relatable, much more comprehensive for everyone involved.
Speaker 1: That makes a lot of sense. Accessibility is key. So
Speaker 1: how does this event consequence method work? You at four steps?
Speaker 3: Yes, four steps, pretty straightforward. First, you identify risks. You
Speaker 3: do this by pairing an event with its potential consequence.
Speaker 1: Okay, give us an example.
Speaker 3: Doctor Brewer uses this one. A laptop is stolen. That's
Speaker 3: your event. The consequence undesirable disclosure of personally identifiable information PII.
Speaker 1: Okay, clear, event consequence, got it? What's step two?
Speaker 3: Step two, assess the severity of that consequence. Doctor Brewer
Speaker 3: suggests using a monetary scale, but crucially a logarithmic one logarithmic.
Speaker 3: Why logarithmic because it lets you handle a huge range
Speaker 3: of impacts consistently. You could have a ten pound consequence
Speaker 3: or one hundred million one. A log scale lets you
Speaker 3: map both onto a single comparable scale. Value like ten
Speaker 3: k might be a three to one million might be
Speaker 3: a five. Even values in between like four point seven
Speaker 3: for five hundred pounds are meaningful.
Speaker 1: Ah okay, So it compresses the range but keeps the
Speaker 1: relative differences meaningful. It makes very different scales of impact
Speaker 1: comparable exactly.
Speaker 3: It ensures you can properly compare and priority whether it's
Speaker 3: a small hit or a catastrophe. Step three you assess
Speaker 3: the likelihood of the event happening the full four row
Speaker 3: frequency or likely?
Speaker 1: And is that logarithmic two?
Speaker 3: Yes, also a reciprocal time logerowidth mix scale. Think about it.
Speaker 3: How else do you consistently compare something that might happen
Speaker 3: once a century versus something happening I don't know, thousands
Speaker 3: of times a second.
Speaker 1: Right, that's a vast difference.
Speaker 3: This scale gives you that range. Once a year might
Speaker 3: be scale value two, every minute could be seven point eight.
Speaker 3: It standardizes frequency assessment across wildly different scenarios.
Speaker 1: That standardization seems really powerful for making comparisons.
Speaker 3: It is, and it leads directly to step four to
Speaker 3: termine the risk level. Because you're using log scales, you
Speaker 3: don't actually multiply likelihood and severity in the usual sense.
Speaker 3: You just add their scale values.
Speaker 1: Oh, a simple addition.
Speaker 3: Simple addition, a likelihood of three plus a consequence of
Speaker 3: two equals a risk level of five. Super easy to
Speaker 3: calculate and compare different risks across the board.
Speaker 1: Now, to make this really practical for you, doctor Brewer
Speaker 1: doesn't leave it there. He actually identifies twelve standard events.
Speaker 1: These aren't just abstract, they cover common, realistic scenarios.
Speaker 3: You need controls for things you're actually worry about, right.
Speaker 1: Like S one theft or loss of mobile devices. It's
Speaker 1: a classic S nine hacking, obviously S three acts of God, vandals, terrorists,
Speaker 1: and maybe S eight fraud or error. Things like that.
Speaker 3: And he even helps categorize how you determine likelihood. Category
Speaker 3: are for random events you can't influence like acts of
Speaker 3: God E where you have little influence but some experience
Speaker 3: maybe like common malware, and O for opportunity dependent events like.
Speaker 1: How often a laptop actually leaves the building. That influence
Speaker 1: is the likelihood of it being stolen outside exactly.
Speaker 3: It adds consistency to assessing likelihood and all this data.
Speaker 3: These scales, they allow for what doctor Brewer calls risk squares.
Speaker 1: Risk squares like a graph Yeah, basically.
Speaker 3: A graphical way to plot your risks likelihood on one
Speaker 3: access consequence on the other, both using those log scales.
Speaker 3: This lets you visually represent that huge range we talked
Speaker 3: about once a century to thousands of times a second,
Speaker 3: ten pounds to one hundred million, all on one chart. Wow, okay,
Speaker 3: And you get these lines of constant risk. You can
Speaker 3: color code them green for acceptable, yellow for borderline, red
Speaker 3: for unacceptable. It gives you this immediate visual snapshot of
Speaker 3: your risk landscape. Very powerful for communication.
Speaker 1: That sounds incredibly useful, especially for talking to management and
Speaker 1: throughout this whole assessment. You're not just getting numbers, you're
Speaker 1: also identifying the risk owners.
Speaker 3: Right, absolutely critical. You need to know who has the
Speaker 3: actual accountability and the authority to manage each specific risk.
Speaker 1: So if that risk happens, everyone knows who's responsible for
Speaker 1: dealing with it. No confusion.
Speaker 3: Precisely, it assigns clear responsibility.
Speaker 1: Okay, so we've identified the risks, we've quantified them, we
Speaker 1: know who owns them. Now we need to figure out
Speaker 1: what to do about the unacceptable ones risk treatment. And
Speaker 1: this is where doctor Brewer gets quite creative with his
Speaker 1: tell it like a story method.
Speaker 3: Yes, it's a brilliant intuitive approach. The idea is, for
Speaker 3: each of those twelve standard events, you imagine it like
Speaker 3: a short movie playing out in three scenes. Yeah. Scene
Speaker 3: one is preventative. What measures do you have to stop
Speaker 3: the event from happening in the first place? Think strong building, security,
Speaker 3: clear policies, good training.
Speaker 1: Okay, stop it before it starts.
Speaker 3: Scene two is detective. If prevention fails and the event
Speaker 3: does happen, how do you detect it quickly? That's your alarms,
Speaker 3: your monitoring systems, your audit logs catch it in the act.
Speaker 3: And Scene three is reactive. Once you've detected it, what
Speaker 3: do you do to limit the damage the consequences? Data backups,
Speaker 3: encryption on stolen data, your incident response plan kicking.
Speaker 1: In prevent, detect, react.
Speaker 3: It's a sequence, it is, and this ties into something
Speaker 3: doctor Brewer calls the time theory, which is I think
Speaker 3: quite profound time theory.
Speaker 2: Yeah.
Speaker 3: It basically says that an effective control system is all
Speaker 3: about time. It's about detecting opportunities for bad things or
Speaker 3: the bad things themselves early enough to do something positive
Speaker 3: about them. Okay, So preventive detective controls they operate before
Speaker 3: the full impact. They give you a time window to
Speaker 3: change a likelihood. Reactive controls they happen after detection to
Speaker 3: lessen the severity.
Speaker 1: So it forces you to think about the timing of
Speaker 1: your controls, not just whether you have them. That really
Speaker 1: does shift the perspective.
Speaker 3: It does. It's about building resilience through timely intervention.
Speaker 1: Let's make that concrete with the stolen laptop story again
Speaker 1: using this three scene approach. Okay, preventative might be say
Speaker 1: a strict policy no company laptops leave the main office
Speaker 1: period enforced at the door.
Speaker 3: Good preventive control.
Speaker 1: Detective could be maybe a GPS chip in the laptop
Speaker 1: that sends an alert if it crosses a defined boundary,
Speaker 1: a geofence.
Speaker 3: Quick detection if the prevented control fails or is it used.
Speaker 1: And react it well. That's things like having strong encryption
Speaker 1: on the hard drive so the data is useless to
Speaker 1: the thief, or having the ability to remotely wipe the
Speaker 1: device once you confirm it's gone.
Speaker 3: Exactly you're writing script for how you'll handle that specific
Speaker 3: event seen by scene.
Speaker 1: It makes it very practical.
Speaker 3: And he goes further categorizing how different controls behave within
Speaker 3: these stories. There are in factor controls like passwords. Their
Speaker 3: strength depends on how hard they are to guess. They
Speaker 3: reduce likelihood by a factor of n. Then there's excess.
Speaker 3: That's where we replace one consequence with a smaller one,
Speaker 3: like insurance paying out after a theft. You still have
Speaker 3: the disruption, maybe a deductible, but the main financial loss
Speaker 3: is covered, right.
Speaker 1: You swap a big loss for a smaller, manageable one.
Speaker 3: And strangulation. This is where a control works fine up
Speaker 3: to a point, but gets overwhelmed if the event happens
Speaker 3: too often or too intensely. Think of one person trying
Speaker 3: to handle a sudden flood of security alerts. They just
Speaker 3: can't keep up. The control effectively fails.
Speaker 1: Understanding those failure points is crucial, so doctor Brewer calls
Speaker 1: this storytelling the optimum approach.
Speaker 3: Yes, because you use it as a design tool. You're
Speaker 3: proactively designing your response, constantly asking okay, but what if
Speaker 3: this part fails, what's next?
Speaker 1: It sounds like it really builds security awareness across the
Speaker 1: organization much better than just ticking boxes on a control list.
Speaker 3: Absolutely foster's genuine understanding of how security works in your context.
Speaker 3: The goal is always that happy ending where the risk
Speaker 3: left over after your story plays out, the residual risk
Speaker 3: is actually acceptable to you.
Speaker 1: Okay, so you've done the assessment, You've designed your treatments
Speaker 1: using these stories. How do you package all this up?
Speaker 1: That brings us back to the statement of a peck
Speaker 1: capability the SOA exactly.
Speaker 3: The SOA is the formal output. It's your comprehensive catalog,
Speaker 3: your inventory of all your information security controls. It's a
Speaker 3: mandatory document for ISO twenty seven thousand zero one.
Speaker 1: And what has to be in it.
Speaker 3: Several key things. All the necessary controls you decided you
Speaker 3: needed based on your risk treatment stories. Okay, you need
Speaker 3: justification for why you included each one. You need to
Speaker 3: state clearly whether each control is actually implemented or not right.
Speaker 3: Status is important, and crucially, if you decide not to
Speaker 3: implement any of the controls listed in and of the standard,
Speaker 3: you have to justify those exclusions too.
Speaker 1: Let's just quickly clarify ANXA for anyone who might not
Speaker 1: live and breathe this stuff.
Speaker 3: Good point. ANNXA is basically ISO twenty seven thousand zero
Speaker 3: one's big reference list of common security controls. Think of
Speaker 3: it as a library of good practices, covering everything from
Speaker 3: access control to cryptography to physical security.
Speaker 1: It's the standard's baseline checklist, right.
Speaker 3: It provides that common language a solid starting point, but
Speaker 3: relying only on NXA has a weakness, which is, if
Speaker 3: your risk assessment, your storytelling identifies a control you absolutely need,
Speaker 3: but that control just doesn't happen to be an ANXA,
Speaker 3: just comparing your list to ANNEXA won't tell you you're
Speaker 3: missing something important from your own assessment.
Speaker 1: Ah. I see ANNXA is a reference, not the definitive
Speaker 1: list of your necessary controls. So how does doctor Brewer
Speaker 1: handle that potential gap?
Speaker 3: Through what he calls the cross checking process. It's vital
Speaker 3: you take the necessary controls you identified yourself through your
Speaker 3: event consequence analysis and storytelling.
Speaker 1: Your optimum approach.
Speaker 3: List exactly, and you compare that list against NXA. It's
Speaker 3: not about replacing your list with ANXA. It's about validating
Speaker 3: your list.
Speaker 1: Against NXA, like checking your work.
Speaker 3: Precisely a smart cross reference. And during this you might
Speaker 3: find different types of controls. You'll have your necessary controls
Speaker 3: that do map do NXA. Yeah, you might have custom
Speaker 3: controls ones you need that just aren't in NXA at all.
Speaker 3: You might find obviated controls. This is interesting. Say you
Speaker 3: implement a really strong custom control, like completely banning removable media.
Speaker 3: That custom control makes the standard ANXA control about managing
Speaker 3: removable media unnecessary or obviated.
Speaker 1: Right, Your custom control super sees it exactly.
Speaker 3: And then you have variants which are just your specific
Speaker 3: way of implementing a general ANXA control.
Speaker 1: That level of detail ensures a really accurate picture. And
Speaker 1: I remember you mentioning. Doctor Brewer goes even further with
Speaker 1: a reference control superset.
Speaker 3: Yes, this is really forward thinking. He doesn't just use
Speaker 3: NXA as the reference. His superset includes controls from NXA,
Speaker 3: but also anticipates controls likely to appear in future versions
Speaker 3: of related standards, like ISO twenty seven thousand, and two,
Speaker 3: and it fills in gaps he identified in the current standards,
Speaker 3: especially around detective and reactive measures.
Speaker 1: So using his superset makes your ISMS more robust now
Speaker 1: and potentially saves you work when the standards update later.
Speaker 3: That's the idea, better security for you now and less
Speaker 3: rework down the line. And importantly, using these extra reference
Speaker 3: controls doesn't add burden to your SOA documentation because you
Speaker 3: only need to justify excluding controls that are actually in
Speaker 3: the current NXA. Got it.
Speaker 1: So the SOA itself, how does it look? Does it
Speaker 1: have to follow the NXA structure?
Speaker 3: Not necessarily it can. That's the traditional layout, but you
Speaker 3: can also use a more modern layout, maybe grouping controls
Speaker 3: by pillars like organizational people physical tech controls. The key
Speaker 3: thing is clarity and accuracy because remember auditors, they view
Speaker 3: your SOA not just annexday and isolation.
Speaker 1: The SOA is the real evidence of your system, it
Speaker 1: really is.
Speaker 3: It's accuracy that justifications. That's what demonstrates your conformity.
Speaker 1: So you've built the system, you've documented it in the SOA.
Speaker 1: What about keeping it alive? An ISMS isn't a one
Speaker 1: time project.
Speaker 3: Right, absolutely not. It's a continuous cycle. Maintaining and improving
Speaker 3: it is crucial.
Speaker 1: What does that involve?
Speaker 3: The standard requires regular reviews, scheduled reassessments of your risks.
Speaker 3: But also you need to react quickly to significant.
Speaker 1: Changes like new tech, new services, maybe new regulation.
Speaker 3: Exactly anything that can materially change your risk landscape. And
Speaker 3: there's a fascinating aspect here. The isms kind of has
Speaker 3: a self healing.
Speaker 1: Property self healing how so well think about it.
Speaker 3: If a review shows changes are needed, maybe a control
Speaker 3: isn't working, or risks have changed and you don't make
Speaker 3: those necessary updates, that inaction itself creates a non conformity
Speaker 3: against the standards requirement for maintenance and documented information being accurate.
Speaker 1: Ah, So estimate itself forces you to fix it to
Speaker 1: stay compliant.
Speaker 3: Right. It pushes you to ensure your documented system always
Speaker 3: reflects the reality on the ground. It's a built in
Speaker 3: driver for keeping things up to date.
Speaker 1: And that ties back to doctor Brewer's approach being future proof.
Speaker 3: Yes, especially using his broader reference control superset. By thinking ahead,
Speaker 3: anticipating changes, addressing gaps, now you're better prepared for when
Speaker 3: ISOI E seven thousand zero one gets its next revision
Speaker 3: it should mean less frantic scrambling for you later.
Speaker 1: You're building on a more solid, forward looking foundation.
Speaker 3: That's the goal.
Speaker 1: Okay, well, we have certainly taken a deep dive today.
Speaker 1: We've unpacked isoie C twenty seven hours zero one, seeing
Speaker 1: how doctor Brewer's methodology really tackles that how to problem
Speaker 1: head on.
Speaker 3: From the event consequence method for risk assessment to that.
Speaker 1: Really intuitive tell it like a story approach for designing
Speaker 1: risk treatments.
Speaker 3: And understanding how the SOA becomes your living blueprint for security.
Speaker 1: The takeaway for you listening is hopefully real clarity, an actionable,
Speaker 1: structured way to get a better handle on your information security.
Speaker 3: Making it less daunting, more manageable.
Speaker 1: Definitely. And as we wrap up, maybe here's a thought
Speaker 1: to leave you with, Building on that idea of proactive design.
Speaker 1: As threats keep changing, how much is your organization really
Speaker 1: thinking beyond just prevention?
Speaker 3: Yeah? Are you actively designing systems not just to block attacks,
Speaker 3: but assuming some things might get through and focusing on
Speaker 3: robust detection, swift reaction, effective response.
Speaker 1: It's that whole story. Prevent, detect, react, It's not just
Speaker 1: about what you managed to stop, but how well prepared
Speaker 1: you are to handle what you don't something to definitely
Speaker 1: mull over. Thank you so much for joining us on
Speaker 1: this deep dive today. Keep learning, keep questioning, and stay
Speaker 1: proactive out there. We'll catch you next time.