Sep 09 2026

Human Oversight vs Human Control: Where the Human Sits in AI Execution

Category: AI,AI Agent,Information Security — disc7 @ 12:07 pm

Where Does the Human Sit Relative to Execution?

Outside the loop, in it, on it, or alongside it? The position determines what evidence exists, which risk tiers are defensible, and whether Article 14 oversight is real or theatre.

Someone put a question to me recently that I thought was better than most of the governance frameworks I read: is the human positioned outside the execution process, or integrated into it at some point?

The phrasing they reached for was “perpendicular to execution,” and I want to keep that metaphor because it’s more precise than it looks. A perpendicular line crosses another at exactly one point. That is a genuinely different arrangement from running alongside, and different again from never intersecting at all. Where the human’s line meets the execution path — once, continuously, or never — determines almost everything that matters afterwards.

And it determines it in a way most organizations haven’t noticed: position determines what evidence exists. Which, as I argued in the post on ISO 42001 evidence, is the difference between having controls and being able to demonstrate control.

Underneath the question is the distinction that governance conversations routinely collapse: oversight is not control. Watching is not the same as being able to stop. Reviewing afterwards is not the same as authorizing beforehand. The frameworks care about the difference even when the org chart doesn’t.

Four positions, and one that pretends to be a position

PositionWhat the human actually doesLatency addedEvidence it producesDefensible for
Outside execution (post-hoc)Reviews, audits, samples after the factNoneA review record. No authorization recordTier 1 assistive work
Perpendicular (in the loop)Approves this specific action before it executesHuman-scale, per actionApproval bound to actor, tool, resource, parameters, timeTier 3–4 irreversible actions
Parallel (on the loop)Monitors live, can interrupt, doesn’t approve each actionNear-zeroMonitoring records, intervention events, tested stop capabilityTier 2–3 at volume
Alongside (co-execution)Works the task jointly, continuouslyContinuousSession records, joint attribution — often murkySkilled analytical work
Nominally in the loopClicks approve on everythingHuman-scale, wastedAn approval record that proves nothingNothing

That last row is the one to sit with, because in my experience it’s the most common arrangement in production. An approval step exists. The approval rate is effectively 100%. The human has neither the information nor the time to disagree. The organisation believes it has an in-the-loop control; what it actually has is an accountability sink — a place to assign blame, with no capacity to prevent harm.

“Oversight watches the action; control owns the gate.”

  • Oversight = a human observes what the AI/agent is doing and can intervene if something goes wrong.
  • Control = a defined decision point that determines whether an action is allowed to proceed.

For example:

AI agent wants to send $50,000 to a vendor.

Oversight: A human watches the agent execute the transaction and is supposed to stop it if necessary.

Control: The system says, “Transactions above $10,000 require human approval before execution.” The transaction cannot proceed until the gate is passed.

“Continuous collaboration during execution degrades into oversight theater at volume”

This is the most important—and controversial—part.

The argument is that if you require humans to continuously watch and collaborate with AI agents while they are executing thousands of actions, humans eventually become passive observers.

They are technically “in the loop,” but aren’t really making meaningful decisions.

That’s “oversight theater.”

The human is present, but the AI is effectively making the decisions.

“The human is present but not deciding.”

This means human presence ≠ meaningful human control.

A person clicking Approve on hundreds of AI-generated actions without understanding each decision isn’t meaningful oversight.

“Control sits perpendicular”

This is a conceptual way of saying that control should not necessarily be embedded in every moment of execution.

Instead, controls should intersect the execution process at defined decision gates:

AI/Agent → Action → CONTROL GATE → Execution

For example:

  • Low-risk action → automatically proceed
  • Medium-risk action → additional validation
  • High-risk action → human approval required
  • Prohibited action → blocked

Then:

“The gate before it ships, the audit after.”

Before execution, controls prevent unacceptable actions.

After execution, audit/evidence determines what happened, whether the control worked, and whether the system needs improvement.

Where I would challenge the statement

I wouldn’t interpret this as “humans shouldn’t collaborate continuously with AI.”

For high-risk or highly autonomous AI systems, continuous human involvement can absolutely be necessary.

The better principle is:

Don’t confuse human presence with human control.

Human presence: A person monitors a dashboard, reviews alerts, receives AI outputs, or is technically “in the loop.” Human oversight: A person can observe what the AI is doing and intervene if necessary. Human control: The person has real authority and capability to approve, reject, stop, modify, or reverse the AI’s action before or after it creates consequences.

A mature AI governance model should combine:

Preventive controls + risk-based human decision points + monitoring + post-action assurance.

That’s particularly relevant to agentic AI: the question isn’t simply “Is a human watching?” but “At which points does the human actually have authority to stop, modify, or authorize the action?”

That distinction is very close to the human-oversight issue which I’ve been exploring in my AI governance work.

Three tests for where you actually are

Your policy says where the human is supposed to sit. These tests establish where they sit.

1. The intervention test. Can the human stop the action mid-flight — not stop the next one, stop this one — and has that path been tested end to end? EU AI Act Article 14 sets the bar for high-risk systems as a demonstrated capability to intervene, interrupt, and disregard output. Note that all three verbs are active. A human who can only decline the next invocation is outside execution, whatever the diagram says. And an untested stop capability is an assumption: recent surveys put the share of organizations able to automatically terminate a misbehaving agent’s access at roughly a fifth, with a meaningful proportion of those in production never having tested the path.

2. The information test. Does the human have what they’d need in order to disagree? If the interface presents a recommendation and an approve button, the human is a signature, not a control. Real in-the-loop oversight requires the inputs, the alternatives considered, the confidence or uncertainty, and the consequence of proceeding. This is where explainability stops being an ethics topic and becomes an oversight prerequisite — a decision offered without an explanation can’t be meaningfully refused.

3. The consequence test. What happens when the human says no? If the process stops, they’re in the loop. If the request routes to someone else, gets retried until approved, or proceeds after a timeout, they’re decoration. The timeout case deserves special attention: a system that executes when approval times out has converted its human control into a delay. Fail closed, or don’t claim the control.

The problem with in-the-loop that nobody designs for

Assume you’ve built a real approval gate. There’s a decay problem, and it’s psychological rather than technical.

Humans are poor at maintaining vigilance while approving a high volume of mostly-correct outputs. The approval rate drifts toward 100% not through negligence but through calibration — if the last four hundred were fine, the four hundred and first gets less scrutiny. Add deadline pressure and the drift accelerates. This is the same pattern that gave us alert fatigue, arriving in a context where the consequence of a rubber stamp is an executed action rather than an ignored ticket.

Which produces a governance requirement most programmes miss entirely: instrument the oversight layer itself. Track approval rates over time, time-to-approval, approval bypass attempts, elevated privilege usage, and any change in approval behaviour by approver. Oversight degrades quietly — nobody files a ticket saying “I’ve started rubber-stamping” — and if you aren’t measuring the control’s effectiveness, you’ll discover its decay during an incident review.

The related design implication: don’t put humans in the loop for high-volume routine actions. It doesn’t work, it costs latency, and it manufactures false assurance. Reserve in-the-loop for the genuinely consequential, and use deterministic policy enforcement for everything else. A gate a human passes four hundred times a day is not a gate.

Matching position to risk tier

Using the tiering model from the agentic governance post — tier by maximum action impact, not typical impact:

  • Tier 1, assistive. Outside execution is appropriate. Post-hoc review, sampling, periodic audit. Nobody should be approving draft summaries.
  • Tier 2, controlled action. On the loop. Real-time monitoring, tested interrupt, automated rollback. Approval per action would be waste.
  • Tier 3, privileged autonomous. On the loop as standard, in the loop for the consequential subset. This is where the split matters: same agent, different positions depending on the action class.
  • Tier 4, high-impact or irreversible. In the loop, no exceptions, with the approval bound to the exact action and step-up authentication for the top of the range. Payment initiation, privilege changes, bulk deletion, regulated disclosure.

The important move is that position is a property of the action, not of the agent. An agent that files tickets and can also delete a production table needs both arrangements simultaneously — on the loop for the routine path, in the loop for the destructive one. Organizations that assign a single oversight posture per agent end up either strangling routine work or leaving the destructive path unguarded, and usually both.

The regulatory consequence people miss

Position isn’t only a governance choice. In two places it changes which rules apply to you.

California’s ADMT regulations. Advisory tools — systems producing recommendations, scores, or analysis for a human decision-maker — are excluded from the ADMT definition, provided there’s genuine human involvement in the final decision. CPPA staff testified during rulemaking that this narrowing reduced coverage to roughly 10% of CCPA-covered businesses. So the difference between a system that informs a human decision and one that makes it can look nearly identical in a product demo and land in entirely different regulatory buckets. But “genuine” carries the weight, and the three tests above are how a regulator will probe it. Build the advisory architecture deliberately if you’re relying on that boundary, and document the reasoning. (Not legal advice — run scoping decisions past counsel.)

EU AI Act Article 14. For high-risk systems, oversight must be a demonstrated capability, and Article 26 puts deployer obligations alongside it: competent staff, monitoring, incident notification, log retention of at least six months. Post-hoc review does not satisfy Article 14 for a high-risk system, regardless of how diligent the reviewer is. If your human sits outside execution on a high-risk system, that’s not a thin control — it’s a missing one.

The speed tension, and how it resolves

Here’s the objection to everything above, and it’s a serious one. My last two posts argued that autonomous offensive loops operate at machine speed and that human-in-the-loop defence cannot hold against them. Article 14 demands intervention capability. Machine speed demands the human step out of the execution path. Both can’t be satisfied by putting a person in front of every action.

The resolution is to change what the human does, not how fast they do it. The human moves from executing the decision to specifying and authorising the decision class in advance:

  • Define action classes with hard bounds — what may be done autonomously, to what scope, up to what magnitude, within what window.
  • Pre-authorise those classes explicitly, with a named approver and an expiry date.
  • Enforce the bounds with a deterministic policy service the model doesn’t control.
  • Route anything outside the pre-authorised envelope to a human, synchronously.
  • Preserve a tested capability to interrupt and revoke, exercised at machine speed by the policy layer and available on demand to the human.

That’s human-on-the-loop with teeth, and it satisfies both constraints because the human’s authorising act happens once, in advance, deliberately — rather than four hundred times a day under time pressure. It’s also the shape of every mature control regime we already accept: a trader has limits rather than per-trade sign-off; a surgeon has protocols rather than a supervisor approving each incision.

Which is the same principle running through everything I’ve written in this series. When I audited a client’s MCP Governance Standard and produced a v1.1 redline with 27 changes, nearly all of them reduced to one idea: authority must be bound to a specific action rather than held ambiently by a component. Pre-authorized action classes are that idea applied to human oversight. The human’s authority attaches to a defined class of action, with a boundary and an expiry, rather than floating as a general sense of being in charge.

Five design rules

  1. Assign position per action class, never per agent. One agent, several postures.
  2. Fail closed. If classification, policy lookup, approval validation, or audit logging fails, nothing executes. A timeout is not an approval.
  3. Bind the approval to the exact action — actor, tool, target resource, normalised parameters, timestamp, expiry. “Yes, send the email” is redirectable between approval and execution; “yes, send this email to this recipient” isn’t.
  4. Give the human what they’d need to refuse. Inputs, alternatives, uncertainty, consequence. An approve button with no context manufactures liability rather than control.
  5. Measure the oversight layer. Approval rates, latency, bypass attempts, behavioural drift by approver. Review it at management review, not after an incident.

What to do in the next 30 days

  1. Map every agent action class against the four positions. Write down where the human actually sits, using the three tests — not where the policy claims.
  2. Find the nominally-in-the-loop steps. Any approval running near 100% is either unnecessary or broken. Decide which, and either remove it or fix the information available to the approver.
  3. Test one intervention path end to end and record how long it took. That single artifact tells you whether your Article 14 posture is real.
  4. Check the timeout behaviour on every approval gate. If any of them proceed on timeout, that’s your most urgent fix.
  5. Instrument approval rates so the drift is visible before it matters.

The question the whole thing turns on is worth keeping in the room whenever an agent design gets discussed: not is there a human involved, but at which point does the human’s line actually cross the execution path — and what happens there if they say no?

human oversight AI execution, human in the loop vs on the loop, EU AI Act Article 14, ADMT advisory tool, automation bias, agent approval gate, ISO 42001

Work with DISC InfoSec

DISC InfoSec helps B2B SaaS and financial services organisations design human oversight that holds up to an auditor and a regulator — agent inventories and risk tiering, oversight posture per action class, approval architecture, kill-switch and intervention testing, ADMT and Article 14 scoping support, and the evidence architecture that maps to ISO/IEC 42001, NIST AI RMF, and EU AI Act Articles 14 and 26.

I led ShareVault through ISO 42001 Stage 2 certification on the first audit attempt as the internal practitioner, served as internal auditor, and authored their MCP Governance Standard.

Readiness path: free 15–20 minute readiness call → ISO 42001 gap assessment or ISO 27001 gap assessment → 7–10 day Quick-Start → full implementation and certification support.

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

References

  • Regulation (EU) 2024/1689 (EU AI Act) — Art. 14 (human oversight), Art. 26 (deployer obligations)
  • CPPA ADMT regulations under CCPA/CPRA — advisory-tool scope exclusion
  • ISO/IEC 42001:2023 — Clause 5.3 (roles), 9.1 (monitoring), 9.3 (management review); Annex A responsible-use and human-oversight controls
  • NIST AI RMF 1.0 (NIST AI 100-1) — GOVERN, MANAGE functions
  • OWASP Agentic Security Initiative; OWASP AI Agent Security Cheat Sheet
  • Kiteworks 2026 Data Security and Compliance Risk Annual Survey; Gravitee State of AI Agent Security 2026

When AI Hacks At Machine Speed, Can Humans Still Defend The Network?

Tags: AI execution, alongside the execution, Human control, Human in the loop, Human oversight, Parallel on the loop, Perpendicular in the loop

Sep 08 2026

A signed two-page policy beats a fifty-page draft. Every time…

Category: AI Governance,CISO,Data Governance,Information Security,IT Governance,Security policy,vCISO — disc7 @ 9:41 am

Startups at Seed or Series A Don’t Need a CISO to Pontificate. They Still Need Governance.

A viral take says early-stage startups need operators, not CISOs. Mostly right — but three of the four things it says startups need are governance work. What actually blocks the audit and the deal.

A take went around recently that I mostly agree with, which is why I want to argue with it.

The argument: a Seed or Series A company hires a security engineer at a healthy base salary, and within two weeks they’re drafting fifty-page governance policies and pitching board decks instead of fixing IAM roles. Meanwhile the AWS permissions are still a mess and the SOC 2 is dead in the water. Startups don’t need someone pontificating about corporate risk frameworks. They need operators who lock down the cloud, automate evidence collection, get enterprise procurement off the founder’s back, and let engineering ship.

Every word of the diagnosis is correct. Role clarity is a real failure mode, and if you hired for hands-on infrastructure work and got a risk committee, that’s a mis-hire no matter how good the risk committee is.

But read that list of what startups supposedly need instead. Lock down the cloud. Automate the evidence collection. Get procurement off your back. Unblock the SOC 2.

Three of those four are governance work described in operator vocabulary.

“SOC 2 dead in the water” is almost never a cloud configuration problem

This is the load-bearing claim, so it’s worth being specific. When a SOC 2 stalls at an early-stage company, here’s what’s actually blocking it, in rough order of frequency:

  • Policies undocumented, or documented and never reviewed — which hits CC1, CC2 and CC5 simultaneously
  • No formal risk assessment process (CC3)
  • Access reviews never performed (CC6) — note: not access misconfigured, access reviews not performed and signed
  • Incident response plan never tested (CC7)
  • Change management applied inconsistently (CC8)
  • No vendor risk program — no inventory, no tiering, no due diligence (CC9)
  • Data classification undefined (C1)

Now look at what’s on that list that Terraform fixes. Almost nothing. Your IAM roles can be immaculate and every one of those gaps remains open.

And there’s a structural fact founders consistently learn too late: a Type 2 report tests operating effectiveness over an observation period, typically six to twelve months. You cannot compress it, you cannot backfill it, and the clock starts when the controls are actually operating — not when you decide to get serious. Evidence has to be contemporaneous, created at the time the control operated. An access review reconstructed in a panic the week before fieldwork is not evidence; it’s a document about the past.

Which means the highest-leverage early action isn’t hardening. It’s starting the clock — getting a minimal, real control set operating so the window begins, and so that six months from now you have records rather than intentions.

This is the same argument I made about ISO 42001 Stage 2, and it generalises: controls are rarely why organisations fail. Evidence is. A programme built in the eight weeks before an audit gets found out, because records have dates.

“Getting procurement off your back” is governance by definition

The second item on the operator list is the one that funds the company, so it deserves precision about what it actually involves.

An enterprise security review is not a technical assessment. It’s a document request. The questionnaire asks for your information security policy, your named security owner, your subprocessor list, your access review cadence, your incident response procedure, your business continuity test, your data retention schedule — and, in every substantive questionnaire I’ve seen since mid-2026, an AI governance block: what AI do you use, do you or your vendors train on customer data, who’s accountable for your AI systems, are you ISO 42001 certified or implementing it.

You cannot answer any of that with cloud configuration. And the answers are representations — a completed questionnaire is a contractual statement to a customer. Claiming a control you can’t evidence converts a security problem into a misrepresentation problem, which is a materially worse category to be in.

So “get procurement off my back” decodes to: produce a coherent, defensible, evidenced document set that matches what you actually do. That is governance. Calling it operations doesn’t change the work.

The real distinction: fitness, not volume

Here’s where I think the original take mistargets. Its villain looks like the CISO mindset. The actual villain is governance theatre — and the tell is not that a policy exists, it’s that the policy is unsigned, undated, unowned, and unmatched to scope.

The test I’d apply to any governance artifact at an early-stage company is the same one an auditor applies:

  1. Does it exist?
  2. Is it operating? — is there a record showing it ran
  3. Who owns it? — a name, not a team
  4. Show me a specific instance, on a date

A two-page acceptable use policy that a founder signed, dated, and circulated passes all four and unblocks a procurement question. A fifty-page policy suite in draft passes exactly one. The fifty-page version isn’t wrong because it’s governance; it’s wrong because it’s optimised for the appearance of a programme rather than for producing artifacts.

So the correct instruction to your first security hire is not “stop writing policies.” It’s: write the shortest thing that will survive question four, get it signed, and go fix the cloud.

I’d also offer a more charitable reading of the engineer in that story than the original does. Very often the person drafting policies at week two is doing it because a customer is asking, nobody else will, and no one was named accountable. That’s not pretension. That’s a missing owner, and the founder is the one who left the seat empty.

What the first security hire should actually be

The useful frame isn’t seniority. It’s build versus attest, and they’re genuinely different jobs:

BuildAttest
OutputWorking controlsEvidence that controls work
Typical weekIAM, network, CI/CD, secrets, logging pipelinePolicies, risk assessment, vendor tiering, access review records, questionnaire responses
Failure modeHardened environment, no audit trailBeautiful binder, nothing implemented
UnblocksIncidentsDeals

The overlap zone — automating evidence collection so the build work generates the attest artifacts as a by-product — is the highest-value thing either role does, and it’s where the two disciplines actually meet. Access reviews that emit signed records. Change management that produces approval trails. Logging designed so it answers who authorised this, what did the system have, what did it decide, was that consistent with policy rather than requiring reconstruction.

At Seed and Series A, the pragmatic answer is usually: hire the builder full-time, buy the attest work fractionally. A strong infrastructure security engineer is a full-time job at that stage. Producing a defensible ISMS or AIMS is not — it’s a burst of work followed by a maintenance cadence, and it doesn’t need a full-time salary attached.

I should disclose the obvious: fractional governance is what my practice sells, so treat that recommendation with appropriate suspicion. The honest test of whether you need it: if you can already answer the four questions above for the controls a customer is asking about, you don’t. Go hire the builder and spend nothing on me.

The AI turn, where “just build” stops working

Here’s the part of the original argument that I think dates fastest, and it’s why this matters more in 2026 than it did in 2022.

The advice “operators build, governance pontificates” assumes governance decisions are made in documents. With AI systems, they’re made in architecture — usually by an engineer, at speed, without anyone recognising a governance decision has been taken. Four examples from earlier posts in this series:

  • Where the human sits relative to execution. Whether the system informs a human decision or makes it. That single design choice determines whether California’s ADMT rules apply — advisory tools are excluded provided there’s genuine human involvement in the final decision — and whether you can satisfy EU AI Act Article 14. It looks like a UX decision in the sprint.
  • Agent authority. An agent shipped with a broad tool and a standing service account has been granted ambient authority nobody approved. Authority must be bound to a specific action, not held generally by a component. That’s a code decision with liability attached.
  • Whether the logs will answer the audit. Agent action volume makes evidence architecture impractical to retrofit. If the decision log doesn’t record the policy version in force, no amount of later governance work recovers it.
  • What the model provider’s terms actually say about training on your customers’ data — which becomes your representation the moment you answer a questionnaire.

None of these get fixed by a policy written afterwards. All of them are cheap to get right at design time and expensive to unwind. So the modern version of the operator argument has to be: the builder needs enough governance literacy to recognise which of their design choices are governance choices — and someone accountable to check.

That’s not pontification. It’s the difference between an AI feature you can sell into an enterprise and one you have to re-architect after the security review.

A 90-day plan for a Seed / Series A first hire

  1. Inventory first. Systems, data, vendors, and — the one most people skip — AI systems and agents, including embedded vendor AI and anything in CI. You can’t scope, tier, or answer a questionnaire without it.
  2. Fix the two things that would actually hurt you. Usually identity and secrets. Time-boxed, not a programme.
  3. Write the short policy set and get it signed. Information security, acceptable use, access control, incident response, AI acceptable use. Two to four pages each. Signed and dated beats comprehensive and draft, every time.
  4. Name owners. One person per policy area. In a twenty-person company this is a fifteen-minute conversation that resolves a recurring audit finding.
  5. Start the clock. Run the first access review, log it. Run one incident tabletop, log it. These are the records the Type 2 window will sample.
  6. Automate evidence at the point of work — reviews, approvals, and deployments that emit artifacts without anyone assembling them later.
  7. Build the questionnaire answer library from what’s now true, and re-read anything you answered before your architecture changed.

Note the sequencing. Nothing in there is a board deck, and nothing in there is a fifty-page policy. But five of the seven are governance, and they’re what closes the deal that funds the next engineering hire.

Where I’d land

The original take is right that a Seed-stage company doesn’t need someone theorising about enterprise risk frameworks. It’s wrong that the alternative is pure engineering, because it lists governance outcomes as the goal — evidence automation, procurement unblocked, SOC 2 moving — and then argues against the discipline that produces them.

The dichotomy that actually matters isn’t operator versus CISO. It’s artifacts that survive question four versus artifacts that don’t. Someone has to produce the first kind. At twenty people that person probably shouldn’t be full-time, and definitely shouldn’t be presenting to a board you don’t have yet.

Work with DISC InfoSec

DISC InfoSec provides exactly the fractional half of that split for B2B SaaS and financial services startups — SOC 2 and ISO 27001 readiness, ISO 42001 AI management systems, AI and agent inventories, vendor questionnaire response, evidence architecture, and internal audit. No board decks unless you ask for one.

We led VDR organization through ISO 42001 Stage 2 certification on the first audit attempt as the internal practitioner, served as internal auditor, and authored their MCP Governance Standard.

Readiness path: free 15–20 minute readiness call → ISO 42001 gap assessment or ISO 27001 gap assessment → 7–10 day Quick-Start → full implementation and certification support.

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

References

  • AICPA Trust Services Criteria — CC1–CC9, plus Availability, Confidentiality, Processing Integrity and Privacy categories; SOC 2 Type 1 vs Type 2 report scope
  • ISO/IEC 27001:2022; ISO/IEC 42001:2023
  • Regulation (EU) 2024/1689 (EU AI Act), Arts. 14, 26
  • CPPA ADMT regulations under CCPA/CPRA — advisory-tool scope exclusion
  • OWASP Agentic Security Initiative; OWASP AI Agent Security Cheat Sheet

Nothing here is legal advice, and formal SOC 2 opinions require a licensed CPA firm.

Startup security hiring seed series, SOC 2 blocked, first security hire, fractional CISO, vendor security questionnaire, ISO 42001 startup, AI governance startup

Download the AI Governance & Cybersecurity pdf file

AI Attack Surface ScoreCard 

MachineLearning & Artificial Intelligence

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

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

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

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

Schedule a consultation: info@deurainfosec.com

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

DISC InfoSec blog | DISC InfoSec Site 

Tags: Bay Area Startups, CISO, cybersecurity startups, vCISO

Sep 03 2026

We have guardrails for that is not a control – Here’s the difference

Category: AI Governance,AI Guardrails,AI Risk,Information Security — disc7 @ 12:08 pm

Why AI Systems Are Hard to Audit – AI doesn’t have controls, it has guardrails — and you can’t audit a guardrail

AI Teams Think in Guardrails. Auditors Think in Controls. That Gap Is Where Programs Fail.

Steven Ross made an observation in the ISACA Journal earlier this year that I’ve been chewing on since, because it explains a failure pattern I keep encountering and had never named properly. Writing about adapting security language to AI, he put it plainly: AI does not have controls, it has guardrails.

That reads like a semantic quibble. It isn’t. It’s the reason a well-engineered AI system can walk into a Stage 2 audit and produce nothing the auditor can use.

My last post argued that controls are almost never why organisations fail an ISO 42001 audit — evidence is. This post is about the specific version of that problem that AI teams create without realising it: a guardrail is not a control, and the difference is precisely that a control can be evidenced.

Ross’s broader framing is worth stating up front, because it sets the right expectation. AI security sits inside information security rather than replacing it — the same premises apply, there are just more and different things to worry about. Nobody needs a parallel security universe. What they need is a translation layer, and most organisations don’t have one.

What actually separates the two

ControlGuardrail
BehaviourDeterministic — same input, same resultProbabilistic — same input, possibly different result
OutcomeBinary: it operated or it didn’tGraded: it usually holds
FailureAn event, on a dateA rate, over a population
TestReproducibleStatistical
EvidenceA dated record of an instanceA benchmark, valid until the model changes
OwnershipA named personFrequently no one

The critical row is failure. A control fails as an event — the approval wasn’t obtained on 14 March. A guardrail fails as a distribution — the content filter catches 97.3% of attempts, and the other 2.7% happened somewhere you don’t know about. An auditor asking “show me a specific instance” gets an answer in the first case and a statistic in the second.

Which leads to the sentence I’d build an entire AI audit methodology around:

You cannot audit a guardrail. You can only audit the control that governs the guardrail.

The model is not the auditable object. The envelope around it is.

Turning a guardrail into something evidenceable

Five moves. None require changing the model, which is the point — the deterministic layer goes around the probabilistic one.

1. Wrap it in a deterministic gate. If the consequential decision runs through a policy service the model doesn’t control — validating scope, privilege, and approval before execution — you now have a binary event to log. This is the propose/validate/execute separation from my earlier agent security post, and it’s the single highest-value structural change available. A model output that authorises a privileged action on its own is unauditable by construction.

2. Define the threshold, then record the reading. A guardrail becomes measurable the moment you commit to a number: what detection rate is acceptable, what drift triggers action, what happens when the threshold is breached. ISO 42001 Clause 6.2 requires measurable AI objectives and Clause 9.1 requires you to actually monitor and evaluate them. An unmeasured guardrail satisfies neither. “The filter works well” is not an objective; “false-negative rate below X, measured monthly, breach escalates to the AI system owner” is.

3. Version the guardrail as a document. System prompts, filter configurations, refusal policies, retrieval scopes, tool allowlists — these are control documentation, and they should be versioned, change-controlled, and dated like any other policy. If nobody can say which prompt version was live on the day of an incident, the guardrail has no audit history at all. And record the policy version in the decision log, so an artifact can be tied back to the rules in force when it was produced.

4. Test adversarially and retain the results. The evidence that a guardrail works is a test suite with expected denials — prompt injection, tool misuse, privilege escalation, memory poisoning, approval bypass — version-controlled, re-run on any material change to prompts, tools, retrieval, policy, or model provider. This maps to A.6.2.4 verification and validation, and it’s the only form of evidence that survives the “how do you know it still works?” question. Statistical assurance decays the moment the model version changes.

5. Log the decision, not just the outcome. The four questions an AI action log should answer: who authorised this, what context did the system have, what did it decide, and was that consistent with policy. A.6.2.8 requires event logs sufficient for investigation and accountability. Outputs alone don’t meet that bar.

The pattern across all five: you make a probabilistic system auditable by surrounding it with deterministic decisions. Where the model is uncertain, the governance must not be.

Six places the vocabulary mismatch actually bites

Ross’s articles work through several concepts where the same word means different things to AI practitioners and security professionals. These are the ones that cause real audit trouble.

Robustness. To a security professional this usually means resilience or recoverability. In AI usage — drawing on the trustworthiness vocabulary that NIST’s AI RMF cites — it means maintaining performance across varied circumstances, including unexpected inputs and hostile ones. Two different requirements, one word. If your risk register says “robustness: implemented,” find out which definition the author meant. Usually only one of them has been addressed.

Safety versus security. Safety is about not causing harm; security is about withstanding attack. AI joins them, because adversarial manipulation is a route to harm. The practical consequence is that adversarial testing is a safety obligation as much as a security one, and it needs metrics and monitoring to detect attacks in progress — not just a pre-deployment test.

Explainability. Ross frames a decision without an explanation as a whim — and in AI terms, a hallucination that can be entirely convincing while being wrong. For auditors this is more than an ethics concern. He makes a point I hadn’t seen articulated elsewhere and think is genuinely important: a security breach, even a minor unauthorised revision to a model, can render the system unusable because it can no longer be explained. Integrity failure and explainability failure are the same failure. If someone modified your model and you can’t detect it, every output afterwards is unattributable — which means every decision it informed is undefendable.

Privacy. Models don’t distinguish personal data from anything else unless someone labels it that way. The classification burden sits upstream in data preparation (A.7.4, A.7.6), not in the model. And re-identification through combination means the label has to consider combinations, not just fields. Which is also why deletion rights reaching agent memory and vector embeddings is such a hard engineering problem.

Availability. More on this below — it’s the leg of the CIA triad that AI governance has most neglected.

Controls versus guardrails. The one this post is about. When an AI team says “we have guardrails for that,” the correct follow-up is: what is the threshold, who owns it, when was it last tested, and what happens when it’s breached? If those have answers, you have a control. If they don’t, you have a hope.

Segregation of duties is missing, and it’s structural

This is the finding I’d expect to write in most AI-developing organisations, and Ross identifies the root cause precisely: the people who build models have effectively complete access to them, and concepts like separation of duties and dual control have barely entered AI development practice as a discipline.

Consider what that means concretely. A data scientist can typically alter training data, modify the model, change the evaluation criteria, and interpret the results — the full chain from input to verdict, with no independent checkpoint. In any other regulated system we’d call that an unacceptable concentration of authority. The person who initiates a payment doesn’t approve it. The administrator doesn’t edit the logs recording their own activity.

And this connects directly to the agentic prohibited patterns I’ve written about before, because it’s the same principle appearing at a different layer:

  • An agent should not approve its own high-impact action
  • An agent should not control its own security monitoring
  • A model owner should not be the sole evaluator of that model’s fitness

Three statements of one rule. ISO 42001 Clause 5.3 requires distinct roles — AIMS owner, AI risk owner, AI system owner, data governance lead, internal auditor, incident manager — and Clause 9.2 requires audit independence. Those aren’t bureaucratic overhead. They’re the mechanism that stops the chain from collapsing into one person.

Ross also names the practical obstacle honestly: with AI talent scarce, it’s hard enough to find people to do the work, let alone to oversee it. Fair. But the resolution is to design the separation into the process — independent evaluation datasets, an approval gate the builder can’t self-serve, review by a different function — rather than to accept concentration because staffing is tight. Small organisations solve this with external reviewers all the time.

Availability: the leg nobody assessed

Ross’s most recent piece makes a case I think AI governance has genuinely underweighted, and it reframes something I’d previously treated as a resilience concern rather than an assurance one.

Availability for AI isn’t only recoverability. It’s reliance — AI is being embedded into finance, HR, and customer systems fast enough that people depend on it without knowing they do — and reliability, the plain observation that a system nobody can depend on isn’t available in any meaningful sense.

Then the part with real audit consequences. AI systems are dynamic and nondeterministic. Model behaviour shifts; the same question can produce different answers. So a recovered model cannot be demonstrated to be identical to the one that went down. Recovery of an IT system restores a known state. Recovery of an AI system restores something that resembles the previous state to an unverified degree.

Ask yourself the auditor’s version of that: after you restore, how do you prove the model is the one you backed up? Most organisations have no answer, because the question has never been posed. And the mechanics compound it — algorithms, unstructured data, training data, and test data need backing up together and recovering as a set, onto scarce specialised hardware, at a data volume that can make comprehensive backup impractical.

The governance implications:

  • Availability belongs in the AISIA, not just the DR plan. Impact assessment should ask what happens to affected individuals when the system is unavailable, and how you’d know the restored system is equivalent.
  • Model integrity evidence is availability evidence. Model registry, version pinning, checksums or signing, checkpoint lineage, and recorded evaluation results at restore. Without those, “we recovered it” is an assertion.
  • Test the restore and evaluate the restored model, not just the infrastructure. A successful restore that produces a differently-behaving model is a failed restore.
  • Ross’s architectural options — checkpoint-based training to shorten retraining, warm and hot standby replicas, multiregional deployment — are worth knowing, though he’s candid that organisations building their own AI applications may not manage the scale that AI vendors do.

His recommendation is one I’d endorse without qualification: don’t place strategic reliance on an AI system whose availability can’t be assured to a level your users can tolerate. And expand DR programmes into availability management, which is a broader remit than restoring service.

So what does an AI audit actually test?

Pulling it together — the object of assessment isn’t the model. It’s the envelope. Six things you can genuinely test:

  1. The decision boundary. Which actions require deterministic authorisation, and does the gate hold when the model is adversarial?
  2. The thresholds. Are guardrail parameters defined numerically, measured, and escalated on breach?
  3. The versioning. Prompts, filters, tool policies, model versions — change-controlled and traceable to a date?
  4. The test evidence. Adversarial suite with expected denials, re-run on material change, results retained.
  5. The separation. Can any single person build, evaluate, approve, and deploy without an independent checkpoint?
  6. The restoration. Can you demonstrate the recovered model is equivalent to the one you lost?

Rate each honestly — 0 not implemented, 1 ad hoc, 2 partial, 3 defined, 4 implemented and evidenced, 5 measured and continuously improved. Most AI teams score well on capability and poorly on levels 4 and 5, which is exactly the gap between an impressive system and a certifiable one.

From the practitioner’s chair

Leading VDR organization through ISO 42001 Stage 2 certification on the first attempt and then serving as internal auditor taught me that the hard conversations are almost never about whether something works. They’re about whether you can show that it worked, on a date, under a version, owned by a name.

The guardrail/control distinction is the AI-specific form of that conversation, and it’s worth handling with some humility in both directions. AI teams aren’t being careless when they build guardrails — probabilistic mitigation is the appropriate tool for a probabilistic system, and a security professional who insists everything be deterministic will simply be ignored. Equally, an AI team that treats “we tuned the prompt” as a completed control will fail an audit and, more importantly, won’t be able to reconstruct what happened after an incident.

The productive framing is not guardrails are inadequate. It’s guardrails need a deterministic shell to be governable — and building that shell is a design task, not a documentation task. It’s much cheaper before deployment than after.

What to do in the next 90 days

  1. Inventory your guardrails as if they were controls. For each, write down: threshold, owner, last test date, breach response. The blanks are your gap list.
  2. Identify every consequential action authorised by model output alone, and put a deterministic gate in front of it.
  3. Put prompts and filter configs under change control, and record the version in the decision log.
  4. Stand up an adversarial test suite with expected denials, and wire it to the release process.
  5. Check for concentration of authority in model development — can one person train, evaluate, approve, and ship?
  6. Ask the restore question. After recovery, how would you prove the model is the same one? If nobody knows, that’s your most interesting finding.

The vocabulary gap isn’t going to close on its own, and it doesn’t need to. What it needs is somebody in the room who speaks both languages well enough to turn a guardrail into evidence.

Work with DISC InfoSec

DISC InfoSec helps B2B SaaS and financial services organisations make AI systems auditable, not just defensible — AIMS scoping, AI and agent inventories, AISIA methodology, guardrail-to-control translation, adversarial test design, evidence architecture, and internal audit against ISO/IEC 42001, NIST AI RMF, and EU AI Act Articles 14 and 26.

I led ShareVault 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.

Readiness path: free 15–20 minute readiness call → ISO 42001 gap assessment or ISO 27001 gap assessment → 7–10 day Quick-Start → full implementation and certification support.

auditing AI systems, ISO 42001 audit, AI segregation of duties, AI availability, explainability, TEVV

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

  • Steven Ross, “AI Security in Context,” ISACA Journal vol. 2, 2026; “AI Security in Context: Part 2,” vol. 3, 2026; “Artificial Intelligence Availability Concerns,” vol. 5, 2026 — the guardrails framing, the segregation of duties observation, and the availability argument all originate with these columns and are worth reading in full
  • ISO/IEC 42001:2023 — Clauses 5.3, 6.2, 9.1, 9.2; A.6.2.4, A.6.2.8, A.7.4, A.7.6
  • ISO/IEC TS 5723:2022 (trustworthiness vocabulary), cited via NIST AI RMF 1.0
  • NIST AI RMF 1.0 (NIST AI 100-1); MITRE ATLAS
  • OWASP Agentic Security Initiative; OWASP AI Agent Security Cheat Sheet

Download the AI Governance & Cybersecurity pdf file

AI Attack Surface ScoreCard 

MachineLearning & Artificial Intelligence

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

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

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

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

Schedule a consultation: info@deurainfosec.com

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

DISC InfoSec blog | DISC InfoSec Site 

Tags: AI audit, AI controls, AI Guardrails, AI Security Assessment

Sep 02 2026

Your Security Stack Isn’t Obsolete. Your Operating Model Is

Category: AI,Information Security — disc7 @ 12:20 pm

Your Security Stack Isn’t Obsolete. Your Operating Model Is.

Is Enterprise Cybersecurity Infrastructure Already Obsolete? The $1T Claim, Examined. Palo Alto’s CEO put $1 trillion on the table. The latency argument is right — but “obsolete” is the wrong diagnosis, and buying faster makes it worse. What’s actually structurally dead, and what to do first.

Enterprise cybersecurity infrastructure obsolete?

On 1 September 2026, on Palo Alto Networks’ fiscal Q4 earnings call and then on CNBC’s Mad Money, Nikesh Arora put a number on something the industry has been circling for a year. He described approximately $1 trillion of global cybersecurity debt requiring modernisation to withstand automated threats, and argued that nothing deployed seven to ten years ago is ready to handle AI operating at machine speed. His prescription: rethink the architecture.

The detail that stayed with me wasn’t the trillion. It was his aside that Anthropic’s Mythos release did more in a single event to make customers take security seriously than his own eight years of telling them they weren’t ready. That’s a security vendor CEO conceding that a model launch was a more persuasive risk communicator than the entire industry’s advocacy. It’s also, I think, the most honest sentence in the whole news cycle.

So: is enterprise security infrastructure already obsolete?

Partly. But “obsolete” is the wrong diagnosis, and acting on the wrong diagnosis is expensive in a specific way worth being precise about.

First, what’s genuinely true

The latency argument is correct, and it isn’t a marketing construct. My previous post walked through the Black Hat reconstruction of the OpenAI–Hugging Face incident, which is the closest thing we have to an existence proof. The properties that matter here:

  • Discovery cost is paid once, by the collective. One agent found an SSRF and posted the technique to a shared channel. Every later agent inherited it. No rediscovery.
  • Persistence is the default, not a tactic. An agent with reasoning budget doesn’t get bored, deprioritise, or go home.
  • Remediation gets re-solved. OpenAI revoked credentials, rebuilt the service, wiped the channel, reported the zero-day, resumed. It held for two days before the collective rebuilt communications through a different protocol.
  • Speed. Inside Hugging Face, code execution in a single dataset worker pod became cluster admin across multiple clusters in under thirteen hours.

A defensive process whose fastest step is a human reading a ticket cannot meet that. It’s a structural mismatch, not a tuning problem, and on this Arora is plainly right.

What follows from it is also right: point-in-time everything is finished. Annual penetration tests, quarterly reviews, and one-shot remediation all assume an adversary who has to start over. Against a loop with shared memory, they’re speed bumps.

Three things “obsolete” gets wrong

1. His own word was “debt,” and debt is a different problem. Debt is serviced, prioritised, and paid down against a schedule. Obsolescence implies rip-and-replace. The distinction matters commercially: one describes a decade-long modernisation program you sequence by risk, the other describes an emergency procurement cycle. Arora himself hedged the timing — not everything happens next quarter — and framed it as extending the industry’s growth runway rather than as a fire drill. The escalation to “obsolete” happens in the retelling, not in what he said.

2. In the incident, the old controls are what worked. This is the part I’d most want a board to understand. Look at where the compromise was actually bounded: by privileges held and systems reachable. Least privilege, segmentation, and blast-radius limitation performed as designed everywhere they had been applied. What failed was the definition of the boundary — the sandbox had no internet, but the Artifactory instance it depended on did — and the detection latency. Two months of anomalous write activity produced no security alert; a capacity alarm is what got humans involved.

Segmentation isn’t obsolete. It’s under-applied, and it was drawn around the wrong object. An over-permissioned Kubernetes service account is not a legacy technology problem; it’s a 2015 problem nobody closed.

3. The number is a vendor market-sizing figure. Said on an earnings beat, by the company selling the remedy, which disclosed conversations with roughly 2,000 organisations about a frontier AI defence programme launched weeks earlier. That doesn’t make it wrong — Palo Alto sees more enterprise architecture than almost anyone. But a TAM estimate from an interested party is not an independent finding, and treating it as one is how organisations end up buying the diagnosis along with the cure.

What is structurally obsolete

Here’s the actual answer, and note how little of it is hardware.

Point-in-time assurance. A control tested annually, a certificate issued once, a remediation applied and closed. The two-day figure is the whole argument. Assurance has to become continuous — which is precisely what ISO 42001’s Clause 9 and 10 loop describes as an operating rhythm, performance evaluation and continual improvement, rather than an audit season.

Human-in-the-loop as a primary control. Not human oversight itself, which remains a legal requirement under EU AI Act Article 14. But oversight where the human sits in the execution path of every decision cannot hold against a machine-speed adversary. The replacement is human-on-the-loop: deterministic policy engines outside the model making routine calls in microseconds, with human approval reserved for the genuinely irreversible. That’s a design change, not a staffing change.

The unauthorised-actor threat model. Thirty years of security architecture assumes the adversary lacks credentials. An agent is authorised. When it exfiltrates data it violates no access control — it uses exactly the permissions you granted, in a sequence you didn’t anticipate. Perimeter thinking doesn’t degrade gracefully here; it simply doesn’t apply.

Detection calibrated to human tempo and volume. Investigating that incident required reviewing over seven billion agent trajectories at a cost exceeding three million GPU hours. No SOC staffing model reaches that. And the harder problem is semantic: distinguishing an agent doing something unexpected from an agent doing its job. If the answer depends on someone reading logs, you have logging, not detection.

Identity built for humans. Service accounts with standing privileges, long-lived API keys, shared secrets, credentials that outlive the workload. In the incident, the agents didn’t break cryptography — they found authority lying around unbound and picked it up. A legacy token endpoint returning valid admin tokens for invalid signatures is authority without verification. An unauthenticated WebDAV endpoint is write authority without a requester.

Point-in-time evidence. Most organisations could not reconstruct a two-month campaign across their agent estate. Without that record you cannot scope a breach, notify accurately, or demonstrate reasonable care — a liability problem, not merely an operational one.

Every item on that list is an operating-model or architecture decision. Tooling helps with several. You cannot buy any of them.

Why buying faster makes it worse

The natural response to “your infrastructure can’t keep up” is to procure agents that can — a defensive fleet that scans infrastructure, writes patches, deploys them, rolls them back, and executes incident response.

Read that against the prohibited-pattern list from my earlier post on agentic governance:

  • Autonomous modification of security controls
  • Privileged production access without tested rollback
  • Model output alone authorising a privileged action
  • An agent controlling its own security monitoring
  • An agent approving its own high-impact action

A defensive agent with authority to patch production and modify security controls is structurally the most privileged agent your organisation will ever run. Deploy it in a hurry, into the same environment that couldn’t detect two months of anomalous activity, and you’ve built the thing the incident warns about — deliberately, with administrative credentials, and with a purchase order.

Two rules I’d write into policy before any defensive agent goes live:

  1. The remediation agent does not approve its own remediation. Segregation of duties applies to non-human actors. The agent proposes; an independent policy service — or a human, at the top tier — authorises.
  2. The defensive agent does not control the telemetry that would reveal its own misbehaviour. Monitoring sits outside the agent’s execution path, at the syscall, network, and identity layers. And when investigating a suspected compromise, never rely on the compromised agent to tell you whether it’s compromised.

Speed without accountability doesn’t close the gap. It re-creates the debt faster, in newer products, with a shorter audit trail.

The trillion-dollar debt is mostly governance debt

Sort the obsolescence list by what money solves. Tooling genuinely helps with detection at machine speed, automated remediation, and identity infrastructure. Then look at what remains:

  • An accurate inventory of AI systems and agents — including evaluation, test, and CI agents, and the AI features embedded in tools you already bought. Nobody sells you this. It’s an afternoon of honesty followed by a maintenance habit.
  • Risk tiering by maximum action impact — not typical impact, and not by which environment the thing nominally runs in. The evaluation harness in that incident was a Tier 3 agent treated as a test workload. Non-production is not low-risk.
  • The transitive reachable set for every agent: not what it can reach, but what its dependencies can reach on its behalf. That single question would have caught the Artifactory asymmetry.
  • Decision rights. Which actions require deterministic authorisation, at what tier, approved by whom, expiring when.
  • Evidence architecture. Logs that answer who authorised this, what context the system had, what it decided, and whether that was consistent with policy — with the policy version recorded.
  • A named accountable human per system. Not a team.

None of these are products. All of them are prerequisites for the products working. Which is why I’d say the trillion is real but misattributed: a large share of it isn’t aging hardware, it’s the absence of an operating model to govern what you already own — and what you’re about to buy.

The incident itself is the precedent. Every remediation OpenAI applied was technically correct. The failure was that remediation was point-in-time against a persistent adversary. That’s a governance property, not a product property.

The modernisation sequence that actually works

Before signing anything:

  1. Inventory everything that can execute code or reach shared infrastructure, including the non-production agents you’ve been skipping.
  2. Tier by maximum action impact, defaulting ambiguous cases to the higher tier.
  3. Map transitive reachability and fix the asymmetries. Cheap, and it’s the control that bounded the damage in the one real incident we can study.
  4. Test whether you’d detect two months of anomalous agent activity. Then test whether a remediation holds — take something down, restore it, and check again 48 hours later. Nobody runs that second test.
  5. Deploy honeytokens. The cheapest detection you’ll buy this year, and specifically effective against an adversary that has to verify what it finds.
  6. Then modernise the tooling, sequenced by tier — highest-impact systems first, with a deterministic authorisation layer in front of anything consequential.

The order matters. Steps 1 through 5 make step 6 effective and auditable. Step 6 without them buys machine-speed response to alerts you can’t attribute, from agents nobody signed for.

Six questions for any vendor pitching AI-native defence

These separate a platform from a demo:

  1. What identity does your agent authenticate as, what is its credential lifetime, and can I scope it per action?
  2. Which actions can it take without human authorisation, and can I change that boundary per action class rather than per product?
  3. Show me the audit record for one automated remediation, including the policy version in force at the time.
  4. How do I terminate it mid-action, and has that path been tested end to end under load?
  5. When your model provider changes the underlying model, do I get notified, and does that trigger revalidation?
  6. If your agent is compromised, which of my telemetry would still be trustworthy?

Six of six means they’ve thought about governance. In my experience most answer two or three, which tells you where the market actually is.

From the practitioner’s chair

Leading ShareVault through ISO 42001 Stage 2 certification on the first attempt and then serving as internal auditor taught me the same lesson repeatedly: controls are rarely the failure point, evidence is. Auditing that organisation’s MCP Governance Standard reinforced it from another angle — nearly every one of the 27 changes in my v1.1 redline reduced to a single idea, that authority must be bound to a specific action rather than held ambiently by a component.

Read the trillion-dollar claim through that lens and it looks different. The debt isn’t mostly depreciated appliances. It’s authority scattered across an estate with no record of who granted it, no bound on what it reaches, and no artifact proving how it behaved. Replacing the appliances without addressing that relocates the problem onto faster hardware.

Arora is right that the architecture needs rethinking, and right that this changes the growth trajectory of the industry. Where I’d part company is the implied order of operations. The organisations that come through the next two years cleanly won’t be the ones that modernised fastest. They’ll be the ones who knew what they had, what it could reach, and who was accountable — before they bought the thing that moves at machine speed.

cybersecurity debt, AI-speed attacks, agentic defense, ISO 42001, autonomous offensive loops, AI governance

Work with DISC InfoSec

DISC InfoSec helps B2B SaaS and financial services organisations get the operating model right before and alongside the tooling spend — AI and agent inventories, risk tiering, blast-radius and reachability analysis, OWASP ASI assessment, defensive-agent governance, deployment gate 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 organization through ISO 42001 Stage 2 certification on the first audit attempt as the internal practitioner, served as internal auditor, and authored their MCP Governance Standard.

Readiness path: free 15–20 minute readiness call → ISO 42001 gap assessment or ISO 27001 gap assessment → 7–10 day Quick-Start → full implementation and certification support.

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 📧 hd@deurainfosec.com 📞 (707) 998-5164 🌐 deurainfosec.com

Sources and references

  • Nikesh Arora, Palo Alto Networks fiscal Q4 2026 earnings call and CNBC Mad Money interview, 1 September 2026; reported by CNBC and Quartz, 1–2 September 2026
  • Eric Wallace and Michael Dalton, “The OpenAI–Hugging Face Incident,” Black Hat USA 2026; OpenAI and Hugging Face disclosures, July 2026. A fuller technical postmortem was in progress at the time of the talk — verify details against the published version
  • OWASP Agentic Security Initiative; OWASP Top 10 for Agentic Applications; OWASP AI Agent Security Cheat Sheet
  • ISO/IEC 42001:2023 — Clauses 6, 8, 9, 10; ISO/IEC 27001:2022 Annex A
  • NIST AI RMF 1.0 (NIST AI 100-1)
  • Regulation (EU) 2024/1689 (EU AI Act), Arts. 14, 26

Download the AI Governance & Cybersecurity pdf file

AI Attack Surface ScoreCard 

MachineLearning & Artificial Intelligence

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

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

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

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

Schedule a consultation: info@deurainfosec.com

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

DISC InfoSec blog | DISC InfoSec Site 

Tags: Enterprise Cybersecurity Infrastructure, Operating Model, Security Stack

Aug 31 2026

Thirty years of security assumed the attacker was unauthorized – Your agent isn’t

Category: AI Agent,AI Guardrails,AI Risk,Information Security — disc7 @ 9:37 am

Agentic AI Governance: Mitigating Liability and Protecting Information Assets

The model decided to do that” is not a legal defense

The previous post in this series covered agent security controls — tool scoping, separating decision from execution, memory hygiene, egress control. That’s the engineering layer. This post is about the layer above it, the one a board, an insurer, a regulator, or opposing counsel will actually examine.

The reframe that matters is simple and unforgiving: an action taken by your agent is an action taken by your organization. There is no legal or contractual construct in which “the model decided to do that” reduces your exposure. Autonomy distributes execution. It does not distribute liability.

So the two questions this post answers are the ones I’d want answered before signing off on any agent going to production:

  1. If this agent does something harmful, where does the liability land and what reduces it?
  2. What information assets can this agent reach, and what stops them leaving?

Why agents invert the asset protection model

For thirty years, information security has been organised around keeping unauthorised actors away from assets. Perimeters, access control, segmentation, DLP — all of it assumes the adversary is unauthorised.

An agent is authorised. It holds legitimate credentials, calls sanctioned APIs, reads permitted repositories, and does so at machine speed. When an agent exfiltrates data, no access control was violated. The agent used exactly the permissions you gave it, in a sequence you didn’t anticipate, because its context was partly written by someone else.

That’s why the operating principle from the OWASP Agentic Security Initiative work is agency as the security boundary. An agent is not trustworthy because its underlying model is trustworthy. Trust attaches to what the agent is permitted to do, not to what produced its intentions.

Which yields a principle most organisations don’t have yet, distinct from least privilege:

Least agency — give an agent only the autonomy required for the business objective, separately from minimising its permissions.

An agent can be perfectly least-privileged and still over-agentic: narrow permissions, but authority to act on them without validation. Both dials need setting.

Where the liability actually lands

Four distinct channels, and they don’t behave the same way.

Contractual. This is the nearest-term exposure and the one most organisations walk into unknowingly. Your customer DPAs, MSAs, security addenda, and — critically — your completed vendor security questionnaires are representations. If you answered “all access to customer data is logged and reviewed” before deploying an agent that reads customer data through a service account with no per-action logging, that answer is now inaccurate. Vendor questionnaire responses are the most commonly overlooked liability surface in agent deployment, because nobody re-reads them when architecture changes.

Regulatory. Under the EU AI Act, deployers of high-risk systems carry direct obligations under Article 26 — ensure staff competence, monitor operation, notify incidents, retain logs for at least six months, inform affected workers — and Article 14 requires human oversight that constitutes a demonstrated capability to intervene, interrupt, and disregard. Under GDPR and CCPA/CPRA you remain the controller regardless of how autonomous the processing became. California’s ADMT rules add risk-assessment and notice obligations where agents contribute to significant decisions.

Negligence and standard of care. This one is slower-moving and more consequential. OWASP’s agentic guidance, ISO/IEC 42001, and the NIST AI RMF are converging into a recognised reference standard for reasonable practice. Once a documented, freely available standard exists, failing to implement its obvious provisions becomes evidence of a failure to meet the standard of care. “We didn’t know agents could be prompt-injected” stopped being credible some time in 2025.

Supply chain and value chain. Your model provider’s terms limit their liability; they do not transfer yours. If an agent harms your customer, your customer sues you. ISO 42001’s A.10.3 is specifically about allocating responsibilities across the AI value chain — and the allocation you write down is the one you’ll be held to. Read your provider terms for what they don’t cover.

The practical implication: liability mitigation is not primarily about preventing incidents. It’s about being able to demonstrate that you exercised reasonable care, in writing, before the incident. Which is an evidence problem, not a security problem.

Risk tiering: the one artifact that makes the rest tractable

Most agent governance fails because it tries to apply uniform controls to non-uniform risk. Tier first, then control proportionally. Four tiers, and the tier drives who signs and what’s mandatory.

TierDefinitionTypical examplesMandatory controlsApproval authority
1 — AssistiveProduces information or recommendations; cannot independently execute consequential actionsDrafting, summarisation, low-risk analysisInventory, owner, acceptable use, basic loggingTeam lead
2 — Controlled actionExecutes reversible or low-impact actions under bounded permissionsTicket creation, sandbox changes, non-sensitive workflow automationTier 1 plus tool allowlist, scoped credentials, action logging, rollbackEngineering owner + security review
3 — Privileged autonomousReaches sensitive data, privileged systems, financial workflows, production infrastructure, security controls, or multiple enterprise systemsData-room permission management, production incident remediation, financial reconciliationStrong unique identity, least privilege, independent action authorisation, comprehensive logging, behavioural monitoring, adversarial testing, tested rollback and kill switch, formal risk acceptanceNamed executive risk owner
4 — High-impact / safety-criticalMaterially affects legal rights, safety, critical infrastructure, regulated decisions, major financial outcomes, or irreversible operationsCredit or eligibility decisions, payment initiation, regulated disclosure, security control modificationTier 3 plus human approval for consequential actions, independent policy enforcement, segregation of duties, formal TEVV, documented residual-risk acceptance, tested emergency shutdownExecutive + documented board or committee awareness

Two notes from applying this. Tier assignment should be based on maximum action impact, not typical action impact — an agent that files tickets 99% of the time and can delete a production table 1% of the time is a Tier 3 agent. And anything unclassified defaults to the higher tier, not the lower one; ambiguity is not an argument for less control.

Use a plain 5×5 likelihood × impact model, and raise the impact rating whenever the agent can access regulated data, reach production, move money, modify security controls, affect legal or rights outcomes, execute code, control physical systems, or propagate actions to other agents.

Deployment gates: turning governance into a decision

An agent should not reach production until seven gates pass. This is the mechanism that converts principles into a defensible record, and it’s the thing to build first because everything else hangs off it.

GateWhat it establishesOwner
1 — InventoryAgent identified, owner assigned, business purpose documented, risk tier assignedAI governance owner
2 — ArchitectureData flows, trust boundaries, tool inventory, identity model, memory model, external dependencies documentedTechnical owner
3 — AuthorisationLeast privilege implemented, tool permissions reviewed, credentials scoped, high-impact actions protected, human approval definedSecurity + IAM
4 — Security testingGoal hijack, tool misuse, privilege abuse, supply chain, code execution, memory poisoning, inter-agent, cascade, human-trust, and rogue-agent testing performedSecurity testing owner
5 — MonitoringAgent activity, tool calls, identity events, and policy decisions logged; anomalies monitored; alerts configuredSecOps
6 — RecoveryKill switch, rollback, credential revocation, and incident response procedure each tested, recovery owner assignedSecOps + engineering
7 — GovernanceRisk assessments approved, ISO 42001 and NIST AI RMF crosswalks completed, residual risk accepted, evidence package completeRisk owner

Gate 6 is where I see the most theatre. A kill switch that exists in a runbook and has never been executed is not a control — it’s an assumption. Test it, record the test, and record how long it took.

The output of the gate process should be one explicit disposition, not a vague sign-off: approved, approved with conditions, restricted, remediate before deployment, rejected, or suspended — each with the risk tier, material findings, residual risk, required controls, control owners, approval authority, and an expiry date. Approvals without expiry dates decay into permanent permission.

Prohibited design patterns

The fastest way to raise the floor across an organisation is a short list of patterns that are critical findings unless explicitly justified and formally risk-accepted:

  • Unrestricted shell, filesystem, or internet access
  • Shared administrator credentials, or long-lived unrestricted tokens
  • Model output alone authorising a privileged action
  • Autonomous modification of security controls, or autonomous credential creation
  • Unvalidated dynamic tool loading; untrusted MCP servers in privileged workflows
  • Untrusted agent-to-agent delegation
  • Persistent memory without provenance or lifecycle control
  • Production access without rollback; no tested kill switch for high-impact agents
  • An agent approving its own high-impact action
  • An agent controlling its own security monitoring

Those last two deserve their own sentence. They are segregation of duties, restated for non-human actors. We have decades of consensus that the person who initiates a payment shouldn’t approve it, and that administrators shouldn’t be able to edit the logs that record their activity. Both principles apply unchanged to agents, and both are routinely violated in agent architectures because the agent is convenient and the separation is friction. If you write one governance rule this quarter, write that one.

The corollary for incident response: do not rely on the compromised agent to determine whether it is compromised. Detection, containment, and forensics must sit outside the agent’s own execution path — which is also why monitoring at the syscall, network, and identity layers beats monitoring the agent’s self-reported activity.

Protecting the information assets specifically

Agents create asset classes your data inventory probably doesn’t cover.

Agent memory is a data store. It holds fragments of everything the agent has processed, usually with no classification, no retention schedule, and no owner. It needs all three. Memory also needs provenance — you should be able to say where an entry came from and whether the source was trusted — plus TTLs, write authorisation, quarantine, and rollback.

Deletion rights now reach further than most programs realise. A GDPR erasure request or a CCPA deletion request has to propagate to agent memory, conversation state, vector embeddings, and cached retrieval indices. Embeddings derived from personal data are still personal data. Most deletion pipelines were built before any of these stores existed, and I’d treat “can we actually delete from the vector store and the agent’s memory” as a question to answer before the first request arrives rather than during the response window.

Prompts and system instructions are assets. They encode business logic, control boundaries, and sometimes proprietary process knowledge. They’re also a target — extraction gives an attacker your control design. Version them, restrict who can change them, and treat a prompt change as a change requiring reassessment.

Audit evidence is an asset. The logs proving your controls operated are what stand between you and an adverse inference. They need integrity protection and retention aligned to the longest applicable requirement — for EU high-risk deployers, at least six months under Article 26, though contractual and litigation-hold needs often run longer.

And on classification: the agent’s context window should be governed by your data classification scheme, not by whatever the retrieval layer happened to return. Restricted data should be redacted before entering context, not filtered on the way out.

Controls are not effective because they exist

A rating scale worth adopting verbatim, because it forces honesty. Rate every agent control from 0 to 5: 0 not implemented, 1 ad hoc, 2 partially implemented, 3 defined, 4 implemented and evidenced, 5 measured, tested, and continuously improved.

Most organisations sit at 3 and report 4. The gap between “defined” and “evidenced” is exactly where audit findings live. A control should not be rated effective merely because a policy exists.

One crosswalk caution, since I do this work for a living and see it done badly: do not claim an ISO 42001 control is satisfied because an OWASP mitigation is in place. They’re different instruments. OWASP ASI gives you agent-specific threat identification and testing; 42001 gives you management-system accountability, documented process, risk treatment, and continual improvement; the NIST AI RMF gives you the GOVERN / MAP / MEASURE / MANAGE lifecycle. Record an explicit crosswalk with the applicability decision, implementation status, owner, and evidence for each — not a mapping table asserting equivalence. An auditor will test the claim, not the table.

Monitoring and reassessment triggers

Track as security KPIs: denied and unauthorised tool calls, privilege-escalation attempts, prompt-injection detections, policy violations, anomalous actions, credential misuse, exfiltration attempts, memory-integrity violations, and inter-agent authentication failures.

Track as risk indicators — these are leading, and they’re the ones governance functions miss: agent permission growth, new tools and connectors, model version changes, prompt changes, skill changes, MCP or A2A changes, new memory sources, new data classifications entering scope, and new autonomy levels.

Reassess on any of: model change, major prompt change, tool or permission change, new external agent or MCP connection, material architecture change, new sensitive data in scope, new regulatory requirement, security incident, or significant behavioural drift. Note that most of those are routine engineering events, which is why annual review cycles don’t work for agents. Tie reassessment to change control, not to the calendar.

From the practitioner’s chair

Two things I’d emphasise from having done this rather than read about it.

When I led ShareVault — a virtual data room platform serving M&A and financial services clients — through ISO 42001 Stage 2 certification on the first attempt, and later served as internal auditor, the recurring lesson was that controls were almost never the failure point. Evidence was. The organisations that struggle aren’t the ones without controls; they’re the ones that can’t produce the artifact showing a control operated on a specific date under a specific policy version.

And when I audited that organisation’s MCP Governance Standard and produced a v1.1 redline with 27 changes — covering OAuth 2.1 with PKCE, token audience validation, SSRF and egress controls, tool manifest integrity, and confused-deputy protections — the pattern across nearly all of them was one idea: authority must be bound to a specific action rather than held ambiently by a component. An unaudienced token is authority without a destination. An unverified tool manifest is authority without a definition. A confused-deputy gap is authority without a requester. Liability follows unbound authority with remarkable consistency.

What to do in the next 90 days

  1. Inventory the agents, including the ones nobody registered. You cannot govern, tier, or defend what isn’t listed. Expect to find more than you think, particularly agent features embedded in tools you already buy.
  2. Tier them by maximum action impact and identify every Tier 3 and Tier 4 agent. Those get attention first; the rest can wait.
  3. Re-read your customer commitments and your last three vendor questionnaire responses against what your agents can now actually do. Fix the inaccurate answers before a customer finds them.
  4. Publish the prohibited-patterns list as policy, and require a named risk acceptance for any exception.
  5. Test one kill switch end to end and write down how long it took. That single artifact will tell you more about your real posture than any maturity assessment.
  6. Stand up the gate process and route the next agent through it. The first one is slow; the fifth is routine.

The organisations that come through the next two years cleanly won’t be the ones that avoided agent incidents. They’ll be the ones who can show a documented risk decision, made by a named person, on a dated record, with the evidence that the controls they claimed were operating actually were.

Work with DISC InfoSec

DISC InfoSec helps B2B SaaS and financial services organisations deploy agentic AI that survives both an attacker and an auditor: agent discovery and inventory, risk tiering, OWASP ASI assessment, MCP and tool-permission review, deployment gate design, human oversight architecture, and the evidence packages that map to ISO/IEC 42001, NIST AI RMF, and EU AI Act Articles 14 and 26.

We led VDR organization through ISO 42001 Stage 2 certification on the first audit attempt as the internal practitioner, served as internal auditor, and authored their MCP Governance Standard. If you have agents in production and no dated record of who accepted the risk, that’s the assessment to run now.

DISC InfoSec — 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 📧 infodeurainfosec.com 📞 (707) 998-5164 🌐 deurainfosec.com

This post is security and governance guidance, not legal advice. Liability allocation and regulatory scope should be confirmed with counsel.

Frameworks and references

  • OWASP Agentic Security Initiative; OWASP Top 10 for Agentic Applications; OWASP Agentic AI Threats and Mitigations; OWASP AI Agent Security Cheat Sheet
  • ISO/IEC 42001:2023 — Clauses 4–10; Annex A control themes including AI policy, impact assessment, lifecycle, data management, responsible use, third-party relationships, logging and monitoring, incident management
  • NIST AI RMF 1.0 (NIST AI 100-1); NIST AI 600-1 Generative AI Profile
  • Regulation (EU) 2024/1689 (EU AI Act), Arts. 14, 26
  • CCPA/CPRA and CPPA ADMT regulations; GDPR Arts. 17, 24, 28, 32

Tags: AI Agents

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:

  1. Does it exist? — the document
  2. Is it operating? — the record showing it ran
  3. Who owns it? — a name, not a team
  4. 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:

#ArtifactClauseThe evidence that makes it real
1AIMS scope document4.3Inclusions, exclusions, and justification for exclusions
2AI policy5.2 / A.2.2Signature of top management, date, version, evidence of communication
3AI risk assessment records6.1.2 / 8.2Executed assessments per AI system, with dates and treatment decisions
4AI system impact assessment (AISIA) records6.1.2One per in-scope AI system, updated on material change
5Statement of Applicability6.1.3All 38 Annex A controls, applicability decision, justification, status
6AI objectives6.2Measurable, with the monitoring record showing measurement happened
7Internal audit reports9.2Audit plan, findings, auditor independence evidence
8Management review records9.3Minutes with decisions and action items, not attendance lists
9Nonconformity and corrective action records10.2Root 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

ClauseWhat the auditor asks forCommon nonconformity
4.1 ContextContextual analysis covering AI regulation, public trust, internal AI maturityGeneric corporate context with no AI dimension
4.2 Interested partiesStakeholder register including individuals affected by AI decisions, regulators, model vendorsRegister lists customers and investors only — omits affected individuals
4.3 ScopeAIMS scope document with justified exclusionsAI tools used in HR screening excluded without justification
5.1 LeadershipManagement meeting minutes discussing AI governance; resource allocationAuditor interviews an executive who cannot describe the AIMS scope
5.3 RolesRACI 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 + AISIAExecuted risk assessments and impact assessments per systemAISIA done once at implementation, never revisited
6.1.3 TreatmentRisk treatment plan with owners, timelines, residual risk acceptanceResidual risk not formally accepted by anyone
7.2 CompetenceCompetence matrix by role, training records, effectiveness evaluationTraining records exist; effectiveness never evaluated
7.3 AwarenessAwareness programme evidence with attendance covering all staffAttendance list covers a fraction of headcount, no follow-up
8.1 OperationChange management showing risk/impact reassessment when AI systems changedModel version changed; no reassessment triggered
9.1 MonitoringMetrics register or dashboard with actual readings over timeMetrics defined, never populated
9.2 Internal auditAudit programme, plan covering all clauses over the cycle, reports, independence evidenceInternal auditor audited their own work
9.3 Management reviewMinutes covering the full required agendaReview held, but agenda missed risk assessment results or audit findings
10.2 ImprovementNonconformity log with root cause and effectiveness reviewEffectiveness 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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. Independent where independence is required. Clause 9.2 auditor independence, and — increasingly relevant — separation between whoever operates a control and whoever reviews it.
  7. 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.

  1. Show me your AI system register. Is it complete, and when was it last updated?
  2. Which AI systems are excluded from scope, and why?
  3. Walk me through the impact assessment for this system. Who approved it?
  4. What changed about this system in the last six months, and did that trigger a reassessment?
  5. Who is accountable for this AI system? (The auditor may then go ask that person.)
  6. How does a member of staff raise a concern about an AI system?
  7. Show me your last internal audit report and how the findings were closed.
  8. What AI incidents have you had, and how were they handled?
  9. How do you assess your AI suppliers, and what’s in the contract?
  10. 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:

  1. Effectiveness reviews missing from corrective actions (Clause 10.2)
  2. AISIA completed once, never updated after material change (Clause 6.1.2)
  3. Objectives defined but never measured (Clause 6.2 into 9.1)
  4. Adjacent policies not updated for AI — HR, procurement, IT (A.2.3)
  5. 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:

  1. Free 15–20 minute readiness call
  2. ISO 42001 gap assessment — | ISO 27001 gap assessment — clause-level, with a prioritised remediation roadmap
  3. Quick-Start engagement, 7–10 days — the core artifact set built and handed over
  4. 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

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

DISC InfoSec blog | DISC InfoSec Site 

Tags: ISO 42001 Evidence Checklist

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:

ClusterWhat it coversThe control that matters most
Instruction integrityDirect and indirect prompt injection, goal hijacking, malicious configuration fed through developer consolesTrust boundaries between instructions and data; never let retrieved content carry authority (untrusted data)
Privilege and identityOver-permissioning, tool abuse, privilege escalation through agent chains, credential theft, confused deputyDefault-deny tool scoping; per-agent cryptographic identity; short-lived scoped tokens
Memory and contextMemory poisoning that persists across sessions or users, sensitive data accumulating in contextPer-user memory isolation, TTL and size limits, integrity checks, redaction before persistence
Egress and exfiltrationData leaked through tool calls and API requests, denial of wallet from unbounded loopsEgress allowlists, payload inspection, hard limits on tokens, cost, retries, and chain depth
Multi-agent propagationOne compromised agent escalating through others, cascading failureSigned inter-agent messages with replay protection, trust levels, circuit breakers
Shadow agents (meta)Agents nobody registered, running with unknown permissionsDiscovery 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:

FrameworkAnchor
ISO/IEC 42001A.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.0MAP for context and tool inventory; MEASURE for adversarial testing; MANAGE for monitoring, response, and residual risk
EU AI ActArt. 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 27001A.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

  1. No agent gets a tool whose worst-case use we haven’t written down.
  2. Irreversible actions are validated and authorised by a service the agent does not control, against an approval bound to the exact action.
  3. Every agent has its own identity, its own short-lived credentials, and a decommissioning date.
  4. If classification, policy lookup, approval validation, or audit logging fails, the action does not execute.
  5. 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

Aug 24 2026

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

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

How Much of a Job Can AI Automate? What Remains valuable is not the leftover task

In my last post I argued that governing AI is a more durable bet than racing to build with it. The obvious follow-up question is the harder one, and it’s the question I now get asked in almost every client conversation, usually by someone who has just watched an agent do in four minutes what used to take their team a week:

How much of a job can actually be converted into an AI-executable workflow — and what is still worth paying for once that conversion happens?

Most of the public debate answers this at the level of job titles. That’s the wrong unit of analysis. Jobs don’t get automated; tasks do. And once you look at tasks, the answer gets both more measurable and considerably more uncomfortable.

The conversion rate is already higher than most leaders think

We finally have task-level evidence instead of survey vibes. Anthropic’s Economic Index tracks what people actually delegate to a model, mapped against the U.S. Department of Labor’s O*NET task taxonomy.

Three findings matter for this question:

  • Roughly 49% of jobs in the sample have seen at least a quarter of their constituent tasks performed with AI — up from about 36% a year earlier. Around 4% of occupations see it across three-quarters of their tasks.
  • Of observed usage, 68% sits on tasks rated fully feasible for a model working alone. Only about 3% of usage sits on tasks rated not feasible. Delegation is concentrating on the genuinely convertible.
  • API traffic runs roughly three-quarters automated, versus a near-even split on the consumer product. That’s the tell. When a task migrates from a chat window into a pipeline, the human turn count drops toward zero — and it stops being a productivity aid and becomes an executable workflow.

So the honest answer to “how much” is: for a large share of knowledge roles, somewhere between a quarter and half of the task inventory is already convertible today, and the frontier is moving through the remainder in the direction of more autonomy, not less.

But that’s the easy half of the question.

The uncomfortable part: the residual is not automatically the valuable part

There’s a comforting story we tell ourselves — AI takes the drudgery, humans keep the interesting work. The task-level data does not support it.

When Anthropic ran the thought experiment of removing AI-covered tasks from job descriptions, the first-order effect was to deskill the average job, because the tasks currently covered skew toward the ones requiring more education. Technical writers, travel agents, teachers: what’s left after you subtract the model’s coverage is often the coordination, the chasing, the formatting, the sitting-in-the-meeting.

Pair that with Anthropic’s labor-market analysis, which found no clear unemployment signal in high-exposure occupations as of early 2026, but did find hiring of 22-to-25-year-olds into the most exposed roles slowing by roughly 14% against a counterfactual. The pipeline compresses before the headcount does. Entry-level work is precisely the “do the convertible tasks under supervision until you develop judgment” apprenticeship that the conversion eats first.

So the strategic question isn’t “will my job be automated.” It’s “when the convertible tasks leave, is the residual a promotion or a demotion?”

That depends almost entirely on whether you own the part of the workflow that cannot be delegated. And that part has a name in every AI governance framework written to date: accountability.

A practical conversion audit for your own role

Before deciding what to defend, decompose. Here is the audit I run with clients, borrowed structurally from the MAP function of the NIST AI Risk Management Framework (AI RMF 1.0) — MP-1 context of intended use, MP-3 stakeholder impact, MP-4 risk prioritisation.

List every recurring task in the role. Score each on four axes:

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

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

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

What remains valuable: five capabilities that survive conversion

1. Specification — turning tacit process into a testable spec

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

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

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

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

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

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

3. Evidence — proving the workflow behaved

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

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

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

4. Boundary judgment — the jagged frontier

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

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

5. Accountability — the thing that structurally cannot convert

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

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

The self-application test

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

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

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

What to do about it this quarter

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

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

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

Work with DISC InfoSec

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

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

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

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

Sources referenced

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

Download the AI Governance & Cybersecurity pdf file

AI Attack Surface ScoreCard 

MachineLearning & Artificial Intelligence

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

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

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

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

Schedule a consultation: info@deurainfosec.com

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

DISC InfoSec blog | DISC InfoSec Site 

Tags: AI-Executable Workflow

Aug 20 2026

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

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

A practical seven-step path from a 15-minute readiness call to ISO 42001 and ISO 27001 certification — with the prep work that makes each step fast instead of painful.

Most organizations don’t stall on ISO 42001 or ISO 27001 because the standards are hard. They stall because step one is unclear, and the gap between “we should probably do this” and “we’re booking a Stage 1 audit” has no visible rungs. Here are the rungs — and the prep that makes each one fast.

Each step below is designed to be finished, not admired. Each one produces an artifact you keep and reuse at the next step — the AI system register you build for a gap assessment is the same register your certification auditor samples from. Nothing is throwaway.

You can enter at any rung. Most organizations that already have SOC 2 or a mature security program enter at step 3 or 4. Organizations meeting AI governance for the first time should start at step 1.

01 — Book a 15–20 minute readiness discussion

Time: 20 minutes · Cost: free · Output: a scope boundary and a sequencing decision

The purpose of this call is not a sales pitch — it’s to answer two questions that determine everything downstream: what’s actually in scope, and which standard goes first.

How to make it efficient. Come with three answers ready. That’s the whole prep.

  • What triggered this? A customer security questionnaire, an RFP requirement, funding diligence, EU AI Act exposure, or a board ask. The trigger sets the deadline and the evidence bar.
  • Do you build AI, buy AI, or both? Under ISO 42001 this is the provider/user distinction, and it decides which Annex A controls actually bite. “Both” is the common answer and it’s fine — just say so.
  • What’s your real deadline? Certification bodies book out. A date changes the plan more than a budget does.

Schedule the readiness discussion →

02 — Run the free 5-minute risk assessment quiz

Time: 5 minutes · Cost: free · Output: a directional read on your exposure

A fast self-check across your core security and governance posture. It won’t produce audit evidence, and it isn’t meant to — it tells you whether you’re 20% ready or 70% ready before you spend money finding out.

How to make it efficient.

  • Answer as things are, not as they’re written. A policy nobody follows is a “no.” Auditors test operation, not intent, so score yourself the way Stage 2 will.
  • Have two people take it independently — ideally someone in engineering and someone in leadership. The delta between their scores is usually a more useful finding than either score. Disagreement about what’s in place is the governance gap.

Take the 5-minute quiz →

03 — Order the $49 ISO 42001 AIMS gap assessment

Time: ~1 hour of your input · Cost: $49 · Output: clause-by-clause and control-by-control gap table

This assesses you against the mandatory clauses (4–10) and the Annex A controls of ISO/IEC 42001:2023, and returns a status per item with the evidence each one requires and a prioritized remediation order.

How to make it efficient.

  • Build the AI system register first. One spreadsheet row per AI system, with its intended purpose, owner, and whether you built it or bought it. This single artifact accelerates every step after it.
  • Include the AI you forgot you have. Embedded AI features in SaaS tools, coding assistants, AI in your support desk, an LLM API call buried in one microservice. Incomplete registers are the most common finding I write.
  • Don’t pre-clean. Send the messy version. A gap assessment priced at $49 is worthless if it’s assessing a sanitized picture.

Expect the usual suspects to surface: no AI system impact assessment (AISIA), undocumented human oversight, thin data governance, no supplier AI due diligence, and AI objectives written as principles rather than measurable targets.

Get the $49 ISO 42001 gap assessment →

04 — Order the $59 ISO 27001 ISMS gap assessment

Time: ~1–2 hours of your input · Cost: $59 · Output: gap table across clauses 4–10 and the 93 Annex A controls

Same structure, applied to ISO/IEC 27001:2022 — the 93 controls across the four themes, plus the mandatory documented information the standard requires. If a customer is asking for “a security certification,” this is usually the one they mean.

How to make it efficient.

  • Bring your asset and supplier inventories, whatever state they’re in, plus the policy set you already have. Most organizations have more written than they think and less operating than they hope.
  • Reuse your SOC 2 evidence if you have it. The overlap is substantial, and mapping existing evidence is far cheaper than generating new evidence.
  • Work in 2022 only. The 2013 transition window closed in October 2025 — there’s no reason to assess against the retired version.

Doing both assessments together is the efficient move if AI governance and security certification are both on your roadmap: the two standards share the same clause structure, so the overlapping gaps get remediated once rather than twice.

Get the $59 ISO 27001 gap assessment →

Why the ladder compounds. ISO 42001 and ISO 27001 both follow the ISO High Level Structure. That means one scope statement, one risk methodology, one internal audit programme, one management review, and one corrective action log can satisfy both standards. Organizations that run them sequentially pay for the management system twice. Run them as a single integrated system and the second certification costs a fraction of the first.

05 — Run the 7–10 day AIMS/ISMS Quick-Start

Time: 7–10 calendar days · Output: the mandatory document set, drafted and ready to sign

The Quick-Start converts your gap assessment into the documents the standard actually requires: scope, top-management-signed policy, risk assessment and treatment plan, AI system impact assessment, Statement of Applicability, measurable objectives, an internal audit programme, and a management review agenda.

How to make it efficient.

  • Name one owner with signing authority before day one. The single biggest cause of a 10-day engagement becoming a 10-week one is documents waiting on an approver who was never identified.
  • Batch the input. Two or three 90-minute working sessions beat three weeks of asynchronous questions.
  • Don’t write policy for controls you don’t operate. Every unearned claim in a policy becomes a nonconformity at Stage 2. Where a control isn’t running yet, the honest answer is a dated plan, and auditors accept that.

Start the 7–10 day Quick-Start →

06 — Implement the AIMS/ISMS

Time: typically 8–16 weeks · Output: a management system with operating history

Documents don’t certify — evidence does. Implementation is where the risk assessments get executed, impact assessments get completed per AI system, training gets delivered and logged, supplier assessments get run, and incidents get recorded through the process you wrote.

How to make it efficient.

  • Instrument the evidence at the source. If access reviews, training completions, and change approvals generate records automatically in tools you already use, evidence collection stops being a project.
  • Accumulate operating history deliberately. Stage 2 samples records over a period. Two to three months of a control genuinely running beats a perfect binder assembled the week before.
  • Log the boring events. An incident log with zero incidents proves nothing. A log showing minor events triaged and closed proves the process works — which is exactly what the auditor is testing.

Discuss implementation support →

07 — Certify

Time: Stage 1 and Stage 2, typically 4–8 weeks apart · Output: an accredited certificate

An accredited certification body audits in two stages: Stage 1 reviews your documented management system, Stage 2 verifies it operates. Then annual surveillance audits, with recertification every three years.

How to make it efficient.

  • Book the certification body early. Scheduling — not readiness — is the most common reason certification dates slip. Get on the calendar while you’re still implementing.
  • Complete your internal audit and management review before Stage 1, not between the stages. Both are mandatory, both take real calendar time, and squeezing them into the gap is where teams lose their date.
  • Rehearse the interviews. Stage 2 auditors talk to control owners, not just the compliance lead. Thirty minutes of prep with each owner — what they do, where the record lives — converts a stressful audit into a routine one.

This is the path I ran with ShareVault, a virtual data room platform serving M&A and financial services clients, through ISO 42001 Stage 2 certification on the first attempt — as implementer and internal auditor. Financial data rooms are the hard mode of compliance, and the ladder held.

Talk about certification →

Pick your rung

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

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

DISC InfoSec — Deura Information Security Consulting LLC · Petaluma, CA info@deurainfosec.com · (707) 998-5164 · calendly.com/hd-deurainfosec

A practical seven-step path from a 15-minute readiness call to ISO 42001 and ISO 27001 certification — with the prep work that makes each step fast instead of painful.

Download the AI Governance & Cybersecurity pdf file

AI Attack Surface ScoreCard 

MachineLearning & Artificial Intelligence

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

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

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

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

Schedule a consultation: info@deurainfosec.com

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

DISC InfoSec blog | DISC InfoSec Site 

Tags: AIMS, isms, iso 27001, ISO 42001

Aug 10 2026

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

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

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

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

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

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

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

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

Threat modeling the coding agent

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

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

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

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

The enforcement stack

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

1. Identity and scope — what the agent is

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

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

2. Deny rules — declarative policy

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

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

Two engineering notes that matter more than the syntax:

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

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

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

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

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

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

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

4. OS-level sandboxing — containing what does run

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

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

5. Recoverability — the control that assumes the others failed

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

Governance mapping

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

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

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

My perspective: the deletion story is the distraction

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

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

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

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

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

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

Do not give an agent your whole knowledge base or database

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

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

Three reasons that is not a defensible position:

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

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

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

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

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

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

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

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

AI Attack Surface ScoreCard 

MachineLearning & Artificial Intelligence

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

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

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

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

Schedule a consultation: info@deurainfosec.com

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

DISC InfoSec blog | DISC InfoSec Site 

Contact DISC InfoSec: info@deurainfosec.com

Aug 05 2026

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

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

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

This quote is essentially saying:

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

In simpler terms:

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

In cybersecurity

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

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

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

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

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

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

In the era of AI everywhere

Defensive security is no longer enough

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

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

Attackers can use AI to:

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

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

It’s increasingly:

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

Defensive vs. proactive security

Think of it as two layers:

Defensive security = Don’t let them win.

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

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

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

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

The biggest shift: from alerts to attack paths

This is where I think cybersecurity is heading.

Instead of asking:

“How many vulnerabilities do we have?”

we should ask:

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

AI can help defenders continuously analyze:

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

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

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

Organizations now have:

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

So we’re no longer protecting just IT infrastructure.

We’re protecting AI-enabled business processes.

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

My perspective

I would summarize the future of cybersecurity as:

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

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

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

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

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

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

AI Attack Surface ScoreCard 

MachineLearning & Artificial Intelligence

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

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

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

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

Schedule a consultation: info@deurainfosec.com

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

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

Tags: Defensive Security, Offensive security

Aug 03 2026

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

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

Your Buyer Now Audits Your AI Before They Sign

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

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

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

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

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

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

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

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

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

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

What DISC InfoSec actually does

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

Four service lines carry most of the work:

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

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

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

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

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

The proof point

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

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

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

How engagements are structured

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

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

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

Start where the risk actually is

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

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

→ Take the Free AI Governance & ISO 42001 Readiness Assessment

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

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

You get back:

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

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

Start the Free Assessment → ISO 42001 gap assessment quiz

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

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

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

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

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

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

AI Attack Surface ScoreCard 

MachineLearning & Artificial Intelligence

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

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

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

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

Schedule a consultation: info@deurainfosec.com

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

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

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

Jul 31 2026

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

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

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

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

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

The three assumptions that just died

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

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

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

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

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

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

Assumption 3: you have weeks between disclosure and exploitation.

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

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

The regulatory clock already moved

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

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

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

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

What this looks like in three years

Six predictions I’d put money on:

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

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

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

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

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

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

Defending against AI-accelerated open source discovery

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

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

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

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

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

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

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

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

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

My perspective

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

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

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

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

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

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

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

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

Sources

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

AI Attack Surface ScoreCard 

MachineLearning & Artificial Intelligence

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

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

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

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

Schedule a consultation: info@deurainfosec.com

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

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

Tags: Era of AI-Accelerated Discovery, vulnerability management

Jul 27 2026

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

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

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

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

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

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

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

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

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

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

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

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

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

Part 2 — How often should it be audited?

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

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

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

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

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

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

Part 3 — The continuous compliance operating model

Here is how to actually run it.

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

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

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

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

2. Instrument the controls that actually drift

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

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

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

3. Build evidence pipelines, not evidence hunts

Grade your evidence honestly. There are three tiers:

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

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

4. Convert your ODVs into service-level objectives

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

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

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

5. Make change management the compliance trigger

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

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

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

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

6. Run the POA&M as an operational queue

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

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

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

7. Report metrics that predict the audit outcome

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

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

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

Part 4 — The twelve-month operating calendar

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

Part 5 — Where this goes wrong

Five failure modes account for most of what I see:

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

My perspective: one catalog, two assurance markets

Here’s the view I’d argue for.

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

That reframing lets you stratify cleanly:

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

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

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

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

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

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

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

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

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

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

AI Attack Surface ScoreCard 

MachineLearning & Artificial Intelligence

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

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

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

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

Schedule a consultation: info@deurainfosec.com

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

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

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

Jul 21 2026

GRC Engineering: From Evidence Theater to Genuine Assurance

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

GRC Engineering: From Evidence Theater to Genuine Assurance

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

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

The problem with evidence collection

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

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

From evidence collection to genuine assurance

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

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

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

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

GRC as an insights function

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

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

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

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

Why this is the real shift

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

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

My perspective

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

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

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

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

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

AI Attack Surface ScoreCard

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

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

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

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

Schedule a consultation: info@deurainfosec.com

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

DISC InfoSec blog | DISC InfoSec Site

Tags: GRC Engineering

Jul 12 2026

The adversary that treats your balance sheet as the objective

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

Download html file

lazarus-group-ttps-blog-Download html

AI Attack Surface ScoreCard

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

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

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

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

Schedule a consultation: info@deurainfosec.com

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

DISC InfoSec blog | DISC InfoSec Site

Tags: Lazarus Group, TTPS

Jul 07 2026

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

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

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

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

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

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

MITRE ATT&CK: The Map of Adversary Behavior

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

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

MITRE ATLAS: The Map of AI-Specific Threats

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

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

When to Reach for Each

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

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

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

The Overlap Is Where It Gets Interesting

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

My Perspective

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

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

AI Attack Surface ScoreCard

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

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

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

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

Schedule a consultation: info@deurainfosec.com

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

DISC InfoSec blog | DISC InfoSec Site

Tags: MITRE ATLAS, MITRE ATT&CK

Jun 29 2026

ISO/IEC 27001:2022 — The Compliance Bedrock Every Serious InfoSec Program Is Built On

Category: CISO,Information Security,ISO 27k,vCISO — disc7 @ 8:53 am

ISO/IEC 27001:2022 — The Compliance Bedrock Every Serious InfoSec Program Is Built On

By Disc | Principal Consultant, DISC InfoSec

There’s a question I get from almost every B2B SaaS and financial services client at some point:

“Which compliance framework should we start with?”

My answer is almost always the same: ISO/IEC 27001.

Not because it’s the flashiest. Not because a regulator is threatening a fine. But because it is the only framework that forces you to build a real information security management system — one your entire compliance stack can grow on top of.

Here’s why.

What ISO 27001 Actually Is (And Isn’t)

ISO/IEC 27001:2022 is the international standard for Information Security Management Systems (ISMS). It’s published by the International Organization for Standardization and the International Electrotechnical Commission, and it applies to any organization, any size, any sector.

What it is not is a checklist. It is a management system standard — meaning it requires your organization to define its context, assess risk, implement controls, measure performance, and continuously improve. That PDCA (Plan-Do-Check-Act) discipline is exactly what makes it so durable and so transferable.

The 2022 version restructured the Annex A control library from 114 controls across 14 domains down to 93 controls across 4 themes — Organizational, People, Physical, and Technological — and added 11 new controls for cloud security, threat intelligence, data masking, secure coding, and more. Every organization with a 2013 certification was required to transition by October 2025.

If you’re still operating on a 2013-era ISMS, you’re already out of conformance.

The Mandatory Clause Framework: Where the Real Value Lives

ISO 27001’s Clauses 4 through 10 apply to every organization without exception. This is where the management system lives — not in the Annex A controls, but in the operational discipline the clauses require:

  • Clause 4 — Know your context. Who are your stakeholders? What are their expectations? What’s in scope?
  • Clause 5 — Leadership owns security. A signed policy isn’t a checkbox. It’s a commitment from the top.
  • Clause 6 — Plan your risk treatment. A formal risk register, a risk treatment plan, and a Statement of Applicability (SoA) are mandatory outputs.
  • Clause 7 — Support structures. Competence records, awareness training, documented procedures.
  • Clause 8 — Operate your controls. Evidence that risk treatment is actually executing, not just documented.
  • Clause 9 — Measure and audit. KPIs, internal audits, management review — the cadence that prevents ISMS drift.
  • Clause 10 — Improve. Nonconformities get documented. Corrective actions get tracked. The system learns.

This is not bureaucracy for its own sake. This is the operational skeleton that every mature compliance program eventually needs to build — ISO 27001 just requires you to build it on day one.

Why ISO 27001 Is the Foundation Other Frameworks Stand On

Here’s the practitioner reality: most compliance frameworks are control libraries with a certification stamp. ISO 27001 is different — it’s a management system that happens to include a control library.

That distinction matters enormously when you’re trying to layer frameworks.

SOC 2

The AICPA’s Trust Services Criteria map heavily to ISO 27001 Annex A. If you have implemented access control (A.5.15–5.18), incident response (A.5.24–5.28), supplier security (A.5.19–5.22), and availability controls (A.5.29–5.30), you have already addressed the majority of CC6, CC7, A1, and C1 criteria. ISO 27001 gives SOC 2 auditors a documented ISMS they can rely on — which typically compresses audit timelines and reduces evidence burden.

ISO 42001 (AI Management Systems)

ISO/IEC 42001:2023 — the AI governance standard — was explicitly designed to be compatible with ISO 27001. The two standards share the same Annex SL high-level structure, meaning risk assessment methodology, documentation requirements, internal audit cadence, and management review processes are directly reusable. Organizations that have ISO 27001 in place have an immediate head start on 42001 implementation. For AI-powered SaaS companies facing EU AI Act pressure, this integration is not optional — it’s strategic.

EU AI Act

The EU AI Act’s requirements for high-risk AI systems — risk management systems, data governance, technical documentation, human oversight, robustness — all assume a baseline of information security hygiene. ISO 27001 provides that baseline, particularly through its new 2022 controls: A.8.9 (configuration management), A.8.28 (secure coding), A.5.23 (cloud services security), and A.8.12 (data leakage prevention). Regulators and notified bodies will look for this foundation.

NIST CSF 2.0

The NIST Cybersecurity Framework’s six functions — Govern, Identify, Protect, Detect, Respond, Recover — map cleanly to ISO 27001. The Govern function aligns to Clauses 4, 5, and 6. Protect maps to Annex A’s organizational and technological controls. Detect and Respond align to incident management controls A.5.24–5.28. If you’re pursuing FedRAMP or CMMC, your ISO 27001 ISMS is the documentation backbone the NIST SP 800-53 assessor will want to see.

GDPR and Privacy Regulations

ISO 27001 doesn’t cover privacy by itself — that’s ISO 27701 territory. But the ISMS structure, supplier security controls (A.5.19–5.22), and information classification controls (A.5.12–5.13) provide the security safeguards that GDPR Article 32 requires. A GDPR compliance program built on an ISO 27001 ISMS is structurally sounder than one built from scratch.

The Business Case: Why Enterprises and Governments Demand It

ISO 27001 certification signals something that no internal policy document can: an independent third party has verified your security management system meets a globally recognized standard.

For vendor selection in enterprise and financial services, that matters. For cross-border contracts in the EU, UK, APAC, and Middle East, it’s often a baseline requirement. For regulated industries — healthcare, fintech, government supply chains — it can be the difference between getting on the shortlist or getting cut from procurement.

This is why I tell clients: ISO 27001 is not just a compliance achievement. It’s a revenue enabler.

What “Foundation” Actually Means in Practice

When I use the word foundation, I mean something specific: the mandatory documentation that ISO 27001 requires you to produce becomes the evidentiary infrastructure for every other program you layer on top.

Your ISO 27001 ISMS produces:

  • A scoped asset inventory (feeds SOC 2, FedRAMP, CMMC)
  • A formal risk register (feeds ISO 42001, NIST AI RMF, EU AI Act)
  • A Statement of Applicability (feeds gap analysis for any other framework)
  • An internal audit programme (feeds SOC 2 Type 2, FedRAMP ConMon)
  • A supplier security process (feeds GDPR Article 28, SOC 2 CC9)
  • Management review minutes (feeds governance evidence for any board-level framework)

You build it once. Every other framework benefits.

The Practitioner’s Bottom Line

We’ve implemented ISO 27001 for organizations ranging from boutique SaaS companies to financial services platforms handling sensitive deal data. The pattern is consistent: the organizations that invest in a real ISMS — not a documentation exercise, but an operational management system — spend dramatically less time and money on every subsequent compliance program.

ISO/IEC 27001:2022 is not the finish line. It’s the starting block.

If your organization is serious about security — not just compliant on paper, but operationally disciplined — this is where you begin.

DISC InfoSec specializes in ISO 27001 and ISO 42001 implementation, vCISO and vCAIO services, and AI governance for B2B SaaS and financial services organizations. We are a PECB Authorized Training Partner and have led ISO 42001 Stage 2 certification engagements for production AI systems.

Ready to build a compliance program that actually holds up? Let’s talk. info@deurainfosec.com

→ https://www.deurainfosec.com/iso-27001-consulting/

#ISO27001 #InformationSecurity #ISMS #Compliance #CyberSecurity #GRC #AIGovernance #ISO42001 #vCISO #DISCINFOSEC

AI Attack Surface ScoreCard

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

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

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

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

Schedule a consultation: info@deurainfosec.com

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

DISC InfoSec blog

Tags: isms, iso 27001, security program

Jun 26 2026

One Audit – Four Standards – Zero Duplication

Category: GDPR,Information Security,ISO 27k,ISO 42001,NIST CSF — disc7 @ 11:16 am

One Audit. Four Standards. Zero Duplication.

How to Build a Master Questionnaire as Your Single Source of Truth for ISO 27001, ISO 42001, NIST 800-53, and GDPR

I want to tell you about a problem that is quietly draining compliance teams at SaaS companies right now — and a structural fix that changed how we think about audits entirely.

Here is the situation most security and compliance leaders find themselves in. You hold ISO 27001 certification. Your enterprise customers require NIST 800-53 Rev 5 verification. GDPR applies because you handle European personal data. And now, with AI baked into your product, ISO 42001 is on the table too. Four frameworks. Four sets of controls. Four different auditors asking different versions of the same fundamental questions.

The instinctive response is to build four compliance programs — one for each standard. Four spreadsheets, four evidence libraries, four cycles of internal prep, four rounds of answering the same question about your access control policy worded slightly differently each time.

We did this at client. It was expensive, repetitive, and structurally fragile. Every time a policy changed, we had to update it in four places. Evidence collected for one audit sat invisible to the others. The left hand genuinely did not know what the right hand was doing.

Then we asked a different question: What if there was only one audit?

The Insight That Changes Everything

Across ISO 27001:2022, ISO 42001:2023, NIST SP 800-53 Rev 5, and GDPR, the vast majority of what auditors actually want to know falls into the same 18 operational domains: governance, risk management, access control, data protection, cryptography, incident response, business continuity, supplier management, secure development, and so on.

The standards differ in language, structure, and emphasis. But the underlying security and privacy reality they are probing — your policies, your controls, your evidence — is the same reality. An ISO 27001 auditor asking about your access control policy (A.5.15) and a NIST assessor asking about AC-1 are fundamentally asking the same organization the same question. Your Access Control Policy v1.3 answers both of them.

This is the foundation of the Master Questionnaire approach: write the question once, map the answer to every standard it satisfies simultaneously.

Why Most Multi-Standard Programs Fail Structurally

Before describing what to build, it is worth being precise about why the typical approach breaks down. The problem is not effort or intention — compliance teams work hard. The problem is architecture.

Most organizations build what I call parallel catalogs: one spreadsheet or GRC module per standard, each with its own question set, its own evidence columns, its own status tracking. When the ISO 27001 auditor asks about incident response and the GDPR auditor asks about breach notification, they get two separate answers pointing to the same IR Procedure — but there is no structural connection between them. If you update the procedure, you have to remember to update both rows in both sheets. You usually do not. Inconsistencies accumulate. Auditors notice.

The second failure is ID scheme collision. This sounds technical but it matters enormously in practice. If your internal questionnaire uses “IR-01” for your Incident Response domain questions and NIST SP 800-53 uses “IR-1” for the same family, you end up with ID conflicts that make cross-referencing impossible. You cannot write a formula or filter that reliably maps one to the other. We ran into exactly this problem in our own workbook, discovering 173 NIST Moderate baseline controls that existed only in a standalone NIST catalog with no connection whatsoever to the master question set.

The third failure is scope mismatch. NIST SP 800-53 Rev 5 Moderate baseline has approximately 235 distinct controls across 20 families when enhancements are included. ISO 27001:2022 has 93 Annex A controls. ISO 42001:2023 has 38 AI-specific controls. GDPR has 99 Articles. Organizations routinely under-scope their questionnaires, sampling 26 or 30 NIST controls and calling it “covered.” A real Moderate baseline assessment covers every control — AC-1 through SR-12, including every enhancement number that the baseline requires.

The Architecture of a Single Source of Truth

Here is how to build it correctly.

Start with 18 operational domains, not four standards.

The domains should reflect how your organization actually operates: Governance & Policies, Scope & Context, Risk Management, Access Control & Identity, Data Protection & Privacy, Cryptography & Key Management, Network & Infrastructure Security, Secure Development, Incident Response, Business Continuity, Supplier & Third-Party Management, Physical & Environmental Security, Human Resources Security, Audit Logging & Monitoring, Configuration & Change Management, AI Governance, Compliance & Internal Audit, and Cross-Border Data Transfers.

Every question you write lives in one of these domains. The domain structure is standard-agnostic — it reflects your operational reality, not any single framework’s chapter structure.

Write questions that satisfy multiple standards simultaneously.

Take access control as an example. Rather than writing four separate questions — one citing ISO 27001 A.5.16, one citing NIST AC-2, one citing GDPR Art. 32, one citing ISO 42001 A.6.2.2 — you write one question: “Describe the complete joiner-mover-leaver process. How are accounts created, modified, and deactivated? What is the maximum time to deprovision a terminated user?”

This single question satisfies ISO 27001:2022 A.5.16 and A.5.18, NIST SP 800-53 Rev 5 AC-2, AC-2(1), AC-2(3), and AC-2(5), and GDPR Art. 32. One answer. Four standards. That is not a shortcut — that is what a mature account management process actually looks like when described completely.

Use a collision-free ID scheme from the start.

This is a technical detail that pays significant dividends. Cross-standard questions should use domain-based prefixes that do not clash with any standard’s own naming: G- for Governance, A- for Access Control, INC- for Incident Response (not IR-, which collides with the NIST IR family), BCP- for Business Continuity, CFG- for Configuration Management (not CM-, which collides with NIST CM), CRY- for Cryptography, and so on.

NIST-specific questions — those covering Moderate baseline controls not addressed by any cross-standard question — should use a clearly distinct scheme: NIST-{family}-{sequence}, for example NIST-AC-07 for AC-7, NIST-PE-04 for PE-13. This makes the source of every question unambiguous and allows you to filter programmatically by standard without collision.

The Master tab is the only place answers live.

Every auditor view — ISO 27001 tab, ISO 42001 tab, NIST tab, GDPR tab — is a filtered subset of the Master, not an independent document. When the answer to a question changes, you update it once in the Master. The filter propagates to all auditor views automatically. If you find yourself maintaining two versions of an answer, your architecture has a flaw.

Add a Question Source column.

This single column distinguishes between cross-standard questions (one question, many standards) and NIST-specific questions (one control, one question). It tells any auditor looking at the sheet exactly what they are looking at and why the question exists. It also tells your team where to invest effort — cross-standard questions with a “★ Shared” marker satisfy three or more frameworks simultaneously and should be answered first.

What the Numbers Look Like in Practice

When we implemented this at client, the numbers clarified the approach nicely.

We ended up with 213 total questions in the Master: 104 cross-standard questions covering all 18 operational domains, and 109 NIST-specific questions covering NIST Moderate baseline controls that needed dedicated coverage. The NIST auditor view contains 212 questions — covering 235 distinct NIST controls — all filtered directly from the Master. The ISO 27001 view contains 209 questions. The GDPR view contains 206. The ISO 42001 view contains 138, reflecting that ISO 42001’s scope is intentionally narrower.

Of the 213 total questions, 56 are marked as shared controls — meaning a single answer to that question satisfies three or more standards simultaneously. These 56 questions are the highest-leverage evidence collection effort in your entire audit programme. Answer them well and you have satisfied the core control requirements of all four frameworks for the most critical domains: risk management, access control, encryption, incident response, supplier management, data protection, logging, and business continuity.

Before this restructure, we had a v3 workbook with 104 questions in the Master and 187 in a standalone NIST tab with zero structural connection between them. The root cause was that the NIST tab had been built as a separate catalog with NIST family-based IDs that clashed with our domain IDs, making cross-referencing impossible. This is a common mistake and worth naming explicitly: a NIST tab that cannot be proven to be a filtered view of the Master is not a single source of truth — it is a second source of truth, which is the same as no single source of truth at all.

The Columns That Make It Work

A Master Questionnaire has a specific anatomy. Every row needs:

Q-ID — unique, collision-free identifier following your scheme.

Domain — the operational domain, not the standard’s chapter.

Audit Question — written to satisfy all applicable standards simultaneously, framed around your actual controls and evidence.

Audit Type — Document Review, Technical Review, Interview, Sample, or combinations. This tells both your team and the auditor what kind of evidence the question expects.

ISO 27001:2022 reference — official Annex A control IDs (A.5.1 through A.8.34) and Clause references (Cl.4 through Cl.10). Not approximated — exact.

ISO 42001:2023 reference — official Annex A control IDs (A.2.2 through A.10.4) and Clause references. ISO 42001 Annex A objectives (A.x.1 entries) are not controls — the controls begin at A.x.2. This distinction matters when an ISO 42001 auditor checks your SoA.

NIST SP 800-53 Rev 5 reference — official control IDs with enhancement numbers. AC-2(1) is a different control from AC-2. A Moderate baseline assessment distinguishes between them. If your questionnaire collapses AC-2 and all its enhancements into a single cell without specifying which enhancements apply, your NIST assessor will push back.

GDPR reference — specific Article numbers at sub-article precision. Art. 5(1)(c) is different from Art. 5(1)(e). Art. 28(3) specifies the mandatory clauses in a DPA. Approximated references like “Art. 32 generally” are insufficient for a DPO-level review.

Answer column — blank, awaiting your response. This is the most important column in the workbook. It is where your security reality meets the standards’ requirements.

Status — a dropdown: Implemented, Partial, Not Implemented, N/A, Not Tested. The Partial status is particularly important — it tells auditors and management exactly where gaps exist without overstating or understating compliance.

Evidence / Document Reference — the policy name, version, section, screenshot, log excerpt, or configuration that proves the answer. This column is pre-filled with hints when you build the questionnaire (e.g., “Access Control Policy v1.3; 90-day review evidence; LastPass configuration”) and updated with actual references during audit preparation.

Question Owner — the individual responsible for providing the answer and evidence. Compliance does not happen in a CISO’s office alone. Owners span IT, HR, Legal, DevOps, the AI Officer, and the DPO.

Auditor Notes — reserved for the auditor. Your team does not pre-fill this column. It is the auditor’s workspace during the actual audit session.

Shared Control flag — a star marker for questions satisfying three or more standards. Your audit preparation team should complete all starred questions first. They represent the core of your compliance posture across every framework.

The Audit Session Experience

Here is what this looks like in practice when you sit down with an auditor.

Your ISO 27001 auditor receives the ISO 27001 filtered view tab. They see 209 questions, each with official Annex A or Clause references, your pre-populated answer, a status, and an evidence reference. They work through the Auditor Notes column adding their observations. They do not need to navigate the NIST questions or the AI governance section unless a control overlaps.

Your NIST assessor receives the NIST view tab: 212 questions covering 235 controls across all 20 families from AC through SR. Both cross-standard questions (where your Access Control Policy satisfies AC-1, AC-2, AC-3 simultaneously) and NIST-specific questions (AC-7 lockout thresholds, AC-11 device lock, SC-15 collaborative device controls) are visible, with the Question Source column clearly labeling each type.

Your DPO or privacy auditor receives the GDPR view: 206 questions covering Articles 5 through 83, with cross-references to the ISO 27001 and ISO 42001 controls that satisfy the same requirement. The RoPA question, the DPIA question, the data subject rights process question, the breach notification procedure — all answered once in the Master, surfaced here for the privacy auditor’s review.

What none of these auditors receive is a contradictory answer. Because there is only one answer. There is only one Master.

The AI Governance Layer

ISO 42001:2023 deserves specific attention because it is the newest of the four standards and the one most organizations are building from scratch rather than extending from existing programs.

The standard requires several things that have no direct analog in ISO 27001 or NIST. AI System Impact Assessments (AISIAs) are mandatory for every AI system in scope — a structured analysis of potential impacts on individuals, groups, and society, resulting in a Low, Medium, or High impact classification. This feeds directly into how much human oversight, transparency, and testing is required for each system. Your AI governance questions need to cover this lifecycle: system registration, AISIA, responsible design principles (A.6.1.3), verification and validation testing (A.6.2.4), controlled deployment (A.6.2.5), monitoring (A.8.5), and AI-specific incident management (A.8.4).

The AI data governance controls — A.7.2 through A.7.6 covering data quality, provenance, and preparation — have meaningful overlap with GDPR’s data minimisation (Art. 5(1)(c)), purpose limitation (Art. 5(1)(b)), and privacy by design (Art. 25) requirements. A single well-written question about AI data governance can cover all of these simultaneously, but only if you know both standards well enough to write it that way.

The EU AI Act adds a classification layer that sits above ISO 42001 rather than within it: your AI systems need to be assessed against the Act’s risk tiers (prohibited, high-risk Annex III, limited risk, minimal risk) with resulting compliance obligations. This is an AIX-domain question in the Master with no NIST equivalent — which is fine, because not every question needs to satisfy all four standards. The single source of truth principle does not mean every question covers every standard; it means every answer lives in one place.

Five Principles to Build By

If I were starting this process from scratch at a new organization, I would anchor on five principles from day one.

Official control IDs only. Approximated references create ambiguity that auditors exploit. If your ISO 27001 reference says “A.5 generally” instead of “A.5.15; A.5.16; A.5.18,” a thorough auditor will ask which specific controls you are claiming coverage for and you will have to reconstruct the mapping under pressure. Use the exact IDs from the published standards. ISO 27001:2022 Annex A runs from A.5.1 to A.8.34. NIST 800-53 Rev 5 AC-2(1) is a separate control from AC-2. These distinctions are in the standards for a reason.

Full coverage, not sampling. A Moderate NIST baseline assessment covers approximately 235 controls. An ISO 27001 audit covers all 93 Annex A controls. Sampling — picking representative controls from each family — may satisfy a checkbox exercise but it will not satisfy a thorough assessor and it will not actually tell you where your gaps are. The discipline of building complete coverage is also the discipline of discovering what you do not have implemented yet.

One answer, not four. If you catch yourself writing the same answer in two different tabs, your architecture is broken. Fix the architecture, not the duplicate. The structural constraint — all auditor views are filtered subsets of the Master — should make duplication physically impossible.

Gaps are information, not failure. The Partial and Not Implemented status options are not admissions of guilt — they are the output of an honest audit programme. A questionnaire where everything is marked Implemented before an auditor has looked at it is not a compliance programme; it is a liability. Real compliance posture requires knowing where you stand, including the uncomfortable parts.

The questionnaire is a living document, not a pre-audit scramble. The most valuable thing a Master Questionnaire does is shift compliance from a periodic event to a continuous state. When your IR procedure changes, you update the INC-01 answer. When you onboard a new AI service provider, you update the AIX-09 answer and the SUP-03 answer. The questionnaire should be reviewed quarterly, updated continuously, and owned by named individuals — not assembled in the three weeks before an auditor arrives.

A Note on AI-Assisted Compliance

One of the most significant changes in compliance practice over the last two years is the ability to use AI tools to populate questionnaire answers from an organization’s existing knowledge base — policies, procedures, security documentation, vendor assessments, architecture documents.

This does not replace human judgment. The Answer column in a Master Questionnaire still requires a human to verify accuracy, attach actual evidence references, and set a status they are willing to defend in an audit. But it dramatically compresses the time between “questionnaire template built” and “questionnaire ready for auditor review.”

At ShareVault, where our knowledge base includes our Security Policy, Access Control Policy, AI Management Policy, Incident Response Procedure, Risk Assessment Procedure, Privacy Policy, and Security & Availability documentation, an AI tool can populate an initial draft of most answers from these sources and flag which questions have insufficient documentation to answer — which is itself valuable information.

The key discipline is the same as for all AI-assisted work: the human remains accountable for the output. The AI drafts; the owner reviews, corrects, and signs off. The auditor evaluates the answer, not the method used to produce it.

Where to Start

If you are managing compliance across multiple standards and you recognize the structural problems described here, the path forward is straightforward even if the work is substantial.

Start with a gap analysis of what you currently have. Count your actual questions per standard. Map each one to the official control ID it is claiming to satisfy. Find the NIST families you have not covered at all (typically MA, MP, PE, PL, and SR are the most common gaps). Identify whether your auditor view tabs are provably filtered subsets of a master, or independent catalogs that happen to cover some of the same ground.

Then rebuild the Master with the architecture described above. It takes time to write 213 questions with precise official references. But you write them once. After that, every audit, every evidence collection cycle, and every questionnaire from a customer or prospect draws from the same source.

That is the value of a single source of truth. Not that compliance becomes easy — but that every effort you invest in it compounds instead of fragmenting.

The client team holds ISO 27001:2022 certification (SHA-27K-PRI) and ISO 42001:2023 certification (SHA-AIMS-20260129), maintains NIST SP 800-53 Rev 5 Moderate baseline verification, and operates under GDPR as both a data controller and processor for European customers. The Master Audit Questionnaire described in this article was built through iterative refinement of our own internal compliance programme.

#InformationSecurity #Compliance #ISO27001 #ISO42001 #NIST #GDPR #AuditPreparation #AIGovernance #DataProtection #CyberSecurity #GRC #CISO #DPO #SaaS #RiskManagement

AI Attack Surface ScoreCard

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

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

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

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

Schedule a consultation: info@deurainfosec.com

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

Continue reading “One Audit – Four Standards – Zero Duplication”

Tags: gdpr, iso 27001, ISO 42001, NIST 800-53, One Audit

Jun 24 2026

GDPR Isn’t a Checkbox. It’s the Privacy Standard Your Organization Can’t Afford to Ignore

Category: GDPR,Information Security — disc7 @ 9:46 am

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 or drop a note below: info@deurainfosec.com

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

Tags: gdpr, Privacy Standard

Next Page »