Audit Readiness, Evidence and Inspection Management Questions

Direct answer. Logs count as evidence when the auditor can trust three things: they are complete (nothing is missing), attributable (each entry names a real person or service identity), and tamper-evident (any edit or deletion would be detectable). Retention is set by the longest applicable requirement, and trust is shown by demonstrating the protections, not by asserting them.

What the auditor needs to see for one privileged change

• The request and approval: a ticket or change record with requester, approver (a different person), time, and scope.
• The execution record: an audit log entry (a time-ordered record of who did what, to which resource) showing the same ticket ID, the privileged identity, the action, source, and outcome.
• The link between them: the change ticket ID in the commit, pipeline run or session, so approval and action tie together without guesswork.
• Clock quality: all sources synchronized to a common time source, so ordering is defensible.

Making the record trustworthy (tamper-evidence)

1. Ship logs off the system being logged to a separate account or collector that the administrators of the source system cannot write to or delete from. Privileged admins editing their own trail is the main risk the auditor has in mind.
2. Store them in write-once (immutable) storage with retention locks (a setting that forbids deleting objects or shortening their retention until a set date), so the lock cannot be shortened before its date. Choose the strict mode: in S3 Object Lock, compliance mode cannot be overridden by any user, including the account's root user, while the weaker governance mode lets anyone holding a special bypass permission delete or shorten it, which would leave a privileged admin able to tamper.
3. Add integrity checks: hash chaining or signed log digests so a gap or edit breaks the chain. A hash is a fingerprint of data: change one character and the fingerprint changes completely. A digest is a small file listing the fingerprints of a batch of log files, signed with a private key so only the log service could have produced it. Chaining means each digest also contains the previous digest's fingerprint. Example: digest 1 lists the fingerprint of every log file in batch 1, and digest 2 also carries the signature of digest 1. Editing a log file in batch 1 changes its fingerprint, which no longer matches the value digest 1 recorded; deleting or replacing digest 1 itself is exposed because digest 2 still carries the signature of the original digest 1. Either way the auditor sees the break.
4. Restrict and log access to the log store itself (the logs about the logs).
5. Show completeness: an expected-source inventory, plus an alert or check that every source delivered logs each day.

Worked example. An engineer used a break-glass admin role (an emergency elevated-access role that skips normal pre-approval, so each use is reviewed afterwards) at 14:02 to change a database parameter. Evidence pack: emergency change ticket CHG-1042 opened at 13:58 declaring the emergency, and approved after the fact by a second engineer at 15:10 (the after-the-event review that break-glass requires, since no approval could be obtained beforehand); the role-assumption event and the parameter-change event, both citing CHG-1042; the digest file covering that hour with its stored hash; and a log showing the digest verified clean at the next daily check. Then the auditor can re-verify the hash themselves.

Retention. Do not pick a number from habit. Take the longest of: legal or regulatory requirements for your sector, contractual commitments, and the audit look-back window (how far back the auditor samples: usually a full audit period, often 12 months, and sometimes the prior period for comparison, so those older records must still exist). Example only: if the strictest rule in force is 7 years, keep audit logs 7 years, with a recent window (say 90 days) fast to search and the rest in cheaper immutable archive. Counsel confirms the legal minimum; the auditor confirms the look-back.

Pitfalls. Logs the same admin can edit; logs rotated out before the audit period ends; approvals living only in chat; shared accounts that break attribution; unsynchronized clocks.

Direct answer. In 72 hours, I would not try to prove everything. I would scope to exactly what the notice asks (encryption in transit and at rest for the named product), inventory services and data stores, collect system-generated configuration evidence from each, validate it with independent checks, assign owners per service, and report gaps openly with a remediation plan rather than hiding or hurriedly fixing them before the evidence is captured.

Timeline (hours elapsed; illustrative split of 72)

• 0 to 4: read the notice with compliance or counsel to pin the exact ask and deadline; name one lead who coordinates the effort the way an incident commander coordinates an outage (one decision-maker, regular status updates) and an evidence owner per service.
• 4 to 24: inventory every service, data store, queue, backup and external connection; start collection.
• 24 to 48: collect and validate.
• 48 to 60: analyse gaps, decide interim measures, draft the response.
• 60 to 72: review, finalise and deliver.
  That is 4, 20, 24, 12 and 12 hours: 72 in total.

Collect (system-generated, dated)

• At rest: provider API exports of storage, database, volume and backup encryption settings, plus key management settings (key type, for example customer-managed or provider-managed, plus rotation schedule and who can use the keys).
• In transit: TLS configuration for external endpoints, internal service-to-service settings, load balancer policies; and scan output confirming which protocol version (such as TLS 1.2) and which cipher suite (the named set of encryption algorithms the two sides agree on for a connection) are actually negotiated.
• Infrastructure as code and policy checks that enforce encryption, as supporting evidence.

Validate. Do not trust configuration alone. Sample live endpoints with an external scan; compare the inventory to the cloud account's resource list to catch services nobody mentioned; check exceptions are documented.

Owners. Platform team: storage and keys. Service teams: their own endpoints. Security: validation and scans. Compliance: the response and communication with the regulator. One person integrates.

When gaps appear. Do not quietly fix first and capture afterwards, because the evidence must show the state at the time; capture, then fix. Classify by data sensitivity and exposure, apply a quick compensating measure (a temporary, different safeguard that lowers the same risk) where possible (for example, restrict network access while a legacy store is migrated), record owner and date, and disclose in the response. Counsel decides what the notice requires you to say.

Worked example. Inventory 31 data stores (illustrative); 29 encrypted at rest, 2 not. Both are internal and low-sensitivity: documented, access restricted, migration dated in 3 weeks (illustrative). The response shows 29 of 31 with evidence, 2 with plans.

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