Technology you can prove is trustworthy.

AI is al­ready in­side your or­ga­ni­za­tion. Some of it came through ap­proved projects. Some ar­rived in a ven­dor’s lat­est soft­ware up­date. Some is run­ning in an em­ploy­ee’s brows­er right now. Each use rais­es real ques­tions about data, se­cu­ri­ty, ac­count­abil­i­ty, and human judg­ment, and reg­u­la­tors, au­di­tors, and cus­tomers are start­ing to ask them.

Gov­er­nance be­gins with three an­swers: where AI is in use, what risk each use cre­ates, and who is ac­count­able for the out­come. From there, I build and as­sess con­trols across the full life cycle, from in­take and use-case as­sess­ment through ap­proval, de­ploy­ment, mon­i­tor­ing, and re­tire­ment. Over­sight should match the stakes. A tool that sum­ma­rizes meet­ing notes doesn’t need the scruti­ny of a model that shapes cred­it, claims, or cus­tomer de­ci­sions.

The risks I as­sess in­clude un­re­li­able or fab­ri­cat­ed out­puts, sen­si­tive data ex­po­sure, bias, weak ex­plain­abil­i­ty, un­ap­proved “shad­ow AI,” and heavy de­pen­dence on out­side model providers. I also test whether human re­view has teeth. A re­view­er needs the au­thor­i­ty, the knowl­edge, and the in­for­ma­tion to chal­lenge an AI-sup­port­ed de­ci­sion. With­out all three, “human in the loop” is just a check­box.

My as­sess­ments are ground­ed in the NIST AI Risk Man­age­ment Frame­work and ISO/IEC 42001, with at­ten­tion to the EU AI Act and the model risk ex­pec­ta­tions that apply to reg­u­lat­ed firms. These frame­works give the work struc­ture, ex­pose gaps quick­ly, and de­fine the ev­i­dence a sound gov­er­nance con­clu­sion re­quires.

Real as­sur­ance looks past the pol­i­cy to daily prac­tice. I ver­i­fy that ap­provals took place, de­ci­sions were doc­u­ment­ed, per­for­mance is mon­i­tored, and teams re­spond when a model’s be­hav­ior or risk pro­file shifts.

My per­spec­tive is prac­ti­cal. I have su­per­vised teams that built AI so­lu­tions, so I un­der­stand how these sys­tems are de­signed, test­ed, and re­leased, and where con­trols tend to get skipped under dead­line pres­sure.

Every fi­nan­cial state­ment, cus­tomer trans­ac­tion, and op­er­at­ing de­ci­sion de­pends on tech­nol­o­gy work­ing the way man­age­ment be­lieves it does. When a con­trol fails qui­et­ly, the busi­ness is usu­al­ly the last to know. The news tends to ar­rive from an au­di­tor, an ex­am­in­er, or a cus­tomer. My job is to find it first.

I take a risk-based ap­proach. Be­fore I test any­thing, I learn the busi­ness process: what it does, which sys­tems carry it, and what a con­trol fail­ure would cost. That un­der­stand­ing shapes the scope, so audit hours go to the areas of great­est ex­po­sure in­stead of the areas eas­i­est to test.

I then test con­trol de­sign and op­er­at­ing ef­fec­tive­ness. I ex­am­ine pri­ma­ry ev­i­dence, chal­lenge ex­pla­na­tions that don’t hold to­geth­er, and tie each find­ing to a spe­cif­ic busi­ness con­se­quence. Man­age­ment re­ceives find­ings it can act on, not ob­ser­va­tions it has to de­code.

My re­ports are writ­ten to be used. Each find­ing ex­plains what failed, why it mat­ters, and what will cor­rect the root cause. I agree on cor­rec­tive ac­tions with the own­ers re­spon­si­ble for de­liv­er­ing them, and I retest be­fore an issue clos­es. A fix that hasn’t been val­i­dat­ed isn’t a fix.

Most or­ga­ni­za­tions have the poli­cies, the frame­works, and the risk reg­is­ter. What they often lack is fol­low-through. Reg­is­ters go stale. Con­trols are mapped to re­quire­ments but never test­ed. Is­sues sit open for quar­ters be­cause no one owns the dead­line. Then an ex­am­in­er asks a sim­ple ques­tion, and no­body can an­swer it with ev­i­dence.

I close the gap be­tween what gov­er­nance doc­u­ments promise and what teams ac­tu­al­ly do. I ex­am­ine how risks are iden­ti­fied, how con­trols are eval­u­at­ed, who signs off on resid­ual ex­po­sure, and how open is­sues are tracked and es­ca­lat­ed. My sec­ond-line work has shown me where pro­grams break down: blurred own­er­ship, loose risk ac­cep­tance, and re­me­di­a­tion marked com­plete be­fore the ev­i­dence sup­ports it.

I turn frame­work lan­guage into four ques­tions every risk owner should be able to an­swer:

• 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 an­swers are clear, ac­count­abil­i­ty stops being ab­stract, and de­ci­sions be­come far eas­i­er to de­fend be­fore ex­am­in­ers and au­di­tors.

Issue man­age­ment re­ceives par­tic­u­lar at­ten­tion. A cor­rec­tive ac­tion should re­move the cause of a weak­ness and leave a clear ev­i­dence trail. I as­sess issue qual­i­ty, the re­al­ism of re­me­di­a­tion plans, the ra­tio­nale be­hind each risk ac­cep­tance, and the cri­te­ria used to close an issue.

I also bring hands-on plat­form ex­pe­ri­ence: more than three years build­ing out and man­ag­ing OneTrust, in­clud­ing pro­duc­tion and UAT en­vi­ron­ments for a GRC and third-party risk plat­form. I know how a gov­er­nance de­sign turns into work­flows, data, and re­ports that peo­ple ac­tu­al­ly use.

A se­cu­ri­ty fail­ure never stays in the IT de­part­ment. It be­comes an out­age, a breach no­ti­fi­ca­tion, a reg­u­la­to­ry in­quiry, or a hard con­ver­sa­tion with your largest cus­tomer. The ques­tion lead­er­ship needs an­swered is sim­ple: will our con­trols hold, and can we prove it?

I an­swer that ques­tion as a risk and as­sur­ance pro­fes­sion­al. I as­sess whether you un­der­stand your ex­po­sures, whether your con­trols ad­dress them, and whether you have ev­i­dence those con­trols op­er­ate as de­signed. The core areas are iden­ti­ty and ac­cess, vul­ner­a­bil­i­ty man­age­ment, se­cure con­fig­u­ra­tion, in­ci­dent re­sponse, and data pro­tec­tion.

Cloud en­vi­ron­ments add a risk many or­ga­ni­za­tions un­der­es­ti­mate: shared re­spon­si­bil­i­ty. Your provider se­cures part of the stack and you se­cure the rest, and the di­vid­ing line shifts from one ser­vice to the next. I as­sess whether your ac­cess, con­fig­u­ra­tion, log­ging, mon­i­tor­ing, and re­cov­ery prac­tices fully cover your side of that line, in­clud­ing con­trol as­sess­ments in AWS and Azure.

Re­silience gets equal scruti­ny. A re­cov­ery plan that has never been test­ed is a hope, not a con­trol. I re­view back­up prac­tices, restora­tion re­sults, re­cov­ery de­pen­den­cies, and open weak­ness­es that af­fect crit­i­cal op­er­a­tions. Ran­somware readi­ness is a spe­cif­ic focus, be­cause that is where weak back­ups and slow re­cov­ery do the most dam­age.

Through­out, I trans­late tech­ni­cal find­ings into busi­ness terms. Lead­ers come away know­ing what is ex­posed, how much it mat­ters, and where to in­vest first.

Your ven­dors run es­sen­tial ser­vices, han­dle sen­si­tive data, and con­nect di­rect­ly to your sys­tems. When their con­trols fail, the con­se­quences land on you, and reg­u­la­tors ex­pect you to have seen it com­ing. Ef­fec­tive over­sight de­pends on un­der­stand­ing the ser­vice, the de­pen­den­cy, and how the ex­po­sure shifts over the life of the re­la­tion­ship.

I start with the ven­dor’s role in your busi­ness. What data does it touch? What ac­cess does it hold? How crit­i­cal is the ser­vice, and what hap­pens the day it stops? Those an­swers set the depth of due dili­gence and mon­i­tor­ing, so your team’s ef­fort goes to the ven­dors that carry real risk in­stead of spread­ing thin across hun­dreds of low-im­pact sup­pli­ers.

Next, I test whether the ven­dor’s ev­i­dence ac­tu­al­ly cov­ers the ser­vices you use. That means re­view­ing SOC re­port scope, ex­cep­tions, carved-out sub­ser­vice or­ga­ni­za­tions, and the com­ple­men­tary user en­ti­ty con­trols your own team is ex­pect­ed to run. Those con­trols are easy to over­look, and they often go untest­ed. I also eval­u­ate sup­port­ing se­cu­ri­ty doc­u­men­ta­tion, open find­ings, and the basis for every risk ac­cep­tance.

On­go­ing mon­i­tor­ing is where many pro­grams fall short. An ac­qui­si­tion, a host­ing change, a se­cu­ri­ty in­ci­dent, or a change to a crit­i­cal ser­vice should each trig­ger a fresh look. I as­sess whether your or­ga­ni­za­tion catch­es these events and re­assess­es the ex­po­sure that fol­lows, in­clud­ing risk that sits with your ven­dors’ own ven­dors.

For third-party AI, I ex­tend the re­view to data han­dling and model train­ing, provider ac­count­abil­i­ty, out­put re­li­a­bil­i­ty, and the human over­sight you keep in place.

My ap­proach is ground­ed in hands-on plat­form work. I have built out and man­aged OneTrust for third-party risk, so I know how in­take, tier­ing, as­sess­ments, and issue track­ing per­form under real vol­ume.

A dis­crep­an­cy rais­es ques­tions. An­swer­ing them takes dis­ci­pline. Es­tab­lish­ing what re­al­ly hap­pened means ex­am­in­ing the trans­ac­tions, the records, the ap­provals, and the cir­cum­stances around them, while keep­ing fact and as­sump­tion apart at every step.

My foren­sic work draws di­rect­ly on my back­ground in tech­nol­o­gy risk, and that com­bi­na­tion mat­ters. Mod­ern fraud al­most al­ways runs through sys­tems: ac­cess some­one shouldn’t have, an ap­proval limit no­body en­forces, a con­trol that looks sound on paper and never fires. I ex­am­ine how fi­nan­cial ac­tiv­i­ty, sys­tem ac­cess, ap­proval au­thor­i­ty, and con­trol weak­ness­es in­ter­act, so I can as­sess an ir­reg­u­lar­i­ty with­in the full busi­ness process rather than as an iso­lat­ed entry.

My focus in­cludes fraud risk as­sess­ment, trans­ac­tion analy­sis, pro­cure­ment and pay­ment ir­reg­u­lar­i­ties, and ev­i­dence eval­u­a­tion. For each trans­ac­tion, I ask three ques­tions. Did it serve a le­git­i­mate busi­ness pur­pose? Do the sup­port­ing records hold up? Does in­de­pen­dent ev­i­dence con­firm the ex­pla­na­tion? Data an­a­lyt­ics let me test en­tire pop­u­la­tions in­stead of sam­ples, sur­fac­ing du­pli­cate pay­ments, un­fa­mil­iar ven­dors, round-dol­lar en­tries, and ac­tiv­i­ty out­side nor­mal hours.

I keep doc­u­ment­ed facts, as­sump­tions, and open ques­tions clear­ly sep­a­rat­ed. My work­pa­pers are trace­able, my pro­ce­dures are con­sis­tent, and my con­clu­sions never reach past the ev­i­dence. Where records con­flict or sup­port is miss­ing, I name the gap and the work re­quired to close it.

I also ex­am­ine the con­di­tions that al­lowed an ir­reg­u­lar­i­ty to occur or go un­no­ticed. Find­ing those con­di­tions is what makes last­ing cor­rec­tive ac­tion pos­si­ble across ac­cess, ap­provals, mon­i­tor­ing, and ac­count­abil­i­ty.