‘A safe and secure cyber world’: An interview with the CISO of ISC2

Following is the transcript of an interview last week (Oct. 30) with Jon France, Chief Information Security Officer of the International Information System Security Certification Consortium (ISC2), at the 2025 ISC2 Security Congress in Nashville, Tennessee.

This interview has been condensed and edited for clarity.

Paul Wagenseil, SC Media:  ISC2 was founded, if I'm correct, as an organization to provide certifications and to provide standards for what was then a fairly new field of cybersecurity professionals. Is that correct?

Jon France, CISO, ISC2: Yes. If you look at the CISSP [Certified Information Systems Security Professional], which is probably our best-known qualification, that's 30 years old last year. We were founded obviously slightly before then to generate that.

We're the largest pure cybersecurity education body, professional body in the world. We've got 265,000 members and growing, so we're statistically relevant, you could say. But yeah, we were founded basically to not only educate and certify, but to further the profession.

Recently, we've obviously seen the profession go from a narrow church, technical skills. It's a much broader church now, but we're still cybersecurity at our core in terms of our products and offerings.

If it's a broader church, what else is in there besides cybersecurity?

If you look beyond the core certifications, we have certificate programs and offerings around AI. That's kind of topical at the moment, of course, can't not mention it. But we have leadership skill development, cyber leadership skills, which are relatively new and actually very much desired.

We have a lot of professional development on topics of the day. Some of them are sort of temporal, and we do insights and webinars and briefings on those kinds of things. We still are anchored in the cybersecurity landscape, but some of it will be commentary, some of it will be education. A little broader than just the core technical disciplines that we use as our bedrock, in essence.

You've got to grow with the times after all.

We've always been competency-based. We're not teaching you a specific vendor tool or technology. We address skills and competencies required to be in the profession.

If you look at the CISSP, we've got eight domains in there. I'm just going to pick one: identity and access management. That's a concept that goes across, whether you're a Microsoft shop, a Google shop, or whatever it happens to be. We trade on competencies. There'll be a body of practice that we relate back to.

I don't know if you heard some of the questions, "What are you doing in AI certification?" Well, AI is a bit new. It isn't a domain in its own right just yet. Eighty percent of what it is, is good systems engineering. That's covered for in our core body of knowledge and our competency base.

But we do have certificate programs because we do realize there are some top-up things in there. And eventually it'll make it back into the core qualifications.

Our certifications go through a three-year cycle. We do something called a job task analysis, JTA, which looks at what's required for jobs that get covered by this, and how. So that's how we deal with shift and drift.

And DCOs, Detailed Content Outlines, which is actually what's in the course and what's in the deliverable material. Those go through a three-year cycle, and that's how we keep fresh, relevant, and up to date.

It seems to me that offering a certification on AI may stray from the strict bounds of cybersecurity, but I don't know who else would be better qualified to do it.

The same goes with IAM. That's not entirely cybersecurity, but it's very, very close to it. It just bleeds into it. And especially with AI, identity management seems to be even more and more important.

I don't know if you were at [the ISC2] Town Hall [earlier during the Security Congress]. But that question got asked around AI certification, and Debra [Taylor], our acting CEO and CFO, was answering why it's not a distinct certification right now.

But if it becomes such in the future that it has a competency and a practice behind it, we're not closing the door to it. We just want to make sure that it is more than — I can't believe I'm going to say, "it's a fad," AI is not a fad — but at least look at it from a get-rid-of-the-hype [perspective].

IAM is the same way. The skill set is quite different than it is for cybersecurity. Most people don't instinctively realize that, for example, authentication and authorization are two different things.

Oh, very different. You're purporting to be person A? Yeah, go for it. Or machine A, or process A, or whatever it happens to be. There's a fundamental difference.

Sure. What does the "auth" in OAuth stand for? Which one does it stand for?

We've seen over the last few years zero trust as a way of shrinking trust boundaries, auth in everything too. It should be auth and authentication, authorization in everything. IoT drove a lot of that.

At ISC2, we're a 100% remote organization. The notion of a perimeter, it's been long since dead, but how do you put the controls?

If you look at the shrinking of what used to be the network, and then it used to be the VLAN, and then it might be the VPN connection, or whatever it happened to be, it's actually shrinking all the way down to identity as your perimeter. And it's not just human identity. It's process and machine identity as well.

The good thing about identity, for better or for worse, is that it's entirely portable if you do it right. It's the same in any context if you do it right, if you have common standards.

 Like many things in systems engineering, it's good if you do it right.

Getting back to the whole idea of ISC2, what is the organization's core mission today?

 A safe and secure cyber world.

We promulgate that mission through several ways. We know that building, growing a competent, qualified base of practitioners is a good solve to that. That's predominantly how we address that.

That's not all we do. We have quite a lot of advocacy activities as well. We go educate, discuss and shape opinions in regulators and in government sectors and circles and in large businesses.

One of the things that we would advocate for is things like harmonized regulation. If you're going to get a global practitioner base, or global organizations for that matter, to adhere to your rules and regulations, if you get them harmonized between different jurisdictions as much as possible, then it becomes a lower burden for us, and we will do better at it.

An example of that might be some of the AI Act in Europe. Europe's a good example of a block of trying to get harmonized across.

But that's a good example of one of our core missions is harmonization. We know that is a trading block. We try to do that, obviously, internationally as well.

One of the big issues that many industries, not just ours, are facing, there's things like reporting requirements.

If you look at the plethora of reporting requirements around cyber incidents, some are 24 hours, some are 72. Some have a catalog of, "You've got to give us these 10 things." Some of them, "You've got to give us these 20 things."

If I looked across all of those, we could harmonize it, even if not in time, but in items that you want reporting. It makes our lives much easier, and we'll do a better job at it.

What kind of clout or influence does your organization have to try to influence legislation of that sort?

We spend a long time building those relationships. We're not just a think tank of, "Here's a good idea." We back it with member opinion.

If we go back to that 265,000 qualified member base, we represent the wants, needs, and desires of a pretty big proportion of the profession. That's how we get relevance. We concentrate on the right topics. We're not lobbying, we are advocating.

We try and convene those kind of conversations as well. We'll bring together practitioners and companies, listen to them and then project their opinion into regulatory bodies. We are a member of a number of consortia and groups that do that across various different jurisdictions.

Amanda Steinman, Senior Manager of Corporate Communications at ISC2: One of our advocacy-team members that was here at Security Congress left yesterday [Oct. 29] and flew straight to Ottawa to testify in front of Canada's House of Commons on the C8 bill. They heard from members that this is important.

We need to share our members' opinions. They are discussing that and how it will impact the profession.

In other words, your opinion is sought by legislatures.

Jon France: Yes.

One thing that concerns a lot of people in this industry is maintaining the mental health of cybersecurity practitioners, trying to prevent and minimize burnout, while at the same time trying to forge career paths. Is ISC2 doing anything along those lines?

I don't know if we have a specific solve for it, but we do recognize it as a problem, and we do highlight it as one as well.

Through the workforce study that we do every year — the next one's expected later in November — there's a whole bunch of data, that part of that is around stresses in the industry. Some of that's threat landscape, some of that is not enough people to do the job, some of it's about skills deficit. And those things can lead to things like job dissatisfaction and burnout.

We absolutely do recognize it. We highlight that through public reporting. It's part of the commentary that the advocacy people talk about as well, is burnout in the industry.

Are we going to solve it directly ourselves? No. We have a great chapter network where that gets discussed at the chapter level.

A chapter is formed by practitioners attached to ISC2. But members don't have to be ISC2 qualified people, and they deal with local issues where you can go and talk. I know that's been talked about in some chapters.

That's almost a peer-to-peer talk track. The chapter network is a great way of having those conversations that are locally relevant today. They're geographically formed.

Another topic we keep hearing about is the cybersecurity job gap, that there's more jobs available than there are people to do them. I don't know if some of those figures are based on your statistics or on other people's. We seem to get these numbers from a lot of places.

We're also getting a lot of skepticism among practitioners about whether those numbers are actually accurate. Because I've heard, the idea is that companies are advertising for more jobs than they really have, or they're seeking people with skills that are impossible. Entry-level positions that require five years' experience.  Things like that.

So there's two separate issues.

One, let's talk about the jobs gap. The workforce study does have an element of that, but it's not done in a way of looking at open positions to the number of people to fulfill them.

It's done with — I'm going to call it the desire line. We ask around 15,000 people in the survey group, so it's statistically relevant. We ask them, "What do you think the resources are required to successfully discharge your responsibilities?"

That generates a number through a method they use here. And that has been expressed as a jobs gap. It's not the number of available positions in the market. It's the number of positions we think we need to do to discharge our duties.

I want to bust the myth of it: It's not that there's four and a half million jobs available.

You're getting this information from the membership, from the bottom up?

It's surveyed around 15,000. We use some other data sources as well. There is some market data in there. But there is a scientific methodology about how all of that comes together.

That's probably less important than the second topic we touched on, which is a skills gap. Through the last couple of years, and I'm sure the headlines will show this again in the upcoming workforce study, there might be a skills mismatch, and that's probably the keener problem we have.

The desire line for skills available in the market and the availability of the market with those candidate skills is an issue. We've seen the required, or the desired, skills mix change.

Unsurprisingly, cloud is in there, AI skilling is in there. But some of the soft skills as well: critical thinking, logical thinking, curiosity. Those kinds of things are coming to the fore as really good indicators of A) employability, and B) that they'll be a good candidate.

Entry-level positions are not now requiring only degree-qualified candidates. That's starting to fall away slightly, which is good news because we're a broad church and we need lots of people in it.

Then the last piece you mentioned, which is job description abuse. "I want an entry-level person with a CISSP."

The CISSP is a senior-level qualification that requires at least five years' experience in the industry. That's not entry level.

Not the workforce study, but the Hiring Managers' Trend Report showed that. We do quite a lot to try and say, "Look, put a job description together appropriately and you might get the right candidates for it."

One of the pieces of advice is that the hiring manager should work with the HR department to express what is actually required, not just, "Oh, I've seen CISSP written somewhere, I'm going to stick that in as a requirement."

We do think good signposting is through certification, though. We have entry level CC [Certified in Cybersecurity] through to mid-levels, things like SSCP [Systems Security Certified Practitioner], through to senior-level CISSP through to very advanced, AP, EP and MP, which is architecture management and architecture engineering and management [Information Systems Security Architecture Professional, Information Systems Security Engineering Professional and Information Systems Security Management Professional].

What is interesting to me is that you have a lot of people coming up in the cybersecurity world, or the software-development world, especially when it comes to AI, who, from my old-time perspective, have no idea of how to use common cybersecurity best practices that have been developed over the past couple of decades.

I don't know if there's a way to get greybeards to tell the young developers how to do this properly. Is that something that you're working on? It's a little bit outside the bounds of cybersecurity because it involves developers as well.

Well, yes and no. Security is not a treatment for business. It's an inherent part of it. If you bolt it on at the end, you're doing it wrong. That isn't just the cybersecurity bit of the business. It's a development piece as well.

Another one of my favorite phrases internally is, "Let's not do firefighting, let's go after the arsonist." Flippantly sort of saying things like that, but practically, we have a certification, which is LP [Certified Secure Software Lifecycle Professional], which is lifecycle management, which is aimed at developers.

We're seeing some of the technological changes, like memory-safe languages, in Rust, et cetera. It's out there. But like anything, you have to be intentional about adoption.

I think getting developers to adopt it, it's now becoming a business imperative much more than it was, because the attack vectors out there are growing.

It's not only education and skilling. We're a part of that mix and helping solve for that. It's also hearts and minds, which is, "You need to do this if you're going to survive in the digital world, if your product's based on digital componentry, make sure they're delivered secure."

There's an operational piece that we absolutely do have direct addressment through, which is security design, development, deployment, and maintenance.

It is the life cycle. It's not just, "Oh yeah, I've done the design securely." OK, was it implemented securely? Is it operated securely? There are disciplines across the whole stack for that.

That's why we say is it is the life cycle — and disposal if you're looking at the death stage — and really impressing that upon people. I think we're winning — maybe not as quickly as we'd like to.

I think you were until AI came along.

I can't remember which keynote mentioned it, maybe it was Alissa [Knight]: "Threats are now moving at machine speed. You cannot have your defenses moving at human speed."

It's definitely getting the right mix. If we look at the vendor landscape and security tooling, they've all got AI offerings in some way, shape, or form.

We can have a philosophical argument: Are they really AI, is it ML, or is it just smoke and mirrors? But we're definitely moving beyond human tooling and machine tooling. That can also help on the defense side, so we're using AI for fuzzing, for vulnerability detection, for code analysis, those kinds of things.

And you have to protect the AI models themselves.

I look at AI in three bubbles. You've got the security of AI itself. That's things like prompt injection, model inversion, poisoning, those kinds of things.

If you move it slightly away from the technical ones, there's things like hallucinations and believability and copyright and ethics and a whole bunch of stuff. It's all to do with the security and believability of AI.

The next part I look at is using AI for good security outcomes. How do I adopt it, as a CISO, that is going to help me discharge my duties and protect my core assets?

That's something that we are playing a part in through our certificate programs. We educate on AI strategy development and securing AI. That's one of the certificates we have: using AI for good security outcomes.

And then the third bubble is a leadership bubble. The bubble is actually businesses adopting AI for business outcomes, whether that be efficiency gain or capability gain.

We're being asked, thankfully, and asked more often than not now, how do I do that in a way that's risk managing, if I look back to the security-of-AI bubble, and how do I do it securely in business?

Security leadership is actually part of that conversation. Here's where you can afford to take a bit of risk, here's how we're going to mitigate some risk of AI adoption.

I look at it in three bubbles. And then there's the intersections, and you can start to put job roles in there. Regulators are going to be interested in the business use of it and security of AI.

Engineers are going to be looking at it for good security outcomes and potentially the security of AI. Policy people will probably be right in the middle. Leadership's definitely been — they care about it all.

But you can start to sort of chunk it up and examine it from different angles.

I'm glad to hear that people are asking questions about it.

In fact, if you went to any of the [Security Congress] sessions around AI, a lot of it is around, "How do I adopt it in a way that it comes down to some of the standards you've seen," ISO 42001, which is a management system around AI.

NIST has got the NIST AI RMF, risk management framework. Those are not technical disciplines. They are management disciplines for adopting AI.

AI has really only been around two years, at least in the form that everyone recognizes it. It's interesting that they came out into the fore very quickly.

That is a good thing. It took a lot longer for the same thing to happen with Windows 95. Thank you very much.