Aug 24 2026

How Much of Your Job Can Become an AI-Executable Workflow — and What’s Left Standing When It Does

Category: AI,Information Security — disc7 @ 9:34 am

How Much of a Job Can AI Automate? What Remains valuable is 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:

AxisQuestionWhy it matters
SpecifiabilityCan 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.
FeasibilityCould a competent model do this alone, given the right context and tools?This is the raw conversion ceiling.
ReversibilityIf 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.
AttributabilityWhen 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

  1. 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.
  2. 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.
  3. 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.
  4. Learn to produce evidence, not just outcomes. Logs, artifacts, defensible decision records. This is the skill that converts a technologist into a governance practitioner.
  5. 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

Download the AI Governance & Cybersecurity pdf file

AI Attack Surface ScoreCard 

MachineLearning & Artificial Intelligence

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Schedule a consultation: info@deurainfosec.com

InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory | ISO 27k Chat bot | Comprehensive vCISO Services | ISMS Services | AIMS Services | Security Risk Assessment Services | Mergers and Acquisition Securit

DISC InfoSec blog | DISC InfoSec Site 

Tags: AI-Executable Workflow

Aug 20 2026

The AIMS/ISMS readiness ladder: seven steps from curious to certified

Category: Information Security,ISO 27k,ISO 42001 — disc7 @ 10:38 am

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.

Schedule the readiness discussion →

02 — Run the free 5-minute risk assessment quiz

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.

Take the 5-minute quiz →

03 — Order the $49 ISO 42001 AIMS gap assessment

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.

Get the $49 ISO 42001 gap assessment →

04 — Order the $59 ISO 27001 ISMS gap assessment

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.

Get the $59 ISO 27001 gap assessment →

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.

Start the 7–10 day Quick-Start →

06 — Implement the AIMS/ISMS

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.

Discuss implementation support →

07 — Certify

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.

Talk about certification →

Pick your rung

If you don’t know where you sit, start at the top of this list — the call is 20 minutes and it will tell you which step is actually yours.

  1. Schedule a 15–20 minute AIMS/ISMS readiness discussion — free, 20 min
  2. Free 5-minute risk assessment quiz — free, 5 min
  3. Paid AIMS ISO 42001 gap assessment — $49
  4. Paid ISMS ISO 27001 gap assessment — $59
  5. 7–10 day AIMS/ISMS Quick-Start — fixed scope
  6. ISO 42001/27001 AIMS/ISMS implementation — 8–16 weeks
  7. ISO 42001/27001 AIMS/ISMS certification — Stage 1 + Stage 2

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.

Download the AI Governance & Cybersecurity pdf file

AI Attack Surface ScoreCard 

MachineLearning & Artificial Intelligence

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Schedule a consultation: info@deurainfosec.com

InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory | ISO 27k Chat bot | Comprehensive vCISO Services | ISMS Services | AIMS Services | Security Risk Assessment Services | Mergers and Acquisition Securit

DISC InfoSec blog | DISC InfoSec Site 

Tags: AIMS, isms, iso 27001, ISO 42001

Aug 17 2026

AI Governance Careers: The Skills Gap Nobody Is Filling (2026)

Category: AI,AI Governance,AI Guardrails,AI Risk,Cyber career — disc7 @ 11:51 am

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 doWhere it lands in AI governance
Risk register, risk appetite, board reportingGOVERN (GV-1 to GV-6), ISO 42001 Clause 5 and 6
Asset inventoryAI system inventory — first-party models, LLM features, embedded third-party AI, AI in HR and customer decisions
Business impact analysisMAP + the AI System Impact Assessment (severity, reversibility, affected population, human oversight)
Control testing and evidence collectionMEASURE — accuracy on data slices, fairness metrics, robustness, explainability
Vendor security assessmentThird-party model risk — training data provenance, retention terms, subprocessor chains
Incident responseMANAGE (MG-3) — AI incident triggers: accuracy degradation, bias threshold breach, jailbreak in the wild, drift
Internal auditStage 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Book a conversation: info@deurainfosec.com · (707) 998-5164

Download the AI Governance & Cybersecurity pdf file

AI Attack Surface ScoreCard 

MachineLearning & Artificial Intelligence

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Schedule a consultation: info@deurainfosec.com

InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory | ISO 27k Chat bot | Comprehensive vCISO Services | ISMS Services | AIMS Services | Security Risk Assessment Services | Mergers and Acquisition Securit

DISC InfoSec blog | DISC InfoSec Site | Contact us at info@deurainfosec.com

Aug 15 2026

AI Governance & Cybersecurity That Holds Up Under Scrutiny

Category: AI Governance,AI Risk,cyber security,Risk Assessment — disc7 @ 3:08 pm

AI risk is moving faster than most organizations’ governance programs.

Expert AI Governance and Cybersecurity Consulting

Strengthening B2B SaaS and Financial Services with Robust Compliance Frameworks – DISC InfoSec turn AI governance and cybersecurity requirements into practical, defensible programs—not another stack of policies.

Deura Information Security Consulting LLC provides expert guidance for B2B SaaS and financial services companies seeking to establish practical and defensible security and AI governance programs. We specialize in transforming compliance from a theoretical exercise into an operational reality. Our approach ensures your organization not only meets but exceeds industry standards, building significant customer trust and reducing risk.

Comprehensive AI Governance Services

In an era defined by artificial intelligence, robust governance is not optional. We offer specialized ai governance services to help your business navigate the complexities of AI ethics, accountability, and regulatory requirements. Our consultants implement frameworks that align with your strategic objectives, ensuring responsible and secure AI deployment. We focus on creating sustainable programs that stand up to rigorous scrutiny from auditors and stakeholders.

Mastering NIST AI RMF Compliance

Achieving nist ai rmf compliance is critical for organizations looking to manage risks associated with artificial intelligence systems. Our team provides hands-on consulting to implement the NIST AI Risk Management Framework, helping you identify, assess, and mitigate AI-related risks effectively. We guide you through every step, from building the initial framework to preparing for audits, ensuring your AI systems are trustworthy and secure.

Our Core Consulting Expertise

Deura Information Security Consulting LLC delivers tangible results through a suite of specialized services designed for the modern digital landscape. We move beyond simple documentation, building functioning programs that produce the evidence required for successful certification.

  • ISO 27001 & ISO 42001 Consulting: We guide companies to successful certification with a practitioner-led approach, including first-audit ISO 42001 certification.
  • vCISO and vCAIO Services: Access executive-level security and AI leadership from our CISSP and CISM certified consultants with over 20 years of experience.
  • SOC 2 Readiness: We prepare your organization for SOC 2 audits by building robust security controls and operational procedures.
  • Holistic Security Programs: Unlike firms that treat compliance as a checkbox, we integrate security and AI governance into the core of your operations.

Specialized AI Compliance Solutions

  • ISO 42001 Consulting: Achieve certification for the first international standard for AI Management Systems. Our ISO 42001 consulting service helps implement a framework for responsible AI development and deployment.
  • NIST AI RMF Compliance: Align your AI governance program with the National Institute of Standards and Technology’s framework. We facilitate NIST AI RMF compliance to manage the risks associated with AI technologies.
  • EU AI Act Compliance: Prepare for the future of AI regulation. Our consulting for EU AI Act compliance ensures your organization is ready to meet the requirements of this landmark legislation.

Why DISC InfoSec

Independent AI Governance & Security Expertise – 20+ years in regulated environments. We translate AI risk into clear board, legal, and regulatory language—without vendor bias. In two weeks, we show leadership where AI risk lives, who owns it, and what must be fixed before AI becomes a liability

Timeline 14 calendar days from kickoff to executive briefing:

Day 1–2: Kickoff + scoping | Day 3–10: Analysis & mapping | Day 11–13: Risk synthesis

Day 14: Executive debrief

Partner with Deura Information Security Consulting LLC for practitioner-level insight and implementation. Contact us at +17079985164 to begin building a more secure and compliant future.

Download the AI Governance & Cybersecurity pdf file

DISC-AI-Governance-Readiness-Assessment-1-1 pdf downloadDownload

AI Attack Surface ScoreCard 

MachineLearning & Artificial Intelligence

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Schedule a consultation: info@deurainfosec.com

InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory | ISO 27k Chat bot | Comprehensive vCISO Services | ISMS Services | AIMS Services | Security Risk Assessment Services | Mergers and Acquisition Securit

DISC InfoSec blog | DISC InfoSec Site | Contact us at info@deurainfosec.com

Tags: AI Governance & Cybersecurity

Aug 10 2026

“Sorry, Typo”: Why a Markdown File Is Not a Security Control

Category: AI Governance Enforcement,AI Guardrails,AI Risk,Information Security,Security controls — disc7 @ 10:33 am

“Sorry, Typo”: Why a Markdown File Is Not a Security Control

PCWorld ran a piece last week on the one command you should never let an AI coding agent execute: rm -rf. The reporting is solid and the anecdotes are grim — developers who let an agent handle a routine cleanup task and lost a home directory, a project tree, or an entire drive. In one widely shared case, the agent was asked to create a backup, wrote it to the wrong location, recursively force-deleted the drive, and then apologized for the typo.

The recommended fix was to add a rule to CLAUDE.md or AGENTS.md instructing the agent never to run recursive forced deletions, including reordered flags, aliases, shell wrappers, and equivalents like find -delete or git clean -fdx.

That advice is directionally correct and worth doing. But it is not a control, and the distinction is the entire point of this post.

A CLAUDE.md instruction is a prompt. It is processed by the same probabilistic layer that generated the destructive command in the first place. You are asking the thing that made the mistake to please remember not to make the mistake. In control language, that is an awareness measure — the equivalent of a wall poster reminding staff not to click phishing links. Useful. Not the thing you point an auditor at.

Real controls sit below the model, in a layer the model cannot argue with.

Threat modeling the coding agent

Before reaching for controls, model the thing. An AI coding agent is a process with a shell, network egress, credentials, and a non-deterministic decision function. Run STRIDE against it as you would any other element in a data flow diagram:

STRIDEThreat against the agentLikelihoodImpact
S — SpoofingA malicious or typosquatted MCP server registers tools the agent trusts; a poisoned dependency masquerades as a legitimate packageMH
T — TamperingAgent modifies its own configuration, hooks, CI definitions, or .env files; commits changes no human reviewedMH
R — RepudiationNo durable log of which tool calls ran with which arguments; post-incident, nobody can reconstruct what the agent didHH
I — Information disclosureAgent reads ~/.ssh, ~/.aws, credential stores, or an entire knowledge base and emits contents into a prompt, a commit, or an outbound requestHC
D — Denial of serviceUnbounded agent loop; destructive deletion of source, database dumps, or infrastructure stateMC
E — Elevation of privilegeAgent runs under a broad service account and performs actions the invoking human is not authorized to performHC

Read that table again and notice what rm -rf actually is. It is one instance of D, in one row, on one machine. It is the failure mode that gets written up because it is loud and immediately visible. The rows that will actually end up in a breach notification are I and E, and they are silent.

This is OWASP’s Excessive Agency category (LLM06 in the 2025 Top 10 for LLM Applications). The vulnerability is not that the model is wrong sometimes — the model will always be wrong sometimes. The vulnerability is that a wrong decision has been wired to an unbounded capability.

The enforcement stack

Five layers, in order of how much they actually protect you. Each one holds when the layer above it fails.

1. Identity and scope — what the agent is

The agent is a non-human identity. Treat it like one. It gets its own service account, not a developer’s personal credentials. Its permissions are the union of what it needs for the task at hand, not the union of what its human operator happens to be entitled to.

This single decision determines blast radius. Everything downstream is mitigation.

2. Deny rules — declarative policy

Claude Code evaluates permission rules in deny → ask → allow order, and a deny at any settings level cannot be re-allowed by another level or by bypass mode. Managed (organization-level) denies are absolute. Write the deny list first, then decide how permissive to be about everything else:

{
  "permissions": {
    "deny": [
      "Bash(rm:*)",
      "Bash(git clean:*)",
      "Bash(git reset --hard:*)",
      "Bash(find:*)",
      "Bash(curl:*)",
      "Bash(sudo:*)",
      "Read(./.env)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(./secrets/**)"
    ],
    "ask": [
      "Bash(git push:*)",
      "Bash(npm install:*)",
      "Write(**)"
    ]
  }
}

Two engineering notes that matter more than the syntax:

Deny the binary, not the flag combination. Pattern matching is prefix-based. A rule targeting the literal string rm -rf misses rm -fr, rm -r -f, rm --recursive --force, an alias, and anything wrapped in a shell script. Deny rm itself and grant exceptions deliberately.

Test that your rules fire. There are open reports of Bash permission patterns not being enforced as documented (see anthropics/claude-code issue #18846). An untested control is a documented control, which is worse than no control because it produces false assurance. Write a five-line test that attempts each denied command and confirms it is blocked. Re-run it after every CLI upgrade.

3. Policy-as-code hooks — the part that actually generalizes

A PreToolUse hook intercepts every tool call before execution and returns allow, ask, or deny. Two properties make this the load-bearing layer:

  • It can parse the command rather than string-match it, so it catches the evasions a glob pattern cannot.
  • It fires even under --dangerously-skip-permissions.

That second property is the one to underline. In practice, “approval fatigue” is what kills agent security programs — a developer running several parallel sessions turns every confirmation prompt into a reflexive keystroke within about a day. The answer is not to demand more discipline from tired humans. It is to move the decision into code that does not get tired.

Hooks are also where the auditability comes from: a hook that logs every intercepted command with arguments, timestamp, session ID, and decision is your non-repudiation control for the R row above.

4. OS-level sandboxing — containing what does run

Permissions decide whether a call executes. Sandboxing decides what it can reach once it does. Claude Code’s sandbox uses Seatbelt on macOS and bubblewrap on Linux/WSL2 (native Windows and WSL1 are unsupported). Devcontainers, ephemeral VMs, and per-project containers do the same job at a coarser grain.

The rule of thumb: an agent operating with reduced human oversight should be operating inside a boundary that makes the reduced oversight defensible. Autonomy and isolation are traded against each other, and the trade has to be explicit.

5. Recoverability — the control that assumes the others failed

Version control on a remote the agent has no credentials to force-push to. Database backups on a system the agent cannot reach. And a restore you have actually performed at least once, because an untested backup is a hypothesis.

Governance mapping

For clients who need this to land in a management system rather than a wiki page:

ControlISO/IEC 42001NIST AI RMFNIST CSF 2.0
Agent inventory, ownership, approved-use policyClause 6, Annex A (AI policy, roles, impact assessment)GOVERN, MAPGV.OC, ID.AM
Scoped non-human identity, least privilegeAnnex A (resources, lifecycle controls)MANAGEPR.AA
Deny rules, hooks, sandboxingAnnex A (operational controls)MANAGEPR.PS, PR.IR
Tool-call logging and anomaly reviewAnnex A (monitoring, event logging)MEASURE, MANAGEDE.CM, DE.AE
Human approval for irreversible actionsAnnex A (human oversight)MANAGEGV.RM
Agent incident handling and post-mortemAnnex A (incident management)MANAGERS.MA, RC.RP

If you are already certified to ISO 27001, most of this is control extension rather than new work. The gap is almost always the same two things: the agent is not in the asset inventory, and no one has written down what it is permitted to do.

My perspective: the deletion story is the distraction

A lost home directory is recoverable, embarrassing, and over in a day. I want to close on the two failure modes that are neither loud nor recoverable, because they are where I expect the next several years of AI governance findings to concentrate.

Monitor for harmful instructions, because the agent cannot tell instructions from data

Every AI agent shares one architectural property: it has no reliable mechanism for distinguishing content it should reason about from commands it should obey. Everything arrives as tokens. The system prompt, the developer’s request, a README, a Jira comment, a dependency’s post-install script, a scraped web page, a row in a database, a response from an MCP tool — all of it lands in the same context window with the same claim to authority.

That means every data channel into the agent is also an instruction channel. The PCWorld story involved a wrong command the agent generated on its own. The same execution path is reachable by a command an attacker put there — planted in a code comment, an issue description, a vendor’s documentation page, a poisoned retrieval chunk. This is indirect prompt injection, and it is the vector I would use against a client whose agents are wired to real systems.

The cross-privilege version is worse and gets overlooked. A low-privilege user leaves a comment on a shared ticket. A senior engineer’s agent reads that ticket as context and follows the embedded instruction with the senior engineer’s entitlements. Nobody exploited a CVE. The AI layer was simply used as a confused deputy, and the privilege boundary your IAM team spent two years building was crossed sideways.

So: log prompts, completions, retrieved chunks, and every tool call with arguments. Feed them somewhere queryable and set detections on the sequences that indicate manipulation rather than on individual events — an unusual tool paired with an unusual argument, a retrieval followed immediately by an egress attempt, a sudden shift in the ratio of reads to writes, credential-shaped strings appearing in output. This is not novel detection engineering; it is the same behavioral analytics we already apply to service accounts, pointed at a new identity class. The organizations that will struggle are the ones treating agent activity as application telemetry rather than as security-relevant audit evidence.

Do not give an agent your whole knowledge base or database

This is where I push hardest with clients, and where I get the most resistance, because broad access is what makes the demo impressive.

Grant an agent read access to the entire knowledge base and you have collapsed, in a single configuration line, every compartment your organization built deliberately over years. HR files, board material, unreleased financials, customer contracts, security findings, the incident log. The access control model no longer reflects need-to-know; it reflects what was convenient to index.

Three reasons that is not a defensible position:

Read is exfiltration. “Read-only, so it’s low risk” is the most common error in this space. The entire value of a knowledge base is aggregation — a single well-crafted retrieval can surface more in one query than a determined insider could assemble in a month of browsing. Confidentiality impact does not require write access.

Broad service accounts break tenant and role isolation. If the agent queries under its own privileged identity rather than the requesting user’s, then every user effectively inherits the agent’s permissions. Row-level security, tenant filters, and role-based restrictions all sit underneath the layer the agent bypassed. Retrieval must be scoped to the invoking user’s actual entitlements, and vector stores must filter by tenant before results reach the context window — not after.

Aggregation changes the classification. Individually innocuous records combine into something that is not. A regulated institution can hold twenty datasets each rated internal-use and produce, through unrestricted joined retrieval, an output that is material non-public information or a reportable privacy event. Your data classification scheme almost certainly does not model this, because it was written for humans who could not join twenty datasets in 400 milliseconds.

The practical posture: per-purpose retrieval scopes rather than one omniscient index. Identity propagation so the agent’s reach is bounded by the human it acts for. Egress allowlists so a successful injection has nowhere to send anything. Human approval on irreversible and cross-boundary actions. Time-boxed and revocable credentials. Treat every tool response and retrieved document as untrusted input, because that is exactly what it is.

None of this is anti-AI. I use these tools daily and they have materially changed how much a small consultancy can deliver. But the governance question is not whether to adopt agents — that is settled. It is whether your agents are entitled to less than they can currently reach.

In financial data rooms, where a single unauthorized disclosure can move a transaction, that question has a very short answer. Everyone else is on the same trajectory; they just have not been tested yet.

DISC InfoSec helps B2B SaaS and financial services organizations build AI governance programs that survive an audit — ISO 42001 and ISO 27001 implementation, AI risk assessments, and vCISO advisory. If your organization has deployed AI agents faster than it has governed them, let’s talk.

DISC-AI-Governance-Readiness-Assessment-1-1 pdf downloadDownload

AI Attack Surface ScoreCard 

MachineLearning & Artificial Intelligence

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Schedule a consultation: info@deurainfosec.com

InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory | ISO 27k Chat bot | Comprehensive vCISO Services | ISMS Services | AIMS Services | Security Risk Assessment Services | Mergers and Acquisition Securit

DISC InfoSec blog | DISC InfoSec Site 

Contact DISC InfoSec: info@deurainfosec.com

Aug 05 2026

Security against defeat implies defensive tactics; ability to defeat the enemy means taking the offensive

Category: AI,Information Security,Security vulnerabilities — disc7 @ 8:35 am

“security against defeat implies defensive tactics; ability to defeat the enemy means taking the offensive” Sun Tzu

This quote is essentially saying:

If your goal is simply to avoid losing, you play defense. If your goal is to actually defeat the opponent, you must eventually take the initiative.

In simpler terms:

  • “Security against defeat implies defensive tactics”
    If you’re focused on preventing an attack or minimizing damage, you’re primarily reacting to what the adversary does. You protect assets, patch vulnerabilities, monitor systems, and respond to incidents.
  • “Ability to defeat the enemy means taking the offensive”
    If you want to consistently outmaneuver the adversary, you need to be proactive. You look for weaknesses before the attacker does, hunt for threats, test your defenses, and anticipate attacks.

In cybersecurity

This maps very well to the difference between defensive security and proactive security:

Defensive mindsetOffensive/proactive mindset
Patch vulnerabilitiesActively hunt for vulnerabilities
Monitor alertsThreat hunt
Respond to attacksSimulate attacks
Wait for indicatorsSearch for attacker behavior
Protect the perimeterAssume the perimeter will be breached
Reduce damageFind and eliminate attack paths

For example, a company that only waits for a vulnerability scanner to tell it what is wrong is primarily defending against defeat.

A company that continuously performs threat hunting, penetration testing, attack-surface discovery, red teaming, and adversary simulation is taking the offensive.

The deeper lesson: You cannot win a security war by merely absorbing attacks. Defense keeps you from losing; proactive action creates the conditions for winning.

That concept fits especially well with modern AI-accelerated vulnerability discovery: if attackers can discover weaknesses faster than your traditional security program can react, the defender has to become more proactive.

In the era of AI everywhere

Defensive security is no longer enough

Traditional defensive security assumes you can build a strong perimeter, deploy controls, monitor events, detect anomalies, and respond when something happens.

That model still matters—but AI is changing the economics of the attack.

Attackers can use AI to:

  • Discover vulnerabilities faster
  • Generate convincing phishing and social-engineering content
  • Automate reconnaissance
  • Adapt attacks dynamically
  • Analyze large amounts of stolen data
  • Scale attacks that previously required significant human effort

So the defender’s problem isn’t simply “Can we detect an attack?”

It’s increasingly:

“Can we discover and eliminate the attacker’s opportunities before they exploit them?”

Defensive vs. proactive security

Think of it as two layers:

Defensive security = Don’t let them win.

You protect, detect, respond, recover, and contain.

Proactive security = Don’t let them get the opportunity to attack successfully.

You continuously discover, test, validate, hunt, simulate, and remediate.

In an AI-driven environment, proactive security becomes much more important because the attacker can operate at machine speed.

The biggest shift: from alerts to attack paths

This is where I think cybersecurity is heading.

Instead of asking:

“How many vulnerabilities do we have?”

we should ask:

“Which weaknesses can an adversary actually chain together to compromise something valuable?”

AI can help defenders continuously analyze:

Asset → Vulnerability → Identity → Misconfiguration → Privilege → Attack Path → Business Impact

That changes vulnerability management from a batch process into a continuous risk-discovery process.

And there’s another problem: AI itself becomes part of the attack surface

Organizations now have:

  • AI applications
  • LLMs
  • AI agents
  • APIs
  • RAG systems
  • Vector databases
  • Model providers
  • AI-generated code
  • Shadow AI
  • Autonomous workflows

So we’re no longer protecting just IT infrastructure.

We’re protecting AI-enabled business processes.

That introduces risks such as prompt injection, data leakage, model abuse, excessive agent permissions, insecure AI integrations, supply-chain risks, and uncontrolled use of AI.

My perspective

I would summarize the future of cybersecurity as:

Defensive security keeps the adversary out. Proactive security assumes the adversary is looking for a way in—and continuously looks for that way first.

And with AI, the winning organizations won’t necessarily be the ones with the most security tools.

They’ll be the ones that can continuously discover risk, prioritize what matters, validate their defenses, and remediate faster than the threat can exploit them.

In the AI era, security has to move from “detect and respond” toward “discover, anticipate, validate, and disrupt.”

That is where I see the real evolution from defensive cybersecurity to proactive cybersecurity.

DISC-AI-Governance-Readiness-Assessment-1-1 pdf downloadDownload

AI Attack Surface ScoreCard 

MachineLearning & Artificial Intelligence

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Schedule a consultation: info@deurainfosec.com

InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory | ISO 27k Chat bot | Comprehensive vCISO Services | ISMS Services | AIMS Services | Security Risk Assessment Services | Mergers and Acquisition Securit

DISC InfoSec blog | DISC InfoSec Site | Contact us at info@deurainfosec.com

Tags: Defensive Security, Offensive security

Aug 03 2026

ISO 27001 Got You in the Door. ISO 42001 Keeps You There

Category: Information Security,Internal Audit,ISO 27k,ISO 42001,Security Compliance,Security Risk Assessment,vCISO — disc7 @ 10:19 am

Your Buyer Now Audits Your AI Before They Sign

Two years ago, the security questionnaire that stalled your enterprise deal asked about encryption at rest, access reviews, and whether you had a SOC 2 report.

It still asks those things. But now there’s a second section — and most B2B SaaS and financial services firms have no defensible answer to it.

Which AI systems are in scope? Who owns model risk? Where is your AI inventory? What happens when the model produces a harmful output — who finds out, and how fast?

The questions aren’t hypothetical anymore. The EU AI Act is phasing in. The Colorado AI Act is on the books. NIST AI RMF has become the reference language procurement teams borrow when they write their own diligence packets. And every enterprise buyer with a general counsel is now asking vendors to prove AI governance the same way they’ve asked them to prove information security for the last decade.

Here’s the part that matters commercially: the firms that can answer cleanly are closing deals the firms that can’t are losing.

The gap isn’t security. It’s evidence.

Most organizations we assess are not insecure. They have decent controls, competent engineers, and reasonable instincts.

What they don’t have is evidence — the documented, dated, owned, repeatable artifacts that let an auditor or an enterprise buyer verify a claim without taking your word for it.

That distinction is the whole ballgame. A control that exists but can’t be evidenced is, for audit purposes, a control that doesn’t exist. This is the single most common finding in the gap assessments we run, and it’s why “we’re basically compliant” is a sentence that costs companies six-figure contracts.

The fix isn’t more tooling. It’s structure: a management system that produces evidence as a byproduct of operating, rather than as a fire drill six weeks before an audit.

What DISC InfoSec actually does

DISC InfoSec is a boutique AI governance and cybersecurity consultancy in the SF Bay Area, working with B2B SaaS and financial services organizations. Not a platform. Not a checkbox vendor. Practitioner-led advisory from someone who has sat on both sides of the audit table.

Four service lines carry most of the work:

AI Governance & ISO 42001 (AIMS). ISO 42001 is the first international standard built specifically for AI management systems, and it layers AI-specific requirements on top of an ISO 27001-style foundation. We run the full lifecycle — AI inventory, AI system impact assessment, Statement of Applicability, AIMS policy set, internal audit, and Stage 1/Stage 2 support. If you’re already ISO 27001 certified, the incremental lift is far smaller than most teams assume, and we scope it precisely rather than selling you a second full program.

ISO 27001 & ISMS. Gap assessment through certification, including risk methodology, risk register, control implementation, and audit liaison. Where relevant, we extend into ISO 27701 for privacy (PIMS) so GDPR and CCPA obligations map to controls instead of living in a legal memo nobody operationalizes.

vCISO and vCAIO. Security and AI governance leadership at a fraction of an executive hire. Board reporting, risk governance, security strategy, customer diligence support, and the unglamorous ongoing work of keeping a program alive between audits. For companies deploying AI at any scale, the vCAIO role is increasingly the one that unblocks revenue.

Compliance readiness and risk assessment. SOC 2 readiness, NIST CSF 2.0 and NIST AI RMF mapping, EU AI Act and Colorado AI Act readiness, third-party and vendor risk, M&A cybersecurity due diligence, and web application penetration testing.

Across all of it, the operating principle is the same: map every gap to a framework requirement, rank it by priority, attach an effort estimate, and assign an owner. A roadmap that doesn’t do those four things is a document, not a plan.

The proof point

We led a virtual data room platform handling some of the most sensitive financial and legal documents in the M&A market — through ISO 42001 certification, passing Stage 2 on the first audit, with SenSiba as the certifying body. We also served as internal auditor on that engagement.

Financial data rooms are hard mode. If the AIMS holds up there, it holds up in your environment.

Credentials behind the work: CISSP, CISM, ISO 27001 Lead Implementer, ISO 42001 Lead Implementer, PECB Authorized Training Partner. Background spanning KPMG, IBM, and Intel/McAfee FoundStone, with prior engagements including NASA, Dell, Lam Research, and O’Reilly Media.

How engagements are structured

No open-ended retainers that quietly become annuities. Clear scope, fixed-fee options where the work allows:

PackageDeliverablesTimeline
ISO 27001 / 42001 Gap AssessmentBaseline audit, prioritized roadmap, executive summary2–4 weeks
SOC 2 ReadinessGap analysis, controls mapping, evidence checklist4–6 weeks
Startup Security ProgramPolicies, risk register, awareness training3–6 weeks

Roughly half of the clients who start with a gap assessment reach full certification within twelve months — with no surprises at Stage 2, because the surprises were surfaced in week two.

Start where the risk actually is

The most expensive mistake in compliance is committing to a certification timeline before you know your real position. Scope gets discovered mid-engagement, the auditor finds a control family nobody owned, and the date slips in front of the board.

Start with an assessment. Know where you stand. Then decide what to commit to.

→ Take the Free AI Governance & ISO 42001 Readiness Assessment

Find out in 15 minutes what your auditor would find in three days.

A structured self-assessment that scores your organization across the AI governance domains that matter to auditors and enterprise buyers alike — AI inventory, risk assessment process, model documentation, bias and performance testing, security controls, incident response, vendor and third-party model risk, and stakeholder accountability.

You get back:

  • A maturity score across each domain, benchmarked against certification-ready
  • The specific ISO 42001 and NIST AI RMF requirements your current state does and doesn’t satisfy
  • A prioritized gap list — what to fix first, and what can wait
  • A realistic view of the distance between where you are and audit readiness

No sales call required to see your results. Report delivered instantly.

Start the Free Assessment → ISO 42001 gap assessment quiz

Also available at no cost on our site deurainfosec.com:

  • EU AI Act Risk Classifier — classify your AI systems into prohibited, high-risk, limited-risk, or minimal-risk tiers and see the obligations that attach to each
  • ISO 42001 Gap Assessment — control-by-control evaluation against the full standard, with a prioritized path to certification
  • 5-Minute Security Risk Assessment — fast baseline across your information security posture

Want the results interpreted by a practitioner? Schedule a 30-minute consultation. We’ll walk your assessment output, tell you honestly whether certification is the right move this year, and scope it precisely if it is.

[ Schedule a Consultation → ] | info@deurainfosec.com | +1 (707) 998-5164

DISC InfoSec — Deura Information Security Consulting LLC. AI governance and cybersecurity consulting for B2B SaaS and financial services. Petaluma, CA / SF Bay Area. AI governance and cybersecurity consulting, ISO 42001 certification, ISO 27001 consulting, vCISO services, AI governance readiness

DISC-AI-Governance-Readiness-Assessment-1-1 pdf downloadDownload

AI Attack Surface ScoreCard 

MachineLearning & Artificial Intelligence

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Schedule a consultation: info@deurainfosec.com

InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory | ISO 27k Chat bot | Comprehensive vCISO Services | ISMS Services | AIMS Services | Security Risk Assessment Services | Mergers and Acquisition Securit

DISC InfoSec blog | DISC InfoSec Site | Contact us at info@deurainfosec.com

Tags: AI governance and cybersecurity consulting, AI governance and cybersecurity consulting Secondary: ISO 42001 certification, AI governance readiness, ISO 27001 consulting, vCISO services

Jul 31 2026

The Batch Model Is Broken: Vulnerability Management in the Era of AI-Accelerated Discovery

Category: Information Security,Security vulnerabilities — disc7 @ 9:37 am

The Batch Model Is Broken: Vulnerability Management in the Era of AI-Accelerated Discovery

Scheduled scans. Monthly patch windows. A CVSS-sorted queue that someone works down until capacity runs out.

That model was never elegant, but it worked because of three assumptions. All three are now false, and the data from the first half of 2026 makes that hard to argue with.

The three assumptions that just died

Assumption 1: discovery is rate-limited by human researchers.

FIRST projected roughly 59,400 CVEs for 2026 in February, then revised upward to about 66,000 in its mid-year forecast after actual publication ran 46% above baseline. H1 2026 closed at 35,364 published CVEs — roughly 192 per day, sustained. Microsoft’s July 2026 Patch Tuesday addressed 622 vulnerabilities, the largest single release on record.

Note that the vendor side is the part most programs are unprepared for. Discovery volume is someone else’s problem until it becomes a patch you have to test, schedule, and deploy. AI-accelerated discovery does not arrive as an interesting statistic. It arrives as a release calendar you cannot absorb.

Assumption 2: someone else enriches and scores the queue for you.

In April 2026, NIST formally stopped pretending it could keep up. The NVD now enriches only CVEs that are in CISA’s KEV catalog, affect federal systems, or fall under EO 14028 “critical software.” Everything unenriched with a publish date before March 1, 2026 was moved to “Not Scheduled” — a polite way of saying the backlog has been written off. NIST cited a 263% increase in submissions between 2020 and 2025.

Meanwhile the CVE program itself has spent two years on short funding extensions, ENISA is standing up the EUVD and moving toward top-level CNA status, and CIRCL is running GCVE as a decentralized alternative. There is no single authoritative source of enriched vulnerability data anymore. If your pipeline assumes one, your pipeline has a dependency that no longer exists.

Assumption 3: you have weeks between disclosure and exploitation.

VulnCheck’s H1 2026 data: of 495 newly exploited vulnerabilities, 23.4% showed exploitation on or before the day the CVE was published. The median time from CVE publication to confirmed exploitation dropped from 120 days to 80. Mandiant’s M-Trends puts mean time-to-exploit at negative seven days. Roughly 200 CVEs reached exploited status within 31 days of disclosure.

A monthly patch window is a policy decision to be exposed for up to 30 days. That was defensible when the median attacker took four months. It is not defensible now, and regulators have noticed.

The regulatory clock already moved

On June 10, 2026, CISA issued BOD 26-04, and it deserves more attention than it got. It revokes both BOD 19-02 and BOD 22-01, and it explicitly removes the requirement to use CVSS for prioritization. Federal civilian agencies now prioritize on four variables: is the asset publicly exposed, is the CVE in KEV, can the exploit be automated, and what is the post-exploitation technical impact. Hit all four and you have three days. Miss most of them and you may legitimately defer to the next system upgrade.

Two things in that directive matter to everyone, not just FCEB agencies:

  1. CVSS has been formally demoted by the agency that spent years telling people to use it. Severity is now an input, not a sort key.
  2. The directive requires forensic triage before patching, on the reasoning that applying a patch does not evict an attacker who already used the bug. That is a real change in posture — the remediation unit of work is no longer “deploy patch,” it’s “deploy patch and answer whether we were already hit.”

Add the EU Cyber Resilience Act’s actively-exploited-vulnerability reporting obligations landing in September 2026, and the direction is unambiguous. Auditors are moving from “did you patch within your stated SLA” to “can you defend, with evidence, why this was remediated before that.”

What this looks like in three years

Six predictions I’d put money on:

1. The queue becomes an event stream. Scheduled scanning survives only as a compliance artifact and a reconciliation check. The operating model is continuous: an asset changes or a vulnerability becomes exploitable, and that fires an event with an SLA clock attached. The clock starts at exposure, not at scan date.

2. Asset truth becomes the load-bearing control. Every prioritization model — BOD 26-04’s four variables included — collapses without accurate answers to “do we run this, where, and is it reachable from the internet.” Exposure is the one variable CISA does not supply for you. Organizations that never solved inventory will find that AI-era vulnerability management is mostly an inventory problem wearing a different hat.

3. Reachability replaces severity as the primary filter. SBOM plus call-graph reachability plus runtime exposure, with EPSS and KEV as overlays. The interesting number stops being “we have 14,000 findings” and becomes “we have 31 reachable, exposed, exploit-automatable findings.”

4. Remediation gets agentic, with gates. Patch generation, PR authoring, regression testing, and cross-repo propagation are already being automated by commercial tooling and by the open-sourced cyber reasoning systems from DARPA’s AI Cyber Challenge. AIxCC finalists patched 43 of 54 synthetic vulnerabilities and found 18 real ones across 54 million lines of code — and all seven systems were released open source. The constraint on autonomous remediation is not fix generation. It’s patch trust: does this change break production, and who signs off. Expect patch reliability scoring and staged autonomous deployment for low-risk classes, human review for the rest.

5. Provenance becomes a first-class field. “Who found this, using what, and was it reproduced” will be metadata you filter on. The signal-to-noise problem in intake is now permanent.

6. Upstream maintainer capacity becomes an enterprise risk register entry. This is the one most programs are not modelling at all, and I’ll come back to it.

Defending against AI-accelerated open source discovery

Concretely, for teams running open source in production — which is everyone:

Fix inventory before buying anything. SBOM per deployable artifact, not per repository, reconciled against what’s actually running. If you cannot answer “which services ship libwhatever 2.4” in under an hour, no prioritization model will help you.

Build a two-lane remediation process and pre-authorize the fast lane. Most organizations have one change process, tuned for a 30-day cadence, and it applies equally to a font rendering library and an internet-facing auth bypass. Define the fast-lane criteria in advance (public exposure + KEV or credible exploit + high technical impact), get standing change-board approval for that class, and pre-stage the rollback. The three-day timeline is not achievable if every emergency patch needs a fresh approval. This is where regulated environments lose — the controls that make you safe on paper are precisely what make you slow in practice, and the answer is to design the fast lane into your ISMS rather than around it.

Decouple mitigation from patching. Virtual patching at the edge, WAF rules, config-level kill switches, feature flags, disabling the vulnerable code path. When the median disclosure-to-exploitation window is measured in hours for edge devices, the question is “how fast can we become not-exploitable,” not “how fast can we deploy the vendor fix.”

Prefer currency over triage. Continuous dependency updating is cheaper than assessing 66,000 CVEs against a stale dependency tree. Teams that stay within a few weeks of upstream spend their triage budget on the genuinely hard calls. Teams that are 18 months behind spend it on archaeology.

Assume compromise inside the exposure window. BOD 26-04 is right about this. For any exploited vulnerability on an internet-facing asset, the remediation ticket should include a compromise assessment for the period between disclosure and patch. Retention of the relevant logs is a prerequisite you have to get right months in advance.

Treat maintainer capacity as a supplier risk. curl ended its paid bug bounty in January 2026 after AI-generated submissions collapsed its confirmed-vulnerability rate from roughly 15% to under 5%. In July 2026 it stopped accepting vulnerability reports altogether for five weeks so its maintainers could rest. Daniel Stenberg’s later point is the one that should worry you more than the slop: report quality has since improved, confirmed vulnerabilities are up past pre-AI levels, and that is what breaks small projects. An avalanche of legitimate findings hitting a two-person volunteer team means your Tier-1 dependency’s fix latency is now a function of someone’s personal bandwidth. HackerOne’s own Internet Bug Bounty paused new submissions in March 2026. Map your critical open source dependencies to their actual maintainer headcount and funding, and put the single-maintainer ones on the risk register.

If you run AI tooling against other people’s code, hold a verification standard. Reproduce it, attach a PoC, confirm the code path exists in the version you claim, and don’t submit anything you don’t understand. AISLE upstreamed 12 of 12 CVEs in a single curl release using AI tooling — the capability isn’t the problem, the discipline is. And if you’re operating that tooling as a service, note that you’ve built an AI system whose failure modes harm third parties: ISO 42001 impact assessment territory, not just an appsec tool.

Map the changes to your control framework now. ISO 27001 A.8.8 gets a documented, risk-based prioritization method with evidence trails, not “monthly patching.” SOC 2 CC7.1 needs your fast-lane criteria written down and consistently applied. NIST CSF ID.RA-05 and RS.MI get the exposure and reachability inputs. If AI is in your remediation pipeline, ISO 42001 Annex A controls apply to your use of it.

My perspective

The bottleneck was never discovery. It was decision and deployment.

For twenty years we treated vulnerability discovery as the scarce resource — that’s why bug bounties, pentests, and scanner licences got the budget. AI drove the marginal cost of discovery toward zero, and what it exposed is that most vulnerability management programs were never throughput-limited by finding bugs. They were limited by knowing what they run, deciding what matters, and getting change through the door. Those constraints are organizational, and no tool purchase fixes them.

I’d also push back on the panic framing. Of 1,061 vulnerabilities VulnCheck attributed to AI-assisted discovery in H1 2026, 14 — 1.3% — have confirmed exploitation in the wild, which roughly matches the base rate for all vulnerabilities. CVE volume rose 45%; KEV additions rose 10%. AI-found bugs are not disproportionately weaponized. So the honest reading is: the volume problem is real and the exploitation-per-CVE problem is not. Anyone selling you AI-attacker doom is selling the wrong crisis. The actual crisis is that your queue math stopped working and your prioritization can no longer be defended to an auditor.

What genuinely concerns me is the asymmetry in deployment, not discovery. Attackers have no change advisory board, no maintenance window, no regression suite, and no customer notification requirement. Defenders have all four, and in financial services and other high-trust environments they have them in heavier form. That asymmetry is where the risk actually accumulates — and it’s why I think the highest-leverage work for the next three years is unglamorous: inventory accuracy, pre-authorized emergency change paths, rollback confidence, and log retention that makes compromise assessment possible after the fact.

The second thing I’d watch is the quiet transfer of risk to unpaid maintainers. Enterprises are about to discover that “we patch within SLA” is meaningless when the upstream fix doesn’t exist because the person who writes it is burned out. If you depend on open source and don’t fund it, you are running an uninsured dependency.

Finally, on measurement. MTTR as a single organizational average is already a vanity metric. Within three years the numbers that matter are MTTR segmented by exposure class, percentage of remediation decisions traceable to documented evidence, and time-to-mitigation as distinct from time-to-patch. Programs that can produce those three will pass audits and survive incidents. Programs still reporting “we closed 94% of criticals this quarter” are describing a queue, not a risk posture.

Financial data rooms are the hard mode of compliance — heavy change control, heavy client scrutiny, zero tolerance for downtime. If you can build a defensible three-day fast lane in that environment, you can build it anywhere. That’s the work.

DISC InfoSec helps B2B SaaS and financial services teams build vulnerability management, ISO 27001, and ISO 42001 programs that hold up under audit and under pressure. If your patch SLAs are written for a threat model that expired, Let’s talk: info@deurainfosec.com

Sources

DISC-AI-Governance-Readiness-Assessment-1-1 pdf downloadDownload

AI Attack Surface ScoreCard 

MachineLearning & Artificial Intelligence

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Schedule a consultation: info@deurainfosec.com

InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory | ISO 27k Chat bot | Comprehensive vCISO Services | ISMS Services | AIMS Services | Security Risk Assessment Services | Mergers and Acquisition Securit

DISC InfoSec blog | DISC InfoSec Site | Contact us at info@deurainfosec.com

Tags: Era of AI-Accelerated Discovery, vulnerability management

Jul 30 2026


NIST CSF 2.0 and ISO 27001: Why the Strongest Programs Use Both

Category: CISO,ISO 27k,NIST CSF,vCISO — disc7 @ 9:51 am

NIST CSF 2.0 and ISO 27001: Why the Strongest Programs Use Both

Every security leader eventually gets asked the same question by a board member, a founder, or a prospect’s procurement team: “Which framework are we doing?”

The question assumes the frameworks compete. They don’t. NIST CSF 2.0 and ISO/IEC 27001:2022 are built for different jobs, and the strongest answer is usually not one or the other. It is understanding what each one is designed to achieve — and then letting each do the work it is actually good at.

Here is how that plays out in practice.

What NIST CSF 2.0 Is Designed to Do

NIST released CSF 2.0 in February 2024. It helps organizations organize, prioritize, and communicate cybersecurity outcomes across six core functions:

Govern → Identify → Protect → Detect → Respond → Recover

The addition of Govern (GV) in 2.0 was the significant change. In CSF 1.1, governance was buried inside Identify. In 2.0 it sits at the center, with six categories covering organizational context, risk management strategy, roles and responsibilities, policy, oversight, and — importantly — supply chain risk (GV.SC), which expanded from a single category into a serious body of guidance.

Three structural features matter:

  • Functions, categories, subcategories. Six functions, 22 categories, 106 subcategories. Each subcategory is an outcome statement, not a prescribed control. GV.OC-01 tells you the organizational mission must be understood and inform risk management. It does not tell you what tool to buy.
  • Profiles. You build a Current Profile (outcomes you achieve today) and a Target Profile (outcomes you need, based on business goals and risk appetite). The delta between them is your roadmap. This is the most underused feature of the framework.
  • Tiers 1–4 (Partial, Risk-Informed, Repeatable, Adaptive). These are not maturity levels, and Tier 4 is not the goal. Tier advancement should be driven by risk reduction needs across three dimensions: risk management process, integrated risk management program, and external participation.

CSF is voluntary, sector-neutral, and free. There is no certification body and no certificate.

What ISO/IEC 27001 Is Designed to Do

ISO/IEC 27001:2022 provides auditable requirements for establishing, operating, maintaining, and continually improving an Information Security Management System (ISMS).

The part people miss: Annex A is not the standard. Annex A is a reference set of 93 controls across four themes (organizational, people, physical, technological). The actual requirements live in Clauses 4 through 10, and they are where certification is won or lost:

ClauseRequirementWhat it forces you to produce
4Context of the organizationISMS scope, interested parties
5LeadershipSigned information security policy, defined roles
6PlanningRisk assessment methodology, risk treatment plan, Statement of Applicability, security objectives
7SupportCompetence records, awareness evidence, document control
8OperationExecuted risk assessments, treatment evidence, change records
9Performance evaluationMetrics, internal audit program, management review minutes
10ImprovementNonconformity and corrective action records

Clauses 9 and 10 are the engine. Internal audit, management review, nonconformity, corrective action — that closed loop is what makes an ISMS a management system rather than a filing cabinet of policies.

And the output is independently verifiable: a Stage 1 and Stage 2 audit by an accredited certification body, surveillance audits in years one and two, recertification in year three. A customer can ask for the certificate and the Statement of Applicability, and get a real answer.

The Distinction That Actually Matters

NIST CSF 2.0ISO/IEC 27001:2022
NatureOutcome-oriented, adaptableRequirements-based, prescriptive on process
AnswersWhat should we achieve?How do we govern and prove it?
Structure6 functions → 22 categories → 106 subcategoriesClauses 4–10 (mandatory) + 93 Annex A controls
AssuranceSelf-assessment; no certificateAccredited third-party certification
StrengthPrioritization, communication, roadmappingGovernance discipline, evidence, continual improvement
Cost to adoptFree, flexible, fast to startFee-bearing, structured, 6–12 months to certify
WeaknessNo enforcement mechanism; easy to self-grade generouslyAnnex A checkbox culture; scope games

Put plainly: NIST helps you decide what to do. ISO 27001 makes sure you actually keep doing it.

Used Together: One Operating Model

The two are complementary by design. NIST publishes ISO 27001:2022 mappings as Informative References in the CSF 2.0 Reference Tool, so the crosswalk is not something you have to invent.

Here is the mapping at the level you’ll actually use it:

CSF 2.0 outcome areaISO 27001:2022 anchor
GV.OC — Organizational contextClauses 4.1, 4.2
GV.RM — Risk management strategyClauses 6.1.2, 6.1.3
GV.SC — Supply chain riskA.5.19–A.5.22
ID.AM — Asset managementA.5.9–A.5.12
ID.RA — Risk assessmentClause 6.1.2, A.5.7
PR.AA — Identity and access controlA.5.15–A.5.18
PR.DS — Data securityA.5.33, A.8.24
PR.IR — Technology resilienceA.5.29, A.5.30, A.8.6
DE.CM — Continuous monitoringA.8.15, A.8.16
RS.MA — Incident managementA.5.24–A.5.28
RC.RP — Recovery planningA.5.29, A.5.30
ID.IM — ImprovementClauses 9.2, 9.3, 10.1

And here is the sequence that turns the mapping into an operating model:

  1. Set direction with CSF. Build the Current and Target Profile. The Target Profile is where regulatory obligations, customer commitments, and board risk appetite get written down as required outcomes.
  2. Convert the gap into a risk-driven roadmap. Sequence matters: GV.OC and GV.RM before ID.RA; ID.AM before PR.AA. You cannot protect an asset inventory you don’t have.
  3. Wrap the roadmap in an ISMS. ISO 27001 Clauses 4–6 turn your Target Profile into a scoped, risk-assessed, formally approved program with a Statement of Applicability that documents every control decision — including the exclusions and why.
  4. Operate with evidence. Clauses 7–8 make the work produce artifacts as a byproduct rather than as a fire drill before an audit.
  5. Verify and improve. Clauses 9–10 give you internal audit, management review, and corrective action. Feed the findings back into the next CSF profile revision.

That last step is the whole point. CSF tells you where you’re going. ISO 27001 is the drivetrain that keeps you moving and the odometer that proves you did.

Where This Breaks in Practice

Four failure patterns, in rough order of how often I see them:

Annex A as the whole standard. A team builds 93 control descriptions, skips Clauses 9 and 10, and shows up to a Stage 2 audit with no internal audit program and no management review minutes. Those are major nonconformities. The controls were never the hard part.

Self-graded CSF profiles. Without an audit function forcing the question, “partially implemented” quietly becomes “largely implemented” over two quarters with nothing changing. CSF has no immune system of its own. This is precisely the gap ISO Clause 9.2 fills.

Scope games. Certifying a narrow slice of the business and letting sales imply the whole company is covered. Sophisticated buyers read the certificate scope statement. It does not end well.

Two programs instead of one. Separate risk registers, separate control libraries, separate reporting. If your CSF assessment and your ISO risk treatment plan are maintained by different people in different tools, you’ve doubled the cost and halved the value. One control library, mapped both ways.

My Perspective

I’ll be direct about where I land, having implemented both.

CSF 2.0 is the better thinking tool. ISO 27001 is the better governing tool.

CSF’s real strength is communication. Six functions is a structure a CFO can follow in a ten-minute board slot. When you tell an executive team “we’re strong in Protect, thin in Detect, and we have no Recover capability worth the name,” they understand the risk without you translating a control matrix. Profiles and gaps are a language non-security stakeholders can actually engage with, and that is worth more than most people credit.

But CSF has no teeth. Nothing in the framework compels you to revisit your profile, audit your own claims, or escalate a stalled remediation. It is a map with no engine. Programs built on CSF alone tend to drift — good in year one, stale by year three, because nothing in the structure forces the review.

ISO 27001 supplies exactly what’s missing: a required cadence. Risk assessment must be repeated. Internal audit must happen on a program. Management review must occur with defined inputs and produce decisions. Nonconformities must be tracked to closure. That discipline is unglamorous and it is the difference between a security program and a security posture.

The honest criticism of ISO 27001 is that the discipline can become the product. Certified organizations with genuinely weak security exist — usually via a narrow scope, generous risk acceptance, and controls documented rather than operated. The certificate proves a management system functions. It does not prove you’d survive a competent adversary.

Which is why I think the pairing is more than a compliance convenience. CSF pushes an ISMS toward outcomes that matter — particularly Detect and Recover, where ISO’s Annex A coverage is thinner than the threat landscape warrants. ISO pushes a CSF program toward evidence and cadence. Each covers the other’s structural blind spot.

One more thing worth saying: CSF 2.0’s Govern function narrowed the historical gap considerably. GV.OC, GV.RM, GV.RR, and GV.PO now cover much of the territory ISO Clauses 4, 5, and 6 occupy. If you built a serious CSF 2.0 program including Govern, your distance to ISO 27001 certification is shorter than it was under CSF 1.1. The remaining delta is mostly Clauses 9 and 10 — the audit and review machinery — plus formal documentation control.

Which One Should You Start With?

Start with the forcing function, not the framework.

Start with NIST CSF 2.0 if:

  • You need to establish direction and priorities before spending money
  • Your budget or headcount can’t absorb a certification effort this year
  • You need to explain risk to a board or executive team quickly
  • You’re US-based, in critical infrastructure, or a federal supply chain participant where CSF and SP 800-53 are the shared language
  • You’re honestly at Tier 1 and need to know what “better” even looks like before committing to an audit date

Start with ISO 27001 if:

  • Deals are stalling in security review right now — that’s a revenue problem with a deadline
  • Enterprise or EU customers are asking for a certificate, not a self-attestation
  • You already have reasonable controls and need the governance layer and third-party validation
  • You have a related obligation nearby (SOC 2, ISO 42001, DORA, NIS2) and can share the management system across them

A practical default for most mid-market B2B SaaS and fintech companies: run a CSF 2.0 profile as a two-to-three week exercise to establish the outcome map, then immediately build the ISMS around it. The profile makes your ISO scope decision defensible and your Statement of Applicability grounded in something better than “the auditor asked for it.” You’re not doing two projects. You’re doing the thinking before the building.

And if your organization is already certified but the program feels performative — controls documented, nothing improving — the fix is usually not another framework. It’s a CSF 2.0 profile laid over your existing ISMS to surface the outcomes your Annex A implementation quietly failed to deliver.

The Real Question

It was never which framework is better. It’s which combination best supports your risk profile, regulatory obligations, customer expectations, assurance needs, and current maturity.

Get that answer right and the frameworks stop being compliance overhead. They become how the program runs.

Which does your organization use today — NIST CSF, ISO 27001, or both? If you’re deciding where to start, or you have a certification that isn’t producing real risk reduction, I’m happy to talk it through: info@deurainfosec.com

HD is Principal Consultant at DISC InfoSec, providing vCISO, ISO 27001, ISO 42001, NIST and SOC 2 advisory to B2B SaaS and financial services organizations. He led ShareVault through a successful ISO 42001 Stage 2 certification audit.

This article provides informational guidance based on NIST CSF 2.0 (February 2024) and ISO/IEC 27001:2022. It is not legal, audit, or certification advice. Certification decisions should be validated with your certification body and qualified advisors.

DISC-AI-Governance-Readiness-Assessment-1-1 pdf downloadDownload

AI Attack Surface ScoreCard 

MachineLearning & Artificial Intelligence

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Schedule a consultation: info@deurainfosec.com

InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory | ISO 27k Chat bot | Comprehensive vCISO Services | ISMS Services | AIMS Services | Security Risk Assessment Services | Mergers and Acquisition Securit

DISC InfoSec blog | DISC InfoSec Site | Contact us at info@deurainfosec.com

Tags: iso 27001, NIST CSF

Jul 27 2026

Continuous NIST 800-53 Compliance: How to Stop Failing in the Eleven Months Between Audits

Category: Information Security,NIST CSF,Security Compliance — disc7 @ 7:33 am

Continuous NIST 800-53 Compliance: How to Stop Failing in the Eleven Months Between Audits

Most organizations do not fail NIST SP 800-53 during the assessment. They fail three months after it, quietly, and only find out the following year when an assessor pulls a sample and the sample doesn’t hold.

The pattern is always the same. A team spends four months assembling a System Security Plan, closes findings in a sprint, gets a favorable Security Assessment Report, and then goes back to shipping product. Accounts drift. Baselines drift. Scans get acknowledged instead of remediated. The POA&M becomes a graveyard of “in progress” line items with completion dates in the past. Twelve months later the control catalog hasn’t changed — the environment has.

This post is about the operating model that prevents that: what NIST 800-53 compliance is actually worth to a business, how often it genuinely needs to be assessed, and how to run it as a continuous process instead of an annual fire drill.

Part 1 — What NIST 800-53 compliance is actually worth

SP 800-53 Rev 5 is the control catalog mandated for federal information systems under FISMA. But the business case for a private company adopting it usually has nothing to do with FISMA.

Market access. This is the honest headline. SP 800-53 is the substrate underneath FedRAMP (Moderate/High baseline plus overlay parameters), CMMC 2.0 Level 2 (via SP 800-171, itself derived from the Moderate baseline), and most agency-specific security requirements you’ll see in a federal contract or subcontract flow-down. If you want to sell to a federal agency, a systems integrator, or a prime, this isn’t a differentiator — it’s the door.

Procurement leverage in the commercial market. Enterprise and financial-services security questionnaires increasingly ask questions that are 800-53 controls wearing a different hat. Being able to answer “here is our AC-2 implementation, here is the evidence, here is the ODV we assert and the metric that proves we hold it” shortens diligence cycles measurably. Security review is a sales-cycle line item; control maturity is how you shorten it.

Framework reuse. This is the underrated one. One well-run 800-53 Moderate program feeds ISO 27001:2022 Annex A, SOC 2 Trust Services Criteria, CSF 2.0, PCI DSS, and the HIPAA Security Rule with substantial overlap. The catalog is a superset of most of what your other auditors will ask for. Organizations that build the evidence pipeline once and map outward spend a fraction of what organizations spend running four parallel compliance programs with four sets of screenshots.

Risk reduction that survives contact with reality. The control families that generate the most audit findings — AC (access control), CM (configuration management), RA (vulnerability monitoring), SI (flaw remediation), AU (audit and accountability) — are also, not coincidentally, the ones that show up in the root-cause section of breach reports. Compliance is a lagging indicator of hygiene. Done right, it is also the forcing function that produces it.

What it is not worth. It is not worth building High-baseline controls for a commercial SaaS product with no federal pipeline. Over-scoping 800-53 is one of the most expensive mistakes I see, and I’ll come back to it at the end.

Part 2 — How often should it be audited?

There is no single answer, because “audited” collapses four different activities that run on four different clocks. Getting this straight is most of the discipline.

ActivityWhoCadenceAuthority
Vulnerability scanning (OS, web app, DB)InternalMonthly minimum; weekly for databases under FedRAMPRA-5, SI-2
POA&M review and updateInternalMonthlyCA-5
Ongoing control assessment (rolling subset)Internal / ISSOContinuous or quarterlyCA-7
Contingency plan testInternalAnnual minimumCP-4
Security awareness and role-based trainingInternalAnnualAT-2, AT-3
Penetration testIndependentAnnual for Moderate and aboveCA-8
Full control assessmentIndependent assessor / 3PAOAnnual under FedRAMP; otherwise at reauthorizationCA-2
ReauthorizationAuthorizing OfficialEvery 3 years, or continuous authorizationRMF Step 6

Two things about assessor independence, because this is where organizations get caught:

  • Low-impact systems may self-assess.
  • Moderate-impact systems require an assessor independent of the implementation team — a different team inside your organization can qualify.
  • High-impact and FedRAMP systems require an accredited third-party assessment organization.

My practical recommendation for a private company with no federal mandate: run a full internal control assessment annually against your tailored baseline, an independent external assessment every two years, monthly scanning and POA&M discipline without exception, and a rolling quarterly assessment of roughly one quarter of your control set so that every control gets touched inside twelve months. That last item is the one nobody does, and it’s the one that makes the annual assessment boring instead of terrifying.

The direction of travel matters here too. The federal program is actively moving off point-in-time assessment. FedRAMP announced its 20x modernization in March 2025 and has been building toward continuous, machine-readable evidence, Key Security Indicators, and automated validation in place of annual assessment plus monthly manual deliverables. FedRAMP published Consolidated Rules in June 2026, and legal analysts read those rules as transitioning existing Rev5 authorizations toward 20x with Rev5 status expected to end by 2028. Whatever the exact timeline turns out to be, the design intent is unambiguous: demonstrate the control working, don’t describe it. If your evidence is a human taking a screenshot, you are building technical debt.

Part 3 — The continuous compliance operating model

Here is how to actually run it.

1. Treat your control set as data, not as a document

The Word-document SSP is the single biggest structural cause of drift. A 400-page narrative cannot be diffed, tested, or queried, so it decays silently.

Move your control inventory into a structured form: one record per control, with implementation status, responsible role, inherited-vs-system-specific designation, the organization-defined values you assert, the evidence source, and the collection frequency. OSCAL is the NIST-developed format for exactly this — catalog, profile, component definition, SSP, assessment plan, assessment results, and POA&M all have machine-readable representations. Even if you never submit OSCAL to anyone, modeling your program that way means you can ask questions like “which controls have no automated evidence source?” and get an answer in seconds.

Rule of thumb: if you cannot generate your SSP from your control data, you have a document, not a program.

2. Instrument the controls that actually drift

Not all 323 Moderate controls decay at the same rate. Physical controls (PE) barely move. Policy controls (the -1 control in every family) move annually. The controls that break between audits are a predictable short list, and they deserve automated telemetry:

ControlWhat driftsAutomate
AC-2, AC-2(3)Orphaned accounts, stale privileges, inactive accounts past ODVDaily IdP query against HR system of record
AC-6(7)Privilege creep after project-based grantsQuarterly automated privileged-access review
CM-6Configuration baseline deviationContinuous config scanning (SCAP/XCCDF, CSPM, policy-as-code)
CM-8Asset inventory divergenceContinuous discovery reconciled against CMDB
CM-3Undocumented changesChange records generated from the deployment pipeline
RA-5 / SI-2Unpatched findings aging past ODVScanner-to-ticket integration with SLA clocks
IA-5(1)Authenticator policy exceptionsPolicy-as-code assertion in the IdP
AU-6Logs collected but never reviewedDetection content plus documented review cadence
CP-9Backups running but never restore-testedScheduled automated restore verification

Everything else can run on a documented periodic review. Focus the engineering effort where the decay rate is highest.

3. Build evidence pipelines, not evidence hunts

Grade your evidence honestly. There are three tiers:

  1. Machine-generated telemetry from the authoritative source. The IdP’s own account export. The scanner’s own output. Can’t be fabricated, can’t go stale.
  2. Automated validation results. A policy-as-code check that asserts the control condition and emits pass/fail on a schedule.
  3. Human-produced artifacts. Screenshots, meeting minutes, attestations.

Tier 3 is the tax you pay for every control you failed to instrument. Inventory your controls by evidence tier, then work the list. The goal is not perfection — it’s that the ratio moves in the right direction every quarter, and that no high-risk control depends on somebody remembering to take a screenshot in the week before the assessor arrives.

4. Convert your ODVs into service-level objectives

Organization-defined values (ODV) are the sharpest tool in the catalog and the most commonly wasted. When you write “disable inactive accounts after 90 days” into your SSP, you have just written an SLO. Treat it like one: instrument it, dashboard it, alert on breach, and report the metric — not the intention.

ControlODV you assertThe metric that proves it
AC-2(3)Inactive accounts disabled within 90 daysMax account inactivity age, measured daily
SI-2Critical flaws remediated within 30 daysAge distribution of open critical findings
AU-11Audit records retained 3 yearsOldest retrievable record, verified quarterly
CA-7ConMon assessment frequency: monthly% of scheduled assessments completed on time
IR-6Incident reported within [x] hoursMedian detection-to-report time per incident

Two failure modes to avoid. First, do not assert an ODV you cannot measure — assessors test exactly these values, and a missed ODV converts a satisfied control into an Other Than Satisfied finding. Second, do not set ODVs tighter than your operational reality to look good on paper. A 15-day critical patch ODV you breach every month is materially worse than a 30-day ODV you consistently hold.

5. Make change management the compliance trigger

Continuous compliance is really change control with a security-authorization boundary drawn around it. Every meaningful change to the system is a potential control-impact event, and CM-3 is where you catch it.

Wire a security-impact assessment into your change process. Three questions, answerable in a pull-request template:

  1. Does this change the authorization boundary or introduce a new external interface?
  2. Does this change how data is stored, transmitted, or classified?
  3. Does this alter the implementation of any control in the SSP?

Any “yes” routes to the ISSO or security owner, updates the affected control narrative, and — for significant changes — triggers reassessment of the affected controls before deployment rather than at the next annual cycle. A “significant change” that reaches the assessor before it reaches you is the worst possible sequencing.

6. Run the POA&M as an operational queue

The POA&M (CA-5) is either a live remediation backlog or a document you write to make an auditor go away. Make it the former:

  • Every open item has a named owner and a real, defensible completion date
  • Risk-based deadlines with a working clock — the FedRAMP model is a reasonable default: 30 days critical, 90 days high, 180 days moderate, one year low
  • Monthly review with the same seriousness as a sprint review
  • Risk acceptance is a documented decision with business justification and signature from the system owner, not a status you drift into
  • Nothing sits in “risk accepted” indefinitely at high or critical severity

If your POA&M has items older than a year with no milestone movement, that is the finding. The underlying weakness is secondary.

7. Report metrics that predict the audit outcome

Board and executive reporting should not be a control count. Five numbers tell you whether the program is actually continuous:

  • Evidence automation ratio — % of controls with Tier 1 or Tier 2 evidence
  • ODV breach rate — % of asserted values held over the last 90 days
  • POA&M aging — count and oldest age of items past their scheduled completion date
  • Assessment coverage — % of the control set assessed within the last 12 months
  • Mean time to control restoration — how long a drifted control stays drifted once detected

If those five are healthy, the annual assessment is a formality. If they aren’t, no amount of documentation effort in assessment month will save you.

Part 4 — The twelve-month operating calendar

CadenceActivities
ContinuousConfig drift detection (CM-6), asset discovery (CM-8), account reconciliation (AC-2), log monitoring (AU-6, SI-4), automated control validation
MonthlyVulnerability scans across OS / web / database (RA-5), POA&M update and review (CA-5), rolling control assessment slice (CA-7), security status report to the authorizing role
QuarterlyPrivileged access review (AC-2, AC-6), risk register review (RA-3), supplier and supply-chain review (SR family), tabletop on one incident scenario (IR-3), backup restore verification (CP-9)
AnnualFull internal control assessment (CA-2), penetration test (CA-8), contingency plan test (CP-4), security awareness and role-based training (AT-2, AT-3), policy refresh across all -1 controls, privacy review (PT family), ODV re-validation
Every 3 yearsReauthorization / full independent assessment — or nothing at all, if you’ve achieved genuine ongoing authorization

Part 5 — Where this goes wrong

Five failure modes account for most of what I see:

  1. Compliance owned entirely by GRC. If engineering doesn’t own control implementation, controls exist in documents only. GRC should own the framework, the evidence model, and the reporting. Engineering owns the controls.
  2. Inherited controls assumed rather than verified. Your cloud provider covers a large slice of PE, MA, and parts of SC — but the customer-responsibility side of every shared control is yours, and it’s where assessors concentrate. Read the responsibility matrix; don’t assume it.
  3. Tailoring never documented. Removing a control is legitimate. Removing it without a written scoping rationale is a finding, and a fast one.
  4. PT and SR treated as optional. Privacy controls apply to any system processing PII regardless of impact level, and supply chain risk management was added as a full family in Rev 5. Both are still routinely skipped in programs built on Rev 4 muscle memory.
  5. Screenshot-driven assessment prep. If the four weeks before an assessment look different from any other four weeks, the program isn’t continuous. That gap is exactly what the federal program’s shift to automated, machine-readable evidence is designed to eliminate.

My perspective: one catalog, two assurance markets

Here’s the view I’d argue for.

Stop thinking of NIST 800-53 as a federal framework you either need or don’t. It is the most complete security and privacy control catalog in public circulation, and it is free. Treat it as your internal control spine — the canonical statement of what your organization does about security — and treat every external framework as a rendering of that spine for a specific audience.

That reframing lets you stratify cleanly:

The private-sector expression is ISO 27001 and SOC 2. Both are audience-facing assurance products. Neither is as complete as 800-53, and both are heavily covered by an 800-53 Moderate implementation. If your market is commercial, do not chase federal-grade documentation artifacts. Implement against the Moderate baseline as an internal standard, tailor aggressively, and render your evidence into ISO Annex A and Trust Services Criteria formats. You will pass both audits with material effort savings, and you will have a substantially better security program than a SOC 2 report alone would produce.

The public-sector expression is FedRAMP, CMMC, and agency ATOs. This layer adds cost that has little to do with security and a lot to do with assurance formality: mandated ODVs, FIPS-validated cryptography, prescribed document templates, accredited third-party assessors, machine-readable submission formats, and a named official accepting risk on the government’s behalf. It is worth paying for only if there is a real federal revenue thesis behind it.

The strategic decision, then, is not “which framework.” It’s how high up the assurance ladder you climb, and when. My recommended sequencing:

  1. Adopt the Moderate baseline as internal policy now, regardless of market. It costs nothing to use as your control taxonomy, and it means every future framework is a mapping exercise rather than a program build.
  2. Automate evidence before you pursue certification. The organizations that struggle with FedRAMP are not the ones with weak controls — they’re the ones with strong controls and manual evidence. That constraint is getting sharper, not looser, as the program moves toward continuous machine-readable validation.
  3. Climb to the public-sector tier only against a named opportunity. A specific agency, a specific prime, a specific contract vehicle. “Federal might be interesting someday” is not a business case for a 3PAO engagement.
  4. Never run two programs. One control inventory. One evidence pipeline. Multiple renderings. The moment you have a FedRAMP evidence set and a separate SOC 2 evidence set, you’ve doubled your cost and halved your accuracy.

The organizations that get this right end up in an unusual position: continuous compliance stops being an expense line and becomes a sales asset. They answer security questionnaires in days instead of weeks, they enter federal procurement with the hard part already done, and their annual assessment is a review of numbers they were already watching.

That’s the whole objective. Not passing the audit — making the audit uninteresting.

HD “Disc” is Principal Consultant at DISC InfoSec, specializing in AI governance and information security compliance — ISO 42001, ISO 27001, NIST 800-53, and SOC 2 — for B2B SaaS and financial services organizations.

Working out where your organization sits on the assurance ladder, or trying to move an 800-53 program from annual scramble to continuous operation? Book a conversation. or email at info@deurainfosec.com

Sources: NIST SP 800-53 Rev 5, SP 800-53A Rev 5, SP 800-53B, SP 800-37 Rev 2, SP 800-137, FIPS 199/200. FedRAMP modernization details current as of July 2026 — verify against fedramp.gov before relying on specific dates.

DISC-AI-Governance-Readiness-Assessment-1-1 pdf downloadDownload

AI Attack Surface ScoreCard 

MachineLearning & Artificial Intelligence

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Schedule a consultation: info@deurainfosec.com

InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory | ISO 27k Chat bot | Comprehensive vCISO Services | ISMS Services | AIMS Services | Security Risk Assessment Services | Mergers and Acquisition Securit

DISC InfoSec blog | DISC InfoSec Site | Contact us at info@deurainfosec.com

Tags: NIST 800-53, NIST-800-53

Jul 22 2026

AI Governance Readiness Assessment — Service

Category: AI Governance — disc7 @ 2:03 pm

A fixed-scope, fixed-fee, two-week engagement that tells a company exactly where it stands against an AI governance standard — and hands them a prioritized, costed remediation plan they can execute against.

Auditor-grade certainty in two weeks, not a six-month program.

Included

  • Kickoff + context intake (60 min) — business model, where AI touches the product, the deadline driving this
  • AI system inventory — a complete catalogue of where AI/ML operates across the product and vendors. Most teams cannot produce this, and every framework starts here.
  • Control-by-control gap analysis against one chosen framework (see lenses below)
  • Risk & impact assessment review — is there a defensible, repeatable process, or a one-off spreadsheet?
  • Evidence review — spot-check that priority controls actually operate and produce proof, not just exist on paper
  • Prioritized remediation roadmap — findings ranked by risk × effort, sequenced, with rough effort/cost estimates
  • Readout call (60 min) walking through the report and the recommended sequence

Explicitly excluded (these are the follow-on engagement)

  • Writing policies, procedures, or the Statement of Applicability
  • Running the risk or impact assessments on their behalf
  • Implementing or remediating any control
  • The certification audit or acting as certification body
  • Penetration testing or technical security testing of the AI system (separate offer)
  • More than one framework lens (multi-framework is a priced add-on)
  • Revisions beyond one round of clarifications on the final report

Framework lenses (pick one)

LensBest fit
ISO 42001Flagship. Teams pursuing certification or building a formal AIMS. Your strongest proof point.
EU AI ActAnyone with EU users or customers; deadline-driven urgency
NIST AI RMFUS teams wanting a framework without a certification commitment
Colorado AI Act / US stateUS SaaS with consumer-facing AI decisions

Add-on: a second lens or an ISO 42001 ↔ EU AI Act crosswalk, priced at +50% of the base fee. This is a natural upsell for anyone serving both markets.

DISC InfoSec                                         DEURA INFORMATION SECURITY CONSULTING

PAID READINESS ENGAGEMENT

AI Governance

Readiness Assessment

Know exactly where you stand — in two weeks, for a fixed fee.

Your free assessment gave you a directional score. This gives you the auditor’s-eye version: a control-by-control review of your actual AI governance against ISO 42001, the EU AI Act, NIST AI RMF, or US state law — and a prioritized, costed plan to close the gaps.

WHAT YOU GET

→  A complete inventory of where AI operates across your product→  A gap register mapped to every relevant control, with maturity ratings
→  A remediation roadmap, sequenced by risk and effort, with cost estimates→  A 60-minute readout to walk through it, personally

  FIXED FEE   /   TWO WEEKS

  CREDITED IN FULL TOWARD IMPLEMENTATION

  IF YOU PROCEED WITHIN 90 DAYS

Led by DISC InfoSec — CISSP, CISM, ISO 42001 Lead Implementer — who took a financial data room platform through its ISO 42001 Stage 2 certification audit. Financial data rooms are the hard mode of compliance; if it holds up there, it holds up for you.

  BOOK A 20-MINUTE SCOPING CALL   →

Is it a fit?  Built for B2B SaaS and fintech teams with AI in production and a deadline in sight. Not there yet? The free assessment is the better starting

deurainfosec.com | hd@deurainfosec.com              

                   

DISC-AI-Governance-Readiness-Assessment-1-1 pdf downloadDownload

AI Attack Surface ScoreCard

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Schedule a consultation: info@deurainfosec.com

InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory | ISO 27k Chat bot | Comprehensive vCISO Services | ISMS Services | AIMS Services | Security Risk Assessment Services | Mergers and Acquisition Securit

DISC InfoSec blog | DISC InfoSec Site

Jul 21 2026

GRC Engineering: From Evidence Theater to Genuine Assurance

Category: GRC,Information Security — disc7 @ 11:14 am

GRC Engineering: From Evidence Theater to Genuine Assurance

Most GRC programs are quietly optimized for the wrong outcome. They are built to survive an audit, not to reduce risk. The busiest weeks on the calendar are the ones before an assessor arrives, and the measure of success is a clean opinion rather than a safer environment. That is the gap GRC engineering exists to close.

The shift is simple to state and hard to internalize: stop spending human effort proving controls work, and start spending it understanding whether they actually do.

The problem with evidence collection

Traditional GRC burns most of its energy on a single low-value activity — assembling evidence to satisfy an auditor. Someone pulls a screenshot of an access review, exports a config, snips a ticket, drops it in a folder, and labels it. Multiply that across dozens of controls and hundreds of systems, and you have a full-time job that produces no security whatsoever. It produces a record of security, sampled once, at a moment that may bear no resemblance to how the environment looks the other 364 days of the year.

The screenshot is not the control. It is a photograph of the control on its best behavior.

From evidence collection to genuine assurance

This is the heart of GRC engineering. Instead of humans manually gathering artifacts, you automate collection so it pulls directly from the source system — the IdP, the cloud provider, the ticketing tool, the code repository — continuously and programmatically. When you do that, three things change in ways that compound:

Assurance gets stronger. You are no longer inspecting one sampled snapshot and hoping it generalizes. You are checking the real thing, continuously, against the live state of the system. A control that passes in January and silently drifts in March gets caught in March, not at next year’s audit.

Policies start to reflect reality. When the people writing policy can see the actual environment — not a sanitized description of it — the gap between “what we say we do” and “what we do” narrows. Policy stops being aspirational fiction and starts describing an enforceable, observable state.

The GRC professional stops being a translator. So much of the traditional role is shuttling screenshots between engineering and auditors, acting as a human API between teams that do not speak the same language. Automate that, and the practitioner is freed to do the work that requires judgment: interpreting risk, advising on trade-offs, and pushing for changes that actually move the needle. The job upgrades from clerk to advisor.

GRC as an insights function

Here is the reframing that makes all of this strategic rather than merely efficient.

When your data is continuous and machine-readable, GRC stops being an audit-prep function and becomes an insights function. You can suddenly surface signals that leadership has never had access to before: trends across hundreds of systems, concentrations of risk that only appear when you aggregate, and — the most valuable of all — controls that look perfectly fine on paper but keep failing quietly in practice.

That last category is where real risk hides. A control marked “implemented” in the register but failing 8% of the time is invisible to a checklist and obvious to a data pipeline. Only continuous, queryable evidence exposes it.

And in this model, audit readiness stops being the goal. It becomes a byproduct. If you are continuously verifying the real state of your controls and can produce that history on demand, the audit is no longer an event you brace for — it is a report you export. You were ready the whole time, because you were never doing this for the audit in the first place.

Why this is the real shift

It is tempting to sell GRC engineering as an efficiency play — fewer manual hours, faster evidence collection, lower cost of compliance. All true, and all beside the point. The efficiency is the least interesting thing about it.

The interesting thing is that GRC engineering changes what the function is for. It moves the center of gravity from “can we pass” to “are we actually secure, and how do we know” — and it gives you the data to answer that second question with something better than a shrug and a folder of screenshots.

My perspective

Having built and audited management systems on both sides of this — the manual, screenshot-driven world and the automated one — I think the framing above is broadly on the right track, but there are two areas where it would benefit from closer scrutiny.

First: automation raises the stakes on your control design, it does not lower them. When evidence collection was manual, a badly designed control was merely tedious to prove. When it is automated and continuous, a badly designed control fails loudly, constantly, and in front of leadership. That is a feature, but teams underestimate the cultural readiness it demands. The first time a dashboard shows a control failing 12% of the time, someone will ask to “fix the dashboard.” The maturity of a GRC engineering program is measured by how the organization answers that request. Continuous assurance is only valuable if you are prepared to act on inconvenient truths, not explain them away.

Second: the hardest part is not the pipeline — it is deciding what “passing” actually means. Automating collection is a solved problem; the tooling is mature. The genuinely difficult, irreducibly human work is translating a control objective into a machine-checkable assertion that is neither so loose it is meaningless nor so strict it drowns you in false positives. “All production access is reviewed quarterly” is a policy. Turning it into a query that knows what production is, what access counts, what a valid review looks like, and what to do about the service account that legitimately never gets reviewed — that is engineering judgment, and it does not automate away. It is exactly the work that gets freed up when you stop shuttling screenshots. So the promise of the advisor role is real, but only if the practitioner has the technical fluency to define the assertions in the first place. The role does not just get more strategic; it gets more technical. Both things are true at once, and the people who thrive in this discipline will be the ones comfortable living in that overlap.

The organizations I have seen get real value from this are, unsurprisingly, the ones operating in high-stakes data environments — where a control drifting silently for a quarter is not an audit finding, it is an incident waiting to be disclosed. When the downside is that severe, continuous assurance stops being a nice-to-have and starts being the only honest way to run the program.

GRC engineering, done well, is not compliance done faster. It is the point at which the compliance function finally starts telling the truth in real time.

AI Attack Surface ScoreCard

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Schedule a consultation: info@deurainfosec.com

InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory | ISO 27k Chat bot | Comprehensive vCISO Services | ISMS Services | AIMS Services | Security Risk Assessment Services | Mergers and Acquisition Securit

DISC InfoSec blog | DISC InfoSec Site

Tags: GRC Engineering

Jul 20 2026

AI Risk Management: AIRM isn’t a Security Problem — It’s Bigger

Category: AI,AI Risk,Risk Assessment — disc7 @ 9:23 am

AI Risk Management: The Discipline Your AI Strategy is Missing

Most organizations discovered last year just how much AI they were already running. A customer support chatbot here. Copilot in the IDE. Einstein scoring leads in the CRM. A fraud model someone built in 2021 that nobody owns anymore. When I run AI inventories for clients, the number of AI systems they think they have and the number they actually have are never the same — and the gap is where the risk lives.

That gap is exactly what AI risk management exists to close.

What Is AI Risk Management?

AI risk management is the discipline of identifying, evaluating, and treating the risks that AI systems introduce across their entire lifecycle — not just the security risks, but the fairness, robustness, transparency, privacy, and accountability risks that traditional security programs were never designed to catch.

Here’s the distinction that matters: prompt injection and jailbreaks are the security slice of AI risk. They get the headlines. But the risks that actually put organizations in front of regulators look different. A hiring model that screens out candidates from a protected class. A credit model that’s 95% accurate overall but 60% accurate on the demographic it impacts most. A production LLM that hallucinates a policy your company never had — to a customer, in writing. A model that drifted quietly for eighteen months because nobody was watching, and no one could explain its decisions when a regulator asked.

None of those are breaches. All of them are business-ending risks in the wrong context.

The most widely adopted framework for managing this is the NIST AI Risk Management Framework (AI RMF 1.0). It’s voluntary, but it has become the lingua franca of AI risk — cited in contracts, RFPs, executive orders, and increasingly in customer security questionnaires. If you speak NIST CSF, the shape will feel familiar. The AI RMF organizes the work into four functions:

GOVERN is the persistent layer: written AI principles, a named AI risk owner, approval gates for high-impact deployments, and — critically — someone with the authority to stop a deployment. If nobody in your organization can say “no” to an AI system, you don’t have governance. You have hope.

MAP establishes context per system: what does this AI actually do, who does it affect, what does “broken” look like, and — the question I find most clarifying in practice — is the decision reversible? A spam filter making a wrong call is an annoyance. A mortgage denial is not.

MEASURE is where the engineering happens: accuracy evaluated on data slices rather than aggregates, fairness metrics (demographic parity, equalized odds, calibration — which conflict, and choosing among them is a governance decision, not a technical one), robustness against adversarial inputs and distribution shift, and explainability. A model you cannot explain is a model you cannot defend in a regulatory inquiry.

MANAGE treats what MEASURE surfaces: retrieval-augmented generation for hallucination, monitoring and scheduled retraining for drift, human-in-the-loop for high-stakes decisions, vendor risk reviews for third-party models — and a decommissioning plan for every model, because an unowned production model is the AI equivalent of an unmaintained dependency.

Layer the regulatory landscape on top — the EU AI Act with its risk tiers and phased enforcement, the Colorado AI Act, NYC’s bias audit law for automated hiring tools, FTC and EEOC enforcement authority — and the picture is clear: AI risk management is no longer optional for any organization deploying AI in consequential decisions.

My Perspective: What a Proper AI Risk Management Program Actually Buys You

I led the ISO 42001 AI Management System implementation at ShareVault, a virtual data room platform serving M&A and financial services clients — an environment where the data is deal-sensitive and the tolerance for AI failure is effectively zero. Taking that program through a successful Stage 2 audit taught me what separates AI risk management as a paper exercise from AI risk management as a working system. Here’s what a proper program delivers:

It converts unknown risk into managed risk. The inventory step alone is worth the engagement. You cannot govern what you haven’t cataloged, and shadow AI — the tools employees adopted without review — is present in every organization I’ve assessed. Visibility precedes control, always.

It prevents the expensive failures, not just the embarrassing ones. Biased outcomes in hiring or credit carry regulatory penalties, litigation exposure, and remediation costs that dwarf the price of evaluating the model before deployment. Fairness testing during MEASURE costs days. A disparate-impact claim costs years.

It turns compliance from a scramble into a byproduct. Organizations with a working AI RMF-aligned program aren’t rebuilding from scratch when the EU AI Act’s high-risk requirements apply to them, or when a state law lands, or when an enterprise customer’s due-diligence questionnaire asks how they govern AI. The documentation, the impact assessments, the human oversight mechanisms — they already exist. Frameworks like NIST AI RMF and ISO 42001 map cleanly onto each other and onto the regulations. Build once, answer everywhere.

It becomes a sales asset. This is the part most organizations underestimate. In B2B — especially financial services — your customers’ risk teams are now asking about your AI. Being able to hand over an AI system inventory, model documentation, and evidence of independent audit doesn’t just pass procurement. It shortens sales cycles. At ShareVault, ISO 42001 certification became a differentiator precisely because the market is full of AI claims and short on AI evidence.

It lets you move faster, not slower. The counterintuitive one. Teams without governance hesitate on every AI deployment because nobody knows what’s acceptable. Teams with clear approval gates — rigorous review for high-impact systems, lightweight paths for low-impact ones — ship with confidence. Good governance is a throttle, not a brake. Overengineering the process kills it; right-sizing it accelerates everything.

The organizations getting AI risk management right in 2026 aren’t the ones with the thickest policy binders. They’re the ones who treated it as an operating discipline: inventory what you have, understand what it affects, measure what matters, treat what you find, and build the governance layer that keeps it working after the consultants leave.

Leadership must treat regulatory security, privacy & AI compliance as a strategic risk management priority. Noncompliance can lead to financial penalties, litigation exposure, reputational damage, and loss of customer trust. Top management should ensure that security, privacy & AI compliance risks are incorporated into enterprise risk assessments, evaluated using risk-based decision-making frameworks, reported regularly to executive leadership and governing bodies, and addressed through mitigation strategies aligned with organizational risk tolerance.

The ones getting it wrong will find out the way organizations always find out — in production, in public, or in front of a regulator.

HD is Principal Consultant at DISC InfoSec, a boutique cybersecurity and AI governance consultancy. He holds CISSP, CISM, AICP, ISO 27001 Lead Implementer, and ISO 42001 credentials, and led the ISO 42001 AIMS implementation and internal audit at ShareVault through a successful Stage 2 certification audit.

If your organization is deploying AI and can’t yet answer “how do you govern it?” — let’s talk. Book a consultation: info@deurainfosec.com

AI Attack Surface ScoreCard

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Schedule a consultation: info@deurainfosec.com

InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory | ISO 27k Chat bot | Comprehensive vCISO Services | ISMS Services | AIMS Services | Security Risk Assessment Services | Mergers and Acquisition Security

DISC InfoSec blog | DISC InfoSec Site

Jul 12 2026

The adversary that treats your balance sheet as the objective

Category: Attack Matrix,Cyber Threats,Information Security,Threat detection,Threat Modeling — disc7 @ 4:02 pm
The-Balance-Sheet-Adversary_-Lazarus-Group-TTPs-Mapped-for-Defenders-—-DISC-InfoSec-1Download pdf

Download html file

lazarus-group-ttps-blog-Download html

AI Attack Surface ScoreCard

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Schedule a consultation: info@deurainfosec.com

InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory | ISO 27k Chat bot | Comprehensive vCISO Services | ISMS Services | AIMS Services | Security Risk Assessment Services | Mergers and Acquisition Security

DISC InfoSec blog | DISC InfoSec Site

Tags: Lazarus Group, TTPS

Jul 10 2026

Why Supplier Security Is Under the Spotlight — and How to Build a Vendor Management Program for the AI Era

Category: AI,AI Risk,Vendor Assessment — disc7 @ 7:22 am

Why Supplier Security Is Under the Spotlight — and How to Build a Vendor Management Program for the AI Era

Your security program is only as strong as the weakest vendor with access to your environment. That’s not a slogan anymore — it’s what the breach data says, it’s what regulators are writing into law, and it’s what enterprise buyers are now testing before they sign anything.

The numbers stopped being deniable

For years, third-party risk was something organizations acknowledged in a policy document and revisited once a year with a questionnaire. That era is over, and the data explains why.

SecurityScorecard’s 2025 Global Third-Party Breach Report attributes roughly 35% of all breaches to third parties. Other industry research puts supply chain breach exposure near-universal — the overwhelming majority of organizations experienced some form of supply chain security incident in 2025. Meanwhile, fewer than half of organizations monitor even 50% of their supply chain. And on the regulatory side, an estimated three-quarters of GDPR fines have a third-party component.

Read those together and the picture is simple: attackers have figured out that the vendor is the door, most organizations aren’t watching the door, and regulators are fining the building owner anyway.

Attackers didn’t get smarter about your perimeter. They got smarter about economics. Why spend months trying to breach one hardened enterprise when you can compromise one widely-used tool and inherit access to thousands of downstream environments at once?

The AI supply chain made it worse

The recent Trivy and LiteLLM supply chain attacks are the clearest example of where this is heading. These weren’t obscure utilities — they were trusted security and AI tooling sitting inside CI/CD pipelines. Attackers compromised the tools upstream, and the malicious code did exactly what you’d fear: harvested secrets, cloud credentials, and SSH keys from inside trusted processes, then used that access to move downstream into additional systems. Almost no warning signs, because the attack ran inside software everyone had already decided to trust.

The lesson isn’t “stop using open source” or “stop using AI tooling.” The lesson is that trust without verification is now a documented attack vector, and the AI era multiplies it in three specific ways:

First, AI tools proliferate faster than procurement can see them. Every SaaS product your vendors use is quietly adding AI features. Your data processor is now also an AI deployer, whether their contract with you contemplated that or not. Shadow AI in your supply chain is shadow AI in your risk register — you just haven’t written it down yet.

Second, AI dependencies are deep and opaque. When a vendor says “we use AI,” the real question is: whose model, trained on what, hosted where, with what access to your data, and what happens when the model provider changes terms, deprecates a version, or gets compromised? Fourth-party AI risk is real, and most vendor questionnaires never touch it.

Third, regulation now assigns you obligations for AI you didn’t build. Under the EU AI Act, if your organization uses a high-risk AI system, Article 26 puts deployer obligations directly on you — following instructions for use, ensuring human oversight and staff competence, monitoring operation, retaining logs, and reporting serious incidents. The AI Omnibus agreed in May 2026 pushed the Annex III high-risk deadline to December 2027, which is breathing room, not a reprieve. NIS 2 and DORA are applying the same logic to supply chain security generally: you are accountable for what your vendors do.

What buyers are actually testing in 2026

If you sell into enterprises or regulated industries, you’ve already felt this from the other side. Buyer expectations have shifted from trust to verification, and the deal breakers are consistent: no recent penetration test results, missing security fundamentals, no ISO 27001 or equivalent certification, slow or incomplete responses to security questionnaires, and misalignment with the regulatory frameworks the buyer answers to.

Certifications get you in the door. Evidence wins the deal. The vendors closing enterprise contracts fastest are the ones who lead with proof — current pen test reports, accredited certification rather than “aligned with,” and documentation that’s ready to share the day the security review lands. Supplier security has become a revenue function, not just a risk function. That’s the same lens you should apply when you’re the buyer.

Building a vendor management program for the AI era

A modern program has to handle two things the traditional model didn’t: continuous change and AI-specific risk. Here’s the build sequence I use with clients.

1. Inventory everything — including the AI. You can’t govern what you haven’t cataloged. Build a vendor register that captures not just who the vendor is and what data they touch, but whether they use or embed AI in delivering the service, whose models sit underneath, and what your data’s role is in those systems. ISO 42001 makes this concrete: the AI system register under Clause 4 should include third-party AI, not just what you built in-house. Most organizations I audit miss the SaaS-embedded AI entirely.

2. Tier by real risk, not spend. Classify vendors by data sensitivity, access level, operational criticality, and — new for this era — AI impact. A vendor whose AI feature makes or influences decisions about your customers or employees belongs in a higher tier than their invoice size suggests. This is where ISO 42001’s impact assessment thinking (the AISIA) earns its keep: intended purpose, affected population, severity, reversibility, human oversight. Apply that lens to vendor AI, not just your own.

3. Move due diligence from questionnaire to evidence. Stop accepting “yes” as an answer. For your critical tier, require the same things enterprise buyers now require of you: current certifications (ISO 27001, and increasingly ISO 42001 for AI-heavy vendors), recent independent testing, SOC 2 reports, and for AI vendors specifically — model documentation, data handling terms, and incident notification commitments. Under ISO 27001:2022, controls A.5.19 through A.5.22 cover the supplier relationship lifecycle; under ISO 42001, control A.10.3 requires assessing suppliers of AI systems and services. If your vendor security policy hasn’t been updated to reference AI suppliers, it’s a 2022 policy living in a 2026 threat landscape.

4. Put obligations in the contract, not the questionnaire. Questionnaire answers expire the day they’re submitted. Contracts persist. Bake in security requirements, breach and AI-incident notification timelines, audit rights, subprocessor transparency (this is where fourth-party AI risk gets managed), and for EU-relevant AI, allocation of provider and deployer responsibilities under the AI Act. When the regulator asks who was responsible, “we assumed the vendor handled it” is not an answer.

5. Monitor continuously, not annually. The Trivy and LiteLLM attacks would not have been caught by an annual review cycle. Continuous assurance means external attack surface monitoring on critical vendors, tracking certificate status and expirations, watching for vendor breach disclosures, and — for AI suppliers — monitoring for model changes, terms-of-service changes, and deprecations that alter your risk position. This is exactly the shift regulators are codifying: DORA and NIS 2 both expect ongoing oversight, not point-in-time attestation.

6. Plan for vendor failure, because it will happen. Have an exit and containment plan for your critical vendors before you need one. Know how to revoke access fast, what data comes back and how, and what the operational fallback is. Incident response plans that don’t include supply-chain scenarios are incomplete — and ISO 42001’s incident management controls (A.8.4) expect AI-specific scenarios, including incidents originating in third-party models.

My perspective

After two decades of implementing and auditing security programs — most recently taking an AI-forward SaaS platform through ISO 42001 Stage 2 certification — here’s what I’ve come to believe about vendor management.

Most vendor risk programs are theater. A 300-question spreadsheet, answered optimistically by a vendor’s sales engineer, filed in a folder nobody reopens until renewal. That model was weak before AI; it’s indefensible now. The organizations getting this right have made one mental shift: they treat their vendors as an extension of their own attack surface and their own regulatory perimeter, because functionally, that’s what vendors are. The breach data proves it, and the EU AI Act’s deployer obligations make it legally explicit.

The second shift is recognizing that vendor security has flipped from a cost center to a commercial differentiator — in both directions. Run a rigorous program and you avoid becoming the 35%. Maintain rigorous, shareable evidence of your own posture and you close enterprise deals your competitors stall on. The same investment pays twice.

And the third: don’t wait for the AI-specific regulation to fully land before governing AI in your supply chain. The December 2027 high-risk deadline feels distant. It isn’t — not when your remediation path runs through contract renegotiations, vendor replacements, and evidence collection that takes quarters, not weeks. The organizations that treated GDPR as a 2018 problem in 2017 spent that year in triage. The ones building AI vendor governance now, on an ISO 42001 backbone that already integrates with their ISO 27001 ISMS, will spend 2027 selling trust while everyone else is buying consultants in a panic.

Your supply chain already has AI in it. The only question is whether your vendor management program knows that yet.

DISC InfoSec helps B2B SaaS and financial services firms build ISO 27001 and ISO 42001 programs that stand up to enterprise scrutiny and regulatory audit. If you want a straight answer on where your vendor management program stands, book a call: calendly.com/hd-deurainfosec.

AI Attack Surface ScoreCard

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Schedule a consultation: info@deurainfosec.com

InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory | ISO 27k Chat bot | Comprehensive vCISO Services | ISMS Services | AIMS Services | Security Risk Assessment Services | Mergers and Acquisition Security

DISC InfoSec blog | DISC InfoSec Site

Tags: Vendor Management

Jul 09 2026

GDPR Isn’t a Cookie Banner: The Audit Findings That Actually Get Companies Fined

Category: GDPR — disc7 @ 10:44 am

GDPR Isn’t a Cookie Banner: The Audit Findings That Actually Get Companies Fined

Seven years after GDPR took effect, most organizations still treat it like a checkbox they ticked in 2018. They dropped in a cookie banner, published a privacy policy their own lawyers haven’t read since, and moved on. Then a data subject access request lands, or a breach hits, or a regulator comes knocking — and suddenly the gap between “we have a privacy policy” and “we can actually demonstrate compliance” becomes very, very expensive. The uncomfortable truth I keep running into in audits is that GDPR failures rarely look dramatic. They’re not master hackers exfiltrating databases. They’re mundane, systemic gaps that sat quietly in plain sight until the day they didn’t. And with AI now feeding on personal data for marketing, sales, and product decisions, the old gaps have gotten wider and the new ones are appearing faster than most compliance programs can track.

Here’s what I actually find when I open the hood — and, more importantly, how to fix it.

Finding #1: No Defensible Lawful Basis (Especially for AI)

What I find: Organizations collect personal data across forms, chat, analytics, and enrichment tools without a documented lawful basis for each processing activity. When AI enters the picture, this gets worse — data collected for support or account management quietly gets repurposed to train or run marketing models, with no fresh basis and no assessment. “Legitimate interest” is invoked as a magic phrase, but no Legitimate Interest Assessment (LIA) exists to back it up.

Why it matters: Lawful basis is the foundation of the entire regulation. Without it, every downstream activity is built on sand — and repurposing data for AI without a compatible basis is one of the fastest-growing enforcement themes in Europe.

How to remediate: Build a processing inventory that maps each data type to a specific lawful basis. Where you rely on legitimate interest, write the LIA — a genuine three-part balancing test, not a paragraph. For any AI use, treat it as its own processing activity: document the basis for feeding personal data into the model, and never assume that consent for one purpose covers another.

Finding #2: The Privacy Notice Doesn’t Match Reality

What I find: The privacy policy describes a company that stopped existing years ago. It doesn’t mention the AI tools now processing customer data, doesn’t name key processors, and says nothing about profiling or automated decision-making. It’s transparency theater — technically present, functionally useless.

Why it matters: Transparency is a legal obligation, not a courtesy. If you’re using AI to score, segment, or make decisions about people, they have a right to know — in plain language — what’s happening and what it means for them.

How to remediate: Rewrite the notice to reflect current reality. Disclose AI processing explicitly, describe what the AI does with personal data, name your processor categories, and clearly explain any profiling and its likely consequences. Then put a recurring review on the calendar — a privacy notice is a living document, not a monument.

Finding #3: Data Subject Rights Requests Can’t Reach the AI Layer

What I find: The company can pull a record from the CRM when someone files an access or erasure request — but has no idea how to locate that person’s data inside the AI system, its logs, or its training set. Worse, when someone objects to marketing or profiling, the objection updates a flag in one system while the AI keeps processing them unchanged.

Why it matters: Rights that stop at the CRM aren’t rights. “We can’t delete that from the model” is a finding, not an acceptable answer — and an objection that doesn’t actually stop processing is a live violation every day it persists.

How to remediate: Map where personal data flows across every system, including the AI layer and its logs. Build rights fulfillment that propagates: an objection or erasure request must reach — and take effect in — the AI system, not just the primary database. Where model training makes deletion technically hard, document your handling approach in advance rather than improvising under a 30-day clock.

Finding #4: Vendor Contracts and Transfers Left Unmanaged

What I find: Personal data flows to a stack of third parties — AI vendors, ad platforms, analytics, enrichment services — often without signed Article 28 Data Processing Agreements. The AI vendor’s terms are unread, meaning nobody actually knows whether the vendor is training its own models on the company’s data. And data routinely leaves the EEA (frequently via US-based AI providers) with no valid transfer mechanism and no Transfer Impact Assessment.

Why it matters: You remain accountable for personal data even after it leaves your systems. An unread AI vendor contract that permits training on your data can turn your customers’ information into someone else’s product — and undocumented international transfers are a well-established enforcement target.

How to remediate: Inventory every processor and sub-processor. Get signed DPAs in place, and read the AI vendor’s terms specifically for whether your data trains their models — get that prohibited in writing if it isn’t already. For any transfer outside the EEA, confirm a valid mechanism (SCCs or adequacy) and complete a Transfer Impact Assessment for high-risk vendors.

Finding #5: No DPIA for High-Risk Processing

What I find: The organization is doing exactly the kind of large-scale profiling and automated decision-making that makes a Data Protection Impact Assessment mandatory under Article 35 — and no DPIA exists. There’s also no Record of Processing Activities that includes the AI, so when a regulator asks the company to demonstrate compliance, there’s nothing to hand over.

Why it matters: GDPR runs on accountability. It’s not enough to be compliant; you have to be able to prove it. A missing DPIA on high-risk AI processing is both a violation in itself and a signal to any regulator that the deeper controls probably aren’t there either.

How to remediate: Run the DPIA before scaling the AI initiative, not after. Document the processing, the risks to individuals, and the mitigations — and consult your DPO. Update the Article 30 Record of Processing Activities to include the AI. These artifacts are the evidence that turns “we think we’re compliant” into “here’s the file.”

My Perspective

After enough of these audits, a pattern becomes impossible to ignore: GDPR compliance almost never fails on the technology. It fails on the paper trail and the follow-through. The encryption is usually fine. What’s missing is the documented lawful basis, the honest privacy notice, the rights process that actually reaches every system, and the evidence that ties it all together. GDPR is, at its core, an accountability regime — and accountability is exactly the muscle most organizations skipped building.

AI has raised the stakes considerably. The same discipline GDPR has demanded since 2018 — know your data, justify your processing, honor people’s rights, prove it — is now the same discipline that frameworks like ISO 42001 and the EU AI Act demand for AI systems. That’s not a coincidence; it’s convergence. The companies that treated GDPR as a genuine data-governance practice rather than a cookie banner are the ones now absorbing AI governance almost effortlessly. The ones that faked it in 2018 are discovering there’s nothing underneath to build on.

My advice is simple and unglamorous: stop auditing for the banner and start auditing for the evidence. Can you produce your lawful basis, your DPIA, your vendor DPAs, and your rights-fulfillment records on demand? If yes, you’re most of the way there. If not, that gap won’t announce itself — until the day a request, a breach, or a regulator forces it into the open. Fix it while it’s still your choice.

AI Attack Surface ScoreCard

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Schedule a consultation & Feel free to contact DISC InfoSec for a GDPR assessment: info@deurainfosec.com

InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory | ISO 27k Chat bot | Comprehensive vCISO Services | ISMS Services | AIMS Services | Security Risk Assessment Services | Mergers and Acquisition Security

DISC InfoSec blog | DISC InfoSec Site

Tags: Audit Findings, gdpr

Jul 07 2026

ATT&CK vs. ATLAS: Why Securing AI Systems Needs Its Own Playbook

Category: Attack Matrix,Information Security — disc7 @ 1:04 pm

MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) is specifically about attacks on AI and machine learning systems — things like data poisoning, model evasion, model extraction, and prompt injection. It’s modeled on the ATT&CK structure (tactics and techniques) but applied to the AI/ML attack surface. The description in your source looks like it may have been confused with a generic threat-intel sharing platform.

This actually makes for a much stronger post for your audience — because the real distinction between ATT&CK and ATLAS sits right at the intersection of cybersecurity and AI governance, which is your whole positioning. Here’s the blog post built on the accurate framing:

ATT&CK vs. ATLAS: Why Securing AI Systems Needs Its Own Playbook

Every security leader knows MITRE ATT&CK. It’s the shared language we use to describe how adversaries move through our environments — the periodic table of attacker behavior. But fewer people have met its younger sibling, MITRE ATLAS, and that gap is becoming a liability. As organizations rush to deploy AI and machine learning into production, they’re discovering that the attack surface has quietly expanded into territory ATT&CK was never built to cover. If ATT&CK tells you how an adversary breaks into your network, ATLAS tells you how an adversary breaks your model. Understanding the difference isn’t academic — it’s the line between an AI governance program that looks good on paper and one that actually holds up when someone tries to poison your training data.

MITRE ATT&CK: The Map of Adversary Behavior

ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is a globally adopted knowledge base of real-world attacker behavior. It’s organized around the lifecycle of an intrusion — the tactics an adversary uses and the specific techniques under each. The framework walks through the full arc of an attack: Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Exfiltration, and Command and Control.

Its power is that it gives defenders a shared vocabulary. Threat hunters use it to map suspicious activity to known techniques. Incident responders use it to anticipate an attacker’s next move. Red teams use it to structure engagements, and security architects use it to test whether their controls actually cover the techniques they claim to. When someone says “we detected T1566 phishing leading to T1055 process injection,” everyone in the room knows exactly what happened.

MITRE ATLAS: The Map of AI-Specific Threats

ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) borrows ATT&CK’s structure but points it at a different target entirely: machine learning and AI systems. It catalogs the tactics and techniques adversaries use to attack models rather than networks — and these threats behave nothing like traditional intrusions.

ATLAS covers techniques such as data poisoning (corrupting training data so the model learns the wrong things), model evasion (crafting inputs designed to fool a deployed model), model extraction or theft (reconstructing a proprietary model by probing its outputs), membership inference (determining whether specific data was in the training set), and — increasingly relevant in the LLM era — prompt injection and manipulation of generative systems. It’s grounded in real-world case studies of AI systems being attacked, not hypotheticals. Crucially, an attacker doesn’t need to breach your perimeter to exploit many of these; they can attack the model through its legitimate interface.

When to Reach for Each

The two aren’t competitors — they’re complementary layers of the same defensive posture.

Reach for ATT&CK when you’re defending infrastructure, endpoints, identities, and networks: threat hunting, incident response, control validation, and red team planning against conventional adversary behavior. It remains the backbone of any mature SOC.

Reach for ATLAS when AI or ML systems are part of what you’re protecting: threat modeling a model before deployment, assessing the AI-specific attack surface, red teaming a machine learning pipeline, or building an AI risk register. If your organization is deploying models that make or influence decisions, ATLAS is where the relevant threats actually live.

The Overlap Is Where It Gets Interesting

Here’s the nuance most people miss: real attacks on AI systems often chain both. An adversary might use classic ATT&CK techniques to gain access to your training environment, then pivot to ATLAS techniques to poison the data once inside. The perimeter breach is ATT&CK; the model corruption is ATLAS. A defense program that only speaks one language will see half the kill chain and miss the other half entirely. Mature organizations use ATT&CK and ATLAS together, mapping how a traditional intrusion can become the delivery mechanism for an AI-specific attack.

My Perspective

For years, “AI security” was treated as a subset of application security — protect the servers, secure the API, encrypt the data, and you’re covered. ATLAS exists because that assumption is dangerously incomplete. The model itself is now an attack surface, and it fails in ways firewalls and EDR were never designed to catch. A poisoned model can pass every traditional security check and still make catastrophic decisions in production.

This is exactly where cybersecurity and AI governance converge — and why frameworks like ISO 42001 and the NIST AI RMF increasingly point toward AI-specific threat modeling as a core control, not an afterthought. In my own work implementing AI Management Systems, ATLAS has become the natural bridge: it translates abstract AI risk into concrete, testable adversary techniques that a security team can actually assess and mitigate. My advice to security leaders is simple — don’t wait for an incident to discover this gap. If you have models in production and your threat modeling stops at ATT&CK, you have a blind spot the size of your entire AI footprint. Add ATLAS to the toolkit now, while your AI attack surface is still something you can get ahead of rather than something you’re cleaning up after.

AI Attack Surface ScoreCard

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Schedule a consultation: info@deurainfosec.com

InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory | ISO 27k Chat bot | Comprehensive vCISO Services | ISMS Services | AIMS Services | Security Risk Assessment Services | Mergers and Acquisition Security

DISC InfoSec blog | DISC InfoSec Site

Tags: MITRE ATLAS, MITRE ATT&CK

Jul 03 2026

20 State Laws, One Enforcement Standard: Privacy by Design or Pay

Category: Information Privacy,ISO 27k — disc7 @ 10:19 am

Privacy Just Became Infrastructure. Most AI Programs Haven’t Noticed.

By DISC InfoSec

For twenty years, privacy compliance meant disclosure: post a policy, collect consent, answer the occasional access request. That era is over. In 2026, privacy is infrastructure — regulators are testing whether your controls actually work, not whether your privacy notice reads well.

I spend my days implementing management systems for companies where the data can’t leak — financial data rooms, M&A platforms, AI-enabled SaaS. Here’s what the privacy threat landscape actually looks like right now, and what I’d do about it.

In practical terms, it means:

  • Privacy is built into systems by design. Organizations must embed privacy controls into applications, AI systems, cloud platforms, and data architectures from the beginning rather than adding them later.
  • Privacy enables business operations. Just as networking, identity management, and cybersecurity are core infrastructure, privacy has become an essential capability that supports AI, data sharing, digital services, and regulatory compliance.
  • Privacy is a technical and operational discipline. Engineers, architects, security teams, and AI governance professionals are now responsible for implementing privacy-enhancing technologies, data minimization, consent management, encryption, and access controls—not just legal or compliance teams.

For organizations deploying AI, the phrase is especially relevant because regulations and frameworks increasingly require privacy to be integrated into AI governance. This includes conducting privacy impact assessments, limiting unnecessary data collection, protecting personal information, and ensuring transparency and accountability throughout the AI lifecycle.

In short, “Privacy Just Became Infrastructure” means privacy is now a foundational capability that organizations must engineer, manage, and continuously maintain—just like cybersecurity, identity, and cloud infrastructure.

The pressure on industry, in general

The patchwork is now a wall. Twenty US states have comprehensive privacy laws in force. Indiana, Kentucky, and Rhode Island went enforceable this year. California’s updated CCPA regulations now mandate independent cybersecurity audits with certifications filed to the CPPA, and formal risk assessments before any “significant risk” processing begins. Rhode Island carries no cure period — day-one enforcement exposure. If your compliance program was built for one or two state laws, it’s already behind. Compliance is no longer optional or fragmented. The growing number of regulations now creates a comprehensive set of expectations that every organization must address.

Enforcement moved from awareness to action. California imposed its largest CCPA fine to date in 2025, targeting exactly the unglamorous stuff: broken opt-out mechanisms, missing processor contract clauses, notices that don’t match actual processing. California, Colorado, and Connecticut ran a joint sweep on Global Privacy Control compliance. Regulators are no longer reading your policy — they’re testing your website.

The data you forgot about is the data that kills you. The average US breach now costs over $10M. In almost every incident I’ve reviewed, the most damaging records were the ones nobody knew the company still held. No current data inventory means no defensible position — full stop.

Cross-border transfers are a moving target. DOJ’s bulk data transfer rule, Vietnam’s new PDPL, evolving adequacy politics — transfer assessments are now a living exercise, not a one-time SCC signing ceremony.

The pressure in the AI space, specifically

AI didn’t create new privacy principles. It broke every assumption the old controls were built on.

Training data is now a regulated disclosure. California’s AB 2013 requires generative AI developers to publicly summarize the categories and sources of their training data. If you fine-tuned a model on customer data and can’t document what went in, you have a transparency problem with an enforcement hook.

Inference is processing. Every prompt containing customer PII, every RAG pipeline pulling from a CRM, every AI agent reading a mailbox — that’s personal data processing, with all the lawful-basis, minimization, and retention obligations that implies. Most AI inventories I review don’t capture inference-time data flows at all.

Automated decisions are the new high-risk zone. Colorado’s AI Act, Texas TRAIGA, and California’s ADMT regulations converge on the same target: AI making consequential decisions about employment, credit, housing, healthcare. The EU AI Act’s high-risk obligations land in August. If your AI touches a consequential decision and you can’t produce a risk assessment, you’re the test case.

Models remember. Memorization and output leakage mean personal data put into a model can come back out — to a different user, in a different context. “We deleted the source record” doesn’t answer “is it still in the weights?”

Shadow AI is shadow processing. Employees pasting customer data into consumer AI tools is the 2026 version of the rogue file share — except the data leaves your control permanently and may train someone else’s model.

Where ISO 27701:2025 changes the math

Here’s the development most compliance teams haven’t caught up with: ISO 27701 was rebuilt as a standalone standard in October 2025. You no longer need ISO 27001 first — you can implement and certify a Privacy Information Management System (PIMS) on its own, with 78 Annex A controls split across PII controller obligations (A.1), processor obligations (A.2), and shared security controls (A.3). The 2025 edition explicitly added control coverage for cloud, IoT, and AI processing — the standard caught up to the threat landscape.

It also shares the same harmonized structure as ISO 27001:2022 and ISO 42001:2023. That matters practically: if you’re building AI governance and privacy management at the same time — and in 2026, you are — the clause structures interlock. One risk methodology, one internal audit program, one management review. I’ve run that integration play; the overhead savings are real.

One honest caveat, because practitioner credibility requires it: ISO 27701 is not a GDPR safe harbor. Certification doesn’t shield you from enforcement and carries no legal presumption of compliance. What it does provide is the thing regulators actually ask for — demonstrable accountability: a current RoPA, tested data subject rights procedures, documented DPIAs, processor contracts with the right clauses, and evidence behind every control. When the CPPA or a DPA comes asking, “we have a certified, audited PIMS” is a very different conversation than “here’s our privacy policy.”

(Already certified under the 2019 edition? You have until October 2028 to transition. Start scoping now — the control structure changed materially.)

My perspective: the threat is unmanaged processing, not AI

The core privacy threat in 2026 isn’t any single technology. It’s processing that nobody owns, nobody inventoried, and nobody assessed — and AI multiplies the amount of it exponentially. Every remediation path runs through the same discipline:

1. Inventory first. Build a unified data + AI inventory: what personal data you hold, which AI systems touch it, at training and at inference. You cannot protect what you cannot see.

2. Assess before you deploy. DPIAs for every AI system processing personal data, mandatory for anything touching consequential decisions. The EU AI Act, Colorado, and California all converge here — one good assessment process serves all three.

3. Fix the processor chain. Audit your DPAs and sub-processor terms against actual data flows, including AI vendors. Contract gaps are the most-fined, least-fixed problem in privacy.

4. Operationalize rights. Data subject requests must work end-to-end — including data that went into AI systems. Test them like you’d test a DR plan.

5. Put it in a management system. Point-in-time compliance decays. A PIMS under ISO 27701:2025 forces the loop — risk assessment, treatment, internal audit, management review, corrective action — that keeps the program alive between audits.

Privacy by design used to be a slogan. In 2026 it’s the enforcement standard. The organizations that treat privacy as infrastructure will spend less, move faster, and sleep better than the ones still treating it as paperwork.

DISC (CISSP, CISM, ISO 27001 & ISO 42001 Lead Implementer) Consultant at DISC InfoSec, helping B2B SaaS and financial services firms build integrated security, privacy, and AI governance programs — including taking a financial data room platform through ISO 42001 certification. Financial data rooms are the hard mode of compliance; privacy programs built for hard mode work everywhere.

Building or transitioning a PIMS? Start the conversation: info@deurainfosec.com | deurainfosec.com

AI Attack Surface ScoreCard

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Schedule a consultation: info@deurainfosec.com

InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory | ISO 27k Chat bot | Comprehensive vCISO Services | ISMS Services | AIMS Services | Security Risk Assessment Services | Mergers and Acquisition Security

DISC InfoSec blog | DISC InfoSec Site

Tags: ISO 27701, PIMS

Jul 02 2026

Compliance Event vs. Compliance Capability: Why ISO 42001 is How You Actually Meet the EU AI Act

Category: ISO 42001 — disc7 @ 9:50 am

How they relate

The cleanest way to frame it: the EU AI Act defines outcomes; ISO 42001 supplies the machinery to produce them repeatedly. The Act (Regulation (EU) 2024/1689) is enforceable law with fines up to €35M or 7% of global turnover for prohibited practices. ISO 42001 is a voluntary, certifiable management system standard published December 2023. One can’t substitute for the other — an ISO 42001 certificate is not a legal safe harbor, and Act compliance without a management system is a snapshot that decays the moment your AI systems, vendors, or models change.

How they complement each other. The Act tells you a high-risk system needs a risk management system (Art. 9), data governance (Art. 10), technical documentation (Art. 11), logging (Art. 12), human oversight (Art. 14), and — critically — a full quality management system with 13 required components (Art. 17). It doesn’t tell you how to build, document, audit, or continually improve any of that. ISO 42001’s Clause 4–10 PDCA structure and 38 Annex A controls are exactly that operational layer: the AISIA process, the AI system register, the SoA, supplier assessments, internal audit, management review. The Act’s own cross-framework guidance recognizes that ISO 42001 certification can support demonstration of Art. 17 QMS compliance, and the SoA process adapts naturally into an AI Act conformity mapping.

How they depend on each other. The dependency is mostly one-directional. The Act doesn’t need ISO 42001 to exist — but a 42001 AIMS must ingest the Act. Clause 4 (context of the organisation) requires you to identify legal obligations as interested-party requirements, so for any organisation touching the EU market, the AI Act becomes a mandatory input to your AIMS scope, risk assessment, and SoA justifications. Practically: the Act feeds requirements into the AIMS; the AIMS feeds evidence back out for conformity assessment (Arts. 43–48), the EU Declaration of Conformity (Art. 47, retained 10 years), and post-market obligations.

Shared control mapping

EU AI ActRequirementISO 42001Shared control objective
Art. 9Risk management system (lifecycle-spanning)Clause 6.1.2 + A.5.2–A.5.5Continuous AI risk + impact assessment (AISIA) informing control selection
Art. 10Data governance, bias detection, representative datasetsA.7.2–A.7.6Data lifecycle governance: acquisition, quality, provenance, preparation
Art. 11Technical documentation (Annex IV)A.6.2.3, A.6.2.7Documented design decisions, specifications, limitations, failure modes
Art. 12Record-keeping / automatic loggingA.6.2.8Event logs sufficient for incident investigation and audit
Art. 13Transparency + instructions for use to deployersA.8.2, A.9.4Intended-purpose documentation and user-facing system information
Art. 14Human oversight (override, intervene, disregard)A.9.2, A.6.1.3Human review of AI outputs, escalation and override procedures
Art. 15Accuracy, robustness, cybersecurityA.6.2.4, A.6.2.6Pre-deployment V&V (bias/adversarial testing) + production drift monitoring
Art. 17Quality management system (13 components)Clauses 4–10 (entire AIMS)The management system itself — policy, roles, competence, audit, improvement
Art. 26Deployer obligations (competence, monitoring, logs)A.4.6, A.9.2–A.9.3Staff competence, responsible-use processes, use monitoring
Art. 50Transparency (chatbots, synthetic media)A.8.5Informing interested parties they’re interacting with AI
Art. 72Post-market monitoring planClause 9.1, A.6.2.6Ongoing performance evaluation with defined thresholds
Art. 73Serious incident reportingA.8.4, Clause 10.2Incident classification, escalation, regulatory notification, corrective action

Third-party AI in the supply chain is the one area the Act handles thinly relative to 42001 — A.10.2/A.10.3 (responsibility allocation, supplier due diligence with contractual AI clauses) go further than the Act’s provider/deployer split, and they’re what actually protects a deployer who inherits risk from a GPAI vendor.

Where to start

Start with three Act-driven steps that take days, not months, then build the 42001 system underneath:

  1. Role and inventory first. Determine whether you’re a provider or deployer under Art. 3 (most companies are both), and build the AI system register — 42001’s most commonly missed artifact, and the input everything else depends on. Shadow AI and SaaS-embedded AI features count.
  2. Prohibited-practices screen (Art. 5). The 8 original prohibitions have applied since February 2025, and the 9th (nudification/CSAM) lands 2 December 2026. This is the only tier carrying 7%-of-turnover exposure, so screen it before anything else.
  3. Risk-tier classification (Art. 6). Sort your register into prohibited / high-risk / limited / minimal. This tells you how much of the mapping table above actually applies to you.
  4. Then build the AIMS. With classification done, implement ISO 42001 as the delivery vehicle: scope (4.3), AI policy (5.2), AISIA and risk assessment (6.1.2), SoA — with each applicable Annex A control’s justification column citing the AI Act article it discharges. That single move turns your SoA into a living conformity map.

The AI Omnibus (May 2026) extended the Annex III high-risk deadline to 2 December 2027, which changes the calculus in one specific way: you now have time to do this via a management system rather than a panic project. GPAI obligations and Art. 50 transparency deadlines did not move, so those bite first.

My perspective

If I had to compress it: the EU AI Act is a compliance event; ISO 42001 is a compliance capability. Organizations that chase the Act article-by-article end up with a binder of point-in-time evidence that’s stale by the next model update. Organizations that build the AIMS first get Act conformity as a byproduct — plus reusable coverage for NIST AI RMF, Colorado’s AI Act, and whatever jurisdiction regulates next, because the artifacts (register, AISIA, SoA, supplier assessments, incident process) are framework-agnostic at their core.

The honest caveats: 42001 certification is not presumption of conformity — the Art. 40 harmonised standards that would grant that are still in development, and a certificate won’t save a provider whose system fails Art. 15 accuracy requirements in practice. And the Act is scoped to the EU market while 42001 is scoped to your organization, so a pure-42001 approach can under-invest in the Act’s market-facing mechanics: CE marking, EU database registration, the Declaration of Conformity.

So my recommendation is deliberately asymmetric: classify under the Act first (cheap, fast, identifies your real exposure), then invest the bulk of your effort in the 42001 AIMS, wiring every SoA justification to an Act article. The deadline extension to December 2027 is exactly enough runway to do it properly — a Stage 1/Stage 2 certification cycle typically runs 6–12 months, which means starting in 2026 gets you certified with a full surveillance cycle of operating evidence before enforcement begins. Waiting turns a management-system build into a fire drill.

If it’s useful, I can turn this into a blog post and hero image in the DISC brand system, or build out the full Act-to-Annex-A crosswalk as a downloadable gap-assessment worksheet.

AI Attack Surface ScoreCard

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Schedule a consultation: info@deurainfosec.com

InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory | ISO 27k Chat bot | Comprehensive vCISO Services | ISMS Services | AIMS Services | Security Risk Assessment Services | Mergers and Acquisition Security

DISC InfoSec blog | DISC InfoSec Site

Tags: EU AI Act, ISO 42001

Jul 01 2026

The AI RMF Gap Nobody’s Talking About: Why GOVERN-Heavy Programs Still Fail Audits

Category: AI,AI Risk,Risk Assessment — disc7 @ 8:04 am

This is the AI RMF gap assessment, not the checklist version. Most write-ups treat GOVERN, MAP, MEASURE, and MANAGE as four boxes to tick. In practice, the interesting failure isn’t which box is empty — it’s the pattern across the boxes. That pattern is what tells you whether your AI program is actually managing risk or just documenting that it thought about risk once.

The trap: treating AI RMF like a checklist

NIST AI RMF 1.0 is voluntary and non-prescriptive by design. That flexibility is the point — it’s supposed to flex to your context, your risk tolerance, your regulatory exposure. But voluntary frameworks have a predictable failure mode: organizations write the GOVERN policy, feel the box getting checked, and stop.

Nineteen categories across four functions look like a checklist. They’re not. They’re a chain. And chains break at the weakest link, not the first one.

The four functions, in the order risk actually moves through them

FunctionWhat it doesThe practitioner question
GOVERNSets accountability, roles, and risk tolerance — underpins everything elseWho actually owns this when it breaks?
MAPEstablishes context before a system ships — intended use, stakeholders, foreseeable misuseWhat did we assume this AI system would not be used for?
MEASUREApplies quantitative and qualitative tools to assess risk across the lifecycleAre we measuring drift, or just measuring at launch?
MANAGEPrioritizes, resources, and actions the response — then feeds lessons back to GOVERNDoes anything we learn in production change the policy?

Most organizations can point to artifacts for GOVERN. Far fewer can show a MAP document for a specific deployed AI system. Almost none have MEASURE instrumented as an ongoing signal rather than a one-time test.

The gap pattern that actually predicts failure

Here’s the part the generic AI RMF explainer post skips: which combination of strong/weak functions you have tells you why your program is weak, not just that it’s weak.

What we see in the fieldWhat’s really going onWhere to focus first
GOVERN complete, MAP/MEASURE weakPolicy was written, never operationalized against a real systemRun a system-level risk assessment (MAP) on your highest-exposure AI use case — not a hypothetical one
MAP done, MEASURE absentRisk was identified in a workshop, never instrumentedDefine metrics for each identified risk and put monitoring behind them
MEASURE present, no MANAGE actionYou’re collecting data nobody ownsAssign a risk owner and a review date to every metric that’s tracked
Strong technical controls, weak societal-risk viewEngineering-led program with no outside perspectiveBring legal, ethics, or affected-user perspective into MAP 3 and MEASURE 2
No lifecycle coverageOnly deployment gets attentionExtend coverage back to design/development and forward to decommission

If you recognize your organization in the first row — GOVERN strong, everything else thin — that’s not a failed program. That’s a program that stopped at the easiest 20%.

Financial services is the hard mode of AI RMF, not the easy mode

Every AI RMF post talks about bias in hiring algorithms. Financial services has that problem and three others stacked on top of it:

  • Credit decision fairness — disparate impact analysis isn’t optional; it’s tested against the EEOC’s four-fifths rule, and adverse action notices have to be explainable to a person, not just accurate to a model.
  • Explainability under legal obligation — ECOA and CFPB guidance mean MEASURE 2 (“system evaluated for trustworthiness”) isn’t a nice-to-have property, it’s the difference between a defensible decision and a discrimination claim.
  • Fraud model drift — a fraud-detection model that was 94% accurate at launch and hasn’t been re-measured since is a MEASURE 3 gap with a very expensive failure mode.

For a platform handling M&A due diligence or financial data rooms, the stakes compound further: the AI risk profile has to sit on top of an existing confidentiality and access-control posture, not replace it.

Building the profile: current state vs. target state

The mechanism that actually closes gaps is simpler than the framework makes it look:

  1. Scope — pick the AI systems in scope. Not “all AI, eventually.” One system, real and deployed.
  2. Rate current state — for each of the 19 categories: Not Started (0) → Partial (1) → Implemented (2) → Optimized (3).
  3. Set target state — driven by regulatory exposure and risk tolerance, not aspiration.
  4. Gap = Target minus Current. Anywhere that’s positive is where the roadmap lives.
  5. Weight by risk, not by ease. The gap that’s easiest to close isn’t necessarily the one that matters.

Most organizations we assess land at Implementation Tier 1 or 2 — ad hoc or risk-informed. Tier 3 (Repeatable) is the realistic target for a regulated environment. Tier 4 (Adaptive) is for organizations where AI is the product, not a feature.

Why AI RMF pairs with ISO 42001 instead of competing with it

AI RMF is voluntary; it doesn’t get you a certificate. ISO/IEC 42001 does. The two aren’t rival frameworks — AI RMF is the risk methodology; ISO 42001 is the management system that makes it auditable.

Concretely: GOVERN 1 (policies in place) maps to ISO 42001 Clause 5 and Annex A.2. MEASURE 3 (ongoing monitoring) maps to Clause 9.1. If you’re already running an ISMS under ISO 27001, this isn’t a parallel program — it’s an extension with about 70% conceptual overlap and a genuinely new 30% around bias, explainability, and AI-specific incident response.

That’s the sequence that actually gets audited in production: AI RMF gives you the risk logic; ISO 42001 gives you the certifiable structure to prove you’re running it.

The one-sentence version

If your AI governance program can describe its policy but can’t name the owner, the metric, and the last review date for a single deployed AI system — you don’t have a gap in one function. You have a program that only did the part that doesn’t get tested.

Building or auditing an AI risk management program against NIST AI RMF, ISO 42001, or the EU AI Act? That’s the work — happy to talk through where your program actually stands.

AI Attack Surface ScoreCard

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Schedule a consultation: info@deurainfosec.com

InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory | ISO 27k Chat bot | Comprehensive vCISO Services | ISMS Services | AIMS Services | Security Risk Assessment Services | Mergers and Acquisition Security

DISC InfoSec blog

Tags: AI RMF, NIST AI RMF

Next Page »