Audit Readiness, Evidence and Inspection Management Questions

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).

Direct answer. I would first assess whether the gap caused harm, then build a factual timeline and evidence pack of what happened across the 90 days, stand up credible interim measures, and fix the process failure. I would be honest that the control failed for that period. The aim is a defensible account, not an excuse. A policy that says critical vulnerabilities are patched within a set number of days (for example 30, whatever our own policy says) was breached, so I would not argue otherwise.

1. Establish the facts

• Timeline: disclosure date (the day the vulnerability was publicly announced, usually with a patch or advisory), detection date, when it was assigned, each reason for delay, and the patch date. 90 days of exposure from disclosure; I would verify the start date from the scanner or advisory record.
• Impact assessment: was the asset internet-facing, was there a known exploit, did logs show exploitation attempts or compromise in the window? A review of logs for indicators of exploitation (traces showing someone tried or managed to use the flaw, such as odd requests or unexpected processes) across all 90 days is essential. If there is evidence of compromise, this becomes an incident and incident response and notification rules take over.
• Scope: how many assets, and whether the same delay applied to other critical vulnerabilities (query the vulnerability system for all criticals older than policy).

2. Evidence to explain the period honestly
Ticket and scanner history, the risk acceptance record (the signed decision by a named owner to live with a risk for a stated time; or its absence), change records that blocked patching (a dependency, a freeze), and communications. If no one formally accepted the risk, say so. Do not create a retroactive exception approval; document it as a missing approval.

3. Interim measures an auditor may accept as compensating
Which of these fits depends on the vulnerability, and none is automatically best: a firewall rule only helps if the flaw is reachable through traffic the firewall sees, isolation only helps if the system can be cut off without breaking the business, and so on. These must reduce the same risk (exploitation of that vulnerability) and leave evidence, ideally from the period itself:

• Virtual patching (blocking the attack without changing the vulnerable software), such as a web application firewall (WAF) rule on web traffic or an intrusion prevention system (IPS) signature that recognises and drops the exploit.
• Network isolation or removing internet exposure.
• Disabling the vulnerable feature or service.
• Heightened monitoring and detection for the specific exploit, with reviewed alerts.
  Evidence that existed during the 90 days counts for most. A mitigation added after the auditor noticed protects going forward but does not retroactively cover the period; describe it that way.

4. Showing it will not recur

• Root cause: why 90 days? (No owner, no SLA tracking, patching blocked by testing capacity.)
• Fixes: vulnerability SLAs (service-level agreements: maximum allowed days to fix per severity) by severity with automatic escalation at, say, 50% and 100% of the window; named asset owners; a formal, time-limited exception process; automatic reporting to a risk owner.
• Proof: a monthly report of criticals past SLA, running for several consecutive months, and a sample test showing the escalation fired.

Worked example. Disclosure on 2026-05-04: day 30 falls on 2026-06-03 and day 90 on 2026-08-02. A WAF rule deployed on 2026-05-07 and reviewed logs for the whole window show whether interim protection existed from day 3, which is a very different story from a rule added on day 85.

Pitfall. Pretending a control operated. Auditors respond far better to an honest deviation with analysis than to a reconstructed story.

Direct answer. I would build a provability matrix for each key system, covering what log evidence exists, how long it is kept and whether it is tamper-resistant. Then I would close what I can (turn on, export, centralize, protect), use compensating evidence where logs are not available, and tell the auditor plainly which periods are covered, which are not, and what replaces them.

1. Work out what you can prove today
For each key system ask: can I answer "who did what, when" for the audit period? Record the log source, retention, whether admin and data actions are both covered, and who can edit or delete it. Label each system Provable, Partial or Not provable.

Illustrative matrix, five systems:

Two Provable, two Partial, one Not provable.

2. Close the gaps

• Enable every log the service offers, and export before the vendor's retention expires.
• Centralize into a protected store with write-once retention.
• Ask vendors about higher service tiers or log access, and request their assurance reports (independent audit reports about the vendor's controls, such as a SOC 2 report).
• Compensating evidence (different records that support the same conclusion when the ideal log is missing). For the vendor-run support portal: sign-in records from the identity provider showing who could reach the system, change tickets, and approvals.

3. What to tell the auditor
State for each system the date logging began, what existed before, what alternative evidence covers earlier periods and what it cannot prove. Do not backfill (create or reconstruct logs for earlier dates) or imply earlier coverage. Sample wording (illustrative): "Exported, retained logging for the billing tool began 1 July 2026 (before that the tool kept only its own 30-day window). For earlier dates we hold change tickets and identity-provider sign-in records, which show who could reach the tool but not what they did." Give owners and dates for remediation.

What changes my call. If the uncovered system holds the most sensitive data, I would prioritize replacing or changing it over documenting the gap.

Direct answer. I would give the regulator everything that genuinely covers the year, label each piece by what it is, and state the gap plainly with dates. I would never reconstruct the missing logs and present them as originals. Legal reviews the wording before it goes out, and the remediation fixes retention going forward.

1. Scope the evidence (what to hand over)

• Define the request window first: 365 days (illustratively 1 Oct 2025 to 30 Sep 2026).
• Incident response timelines (detection, acknowledgement, mitigation, resolution) come from the system of record for incidents (the one tool where the official version of that data lives): incident tickets, paging records, and post-incident reviews. These usually outlive raw logs.
• SLO (service-level objective, a reliability target such as "99.9% of requests succeed") adherence comes from the metrics store, which often keeps downsampled data (older points rolled up into hourly or daily averages to save space) far longer than logs. Recompute from the retained metrics and show the query.
• Raw logs cover only the retained part. Offer them as supporting detail, not as the sole proof.

2. Document the gap honestly
Worked example (illustrative): logs are kept 180 days, so retained logs start 4 Apr 2026. The 365-day window has 185 uncovered days (1 Oct 2025 to 3 Apr 2026), which is 50.7% of the window; 49.3% is covered by logs.

Example gap statement (illustrative): "Raw logs are available for 4 April 2026 to 30 September 2026 (180 days). For 1 October 2025 to 3 April 2026 (185 days) raw logs were not retained, because the retention setting was 180 days. Incident timelines for that period come from the incident ticketing system and paging records (original). SLO attainment was recomputed from retained hourly metrics (reconstructed); it cannot show individual request outcomes."

A gap statement should say: the window, the dates with no raw logs, why (the retention setting), which alternative sources cover those dates, what each alternative can and cannot show, and which figures are recomputed rather than original. Keep a table with one row per evidence item and a column "original / reconstructed / not available".

3. Remediation proposed to auditors and legal

• Immediately: place a legal hold on what exists (a lawyer-ordered freeze on deleting specified records, so nothing more ages out), and ask counsel whether the regulator needs a formal disclosure (a statement to the regulator that the gap exists, separate from handing over evidence) and how to word it.
• Fix: set retention from the longest period any regulation, contract or SLO reporting needs, using cheaper archive storage after the hot period (the recent window kept fast to search), and export incident and SLO data on a schedule.
• Prove the fix: a retention configuration screenshot or export plus a dated test that old data is still retrievable.

What changes my call. If the regulator's rules fix a specific retention period, the gap is a compliance failure, not only an evidence gap, and counsel leads the disclosure. Never backdate, edit or fabricate records.

Direct answer. A SOC 2 (System and Organization Controls 2, an AICPA report on controls relevant to security, availability, processing integrity, confidentiality and privacy) Type II report tests whether controls operated effectively across a period, unlike Type I, which looks at design at a single date. The length of the period is agreed with the auditor in advance; here it is six months. To show a control ran for the whole period, I need dated, system-generated records across the period and a population the auditor can sample from, not a screenshot from audit day. The population is the complete list of items a control applies to (every change, every leaver), and the auditor selects samples from it, so I have to be able to produce the complete list for the six months.

Evidence the auditor trusts more
Ranked from stronger to weaker, by how little the control owner could have shaped it:

1. Pulled by the auditor from the source system (the auditor runs their own query, or watches you run it). You could not have filtered or edited the data.
2. System-generated exports from a system with integrity controls (ticketing or source control with timestamps and edit history, exported by you). Trusted, but the auditor must confirm your report was complete.
3. Recurring evidence (monthly review sign-offs) across every month. Good for showing the period was covered, weaker because a person produced each sign-off.
4. Evidence prepared manually by the control owner (a spreadsheet). Easily edited, so it needs corroboration.
5. A single screenshot or config export taken on one day, which proves state at that moment only.
   Auditors also test the completeness and accuracy of any report you give them (does it include every record, and are the values right), so explain how it was generated.

How to show coverage of the whole period
Take the period 2026-01-01 to 2026-06-30 (181 days, about 26 weeks). A control that runs weekly should have about 26 occurrences, one for each week. Produce all 26 with dates and reviewer; any gap is a deviation (an occurrence where the control did not run as designed) to explain. For event-driven controls (every production change needs approval), the population is every change in the period, and the sample is drawn from it.

Evidence by area, linked to the Trust Services Criteria (the AICPA's control criteria. The codes are labels you do not need to memorise; know that the series exist. The common criteria series cover access (CC6), system operations and monitoring (CC7) and change management (CC8); your auditor's mapping is authoritative.)

Worked example. Claim: every production change is approved by someone other than the author. Evidence: branch protection requiring one approving review, its configuration history, and an export of all 412 merged changes (illustrative) with approver and author fields. The auditor samples some; any change merged by an administrator override is listed and explained.

Pitfall. Taking evidence once at audit time. Collect continuously, since late screenshots cannot show a prior state.