Top Questions Security Leaders Are Asking Right Now (From the Field)

March 5, 2026

Top Questions Security Leaders Are Asking Right Now (From the Field)

Talk to enough security leaders, and a pattern emerges. The conversations may start differently – an audit prep call, a vulnerability review meeting, a board discussion – but the same questions tend to surface again and again.

They’re not theoretical questions. They come from real operational pressures: regulators and auditors asking tougher questions, new technology appearing and evolving faster than governance frameworks can keep up, vulnerability queues that never seem to shrink, and third-party providers whose responsibilities sometimes feel…unclear.

Across industries, a handful of questions are dominating security conversations right now. Below are four that seem to come up most often.

  • Are we meeting regulator expectations?
  • How do we risk assess AI adoption?
  • In a sea of vulnerabilities, how do we prioritize mitigation?
  • Is our Managed Service Provider (MSP) actually doing what is expected?

 

Are We Meeting Regulator Expectations?

For many organizations, particularly in financial services, regulatory expectations are becoming harder to interpret and more difficult to satisfy. It’s not necessarily that the rules themselves are radically different. It’s that oversight is being scrutinized more closely – not just whether policies exist, but how governance is structured, documented, and operationalized.

There’s also growing inconsistency in how expectations are applied. Auditors naturally differ, as no two programs are identical. More concerning, however, is that examiner expectations can vary across agencies and even between regions within the same agency. At the same time, public reporting on high-profile breaches has made everyone more informed, and more opinionated. When a hack makes headlines and the “why” becomes public, stakeholders, boards, and even the broader market feel empowered to second-guess how the ball was fumbled.

One area that often draws scrutiny is the Information Security Officer role. In smaller or mid-sized organizations, it has historically been common for the ISO to sit within IT leadership. That model can work operationally, but regulators are increasingly asking a fair question: if IT operations are responsible for managing risk, who is independently evaluating those risks?

This has led many organizations to revisit their governance structure. Some choose to hire a dedicated security leader. Others assign the responsibility internally and invest in training and program development. Both approaches can work, but they require careful thought about independence, oversight, and board reporting.

Frameworks such as the NIST Cybersecurity Framework (CSF) provide a practical structure for building, assessing, and documenting security governance programs. They help demonstrate that security decisions are being made intentionally and systematically, not simply in reaction to the latest audit findings.

For banks and credit unions transitioning from the now-retired FFIEC Cybersecurity Assessment Tool (CAT) to NIST CSF, an initial maturity assessment can provide a clear baseline and roadmap forward. Structured assessments help leadership understand current-state capabilities, identify gaps, and prioritize remediation efforts in a defensible way.

Support in this area does not have to be all-or-nothing. In addition to ongoing vISO advisory services, organizations can engage on a project basis – whether for a CSF maturity assessment, an asset-based IT risk assessment, incident response plan development, or other targeted governance initiatives. This allows institutions to address specific needs while evaluating longer-term support models.

Ultimately, regulatory expectations tend to center around a simple principle: can leadership clearly demonstrate how cybersecurity risk is identified, governed, mitigated to an acceptable level, and reported?

How Do We Risk Assess AI Adoption?

Artificial intelligence has quickly become the newest topic on boardroom agendas, and the use cases are evolving rapidly. Business leaders are eager to explore productivity gains and automation opportunities, while security and compliance teams are left asking how to evaluate the associated risks.

Unlike many previous technologies, AI adoption often begins informally. Employees experiment with generative tools, departments test automation capabilities, and before long the organization realizes AI is already embedded in daily workflows.

This creates a practical challenge: how do you govern technology that may already be in use across the business?

Guidance is beginning to emerge. The NIST Artificial Intelligence Risk Management Framework (AI RMF) outlines approaches for evaluating trustworthiness, security, privacy, and governance considerations when adopting AI systems (https://www.nist.gov/itl/ai-risk-management-framework).

In practice, many organizations start with a few foundational questions:

  • Where is AI currently being used across the organization?
  • How are employees trained to utilize AI and risk awareness maintained?
  • Are employees sharing internal or sensitive information with external AI services?
  • Do we have a method of tracking all usage?
  • What policies should govern AI-assisted decision making?
  • Who owns AI governance and risk management internally?

Rather than attempting to halt AI adoption entirely, many organizations are focusing on visibility first. Understanding how the technology is being used often leads to more practical governance decisions than trying to prohibit it outright.

AI is unlikely to disappear from enterprise environments anytime soon. The challenge now is figuring out how to enable its benefits while maintaining appropriate oversight and security of sensitive data.

In a Sea of Vulnerabilities, Which Do We Prioritize First?

Security teams rarely struggle with a lack of vulnerability data. If anything, the challenge is the opposite.

Scanning tools generate thousands of alerts. New CVEs appear daily. Security dashboards fill with high-severity warnings. For many teams, the real question becomes not what exists, but what actually matters most.

Industry resources like the CISA Known Exploited Vulnerabilities Catalog can help highlight vulnerabilities that attackers are actively exploiting (https://www.cisa.gov/known-exploited-vulnerabilities-catalog). This provides a helpful starting point, but prioritization still requires context. A thorough and frequently updated business impact analysis is required to assess the criticality of vulnerabilities to operations and security.

Severity scores alone rarely tell the full story. A vulnerability may appear critical on a report but exist on an isolated system with minimal exposure. Another vulnerability with a lower score may affect an externally accessible service that supports a core business process.

Effective prioritization often involves considering factors such as:

  • Whether the vulnerability is actively exploited in the wild
  • The exposure level of the affected system
  • The system’s importance to business operations
  • Existing compensating controls

This is also the moment when some organizations begin asking another question: why wasn’t this already addressed by our managed service provider?

The answer is often tied to scope. Many MSPs handle operational tasks like patching or monitoring but their vulnerability management services may not be responsible for aligning prioritization with the client or patching all systems, such as printers, wireless access points, custom applications, or other components. Without clear expectations and oversight, important issues can easily slip into the gray area between operational support and security strategy.

Is Our MSP Actually Doing What Is Expected?

Managed service providers play an essential role for many organizations. They help manage infrastructure, monitor systems, and maintain day-to-day operations. But relying on an MSP introduces a new challenge: verifying that responsibilities are clearly defined and consistently delivered.

It’s not uncommon for organizations to assume certain security functions are covered simply because an MSP relationship exists. Questions sometimes arise during audits, assessments, or incidents:

  • Who is responsible for vulnerability remediation, such as those requiring configuration changes, versus basic patch deployment?
  • Are security alerts actively investigated or simply logged? Is all activity logged or are only alerts retained long-term?
  • What fourth parties does the MSP rely on in providing security services and how is that relationship managed?
  • Are backups being tested regularly? How, and is that enough validation for our disaster recovery strategy?
  • Who leads incident response if the provider itself experiences a security event?

The answers typically live in the service agreement, but those details may not always match internal expectations, and with scopes of work typically being comparable to a small novel, those details may be easy to overlook.

Regulatory guidance such as the FFIEC IT Handbook on Outsourcing Technology Services emphasizes the importance of oversight and risk management for third-party providers (https://ithandbook.ffiec.gov/it-booklets/outsourcing-technology-services.aspx).

Periodic reviews of provider responsibilities can help ensure that the relationship is functioning as intended and that security responsibilities are clearly understood on both sides.

Why These Questions Keep Appearing

Across these topics – regulatory pressure, AI governance, vulnerability prioritization, and MSP oversight – there is a common theme.

Most organizations do not lack capable people. What they often lack is time and specialized expertise. This is especially common in small organizations where staff already fill the duties of multiple roles, have trouble finding the “right fit” employee to fill a role due to being located in a rural area with a small applicant pool, or being in a saturated market where meeting the cost of a skilled SME is challenging.

Security leaders are balancing operational demands, regulatory expectations, strategic planning, and board reporting all at once. Even well-staffed teams can find it difficult to maintain momentum across every aspect of a security program.

This is one reason many organizations explore virtual Information Security Officer (vISO) support. A vISO can help provide strategic oversight, strengthen governance structures, and guide internal teams through regulatory expectations and program development while allowing internal staff to focus on operational execution.

Organizations approach this in different ways. Some engage vISO support after a regulatory finding or assessment. Others use it proactively to mature their security program before issues arise.

Either way, the goal tends to be the same: bring structure, clarity, and experienced guidance to complex security decisions. Information security is a continual process and is never finished.  vISO services help an organization maintain and improve its information security program.

 

Learn More About vISO Support

If your organization is navigating questions around regulatory expectations, AI governance, vulnerability prioritization, or MSP oversight, structured security leadership can make those conversations significantly easier.

Consider downloading our vISO services overview to learn more about how organizations are strengthening their information security programs.