W3_ISSC662_Example

Example:

Why Risk Artifacts Didn’t Equal Risk Management

Select the Start button to begin

Start

Select the Listen button to play the narration for this slide

Navigation

Listen

buttons

Use the following buttons to navigate through the course content

Listen

Play the audio for the current page

hOME

nEXT

PREVIOUS

Return to the previous page

Return to the course home page

Move to the next page

home

next

previous

Select the Listen button to play the narration for this slide

Listen

Hi, I’m Caleb, and I want to tell you about a time when my organization thought it had “risk covered”—until we realized we were confusing awareness with capability.

home

next

previous

Select the Listen button to play the narration for this slide.

Listen

Part I - The Situation

You’re working in a company that’s growing fast. Not the flashy kind of growth that comes with unlimited budget, but the kind that happens because demand increases, teams stretch, and systems get patched together as you go. That was us: a mid-sized company providing online services to regional clients. We weren’t a household name, but we handled sensitive customer information, and we relied heavily on uptime because downtime meant lost revenue and angry customers.

home

next

previous

Listen

Select the Listen button to play the narration for this slide.

The Situation

We had risk artifacts. That was the phrase leadership liked: “risk artifacts.” We had a risk register. We had a quarterly vulnerability scan. We had a security newsletter. And every time a scan report came in, the same pattern happened: the security team would forward the report to IT with a message like, “Please remediate high and critical findings.” IT would respond with, “We’ll get to it,” and then everyone would move on until the next report.

If you’re honest, you can probably already feel the weakness in that system. It wasn’t that we didn’t see risk. We saw it. We just didn’t have a reliable way to act on it.

home

next

previous

Select the Listen button to play the narration for this slide.

Listen

The Situation

Then we had a bad week. It started with something small: a client reported intermittent login failures. On the same day, our monitoring showed unusual spikes in traffic. IT assumed it was a capacity issue, so they scaled resources. The issue didn’t go away. Then a senior engineer noticed something that should have been caught earlier: repeated, structured requests hitting a legacy endpoint—an endpoint that was supposed to be deprecated but was still running because someone didn’t want to “break dependencies.”

home

next

previous

Listen

Select the Listen button to play the narration for this slide.

The Situation

Within 48 hours, we learned the hard way that the endpoint had a known vulnerability that had been flagged in a scan report two months earlier. It wasn’t just a theoretical weakness. It was being actively probed. We weren’t breached—at least not in a way we could confirm—but we were exposed, and we didn’t have the confidence to say what happened, what data was at risk, or how close we came to a real compromise.

Leadership asked, “How did we miss this?” But the answer wasn’t “we missed it.” The answer was “we saw it and didn’t have the capability to handle it.”

home

next

previous

Select the Listen button to play the narration for this slide.

Listen

Part II - The Shift

After that week, we finally stopped treating risk as paperwork and started treating it like a living operational problem. And the first thing we did was uncomfortable: we mapped the path from vulnerability discovery to remediation, exactly as it happened in reality. It was full of gaps. The vulnerability report didn’t go to system owners—it went to a shared inbox. No one confirmed receipt. No one assigned due dates tied to impact.

home

next

previous

Listen

Select the Listen button to play the narration for this slide.

Investigation

No one tracked exceptions. And worst of all, nobody had the authority to force prioritization when business deadlines competed with security fixes. So we reframed the whole conversation using three questions:

• What is the threat scenario? Not “a vulnerability exists,” but “how could someone exploit this, and what would they gain?”
• What is the vulnerability exposure in our environment? Not “it’s critical,” but “is it reachable, authenticated, internet-facing, used by customers?”
• What is our capability to respond? Not “we intend to patch,” but “do we have owners, timelines, testing capacity, and escalation paths?”

home

next

previous

Listen

Select the Listen button to play the narration for this slide.

Investigation

That third question changed everything, because it pushed us into maturity thinking. We realized we didn’t have a vulnerability problem as much as we had a capability problem. So we built a lightweight capability structure:

• We created ownership: every system had a named security point of contact and an IT owner.

• We created prioritization rules: critical vulnerabilities had response timelines based on exposure and impact, not just severity rating.

• We created an escalation path: if a remediation deadline couldn’t be met, someone had to formally accept risk or approve compensating controls.

home

next

previous

Select the Listen button to play the narration for this slide.

Listen

Response

• We created reporting that leadership could understand: not “number of findings,” but “risk exposure over time” and “aging critical items.”

We also ran a tabletop exercise: “What happens if this vulnerability is exploited tomorrow?” That’s when people realized risk isn’t abstract. It’s time-sensitive.

home

next

previous

Listen

Select the Listen button to play the narration for this slide.

Part III - Results

The first result wasn’t perfection. The first result was clarity. Within a few weeks, we had fewer “surprises,” because vulnerabilities stopped floating around unnoticed. We had accountability that wasn’t personal or emotional—it was structural. People knew what they owned. They knew when something was due. They knew what to do if they couldn’t meet the timeline. And something else happened: leadership started making real tradeoffs. Before, security fixes were always “important,” but somehow always postponed. Now, when a remediation deadline collided with a product launch, the decision was visible. Someone had to choose: accept risk, delay work, or fund resources. That’s what real risk management looks like.

home

next

previous

Select the Listen button to play the narration for this slide.

Listen

Results

We still had vulnerabilities—every organization does—but our exposure dropped because we weren’t just collecting information. We were acting consistently. We began to trust our own processes, not because we hoped they worked, but because we could see them working.

home

next

previous

Listen

Select the Listen button to play the narration for this slide.

Part IV - Takeaway

Here’s what I want you to carry out of Week 3: risk and vulnerability are not just technical facts. They’re operational realities. And the difference between a risky organization and a resilient one is often capability—repeatable, owned processes that turn awareness into action. If your program can identify risks but can’t consistently respond, you don’t have assurance. You have visibility. Visibility is useful, but it’s not enough.

This week, you’re learning to connect the chain: threat, vulnerability, impact, and capability. And when you can do that, your analysis becomes something organizations can use—because it leads to decisions, not just reports.

home

next

previous

Select the Listen button to play the narration for this slide

Listen

Congratulations!

You've successfully completed the example

home

previous