A year from now, somebody is going to look at a risk your organization chose to live with and ask why it was decided that way. Most of the time, they want to know whether anyone can explain it. In this episode, Professor Simon explains what makes a cybersecurity risk decision defensible: a decision that can be explained and supported using what was known at the time, whether or not it turned out well.

He walks through a hypothetical, not a real case, about a business team that wants to connect a new tool to customer data before the security review is finished. Along the way, he covers seven things a good risk decision record should show and five questions it should be able to answer. It is useful for security and GRC professionals who make or document risk decisions, and for anyone learning to write them.

In this episode you'll learn:

- Why a defensible decision is one that can be explained using what was known at the time, not one that turned out well

- Why cybersecurity risk decisions should be written down when they are made, not rebuilt from memory later

- How to state a risk in plain words that a business decision maker can weigh

- How to be honest about evidence, assumptions and confidence in a risk rating

- Why a record should show the options considered, and keep security's recommendation separate from the decision

- How to record residual risk, assumptions and constraints, and the triggers for reviewing a decision

- Five questions a risk decision record should be able to answer

▶️ Companion YouTube Video: https://youtu.be/SzwZ2SGvL-U

📝 Companion Blog Post: https://professorsimon.com/blog/defensible-cybersecurity-risk-decisions

🎧 More Podcast Episodes: https://professorsimon.com/podcast

👉 Need help with your IT or cybersecurity career? Work with me: https://professorsimon.com/guidance

🔗 Resources, blog & more: https://professorsimon.com/links

🌐 Website: https://professorsimon.com

💼 LinkedIn: https://www.linkedin.com/in/leonardsimon

📸 Instagram • X • TikTok: @profsimononline

If you found this episode helpful, please follow the podcast, leave a rating or review, and share it with someone who would benefit.

When a security incident starts, who is actually allowed to decide to take a system offline, bring in legal, or tell the executives? In this CISSP Blueprint episode, Professor Simon looks at incident management through a security manager’s lens, using a fictional healthcare provider, IncidentSecure Inc., as a teaching scenario.

He organizes the management side of the work into three questions: who decides, what is at stake, and what the organization will be able to show afterward. Along the way, he covers the difference between a role and the authority to decide, why severity should follow business impact, how legal, compliance, and communication planning fit in, and what evidence can show about an organization’s preparation and response. This is original teaching, not official ISC2 material, and it contains no exam questions.

In this episode you'll learn:

- Why incident management starts with authority and evidence, not tools

- Where incident management sits in the published CISSP exam outline (Domain 7, Security Operations)

- The difference between a role and the authority to decide, and why it matters during an incident

- Why severity should follow business impact

- Why legal, compliance, and communication planning belong in incident management

- How an organization can demonstrate preparation and follow-through, including why drills need a record

- Three questions to ask about any incident scenario, and what changes when you move toward security management

▶️ Companion YouTube Video: https://youtu.be/glg8OT8ei8w

📝 Companion Blog Post: https://professorsimon.com/blog/who-decides-during-a-security-incident

🎧 More Podcast Episodes: https://professorsimon.com/podcast

👉 Need help with your IT or cybersecurity career? Work with me: https://professorsimon.com/guidance

🔗 Resources, blog & more: https://professorsimon.com/links

🌐 Website: https://professorsimon.com

💼 LinkedIn: https://www.linkedin.com/in/leonardsimon

📸 Instagram • X • TikTok: @profsimononline

If you found this episode helpful, please follow the podcast, leave a rating or review, and share it with someone who would benefit.

Choosing between SOC and GRC usually starts with salary, difficulty, or which one sounds more technical, and those comparisons rarely settle anything. A better question is which kind of work you would actually want to spend your time doing. In this episode, Professor Simon explains what SOC (security operations) work and GRC (governance, risk, and compliance) work tend to feel like day to day.

He explains why the idea that SOC is technical and GRC is not does not hold up, walks through one illustrated vendor security problem from both seats, and covers where the two paths overlap. He then gives two small exercises you can try for free, one for each path, along with the questions to ask yourself afterward. Because this is audio, the exercises and questions are described as he goes, so you can follow along while you walk, drive or work.

In this episode you'll learn:

- Why salary, difficulty and 'which is better' are weak ways to choose between SOC and GRC

- What SOC and GRC mean, and what each kind of work tends to involve day to day

- Why 'SOC is technical and GRC is not' does not hold up

- How the same vendor security problem raises different questions in a SOC and in GRC

- What the two paths share: how systems work, clear writing, and separating what you know from what you assume

- Two small free exercises to try the work before you pick a path

- Questions to ask yourself afterward, and why being able to do the work is different from wanting to do it all day

▶️ Companion YouTube Video: https://youtu.be/7_Ww6uTrMws

📝 Companion Blog Post:

https://professorsimon.com/blog/soc-vs-grc-choose-based-on-the-work

🎧 More Podcast Episodes: https://professorsimon.com/podcast

🧭 Figure out which cybersecurity path fits you: https://careervectors.com

🔗 Resources, blog & more: https://professorsimon.com/links

🌐 Website: https://professorsimon.com

💼 LinkedIn: https://www.linkedin.com/in/leonardsimon

📸 Instagram • X • TikTok: @profsimononline

If you found this episode helpful, please follow the podcast, leave a rating or review, and share it with someone who would benefit.

Your monitoring tools flag something, and now somebody has to decide how serious it is, who needs to know, and who is in charge of the response. If nobody settled that ahead of time, those decisions get made at the worst possible moment. In this episode, Professor Simon explains why detecting an incident and managing one are two different jobs, and why much of the work of managing an incident happens before the incident ever occurs.

He uses a fictional health care provider, IncidentSecure Inc., from his book as a teaching scenario and walks through its four stages: assessing what it needs, designing a strategy, putting controls in place, and training and improving. Along the way he covers defined roles, classification levels, response procedures, a communication plan, where detection fits among the controls, where a response tends to break, and why practice matters. He closes with four questions you can ask about one type of incident your own organization could realistically face. Because this is audio, the four stages and the four questions are described as he goes, so you can follow along while you walk, drive or work.

In this episode you'll learn:

- Why detecting an incident is not the same as managing one

- The four stages of the fictional program: assess needs, design a strategy, put controls in place, train and improve

- Why defined roles, severity levels, response procedures and a communication plan matter

- How a detection becomes a coordinated response, from classification to who hears about it

- Where a response tends to break: a role nobody owns, a severity nobody agreed on, a message that goes out late or wrong

- Four questions to ask about one type of incident your team could realistically face

- How to explain the work around a detection tool in an interview

▶️ Companion YouTube Video: https://youtu.be/IzMXywJ_GBc

📝 Companion Blog Post: https://professorsimon.com/blog/incident-management-process-before-an-incident

🎧 More Podcast Episodes: https://professorsimon.com/podcast

🧭 Figure out which cybersecurity path fits you: https://careervectors.com

🔗 Resources, blog & more: https://professorsimon.com/links

🌐 Website: https://professorsimon.com

💼 LinkedIn: https://www.linkedin.com/in/leonardsimon

📸 Instagram • X • TikTok: @profsimononline

If you found this episode helpful, please follow the podcast, leave a rating or review, and share it with someone who would benefit.

A more personal Professor Simon episode. There are no lessons this time, just an honest conversation about why I'm building Professor Simon.

I'm 44 and have been working in IT since 2000. I talk about getting my first computer, an Apple IIgs, at about eight years old, how that turned into a career in cybersecurity and teaching, and the gap I kept noticing between learning IT and cybersecurity and actually building a career in it. I also talk about learning video and content creation as I go, how slow growth feels, what I'm still figuring out about where Professor Simon goes next, and learning when to stop working and be present as a husband and father.

IT & Cybersecurity Beyond the Textbook.

▶️ Companion YouTube Video: https://youtu.be/0FtMu2uejsw

📝 Companion Blog Post: https://professorsimon.com/blog/starting-something-new-at-44

🎧 More Podcast Episodes: https://professorsimon.com/podcast

🧭 Figure out which cybersecurity path fits you: https://careervectors.com

🔗 Resources, blog & more: https://professorsimon.com/links

🌐 Website: https://professorsimon.com

💼 LinkedIn: https://www.linkedin.com/in/leonardsimon

📸 Instagram • X • TikTok: @profsimononline

If you enjoyed this episode, please follow the podcast and share it with someone who might need to hear it.

Your SIEM flags an account: about a dozen failed logins in a few minutes, then a successful one. It looks like someone guessed a password, but it looks exactly the same when a phone keeps retrying an old one. In this episode, Professor Simon walks through one hypothetical alert from start to finish, with the focus on the reasoning that transfers from one SIEM to the next, not on any product or query syntax.

He treats the alert as a question rather than a verdict and works through six steps: getting the context, building the timeline, checking the source and destination, seeing what happened after the login, arguing both the benign and suspicious stories, and writing a conclusion someone else could follow and check. Because this is audio, the examples are described, not shown, so you can follow along while you walk, drive or work.

In this episode you'll learn:

- Why an alert is a question, not a verdict

- What to check first: what the rule detects, which account is involved, and what it was signing into

- How to build a timeline and read the pattern and reasons behind failed logins

- How to check the source and destination, and how to recognize password spraying

- What to look for after a successful login: new MFA devices, inbox forwarding rules, and unfamiliar systems

- How to argue both the benign and suspicious stories, and how to write a conclusion someone else can check

▶️ Companion YouTube Video: https://youtu.be/gnl2qc-DREM

📝 Companion Blog Post: https://professorsimon.com/blog/siem-alert-investigation-failed-logins

🎧 More Podcast Episodes: https://professorsimon.com/podcast

🧭 Figure out which cybersecurity path fits you: https://careervectors.com

🔗 Resources, blog & more: https://professorsimon.com/links

🌐 Website: https://professorsimon.com

💼 LinkedIn: https://www.linkedin.com/in/leonardsimon

📸 Instagram • X • TikTok: @profsimononline

If you found this episode helpful, please follow the podcast, leave a rating or review, and share it with someone who would benefit.

If you work with a risk register, you've probably noticed one name showing up in the owner column over and over: security. In this episode, Professor Simon explains why that happens, and why identifying and documenting a risk isn't the same as owning the decision about it.

He walks through four roles that tend to get blurred together in one column (risk identification, risk ownership, remediation ownership, and acceptance authority), works through a concrete example of an unsupported finance application, and covers what security still has to do, what every healthy register entry needs, and how leadership should handle risks that stay open past their dates.

In this episode you'll learn:

- Why security's name ends up in the owner column, and why that stalls risk decisions

- The difference between identifying a risk and owning the decision about it

- A simple test for finding the real risk owner: who can say yes to the money, the downtime, or the exposure

- Four roles to keep separate: risk identification, risk ownership, remediation ownership, and acceptance authority

- What security still has to do: rate risks consistently, explain them, track dates, follow up, and verify remediation

- What a healthy register entry needs, and how leadership should handle risks that stay open

▶️ Companion YouTube Video: https://youtu.be/sUgPk7X6CCI

📝 Companion Blog Post: https://professorsimon.com/blog/risk-register-owner-who-decides

🎧 More Podcast Episodes: https://professorsimon.com/podcast

🧭 Figure out which cybersecurity path fits you: https://careervectors.com

🔗 Resources, blog & more: https://professorsimon.com/links

🌐 Website: https://professorsimon.com

💼 LinkedIn: https://www.linkedin.com/in/leonardsimon

📸 Instagram • X • TikTok: @profsimononline

If you found this episode helpful, please follow the podcast, leave a rating or review, and share it with someone who would benefit.

Your organization's biggest data vendor just called. They think, but aren't fully sure yet, that some of your data went out the door in a breach on their side. In this episode, Professor Simon walks through how a CISSP should actually reason through that call, using a scenario from his own CISSP Blueprint book, and why the instinct to terminate the contract immediately usually isn't the strongest answer.

He covers where third-party risk sits in the current CISSP exam outline as Supply Chain Risk Management (Domain 1), the real tradeoffs between terminating a vendor relationship and staying engaged through your existing contractual rights, the difference between due diligence and due care, the four standard risk-response options (mitigation, avoidance, transfer, and acceptance), and a repeatable four-step framework for working through this kind of scenario question, on the exam or on the job.

In this episode you'll learn:

- Why the instinct to immediately terminate a vendor after a possible breach often isn't the strongest answer

- How CISSP scenario questions test proportionate judgment, not vocabulary

- Where third-party risk fits in the current exam outline as Supply Chain Risk Management (SCRM), Domain 1

- The difference between due diligence and due care, and why a program needs both

- The four standard risk-response options: mitigation, avoidance, transfer, and acceptance, and what each one actually does (and doesn't do)

- Why your own regulatory obligations don't pause while a vendor finishes investigating

- A repeatable four-step framework for working through this kind of scenario question

▶️ Companion YouTube Video: https://youtu.be/XF4PQOGv0i0

📝 Companion Blog Post: https://professorsimon.com/blog/cissp-vendor-breach-scenario-reasoning

📚 Companion Workbook (free, CISSP Blueprint exercise): https://professorsimon.com/free-guides

🎧 More Podcast Episodes: https://professorsimon.com/podcast

🧭 Figure out which cybersecurity path fits you: https://careervectors.com

🔗 Resources, blog & more: https://professorsimon.com/links

🌐 Website: https://professorsimon.com

💼 LinkedIn: https://www.linkedin.com/in/leonardsimon

📸 Instagram • X • TikTok: @profsimononline

If you found this episode helpful, please follow the podcast, leave a rating or review, and share it with someone who would benefit.