Technology you can prove is trustworthy.

AI is already inside your organization. Some of it came through approved projects. Some arrived in a vendor’s latest software update. Some is running in an employee’s browser right now. Each use raises real questions about data, security, accountability, and human judgment, and regulators, auditors, and customers are starting to ask them.

Governance begins with three answers: where AI is in use, what risk each use creates, and who is accountable for the outcome. From there, I build and assess controls across the full life cycle, from intake and use-case assessment through approval, deployment, monitoring, and retirement. Oversight should match the stakes. A tool that summarizes meeting notes doesn’t need the scrutiny of a model that shapes credit, claims, or customer decisions.

The risks I assess include unreliable or fabricated outputs, sensitive data exposure, bias, weak explainability, unapproved “shadow AI,” and heavy dependence on outside model providers. I also test whether human review has teeth. A reviewer needs the authority, the knowledge, and the information to challenge an AI-supported decision. Without all three, “human in the loop” is just a checkbox.

My assessments are grounded in the NIST AI Risk Management Framework and ISO/IEC 42001, with attention to the EU AI Act and the model risk expectations that apply to regulated firms. These frameworks give the work structure, expose gaps quickly, and define the evidence a sound governance conclusion requires.

Real assurance looks past the policy to daily practice. I verify that approvals took place, decisions were documented, performance is monitored, and teams respond when a model’s behavior or risk profile shifts.

My perspective is practical. I have supervised teams that built AI solutions, so I understand how these systems are designed, tested, and released, and where controls tend to get skipped under deadline pressure.

Every financial statement, customer transaction, and operating decision depends on technology working the way management believes it does. When a control fails quietly, the business is usually the last to know. The news tends to arrive from an auditor, an examiner, or a customer. My job is to find it first.

I take a risk-based approach. Before I test anything, I learn the business process: what it does, which systems carry it, and what a control failure would cost. That understanding shapes the scope, so audit hours go to the areas of greatest exposure instead of the areas easiest to test.

I then test control design and operating effectiveness. I examine primary evidence, challenge explanations that don’t hold together, and tie each finding to a specific business consequence. Management receives findings it can act on, not observations it has to decode.

My reports are written to be used. Each finding explains what failed, why it matters, and what will correct the root cause. I agree on corrective actions with the owners responsible for delivering them, and I retest before an issue closes. A fix that hasn’t been validated isn’t a fix.

Most organizations have the policies, the frameworks, and the risk register. What they often lack is follow-through. Registers go stale. Controls are mapped to requirements but never tested. Issues sit open for quarters because no one owns the deadline. Then an examiner asks a simple question, and nobody can answer it with evidence.

I close the gap between what governance documents promise and what teams actually do. I examine how risks are identified, how controls are evaluated, who signs off on residual exposure, and how open issues are tracked and escalated. My second-line work has shown me where programs break down: blurred ownership, loose risk acceptance, and remediation marked complete before the evidence supports it.

I turn framework language into four questions every risk owner should be able to answer:

• Who owns this risk?
• Which control addresses it?
• What evidence shows that control works?
• At what point does an open issue reach senior management?

When those answers are clear, accountability stops being abstract, and decisions become far easier to defend before examiners and auditors.

Issue management receives particular attention. A corrective action should remove the cause of a weakness and leave a clear evidence trail. I assess issue quality, the realism of remediation plans, the rationale behind each risk acceptance, and the criteria used to close an issue.

I also bring hands-on platform experience: more than three years building out and managing OneTrust, including production and UAT environments for a GRC and third-party risk platform. I know how a governance design turns into workflows, data, and reports that people actually use.

A security failure never stays in the IT department. It becomes an outage, a breach notification, a regulatory inquiry, or a hard conversation with your largest customer. The question leadership needs answered is simple: will our controls hold, and can we prove it?

I answer that question as a risk and assurance professional. I assess whether you understand your exposures, whether your controls address them, and whether you have evidence those controls operate as designed. The core areas are identity and access, vulnerability management, secure configuration, incident response, and data protection.

Cloud environments add a risk many organizations underestimate: shared responsibility. Your provider secures part of the stack and you secure the rest, and the dividing line shifts from one service to the next. I assess whether your access, configuration, logging, monitoring, and recovery practices fully cover your side of that line, including control assessments in AWS and Azure.

Resilience gets equal scrutiny. A recovery plan that has never been tested is a hope, not a control. I review backup practices, restoration results, recovery dependencies, and open weaknesses that affect critical operations. Ransomware readiness is a specific focus, because that is where weak backups and slow recovery do the most damage.

Throughout, I translate technical findings into business terms. Leaders come away knowing what is exposed, how much it matters, and where to invest first.

Your vendors run essential services, handle sensitive data, and connect directly to your systems. When their controls fail, the consequences land on you, and regulators expect you to have seen it coming. Effective oversight depends on understanding the service, the dependency, and how the exposure shifts over the life of the relationship.

I start with the vendor’s role in your business. What data does it touch? What access does it hold? How critical is the service, and what happens the day it stops? Those answers set the depth of due diligence and monitoring, so your team’s effort goes to the vendors that carry real risk instead of spreading thin across hundreds of low-impact suppliers.

Next, I test whether the vendor’s evidence actually covers the services you use. That means reviewing SOC report scope, exceptions, carved-out subservice organizations, and the complementary user entity controls your own team is expected to run. Those controls are easy to overlook, and they often go untested. I also evaluate supporting security documentation, open findings, and the basis for every risk acceptance.

Ongoing monitoring is where many programs fall short. An acquisition, a hosting change, a security incident, or a change to a critical service should each trigger a fresh look. I assess whether your organization catches these events and reassesses the exposure that follows, including risk that sits with your vendors’ own vendors.

For third-party AI, I extend the review to data handling and model training, provider accountability, output reliability, and the human oversight you keep in place.

My approach is grounded in hands-on platform work. I have built out and managed OneTrust for third-party risk, so I know how intake, tiering, assessments, and issue tracking perform under real volume.

A discrepancy raises questions. Answering them takes discipline. Establishing what really happened means examining the transactions, the records, the approvals, and the circumstances around them, while keeping fact and assumption apart at every step.

My forensic work draws directly on my background in technology risk, and that combination matters. Modern fraud almost always runs through systems: access someone shouldn’t have, an approval limit nobody enforces, a control that looks sound on paper and never fires. I examine how financial activity, system access, approval authority, and control weaknesses interact, so I can assess an irregularity within the full business process rather than as an isolated entry.

My focus includes fraud risk assessment, transaction analysis, procurement and payment irregularities, and evidence evaluation. For each transaction, I ask three questions. Did it serve a legitimate business purpose? Do the supporting records hold up? Does independent evidence confirm the explanation? Data analytics let me test entire populations instead of samples, surfacing duplicate payments, unfamiliar vendors, round-dollar entries, and activity outside normal hours.

I keep documented facts, assumptions, and open questions clearly separated. My workpapers are traceable, my procedures are consistent, and my conclusions never reach past the evidence. Where records conflict or support is missing, I name the gap and the work required to close it.

I also examine the conditions that allowed an irregularity to occur or go unnoticed. Finding those conditions is what makes lasting corrective action possible across access, approvals, monitoring, and accountability.