IT Audit Manager

If the report's completeness and accuracy are unproven, every test built on it is unreliable.

Pause reliance, have the team reperform the extraction or reconcile record counts to the source tables, and document the steps as information provided by the entity testing.

Re-running costs days of fieldwork; reporting with a caveat weakens the opinion.

I would tell the audit committee chair the timeline moved because the evidence base needed validation, which protects the opinion's credibility.

Absence of an incident is not evidence a control works. The rating should follow your methodology, not the reaction.

Re-check the facts and rating criteria with the team, then meet the business head to walk through impact and likelihood using the agreed scale.

Downgrading keeps the relationship but erodes independence; holding firm without listening looks rigid.

I would keep the rating if the criteria support it, record management's view in the report, and brief the CAE before the CEO conversation happens.

The assurance report covers part of the risk; the carve-out and your company's own configuration are untested.

Map the report's controls to your audit objectives, list the complementary user entity controls, and test those plus your tenant configuration directly.

Requesting a right-to-audit clause is slow; accepting the report alone leaves a gap.

I would report what was covered, what relied on third-party assurance, and the residual gap, and recommend the contract and vendor-management actions to close it.

Cutting by subject rather than risk could leave the highest exposures unaudited.

Re-rank the remaining plan by risk, identify audits that could rely on second-line work, and show which risks lose coverage under each option.

Relying on second line saves hours but needs you to assess their quality; deferring adds risk to next year's plan.

I would take a revised, risk-ranked plan to the audit committee for approval, making explicit which risks are uncovered by the cut.

This may be fraud or a poorly designed workflow; either way, normal fieldwork could tip off a suspect.

Preserve evidence, stop discussing it with the auditee, and escalate under the fraud protocol to the CAE and legal or investigations.

Investigating yourself risks tainting evidence; waiting too long risks more loss.

I would brief the CAE immediately, keep the audit report factual about the SoD design gap, and let investigations handle the individual.

Continuous auditing needs reliable data feeds and owners for exceptions; without them it produces noise.

Pick one high-value, data-ready area such as privileged access or payments, prove the analytics, and define who triages exceptions.

A broad launch impresses but floods teams; a narrow pilot looks slow but builds trust.

I would commit to a pilot with measurable exceptions found and closed, and a roadmap for wider coverage once data access is fixed.

This is a quality issue with your function's own work; it may affect reliance by external auditors.

Assess whether the gaps change the conclusion by reperforming key tests now, and log it through the quality assurance process.

Quiet re-testing protects reputation short term; formal disclosure is uncomfortable but defensible.

I would inform the CAE and, if the conclusion changes, the committee, and tighten review sign-off so it cannot recur.

The control objective is unchanged: only authorised, tested changes reach production. The evidence now lives in the pipeline.

Walk through the pipeline with engineers to find the gates (peer review, automated tests, restricted deploy rights) and test those settings and their override logs.

Testing pipeline configuration needs new skills; sampling tickets the old way misses bypasses.

I would explain to leadership that we audit the pipeline as the control, and report any bypass path as the key risk.

Self-assessments are useful but rarely independent; all-green results are a warning sign.

Reperform a sample of their tests to measure accuracy before deciding any reliance.

Reliance saves hours; misplaced reliance damages the audit opinion.

I would report the accuracy rate found and set reliance levels by area, with clear conditions for increasing it.

An overall opinion needs a basis; giving one from limited work overstates assurance.

Combine your audits, second-line results and external assessments into an assurance map showing coverage and gaps by domain.

A heat map is easy to read but can imply more certainty than exists.

I would give an opinion limited to the areas covered, show the assurance map, and propose the work needed for a full opinion next year.