Audit Readiness, Evidence and Inspection Management Questions

Direct answer. I would start by checking whether I am actually right, then raise the disagreement through the proper channel with evidence, and decide in advance what outcome I will accept. The goal is an accurate rating and a good working relationship, not winning. Auditors rate findings by criteria such as the control's importance, the likelihood and size of potential misstatement or harm, and whether compensating controls exist, so my case should be framed in those terms.

Step 1: test my own position internally (same day)
Ask: what facts does the auditor have that I may not? Is the finding about design or operation? A design deficiency means the control, even if followed perfectly, would not stop the risk (for example no review step exists); an operating deficiency means the control is well designed but was not performed as designed (the review exists but some were skipped). Design gaps can warrant a higher rating because following the process harder will not fix them, but severity still turns on the likelihood and size of what could go wrong, so an operating failure on a critical control can outrank a design gap on a minor one. Is the rating consistent with how they rated similar issues before? Get my own security and risk owner to challenge me. If the auditor is right, accept it and move to the fix.

Step 2: raise it with the auditor

• Ask for the criteria and the rating basis in writing.
• Request a short meeting rather than arguing by email, with the engagement lead or manager, not only the staff member who found it.
• Stay factual: "Here is the population, the exception count, and the control that mitigates it". For example: "Of 25 items sampled, 2 lacked a recorded sign-off, and in both the review took place, as these tickets show. Please help us understand why this is rated high rather than medium under your criteria."

What I would bring (a population is the complete list of items the control applies to, a sample is the subset the auditor tested, an exception is a sampled item that failed the control, and a misstatement is an error in the reported financial figures)

Step 3: internally
Brief the sponsor (CISO or audit committee contact) before the meeting so there are no surprises, and agree what we will concede. Tell the control owner the truth: arguing a rating down does not remove the work.

When to accept the rating anyway

• The auditor's reasoning holds once I check it.
• The cost of contesting (relationship strain, delay of the report) outweighs the benefit, for example when a rating difference changes nothing about the remediation required.
• My evidence is weaker than I assumed.
• The disagreement is about judgement that belongs to the auditor, as the auditor must form an independent opinion.
  In that case, record management's response: "Management accepts the finding and the remediation date", optionally with a comment on disagreement. The auditor, not management, owns the final rating.

Worked example. The auditor rates a missing quarterly access review as high. I find the review was done but sign-off was not recorded: then the control operated and the documentation failed. I present the review records and ticket history; the auditor may re-rate to a documentation-only finding, but may still hold that an unevidenced control cannot be relied on. I accept that and fix the sign-off step.

Pitfall. Never go over the auditor's head casually, and never pressure them. Auditor independence means the auditor must form an opinion free from influence by the party being audited, so pressure can look like an attempt to compromise it. The proper route is the engagement lead and the audit committee contact.

Direct answer. With 42 days (six weeks times seven) to the audit, I would triage gaps by a simple rule: first separate "the control exists but I cannot prove it" from "the control does not exist", fix the first group by producing evidence, then fix the second group only where a real control can be operating long enough to show. I would tell the auditors early, in writing, about the gaps with a remediation plan, rather than let them find them. Counsel and the audit owner decide the exact wording to the regulator; I would draft the engineering facts.

Step 1: inventory and classify (days 1-3)
List each missing-evidence control and score it on three things: impact if wrong (does it protect regulated personal data, how many records), auditor visibility (is it a named requirement, will it be sampled), and time to fix. A workable scale: impact 1 to 3 times visibility 1 to 3 gives a priority of 1 to 9, with time to fix in days beside it. Audit scope is the list of systems, processes and periods the auditor will test, so a gap outside it can wait. Then place it in one bucket:

Step 2: prioritise. A priority of 6 or more with a fix of about 20 days or less goes first. Fix first what is high impact and quick. A gap with fix time between about 20 and 42 days goes in bucket B only if it can still be operated before the audit; otherwise it moves to C. Defer what is low impact and slow, never what is high impact: a high-impact gap that cannot be fixed gets an interim measure and an open disclosure.

Step 3: what to tell the auditors. Tell them early: the gap, its scope, risk assessment, the interim measure, the owner and a dated plan. Do not backdate documents or recreate evidence to look historical; label anything created now with its creation date. A created-now artifact can show the control operates today; it cannot prove it operated last quarter.

When an interim (compensating) measure is credible
A compensating control is an alternative control that reduces the same risk when the intended one is not in place. It is credible when it:

• addresses the same risk, not a neighbouring one,
• is actually operating and leaves its own evidence (a weekly manual review with signed records beats a promise),
• has been running long enough to show at least a few occurrences (one manual review a week for three weeks gives three data points, which is thin but real),
• has a named owner, and
• has an end date tied to the permanent fix.
  It is not credible if it is a policy memo, if it depends on one person's memory, or if it was introduced the week before and will be dropped after.

Scoring example (illustrative).

A remediation plan is the written list of actions, owners and dates that closes a gap; an interim measure is the temporary control that reduces the risk until the plan completes. Disclosure sentence for the last row: "We identified that retention is not automatically enforced on the legacy archive store. Until automated deletion is built, the data owner runs and signs a weekly manual deletion review, and evidence of each run is retained. Target date for the permanent control: 30 November." (The target date falls after the audit because the automation needs about 10 weeks, longer than the 42 days available.)

Worked example. Gap: no evidence that deletion requests are executed. Bucket A: deletion jobs exist, logs are kept 30 days. Action: export the last 30 days of logs now, extend retention, and add a weekly report. Gap: no access review for the data warehouse. Bucket B: no review exists yet, but one can be run now with manager sign-off and then scheduled quarterly, so there is a real operated example before the audit.

What would change my call: a regulator-specified deadline, evidence that data is actively being exposed (then it is an incident, not an audit task), or a finding the audit scope can exclude. Pitfall: spending six weeks polishing documents instead of fixing a high-impact control.

Direct answer. SOX (the US Sarbanes-Oxley Act, whose Section 404 requires management to assess internal controls over financial reporting) pushes auditors to test IT general controls (ITGCs: the controls over the systems that produce financial data, covering access, change management and operations), including change management. The delivery process should automatically record, for every production change, an independent approval, the identity of the build that was deployed, and who wrote, approved and released it. Where automation cannot cover a change, I would say so and show the exceptions.

1. Evidence the pipeline should produce

• Approved: a change record or pull request linked to each deploy, with approval by someone who is not the author, enforced by branch protection (a repository setting that blocks a merge until rules such as a required independent review are met).
• Deployed build matches reviewed code: CI records the commit and the artifact digest (a hash of the build); the deploy step records the digest it released; a check blocks deployment when digests differ.
• No one wrote and released the same change: author, approver and deployer identities captured; deployment runs only through a pipeline identity, and humans lack direct production access.
• Records kept in a protected store for the period.

2. Where it falls short

• Emergency changes approved after the fact.
• Direct database or console changes outside the pipeline.
• Admins able to bypass branch protection.
• Approvals that exist but were a rubber stamp (a rubber stamp: an approval proves a click, not a review).
• Changes invisible to the pipeline: if they do not appear in deploy records, the population is incomplete.

3. Showing it to the auditor
The population is the complete list of production deploys in the period, and a sample is the subset the auditor chooses from it to test, so they pick the sample, not you. Reconcile (match line by line) platform deploy events to change records so completeness is demonstrable.

One deploy, traced end to end (illustrative). Deploy D-88121 on 2026-04-14: pull request #5120 written by Asha, approved by Ben (a different person) at 13:41; merged as commit 9c1e4f7; CI built an image with digest sha256:4be1 (shortened); the deploy record shows the same digest; released by the pipeline service identity after Priya approved the release. The auditor checks three things on that one row: author is not approver, digest in the deploy equals digest from CI, and the releaser is the pipeline, not the author.

Illustrative result: 1,240 production deploys; 1,226 fully clean; 14 exceptions (9 emergency changes approved afterwards, 3 where the author triggered the deploy, 2 where the digest could not be matched). 1,226 plus 14 is 1,240, so the clean and exception counts account for every deploy in the list; exceptions are 1.1%. That sum shows the classification is consistent, not that the list is complete. Completeness comes from the reconciliation described above: the 1,240 deploy events in the platform must match 1,240 change records, with any deploy that has no change record, or any change record that has no deploy, listed as its own exception. The three causes differ: an emergency change is approved by an on-call lead after the fix is live, so the approval exists but late; an author-triggered deploy means the pipeline let the person who wrote the change press release; an unmatched digest usually means an artifact was rebuilt or uploaded by hand. Present each exception with its explanation and fix. The auditor and management decide how a deficiency is classified (how serious it is, for example a minor control deficiency versus a material weakness).

Framing. This is a behavioural question, so below is the shape of a strong story in STAR form (Situation, Task, Action, Result). Replace the details with your own real experience; the structure and the specifics of your own actions are what interviewers listen for. The details here are illustrative, not a claim about a real company.

Situation. An external audit of a mid-sized SaaS company produced 14 findings across access management, change management and vendor oversight. Owners were spread over IT, engineering, HR and procurement, and the re-audit was scheduled in five months.

Task. I was responsible for coordinating closure and showing the auditors the gaps were really closed.

Actions I took

1. Prioritised by risk and by dependency. I scored each finding on impact and likelihood (1-5 each) and noted dependencies. For example, the leaver-access finding (former employees' accounts still active) scored highest because it exposed customer data, and the HR offboarding workflow was a dependency for it, so HR went first.
2. Got teams moving. I turned each finding into a ticket in each team's own backlog with one named owner, a due date, and a plain statement of the risk (not audit jargon). For engineering, I sized the fix and proposed the smallest change that satisfied the control. I held a weekly 20-minute status review, and escalated to the VP sponsor only the items that missed dates twice.
3. Fixed causes, not just instances. For leaver access, deleting the stale accounts was the fix for the finding as raised, but the cause was no automatic trigger from HR to IT, so we automated deprovisioning.
4. Built the evidence as we went. For each finding the ticket required a closure package: before and after configuration, the new procedure, and proof of operation (for example, deprovisioning logs for leavers across a full month).
5. Pre-validated with the auditors. Before the re-audit, I shared the closure packages and asked what population, period and attributes they would test (auditors normally keep their exact sample unpredictable, so they will not name it in advance), then drew my own random sample on those terms and ran it myself.

Measuring success and sustainment

• Closure rate by severity, against the plan.
• Recurrence: no repeat of the same finding in the next quarter's internal check.
• Operating measures such as median time from leaving date to account disabled, tracked monthly.
• A tracker listing each finding, owner, evidence location and re-audit status, so re-audit evidence was findable.

Result. Honest results are specific and bounded: for instance, all high findings closed with evidence before re-audit and the auditors reported no repeat of those findings; two low items were carried over with an agreed date. Use only real outcomes.

What I would do differently. Involve engineering in remediation design earlier, rather than handing down tickets, since two first-attempt fixes were rejected as too heavy and had to be redone.

Direct answer. I would treat audit readiness as a delivery capability: build the evidence into the normal ML workflow, designate one audit owner who absorbs the audit load, and set up a findings process before the first finding arrives. Engineers keep shipping because the audit team pulls evidence from systems rather than asking engineers to assemble it.

1. Prepare the organization (before the audit)

• Inventory every ML system and decide which are in scope under the regulation (here, the EU AI Act, which sets extra duties for systems it calls high-risk, such as AI used to screen job applicants or score creditworthiness; counsel confirms classification and which assessment route applies, internal or third-party, and the current application dates).
• Give each in-scope system an owner and a standard evidence set: intended purpose, data sources and versions, evaluation results, risk assessment, human oversight design, change history.
• Generate that evidence automatically in the pipeline (model registry entries, which record each model version with its data and settings; versioned data; saved evaluation reports, including a model card, a short standard document describing what the model is for, how it was tested and its limits), not by hand at audit time.
• Run an internal mock audit (a practice audit run by your own staff) on one system to find gaps while stakes are low.

2. Handle the audit itself

• One liaison (the single point of contact between auditors and staff) and a request tracker (request, owner, due date, status). Engineers answer through the liaison.
• Time-box engineer involvement (illustratively two scheduled interview slots per team per week) so delivery planning stays predictable.
• Protect confidential material: NDAs, a read-only data room (a controlled space holding only the documents the auditor may see), redacted or summarized views, supervised demonstrations in place of handing over model weights or raw data, and a log of what the auditor saw.

3. Respond to adverse findings
An adverse finding is an auditor's conclusion that something falls short. Example tracker and finding (illustrative):

Triage by severity, correct any factual misreading with evidence, then give each accepted finding an owner, a root cause, a dated remediation plan and a retest. Report progress to leadership until closure. Where a fix is slow, propose a compensating control (an alternative safeguard that reduces the same risk) with an expiry date.

Trade-off. Up-front automation costs engineering time now, and I would fund it for the highest-risk system first. If most findings would turn out to be documentation gaps rather than behavior problems, I would invest in templates and model-card standards before tooling.