Audit Fieldwork and Evidence for Engineers

First PublishedApr 29, 2026Last UpdatedMay 1, 2026ByAtif Alam

This page is about what an engineer actually does when their org is in a SOC 2, ISO 27001, PCI DSS, or HIPAA cycle. It covers the fieldwork side — sitting in walkthroughs, producing evidence, answering questions — not the legal interpretation of the frameworks themselves.

Nothing here is legal, audit, or compliance advice. This is engineer-facing fieldwork guidance only. Coordinate with your GRC, security, and legal owners; defer to your auditor’s actual asks.

The CI/CD-specific slice — audit trails, separation of duties, signed commits, change records, and SLSA — lives in CI/CD compliance and audit. This page covers the broader fieldwork patterns that apply across the org.

What Auditors Are Trying to Do

An auditor’s job is to gather evidence that your stated controls (a) exist and (b) operated effectively over the audit period. They are not trying to find what you didn’t think of; they are testing what you said you had.

This shapes everything an engineer needs to know about fieldwork:

Controls are claims you wrote down, usually in a control matrix or trust services criteria mapping. The auditor tests those, not arbitrary things.
Evidence has to cover the period, not just today. “We do this now” is not enough if the audit period is the last 12 months.
Sampling is the dominant testing method — auditors rarely look at everything.
Walkthroughs establish that the control exists; sample testing establishes that it operated.

Types of Evidence

Most engineering evidence falls into a few categories. Knowing which is which speeds collection.

Category	Examples	Source
Identity and access	User lists, role assignments, MFA status, deactivation logs.	IdP (Okta, Azure AD), cloud IAM, Kubernetes RBAC.
Change management	Pull requests with reviews and approvals, deployment records, ticket links.	GitHub/GitLab, Jira/Linear, CI/CD logs.
Configuration	IaC source for production, drift detection reports, baseline configs.	Git repo, Terraform state, config management.
Logs and audit trails	Access logs, admin action logs, SIEM exports.	Cloud provider audit logs, SIEM, application logs.
Vulnerability and patching	SAST/SCA reports, patch compliance, vulnerability scan output.	Security scanning tool, container scanner, SBOM.
Backup and recovery	Backup success records, restore drill results.	Backup tool, runbook attachments, ticket records.
Monitoring and alerting	Alert rules, on-call schedules, incident records.	Prometheus/Alertmanager, paging tool, incident tool.
Vendor management	Vendor list, vendor SOC 2 reports, DPAs.	GRC platform, contracts repo.
Training and policies	Acknowledged policies, training completion.	HR / GRC system.

The first three categories are the ones engineers carry directly. The rest usually have a partial-engineer, partial-GRC owner.

Walkthroughs

A walkthrough is a meeting where the auditor sits with the control owner and watches the control operate end-to-end. It establishes that the control exists in the form claimed.

Typical Engineering Walkthroughs

Control Area	Walkthrough Looks Like
Code change	Open a sample PR; show review approval, CI passing, merge, deployment record.
Production access	Show how an engineer requests production access; approval flow; expiration.
Joiner/leaver	Show a real onboarding ticket and offboarding record; show that access was actually removed.
Backup	Show backup tool dashboard with successes; show last restore drill record.
Vulnerability scan	Show the scan output; show the ticket created from a finding; show its remediation.
Incident response	Walk through a real recent incident: detection, response, postmortem, action items.

Preparing for a Walkthrough

Have the link ready — do not search for things during the meeting; you’ll look uncertain.
Use a real example — pick one ahead of time. Auditors prefer real over hypothetical.
Know who else owns parts of the flow — if a step is owned by another team, name them and offer a follow-up rather than guessing.
Take notes on follow-up items — auditors will ask for evidence after the meeting; capture what they want and by when.

What Not to Do

Don’t volunteer extra controls the auditor didn’t ask about. They become in-scope and now need evidence.
Don’t speculate about whether something would catch a hypothetical attack. Stick to what the control actually does.
Don’t say “always” or “never” unless you can prove it. “Generally” and “in our standard process” are honest.

Sampling

After walkthroughs establish that a control exists, the auditor picks a sample of operations from the audit period and asks for evidence of each.

Common Sample Asks

Request	What to Provide
”5 production deploys from Q2 2026”	Deploy ticket / PR + reviewer + CI run + production deployment log.
”10 new hires from the audit period”	Onboarding ticket + access requests + IdP creation date + role assignments.
”All terminations from the audit period”	Termination ticket + IdP deactivation timestamp + production access removal evidence.
”5 high-severity vulnerabilities from your scanning tool”	Original scan finding + remediation ticket + verification it was fixed.
”All changes to the production firewall”	Change tickets + approvals + before/after config + ticket close.

Engineering Mistakes That Hurt Sample Testing

Inconsistent ticket linking — if half the deploys reference a ticket and half don’t, sampling becomes painful and looks bad.
Manual changes without a corresponding ticket or PR — these are the worst auditor finding because they have no audit trail.
Stale evidence — pointing to a wiki page that hasn’t been updated since the previous audit cycle. Auditors notice timestamps.
Untested backups or restore drills — if you cannot show a successful restore in the audit period, the control fails regardless of how often backups ran.

Common SOC 2 Themes Mapped to Engineering Reality

SOC 2 organizes controls into Trust Services Criteria (TSC). The engineering-relevant ones map roughly as below. (Your auditor or GRC owner will share the actual matrix.)

TSC Area	What It Means for Engineering
CC6 — Logical and Physical Access	IdP, MFA, least privilege, joiner/mover/leaver, production access controls.
CC7 — System Operations	Monitoring, alerting, incident response, change detection, vulnerability management.
CC8 — Change Management	PR review, approvals, separation of duties, deployment records — see CI/CD compliance.
CC9 — Risk Mitigation	Vendor risk, BCP/DR, incident impact assessment.
A1 — Availability (if in scope)	SLOs, capacity, backups, restore drills, redundancy.
C1 — Confidentiality (if in scope)	Data classification, encryption at rest and in transit, access controls.

ISO 27001 organizes controls differently (Annex A) but the underlying engineering practices are largely the same.

PCI DSS and HIPAA add specific technical requirements (network segmentation for cardholder data; encryption and audit for PHI). Treat them as additive to the SOC 2 baseline.

Questions Auditors Often Ask Engineers

A short list of questions to be ready for. Frame answers in terms of what controls do, not what’s possible:

“Walk me through what happens when a developer wants to deploy to production.”
“How do you know that an engineer who left the company three months ago no longer has production access?”
“How are vulnerabilities found in your container images surfaced and fixed?”
“Show me a real incident from this quarter and walk through the response.”
“How do you ensure that the configuration in production matches what’s in your IaC repository?”
“What happens when a backup fails? How do you find out?”
“How are production access requests reviewed and approved?”
“How do you handle access for vendors or contractors?”
“Walk me through your last restore drill.”

For each, prepare a two-sentence answer plus a real example.

Handoff With GRC

Most orgs above a certain size have a GRC (governance, risk, compliance) function or designated security/compliance owner. Engineers should not be running audit cycles alone. Patterns that prevent dropped balls:

Single point of contact (SPOC) between engineering and GRC for the audit. Reduces channel sprawl.
Evidence requests routed to the SPOC, not directly to engineers. The SPOC triages.
Shared evidence repository (often a folder or GRC platform) where engineering uploads artifacts. GRC handles auditor delivery.
Status sync at least weekly during the audit window — open requests, blocked requests, deadlines.
Post-audit retro — what was painful to collect this time becomes automation work for next time.

Making Future Audits Easier

The single highest-leverage thing engineering can do for compliance is make evidence a byproduct of the normal workflow, not a special collection exercise.

Practice	Why It Helps
Tickets on every change	Sample testing becomes “click this ticket” instead of “let me dig through Slack.”
Branch protection and required reviews	Auditor sees the policy and the evidence in one place. See CI/CD compliance.
IdP-driven access with regular reviews	Joiner/leaver evidence is automatic.
Logged access to production with approvals	Production-access sample testing becomes trivial.
Automated vulnerability scanning with ticket creation	The scan run + ticket + remediation is a complete evidence package.
Restore drill calendar with documented results	Backup control passes without scrambling.
Postmortems for every incident, with action items tracked	Incident response evidence exists by default. See Incident response and on-call.

If preparing for the audit feels like a project, the controls are not yet operating as a byproduct — that’s the gap to close before the next cycle.

Checklist

You know which controls your team owns; you have read the relevant rows of the control matrix.
For each control, you can name a real recent example to use in a walkthrough.
Production access has an approval flow with timestamps; you can produce sample evidence in under 10 minutes.
Joiner/leaver flows leave a paper trail in the IdP; access removal is verifiable.
Backup and restore evidence covers the audit period, including at least one restore drill.
Vulnerability scan output flows into tickets that close with verifiable remediation.
You have a SPOC with GRC for the current audit cycle; you are not the sole funnel.
Post-audit retros surface automation opportunities; engineering picks up at least one each cycle.

CI/CD compliance and audit — change management, separation of duties, SLSA, and SOC 2 mapping for the CI/CD pipeline specifically
Security scanning (DevSecOps) — SAST/SCA/container scanning evidence
Kubernetes RBAC — access control evidence on the cluster
Pod Security Standards — workload security baseline
AWS IAM — access control evidence on AWS
Service readiness checklist — production gates that double as audit-friendly defaults