DISC InfoSec blogInternal Audit Archives

Aug 29 2026

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

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

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

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

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

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

Controls are almost never why organisations fail. Evidence is.

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

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

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

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

Most programs can answer 1. Certification requires all four.

Stage 1 and Stage 2 test different things

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

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

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

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

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

The mandatory documented information

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

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

Three of these fail more often than the rest.

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

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

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

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

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

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

Annex A hot spots

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

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

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

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

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

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

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

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

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

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

The seven patterns that separate a pass from a finding

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

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

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

Ten questions to rehearse

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

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

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

The new gap: agentic systems

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

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

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

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

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

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

Five nonconformities I’d bet on finding

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

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

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

Test yourself this afternoon

A genuinely useful exercise that takes about an hour:

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

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

Work with DISC InfoSec

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

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

Readiness path:

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

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

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

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

References

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

AI Attack Surface ScoreCard

MachineLearning & Artificial Intelligence

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

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

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

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

Schedule a consultation: info@deurainfosec.com

DISC InfoSec blog | DISC InfoSec Site

Tags: ISO 42001 Evidence Checklist

Comments (0)

Aug 03 2026

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

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

Your Buyer Now Audits Your AI Before They Sign

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

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

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

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

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

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

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

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

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

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

What DISC InfoSec actually does

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

Four service lines carry most of the work:

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

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

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

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

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

The proof point

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

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

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

How engagements are structured

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

Package	Deliverables	Timeline
ISO 27001 / 42001 Gap Assessment	Baseline audit, prioritized roadmap, executive summary	2–4 weeks
SOC 2 Readiness	Gap analysis, controls mapping, evidence checklist	4–6 weeks
Startup Security Program	Policies, risk register, awareness training	3–6 weeks

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

Start where the risk actually is

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

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

→ Take the Free AI Governance & ISO 42001 Readiness Assessment

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

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

You get back:

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

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

Start the Free Assessment → ISO 42001 gap assessment quiz

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

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

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

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

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

DISC-AI-Governance-Readiness-Assessment-1-1 pdf download Download

AI Attack Surface ScoreCard

MachineLearning & Artificial Intelligence

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

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

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

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

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

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

Comments (0)

Mar 12 2026

AI Governance: From Frameworks to Testable Controls and Audit Evidence

Category: AI,AI Governance,Internal Audit,ISO 42001 — disc7 @ 9:12 am

AI Governance is becoming operational.

Most organizations talk about frameworks — but very few can prove their AI controls actually work.

AI governance is the system organizations use to ensure AI systems are safe, fair, compliant, and accountable. Frameworks provide the guidance, but testing produces the proof.

Here’s the practical reality across the major frameworks:

🇺🇸 NIST AI Risk Management Framework
Organizations must identify and measure AI risks. In practice, that means testing models for bias, hallucinations, and performance drift. Evidence includes risk registers, evaluation scorecards, and drift monitoring logs.

🔐 NIST Cybersecurity Framework 2.0
Cybersecurity applied to AI. Organizations must know what AI systems exist and who has access. Testing focuses on shadow AI discovery, access control validation, and security testing. Evidence includes AI asset inventories, penetration test reports, and access matrices.

🌐 ISO/IEC 42001
The emerging AI management system standard. It requires organizations to assess AI impact and monitor performance. Testing includes misuse scenarios, regression testing, and anomaly detection. Evidence includes AI impact assessments, red-team results, and KPI monitoring reports.

🔒 ISO/IEC 27001
Security for AI pipelines and training data. Controls must protect models, code, and personal data. Testing focuses on code vulnerabilities, PII leakage, and data memorization risks. Evidence includes SAST reports, PII scan results, and data masking logs.

🇪🇺 EU Artificial Intelligence Act
The first binding AI law. High-risk AI must be governed, explainable, and built on quality data. Testing evaluates misuse scenarios, bias in datasets, and decision traceability. Evidence includes risk management plans, model cards, data quality reports, and output logs.

The pattern across all frameworks is simple:

Framework → Requirement → Testing → Evidence.

AI governance isn’t about memorizing regulations.

It’s about building repeatable testing processes that produce defensible evidence.

Organizations that succeed with AI governance will treat compliance like engineering:

• Test the controls
• Monitor continuously
• Produce verifiable evidence

That’s how AI governance moves from policy to proof.

At DISC InfoSec, we help organizations translate AI frameworks into testable controls and audit-ready evidence pipelines.

#AIGovernance #AICompliance #AISecurity #NIST #ISO42001 #ISO27001 #EUAIAct #RiskManagement #CyberSecurity #AIRegulation #AITrust

Get Your Free AI Governance Readiness Assessment – Is your organization ready for ISO 42001, EU AI Act, and emerging AI regulations?

AI Governance Gap Assessment tool

15 questions
Instant maturity score
Detailed PDF report
Top 3 priority gaps

Click below to open an AI Governance Gap Assessment in your browser or click the image to start assessment.

ai_governance_assessment-v1.5Download

Built by AI governance experts. Used by compliance leaders.

At DISC InfoSec, we help organizations navigate this landscape by aligning AI risk management, governance, security, and compliance into a single, practical roadmap. Whether you are experimenting with AI or deploying it at scale, we help you choose and operationalize the right frameworks to reduce risk and build trust. Learn more at DISC InfoSec.

Tags: Audit Evidence

Comments (0)

Jan 24 2026

Smart Contract Security: Why Audits Matter Before Deployment

Category: Information Security,Internal Audit,Smart Contract — disc7 @ 12:57 pm

Smart Contracts: Overview and Example

What is a Smart Contract?

A smart contract is a self-executing program deployed on a blockchain that automatically enforces the terms of an agreement when predefined conditions are met. Once deployed, the code is immutable and executes deterministically – the same inputs always produce the same outputs, and execution is verified by the blockchain network.

Potential Use Case

Escrow for Freelance Payments: A client deposits funds into a smart contract when hiring a freelancer. When the freelancer submits deliverables and the client approves (or after a timeout period), the contract automatically releases payment. No intermediary needed, and both parties can trust the transparent code logic.

Example Smart Contract

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract SimpleEscrow {
    address public client;
    address public freelancer;
    uint256 public amount;
    bool public workCompleted;
    bool public fundsReleased;

    constructor(address _freelancer) payable {
        client = msg.sender;
        freelancer = _freelancer;
        amount = msg.value;
        workCompleted = false;
        fundsReleased = false;
    }

    function releasePayment() external {
        require(msg.sender == client, "Only client can release payment");
        require(!fundsReleased, "Funds already released");
        require(amount > 0, "No funds to release");
        
        fundsReleased = true;
        payable(freelancer).transfer(amount);
    }
}

Fuzz Testing with Foundry

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "forge-std/Test.sol";
import "../src/SimpleEscrow.sol";

contract SimpleEscrowFuzzTest is Test {
    SimpleEscrow public escrow;
    address client = address(0x1);
    address freelancer = address(0x2);

    function setUp() public {
        vm.deal(client, 100 ether);
    }

    function testFuzz_ReleasePayment(uint256 depositAmount) public {
        // Bound the fuzz input to reasonable values
        depositAmount = bound(depositAmount, 0.01 ether, 10 ether);
        
        // Deploy contract with fuzzed amount
        vm.prank(client);
        escrow = new SimpleEscrow{value: depositAmount}(freelancer);
        
        uint256 freelancerBalanceBefore = freelancer.balance;
        
        // Client releases payment
        vm.prank(client);
        escrow.releasePayment();
        
        // Assertions
        assertEq(escrow.fundsReleased(), true);
        assertEq(freelancer.balance, freelancerBalanceBefore + depositAmount);
        assertEq(address(escrow).balance, 0);
    }

    function testFuzz_OnlyClientCanRelease(address randomCaller) public {
        vm.assume(randomCaller != client);
        
        vm.prank(client);
        escrow = new SimpleEscrow{value: 1 ether}(freelancer);
        
        // Random address tries to release
        vm.prank(randomCaller);
        vm.expectRevert("Only client can release payment");
        escrow.releasePayment();
    }

    function testFuzz_CannotReleaseMultipleTimes(uint8 attempts) public {
        attempts = uint8(bound(attempts, 2, 10));
        
        vm.prank(client);
        escrow = new SimpleEscrow{value: 1 ether}(freelancer);
        
        // First release succeeds
        vm.prank(client);
        escrow.releasePayment();
        
        // Subsequent attempts fail
        for (uint8 i = 1; i < attempts; i++) {
            vm.prank(client);
            vm.expectRevert("Funds already released");
            escrow.releasePayment();
        }
    }
}

Run the fuzz tests:

forge test --match-contract SimpleEscrowFuzzTest -vvv

Configure fuzz runs in foundry.toml:

[fuzz]
runs = 10000
max_test_rejects = 100000

Benefits of Smart Contract Audits

Security Assurance: Auditors identify vulnerabilities like reentrancy attacks, integer overflows, access control flaws, and logic errors before deployment. Since contracts are immutable, catching bugs pre-deployment is critical.

Economic Protection: Bugs in smart contracts have led to hundreds of millions in losses. An audit protects both project funds and user assets from exploitation.

Compliance & Trust: For regulated industries or institutional adoption, third-party audits provide documented due diligence that security best practices were followed.

Gas Optimization: Auditors often identify inefficient code patterns that unnecessarily increase transaction costs for users.

Best Practice Validation: Audits verify adherence to standards like OpenZeppelin patterns, proper event emission, secure randomness generation, and appropriate use of libraries.

Reputation & Adoption: Projects with reputable audit reports (Trail of Bits, OpenZeppelin, Consensys Diligence) gain user confidence and are more likely to attract partnerships and investment.

Given our work at DISC InfoSec implementing governance frameworks, smart contract audits parallel traditional security assessments – they’re about risk identification, control validation, and providing assurance that systems behave as intended under both normal and adversarial conditions.

DISC InfoSec: Smart Contract Audits with Governance Expertise

DISC InfoSec brings a unique advantage to smart contract security: we don’t just audit code, we understand the governance frameworks that give blockchain projects credibility and staying power. As pioneer-practitioners implementing ISO 42001 AI governance and ISO 27001 information security at ShareVault while consulting across regulated industries, we recognize that smart contract audits aren’t just technical exercises—they’re risk management foundations for projects handling real assets and user trust. Our team combines deep Solidity expertise with enterprise compliance experience, delivering comprehensive security assessments that identify vulnerabilities like reentrancy, access control flaws, and logic errors while documenting findings in formats that satisfy both technical teams and regulatory stakeholders. Whether you’re launching a DeFi protocol, NFT marketplace, or tokenized asset platform, DISC InfoSec provides the security assurance and governance documentation needed to protect your users, meet institutional due diligence requirements, and build lasting credibility in the blockchain ecosystem. Contact us at deurainfosec.com to secure your smart contracts before deployment.

Tags: Smart Contract Audit

Comments (1)

Dec 03 2025

Why Auditing AI Is Critical for Responsible and Secure Adoption

Category: AI,AI Governance,Internal Audit — disc7 @ 1:51 pm

Managing AI Risks Through Strong Governance, Compliance, and Internal Audit Oversight

Organizations are adopting AI at a rapid pace, and many are finding innovative ways to extract business value from these technologies. As AI capabilities expand, so do the risks that must be properly understood and managed.
Internal audit teams are uniquely positioned to help organizations deploy AI responsibly. Their oversight ensures AI initiatives are evaluated with the same rigor applied to other critical business processes.
By participating in AI governance committees, internal audit can help set standards, align stakeholders, and bring clarity to how AI is adopted across the enterprise.
A key responsibility is identifying the specific risks associated with AI systems—whether ethical, technical, regulatory, or operational—and determining whether proper controls are in place to address them.
Internal audit also plays a role in interpreting and monitoring evolving regulations. As governments introduce new AI-specific rules, companies must demonstrate compliance, and auditors help ensure they are prepared.
Several indicators signal growing AI risk within an organization. One major warning sign is the absence of a formal AI risk management framework or any consistent evaluation of AI initiatives through a risk lens.
Another risk indicator arises when new regulations create uncertainty about whether the company’s AI practices are compliant—raising concerns about gaps in oversight or readiness.
Organizations without a clear AI strategy, or those operating multiple isolated AI projects, may fail to realize the intended benefits. Fragmentation often leads to inefficiencies and unmanaged risks.
If AI initiatives continue without centralized governance, the organization may lose visibility into how AI is used, making it difficult to maintain accountability, consistency, and compliance.

Potential Impacts of Failing to Audit AI (Summary)

The organization may face regulatory violations, fines, or enforcement actions.
Biased or flawed AI outputs could damage the company’s reputation.
Operational disruptions may occur if AI systems fail or behave unpredictably.
Weak AI oversight can result in financial losses.
Unaddressed vulnerabilities in AI systems could lead to cybersecurity incidents.

My Opinion

Auditing AI is no longer optional—it is becoming a foundational part of digital governance. Without structured oversight, AI can expose organizations to reputational damage, operational failures, regulatory penalties, and security weaknesses. A strong AI audit function ensures transparency, accountability, and resilience. In my view, organizations that build mature AI auditing capabilities early will not only avoid risk but also gain a competitive edge by deploying trustworthy, well-governed AI at scale.

Governance in The Age of Gen AI: A Director’s Handbook on Gen AI

Tags: AI Internal Audit

Comments (0)

Mar 28 2025

Preparing for an ISO Audit: Essential Tips and Best Practices for a Successful Outcome

Category: Information Security,Internal Audit,ISO 27k — disc7 @ 2:44 pm

”Preparing for an ISO Audit: Tips and Best Practices” is a comprehensive guide by AuditCo, published in February 2025, aimed at assisting organizations in effectively preparing for ISO audits. The article outlines several key strategies:

Understanding ISO Standards: It emphasizes the importance of familiarizing oneself with the specific ISO standards relevant to the organization.
Conducting a Pre-Audit: The guide recommends performing a self-assessment to identify and address areas of non-compliance before the official audit.
Organizing Documentation: Ensuring that all pertinent documents, such as policies and records, are well-organized and easily accessible is highlighted as a crucial step.
Training Employees: Providing staff with training on the audit process and their respective roles is advised to facilitate a smoother audit experience.
Engaging with Auditors: Establishing open communication with auditors to clarify expectations and address concerns is also recommended.

Additionally, the article suggests best practices like creating an audit checklist, involving top management to demonstrate commitment to compliance, monitoring corrective actions for identified non-conformities, and implementing improvements post-audit to enhance the management system.

For a detailed exploration of these strategies, you can read the full article

Full Preparation Plan for an ISO Audit

1. Understand the ISO Standard :

– Familiarize yourself with the specific ISO standard relevant to your organization (e.g., ISO 27001 for Information Security, ISO 9001 for quality management, ISO 14001 for environmental management, ISO 45001 for occupational health and safety).

– Study the standard requirements and guidelines to fully grasp what is expected.

2. Gap Analysis :

– Conduct a thorough gap analysis to compare your current processes and systems against the ISO standard requirements.

– Identify areas that need improvement and document these gaps.

3. Develop an Implementation Plan :

– Create a detailed plan to address the gaps identified in the gap analysis.

– Assign responsibilities to team members, set timelines, and allocate necessary resources.

4. Training and Awareness :

– Train your employees on the ISO standard requirements and the importance of compliance.

– Ensure that everyone understands their roles and responsibilities related to the ISO standards.

5. Document Control :

– Develop or update documentation to meet ISO requirements, including policies, procedures, work instructions, and records.

– Implement a document control system to manage and maintain these documents efficiently.

6. Internal Audits :

– Conduct internal audits to evaluate your readiness for the ISO audit.

– Identify non-conformities and take corrective actions to address them.

– Internal audits should closely mimic the external audit process.

7. Management Review :

– Hold a management review meeting to assess the effectiveness of your ISO management system.

– Ensure top management is involved and committed to the process.

8. Pre-Audit Assessment :

– If possible, conduct a pre-audit assessment with an external consultant to get an objective evaluation of your readiness.

– Use the feedback to make any necessary adjustments before the actual audit.

9. Audit Logistics :

– Coordinate with the external auditor to schedule the audit.

– Prepare all necessary documentation and ensure key personnel are available during the audit.

10. Continuous Improvement :

– ISO audits are not a one-time event. Implement a culture of continuous improvement to maintain compliance and enhance your management system.

– Regularly review and update your processes and systems to ensure ongoing compliance.

ISO 27001 INTERNAL AUDITS & DATA PROTECTION: STRENGTHENING COMPLIANCE & SECURITY: A Practical Guide to Conducting Internal Audits and Safeguarding Sensitive Data (ISO 27001:2022)

Tags: ISO 27001 Internal Audit, ISO Audit Plan

Comments (9)

Feb 25 2025

Difference Between Internal and External Audit

Category: Internal Audit — disc7 @ 8:42 am

Feature	Internal Audit	External Audit
Objective	Evaluates internal controls, risk management, and compliance to improve efficiency.	Provides an independent opinion on financial statements and compliance with regulations.
Conducted By	Internal employees or outsourced auditors reporting to management or the board.	Independent third-party auditors hired by shareholders or regulators.
Focus	Operational effectiveness, risk management, and compliance.	Accuracy and fairness of financial statements.
Regulation	Not legally required but recommended for governance.	Mandatory for public companies and regulated entities.
Frequency	Ongoing, conducted throughout the year.	Typically conducted annually.
Reporting	Reports to management and the board (Audit Committee).	Reports to shareholders and regulatory authorities.
Independence	May lack full independence due to internal employment.	Fully independent from the organization.

Internal audits help improve internal processes, while external audits ensure compliance and financial integrity. First party audits, known as internal audits, consider the effectiveness and efficiency of the Management System, whereas external audits consider only the effectiveness of the Management System.

ISO certification training courses.

ISMS and ISO 27k training

Tags: External Audit, Internal audit

Comments (13)

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

Stage 1 and Stage 2 test different things

The mandatory documented information

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

Annex A hot spots

The seven patterns that separate a pass from a finding

Ten questions to rehearse

The new gap: agentic systems

Five nonconformities I’d bet on finding

Test yourself this afternoon

Work with DISC InfoSec

References

Your Buyer Now Audits Your AI Before They Sign

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

What DISC InfoSec actually does

The proof point

How engagements are structured

Start where the risk actually is

→ Take the Free AI Governance & ISO 42001 Readiness Assessment

Start the Free Assessment → ISO 42001 gap assessment quiz

Smart Contracts: Overview and Example

What is a Smart Contract?

Potential Use Case

Example Smart Contract

Fuzz Testing with Foundry

Benefits of Smart Contract Audits

DISC InfoSec: Smart Contract Audits with Governance Expertise

Managing AI Risks Through Strong Governance, Compliance, and Internal Audit Oversight

Potential Impacts of Failing to Audit AI (Summary)

My Opinion

Full Preparation Plan for an ISO Audit

ISO certification training courses.

Get new posts by email:

vCISO as a service