InfoSec Compliance & AI Governance For over 20 years, DISC InfoSec has been a trusted voice for cybersecurity professionals—sharing practical insights, compliance strategies, and AI governance guidance to help you stay informed, connected, and secure in a rapidly evolving landscape.
The role of CISO first emerged as organizations embraced digital revolutions and began relying on new data streams to help inform business decisions. As technology continued to advance and became more complex, so too did threat actors who saw new opportunities to disrupt businesses, by stealing or holding that data hostage for ransom.
As the years have gone by and cyberattacks have become more sophisticated, the role of the CISO has had to advance. The CISO has evolved from being the steward of data to also being a guardian for availability with the emergence of more destructive and disruptive attacks. The CISO also must be highly adaptable and serve as the connective tissue between security, privacy and ultimately, consumer trust.
Here are five signs that a virtual CISO may be right for your organization.
1. You have a lot to protect
Companies produce more data than ever, and keeping track of it all is the first step to securing it. A virtual CISO can identify what data needs to be protected and determine the negative impact that compromised data can have, whether that impact is regulatory, financial or reputational.
2. Your organization is complex
Risk increases with employee count, but there are many additional factors that contribute to an organization’s complexity: the number of departments, offices and geographies; how data is used and shared; the distribution of architecture; and the life cycle of applications, data and the technology stack.
A virtual CISO offers an unbiased, objective view, and can sort out the complexity of a company’s IT architecture, applications and services. They can also determine how plans for the future add complexity, identify and account for the corresponding risk, and recommend security measures that will scale to support future demand.
3. Your attack surface is broad
For many organizations, potential vulnerabilities, especially those that share a great deal of data within the organization, may not be obvious at first glance. Virtual CISOs can identify both internal and external threats, determine their probability and quantify the impact they could have on your organization. And at a more granular level, they can determine if those same threats are applicable to competitors, which can help maintain competitiveness within your market.
4. Your industry is highly regulated
Organizations in regulated industries like healthcare, finance, energy/power and insurance will have data that is more valuable, which could make them a bigger target for bad actors. Exposure is even more of a concern due to potential noncompliance. Virtual CISOs bring a wealth of expertise on regulatory standards. They can implement processes to maintain compliance and offer recommendations based on updates to applicable rules and regulations.
5. Your risk tolerance is low
An organization without a great deal of sensitive data may have a much greater tolerance for risk than a healthcare provider or a bank, but an honest assessment is important in determining how much risk each organization should accept. A virtual CISO can coordinate efforts to examine perceived and actual risk, identify critical vulnerabilities and provide a better picture of risk exposure that can inform future decisions.
Cybersecurity is growing more complex, and organizations of all sizes, especially those in regulated industries, require a proven security specialist who can address the aforementioned challenges and ensure that technology and processes are in place to mitigate security risks.
As Jack Jones, co-founder of RiskLens, tells the story, he started down the road to creating the FAIR™ model for cyber risk quantification because of “two questions and two lame answers.” As CISO at Nationwide insurance, he presented his pitch for cybersecurity investment and was asked:
“How much risk do we have?”
“How much less risk will we have if we spend the millions of dollars you’re asking for?”
To which Jack could only answer “Lots” and “Less.”
“If he had asked me to talk more about the ‘vulnerabilities’ we had or the threats we faced, I could have talked all day,” he recalled in the FAIR book, Measuring and Managing Information Risk.
In that moment, Jack saw the need for a way that cybersecurity teams could communicate risk to senior executives and boards of directors in the language of business, dollars and cents.
Some CISOs are still in the position of Jack pre-quantification – talking all day and delivering lame answers, from the board’s point of view. Here’s a short guide to what they’re not saying – and how RiskLens, the analytics platform built on FAIR, can provide the right answers.
1. I don’t really know what our top risks are
I can ask a group of subject matter experts in the company to vote on a top risks list based on their opinions, but that’s as close as I can get.
Top Risks is the first report that many new RiskLens users run, and it only takes minutes, using the Rapid Risk Assessment capability of the RiskLens platform. The platform guides you through properly defining a set of risks (say, from your risk register) for quantitative analysis according to the FAIR standard. To speed the process, the platform draws on data from pre-populated loss tables. The resulting analysis quickly stack-ranks the risks for probable size of loss in dollar terms, across several parameters.
2. I can’t give you an ROI on the money you give me to invest in cybersecurity
You see, cybersecurity is different from other programs you’re asked to invest in – it’s constantly changing and never-ending. You never really hit a point of success; you just chip away at the problem.
With Top Risks in hand, RiskLens clients can dig deeper on individual scenarios and run a Detailed Analysis to expose the drivers of risk to see, for instance, what types of threat actors account for the highest frequency of attacks or what classes of assets account for the highest probable losses. Then they can run the Risk Treatment Analysis capability of the platform to evaluate controls for their ROI in risk reduction.
3. I can’t really tell you if things are getting better on cyber risk.
I can show you our progress with compliance checklists and maturity scales, and I hope you’ll assume that’s reducing risk.
While compliance with NIST CSF, CIS Controls, etc. is good and useful, these frameworks don’t measure performance outcomes in reducing risk – that takes a quantitative approach. The RiskLens platform can aggregate risk scenarios to generate risk assessment reports showing risk across the enterprise or by business unit, in dollar terms – and to show risk exposure over time. It’s easy to update and re-run risk assessments, thanks to the platform’s Data Helpers that store risk data for re-use. Update a Data Helper, and all the related risk scenarios update at the same time – and so do the aggregated risk assessments.
4. I can’t help you set a risk appetite.
I don’t really know how much risk we have and am pretty much operating on the principle that no risk is acceptable.
Boards should have a strong sense of their appetite for risk in cyber as in all fields, but qualitative (high-medium-low) cyber risk analysis only supports vague appetite statements that are difficult to follow in practice. On the RiskLens platform, a CISO can input a dollar figure for “risk threshold” as a hypothetical, and run the analyses to rank how the various risk scenarios stack up against that limit, making a risk appetite a practical target.
5. I don’t know how to align cyber risk management with the other forms of risk management we do.
Enterprise risk, operational risk, market risk, financial risk—I’ve heard their board presentations in quantitative terms. But cyber is just different.
Quantification is the answer – reporting on cyber risk in the same financial terms that the rest of enterprise risk management programs employ finally gives the board what it wants to hear on cyber risk management. ISACA, the National Association of Corporate Directors and the COSO ERM framework have all recommended FAIR for board reporting. As an ISACA white paper said,
The more a risk-management measurement resembles the financial statements and income projections that the board typically sees, the easier it is for board members to manage cybersecurity risk…FAIR can enable the economic representation of cybersecurity risk that is sorely missing in the boardroom, but can illuminate cybersecurity exposure.
Infection Monkey is an open source Breach and Attack Simulation tool that lets you test the resilience of private and public cloud environments to post-breach attacks and lateral movement, using a range of RCE exploiters.
Infection Monkey was created by Israeli cybersecurity firm Guardicore to test its own segmentation offering. Developer Mike Salvatore told told The Stack: “Infection Monkey was inspired by Netflix’s Chaos Monkey.
“Chaos Monkey randomly disables production instances to incentivize engineers to design services with reliability and resilience in mind. We felt that the same principles that guided Netflix to create a tool to improve fault tolerance could be applied to network security. Infection Monkey can be run continuously so that security-related shortcomings in a network’s architecture can be quickly identified and remediated.”
The company recently added a Zero Trust assessment, as well as reports based on the MITRE ATT&CK framework.
CISO role is not only limited to understanding infrastructure, technologies, threat landscape, and business applications but to sway people attitude and influence culture with relevant policies, procedures and compliance enforcement to protect an organization.
By: Melissa Musser, CPA, CITP, CISA, Risk & Advisory Services Principal, and Darren Hulem, IT and Risk Analyst The COVID-19 crisis, with a new reliance on working from home and an overburdened healthcare system, has opened a new door for cybercriminals. New tactics include malicious emails claiming the recipient was exposed COVID-19, to attacks on…Read more ›
Small- to medium-sized nonprofits and associations are particularly at risk, and many are now employing an outsourced Chief Information Security Officer (CISO), also known as a Virtual CISO (vCISO), as part of their cybersecurity best practices.
vCISO model not only offers flexibility over time as the organization changes, providers are also able to deliver a wide range of specialized expertise depending on the client’s needs.
The vCISO offers a number of advantages to small- and medium-sized organizations and should be part of every nonprofit’s or association’s risk management practices.
What are enterprises seeking in their next CISO – a technologist, a business leader or both? Joyce Brocaglia of Alta Associates shares insights on the key qualities
What kinds of CISOs are being replaced? Brocaglia says that an inability to scale and a tactical rather than strategic orientation toward their role are two reasons companies are looking to replace the leaders of their security teams—or place them underneath a more senior cybersecurity executive. They are looking for professionals with broad leadership skills rather than a “one-trick pony.”
Today’s organizations want the CISO to be intimately involved as a strategic partner in digital transformation initiatives being undertaken. This means that their technical expertise must be broader than just cybersecurity, and they must have an understanding of how technology impacts the business—for the better and for the worse. And candidates must be able to explain the company’s security posture to the board and C-suite in language they understand—and make recommendations that reflect an understanding of strategic risk management.
CISOs who came up through the cybersecurity ranks are sometimes at a disadvantage as the CISO role becomes more prominent—and critical to the business. Professionals in this position will do well to broaden their leadership skills and credentials, sooner rather than later.
Never-ending breaches, ever-increasing regulations, and the potential effect of brand damage on profits has made cybersecurity a mainstream board-level issue. It has never been more important for cybersecurity controls and processes to be in line with business
priorities.
A recent survey by security firm Varonis highlights that business and security are not fully aligned; and while security teams feel they are being heard, business leaders admit they aren’t listening.
The problem is well-known: security and business speak different languages. Since security is the poor relation of the two, the onus is absolutely on security to drive the conversation in business terms. When both sides are speaking the same language, aligning security controls with business priorities will be much easier.
Well-presented metrics are the common factor understood by both sides and could be used as the primary driver in this alignment. The reality, however, is this isn’t always happening
SecurityWeek spoke to several past and present CISOs to better understand the use of metrics to communicate with business leaders: why metrics are necessary; how they can be improved; what are the problems; and what is the prize?
Demolishing the Tower of Babel
“While some Board members may be aware of what firewalls are,” comments John Masserini: CISO at Millicom Telecommunications, “the vast majority have no understanding what IDS/IPS, SIEMs, Proxies, or any other solution you have actually do. They only care about the level of risk in the company.”
CISOs, on the other hand, understand risk but do not necessarily understand which parts of the business are at most risk at any time. Similarly, business leaders do not understand how changing cybersecurity threats impact specific business risks.
The initial onus is on the security lead to better understand the business side of the organization to be able to deliver meaningful risk management metrics that business leaders understand. This can be used to start the process for each side to learn more about the other. Business will begin to see how security reduces risk, and will begin to specify other areas that need more specific protection.
The key and most common difficulty is in finding and presenting the initial metrics to get the ball rolling. This is where the different ‘languages’ get in the way. “The IT department led by the CIO typically must maintain uptime for critical systems and support transformation initiatives that improve the technology used by the business to complete its mission,” explains Keyaan Williams, CEO at CLASS-LLC. “The Security department led by the CISO typically must maintain confidentiality, integrity, and availability of data and information stored, processed, or transmitted by the organization. These departments and these leaders tend to provide metrics that focus on their tactical duties rather than business drivers that concern the board/C-suite.”
Drew Koenig, consultant and host of the Security in Five podcast, sees the same basic problem. “In security there tends to be a focus on the technical metrics. Logins, blocked traffic, transaction counts, etc… but most do not map back to business objectives or are explained in a format business leaders can understand or care about. Good metrics need to be tied to dollars, business efficiency shown through time improvements, and able to show trending patterns of security effectiveness as it relates to the business. That’s the real challenge.”
Williams sees the problem emanating from a lack of basic business training in the academic curriculum that supports IT and security degrees. “The top management tool in 2017 was strategic planning,” he said. “Strategic planning is often listed as one of the top-five tools of business leaders. How many security leaders understand strategic planning and execution enough to ensure their metrics contribute to the strategic initiatives of the organization?”
It is not up to the business leaders to learn about security. “The downfall for many CISOs in the past is believing that business needs to understand security,” adds Candy Alexander, a virtual CISO and president-elect of ISSA. “That is a mistake, because security is our job. We need to better understand the business, so that we can articulate the impact of not applying appropriate safeguards. The key to this whole approach is for the CISO to understand the business, and to understand the mission and goals of the business.”
In order for CISOs to stay relevant in their field today, they must add communication and soft skills to their list of capabilities. Traditionally, their role has been to take charge of IT security. Now CISOs oversee cybersecurity and risk management systems. They must manage teams and get leadership approval in order to successfully implement a system that aligns with overall business goals.
Speak in a common business language
The CISO will need to appoint both technical and non-technical individuals to support a risk management system, which requires communication in a language that everyone can relate to. Additionally, senior executives’ approval is required and this will involve presenting proposals in non-technical terms.
Being able to communicate and having the soft skills to manage people is a challenge CISOs face. For CISOs to reach a larger audience, they need to clearly explain technical terms and acronyms that are second nature and translate the cybersecurity risks to the organization into simple business vocabulary.
Get the tools to gain the skills
IT Governance Publishing books are written in a business language that is easy to understand even for the non-technical person. Our books and guides can help you develop the softer skills needed to communicate in order to successfully execute any cybersecurity or risk management system.
Discover the best-practice cyber risk management system, ISO 27001
This international standard sets out a best-practice approach to cyber risk management that can be adopted by all organizations. Encompassing people, processes, and technology, ISO 27001’s enterprise-wide approach to cybersecurity is tailored to the outcomes of regular risk assessments so that organizations can mitigate the cyber risks they face in the most cost-effective and efficient way.
AI Governance for Bay Area Startups: What to Put in Place Before Enterprise Customers Ask
There’s a specific email that changes a startup’s quarter. It arrives from a champion who is genuinely on your side, and it reads something like: “Security review went fine, but our AI risk team added a section. Can you send over your AI governance documentation?”
You have a SOC 2. You do not have AI governance documentation. The deal is in the forecast. The quarter closes in five weeks.
I’ve now watched this play out enough times to say it plainly: the AI governance question in enterprise procurement is not coming, it’s here, and the timeline mismatch is brutal. A certifiable management system takes six to eighteen months to build and operate. Procurement does not pause while you build one. The startups that clear this cleanly are the ones that assembled the artifacts before the questionnaire arrived — which, conveniently, is also the cheapest time to do it.
This post is for founders, first security hires, and technical co-founders at Bay Area startups shipping AI features into enterprise accounts. Two things are true for you simultaneously that aren’t true for most companies: your buyers are the enterprises applying the pressure, and your legal address is in the state with the most active AI and privacy regulator in the country.
Why this shifted so fast
Three forces converged in roughly twelve months.
Enterprise procurement rewrote its questionnaires. The 2026 SIG update added an expanded AI governance section; CAIQ picked up AI-specific control mappings. Practically every substantive vendor security questionnaire in the second half of 2026 now contains an AI block. Industry reporting puts “Are you ISO 42001 certified or implementing it?” in roughly 40% of enterprise AI vendor RFPs in the EU and around 25% in North America.
ISO/IEC 42001 became the artifact procurement can file. Published December 2023, it’s the first certifiable international standard for AI management systems. Anthropic certified in January 2025; Snowflake, ServiceNow, CrowdStrike and others followed. More than 350 organisations globally held certificates by mid-2026. The pattern is exactly what SOC 2 did to SaaS procurement a decade ago: a voluntary good practice quietly becoming a default filter that removes vendors who can’t answer.
The EU AI Act’s high-risk obligations landed on 2 August 2026. If you sell into EU-facing customers, their obligations flow contractually back to you regardless of where you’re headquartered — Articles 25 and 26 are the mechanism.
Here’s the part I want to be honest about: your buyer’s AI risk team is not trying to make your life difficult. They’re being asked by their own board, auditors, and insurers to demonstrate control over AI risk. If you can’t answer, the risk transfers to them. That’s why the questions come before signature and not after.
The California layer nobody warns startups about
Bay Area founders tend to think of AI regulation as a Brussels problem. It isn’t. California moved first among US states, and several deadlines have already passed.
Rule
What it reaches
Status
CPPA ADMT regulations (under CCPA/CPRA)
Automated decision-making technology used for significant decisions — employment, housing, credit, healthcare, education
Effective 1 Jan 2026. Risk assessments required now. Consumer rights (pre-use notice, opt-out, access to decision logic) by 1 Jan 2027. First CPPA attestations 1 Apr 2028.
AB 2013
Generative AI training data transparency
Documentation deadline 1 Jan 2026
SB 942 (AI Transparency Act)
Provenance disclosure and detection tooling for GenAI systems with >1M monthly users accessible in California
Operative 2 Aug 2026, further phases 2027–2028
SB 53 (Transparency in Frontier AI Act)
Frontier developers above ~10²⁶ training FLOPs; transparency reports and critical-incident reporting
Effective 1 Jan 2026 — most startups are nowhere near the threshold
AB 489
AI implying licensed healthcare care without human oversight, including in advertising
Effective 1 Jan 2026
One detail in the ADMT rules is worth an architecture conversation, not just a legal one. Advisory tools — systems that produce recommendations, scores, or analysis for a human decision-maker — are explicitly excluded from the ADMT definition, provided there is genuine human involvement in the final decision. CPPA staff testified during rulemaking that this narrowing cut coverage to roughly 10% of CCPA-covered businesses.
That single distinction is one of the highest-leverage design decisions available to an early-stage AI product. A system that informs a human decision and a system that makes it can look nearly identical in the product demo and land in completely different regulatory buckets. Decide which one you’re building deliberately, document the reasoning, and make sure the human involvement is real rather than a rubber-stamp UI. “Genuine” is doing load-bearing work in that sentence, and a regulator will read it the same way an auditor reads “human oversight” under EU AI Act Article 14 — as a demonstrated capability to intervene, override, and disregard.
Standard caveat: I’m a security and governance practitioner, not an attorney. Scoping decisions of this kind should be run past counsel.
The eight artifacts to have on the shelf
None of this requires a compliance team. At startup scale, most of it is a focused week of work plus a habit. Every item below maps to something a questionnaire actually asks and to a clause an auditor will actually test.
1. An AI system inventory
Every AI system you build, embed, or consume — including the ones your team adopted without telling anyone. Vendor-embedded AI counts. Your support tool’s summarisation feature counts. For each: intended purpose, model and provider, data it touches, who it affects, what decision it informs, and whether a human reviews the output.
Anchors: ISO 42001 Clause 4.3 (scope) and the AI system register; NIST AI RMF MAP 1.1. Effort: one afternoon with a spreadsheet, if you’re honest. Why first: you cannot govern, scope, or certify what you haven’t listed, and this is the single artifact that unblocks all seven others.
2. An impact assessment for each material system
ISO 42001’s AI system impact assessment (AISIA) is mandatory under Clause 6.1.2. It asks: intended purpose, output type, impact domain, affected population, severity if it fails, reversibility, and whether human oversight exists. Low / medium / high classification then drives which controls you actually need.
Why it matters commercially: this is the document that lets you answer “how do you assess AI risk?” with a process rather than an adjective. It also does double duty against the CPPA risk assessment requirement and EU AI Act classification questions.
3. A signed AI policy and an acceptable use policy
Two short documents, not a binder. The AI policy states your principles, scope, and objectives, and carries a founder’s signature. The acceptable use policy tells your own team what they may and may not put into which tools — the practical antidote to shadow AI.
Anchors: Clause 5.2, Annex A.2.2 (AI policy), A.9.2 (responsible use processes). Effort: a day to draft, an hour to sign. Please actually sign it; unsigned policies are the most common finding I write.
4. A named accountable owner
One person, not a committee. Someone whose job description includes knowing which AI systems are running, what they can do, and what happens when one misbehaves. At a 30-person company this is usually a technical co-founder or the first security hire, and that’s fine — what matters is that the name is written down.
Anchors: Clause 5.3 (roles and responsibilities); NIST AI RMF GOVERN 1.1 and GV-3. Why buyers care: “who is accountable?” is now a standard questionnaire line, and “the team” is a failing answer.
5. Data provenance and a training-data position
Where does training or fine-tuning data come from, what rights do you have to it, and — the question every enterprise buyer asks — do you or your model providers train on customer data? You need the contractual proof, not just the intention: the no-training clause in your provider’s terms, the configuration that enforces it, and the retention settings.
Anchors: Annex A.7 (data for AI systems); AB 2013 for generative training data disclosure. Effort: mostly reading your own vendor contracts, which is a useful exercise regardless.
6. A model and sub-processor register with real diligence
Every model provider and AI-enabled sub-processor, with what they process, where, under what terms, and what happens if they change models underneath you. Enterprise buyers increasingly want the chain, not just your name.
Anchors: Annex A.10.3 (suppliers, allocation of responsibilities across the AI value chain); NIST AI RMF GOVERN 6. Note: silent model swaps by your provider are a real change-management risk and a question sophisticated buyers now ask directly.
7. Human oversight design — with a kill switch you’ve actually tested
Define, per system, where a human must be in the loop, what the escalation path is, and how you stop the thing. Then test the stop. Kiteworks’ 2026 survey across 459 organisations found only about 21% could automatically terminate a misbehaving agent’s access, and among those running AI in production, 23% had never tested their termination process end to end. Gravitee’s 2026 survey of 900+ practitioners found more than half of deployed agents operating with no security oversight or logging, and 88% of organisations reporting confirmed or suspected agent security incidents in the year.
An oversight mechanism that can’t intervene isn’t a control — it’s a place to assign blame after the fact. Anchors: EU AI Act Art. 14; ISO 42001 human oversight controls; NIST AI RMF MANAGE.
8. Logging that answers four questions
Your AI logs should let you reconstruct: who authorised this, what context did the system have, what did it decide, and was that consistent with policy? If you can’t answer all four from your telemetry, you’re not audit-ready — and if you have EU-facing high-risk exposure, Article 26 obliges deployers to retain logs for at least six months, monitor operation, ensure staff competence, and notify incidents.
The practitioner’s version: when I led ShareVault through ISO 42001 Stage 2 certification, the difference between a clean pass and a nonconformity was almost never whether a control existed. It was whether we could produce the artifact that proved it operated. Controls are cheap. Evidence is the product.
Sequencing for a 20-to-50-person company
Days 1–30 — Get honest. Build the inventory. Draft and sign the AI policy and acceptable use policy. Name the owner. Read your model providers’ data terms and write down your training-data position. This is roughly one focused week spread over a month, and it answers about 60% of a typical AI questionnaire block.
Days 31–60 — Get defensible. Run impact assessments on your two or three material systems. Stand up the sub-processor register. Define human oversight thresholds per system and test the kill switch. Write a one-page AI incident runbook that includes prompt injection and data-leak scenarios — treat a prompt injection event in a regulated context as a compliance event, not just a security ticket.
Days 61–90 — Get ahead of the ask. Turn the artifacts into a reusable answer library and a public trust page section on AI governance. Decide your certification posture: ISO 42001 now, or a documented, dated roadmap. A credible roadmap is an acceptable answer to most buyers today. “We take AI safety seriously” is not.
If you already hold ISO 27001, this is far less work than it sounds — the two standards share the Annex SL High Level Structure, so context, leadership, planning, support, evaluation, and improvement are one system serving two standards. Organisations with a running ISMS typically complete ISO 42001 in a meaningful fraction of the elapsed time.
Three mistakes I’d rather you skip
Chasing the certificate before the inventory. Certification scope is derived from what you actually run. Starting with an auditor conversation before you have a system register means paying someone to discover your own environment.
Buying a platform instead of making decisions. Governance tooling is genuinely useful after you’ve decided who is accountable, what your risk appetite is, and which systems are in scope. Bought first, it becomes an expensive dashboard displaying unresolved questions.
Answering a questionnaire aspirationally. This is the one that actually causes damage. A questionnaire response is a representation to a customer. If you claim a control you can’t evidence and an incident follows, you’ve converted a security problem into a contractual and potentially a misrepresentation problem. When I ran a scanner against a client environment and it produced findings I couldn’t reproduce, I pulled them from the report rather than pad it — same principle applies in reverse here. Say what’s true, say what’s planned, date the plan.
The founder’s advantage
Here’s the thing large enterprises would pay a great deal for and can’t buy: your scope is small. You have four AI systems, not four hundred. You can enumerate every model call in your product in an afternoon. You can get a policy signed by walking across the room. The AI management system that takes a 5,000-person company eighteen months of committee work is, at your stage, a couple of weeks of clear thinking plus a discipline of keeping the register current.
That advantage has a short half-life. Every quarter you grow, the inventory gets harder, the shadow AI gets deeper, and the retrofit gets more expensive. The best time to build this was before your first enterprise deal. The second-best time is before the questionnaire lands in your inbox — which, based on where procurement is heading in 2026, is probably this quarter.
Where to start with DISC InfoSec
DISC InfoSec helps Bay Area B2B SaaS and financial services startups get from “we ship AI features” to “here’s our documented, evidenced AI management system” — without a compliance department. I led ShareVault, a virtual data room platform serving M&A and financial services clients, through ISO 42001 Stage 2 certification on the first audit attempt, as the internal practitioner who did the work.
The readiness path is deliberately incremental:
Free 15–20 minute readiness call — where you actually are, and what the next rung costs.
ISO 42001 gap assessment — | ISO 27001 gap assessment — — clause-level, with a prioritised remediation roadmap.
Quick-Start engagement, 7–10 days — the core artifact set built and handed over.
Full implementation and certification support — including internal audit.
If an AI governance section just showed up in a live deal, start with the call — most of the questions in front of you are answerable faster than you think.
DiscInfoSec— Principal Consultant, DISC InfoSec (Deura Information Security Consulting LLC), Petaluma, CA CISSP, CISM | ISO/IEC 42001 & ISO/IEC 27001 Lead Implementer | PECB Authorized Training Partner
How Much of a Job Can AI Automate? What Remains valuableis not the leftover task
In my last post I argued that governing AI is a more durable bet than racing to build with it. The obvious follow-up question is the harder one, and it’s the question I now get asked in almost every client conversation, usually by someone who has just watched an agent do in four minutes what used to take their team a week:
How much of a job can actually be converted into an AI-executable workflow — and what is still worth paying for once that conversion happens?
Most of the public debate answers this at the level of job titles. That’s the wrong unit of analysis. Jobs don’t get automated; tasks do. And once you look at tasks, the answer gets both more measurable and considerably more uncomfortable.
The conversion rate is already higher than most leaders think
We finally have task-level evidence instead of survey vibes. Anthropic’s Economic Index tracks what people actually delegate to a model, mapped against the U.S. Department of Labor’s O*NET task taxonomy.
Three findings matter for this question:
Roughly 49% of jobs in the sample have seen at least a quarter of their constituent tasks performed with AI — up from about 36% a year earlier. Around 4% of occupations see it across three-quarters of their tasks.
Of observed usage, 68% sits on tasks rated fully feasible for a model working alone. Only about 3% of usage sits on tasks rated not feasible. Delegation is concentrating on the genuinely convertible.
API traffic runs roughly three-quarters automated, versus a near-even split on the consumer product. That’s the tell. When a task migrates from a chat window into a pipeline, the human turn count drops toward zero — and it stops being a productivity aid and becomes an executable workflow.
So the honest answer to “how much” is: for a large share of knowledge roles, somewhere between a quarter and half of the task inventory is already convertible today, and the frontier is moving through the remainder in the direction of more autonomy, not less.
But that’s the easy half of the question.
The uncomfortable part: the residual is not automatically the valuable part
There’s a comforting story we tell ourselves — AI takes the drudgery, humans keep the interesting work. The task-level data does not support it.
When Anthropic ran the thought experiment of removing AI-covered tasks from job descriptions, the first-order effect was to deskill the average job, because the tasks currently covered skew toward the ones requiring more education. Technical writers, travel agents, teachers: what’s left after you subtract the model’s coverage is often the coordination, the chasing, the formatting, the sitting-in-the-meeting.
Pair that with Anthropic’s labor-market analysis, which found no clear unemployment signal in high-exposure occupations as of early 2026, but did find hiring of 22-to-25-year-olds into the most exposed roles slowing by roughly 14% against a counterfactual. The pipeline compresses before the headcount does. Entry-level work is precisely the “do the convertible tasks under supervision until you develop judgment” apprenticeship that the conversion eats first.
So the strategic question isn’t “will my job be automated.” It’s “when the convertible tasks leave, is the residual a promotion or a demotion?”
That depends almost entirely on whether you own the part of the workflow that cannot be delegated. And that part has a name in every AI governance framework written to date: accountability.
A practical conversion audit for your own role
Before deciding what to defend, decompose. Here is the audit I run with clients, borrowed structurally from the MAP function of the NIST AI Risk Management Framework (AI RMF 1.0) — MP-1 context of intended use, MP-3 stakeholder impact, MP-4 risk prioritisation.
List every recurring task in the role. Score each on four axes:
Axis
Question
Why it matters
Specifiability
Can success be defined in writing, in advance, without you in the room?
Unspecifiable work can’t be converted — but it also can’t be scaled or defended.
Feasibility
Could a competent model do this alone, given the right context and tools?
This is the raw conversion ceiling.
Reversibility
If it’s done wrong, can the decision be unwound?
A mis-sorted ticket is cheap. A denied credit application, a mis-scoped data room permission, a wrongly redacted disclosure document is not.
Attributability
When it goes wrong, whose name is on it?
This is the axis that survives everything.
The pattern is consistent across the roles I’ve audited:
High specifiability, high feasibility, high reversibility — retrieval, summarisation, first-draft generation, format conversion, control-language mapping, reconciliation against a defined rubric. Convert these now. Defending them is a losing position and, frankly, keeping them is a waste of a professional.
High feasibility, low reversibility — eligibility determinations, access provisioning, disclosure decisions, anything touching a regulated outcome. Convertible in execution, not in authority. The model drafts; a named human owns.
Low specifiability — judgment under conflicting stakeholder interests, negotiating a finding with an auditor, telling a CEO their flagship AI feature isn’t defensible. Not convertible, and the reason is not model capability. It’s that nobody can write down the success criteria in advance, which means nobody can hand over the consequences either.
What remains valuable: five capabilities that survive conversion
1. Specification — turning tacit process into a testable spec
The bottleneck on agentic deployment turns out not to be model capability. Deloitte’s 2026 survey of 3,235 leaders found roughly three-quarters of enterprises expecting to use agentic AI at least moderately within two years, while only about 21% had a mature governance model for autonomous agents. Every credible study lands in the same place: integration, data quality, and decision rights are what stall, not intelligence.
Which means the person who can take an undocumented process living in three people’s heads and render it as an explicit, bounded, testable specification — inputs, tools, permitted actions, escalation thresholds, definition of done — is doing the work that makes conversion possible at all. That skill maps directly to ISO/IEC 42001 Annex A.6 (AI system lifecycle) and A.9.2 (processes for responsible use). It is also the least automatable thing in the building, because it requires knowing which undocumented exceptions actually matter.
2. Oversight design — and the difference between oversight and theatre
Grant Thornton’s 2026 AI Impact Survey found only 5% of organisations allow agents to execute high-stakes decisions without human review. Encouraging, until you check whether the review can actually intervene.
Kiteworks’ 2026 annual survey scored AI governance maturity at 35 out of 100 across 459 organisations — roughly 7 of 19 measured capabilities deployed. Only about 26% restrict AI agents to authorised tasks and data scopes. Only about 21% can automatically terminate a misbehaving agent’s access, and among organisations running AI in production, 23% have never tested their termination process end to end. Gravitee’s 2026 survey of 900+ practitioners found more than half of deployed agents running with no security oversight or logging at all, and 88% of organisations reporting confirmed or suspected agent security incidents in the year.
A human in the loop who cannot actually override, disregard, or halt the system is not a control. It is an accountability sink — a place to put blame with no capacity to prevent harm. EU AI Act Article 14 is explicit on this point: human oversight for high-risk systems means the demonstrated capability to intervene, interrupt, and disregard output. Designing oversight that meets that bar — thresholds, kill switches that have been tested, escalation paths with named owners — is durable, senior, and currently very scarce work.
3. Evidence — proving the workflow behaved
An automated workflow that cannot be reconstructed after the fact is a liability with good throughput. Four questions have to be answerable from your logs: Who authorised this? What context did the system have? What did it decide? Was that consistent with policy?
This is not aspirational. EU AI Act Article 26 obliges deployers of high-risk systems to ensure staff competence, monitor operation, notify incidents, retain logs for at least six months, and inform affected workers. ISO 42001 Clause 9.2 wants internal audit evidence, not intentions. When I led VDR through ISO 42001 Stage 2 certification, the difference between passing on the first attempt and a nonconformity was almost never whether a control existed. It was whether we could produce the artifact that proved it operated.
Evidence production is where AI-executable workflows create more human work, not less — and it’s higher-status work than what it replaced.
4. Boundary judgment — the jagged frontier
The Dell’Acqua field experiment with management consultants remains the cleanest finding in this literature: AI improved performance inside its capability frontier and degraded performance outside it, because people accepted plausible-but-wrong output. Anthropic’s own data shows the largest productivity gains on complex work — where reliability is simultaneously lowest.
That combination defines the residual professional job: knowing where the frontier runs for your domain, and catching the confident failure. It cannot be delegated to the system whose blind spot you are compensating for. It also can’t be learned from a framework — it comes from having done the task manually enough times to feel when an answer is wrong before you can articulate why. Which is exactly what the compression of entry-level work threatens, and why serious firms should be deliberately preserving some manual reps for junior staff even where automation is available.
5. Accountability — the thing that structurally cannot convert
ISO 42001 Clause 5.3 requires assigned roles and responsibilities for the AI management system. NIST AI RMF GOVERN 1.1 and GV-3 require accountability structures and defined roles. EU AI Act Article 4 has required AI literacy across staff since February 2025. Every one of these instruments makes the same structural assumption: a named human being carries the consequence.
You can automate the analysis, the drafting, the monitoring, the reconciliation, and the reporting. You cannot automate the signature. Someone has to be answerable to a regulator, a board, an auditor, a customer whose data was in scope. SAP and Oxford Economics surveyed 2,600 leaders across 13 countries and found 69% either unsure or believing they deploy agents faster than they can govern them. That is not a tooling gap. It’s an unfilled seat.
The self-application test
It would be dishonest to run this analysis on everyone else’s job and not my own. So: consulting is roughly 60% convertible, and I’ve converted most of it.
Drafting gap-assessment language against Annex A controls, mapping ISO 27001 controls to NIST CSF 2.0 subcategories, generating first-pass policy text, building assessment logic, summarising a 200-page vendor security package — all of that runs as workflow now, and my throughput is several times what it was. What did not convert: deciding whether a control is effective rather than present; sitting across from a certification body and defending a scoping decision; telling a client the AI feature they’ve already announced needs an impact assessment before launch; carrying the professional judgment that an audit opinion rests on.
The convertible 60% got faster. The remaining 40% got more valuable, because there is now far more AI in production needing someone to sign for it. That asymmetry is the whole thesis. It holds for me because I owned the accountable end of the workflow before the conversion started. For people who owned only the execution end, the same conversion runs the other direction.
What to do about it this quarter
Run the conversion audit on your own role. Four columns: specifiability, feasibility, reversibility, attributability. Be ruthless about which of your tasks are just well-paid formatting.
Convert your own high-reversibility tasks before someone converts them for you. Owning the automation of your work is a fundamentally different position from being its subject.
Move up the accountability axis deliberately. Get named on something. Own an inventory, an oversight threshold, an internal audit, a supplier assessment under ISO 42001 A.10.3.
Learn to produce evidence, not just outcomes. Logs, artifacts, defensible decision records. This is the skill that converts a technologist into a governance practitioner.
Protect the apprenticeship. If you manage people, do not let AI eat every rep that builds boundary judgment. You are buying throughput today with capability you’ll need in three years.
The uncomfortable summary: a large and growing share of any knowledge job converts into an AI-executable workflow. What remains valuable is not the leftover tasks — it’s the specification, the oversight, the evidence, the boundary judgment, and the signature. Those five things are exactly what AI governance is made of, which is why the governance seat keeps getting more valuable while the execution seat gets cheaper.
AI-executable workflow, AI automation tasks vs jobs, human oversight AI, ISO 42001, NIST AI RMF, EU AI Act Article 14, AI governance career
Work with DISC InfoSec
DISC InfoSec helps B2B SaaS and financial services organisations convert AI adoption into something defensible — AI system inventories, ISO/IEC 42001 AIMS implementation, NIST AI RMF profiles, EU AI Act readiness, human oversight design, and the evidence packages that survive an external audit. I led ShareVault through ISO 42001 Stage 2 certification on the first attempt as an internal practitioner, not a spectator.
If you’re standing up AI-executable workflows and you don’t yet have a clear answer to who is accountable when this acts on its own, that’s the conversation to have now rather than after the incident.
Disc — Principal Consultant, DISC InfoSec CISSP, CISM | ISO 42001 & ISO 27001 Lead Implementer | PECB Authorized Training Partner
📅 Book an appointment: 📧 info@deurainfosec.com 📞 (707) 998-5164 🌐 deurainfosec.com
Sources referenced
Anthropic Economic Index reports (Jan 2026, Mar 2026) and Labor market impacts of AI: A new measure and early evidence
Deloitte, State of Generative AI in the Enterprise 2026 (3,235 leaders, 24 countries)
Grant Thornton, 2026 AI Impact Survey
Kiteworks, 2026 Data Security and Compliance Risk Annual Survey (459 organisations)
Gravitee, State of AI Agent Security 2026 (900+ respondents)
SAP / Oxford Economics, Value of AI Report 2026 (2,600 leaders, 13 countries)
Dell’Acqua et al. (2023), field experiment on AI and consultant performance
ISO/IEC 42001:2023; NIST AI RMF 1.0 (NIST AI 100-1); Regulation (EU) 2024/1689 (EU AI Act), Arts. 4, 14, 26
A practical seven-step path from a 15-minute readiness call to ISO 42001 and ISO 27001 certification — with the prep work that makes each step fast instead of painful.
Most organizations don’t stall on ISO 42001 or ISO 27001 because the standards are hard. They stall because step one is unclear, and the gap between “we should probably do this” and “we’re booking a Stage 1 audit” has no visible rungs. Here are the rungs — and the prep that makes each one fast.
Each step below is designed to be finished, not admired. Each one produces an artifact you keep and reuse at the next step — the AI system register you build for a gap assessment is the same register your certification auditor samples from. Nothing is throwaway.
You can enter at any rung. Most organizations that already have SOC 2 or a mature security program enter at step 3 or 4. Organizations meeting AI governance for the first time should start at step 1.
01 — Book a 15–20 minute readiness discussion
Time: 20 minutes · Cost: free · Output: a scope boundary and a sequencing decision
The purpose of this call is not a sales pitch — it’s to answer two questions that determine everything downstream: what’s actually in scope, and which standard goes first.
How to make it efficient. Come with three answers ready. That’s the whole prep.
What triggered this? A customer security questionnaire, an RFP requirement, funding diligence, EU AI Act exposure, or a board ask. The trigger sets the deadline and the evidence bar.
Do you build AI, buy AI, or both? Under ISO 42001 this is the provider/user distinction, and it decides which Annex A controls actually bite. “Both” is the common answer and it’s fine — just say so.
What’s your real deadline? Certification bodies book out. A date changes the plan more than a budget does.
Time: 5 minutes · Cost: free · Output: a directional read on your exposure
A fast self-check across your core security and governance posture. It won’t produce audit evidence, and it isn’t meant to — it tells you whether you’re 20% ready or 70% ready before you spend money finding out.
How to make it efficient.
Answer as things are, not as they’re written. A policy nobody follows is a “no.” Auditors test operation, not intent, so score yourself the way Stage 2 will.
Have two people take it independently — ideally someone in engineering and someone in leadership. The delta between their scores is usually a more useful finding than either score. Disagreement about what’s in place is the governance gap.
Time: ~1 hour of your input · Cost: $49 · Output: clause-by-clause and control-by-control gap table
This assesses you against the mandatory clauses (4–10) and the Annex A controls of ISO/IEC 42001:2023, and returns a status per item with the evidence each one requires and a prioritized remediation order.
How to make it efficient.
Build the AI system register first. One spreadsheet row per AI system, with its intended purpose, owner, and whether you built it or bought it. This single artifact accelerates every step after it.
Include the AI you forgot you have. Embedded AI features in SaaS tools, coding assistants, AI in your support desk, an LLM API call buried in one microservice. Incomplete registers are the most common finding I write.
Don’t pre-clean. Send the messy version. A gap assessment priced at $49 is worthless if it’s assessing a sanitized picture.
Expect the usual suspects to surface: no AI system impact assessment (AISIA), undocumented human oversight, thin data governance, no supplier AI due diligence, and AI objectives written as principles rather than measurable targets.
Time: ~1–2 hours of your input · Cost: $59 · Output: gap table across clauses 4–10 and the 93 Annex A controls
Same structure, applied to ISO/IEC 27001:2022 — the 93 controls across the four themes, plus the mandatory documented information the standard requires. If a customer is asking for “a security certification,” this is usually the one they mean.
How to make it efficient.
Bring your asset and supplier inventories, whatever state they’re in, plus the policy set you already have. Most organizations have more written than they think and less operating than they hope.
Reuse your SOC 2 evidence if you have it. The overlap is substantial, and mapping existing evidence is far cheaper than generating new evidence.
Work in 2022 only. The 2013 transition window closed in October 2025 — there’s no reason to assess against the retired version.
Doing both assessments together is the efficient move if AI governance and security certification are both on your roadmap: the two standards share the same clause structure, so the overlapping gaps get remediated once rather than twice.
Why the ladder compounds. ISO 42001 and ISO 27001 both follow the ISO High Level Structure. That means one scope statement, one risk methodology, one internal audit programme, one management review, and one corrective action log can satisfy both standards. Organizations that run them sequentially pay for the management system twice. Run them as a single integrated system and the second certification costs a fraction of the first.
05 — Run the 7–10 day AIMS/ISMS Quick-Start
Time: 7–10 calendar days · Output: the mandatory document set, drafted and ready to sign
The Quick-Start converts your gap assessment into the documents the standard actually requires: scope, top-management-signed policy, risk assessment and treatment plan, AI system impact assessment, Statement of Applicability, measurable objectives, an internal audit programme, and a management review agenda.
How to make it efficient.
Name one owner with signing authority before day one. The single biggest cause of a 10-day engagement becoming a 10-week one is documents waiting on an approver who was never identified.
Batch the input. Two or three 90-minute working sessions beat three weeks of asynchronous questions.
Don’t write policy for controls you don’t operate. Every unearned claim in a policy becomes a nonconformity at Stage 2. Where a control isn’t running yet, the honest answer is a dated plan, and auditors accept that.
Time: typically 8–16 weeks · Output: a management system with operating history
Documents don’t certify — evidence does. Implementation is where the risk assessments get executed, impact assessments get completed per AI system, training gets delivered and logged, supplier assessments get run, and incidents get recorded through the process you wrote.
How to make it efficient.
Instrument the evidence at the source. If access reviews, training completions, and change approvals generate records automatically in tools you already use, evidence collection stops being a project.
Accumulate operating history deliberately. Stage 2 samples records over a period. Two to three months of a control genuinely running beats a perfect binder assembled the week before.
Log the boring events. An incident log with zero incidents proves nothing. A log showing minor events triaged and closed proves the process works — which is exactly what the auditor is testing.
Time: Stage 1 and Stage 2, typically 4–8 weeks apart · Output: an accredited certificate
An accredited certification body audits in two stages: Stage 1 reviews your documented management system, Stage 2 verifies it operates. Then annual surveillance audits, with recertification every three years.
How to make it efficient.
Book the certification body early. Scheduling — not readiness — is the most common reason certification dates slip. Get on the calendar while you’re still implementing.
Complete your internal audit and management review before Stage 1, not between the stages. Both are mandatory, both take real calendar time, and squeezing them into the gap is where teams lose their date.
Rehearse the interviews. Stage 2 auditors talk to control owners, not just the compliance lead. Thirty minutes of prep with each owner — what they do, where the record lives — converts a stressful audit into a routine one.
This is the path I ran with ShareVault, a virtual data room platform serving M&A and financial services clients, through ISO 42001 Stage 2 certification on the first attempt — as implementer and internal auditor. Financial data rooms are the hard mode of compliance, and the ladder held.
DISC InfoSec — Deura Information Security Consulting LLC · Petaluma, CA info@deurainfosec.com · (707) 998-5164 · calendly.com/hd-deurainfosec
A practical seven-step path from a 15-minute readiness call to ISO 42001 and ISO 27001 certification — with the prep work that makes each step fast instead of painful.
Everyone Is Learning to Build With AI. Almost Nobody Is Learning to Govern It.
I keep meeting people who are burning nights and weekends teaching themselves to build with AI. Agents, RAG pipelines, orchestration frameworks, the whole stack. I understand the instinct completely. The tooling is genuinely exciting, the demand looks self-evident, and nobody wants to be the person the wave passes by.
But it’s worth asking a harder question before you spend another six months on it: who actually gets displaced first?
If your value proposition is that you can prompt a model into producing something useful, you are competing against every other person who can prompt a model into producing something useful — and against the model itself, which gets better at doing that unsupervised every quarter.
That isn’t a prediction. It already happened once. “Prompt Engineer” peaked as a standalone job title and then quietly disappeared from job boards. The skill didn’t vanish; it got absorbed. LinkedIn postings tagging prompt engineering as a skill grew sharply while postings with it in the title declined. The people who survived that transition weren’t the prompt whisperers. They were the engineers, product managers, and risk owners who happened to also prompt well.
Something similar is working its way through the entry-level engineering market right now. Employment for developers aged 22 to 25 has fallen roughly 20% since generative AI tools went mainstream. Entry-level hiring at the largest tech firms dropped about 25% between 2023 and 2024. The mechanism isn’t mysterious: AI is very good at exactly the codified, well-bounded work that used to be the first rung of the ladder.
Meanwhile, there’s a job almost nobody is lining up for.
The questions nobody in the building can answer
Somebody has to sit in a room and answer, in writing, with their name on it:
Can this AI system be trusted with customer data, and what evidence supports that answer?
Can this output be defended in an audit twelve months from now?
Is the vendor’s model quietly training on our information, and does the contract actually prohibit it?
Does the feature the dev team shipped last month violate three controls nobody checked?
If a regulator asks how we govern AI, what document do we hand them?
Right now, in most organizations, the honest answer to all five is nobody knows.
This gap is measurable, not theoretical
The 2026 Enterprise AI Trends Study from Smarsh, conducted by FTI Consulting, found that 55% of enterprises are actively deploying AI while only 26% say their governance frameworks are keeping pace with that deployment. Just 30% report comprehensive capability to detect and manage shadow AI — the unsanctioned tools employees are already using.
Other 2026 data points in the same direction. ISACA found that a quarter of organizations have no active AI policy at all. Roughly 80% report moderate to pervasive shadow AI use, while only about 25% have real visibility into how employees are using it. The Verizon DBIR flagged shadow AI as one of the most common non-malicious insider actions in DLP data, with source code the most frequently submitted data type to unauthorized external models.
Read that last one again. The most common thing leaving organizations through an ungoverned channel is their own intellectual property.
This shows up in assessments constantly. Not as a philosophical concern about AI risk — as a specific finding, on a specific system, with a specific owner who cannot produce the evidence.
What the market is paying for the seat
The labor data is unusually clean for an emerging field.
LinkedIn’s 2026 Skills on the Rise report put year-over-year demand growth for AI governance skills at 150%, with AI ethics at 125% — among the fastest-growing categories it tracks. The IAPP reports that 98.5% of organizations say they need more AI governance professionals than they currently have. By late 2025, LinkedIn was already showing over 14,000 open roles carrying some form of AI governance title.
Axial Search’s analysis of roughly 2,000 US postings found the market averaging about 71 new AI governance roles per week through the first seven months of 2026, with no seasonal collapse — median pay around $169,000, with a heavy concentration in professional services (about 35% of postings) and financial services. Notably, 27% of postings reference NIST frameworks specifically. IAPP data also shows a measurable certification premium: roughly 13% for one relevant credential, around 27% for a stacked combination.
Steady weekly volume matters more than the headline growth number. It means the market has stabilized into a standing capability rather than a hype spike.
The regulatory clock makes this structural
Career bets built on hype decay. Career bets built on statutory deadlines do not.
The EU AI Act (Regulation (EU) 2024/1689) is phasing in on a fixed schedule. GPAI obligations under Articles 53–55 have applied since 2 August 2025, with the GPAI Code of Practice as the primary compliance path. Article 50 transparency requirements for new systems hit 2 August 2026. Following the AI Omnibus revisions agreed in May 2026, the full high-risk obligations for Annex III standalone systems — Article 9 risk management, Article 10 data governance, Article 11 technical documentation, Article 14 human oversight, Article 15 accuracy and cybersecurity — now apply from 2 December 2027, with Annex I embedded systems following on 2 August 2028.
That extension is not a reprieve. It is an eighteen-month runway during which every provider and deployer in scope has to build a conformity assessment capability from scratch, and penalties under Article 99 reach €35M or 7% of global turnover for prohibited practices, €15M or 3% for provider and deployer violations.
Underneath the regulation sits the standards layer that organizations will actually implement against: ISO/IEC 42001:2023, the first international AI management system standard, and the NIST AI Risk Management Framework (AI RMF 1.0). Neither is going anywhere. Both are already showing up in contracts, RFPs, and customer security questionnaires — which is usually the real forcing function, well ahead of the regulator.
If you already work in security, compliance, audit, or risk, you are closer than you think
Here’s what most people in the field don’t realize: the AI governance frameworks are deliberately built on structures you already know.
ISO 42001 follows the Annex SL High Level Structure — the same Clause 4 through 10 skeleton as ISO 27001. Context, leadership, planning, support, operation, performance evaluation, improvement. If you have run an ISMS, you have run 70% of an AIMS. What’s new is the AI-specific content bolted into that skeleton: the AI System Impact Assessment under Clause 6.1.2, documented intended purpose for every system in scope, human oversight controls for decisions affecting individuals, and data quality controls for training, validation, and test data.
The NIST AI RMF maps the same way. Four functions — GOVERN, MAP, MEASURE, MANAGE — with GOVERN underpinning the rest, exactly as it does in CSF 2.0. Here’s the translation:
What you already do
Where it lands in AI governance
Risk register, risk appetite, board reporting
GOVERN (GV-1 to GV-6), ISO 42001 Clause 5 and 6
Asset inventory
AI system inventory — first-party models, LLM features, embedded third-party AI, AI in HR and customer decisions
Business impact analysis
MAP + the AI System Impact Assessment (severity, reversibility, affected population, human oversight)
Control testing and evidence collection
MEASURE — accuracy on data slices, fairness metrics, robustness, explainability
Vendor security assessment
Third-party model risk — training data provenance, retention terms, subprocessor chains
Incident response
MANAGE (MG-3) — AI incident triggers: accuracy degradation, bias threshold breach, jailbreak in the wild, drift
Internal audit
Stage 1 / Stage 2 readiness against ISO 42001
The security-specific slice is the part that genuinely requires new study, and it’s the part that makes you hard to replace: prompt injection and indirect injection through untrusted content, agent privilege boundaries, MCP and tool-invocation security, output handling, and the uncomfortable fact that an instruction file like CLAUDE.md is an advisory control, not an enforced one. Anyone who tells an executive that model-level instructions constitute a control has misunderstood the threat model.
You do not need to become an AI developer to do this work. You need to become the person who can tell an executive whether the AI they just bought is safe, legal, and defensible — and produce the artifact that proves it.
A realistic path in
If you’re coming from security, GRC, audit, privacy, or risk, this is roughly the sequence that works:
Build the inventory skill first. Most organizations underestimate their AI footprint by an order of magnitude. Shadow AI, embedded vendor features, AI in hiring and pricing. Inventory is unglamorous, it’s the mandatory first step in every framework, and almost nobody has done it.
Learn one framework properly, not four superficially. ISO 42001 if your world is certification and enterprise sales. NIST AI RMF if your world is US enterprise risk. They map to each other; pick your entry point.
Add the EU AI Act classification workflow. Provider vs. deployer, prohibited practices screen, risk tier, obligations. This is a repeatable analysis, and executives will pay for a defensible answer.
Get the AI security slice. Prompt injection, agent boundaries, third-party model risk. This is where security backgrounds create separation from the legal-and-policy entrants.
Produce one real artifact. An AI system inventory, an AISIA, a gap assessment with evidence requirements. One completed artifact beats three certifications with nothing behind them.
Certifications help — AIGP, ISO 42001 Lead Implementer or Lead Auditor, stacked on a CISSP or CIPP — but they’re an accelerant, not the substance.
The asymmetry
Both paths involve real work. The difference is what happens to that work over time.
The ability to prompt a model into producing an output is on a curve toward commodity. Every model release erodes the moat, and the tooling is explicitly designed to remove the human from the loop.
The ability to determine whether an AI system is safe, legal, and defensible moves the other way. Every new deployment expands the surface. Every new regulation adds an obligation. Every audit cycle adds an evidence requirement. And critically, the accountability cannot be delegated to the model — a regulator asking “who signed off on this” will not accept “the AI did.”
One of those roles is a commodity in eighteen months. The other one gets more valuable every quarter.
FAQ
Do I need to be able to code to work in AI governance? No, but you need to be technically literate enough to ask a dev team the right questions and recognize a bad answer. The people who struggle in this role are the ones who can only speak policy. The ones who thrive can read an architecture diagram, understand where the model sits in the data flow, and tell you what a prompt injection actually does.
Is ISO 42001 or NIST AI RMF the better starting point? ISO 42001 if you need a certifiable management system — it’s what enterprise customers and procurement teams increasingly ask for. NIST AI RMF if you need a risk framework for internal use without a certification driver. They’re structurally compatible; most mature programs end up running both.
Should a mid-sized company hire a full-time AI governance person? Usually not as the first move. Document the framework, assign an existing owner — typically the person already running security or compliance — and bring in fractional expertise for the assessment and design work. Add headcount when the workload genuinely exceeds what that owner can carry.
How long does this transition take from a security or compliance background? Six to twelve months to be credible, if you’re producing real artifacts along the way. Considerably longer if you’re only collecting credentials.
DISC InfoSec is a boutique AI governance and cybersecurity consultancy in Petaluma, California, serving B2B SaaS and financial services organizations across the North Bay and beyond. We led VDR through ISO 42001 Stage 2 certification on the first audit attempt. If you need to know whether the AI you’ve deployed is safe, legal, and defensible — that’s the assessment we run.
, ever-increasing regulations, and the potential effect of brand damage on profits has made 
a mainstream board-level issue. It has never been more important for 
and processes to be in line with business
feel they are being heard, business leaders admit they aren’t listening.
with business priorities will be much easier.
are the common factor understood by both sides and could be used as the primary driver in this alignment. The reality, however, is this isn’t always happening
s to better understand the use of metrics to communicate with business leaders: why metrics are necessary; how they can be improved; what are the problems; and what is the prize?
/
, 
s, Proxies, or any other solution you have actually do. They only care about the level of risk in the company.”
impact specific 
.
that business leaders understand. This can be used to start the process for each side to learn more about the other. Business will begin to see how security reduces risk, and will begin to specify other areas that need more specific protection.
and information stored, processed, or transmitted by the organization. These departments and these leaders tend to provide metrics that focus on their tactical duties rather than business drivers that concern the board/C-suite.”
. Logins, blocked traffic, transaction counts, etc… but most do not map back to business objectives or are explained in a format business leaders can understand or care about. Good metrics need to be tied to dollars, business efficiency shown through time improvements, and able to show trending patterns of security effectiveness as it relates to the business. That’s the real challenge.”
and president-elect of ISSA. “That is a mistake, because security is our job. We need to better understand the business, so that we can articulate the impact of not applying 
. The key to this whole approach is for the CISO to understand the business, and to understand the mission and goals of the business.”
and 
systems. They must manage teams and get leadership approval in order to successfully implement a system that aligns with overall business goals.
will need to appoint both technical and non-technical individuals to support a risk management system, which requires communication in a language that everyone can relate to. Additionally, senior executives’ approval is required and this will involve presenting proposals in non-technical terms.
