Understanding Cybersecurity Risk: A Practical Guide for CompTIA Exam Prep

In this episode of Technology Tap: CompTIA Study Guide, we dive deep into the concept of cybersecurity risk and why it's a critical factor in your IT skills development. Forget common myths and technical jargon — this episode breaks down risk into understandable elements: threat, vulnerability, likelihood, and impact. Perfect for CompTIA exam candidates, we provide practical IT certification tips that turn abstract fears into concrete strategies to protect your digital assets. Whether you're prepping for your CompTIA exam or interested in technology education, this discussion equips you with essential knowledge for effective tech exam prep.

We walk through inherited risk (your baseline exposure) and residual risk (what remains after controls), and explain why zero risk is a dangerous fantasy. From there, we unpack the four response strategies—avoidance, mitigation, transfer, and acceptance—using clear examples you can bring to your Sec+, Net+, or A+ studies and your day job. You’ll learn when quantitative numbers help, when qualitative scales are more honest, and how heat maps can mislead when assumptions go unchallenged.

Because modern exposure doesn’t end at your perimeter, we dive into vendor risk management: evaluating partners before you sign, setting expectations with NDAs, MSAs, SLAs, SOWs, and rules of engagement, and keeping continuous oversight to match changing realities. We also connect the dots to business impact analysis, translating risk into recovery targets with MTD, RTO, RPO, and WRT so you prioritize mission essential functions instead of treating every system the same. Finally, we clarify the role of internal and external assessments and demystify penetration testing as a snapshot that challenges assumptions rather than a guarantee of safety.

If you want security that aligns with real-world priorities, this conversation gives you the mental model and vocabulary to make better decisions under uncertainty. Subscribe, share with a teammate, and leave a review with one insight you’re taking back to your org. What risk will you accept—and why?

Turn Any Doc Into a Private Audiobook. No Subscriptions. Try WithAudio on Your Mac/PC.
100% Local AI. No cloud. No tracking. Convert URLs, PDFs & EPUBs into high-quality audio.

Chapters

• 0:00 Programming Notes And New Schedule
• 2:10 Reframing Security Around Risk
• 4:20 Threats, Vulnerabilities, Likelihood, Impact
• 8:16 [Ad] Turn Any Doc Into a Private Audiobook. No Subscriptions. Try WithAudio on Your Mac/PC.
• 8:51 (Cont.) Threats, Vulnerabilities, Likelihood, Impact
• 9:19 Inherited Versus Residual Risk
• 12:44 Analysis Vs Assessment And Heat Maps
• 17:44 Risk Responses: Avoid, Mitigate, Transfer, Accept
• 22:54 Risk Appetite, Registers, And KRIs
• 26:34 Mission Essential Functions And Recovery Targets
• 29:44 Vendor Risk, Contracts, And Governance
• 34:44 Audits, Assessments, And Pen Testing
• 38:34 Quiz Review And Key Takeaways

Transcript

SPEAKER_00: 0:27

And welcome to Technology Tap. I'm Professor J. Rod. In this episode, risk is not the enemy. Let's tap in the hospital. Hey, welcome to Technology Tap. I'm Professor J. Rock. For those of you who don't know me, I'm a professor of cybersecurity and I love helping my students have pass their A, Network Plus, and Security Plus Comp T exams. I also like to throw a little bit of history of modern technology in there since I'm a wannabe historian. Before we get into this episode, I just want to make some programming notes, or as my friend likes to say, some housekeeping. Number one, I'm all going forward, I'm only gonna do one episode a week. I was doing three episodes a week for a while, and I think it's kind of overwhelming people. I I have the feeling that if you miss one, I think I think people are just like saying, like, oh, there's too many. And after like six or seven episodes, they're like, Oh, I'm just missing too many, and then they stop listening. So I'm only gonna do one episode a week. I'm gonna do chapter 15 and chapter 16 of the security plus the Surfmaster chapters, and then that's it. I'm done with Security Plus. So starting the first week of February, I'm going to do one week of A Plus, continue that series, and then maybe one week of Tech Plus, we start that series over or anew, and then uh we'll do a history of technology week, and then I'm hoping to do interviews uh one week a month. If not, we'll think of something. I have some surprises installed, some announcements that I want to make, but I can't make them now. But I'm pretty excited. I went to Podfest and shout out for Buzz Sprout for inviting me and giving me a free ticket. But I went to a Pod Fest the weekend of the 15th to the 18th, so I kind of learned a lot of things about podcasting and what I need to know to grow my audience and stuff. This is one of the suggestions made. Don't do too many, just concentrate on the one a week and try to make that you know really, really, really good. So I told you 2026 was gonna be a different year, and you know, there's there's so many stuff that I want to mention, but I I I just can't right now. Alright, so let's get started. So before we talk about cybersecurity, I want you to do something for me. I want you to forget just for a moment everything you've been told about security being everything you've been told about security being about stopping attacks, because that's the idea. That's where most people get it wrong. Security is not about stopping everything, security is about deciding what you are willing to live with. I know that sounds strange, but that decision, that decision is called risk. Welcome back to Technology Tap. I'm Professor J-Rodd, and today we're not talking about firewalls, we're not talking about malware signatures, we're not talking about encryption algorithms. We're talking about the thing that quietly controls every security decision ever made, whatever or not the executives cared to admit it, and that is risk. Now, already now I already know what you some of you are thinking, professor. This feels abstract, this isn't technical enough, or just tell me what to memorize for the exams, and I get it because risk management doesn't feel exciting. There is no blinking terminal, there is no hacker hoodie moment. But let me tell you something. I've learned after years of teaching, consulting, and watching breaches unfold in real time, every major breach you ever studied was a risk management failure first, not a technical one, a decision one. Someone knew, someone documented it, someone accepted it, and someone moved on. And the system did exactly what it was allowed to do. Let's clear this up right now. Risk is not a virus, a hacker, a vulnerability, a missing patch. Those are ingredients. Risk is the outcome of how these ingredients interact in a real environment. And if you don't understand that, every security control that you deploy is just security theater. This is where, if you were in the classroom, I stop talking and I look around the room and I ask, who thinks that the goal to cybersecurity is to eliminate risk? And then hands will go off. And I'll ask, who has ever crossed the street? Because congratulations, you accepted the risk when you cross the street, right? You hoping that the cars obey the traffic light and don't hit you. Correct? Let's make this human. Imagine this: you live in a city, you know your neighborhood isn't perfect. Car speeds, crime exists, weather happens. You don't eliminate all risk by never leaving your house or wearing a helmet to bed or installing 10 deadbolts on your refrigerator. You manage risk. You lock the door, you look both ways before you cross the street, you decide what's reasonable. Organizations do the same thing, except with money, data, and legal exposure on the line. Now here's where we slow down because Cantia and the real world define risk using four ingredients: threat, vulnerability, likelihood, and impact. If even one of these is missing, risk collapse. Threat is a potential cause of harm. Example, malware, phishing, insider abuse, power failure, natural disasters, human error. A threat doesn't mean that something will happen. It means something could happen. Right? Rain is a threat, but it's not a guarantee. Vulnerability. A vulnerability is a weakness that a threat could exploit. Example. Unpatched software, weak passwords, poor training, bad policies, misconfigured systems. Here's the key mistake students make. They think vulnerabilities are always technical. They're not. A company with no incident response plan, that's a vulnerability. A company that never trains its employees, that's a vulnerability. Likelihood. Likelihood answers one question. How likely is this to happen here? Not globally, not hypothetically. Here. This is where experience matters. A nation-state attack on a small bakery, low likelihood. Fishing emails to staff, extremely high. Impact. Impact is damage, financial loss, legal penalties, reputational harm, operational downtime, loss of life in healthcare infrastructure. This is where executives suddenly start paying attention. And here's the formula risk exists when a threat exploits a vulnerability with significant likelihood causing meaningful impact. Remove any one of these and risk changes. No vulnerability, threat fails. No impact, nobody cares. This is where Camptea likes to trick people. They give you a scary sounding threat, a technical vulnerability. And the correct answer depends on which element of risk is actually presented. Now, what sounds dangerous? This is thinking like a professional and not memorizing terms, even though this exam is very term definition heavy. Inherited risk. Now we introduce a term student always passed, inherited risk, right? Inherited risk is the level of risk before you do anything, before firewalls, MFAs, training, policies, monitoring, inherited risk answers the question: if we did absolutely nothing, how bad would this be? Why do organizations care? Because leadership wants to know how dangerous the baseline environment is, where control matters most, what absolutely must be addressed. You don't put a security guard at every door, you put them where inherited risk is the highest, usually the front. So let me give you a couple of real-world examples. A college student, a college stores student records, right? Their names, social security numbers, financial aid data. Before controls, anyone with internal access can view it. No logging, no monitoring. That's the inherited risk is extremely high. Right? After road-based access, you put MFA, you put logging, you put audits. Now the risk drops, but it doesn't disappear. That remaining risk, well, we'll talk about that later. And this sentence I want to burn into your brain zero risk does not exist. Anyone who tells you otherwise is telling you something. Security is not a finish line, it is a moving balance. Because risk forces honestly, it forces organizations to admit what they value, what they can't protect perfectly, and what they're willing to lose. And that's uncomfortable. It's much easier to say we have security than say we accepted the risk and documented why. This is why cybersecurity professionals burn out. Not because they don't know how to secure systems, but because they don't know what isn't being fixed and why. Let's pause here. Risk is not failure, risk is a choice. Alright. How do organizations pretend to measure risk and how professionals learn to see through it? Here's the uncomfortable truth. Most organizations don't struggle with identifying risk, they struggle with being honest about it. And nowhere is that more obvious than in risk assess risk analysis and risk assessment. Let me say this carefully. Risk is not math. Risk uses math. But risk is ultimately about judgment under uncertainty. If risk could be perfectly calculated, reaches wouldn't surprise anyone. And yet they do constantly. Risk analysis and risk assessment, these are two terms that get blurred, especially on the exam. So let's slow walk this. Risk analysis. Risk analysis is about studying the risk. What could go wrong? What are the characteristics? What factors influence it? Think of analysis as investigation. Risk assessment is about deciding what that means. How serious is this? How does it compare to other risk? What priority does it get? Assessment is judgment. Analysis feeds assessments, but they are not the same thing. Now let's start with one that students usually love quantitative analysis, because numbers feel solid, numbers feel scientific, and numbers feel objective. And quantitative analysis, we try to assess actual values to risk, either be dollars, percentage, or loss expectancy, right? If the system is breached, the estimated loss is$2.4 million, right? Everybody loves that. Executive loves it, board loves it, insurance companies really love it, right? They have a number, they have a figure. The problem with quantitative analysis is how do you know the breach will cost$2.4 million? Where did that number come from? Was it from a past incident, an industry estimate, a consultant spreadsheet, a guess with confidence? Here's the truth: most quantitative risk numbers are educated approximates, not facts. And when students think quantitative analysis is better, they miss the point. It's not better, it's just more concrete looking. Quantitative analysis works best when you have historical data. The system is stable and lost patterns are predictable. Right? Examples, insurance claims, manufacturing, downtime, and power outage. Cybersecurity, much harder. Attackers adapt. Systems change, threats evolve. Now qualitative risk. This is where the risk is being described using high, medium, and low, or critical, moderate, modern, or severe, limited, or negligible. Sometimes, students sometimes dismiss this as less accurate. It's not, it's more realistic, actually. Because qualitative analysis accounts for uncertainty, allows expert judgment, works without perfect data, and is faster to update. And more importantly, it reflects how human actually makes decisions. Executives don't think in decimals, they think in this could shut us down. This will be embarrassing. And can we live with this? That's qualitative thinking. So here's a security plus exam truth. If Camtia describes risk levels, heat lamps, severity categories, and impact scales, they're always almost always describing a qualitative analysis, even if they don't say it explicitly. Students miss that. Now on the exam. Risk assessments take analysis and ask, so what? It prioritizes, it ranks, it compares risk against each other, but no organization fixes everything at once. Ever. Let's talk about heat maps. You see them color grants, granite, red, yellow, and green, likelihood on one axis, impact on the other. They look professional, they look decisive. But here's the technology top truth. Heat maps don't measure risk, they visualize judgment. And that's okay if you if you understand that's what they are. But heat maps lie when likelihood is guessed and not evaluated. Impact is minimized to avoid attention. Categories are too vague, and everything ends up medium. I see organizations where every risk is yellow, nothing is red, is in red, and leadership feels safe until something breaks. True light grids do the same, right? Stop is red, and yellow is caution, and green is go. They simplify decision making for you crossing the street. But simplification hinds nuance and security lives in nuance. Now we return to a concept of student confused consistency. You already made inherited risk. Now meet his partner, residual risk. Residual risk is the risk that remains after the controls are applied, after you put in the firewalls, the MFA, the training, the policies, the monitoring. That's because some people believe that if we mitigate the risk, it's gone. No, it's not gone, it's reduced, it's modified, it's changed, but it's never erased.

unknown: 16:33

Right?

SPEAKER_00: 16:33

This type of risk is the price of doing business. Real world example. A hospital has electronic health records, network medical devices, and remote access for doctors. What's the inherited risk? It's extremely high. Life critical systems, regulated data, they implement network segmentations, MFA, logging, vendor contracts. Your risk drops, but zero-day vulnerabilities exist. Humans can still make mistakes, and vendors can still fail. Right? Residual risk remains. The hospitals accept it. Right? Because they must operate. They have to continue moving on, right? You can't protect everything, cannot be 100% protected. That's never gonna happen. On exam, come team were often asked which risk remains after controls are implemented. They're testing residual risk, not mitigation failure. Students overthink it. Now that you know this, you don't. Risk assessment ultimately answers what is acceptable, what needs immediate action, and what can't wait. This is not technical, this is governance. Security exists to support business objectives, not override them. This that this reality makes students uncomfortable, but professionals accept it. Why is risk a moving target? Risk change because they change, right? When threats evolve or the systems change or the business priorities shift, or the laws are changed and updated, or vendors change behavior. This is why risk assessment is periodic and continuous, and you always have to be doing it, right? So this is where cybersecurity becomes less about tools and more about thinking. The best analysis, they don't panic, they ask, compare to what, according to whom, under what assumptions? That's risk literacy. Still with me? Alright, because this is where cybersecurity stops being theoretical and starts becoming political, financial, and deeply human. So we talked about what risk really is and how organizations analyze and assess it. Now comes the hardest question of all. Once you know the risk, what do you do about it? This is where most cybersecurity failures are born. Not from ignorance, but from choice. Picture this: you identified the risk, you assess it, and you put it on a heat map. Now leadership turns to you and asks, So what are we doing about this? And suddenly cybersecurity is no longer about technology, it's about budget, operations, reputation, legal exposure, human behavior. And this is where your risk response strategy strategies come in. There are four, always four, and Camtiel loves it. But the exam version is neat and tidy. The real world, it's messy. Alright, let's take it one at a time. Risk avoidance. Risk avoidance means we would not engage in that in that in the activity that creates the risk. That's it. No system, no exposure. Example, not storing the credit card data, not offering remote access, not supporting legacy software. This is the cleanest risk response and the least use. Why? Because avoidance often conflicts with business goals. Security may want to avoid, business may want to proceed. And guess who usually wins? Reality check. Avoidance is powerful but expensive. You don't avoid emails because phishing exists, you don't avoid the internet because malware exists. You decide where avoidance makes sense. Risk mitigation. This one students know best. Mitigation means we reduce the likelihood or impact of the risk. Firewalls, MFA, encryption, training, monitoring policies. Most security controls exist solely to mitigate. Risk. Mitigation never removes risk, it just reshapes it. Here's a myth. Here's a dangerous misunderstanding. When a breach happens, people say the controls fail. Often they don't. They worked within design limits. The risk was known, the controls reduced it. Residual risk remained, and that's the risk that materialized. That's not failure, that's reality. Risk transfer. Risk transfer means shifting financial responsibility to another party. Example, cyber insurance, outsourcing services, cloud providers, managed security service. Now pause. This is critical. You can transfer liability, you cannot transfer accountability. If your vendor leaks your data, it's still your reputation on the line. Don't miss this. Students often do. Risk acceptance. This is the one nobody likes to talk about. Risk acceptance means we understand the risk and we are choosing to live with it. This is not laziness, this is not ignorance, this is intentional tolerance, and it happens consistently because resources are finite, time is finite, money is finite, staff is finite, organizations must prioritize. Some risks are too expensive to mitigate, have low impact, have low likelihood, are temporary. Acceptance is how business functions. Let me give you an example of that. This is the one I like to say in class. You have you have a business and you have and you want an office, right? And they offer you an office on the first floor, right? And then they offer you on the third floor, right? So then they tell you, you can take the one on the first floor, it's a thousand dollars, or the one on the third floor is three thousand dollars, and you ask, hey, why is it so cheap? Well, because every now and then the first floor will flood because it rains. Right? But how often does it rain? Maybe three times a year. So you run the risk of maybe getting flooded, maybe getting flooded, and pay a thousand dollars a month as opposed to paying three thousand dollars, which you probably can't afford, right? And be and don't have to worry about the rain. Well, which one would you choose? Depends on the money. Right? If you have enough money and you're not worried about the rain, you probably you know, you choose what it is that you have to choose. That's what risk mitigation, that's another example of risk mitigation. Alright, because acceptance must be documented, reviewed, approved, and revisited. Undocumented acceptance becomes silent exposure, and silent exposure becomes surprise breaches. On security pluses, the question says management decides to take no action, the cost of mitigation outweighs the benefit, or leadership accepts the risk. They are describing risk acceptance, not failure, not neglect, acceptance. Now let's bring it back together. After mitigation, after transference, after avoidance, there's always residual risk.

unknown: 23:55

Right?

SPEAKER_00: 23:56

It's risk that remains after the controls are applied. And here's the risk, and here's the key insight: residual risk must fall within the organization's risk appetite. If it doesn't, something must change. Risk appetite defines how much risk is susceptible. This is not universal, it varies by industry, size, regulation, and culture and leadership tolerance. A hospital's risk appetite is low, a startup risk appetite is higher. A bank risk appetite is very, very small, microscopic, right? Many organizations form this with a risk appetite statement. This is leadership saying what matters most, what will not be tolerated, and where flexibility exists. Security operates inside this boundary, not outside of it. This is the hard truth for technical professionals. Risk management is not a project, it's a process, and process require documentation. A risk registry is that living document. It typically includes risk descriptions, severity, likelihood, impact, owner mitigations, and status. Why owner matters? A risk without an owner is a risk that will be ignored. Ownership creates accountability. Risk thresholds. This is as far as we're willing to go. Example, any high risk must be escalated. Any critical risk requires executive approval. Thresholds prevent quiet acceptance, they force conversations. Key risk indicators are early warning signs. Examples, increase in phishing attempts, spike in failed logins, vendor security advisories, mispatch cycles. KRIs don't prove a breach. They signal rising risk. Think smoke, not fire. Risk reporting exists to inform leadership, show threends trends, justify investments, and evaluate effectiveness. Security fails when it cannot commute risk clearly. Dashboards matter, but explanations matter more. You have to learn how to communicate. Now we shift gears because risk matters most when it affects mission essential functions. These are processes the organizations cannot survive without. If they fail, the business stops, legal exposures increased, and safety is compromised. Security protects functions, not servers. Alright, let's slow down here. Students can use these consistently. Maximum MTD, maximum tolerable downtime. The absolute longest a system can be down. RTO, recovery time objective, how quickly it must be restored. RPO, recovery point objective, how much data loss is acceptable. WRT, work recovery time. How long the staff needs to resume operation. These drive backup frequencies, redundancy, and disaster recovery plan. Let me give you an example. Payroll system. MTD, five days. RTO 24 hours, RPO 12 hours. An emergency response system. MTD minutes. RTO immediate. RPO near zero. Different functions, different priorities. Same organization. This is where cybersecurity becomes strategic. Not every system is equal. Not every risk deserves the same response. Professionals need to understand that. And you guys, students, you learn it here. Alright, so what we just talked about: the four risk response for real, why acceptance is avoidance, why residual risk matters more than controls, how appetite registers stay holds and KRE KRIs fit together, and why BIA business impact drives security priorities. Alright, so this is the part of the episode where things get uncomfortable because everything we talked about so far, all of it assumes that something isn't actually true anymore. It assumes you control your environment. And in modern cybersecurity, you don't. Let me say this plainly: most organizations are breached to systems they don't even own. Vendors, partners, service providers, cloud platforms, contractors, security teams can be flawless internally and still be compromised externally. This is why vendor risk management exists. Why vendors are different? You have your internal systems, you control patching, you control access, you control training. Vendors, different priorities, different budgets, different risk appetite. And yet they may store your data, process your transactions, and authenticate your users. That's not an external, that's shared risk. Vendors' risk begins before the contracts are signed. Vendor selection is a security decision, not just a procurement one. Organizations evaluate vendors to reduce your outsourcing risk and to demonstrate due diligence, support governance, risk, and compliance. This is why security teams get involved early, or at least they should. Vendor assessment answers one question: Are we comfortable tying our risk to yours? Assessment methods include evidence of internal audits, independent assessments, penetration testing reports, supply chain analysis, security questionnaires. This is not about perfection, it's about visibility. Now let's talk about something students often underestimate: a conflict of interest. Conflict of interest occurs when personal relationships, financial incentives, and organizations' pressure compromise objective decision making. Example, a board member owns part of a vendor company. Security may be strong, but governance risk exists. And governance risk is not is security risk. Here's a common failure. Organizations assess vendors once and then they never look back. But vendors change staff turnovers, mergers, new vulnerabilities, new subcontractors. Vendor monitoring must be continuous. Trust without monitoring is bad faith. Now we enter the legal layer because security expectations mean nothing if they're not enforceable. Initial agreements, let's walk through these. NDA, non-disclosure agreement, protects confidential information. MOU, Memorandum of Understanding, Defies intent and general responsibilities. MOA is memorandum of agreement more formal than MOU, clear obligations. These establish trust boundaries. Now the reinforcement begins. MSA, Master Service Agreement, defines overall relationship terms. SLA, service level agreement, defines performance expectations. SOW or WO statement of work or work order defines exactly what work is performed. Security controls live inside these documents. ROD, rules of engagement. They define what is allowed, what is prohibited, what system may be tested, what techniques are permitted. This matters especially for testing. Without rules of engagement, pen test becomes a tax, incidents becomes lawsuits. Audits and assessments. Students confuse these consistently. Let's go through it. Attestation is about verification. It answers. Are the controls present presented accurate and effective? It supports compliance, trust, and accountability. Internal assessments conducted by the organization's own staff. What's the advantage? Faster, customizable, and cheaper. Limitations, it's biased, has blind spots, conflict of interest, right? You don't, you're a programmer, you don't check your own code. Or if you write a book, you don't edit your own book. You let somebody else do it. External assessments conducted by independent third parties, advantage objectivity, credibility, often legally required. The limitation is the cost and less flexibility, and they both matter. Penetration testing. Now let's slow down because penetration testing is one of the most misunderstood concepts in cybersecurity. Penetration testing is authorized hacking to identify exploitable weakness. Authorized is the key word. No authorization, that's a crime. Types of pen testing, known environment. Tester knows systems and architecture. Partially known, some information provided, unknown environment that dissimulates a real attacker. Each test assumes differently. Active versus passive reconnaissance, passive, no direct interaction, public data, active, scanning, probing, touching systems, routes of engagement, decide what's allowed. Red team versus blue team. This is not a movie. Finds weakness. Blue team is defensive, detect and response. Integrated or purple team, they improves coordinations. Red teams don't win. Blue teams don't lose. They learn. Physical penetration testing, often forgotten. Examples, tailgating, badge cloning, server room access. Humans are still the weakest control. And I actually had a student, a former student who took my A class years back. She would go into buildings and try to open, get as many doors open for her in as many floors as she could until somebody stopped her. And she said she would get dialed up and she would put makeup, wear high heels or boots and mini skirts and stuff, and just like men, he's she said, would just open the doors, no questions asked. So, our exercise versus reality. Pen tests are snapshots. They'll show what was exploitable and under specific assumptions. They don't guarantee future security, right? Because future security as all security is continuous. Here's the uncomfortable truth. Most organizations don't fail because they lack tools, they fail because they trust too early. They stop monitoring, they treat compliance as security and they confuse testing with protection. Security is not control, it's ongoing negotiations with uncertainty. Alright, let's land this, right? Risk management is not fear-based, it's decision-based. Vendors extend your attack service surface. Contracts enforce your expectations. Audits verify reality, pen tests, challenges, assumptions. And none of it eliminates risk, it only makes risk more visible. That visibility is power. Alright, let's go over the four questions that we're gonna do. So I'll read it once, give you the choices, then read it again. Alright, question one which best describes risk assessments? A failure to implement security controls, B a decision to eliminate risk entirely, C a documented decision to tolerate risk, or D transfer of risk to a third party. Which best describes risk acceptance? A failure to implement security controls, B a decision to eliminate risk entirely, C a documented decision to tolerate risk, or D transfer of risk to a third party. Let's give you five seconds. Five, four, three, two, one. The correct answer is C risk acceptance is intentional, documented decision to tolerate residual risk within risk appetite. Question two Which agreement defines performance acceptance between an organization and a vendor? A N D A B M O U C S L A or D R O E. Which agreement defines performance expectations between an organization and a vendor? A N D A B M O U C S L A and D R O E. I'll give you five seconds. Think about it. Five, four, three, two, one. The correct answer is C service level agreement, which defines measurable performance and availability expectations. All right. Hopefully you're two for two. Question three What is the primary purpose of penetration testing? A provide compliance, B eliminate vulnerabilities, C, discover exploitable weakness or D replace audits. What is the primary purpose of penetration testing? A provide compliance, B eliminate vulnerabilities, C, discover exploitable weakness or D replace audits. I'll give you five seconds. Think about that. Five, four, three, two, one. The correct answer is C penetration testing, identify exploitable weakness under controlled conditions. Alright, last one. Hopefully you get them all right. Which assessments provide the most objective evaluation? A internal assessment. B vendor self-assessment. C external third party assessment or D automated scanning. Read it again. Which assessments provide the most objectual objective evaluation? A internal assessment. B vendor self-assessment. C external third party assessment or D automated scaling. And the correct answer is C. External third party assessment. External assessments provide independent, impartial evaluation, and often required for compliance. Alright. Gotta wrap it up here. Remember, risk is not the enemy. Risk ignorance is silence, is undocumented acceptance is. If you understand risk, you understand security. This has been Technology Tap. I'm Professor J Rod, and remember, every breach is a lesson in risk management terms. I'll see you on next episode. This has been a presentation of Little Cha Cha Productions, art by Sarah, music by Joe Kim. We're now part of the Pod Match Network. You can follow me at TikTok at Professor J Rod at J R O D, or you can email me at Professor J Rod J R O D at Gmail dot com.