DISC InfoSec blog

Aug 29 2026

ISO 42001 Evidence Checklist: What Auditors Actually Look For (2026)

Category: AI,Information Security,Internal Audit,ISO 42001 — disc7 @ 3:49 pm

We Built an ISO 42001 Evidence Checklist for AI Companies — Here’s What Auditors Actually Look For

Controls are rarely why organisations fail an ISO 42001 audit. Evidence is…A clause-by-clause evidence checklist, the seven patterns that separate a pass from a finding, and the questions auditors actually ask.

ISO 42001 evidence checklist, ISO 42001 audit, AIMS certification, Stage 2 audit, AISIA, Statement of Applicability, AI system register

Across this series I’ve made the same claim four times, in four different contexts, and it’s time to give it a post of its own:

Controls are almost never why organisations fail. Evidence is.

When I led ShareVault through ISO 42001 Stage 2 certification on the first audit attempt and later served as their internal auditor, the pattern held throughout. The difference between a clean pass and a nonconformity was rarely whether a control existed. It was whether we could put a dated artifact on the table showing that the control operated, on a specific date, under a specific policy version, owned by a named person.

So this post is the checklist I wish more teams had before Stage 1 — organised the way an auditor actually works through it, rather than the way the standard is numbered.

One framing that will save you time. Every control an auditor examines gets tested against four questions:

Does it exist? — the document
Is it operating? — the record showing it ran
Who owns it? — a name, not a team
Show me a specific instance. — one dated example, produced now

Most programs can answer 1. Certification requires all four.

Stage 1 and Stage 2 test different things

This trips people up more than any technical requirement, so it’s worth being explicit.

Stage 1 is a documentation review. The auditor is checking whether your AIMS is designed adequately: does the mandatory documented information exist, is the scope coherent, is the SoA complete, does the risk methodology make sense. You can pass Stage 1 with a management system that has never actually run.

Stage 2 tests whether it operates. Records, not documents. The auditor samples: show me the impact assessment for this AI system, the approval that let it deploy, the monitoring output from last quarter, the internal audit that covered this control, the corrective action that closed that finding.

The single most common failure mode I see is a Stage-1-ready programme presented at Stage 2. Beautiful policies, signed and versioned, with no operating history behind them. If your AIMS was built in the eight weeks before the audit, Stage 2 will find that out — not because the auditor is suspicious, but because records have dates.

Practical implication: your AIMS needs an operating history before Stage 2. Three months is thin. Six is comfortable.

The mandatory documented information

Start here, because these are non-negotiable under Clause 7.5 and their absence is an automatic finding. Nine items:

#	Artifact	Clause	The evidence that makes it real
1	AIMS scope document	4.3	Inclusions, exclusions, and justification for exclusions
2	AI policy	5.2 / A.2.2	Signature of top management, date, version, evidence of communication
3	AI risk assessment records	6.1.2 / 8.2	Executed assessments per AI system, with dates and treatment decisions
4	AI system impact assessment (AISIA) records	6.1.2	One per in-scope AI system, updated on material change
5	Statement of Applicability	6.1.3	All 38 Annex A controls, applicability decision, justification, status
6	AI objectives	6.2	Measurable, with the monitoring record showing measurement happened
7	Internal audit reports	9.2	Audit plan, findings, auditor independence evidence
8	Management review records	9.3	Minutes with decisions and action items, not attendance lists
9	Nonconformity and corrective action records	10.2	Root cause, action, and effectiveness review

Three of these fail more often than the rest.

The SoA (#5) fails when exclusions are justified with something like “not currently a priority.” That is not a justification. A valid exclusion explains why the control is not applicable to your context — typically because you’re an AI user rather than a provider, so provider-specific controls in A.4, A.6.2, and A.7 may genuinely not apply. Write the reason, not the intention.

AI objectives (#6) fail when they’re aspirational. “Improve responsible AI practices” is not measurable. “Complete AISIA for all in-scope AI systems by 30 June,” “100% AI awareness training completion,” “AI incident MTTR under X hours” are. And Clause 9.1 then requires you to show you measured them — the objective without the measurement record is half a finding.

Corrective actions (#9) fail on the last step. Teams log the nonconformity, log the action, and stop. Clause 10.2 requires a review of whether the action was effective. That effectiveness review is the single most commonly missing artifact I encounter, in both 42001 and 27001.

Clause-by-clause: what to have on the table

Clause	What the auditor asks for	Common nonconformity
4.1 Context	Contextual analysis covering AI regulation, public trust, internal AI maturity	Generic corporate context with no AI dimension
4.2 Interested parties	Stakeholder register including individuals affected by AI decisions, regulators, model vendors	Register lists customers and investors only — omits affected individuals
4.3 Scope	AIMS scope document with justified exclusions	AI tools used in HR screening excluded without justification
5.1 Leadership	Management meeting minutes discussing AI governance; resource allocation	Auditor interviews an executive who cannot describe the AIMS scope
5.3 Roles	RACI or roles document naming AIMS owner, AI risk owner, system owners, data governance lead, incident manager	“The security team owns it” — no named individuals
6.1.2 Risk + AISIA	Executed risk assessments and impact assessments per system	AISIA done once at implementation, never revisited
6.1.3 Treatment	Risk treatment plan with owners, timelines, residual risk acceptance	Residual risk not formally accepted by anyone
7.2 Competence	Competence matrix by role, training records, effectiveness evaluation	Training records exist; effectiveness never evaluated
7.3 Awareness	Awareness programme evidence with attendance covering all staff	Attendance list covers a fraction of headcount, no follow-up
8.1 Operation	Change management showing risk/impact reassessment when AI systems changed	Model version changed; no reassessment triggered
9.1 Monitoring	Metrics register or dashboard with actual readings over time	Metrics defined, never populated
9.2 Internal audit	Audit programme, plan covering all clauses over the cycle, reports, independence evidence	Internal auditor audited their own work
9.3 Management review	Minutes covering the full required agenda	Review held, but agenda missed risk assessment results or audit findings
10.2 Improvement	Nonconformity log with root cause and effectiveness review	Effectiveness review absent

A note on 9.2 independence: the auditor cannot audit their own work. In a small company this is a real constraint, and the usual resolutions are to have a different function audit the AIMS, bring in an external internal auditor, or split the audit so no one reviews the area they built. Plan for it early — it’s a structural problem, not a documentation one.

Annex A hot spots

Thirty-eight controls across nine domains, and the failures cluster predictably. The ones I’d stress-test first:

A.2.3 — Alignment with other policies. The AI policy exists, but HR, procurement, IT, and data governance policies were never updated to reflect AI. Auditors check this because it’s a fast test of whether the AIMS is real or bolted on.

A.3.3 — Reporting of concerns. A channel for staff to raise ethical concerns, bias observations, or unexpected AI outputs without reprisal. Most organisations have a security incident channel and assume it covers this. It doesn’t — and the auditor will ask an employee whether they know where to report an AI concern.

A.4.6 / 7.2 — Competence and awareness. AI-specific competency requirements per role, not general security awareness with an AI slide.

A.5.2–A.5.5 — Impact assessment. The process document, the records, and specifically the societal impact dimension (A.5.5), which teams routinely skip because it feels abstract. Environmental cost of compute, systemic bias at scale, labour effects — write something considered, even if brief.

A.6.2.4 / A.6.2.5 — Verification and deployment. Bias and fairness testing across demographic groups, adversarial testing, and a documented go/no-go authorisation before deployment. “We tested it” without a record of the authorisation decision is a finding.

A.6.2.8 — Event logs. AI system logs sufficient for incident investigation and accountability, with defined retention and access controls. See the agent section below — this control has quietly become much harder.

A.7.3 / A.7.5 — Data acquisition and provenance. Legal basis for training data, provenance documentation, chain of custody. If you’re an AI user rather than provider, these may be excluded — but then your SoA justification needs to say so, and A.10.3 supplier evidence has to carry the weight instead.

A.9.2 / A.9.4 — Responsible use and intended use. Acceptable use processes, human oversight of outputs, escalation and override procedures, and enforcement of intended purpose. Use beyond documented intended purpose must be identified and controlled — which is the control that catches shadow AI.

A.10.2 / A.10.3 — Allocation and suppliers. Responsibilities allocated across the AI value chain, supplier tiering, AI-specific due diligence, contractual clauses. Your model provider’s terms are evidence here; go read them before the auditor does.

The seven patterns that separate a pass from a finding

This is the part I’d put on the wall. Any artifact you plan to present should satisfy all seven.

Dated and versioned. An undated document proves nothing about when a control operated. If your version numbering doesn’t track chronology — v1.3 dated before v1.2 — expect a document control finding regardless of content quality.
Signed by the right person. Not just signed. The AI policy needs top management under Clause 5.2. Residual risk acceptance needs the risk owner. An approval signed by whoever was available is a finding waiting to be written.
Shows a decision, not just a document. Auditors distinguish artifacts that record a judgement from artifacts that describe a process. “Our deployment process requires impact assessment” is a document. “Impact assessment for System X, classified Medium, approved for deployment by [name] on [date], with these conditions” is evidence.
Shows the loop closed. Finding → root cause → action → effectiveness review. Three out of four is a nonconformity. This applies to internal audit findings, incidents, and supplier issues alike.
Covers the population, not a convenient sample. If you have eleven AI systems and eight AISIAs, the auditor will find the three. Completeness against the register is the test, which is why the register itself has to be accurate.
Independent where independence is required. Clause 9.2 auditor independence, and — increasingly relevant — separation between whoever operates a control and whoever reviews it.
Producible on request, during the audit. This is the practical one. If retrieving an artifact takes a week of searching shared drives, you have a records problem that will read to the auditor as a control problem. My rule of thumb: any mandatory artifact should be retrievable in under ten minutes by someone who isn’t the person who wrote it.

And the underlying principle, borrowed from control-effectiveness rating practice: a control is not effective because a policy exists. Rate honestly — 0 not implemented, 1 ad hoc, 2 partial, 3 defined, 4 implemented and evidenced, 5 measured and continuously improved. Most organisations sit at 3 and report 4. Stage 2 is where that gap surfaces.

Ten questions to rehearse

Auditors vary, but these come up in some form nearly every time. If you can’t answer one in two sentences with an artifact, that’s your gap list.

Show me your AI system register. Is it complete, and when was it last updated?
Which AI systems are excluded from scope, and why?
Walk me through the impact assessment for this system. Who approved it?
What changed about this system in the last six months, and did that trigger a reassessment?
Who is accountable for this AI system? (The auditor may then go ask that person.)
How does a member of staff raise a concern about an AI system?
Show me your last internal audit report and how the findings were closed.
What AI incidents have you had, and how were they handled?
How do you assess your AI suppliers, and what’s in the contract?
Show me the management review where AI risk was discussed.

Question 5 is the one that most often unravels a program, because auditors follow it up by interviewing the named person. If the RACI says someone owns a system and that person doesn’t know it, the document is evidence against you.

The new gap: agentic systems

This is where the evidence bar has risen fastest, and where checklists written even a year ago fall short. If you run agents, add these:

Agents belong in the AI system register (Clause 4.3, A.6.2.7). Including evaluation, test, and CI agents. As the OpenAI–Hugging Face incident demonstrated, non-production is not low-risk — an evaluation harness with code execution and reachability into shared infrastructure is a high-impact AI system whatever environment it nominally sits in.

A.6.2.8 event logs now have to answer four questions: who authorised this action, what context did the system have, what did it decide, and was that consistent with policy — with the policy version recorded. Agent action volume makes retrofitting this impractical; design it in.

A.9.2 human oversight needs to be demonstrable, not declared. Under EU AI Act Article 14 the standard is a demonstrated capability to intervene, interrupt, and disregard. The corresponding evidence is a tested kill switch with a record of the test and how long it took. An untested kill switch is an assumption, and auditors have started asking.

A.10.3 extends to model providers and MCP servers. Tiering, due diligence, contractual terms including data handling and no-training clauses, and change notification — because a silent model swap underneath you is a change you’re accountable for.

A.6.2.4 verification should include adversarial testing. Prompt injection, tool misuse, privilege escalation, memory poisoning, and approval bypass, with expected denials, version-controlled and re-run on material change.

Five nonconformities I’d bet on finding

If I walked into a first-time AI company audit tomorrow, these are where I’d look first, in order:

Effectiveness reviews missing from corrective actions (Clause 10.2)
AISIA completed once, never updated after material change (Clause 6.1.2)
Objectives defined but never measured (Clause 6.2 into 9.1)
Adjacent policies not updated for AI — HR, procurement, IT (A.2.3)
AI system register incomplete — embedded vendor AI and internal agents missing (Clause 4.3)

None of these require sophisticated controls to fix. All of them require having actually run the management system for a couple of quarters.

Test yourself this afternoon

A genuinely useful exercise that takes about an hour:

Pick three controls at random from your SoA. For each, ask someone who did not build it to produce, within ten minutes: the governing document with its version and date, one dated record showing the control operated in the last quarter, and the name of the person accountable.

Count how many of the nine you get. That number is a better predictor of your Stage 2 outcome than any maturity assessment, and it costs you an hour instead of a certification cycle.

Work with DISC InfoSec

DISC InfoSec helps B2B SaaS and financial services organisations build AI management systems that survive an audit rather than describe one — AIMS scoping, AI system and agent inventories, AISIA methodology, Statement of Applicability, evidence architecture, internal audit, and Stage 1 / Stage 2 readiness.

I led Virtual Data Room (VDR) through ISO 42001 Stage 2 certification on the first audit attempt as the internal practitioner, served as their internal auditor, and authored their MCP Governance Standard. I’ve sat on both sides of the table, which is why this checklist is organised around what gets asked rather than how the standard is numbered.

Readiness path:

Free 15–20 minute readiness call
ISO 42001 gap assessment — | ISO 27001 gap assessment — clause-level, with a prioritised remediation roadmap
Quick-Start engagement, 7–10 days — the core artifact set built and handed over
Full implementation and certification support, including internal audit

DiscInfoSec — Principal Consultant, DISC InfoSec (Deura Information Security Consulting LLC), Petaluma, AICP, CISSP, CISM | ISO/IEC 42001 & ISO/IEC 27001 Lead Implementer | PECB Authorized Training Partner

📅 calendly.com/hd-deurainfosec 📧 info@deurainfosec.com 📞 (707) 998-5164 🌐 deurainfosec.com

This checklist reflects general practice and my own experience as an implementer and internal auditor. Certification bodies and individual auditors vary in emphasis; nothing here substitutes for your own certification body’s guidance or your accredited auditor’s judgement.

References

ISO/IEC 42001:2023 — Clauses 4–10; Annex A (38 controls across A.2–A.10); Annex B implementation guidance
ISO/IEC 42005 (AI system impact assessment guidance); ISO/IEC 23894 (AI risk management)
NIST AI RMF 1.0 (NIST AI 100-1)
Regulation (EU) 2024/1689 (EU AI Act), Arts. 14, 26
OWASP Agentic Security Initiative; OWASP AI Agent Security Cheat Sheet

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

DISC InfoSec blog | DISC InfoSec Site

Tags: ISO 42001 Evidence Checklist

Comments (0)

Aug 28 2026

Agents don’t produce wrong answers anymore They take wrong actions – A practitioner’s guide to agent security

Category: AI Agent,AI Governance,AI Governance Enforcement,AI Guardrails,AI Risk,Information Security — disc7 @ 9:30 am

AI Agent Security: Nobody Authorized That Action, and That’s the Problem

The last two posts in this series ended in the same place from different directions. The one on AI-executable workflows argued that when the convertible tasks leave, what remains valuable is specification, oversight, evidence, boundary judgment, and the signature. The one on Bay Area startups argued that enterprise buyers now ask for those things before they sign.

Agents are where both arguments stop being abstract. A chatbot that gives a bad answer produces a bad answer. An agent that gets manipulated moves money, deletes records, emails your customer list, or opens a pull request. The failure mode changes from wrong output to unauthorized action — and unauthorized action is a category that security, compliance, and legal all have opinions about.

So the organizing question for this post is not “how do I make my agent safe.” It’s the one I keep landing on: when this agent takes an action, can you say who authorized it, what it was allowed to do, and prove it? Everything below is in service of being able to answer that.

Two sources worth reading in full alongside this: the OWASP AI Agent Security Cheat Sheet (CC BY-SA 4.0), which is the best free control catalogue for this problem, and Tigera’s AI Agent Security guide, which is stronger on the infrastructure and identity side. I’m synthesising both here with the governance layer they mostly leave implicit.

Why agents break the model you already have

Three structural shifts, and each one invalidates a control you probably rely on.

Data became instructions. Your input validation assumes data is inert (harmless). For an LLM it isn’t — a retrieved document, an email body, a webpage, a tool response, a Jira comment can all carry instructions the agent will follow. This is indirect prompt injection, and it means every data source your agent touches is now part of its instruction surface. Traditional sanitisation doesn’t help because there’s no syntax to strip; the payload is just words.

The actor is nondeterministic. Access control assumes a caller who does the same thing given the same permissions. An agent’s next action is a probabilistic function of its context, and its context is partly attacker-controllable. You cannot reason about what it will do; you can only bound what it can do.

Identity got separated from a human. Agents authenticate as service accounts, often with credentials broader than any human user, and frequently act on behalf of a user without carrying that user’s authorisation scope. That gap is the confused deputy problem: the agent has authority the requester doesn’t, and the requester can steer the agent. Tigera’s framing is the right one — treat each agent as a first-class managed identity with its own credentials, lifecycle, and decommissioning, rather than a process borrowing someone else’s.

A threat model you can hold in your head

OWASP enumerates thirteen risks and Tigera seven. Overlapping them, I find five clusters more useful for actually designing controls, plus one meta-risk:

Cluster	What it covers	The control that matters most
Instruction integrity	Direct and indirect prompt injection, goal hijacking, malicious configuration fed through developer consoles	Trust boundaries between instructions and data; never let retrieved content carry authority (untrusted data)
Privilege and identity	Over-permissioning, tool abuse, privilege escalation through agent chains, credential theft, confused deputy	Default-deny tool scoping; per-agent cryptographic identity; short-lived scoped tokens
Memory and context	Memory poisoning that persists across sessions or users, sensitive data accumulating in context	Per-user memory isolation, TTL and size limits, integrity checks, redaction before persistence
Egress and exfiltration	Data leaked through tool calls and API requests, denial of wallet from unbounded loops	Egress allowlists, payload inspection, hard limits on tokens, cost, retries, and chain depth
Multi-agent propagation	One compromised agent escalating through others, cascading failure	Signed inter-agent messages with replay protection, trust levels, circuit breakers
Shadow agents (meta)	Agents nobody registered, running with unknown permissions	Discovery and a registry — you cannot control what isn’t inventoried

Note how many of these are authorisation problems wearing AI clothing. That’s deliberate. The genuinely novel risks are instruction integrity and memory poisoning; the rest are old problems whose blast radius grew because the caller is now unpredictable and fast.

The control set, in priority order

1. Default-deny tool scoping

The single highest-leverage control. An agent with a general execute_command tool and wildcard permissions has, in effect, your entire environment as its attack surface. The alternative is narrow, purpose-built tools: read-only where possible, scoped to specific paths or resources, with explicit deny patterns for credential-shaped things (.env, .pem, anything matching secret patterns) and separate tool sets per trust level so a user-facing agent and an internal one never share a registry.

Practical test: for every tool your agent can call, can you state the worst thing that tool can do if the agent is fully adversarial? If the answer requires thinking, the tool is too broad.

2. Separate the decision from the execution

This is the best idea in the OWASP sheet and the one most implementations skip. An approval prompt in the agent’s own loop is not a control — the loop is the thing under attack.

The pattern: the agent proposes an action; an independent policy service validates scope, privilege, and approval state before anything executes. And critically, the approval is bound to the exact action — actor, tool name, target resource, normalised parameters, timestamp, expiry. An approval that says “yes, send the email” and not “yes, send this email to this recipient with this body” can be redirected between approval and execution.

Four details that make the difference between a real gate and a decorative one:

Short-lived authorisation artifacts with replay protection for anything irreversible.
Step-up authentication for critical actions — payment initiation, privilege changes, bulk deletion, production deployment, account recovery.
Idempotency where possible; explicit duplicate confirmation where it isn’t.
Fail closed. If risk classification, policy lookup, approval validation, or audit logging fails, the action does not proceed. A system that executes when logging is down produces exactly the actions you can’t account for.

Risk-tier your actions explicitly — reads and safe queries at the bottom, writes and API calls in the middle, external communication and code execution above that, irreversible and financial operations at the top — and set the auto-approval ceiling per tier rather than per agent. Anything not in the mapping should default to the highest tier, not the lowest.

3. Agents as first-class identities

Unique credentials per agent, issued through your existing IdP or SPIFFE/SPIRE rather than shared secrets. Long-lived API keys replaced by short-lived, tightly scoped, auto-rotated tokens — and in multi-agent flows, a fresh token minted per hop so authority doesn’t accumulate down the chain. Real lifecycle management: created, updated, and decommissioned deliberately, with dormant identities disabled automatically.

The governance payoff is attribution. When actions carry a verifiable agent identity, “who did this” has an answer, and that answer survives an auditor asking it six months later.

4. Memory and context hygiene

Validate before you persist, not after. Scope memory per user and per session so one tenant’s poisoned entry can’t surface in another’s context. Set TTLs and size caps. Redact credential and PII patterns before writing to memory rather than filtering on read. Add integrity checks so tampered entries fail verification instead of quietly steering a future session.

Memory poisoning is the risk most teams haven’t modelled, because it’s the only one where the attack lands in one session and detonates in another. That delay also makes it the hardest to attribute after the fact.

5. Egress control and cost bounds

Agents talk to external services, and that channel is the exfiltration path. Allowlist outbound endpoints, broker calls through a gateway you control so policy is enforced before the request leaves, inspect payloads for sensitive data, and rate-limit. Watch for the exfiltration signatures: unusual encoding in URLs, oversized payloads to webhook or HTTP tools, repeated calls to unfamiliar endpoints.

And set hard ceilings on tokens, cost, retries, and tool-chain depth. Denial of wallet is a real availability-and-budget risk, and unbounded recursion is how a bug becomes an incident with an invoice attached.

6. Adversarial testing as a release gate

Agents should be tested before production and re-tested after any material change — prompts, tools, memory, retrieval, policies, or model provider. Keep a repeatable abuse-case matrix: prompt override, tool misuse, privilege escalation, memory poisoning, data exfiltration, recursive tool abuse, approval bypass, multi-agent chaining. Each with a specific expected denial, version-controlled, running in CI.

One warning from the OWASP sheet deserves repeating verbatim in your review process, because it’s the kind of thing that only occurs to someone who has seen it: review test changes carefully, because an attacker may try to weaken or remove security tests in the same pull request that changes agent behaviour.

The part that turns controls into evidence

Everything above is security engineering. Here’s where it becomes governance — and where, in my experience, the gap between “we have controls” and “we can demonstrate control” gets exposed.

For every high-risk agent action, log structured decision metadata: action classification, risk score where applicable, authorisation outcome, approval identifier, execution result, and policy version. That last field is the one people forget, and it’s the one that lets you answer “what rules were inforce when this happened?” — which is the question that actually gets asked during an incident review.

Then monitor for drift in the oversight layer itself: repeated approval bypass attempts, elevated privilege usage, abnormal tool invocation frequency, sudden increases in high-risk actions, and changes in approval behaviour over time. An oversight mechanism degrades quietly — approvers start rubber-stamping, thresholds get relaxed for a deadline — and nothing alerts you unless you instrument for it.

For production agents, retain validation evidence: the tested agent version, model provider, tool policy and retrieval configuration; the abuse cases executed and their expected results; the approval, denial, timeout, and circuit-breaker behaviour observed; and any accepted residual risk with its compensating control. That last item is what separates a mature program from a hopeful one — mature programs have documented accepted risks, not zero risks.

Where this maps:

Framework	Anchor
ISO/IEC 42001	A.6 (AI system lifecycle), A.9.2 (responsible use), A.10.3 (supplier and value-chain responsibilities), Clause 9.2 (internal audit evidence)
NIST AI RMF 1.0	MAP for context and tool inventory; MEASURE for adversarial testing; MANAGE for monitoring, response, and residual risk
EU AI Act	Art. 14 human oversight as demonstrated capability to intervene, interrupt, and disregard; Art. 26 deployer duties including staff competence, monitoring, incident notification, and log retention of at least six months
ISO/IEC 27001	A.5.15 / A.8.2 for agent authorisation; A.8.16 monitoring; A.5.7 threat intelligence feeding the abuse-case matrix

The overlap is the point. An agent action log built to answer who authorised this, what context did the system have, what did it decide, was that consistent with policy simultaneously serves your incident response, your ISO 42001 internal audit, and an Article 26 request. Build it once.

From the practitioner’s chair

DISC InfoSec audited a client’s MCP Governance Standard and produced a v1.1 redline with 27 changes. Worth being specific about what those changes were, because the distribution is instructive.

They covered OAuth 2.1 with PKCE, token audience validation, SSRF and egress controls, tool manifest integrity, and confused-deputy protections. But the pattern across most of them was the same single idea: authority must be bound to a specific action, not held ambiently by a component. A token that isn’t audience-validated is authority without a destination. A tool manifest without integrity checking is authority without a definition. A confused-deputy gap is authority without a requester. Almost every finding was a variation on authority floating free of the thing it was supposed to authorise.

If you take one design principle from this post, take that one. It generalises further than any specific control in the list above.

The other thing I’d say from the audit chair: the controls are rarely the hard part. When we led VDR through ISO 42001 Stage 2 certification, the difference between passing and a nonconformity was almost never whether a control existed — it was whether we could produce the artifact proving it operated. Agents make that harder, because the volume of actions is high and the actions are taken by something that can’t be interviewed. Design the evidence trail at the same time as the control, or you’ll be reconstructing it under deadline.

Worth a sober note on where the industry actually is: across recent 2026 surveys, roughly a fifth of organisations can automatically terminate a misbehaving agent’s access, and a substantial share of deployed agents run with no security oversight or logging at all. If your kill switch has never been tested end to end, you don’t have one — you have a plan to find out during an incident.

#AIagentsecurity #MCPsecurity #promptinjection #agentleastprivilege #ISO42001agents #EUAIActArticle14 #humanintheloop

Why AI Agents Need Persistent Browser Identities

Five sentences worth putting in a policy

No agent gets a tool whose worst-case use we haven’t written down.
Irreversible actions are validated and authorised by a service the agent does not control, against an approval bound to the exact action.
Every agent has its own identity, its own short-lived credentials, and a decommissioning date.
If classification, policy lookup, approval validation, or audit logging fails, the action does not execute.
Any change to prompts, tools, memory, retrieval, policy, or model provider re-runs the adversarial test suite before release.

Work with DISC InfoSec

DISC InfoSec helps B2B SaaS and financial services organisations deploy AI agents that survive both an attacker and an auditor: agent and tool inventories, MCP and tool-permission review, prompt injection and agent security assessment, human oversight design, and the evidence architecture that maps to ISO/IEC 42001, NIST AI RMF, and EU AI Act Articles 14 and 26.

I led VDR through ISO 42001 Stage 2 certification on the first attempt as the internal practitioner, served as internal auditor, and authored their MCP Governance Standard. If you have agents in production and no clear answer to who authorised that action, that’s the assessment to run now.

DISC InfoSec — | ISO/IEC 42001 & ISO/IEC 27001 Lead Implementer | PECB Authorized Training Partner

📅 calendly.com/hd-deurainfosec 📧 info@deurainfosec.com 📞 (707) 998-5164 🌐 deurainfosec.com

Sources and further reading

OWASP AI Agent Security Cheat Sheet — licensed CC BY-SA 4.0; also the MCP Security, RAG Security, and LLM Prompt Injection Prevention cheat sheets
OWASP Top 10 for Large Language Model Applications
Tigera, AI Agent Security: Top 7 Risks and 4 Types of Security Solutions
NIST AI Risk Management Framework 1.0 (NIST AI 100-1)
ISO/IEC 42001:2023; ISO/IEC 27001:2022 Annex A
Regulation (EU) 2024/1689 (EU AI Act), Arts. 14, 26
Google Secure AI Framework (SAIF)

Tags: agent least privilege, AI Agent Security, AIMS, EU AI Act Article 14, human-in-the-loop, ISO 42001, ISO 42001 agents, prompt Injection

Comments (0)

Aug 25 2026

AI Governance for Bay Area Startups: What to Put in Place Before Enterprise Customers Ask

Category: AI,AI Governance — disc7 @ 9:30 am

AI Governance for Bay Area Startups: What to Put in Place Before Enterprise Customers Ask

There’s a specific email that changes a startup’s quarter. It arrives from a champion who is genuinely on your side, and it reads something like: “Security review went fine, but our AI risk team added a section. Can you send over your AI governance documentation?”

You have a SOC 2. You do not have AI governance documentation. The deal is in the forecast. The quarter closes in five weeks.

I’ve now watched this play out enough times to say it plainly: the AI governance question in enterprise procurement is not coming, it’s here, and the timeline mismatch is brutal. A certifiable management system takes six to eighteen months to build and operate. Procurement does not pause while you build one. The startups that clear this cleanly are the ones that assembled the artifacts before the questionnaire arrived — which, conveniently, is also the cheapest time to do it.

This post is for founders, first security hires, and technical co-founders at Bay Area startups shipping AI features into enterprise accounts. Two things are true for you simultaneously that aren’t true for most companies: your buyers are the enterprises applying the pressure, and your legal address is in the state with the most active AI and privacy regulator in the country.

Why this shifted so fast

Three forces converged in roughly twelve months.

Enterprise procurement rewrote its questionnaires. The 2026 SIG update added an expanded AI governance section; CAIQ picked up AI-specific control mappings. Practically every substantive vendor security questionnaire in the second half of 2026 now contains an AI block. Industry reporting puts “Are you ISO 42001 certified or implementing it?” in roughly 40% of enterprise AI vendor RFPs in the EU and around 25% in North America.

ISO/IEC 42001 became the artifact procurement can file. Published December 2023, it’s the first certifiable international standard for AI management systems. Anthropic certified in January 2025; Snowflake, ServiceNow, CrowdStrike and others followed. More than 350 organisations globally held certificates by mid-2026. The pattern is exactly what SOC 2 did to SaaS procurement a decade ago: a voluntary good practice quietly becoming a default filter that removes vendors who can’t answer.

The EU AI Act’s high-risk obligations landed on 2 August 2026. If you sell into EU-facing customers, their obligations flow contractually back to you regardless of where you’re headquartered — Articles 25 and 26 are the mechanism.

Here’s the part I want to be honest about: your buyer’s AI risk team is not trying to make your life difficult. They’re being asked by their own board, auditors, and insurers to demonstrate control over AI risk. If you can’t answer, the risk transfers to them. That’s why the questions come before signature and not after.

The California layer nobody warns startups about

Bay Area founders tend to think of AI regulation as a Brussels problem. It isn’t. California moved first among US states, and several deadlines have already passed.

Rule	What it reaches	Status
CPPA ADMT regulations (under CCPA/CPRA)	Automated decision-making technology used for significant decisions — employment, housing, credit, healthcare, education	Effective 1 Jan 2026. Risk assessments required now. Consumer rights (pre-use notice, opt-out, access to decision logic) by 1 Jan 2027. First CPPA attestations 1 Apr 2028.
AB 2013	Generative AI training data transparency	Documentation deadline 1 Jan 2026
SB 942 (AI Transparency Act)	Provenance disclosure and detection tooling for GenAI systems with >1M monthly users accessible in California	Operative 2 Aug 2026, further phases 2027–2028
SB 53 (Transparency in Frontier AI Act)	Frontier developers above ~10²⁶ training FLOPs; transparency reports and critical-incident reporting	Effective 1 Jan 2026 — most startups are nowhere near the threshold
AB 489	AI implying licensed healthcare care without human oversight, including in advertising	Effective 1 Jan 2026

One detail in the ADMT rules is worth an architecture conversation, not just a legal one. Advisory tools — systems that produce recommendations, scores, or analysis for a human decision-maker — are explicitly excluded from the ADMT definition, provided there is genuine human involvement in the final decision. CPPA staff testified during rulemaking that this narrowing cut coverage to roughly 10% of CCPA-covered businesses.

That single distinction is one of the highest-leverage design decisions available to an early-stage AI product. A system that informs a human decision and a system that makes it can look nearly identical in the product demo and land in completely different regulatory buckets. Decide which one you’re building deliberately, document the reasoning, and make sure the human involvement is real rather than a rubber-stamp UI. “Genuine” is doing load-bearing work in that sentence, and a regulator will read it the same way an auditor reads “human oversight” under EU AI Act Article 14 — as a demonstrated capability to intervene, override, and disregard.

Standard caveat: I’m a security and governance practitioner, not an attorney. Scoping decisions of this kind should be run past counsel.

The eight artifacts to have on the shelf

None of this requires a compliance team. At startup scale, most of it is a focused week of work plus a habit. Every item below maps to something a questionnaire actually asks and to a clause an auditor will actually test.

1. An AI system inventory

Every AI system you build, embed, or consume — including the ones your team adopted without telling anyone. Vendor-embedded AI counts. Your support tool’s summarisation feature counts. For each: intended purpose, model and provider, data it touches, who it affects, what decision it informs, and whether a human reviews the output.

Anchors: ISO 42001 Clause 4.3 (scope) and the AI system register; NIST AI RMF MAP 1.1. Effort: one afternoon with a spreadsheet, if you’re honest. Why first: you cannot govern, scope, or certify what you haven’t listed, and this is the single artifact that unblocks all seven others.

2. An impact assessment for each material system

ISO 42001’s AI system impact assessment (AISIA) is mandatory under Clause 6.1.2. It asks: intended purpose, output type, impact domain, affected population, severity if it fails, reversibility, and whether human oversight exists. Low / medium / high classification then drives which controls you actually need.

Why it matters commercially: this is the document that lets you answer “how do you assess AI risk?” with a process rather than an adjective. It also does double duty against the CPPA risk assessment requirement and EU AI Act classification questions.

3. A signed AI policy and an acceptable use policy

Two short documents, not a binder. The AI policy states your principles, scope, and objectives, and carries a founder’s signature. The acceptable use policy tells your own team what they may and may not put into which tools — the practical antidote to shadow AI.

Anchors: Clause 5.2, Annex A.2.2 (AI policy), A.9.2 (responsible use processes). Effort: a day to draft, an hour to sign. Please actually sign it; unsigned policies are the most common finding I write.

4. A named accountable owner

One person, not a committee. Someone whose job description includes knowing which AI systems are running, what they can do, and what happens when one misbehaves. At a 30-person company this is usually a technical co-founder or the first security hire, and that’s fine — what matters is that the name is written down.

Anchors: Clause 5.3 (roles and responsibilities); NIST AI RMF GOVERN 1.1 and GV-3. Why buyers care: “who is accountable?” is now a standard questionnaire line, and “the team” is a failing answer.

5. Data provenance and a training-data position

Where does training or fine-tuning data come from, what rights do you have to it, and — the question every enterprise buyer asks — do you or your model providers train on customer data? You need the contractual proof, not just the intention: the no-training clause in your provider’s terms, the configuration that enforces it, and the retention settings.

Anchors: Annex A.7 (data for AI systems); AB 2013 for generative training data disclosure. Effort: mostly reading your own vendor contracts, which is a useful exercise regardless.

6. A model and sub-processor register with real diligence

Every model provider and AI-enabled sub-processor, with what they process, where, under what terms, and what happens if they change models underneath you. Enterprise buyers increasingly want the chain, not just your name.

Anchors: Annex A.10.3 (suppliers, allocation of responsibilities across the AI value chain); NIST AI RMF GOVERN 6. Note: silent model swaps by your provider are a real change-management risk and a question sophisticated buyers now ask directly.

7. Human oversight design — with a kill switch you’ve actually tested

Define, per system, where a human must be in the loop, what the escalation path is, and how you stop the thing. Then test the stop. Kiteworks’ 2026 survey across 459 organisations found only about 21% could automatically terminate a misbehaving agent’s access, and among those running AI in production, 23% had never tested their termination process end to end. Gravitee’s 2026 survey of 900+ practitioners found more than half of deployed agents operating with no security oversight or logging, and 88% of organisations reporting confirmed or suspected agent security incidents in the year.

An oversight mechanism that can’t intervene isn’t a control — it’s a place to assign blame after the fact. Anchors: EU AI Act Art. 14; ISO 42001 human oversight controls; NIST AI RMF MANAGE.

8. Logging that answers four questions

Your AI logs should let you reconstruct: who authorised this, what context did the system have, what did it decide, and was that consistent with policy? If you can’t answer all four from your telemetry, you’re not audit-ready — and if you have EU-facing high-risk exposure, Article 26 obliges deployers to retain logs for at least six months, monitor operation, ensure staff competence, and notify incidents.

The practitioner’s version: when I led ShareVault through ISO 42001 Stage 2 certification, the difference between a clean pass and a nonconformity was almost never whether a control existed. It was whether we could produce the artifact that proved it operated. Controls are cheap. Evidence is the product.

Sequencing for a 20-to-50-person company

Days 1–30 — Get honest. Build the inventory. Draft and sign the AI policy and acceptable use policy. Name the owner. Read your model providers’ data terms and write down your training-data position. This is roughly one focused week spread over a month, and it answers about 60% of a typical AI questionnaire block.

Days 31–60 — Get defensible. Run impact assessments on your two or three material systems. Stand up the sub-processor register. Define human oversight thresholds per system and test the kill switch. Write a one-page AI incident runbook that includes prompt injection and data-leak scenarios — treat a prompt injection event in a regulated context as a compliance event, not just a security ticket.

Days 61–90 — Get ahead of the ask. Turn the artifacts into a reusable answer library and a public trust page section on AI governance. Decide your certification posture: ISO 42001 now, or a documented, dated roadmap. A credible roadmap is an acceptable answer to most buyers today. “We take AI safety seriously” is not.

If you already hold ISO 27001, this is far less work than it sounds — the two standards share the Annex SL High Level Structure, so context, leadership, planning, support, evaluation, and improvement are one system serving two standards. Organisations with a running ISMS typically complete ISO 42001 in a meaningful fraction of the elapsed time.

Three mistakes I’d rather you skip

Chasing the certificate before the inventory. Certification scope is derived from what you actually run. Starting with an auditor conversation before you have a system register means paying someone to discover your own environment.

Buying a platform instead of making decisions. Governance tooling is genuinely useful after you’ve decided who is accountable, what your risk appetite is, and which systems are in scope. Bought first, it becomes an expensive dashboard displaying unresolved questions.

Answering a questionnaire aspirationally. This is the one that actually causes damage. A questionnaire response is a representation to a customer. If you claim a control you can’t evidence and an incident follows, you’ve converted a security problem into a contractual and potentially a misrepresentation problem. When I ran a scanner against a client environment and it produced findings I couldn’t reproduce, I pulled them from the report rather than pad it — same principle applies in reverse here. Say what’s true, say what’s planned, date the plan.

The founder’s advantage

Here’s the thing large enterprises would pay a great deal for and can’t buy: your scope is small. You have four AI systems, not four hundred. You can enumerate every model call in your product in an afternoon. You can get a policy signed by walking across the room. The AI management system that takes a 5,000-person company eighteen months of committee work is, at your stage, a couple of weeks of clear thinking plus a discipline of keeping the register current.

That advantage has a short half-life. Every quarter you grow, the inventory gets harder, the shadow AI gets deeper, and the retrofit gets more expensive. The best time to build this was before your first enterprise deal. The second-best time is before the questionnaire lands in your inbox — which, based on where procurement is heading in 2026, is probably this quarter.

Where to start with DISC InfoSec

DISC InfoSec helps Bay Area B2B SaaS and financial services startups get from “we ship AI features” to “here’s our documented, evidenced AI management system” — without a compliance department. I led ShareVault, a virtual data room platform serving M&A and financial services clients, through ISO 42001 Stage 2 certification on the first audit attempt, as the internal practitioner who did the work.

The readiness path is deliberately incremental:

Free 15–20 minute readiness call — where you actually are, and what the next rung costs.
ISO 42001 gap assessment — | ISO 27001 gap assessment — — clause-level, with a prioritised remediation roadmap.
Quick-Start engagement, 7–10 days — the core artifact set built and handed over.
Full implementation and certification support — including internal audit.

If an AI governance section just showed up in a live deal, start with the call — most of the questions in front of you are answerable faster than you think.

DiscInfoSec— Principal Consultant, DISC InfoSec (Deura Information Security Consulting LLC), Petaluma, CA CISSP, CISM | ISO/IEC 42001 & ISO/IEC 27001 Lead Implementer | PECB Authorized Training Partner

📅 calendly.com/hd-deurainfosec 📧 info@deurainfosec.com 📞 (707) 998-5164 🌐 deurainfosec.com

Sources and references

ISO/IEC 42001:2023 — Clauses 4–10, Annex A (A.2.2, A.7, A.9.2, A.10.3)
NIST AI RMF 1.0 (NIST AI 100-1) — GOVERN 1.1, GV-3, GV-6, MAP 1.1, MANAGE
Regulation (EU) 2024/1689 (EU AI Act) — Arts. 14, 25, 26; high-risk obligations from 2 Aug 2026
CPPA ADMT and risk assessment regulations under CCPA/CPRA (adopted 24 Jul 2025, OAL approved 22 Sep 2025, effective 1 Jan 2026)
California AB 2013, SB 942, SB 53, AB 489
Kiteworks, 2026 Data Security and Compliance Risk Annual Survey (459 organisations)
Gravitee, State of AI Agent Security 2026 (900+ respondents)
Shared Assessments SIG 2026 update; CSA CAIQ AI control mappings

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

DISC InfoSec blog | DISC InfoSec Site

Tags: AI Governance, Bay Area Startups

Comments (0)

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:

Axis	Question	Why it matters
Specifiability	Can success be defined in writing, in advance, without you in the room?	Unspecifiable work can’t be converted — but it also can’t be scaled or defended.
Feasibility	Could a competent model do this alone, given the right context and tools?	This is the raw conversion ceiling.
Reversibility	If it’s done wrong, can the decision be unwound?	A mis-sorted ticket is cheap. A denied credit application, a mis-scoped data room permission, a wrongly redacted disclosure document is not.
Attributability	When it goes wrong, whose name is on it?	This is the axis that survives everything.

The pattern is consistent across the roles I’ve audited:

High specifiability, high feasibility, high reversibility — retrieval, summarisation, first-draft generation, format conversion, control-language mapping, reconciliation against a defined rubric. Convert these now. Defending them is a losing position and, frankly, keeping them is a waste of a professional.
High feasibility, low reversibility — eligibility determinations, access provisioning, disclosure decisions, anything touching a regulated outcome. Convertible in execution, not in authority. The model drafts; a named human owns.
Low specifiability — judgment under conflicting stakeholder interests, negotiating a finding with an auditor, telling a CEO their flagship AI feature isn’t defensible. Not convertible, and the reason is not model capability. It’s that nobody can write down the success criteria in advance, which means nobody can hand over the consequences either.

What remains valuable: five capabilities that survive conversion

1. Specification — turning tacit process into a testable spec

The bottleneck on agentic deployment turns out not to be model capability. Deloitte’s 2026 survey of 3,235 leaders found roughly three-quarters of enterprises expecting to use agentic AI at least moderately within two years, while only about 21% had a mature governance model for autonomous agents. Every credible study lands in the same place: integration, data quality, and decision rights are what stall, not intelligence.

Which means the person who can take an undocumented process living in three people’s heads and render it as an explicit, bounded, testable specification — inputs, tools, permitted actions, escalation thresholds, definition of done — is doing the work that makes conversion possible at all. That skill maps directly to ISO/IEC 42001 Annex A.6 (AI system lifecycle) and A.9.2 (processes for responsible use). It is also the least automatable thing in the building, because it requires knowing which undocumented exceptions actually matter.

2. Oversight design — and the difference between oversight and theatre

Grant Thornton’s 2026 AI Impact Survey found only 5% of organisations allow agents to execute high-stakes decisions without human review. Encouraging, until you check whether the review can actually intervene.

Kiteworks’ 2026 annual survey scored AI governance maturity at 35 out of 100 across 459 organisations — roughly 7 of 19 measured capabilities deployed. Only about 26% restrict AI agents to authorised tasks and data scopes. Only about 21% can automatically terminate a misbehaving agent’s access, and among organisations running AI in production, 23% have never tested their termination process end to end. Gravitee’s 2026 survey of 900+ practitioners found more than half of deployed agents running with no security oversight or logging at all, and 88% of organisations reporting confirmed or suspected agent security incidents in the year.

A human in the loop who cannot actually override, disregard, or halt the system is not a control. It is an accountability sink — a place to put blame with no capacity to prevent harm. EU AI Act Article 14 is explicit on this point: human oversight for high-risk systems means the demonstrated capability to intervene, interrupt, and disregard output. Designing oversight that meets that bar — thresholds, kill switches that have been tested, escalation paths with named owners — is durable, senior, and currently very scarce work.

3. Evidence — proving the workflow behaved

An automated workflow that cannot be reconstructed after the fact is a liability with good throughput. Four questions have to be answerable from your logs: Who authorised this? What context did the system have? What did it decide? Was that consistent with policy?

This is not aspirational. EU AI Act Article 26 obliges deployers of high-risk systems to ensure staff competence, monitor operation, notify incidents, retain logs for at least six months, and inform affected workers. ISO 42001 Clause 9.2 wants internal audit evidence, not intentions. When I led VDR through ISO 42001 Stage 2 certification, the difference between passing on the first attempt and a nonconformity was almost never whether a control existed. It was whether we could produce the artifact that proved it operated.

Evidence production is where AI-executable workflows create more human work, not less — and it’s higher-status work than what it replaced.

4. Boundary judgment — the jagged frontier

The Dell’Acqua field experiment with management consultants remains the cleanest finding in this literature: AI improved performance inside its capability frontier and degraded performance outside it, because people accepted plausible-but-wrong output. Anthropic’s own data shows the largest productivity gains on complex work — where reliability is simultaneously lowest.

That combination defines the residual professional job: knowing where the frontier runs for your domain, and catching the confident failure. It cannot be delegated to the system whose blind spot you are compensating for. It also can’t be learned from a framework — it comes from having done the task manually enough times to feel when an answer is wrong before you can articulate why. Which is exactly what the compression of entry-level work threatens, and why serious firms should be deliberately preserving some manual reps for junior staff even where automation is available.

5. Accountability — the thing that structurally cannot convert

ISO 42001 Clause 5.3 requires assigned roles and responsibilities for the AI management system. NIST AI RMF GOVERN 1.1 and GV-3 require accountability structures and defined roles. EU AI Act Article 4 has required AI literacy across staff since February 2025. Every one of these instruments makes the same structural assumption: a named human being carries the consequence.

You can automate the analysis, the drafting, the monitoring, the reconciliation, and the reporting. You cannot automate the signature. Someone has to be answerable to a regulator, a board, an auditor, a customer whose data was in scope. SAP and Oxford Economics surveyed 2,600 leaders across 13 countries and found 69% either unsure or believing they deploy agents faster than they can govern them. That is not a tooling gap. It’s an unfilled seat.

The self-application test

It would be dishonest to run this analysis on everyone else’s job and not my own. So: consulting is roughly 60% convertible, and I’ve converted most of it.

Drafting gap-assessment language against Annex A controls, mapping ISO 27001 controls to NIST CSF 2.0 subcategories, generating first-pass policy text, building assessment logic, summarising a 200-page vendor security package — all of that runs as workflow now, and my throughput is several times what it was. What did not convert: deciding whether a control is effective rather than present; sitting across from a certification body and defending a scoping decision; telling a client the AI feature they’ve already announced needs an impact assessment before launch; carrying the professional judgment that an audit opinion rests on.

The convertible 60% got faster. The remaining 40% got more valuable, because there is now far more AI in production needing someone to sign for it. That asymmetry is the whole thesis. It holds for me because I owned the accountable end of the workflow before the conversion started. For people who owned only the execution end, the same conversion runs the other direction.

What to do about it this quarter

Run the conversion audit on your own role. Four columns: specifiability, feasibility, reversibility, attributability. Be ruthless about which of your tasks are just well-paid formatting.
Convert your own high-reversibility tasks before someone converts them for you. Owning the automation of your work is a fundamentally different position from being its subject.
Move up the accountability axis deliberately. Get named on something. Own an inventory, an oversight threshold, an internal audit, a supplier assessment under ISO 42001 A.10.3.
Learn to produce evidence, not just outcomes. Logs, artifacts, defensible decision records. This is the skill that converts a technologist into a governance practitioner.
Protect the apprenticeship. If you manage people, do not let AI eat every rep that builds boundary judgment. You are buying throughput today with capability you’ll need in three years.

The uncomfortable summary: a large and growing share of any knowledge job converts into an AI-executable workflow. What remains valuable is not the leftover tasks — it’s the specification, the oversight, the evidence, the boundary judgment, and the signature. Those five things are exactly what AI governance is made of, which is why the governance seat keeps getting more valuable while the execution seat gets cheaper.

AI-executable workflow, AI automation tasks vs jobs, human oversight AI, ISO 42001, NIST AI RMF, EU AI Act Article 14, AI governance career

Work with DISC InfoSec

DISC InfoSec helps B2B SaaS and financial services organisations convert AI adoption into something defensible — AI system inventories, ISO/IEC 42001 AIMS implementation, NIST AI RMF profiles, EU AI Act readiness, human oversight design, and the evidence packages that survive an external audit. I led ShareVault through ISO 42001 Stage 2 certification on the first attempt as an internal practitioner, not a spectator.

If you’re standing up AI-executable workflows and you don’t yet have a clear answer to who is accountable when this acts on its own, that’s the conversation to have now rather than after the incident.

Disc — Principal Consultant, DISC InfoSec CISSP, CISM | ISO 42001 & ISO 27001 Lead Implementer | PECB Authorized Training Partner

📅 Book an appointment: 📧 info@deurainfosec.com 📞 (707) 998-5164 🌐 deurainfosec.com

Sources referenced

Anthropic Economic Index reports (Jan 2026, Mar 2026) and Labor market impacts of AI: A new measure and early evidence
Deloitte, State of Generative AI in the Enterprise 2026 (3,235 leaders, 24 countries)
Grant Thornton, 2026 AI Impact Survey
Kiteworks, 2026 Data Security and Compliance Risk Annual Survey (459 organisations)
Gravitee, State of AI Agent Security 2026 (900+ respondents)
SAP / Oxford Economics, Value of AI Report 2026 (2,600 leaders, 13 countries)
Dell’Acqua et al. (2023), field experiment on AI and consultant performance
ISO/IEC 42001:2023; NIST AI RMF 1.0 (NIST AI 100-1); Regulation (EU) 2024/1689 (EU AI Act), Arts. 4, 14, 26

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

DISC InfoSec blog | DISC InfoSec Site

Tags: AI-Executable Workflow

Comments (0)

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.

Schedule a 15–20 minute AIMS/ISMS readiness discussion — free, 20 min
Free 5-minute risk assessment quiz — free, 5 min
Paid AIMS ISO 42001 gap assessment — $49
Paid ISMS ISO 27001 gap assessment — $59
7–10 day AIMS/ISMS Quick-Start — fixed scope
ISO 42001/27001 AIMS/ISMS implementation — 8–16 weeks
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

DISC InfoSec blog | DISC InfoSec Site

Tags: AIMS, isms, iso 27001, ISO 42001

Comments (0)

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 do	Where it lands in AI governance
Risk register, risk appetite, board reporting	GOVERN (GV-1 to GV-6), ISO 42001 Clause 5 and 6
Asset inventory	AI system inventory — first-party models, LLM features, embedded third-party AI, AI in HR and customer decisions
Business impact analysis	MAP + the AI System Impact Assessment (severity, reversibility, affected population, human oversight)
Control testing and evidence collection	MEASURE — accuracy on data slices, fairness metrics, robustness, explainability
Vendor security assessment	Third-party model risk — training data provenance, retention terms, subprocessor chains
Incident response	MANAGE (MG-3) — AI incident triggers: accuracy degradation, bias threshold breach, jailbreak in the wild, drift
Internal audit	Stage 1 / Stage 2 readiness against ISO 42001

The security-specific slice is the part that genuinely requires new study, and it’s the part that makes you hard to replace: prompt injection and indirect injection through untrusted content, agent privilege boundaries, MCP and tool-invocation security, output handling, and the uncomfortable fact that an instruction file like CLAUDE.md is an advisory control, not an enforced one. Anyone who tells an executive that model-level instructions constitute a control has misunderstood the threat model.

You do not need to become an AI developer to do this work. You need to become the person who can tell an executive whether the AI they just bought is safe, legal, and defensible — and produce the artifact that proves it.

A realistic path in

If you’re coming from security, GRC, audit, privacy, or risk, this is roughly the sequence that works:

Build the inventory skill first. Most organizations underestimate their AI footprint by an order of magnitude. Shadow AI, embedded vendor features, AI in hiring and pricing. Inventory is unglamorous, it’s the mandatory first step in every framework, and almost nobody has done it.
Learn one framework properly, not four superficially. ISO 42001 if your world is certification and enterprise sales. NIST AI RMF if your world is US enterprise risk. They map to each other; pick your entry point.
Add the EU AI Act classification workflow. Provider vs. deployer, prohibited practices screen, risk tier, obligations. This is a repeatable analysis, and executives will pay for a defensible answer.
Get the AI security slice. Prompt injection, agent boundaries, third-party model risk. This is where security backgrounds create separation from the legal-and-policy entrants.
Produce one real artifact. An AI system inventory, an AISIA, a gap assessment with evidence requirements. One completed artifact beats three certifications with nothing behind them.

Certifications help — AIGP, ISO 42001 Lead Implementer or Lead Auditor, stacked on a CISSP or CIPP — but they’re an accelerant, not the substance.

The asymmetry

Both paths involve real work. The difference is what happens to that work over time.

The ability to prompt a model into producing an output is on a curve toward commodity. Every model release erodes the moat, and the tooling is explicitly designed to remove the human from the loop.

The ability to determine whether an AI system is safe, legal, and defensible moves the other way. Every new deployment expands the surface. Every new regulation adds an obligation. Every audit cycle adds an evidence requirement. And critically, the accountability cannot be delegated to the model — a regulator asking “who signed off on this” will not accept “the AI did.”

One of those roles is a commodity in eighteen months. The other one gets more valuable every quarter.

FAQ

Do I need to be able to code to work in AI governance? No, but you need to be technically literate enough to ask a dev team the right questions and recognize a bad answer. The people who struggle in this role are the ones who can only speak policy. The ones who thrive can read an architecture diagram, understand where the model sits in the data flow, and tell you what a prompt injection actually does.

Is ISO 42001 or NIST AI RMF the better starting point? ISO 42001 if you need a certifiable management system — it’s what enterprise customers and procurement teams increasingly ask for. NIST AI RMF if you need a risk framework for internal use without a certification driver. They’re structurally compatible; most mature programs end up running both.

Should a mid-sized company hire a full-time AI governance person? Usually not as the first move. Document the framework, assign an existing owner — typically the person already running security or compliance — and bring in fractional expertise for the assessment and design work. Add headcount when the workload genuinely exceeds what that owner can carry.

How long does this transition take from a security or compliance background? Six to twelve months to be credible, if you’re producing real artifacts along the way. Considerably longer if you’re only collecting credentials.

DISC InfoSec is a boutique AI governance and cybersecurity consultancy in Petaluma, California, serving B2B SaaS and financial services organizations across the North Bay and beyond. We led VDR through ISO 42001 Stage 2 certification on the first audit attempt. If you need to know whether the AI you’ve deployed is safe, legal, and defensible — that’s the assessment we run.

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

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

Comments (0)

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 download Download

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

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

Tags: AI Governance & Cybersecurity

Comments (0)

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:

STRIDE	Threat against the agent	Likelihood	Impact
S — Spoofing	A malicious or typosquatted MCP server registers tools the agent trusts; a poisoned dependency masquerades as a legitimate package	M	H
T — Tampering	Agent modifies its own configuration, hooks, CI definitions, or `.env` files; commits changes no human reviewed	M	H
R — Repudiation	No durable log of which tool calls ran with which arguments; post-incident, nobody can reconstruct what the agent did	H	H
I — Information disclosure	Agent reads `~/.ssh`, `~/.aws`, credential stores, or an entire knowledge base and emits contents into a prompt, a commit, or an outbound request	H	C
D — Denial of service	Unbounded agent loop; destructive deletion of source, database dumps, or infrastructure state	M	C
E — Elevation of privilege	Agent runs under a broad service account and performs actions the invoking human is not authorized to perform	H	C

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:

Control	ISO/IEC 42001	NIST AI RMF	NIST CSF 2.0
Agent inventory, ownership, approved-use policy	Clause 6, Annex A (AI policy, roles, impact assessment)	GOVERN, MAP	GV.OC, ID.AM
Scoped non-human identity, least privilege	Annex A (resources, lifecycle controls)	MANAGE	PR.AA
Deny rules, hooks, sandboxing	Annex A (operational controls)	MANAGE	PR.PS, PR.IR
Tool-call logging and anomaly review	Annex A (monitoring, event logging)	MEASURE, MANAGE	DE.CM, DE.AE
Human approval for irreversible actions	Annex A (human oversight)	MANAGE	GV.RM
Agent incident handling and post-mortem	Annex A (incident management)	MANAGE	RS.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 download Download

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

DISC InfoSec blog | DISC InfoSec Site

Contact DISC InfoSec: info@deurainfosec.com

Comments (0)

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 mindset	Offensive/proactive mindset
Patch vulnerabilities	Actively hunt for vulnerabilities
Monitor alerts	Threat hunt
Respond to attacks	Simulate attacks
Wait for indicators	Search for attacker behavior
Protect the perimeter	Assume the perimeter will be breached
Reduce damage	Find 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 download Download

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

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

Tags: Defensive Security, Offensive security

Comments (0)

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:

Package	Deliverables	Timeline
ISO 27001 / 42001 Gap Assessment	Baseline audit, prioritized roadmap, executive summary	2–4 weeks
SOC 2 Readiness	Gap analysis, controls mapping, evidence checklist	4–6 weeks
Startup Security Program	Policies, risk register, awareness training	3–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 download Download

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

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

Comments (0)

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:

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.
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 download Download

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

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

Tags: Era of AI-Accelerated Discovery, vulnerability management

Comments (0)

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:

Clause	Requirement	What it forces you to produce
4	Context of the organization	ISMS scope, interested parties
5	Leadership	Signed information security policy, defined roles
6	Planning	Risk assessment methodology, risk treatment plan, Statement of Applicability, security objectives
7	Support	Competence records, awareness evidence, document control
8	Operation	Executed risk assessments, treatment evidence, change records
9	Performance evaluation	Metrics, internal audit program, management review minutes
10	Improvement	Nonconformity 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.0	ISO/IEC 27001:2022
Nature	Outcome-oriented, adaptable	Requirements-based, prescriptive on process
Answers	What should we achieve?	How do we govern and prove it?
Structure	6 functions → 22 categories → 106 subcategories	Clauses 4–10 (mandatory) + 93 Annex A controls
Assurance	Self-assessment; no certificate	Accredited third-party certification
Strength	Prioritization, communication, roadmapping	Governance discipline, evidence, continual improvement
Cost to adopt	Free, flexible, fast to start	Fee-bearing, structured, 6–12 months to certify
Weakness	No enforcement mechanism; easy to self-grade generously	Annex 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 area	ISO 27001:2022 anchor
GV.OC — Organizational context	Clauses 4.1, 4.2
GV.RM — Risk management strategy	Clauses 6.1.2, 6.1.3
GV.SC — Supply chain risk	A.5.19–A.5.22
ID.AM — Asset management	A.5.9–A.5.12
ID.RA — Risk assessment	Clause 6.1.2, A.5.7
PR.AA — Identity and access control	A.5.15–A.5.18
PR.DS — Data security	A.5.33, A.8.24
PR.IR — Technology resilience	A.5.29, A.5.30, A.8.6
DE.CM — Continuous monitoring	A.8.15, A.8.16
RS.MA — Incident management	A.5.24–A.5.28
RC.RP — Recovery planning	A.5.29, A.5.30
ID.IM — Improvement	Clauses 9.2, 9.3, 10.1

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

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.
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.
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.
Operate with evidence. Clauses 7–8 make the work produce artifacts as a byproduct rather than as a fire drill before an audit.
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 download Download

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

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

Tags: iso 27001, NIST CSF

Comments (0)

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.

Activity	Who	Cadence	Authority
Vulnerability scanning (OS, web app, DB)	Internal	Monthly minimum; weekly for databases under FedRAMP	RA-5, SI-2
POA&M review and update	Internal	Monthly	CA-5
Ongoing control assessment (rolling subset)	Internal / ISSO	Continuous or quarterly	CA-7
Contingency plan test	Internal	Annual minimum	CP-4
Security awareness and role-based training	Internal	Annual	AT-2, AT-3
Penetration test	Independent	Annual for Moderate and above	CA-8
Full control assessment	Independent assessor / 3PAO	Annual under FedRAMP; otherwise at reauthorization	CA-2
Reauthorization	Authorizing Official	Every 3 years, or continuous authorization	RMF 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:

Control	What drifts	Automate
AC-2, AC-2(3)	Orphaned accounts, stale privileges, inactive accounts past ODV	Daily IdP query against HR system of record
AC-6(7)	Privilege creep after project-based grants	Quarterly automated privileged-access review
CM-6	Configuration baseline deviation	Continuous config scanning (SCAP/XCCDF, CSPM, policy-as-code)
CM-8	Asset inventory divergence	Continuous discovery reconciled against CMDB
CM-3	Undocumented changes	Change records generated from the deployment pipeline
RA-5 / SI-2	Unpatched findings aging past ODV	Scanner-to-ticket integration with SLA clocks
IA-5(1)	Authenticator policy exceptions	Policy-as-code assertion in the IdP
AU-6	Logs collected but never reviewed	Detection content plus documented review cadence
CP-9	Backups running but never restore-tested	Scheduled 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:

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.
Automated validation results. A policy-as-code check that asserts the control condition and emits pass/fail on a schedule.
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.

Control	ODV you assert	The metric that proves it
AC-2(3)	Inactive accounts disabled within 90 days	Max account inactivity age, measured daily
SI-2	Critical flaws remediated within 30 days	Age distribution of open critical findings
AU-11	Audit records retained 3 years	Oldest retrievable record, verified quarterly
CA-7	ConMon assessment frequency: monthly	% of scheduled assessments completed on time
IR-6	Incident reported within [x] hours	Median 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:

Does this change the authorization boundary or introduce a new external interface?
Does this change how data is stored, transmitted, or classified?
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

Cadence	Activities
Continuous	Config drift detection (CM-6), asset discovery (CM-8), account reconciliation (AC-2), log monitoring (AU-6, SI-4), automated control validation
Monthly	Vulnerability 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
Quarterly	Privileged 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)
Annual	Full 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 years	Reauthorization / 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:

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.
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.
Tailoring never documented. Removing a control is legitimate. Removing it without a written scoping rationale is a finding, and a fast one.
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.
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:

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.
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.
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.
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 download Download

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

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

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

Comments (0)

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)

Lens	Best fit
ISO 42001	Flagship. Teams pursuing certification or building a formal AIMS. Your strongest proof point.
EU AI Act	Anyone with EU users or customers; deadline-driven urgency
NIST AI RMF	US teams wanting a framework without a certification commitment
Colorado AI Act / US state	US 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 download Download

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

DISC InfoSec blog | DISC InfoSec Site

Comments (0)

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

DISC InfoSec blog | DISC InfoSec Site

Tags: GRC Engineering

Comments (0)

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

DISC InfoSec blog | DISC InfoSec Site

Comments (0)

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-1 Download 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

DISC InfoSec blog | DISC InfoSec Site

Tags: Lazarus Group, TTPS

Comments (0)

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

DISC InfoSec blog | DISC InfoSec Site

Tags: Vendor Management

Comments (0)

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

DISC InfoSec blog | DISC InfoSec Site

Tags: Audit Findings, gdpr

Comments (0)

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