Turning a Gemba Board Into Real, Weekly Security Improvement

In the world of security operations, we often talk about metrics — detection times, vulnerability remediation, incident counts, backlog ages. The Driving Real Security Improvement with a Gemba Board post does a great job of outlining how a Gemba board makes these metrics visible to the team and shifts ownership of outcomes to the people doing the work.  

But visibility is only the beginning.

The Power of Weekly Gemba Walks

A Gemba board becomes transformative when the team gathers around it consistently— ideally weekly — not just to glance at numbers, but to connect those numbers to real work and real process challenges happening every day.

This practice — a weekly Gemba walk at the Gemba board — isn’t an administrative review. It’s an opportunity to go to where the work happens, see what’s actually happening there, and engage the team in meaningful conversation about how to improve. In Lean practice, that’s what “Gemba” means: the real place where value is created.  

Weekly walks help teams:

• Connect metrics to actions. Rather than seeing a number in isolation, teams can ask: Why is throughput down this week? What changed in the process?

• Spot both successes and failures. A Gemba walk provides space for the team to share what went well and what didn’t — validating good work and uncovering process friction.

• Surface process issues, not personal blame. The goal is not to point fingers but to understand where processes break down or fall short — and collaboratively improve them.

Conversations Over Blame

One of the biggest cultural shifts you get from weekly Gemba walks is a move away from individual blame toward collective learning.

Real improvement comes when:

• Team members feel safe to share challenges, without fear of being singled out for mistakes. Psychological safety like this fuels honest discussion and real insights.  

• Failures become learning opportunities. When you treat a failure as a process insight rather than a personal flaw, the team can analyze what happened and co-create solutions.

• Successes are recognized and understood. Celebrating what workedbuilds positive momentum and shows the process improvements that contributed to that success.

This is exactly what Lean leadership encourages during Gemba walks: Observe first, ask good questions, engage respectfully, then improve the process.  

How Weekly Gemba Walks Drive Continuous Improvement

Consistency is key. Many organizations that embed Gemba walks into weekly routines find that it accelerates continuous improvement because:

• Teams begin to spot patterns over time, not just isolated incidents.

• Conversations become actionable: ideas, experiments, follow-up tasks.

• You build a cadence of improvement rather than a cadence of crisis response.

A weekly Gemba walk creates a rhythm for improvement — a reliable space for reflection, adjustment, and collective problem-solving.

This is how you make a Gemba board more than a dashboard. It becomes the hub of real operational insight, where the whole team converges to learn, adapt, and improve the security processes that matter most.

Final Thought

A Gemba board tells you what’s happening. Weekly Gemba walks help you understand why it’s happening — and how to make it better.

When teams consistently engage around the board, focusing on processes instead of people, they unlock a culture of continuous improvement. That’s where real security improvement lives: visible metrics, weekly reflection, open dialogue, and shared ownership of solutions.

Driving Real Security Improvement with a Gemba Board

In information security, we talk a lot about metrics. Mean time to detect, vulnerabilities closed, incidents resolved, backlog aging, control coverage—the list goes on. But too often, those metrics live in dashboards that few people check, or in reports reviewed once a month and quickly forgotten.

A Gemba board changes that.

What Is a Gemba Board?

“Gemba” is a Lean concept that means the place where the work happens. A Gemba board is a visual representation of the team’s work, processes, and performance—displayed where the team can see it every day.
Unlike executive dashboards built for status reporting, a Gemba board is designed for the people doing the work. Its purpose is simple: make the process visible so the team can improve it.

Why Infosec Teams Need Visual Process Metrics

Security work often feels abstract. When you’re buried in alerts, tickets, audits, and remediation tasks, it’s hard to tell whether things are actually getting better.

A well-designed Gemba board answers key questions at a glance:

• Are we improving detection and response times?

• Is our vulnerability backlog shrinking or growing?

• Where are we consistently blocked?

• What improvements are actually working?

When process metrics are visible every day, improvement stops being theoretical. It becomes tangible.

Turning Metrics into Motivation

One of the biggest benefits of a Gemba board is motivation.

When a team sees that:

• Mean time to remediate dropped by 20%
• High-risk vulnerabilities are closing faster
• Incident volume is stabilizing despite increased coverage

…it creates momentum.

People are naturally motivated when they can connect their daily work to visible progress. Instead of leadership saying “We need to do better”, the board shows how the team is doing better—because of their actions.

This is especially powerful in security, where success often means nothing bad happened. A Gemba board makes invisible wins visible.

Driving Change from the Front Line

Gemba boards work best when they’re used during regular team conversations:

• Daily standups
• Weekly operational reviews
• Continuous improvement discussions

Rather than leadership dictating change, the team can point to the metrics and say:

• “This step is slowing us down.”
• “This automation reduced noise.”
• “This control change actually worked.”

The data sparks discussion. The discussion drives experimentation. And the results show up—again—on the board.

What Belongs on an Infosec Gemba Board?

Every team is different, but strong Gemba boards usually include:

• Outcome metrics (e.g., incident response time, vulnerability risk reduction)
• Flow metrics (backlog size, aging, throughput)
• Quality signals (reopened tickets, false positives)
• Improvement experiments (what the team is trying to improve this week)

The key is clarity. If the team can’t quickly understand what they’re seeing, the board won’t drive behavior.

From Reporting to Ownership

The real shift a Gemba board creates is cultural.

Metrics stop being something leadership asks for and start being something the team owns. The board isn’t about judgment—it’s about learning. It answers the question: “How is our system performing, and how can we make it better?”

In information security, where complexity is high and burnout is common, that sense of ownership matters.

Final Thoughts

A Gemba board isn’t about more metrics—it’s about making the right metrics visible to the right people at the right time.

When your infosec team can see their process, track improvements, and celebrate progress together, change stops being forced. It becomes a natural outcome of engaged, motivated professionals improving their own system of work.

That’s how security gets better—one visible improvement at a time.

When Leadership Says “Keep Us Safe”: Finding Cyber Risk Tolerance in the 10-K

 One of the most common questions cybersecurity professionals ask executive leadership is:

“What is the organization’s risk tolerance when it comes to cyber risk?”

And one of the most common answers they get back is:

“Keep us safe.”

“Don’t let a breach happen.”

While well-intended, these answers don’t actually define risk tolerance. No organization can be perfectly safe, and “no breaches ever” isn’t a strategy—it’s a hope. When leadership can’t (or won’t) clearly articulate cyber risk tolerance, you need to look elsewhere for clues.

One of the most useful—and often overlooked—places to find them is the company’s 10-K report.

Why Risk Tolerance Matters

Risk tolerance drives real decisions:

• How much downtime is acceptable?
• How much data exposure is tolerable?
• How much money should be spent on security controls?
• Which risks are accepted versus mitigated?

Without understanding leadership’s tolerance, security teams either over-invest (creating friction and wasted spend) or under-protect (creating unacceptable exposure).

The 10-K: Executive Risk Thinking, in Writing

A public company’s 10-K is an annual filing that details financial performance, business operations, and—most importantly for security leaders—risk factors. These disclosures are reviewed by legal teams and executive leadership, which means they reflect what leadership is willing to formally acknowledge as material risk.

When you read the 10-K, focus on:

• Risk Factors section
• Management’s Discussion and Analysis (MD&A)
• Any section referencing cybersecurity, data breaches, operational disruption, or regulatory exposure

Pay attention to:

• How strongly cyber risk is worded
• Whether breaches or data loss are explicitly mentioned

Asset Management - Physical Devices - What do you have? Do you know?

Asset management and inventorying your physical systems, we all know we should do it, and I am sure most try.  I am not going to talk about the should have, would have or could have. Instead, I am going to focus on the risks associated with the NIST CSF control ID-AM.1.  

The control simply states, “Physical devices and systems within the organization are inventoried.”  At the simplest level, this control is saying that the organization inventories all physical systems that are apart of the information system. In my opinion, the control is foundational because how can you secure something if you don't know it exists.  If you are not inventorying your systems, how do you know if they have adequate controls to protect the data and network.   If you had a breach of data, would you know what type of data was involved, or would you even know if you had a breach?  To further extend this, how can you perform a risk assessment on the system to understand and relay any risks to the overall information system?  

If this control is not in place and at a minimum level repeatable, your organization is higher risk.  You have to know what you have to be able to protect it.

The associated risks of the NIST CSF

In this series, I am hopefully going to explain the risks associated with the NIST CSF and associated controls.  I will primarily focus on NIST controls.  I intend to review each NIST CSF control individually and help understand the risks associated with not satisfying that control.  This series should help you know which controls are essential for your business when developing your profile.  The information can be further extended to developing scorecards and metrics for your information security program. 

Vulnerability Management… It’s easy - Planning

I am sure you have had either consultants, vendors, or heard at a conference that vulnerability management is foundational security control.  While I agree that it is an essential control, I also understand that it is challenging to implement.  Vulnerability management is not just to pick a tool, scan, and fix issues.  Many components make it a complicated journey.  This series will attempt to help break it down and give you ideas on how this complex service and be delivered effectively. 

 

Planning

 

Objective

When you start, I recommend creating a targeted objective and set of measures against your objective.  Ensure that you keep in mind your organization’s culture, politics, and risk appetite as you are developing your objective.  I have seen some target just “critical” systems for regulatory compliance, whereas others have targeted their entire enterprise.  No matter your scope, keep in mind your team’s current resource load, as standing up a vulnerability management program is resource-intensive at first.  In the example of scoping your vulnerability management program to the entire enterprise, break it down into smaller actionable pieces.  Smaller actionable pieces will allow you to show continual progress as you build your complete vulnerability management program.  To give you some ideas, limit scopes to a zone, subnet, or system.  Don’t try to tackle everything at once.  That often leads to frustration and failure.

 

For instance, talk to your business customers and understand what they perceive as their most critical systems.  Understand from their point of view what needs to be protected, this will help you later when you are seeking their approval, or buy in. 

 

Socializing

I have seen lots of projects fail because of lack of buy in.  For most a vulnerability management program is telling system owners how ugly their system is and that it may cost more money to fix it, or make it prettier.  To help make your program a success you should get as much executive buy in as possible.  To do this, you need to get them to understand how this program will help.  Cost avoidance is typically a difficult sell, and stating that it is mandatory for regulatory compliance is about the same.  Instead help them understand that this program will help lead to a more secure product/service.  This increased posture can be used as a competitive advantage.

Now that your executive team is starting to support you make sure you understand from their point of view what is the most critical systems that need to be protected.  Build the critical systems into your plan and agree to a scope and timing.  Just don’t forget to keep them updated as to progress and any potential roadblocks as you progress. 

 

Documenting

Formally documenting your project plan is a great way to hold yourself accountable and be able to show progress.  The documented project plan can be provided to executive management to provide updates as to the progress of the project, or show roadblocks and issues in which you need their support. 

 

Next up… reviewing and selecting tools